日誌傳送核心概念
隨著企業對 24×7 全天候服務需求升級，「四個九」（99.99%）可用性成為標配。日誌傳送是一種低成本、高可靠的備援方案：自動將主資料庫的交易日誌備份並傳送至備用伺服器，備用端持續重播日誌保持與主庫近乎同步。主庫故障時，備用庫可在極短時間內接管服務。
為何選擇日誌傳送？
- 成本效益高：無需昂貴叢集軟硬體，主備硬體規格可異構，備用機平時可跑其他工作負載。
- 部署維護簡單：一次設定，長期受益。
- 熱備援特性：備用資料庫處於前滾狀態，記憶體快取已暖機，故障切換極快。
- 資料損失可控：可配置為極小甚至零資料損失。
- 支援本地與異地災備：架構靈活適用多種拓撲。
認清限制與權衡
日誌傳送非全自動故障轉移（不像 HACMP/Veritas Cluster），切換仍需人工或腳本觸發；切換耗時取決於日誌重播速度與檔案大小。切換後用戶端連線需重導向新伺服器（修改連線字串或漂移 IP）。這是一個成本與可用性、複雜度的權衡：適合能容忍極少量資料遺失、追求高性價比的場景。
操作關鍵：何時重新初始化備用庫？
- 索引重建：主庫重建索引時產生的日誌記錄，備用庫重播時不會自動重建索引。故障切換後首次連線或首次存取索引時才會觸發重建，造成效能抖動。預防：從主庫備份映像重新填充備用庫，或使用 I/O 暫停與分離鏡像技術刷新。
- LOAD 工具操作：LOAD 可選擇建立表空間備份映像或延後備份。若選擇建立映像，備用機必須能存取目標裝置；否則表空間進入「恢復暫掛」狀態。建議 LOAD 完成後立即刷新備用庫，確保故障時所有資料可用。
先決條件清單
- 主備雙邊運行相同版本 DB2（修訂包可不同，但 OS 層級也須一致）。
- 備用機磁碟空間 ≥ 主機，預留主機長期離線空間。
- 備用機配置主機同樣的自動化維護程序；若已有其他資料庫，需獨立 DB2 實例（單實例僅支援一個用戶出口程式）。
- 備用機日誌歸檔目標可存取，故障轉移後需保留日誌以便主庫回復。
- 備用機已還原完整資料庫備份，並具備該備份後產生的所有日誌檔。
兩種傳送模式
- Pull（拉取）模式：備用機從共享歸檔目標（如 NFS、共享磁碟）定期拉取日誌。
- Push（推送）模式：主庫歸檔時直接將日誌推送至備用機本地路徑。
兩者核心均依賴用戶出口程式（db2uext2）。DB2 實例目錄 sqllib/samples/c 提供磁碟、磁帶、TSM 等範例程式碼。
備用端必要作業：定時 Rollforward
備用機需排程執行 db2 rollforward db <DBNAME> to end of logs。執行頻率決定故障切換後的可用速度；也可刻意延後數小時作為邏輯錯誤防護（如應用程式誤刪資料，可切換至較早時間點的備用庫「時光倒流」）。
