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

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

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

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

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

這是一個一主一備的環境，11gR2的版本，開啟了ADG，快速查看了主庫，發現業務處理是正常的，而且查看數據庫日志也沒有發現什么和空間相關的錯誤信息。所以很快主庫的系統級，表空間的可能性排除了。

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

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

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

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

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

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

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

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

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

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

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

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

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

首先是停掉備庫。

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

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

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

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

duplicate target database for standby from active database nofilenamecheck;

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

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

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

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

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

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