Solution to the Problem of RMAN-05021 in slave uard Environment

Solution to the Problem of RMAN-05021 in slave uard Environment

As an important component of the Oracle HA function, the Dataguard environment has many application scenarios and success stories in the field of practice. Like any technology, some problems need to be solved during the configuration process. This article describes the problems and solutions for modifying the Physical Standby backup Rman parameters.

1. Problem Description

In the replicuard environment of 11.2.0.4, the two servers are configured as Physical Standby with dual and single nodes. The following problems occur in the RMAN information of the slave Database Configuration:

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

(Space reasons, omitted ......)

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

According to the prompts, The RMAN configuration item on the Standby end cannot be modified. From the perspective of MOS data, the root cause of this problem is that the control file on the Standby side is a read-only file. In control file, Oracle stores data files, logs (archived and online), and backup information. For the Standby end, the Control File is a read-only File. through conventional Configuration modification methods, the configuration content cannot be modified.

2. Two official processing strategies

In mos id 1519386.1, two potential processing methods are proposed. The first processing policy is to directly write the configuration content in the Backup Recovery statement during Backup.

RMAN> list backup summary;

List of Backups

====================

Key ty lv s Device Type Completion Time # Pieces # Copies Compressed Tag

-----------------------------------------------------------------

61 B 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 DISK 31-DEC-15 1 1 NO TAG20151231T091532

65 B F A DISK 31-DEC-15 1 1 NO TAG20151231T091548

66 B A DISK 31-DEC-15 1 1 NO TAG20151231T091606

67 B F A DISK 31-DEC-15 1 1 NO TAG20151231T091607

According to the current redundancy policy, the records for April December 21 will be deleted.

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

Directly specify the obsolete window in the RMAN command window.

RMAN> delete obsolete recovery window of 5 days;

Using channel ORA_DISK_1

No obsolete backups found

The second method is to copy a new standby control file from Primary, modify the RMAN parameter, and then transfer it to Standby. As the new Standby.

This solution was tested in detail and failed. The main reason is that there are too many modifications and the operation steps are too complicated.

Ü for the switched Standby Control File, all data files and online logs need to be relocated and renamed;

Ü the automatic file management function must be terminated during file name adjustment;

Ü all archiving logs, backup information, and synchronization time information on the slave database will be lost;

Based on this, I do not recommend this method.

3. Switch Switchover to solve the problem

After thinking, the author puts forward a hypothesis. If the Control File cannot be modified on the Standby side, but the Control File can be modified on the Primary side. Can I perform a prepared Switchover action to temporarily change the Standby end to a controllable File that can be modified. After modification, Switchover will be ready.

The experiment process is as follows: first, switch the role on the master database.

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 00:00:00 pts/0 grep pmon

After the master database is switched, the instance is automatically shut down. Perform the following operations on the slave database.

[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,201 3, 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.

The original master database (slave database) is started to perform the Redo Apply process.

[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,201 3, 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.

-- Log transmission is normal.

SQL> select STATUS from v $ archive_dest_status;

STATUS

---------

VALID

VALID

INACTIVE

Modify the RMAN project of the original standby database.

[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,201 1, 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

You can use the same method to switch back the original Primary and Standby relationships. Due to space limitations, do not describe them in detail. After the operation, the modified parameters take effect.

[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,201 1, 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. Conclusion

Based on the above three methods, the actual problems we face can be solved theoretically. However, in practical environments, especially production systems, we need to make a comprehensive assessment from the perspectives of system downtime windows, backup solution availability, and operation complexity to make the best judgment.

Steps for installing Oracle 11gR2 in vmwarevm

Install Oracle 11g XE R2 In Debian

Important configuration parameters of Oracle Data Guard

Configure Oracle 11g Data Guard based on the same host

Explore Oracle 11g elastic uard

Oracle Data Guard (RAC + DG) archive deletion policies and scripts

Role conversion for Oracle Data Guard

FAL gap in Oracle Data Guard logs

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby