備份和恢復DB2 Universal Database（1）

動機

SQL 語言提供了模式的概念，用來對所有類型的 SQL 對象進行分組。可以將 SQL 語言中的模式 理解成文件系統中的目錄。DB2 UDB for Linux, UNIX, and Windows 很好地支持 SQL 模式概念，可以將 USER 與 CURRENT SCHEMA 隔離開，并為例程解析提供了 PATH。

使用模式很輕易，但是它們的治理就不同了。模式的重命名、模式級備份和恢復以及模式的復制等任務比較困難，因為必須手工進行腳本編程，而且對象及其依靠性可能很復雜。

本文提供一個具有簡單接口的過程庫，使用戶能夠將給定模式中的所有對象備份到文件系統中、在另一個模式下恢復備份以及刪除給定模式中的所有對象。

安裝

下載并解壓縮本文包含的 backupschema.zip 文件之后，會得到以下文件：

backupschema.sql

這個文件包含一些 DDL 語句，這些語句安裝過程以及各個 helper 例程和表。在默認情況下，所有對象使用的模式是 "ADMIN"。假如要改變這個模式，只需修改這個文件開頭的 SET SCHEMA 和 SET PATH 語句，將 "ADMIN" 替換為您選擇的模式名。

為了執行這個腳本，作為 DB2 治理員連接到數據庫，然后執行 db2 -tvf backupschema.sql。

這些過程使用 SYSPROC.ADMIN_CMD() 存儲過程進行導出并使用 SYSPROC.DB2LOAD() 存儲過程進行裝載。（SYSPROC.ADMIN_CMD() 是在 DB2 V8.2.2（FP 9）中引入的。因此，需要的最低版本是 V8.2.2。）SYSPROC.ADMIN_CMD() 在 sqllibadm.fenced 的所有者指定的 fenced 用戶 id 和組 之下執行。因此，導出的文件具有與 sqllibadm.fenced 相同的所有者和組。因此一定要確保這個用戶和組對指定的目錄有寫特權，而且用來訪問文件的用戶 id 也有訪問權。簡單的解決方案是將 sqllibadm.fenced 的所有者改為實例所有者。更安全的解決方案是讓這兩個 ID 成為同一個組的成員，然后只將 sqllibadm.fenced 的組所屬權改為這個組。這樣就能夠通過組成員關系訪問產生的文件。

規范

DROPSCHEMA()

這個過程將刪除模式中定義的所有對象，并最終刪除這個模式本身。

參數

要刪除的模式的名稱。SQL 標識符是大小寫敏感的。要刪除模式 "MYSCHEMA"，模式名必須是大寫的：'MYSCHEMA'。

假如另一個模式中的對象依靠于要刪除的模式，那么應用刪除對象的常規規則。因此，在大多數情況下，依靠對象也會被刪除或失效。但是，一些對象（比如 SQL 函數）實施 RESTRICT 語義。假如碰到這種情況，那么這個過程將失敗。

DROPSCHEMA 過程在事務控制下執行，它自己不執行提交或回退。所以，要想讓模式的刪除持久化，必須提交刪除操作。同樣，假如發生錯誤，那么過程的調用者需要決定是否將過程回退。

BACKUPSCHEMA(,)

這個過程將模式中的所有對象邏輯備份到文件系統中。支持的對象是：

表，包括統計數據。不支持范圍簇表（RCT）、物化查詢表（MQT）和有類型的表。

視圖，但是不包括有類型的視圖。

函數，包括源、SQL 和外部函數。注重，對外部函數的可執行代碼不進行備份。函數的統計數據也不備份。

SQL 過程和外部過程。注重，對外部過程的可執行代碼不進行備份。

不同的數據類型。注重，不支持結構化數據類型。

索引，但是不包括索引擴展。

所有約束。

序列，包括它們的高水位標志。

支持的所有對象上的注釋。

支持的所有對象上的特權。

這個備份過程可以包括 PATH、SCHEMA 和 PREP 選項。

