Oracle資料不同步的問題分析和解決思路

其實幫助很多的朋友解決過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導致資料庫故障，就得不償失了。

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

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