由於DG Broker的配置導致RAC某執行個體無法mount

由於DG Broker的配置導致RAC某執行個體無法mount

今天碰到一個我自己實驗室發生的故障，起初看起來很簡單，但實際上還很有趣，而且不細心的話還容易被忽視掉。相信在生產環境也會有客戶會實際遇到。

環境：Oracle 11.2.0.4 RAC （2 nodes Primary + 2 nodes Standby）
背景：起初這個實驗環境搭建好是沒有任何問題的。後期做過各類測試，其中包括主庫增加了新的儲存目錄，所以現在需要修改備庫的db_file_name_convert參數，添加對應各自的關係。

本來修改個參數沒太在意，當時重啟資料庫也是成功的，結果後來standby資料庫又一次重啟後，standby的兩個節點，其中一個節點啟動正常，另外一個節點居然起不來，報錯如下：

SQL> shutdown abortORACLE instance shut down.SQL> startupORACLE instance started.Total System Global Area  534462464 bytesFixed Size                  2254952 bytesVariable Size             444598168 bytesDatabase Buffers           83886080 bytesRedo Buffers                3723264 bytesORA-01105: mount is incompatible with mounts by other instancesORA-01677: standby file name convert parameters differ from other instance

報錯資訊非常明顯，就是說convert參數配置和其他執行個體不一致，檢查的確如此：
起不來的執行個體convert參數如下：

SQL> show parameter convertNAME                                 TYPE        VALUE------------------------------------ ----------- ------------------------------db_file_name_convert                 string      +data1/jyzhao, +data/mynaslog_file_name_convert                string      +data1/jyzhao, +data/mynas, +f                                                 ra1/jyzhao, +fra/mynas

正常啟動的執行個體convert參數如下：

SQL> show parameter convertNAME                                 TYPE        VALUE------------------------------------ ----------- ------------------------------db_file_name_convert                 string      +fra1/jyzhao, +fra/mynas, +dat                                                 a1/jyzhao, +data/mynaslog_file_name_convert                string      +data1/jyzhao, +data/mynas, +f                                                 ra1/jyzhao, +fra/mynas

很明顯，db_file_name_convert參數兩個執行個體的值不一致。

看到這裡，第一反應就是，看下兩邊參數檔案是不是一致？
答案是參數檔案內容完全一致，而且參數檔案對應的db_file_name_convert參數值是。

*.db_file_name_convert='+data1/jyzhao','+data/mynas'

這裡補充下背景：之前Standby RAC的參數值是 *.db_file_name_convert='+data1/jyzhao','+data/mynas'
後來修改過備庫的參數值：

SQL> alter system set db_file_name_convert = '+fra1/jyzhao', '+fra/mynas', '+data1/jyzhao', '+data/mynas' scope=spfile;

但是如今看來並沒有生效。難道是上次修改過程中有什麼疏忽的地方？
再次修改為正確的值測試：

SQL> alter system set db_file_name_convert = '+fra1/jyzhao', '+fra/mynas', '+data1/jyzhao', '+data/mynas' scope=spfile;System altered.SQL> shutdown abortORACLE instance shut down.SQL> startupORACLE instance started.Total System Global Area  534462464 bytesFixed Size                  2254952 bytesVariable Size             444598168 bytesDatabase Buffers           83886080 bytesRedo Buffers                3723264 bytesDatabase mounted.Database opened.SQL> SQL> show parameter convertNAME                                 TYPE        VALUE------------------------------------ ----------- ------------------------------db_file_name_convert                 string      +fra1/jyzhao, +fra/mynas, +dat                                                 a1/jyzhao, +data/mynaslog_file_name_convert                string      +data1/jyzhao, +data/mynas, +f                                                 ra1/jyzhao, +fra/mynas

可以看到，再次修改後，這個執行個體可以正常啟動了，參數值也顯示正確了。
那上次是什麼情況？再次關閉執行個體後重啟，發現問題重現：

