Skip Headers
Oracle® Database Backup and Recovery Reference
11g Release 1 (11.1)

Part Number B28273-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

CHANGE

Purpose

Use the CHANGE command to perform the following tasks:

See Also:

Oracle Database Backup and Recovery User's Guide to change the availability status of a backup or copy

Prerequisites

RMAN must be connected as TARGET to a database instance, which must be started.

Usage Notes

"RMAN Backups in a Data Guard Environment" explains the difference between the association and accessibility of a backup. In a Data Guard environment, the database that creates a backup or copy is associated with the file. You can use maintenance commands such as CHANGE, DELETE, and CROSSCHECK for backups when connected to any database in the Data Guard environment as long as the backups are accessible. In general, RMAN considers tape backups created on any database as accessible to all databases in the environment, whereas disk backups are accessible only to the database that created them.

RMAN can only update the status of a backup from AVAILABLE to EXPIRED or DELETED when connected as TARGET to the database associated with the backup. If RMAN cannot delete a backup because it is not associated with the target database, then RMAN prompts you to perform the same CROSSCHECK operation for the file at the database with which it is associated. In this way RMAN protects against unwanted status changes that result from incorrect SBT configurations.

For example, suppose that you connect RMAN as TARGET to standby database standby1 and back it up to tape and disk. If the tape drive becomes unavailable, then you can connect RMAN as TARGET to any primary or standby database in the Data Guard environment to change the status of the tape backup to UNAVAILABLE. After the tape drive is repaired, you can connect RMAN as TARGET to any database to change the status of the tape backup back to AVAILABLE. However, if the disk backup is accidentally removed by an operating system utility, then RMAN can only change the status of the disk backup when connected as TARGET to standby1.

Syntax

change::=

Description of change.gif follows
Description of the illustration change.gif

(maintSpec::=, forDbUniqueNameOption::=, keepOption::=, deviceSpecifier::=)

maintSpec::=

Description of maintspec.gif follows
Description of the illustration maintspec.gif

(listObjList::=, archivelogRecordSpecifier::=, maintQualifier::=, recordSpec::=, deviceSpecifier::=)

forDbUniqueNameOption::=

Description of fordbuniquenameoption.gif follows
Description of the illustration fordbuniquenameoption.gif

resetDbUniqueNameOption::=

Description of resetdbuniquenameoption.gif follows
Description of the illustration resetdbuniquenameoption.gif

changeFailure::=

Description of changefailure.gif follows
Description of the illustration changefailure.gif

Semantics

change

This clause enables you to change the status of RMAN repository records. To obtain the primary keys of RMAN repository records whose status you want to change, run a LIST command or query the recovery catalog views.

Syntax Element Description
maintSpec
Specifies which files you want to CHANGE.

See Also: maintSpec for descriptions of the options in this clause.

   forDbUniqueNameOption
Changes the metadata for objects that are exclusively associated with the specified DB_UNIQUE_NAME in a Data Guard environment.

See Also: forDbUniqueNameOption for descriptions of the options in this clause.

   AVAILABLE Changes the status of a backup or copy to AVAILABLE in the repository. RMAN searches for the file and verifies that it exists.

This feature is useful when a previously unavailable file is made available again. You can also use this option to alter the repository status of backups and copies from prior incarnations.

This is the only CHANGE option that requires either a manual or automatic maintenance channel. A maintenance channel is not required, however, when CHANGE ... AVAILABLE is used with a file that is disk only (that is, an ARCHIVELOG, DATAFILECOPY, or CONTROLFILECOPY). If you use CHANGE ... AVAILABLE on files that are not disk-only, and have objects created on device types that are not configured for automatic channels, then issue manual maintenance commands on these channels. For example, if you created a backup on an sbt channel, but have only a DISK channel automatically configured, then you must manually allocate an sbt channel before CHANGE ... AVAILABLE can operate on the backup.

If you execute CHANGE ... AVAILABLE for a file in a Data Guard environment, then RMAN attempts to crosscheck the file before updating its status to AVAILABLE. If the file is inaccessible, then RMAN prompts you to perform the same operation when connected as TARGET to the database associated with the file. If the file is accessible, then RMAN updates the status as requested.

