CHANGE

Syntax

Text description of the illustration rcmsynta60.gif

Purpose

To make the following changes:

• Change the status of backups, copies, and archived logs in the repository to AVAILABLE or UNAVAILABLE. This feature is useful when a previously unavailable file is made available again, or you do not want a specific backup or copy to be eligible to be restored but also do not want to delete it.
• Remove catalog records for backups and copies, and update the corresponding records in the target control file to status DELETED. This feature is useful when you remove a file by using an operating system command rather than the RMAN CHANGE command, and want to remove its repository record as well.
• Specify that a backup or copy should either abide by the currently configured retention policy or be exempt from it.

  See Also: Oracle9i Recovery Manager User's Guide to change the availability status of a backup or copy, and Oracle9i Recovery Manager User's Guide to learn how to make a backup or copy exempt from the retention policy

Restrictions and Usage Notes

• Execute the CHANGE command within the braces of a a RUN command or at the RMAN prompt.
• The target instance must be started.
• Use CHANGE only on files that are recorded in the RMAN repository and belong to the current database incarnation.
• The KEEP FOREVER clause requires use of a recovery catalog.
• The only CHANGE command that requires either a manual or automatic maintenance channel is the CHANGE ... AVAILABLE command. However, a maintenance channel is not required 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.

Keywords and Parameters

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

Syntax Element	Description
BACKUP	Operates on the specified backups: backup sets, backup pieces, and proxy copies. If you do not specify an option for BACKUP, then CHANGE BACKUP operates on all backups recorded in the repository. Note: Use the KEY column of the LIST output to obtain the primary key usable in the CHANGE command.
COPY	Operates on datafile copies, archived redo logs, and image copies of archived redo logs. If you do not specify an option for COPY, then CHANGE COPY operates on all copies recorded in the repository.
OF listObjList	restricts the list of objects operated on to the object type specified in the listObjList clause. If you do not specify an object, then CHANGE defaults to all copies. Note that CHANGE COPY OF DATABASE includes datafiles but not control files. See Also: "listObjList"
maintQualifier	restricts the command based on the specified options. See Also: "maintQualifier"
archivelogRecordSpecifier	Specifies archived logs. See "archivelogRecordSpecifier".
recordSpec	Specifies the object whose availability status you are changing. See "recordSpec".
AVAILABLE	Changes the status of a backup or copy to AVAILABLE in the repository. View the status in the LIST output or recovery catalog views.
UNAVAILABLE	Changes the status of a backup or copy to UNAVAILABLE in the repository. View the status in the LIST output or recovery catalog views. This option is provided for cases when the 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.
UNCATALOG	Removes references to a datafile copy or archived redo log (but not a backup piece or backup set) from the recovery catalog, and updates records in the target control file to status DELETED. 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. Caution: If you resynchronize from a backup control file, or upgrade the recovery catalog, then uncataloged records can sometimes reappear in the catalog metadata.
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.
keepOption	Changes the exemption status of a backup or copy in relation to the configured retention policy. For example, specify CHANGE ... NOKEEP to make a backup that is currently exempt from the retention policy eligible for OBSOLETE status. Note: You can also specify KEEP in the backupSpec clause. See Also: "keepOption"

Examples

Updating Backups to Status UNAVAILABLE: Example

This example changes the status of backup set 100 as well as all backups of server parameter files created more than one day ago to UNAVAILABLE. You do not need to allocate a maintenance channel:

CHANGE BACKUPSET 100 UNAVAILABLE;
CHANGE BACKUP OF SPFILE COMPLETED BEFORE 'SYSDATE-1' UNAVAILABLE;

Uncataloging and Cataloging Archived Logs: Example

In this example, you first move all archived logs to a temporary directory and then uncatalog them:

HOST 'mv $ORACLE_HOME/oradata/trgt/arch/* /tmp/arch';
CHANGE COPY OF ARCHIVELOG ALL UNCATALOG;
EXIT;

From the UNIX command shell you use Perl to create a command file that contains a CATALOG command for each archived log:

% perl5 -e '@files=</tmp/arch/*>; foreach (@files) \
? {print "CATALOG ARCHIVELOG '$_'\;\n";}' > $HOME/rman.cmd

Finally, you start RMAN and run the command file to catalog the relocated logs:

% rman TARGET / @$HOME/rman.cmd

Changing the Retention Status of a Backup Set: Example

This example, which requires a recovery catalog, changes an ordinary backup into a long-term backup:

CHANGE BACKUP TAG 'consistent_db_bkup'
  KEEP FOREVER NOLOGS;