Oracle 與 SQL Server 企業級應用架構深度對比：鎖機制、一致性與擴展性

背景動機

作者所在企業同時運行 Oracle 與 SQL Server，常面臨兩類詢問：
1. 「教我用 Oracle」—— 學習曲線陡峭。
2. 「SQL Server 遇到問題，Oracle 怎麼處理？」—— 具體問題導向，價值較高。
本文聚焦架構層面的根本差異，而非功能清單對比。

核心差異：讀寫鎖定機制

SQL Server：讀寫阻塞

預設 READ COMMITTED 隔離等級下，讀取者封鎖寫入者，寫入者封鎖讀取者。
微軟宣稱可防止「髒讀」，實則是效能妥協的藉口。

Oracle：多版本並發控制 (MVCC)

• 讀取者永不封鎖寫入者，寫入者永不封鎖讀取者。
• 修改在記憶體建立新版本，COMMIT 前其他交易仍讀到舊版本（讀取一致性）。
• 長時間交易不回滾也不會阻塞讀取者，讀取者看到的是交易開始時的資料快照。

超市買果汁比喻

• SQL Server：你站在貨架前猶豫，別人想買同款果汁必須等你決定拿走或放回才能看見貨架現況。
• Oracle：你猶豫時，別人依然能看見貨架上所有果汁，甚至打電話詢問家人意見；只有你真正結帳（COMMIT）後，庫存才更新，他人下次查詢才會看到新數量。

企業級系統的致命影響

高並發環境下，同一熱門資料表頻繁更新且大量讀取：
SQL Server 的讀寫阻塞會導致連鎖封鎖、逾時、死結，系統吞吐量崩潰。
Oracle MVCC 天然適合高並發讀寫共存，是企業級 ERP/CRM 系統的架構優勢。

其他架構痛點（SQL Server）

• 記憶體不足觸發鎖升級，擴大封鎖範圍。
• 缺乏讀取一致性，長查詢可能回傳「進行中」的不一致資料。
• DBCC 維護作業耗時、需離線、易造成效能抖動。
• 「自我調整」機制常干擾 DBA 手動調校。
• 縱向擴展受限，TPC 基準測試成績不代表真實業務擴展性。

結語

架構特性由核心機制決定，非使用者可輕易改變。選擇平台即選擇其先天優缺點。Oracle MVCC 為高並發一致性讀取而生，SQL Server 鎖架構適合低衝突、高寫入吞吐場景。企業級決策應以業務並發模式為依據，而非單純功能清單比較。