[[221969]]

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

Oracle數(shù)據(jù)庫問題的一點總結(jié)

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

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

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

當然簡單確認問題，只是說數(shù)據(jù)同步有問題，面對各種可能性，只能讓日志告訴方向了。

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

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

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

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

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

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

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

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

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

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

這個時候查明白歸檔為什么會丟失相比修復問題，修復當前問題的優(yōu)先級要高得多，所以我簡單評估了這個問題。

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

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

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

首先是停掉備庫。

這個簡單的操作，竟然備庫hang住了，當然我提前看了下保護模式，這里是最大高可用模式，即可以在最大保護模式和最大性能之間來權(quán)衡，如果是最大保護模式，我就溴大了，因為這個操作會直接把主庫也干掉。

因為不斷的確認角色和狀態(tài)，所以這些也算是心中有數(shù)，因為要重做數(shù)據(jù)，所以直接shutdown abort也是可以的。

搭建備庫，用了duplicate的方式簡直就是酸爽。

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

duplicate target database for standby from active database nofilenamecheck;

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

看了下時間，從確認要開始這么做到完成，還不到一個小時，也算是按照預期完成了任務。

后面做了一些補充的檢查，把一些潛在的問題都修復了下，心里才算是踏實了一些。

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

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

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