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

創(chuàng)新互聯(lián)公司專注于企業(yè)成都營銷網(wǎng)站建設(shè)、網(wǎng)站重做改版、羅甸網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5場景定制、商城網(wǎng)站開發(fā)、集團公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)公司、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為羅甸等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

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

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

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

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

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

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

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

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

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

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

問題1：

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

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：

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

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

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

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

問題3：

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

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

問題4：

這個問題是在數(shù)據(jù)庫做了主備切換之后碰到的，看日志可以得知是歸檔的問題，但是實際上閃回區(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ù)有多個，像log_archive_dest1,log_archive_dest2其實有不同的含義和用法，解決問題的方法就是把這些路徑參數(shù)清空，重置DG Broker來初始化。見效快還一步到位。

問題5：

DB link的問題，說實話DB link在多個數(shù)據(jù)庫間查取數(shù)據(jù)庫，有點蜘蛛網(wǎng)的感覺。我們可以使用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

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

分享標題：數(shù)據(jù)遷移中的幾個問題總結(jié)
標題路徑：http://m.newbst.com/article48/gdeehp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、品牌網(wǎng)站設(shè)計、靜態(tài)網(wǎng)站、網(wǎng)站建設(shè)、企業(yè)網(wǎng)站制作、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)