如何做好Oracle邏輯資料遷移
阿新 • • 發佈：2018-12-12
如何做好邏輯資料遷移 如何使用exp/expdp進行資料遷移，如果是一個簡單的業務系統遷移，你可能不需要考慮任何外部因素，只要新庫建好，執行匯入匯出即可，你也完成了一個數據遷移專案，如果面對一個複雜的業務系統，與其他系統關聯度較高的業務系統，簡單的匯入匯出是無法安全的按時完成整個資料遷移專案，或許一個疏忽都會導致整個專案失敗而全部回退，本章節介紹了一套業務系統進行遷移的諸多注意事項，希望能給資料遷移實施工程師多一點參考少走一些彎路，若有不正確的地方還望指正。 一、資訊調研 ㈠ 最初的基本資訊核定 作為資料庫遷移專案的工程師，在進行資料庫遷移前需要進行充分的前期調研，調研得到的資訊越詳細，遷移就會越順利，制定的方案會更匹配當前的系統遷移，碰到的問題自然就會越少，在確定遷移方案之前你需要核實以下資料庫相關資訊 1. 源庫的建設架構 確定源庫的架構，其中包括Single instance單例項,linux unix，windows平臺下的HA, Single instance+DataGuard,多節點RAC,多節點RAC+DG，對於有DG環境的系統，當存在備庫作為業務查詢系統的情況時，如果資料遷移失敗回退，確保原主庫和DG備庫資料同步正常，確保回退時不遺留問題 2. 源庫的業務架構 確定源庫的業務架構，主要核證業務屬於CS架構或者BS架構還是CS+BS混合架構，遷移後需要修改多少個業務客戶端和連線池，這部分資訊涉及到後面的業務驗證與業務回退 3. 源庫的互動架構 核查與源庫有互動的所有資料庫的版本和dblink及當前的SCN headroom閥值，SCN閥值可以通過MOS [ID 1393363.1]文章中的scnhealthcheck.sql” 指令碼來檢查當前SCN情況，如果客戶業務的辦理方式是通過資料庫間的dblink互動來實現，則在使用跨資料庫版本遷移方案中需要特別謹慎對待，由於不同版本資料庫的SCN增長速率與閥值不同，如果在不同版本的資料庫之間發生SCN拒絕同步，在遷移後的資料庫使用dblink進行互動查詢時會頻繁出現ORA-19706: Invalid SCN的錯誤，此項錯誤對於使用dblink辦理業務的系統來說無疑使致命的，終將會導致通過使用dblink來辦理的業務均無法正常辦理，因此對於是否確定使用跨資料庫版本遷移方案事前一定要評估跨版本遷移的風險和影響範圍。 4. 源庫與新庫的版本 確定源庫與新庫的資料庫版本，包括同版本間的資料遷移、跨版本的資料遷移，資料庫版本決定這使用exp還是expdp工具還是exp/imp結合expdp/impdp，例如oracle 9i就只能使用exp/imp 5. 源庫新庫作業系統的平臺 確定源庫與新庫的作業系統平臺Windows,Linux,Unix 6. 源庫與新庫主機硬體資源 確定源庫與新庫的主機硬體，主要包括CPU，記憶體，這兩項引數決定使用exp/expdp/imp/impdp進行邏輯遷移時最大可以加到多少併發量以達到最快的速度完成遷移 7. 源庫與新庫的可用的儲存 7.1 儲存型別確定 源庫與新庫儲存型別的核查包括確認本次遷移所有使用的儲存是獨立的儲存還是伺服器的本地儲存，因為兩者讀寫的效能差異巨大，直接影響遷移速度和專案完成時間 7.2 儲存效能確定 確定源庫與新庫的所使用的儲存，主要驗證儲存的最大可使用空間，儲存的讀、寫效能，RAID冗餘級別，讀寫效能測試使用dd只能作為參考值，可以通過orion專業IO測試工具或資料庫建立表空間的方式粗略估算儲存的讀寫效能 8. 源庫與新庫的網路情況 確定源庫的網路使用情況，千兆網路還是百兆網路，網路穩定性，如果涉及到網路傳輸dmp檔案還需要估算最大傳輸的時間，這項引數決定著遷移的進度快慢 9. 源庫的資料 9.1資料量 首先確定的是資料量，包括segment與datafile，LOB欄位（LOB欄位作為一個Oracle特殊欄位需要特殊對待，通常lob欄位在（exp/expdp/imp/impdp）匯入匯出的時候速度非常緩慢，匯入匯出速度通常慢於傳統資料的幾倍或者十幾倍，大量的LOB欄位也是遷移的瓶頸，因此在遷移過程中存在大量的LOB欄位則需要單獨進行處理） 9.2有效資料 使用者的有效資料是指哪些資料是可以提前進行遷移，哪些使用者的表資料是不需要遷移，這種情況包括很多業務端通過CTS備份的表和過期的不使用業務表等這些都屬於無效資料，忽略無效資料會大大加快遷移速度 10. 源庫的停機時間 使用者允許最大停機時間，與客戶商定最大的停機時間，保證遷移時間充裕確定了基本資訊後基本可以確定使用哪種方案進行對資料庫遷移，你有多少可控的資料遷移時間 二、方案選擇 Exp/Expdp為例 在對資料庫進行邏輯遷移的時一般使用最多的是Oracle自帶的exp/expdp/imp/impdp邏輯遷移工具，在對資料庫進行遷移的時一般包括兩種，全庫遷移和部分使用者遷移，全庫進行遷移到時候主要還是對除資料庫系統使用者(SYS,SYSTEM等)外的所有業務使用者進行遷移，由於使用者之間存在依賴關係，遷移順序無法掌控，這種多使用者的資料遷移往往再遷移後容易丟失一些許可權和同義詞等資訊，對於丟失部分資訊的情況需要在遷移完成後進行單獨比對處理 ㈠ 資料庫資訊處理 1. 資料庫的job 在使用sysdba許可權的使用者對資料庫業務使用者進行遷移的時，會發生部分使用者業務的job會發生匯入失敗的情況或者屬主匯入不匹配的情況，這種情況的job是無效的，對於這種情況遷移工程師需要與業務系統的運維人員確認業務所有的可用的job，然後以業務使用者自身的角色進行單獨對job匯出匯入，使用expdp/impdp include=job，content=meatdata_only選項即可 2. 資料庫的dblink 在資料互動多的系統中，dblink也是用的最多的，需要確認哪些dblink需要重建，包括建立dblink的使用者和密碼和Netservice name 3. 資料庫的ACL列表 11g的資料庫，某些應用程式需要ORACLE ACL的訪問列表進行訪問，此種情況存在,通過Select * From dba_network_acls命令來檢視 4. 資料庫的字符集 確定好源庫與新庫的字符集，新庫與源庫的字符集必須要一致 5. 資料庫的無效物件 確定好業務使用者無效的物件，以在遷移後進行比對 6. 資料庫的加密物件 檢查源庫是否存在加密的package，procedure資料庫如果存在加密的package，procedure，則使用impdp還是容易觸發資料泵bug，impdp匯入會損壞加密的包以及儲存過程，導致業務無法使用，如果存在加密的package需要使用原始的exp/imp方式對其進行單獨匯出匯入 7. 源庫的SQL執行計劃 對於業務壓力大的待遷移資料庫系統，遷移前後務必保持遷移後SQL執行計劃最優，需要提前兩週做好核心業務的SQL執行計劃的抓取，執行計劃的抓取可以使用awr+sqlrpt及sqlplus autotrace工具進行抓取，在跨資料庫版本進行資料庫遷移後，由於優化器演算法，表的統計資訊，聚簇因子等變化導致SQL的執行計劃改變，在進行遷移後，新庫很容易出現由於SQL走了錯誤的執行計劃導致資料庫效能問題 8. 作業系統的NLS環境變數 使用Select * from v$nls_parameters where parameter='NLS_CHARACTERSET';語句來查詢源庫與新庫的NLS環境變數，在使用exp/imp匯入前通過export NLS_LANG=XXXX 保證源庫與新庫的NLS_LANG一致,以避免IMP-00091匯入錯誤和其他異常 ㈡ 資料庫使用者處理 1. 使用者的資料量 統計遷移使用者的資料量，這是資料遷移的常識，統計好單個使用者的資料量，定製合理的遷移順序和併發匯入 2. 使用者的密碼 對於個別不知道密碼的資料庫業務使用者可以在匯入時臨時在新庫修改使用者密碼，再通過查詢源庫dba_user或user$中的password欄位得到加密過的原密碼，在新庫中通過（alter user identified by values‘源庫查詢出來的加密的密碼’;）命令來恢復新庫遷移後用戶的原密碼 3. 使用者的預設表空間，臨時表空間 在新庫中建立遷移使用者的對應的預設表空間與臨時表空間，保證新庫與源庫表空間一致，新庫表空間空間充足 4. 使用者的許可權，同義詞、主鍵 在遷移多個使用者的過程中由於不同使用者之間存在許可權的依賴關係，往往在使用者匯入的順序不同的時候會發生許可權缺失，而遷移工程師經常會面臨遷移後用戶許可權缺失的問題，在遷移後用戶的賦權的語句需要重新執行，可以使用impdp 中sqlfile的引數通過載入dmp檔案生成相關的所有ddl dml的sql指令碼，或者使用plsql、toad等工具抽取使用者的相關賦權sql指令碼 ㈢ 統計業務 確定有多少個業務需要連線源庫，使用什麼方式連線，CS客戶端還是使用連線池connect pool，估算業務IP的修改時間，以保證在發生遷移失敗後以最短的時間回退 ㈣ 系統測試 如果情況允許，最好能在新資料庫搭建成功後測試一些imp/impdp的匯入速度以評估資料遷移時間 三、實施資料遷移 ㈠ 業務端操作 1.停止業務系統 確定開始遷移後，備份所有中介軟體的連線配置，修改與源庫相關的所有配置有軟體業務系統的連線配置，關閉業務軟體系統 ㈡ 源庫端操作 1. 停止源庫監聽 關閉資料庫監聽，以保證沒有其他業務通過連線池和dblink連線源對資料庫進行業務操作 2. 重啟資料庫 以shutdown immediate的方式關閉資料庫，再重新開啟，此項保證在遷移後sequence序列和源資料與新庫遷移後保持一致 3. 停止源資料庫JOB 對於複雜的業務系統，通常資料庫在不同時段有很多job在執行，因此在遷移時避免效能問題應該停止源庫的所有job通過alter system set job_queue_processes=0設定停止所有執行或將要執行的job，在dba_jobs_running 資料字典來查詢是否所有job都已經關閉 4. 匯出資料 源庫檢查無誤後開始對資料庫進行匯出，根據當前的硬體與儲存資源來設定並行，對於較大使用者資料，建議生成多個dmp檔案 5. 資料傳輸 資料傳輸注意oracle許可權與檔案使用二進位制方式傳輸 ㈢ 新庫端操作 1. 檢查字符集 在匯入前，檢查資料庫的字符集與作業系統的環境變數 2. 關閉歸檔 關閉新庫的歸檔，以提升資料匯入的效能 3. 檢查表空間 對比源庫與新庫的資料表空間與臨時表空間的個數、名稱及其所屬關係是否一致 4. 檢查dmp檔案許可權 檢查檔案許可權是否正確 5. 開啟並行匯入 加大新庫的資料庫PGA記憶體，根據伺服器的CPU個數來開啟資料泵的並行匯入 ㈣ 驗證 1. 資料驗證 匯入全部結束後，檢查imp/impdp的匯入日誌，檢查資料庫的job,dblink，主鍵，外來鍵、序列、物化檢視是否完整或有效，可以使用plsqldeveloper，veridata進行比對，重新執行賦權的sql,檢查、重新編譯無效物件，在sqlplus裡執行@？/rdbms/admin/utlrp.sql編譯所有無效物件 2. 開啟資料庫歸檔 開啟資料庫歸檔使資料庫執行在歸檔模式下 3. 重啟業務驗證業務 需要業務運維工程師配合驗證業務，核心業務逐一驗證 四、回退 回退，這是最不願意看到的一幕，如果資料庫遷移在規定時間內無法完成，需要立刻回退至原系統 ㈠ 業務軟體系統 還原軟體系統的連線配置 ㈡ 資料庫回退 對源庫的操作根據修改記錄逐一回退 ㈢ 驗證業務 驗證回退的業務 --------------------- 作者：灰帽DBA 來源：CSDN 原文：https://blog.csdn.net/Evils798/article/details/50219257 版權宣告：本文為博主原創文章，轉載請附上博文連結！