Using the RMAN CHANGE Command in Oracle 26ai

Lesson 6 explained when Recovery Manager (RMAN) automatically resynchronizes a recovery catalog and when an operator should issue RESYNC CATALOG. Resynchronization transfers available metadata from a known control-file source. It does not deliberately assign a new status to a backup, change its retention attributes, or associate it with another member of a Data Guard environment. Those are supported uses of the RMAN CHANGE command.

CHANGE modifies records in the RMAN repository. The repository always includes metadata in the target database control file and can also include a recovery catalog when RMAN is connected to one. Some clauses require a recovery catalog, while others can update repository records without one. For this reason, CHANGE should not be described as a command that only alters recovery-catalog information.

The command is useful during planned media movement, a temporary storage outage, archival-backup retention changes, repository cleanup after files were removed outside RMAN, or Data Guard metadata maintenance. Every use must be deliberate. A broad or incorrect selection can exclude needed backups from recovery, remove repository history, or change which database owns a recorded backup.

A safe workflow: inspect, select, change, and verify

Do not begin with a copied backup key, path, or tag from a course example. Repository keys and handles belong to a particular target database and RMAN repository. Start by inspecting current metadata, identify the narrowest supported selection, issue the change, and verify its exact scope.

1. Inspect: Use LIST or an appropriate recovery-catalog view to find current keys, handles, tags, device types, statuses, completion times, and database associations.
2. Select: Prefer a specific backup-set key, backup-piece key, exact archived-log name, exact tag, completion range, or device type that represents the intended records.
3. Change: Confirm catalog, channel, storage, Fast Recovery Area, and Data Guard prerequisites before issuing the command.
4. Verify: Run a focused LIST command. If restore selection is affected, use RESTORE ... PREVIEW or another approved recovery-planning check.

The following sequence illustrates the workflow. Backup-set key 33 is only an example. In an actual environment, obtain the key from the current target's repository output:

LIST BACKUP SUMMARY;
LIST BACKUPSET 33;
CHANGE BACKUPSET 33 UNAVAILABLE;
LIST BACKUPSET 33;

The command changes metadata only. It does not move, delete, damage, or test the backup pieces in backup set 33. The final LIST verifies that RMAN changed the selected record rather than some broader set of backups.

Principal CHANGE actions for backup maintenance

The complete Oracle 26ai grammar contains many selectors and qualifiers. It is more accurate to organize the backup-maintenance behavior by action than to teach a generic CHANGE <filetype> <name> <option> template. Not every selector and action combination is valid, and several actions have clause-specific prerequisites.

Marking backups AVAILABLE or UNAVAILABLE

Use UNAVAILABLE when a recorded backup or copy is temporarily inaccessible and should not be selected by RESTORE or RECOVER. Examples include an offsite tape awaiting recall, an offline tape library, or an unavailable network-mounted backup location. The record remains in the repository, which makes the status reversible when the storage becomes accessible again.

RMAN does not first verify whether a file exists when assigning UNAVAILABLE. The operator is deliberately changing the repository status. This differs from CROSSCHECK, which compares recorded files with accessible storage and can mark absent objects EXPIRED.

After storage access is restored, use AVAILABLE to return the backup to eligible status. RMAN searches for the selected file and verifies that it exists before changing the status:

LIST BACKUPSET 33;
CHANGE BACKUPSET 33 AVAILABLE;
LIST BACKUPSET 33;

For backups on nondisk media such as SBT, CHANGE ... AVAILABLE can require an automatic maintenance channel or a manually allocated maintenance channel of the appropriate device type. A maintenance channel is not required for disk-only ARCHIVELOG, DATAFILECOPY, or CONTROLFILECOPY objects.

Changing a record to AVAILABLE confirms that RMAN can find the object through the required media access path. It does not perform the same block-level work as VALIDATE, and it does not prove that a complete recovery can succeed.

Archived redo logs at an unavailable off-FRA location

Assume two archived redo log copies are recorded at an off-FRA filesystem that is temporarily offline. First obtain their exact names from LIST output. Do not invent filenames from a naming convention:

CHANGE ARCHIVELOG
  '/backup/prodcdb/arch/arch_000104_1172239911.arc',
  '/backup/prodcdb/arch/arch_000105_1172239911.arc'
  UNAVAILABLE;

LIST ARCHIVELOG
  LIKE '/backup/prodcdb/arch/arch_00010%';

RMAN will not consider those copies for restore or recovery while their status is UNAVAILABLE. Another recorded copy or backup might satisfy the same redo requirement, but an alternate path is not guaranteed. Recovery can stop if no accessible file covers the required redo range. Review the recovery plan and use RESTORE ... PREVIEW when the change could affect a scheduled or emergency restore.

When the remote filesystem returns, issue CHANGE ... AVAILABLE only after the target host and RMAN media path can access the files. Then verify the new status and repeat the recovery-planning check if those logs are part of an active strategy.

Selecting records by tag or device type

An exact tag can select a related group of database backups:

LIST BACKUP OF DATABASE TAG 'GOLD';
CHANGE BACKUP OF DATABASE TAG 'GOLD' UNAVAILABLE;
LIST BACKUP OF DATABASE TAG 'GOLD';

TAG 'GOLD' is an exact tag selection. Do not use a LIKE pattern and describe it as a substring search against tags. A LIKE qualifier can be associated with handles or filenames in supported contexts, but it is not a tag-pattern operator.

RMAN can also restrict a backup selection by device type. For example, CHANGE BACKUP OF DATABASE DEVICE TYPE DISK UNAVAILABLE; is a broad operation that can affect many disk backups. Review the complete candidate set first, confirm that every selected file is eligible for the action, and avoid broad status changes when a specific key or tag can express the actual intent.