不支持聯邦對象（比如 NICKNAME）以及數據庫分區特性（DPF）。

參數

要備份的模式的大小寫敏感名。

對象要備份到的文件系統目錄。這個目錄必須存在，在 UNIX 或 Linux 上以斜線結尾，在 Windows 上以反斜線結尾；例如 'D:TEMPMYSCHEMA'。假如這個目錄是 NULL 或空字符串，那么不導出文件。這個過程只用 DDL 語句填充 DDLLOG 表。COPYSCHEMA 過程要使用這個方式。

在成功地備份之后，這個目錄包含以下對象的 IXF 文件：

備份的模式中的表。

SYSSTAT 視圖，包含表、列和索引統計數據。

DDL 日志，包含重建所有對象所需的信息。

用戶可以在這個目錄中添加其他文件，比如外部例程的可執行代碼。完成之后，可以根據需要用 zip 和 tar 對這個目錄進行壓縮、打包或傳輸。

RESTORESCHEMA(,,,)

這個過程恢復以前用 BACKUPSCHEMA 備份的模式。使用當前用戶的 ID 創建所有對象。假如恢復的任何對象引用另一個模式中的對象，而被引用的對象在目標數據庫中不存在，那么這個過程將失敗。這個過程執行內部提交。

假如恢復到與 BACKUPSCHEMA 不同的模式中，那么所有包含 SQL 體（比如視圖、SQL 例程和檢查約束）的 SQL 對象在它們的定義中必須沒有顯式地引用源模式。例如，CHECK (MYSCHEMA.MYTABLE.C1 > 0) 無法成功地恢復到 "MYSCHEMA" 之外的模式中，而 CHECK (MYTABLE.C1 > 0) 可以。為了能夠在 RESTORESCHEMA 中指定其他模式，建議在定義 SQL 對象時利用非凡寄存器 CURRENT PATH 和 CURRENT SCHEMA，而不是顯式地指定局部模式。

參數

要將對象恢復到的模式的大小寫敏感名。假如這個模式已經存在，那么先刪除它。假如模式是 NULL 或空字符串，那么這個過程采用備份時的模式名進行恢復。COPYSCHEMA 過程采用這種方式。

包含要添加到每個表定義中的表空間信息的字符串。這個子句可能包含 IN 、LONG IN 和 INDEX IN 子句。假如應該使用默認值，那么這個參數可以是空字符串或 NULL。例如：'IN DATA8K INDEX IN INDEX4K'

文件系統中存放 BACKUPSCHEMA 生成的文件的目錄。這個目錄在 UNIX 或 Linux 上必須以斜線結尾，在 Windows 上必須以反斜線結尾；例如 'D:TEMPMYSCHEMA'。 文件系統中的一個目錄，這個過程將把裝載消息文件寫到這個目錄中。這個目錄必須根據操作系統以適當的斜線或反斜線結尾。

COPYSCHEMA(,,) 這個過程在相同的數據庫中創建模式的副本。

參數

新模式的大小寫敏感名。

包含要添加到每個表定義中的表空間信息的字符串。假如是 NULL 或 ''，那么使用默認值。

要復制的模式的大小寫敏感名。

REBINDPROCEDURES()

這個過程對一個模式中的所有 SQL 過程進行重新綁定。在為模式中過程使用的表收集新的統計數據之后，應該調用這個過程。這個過程將重新優化 SQL 過程中使用的所有 SQL 語句。

參數

模式的大小寫敏感名。

示例

CALL ADMIN.DROPSCHEMA('SAMPLE')

這個過程調用會刪除模式 "SAMPLE" 中的所有對象。

CALL ADMIN.BACKUPSCHEMA('UTIL', 'D:TEMPUTIL_SCHEMA')

這個過程調用將模式 "UTIL" 中的所有對象存儲在目錄 D:TEMPUTIL_SCHEMA 中。

CALL ADMIN.RESTORESCHEMA(NULL, NULL, 'D:TEMPUTIL_SCHEMA', 'D:TEMP')

