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

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

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

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

遷移部分核心業(yè)務(wù)從Solaris到X86平臺，同時(shí)需要升級數(shù)據(jù)庫版本
遷移x86平臺的部分核心業(yè)務(wù)，這個(gè)方向操作相對簡單，基本就是主備切換
整合部分X86平臺的環(huán)境，比如數(shù)據(jù)庫a,b整合后就是一個(gè)數(shù)據(jù)庫a

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

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

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

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

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

我拿出幾個(gè)遷移中碰到的問題，很多還是很有代表性，也是我們做技術(shù)方案的時(shí)候需要不斷改進(jì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
問題2：

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

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

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

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

問題3：

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

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

問題4：

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

問題5：

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

比如下面的報(bào)錯(cuò)信息，都是DB link的問題，但是報(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í)間來修復(fù)這類問題，排查的過程會(huì)因?yàn)樾畔⑻峁┑恼`差而偏離問題的方向。我們需要冷靜一點(diǎn)，再細(xì)心一些。

分享標(biāo)題：數(shù)據(jù)遷移中的幾個(gè)問題總結(jié)
標(biāo)題路徑：http://muchs.cn/article48/gdeehp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、品牌網(wǎng)站設(shè)計(jì)、靜態(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)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容