Note: You can view the status of backups in the LIST output or recovery catalog views.

Note: CHANGE ... AVAILABLE is not valid for foreign archived redo logs, which are received by a logical standby database for a LogMiner session. Unlike normal archived logs, foreign archived logs have a different DBID.

   keepOption
Changes the exemption status of a backup or copy in relation to the configured retention policy. For example, specify CHANGE ... NOKEEP to remove the KEEP attributes for a backup, making it subject to the backup retention policy.

The KEEP FOREVER clause requires use of a recovery catalog (see Example 2-36). The RESTORE POINT option is not valid with CHANGE. You cannot use CHANGE ... UNAVAILABLE or KEEP attributes for files stored in the flash recovery area.

See Also: keepOption

   resetDbUniqueNameOption
Associates the files in maintSpec with a different database in a Data Guard environment.

See Also: resetDbUniqueNameOption

   UNAVAILABLE Changes the status of a backup or copy to UNAVAILABLE in the repository (see Example 2-34). View the status in the LIST output or recovery catalog views.

This option is useful when a file cannot be found or has migrated offsite. RMAN does not use a file that is marked UNAVAILABLE in a RESTORE or RECOVER command. If the file is later found or returns to the main site, then use the AVAILABLE option to update its status. The UNAVAILABLE option is also useful when you do not want a specific backup or copy to be eligible to be restored but also do not want to delete it, or when you want to alter the repository status of backups and copies from prior incarnations.

CHANGE ... UNAVAILABLE is not valid for files in the flash recovery area. This command is also not valid for foreign archived redo logs, which are received by a logical standby database for a LogMiner session. Unlike normal archived logs, foreign archived logs have a different DBID.

Note: If you execute CHANGE ... UNAVAILABLE for a file in a Data Guard environment, then RMAN does not attempt to crosscheck the file before updating its status to UNAVAILABLE. RMAN updates the status as requested regardless of whether the file physically exists.

   UNCATALOG Removes references to a datafile copy, backup piece, or archived redo log from the recovery catalog, and updates records in the target control file to status DELETED (see Example 2-35). Note that the CHANGE ... UNCATALOG command does not touch physical backups and copies. Use this command to notify RMAN when a file is deleted by some means other than a DELETE command.

If you execute CHANGE ... UNCATALOG for a file in a Data Guard environment, then RMAN does not attempt to crosscheck the file before removing its metadata from the recovery catalog. RMAN removes the metadata as requested regardless of whether the file physically exists.

Caution: If you resynchronize from a backup control file, or upgrade the recovery catalog, then records previously removed from the RMAN repository with CHANGE ... UNCATALOG may reappear in the recovery catalog.

   DEVICE TYPE

   deviceSpecifier

Executes the CHANGE for the specified device type only (see deviceSpecifier). This option is valid only if you have configured automatic channels and have not manually allocated channels. For example, if you run CHANGE UNCATALOG ... DEVICE TYPE DISK, then RMAN only uncatalogs files on disk.
changeFailure
Specifies changes for failures recorded by the Data Recovery Advisor.
DB_UNIQUE_NAME FROM db_unique_name TO db_unique_name Updates the metadata in the recovery catalog to reflect a new DB_UNIQUE_NAME for a database in a Data Guard environment. The first value specifies the old DB_UNIQUE_NAME for the database currently recorded in the recovery catalog, whereas the second specifies the new DB_UNIQUE_NAME.

RMAN must be connected to a recovery catalog and a mounted target database. The target database should not have the DB_UNIQUE_NAME specified in the FROM db_unique_name parameter; otherwise, RMAN signals an error.

Typically, you use this command after you have already changed the DB_UNIQUE_NAME initialization parameter of a database and need to update its metadata in the recovery catalog. In general, you should run this command before performing any other RMAN operations on a renamed database. The recommended practice is to execute LIST DB_UNIQUE_NAME before CHANGE DB_UNIQUE_NAME.

