Using the Change Command

You will rarely run into a situation where you want to change the information in your recovery catalog. On those rare occasions, you can use the change command. The change command works only on backup set, backup pieces, data file copies, and archive log and control files. Some of the change command options work with or without a recovery catalog. The basic syntax for a change command is:

rman>change <filetype> <name> <option>;

The <filetype> options are archivelog, backuppiece, backupset, controlgilecopy, and datafilecopy. The <name> is usually a quoted string that identifies a file. The valid choices for the <option>; keyword are in the table below.

Option	Used with or without a recovery catalog	Description
uncatalog	With	Removes references from the catalog. Use this to notify Recovery Manager when you have deleted items by means other than thechange deletecommand, which is covered in the next lesson.
unavailable	With	Marks references as unavailable. Use this when a file cannot be found or may have been relocated. Files marked unavailable will not be used during a restore or recovery operation.
available	With	Marks references as available. If an unavailable file is located, it can be made available for use during a backup or restore.
delete	With and without	Removes references from the catalog and deletes the physical OS file. This option is covered in the next lesson.
validate	With and without	Removes references from the catalog and control file. This option is covered in the next lesson.

In this first example, your D disk is lost and the data file copy on that drive is no longer available. Hence, you do not want Recovery Manager to consider this backup file during a recovery strategy.

rman>change datafilecopy 
'd:\backup\userorc1.dbf' uncatalog;

In Oracle 11g R2, the syntax for marking archived redo logs as unavailable is similar to Oracle 8. However, it is often recommended to use fully qualified commands^[1] and specify the appropriate paths or configure RMAN channels if needed.
Here’s an updated RMAN script for Oracle 11g R2:

#----- script starts
RMAN> CONNECT TARGET /;

RUN {
    CHANGE ARCHIVELOG '/path/to/your/archivelogs/arc474.1' UNAVAILABLE;
    CHANGE ARCHIVELOG '/path/to/your/archivelogs/arc473.1' UNAVAILABLE;
}

RMAN> EXIT;
#----- script ends

Key Adjustments for Oracle 11g R2:

1. Use fully qualified paths for the archived redo logs.
2. Encapsulate commands within a RUN block to allow for more complex scripting.
3. Include the CONNECT TARGET /; command to establish a connection to the target database if not already connected.
4. Make sure to replace /path/to/your/archivelogs/ with the actual path of your archived logs.

This script marks specific archived logs as unavailable in Oracle 11g R2. Remember to adjust paths as per your environment.

In this next example, you are moving some of your archivelogs to a remote location and the remote location is down.
You do not want RecoveryManager to consider these files during a recovery strategy.

rman>change archivelog 'd:\backup\arch_0001.rdo',  
'd:\backup\arch_0002.rdo' unavailable;

The provided RMAN script marks the specified archive logs as unavailable:

change archivelog 'd:\backup\arch_0001.rdo', 'd:\backup\arch_0002.rdo' unavailable;

What This Script Will Do
When this script is executed, Recovery Manager (RMAN) will:

1. Mark the specified archive log files as unavailable:
   • d:\backup\arch_0001.rdo
   • d:\backup\arch_0002.rdo
2. Exclude these logs from recovery operations:
   • Since they are marked as unavailable, RMAN will not consider these files as part of any recovery strategy. This can be useful when the files are inaccessible, such as when they are stored in a remote location that is currently down.
3. Attempt alternative recovery strategies if needed:
   • If RMAN needs these specific archive logs for recovery, it will try to use any available backups or other logs to fulfill the recovery requirements. If it cannot locate alternative resources, recovery could potentially halt, depending on the criticality of these logs.

By marking the logs as unavailable, you are effectively telling RMAN not to expect these specific files during a recovery session until they are made available again.

