Create Backup Reports and Lists with Oracle 26ai RMAN

Connect and establish the reporting scope

Run these commands at the RMAN prompt, not in SQL*Plus. Use an account with the required administrative privilege, such as SYSBACKUP, through your established authentication method. A local operating-system-authenticated connection is appropriate only when that operating-system account is authorized. Do not place passwords in reusable report scripts.

For the straightforward workflow here, connect to a mounted or open target database. A recovery catalog is optional. These examples assume a connection to the CDB root unless stated otherwise. Confirm the database identity shown at connection time before interpreting any results. A datafile number from another database is not a reliable identifier for this target.

SHOW ALL;
REPORT SCHEMA;
LIST INCARNATION;

SHOW ALL supplies configuration context, including retention policy and configured devices. REPORT SCHEMA maps file numbers to file names and tablespaces, including temporary files. It describes database structure, not backup coverage. LIST INCARNATION supplies database incarnation history, which matters when reviewing backups around an OPEN RESETLOGS event. Listing that history does not change the current incarnation.

Container scope matters. A SYSTEM tablespace example executed from the root refers to the root's tablespace. For a particular PDB, use documented PDB selection or a supported connection to that PDB. Record the container context with the report so a colleague does not mistake one container's inventory for the whole CDB.

Start with a backup inventory

LIST BACKUP SUMMARY;
LIST BACKUP;
LIST COPY;

The summary is a convenient first pass through backup records. The detailed listing expands the information about backup sets and their pieces and identifies the files or archived logs contained in them. Image copies have their own listing. Comparing these views helps answer whether protection exists as backup sets, copies, or a combination.

A backup set is an RMAN backup structure; a backup piece is a physical file belonging to that set. A set can contain multiple pieces. The word piece does not mean that the backup protects only part of the database. An image copy, by contrast, is a copy of an individual file recorded by RMAN.

Read the object type before interpreting a row. Useful fields include the repository key, device type, status, completion time, tag, and file name or media handle. Detailed output also identifies backed-up datafiles and archived redo sequences. A tag helps locate a job's output, but it is not a substitute for checking the actual contents and dates.

An available status is repository evidence, not a fresh physical inspection. Storage may have changed since RMAN last checked it. Similarly, a familiar weekly tag can appear on multiple runs. When investigating a recovery requirement, relate the file coverage and redo history to the intended recovery point rather than selecting a row solely because its name looks right.

One reference for the eleven LIST examples

The consolidated figure groups the inventory commands with the main report commands. The examples below it provide selectable text and explain the distinctions that are easy to miss in a screenshot.

Inventory database files and copies

LIST COPY;
LIST BACKUP;
LIST BACKUP OF DATABASE;
LIST COPY OF DATAFILE 7;
LIST BACKUP OF TABLESPACE SYSTEM;

The first two commands provide broad inventories. LIST BACKUP OF DATABASE selects backups of database datafiles; use explicit control-file and archived-log selections when reviewing those components. Do not interpret the word database as a promise that every recovery dependency is present in a single backup set.

LIST COPY OF DATAFILE 7 narrows the copy inventory to one file. Obtain its number from the current schema report. LIST BACKUP OF TABLESPACE SYSTEM narrows the backup listing by tablespace, with the root scope described earlier. These focused commands are useful when a broad report is too large to review efficiently.

Inspect archived logs, control files, and tags

LIST COPY OF ARCHIVELOG ALL;
LIST BACKUP OF CONTROLFILE;
LIST BACKUP TAG 'WEEKLY_FULL_DB_BACKUP';

The archived-log copy listing concerns recorded archived redo files and copies. To inspect archived redo stored in backup sets, use LIST BACKUP OF ARCHIVELOG ALL;. These answer different questions: an archived log on disk and a backup containing that log are different objects, even when both protect the same redo sequence.

