Additional Backup Situations

The following sections describe how to modify the backup procedures for other configurations, such as when the standby and primary databases cannot share backup files; the standby instance is only used to remotely archive redo log files; or the standby database filenames are different than the primary database.

10.3.1 Standby Databases Too Geographically Distant to Share Backups

In this case, the backups taken on a standby system are not easily accessible by the primary system or other standby systems. Perform a complete backup of the database on all systems to perform recovery operations. The flash recovery area can reside locally on the primary and standby systems (for example, the flash recovery area is not the same for the primary and standby databases).

In this scenario, you can still use the general strategies described in Section 10.2, with the following exceptions:

■ Backup files created by RMAN must be tagged with the local system name, and with RESTORE operations that tag must be used to restrict RMAN from selecting backups taken on the same host. In other words, the BACKUP command must use the TAG node name option when creating backups; the RESTORE command must use the FROM TAG node name option; and the RECOVER command must use FROM TAG node name ARCHIVELOG TAG node name option.

■ Disaster recovery of the standby site:

1. Start the standby instance in the NOMOUNT state using the same parameter files with which the standby was operating earlier.

2. Create a standby control file on the primary instance using the SQL ALTER DATABASE CREATE STANDBY CONTROLFILE AS filename statement, and use the created control file to mount the standby instance.

3. Issue the following RMAN commands to restore and recover the database files:

RESTORE DATABASE FROM TAG 'node name'

RECOVER DATABASE FROM TAG 'node name' ARCHIVELOG TAG 'node name' 4. Restart Redo Apply.

The standby instance will fetch the remaining archived redo log files as described in Section 5.8.

10.3.2 Standby Database Does Not Contain Datafiles, Used as a FAL Server

Use the same procedure described in Section 10.1, with the exception that the RMAN commands that back up database files cannot be run against the FAL server. The FAL server can be used as a backup source for all archived redo log files, thus off-loading backups of archived redo log files to the FAL server.

Additional Backup Situations

10.3.3 Standby Database File Names Are Different than Primary Database

If the database filenames are not the same on the primary and standby databases, the RESTORE and RECOVER commands you use will be slightly different. To obtain the actual datafile names on the standby database, query the V$DATAFILE view and specify the SET NEWNAME option for all the datafiles in the database:

RUN {

SET NEWNAME FOR DATAFILE 1 TO 'existing file location for file#1 from V$DATAFILE';

SET NEWNAME FOR DATAFILE 2 TO 'existing file location for file#2 from V$DATAFILE';

…

…

SET NEWNAME FOR DATAFILE n TO 'existing file location for file#n from V$DATAFILE';

RESTORE {DATAFILE <n,m,…> | TABLESPACE tbs_name_1, 2, …| DATABASE;

SWITCH DATAFILE ALL;

RECOVER DATABASE {NOREDO};

}

Similarly, the RMAN DUPLICATE command should also use the SET NEWNAME option to specify new filenames during standby database creation.

10.3.4 Deletion Policy for Archived Redo Log Files In Flash Recovery Areas

By default, archived redo log files in a flash recovery area that were backed up to a tertiary device or made obsolete (as defined by the RMAN retention policy) are eligible for deletion. The archived redo log files that are backed up or obsolete can eventually be deleted automatically to make space if the disk space in the flash recovery area becomes full. However, you can change this default deletion policy using the following RMAN command:

CONFIGURE ARCHIVELOG DELETION POLICY TO [CLEAR | NONE | APPLIED ON STANDBY];

This section describes the command qualifiers and provides examples for setting up a deletion policy. See Oracle Database Backup and Recovery Advanced User's Guide for more information about how Oracle software manages disk space in the flash recovery area.

Using the APPLIED ON STANDBY Clause

Use the APPLIED ON STANDBY clause so that archived redo log files that have been applied on all mandatory standby destinations will be deleted. The actions taken when you specify this clause are described in the following table:

See Appendix E for more information about cascaded destinations.

Using the CLEAR Clause

Use the CLEAR clause to disable the deletion policy that was previously set up with the RMAN CONFIGURE ARCHIVELOG DELETION POLICY command. The Oracle When the APPLIED ON STANDBY

clause is configured on. . . Then, these files are eligible for deletion. . . The primary database Archived redo log files in the flash recovery area that

were applied on all mandatory standby databases.

A standby database that has one or more mandatory cascading standby databases

Archived redo log files in the flash recovery area that were applied on all mandatory cascading standby databases.

A standby database that has no cascading standby databases

Archived redo log files in the flash recovery area that were applied on the standby database.

Additional Backup Situations

database will resume the default deletion policy behavior, which is to delete archived redo log files that are backed up or obsolete to make space if disk space in the flash recovery area becomes full.

Using the NONE Clause

Use the NONE clause so that archived redo logs in flash recovery area that were backed up or obsolete as per the RMAN retention policy are eligible for deletion. This is the default configuration. Archived redo log files that are backed up or obsolete are deleted to make space if the disk space in the flash recovery area becomes full.

Examples of the CONFIGURE ARCHIVELOG DELETION POLICY Command When backups of archived redo log files are taken on the standby database:

1. Issue the following command on the primary database:

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

2. Issue the following command on the standby database:

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

When backups of archived redo log files are taken on the primary database:

1. Issue the following command on the standby database:

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

2. Issue the following command on the primary database:

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

10.3.4.1 Reconfiguring the Deletion Policy After a Role Transition

After a switchover or failover, you may need to reissue the RMAN CONFIGURE ARCHIVELOG DELETION POLICY command on each database. If the backup site for archived redo log files remains the same, then do nothing. Otherwise, you must switch the archivelog deletion policy by issuing the CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY statement on the database where backups are not taken, and issuing the CONFIGURE ARCHIVELOG DELETION POLICY TO NONE statement on the database where backups are taken.

10.3.4.2 Viewing the Current Deletion Policy

To see the current setting (APPLIED ON STANDBY, CLEAR, NONE) for a database, issue the following query:

SELECT NAME, VALUE FROM V$RMAN_CONFIGURATION WHERE NAME LIKE '%ARCHIVELOG DELETION POLICY%';

NAME VALUE

- ---ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY

You can also find the existing configuration using the RMAN SHOW ARCHIVELOG DELETION POLICY command:

RMAN> SHOW ARCHIVELOG DELETION POLICY RMAN configuration parameters are:

Additional Backup Situations

11

Using SQL Apply to Upgrade the Oracle