DB2 Capture 程式深度解析：核心進程架構、CD 表生命週期與效能調優關鍵

DB2 Capture 程式是 SQL Replication / Q Replication 複寫拓撲中的「心臟」，負責從來源資料庫日誌中擷取變更、寫入變更資料（CD）表，供 Apply 程式後續傳遞。掌握其內部進程模型與關鍵參數，是保障複寫低延遲、高穩定的前提。

四大核心進程職責拆解

工作進程：日誌讀取與寫入節奏

工作進程持續運行，非事件觸發。它從記憶體中的重做日誌緩衝區優先讀取已提交交易（Committed Transactions），批次寫入 CD 表。`COMMIT_INTERVAL` 控制「攒批寫入」頻率：

• 值過大 → CD 表膨脹、複寫延遲上升、修剪壓力增大。
• 值過小 → 頻繁提交增加日誌寫入與鎖競爭，拖垮來源庫效能。
• 建議：從預設值起步，監控 `CAPTURE_LATENCY` 與來源庫 `LOG_WRITE_TIME`，微調至延遲 < 5 秒且來源庫 CPU 增長 < 3% 的平衡點。

修剪進程：雙軌制清理機制

CD 表是暫存區，若不清理將無限增長。修剪進程執行兩種獨立邏輯：

1. 正常修剪：讀取修剪控制表，確認某筆變更已被所有訂閱的目標表套用，才刪除 CD 列與對應 UOW 表列。由 `PRUNE_INTERVAL` 控制掃描頻率。
2. 保留限制修剪：兜底機制。無論是否已複寫，CD 列存活超過 `RETENTION_LIMIT`（預設 86400 秒/24 小時）即強制刪除，防止應用端長時間停滯導致 CD 表暴增。

參數調優鐵律：`RETENTION_LIMIT` 必須 > 最大可容忍的 Apply 停機時間 + 複寫追趕時間。設太短恐丟失未複寫資料；設太長則儲存浪費。建議：生產環境設 48~72 小時，並配合監控告警（CD 表列數、修剪落後量）。

效能調優三大黃金法則

1. 日誌讀取優先走記憶體：確保 `LOGBUFSZ`、`LOGFILSIZ`、`LOGPRIMARY`/`LOGSECOND` 配置充足，減少工作進程落盤讀取。
2. CD 表獨立表空間 + DMS 裸裝置：高頻寫入/刪除特徵極需連續 I/O 與無雙重緩衝。
3. 監控指標儀表板化：重點監控 `CAPTURE_LATENCY`、`CD_TABLE_ROWS`、`PRUNE_STATUS`、`LOG_READ_LSN_GAP`，設定分級告警。

總結：Capture 程式看似「讀日誌、寫 CD 表」簡單，實則是高併發、強一致、長運行的系統級服務。DBA 的核心價值在於：以業務 SLA 為錨，將 `COMMIT_INTERVAL`、`PRUNE_INTERVAL`、`RETENTION_LIMIT` 三參數調至「延遲可控、空間收斂、來源庫無感」的最佳三角區。