The control-file selection helps identify recorded control-file backups. The tag selection locates backups bearing the requested tag. Neither proves that the necessary restore credentials, encryption material, media-management access, or recovery instructions are available. Keep those dependencies in the recovery procedure and verify them during a planned recovery exercise.

Filter names and time ranges carefully

LIST COPY LIKE '/u02/backup/%';
LIST BACKUP OF ARCHIVELOG UNTIL TIME 'SYSDATE-30';
LIST COPY OF DATAFILE 7
  COMPLETED BETWEEN 'SYSDATE-7' AND 'SYSDATE';

LIKE in this copy example filters recorded copy names using a pattern. The percent sign matches a variable suffix. Substitute your own naming convention; the example does not search the filesystem or list every backup piece under that directory. A Windows installation can use its recorded Windows path instead.

The second command applies an archived-redo time selection. It is not a request for backups completed more than thirty days ago. The third explicitly selects copies by their completion times. Choosing between redo coverage and backup completion is essential when investigating whether a particular recovery interval is protected.

Relative expressions such as SYSDATE-7 change as time passes. Save the execution time and relevant database time-zone context with the report. For repeatable incident analysis, choose explicit boundaries using the documented date-expression syntax and the session's date-format rules. Avoid ambiguous dates that one operator reads as month/day and another reads as day/month.

Use REPORT to assess backup requirements

After identifying existing objects, ask what protection is missing. Reports analyze repository records according to their particular criteria. Read the criterion printed with the result; an empty report is meaningful only when the database, scope, policy, and repository history are appropriate to the question.

REPORT NEED BACKUP;
REPORT NEED BACKUP REDUNDANCY 2;
REPORT NEED BACKUP RECOVERY WINDOW OF 7 DAYS;
REPORT NEED BACKUP DAYS 7;

The first command uses the configured retention policy. The next two let you evaluate explicit redundancy and recovery-window requirements without changing the configuration. With redundancy two, a reported datafile lacks the required number of backups or copies. With a seven-day recovery window, the report evaluates whether sufficient backups support recovery across that interval.

The final command asks a different question: which files would require more than seven days of archived redo for complete recovery? It does not simply list every file whose latest backup is older than seven days. Offline-file circumstances can affect the assessment. This distinction matters when balancing backup frequency against the amount of redo that recovery must process.

Before interpreting a default report, inspect the configured policy. If the retention policy is NONE, an unqualified policy-dependent report can produce an error. Treat that as missing policy context, not a clean result. Decide on the intended protection requirement with the database owner before changing configuration or drawing conclusions.

Keep obsolete, expired, and unrecoverable separate

REPORT OBSOLETE;
REPORT UNRECOVERABLE;

REPORT OBSOLETE identifies objects no longer required under the applicable retention criteria. It does not delete them. Review the report alongside operational retention requirements and recovery dependencies before a separately authorized cleanup. A backup's age alone is not a sufficient deletion rule.

Expired describes a repository status used when a crosscheck cannot find an object through the applicable storage access. A disconnected filesystem or media-management problem can explain that result. Expired and obsolete are not interchangeable: one concerns an object's accessibility assessment, while the other concerns retention requirements.

REPORT UNRECOVERABLE identifies datafiles affected by unrecoverable operations since their last backup, such as operations performed without the redo needed to reproduce their changes. The appropriate response is to investigate the operation and arrange suitable backup protection. These are not files or backup pieces that the report recommends deleting.

For example, suppose a permitted direct-path load generated insufficient redo after the latest backup. A normal-looking backup inventory does not fill that recovery gap. The unrecoverable report draws attention to the affected datafile so the DBA can address its protection before relying on an older copy plus subsequent redo.

Save a repeatable reporting session

A useful operational report records both the inventory and the assumptions behind it. Start with database identity and policy context, then collect the detailed evidence needed for the review. The following sequence lists and reports repository information without issuing backup, restore, crosscheck, or deletion commands.

