Oracle 唯讀模式下 Cache Buffers Chains Latch 爭用測試與結論

測試背景

Oracle 9i 引入「唯讀模式獲取 CBC Latch」優化：純查詢（全表掃描/索引範圍掃描）以共享模式獲取 Cache Buffers Chains (CBC) Latch，降低獨佔模式爭用。但實測發現高併發下仍有顯著爭用。

測試環境建立

-- 1. 建表
CREATE TABLE test (a INT, b VARCHAR2(20));

-- 2. 載入 50,000 筆資料
BEGIN
  FOR i IN 1..50000 LOOP
    INSERT INTO test VALUES (i, 'adsfsafsa');
  END LOOP;
  COMMIT;
END;
/

-- 3. 建立索引
CREATE INDEX test_i ON test(a);

-- 4. 存儲過程：大量索引掃描
CREATE OR REPLACE PROCEDURE test_k IS
BEGIN
  FOR rec IN (SELECT /*+ INDEX(TEST TEST_I) */ * FROM test WHERE a > 20000) LOOP
    NULL;
  END LOOP;
END;
/

高併發施壓

-- 開啟 2000 個 DBMS_JOB 並行執行 test_k
VAR i NUMBER;
BEGIN
  FOR j IN 1..2000 LOOP
    DBMS_JOB.SUBMIT(:i, 'TEST_K;');
    COMMIT;
  END LOOP;
END;
/

觀測結果

• 等待事件： `latch: cache buffers chains` 佔據絕大多數等待時間。
• CPU 模式： `top` 顯示 `83.7% sy` (System/Kernel 模式)，`16.3% us` (User 模式)，極少 `id` (Idle)。

Cpu(s): 16.3%us, 83.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

結論

唯讀模式獲取 CBC Latch 並未徹底解決熱塊爭用問題，僅降低爭用嚴重度。

原因分析：

1. 索引根塊、分支塊極易成為熱點，所有併發掃描必須經過。
2. 共享模式雖允許並發讀取，但 Latch 獲取/釋放仍需原子操作（CAS/自旋），極高併發下自旋消耗大量 CPU。
3. 9i/10g 尚未引入「CBC Latch 子分區」或「無鎖一致性讀」機制（11g+ 引入 `_kcb_latch_contention` 參數與優化）。

緩解策略（9i/10g 環境）

結語

唯讀模式 CBC Latch 是重要優化里程碑，但非銀彈。面對極高併發索引掃描場景，**架構層面分散熱點**與**應用層面減少重複存取**才是根本出路。測試方法（建表→建索引→存儲過程→DBMS_JOB 施壓→觀察 `latch: cache buffers chains` 與 CPU `sy%`）可作為評估新版本/參數效果的標準基準。