SQL> SQL> SQL> shutdown abortORACLE instance shut down.SQL> startupORACLE instance started.Total System Global Area  534462464 bytesFixed Size                  2254952 bytesVariable Size             444598168 bytesDatabase Buffers           83886080 bytesRedo Buffers                3723264 bytesORA-01105: mount is incompatible with mounts by other instancesORA-01677: standby file name convert parameters differ from other instanceSQL> show parameter convertNAME                                 TYPE        VALUE------------------------------------ ----------- ------------------------------db_file_name_convert                 string      +data1/jyzhao, +data/mynaslog_file_name_convert                string      +data1/jyzhao, +data/mynas, +f                                                 ra1/jyzhao, +fra/mynasSQL> select status from v$instance;STATUS------------STARTED                                              

最後在資料庫的alert中找到了蛛絲馬跡，就是手工修改參數後，啟動資料庫成功後，又顯示自動被修改為原值。

Wed Jan 03 05:47:06 2018Starting Data Guard Broker (DMON)Wed Jan 03 05:47:06 2018INSV started with pid=41, OS id=26314Physical standby database opened for read only access.Completed: ALTER DATABASE OPENWed Jan 03 05:47:10 2018NSV0 started with pid=42, OS id=26321Wed Jan 03 05:47:14 2018RSM0 started with pid=43, OS id=26331 Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DESTALTER SYSTEM SET log_archive_trace=0 SCOPE=BOTH SID='jyzhao1';ALTER SYSTEM SET log_archive_format='%t_%s_%r.dbf' SCOPE=SPFILE SID='jyzhao1';ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH SID='*';ALTER SYSTEM SET archive_lag_target=0 SCOPE=BOTH SID='*';ALTER SYSTEM SET log_archive_max_processes=4 SCOPE=BOTH SID='*';ALTER SYSTEM SET log_archive_min_succeed_dest=1 SCOPE=BOTH SID='*';ALTER SYSTEM SET db_file_name_convert='+data1/jyzhao','+data/mynas' SCOPE=SPFILE;ALTER SYSTEM SET log_file_name_convert='+data1/jyzhao','+data/mynas','+fra1/jyzhao','+fra/mynas' SCOPE=SPFILE;ALTER SYSTEM SET fal_server='jyzhao' SCOPE=BOTH;Wed Jan 03 05:47:53 2018Decreasing number of real time LMS from 1 to 0

看到這裡，已經知道問題的答案了。
大家也可以思考下，這段alert說明了什嗎？

真相就是：
該DG環境曾經在類比某客戶真實情境做DG測試時，配置了DG Broker。而後續環境在各種變更後DG Broker的配置資訊卻沒有正常更新。

• Oracle RAC 11g DG Broker配置和測試

解決方案兩種：
一是刪除DG Broker的配置，不再使用，最簡單的就是設定dgbroker不啟動。
二是繼續使用DG Broker，但需要重新設定正確。

下面重新設定DG Broker，然後在主庫修改參數：
重新設定DG Broker可以直接參考上面的文章。

原值：

db_file_name_convert                 string      +data/mynas, +data1/jyzhao

主庫修改參數：

SQL> alter system set db_file_name_convert = '+data/mynas', '+data1/jyzhao', '+fra/mynas', '+fra1/jyzhao' scope=spfile;

備庫修改參數：

SQL> alter system set db_file_name_convert = '+fra1/jyzhao', '+fra/mynas', '+data1/jyzhao', '+data/mynas' scope=spfile;

還是不行：
Broker命令：

show database verbose jyzhao;show database verbose mynas;

更新broker中的配置（根本原因）：

edit database 'jyzhao' set property 'DbFileNameConvert'='+data/mynas, +data1/jyzhao, +fra/mynas, +fra1/jyzhao';edit database 'mynas' set property 'DbFileNameConvert'='+fra1/jyzhao, +fra/mynas, +data1/jyzhao, +data/mynas';

看來DG Broker的配置一定要和資料庫保持一致。

總結：做為一名合格的DBA心細很重要，各類常用工具也要熟悉，比如這裡的DG Broker。