簡介
本文幫助現有的 MySQL 數據庫管理員轉移自己的技能，學習 DB2 Express 的備份和恢復功能。您可能已經熟悉在 MySQL 中對數據庫進行備份和恢復的方法；本文主要介紹備份和恢復策略的特性、功能和好處，以及如何在 DB2 Express 中完成備份和恢復。本文還介紹如何利用 DB2 Express 中的絕對無數據損失選項。
本文主要關注 DB2 Express 的功能，同時介紹開放源碼的 MySQL 和 DB2 Express 之間的相似性和差異。
概述
本文討論以下主題：
系統結構
備份 —— 離線
恢復 —— 離線
備份 —— 在線
恢復 —— 在線
Throttling
自動備份維護
其他實用程序
介紹
本文主要關注使用 MyISAM 和 InnoDB 存儲引擎進行備份和恢復，因為它們是 MySQL 中最常用的引擎。本文不關注 MySQL 的復制特性。
因為 MySQL 可以選擇底層的存儲引擎，比如 MyISAM、Oracle 的 InnoDB 和 Sleepycat 的 Berkeley BDB，因此備份和恢復機制隨使用的存儲引擎而變。例如，如果底層存儲引擎是 MyISAM，它提供了兩個備份和恢復實用程序：mysqldump 和 mysqlhotcopy（出於性能原因，本文主要關注 mysqlhotcopy）。MySQLhotcopy 腳本進行文件級復制（*.frm、*.MYD 和 *.MYI 文件），只適用於 MyISAM 存儲引擎。它可以在需要備份的數據庫所在的相同機器上運行。在恢復時，將數據庫目錄替換為備份目錄。
對於大型環境，mysqldump 執行起來很慢；但是，在備份重要的表時它非常有用。它將表轉儲為一種可讀的格式。盡管 MySQLdump 提供了 --single-transaction 標志用於為 InnoDB 執行在線備份（需要讀鎖；FLUSH TABLES WITH READ LOCK），還提供了用於前滾的二進制日志，但是仍然最好使用單獨付費的 InnoDB 備份和恢復工具，ibbackup（注意，這個組件在 InnoDB 存儲引擎之上工作，是一個單獨付費的組件）。
因為在本質上不具有內在的 ACID 性質，所以 MyISAM 存儲引擎的備份和恢復可以用來執行版本級恢復，但是不保證數據完整性。使用這種存儲引擎，在發生介質故障時，自上次備份以來的所有工作都會丟失。
對於具有 MyISAM 和 InnoDB 存儲引擎的混合式 MySQL 數據庫環境，進行備份的更好的方法可能是使用 innobackup。這個實用程序對 InnoDB 進行在線備份，同時建立 MyISAM 表的快照。
對於事務安全的存儲引擎，InnoDB 備份工具 ibbackup 是首選的。但是，要注意下面列出的兼容性問題：
MySQL/InnoDB 5.0 需要 InnoDB Hot Backup 3.0 或更新版本。
MySQL/InnoDB 4.1 需要 InnoDB Hot Backup 2.0 或更新版本。
MySQL/InnoDB 4.0 需要 InnoDB Hot Backup 1.40 或更新版本。
MySQL/InnoDB 3.23 需要 InnoDB Hot Backup 1.40 或更新版本。
InnoDB Hot Backup 2.0 可以用於 MySQL/InnoDB 4.1 以下的所有 MySQL/InnoDB 版本（包含 4.1），但是與 MySQL/InnoDB 5.0 或更新版本不兼容。
InnoDB Hot Backup 3.0 與從 3.23 到 5.0 的所有 MySQL/InnoDB 版本兼容。
DB2 Express-C 附帶一種內置的備份和恢復機制，所以不需要為版本不匹配或任何兼容性問題擔心。另外，如果使用 DB2 Control Center 進行備份和恢復，那麼幾乎不需要編寫任何代碼，因此這個過程很少會出錯誤。DB2 Express-C 備份和恢復非常簡單，很容易完成。
在 DB2 Express-C 中，數據庫可以以兩種模式進行備份和恢復。DB2 Express-C 與 MySQL 的備份和恢復不同，因為 DB2 Express-C 沒有即插即用的存儲引擎（這些引擎需要自己的備份和恢復機制）。例如，對 MyISAM 進行備份的方式與對 InnoDB 或 Berkeley 進行備份的方式不同。對 MyISAM 和 InnoDB 數據庫進行備份需要特殊處理，也就是需要 innobackup 那樣的 shell/perl 腳本。但是，DB2 Express-C 就簡單多了，只需用一個命令進行備份（BACKUP），用另一個命令進行恢復（RESTORE）。
在 DB2 Express-C 中，除了用戶數據之外，還可以備份以下對象：
用戶定義的函數
用戶定義的數據類型
存儲過程
觸發器
序列
表
索引
視圖
離線模式適用於非連續運行的環境，在這種環境中，數據庫常常每天或每周（取決於數據庫的重要性）進行一次整體備份。還可以將離線模式應用於只讀的數據庫。這種模式簡單易行，但這是有代價的；如果發生故障，上次備份以來的數據就會丟失（請注意這種風險！）。通常，備份的時間間隔由事務量和在發生硬件故障時能夠接受的數據損失量決定。在進行恢復之後，需要重新輸入數據。在 DB2 Express-C 中，這種模式稱為版本恢復，即以一定的時間間隔對整個數據庫（不可恢復的數據庫）進行備份，並在發生故障時進行恢復。
不需要對整個文件系統進行備份，因為 DB2 Express-C 提供了對數據庫進行離線備份和恢復的簡易方法。有一個命令用於備份，另一個命令用於恢復。
在線備份和恢復是一種內置的機制，用來確保數據庫中的數據不會丟失。典型的連續運行環境常常使用這種模式，從而確保所有數據在災難中得到保護。DB2 Express-C 提供的這種備份和恢復模式有許多選項。例如，對於實現無數據損失策略的小型環境，可以對數據庫進行整體的在線備份和恢復。換句話說，備份和恢復功能在數據庫級執行。作為一種更好、更靈活的維護選項，可以選擇在表空間級進行備份。最後（但並非是最次要的），對於大型環境（尤其是對於 DB2 Workgroup 和 Enterprise 版本）可以在在線全數據庫備份的基礎上執行 delta 和增量備份。
同樣，別以為備份文件系統就可以備份數據庫。DB2 Express-C 提供了內部機制來確保數據完整性和同步。如果在文件系統級進行備份，就可能使數據庫完全失效。您不應該這麼做，因為 DB2 Express-C 為備份和恢復、在線備份和在線恢復分別提供了簡單的命令。
如果沒有提到 DB2 Express-C 中的自動備份和恢復維護特性，本文就是不完整的。這個特性使 DBA 可以高枕無憂，因為數據庫備份和恢復可以完全自動地進行。
最後，DB2 Express-C 的備份機制附帶一個 throttling 特性（尤其適用於 Workgroup and Enterprise 版本），它在生產負載低的時間段占用更多的 CPU 時間，在生產負載高的時間段占用更少的 CPU 時間。Throttling 特性使服務器不會由於數據庫備份這樣的資源密集型活動而變慢。利用這個特性，備份活動就可以在生產負載高的時間段執行。
現在，我們來詳細討論每個方面。
系統結構
為了理解 DB2 Express-C 提供的備份和恢復機制，最好先了解它的體系結構。例如，日志緩沖區將每個事務寫到日志，可以使用不同的日志模式來實現不同的備份和恢復模式。
內存結構
下圖給出 DB2 Express-C 內存結構的簡化版本。關於更完整、更詳細的內存結構，請參考 developerWorks 中的 內存模型。注意，日志緩沖區位於數據庫的共享內存中，這種機制確保每個事務被記錄到日志文件中。
圖 1. DB2 Express-C 內存結構
下面列出這些組件的功能：
包緩存（package cache）—— 分配這裡的內存來存儲靜態和動態 SQL 語句。
緩沖區池（buffer pool）—— 在將數據刷新到磁盤之前，分配這裡的內存來存儲數據。
日志緩沖區（log buffer）—— 在刷新到磁盤上的日志文件之前，使用這裡的內存存儲對數據庫的所有修改。
目錄布局
在默認安裝的情況下，DB2 Express-C 具有以下表空間：
Syscatspace —— 存儲系統編目信息。
Tempspace1 —— 存儲系統臨時表。臨時表空間可以是系統的，也可以是用戶的。最好從系統臨時表空間創建用戶臨時表空間。
Userspace1 —— 存儲用戶數據。
但是，表空間代表數據庫容器的邏輯方面，而物理布局決定實際數據存儲在文件系統中的什麼地方。
物理文件系統的布局如下圖所示：
圖 2. DB2 UDB Express 容器布局 
驅動器/目錄 —— CREATE DATABASE 命令中指定的驅動器或目錄
DB2 實例名 —— DB2 實例所有者的名稱
NODE0000 —— 數據庫的分區號（0 代表無分區數據庫）
SQL00001 —— 從 1 開始的數據庫 ID
SQLOGDIR —— 數據庫的默認日志目錄
SQLT0000.0 —— 編目表空間，SYSCATSPACE
SQLT0001.0 —— 臨時表空間，TEMPSPACE1
SQLT0002.0 —— 用戶表空間，USERSPACE1
比較重要的問題是，在 DB2 Express-C 8.2 之前的版本中，事件日志需要發送到離站位置，DBA 必須知道需要發送哪些存檔日志以及這些日志的位置。由於在備份命令中引入了 include logs 選項，日志也包含在備份映像中。這使日志管理更容易了。對於前滾恢復，不需要知道實際日志的位置，因為前滾命令會自動找到它們。
日志機制
DB2 Express-C 提供兩種日志模式，循環和存檔日志模式。在循環日志模式中，事務以循環方式寫到日志中。循環日志只能支持版本恢復。換句話說，無法前滾到上次全數據庫備份以來的任意時間點或日志的末尾。這種模式只適用於只需恢復上次全數據庫備份的場合。當然，其影響就是上次備份之後的所有事務都會丟失。如下圖所示，由於日志采用循環方式，所以日志會被重寫。活躍日志防止在崩潰恢復（比如電源故障）期間的數據損失。輔助日志用於長期運行的事務；指定 -1 表示允許無限的輔助日志。
圖 3. 打開輔助日志的循環日志
存檔日志模式支持在線備份和恢復。利用在線備份，就可以將日志前滾到任何特定的時間點或日志的末尾。這是配置存檔日志模式的最大優點。崩潰恢復需要活躍日志，存檔日志是活躍的，但崩潰恢復不再需要這種日志。但是，在日志重放期間需要存檔日志。只有在這些日志之間沒有 “中斷” 的情況下，才可能前滾到任何特定的時間點或日志的末尾。換句話說，要想確保絕對沒有數據損失，需要原樣保存上次在線備份以來的日志。在默認情況下，在完成在線備份之後，DB2 會將當前活躍的日志關閉，從而確保可以使用完整的存檔集來進行前滾。從 DB2 Express-C Version 8.2 開始，可以在備份命令中使用 include logs 選項，從而將日志包含在備份映像中。用戶退出時也會發送日志，這只是為了提供向後兼容性。
圖 4. DB2 存檔日志
可以在 DB2 Control Center 或命令提示 CLP 中控制和設置 DB2 Express-C 日志參數。對於 Control Center，只需選擇一個數據庫並右擊，再選擇 configure parameters。
圖 5. DB2 Express-C 日志參數
要想在命令 CLP 中看到參數，應該發出命令 get db cfg for <your_db_name>。要更新參數，應該發出命令 update db cfg using <parameter_name> <value>。例如，要將 logretain 設置為 ON，應該發出命令 update db cfg using logretain on。一些參數設置只有在斷開所有應用程序與數據庫的連接之後才會生效。最後，如果需要恢復系統默認設置，那麼應該發出命令 reset db cfg for <your_db_name>。
圖 6. 在 CLP 中顯示的 DB2 Express-C 日志參數
圖片看不清楚？請點擊這裡查看原圖（大圖）。
下面討論在 DB2 Express-C 中使用的一些重要的日志參數。正如前面提到的，需要回顧一些概念才能更好地理解配置參數。
活躍日志是崩潰恢復需要的日志。
存檔日志是活躍的，前滾恢復需要存檔日志，但是崩潰恢復不再需要它們。
logarchmeth1/logarchmeth2（默認值是 OFF）—— 它們首先決定使用哪種日志機制，然後決定存儲存檔日志的位置。它們使存檔日志文件寫到活躍日志路徑（默認為 SQLOGDIR）之外的位置。這些參數的默認值是 OFF，這表示使用循環日志模式。下面是可以為這兩個參數設置的 5 個值：
OFF —— 默認設置，表示使用循環日志模式。采用這個設置時，只能進行版本恢復，沒有前滾功能。
LOGRETAIN —— 設置 LOGRETAIN 值會自動地將參數 LOGRETAIN 的值改為 RECOVERY，這表示使用存檔日志模式。這個值允許在數據庫恢復期間進行前滾。這個值只對 logarchmeth1 是有效的。
USEREXIT —— 調用一個用戶退出程序來進行日志的存檔和獲取。設置這個選項將把配置參數 USEREXIT 自動地更新為 ON。這個值只對 logarchmeth1 是有效的。
DISK —— 指定存儲存檔日志的位置（物理文件系統）。這個選項也允許使用磁帶存儲存檔日志。
TSM —— 使用 Tivoli® Storage Manager 來維護存檔日志。要使用這個選項，需要指定 TSM 管理類名。例如，要使用 CMDISK 作為管理類，應該發出命令 update db cfg for <your_db_name> using logarchmeth1 TSM:CMDISK。配置參數 TSM_MGMTCLASS 不會自動更新。
VENDOR —— 這個選項指定要使用廠商的備份和恢復 API。
logbufsz（默認值是 8 x 4K）—— 表示作為日志緩沖區的內存大小。
logfilsiz（默認值是 4096 x 4K）—— 指定日志文件的統一大小。對整個活躍日志空間的邏輯限制是 256GB。
logprimary（默認值是 3）—— 指定使用的主日志的總數。每個日志的統一大小由參數 logfilsz 指定。選擇要創建的主日志的總數和大小時，需要在可用磁盤空間和應用程序的功能之間進行折中，以便適應日志的所有情況。無論日志被填充了 10% 還是 90%，創建的每個日志都需要相同的磁盤空間。對於長期運行的事務，常常需要創建容量更大的主日志。在當前的 DB2 Express-C 版本中，整個活躍日志空間大小的上限是 256GB。
logsecond（默認值是 2）—— 指定在主日志文件被填滿時創建的日志文件總數。這些日志文件只在主日志文件被填滿之後創建。默認值 2 意味著只創建 2 個日志文件。但是，可以指定 -1，這允許無限的活躍日志空間。
logretain（默認值是 OFF）—— 表示使用循環日志還是存檔日志。這個值通常使用 logarchmeth1 配置參數進行設置。
userexit（默認值是 OFF）—— 表示使用用戶退出程序。不建議使用這個選項，因為它主要用於提供向後兼容性。這個值也可以使用 logarchmeth1 配置參數進行設置。
mirrorlogpath（默認值是 NULL）—— 這個配置參數允許通過在指定的路徑中保存相同的副本來保護日志。這可以防止介質故障或意外刪除日志造成日志 “中斷”。
但是有兩件事需要注意：當打開 logarchmeth1 以支持前滾恢復時，當前活躍日志不會復制到 mirrorlogpath 中指定的路徑；需要記住這個路徑，以防主日志位置中出現日志損失。
newlogpath —— 這個路徑的默認設置隨數據庫 ID（創建的第一個數據庫的 ID 是 1）和節點號（適用於 Workgroup and Enterprise 版本）而變。對於創建了第一個數據庫的一個節點設置，這個路徑是 C:\DB2\NODE0000\SQL00001\SQLOGDIR（參見上面 “目錄布局” 一節中對布局的解釋）。如果對默認路徑不滿意，那麼可以使用這個配置參數修改它，活躍日志和存檔日志就可以寫到這個新位置。
overflowlogpath（默認值是 NULL）—— 表示在前滾恢復期間使用的日志路徑。注意，可以在恢復命令中使用 OVERFLOW LOG PATH 選項，這個選項的優先級比這個配置參數高。
num_log_span（默認值是 0）—— 指定在一個工作單元中可以跨越的活躍日志總數。0 表示無限制跨越。
failarchpath（默認值是 NULL）—— 當實際存檔路徑不可用時使用的路徑。只有在嘗試過 numarchretry 中指定的次數（默認值是 5）之後，才會使用這個路徑。可以使用參數 archretrydelay 指定在這些嘗試之間等待的時間間隔（秒數，默認值是 20 秒）。換句話說，在使用默認值時，需要等待 (5 x 20) 秒，然後存檔日志才會寫到 failarchpath 中指定的路徑。
下表對比了這兩種數據庫中的特性以及控制它們的參數。對於使用 MySQLhotcopy 的 MyISAM 存儲引擎，大多數日志特性是不可用的。
表 1. MySQL 和 IBM DB2 Express-C 的日志選項和參數對比 日志功能 在 MySQL - InnoDB 中的可用性 在 DB2 Express-C 中的可用性 DB2 Express-C 參數 注釋 循環日志 √ √ logarchmeth1 InnoDB 的日志是以循環方式寫入的。 存檔日志 × √ logarchmeth1 打開二進制日志 log-bin 就可以在 InnoDB 中恢復到特定的時間點。在進行時間點恢復時，將 mysqlbinlog 的輸出重定向到 MySQL。不使用參數 innodb_log_arch_dir 和 innodb_log_archive。 分配給日志緩沖區的內存 √ √ logbufsz 使用 InnoDB 的參數 innodb_log_buffer_size。 日志文件大小 √ √ logfilsiz 使用 InnoDB 的參數 innodb_log_file_size。在 DB2 Express-C 中，這個值在所有日志文件上是統一的。 創建的主日志總數 √ √ logprimary 在 InnoDB 中，備份目錄中只有一個日志文件 ibbackup_logfile，其中包含前滾信息。要進行前滾，應該使用選項 --apply-log。 創建的輔助日志總數 × √ logsecond 在 InnoDB 中，沒有用來處理長期運行的事務的輔助日志概念。日志將以循環方式寫到 innodb_log_group_home_dir 指定的目錄中。 日志發送 √ √ userexit 對於使用 ibbackup 的 InnoDB 備份，將生成日志文件 ibbackup_logfile，可以通過標志 --apply-log 使用這個文件進行前滾。從 DB2 Express-C Version 8.2 開始，日志可以包含在備份映像中。參數 userexit 僅僅用於提供向後兼容性。 日志鏡像 √ √ mirrorlogpath InnoDB 的鏡像日志由 innodb_mirrored_log_groups 指定。 修改默認的日志路徑 √ √ newlogpath InnoDB 日志文件和數據文件將寫到 innodb_log_group_home_dir 指定的路徑中。 溢出日志路徑 × √ overflowlogpath 活躍日志跨越 √ √ num_log_span InnoDB 日志文件 innodb_log_files_in_group 可以用來處理長期運行的事務。 設置活躍日志空間中允許使用的空間百分比 × √ max_log 在 DB2 Express-C 中，max_log 指定可以使用的主日志空間的百分比。這個參數確保單一事務不會耗盡所有活躍日志空間。 控制將日志緩沖區寫到磁盤中的頻率 √ √ mincommit InnoDB 日志的刷新由 innodb_flush_log_at_trx_commit 控制。在 DB2 Express-C 中，mincommit 確保只在一定的時間間隔之後將日志緩沖區寫到磁盤中。 故障轉移存檔路徑 × √ failarchpath 在 DB2 Express-C 中，archretrydelay 和 numarchrety 與 failarchpath 結合使用。 防止磁盤滿錯誤 × √ blk_log_dsk_ful 在 DB2 Express-C 中，這個參數向用戶通知磁盤滿錯誤（使用一個管理日志），並每 5 分鐘創建一個新日志，直到解決磁盤空間滿問題。但是，DB2 在磁盤填充到 80% 或 90% 時沒有提供警告措施。所有 DB2 都會阻止事務，直到有更多的空間可用。 用磁帶進行日志管理 × √ logarchmeth1/logarchmeth2 在 DB2 Express-C 中，這是通過參數 logarchmeth1 或 logarchmeth2 支持的開箱即用特性。另外，可以使用內置命令 db2tapemgr 進行日志文件的存儲/獲取管理。 與 TSM、Veritas 等第三方解決方案進行集成 × √ logarchmeth1/logarchmeth2 在 DB2 Express-C 中，這是通過參數 logarchmeth1 或 logarchmeth2 支持的開箱即用特性。Tivoli Storage Manager（TSM）本機集成到 DB2 Express-C 中。對於其他廠商，可以通過在這些參數中指定選項來使用他們的備份和恢復 API。
備份 —— 離線
離線備份方法支持進行版本恢復。這種方法用於沒有存檔日志可用的不可恢復數據庫。采用這種方法時，使用循環日志模式，可以以循環方式重寫日志。在數據庫恢復操作期間，使用以前的備份映像恢復整個數據庫（不是部分數據庫）。這會將數據庫恢復到創建這個映像的時間點。創建上一個備份映像以來的事務都會丟失。
關於離線備份有幾點應該記住：
只能進行版本恢復。上次備份以來的所有工作都會丟失。
這是默認的備份模式，由 logarchmeth1 設置為 OFF 來表示。
由 logsec 表示允許長期運行的事務。
在發出備份命令時，不允許有連接。
執行離線備份需要特殊的授權 —— sysadm、sysctrl 和 sysmaint。
備份在數據庫級進行。不能進行表級或表空間級備份。
有完整的備份歷史列表。
不能進行增量或 delta 備份。
簡單、容易而且靈活。
可以使用命令 CLP 或 Control Center 進行離線備份。我們將分別看看這兩種方式。
使用命令 CLP 進行離線備份
使用命令 CLP 進行離線備份是很簡單的。首先發出命令 db2 force applications all 或 quIEsce，確保所有應用程序斷開連接。下面給出備份命令。
清單 1. 使用命令 CLP 進行離線備份 db2 backup db <your_db_name> to <your_backup_path>
這樣就可以了，但是如下面的完整語法所示，也可以用許多選項控制備份過程。在一般情況下，只需要使用簡單的備份命令。
清單 2. DB2 Express-C 備份語法 BACKUP DATABASE database-alias [USER username [USING passWord]]
[TABLESPACE (tblspace-name [ {,tblspace-name} ... ])] [ONLINE]
[INCREMENTAL [DELTA]] [USE {TSM | XBSA} [OPEN num-sess SESSIONS]
[OPTIONS {options-string | options-filename}] | TO dir/dev
[ {,dir/dev} ... ] | LOAD lib-name [OPEN num-sess SESSIONS]
[OPTIONS {options-string | options-filename}]]
[WITH num-buff BUFFERS] [BUFFER buffer-size] [PARALLELISM n]
[COMPRESS [COMPRLIB lib-name [EXCLUDE]] [COMPROPTS options-string]]
[UTIL_IMPACT_PRIORITY [priority]] [{INCLUDE | EXCLUDE} LOGS] [WITHOUT PROMPTING]
使用 DB2 Control Center 進行離線備份
使用 DB2 Control Center 進行數據庫離線備份是另一種備份方法，這種方法不需要發出任何命令。DB2 Control Center 是一個用於管理的 GUI。它主要基於向導，可以引導用戶完成管理任務。它提供的一個選項可以在每個向導結束時顯示底層的命令。為進行離線數據庫備份，需要執行以下步驟。
打開 DB2 Control Center。
選擇要備份的數據庫（例如，ABX84）並右擊選擇 Backup 選項。
圖 7. 使用 Control Center 進行離線備份 —— 右擊選擇 Backup 選項
在第一個屏幕上，可以獲得以下信息。點擊 Next 繼續。
要備份的數據庫。
數據庫狀態，可用或不可用。
這個數據庫上次備份的時間戳。
自動備份維護。在默認情況下，這是禁用的。本文後面的一節將討論這個問題。
日志類型，循環或存檔。
在線備份。對於離線備份，這個選項總是 NO。
表空間級備份。對於離線備份，這個選項總是 NO。
圖 8. 使用 Control Center 進行離線備份 —— 介紹
有幾個可供選擇的目標選項。為了簡單，選擇 File System 並添加路徑。點擊 Next。
File System
Tape
Tivoli Storage Manager (TSM)
XBSA
Vendor
圖 9. 使用 Control Center 進行離線備份 —— 映像
在這一步中可以了解到許多信息。
備份類型 —— 只啟用全備份。在使用循環日志時，只能進行離線全數據庫備份。
可用性 —— 在使用循環日志模式時，只能進行離線全備份。如果要進行在線備份，那麼需要將日志模式改為存檔日志。這可以使用命令提示 CLP 或 DB2 Control Center 的 Configure Database Logging Wizard 來完成。
Quiesce 數據庫 —— 可以顯式地斷開所有應用程序的連接，也可以使用這個新的 quIEsce 數據庫特性。它迫使所有用戶離開實例或數據庫，並進入 quIEsced 模式以便進行維護。這個選項在默認情況下是啟用的。
Throttling —— 正如前面提到的，這是最好的特性之一，可以確保在備份期間服務器不會過載。在默認情況下，這個選項沒有啟用。啟用這個選項之後，可以根據希望分配給這個備份操作的資源相應地設置優先級。
壓縮 —— 在默認情況下沒有啟用。打開這個選項會使備份映像被壓縮。
圖 10. 使用 Control Center 進行離線備份 —— 選項
這一步處理性能設置。對於一般情況，采用默認值即可。
圖 11. 使用 Control Center 進行離線備份 —— 性能
可以立即運行備份，也可以安排它的運行時間。
圖 12. 使用 Control Center 進行離線備份 —— 調度
接下來，在總結頁面中顯示前面的所有選項/設置。同時，可以使用 show command 按鈕生成命令，還可以保存命令供以後使用。點擊 Back 按鈕可以返回前面的頁面進行修改，或點擊 Finish 按鈕執行備份。
圖 13. 使用 Control Center 進行離線備份 —— 總結
在執行期間，顯示備份過程已經經過的時間。
圖 14. 使用 Control Center 進行離線備份 —— 備份進度
最後，顯示備份成功提示。
圖 15. 使用 Control Center 進行離線備份 —— 備份成功
您可能會注意到，備份映像采用以下格式寫入：
清單 3. 使用命令 CLP 進行離線備份 DB_alias.Type\Inst_name\NODEnnnn\CATNnnnn\yyyymmdd\hhmmss.Seq_num
在我的環境中，路徑是 E:\temp\ABX84.0\DB2\NODE0000\CATN0000\20060519\151906.001。
恢復 —— 離線
在進行版本恢復時，需要使用一個離線全備份映像將數據庫恢復到建立這個備份時的狀態。恢復備份映像與進行備份一樣簡單。這也可以用命令 CLP 和 DB2 Control Center 兩種方式完成。
使用命令 CLP 進行離線恢復
恢復離線備份與進行備份一樣簡單。在發出離線恢復命令之前，需要發出命令 force applications all 或新的 quiesce 命令（並在完成恢復之後發出 unquIEsce 命令），從而讓數據庫進入維護模式；否則可能會收到錯誤 SQL1035N The database is currently in use. SQLSTATE=57019。
需要注意離線恢復的一些性質：
恢復可以覆蓋現有的數據庫，也可以改為新的數據庫名。
可以根據備份時間戳恢復特定的映像。
需要 sysadm、sysctrl 和 sysmaint 等特權。
恢復在數據庫級進行。不能進行表級或表空間級恢復。
有完整的恢復歷史列表。
不能進行增量或 delta 恢復。
簡單、容易而且靈活。
以下命令演示如何從離線備份映像進行恢復。
清單 4. 使用命令 CLP 進行離線恢復 restore db <your_db_name> from <your_backup_directory>
基本上只需要使用上面這樣的簡單命令。但是，有時候需要更大的靈活性，比如選擇要恢復的特定備份映像、在恢復期間修改數據庫的名稱等等。為了完整，下面給出恢復語法（但是注意，有些選項只對在線恢復有意義）：
清單 5. 使用命令 CLP 進行離線恢復 RESTORE DATABASE source-database-alias { restore-options | CONTINUE | ABORT }
restore-options:
[USER username [USING passWord]] [TABLESPACE [ONLINE] |
TABLESPACE (tblspace-name [ {,tblspace-name} ... ]) [ONLINE] |
HISTORY FILE [ONLINE] | LOGS [ONLINE] | COMPRESSION LIBRARY [ONLINE]]
[INCREMENTAL [AUTOMATIC | ABORT]] [USE {TSM | XBSA} [OPEN num-sess SESSIONS]
[OPTIONS {options-string | options-filename}] |
FROM dir/dev [{,dir/dev} ... ] | LOAD shared-lib [OPEN num-sess SESSIONS]
[OPTIONS {options-string | options-filename}]] [TAKEN AT date-time]
[TO target-directory] [INTO target-database-alias] [LOGTARGET directory]
[NEWLOGPATH directory] [WITH num-buff BUFFERS] [BUFFER buffer-size]
[DLREPORT file-name] [REPLACE HISTORY FILE] [REPLACE EXISTING] [REDIRECT]
[PARALLELISM n] [COMPRLIB lib-name] [COMPROPTS options-string]
[WITHOUT ROLLING FORWARD] [WITHOUT DATALINK] [WITHOUT PROMPTING]
使用 DB2 Control Center 進行離線恢復
使用 DB2 Control Center 進行離線恢復只需要兩個步驟。
打開 DB2 Control Center。
右擊要恢復的數據庫。選擇 Restore 選項。
圖 16. 使用 Control Center 進行離線恢復 —— 右擊選擇 Restore 選項
在恢復向導的介紹頁面中有三個恢復選項。如果需要決定恢復哪個數據庫映像，但是當前的歷史文件損壞了，那麼歷史文件恢復是非常有用的。備份映像中存儲的歷史可以單獨恢復，它包含所有備份和恢復信息。對於本例，只使用默認選項。點擊 Next 繼續。
圖 17. 使用 Control Center 進行離線恢復 —— 介紹
可以手工輸入要恢復的映像。如果采用手工選項，那麼需要指定備份映像的位置。也可以從 Available backup images 列選擇一個可用的映像並將它移動到 Selected backup images。這個列表是使用歷史文件中記錄的信息填充的（記住，歷史文件記錄了備份和恢復的歷史）。點擊 Next 繼續。
圖 18. 使用 Control Center 進行離線恢復 —— 可用映像
圖片看不清楚？請點擊這裡查看原圖（大圖）。
如果原來的容器路徑不可用，或者需要恢復到非默認的容器路徑，恢復期間的容器重定向是很有用的。我們只使用默認選項。點擊 Next 繼續。
圖 19. 使用 Control Center 進行離線恢復 —— 容器
在向導的這一步中有 4 個選項。
quIEsce 數據庫讓數據庫進入維護模式，不允許應用程序連接它。
數據鏈接用來引用數據庫之外存儲的對象。
歷史文件選項替換已經損壞的歷史文件。
恢復日志文件選項恢復備份映像中保存的日志文件（適用於在線備份和恢復）。
選擇 Queisce 數據庫並點擊 Next 繼續。
圖 20. 使用 Control Center 進行離線恢復 —— 選項
接受默認的性能選項。點擊 Next 繼續。
圖 21. 使用 Control Center 進行離線恢復 —— 性能
接受默認的立即運行選項。點擊 Next 繼續。
圖 22. 使用 Control Center 進行離線恢復 —— 調度
在總結頁面上，檢查設置。要想看到將發出的命令，點擊 Show command 按鈕。點擊 Finish 運行恢復。
圖 23. 使用 Control Center 進行離線恢復 —— 總結
顯示經過的時間，然後顯示成功恢復消息。
圖 24. 使用 Control Center 進行離線恢復 —— 恢復成功
離線備份和恢復 —— 對照表
下面的對照表對比 MySQL 和 DB2 Express-C 中用於離線備份和恢復的特性和功能。通過這個對比，現有的 MySQL 用戶能夠了解 DB2 Express-C 中可用的特性並適當地使用它們。盡管 mysqlhotcopy 不是完全離線的，我認為最好對比 MySQLhotcopy 和 DB2 Express-C 的離線備份和恢復，在對比在線備份和恢復時再考慮 InnoDB 的 ibbackup。
表 2. MySQL 和 IBM DB2 Express-C 離線備份之間的相似性和差異 特性/功能 在 MySQL 中的可用性（MyISAM —— MySQLhotcopy） 在 DB2 Express-C 中的可用性 注釋 日志模式 × √ InnoDB 主要使用二進制日志。在 DB2 Express-C 中，使用循環日志支持離線備份和恢復。 需要的授權 √ √ 對於 MySQLhotcopy，需要 SELECT 和 RELOAD 特權。在 DB2 Express-C 中，執行備份和恢復需要 sysadm、sysctrl 和 sysmaint 等特殊授權。 是否允許連接正在備份的數據庫 √ × MySQLhotcopy 使用 READ LOCK。用戶不必斷開連接。在 DB2 Express-C 中，在離線備份和恢復操作期間，不允許連接。使用 quiesce 讓數據庫進入維護模式，進行備份或恢復之後使用 unquIEsce 讓數據庫回到一般操作模式。 數據庫級備份和恢復 √ √ 在 DB2 Express-C 中，提供這個特性。 表空間級備份和恢復 × × 在 DB2 Express-C 中，離線備份只能在數據庫級進行。 表級備份和恢復 √ √ 在 DB2 Express-C 中，離線備份只能在數據庫級進行。不需要對表進行備份以防止意外地刪除表。在創建數據表空間期間 DB2 負責處理這個問題，表空間上的選項 DROPPED TABLE RECOVERY 是默認打開的。這個選項可以恢復被刪除的表。 只包含數據的備份（沒有索引） √ × MySQLhotcopy 使用 --noindices 標志。 正則表達式支持 √ × MySQLhotcopy 使用 --regexp 標志來匹配需要備份的數據庫或表。在 DB2 Express-C 中，不支持正則表達式。因為備份在數據庫級進行，只需選擇需要備份的數據庫。 GUI 向導備份和恢復 √ √ 到編寫本文時為止，MySQL Administrator（版本 1.1.9）提供以下備份模式。
InnoDB 在線備份
鎖定所有表備份
用二進制日志位置進行在線備份
一般備份
完整的備份
在 DB2 Express-C 中，提供這個特性。
命令提示級備份和恢復 √ √ 在 DB2 Express-C 中，提供這個特性。 多個映像目標 × √ 在 DB2 Express-C 中，提供這個特性。 對備份進行 throttling × √ 在 DB2 Express-C 中，提供這個新特性，可以在高負載和低負載時間段更好地使用資源。 備份壓縮 × √ mysqldump 提供壓縮功能，但是 MySQLhotcopy 沒有提供。在 DB2 Express-C 中，提供這個特性。 提供備份和恢復歷史列表 × √ 在 DB2 Express-C 中，歷史列表包含數據庫備份和恢復的完整歷史。這個歷史列表捕獲以下活動：數據庫或表空間被備份、恢復或前滾。
表空間被創建、修改、刪除、quIEsce 或重命名。
表被裝載、重構或刪除。
創建新的日志文件。
對日志文件進行存檔。
等等
恢復成新的數據庫 × √ 在 DB2 Express-C 中，提供這個特性。 在恢復期間重新指定數據庫文件（容器）的位置 × √ 在 DB2 Express-C 中，提供這個恢復選項。 從預填充的列表（GUI）中選擇備份映像 × √ 對於 MySQL Administrator 恢復，需要指定備份映像的位置。在 DB2 Express-C 中，在一個 GUI 向導中提供這個特性。 備份和恢復 API × √ 在 DB2 Express-C 中，嵌入式程序可以調用提供的備份和恢復 API。 與廠商 API 集成 × √ 在 DB2 Express-C 中，提供了與廠商 API 集成的開箱即用功能。 改進備份和恢復的性能選項 × √ 在 DB2 Express-C 中，可以實現更高的並發度並使用更大的緩沖區，從而改進備份和恢復過程。 對備份和恢復進行調度 √ √ 這兩種數據庫都提供了調度程序。可以將備份和恢復任務安排在特定的時間以一定的時間間隔運行。 保存備份和恢復腳本（GUI） × √ MySQL Administrator 允許將備份項目（而不是底層備份命令）保存到腳本中。在 DB2 Express-C 中，可以將備份和恢復命令保存到腳本中。 進度指示（GUI） × √ 在 DB2 Express-C 中，提供了顯示經過的時間的進度指示。 對備份和恢復操作的進度監視 × √ 在 DB2 Express-C 中，要監視備份和恢復操作的進度，可以使用 LIST UTILITIES 命令。例如，list utilitIEs show detail。 錯誤或成功日志 √ √ 這兩種數據庫都提供了豐富的錯誤日志。備份 —— 在線
與離線備份相似，我們也將演示在 DB2 Express-C 中進行在線備份的兩種方法 —— 使用命令 CLP 和 DB2 Control Center。先看看使用命令 CLP 進行在線備份，然後使用 DB2 Control Center 進行在線備份。然後，以相同的次序討論恢復。
在對數據庫進行在線備份之前，首先需要將日志機制從默認的循環日志改為存檔日志。可以在命令 CLP 中使用命令或在 GUI 向導中進行這個設置。可以在命令 CLP 中發出的命令都可以在 GUI 向導中得到，反之亦然。但是，我們將演示這兩種方法。
在命令 CLP 中，發出以下命令：
清單 6. 打開存檔日志 —— 命令 CLP db2 update db cfg for <your_db_name> using logarchmeth1 LOGRETAIN
為了確認設置，發出命令 get db cfg for <your_db_name> 並尋找 archlogmeth1 項。注意，將 archlogmeth1 參數設置為 LOGRETAIN 就會導致 logretain 參數被更新為 RECOVERY。這是默認的行為。如果想恢復這個設置，簡便的方法是發出命令 reset db cfg for <your_db_name>。打開存檔日志之後，DB2 會要求執行一次離線全數據庫備份。
除了打開存檔日志之外，還可能需要打開 mirrorlogpath 和 failarchpath。
要在 DB2 Control Center 中完成相同的任務，只需進行幾次點擊：
右擊要打開存檔日志的數據庫。
圖 25. 使用 DB2 Control Center 配置數據庫日志
選中 Archive logging。
圖 26. 配置數據庫日志 —— 日志類型
盡管提供了三個選項，但是建議讓 DB2 自動地對日志文件進行存檔。使用自動選項時要求指定主存檔日志路徑和故障轉移存檔日志路徑。
圖 27. 配置數據庫日志 —— 日志存檔
使用默認設置。
圖 28. 配置數據庫日志 —— 日志存檔
使用默認的日志位置。鏡像路徑可以防止單點故障。
圖 29. 配置數據庫日志 —— 日志位置
指定備份映像位置。
圖 30. 配置數據庫日志 —— 備份映像位置
指定備份選項。下面兩步分別是調度和總結回顧。
圖 31. 配置數據庫日志 —— 備份選項
打開存檔日志時需要執行一次離線全數據庫備份。點擊 Finish。
圖 32. 配置數據庫日志 —— 離線全數據庫備份
使用命令 CLP 進行在線備份
使用命令 CLP 進行在線備份只需一行命令（完整的備份語法見清單 2）：
清單 7. 使用命令 CLP 進行在線備份 db2 backup db <your_db_name> online to <your_backup_path>
使用 DB2 Control Center 進行在線備份
使用 DB2 Control Center 對數據庫或表空間進行在線備份只需要 6 個步驟，對於後 3 個步驟，就不再給出屏幕圖了，因為它們與離線備份時一樣。這 6 個步驟是：
介紹
映像
選項
性能
調度
總結
按照這些步驟對數據庫或表空間進行在線備份。
注意，可以備份整個數據庫，也可以備份數據庫中的某些表空間。我們選擇備份整個數據庫以便說明幾個問題。但是，如果選擇表空間備份，那麼必須在下個頁面中選擇要進行在線備份的表空間。
圖 33. 使用 Control Center 進行在線備份 —— 介紹
選擇存儲備份映像的位置。
增量和 delta 備份是禁用的。要打開它們，需要打開配置參數 trackmod。另外，可以將日志包含在備份映像中。這對於發送日志尤其有用。
圖 34. 使用 Control Center 進行在線備份 —— 選項
恢復 —— 在線
但是，在線恢復不像離線恢復那麼簡單，它提供了許多選項。我們將研究這些選項以及它們最適合在什麼場景中使用。
使用命令 CLP 進行在線恢復
需要發出以下命令。但是注意，可以選擇前滾到給定的本地時間（新特性）或 GMT 時間。
清單 8. 使用命令 CLP 進行在線恢復db2 restore db <your_db_name> from <your_image_location> taken at <your_image_timestamp>;
db2 rollforward db <your_db_name> to end of logs and complete;
另外，還可以發出簡化的命令 RECOVER DATABASE，它會自動執行前滾任務。見以下示例。
清單 9. 使用命令 CLP 進行在線恢復 —— 數據庫還原 db2 recover db <your_db_name> to end of logs;
或
db2 recover db <your_db_name> to <your_image_timestamp>;
使用 DB2 Control Center 進行在線恢復
現在看看主要的向導頁面（超過 10 個），了解在線恢復的一些特性。
可以使用三個選項進行在線恢復：
圖 35. 使用 Control Center 進行在線恢復 —— 介紹
有兩個對象恢復選項，表空間或整個數據庫。對於表空間級恢復，要在下個頁面中選擇要恢復的表空間。在我們的示例中，只進行整個數據庫的恢復。
圖 36. 使用 Control Center 進行在線恢復 —— 恢復對象
從預填充的列表中選擇一個映像，或者手工輸入映像位置。從預填充的列表中進行選擇是最容易的。這個列表是從歷史列表生成的。
圖 37. 使用 Control Center 進行在線恢復 —— 可用映像
可以重新指定容器路徑。我們采用默認路徑。
圖 38. 使用 Control Center 進行在線恢復 —— 容器
這裡給出許多選項，下面解釋這些選項：
可以只進行恢復而不進行前滾。不進行前滾會使數據庫處於未決模式。
前滾到
日志的末尾 —— 當要求沒有數據損失時通常使用這個選項。它會前滾到日志的末尾，達到最近的事務模式。
特定的本地時間（新特性） —— 它會前滾到特定的本地時間戳。由於 GMT 轉換比較麻煩，所以添加了這個特性。
特定的 GMT 時間 —— 它會前滾到特定的 GMT 時間戳。
日志獲取選項：
默認的存檔日志路徑 —— 這是默認路徑。
替換的存檔日志位置 —— 這相當於在前滾命令中指定 OVERFLOW LOG PATH，或者設置 OVERFLOWLOGPATH 配置參數。如果這兩個參數都設置了，那麼前者優先。
禁用存檔日志的獲取 —— 這由 NORETRIEVE 配置參數控制，禁用存檔日志的獲取。
圖 39. 使用 Control Center 進行在線恢復 —— 前滾
選擇完整的恢復並返回到活躍狀態。
圖 40. 使用 Control Center 進行在線恢復 —— 最終狀態
對於向導的其余步驟（選項、性能、調度和總結），可以使用默認設置；因為這些步驟與離線恢復相似，這裡就不重復解釋了。最後會顯示一個消息，指出恢復和前滾操作成功。
增量和 delta 備份和恢復
盡管這種特性主要用於使用 DB2 Universal Database™（UDB） Workgroup and Enterprise 的大型環境，但是為了本文的完整性，這裡仍然討論這個主題。
為了只對修改進行備份，DB2 UDB 在在線全備份（0 級）之上提供了增量（1 級）和 delta（2 級）備份。
增量備份是最近一次成功的全備份以來的所有修改的備份。這種備份形式也稱為累積備份。每個後續的增量備份映像都包含前一個增量映像的全部內容，也就是包含上一次全備份以來的所有修改。在發生故障時，例如在星期六進行增量備份之後發生了故障，那麼只能恢復上個星期日的全備份並應用星期六的增量備份。請參考下圖。
圖 41. 增量備份
delta 備份是最近一次成功的備份（包括全備份、增量備份和 delta 備份）以來修改的備份。在星期六發生故障時，可以恢復上個星期日的全備份並應用從星期一到星期六的 delta 備份。請參考下圖：
圖 42. delta 備份
為了進行增量或 delta 備份，需要打開 db cfg 參數 TRACKMOD。假設在每個星期日進行一次 0 級備份，在星期三和星期六進行 1 級備份，其他的日子進行 2 級備份，采用的步驟如下：
打開 TRACKMOD —— 發出命令 db2 update db cfg for icmnlsdb using trackmod on。
在星期日 —— 發出命令 db2 backup db icmnlsdb online。
在星期一 —— 發出命令 db2 backup db icmnlsdb online incremental delta。
在星期二 —— 發出命令 db2 backup db icmnlsdb online incremental delta。
在星期三 —— 發出命令 db2 backup db icmnlsdb online incremental。
在星期四 —— 發出命令 db2 backup db icmnlsdb online incremental delta。
在星期五 —— 發出命令 db2 backup db icmnlsdb online incremental delta。
在星期六 —— 發出命令 db2 backup db icmnlsdb online incremental。
要恢復增量備份，只需要兩步，恢復增量數據庫並前滾。
清單 10. 增量恢復 db2 restore db icmnlsdb incremental automatic taken at <your_image_timestamp>;
db2 rollfoward db <your_image_timestamp> to end of logs and complete;
在線備份和恢復 —— 對照表
與前面相似，下面的對照表對比 MySQL 和 DB2 Express-C 中用於在線備份和恢復的特性和功能。由於 InnoDB 的 ibbackup 具有在線和前滾功能，所以將它與 DB2 Express-C 進行對比。
表 3. MySQL 和 DB2 Express-C 在線備份之間的相似性和差異 特性/功能 在 MySQL 中的可用性（InnoDB —— ibbackup） 在 DB2 Express-C 中的可用性 注釋 日志模式 √ √ ibbackup 要求使用二進制日志。在 DB2 Express-C 中，使用存檔日志支持在線備份和恢復。 需要的授權 √ √ 在 DB2 Express-C 中，執行在線備份和恢復需要 sysadm、sysctrl 和 sysmaint 等特殊授權。 是否允許連接正在備份的數據庫 √ √ 這兩種數據庫都允許用戶在線執行自己的日常任務。 數據庫級備份和恢復 √ √ 這兩種數據庫都支持數據庫級備份和恢復。 表空間級備份和恢復 × √ ibbackup 不支持表空間級備份和恢復。 表級備份和恢復 √ √ 盡管這兩種數據庫都不支持表級備份（注意，我們指的不是表轉儲），但是都可以恢復被刪除的表。在 DB2 Express-C 中，在線備份只能在數據庫級和表空間級進行。不需要對表進行備份以防止意外地刪除表。在創建數據表空間期間，DB2 負責處理這個問題，表空間上的選項 DROPPED TABLE RECOVERY 是默認打開的。這個選項可以恢復被刪除的表。 在恢復期間數據庫/表空間是否需要離線 √ √ InnoDB 恢復要求數據庫離線。在 DB2 Express-C 中，在線備份和恢復只能在數據庫和表空間級進行。 增量和 delta 備份和恢復 × √ ibbackup 不支持增量和 delta 備份。在 DB2 Express-C 中，提供了這些特性，它們適用於不適合進行全數據庫備份的大型數據庫；只需要對修改進行備份。 前滾到特定的時間戳 √ √ 要將 InnoDB 恢復到特定的時間戳，需要多做一些工作。需要根據時間戳手工整理 MySQLbinlog 生成的輸出中的項目。在 DB2 Express-C 中，可以前滾到本地時間或 GMT 時間，或前滾到日志的末尾。 指定在主日志位置失效的情況下使用的替代日志位置 √ √ 這兩種數據庫都支持這個特性。 GUI 向導備份和恢復 × √ ibbackup 基本上是一個命令工具。 命令提示級備份和恢復 √ √ 在 DB2 Express-C 中，提供這個特性。 多個映像目標 × √ 在 DB2 Express-C 中，提供這個特性。 對備份進行 throttling × √ 在 DB2 Express-C 中，提供這個新特性，可以在高負載和低負載時間段更好地使用資源。 備份壓縮 √ √ 這兩種數據庫都支持壓縮。 提供完整且豐富的備份和恢復歷史列表 × √ ibbackup 中提供的一個日志記錄了備份和日志應用是失敗還是成功。但是，它不夠完整和豐富，沒有記錄對特定數據庫發出的所有備份和恢復命令。在 DB2 Express-C 中，歷史列表包含數據庫備份和恢復的完整歷史。換句話說，只要沒有刪除數據庫，就會一直維護歷史列表。這個歷史列表捕獲以下活動：
數據庫或表空間被備份、恢復或前滾。
表空間被創建、修改、刪除、quIEsce 或重命名。
表被裝載、重構或刪除。
創建新的日志文件。
對日志文件進行存檔。
等等
恢復成新的數據庫 × √ 在 ibbackup 中，無法在恢復數據庫時對它進行重命名。在 DB2 Express-C 中，提供這個特性。 將日志包含在備份映像中 √ √ ibbackup 備份日志包含在 ibbackup_logfile 中。在 DB2 Express-C 在線備份中，提供這個特性。 在恢復期間重新指定數據庫文件（容器）的位置 × √ 在 DB2 Express-C 中，提供這個恢復選項。 指定恢復期間的替代日志路徑 × √ 在 DB2 Express-C 中，提供這個恢復選項。 從預填充的列表（GUI）中選擇備份映像 × √ 在 DB2 Express-C 中，在一個 GUI 向導中提供這個特性。 備份和恢復 API × √ 在 DB2 Express-C 中，嵌入式程序可以調用提供的備份和恢復 API。 與廠商 API 集成 × √ 在 DB2 Express-C 中，提供了與廠商 API 集成的開箱即用功能。 改進備份和恢復的性能選項 × √ 在 DB2 Express-C 中，可以實現更高的並發度並使用更大的緩沖區，從而改進備份和恢復過程。 對備份和恢復進行調度（GUI） × √ 在 ibbackup 中可以設置 cron 作業來進行調度。在 DB2 Express-C 中，提供了調度程序。可以將備份和恢復任務安排在特定的時間以一定的時間間隔運行。 保存備份和恢復腳本（GUI） × √ 在 DB2 Express-C 中，可以將備份和恢復命令保存到腳本中。 進度指示（GUI） × √ 在 DB2 Express-C 中，提供了顯示經過的時間的進度指示。 對備份和恢復操作的進度監視 × √ 在 DB2 Express-C 中，要監視備份和恢復操作的進度，可以使用 LIST UTILITIES 命令。例如，list utilitIEs show detail。 錯誤或成功日志 √ √ 這兩種數據庫都提供這個特性。Throttling
Throttling 是 DB2 Express-C 中提供的一種令人興奮的新特性。DB2 Express-C 備份是一個具有 throttling 功能的實用程序，能夠在低負載時間段占用更多的資源，在高峰時間段占用較少的資源。Throttling 是一種非常新穎的特性。為了使用這個特性，需要 sysadm、sysctrl 和 sysmaint 等授權。新的配置參數 UTIL_IMPACT_PRIORITY 指定進行 throttling 的實用程序的優先級。
設置 throttling 優先級的語法很簡單。
清單 11. throttling 設置 set util_impact_priority for <utility_id> to priority
可以通過命令 list utilitIEs 獲得實用程序 ID。可以在以下范圍內設置優先級：
優先級 0 —— 不進行 throttling。
優先級 1-100 —— 最高數值是 100，表示最高優先級。
util_impact_priority 參數與 util_impact_lim 配置參數結合使用。後者指定允許任何給定的 throttling 實用程序對服務器產生多大的影響（百分數）。默認值 100 表示不進行任何 throttling 。這個值只在 util_impact_priority 設置為非零值時有意義。
另一種設置 throttling 優先級的方法是使用 DB2 Control Center。
圖 43. 設置 throttling 優先級
自動備份維護
自動備份維護是到目前為止最令人興奮的主題。這是大多數 DBA 長期盼望的特性（我就是其中的一員！）。自動備份維護究竟是什麼？自動備份維護是 DB2 Express-C 為提高數據庫系統的可管理性而提供的功能之一。備份（而非 runstats 和表重構）的自動維護加入自管理的屬性列表，可以由以下條件之一來調用該列表：
執行全數據庫備份時（如果還沒有這麼做的話）。
上次全備份以來經過的時間。
對於在線備份（使用存檔日志），達到使用的日志空間的阈值。
有兩個數據庫配置參數會影響自動備份維護，auto_db_backup 和 auto_maint。使用以下命令設置配置參數：
清單 12. 設置配置參數的命令 db2 update db cfg for <your_db_name> using auto_db_backup ON;
db2 update db cfg for <your_db_name> using auto_maint ON;
圖 44. 自動備份維護 —— 配置參數設置
可以使用 DB2 Control Center 設置相同的配置參數。
對自動備份維護的選項進行配置的快速方法是使用 DB2 Control Center。
在右面板上（接近底部），點擊 Maintenance。
圖 45. 自動備份維護 —— 維護
在介紹頁面上點擊 Next。
點擊 Next 修改設置。
圖 46. 自動備份維護 —— 類型
在這個頁面上，可以設置在線和離線備份維護時間窗。
圖 47. 自動備份維護 —— 計時
負責的 DBA 可以得到通知。
圖 48. 自動備份維護 —— 通知
其他一些活動或選項可以進一步影響備份維護：
圖 49. 自動備份維護 —— 活動
圖 50. 自動備份維護 —— 總結
其他實用程序
最後，DB2 Express-C 為對象的完整性檢查提供了幾個實用程序，可以探測數據損壞：
inspect —— 檢查表對象和表空間的結構，確保它們是有效的。
db2dart —— 表示 Database Analysis and Reporting Tool，它檢查數據庫體系結構的正確性。
db2ckbkp —— 檢查備份映像是否有任何損壞。這個程序檢查特定的映像是否是可恢復的。
為了進行總體的對比，下面的表對比 MySQL 和 DB2 Express-C 在備份和恢復方面的差異。
表 4. MySQL 和 IBM DB2 Express-C 高級特性對比 特性/功能 在 MySQL MyISAM（mysqldump/MySQLhotcopy）中的可用性 在 MySQL InnoDB（ibbackup）中的可用性 在 DB2 Express-C 中的可用性 離線備份 √ √ √ 在線備份 √ √ √ 前滾功能 × √ √ 在備份期間鎖定表 √ × × 靈活的存檔日志寫路徑 √ √ √ 靈活的存檔日志恢復路徑 √ √ √ 靈活的日志重試控制 √ √ √ 用來防止單點故障的內置日志鏡像 × × √ 對單一表進行備份和恢復 √ （MySQLdump） √ √ 時間點恢復 × √ √ 備份和恢復進度監視 × × √ 數據庫可以是本地或遠程的 × × √ 備份和恢復的完整歷史列表 × × √ throttling × × √ 備份映像的壓縮 √ （MySQLdump） √ √ 只備份數據（沒有索引） √ × × 使用電子郵件或呼叫器進行通知的內置特性 × × √ 內置的調度 × × √ 檢查備份映像完整性的實用程序 √ （myisamchk） √ √ 錯誤和成功日志 √ √ √ 手工備份和恢復 √ √ √ 自動備份維護 × × √ 增量和 delta 備份和恢復 × × √
結束語
本文討論了 MySQL 和 DB2 Express-C 備份和恢復機制的許多方面，包括體系結構、內存結構、日志類型以及備份和恢復類型。以一種並不詳盡的方式對比了 MySQL MyISAM 和 Oracle 的 InnoDB 存儲引擎與 DB2 Express-C 內置的備份和恢復機制之間的差異。盡管本文的主要目標讀者是 MySQL DBA，但是對規劃師和一般的 IT 人員也有幫助。
