DataGuard环境下备库RMAN-05021问题有效性解决方案

Dataguard环境作为Oracle官方重要的HA功能组件，在实践领域有非常多的应用场景和成功案例。同任何技术一样，在配置过程中，会出现一些问题需要解决。本文主要介绍在修改Physical Standby备份Rman参数中出现的问题和解决策略。1、问题描述笔者环境为11.2.0.4的Dataguard环境，两台服务器配置为双单节点的Physical Standby。在配置备库的RMAN信息中，出现如下问题：RMAN> connect target sys/oracleconnected to target database: VLIFE （DBID=4207470439）using target database control file instead of recovery catalogRMAN> show all;RMAN configuration parameters for database with db_unique_name URESTB are:CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # defaultCONFIGURE BACKUP OPTIMIZATION OFF; # default（篇幅原因，有省略……）RMAN> configure retention policy to recovery window of 15 days;RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of configure command at 12/31/2015 08:55:16RMAN-05021: this configuration cannot be changed for a BACKUP or STANDBY control file从提示信息情况看，在Standby端的RMAN配置项目是不能进行修改的。从MOS资料上看，这个问题的根源在于Standby端的控制文件control file是一个只读文件。在control file中，Oracle将数据文件、日志（归档和在线）、备份信息都保存在其中。对于Standby端，Control File是一个只读的文件内容，通过常规的修改配置手段，是不能够修改配置内容的。2、官方两种处理策略在MOS ID 1519386.1中，提出了两种潜在的处理方法。第一种处理策略是在进行备份的时候，将配置内容直接写在备份还原操作语句中。RMAN> list backup summary;List of Backups===============Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag------- -- -- - ----------- --------------- ------- ------- ---------- ---61 B A A DISK 21-DEC-15 1 1 NO TAG20151221T15320962 B F A DISK 21-DEC-15 1 1 NO TAG20151221T15332263 B F A DISK 21-DEC-15 1 1 NO TAG20151221T15334764 B A A DISK 31-DEC-15 1 1 NO TAG20151231T09153265 B F A DISK 31-DEC-15 1 1 NO TAG20151231T09154866 B A A DISK 31-DEC-15 1 1 NO TAG20151231T09160667 B F A DISK 31-DEC-15 1 1 NO TAG20151231T091607按照当前的一份冗余策略，就会删除掉12月21日的记录。RMAN> delete obsolete; RMAN retention policy will be applied to the commandRMAN retention policy is set to redundancy 1using channel ORA_DISK_1Deleting the following obsolete backups and copies:Type Key Completion Time Filename/Handle-------------------- ------ ------------------ --------------------Backup Set 61 21-DEC-15 Backup Piece 62 21-DEC-15 /u01/app/oracle/fast_recovery_area/VLIFESB/backupset/2015_12_21/o1_mf_annnn_TAG20151221T153209_c7hbry5x_.bkpBackup Set 62 21-DEC-15 Backup Piece 63 21-DEC-15 /u01/app/oracle/fast_recovery_area/VLIFESB/backupset/2015_12_21/o1_mf_nnndf_TAG20151221T153322_c7hbt2l2_.bkpBackup Set 63 21-DEC-15 Backup Piece 64 21-DEC-15 /u01/app/oracle/fast_recovery_area/VLIFESB/autobackup/2015_12_21/o1_mf_s_899017209_c7hbtvxo_.bkpDo you really want to delete the above objects （enter YES or NO）？ no直接指定obsolete窗口在RMAN命令窗口。RMAN> delete obsolete recovery window of 5 days;using channel ORA_DISK_1no obsolete backups found第二种方法是从Primary中拷贝处一份全新的standby control file，之前修改好RMAN参数，之后转移到Standby中。作为新的Standby进行处理加载。这个方案，笔者进行了详细测试，最后没有成功。主要原因是修改内容太多，操作步骤过于复杂。ü 对于切换过来的Standby Control File，所有的数据文件、在线日志都需要重新进行定位重新命名；ü 在调整文件名过程中，还要终止文件自动管理功能；ü 备库上所有的归档日志、备份信息和同步时间点信息，都会丢失；基于此，笔者并不推荐使用这种方法。3、切换Switchover解决问题经过思考，笔者提出了一种假说。如果Control File在Standby端是不允许进行修改，但是在Primary端允许修改的话。可否进行一次有准备的Switchover动作，让Standby端临时性变为可以修改的Control File。修改之后再Switchover就可以了。实验过程如下，首先在主库上进行角色切换动作。SQL> select open_mode, database_role from v$database;OPEN_MODE DATABASE_ROLE-------------------- ----------------READ WRITE PRIMARYSQL> alter database commit to switchover to standby with session shutdown;Database altered.SQL> quitDisconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing options[oracle@vLIFE-URE-OT-DB-PRIMARY ~]$ ps -ef | grep pmonoracle 30720 30659 0 10:40 pts/0 00:00:00 grep pmon主库切换之后，自动停机。下面进行备库操作。[oracle@vLIFE-URE-OT-DB-STANDBY ~]$ sqlplus /nologSQL*Plus: Release 11.2.0.4.0 Production on Wed Jan 13 10:38:32 2016Copyright （c） 1982, 2013, Oracle. All rights reserved.SQL> conn / as sysdbaConnected.SQL> select open_mode, database_role from v$database;OPEN_MODE DATABASE_ROLE-------------------- ----------------READ ONLY WITH APPLY PHYSICAL STANDBYSQL> select switchover_status from v$database;SWITCHOVER_STATUS--------------------TO PRIMARYSQL> alter database commit to switchover to primary with session shutdown;Database altered.SQL> select open_mode, database_role from v$database;OPEN_MODE DATABASE_ROLE-------------------- ----------------MOUNTED PRIMARYSQL> alter database open;Database altered.原来的主库（先备库）启动，进行Redo Apply过程。[oracle@vLIFE-URE-OT-DB-PRIMARY ~]$ sqlplus /nologSQL*Plus: Release 11.2.0.4.0 Production on Wed Jan 13 10:42:37 2016Copyright （c） 1982, 2013, Oracle. All rights reserved.SQL> conn / as sysdbaConnected to an idle instance.SQL> startup mount;ORACLE instance started.Total System Global Area 2471931904 bytesFixed Size 2255752 bytesVariable Size 738198648 bytesDatabase Buffers 1711276032 bytesRedo Buffers 20201472 bytesDatabase mounted.SQL> alter database recover managed standby database using current logfile disconnect;Database altered.--日志传输正常。SQL> select STATUS from v$archive_dest_status;STATUS---------VALIDVALIDINACTIVE修改原备库RMAN项目。[oracle@vLIFE-URE-OT-DB-STANDBY trace]$ rman nocatalogRecovery Manager: Release 11.2.0.4.0 - Production on Wed Jan 13 10:48:47 2016Copyright （c） 1982, 2011, Oracle and/or its affiliates. All rights reserved.RMAN> connect target /connected to target database: VLIFE （DBID=4207470439）using target database control file instead of recovery catalogRMAN> show all;RMAN configuration parameters for database with db_unique_name VLIFESB are:CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # defaultCONFIGURE BACKUP OPTIMIZATION ON;RMAN> configure retention policy to recovery window of 15 days;new RMAN configuration parameters:CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;new RMAN configuration parameters are successfully storedRMAN> show all;RMAN configuration parameters for database with db_unique_name VLIFESB are:CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;CONFIGURE BACKUP OPTIMIZATION ON;CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default下面就可以使用相同的方法将原来的Primary和Standby关系切换回来。由于篇幅所限，不进行详细说明。操作后，修改的参数生效。[oracle@vLIFE-URE-OT-DB-STANDBY trace]$ rman nocatalogRecovery Manager: Release 11.2.0.4.0 - Production on Wed Jan 13 11:11:18 2016Copyright （c） 1982, 2011, Oracle and/or its affiliates. All rights reserved.RMAN> connect target /connected to target database: VLIFE （DBID=4207470439）using target database control file instead of recovery catalogRMAN> show all;RMAN configuration parameters for database with db_unique_name VLIFESB are:CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;CONFIGURE BACKUP OPTIMIZATION ON;3、结论综合上面的三种方法，理论上都能够解决我们面临的实际问题。但是在实践环境，特别是投产系统中，我们要从系统停机窗口、备份方案可用性和操作复杂性等多个角度进行综合评估，作出最好的判断。Oracle 11gR2 在VMWare虚拟机中安装步骤 http://www.linuxidc.com/Linux/2013-09/89579p2.htmDebian 下安装 Oracle 11g XE R2 http://www.linuxidc.com/Linux/2014-03/98881.htmOracle Data Guard 重要配置参数 http://www.linuxidc.com/Linux/2013-08/88784.htm基于同一主机配置 Oracle 11g Data Guard http://www.linuxidc.com/Linux/2013-08/88848.htm探索Oracle之11g DataGuard http://www.linuxidc.com/Linux/2013-08/88692.htmOracle Data Guard （RAC+DG）归档删除策略及脚本 http://www.linuxidc.com/Linux/2013-07/87782.htmOracle Data Guard 的角色转换 http://www.linuxidc.com/Linux/2013-06/86190.htmOracle Data Guard的日志FAL gap问题 http://www.linuxidc.com/Linux/2013-04/82561.htmOracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 处理方法 http://www.linuxidc.com/Linux/2013-03/82009.htm更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx？tid=12本文永久更新链接地址