Control File/SPFILE Backups, Archived Logs, Retention Policies, and Recovery Catalog Concepts

Learning outcomes

A server is lost completely. The backup disk contains datafile pieces, but the SPFILE, current control files, and RMAN repository were on the failed host. The DBA can see files with names such as c-1234567890-... but has never tested bootstrap recovery. Disaster recovery begins with metadata: RMAN must be able to start an instance, identify the database, restore/mount a control file, discover backup records, and locate the redo needed to make restored files consistent.

1. Control-file autobackup can bootstrap RMAN without the normal repository

For modern databases with COMPATIBLE at the documented threshold, 26ai turns control-file autobackup on by default. The autobackup contains the current control file and, when the instance uses an SPFILE, the server parameter file. Its well-known %F-based naming makes it discoverable even after the current control file and ordinary catalog connection are unavailable.

SHOW ALL;

CONFIGURE CONTROLFILE AUTOBACKUP ON;CONFIGURE CONTROLFILE AUTOBACKUP FORMAT  FOR DEVICE TYPE DISK CLEAR;

Clearing a custom disk format returns to the default format/location behavior. If a Fast Recovery Area (FRA) is configured, the default autobackup can be placed there. In production, keep a copy of the DBID and recovery bootstrap procedure outside the failed database host.

2. Protect the SPFILE and control file after structural/backup changes

BACKUP CURRENT CONTROLFILE  TAG 'SH15_BOOTSTRAP_CF';BACKUP SPFILE  TAG 'SH15_BOOTSTRAP_SPFILE';LIST BACKUP OF CONTROLFILE;LIST BACKUP OF SPFILE;

If the database was started from a PFILE rather than SPFILE, there may be no current SPFILE to back up. Verify startup configuration instead of treating BACKUP SPFILE failure as media corruption.

3. Archived redo connects a datafile backup to a later recoverable point

An online backup taken while the database is open is not a transactionally closed set of files. During restore, RMAN applies redo to make restored datafiles consistent. In ARCHIVELOG mode, archived redo preserves completed online-log sequences so recovery can proceed beyond a backup SCN.

SELECT name,log_mode,open_modeFROM v$database;SELECT dest_id,status,destination,errorFROM v$archive_destWHERE status <> 'INACTIVE'ORDER BY dest_id;

LIST ARCHIVELOG ALL;BACKUP ARCHIVELOG ALL  NOT BACKED UP 1 TIMES  TAG 'SH15_ARCHIVE_SAFETY';

If the database is in NOARCHIVELOG, do not issue an archived-log policy as though logs exist. Online/open backups and recovery options are different; consistent whole-database backups require the documented mounted/clean-shutdown conditions.

4. Retention answers “what must remain recoverable?”

A redundancy policy retains a configured count of full/level-0 recoverable backups for each datafile/control file. The current default is REDUNDANCY 1. A recovery window policy retains enough backups and dependent incremental/archived redo to recover to any point within a specified recent time window, subject to what was actually backed up.

SHOW RETENTION POLICY;REPORT OBSOLETE;-- Example production policies; choose one from RPO/recovery design:-- CONFIGURE RETENTION POLICY TO REDUNDANCY 2;-- CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

A seven-day recovery window does not create missing redo or guarantee an application-consistent seven-day RPO. It tells RMAN which backup artifacts must remain nonobsolete given the backups that exist.

5. OBSOLETE and EXPIRED are different states

CROSSCHECK BACKUP;CROSSCHECK COPY;CROSSCHECK ARCHIVELOG ALL;LIST EXPIRED BACKUP;LIST EXPIRED COPY;REPORT OBSOLETE;

6. Deliberately wrong: delete backup files with Explorer/rm and leave RMAN metadata untouched

If an operator removes a backup piece outside RMAN, the repository can still show it as AVAILABLE until a crosscheck attempts to find it. A later restore then fails at the worst time. The correct workflow is retention-policy-driven deletion through RMAN or an integrated media manager, plus periodic crosscheck/validation.

DELETE NOPROMPT EXPIRED BACKUP;

This deletes stale repository records for files already unavailable; it does not delete an existing backup file. In contrast, DELETE OBSOLETE removes obsolete physical backups as well as their metadata.

7. Archived-log deletion has its own safety policy

Archived redo can be needed by database/PDB recovery, incremental strategy, a standby, downstream capture, or a migration. Do not purge archives merely because a datafile backup exists. RMAN supports archived-log deletion policies such as requiring a log to be backed up a certain number of times or, in Data Guard topologies, applied/shipped criteria.

SHOW ARCHIVELOG DELETION POLICY;

The single-instance Free lab does not configure standby-specific deletion rules. In production, archived-log deletion policy must be coordinated with Data Guard/GoldenGate/recovery-catalog/offsite-copy requirements.

8. A recovery catalog gives repository redundancy and richer history

A recovery catalog is an RMAN-owned schema in another Oracle database. It provides redundancy for the target control-file repository, longer metadata history, stored RMAN scripts, and centralized management of multiple target databases. It can be protected with its own backup/recovery policy.

The catalog does not contain the datafile backup pieces, archived logs, wallet keys, password files, or application secrets. Losing the backup media while preserving the catalog is still losing the backup.

9. Disaster-bootstrap card

# Record/document, do not paste secrets:# - DBID and DB_UNIQUE_NAME# - Oracle AI Database/RU and COMPATIBLE# - platform/Oracle Home# - control-file autobackup format/location# - SPFILE/control-file backup locations# - recovery catalog connect alias (if any)# - FRA/archive destinations# - keystore/wallet locations and independent key backup procedure# - media-manager/cloud credentials retrieval process# - last restore-drill result

10. Production judgment

Make control-file/SPFILE autobackup explicit even when the modern default is already ON. Choose retention from the business recovery window and backup cadence. Let RMAN/media-manager workflows own backup deletion, crosscheck routinely, and preserve archived logs until every dependent recovery/replication consumer is safe.

No pack or COMPATIBLE change is required. Lesson 3 now answers the question backups exist to solve: exactly what does RMAN restore, what does recovery add afterward, and how do those operations differ at CDB/PDB/tablespace/datafile/table scope?

Authoritative references

• Configuring the RMAN Environment — control-file/SPFILE autobackup and default configuration
• CONFIGURE Reference — autobackup, retention and archived-log policy syntax
• RMAN Backup Concepts — obsolete versus expired and retention behavior
• Managing a Recovery Catalog — catalog purpose and metadata
• Managing Backups and Repository Records — crosscheck/delete/catalog maintenance