ORACLE 11G ACTIVE DATA GUARD是基于ORACLE 11G数据库的一种成熟可靠的HA解决方案，在特定情况下，ACTIVE DATA GUARD支持进行主库、备库角色切换（SWITCHOVER）。但在实际生产环境中，尤其是主库承担重要的业务应用时，客户并不敢轻易地实施SWITCHOVER，即便仅仅一次应急演练。在实际运维中，我们也碰到过不少因ACTIVE DATA GUARD环境搭建不严谨，造成SWITCHOVER失败；更严重的是SWITCHOVER导致出现各类ORA-XXX错误出现，造成数据库实例CRASH，甚至无法正常启动。为防患于未然，下面介绍ORACLE11G ACTIVE DATA GUARD安全SWITCHOVER需要关注的要点及实施方法。
1. 建议安装的PATCH
ORACLE 11G ACTIVE DATA GUARD执行SWITCHOVER出现数据库实例CRASH、ORA-600等等严重故障，绝大部分是由于BUG引起，这里梳理一些典型的BUG（这里主要针对ORACLE RDBMS11.2.0.4环境）：
1) BUG 22241601: ORA-600[kdsgrp1]ORA-1555/ ORA-600 [ktbdchk1: baddscn] due to Invalid Commit SCN in INDEX block
2) Bug 18515268 ACTIVE DATAGUARD STANDBY CRASHES DUE TO ANORA-4020 ENCOUNTERED BY LGWR
3) Bug 17018214 ORA-600 [krdrsb_end_qscn_2] ORA-4021 inActive Dataguard Standby Database with fix for bug 16717701 present - Instancemay crash
对于1、2点BUG，可以去MOS下载相应的PATCH安装；对于3点BUG，在ORACLE RDBMS 11.2.0.4已经FIXED，但需要设置隐含参数开启功能：
alter system set"_adg_parselock_timeout"=104887600 scope=both;
2. 建议设置的数据保护参数
如果数据库中存在坏块，也可能造成SWITCHOVER后，数据库实例无法启动。以下数据库参数用于防止或辨识数据库中块损坏。需要注意：参数设置为较高级别会带来一定的性能消耗，所以需要结合现网情况评估，妥善设置。
1） db_block_checking
当block发生任何变化的时候进行逻辑上的完整性和正确性检查。该参数通常能够避免内存中数据块的损坏。块的检查将对系统会有1%到10%的性能影响。频繁的DML将使得块检查带来更多的开销。
参数默认为FALSE，如果数据库不是繁忙的OLTP系统，可以考虑设置为FULL。
2） db_block_checksum
用于DBWn和direct loader数据块写入到磁盘时，基于块内的所有字节计算得出一个校验值并将其写入块头。在该参数设置为typical和full时，当读入时候重新计算校验和写出时候的校验对比，如果不同则认为是块损坏。如果设置为FULL模式，则针对应用程序update/delete语句级别的改变发生后，校验值会被重新计算并写入。同时对于日志块，在写入之前，同样会生产校验值并写入到块头。
参数默认为TYPICAL，如果数据库不是繁忙的OLTP系统，可以考虑设置为FULL。
3） DB_LOST_WRITE_PROTECT
数据库将块改变写入到存储CACHE后则返回写操作成功，如果存储异常造成CACHE中的数据并没有真正写入磁盘，则认为是写丢失。在ACTIVE DATA GUARD环境中，如设置DB_LOST_WRITE_PROTECT，能及时发现主库或备库上的写丢失情况，可以做相应的恢复处理，如MEDIA RECOVERY。
该参数默认为NONE，如果存储存在不稳定情况，建议设置为TYPICAL。
3. SWITCHOVER实施流程
1) 检查主库、备库之间同步状态是否正常
在备库执行：
Sql>select process,status fromv$managed_standby;
RFS进程工作正常。 MRP0进程状态为APPLYING_LOG。
在主库侧执行：
Sql>SELECT RECOVERY_MODE FROMV$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;
RECOVERY_MODE应为：MANAGED REAL TIME APPLY
2）清理备库online logfile
在switch over之前，建议清理备库online redo logfile。
如果设置了log_file_convert_name或使用omf，则执行SWITCHOVER会做自动清理。
手工清理方式：
停掉redo apply;
Sql>ALTERDATABASE CLEAR LOGFILE GROUP nn;
3）传输归档文件GAP检查
在备库端检查是否存在传输归档文件GAP。
Sql>select * from v$archive_gap;
如果存在gap，可以从主库复制传输缺失的归档文件到备库，并注册：
Sql>ALTER DATABASE REGISTER LOGFILE ‘missingarchive file’
4） 检查主库是否有offline的数据文件
执行数据文件online或drop。
5） 主库关停JOB
主库停止运行的JOB，并设置参数：
Sql>Alter system set job_queue_processing=0 scope=both;
Sql>Alter system set AQ_TM_PROCESSES=0 scope=both;
以避免SWITCHOVER过程中JOB和AQ带来影响。SWITCHOVER完成后再开启。
6） 主库停止数据库访问应用
如关停业务、EM、OEM AGENT等等。并确保主库改变均应用到备库。
7） 主库、备库开启LOG TRACE
这个步骤可选。将打印更详细的trace，便更清楚地跟踪SWITCHOVER过程。
Sql>alter system setlog_archive_trace=8191;
8) 检查主库的SWITCHOVER STATUS
Sql>SELECT SWITCHOVER_STATUS FROMV$DATABASE;
应为TO STANDBY or SESSIONSACTIVE，表明支持切换为STANDBY。
9) 主库切换为PHYSICALSTANDBY DATABASE
在主库执行：
rman>alter database commit to switchoverto standby with session shutdown;
在主库的alert log中会提示：
Switchover End-Of-Redo Log thread 1sequence nnnn。
完成角色切换前，主库将redo log终止标志发送到备库。
备库的alert log会提示：
RFS[20]: End-Of-Redo archival of thread 1sequence nnnn
收到主库发来的最后的redo并apply。
10) 备库切换为PRIMARYDATABASE
主库切换为PHYSICAL STANDBYDATABASE后，查看备库的SWITCHOVER STATUS：
Sql>select switchover_status fromv$database;
状态应为TO PRIMARY orSESSIONS ACTIVE，表明备库可以进行角色切换。
执行备库切换：
rman>alter database commit to switchoverto primary with session shutdown;
将关闭MRP进程。
打开新的primary库:
Sql>alter database open；
11) 在新的备库上执行ADGREAL-TIME APPLY
重启新的备库：
Sql>startup mount;
Sql>alter database open;
启动REAL-TIME APPLY:
rman>alter database recover managedstandby database using current logfile disconnect;
在新的ADG环境中验证数据同步情况。
至此，ORACLE 11G ACTIVEDATA GUARD安全SWITCHOVER完成。
专家简介：李捷：甲骨文公司资深高级技术专家，15年数据库服务经验。曾服务于中国电信、中国网通、中国移动等大型通信企业。擅长数据库高可用性架构、数据迁移、性能优化、各类数据库疑难问题处理,有非常丰富的实战经验。 |  |
原创文章，作者版权所有，转载请联系作者或者注明出处
