Analyze the RMAN Repository with REPORT in Oracle 26ai

The Recovery Manager REPORT command performs detailed analysis of metadata in the RMAN repository. In Oracle AI Database 26ai, it can answer four important operational questions: What physical database structure is recorded? Which data files need another backup? Which recorded backups are obsolete under a retention rule? Which data files have been exposed to unrecoverable operations since their last backup?

RMAN always stores repository metadata in the target database control file. If a recovery catalog is configured, RMAN also maintains metadata in the catalog. The catalog can retain history longer than the control file and can support reporting across databases in a Data Guard environment. The quality of a report therefore depends on the repository records available to the RMAN session.

Choose REPORT, LIST, or SHOW

RMAN has several commands that display repository information, but they answer different types of questions. Choosing the correct command avoids the common mistake of treating every display operation as a report.

There is no current REPORT BACKUP form. Use LIST BACKUP or LIST BACKUP SUMMARY when the goal is to inventory backup sets and pieces. Use SHOW RETENTION POLICY to inspect the active retention setting, then use REPORT OBSOLETE to analyze recorded backups against that setting.

Connections and repository scope

Run REPORT at the RMAN prompt. Normally, RMAN is connected to a mounted or open target database. An alternative is to connect to a recovery catalog and identify the target database by running SET DBID. A recovery catalog is optional for many reports about the current target, but it is required for historical REPORT SCHEMA ... AT analysis and catalog-wide Data Guard reporting.

Use an administrative account appropriate for backup operations, such as a dedicated account granted SYSBACKUP. Avoid putting passwords in shell history or command-line process listings. One interactive connection pattern is:

rman

RMAN> CONNECT TARGET "backup_admin@prodcdb AS SYSBACKUP";
RMAN> CONNECT CATALOG rco@catpdb;

The catalog connection in this example is optional unless the requested report needs catalog history or catalog-wide scope. Before acting on a report, confirm that the session is connected to the intended target, DBID, incarnation, container, and recovery catalog.

Report the recorded database structure

REPORT SCHEMA lists permanent data files, temporary files, and tablespaces for the target database at the current point in time:

REPORT SCHEMA;

In this RMAN command, schema means the physical tablespace and file structure recorded for the database. It does not list an application user's tables, indexes, constraints, views, or PL/SQL objects. Use SQL data dictionary views when the objective is to inspect those logical schema objects.

With a recovery catalog, RMAN can report the structure recorded at an earlier SCN, archived redo log sequence, or time:

REPORT SCHEMA AT SCN 123456789;
REPORT SCHEMA AT SEQUENCE 742 THREAD 1;
REPORT SCHEMA AT TIME 'SYSDATE-1';

The AT clause requires a recovery-catalog connection because the target control file alone is not used for this historical form. Use AT SEQUENCE, not the obsolete Oracle8 wording AT LOGSEQ. A time expression is evaluated according to Oracle date-expression rules and the applicable environment settings, including date format and time-zone behavior. For automation, prefer an unambiguous expression and document the time basis used by the recovery procedure.

A schema report can help reconstruct the database layout expected at a recovery point. It does not establish that the required backups and archived redo logs are accessible. After selecting a recovery point, use restore preview and validation procedures to examine the files RMAN expects to use.

Identify data files that need backup

The default form evaluates the requested data files by using the configured retention policy:

REPORT NEED BACKUP DATABASE;

If the retention policy is disabled with CONFIGURE RETENTION POLICY TO NONE, RMAN cannot perform this default policy-based analysis and reports an error. You can also supply an explicit criterion for a one-time analysis.

Interpret each criterion precisely

DAYS 3 is not a simple statement that a backup is more than three days old. RMAN reports a data file when complete recovery from its most recent backup would require more than three days of archived redo. The result describes redo-application exposure, which can affect recovery time and archived redo log dependencies.

INCREMENTAL 1 reports a data file when recovery would require more than one incremental backup. A file for which no backup exists does not appear in this form. Use REDUNDANCY when the requirement is to expose data files with too few recorded backups, including no backup.

REDUNDANCY 2 means that fewer than two backups or copies are recorded for a data file. It does not prove that two copies are readable, independent, stored on different media, or protected from the same failure. Repository count, storage diversity, media readability, and recovery objective compliance must be assessed separately.

RECOVERY WINDOW OF 7 DAYS asks whether backups provide point-in-time recovery coverage throughout the seven-day window ending at the current database time. This is a coverage question, not merely a backup-count question. Time calculations depend on the documented behavior of SYSDATE and the TIME_AT_DBTIMEZONE initialization parameter.

