前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >由于DG Broker的配置导致RAC某实例无法mount

由于DG Broker的配置导致RAC某实例无法mount

作者头像
Alfred Zhao
发布2019-05-24 20:16:11
7190
发布2019-05-24 20:16:11
举报

今天碰到一个我自己实验室发生的故障,起初看起来很简单,但实际上还很有趣,而且不细心的话还容易被忽视掉。相信在生产环境也会有客户会实际遇到。

环境:Oracle 11.2.0.4 RAC (2 nodes Primary + 2 nodes Standby) 背景:起初这个实验环境搭建好是没有任何问题的。后期做过各类测试,其中包括主库增加了新的存储目录,所以现在需要修改备库的db_file_name_convert参数,添加对应各自的关系。

本来修改个参数没太在意,当时重启数据库也是成功的,结果后来standby数据库又一次重启后,standby的两个节点,其中一个节点启动正常,另外一个节点居然起不来,报错如下:

代码语言:javascript
复制
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参数如下:

代码语言:javascript
复制
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参数如下:

代码语言:javascript
复制
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参数值是。

代码语言:javascript
复制
*.db_file_name_convert='+data1/jyzhao','+data/mynas'

这里补充下背景:之前Standby RAC的参数值是 *.db_file_name_convert='+data1/jyzhao','+data/mynas' 后来修改过备库的参数值:

代码语言:javascript
复制
SQL> alter system set db_file_name_convert = '+fra1/jyzhao', '+fra/mynas', '+data1/jyzhao', '+data/mynas' scope=spfile;

但是如今看来并没有生效。难道是上次修改过程中有什么疏忽的地方? 再次修改为正确的值测试:

代码语言:javascript
复制
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

可以看到,再次修改后,这个实例可以正常启动了,参数值也显示正确了。 那上次是什么情况?再次关闭实例后重启,发现问题重现:

代码语言:javascript
复制
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中找到了蛛丝马迹,就是手工修改参数后,启动数据库成功后,又显示自动被修改为原值。

代码语言:javascript
复制
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的配置信息却没有正常更新。

解决方案两种: 一是删除DG Broker的配置,不再使用,最简单的就是设置dgbroker不启动。 二是继续使用DG Broker,但需要重新配置正确。

下面重新配置DG Broker,然后在主库修改参数: 重新配置DG Broker可以直接参考上面的文章。

原值:

代码语言:javascript
复制
db_file_name_convert                 string      +data/mynas, +data1/jyzhao

主库修改参数:

代码语言:javascript
复制
SQL> alter system set db_file_name_convert = '+data/mynas', '+data1/jyzhao', '+fra/mynas', '+fra1/jyzhao' scope=spfile;

备库修改参数:

代码语言:javascript
复制
SQL> alter system set db_file_name_convert = '+fra1/jyzhao', '+fra/mynas', '+data1/jyzhao', '+data/mynas' scope=spfile;

还是不行: Broker命令:

代码语言:javascript
复制
show database verbose jyzhao;
show database verbose mynas;

更新broker中的配置(根本原因):

代码语言:javascript
复制
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。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2018-01-04 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档