簡介
我們花了大量時間同客戶和用戶組談關於 DB2 Universal Database for Linux、UNIX® 和 Windows® (DB2) 中最新、最重要特性的承諾。但事實總是：當我們在講一個話題時，如果問聽眾他們是否熟悉一項新的關鍵特性，即使這項特性已經存在有一段時間了，大多數人還是沒有聽說過這項特性。在本文中，我們將帶您經歷一次 BACKUP 實用程序之旅，並展示該實用程序在 DB2 中的工作原理。我們將談到它的內部組成，以及已經增加了有一段時間的一些新特性，這些新特性使它的速度更快，功能更豐富。
為什麼要備份？
對於為什麼應該定時進行備份（並測試這些備份的可恢復性），有很多的原因。備份中的數據對您雖然沒什麼用，但它卻是您企業的救命稻草，所以把備份數據當作您的工作吧。
以下情況都需要備份：為了在出現應用程序錯誤時進行恢復，為了復制數據庫（例如，填充開發或測試系統），為了將數據庫轉移到新的硬件上，為了遷移到一個新的級別，為了確保軟件更新保護前後的可恢復性，為了建立某種災難恢復（DR）或高可用性（HA）拓撲結構，等等。
有趣的是，如今人們做備份的最大原因是確保能夠在出現應用程序錯誤時進行恢復。可以說，如今的硬件（H/W）已經相當安全了。例如，雙電源、RAID、雙控制器等等都非常接近標准，如果一切設置無誤的話（顯然有例外），遭受 H/W 停機事故的幾率很小。但如何才能避免人為的錯誤呢？
為什麼是 DB2 備份而不是文件系統備份？
很多新的數據庫管理員（DBA）都會問這個問題。主要原因是，DB2 在努力保持熱緩存（實際上是在內存中應用程序所需的數據）方面非常主動。隨著 64-位模型的壯大，這會成為一種趨勢，並且這種趨勢不會減緩（也不應該減緩，因為能夠放在處理器的 L1、L2 或 L3 緩存或隨機存儲器中的數據越多，工作負載就運行得越快。實際上，您需要積極主動的數據緩存，因為它使數據盡可能遠離磁盤，從而避免高代價的 I/O 周期。
當 DB2 在運行的時候，如果要拷貝一個文件系統上的文件，那麼肯定會導致數據的不一致，DB2 不能保證可以恢復數據。例如，如果數據庫在運行，那麼執行文件系統復制操作時將得不到即時點（point in time,PIT）上數據庫的快照。您應該堅持使用 DB2 備份來確保數據的一致性 —— 否則，如果不終止整個 DB2 實例的話，就無法確保數據的一致性。
而且，有了基於 DB2 的備份，就可以利用 DB2 的在線能力，它允許在備份過程中執行 DDL 和 DML，這樣業務操作就可以像往常一樣繼續。由於可以在表空間級進行備份，所以還可以進行粒度控制。這樣可以將那些關鍵的表分離出來進行備份，而留下其他那些不需要備份或者不需要經常備份的表。
DB2 備份還有助於可恢復性。您可以通過日志前滾到所選擇的某個 PIT 上。換句話說，您可以細粒度地控制系統在“起死回生”時的樣子，而不是像使用文件系統的方法那樣只是得到一個靜態的快照（這種快照很可能是不一致的）。
DB2 還支持“子集（subset）”恢復。例如，如果備份 5 個表空間，那麼可以選擇只恢復其介質出現故障的那個表空間。而在文件系統備份中，要麼是全部恢復，要麼一個也不恢復。
關於 DB2 備份
DB2 備份實用程序通常被集成在 DB2 引擎中，它不是一個附帶的實用程序。我們曾經提到，DB2 備份實用程序具有粒度控制能力。備份鏡像（backup image）可以是以下任何組合：
數據庫或一系列的表空間。
離線或在線。
完全（full）、增量（incremental）或差異（delta）。
備份實用程序有很多“調節器（knob）”，這些調節器可用於對備份進行調優（從 DB2 V8.2 開始，調優將自動完成 —— 後面有更詳細的討論）。例如，可以設置的一些參數包括：如何使用進程讀或寫數據庫，用於寫到目標介質的緩沖區的數目和大小，等等。
DB2 中的備份實用程序對數據頁進行物理上的復制。這種備份不是文件系統的備份，而是邏輯上的備份。DB2 備份鏡像包括數據以外的附加信息，例如元數據、數據庫配置、歷史文件、表空間定義，等等。
當備份一個系統時，DB2 將數據從磁盤讀入到它的輸入/輸出（I/O）緩沖區，並將這些數據從緩沖區寫到目標設備或第三方存儲管理軟件（例如 IBM Tivoli Storage Manager）。從 DB2 V8.2 開始，對於在線備份，日志文件是備份鏡像的一部分（顯然，離線備份不需要日志文件就可以進行恢復）。值得注意的是，臨時表空間和空閒 DMS 盤區（extent）不是備份鏡像的一部分。DB2 備份實用程序還具有壓縮功能（從 DB2 V8.1.4 開始）和 throttling 功能（從 DB2 V8.2 開始）。我們將在本文的後面討論這些功能。
DB2 有一個非常高效的備份實用程序，它可以將從數據庫讀出的數據頁分成多個部分，並以隨機的順序將它們寫到目標設備。換句話說，數據頁完全不是按照它們在存檔介質上的表關聯順序存放的。DB2 這樣做是為了優化備份實用程序的性能（我們假設備份要多於恢復）。DB2 備份實用程序還支持原始設備。
DB2 中提供了三種不同的備份方式：
完全備份使您得到完整的備份（有時候也稱 0 級備份）。
增量備份捕捉自上一次完全備份以來的所有變化（有時候也稱 1 級備份）。
最後，差異備份捕捉自上一次任何類型的備份以來的一切變化（有時也稱 2 級備份）。
只要正確地配置數據庫使之提供相關的支持，就可以在數據庫或者表的級別上進行這些類型的備份，還可以在線或離線進行備份。
備份進程模型
這裡有必要討論一下 DB2 備份進程模型。如果知道 DB2 生成的進程在做些什麼，則有助於理解系統的性能。 圖 1 解釋了 DB2 中的備份進程。
圖 1. 備份進程模型
從左邊可以看到 DB2 表空間和它們相關的容器。當調用備份實用程序時，DB2 將生成 db2agent 進程，以便控制緩沖區操縱者（ db2bm 進程用於將數據從磁盤讀到共享內存）與 db2med 進程（從共享內存讀數據並將數據頁寫出到目標設備）之間的流。
這些進程的運行速度沒有限制，但是，您可以根據自身環境的工作負載通過 DB2 的 throttling 功能控制它們的速度。為了為這個實用程序設計盡可能快的架構，在對緩沖區操縱者編寫代碼時，已經使它不必將數據發給特定的控制器。這就像是一場“賽跑” —— DB2 不關心數據頁在備份介質上的存放順序，只關心數據頁到達備份介質的速度有多快。
然而數據頁之間還是有一定的關聯：每個表空間將被指定給一個單獨負責處理該表空間中所有數據的進程。緩沖區操縱者的數量由調用備份實用程序時的 parallelism 選項控制。例如，如果將此選項設置為 2，那麼將會有兩個 db2bm 進程，每個進程並行地讀取兩個不同的表空間。
生成的 db2med 進程數等於目標數。例如，對於 Tivoli Storage Manager，如果想要打開三個會話，DB2 就會建立三個到 Tivoli 服務器的流。這將幫助 DB2 產生到存檔介質的並行性。
如果要備份數據到一個文件系統，並且這個文件系統是多個磁盤的一個虛擬系統，那麼應該多次指定掛載點（mount point）。例如，在 Windows 環境下的 DB2 中，您將輸入以下命令：
清單 1. 當文件系統是多個磁盤的一個虛擬系統時，備份數據到這個文件系統
backup database sample to c: c: c:
在這個例子中，DB2 將生成 3 個到存檔介質的 db2med 進程，然後並行地將數據頁從 db2bm 進程寫到這三個進程。
增量備份
增量備份首先在 V7.2 版中找到立身之處。由於它是被首先引入的，我們已見證了這種類型的備份受歡迎程度的日益增加 —— 尤其是在只有很小一部分數據會變化的數據倉庫中。
增量備份允許只備份自上一次備份以來發生變化的索引和數據頁。不過有一個例外，對於“髒（dirty）”表空間中的 long 型字段和大型對象數據，總是需要進行備份。對於這一類的數據沒有增量支持，因為這些數據類型具有不同於索引和數據頁的物理格式，目前 DB2 在備份時不確定這樣的數據是否有變化。在以後版本的 DB2 中這個例外就不復存在。
圖 2 展示了 DB2 中提供的不同類型的部分備份方式：
圖 2. 增量備份和差異備份
從這個圖中可以看到，增量備份實際上是以上一次的完全備份為基礎。由於完全備份是在星期天進行的（在我們的例子中是如此），這意味著在星期二進行的增量備份將包括星期一和星期二的所有變化。
差異備份以上一次的增量備份或差異備份為基礎。對於差異備份，需要維護自上次完全備份以來采取的所有備份，以便能夠重構數據。例如，為了將數據恢復到星期三工作結束時，需要星期一、星期二和星期三的差異備份鏡像（或星期三的日志文件）。如果在星期二做了增量備份，那麼只需要星期二的增量備份鏡像以及星期三的差異備份鏡像（或日志文件）即可。
除了發生變化的數據頁之外，增量備份還包括數據庫的元數據（數據庫配置、歷史文件、表空間定義等），以便在恢復時起到輔助作用。元數據不是增量復制的，而是每次都一一完全復制。
默認情況下，DB2 數據庫沒有被配置為支持增量備份，因為為了使 DB2 能執行這類備份，會對運行時性能產生一個非常小的影響。要啟用這種備份，可以將 TRACKMOD 數據庫配置參數設置為 ON （對這個參數的更改要到下一次數據庫活動時才生效）。
如果啟用了 TRACKMOD，則第一個寫操作將把數據的主機表空間標記為“髒（dirty）”。如果這個表空間不是髒的，那麼在備份開始的時候，DB2 完全不會理會它。如果看到一個表空間中有一個髒位（dirty bit），它將繼續檢查作了標記的表空間中的盤區（這些表空間也用髒位作了標記），最終 DB2 只將發生了變化的數據頁放入到備份鏡像中。用於支持增量備份的跟蹤特性完全是內部的，不需要考慮任何存儲方面的因素。
在采取非增量備份之前，增量備份是不允許的，非增量備份為增量備份奠定了基礎，以便後者可以恢復 —— 這是為了支持總需要非增量基礎鏡像的增量存儲。
在線備份
DB2 可以執行在線備份或離線備份。在對數據庫進行常規的 SELECT、INSERT、DELETE 和 UPDATE 活動的同時可以執行在線備份。在 DB2 中運行在線備份的惟一約束是：當一個表空間正在被備份的時候，不能刪除這個表空間。
對於離線備份，DB2 知道應用程序只是從數據庫中讀取數據，因此無需擔心鎖的問題。而對於在線備份，事情就有所不同。DB2 必須為在線備份實現一個鎖策略。對於大型對象和 long 字段數據，DB2 將 Intent None (IN) 鎖升級為 Share (S) 鎖，因而要慢大約 10%。
在線備份很可能需要從 UTIL_HEAP 內存分配中得到更多的內存，以便為一些幫助支持這種操作的內部結構分配內存。
數據庫歷史文件
數據庫歷史文件正成為數據庫引擎中越來越關鍵的部分。數據庫歷史文件是對管理操作的一種記錄。任何類型的備份鏡像都在各自存儲數據庫歷史文件（它是我們前面詳細提到的元數據的一部分）。在歷史文件中的事件記錄包括諸如備份、恢復、日志前滾、裝載、數據庫或表空間的 queiscing、表空間的修改以及被刪除的表（當被刪除的表的恢復被支持時）。與記錄的操作有關的信息包括：受影響的對象（數據庫、表空間或表）、位置和設備類型（備份鏡像或裝載復制）、相關日志文件的范圍、操作的起始和完成時間，以及產生的 SQLCA 代碼等。以前，數據庫歷史文件是一種信息文件，您可以對其進行查詢。現在 DB2 使用該文件來支持可恢復性，例如自動恢復。新的日志管理器也使用這種文件。
這種信息被放在一個文件中，而不是放在 DB2 表中，因為需要這種信息來執行恢復操作。如果數據庫不可用，那麼就不能利用它來進行數據庫恢復。因此，數據庫歷史數據存儲在一個 ASCII 文件中，並放在備份鏡像中，我們可以從中檢索和處理它。
第三方備份供應商支持
備份期間 DB2 用於寫出數據的介質進程（media process）是構建在一套公布的接口之上的，從 1993 年開始這些接口就已經向開發市場提供。這導致對當今大多數主流備份供應商的廣泛 DB2 支持，包括 IBM Tivoli Storage Manager (TSM)、Veritas NetBackup、Legato NetWorker、Compuer Associates 等等。
任何供應商可以使用這些接口來將他們的存檔解決方案集成到 DB2 中，如 圖 3 所示：
圖 3. DB2 備份接口
在將備份信息“插入”到供應商的存檔軟件中時，DB2 不是將備份信息寫入到文件中，而是將備份數據寫入這些接口，然後以位流的形式直接將它們發送到目標介質進程服務器。
例如，如果使用 TSM，那麼 DB2 將裝載 TSM API 等。這些庫被直接裝載到 DB2 內核中，並在我們的地址空間中運行。您無需擔心供應商插入式代碼（從 DB2 V7+FP11 開始）的質量，因為 DB2 將保護實例地址，使其不受第三方代碼失效的影響。實際上，在執行每個操作之前，DB2 都將獲取以前的信號處理程序的狀態，並在事後重現設置它們。這意味著，即使供應商的代碼中斷，數據庫引擎也不會停機（但很顯然，備份操作本身將失敗）。
DB2 與 Tivoli Storage Manager 的集成已有很長的歷史。實際上，DB2 是第二個曾經支持 TSM API 的應用程序。由於 DB2 與 Tivoli（實際上它是一種 IBM 產品）悠久的集成歷史，所以我們直接免費發布對 TSM 的支持。
Tivoli Storage Manager 提示和技巧
通過設置 DB2 來使用 TSM 是件很簡單的事。
首先，您需要運行 dsmapipw 實用程序（以具有管理權限的用戶身份），以設置 TSM 密碼。該實用程序位於 sqllib\adsm 目錄中。這個實用程序對用於節點的 TSM 密碼進行加密，並將其存儲到磁盤上。在使用 TSM 和 DB2 時，人們碰到的 60% 的問題都是由於這一步執行失敗而引起的。如果沒有正確設置密碼，那麼將收到一個 137 錯誤碼。
接下來，導出特定於 DB2 TSM 的環境變量。有三個可以設置的環境變量：
DSMI_DIR 是 TSM 客戶機的安裝目錄。
DSMI_CONFIG 是設置 TSM 時所在的配置。
DSMI_LOG 指定記錄任何錯誤的文件。
當啟動實例時，所有這些設置都將被捕捉，因此，改變其中任何一個設置（以及第一次設置 DB2，使其使用 TSM 時）都必須重新啟動實例。如果更改了任何配置參數，只需重新啟動實例即可。例如，如果您更改了 TSM 配置文件中的任何特定的 TSM 設置（例如您想與某台 TSM 服務器通信），則無需重新啟動數據庫引擎。這些環境變量通常位於 DB2 實例的用戶配置文件中。
TSM 以時間戳來惟一地標識所有備份。DB2 在 TSM 服務器上並不使用期限（expiration）策略。這一點很重要，因為它意味著您的備份不會過期，因此需要制定一個計劃來處理這種情況。
在 DB2 V7 中，DB2 不會刪除備份，而是將它們標記為非活動（inactive），所以需要設置 TSM，以便保留非活動的備份（這不是默認設置）。在 DB2 V8 中，這種情況有所變化。現在，當您想要刪除一個備份時，不管 TSM 管理類的定義如何，都可以執行刪除操作。
在 DB2 V7 中，如果使用 TSM 在節點上備份一個數據庫，那麼只有執行該備份的用戶才能恢復這個數據庫。這在 DB2 V7 環境中會導致一些問題，為了恢復到另一台服務器，您必須“偽裝”成原先的節點，並且要知道它們各自的密碼。您必須在目標節點上創建一個空的數據庫，設置 TSM_NODENAME、TSM_PASSWord、TSM_OWNER 數據庫配置參數，然後在 dsm.opt 文件中更改 PASSWordAccess=PROMPT，再將 NODENAME 注釋掉。
在 DB2 V 8.2 中，通過附件的“供應商選項”支持，已經消除了這種復雜性。該特性允許將初始參數直接發送到 TSM API，其中包括生成備份鏡像時所在節點的名稱以及 DB2 實例的初始 ID。您不再需要知道節點 TSM 的初始密碼。將一個備份鏡像恢復到任何節點需要兩步：
在生成備份鏡像之後，必須使用 db2adutl 授權選項將訪問該鏡像的訪問權限授給所需的節點。例如：
db2adutl grant newuser on nodename newhost for db mydb
在新的目標節點上，必須在備份命令中使用 'options' 字段。例如：
db2 restore db mydb use tsm options 'fromnode=originalnode fromuser=originalinstance'
最後，在 DB2 V8 中，隨著 db2audtl 實用程序的引入，對於在 TSM 服務器上如何管理 DB2 備份也有所增強。之前，由於 DB2 的命名慣例，對備份的管理總是導致一定程度的復雜性。DB2 為備份文件命名，因而您不能依賴 TSM 管理類來管理它們，因為它們有惟一的名稱，並且永遠不會過期。
db2audtl 命令有 7 個選項：
DELETE：用於將備份標記為非活動（低於 DB2 version 8 的版本），刪除備份（DB2 version 8）和刪除日志。對於低於 DB2 version 8 的版本，TSM 將標記非活動 DB2 數據庫備份對象，以便基於相關管理類中的 備份復制組（backup copy group）定義執行刪除操作。在運行 TSM Expire Inventory 命令時，將從 TSM 服務器上刪除被標記要刪除的對象。為了讓 db2adutl 能夠刪除數據庫備份，必須為 TSM 將 Backdel 參數設置為 yes。為了清除保存在 TSM 服務器上的 DB2 日志，需要為節點設置 Archdel Yes 參數。這些參數可以在注冊 TSM 節點時指定，也可以通過在 TSM 服務器上執行對節點信息的更新來設置。
QUERY：列出在這個節點上創建的所有或特定的 DB2 對象。可以使用 Show inactive 子句來查看已經被標記為非活動的備份鏡像。
EXTRACT：從 TSM 對象創建磁盤鏡像。如果一個數據庫鏡像標記為非活動，那麼它就不能再被恢復，但是仍然可以從 TSM 服務器提取該數據庫鏡像，而被提取的鏡像可用於執行恢復。注意，在 DB2 version 8 中，db2adutl 用於刪除一個對象，它不只是將對象標記為非活動，而是將其設為在 TSM 服務器上立即過期。
