我們花大量時間向客戶承諾 DB2 最新關鍵特性，但詢問聽眾時，即使特性存在一段時間，大多數人仍未聽聞。本文帶您深入 BACKUP 實用程式內部，展示其工作原理、內部組成與已存在一段時間的新特性——它們讓備份更快、功能更豐富。
定時備份（並測試可恢復性）理由眾多：應用程式錯誤恢復、複製資料庫（填充開發/測試系統）、遷移新硬體、遷移新級別、確保軟體更新前後可恢復性、建立災難恢復 (DR) 或高可用性 (HA) 拓撲等。有趣的是，如今最大備份理由是確保應用程式錯誤可恢復。硬體已相當安全（雙電源、RAID、雙控制器近乎標準），若配置正確 H/W 停機概率極低。但如何避免人為錯誤？
新 DBA 常問此題。主因：DB2 極度主動保持熱緩存（應用所需數據在內存）。隨 64 位模型壯大，此趨勢不減（數據越多在 L1/L2/L3 緩存或 RAM，工作負載越快）。主動數據緩存使數據遠離磁碟，避免高昂 I/O 週期。
DB2 備份實用程式集成於 DB2 引擎，非附帶工具。備份鏡像可為任意組合：資料庫或一系列表空間、離線/在線、完全/增量/差異。有許多「調節器」可調優（V8.2 起自動調優）。參數包括：進程讀寫數據庫方式、寫目標介質緩衝區數目大小等。
備份對數據頁進行物理複製。非檔案系統備份，而是邏輯備份。鏡像含數據外附加信息：元數據、資料庫配置、歷史文件、表空間定義等。備份時 DB2 從磁碟讀入 I/O 緩衝區，寫目標設備或第三方儲存管理軟體 (如 IBM Tivoli Storage Manager)。V8.2 起在線備份日誌文件納入鏡像（離線備份恢復不需日誌）。臨時表空間與空閒 DMS 區段不在鏡像中。支援壓縮 (V8.1.4) 與節流 (V8.2)。
DB2 備份極高效：將讀出的數據頁分成多部分，以隨機順序寫目標設備。數據頁完全非按表關聯順序存放。為優化備份性能（假設備份多於恢復）。支援原始設備。
三種備份方式：
正確配置資料庫支援相關功能後，可在資料庫/表級別、在線/離線進行。
了解 DB2 生成進程做什麼有助理解系統性能。圖 1 解釋備份進程模型。
左側 DB2 表空間與容器。調用備份時，DB2 生成 db2agent 控制緩衝區操縱者 (db2bm 進程：從磁碟讀到共享內存) 與 db2med 進程（從共享內存讀並寫頁面到目標設備）間流。進程速度無限制，但可用 throttling 功能按環境負載控制。為設計最快架構，緩衝區操縱者代碼使其無需將數據發給特定控制器——像「賽跑」，DB2 不關心頁面在備份介質存放順序，只關心到達速度。但頁面間有關聯：每表空間指定單一進程處理該表空間所有數據。db2bm 數量由 parallelism 選項控制（如設 2，兩進程並行讀兩不同表空間）。db2med 數量等於目標數（如 TSM 開 3 會話，建立 3 流，產生並行性）。備份到多磁碟虛擬檔案系統時應多次指定掛載點（Windows 例：BACKUP DATABASE SAMPLE TO C: C: C: 生成 3 db2med 並行寫）。
V7.2 引入，日益普及——尤其數據倉庫僅小部分數據變化。增量備份僅備份上次備份以來變化的索引與數據頁。例外：「髒」表空間中的 LONG/LOB 數據總需備份，因物理格式不同，DB2 備份時不確定是否變化，未來版本將解決。圖 2 展示增量/差異備份關係。
增量備份以上次完全備份為基礎（例：週日完全備份，週二增量含週一週二變化）。差異備份以上次增量/差異為基礎。恢復至週三需週一週二週三差異鏡像（或週三日誌）；若週二做增量，僅需週二增量與週三差異（或日誌）。增量備份除變化頁外含資料庫元數據（配置、歷史、表空間定義）輔助恢復，元數據非增量複製而是每次完整複製。預設資料庫不支援增量備份，因啟用對運行時性能有極小影響。啟用：TRACKMOD 設 ON（下次資料庫活動生效）。啟用後首次寫操作將表空間標「髒」，備份時非髒表空間完全忽略，髒表空間檢查標記區段，最終僅變化頁面入鏡像。支援增量備份的追蹤特性完全內部，無儲存考量。非增量備份前不允許增量備份，非增量為增量奠定基礎。
DB2 可執行在線/離線備份。在線備份期間可執行常規 SELECT/INSERT/DELETE/UPDATE。唯一約束：表空間正被備份時不可刪除該表空間。離線備份 DB2 知應用僅讀數據，無鎖憂慮。在線備份需鎖策略：對大物件與 LONG 字段，DB2 將 Intent None (IN) 鎖升級為 Share (S) 鎖，慢約 10%。在線備份可能需更多 UTIL_HEAP 內存分配支援內部結構。
日益成為引擎關鍵部分。記錄管理操作。任何備份鏡像含各自歷史文件（元數據一部分）。事件記錄含備份、恢復、日誌前滾、掛載、資料庫/表空間静默、表空間修改、被刪除表（支援恢復時）。相關信息：受影響對象、位置設備類型、相關日誌範圍、操作起止時間、SQLCA 代碼。舊版為信息文件可查詢。新版 DB2 用其支援可恢復性（如自動恢復），新日誌管理器也用之。存 ASCII 文件而非 DB2 表，因恢復操作需此信息，資料庫不可用時無法利用表恢復。放備份鏡像中可檢索處理。
備份寫出介質進程建於公開接口之上（1993 年起提供開發市場），導致對主流備份供應商廣泛支援：IBM Tivoli Storage Manager (TSM)、Veritas NetBackup、Legato NetWorker、Computer Associates 等。任何供應商可用接口集成存檔方案到 DB2（圖 3）。
備份信息不寫文件，而是寫接口以位流形式直接發送目標介質進程服務器。用 TSM 時 DB2 載入 TSM API 庫直接進 DB2 核心、在其位址空間運行。無需擔心供應商插入式代碼質量（V7+FP11 起），DB2 保護實例位址不受第三方代碼失效影響。實際上每操作前獲取前信號處理器狀態、事後重現設置。即使供應商代碼中斷，資料庫引擎不會停機（備份操作本身會失敗）。
DB2 與 TSM 集成歷史悠久。DB2 是第二個支援 TSM API 的應用。因悠久歷史且均為 IBM 產品，直接免費發布 TSM 支援。
dsmapipw 設 TSM 密碼（具管理權限用戶），位於 sqllib\adsm。加密節點密碼存磁碟。60% TSM+DB2 問題源於此步驟失敗。密碼未正確設將收到 137 錯誤碼。DSMI_DIR (TSM 客戶端安裝目錄)、DSMI_CONFIG (配置位置)、DSMI_LOG (錯誤日誌文件)。啟動實例時捕獲，改變任何設置（含首次設 DB2 用 TSM）必須重啟實例。改配置參數只需重啟實例（如改 TSM 配置文件特定設置，無需重啟資料庫引擎）。通常位於 DB2 實例用戶配置文件。TSM_NODENAME/PASSWORD/OWNER、改 dsm.opt PASSWORDACCESS=PROMPT、註釋 NODENAME。V8.2 「供應商選項」支援消除複雜性：允許直接發送初始參數到 TSM API，含生成鏡像節點名與實例初始 ID。無需知節點 TSM 初始密碼。恢復到任意節點兩步：db2adutl grant newuser on nodename newhost for db mydb 授權訪問權限。options：db2 restore db mydb use tsm options 'fromnode=originalnode fromuser=originalinstance'。db2adutl 增強 TSM 上 DB2 備份管理：先前 DB2 命名慣例導致管理複雜。db2adutl 7 選項：DELETE：標非活動 (V8 以下)、刪除備份 (V8)、刪除日誌。V8 以下 TSM 標非活動對象按管理類備份複製組定義刪除。執行 TSM Expire Inventory 刪除被標對象。需設 TSM Backdel=yes 讓 db2adutl 刪除備份。清除 TSM 上 DB2 日誌需節點設 Archdel=yes（註冊節點或更新節點信息時指定）。QUERY：列出節點上所有/特定 DB2 對象。SHOW INACTIVE 顯示已標非活動鏡像。EXTRACT：從 TSM 對象創建磁碟鏡像。非活動鏡像不可恢復但可提取、提取鏡像可用於恢復。V8 中 db2adutl 刪除對象非標非活動而是立即過期。
