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

成都創(chuàng)新互聯(lián)公司長(zhǎng)期為上千家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開(kāi)放共贏平臺(tái)，與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為青羊企業(yè)提供專業(yè)的成都網(wǎng)站制作、成都做網(wǎng)站、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)，青羊網(wǎng)站改版等技術(shù)服務(wù)。擁有十年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開(kāi)發(fā)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

首先是停掉備庫(kù)。

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

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

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

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

duplicate target database for standby from active database nofilenamecheck;

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

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

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

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

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

總之，快速解決了問(wèn)題，你就是專家，否則，任何解釋都沒(méi)有用。