DataGuard环境下备库RMAN-05021问题有效性解决方案
DataGuard环境下备库RMAN-05021问题有效性解决方案
Dataguard环境作为Oracle官方重要的HA功能组件，在实践领域有非常多的应用场景和成功案例。同任何技术一样，在配置过程中，会出现一些问题需要解决。本文主要介绍在修改Physical Standby备份Rman参数中出现的问题和解决策略。
1、问题描述
笔者环境为11.2.0.4的Dataguard环境，两台服务器配置为双单节点的Physical Standby。在配置备库的RMAN信息中，出现如下问题：
RMAN> connect target sys/oracle
connected to target database: VLIFE (DBID=4207470439)
using target database control file instead of recovery catalog
RMAN> show all;
RMAN configuration parameters for database with db_unique_name URESTB are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE 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:16
RMAN-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 TAG20151221T153209
62 B F A DISK 21-DEC-15 1 1 NO TAG20151221T153322
63 B F A DISK 21-DEC-15 1 1 NO TAG20151221T153347
64 B A A DISK 31-DEC-15 1 1 NO TAG20151231T091532
65 B F A DISK 31-DEC-15 1 1 NO TAG20151231T091548
66 B A A DISK 31-DEC-15 1 1 NO TAG20151231T091606
67 B F A DISK 31-DEC-15 1 1 NO TAG20151231T091607
按照当前的一份冗余策略，就会删除掉12月21日的记录。
RMAN> delete obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
using channel ORA_DISK_1
Deleting 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_.bkp
Backup 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_.bkp
Backup 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_.bkp
Do 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_1
no 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 PRIMARY
SQL> alter database commit to switchover to standby with session shutdown;
Database altered.
SQL> quit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@vLIFE-URE-OT-DB-PRIMARY ~]$ ps -ef | grep pmon
oracle 30720 30659 0 10:40 pts/0 00:00:00 grep pmon
主库切换之后，自动停机。下面进行备库操作。
[oracle@vLIFE-URE-OT-DB-STANDBY ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Wed Jan 13 10:38:32 2016
Copyright (c) 1982, 2013, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ ONLY WITH APPLY PHYSICAL STANDBY
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO PRIMARY
SQL> 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 PRIMARY
SQL> alter database open;
Database altered.
原来的主库（先备库）启动，进行Redo Apply过程。
[oracle@vLIFE-URE-OT-DB-PRIMARY ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Wed Jan 13 10:42:37 2016
Copyright (c) 1982, 2013, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 2471931904 bytes
Fixed Size 2255752 bytes
Variable Size 738198648 bytes
Database Buffers 1711276032 bytes
Redo Buffers 20201472 bytes
Database mounted.
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.
--日志传输正常。
SQL> select STATUS from v$archive_dest_status;
STATUS
---------
VALID
VALID
INACTIVE
修改原备库RMAN项目。
[oracle@vLIFE-URE-OT-DB-STANDBY trace]$ rman nocatalog
Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jan 13 10:48:47 2016
Copyright (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 catalog
RMAN> show all;
RMAN configuration parameters for database with db_unique_name VLIFESB are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE 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 stored
RMAN> 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 nocatalog
Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jan 13 11:11:18 2016
Copyright (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 catalog
RMAN> 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虚拟机中安装步骤
Debian 下 安装 Oracle 11g XE R2
Oracle Data Guard 重要配置参数
基于同一主机配置 Oracle 11g Data Guard
探索Oracle之11g DataGuard
Oracle Data Guard （RAC+DG) 归档删除策略及脚本
Oracle Data Guard 的角色转换
Oracle Data Guard的日志FAL gap问题
Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 处理方法
评论暂时关闭