這個過程調用從 D:TEMPUTIL_SCHEMA 中獲取對象，并使用默認表空間將它們恢復到原來的模式中。來自裝載過程的消息寫入 D:TEMP 中。

CALL ADMIN.RESTORESCHEMA('SRIELAU', 'IN "DATA" INDEX IN "INDEX"', 'D:TEMPUSER_SCHEMA', 'D:TEMP')

這個過程調用從 D:TEMPUSER_SCHEMA 中獲取對象，并將它們恢復到 "SRIELAU" 模式中，對于表數據使用表空間 "DATA"，對于索引使用 "INDEX"。來自裝載過程的消息寫入 D:TEMP 中。

CALL ADMIN.COPYSCHEMA('SRIELAU', 'IN "DATA" INDEX IN "INDEX" LONG IN "LONG"', 'STOLZE')

這個過程調用將模式 "STOLZE" 中的所有對象復制到模式 "SRIELAU" 中，對于表數據使用表空間 "DATA"，對于索引使用 "INDEX"，對于 LOB 數據使用 "LONG"。 CALL ADMIN.REBINDPROCEDURES('SRIELAU'') 這個過程調用對模式 SRIELAU 中的所有 SQL 過程進行重新綁定，獲取新的統計數據。

實現

本節在較高的層面上概述本文前面討論的過程的實現。

成功地恢復一個模式中的所有對象的主要困難是，處理模式中不同對象之間的依靠性。例如，表可能依靠于用戶定義的不同類型；檢查約束依靠于函數；視圖依靠于視圖、別名和函數；等等。

因為 DB2 UDB 不能創建依靠于不存在的實體的對象，所以正確的執行次序是非常重要的。但是，假如仔細考慮一下這個問題，就會發現依靠圖的深度一般不大，而且某些對象是自然的端點。比如，用戶定義的類型不能依靠于其他 DDL 對象，而且表（不包括約束）只依靠于不同的類型。意識到這一情況，就可以分三個階段實現恢復：

恢復所有不同的類型，然后恢復所有表及其索引。

將數據復制到表中并獲取統計數據。這樣做是為了確保 SQL 過程的執行計劃是正確的。

在一個循環中恢復所有其他對象。因此，假如任何給定對象的創建失敗了，那么不必擔心，只要能夠繼續遍歷要恢復的對象的列表。只有當過程進行不下去時，才會返回錯誤。

利用這種基本的恢復算法，很輕易實現一種簡單的基礎設施。

BACKUPSCHEMA 過程使用 DDLLOG 表記錄 DDL 語句。第一行（編號為 0）包含源模式。后面是不同類型的 DDL 語句，然后是表的 DDL 語句。這個階段的末尾由一個空行表示，空行后面是所有其他對象。

這個表包含一個 SUCCESS 列，RESTORESCHEMA 使用這一列記錄一個對象是否成功創建了。

DDL 對象的組成完全基于文檔記錄的 SYSCAT 編目視圖，只有一個例外。IDENTITY 列的高水位標志需要從 SYSIBM.SYSSEQUENCES.LASTASSIGNVAL 中獲得，在 DB2 UDB V8 中沒有提供這個值。

與文件系統的交互是通過 SYSPROC.ADMIN_CMD 過程實現的，這個過程支持導出，用于將 DDLLOG 表、用戶數據和統計數據寫到文件中。對于裝載，要使用 SYSPROC.DB2LOAD。

用來恢復模式的強制性方式也用于刪除模式。DROPSCHEMA 過程簡單地不斷嘗試刪除對象，直到這個過程進行不下去或者所有對象都被刪除為止。

結束語

本文提供了一組強大的過程，可以執行模式級操作，比如對給定模式中的所有對象進行邏輯備份、恢復和復制。除了用這個庫幫助 ISV 和最終用戶之外，本文還演示了如何利用 DB2 UDB 中豐富的 SQL API 為用戶提供更多功能。