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、结论

 

综合上面的三种方法，理论上都能够解决我们面临的实际问题。但是在实践环境，特别是投产系统中，我们要从系统停机窗口、备份方案可用性和操作复杂性等多个角度进行综合评估，作出最好的判断。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/17203031/viewspace-1976242/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/17203031/viewspace-1976242/