adg备库做一致性备份

Oracle Database - Enterprise Edition - Version 11.2.0.1 and later
Enterprise Manager for Oracle Database - Version 12.1.0.2.0 to 12.1.0.2.0 [Release 12.1]
Oracle Database Cloud Schema Service - Version N/A and later
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Information in this document applies to any platform.

GOAL

Howto create a consistent RMAN backup on a Standby database in Active Dataguard Mode.

Consistent means, that the backup is having the datafiles and the related archived redologs, so that it can be opened with this backup. This done on the Primary database by using :
 

RMAN> backup database plus archivelog;

This will execute the following :

1. Backup the existing archived redologs
2. Backup the datafiles
3. Switch a logfile
4. Backup all the archives again, but this time it will include all the archived redologs created during and just after the datafile backup. This are the archives which are required to make the datafile backup consistent.

The goal of this document it to accomplish this in an Active DataGuard database.
An Active DataGuard database is a standby database which is open in READ ONLY, but with an ongoing recovery.
This ongoing recovery is updating the datablocks, even while the database is in READ ONLY mode.
From an RMAN perspective the datafiles will behave the same as in a Primary database, meaning that they are FUZZY and will need some recovery to become consistent.

As the standby database is open in READ ONLY, RMAN will NOT be able to force a switch. This is only done when a database is in READ WRITE. The archives are only created when the Primary is switching a logfile. So the above step(4) will NOT backup any new archived redologs and therefor this total backup will not be consistent as it requires additional archives which are not backed up (yet).
 

SOLUTION

The missing logswitch on the Active DataGuard database can be force, by making an explicit logswitch on the Primary.

shell script : /usr/local/bin/logswitch.sh

#!/bin/ksh

#
# Change <passwd>
#        <primary_db>
#

sqlplus -s "sys/<passwd>@<primary_db> as sysdba" <<EOF
alter system archive log current;
exit
EOF
 

% chmod 755 /usr/local/bin/logswitch.sh

Example of RMAN backup script on the Active Dataguard Standby database

% rman target / catalog <un/pw@catalog_db>

Rman> Configure controlfile autobackup on  ;--------------> This would ensure Controlfile auto backup
RMAN> backup database plus archivelog delete input;

      host "/usr/local/bin/logswitch.sh";

      backup archivelog all delete input;

For 19c and above versions ,use below command to take consistent backups on standby database . This command works only in Active Dataguard

RMAN> BACKUP CONSISTENT DATABASE;

Additional Comments

Note 1:
The missing 'Log Switch' by making an explicit 'Log Switch' on the Primary.
also does apply to the BASIC DATA GUARD case as well where the database is MOUNTED and in
managed recovery mode (MRP).
A backup taken of a MOUNTED standby database in recovery mode will also not get all of the
archived logs required unless a switch is performed on the primary and a second archived log backup is taken.
 

Note 2:
For taking consistent RMAN Backups in a basic Standby
"not" in Active DataGuard mode and not running recovery mode (MRP)
.
Please see:
 (Doc ID 1292126.1) How to take consistent backups at standby site
.

Note 3:
The logswitch on primary is NOT required in 11.2.0.4 and above anymore.

Reference:
(Doc ID 1616074.1) RMAN-06820 ORA-17629 During Backup at Standby Site

Bug 17580082 : ACTIVE STANDBY - RMAN-6820: WARNING: FAILED TO ARCHIVE CURRENT LOG AT PRIMARY
Status: 32 - Not a Bug

REFERENCES

NOTE:1292126.1 - How to take consistent backups at standby site

How to take an offline, consistent, self-contained backup at the standby site. The aim of this exercise is to have a self-contained backup that can be restored on its own without needing recovery.  I.e., since recovery of standby is stopped, the backup is a cold backup.  

This process will work for both RAC and non-RAC systems.

SOLUTION

1) stop managed recovery:
 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2) backup the database and controlfile
 

Please note :-
If you have a recovery catalog configured you can connect to it and take a backup.
Both the Primary and Standby database should use the same recovery catalog. Even though these database share the same DBID,Rman is able to differentiate the standby database from Primary .
Note you do not need to register the standby database in the catalog if the primary is already registered. Simply connect to the standby as target and then connect to recovery catalog for taking backup.

 

