Intro
In the current data-driven era, businesses leverage data analysis to seize opportunities and gain a competitive edge. This makes it crucial for organizations to have a robust disaster recovery (DR) plan. Oracle Data Guard offers significant flexibility for maintaining data synchronization with the primary database. Additionally, it allows opening the database in snapshot standby mode for testing purposes, ensuring the standby database is reliable and up-to-date.
In this article, I will discuss the issues encountered while rebuilding a standby database. While attempting an incremental recovery, we faced issues after executing the command to catalog the data files and then switching the database to the copy. This command failed with RMAN-06571.
Error
We cataloged the data files because the latest standby control file backup taken from the primary had different data file locations. The primary use ACFS, while the standby datafiles are under the ASM +DATA mount point.
How to catalog data files.
You can catalog the datafiles using the following command:
catalog start with '+DATA/TEST_HA/datafile/';
Once the cataloging is complete, you can switch the database to the copy since this is a standby database. This is where we faced the RMAN-06571 error.
RMAN> switch database to copy;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of switch to copy command at 06/24/2024 20:01:49
RMAN-06571: datafile 1430 does not have recoverable copy
Reason for the failure
Solution
You need to restore the missing data files and then run the switch database to copy the command. Use the following commands to restore the data files.
Single datafiles restore
To restore a single datafile, use the RMAN run block:
run
{
set newname for datafile 1430 to '+DATA/TEST_HA/datafile/%b';
restore datafile 1430;
}
Multiple datafile restore
run
{
set newname for datafile 1431 to '+DATA/TEST_HA/datafile/%b';
set newname for datafile 1432 to '+DATA/TEST_HA/datafile/%b';
set newname for datafile 1433 to '+DATA/TEST_HA/datafile/%b';
set newname for datafile 1434 to '+DATA/TEST_HA/datafile/%b';
restore datafile 1431,1432,1433,1434;
}
Expected output
RMAN> run
{
set newname for datafile 1430 to '+DATA/TEST_HA/datafile/%b';
restore datafile 1430;
}2> 3> 4> 5>
executing command: SET NEWNAME
Starting restore at 24-JUN-24
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=13 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=396 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=776 device type=DISK
allocated channel: ORA_DISK_4
channel ORA_DISK_4: SID=1155 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 01430 to +DATA/TEST_HA/TEST_HA/o1_mf_dg_histo_m6s7bj9b_.dbf
channel ORA_DISK_1: reading from backup piece /rman_restore/TEST_HA/Incr_standby_HOT_os2u6340_1_1.bkp
channel ORA_DISK_1: piece handle=/rman_restore/TEST_HA/Incr_standby_HOT_os2u6340_1_1.bkp tag=TAG20240624T163132
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:02:45
Finished restore at 24-JUN-24
Restart recovery
You can start the database recovery once you complete the datafile restore and switch the database to the copy. Below is the sample RMAN run block for standby incremental recovery:
run
{
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK ;
ALLOCATE CHANNEL CH2 DEVICE TYPE DISK ;
ALLOCATE CHANNEL CH3 DEVICE TYPE DISK ;
ALLOCATE CHANNEL CH4 DEVICE TYPE DISK ;
ALLOCATE CHANNEL CH5 DEVICE TYPE DISK ;
ALLOCATE CHANNEL CH6 DEVICE TYPE DISK ;
recover database noredo;
}
Conclusion
Rebuilding a standby database involves several critical steps to ensure synchronization with the primary database and readiness for recovery. Cataloging datafiles correctly is essential, especially when datafile locations differ between the primary and standby databases. Issues such as RMAN-06571 can arise if new data files on the primary are not accounted for on the standby, highlighting the importance of restoring any missing data files before attempting to switch the database to the copy.
By carefully following the outlined steps for cataloging, restoring, and recovering the database, you can effectively manage and rebuild standby databases, ensuring minimal downtime and maximum data protection.
No comments:
Post a Comment