Report Backup Sets and Datafile Copies in Oracle 26ai

Establish the target, container, and policy

Connect through your approved RMAN authentication method with the required privilege, such as SYSBACKUP. For the examples below, use a mounted or open target database and a CDB-root connection. A recovery catalog is optional for ordinary inventory reporting, but necessary for the historical schema example later in this lesson.

Local operating-system authentication can be appropriate for an authorized database administration account. Avoid embedding catalog passwords in command lines, scripts, or saved reports. Confirm the database identity displayed at connection time, and record whether the session uses a recovery catalog. Do not assume that a previously used terminal still targets the intended database.

SHOW ALL;
REPORT SCHEMA;

The configuration provides the retention-policy context. The schema report maps file numbers to names and tablespaces. Use that mapping before substituting a datafile number into a command. A file called 7 in one database may have a different role in another, and file names can change after a migration.

State the container scope in the review. A tablespace selection for SYSTEM from the root refers to the root's tablespace. A PDB has its own context. If the question concerns a particular PDB, select it using supported RMAN syntax or a suitable PDB connection and record that narrower scope with the results.

Distinguish a backup set, a piece, and a copy

A backup set is an RMAN backup structure that can contain data from one or more input files. It is stored in one or more physical backup pieces. The listing therefore has both logical content information and physical output information. A piece is not a synonym for a partial database backup.

A datafile image copy represents an individual datafile in its native file format. It has a different role from a backup piece and a separate repository record. Keep the distinction visible in your report: several pieces from one set do not automatically represent several independent backups of a datafile.

For each finding, preserve the database identity, object type, repository key, file coverage, completion time, status, device type, and handle or path shown by RMAN. Keys identify records in a particular repository context. Do not copy a key from an old report and assume it identifies the same operational object in a different target or catalog session.

Inventory backup sets and their contents

LIST BACKUP SUMMARY;
LIST BACKUP;
LIST BACKUP BY FILE;
LIST BACKUP OF DATABASE;

Begin with the summary to locate relevant backups, then inspect detailed output. The file-oriented view helps when the question starts with a datafile rather than a backup job. The database selection narrows attention to backups of database datafiles. Use explicit archived-log and control-file selections when reviewing those recovery dependencies.

Read the set and piece details together. A set containing the desired file is useful evidence, but its associated pieces must also be accessible for the intended restore. Completion time and tag help locate a run; they do not establish its full contents. Reused tags can identify multiple backup operations.

When a report contains more rows than expected, check whether it includes several runs, devices, or objects within a set. When it contains fewer rows, check your selection before declaring a backup missing. An inventory organized by backup and one organized by file can describe the same protection from different directions.

Report datafile copies separately

LIST COPY OF DATABASE;
LIST COPY OF DATAFILE 7;

These commands focus on recorded database-file copies and a selected datafile's copies. The broader LIST COPY; command also includes archived redo information, so do not label every row in its output as a datafile image copy. Read the object type, status, and path before using the record in an assessment.

A listing can include unusable, expired, or unavailable copies. Presence in the repository does not guarantee that a copy can be restored now. Compare the recorded location with the storage accessible to the connected environment, and preserve any uncertainty as a follow-up item rather than silently treating every listed object as healthy.

If your report groups results by a backup tag or completion interval, explain that selection in its heading. An operator reviewing only the exported text should be able to distinguish an intentionally filtered inventory from a complete database inventory. This avoids turning a convenient search into an unsupported coverage claim.

Determine which backups are obsolete

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

The first report uses the configured retention policy. The next two assess explicit alternative criteria without changing that configuration. Run them as separate questions and label their outputs accordingly. A result under redundancy two is not automatically the result under a fourteen-day recovery window.

Redundancy is evaluated in relation to the protected datafiles. For example, two newer backup jobs are not enough evidence that every file in an older set has sufficient newer protection. Inspect the relevant file coverage instead of counting job names or pieces in a directory.

A recovery window concerns recovery points within an interval. An older backup may remain necessary to reach the earliest point in that window, together with the required incremental backups and archived redo. Consequently, a fourteen-day window is not an instruction to delete everything whose completion date is more than fourteen days old.

Oracle's current obsolete-selection syntax supports either a recovery window or redundancy in one command, not both together. The figure's fourteen-day window is a modern alternative to the legacy combined redundancy/time example. It is a different policy question, not a word-for-word translation of that old command.

Before using an unqualified report, review the policy shown by SHOW ALL. With retention policy NONE, the default policy-dependent report can fail. A command error is not a report of zero obsolete objects. Save the error and resolve the policy question before writing a conclusion.

REPORT OBSOLETE performs analysis; it deletes nothing. Review proposed cleanup against recovery objectives, required retained backups, and operational obligations. Keep deletion as a separately authorized maintenance activity, with its own target selection and verification. This lesson's reporting script intentionally contains no deletion commands.

Seven REPORT examples for Oracle 26ai

The consolidated reference below replaces the old screenshot sequence. Its commands address different questions: recovery workload, retention, protection after unrecoverable operations, and historical structure. The following explanations make those distinctions explicit.

