Oracle 並行 DML 迷思（二）：並行 UPDATE 竟會鎖全表

Oracle 並行 DML 迷思（二）：並行 UPDATE 竟會鎖全表

許多開發者以為 Parallel DML 僅鎖定修改的行，實測發現：Parallel UPDATE 會對整張表加排他鎖 (TM-X)，導致同表其他 Session 的 DML 完全阻塞。本文以實驗證實此行為，並解析 V$LOCK 關鍵欄位含義。

實驗場景

-- Session 1：並行更新
ALTER SESSION FORCE PARALLEL DML;
UPDATE /*+ PARALLEL(t,4) */ test t SET object_name='ggg' WHERE object_type='TABLE';
-- 持有鎖，未提交

-- Session 2：嘗試更新不同條件行
UPDATE test t SET object_name='ggg' WHERE object_type='INDEX';
-- Hang 住，等待 TM 鎖

-- Session 3：查詢鎖狀態
SELECT sid, type, id1, id2, lmode, request, ctime, block
FROM v$lock WHERE sid IN (8,11) ORDER BY sid;

鎖狀態分析

結論：Session 1 並行更新持有 TM 模式 6 (Exclusive)，Session 2 請求模式 3 (Row-X/SX) 即被阻塞。V$LOCKED_OBJECT 同樣顯示 OBJECT_ID=80189 的 LOCKED_MODE=6 (X) 與 0 (None)。

V$LOCK 關鍵欄位速查

為什麼並行 DML 需鎖全表？

• 並行執行單元需協調分區範圍、避免重複掃描，協調器需獨佔表級元數據鎖。
• 直接路徑載入、並行 DDL/DML 設計上即要求排他表鎖，確保資料一致性與恢復簡化。

實務對策

1. 避開高峰：並行大量更新安排在維護窗口。
2. 分批提交：將大 UPDATE 拆分為多個小批次，各自提交釋放鎖。
3. 考慮 CTAS：CREATE TABLE new AS SELECT ... + 重建索引/約束 + 重命名，鎖定時間極短。
4. 監控腳本：定期查詢 V$LOCK 發現 TM-X 長持有者並告警。