SPOOL LOG TO '/u02/rman/reports/backup-review.log';
SHOW ALL;
REPORT SCHEMA;
LIST INCARNATION;
LIST BACKUP SUMMARY;
LIST BACKUP OF DATABASE;
LIST BACKUP OF ARCHIVELOG ALL;
LIST BACKUP OF CONTROLFILE;
REPORT NEED BACKUP;
REPORT OBSOLETE;
REPORT UNRECOVERABLE;
SPOOL LOG OFF;

Create the report directory beforehand and ensure that the operating-system account running the RMAN client can write to it. The spool file belongs to that client environment, which may be different from the database server. Prefer a unique dated filename for each run. Spooling overwrites an existing file by default; use the documented APPEND option only when combining sessions is intentional.

Check the saved log for errors as well as report rows. A failed command halfway through the sequence does not become successful because later output exists. Attach the target identity, container scope, start time, policy being evaluated, and operator's interpretation to the review record. Protect logs appropriately because file names and infrastructure details can be operationally sensitive.

A short conclusion might state that file 7 needs an additional backup under the chosen redundancy criterion, that archived redo inventory requires a separate coverage review, and that obsolete objects await retention review. Keep each conclusion tied to its report. Do not turn a list of filenames into a blanket claim that the database is recoverable.

Interpret gaps and plan follow-up work

If an expected object is absent, first check the target database, container, filters, and repository being queried. Control-file metadata has finite retention, and catalog history depends on the information recorded and maintained there. A missing row can indicate missing metadata rather than a physically missing backup. Conversely, a recorded row does not guarantee the file still exists.

In a Data Guard environment, also consider database association and storage accessibility. Disk paths accessible on one host may be unavailable on another. Record the relevant database identity rather than assuming that every backup associated with the same database family can be read from the connected target.

Historical structure is a separate reporting task. A current REPORT SCHEMA needs no recovery catalog, but an AT clause for a historical schema report requires one. Confirm the available history before trying to reconstruct a prior file layout from today's file list.

Choose follow-up actions according to the uncertainty. CROSSCHECK checks accessibility and updates repository status; it is not merely another read-only report. Backup validation reads the selected backup material and can expose problems that metadata queries cannot. A restore rehearsal goes further by exercising the recovery procedure and its dependencies. Schedule these operations with suitable resources and review their own results.

Oracle 26ai desupports Data Recovery Advisor. Do not use the old LIST FAILURE, ADVISE FAILURE, and REPAIR FAILURE sequence as this lesson's reporting workflow. Use the current inventory and report commands for backup assessment, with separately planned diagnostic or recovery operations where needed.

For a useful handoff, preserve the report, identify each protection gap, assign the next action, and specify how its completion will be checked. After a corrective backup, rerun the relevant inventory and requirement report. This produces evidence for a particular protection decision instead of relying on an earlier job's success message.

Practice: turn report findings into a decision

Consider a morning review in which the weekly backup tag appears in the inventory, but the redundancy report still identifies file 7. Start by resolving file 7 in the schema report. Then inspect backups for that file rather than assuming that the tagged job included it. The job could have a different scope from the protection requirement being assessed.

Next, record the exact criterion that produced the finding. A requirement for two backups is different from a requirement to recover to any point within seven days. Explain which requirement the review is testing and why it applies. If the evidence does not establish the cause, report that uncertainty instead of inventing a failed backup job.

Finally, assign a corrective action and a verification step. For example, the responsible DBA can investigate the backup selection, arrange the required protection, and then rerun the relevant file inventory and redundancy report. Preserve both reports so another operator can compare the before and after evidence. The review is complete when the finding has an explained outcome, not merely when the command window closes.

Oracle 26ai documentation

• Reporting on RMAN operations: reporting workflow and repository context.
• LIST reference and REPORT reference: selection rules and report criteria.
• Archived-log selection and completion-time selection: distinguish redo boundaries from backup completion.
• SPOOL reference and About RMAN commands: log handling and release guidance.

The next lesson examines data dictionary views for additional database information.