1 and 2: Assess archived redo needed for recovery

REPORT NEED BACKUP DAYS 7 DATABASE;
REPORT NEED BACKUP DAYS 30 TABLESPACE SYSTEM;

These reports concern the amount of archived redo required for complete recovery. The first applies a seven-day threshold to the database; the second applies a thirty-day threshold to the root's SYSTEM tablespace in this session. Neither means simply “show backups older than this many days.”

Use the results when assessing how backup frequency affects recovery work. A file needing a long redo sequence may warrant fresher protection. Record the threshold used, and investigate the file's circumstances before assuming the finding has the same cause as a missed scheduled job.

3: Assess the incremental recovery chain

REPORT NEED BACKUP INCREMENTAL 5 DATAFILE 7;

This test asks whether complete recovery of file 7 requires more than five incremental backups. Five is a count, not a number of days or a requested point-in-time recovery interval. The test excludes files with no backups; use an appropriate redundancy report when investigating that separate gap.

4 and 5: Compare retention criteria

The redundancy and recovery-window commands shown earlier provide alternative obsolete assessments. Preserve both the criterion and its output if comparing policies. Do not combine their rows into one unlabeled cleanup list: each result answers a different question and may retain different recovery dependencies.

6: Identify unrecoverable operations since backup

REPORT UNRECOVERABLE DATABASE;

This report identifies datafiles affected by unrecoverable operations since their last backup, such as operations without sufficient redo to reproduce their changes. Investigate the affected files and arrange suitable protection. The result identifies a backup need; it is not a list of objects safe to delete.

7: Inspect a historical schema

REPORT SCHEMA AT TIME 'SYSDATE-14';

This asks for the recorded file and tablespace structure fourteen days ago. A recovery catalog with relevant history is required for the historical AT clause. Use REPORT SCHEMA; for the current structure. Record execution time and date context because the relative expression changes on each run.

Separate accessibility checks from retention analysis

Available and expired are repository status information; obsolete is a retention conclusion. An object can be present on storage yet obsolete under a policy. Another object may still be needed but be marked expired because a crosscheck could not find it through the applicable storage access.

A crosscheck can help reconcile recorded status with accessibility, but it changes repository metadata. It is not a prerequisite that must be inserted into every read-only report. Perform it under the established maintenance procedure after confirming storage and channel configuration. For example, a disk-backup check has this form:

CROSSCHECK BACKUP DEVICE TYPE DISK;

This example is a maintenance action, not part of the read-only reporting script below. It checks backup objects on the selected device; it is not a complete image-copy inventory or a full validation of every backup block. Tape access also depends on working media-management configuration and appropriate channels.

If objects unexpectedly become expired, investigate disconnected storage, permissions, host context, and media-management access before deciding what happened. A temporary outage does not establish that a backup was intentionally removed. Preserve the report and the environmental evidence so the eventual correction is traceable.

For stronger recovery evidence, schedule backup validation and a suitable restore rehearsal separately. They exercise aspects that repository analysis cannot establish. Record the scope and outcome of those checks alongside the reporting record without suggesting that a successful listing substitutes for them.

Save a repeatable reporting session

The following sequence collects configuration, schema, inventories, and policy assessments. Run it in an already authorized RMAN connection. The report directory must exist and be writable by the operating-system account running the RMAN client.

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

Use a unique dated filename for each real run. The path belongs to the RMAN client environment, which may differ from the database server. Spooling overwrites an existing file by default; use the documented append option only when intentionally combining sessions.

Inspect command errors as well as successful output. A log file's existence proves only that a file was produced. Record the target, container, repository source, execution time, policy, and any explicit filters. If a scheduler runs the report, ensure that someone reviews failures and that an empty or incomplete log cannot be mistaken for a clean assessment.

Turn findings into a reviewable decision

Suppose a weekly job appears in the backup summary, but a datafile still appears in the need-backup report. Resolve that file in the schema report and inspect its actual backup coverage. The weekly tag might describe a job whose scope does not satisfy the particular requirement being evaluated.

Now suppose an older copy appears in the obsolete report while another copy is marked expired. Keep the findings separate. The first needs retention review; the second needs an accessibility investigation. Neither finding, by itself, proves that deleting a file or removing a repository record is the appropriate next action.

A concise handoff should identify the finding, the command and criterion that produced it, the evidence still missing, the responsible person, and the next verification step. For a corrective backup, rerun the affected file's inventory and the relevant requirement report. For an accessibility issue, document the restored access and the resulting repository status under the maintenance procedure.

Preserve before-and-after evidence with the report. This gives the next operator a defensible explanation of what changed and why the finding was closed. It also keeps backup reporting focused on a specific recovery requirement instead of an unsupported statement that all backups are good.

Oracle 26ai references

• LIST: backup and copy inventory syntax and output.
• REPORT and obsolete-selection criteria: report semantics and retention options.
• CROSSCHECK: repository-status maintenance and device requirements.
• SPOOL and reporting on RMAN operations: saving and interpreting reporting evidence.

The next lesson examines data dictionary views for backup and recovery.