Using RMAN DELETE, CROSSCHECK, and VALIDATE in Oracle 26ai

CROSSCHECK to reconcile repository status, and VALIDATE to test recoverability.
Lesson 7 used CHANGE to alter RMAN metadata. It showed how AVAILABLE and UNAVAILABLE affect recovery selection, how UNCATALOG removes a record without deleting a physical file, and how KEEP and NOKEEP change retention attributes. This lesson moves to three independent RMAN commands. DELETE and VALIDATE are not options of CHANGE.

Begin every maintenance decision by asking which result you need:

What DELETE changes

DELETE is a destructive maintenance command. When a normal deletion succeeds, RMAN removes the selected backup pieces, image copies, or archived redo logs from disk or through the media manager. It marks the applicable target control-file repository records DELETED. If RMAN is also connected to a recovery catalog, it removes the corresponding catalog rows.

A recovery catalog is optional for an ordinary deletion. The target control file is always an RMAN repository, while a recovery catalog is an additional repository when configured. RMAN must be connected to a target database that is mounted or open. Use an account with the required administrative privilege, normally SYSBACKUP for backup and recovery work.

Do not issue SQL DELETE statements against recovery-catalog tables or RC_* views. Those views are reporting interfaces, not supported DML targets. RMAN commands coordinate the target control file, optional catalog, and storage operation.

Channels, confirmation, and automation

RMAN uses configured channels for deletion. If the selected files reside on a device type for which no automatic channel is configured, allocate a maintenance channel for that device. A configured disk channel can satisfy the disk requirement, so a manual allocation is not required for every command. In Oracle RAC, also verify that the chosen node can reach node-local backup storage.

The following SBT example is intentionally broad and destructive. It is not a general cleanup script:

ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE SBT;
DELETE BACKUP DEVICE TYPE SBT;
RELEASE CHANNEL;

Issue ALLOCATE CHANNEL FOR MAINTENANCE at the RMAN prompt, not inside a RUN block. The target instance must be started. Before using the example, review the media-manager configuration and an exact inventory of the affected backups. Persistent channel configuration is preferable when it matches the operating environment.

In an interactive session, DELETE lists its selections and asks for confirmation unless NOPROMPT is specified. Treat that review as a safety boundary. A command file does not provide the same interactive protection, so automation needs a reviewed selection, approval, complete logging, and post-deletion verification. Use NOPROMPT only when independent safeguards make the scope deterministic:

DELETE NOPROMPT EXPIRED BACKUP;

Review a deletion from policy through verification

A useful maintenance workflow starts with facts rather than a broad deletion. Record the target database and DB_UNIQUE_NAME, current RMAN repository connection, channel configuration, retention policy, archived-log deletion policy, and restore requirements. Then list the relevant backup inventory and crosscheck only the device types that can be reached successfully. A crosscheck performed while storage is unavailable creates misleading evidence rather than a safe cleanup opportunity.

CROSSCHECK BACKUP;
LIST BACKUP SUMMARY;
REPORT OBSOLETE;
DELETE OBSOLETE;
LIST BACKUP SUMMARY;

This sequence illustrates the checkpoints. It must be narrowed or changed for the actual objective. For example, a team investigating missing disk pieces might stop after LIST EXPIRED BACKUP, restore the mount, and crosscheck again. A team enforcing a recovery-window policy might review REPORT OBSOLETE but postpone deletion because an archival copy or pending restore test still depends on a candidate.

Before confirmation, compare the selection with recent backup jobs and known restore paths. After deletion, verify both repository state and the intended storage outcome. Also review the RMAN message stack for partial failures. A command can affect many objects, and success for one piece does not establish success for every selected piece. The retained log should make it possible for another operator to reconstruct exactly what RMAN selected, which device handled it, and which records changed.

Repository status and retention terms

A status describes repository state or recovery eligibility. Obsolescence is a retention-policy decision. These concepts are related, but they are not interchangeable.

A physically missing file can remain recorded as AVAILABLE until a crosscheck or another maintenance operation updates its status. Conversely, a physically present and AVAILABLE backup can be OBSOLETE under the retention policy.