Assume that you have changed the DB_UNIQUE_NAME initialization parameter for a standby database from standby_old to standby_new. Typically, you execute CHANGE DB_UNIQUE_NAME in the following scenarios:

  • A LIST DB_UNIQUE_NAME command shows the old DB_UNIQUE_NAME value but does not show the new one (see Example 2-39).

  • A LIST DB_UNIQUE_NAME command shows both the old and new DB_UNIQUE_NAME values. When RMAN connects as TARGET to a database with an unrecognized DB_UNIQUE_NAME, RMAN implicitly registers the instance as a new database. For this reason, LIST DB_UNIQUE_NAME command can show both the old and new names (in this example, standby_old and standby_new) for a database whose DB_UNIQUE_NAME initialization parameter has been changed.

In the scenario in which only the old name is listed, execute CHANGE DB_UNIQUE_NAME FROM standby_old TO standby_new so that RMAN changes the DB_UNIQUE_NAME for standby_old to standby_new in the recovery catalog.

In the scenario in which both the old and new names are listed, RMAN automatically executes the following commands when you run CHANGE DB_UNIQUE_NAME FROM standby_old TO standby_new:

  1. CHANGE ARCHIVELOG ALL FOR DB_UNIQUE_NAME standby_old RESET DB_UNIQUE_NAME

  2. CHANGE BACKUP FOR DB_UNIQUE_NAME standby_old RESET DB_UNIQUE_NAME

  3. UNREGISTER DB_UNIQUE_NAME standby_old

Thus, RMAN changes the association of all backups for the DB_UNIQUE_NAME specified in the FROM clause to the DB_UNIQUE_NAME specified in the TO clause.


resetDbUniqueNameOption

This clause enables you to associate backups made on one database in a Data Guard environment with a different database in the environment. The following table explains the RMAN behavior when different options are specified with RESET DB_UNIQUE_NAME.

Table 2-2 RESET DB_UNIQUE_NAME Options

TO db_unique_name FOR DB_UNIQUE_NAME RMAN Behavior

No

No

RMAN associates the maintSpec files with the target database. RMAN also changes the association of all backups that are not associated with any database.

Typically, you would execute CHANGE with these options after upgrading to an Oracle Database 11g recovery catalog schema, so that you can associate the backups with the target database.

Yes

No

RMAN associates the maintSpec files with the database indicated by the TO db_unique_name. RMAN also changes the association of all backups that are not associated with any database.

No

Yes

RMAN restricts its operations to maintSpec files that are associated with the database in the FOR DB_UNIQUE_NAME clause, and then associates these files with the target database.

Yes

Yes

RMAN restricts its operations to maintSpec files that are associated with the database in the FOR DB_UNIQUE_NAME clause, and then associates these files with the database specified by TO db_unique_name.


Syntax Element Description
RESET DB_UNIQUE_NAME Associates the files in maintSpec with the target database (see Example 2-38). Table 2-2 explains the RMAN behavior when different options are specified.

When changing the association of the files from one database to another database, RMAN deletes the duplicate names from the recovery catalog. For example, if you change the association of datafile copy /d1/df1.bak from database standby1 to database prod, then the recovery catalog has only one record for this file rather than two.

Use caution when specifying the RESET DB_UNIQUE_NAME option because you cannot undo the effect of this command. For example, after you have change the association of the files associated with database standby1 to database prod, the recovery catalog does not retain historical metadata about the database with which these files were previously associated. However, you can unregister database standby1 and connect RMAN again to standby1, but in this case the recovery catalog will be updated with all metadata from the standby1 control file.

   TO db_unique_name Associates the files in maintSpec with the specified database in a Data Guard environment.

changeFailure

This clause enables you to change the status of failures. Use the LIST FAILURE command to show the list of failures.

Syntax Element Description
FAILURE Enables you to change priority or close failures recorded in the Automatic Diagnostic Repository. By default RMAN prompts for confirmation before performing the requested change.

The database to which RMAN is connected must be a single-instance database and must not be a physical standby database.

   ALL Changes only open failures.
   CRITICAL Changes only critical failures.
   HIGH Changes only failures with HIGH priority.
   LOW Changes only failures with LOW priority.
   failnum Changes only the specified failure.
   EXCLUDE FAILURE

   failnum

