簡介
本文講解 Erik（一家虛構的公司 JK Enterprises 的 DBA）如何使用 Data Studio Administrator 對生產數據庫應用更改，從而響應團隊成員提出的請求。如果不使用 Data Studio Administrator，Erik 就必須通過手工編寫腳本在測試系統中遷移和測試更改，這需要很長時間而且很容易出錯。Data Studio Administrator 可以幫助 Erik 快速輕松地執行這些復雜的更改。
前提條件
本文使用 Data Studio Administrator Version 2, Release 1，帶 Fix pack 1。如果您希望實踐 Erik 的操作，那麼需要在機器上安裝 Data Studio Administrator (Administrator)。（試用版：IBM Data Studio Administrator for DB2 for Linux, UNIX, and Windows Data Studio Administrator V2.1）。
注意：這個場景使用 GSDB 數據庫模擬 JK Enterprises 的生產數據庫。您需要使用名為 GSDB 的示例數據庫。按照以下步驟創建這個數據庫：
從本文的 IBM Data Studio Administrator 2.1 中的新特性 部分獲得 zip 文件，從其中解壓出 GSDB_Database.sql 文件。
打開一個 DB2 命令窗口。
導航到保存 GSDB_Database.sql 文件的位置。
輸入：db2 -td~ -f GSDB_Database.sql
為了跟隨這個場景操作，還需要創建一個 “測試” 數據庫。這需要在 DB2 Command Line Processor (CLP) 中執行以下命令： - db2 CREATE DATABASE GSDBDEV USING CODESET UTF-8 TERRITORY US
在啟動 Data Studio Administrator 時，在 Data Source Explorer 中會自動地出現到生產數據庫和測試數據庫的連接，見 圖 1。在第一次使用這些連接時，需要輸入用戶名和密碼信息才能連接數據庫。
圖 1. Data Source Explorer 中的連接
查看原圖（大圖）
Erik 的數據庫更改請求（場景概述）
Erik 是 JK Enterprises 的 DBA，他收到一個請求，要求他在公司的所有客戶中添加移動成員。為了滿足這個請求，他首先把生產系統復制到測試系統，然後在測試系統上執行和測試更改。在測試更改之後，他把更改傳播回生產數據庫。下面的步驟演示 Erik 如何使用 Data Studio Administrator 輕松地完成這些任務。
在測試數據庫中創建模式
為了滿足對生產系統的更改請求，Erik 首先需要設置一個測試環境，他可以在這個環境中執行更改，而不會影響生產系統。這個更改請求涉及生產數據庫中的一個模式。為了在測試數據庫中反映這一點，Erik 決定在測試數據庫 GSDBDEV 中創建一個名為 CHANGES 的模式，它將保存後面所做的更改。
按照以下步驟創建名為 CHANGES 的模式：
在 Data Source Explorer 中 GSDBDEV 數據庫下面找到 Schema 文件夾。
右鍵單擊 Schemas 文件夾，選擇選項 Create > Schema。
圖 2. 在測試數據庫中創建模式
選擇 Data Object Editor 作為更改所用的編輯器。
圖 3. 選擇 Data Object Editor 作為使用的編輯器
在 Name 框中輸入 CHANGES。
單擊 PrevIEw DDL 顯示要執行的 DDL。
單擊 Run DDL 創建新模式。
圖 4. 在 Data Object Editor 中創建 CHANGES 模式
查看原圖（大圖）
CHANGES 模式現在出現在 GSDBDEV 數據庫的 Schemas 文件夾下面，見圖 5：
圖 5. 測試數據庫中的 CHANGES 模式
在測試數據庫中創建 CUST 表的拷貝
在測試數據庫 GSDBDEV 中創建新模式之後，Erik 使用 Data Studio Administrator 中新的復制和粘貼功能把生產數據庫 GSDB 中的 CUST 表復制到測試數據庫 GSDBDEV 中。復制和粘貼功能執行以下任務：
如果需要的話，自動地創建一個更改管理腳本
把數據庫對象從生產系統復制到更改管理編輯器中
可選地設置數據保留命令，這些命令把與數據庫對象相關聯的數據從生產系統復制到測試數據庫
按照以下步驟把 CUST 表從 GSDB 復制到 GSDBDEV：
導航到 GOSALESCT 模式並展開此節點，打開 Tables 文件夾。
在 Tables 文件夾下面找到 CUST 表。
右鍵單擊 CUST 表，選擇 Copy。
圖 6. CUST 表上的 Copy 操作
導航到 GSDBDEV 數據庫並選擇 CHANGES 模式。
右鍵單擊 CHANGES 模式並選擇 Paste。
圖 7. CHANGES 模式上的 Paste 選項
在彈出的對話框中選擇 Create a New Change Management Script，然後單擊 Next。
圖 8. Change Management Script Selection 對話框
在默認情況下，會選擇把 CHANGES 模式添加到更改管理腳本編輯器中。單擊 Next。
圖 9. 在默認情況下選擇 CHANGES 模式
注意：盡管 Erik 在這個場景中只使用一個模式，但是如果需要，可以同時使用多個模式。
選擇 Copy database objects and data，然後單擊 Finish。
圖 10. Copy 選項
注意：在某些公司中，不一定需要把數據從生產系統復制到測試系統，甚至不允許這麼做。如果只希望復制數據對象，那麼選擇 Copy database objects only 選項。選中 “Copy dependent database objects” 還會復制依賴的對象（如果有的話）。
使用更改管理腳本編輯器在 CUST 表中添加 MOBILEPHONE 列
完成粘貼操作之後，Data Studio Administrator 中顯示新的更改管理腳本編輯器 GSDBDEV.changeXML（見 圖 11）。這個編輯器包含粘貼到 CHANGES 模式中的 CUST 表。
圖 11. 包含 CUST 表的 GSDBDEV.changeXML
查看原圖（大圖）
現在在 CUST 表中添加一列 MOBILEPHONE。
Data Project Explorer 項目
對於每個更改操作，必須有一個 Data Project Explorer 項目。項目包含各種 Data Studio Administrator 文件和資源。更改管理腳本編輯器使用更改管理腳本文件（擴展名為 “.changeXML”）記錄和跟蹤對數據庫對象所做的更改。在新的工作空間中，粘貼操作會自動地創建新的 Data Project Explorer 項目。每個更改管理腳本鏈接到特定的數據庫和模式。如果有現有的 Data Project Explorer 項目，那麼在執行粘貼操作時可能會提示您選擇現有的 Data Project Explorer 項目或創建新的項目。
按照以下步驟在 CUST 表中添加 MOBILEPHONE 列：
在更改管理腳本編輯器的 “Objects to be Changed” 列表中選擇 CHANGES.CUST 對象，見 圖 11。
在編輯器右邊的屬性部分中選擇 Columns 選項卡。
注意：Columns 選項卡顯示當前與這個表相關聯的所有列。可以使用這個選項卡操作列。
單擊新列圖標（帶加號的菱形）創建一個新列：
把默認的列名 Column1 改為 MOBILEPHONE，把類型改為長度為 32 的 varchar。
注意：在某些情況下，用戶界面不會馬上顯示新列的信息。單擊 General 選項卡，再返回到 Columns 選項卡，就會顯示新列的信息了。
圖 12. 添加到 CUST 表中的 MOBILEPHONE 列
查看原圖（大圖）
單擊 PrevIEw Command 鏈接查看為執行表粘貼操作和添加新列生成的命令。
圖 13. 生成的 DDL
查看原圖（大圖）
可選：這時顯示一個對話框，詢問是否要查看描述更改的格式化報告。根據您的需要單擊 Yes 或 No。查看報告不會影響 DDL 的生成。
在查看 DDL 時，如果注意到在運行腳本之前應該做一些修改（比如應該修改表空間容器路徑），那麼可以在編輯器中或者通過修改 Data Project Explorer 模型對象執行這些更改。另外，可以使用 Customize 按鈕定制如何導出/導入數據（這在處理 XML 數據時特別重要）以及與 DDL 一起生成的額外命令類型（比如 Runstats）。如果出現一個對話框，它指出有數據保留錯誤，那麼選擇 Customize 按鈕並把導入選項改為 LOAD。
圖 14. 更改表空間
查看原圖（大圖）
影響分析
如果數據庫應用程序是用 Java 技術開發的，而且開發人員使用 Data Studio Developer，那麼非常容易檢查數據庫更改是否會影響某一應用程序。例如，可以使用 SQL outline 輕松地查明哪些查詢要使用 CUST 表並查看相關的 Java 源代碼，從而了解添加新列是否會影響某些查詢（比如 SELECT *）。
單擊 Run 按鈕運行命令。更改現在會應用於 GSDBDEV 數據庫。
可選：要想確認是否成功地執行了生成的命令，可以查看更改管理腳本編輯器的 Messages 部分。
Erik 現在可以測試對測試數據庫 GSDBDEV 所做的更改。因為在表中添加了新列，應該仔細地測試可能受此更改影響的所有應用程序。
把更改從測試數據庫 (GSDBDEV) 遷移回生產數據庫 (GSDB)
對於本文，我們假設 Erik 已經完成了所需的測試，認為可以把更改合並到生產數據庫 GSDB 中了。
為了幫助把更改從 GSDBDEV 數據庫遷移回 GSDB 數據庫，Erik 創建一個新的更改管理腳本。
按照以下步驟在 GSDB 數據庫上創建一個新的更改管理腳本：
右鍵單擊 Data Project Explorer 中的任何地方，選擇 New > Change Management Script。
圖 15. 創建新的更改管理腳本
查看原圖（大圖）
把這個腳本命名為 CHANGE TO PRODUCTION，然後單擊 Next。
圖 16. 指定腳本名稱
查看原圖（大圖）
選擇 GSDB 數據庫的連接並單擊 Next。
圖 17. 選擇 GSDB 數據庫連接
查看原圖（大圖）
選擇 GOSALESCT 模式並單擊 Finish。
圖 18. 為更改管理腳本選擇模式
查看原圖（大圖）
注意：選擇原來在 GSDB 數據庫中創建對象所用的模式。
顯示新的更改管理腳本編輯器，見 圖 19。下一節使用這個編輯器。
圖 19. GSDB 數據庫上的更改管理腳本編輯器
查看原圖（大圖）
使用 “Compare and Migrate” 向導把 CUST 更改遷移到生產數據庫
為了把更改從測試數據庫 GSDBDEV 遷移回生產數據庫 GSDB，Erik 使用 Data Studio Administrator 中的比較和遷移功能。Erik 可以通過比較和遷移功能以圖形化方式比較測試數據庫和生產數據庫。他可以選擇兩個數據庫之間的更改/差異並根據需要調整它們。在這個示例中，他找到對 CUST 表所做的更改並把它們合並到生產數據庫中。
從菜單欄中選擇 Change Management > Compare and Migrate Objects。
圖 20. Compare and Migrate Objects 菜單
選擇 GSDBDEV 測試數據庫連接（這個數據庫包含要遷移的更改），然後單擊 Next。
圖 21. 選擇 GSDBDEV 數據庫連接
查看原圖（大圖）
添加一個針對 CHANGES 模式的 mask：
在 Masks 選項卡中，選擇 SCHEMA 作為 Database Object，選擇 CHANGES 作為 In Mask，選擇 GOSALESCT 作為 Out Mask，然後單擊 Add Mask。
圖 22. 連接 GOSALESCT 和 CHANGES 模式的 mask
查看原圖（大圖）
在 Ignores 選項卡中添加對象，從而減少在比較向導中顯示的更改數量：
單擊 Ignore Database Objects 下拉菜單打開 Ignores 選項卡。
選擇 BPNAME，然後單擊 Add Ignore。
對於 TABLESPACES、CONTAINER 和 AUTHORIZATION 重復相同的步驟。
在選擇 BPNAME、TABLESPACES、CONTAINER 和 AUTHORIZATIONS 作為要忽略的數據庫對象之後，單擊 Next。
圖 23. 添加忽略
