Oracle數(shù)據(jù)不同步的問題分析和解決思路

其實(shí)幫助很多的朋友解決過Oracle數(shù)據(jù)庫數(shù)據(jù)不同步的問題，看似簡(jiǎn)單的問題分析出來的原因也是五花八門。比如：

Oracle數(shù)據(jù)庫問題的一點(diǎn)總結(jié) 在查看一些沒有專業(yè)DBA維護(hù)的數(shù)據(jù)庫的時(shí)候，會(huì)發(fā)現(xiàn)很多的潛在問題，有些可能無傷大雅，看起來是不規(guī)范不標(biāo)準(zhǔn)的問題，倒不會(huì)直接造成問題，而有些問題會(huì)讓人后背發(fā)涼，正如同歌詞里唱的，一旦錯(cuò)過就不再，這里說的就是數(shù)據(jù)，所以也希望大家能夠在一些案例中得到啟發(fā)和參考，避免在自己的系統(tǒng)中重演。

先啰嗦一句，盡管在Oracle命令行下敲過命令了，但是完整的命令和思路還算清晰，所以大家在平時(shí)的工作里面要打好基礎(chǔ)，別被圖形工具和高大上的工具綁架，出問題的時(shí)候，能夠拿起手里的瑞士軍刀才是真道理。

這次幫朋友看的問題，現(xiàn)象還是老三樣，數(shù)據(jù)不同步，無法登陸，無法啟動(dòng)中的數(shù)據(jù)不同步。這類問題的愿意確實(shí)很多，可能是系統(tǒng)級(jí)的空間不足，或者是閃回區(qū)的空間不足，表空間不足等等。

當(dāng)然簡(jiǎn)單確認(rèn)問題，只是說數(shù)據(jù)同步有問題，面對(duì)各種可能性，只能讓日志告訴方向了。

這是一個(gè)一主一備的環(huán)境，11gR2的版本，開啟了ADG，快速查看了主庫，發(fā)現(xiàn)業(yè)務(wù)處理是正常的，而且查看數(shù)據(jù)庫日志也沒有發(fā)現(xiàn)什么和空間相關(guān)的錯(cuò)誤信息。所以很快主庫的系統(tǒng)級(jí)，表空間的可能性排除了。

那么可能是備庫端的空間或者邏輯空間溢出，所以登錄到從庫確認(rèn)，發(fā)現(xiàn)是閃回去溢出了。

Oracle的閃回區(qū)其實(shí)有些糾結(jié)，在很多情況下，備庫的閃回區(qū)沒有自動(dòng)回收，結(jié)果就慢慢溢出，導(dǎo)致了很多的嚴(yán)重問題，這個(gè)庫就是如此，問題拖了一段時(shí)間，導(dǎo)致已經(jīng)超出了控制文件的保留周期。

而且詭異的是似乎主備庫的網(wǎng)絡(luò)也有了一點(diǎn)變動(dòng)，讓這個(gè)問題更加雪上加霜。

面對(duì)這種情況，該如何處理呢，一種直接的方案就是刪除閃回區(qū)中的冗余歸檔文件，或者調(diào)大閃回區(qū)，保險(xiǎn)起見，如果空間還足夠，是建議調(diào)大閃回區(qū)的，如果有些數(shù)據(jù)還沒有同步過去，我們刪除了之后，就很被動(dòng)了。

當(dāng)然我調(diào)大了閃回區(qū)之后，發(fā)現(xiàn)出現(xiàn)了新的問題，原來歸檔斷了，比如歸檔的序列號(hào)是從7000-10000，如果歸檔好7213丟失了，那么7213后續(xù)的歸檔文件都無法直接應(yīng)用，而如果我們更是雪上加上刪除了沒有應(yīng)用的歸檔文件，就麻煩了。

所以我?guī)е鴥e幸的心理對(duì)比了主庫和備庫的在斷點(diǎn)時(shí)間范圍的歸檔日志情況，發(fā)現(xiàn)主庫上竟然有這幾個(gè)歸檔文件，那么我就可以直接拷貝到備庫端了，但是這個(gè)過程是無法觸發(fā)自動(dòng)應(yīng)用的，因?yàn)橹鱾鋷斓臍w檔日志命名格式不同。