% rman target <sys/pw@standby_db> catalog <un/pw@catalog_db>

Rman> Configure controlfile autobackup on  ;--------------> This would ensure Controlfile auto backup
RMAN> backup database plus archivelog ;

Note: In 10g, you will need to backup the controlfile from the primary site.

The above will result in a consistent, self-contained backup.

3) restart managed recovery:

To restore from this backup:
 

RMAN> startup nomount;
RMAN> restore controlfile from 'controlfile backuppiece name and location';
RMAN> alter database mount;
RMAN> restore database;
RMAN> recover database noredo;

---

For taking consistent RMAN Backups in Standby in Active DataGuard mode
Please see:

 (Doc ID 1419923.1) Howto make a consistent RMAN backup in an Standby database in Active DataGuard mode
 

REFERENCES

NOTE:1419923.1 - Howto make a consistent RMAN backup in an Standby database in Active DataGuard mode

GOAL

Benefits and Usage of RMAN with Standby Databases.

How Offloading of the Backups from Primary to Standby database site  is useful when the Load on Primary database is high.

How to take a Cold and Hot backup on Standby database.
.

SOLUTION

RMAN can back up the standby database and its associated archived redo logs. Standby backups of datafiles and archived redo logs are fully interchangeable with primary database backups. In other words, you can run the RESTORE command to restore a backup of a standby datafile to the primary database, and you can restore a backup of a primary datafile to the standby database. The standby control file and primary control file, however, are not interchangeable. Although some files such as the control file and SPFILE must be backed up on the primary database.


Benefits of backing up database at standby site : 

+ Because the standby database is not the production database, a standby backup does not interfere with transactions or batch jobs in the production database. Hence, you can use the standby database as a backup host without interfering with the production system.

+ If the standby and primary databases are on separate hosts, then standby backup operations do not consume CPU cycles, allocate memory, or consume other resources on the production host.

Note :  Both the primary database and standby database should use the same recovery catalog. Even though these databases share the same DBID, RMAN is able to differentiate the standby database from the primary. Note that you do not need to register the standby database in the catalog if the primary is already registered: simply connect to the standby database and run the BACKUP command.

If datafiles are backed up on the Primary aswell, than check Note 579625.1 RMAN Maintenance Commands Affect Wrong Files With Standby Backup Configuration

Backing Up a Standby Database with RMAN :

Use the RMAN BACKUP command to back up the standby database. A backup of the standby database is exactly the same as a backup of the primary database, except that the backup takes place on the standby site. The primary database has no influence on the backup of the standby database. Note that when you connect to the standby database to perform the backup, you connect using the TARGET keyword and not the AUXILIARY keyword.

As the following table shows, whether the standby database backup is consistent or inconsistent depends on the state of the standby database when the backup is made. Only a consistent backup can be restored without performing media recovery.

Standby Database Status	Backup Status
Shutdown cleanly and then mounted (but not placed in recovery mode)	Consistent
Mounted after instance failure or SHUTDOWN ABORT	Inconsistent
Manual recovery mode	Inconsistent
Managed recovery mode	Inconsistent
Read-only Apply mode (Active Data Guard or ADG)	Inconsistent

Example 1 : Performing a consistent/cold backup on the standby database :

SQL> connect SYS/<password>@<connect string of standby>
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP NOMMOUNT PFILE=initSTANDBY.ora
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

$ rman target sys/<password>@<connect string of standby> catalog < rman catalog user>/<password>@<Connect string of Catalog>
RMAN> backup database;
RMAN> backup archivelog all; 

Example 2 : Performing a inconsistent/hot backup on the standby database :

$ rman target sys/<password>@<connect string of standby> catalog <rman catalog user>/<password>@<Connect string of Catalog>
RMAN> backup database;
RMAN> backup archivelog all;

In Example 2 we are assuming that the database is in Managed recovery mode.

Note :  The control file and SPFILE must be backed up on the primary database. 

---

REFERENCES

NOTE:579625.1 - RMAN Maintenance Commands Affect Wrong Files With Standby Backup Configuration