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

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

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

“是好的，都同步好久了?！?/span>

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

“就在主庫(kù)新增了一些數(shù)據(jù)文件?！?/span>

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

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

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

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

環(huán)境介紹：

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

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

是否RAC：是

是否CDB：是

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

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

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

1、查看備庫(kù)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ù)開(kāi)始時(shí)看到的同一文件呢？繼續(xù)查看主備庫(kù)的數(shù)據(jù)文件差異。

主庫(kù)：

備庫(kù)：

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

3、數(shù)據(jù)文件為啥同步不過(guò)來(lái)？

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

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

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

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

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

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

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

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

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

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

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

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

9、注冊(cè)備份集信息

RMAN>catalog start with /OGG noprompt;

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

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

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

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

錯(cuò)誤路徑截圖：

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

主庫(kù)：

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

總結(jié)：

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