Removing repository records with UNCATALOG

CHANGE ... UNCATALOG removes references to selected data-file copies, backup pieces, backup sets, or archived redo logs from the RMAN repository. It updates applicable records in the target control file to DELETED. The physical backup or copy is not deleted.

This action is appropriate when a known file was deleted by an operating-system or storage operation outside RMAN and its metadata must be removed. If the goal is to discover whether recorded files are still present, begin with CROSSCHECK. Do not use UNCATALOG as a substitute for comparing the repository with storage.

A controlled archived-log relocation can use the following repository sequence after the operating-system move has been completed and verified:

CHANGE ARCHIVELOG ALL UNCATALOG;
CATALOG START WITH '/backup/prodcdb/arch-relocated/' NOPROMPT;
LIST ARCHIVELOG ALL;

The first command removes the old records; it does not move the files. The second command inspects the new path and catalogs eligible files. The final inventory verifies the repository state. Because ALL is broad, this sequence requires a validated inventory, an approved change plan, and a recovery path if the relocation or recataloging does not complete as expected.

Uncataloging is not guaranteed historical erasure. Records removed with CHANGE ... UNCATALOG can reappear if the recovery catalog is later resynchronized from a backup control file containing those records or when the recovery catalog is upgraded. Preserve operational evidence about why the records were removed.

Changing archival retention with KEEP and NOKEEP

CHANGE can also alter whether an eligible backup is exempt from the configured retention policy. This operation changes repository attributes; it does not copy the backup to immutable media, verify its contents, or establish organizational retention requirements.

LIST BACKUPSET 333;
CHANGE BACKUPSET 333 KEEP FOREVER;
LIST BACKUPSET 333;

LIST BACKUPSET 123;
CHANGE BACKUPSET 123 NOKEEP;
LIST BACKUPSET 123;

KEEP FOREVER makes the selected archival backup exempt from normal obsolescence under the configured retention policy. It requires a recovery catalog because indefinite archival metadata must outlive the reusable records in a target control file. Applying KEEP FOREVER does not by itself make the backup self-contained, readable, or legally compliant.

NOKEEP removes existing KEEP attributes and returns the backup to normal retention-policy evaluation. It does not immediately delete the backup. A later REPORT OBSOLETE or DELETE OBSOLETE operation evaluates it under the configured policy.

The RESTORE POINT option is not valid with CHANGE. Restore-point syntax can be part of creating an archival backup with BACKUP ... KEEP, but it cannot be added later through CHANGE. Also, KEEP attributes cannot be used for files stored in the Fast Recovery Area.

Storage and media restrictions

Before changing status or retention attributes, determine where the selected files reside and which media management path RMAN must use. The same action is not valid for every storage type.

Do not use an FRA pathname in an UNAVAILABLE example or assume that a general disk selector excludes FRA files. Inspect the selected records and their storage locations before issuing a broad command.

Data Guard metadata and backup associations

In a Data Guard environment, RMAN stores metadata for primary and standby members in a recovery catalog. If a standby's DB_UNIQUE_NAME initialization parameter is changed, update the recorded name before performing other RMAN work against the renamed member:

LIST DB_UNIQUE_NAME OF DATABASE;
CHANGE DB_UNIQUE_NAME FROM standby_old TO standby_new;
LIST DB_UNIQUE_NAME OF DATABASE;

This command requires RMAN to be connected to a recovery catalog and a mounted target database. The target database must not itself have the old DB_UNIQUE_NAME specified in the FROM clause. The first LIST determines whether the catalog contains the old name, the new name, or both, and the final LIST verifies the result.

The RESET DB_UNIQUE_NAME clause can reassociate selected backups or copies with a different database in the Data Guard environment. This is an advanced, high-impact operation. Oracle warns that it cannot simply be undone and that the catalog no longer retains the prior database association for the changed files. Build the command from a verified Data Guard topology and a narrowly reviewed file inventory rather than from a generic course example.

Choose the command that matches the maintenance need

CHANGE, CROSSCHECK, DELETE, VALIDATE, and CATALOG address different repository or backup questions. In particular, DELETE and VALIDATE are independent RMAN commands. They are not actions appended to CHANGE.

Verify operational and recovery impact

A successful RMAN command confirms that the requested repository operation completed. It does not prove that the selection represented the operator's intent or that the remaining backups can satisfy a recovery objective. Preserve the pre-change inventory, exact command, RMAN output, target DBID, DB_UNIQUE_NAME, device type, start and completion times, and post-change inventory.

• After AVAILABLE or UNAVAILABLE, use a focused LIST to confirm the new status.
• After a broad tag or device-type change, compare pre-change and post-change inventories to prove the affected scope.
• After UNCATALOG, confirm repository removal and separately confirm whether the physical file should remain.
• After KEEP or NOKEEP, display the backup's retention attributes.
• After a Data Guard association change, inspect DB_UNIQUE_NAME metadata and the affected backup inventory.

When status changes can influence an upcoming restore, run RESTORE ... PREVIEW, VALIDATE, or an approved restore test as appropriate. A repository record marked AVAILABLE is not a substitute for tested recoverability, and an unavailable file does not imply that RMAN has a usable alternate copy.

Next lesson

The CHANGE command updates supported repository status, retention attributes, and selected Data Guard metadata. Lesson 8 explains the separate DELETE and VALIDATE commands. DELETE performs supported removal of selected backups or records, while VALIDATE reads data or backups to detect recoverability-related problems. Neither command is an option of CHANGE.