比如主庫是1_7213_8980808sa.dbf 而備庫是 1_7213_20180308_89131231.dbf這種情況下，我們就需要手工應(yīng)用日志了。

alter database register logfile 'xxxxx/xxx.dbf' ;

正讓我竊喜的時(shí)候，我發(fā)現(xiàn)問題原來比我想的還要糟糕，盡管這個(gè)斷點(diǎn)問題修復(fù)了，但是后續(xù)又發(fā)現(xiàn)了一系列問題，有大量的歸檔文件依舊丟失。

這個(gè)時(shí)候查明白歸檔為什么會(huì)丟失相比修復(fù)問題，修復(fù)當(dāng)前問題的優(yōu)先級(jí)要高得多，所以我簡(jiǎn)單評(píng)估了這個(gè)問題。

目前遺漏的歸檔文件有上千個(gè)，除非我寫一個(gè)自動(dòng)化腳本來自動(dòng)拷貝，自動(dòng)化應(yīng)用歸檔日志文件，讓這個(gè)腳本看起來足夠強(qiáng)大，加上調(diào)試少說也有1個(gè)小時(shí)。

而如果做一個(gè)減法，我們直接重新搭建備庫，整個(gè)過程就更加平滑了。

我根據(jù)數(shù)據(jù)量做了一個(gè)評(píng)估，保證帶寬的情況下，在一個(gè)小時(shí)內(nèi)應(yīng)該可以搞定，所以確認(rèn)好實(shí)施步驟，就開始操作了。

首先是停掉備庫。

這個(gè)簡(jiǎn)單的操作，竟然備庫hang住了，當(dāng)然我提前看了下保護(hù)模式，這里是最大高可用模式，即可以在最大保護(hù)模式和最大性能之間來權(quán)衡，如果是最大保護(hù)模式，我就溴大了，因?yàn)檫@個(gè)操作會(huì)直接把主庫也干掉。

因?yàn)椴粩嗟拇_認(rèn)角色和狀態(tài)，所以這些也算是心中有數(shù)，因?yàn)橐刈鰯?shù)據(jù)，所以直接shutdown abort也是可以的。

搭建備庫，用了duplicate的方式簡(jiǎn)直就是酸爽。

rman target sys/xxxx@test01auxiliary sys/xxx@test02 nocatalog

duplicate target database for standby from active database nofilenamecheck;

整個(gè)過程還算順利，在配置主備關(guān)系的時(shí)候，我依舊適用了我的老朋友DG Broker,簡(jiǎn)單的幾個(gè)命令就可以讓Data Guard正常跑起來。

看了下時(shí)間，從確認(rèn)要開始這么做到完成，還不到一個(gè)小時(shí)，也算是按照預(yù)期完成了任務(wù)。

后面做了一些補(bǔ)充的檢查，把一些潛在的問題都修復(fù)了下，心里才算是踏實(shí)了一些。

這個(gè)案例看起來思路也很簡(jiǎn)單，但是實(shí)際操作的過程中，面對(duì)的是一個(gè)交易系統(tǒng)，更多的是考慮如果盡快修復(fù)數(shù)據(jù)，不能對(duì)已有的業(yè)務(wù)流程造成影響，或者倒霉的觸發(fā)bug導(dǎo)致數(shù)據(jù)庫故障，就得不償失了。

而處理問題的時(shí)候，也是穩(wěn)中求穩(wěn)，比如如果我面對(duì)丟失歸檔的數(shù)據(jù)庫回復(fù)，其實(shí)也可以考慮使用增量備份來恢復(fù)等方案，但是從簡(jiǎn)單清晰的思路來入手，重新搭建是最穩(wěn)定，思路也是最清晰的，如果增量恢復(fù)出現(xiàn)問題，或者增量備份有任何問題，要承受的壓力都是相當(dāng)大的。

總之，快速解決了問題，你就是專家，否則，任何解釋都沒有用。