核心架構差異
| 面向 | SQL Server | Oracle |
|---|
| 並發控制模型 | 鎖定為主（悲觀），輔以快照隔離（樂觀） | 多版本並發控制 (MVCC)，預設樂觀 |
| 讀取一致性 | 預設 READ COMMITTED 使用共享鎖，寫入會阻塞讀取 | 讀取不阻塞寫入，寫入不阻塞讀取，透過回滾段/Undo 表空間提供陳述式層級一致性讀取 |
| 舊版本資料儲存 | tempdb 版本存放區（啟用快照隔離時） | 回滾段 或 Undo 表空間 |
| 長時間查詢風險 | 快照隔離下版本存放區壓力大可能導致查詢失敗 | Undo 空間不足導致「Snapshot too old」錯誤（ORA-01555） |
Oracle 回滾段與 Undo 表空間演進
- Oracle 8i 及之前：手動管理回滾段，DBA 需規劃段數量、大小、擴展參數，配置不當易導致交易排隊等待。
- Oracle 9i+：引入 Undo 表空間，自動管理 Undo 保留時間與空間分配，大幅降低管理複雜度。仍可選擇使用傳統回滾段。
實務案例比較
情境：上午 11:59 開始更新 John Doe 帳務，12:01 提交。同時 12:00 財務經理啟動全客戶帳務報表查詢（耗時較長）。
- Oracle：查詢看到 12:00 時間點的一致性快照，若期間 John Doe 的 Undo 記錄被覆寫，查詢會拋出 ORA-01555 錯誤。
- SQL Server (預設 READ COMMITTED)：查詢會被更新交易的獨佔鎖阻塞，直到交易提交或回滾，可能導致長時間封鎖。
- SQL Server (啟用 READ_COMMITTED_SNAPSHOT)：查詢讀取 tempdb 版本存放區的 12:00 快照，不阻塞更新，但需監控 tempdb 空間與版本清除速度。
總結
- Oracle MVCC 架構在抽象層面提供更優雅的讀寫不阻塞特性，適合高並發讀取場景。
- SQL Server 傳統鎖定機制簡單直觀，但在高並發下易產生封鎖；快照隔離可緩解，但引入 tempdb 管理負擔。
- 兩者在海量使用者下的實際一致性表現，取決於具體工作負載、硬體資源與參數調校，無絕對優劣。
