List RMAN Backups and Repository Objects in Oracle 26ai

The Recovery Manager LIST command displays backups and other objects recorded in the RMAN repository. In Oracle AI Database 26ai,DBAs can use it to inventory backup sets, backup pieces, image copies, archived redo logs, database incarnations, restore points, and recovery-catalog stored scripts. The command answers a practical question: What does RMAN currently know about the objects needed for backup and recovery?

RMAN always records repository metadata in the target database control file. When a recovery catalog is used, the catalog supplies an additional repository that can retain longer history and information for multiple databases. LIST queries the repository available to the current RMAN session and sends its output to standard output or the configured RMAN message log.

Choose LIST, REPORT, or SHOW

These commands use related RMAN information but serve different purposes. Selecting the right command keeps inventory, analysis, and configuration from being confused.

LIST is not an obsolete or less capable form of REPORT. It has a different job. Lesson 4 used REPORT to answer analytical questions. This lesson uses LIST to identify the repository objects that those analyses and recovery operations depend on.

Connect to the intended repository

Run LIST only at the RMAN prompt. RMAN can be connected to a target database without a recovery catalog; in that case, the target must be mounted or open. If RMAN is connected to both the target and a recovery catalog, the target instance must be started. Another supported pattern is to connect to the recovery catalog and identify the target database by running SET DBID.

Many current-target listings do not require a recovery catalog. Catalog-wide Data Guard listings, stored-script forms, and some historical or cross-database operations do require one. Use a dedicated administrative identity granted SYSBACKUP, and avoid placing passwords in shell history or command-line process listings:

rman

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

Before interpreting output, confirm the target DBID, incarnation, container, DB_UNIQUE_NAME, and catalog connection. A correct command against the wrong repository can produce a technically valid but operationally misleading inventory.

Choose the backup output format

The default detailed form displays backup sets, their backup pieces, the files included in each set, repository status, device type, completion information, and tags:

LIST BACKUP;

When no object is supplied, LIST BACKUP defaults to the database, current control file, and all archived redo logs. For a large repository, summary or file-oriented output may make the first review easier.

The detailed backup-set organization is the default, so there is no need to add a legacy BY BACKUP option. Use SUMMARY for a compact inventory and BY FILE when the question begins with a source data file or archived redo log rather than a backup-set key.

Read summary columns carefully

A summary listing condenses several attributes. Key identifies the backup set in the active repository. A catalog backup-set key and a control-file RECID are not interchangeable. TY identifies the object type, while LV describes full, archived redo log, or incremental-level information. S abbreviates status. Other columns identify device type, completion time, piece count, copy count, compression, and tag.

The #Copies value describes RMAN duplexing of backup pieces. It does not prove that the copies occupy independent failure domains or that every copy is readable. Repository keys, handles, tags, and completion times should be taken from the actual environment rather than copied from sample output.

Limit the listing to the recovery question

A focused listing is easier to interpret than the full repository inventory. Current object forms include the database, a tablespace, a data file, the current control file, and the SPFILE:

LIST BACKUP OF DATABASE;
LIST BACKUP OF TABLESPACE users;
LIST BACKUP OF DATAFILE 7;
LIST BACKUP OF CONTROLFILE;
LIST BACKUP OF SPFILE;

Using a data-file number avoids a platform-specific path in a general example, but production procedures must still confirm that the number refers to the intended file and container. In a CDB, connect to the root as a common user with SYSBACKUP or SYSDBA before listing the root or one or more PDBs through the root:

LIST BACKUP OF DATABASE ROOT;
LIST BACKUP OF PLUGGABLE DATABASE salespdb;

The PDB clause can accept a comma-delimited list where documented. Container scope matters because different PDBs can contain tablespaces with the same name. Verify the active container and qualify the intended object before using a listing in automated recovery checks.

Distinguish sets, pieces, and image copies

Backup sets and backup pieces

A backup set is an RMAN logical container for backed-up data. One or more physical backup pieces store that set. A disk piece has a file name; an SBT piece has a media-manager handle. LIST BACKUP displays the set and its pieces, together with the database files or archived redo logs stored inside them.

A backup-set record is not itself a regular database file. RMAN must interpret its backup-piece format during restore. If a set has multiple pieces, all required pieces must be accessible through the appropriate disk path or media channel.

Image copies

An image copy is a bit-for-bit copy in the database-file format, not an RMAN backup piece. Use LIST COPY to display recorded data-file copies, control-file copies, and archived redo log copies:

LIST COPY;
LIST COPY OF DATABASE;

The default LIST COPY output can include usable and unusable copies, including copies marked unavailable or expired. The fact that a copy appears in the listing therefore does not establish that it can be restored or switched into use.

Separate archived redo records from their backups

