親愛滴伙伴們，大家好。上篇講了一起ADG主備切換異常的故障處理，最近又遇到一個(gè)ADG的問題，做下分享。事情是這樣的，一哥們急急忙忙的跑過來說：

“魏大濕，我手上的ADG實(shí)時(shí)同步死活開不起來！”

“之前實(shí)時(shí)同步是好的么？”

“是好的，都同步好久了。”

“那實(shí)時(shí)同步起不來之前你做了啥操作沒？”

“就在主庫新增了一些數(shù)據(jù)文件。”

“那之前在主庫新增數(shù)據(jù)文件的時(shí)候是正常的，是吧！”

“是的，之前是好的，就這次新增數(shù)據(jù)文件就成這樣了?！?/span>

......   ......  ......

通過溝通了解到，之前這套庫做過主備切換，已經(jīng)實(shí)時(shí)同步一段時(shí)間了，主庫在新增數(shù)據(jù)文件之后，備庫的實(shí)時(shí)同步就關(guān)閉了，并且新增數(shù)據(jù)文件在備庫沒有創(chuàng)建。手動(dòng)開啟實(shí)時(shí)同步也無法開啟。

環(huán)境介紹：

操作系統(tǒng)：Redhat7.6

數(shù)據(jù)庫版本：19.7

是否RAC：是

是否CDB：是

ASM或文件系統(tǒng)：ASM

ADG主備庫節(jié)點(diǎn)數(shù)：均為2個(gè)

注：之前做過主備切換，racdbstd為當(dāng)前主庫，racdb為當(dāng)前備庫。

1、查看備庫dbalert日志發(fā)現(xiàn)報(bào)ORA-01193:file 26 is not the same file seen at start of recovery。

2、為啥會(huì)報(bào)文件26不是恢復(fù)開始時(shí)看到的同一文件呢？繼續(xù)查看主備庫的數(shù)據(jù)文件差異。

主庫：

備庫：

從上圖我們可以看到主庫比備庫多了3個(gè)新增的數(shù)據(jù)文件。初步判斷那個(gè)26號(hào)文件報(bào)錯(cuò)只是表象，真正原因是3個(gè)新增數(shù)據(jù)文件同步不過來導(dǎo)致。

3、數(shù)據(jù)文件為啥同步不過來？

新增數(shù)據(jù)文件主備庫同步涉及轉(zhuǎn)換，一般跟db_file_name_convert參數(shù)有關(guān)系，但疑點(diǎn)是就算db_file_name_convert參數(shù)設(shè)置有問題，也只是備庫這邊創(chuàng)建的新增數(shù)據(jù)文件路徑不對(duì)而已，備庫不會(huì)不創(chuàng)建數(shù)據(jù)文件。

主備庫db_file_name_convert參數(shù)核查正常：

嘗試再次開啟實(shí)時(shí)同步發(fā)現(xiàn)mrp進(jìn)程沒有啟動(dòng)，dbalert日志依舊報(bào)ORA-01193:file 26 is not the same file seen at start of recovery。

開啟實(shí)時(shí)同步顯示成功：

查看v$managed_standby發(fā)現(xiàn)備庫接受主庫的redo信息正常，但同步進(jìn)程(MRP)沒有啟動(dòng)

備庫Dbalert日志依舊報(bào)錯(cuò)

4、在確認(rèn)數(shù)據(jù)庫參數(shù)及其他tns等配置均正常的情況下，懷疑觸發(fā)BUG。在MOS上搜了一把，12C之前有ORA-01193報(bào)錯(cuò)的BUG，但沒有發(fā)現(xiàn)19C類似報(bào)錯(cuò)的文章，而且12C及之前的BUG現(xiàn)象不一致。好吧，既然新建數(shù)據(jù)文件無法自動(dòng)同步過來，那我們還是使用基于scn增量備份恢復(fù)的方式把故障解決了。

5、查看當(dāng)前備庫的SCN。

在主庫創(chuàng)建standbycontrolfile，并基于備庫查詢的SCN在主庫做增量備份。

6、將主庫創(chuàng)建的standbycontrolfile及增量備份集傳至備庫，記錄備庫當(dāng)前數(shù)據(jù)文件的路徑以便重建備庫控制文件后rename數(shù)據(jù)文件，并將standby_file_management設(shè)置為manual。具體的上篇介紹過了，這里就不細(xì)說了。

7、將備庫實(shí)例shutdown并啟動(dòng)至nomount，重建控制文件后mount。并rename備庫原有數(shù)據(jù)文件路徑。

8、查看備庫數(shù)據(jù)文件路徑發(fā)現(xiàn)只有新增數(shù)據(jù)文件路徑是異常的。

9、注冊備份集信息

RMAN>catalog start with /OGG noprompt;

10、由于新增數(shù)據(jù)文件41、42及43在備庫不存在，需要先restore，如果直接recover會(huì)報(bào)錯(cuò)。

11、restore出來的數(shù)據(jù)文件并不是控制文件中的路徑，在主庫對(duì)應(yīng)的目錄，我們需要asmcmd進(jìn)入ASM中把文件詳細(xì)路徑找出來，然后做rename。

12、再次查看備庫控制文件中的數(shù)據(jù)文件路徑，確認(rèn)恢復(fù)正常后，開始recover。

13、恢復(fù)完成后，將數(shù)據(jù)庫啟動(dòng)至open，并開啟實(shí)時(shí)同步成功。注意：在recover之后，mount狀態(tài)下，redofile、standbyredofile及tempfile文件路徑均是不正確的，但不需要額外處理，只要將數(shù)據(jù)庫啟動(dòng)至open，數(shù)據(jù)庫會(huì)自動(dòng)將其修改成正確路徑。另外如果發(fā)現(xiàn)其他節(jié)點(diǎn)的standbyredo file路徑錯(cuò)誤的時(shí)候，只要在路徑錯(cuò)誤的節(jié)點(diǎn)開啟實(shí)時(shí)同步就自動(dòng)恢復(fù)正常。

錯(cuò)誤路徑截圖：

14、在主庫新增表空間之后發(fā)現(xiàn)備庫此時(shí)可正常同步了。

主庫：

備庫查詢到新增test表空間已創(chuàng)建：

總結(jié)：

問題很詭異，在配置均正常的情況下，新增數(shù)據(jù)文件在備庫沒有創(chuàng)建，且實(shí)時(shí)同步失敗。MOS也查不到相關(guān)信息，疑似觸發(fā)BUG。在沒有workroud的前提下，這種ADG同步的系列故障，均可通過scn增量恢復(fù)大法解決，盡量避免備庫重建費(fèi)時(shí)費(fèi)力的工作。