Excludes the specified failures from the change.

Examples

Example 2-34 Updating Backups to Status UNAVAILABLE

Assume that you have temporarily moved backup set 4 to a different location because of a space issue on disk. The backup, which has the key 4, is still listed as available:

RMAN> LIST BACKUP SUMMARY;

List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
1       B  A  A DISK        24-FEB-07       1       1       NO         TAG20070427T115348
3       B  A  A DISK        24-MAR-07       1       1       NO         TAG20070427T115452
4       B  F  A DISK        24-APR-07       1       1       NO         TAG20070427T115456

You do not want to uncatalog the backup because you plan to move it back to its original location when space has been freed up on the disk. Thus, you make the backup unavailable as follows (sample output included):

RMAN> CHANGE BACKUPSET 4 UNAVAILABLE;
 
changed backup piece unavailable
backup piece handle=/disk2/backup/c-3257893776-20070424-00 RECID=4 STAMP=588858897
Changed 1 objects to UNAVAILABLE status

Example 2-35 Uncataloging and Recataloging Archived Redo Logs

In this example, you move all archived redo logs to a new directory, uncatalog them, and then recatalog them in the new location:

HOST '/bin/mv $ORACLE_HOME/dbs/*.arc /disk2/archlog/';
CHANGE ARCHIVELOG ALL UNCATALOG;
CATALOG START WITH '/disk2/archlog' NOPROMPT;

Example 2-36 Changing a Database Backup into an Archival Backup

This example changes a consistent backup into an archival backup, which you plan to store offsite. Because the database is consistent and therefore requires no recovery, you do not need to save archived redo logs with the backup. The example specifies KEEP FOREVER to indicate that the backup should never become obsolete.

CONNECT TARGET /
CONNECT CATALOG rman/password@catdb
CHANGE BACKUP TAG 'consistent_db_bkup'
  KEEP FOREVER;

Example 2-37 Changing the Status of a Failure

In the following example, the LIST FAILURE command shows that a datafile has corrupt blocks. The failure number is 5 and has a priority of HIGH. You decide to change the priority of this failure to low.

RMAN> LIST FAILURE;

List of Database Failures
Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
5          HIGH     OPEN      11-DEC-06     datafile 8 contains corrupt blocks
 
RMAN> CHANGE FAILURE 5 PRIORITY LOW;
 
List of Database Failures
Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
5          HIGH     OPEN      11-DEC-06     datafile 8 contains corrupt blocks
 
Do you really want to change the above failures (enter YES or NO)? YES
changed 1 failures to LOW priority

Example 2-38 Associating Backups with a New Database in a Data Guard Environment

Assume that standby1, standby2, and standby3 are standby databases in a Data Guard environment. You are planning to remove standby1 from your environment, so you want to association the standby1 backups with your primary database, which is prod. You are also planning to remove standby3 from your environment, so you want to associated the standby3 backups with standby2. You execute the following commands:

CONNECT TARGET SYS/password@prod
CONNECT CATALOG rman/password@catdb
CHANGE BACKUP FOR DB_UNIQUE_NAME standby1 RESET DB_UNIQUE_NAME;
CHANGE BACKUP FOR DB_UNIQUE_NAME standby3 RESET DB_UNIQUE_NAME TO standby2;

Example 2-39 Updating a DB_UNIQUE_NAME in the Recovery Catalog

Assume that a standby database has the DB_UNIQUE_NAME initialization parameter setting of dgrdbms4. You shut down the standby instance, change the DB_UNIQUE_NAME initialization parameter to sfrdbms4, and restart the instance. Later, to update the recovery catalog to reflect the changed unique name, you connect RMAN to the primary database as TARGET, connect to the recovery catalog, and execute the CHANGE command as follows:

CONNECT TARGET SYS/password@prod
CONNECT CATALOG rman/password@catdb
CHANGE DB_UNIQUE_NAME FROM dgrdbms4 TO sfrdbms4;