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解决问题