We have just mentioned the change command and explained how it can be used to modify the retention window assigned to a specific backup. The change command allows you to change the status of a backup. You might have a case where one of your backup media devices becomes unavailable for a period of time (perhaps someone spilled a drink down the power supply). In this event, you can use the change command to indicate that the backups on that device are unavailable. Once you have properly scolded the employee for fiddling around in your hardware area with a drink and have fixed the device, you can change the status of that backup set with the change command again so that it will take on an AVAILABLE status. You can also change a backup status to UNAVAILABLE, indicating that the backup is not currently available. This effectively disqualifies the backup from consideration during restore and recovery operations, but protects the backup record from being removed during the execution of the delete expired command. Some change commands, such as the change unavailable command, are not valid when the backup set pieces are stored in the FRA.
Here are some examples of the use of the change command:

change backup of database tag = 'GOLD' unavailable;
change backup of database like '%GOLD%' unavailable;
change backupset 33 unavailable;
change backupset 33 available;
change archivelog 'd:\oracle\mydb\arch\arch_001.arc' unavailable;

Using the change command, you can modify the status of archived redo log backups. For example, you can modify the status to UNAVAILABLE for all archived redo logs that have been backed up at least a given number of times. You can also change the status of all backups that occurred using a given device.

In Oracle RMAN (Recovery Manager), the `CHANGE` command is used to update the status or attributes of backups, backup sets, or archived logs in the RMAN repository. The specific effects of the commands in your script are as follows:

1. `change backup of database tag = 'GOLD' unavailable;`

   This marks all backups (datafiles, archived logs, control files, etc.) with the tag `GOLD` as unavailable in the RMAN repository.

   • Effect:
   • RMAN will not consider these backups during restore or recovery operations.
   • Useful when the tagged backups are moved, corrupted, or otherwise inaccessible.
2. `change backup of database like '%GOLD%' unavailable;`

   This marks all backups with tags containing 'GOLD' as a substring as unavailable.

   • Effect:
   • Similar to the first command but matches any tag containing 'GOLD' (e.g., `GOLD001`, `MY_GOLD_BACKUP`).
   • Broader in scope than the first command.
   • Useful for handling multiple backups with similar naming conventions.
3. `change backupset 33 unavailable;`

   This marks backup set 33 as unavailable.

   • Effect:
   • Specifically targets backup set number 33, making it ignored by RMAN for restore/recovery.
   • Backup set 33 remains in the repository but flagged as unusable until re-marked as available.
4. `change backupset 33 available;`

   This marks backup set 33 as available again.

   • Effect:
   • Reverses the effect of the previous command.
   • RMAN will now include backup set 33 during restore/recovery operations if needed.
5. `change archivelog 'd:\oracle\mydb\arch\arch_001.arc' unavailable;`

   This marks the specific archived log file located at 'd:\oracle\mydb\arch\arch_001.arc' as unavailable.

   • Effect:
   • RMAN will ignore this specific archived log during recovery.
   • Useful if the log is moved, missing, or corrupted.

General Use Cases for These Commands

• Marking unavailable backups/logs: Useful when files are temporarily inaccessible or no longer needed, but you don't want to delete the metadata from the RMAN repository.
• Re-enabling backups: Restores availability after ensuring the file is accessible again.
• Backup management: Helps in organizing which backups RMAN should consider without removing entries from the repository.

Important Notes

1. Why "Unavailable"?
   • The unavailable status helps RMAN avoid errors during recovery or validation operations when the files are missing or inaccessible.
   • It allows temporary exclusion without permanently unregistering or deleting the backup.
2. Re-enabling (Available):
   • When backups or logs are reintroduced (e.g., a tape is remounted or a disk location is restored), marking them as available ensures RMAN can use them again.
3. Consistency:
   • After marking backups/logs unavailable, ensure recovery or restoration plans are updated to avoid relying on excluded files.

In the next lesson, you will learn how to use the delete and validate commands.

[1] fully qualified commands: Fully qualified commands in the context of RMAN scripts means writing out the complete and unambiguous syntax for each command, leaving no room for interpretation or reliance on defaults. This includes specifying the full path for files (like the archived redo logs in your example), explicitly naming the database and any necessary parameters, and avoiding any abbreviated command forms. This practice ensures that the RMAN script executes as intended, regardless of the environment or settings where it's run.