數據遷移中的幾個問題總結

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

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

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

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