共计 5009 个字符，预计需要花费 13 分钟才能阅读完成。
今天碰到一个我自己实验室发生的故障，起初看起来很简单，但实际上还很有趣，而且不细心的话还容易被忽视掉。相信在生产环境也会有客户会实际遇到。
环境：Oracle 11.2.0.4 RAC（2 nodes Primary + 2 nodes Standby）
背景：起初这个实验环境搭建好是没有任何问题的。后期做过各类测试，其中包括主库增加了新的存储目录，所以现在需要修改备库的 db_file_name_convert 参数，添加对应各自的关系。
本来修改个参数没太在意，当时重启数据库也是成功的，结果后来 standby 数据库又一次重启后，standby 的两个节点，其中一个节点启动正常，另外一个节点居然起不来，报错如下：
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 534462464 bytes
Fixed Size 2254952 bytes
Variable Size 444598168 bytes
Database Buffers 83886080 bytes
Redo Buffers 3723264 bytes
ORA-01105: mount is incompatible with mounts by other instances
ORA-01677: standby file name convert parameters differ from other instance 报错信息非常明显，就是说 convert 参数配置和其他实例不一致，检查的确如此：
起不来的实例 convert 参数如下：
SQL> show parameter convert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string +data1/jyzhao, +data/mynas
log_file_name_convert string +data1/jyzhao, +data/mynas, +f
ra1/jyzhao, +fra/mynas正常启动的实例 convert 参数如下：
SQL> show parameter convert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string +fra1/jyzhao, +fra/mynas, +dat
a1/jyzhao, +data/mynas
log_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 abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 534462464 bytes
Fixed Size 2254952 bytes
Variable Size 444598168 bytes
Database Buffers 83886080 bytes
Redo Buffers 3723264 bytes
Database mounted.
Database opened.
SQL>
SQL> show parameter convert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string +fra1/jyzhao, +fra/mynas, +dat
a1/jyzhao, +data/mynas
log_file_name_convert string +data1/jyzhao, +data/mynas, +f
ra1/jyzhao, +fra/mynas
可以看到，再次修改后，这个实例可以正常启动了，参数值也显示正确了。
那上次是什么情况？再次关闭实例后重启，发现问题重现：
SQL>
SQL>
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 534462464 bytes
Fixed Size 2254952 bytes
Variable Size 444598168 bytes
Database Buffers 83886080 bytes
Redo Buffers 3723264 bytes
ORA-01105: mount is incompatible with mounts by other instances
ORA-01677: standby file name convert parameters differ from other instance
SQL> show parameter convert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string +data1/jyzhao, +data/mynas
log_file_name_convert string +data1/jyzhao, +data/mynas, +f
ra1/jyzhao, +fra/mynas
SQL> select status from v$instance;
STATUS
------------
STARTED 最后在数据库的 alert 中找到了蛛丝马迹，就是手工修改参数后，启动数据库成功后，又显示自动被修改为原值。
Wed Jan 03 05:47:06 2018
Starting Data Guard Broker (DMON)
Wed Jan 03 05:47:06 2018
INSV started with pid=41, OS id=26314
Physical standby database opened for read only access.
Completed: ALTER DATABASE OPEN
Wed Jan 03 05:47:10 2018
NSV0 started with pid=42, OS id=26321
Wed Jan 03 05:47:14 2018
RSM0 started with pid=43, OS id=26331
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
ALTER 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 2018
Decreasing 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。
更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2018-01/150161.htm