Reconcile storage with CROSSCHECK

Use CROSSCHECK when files might have been removed outside RMAN or when a repository might no longer reflect accessible storage. For disk objects, RMAN checks file headers. For SBT objects, it queries the media manager. It processes records marked AVAILABLE or EXPIRED and updates their status. It does not delete repository records.

CROSSCHECK BACKUP;
LIST EXPIRED BACKUP;
DELETE EXPIRED BACKUP;
LIST EXPIRED BACKUP;

Investigate every unexpected EXPIRED result before deleting its record. An offline tape library, incorrect media-manager parameters, missing credentials, an unmounted file system, or node-local storage can make a valid backup appear absent. After access is restored, another CROSSCHECK can return the record to AVAILABLE.

Crosscheck scope also matters. A disk channel cannot confirm an SBT object, and a media-manager channel cannot prove that a disk path is readable. In environments with multiple backup copies, verify the device type and copy being examined before interpreting the status. The question is not whether an object exists somewhere in the enterprise; it is whether RMAN can access the recorded object through the channel and credentials used for that crosscheck.

DELETE EXPIRED removes records already marked EXPIRED. If an expired record unexpectedly points to a physical file that still exists, DELETE EXPIRED removes the record but does not delete that physical file. This differs from a normal deletion of an available object.

Apply the same distinction when archived logs are the scope:

CROSSCHECK ARCHIVELOG ALL;
LIST EXPIRED ARCHIVELOG ALL;
DELETE EXPIRED ARCHIVELOG ALL;

This sequence reconciles access and removes confirmed expired records. It does not read every archived-log block to test for corruption. Use a scoped VALIDATE ARCHIVELOG operation when integrity is the question.

Delete objects made obsolete by policy

DELETE OBSOLETE removes backups and copies that RMAN determines are no longer required by specified criteria or the configured backup retention policy. Review the candidate set first:

SHOW RETENTION POLICY;
REPORT OBSOLETE;
DELETE OBSOLETE;
LIST BACKUP SUMMARY;

The commands form a review model, not a universal production script. Confirm the recovery-point objective, recovery-time objective, archival backup requirements, current restore-test evidence, Data Guard needs, and storage accessibility before accepting the candidate list. A valid KEEP attribute can exempt an archival backup from normal retention-policy obsolescence.

DELETE OBSOLETE uses the backup retention policy. By contrast, DELETE ARCHIVELOG ALL considers the configured archived-log deletion policy, not the backup retention policy. Never delete archived logs solely because they are old when standby apply, downstream copies, recovery requirements, or compliance retention are unknown. A Fast Recovery Area does not replace an explicit deletion strategy.

Make specific selections and verify them

Obtain actual keys and handles from current LIST output before using specific deletion commands:

DELETE BACKUPSET 123;
DELETE DATAFILECOPY '/backup/prodcdb/users01.dbf';
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
DELETE OBSOLETE;
DELETE EXPIRED BACKUP;

The key, path, and time range above are examples only. Before each deletion, capture an inventory that proves the intended scope. Review the candidate list or interactive prompt, preserve the complete RMAN output, and run a post-deletion LIST operation.

DELETE is different from CHANGE ... UNCATALOG. Deletion removes a selected physical backup or copy and coordinates the repositories. UNCATALOG removes metadata without deleting the physical file. Moving a backup normally requires a controlled uncatalog and recatalog workflow, not deletion of an old row alone. Moving a database data file is a separate database operation.

Use FORCE only as an approved exception

DELETE FORCE BACKUPSET 123;

DELETE FORCE attempts to delete the specified files regardless of whether RMAN finds them and removes the repository records. RMAN ignores I/O errors for the selection and overrides the archived-log deletion policy. These semantics make FORCE high impact. Prefer CROSSCHECK, investigation, and DELETE EXPIRED when those commands accurately describe the condition. Use FORCE only with an approved reason, exact keys or handles, preserved output, and a storage follow-up.

CDB and Data Guard boundaries

In a multitenant database, connect to the CDB root as a common user with SYSDBA or SYSBACKUP to delete archived redo logs. RMAN cannot delete archived redo logs from a PDB connection. Preplugin backups have additional open-mode and privilege requirements, so consult the current command reference before maintaining them.

