數(shù)據(jù)遷移中的幾個(gè)問(wèn)題總結(jié)

   總結(jié)一下昨晚在數(shù)據(jù)遷移前線奮戰(zhàn)碰到的一些問(wèn)題，雖然總體來(lái)說(shuō)是按照預(yù)定的計(jì)劃完成，并且提前完成，但是哪怕一丁點(diǎn)兒的操作都會(huì)導(dǎo)致一些嚴(yán)重的影響。

   總體來(lái)說(shuō)，需要做的事情就是把核心業(yè)務(wù)服務(wù)器從一個(gè)機(jī)房遷移到另外一個(gè)機(jī)房，這個(gè)過(guò)程中因?yàn)榄h(huán)境的重要性和硬件軟件的情況，大體分為了下面三個(gè)方向的技術(shù)方案。

1. 遷移部分核心業(yè)務(wù)從Solaris到X86平臺(tái)，同時(shí)需要升級(jí)數(shù)據(jù)庫(kù)版本

2. 遷移x86平臺(tái)的部分核心業(yè)務(wù)，這個(gè)方向操作相對(duì)簡(jiǎn)單，基本就是主備切換

3. 整合部分X86平臺(tái)的環(huán)境，比如數(shù)據(jù)庫(kù)a,b整合后就是一個(gè)數(shù)據(jù)庫(kù)a

這些工作需要在幾個(gè)小時(shí)內(nèi)全部完成，而且保證不能出現(xiàn)數(shù)據(jù)類(lèi)問(wèn)題。

   技術(shù)方案1，是跨平臺(tái)的數(shù)據(jù)庫(kù)遷移式升級(jí)，我們采用了混合式的技術(shù)組合，比如對(duì)于小表，數(shù)據(jù)類(lèi)不大使用Datapump來(lái)全量同步，對(duì)于中型表使用物化視圖的prebuilt來(lái)達(dá)到增量刷新的目的，對(duì)于大型表，則使用OGG的復(fù)制方式，當(dāng)然為什么中性型表和大型表要分開(kāi)對(duì)待，都使用OGG行嗎，可以的，這個(gè)主要還是考慮團(tuán)隊(duì)等的因素，而不單單技術(shù)可行。

  技術(shù)方案2，這個(gè)部分相對(duì)來(lái)說(shuō)比較常規(guī)，就是主備切換。主備切換的過(guò)程其實(shí)沒(méi)有更多可談的了，完全沒(méi)有理由切到一半切不動(dòng)了。只要配置沒(méi)問(wèn)題，在DG Broker里面就一個(gè)命令即可。

   技術(shù)方案3，這個(gè)部分涉及數(shù)據(jù)整合，而且在這個(gè)基礎(chǔ)上需要做一次數(shù)據(jù)庫(kù)的升級(jí),如果數(shù)據(jù)量不大，其實(shí)Datapump足矣，如果數(shù)據(jù)量在TB級(jí)別，要實(shí)現(xiàn)這類(lèi)數(shù)據(jù)整合和升級(jí)的需求就有一些難度了，至少目前我看到的絕大多數(shù)情況是通過(guò)增量或者邏輯復(fù)制的方式。

   遷移的需求大體如上所述，維護(hù)時(shí)間是限定的，需要不到3個(gè)小時(shí)的時(shí)間內(nèi)搞定，要么成功要么回退。

   我拿出幾個(gè)遷移中碰到的問(wèn)題，很多還是很有代表性，也是我們做技術(shù)方案的時(shí)候需要不斷改進(jìn)和完善的地方。

問(wèn)題1：

在使用prebuilt的物化視圖增量刷新的時(shí)候，在最后的數(shù)據(jù)確認(rèn)階段，再次嘗試一次增量刷新，竟然拋出了下面的錯(cuò)誤。

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
問(wèn)題2：

還有一部分的物化視圖增量刷新的時(shí)候會(huì)出現(xiàn)hang的情況，盡管主庫(kù)的物化視圖日志數(shù)據(jù)不多，但是這個(gè)刷新的過(guò)程就很慢。

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

上面的兩類(lèi)問(wèn)題在時(shí)間不等人的數(shù)據(jù)遷移中，是很敏感的，所以如果這種一下，表數(shù)據(jù)量不是太大，就干脆直接全量同步或者Datapump來(lái)重新做。

還有一個(gè)技巧就是如果刷新的表極大，先優(yōu)先查看物化視圖日志，如果沒(méi)有數(shù)據(jù)，心里就會(huì)踏實(shí)很多，哪怕刷新時(shí)出點(diǎn)小問(wèn)題，心里還是亮堂的。

問(wèn)題3：

在從源庫(kù)使用DAtapump導(dǎo)出數(shù)據(jù)的時(shí)候，竟然拋出了錯(cuò)誤，這對(duì)于依賴(lài)Datapump的遷移項(xiàng)目來(lái)說(shuō)，不能很好的使用Datapump會(huì)困難重重，下面是一個(gè)基本的導(dǎo)出方式，當(dāng)然在10g版本里面可能有點(diǎn)問(wèn)題，比如使用了并行，導(dǎo)出的時(shí)候就可能提示溢出而失敗。

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

問(wèn)題4：

這個(gè)問(wèn)題是在數(shù)據(jù)庫(kù)做了主備切換之后碰到的，看日志可以得知是歸檔的問(wèn)題，但是實(shí)際上閃回區(qū)也足夠，歸檔路徑也是有效的。

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

初步分析發(fā)現(xiàn)是歸檔路徑的不規(guī)范，比如設(shè)置的歸檔路徑參數(shù)有多個(gè)，像log_archive_dest1,log_archive_dest2其實(shí)有不同的含義和用法，解決問(wèn)題的方法就是把這些路徑參數(shù)清空，重置DG Broker來(lái)初始化。見(jiàn)效快還一步到位。

問(wèn)題5：

DB link的問(wèn)題，說(shuō)實(shí)話DB link在多個(gè)數(shù)據(jù)庫(kù)間查取數(shù)據(jù)庫(kù)，有點(diǎn)蜘蛛網(wǎng)的感覺(jué)。我們可以使用tnsping的方式來(lái)驗(yàn)證tnsnames.ora的配置。但是如果端口通了，不一定證明tns的配置沒(méi)有問(wèn)題。

比如下面的報(bào)錯(cuò)信息，都是DB link的問(wèn)題，但是報(bào)錯(cuò)信息不同

  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

我們需要花一些時(shí)間來(lái)修復(fù)這類(lèi)問(wèn)題，排查的過(guò)程會(huì)因?yàn)樾畔⑻峁┑恼`差而偏離問(wèn)題的方向。我們需要冷靜一點(diǎn)，再細(xì)心一些。