Analyze obsolescence under a retention policy

A retention policy defines which backups RMAN must retain to meet either a redundancy goal or a recovery window. Review the configured policy before analyzing obsolescence:

SHOW RETENTION POLICY;
REPORT OBSOLETE;

REPORT OBSOLETE evaluates recorded full backups, backup pieces, data file copies, and archived redo logs under the configured policy. If the retention policy is NONE, the no-argument report cannot identify obsolete backups and returns an error. The report identifies repository objects that RMAN considers unnecessary for satisfying the selected retention rule. It does not delete physical files or repository records.

A DBA can perform a one-time analysis with an explicit rule:

REPORT OBSOLETE REDUNDANCY 2;
REPORT OBSOLETE RECOVERY WINDOW OF 14 DAYS;

These options override the criterion for that report only. They do not change the persistent retention policy. The current syntax does not use an equals sign between REDUNDANCY and its value.

A backup can be obsolete under one technical retention policy yet still be required by another operational obligation. Conversely, a recorded nonobsolete backup may be missing from storage. The report's policy analysis and the file's physical status are distinct facts.

Find exposure from unrecoverable operations

Some operations, including certain direct-path loads and changes performed with NOLOGGING, do not generate the redo normally required for media recovery. REPORT UNRECOVERABLE identifies data files affected by such an operation since their most recent backup:

REPORT UNRECOVERABLE DATABASE;

The report can indicate that a full or incremental backup is required to protect an affected data file. After the appropriate backup completes, the exposure covered by that backup should no longer be reported. The operational response is therefore to identify the workload responsible for the unrecoverable change and create the required backup promptly.

The word unrecoverable has a narrow meaning here. It refers to recorded data-file changes for which redo was not generated. The report does not validate backup headers or blocks, prove that required archived redo logs exist, or certify that every logical object can be recovered. Empty output means RMAN found no data file needing backup because of a recorded unrecoverable operation since that file's last backup. It does not prove general database recoverability.

CDB, PDB, and Data Guard scope

Oracle 26ai reporting supports multitenant scope. When connected to a CDB root, a supported report object can refer to the root, one or more PDBs, the database, tablespaces, or data files. For example:

REPORT NEED BACKUP DATABASE ROOT;
REPORT NEED BACKUP PLUGGABLE DATABASE salespdb;

Connect to the root when using the PDB object clause for one or more pluggable databases. When connected directly to a PDB, tablespace and data-file references are interpreted within that container's scope. Confirm the exact object form supported by the selected report before using it in an automated command file.

In a Data Guard environment, each backup is associated with the primary or standby database that created it through DB_UNIQUE_NAME. A recovery catalog is required for the shared Data Guard repository. Catalog-wide schema reporting can use the documented database scope:

REPORT SCHEMA FOR DB_UNIQUE_NAME standby1;
REPORT SCHEMA FOR DB_UNIQUE_NAME ALL;

Without explicit DB_UNIQUE_NAME scope, reporting output is influenced by the files accessible to the connected target. Association tells RMAN which database created a backup; accessibility determines whether the connected database can use the file through the configured storage or media-management environment.

Move from metadata to recovery evidence

Repository reports are valuable, but recovery confidence grows through several different checks. Each step answers a different question:

RESTORE ... VALIDATE HEADER goes beyond a preview by checking whether backup-file headers correspond to repository metadata. Broader validation reads the content selected by the command. A controlled restore test provides the strongest operational evidence because it exercises the documented procedure, credentials, channels, storage access, and destination environment together.

Operational reporting checklist

1. Confirm the target database, DBID, incarnation, container, DB_UNIQUE_NAME, and catalog connection.
2. Run SHOW RETENTION POLICY before interpreting policy-based NEED BACKUP or OBSOLETE results.
3. Use REPORT SCHEMA for physical file structure, not application schema objects.
4. Select the NEED BACKUP criterion that matches the recovery decision, then account for the criterion's limitations.
5. Review obsolete results against organizational retention requirements before authorizing deletion.
6. Treat UNRECOVERABLE as a focused warning about missing redo and data-file backup exposure.
7. Reconcile repository records with storage, validate critical backup content, preview restore selection, and perform scheduled restore tests.
8. Save report output in the RMAN message log or an approved monitoring system so that changes and exceptions can be reviewed over time.

REPORT answers analytical questions about schema history, backup need, obsolescence, and unrecoverable operations. In Lesson 5, you will use the RMAN LIST command to inventory the backup sets, copies, archived redo logs, incarnations, and scripts recorded in the repository. LIST complements REPORT, but it is not an interchangeable synonym.