In Data Guard, association and accessibility are separate. Tape backups are generally accessible across members, while a disk backup is normally accessible only from the database that created it. An unsuccessful deletion can require reconnecting as TARGET to the associated database. Some deletions support FOR DB_UNIQUE_NAME, but DELETE OBSOLETE does not. Do not use FORCE to work around an incorrect association, inaccessible disk, or broken SBT configuration.

Read files and backup sets with VALIDATE

VALIDATE checks for corrupt blocks and missing files, or determines whether a selected backup set can be restored. It does not compare all repository records with storage, change a missing record to EXPIRED, or purge metadata. The target database must be mounted or open. A recovery catalog is not required.

VALIDATE DATABASE;
VALIDATE CURRENT CONTROLFILE;
LIST BACKUP SUMMARY;
VALIDATE BACKUPSET 3871, 3890;

Obtain backup-set keys from the current repository. VALIDATE BACKUPSET reads every block in the selected backup set to determine restorability. It is deeper than CROSSCHECK, which checks a disk header or asks a media manager about an object rather than reading every backup block. If automatic channels are not configured, allocate a suitable channel before validating backup sets on that device type.

From the CDB root, VALIDATE DATABASE covers the whole CDB. A direct PDB connection limits validation to that PDB. An appropriately privileged root connection can use VALIDATE DATABASE ROOT or VALIDATE PLUGGABLE DATABASE for a narrower scope. For large data files, SECTION SIZE can divide validation across multiple channels. Use it only when parallel channels and storage capacity make the extra concurrency beneficial.

Plan validation as a workload and a recovery check

Validation consumes database or backup storage bandwidth and can contend with production work. Define the scope, expected duration, channel count, and acceptable I/O impact before running a database-wide check. Schedule large validations for an appropriate window, monitor the job, and keep the command text with its start and completion times. Narrow validation is useful for investigating a known file or backup set, while periodic broader validation provides stronger coverage of the recovery inventory.

For a backup set with multiple copies, confirm which copy and device type RMAN will use. RMAN normally validates the most recent copy, and device selection can distinguish copies held on different media. If the required backup is on SBT, successful validation also depends on the media-manager configuration and credentials. A failed media lookup is not automatically proof of corrupt backup blocks; examine the complete error stack and restore access before drawing that conclusion.

Choose a command that matches the evidence needed. Validating the current control file establishes readability of that file, not correctness of every catalog row. Validating a backup set establishes that RMAN can read its blocks through the selected path, not that the database can meet a recovery objective from that set alone. Database recovery may also need control-file metadata, archived redo, encryption keys, passwords, parameter files, network access, and documented procedures. A restore and recovery exercise tests how those dependencies work together.

Understand corruption checks and evidence

By default, VALIDATE checks for physical corruption. The CHECK LOGICAL modifier also examines data and index blocks that pass physical checks for logical intrablock problems, such as inconsistent row pieces or index entries. It does not prove application-level correctness, referential integrity, or every interblock relationship.

When validation finds corruption, review the complete RMAN error stack, the alert log, server trace files, and the Automated Diagnostic Repository. RMAN also records relevant corrupt ranges in V$DATABASE_BLOCK_CORRUPTION. Preserve the exact validation scope, device type, channel configuration, diagnostics, and corruption-view results as operational evidence. Do not infer success from the absence of one process error.

Validation improves evidence because it reads blocks, but it does not execute the entire recovery path. A successful validation cannot replace a scheduled restore and recovery test that measures the organization's recovery-point and recovery-time objectives.

Use a controlled maintenance sequence

The decision model is simple: use DELETE for intentional physical removal, CROSSCHECK for repository-to-storage status, DELETE EXPIRED for confirmed expired records, and VALIDATE for readability and corruption evidence. That separation keeps storage, the target control-file repository, and an optional recovery catalog coordinated without confusing metadata cleanup with integrity testing.

The module conclusion follows this lesson. It brings together catalog registration and resynchronization, repository status changes, retention, deletion, reconciliation, and validation as one controlled RMAN maintenance practice.