用數據泵遷移數據

筆者單位新購置了數據庫服務器，為了便于管理、維護和節約成本的考慮，需要對數據庫按功能以及服務級別進行整合。但部分數據庫實時性要求時間性特別強，數據遷移工作給筆者帶來不小的挑戰。

為了盡快完成數據庫遷移并盡量減少服務終止時間，我們使用了Oracle數據庫提供的數據泵（DATA PUMP）工具對生產數據庫進行遷移。

環境：

操作系統：AIX7.1

數據庫：Oracle 12.0.4

遷移工具：DataPump

遷移數據庫表空間：DZGWZDTB、DZGWDOCZDTB

前期準備：

對于一個生產系統來說，一旦投入使用，應用數據持續產生和變化將是必然。對于系統的切換以及更新，需要很好的工程化方法，也需要多個應用業務部門的協調和溝通。因為數據彼此的關聯性已經有驅動力效應，導致越來越多的系統集成后，某些局部故障引發的蝴蝶效應。

因此，不論是既有系統更新或是新建系統上線與既有系統的整合都需要很好的部門間協調和共同努力來應對可能的問題和挑戰。

對業務及數據流的梳理是前期準備工作的重要方面。切換前的實驗以及切換時間的確定需要組織級決策。實驗的目的是輸出良好的自動化腳本，減少切換時間內人為錯誤的發生帶來的服務終止時間延續，避免因為切換帶來的災難性后果。同時，可以通過實驗進行良好的切換時間推算和預算，為組織級決策提供有效依據。

測試中發現使用數據泵進行數據導出導入時，對視圖、同義詞以及過程等沒有存放在表空間的用戶元數據需要進行特定步逐來進行，否則會導致這部分沒有存放在表空間的用戶元數據消失，導致應用系統及程序出錯。

切換實施過程:

1.源數據庫表空間導出操作

第一步，創建DIRECTORY，我們可以把DIRECTORY變量理解為EXPDP或者IMPDP導出、導入數據泵的工作目錄，它將dump文件、log文件以及SQL文件保存在其中。數據泵要求將目錄路徑作為一個目錄對象，創建過程如下所示：

這樣我們就可以在隨后的數據導出中使用該目錄對象進行數據導出。

使用ALL_DIRECTORIES視圖查看剛剛創建成功的DIRECTORY對 象，SELECT語句如下所示：

第二步，對用戶進行授權操作，對目錄對象的READ或WRITE權限僅僅表示Oracle將會替你讀寫這個文件。

你并沒有訪問Oracle以外文件的權限，因此使用AIX系統進行數據泵導入導出時，也需要檢查文件系統指定目錄權限。操作命令如下：

然后需要在操作系統中使用命令創建指定目錄，并進行用戶、屬組以及權限修改。

第三步，進行待導出表空間嚴格自包含檢查，導出沒有存放在表空間的用戶元數據（視圖、同義詞、過程等），并將該表空間修改為只讀，執行語句如下所示：

出現no rows selected后繼續執行以下的語句，先行導出沒有存放在表空間的用戶元數據（視圖、同義詞、過程等），執行語句如下所示：

然后執行表空間修改為只讀屬性語句，執行語句如下：

第四步，執行表空間的用戶元數據導出命令，執行語句如下：

完成后系統將在目錄“/data/tmp/dzgw”中生成dzgwzd2017.dmp。

2.源、目標節點數據傳輸

在進行完數據導出操作后，用戶需要將產生的DMP文件以及表空間對應的數據文件按照實際情況定義的目標文件目錄一同傳輸到目標數據庫所在主機。

這里基本就是按照規劃好的目錄結構進行數據復制，用戶可以根據自己喜歡的方式選擇具體工具進行文件傳輸。

生產系統中我們還是使用了工程化方法，保證兩臺數據庫節點DMP文件及表空間文件目錄名稱統一，這樣將減少因此帶來的不必要的細節干擾。

兩個節點上數據庫中數據文件目錄統一設置為/data/oradata/ORAXA/datafile/，數據泵使用的DIRECTORY目錄統一設置為/data/tmp/dzgw。

3.目標數據庫表空間導入操作

第一步，按照在源數據庫中創建DIRECTORY及授權操作的方法在目標數據庫中創建數據泵工具需要的基礎配置。

第二步，目標數據庫創建對應Oracle用戶并進行授權操作

根據源數據庫Oracle用戶信息，在目標數據庫中創建該用戶，執行命令內容如下：

用戶創建完成后繼續執行用戶授權操作，執行命令如下：

第三步，執行數據泵導入命令導入用戶元數據，內容如下：

導入沒有存放在表空間的用戶元數據（視圖、同義詞、過程等），執行語句如下所示：

第四步，將用戶默認表空間指向導入表空間，執行命令內容如下：

繼續執行命令進行表空間狀態查詢，執行命令內容如下：

此時新導入表空間狀態應該為”READ ONLY”狀態。

第五步，將表空間置為可讀寫狀態，完成整個表空間的遷移任務。

使用命令修改表空間為可讀寫狀態，執行命令如下：

至此數據庫遷移工作完成，可以進入應用測試和業務倒切恢復。

寫在最后

此次實際生產系統數據庫使用中對一個近80GB的數據庫進行遷移用時2.5小時，和傳統的EXPORT和IMPORT相比縮短近8小時，大大提高了數據庫遷移的時效性，有效的減少了服務終止時間。

基本對業務應用用戶沒有帶來影響，同時在測試中發現和解決了數據泵在導入過程中出現的表視圖、同義詞以及過程消失帶來的應用系統錯誤問題并進行了問題解決，避免了生產系統中數據庫遷移過程中可能出現的隱性問題。