為何 IMPORT 比 LOAD 慢？ IMPORT 逐筆執行 INSERT、驗證所有約束、觸發觸發器、記錄完整日誌，適合小批量、需觸發業務邏輯場景。LOAD

災難場景模擬 假設資料庫 SAMPLE 遭受儲存故障/人為誤刪，需從 TSM 備份還原至最近一致性時間點。 標準恢復流程 (4 步驟) 步驟 1：移除損壞資

前置條件確認 確已完成：LOGRETAIN=ON, USEREXIT=ON, TRACKMOD=ON 並完成初始線上完整備份。 兩種增量備份模式對照 模式指

線上備份前提：啟用前滾恢復模式 線上備份要求資料庫處於 Roll-Forward Recovery 模式，需設定三項關鍵配置參數 (每個分區皆需設定)： db2

離線備份前提條件 資料庫處於非啟用前滾恢復模式 (logretain=off, userexit=off) 無作用中連線 (需強制斷開) 備份媒體就緒 (本地

錯誤現象 執行 db2 connect to <db_name> 失敗，回傳： SQL0332N There is no available con

高可用性 (HA) 核心定義 HA (High Availability)： 確保依賴性應用在需要資料時能取得資料，目標是消除或最小化停機時間。 區別於 DR

問題現象 變更 DB2 伺服器主機名後，實例無法啟動，報錯 SQL6031N (Reason Code 10)。 根因：db2nodes.cfg 主機名不一致

錯誤現象與環境 錯誤代碼： SQL2009N 適用平台： Linux Kernel 2.4 (RHEL 3, SLES 8 等) DB2 版本： 7.x, 8.

前言：打破錯誤認知，回歸效能本質 DB2 效能調優領域流傳許多「經驗法則」，部分源自早期版本限制，部分則是過度簡化。本文梳理 20 大常見迷思，對照實際機制給出

DB2 Database Partitioning (DPF) 架構概覽 DB2 資料庫分區功能 (Database Partitioning Feature,

鎖等待：DB2 開發與運維的常見痛點 DB2 擁有豐富的鎖模式 (S, IS, NS, X, IX, SIX, NX, U, Z...) 雖保障資料一致性，但也

並行處理不只加速查詢，更能提升索引效能 提到資料庫並行處理，多數人聯想到的是利用多核心 CPU 加速單一查詢。但 IBM DB2 UDB for iSeries

為何需要驗證 DB2 備份？ 對於 DB2 資料庫管理員而言，成功的備份是災難恢復的基石。然而，單純執行備份指令並不代表備份檔案完好無損。為了確保在緊急情況下能

1. 建立結果表（僅結構） CREATE TABLE new_table AS (SELECT * FROM src_table) DEFINITION ONL

前 10 條核心指令速查 查看本地節點目錄：db2 list node directory 編目 TCP/IP 節點：db2 catalog tcpip no

背景 DB2 8.2 版起支援為每個 Session 獨立指定鎖定等待策略，不再僅能透過資料庫層級參數 LOCKTIMEOUT 統一控制。 四種等待模式 N

資料移動的三大操作 Import（導入）：將外部檔案資料存入資料表。 Export（導出）：將資料表資料存成外部檔案。 Load（裝入）：高效率將外部檔案資料

建立 DB2 實例（ESE 版） db2icrt -s ESE -u db2admin,aaa123456 -h ANWENHAO DBINSTANCENAME

驗證工具：db2ckbkp DB2 提供 db2ckbkp 工具快速驗證備份映像檔的可用性。注意：此命令僅能驗證磁碟上的備份，無法驗證磁帶備份。 實際操作範例