扒一扒Oracle資料庫遷移中的各種坑

oracle遷移是資料庫運維中一項必不可少的工作，具體到項目層面上則有系統割接、資料庫版本更新遷移、資料庫主機更換、資料庫拆庫、資料庫合庫、測試系統搭建等等各類場景，然而正所謂萬變不離其宗，遷移總的來說就是dataguard、rman、底層複制等實體方式以及datapump、goldengate等邏輯方式。本文目的在于從筆者實際參與的各種遷移類項目出發，簡明扼要地從宏觀的角度數一數遷移類項目中可能遇到的坑。

一無法繞過的架構類問題 

對于一個核心的系統來說，資料庫很可能并不是孤立的，而是涉及應急、容災、bcv、備份等各個方面，同時這個資料庫又可能是别的資料庫的資料源的源端或者目标端。當進行這種複雜系統的遷移時，務必考慮到這些方面。

筆者進行參與的某營運商資料庫更新項目是通過goldengate方式實作換機器方式更新的，這個營運商的某核心庫則相當複雜了，其涉及的外圍因素如下：

通過賽門鐵克底層同步庫軟體實作的容災庫；

通過賽門鐵克底層同步庫軟體實作的bcv庫；

通過goldengate軟體實作的應急系統。

由于涉及的資料庫較多，我們在處理這個項目時，采用了提前更新應用系統，同時更新主系統以及容災系統，最後更新bcv系統的方式進行調配。

二不能掉以輕心的資源問題 

遷移工作應當盡可能降低對現網運維工作的影響，由于遷移工作而引發的現網系統出現問題是客戶很難接受的事情，然而在實際的遷移工作中，因為疏忽大意或者對系統架構不了解而導緻問題。

對于需要從源端資料庫直接進行datapump等方式資料導出的遷移工作而言，需要注意導出工作對源端造成的cpu、記憶體、io、檔案系統等影響相信很多dba都能想到，但在後續的傳輸以及入庫中，則反而容易遇到不了解系統架構的問題了，例如下述兩個例子：

網絡未分離，過多ftp程序并發傳輸占用網絡帶寬，進而影響應用系統；

目标資料上沒有應用，但其存儲與現網是共用的，大并發進行資料導入導緻影響現網。

對于目标端本身就是生産系統的情況，則操作更得小心翼翼了，除了正常的cpu、記憶體等名額外，還得注意歸檔、表空間等細節，遺漏其中一項都可能引發故障，這種遷移隻能步步為營，慢慢搞了。

三難以省心的應用 

遷移工作的完成需要應用廠商和資料庫的互相支撐，然而，從筆者親身的項目經驗來看，偶爾也會遇到個别不靠譜的開發人員，進而影響整個項目的推進，下面是筆者遇過的幾個例子：

割接後跑過來抗議說新庫和舊庫資料不一緻，核查原因發現舊庫應用未停止幹淨，幸虧提前做了監控，否則問題說不清；

未正确修改應用配置，導緻連錯執行個體，影響進度；

前期未充分測試，在更新期間才發現，處理起來相當被動。

四五花八門的資料庫問題 

與上面相比起來，資料庫本身的問題就更複雜了，需要通過項目經理來積累了，下面是筆者總結的類型：

sql語句性能類，例如版本變更導緻的語句性能退化；

對象及權限類問題，例如對象編譯不通過，這種問題留到割接期間會顯得相當被動；

job排程問題，例如執行個體重新開機導緻的job多餘排程導緻髒資料；

資料庫管理問題，例如監控或者備份機制跟不上；

資料庫配置問題，例如參數設定不合理；

特殊對象類型問題，例如不常用的queue僅遷移而未start導緻應用報錯。

<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2015-12-07</b>