datagaurd是oracle 数据库常用的容灾保护方案,但standby不再需要或删除后,在primary 需要清理之前的配置,通常认为很容易,比如禁用日志传输,no force logging, 清理log_archive _destn \log_archive_config相关的参数等。是否很容易? 但里面隐藏着一个风险。上周一客户遇到个案例,主库oracle rac 11.2.0.4原来有dataguard,但是清理后,直到有1个节点重启后实例无法启动,简单记录。
db alert log
tue jul 25 22:27:41 2023 errors in file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_m000_58781.trc (incident=296583): ora-01578: oracle data block corrupted (file # 403, block # 2) ora-01110: data file 403: ' datavg/anbob/tempfile/temp2.dbf' tue jul 25 22:27:41 2023 sweep [inc][296583]: completed tue jul 25 22:37:41 2023 errors in file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_m000_64973.trc (incident=296584): ora-01578: oracle data block corrupted (file # 403, block # 2) ora-01110: data file 403: ' datavg/anbob/tempfile/temp2.dbf' tue jul 25 22:37:43 2023 sweep [inc][296584]: completed tue jul 25 22:48:18 2023 ipc send timeout detected. receiver ospid 25486 [ tue jul 25 22:48:18 2023 errors in file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_lms2_25486.trc: ipc send timeout detected. receiver ospid 25478 [ tue jul 25 22:48:18 2023 errors in file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_lms0_25478.trc: ipc send timeout detected. receiver ospid 25490 [ tue jul 25 22:48:19 2023 ... errors in file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_lms2_25486.trc: ipc send timeout detected. receiver ospid 25482 [ errors in file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_lms1_25482.trc: ipc send timeout detected. receiver ospid 25486 [ errors in file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_lms2_25486.trc: ipc send timeout detected. receiver ospid 25486 [ errors in file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_lms2_25486.trc: tue jul 25 22:48:53 2023 ipc send timeout detected. receiver ospid 25482 [ tue jul 25 22:48:53 2023 errors in file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_lms1_25482.trc: tue jul 25 22:49:07 2023 detected an inconsistent instance membership by instance 1 tue jul 25 22:49:08 2023 received an instance abort message from instance 1 please check instance 1 alert and lmon trace files for detail. lmd0 (ospid: 25476): terminating the instance due to error 481 tue jul 25 22:49:08 2023 system state dump requested by (instance=2, osid=25476 (lmd0)), summary=[abnormal instance termination]. system state dumped to trace file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_diag_25464_20230725224908.trc tue jul 25 22:49:09 2023 ora-1092 : opitsk aborting process tue jul 25 22:49:09 2023 license high water mark = 1404 instance terminated by lmd0, pid = 25476 user (ospid: 8175): terminating the instance instance terminated by user, pid = 8175 wed jul 26 22:14:00 2023 adjusting the default value of parameter parallel_max_servers from 2560 to 1970 due to the value of parameter processes (2000) starting oracle instance (normal) ... ... arc3 started with pid=47, os id=11845 arc1: archival started arc2: archival started arc1: becoming the 'no fal' arch arc1: becoming the 'no srl' arch arc2: becoming the heartbeat arch warning: the 'log_archive_config' init.ora parameter settings are inconsistent with another started instance. this may be caused by the 'db_unique_name' init.ora parameter being specified differently on one or more of the other rac instances; thedb_unique_name parameter value must be identical for allinstances of the database. errors in file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_lgwr_11631.trc: ora-16188: log_archive_config settings inconsistent with previously started instance lgwr (ospid: 11631): terminating the instance due to error 16188 wed jul 26 23:06:28 2023 system state dump requested by (instance=2, osid=11631 (lgwr)), summary=[abnormal instance termination]. system state dumped to trace file /u01/app/oracle/diag/rdbms/anbob/anbob2/trace/anbob2_diag_11578_20230726230628.trc dumping diagnostic data in directory=[cdmp_20230726230628], requested by (instance=2, osid=11631 (lgwr)), summary=[abnormal instance termination]. instance terminated by lgwr, pid = 11631
note:
这里实际有3个问题我用三种颜色表示, 绿色是tempfile发现了坏块, 橙色是rac 节点间出现ipc通信错误, 红色是实例异常crash,crs自动拉起后启动失败,提示ora-16188: log_archive_config 节点间参数不一致。 前两个问题不在本篇的描述范围,关键是ora-16188, 想起了前不久《》那个故障,也是两个实例间不兼容无法启动,当时还排查过这个参数。接下来分析看一下当前参数
log_archive_config参数
sql> show parameter pfile name type value ------------------------------------ ----------- ------------------------------ spfile string datavg/anbob/spfileanbob.ora sql> show parameter config name type value ------------------------------------ ----------- ------------------------------ dg_broker_config_file1 string /u01/app/oracle/product/11.2.0/db_1/dbs/dr1anbob.dat dg_broker_config_file2 string /u01/app/oracle/product/11.2.0/db_1/dbs/dr2anbob.dat log_archive_config string
note:
对比了rac所有实例使用的是同一 spfile, 另一存活实例参数与spfile参数相同,都是null 或”, 通过create pfile能发现有*.log_archive_config=” 的配置。
ora-16188
log_archive_config settings are inconsistent with the previously started instance. cause the settings for the log_archive_config parameter were inconsistent with the settings of a previously started instance. the settings for this parameter must be exactly the same for all instances. action ensure that all instances use the exact same log_archive_config settings.
note:
这里给oracle做个宣传,oracle已悄悄上线了error-help功能, 该功能确实早就应该有,在线可以查询错误编码,增加到google浏览器的自定义搜索引擎,可以快速的搜索错误代码,有些内容比oerr程序 提示更加丰富。页面如
也许你从网上能搜到或standby instance crash or failed to startup with ora-16188 (doc id 1580482.1) ,对于standby启动相关的错误的解决方法 cause: setting log_archive_config to null in rac standby database and startup of node 2 fails with ora-16188. alter system set log_archive_config=” scope=both sid=’*’ solution: this is due to v$dataguard_config not updated between instances. to fix this do the below in any one of the nodes. alter system set log_archive_config=nodg_config scope=both sid=’*’; and retry the standby setup.
上面这种修改为”的方式,可能会导致实例v$dataguard_config 可能没有及时更新,提示参数不一致,似乎是个bug, 从oracle 12c已经修复了该问题, 这之前可能更新值为nodg_config, 我们在幸存的节点修改参数.
sql> alter system set log_archive_config=nodg_config scope=both sid='*'; alter system set log_archive_config=nodg_config scope=both sid='*' * error at line 1: ora-02097: parameter cannot be modified because specified value is invalid ora-16135: invalid log_archive_config modification while in protected mode
note:
注意这里提示修改的值是无效值,无语,既然开始提示2实例参数不一致,那重启幸存实例肯定就可以解决了吧? 这里因为时间紧急,客户反馈可以重启幸存节点,但如果重启就尽快因为20分钟后有批处理作业。于是决定重启, 至于这个nodg_config值是无效值,这里其实忽略了一个问题.
重启幸存实例
-- 备份了一个spfile sql> alter system reset log_archive_config scope=spfile; system altered. sql> shut immediate sql> startup oracle instance started. total system global area 2.2448e 11 bytes fixed size 2266664 bytes variable size 3.4897e 10 bytes database buffers 1.8952e 11 bytes redo buffers 64827392 bytes database mounted. ora-03113: end-of-file on communication channel process id: 26774 session id: 2065 serial number: 3
note:
重启以后坏了,一个也无法启动了,查看db alert log
db alert log
lost write protection disabled
completed: alter database mount /* db agent *//* {0:7:13143} */
alter database open /* db agent *//* {0:7:13143} */
this instance was first to open
picked broadcast on commit scheme to generate scns
lgwr: starting arch processes
wed jul 26 23:39:09 2023
arc0 started with pid=44, os id=27434
wed jul 26 23:39:10 2023
arc0: archival started
lgwr: starting arch processes complete
arc0: starting arch processes
lgwr: primary database is in maximum availability mode
lgwr: destination log_archive_dest_1 is not serviced by lgwr
lgwr: minimum of 1 lgwr standby database required
errors in file /u01/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_lgwr_27288.trc:
ora-16072: a minimum of one standby database destination is required
wed jul 26 23:39:10 2023
arc1 started with pid=45, os id=27436
lgwr (ospid: 27288): terminating the instance due to error 16072
wed jul 26 23:39:10 2023
system state dump requested by (instance=1, osid=27288 (lgwr)), summary=[abnormal instance te
system state dumped to trace file /u01/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_diag_2
dumping diagnostic data in directory=[cdmp_20230726233910], requested by (instance=1, osid=27
instance terminated by lgwr, pid = 27288
note:
注意这里的提示已经很明确,主库目前是最大可用模式,至少需要1个standby, 而我们这个库已经清理了所有的standby ,只是之前一直未重启过, 所以这个雷留到了现在。 知道原因解决就容易了。不过我们再回看上面提示nodg_config报错时提到的:
ora-02097: parameter cannot be modified because specified value is invalid
ora-16135: invalid log_archive_config modification while in protected mode
ora-16135
cause: the log_archive_config parameter can not be modified while any rac instance is open in either maximum protection or maximum availability mode. also, the parameter can not be modified in such way that would cause all destinations to fail while in maximum protection mode.
action: make the modification before the database is opened by any instance.
这个错误时忽略了检查一下原来database 的保护模式. 以后禁用dg或清理参数前记的检查, 既然一个dg standby都没有,也只能重启所有节点,切到最大性能模式。
select database_name,database_role,force_logging,protection_mode from v$database;
修改保护模式
sql> startup mount oracle instance started. total system global area 2.2448e 11 bytes fixed size 2266664 bytes variable size 3.4897e 10 bytes database buffers 1.8952e 11 bytes redo buffers 64827392 bytes database mounted. sql> alter database set standby to maximize performance; database altered. sql> alter database open; database altered.
summary:
当清理或删除standby时,在主库需要检查当前的保护模式,如最大可用和最大保护模式至少要有1 standby, 在12c之前rac 修改log_archive_config参数记的使用nodg_config而不是”,否则可能会出现后期实例重启无法启动的风险。