資料遷移中的幾個問題總結

   總結一下昨晚在資料遷移前線奮戰碰到的一些問題，雖然總體來說是按照預定的計劃完成，並且提前完成，但是哪怕一丁點兒的操作都會導致一些嚴重的影響。

   總體來說，需要做的事情就是把核心業務伺服器從一個機房遷移到另外一個機房，這個過程中因為環境的重要性和硬體軟體的情況，大體分為了下面三個方向的技術方案。

1. 遷移部分核心業務從Solaris到X86平臺，同時需要升級資料庫版本

2. 遷移x86平臺的部分核心業務，這個方向操作相對簡單，基本就是主備切換

3. 整合部分X86平臺的環境，比如資料庫a,b整合後就是一個資料庫a

這些工作需要在幾個小時內全部完成，而且保證不能出現資料類問題。

   技術方案1，是跨平臺的資料庫遷移式升級，我們採用了混合式的技術組合，比如對於小表，資料類不大使用Datapump來全量同步，對於中型表使用物化檢視的prebuilt來達到增量重新整理的目的，對於大型表，則使用OGG的複製方式，當然為什麼中性型表和大型表要分開對待，都使用OGG行嗎，可以的，這個主要還是考慮團隊等的因素，而不單單技術可行。

  技術方案2，這個部分相對來說比較常規，就是主備切換。主備切換的過程其實沒有更多可談的了，完全沒有理由切到一半切不動了。只要配置沒問題，在DG Broker裡面就一個命令即可。

   技術方案3，這個部分涉及資料整合，而且在這個基礎上需要做一次資料庫的升級,如果資料量不大，其實Datapump足矣，如果資料量在TB級別，要實現這類資料整合和升級的需求就有一些難度了，至少目前我看到的絕大多數情況是透過增量或者邏輯複製的方式。

   遷移的需求大體如上所述，維護時間是限定的，需要不到3個小時的時間內搞定，要麼成功要麼回退。

   我拿出幾個遷移中碰到的問題，很多還是很有代表性，也是我們做技術方案的時候需要不斷改進和完善的地方。

問題1：

在使用prebuilt的物化檢視增量重新整理的時候，在最後的資料確認階段，再次嘗試一次增量重新整理，竟然丟擲了下面的錯誤。

SQL> exec dbms_mview.refresh('GAMEUSER.PEAK_LOGINLOG','F');
BEGIN dbms_mview.refresh('GAMEUSER.PEAK_LOGINLOG','F'); END;
*
ERROR at line 1:
ORA-04062: timestamp of package "SYS.DBMS_SNAPSHOT_UTL" has been changed
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2809
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 3025
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2994
ORA-06512: at line 1
問題2：

還有一部分的物化檢視增量重新整理的時候會出現hang的情況，儘管主庫的物化檢視日誌資料不多，但是這個重新整理的過程就很慢。

 exec dbms_mview.refresh('TLBB.PURSE_RESERVE_RECORD','F');

上面的兩類問題在時間不等人的資料遷移中，是很敏感的，所以如果這種一下，表資料量不是太大，就乾脆直接全量同步或者Datapump來重新做。

還有一個技巧就是如果重新整理的表極大，先優先檢視物化檢視日誌，如果沒有資料，心裡就會踏實很多，哪怕重新整理時出點小問題，心裡還是亮堂的。

問題3：

在從源庫使用DAtapump匯出資料的時候，竟然丟擲了錯誤，這對於依賴Datapump的遷移專案來說，不能很好的使用Datapump會困難重重，下面是一個基本的匯出方式，當然在10g版本里面可能有點問題，比如使用了並行，匯出的時候就可能提示溢位而失敗。

expdp xx/xxx dumpfile=gameuser.dmp directory=dp_dir parfile=gameuser.par parallel=4

問題4：

這個問題是在資料庫做了主備切換之後碰到的，看日誌可以得知是歸檔的問題，但是實際上閃回區也足夠，歸檔路徑也是有效的。

Mon Jul 24 04:10:13 2017
ARC0: LGWR is actively archiving destination LOG_ARCHIVE_DEST_1
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance acccomdb - Archival Error
ORA-16014: log 1 sequence# 31829 not archived, no available destinations
ORA-00312: online log 1 thread 1: '/U01/app/oracle/oradata/acccomdb/redo01.log'
Mon Jul 24 04:13:11 2017
Starting background process SMCO
Mon Jul 24 04:13:11 2017
SMCO started with pid=39, OS id=51303

初步分析發現是歸檔路徑的不規範，比如設定的歸檔路徑引數有多個，像log_archive_dest1,log_archive_dest2其實有不同的含義和用法，解決問題的方法就是把這些路徑引數清空，重置DG Broker來初始化。見效快還一步到位。

問題5：

DB link的問題，說實話DB link在多個資料庫間查取資料庫，有點蜘蛛網的感覺。我們可以使用tnsping的方式來驗證tnsnames.ora的配置。但是如果埠通了，不一定證明tns的配置沒有問題。

比如下面的報錯資訊，都是DB link的問題，但是報錯資訊不同

  java.sql.SQLException: ORA-04053: error occurred when validating remote object GAMECARD.USECARDMAIN@DB_SWORD_TEST0

ORA-00604: error occurred at recursive SQL level 1
ORA-02019: connection description for remote database not found

java.sql.SQLException: ORA-04045: errors during recompilation/revalidation of APP_TL_SDE_128.CHONG_KAMI_RECHARGE_NEW?
ORA-04052: error occurred when looking up remote object TLBB.USER_POINT@GCDB?
ORA-00604: error occurred at recursive SQL level 3?
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

我們需要花一些時間來修復這類問題，排查的過程會因為資訊提供的誤差而偏離問題的方向。我們需要冷靜一點，再細心一些。