Two similar-looking commands answer different questions:

LIST ARCHIVELOG ALL;
LIST BACKUP OF ARCHIVELOG ALL;

LIST ARCHIVELOG ALL displays archived redo log records or copies known to RMAN. LIST BACKUP OF ARCHIVELOG ALL displays backup sets containing archived redo logs. A recorded archived redo log has not necessarily been backed up, and a backup-set record does not prove that its physical piece has been validated.

Limit an archived redo listing by sequence, SCN, time, or incarnation when the recovery question has a defined range. For example:

LIST BACKUP OF ARCHIVELOG
  FROM SEQUENCE 1000 UNTIL SEQUENCE 1100 THREAD 1;

The THREAD clause is important in Oracle RAC. Thread 1 is the default when no thread is specified, but a production procedure should state the intended thread explicitly. A sequence range selects records RMAN finds; it does not guarantee that every required sequence is present without a gap.

Interpret repository status correctly

Expired status becomes meaningful after an appropriately scoped crosscheck has reconciled repository records with storage:

CROSSCHECK BACKUP;
LIST EXPIRED BACKUP;

A crosscheck uses the disk paths and media channels available to that operation. A file can appear expired because the necessary mount, credential, or media configuration was unavailable during the check. Investigate the access path before treating the record as permanently lost.

List incarnations, restore points, and scripts

The command can inventory recovery metadata beyond backups and copies:

LIST INCARNATION;
LIST RESTORE POINT ALL;
LIST SCRIPT NAMES;

Opening a database with RESETLOGS creates a new database incarnation. LIST INCARNATION displays the current, parent, and orphaned incarnation records, including their keys and reset information. An incarnation key can be used in a separately planned RESET DATABASE TO INCARNATION operation, but the presence of an older record is not a reason to change the current incarnation.

For PDB history, connect to the CDB root as the required common administrative user:

LIST INCARNATION OF PLUGGABLE DATABASE salespdb;

LIST RESTORE POINT ALL displays restore points known to the repository, including the name, SCN, time, and guaranteed status. It does not prove that all backups and archived redo logs required for recovery to a restore point are physically usable.

LIST SCRIPT NAMES lists local and global scripts executable for the current target when RMAN is connected to the target and recovery catalog. Catalog-only forms include LIST GLOBAL SCRIPT NAMES and LIST ALL SCRIPT NAMES. These commands list names and comments; they do not execute the scripts.

Data Guard and preplugin context

In Data Guard, every 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. The registered databases for a DBID can be inventoried with:

LIST DB_UNIQUE_NAME ALL;

Without an explicit FOR DB_UNIQUE_NAME scope, LIST displays files accessible to the connected target. Disk backups are generally accessible to the database that created them. SBT availability depends on the shared media environment and channel configuration. Association and physical accessibility are separate properties.

Oracle 26ai also supports preplugin listings for backups associated with a PDB before it was plugged into the current CDB. These forms require a connection to the CDB root as a common user with SYSBACKUP or SYSDBA. Use the precise documented form for the required PDB migration history rather than assuming ordinary current-container scope.

Specialized 26ai catalog-maintenance forms can list connected, blocking, and waiting catalog users during a recovery-catalog upgrade. They are administrative connection-monitoring commands, not backup inventories, and should be used only within the documented catalog-maintenance workflow.

Move from inventory to recovery evidence

A useful inventory is the beginning of verification. Follow the listing with the operation that answers the next question:

RESTORE ... PREVIEW queries repository metadata without reading backup content. Header validation and broader validation provide stronger evidence about correspondence and readability. A controlled restore test supplies the strongest operational evidence because it exercises the procedure, credentials, storage, channels, and destination environment together.

Operational LIST checklist

1. Confirm the target database, DBID, incarnation, container, DB_UNIQUE_NAME, and catalog connection.
2. Begin with LIST BACKUP SUMMARY for a compact inventory, then use detailed or file-oriented output where investigation is needed.
3. Scope listings to the database, PDB, tablespace, data file, control file, SPFILE, or archived redo range relevant to the recovery question.
4. Distinguish backup sets and pieces from image copies and archived redo log records.
5. Review status, device type, completion time, piece count, copy count, compression, and tags in their repository context.
6. Run an appropriately scoped crosscheck before relying on expired status.
7. Use restore preview, validation, and scheduled restore tests to obtain evidence beyond repository inventory.
8. Save relevant listing output in the RMAN message log or approved monitoring system so changes can be reviewed over time.

LIST inventories the backups, copies, archived redo logs, incarnations, restore points, and scripts recorded in the RMAN repository. In Lesson 6, you will use recovery-catalog stored scripts to centralize and reuse RMAN command sequences. A stored script is a named command sequence, not a backup object.