Oracle DBA Lesson 32C — Starting Recovery Without a Control File

When the current control files are lost, recovery first needs its settings and recorded file map back. Rebuild that starting point from protected parameter settings, an accessible control-file autobackup, and externally retained backup records.

Oracle DBA Lesson 32C — Starting Recovery Without a Control File

The bootstrap sequence

Parameter settings permit NOMOUNT startup. The control file supplies recorded file names and RMAN backup metadata. In the selected no-catalog case, SET DBID and an exact accessible autobackup handle allow control-file restoration. Mounting that restored file gives RMAN its recorded recovery map. Missing newer pieces can then be registered specifically. Recorded source paths must be detected and resolved before later data-file writes.

Backup-control-file recovery uses RECOVER even if the data files were already present. After successful recovery to the documented target, OPEN RESETLOGS establishes a database incarnation. This course takes a fresh baseline backup and preserves earlier incarnation records and the required recovery media. Oracle 19c can use valid ancestral backups and continuous redo across RESETLOGS. The fresh backup is an operational practice. See advanced recovery.

Practice: rebuild the recovery metadata

Eligibility and authority. The lab is Oracle Database 19c on Linux: a single-instance CDB, the correct Oracle home and release update, the root instance, and authorized SYSDBA or SYSBACKUP. Use a separately provisioned disposable recovery copy with a reviewed VM, storage and service isolation, and no source or shared FRA access. This exercise models loss of all current control-file copies. An available current copy requires its own documented replacement procedure. The instructor supplies the failed-copy condition. This guide gives no source-file deletion step.

Before any command, retain the identity, the DBID, the exact autobackup location, the discovery format, every required backup-piece handle, the timestamps and set keys, the redo inventory, and any required keystore or key history in protected records outside the failed host. Verify the actual copies, ownership, integrity, and authorized channel and media access. Keep decryption secrets out of logs and lesson assets. Confirm encryption eligibility, and any extra key-management privilege, for the lab.

Reviewed bootstrap settings. Use an instructor-approved <LAB_PFILE> reconstructed from protected settings. Its DB_NAME must match the recorded database. Choose an appropriate lab DB_UNIQUE_NAME. CONTROL_FILES must name only isolated lab files. Review every referenced setting and included parameter file: CONTROL_FILES, DB_RECOVERY_FILE_DEST, archive destinations, audit and diagnostic destinations, OMF destinations, wallet paths, and IFILE or SPFILE indirections. Confirm that the operating-system account cannot access source data, control, redo, or FRA locations, and that services cannot route this copy's sessions to the source. Preserve the reviewed settings and the target map externally.

The placeholder values below are deliberate. Replace each one from verified records. Never guess an identity, a destination, or a backup handle. These placeholders are not ready-to-run commands.

1. Start only the lab instance, using the approved local SQL*Plus authentication route:

   sqlplus / as sysdba

   STARTUP NOMOUNT PFILE='<LAB_PFILE>';
   SHOW PARAMETER db_name
   SHOW PARAMETER db_unique_name
   SHOW PARAMETER control_files
   SHOW PARAMETER db_recovery_file_dest
   SHOW PARAMETER log_archive_dest
   SELECT instance_name, status FROM v$instance;
   EXIT

   Interpret the actual output. NOMOUNT initializes memory and processes using this PFILE. Confirm the identity, the state, and every write destination against the approved map. Stop on any unexpected source path or identity. Instance startup alone provides no normal mounted control-file inventory.

2. Connect RMAN locally to that same confirmed instance, using its separately authorized OSBACKUPDBA route. Retain the non-secret command log outside the tested failure domain:

   rman log=lab32c_bootstrap.log

   CONNECT TARGET "/ AS SYSBACKUP";
   SET DBID <RECORDED_DBID>;
   RESTORE CONTROLFILE FROM '<EXACT_CONTROLFILE_AUTOBACKUP_HANDLE>';
   ALTER DATABASE MOUNT;
   REPORT SCHEMA;
   LIST BACKUP SUMMARY;

   SET DBID establishes the no-catalog restore identity. FROM names the specific copied disk autobackup, and the restore writes the approved CONTROL_FILES locations already checked at NOMOUNT. MOUNT opens the recovered control file. REPORT SCHEMA shows its recorded file and tablespace map. LIST shows its known backups. Preserve the actual restore handle, the completion and error messages, and the output. Compare all file names with the approved target map. Detect the deliberately supplied source path, and stop before any database contents are restored. See SET and RESTORE.

3. Inspect control-file, redo, permanent, and temporary file paths from SQL*Plus while the database is mounted:

   sqlplus / as sysdba

   SELECT name FROM v$controlfile;
   SELECT file#, name FROM v$datafile ORDER BY file#;
   SELECT file#, name FROM v$tempfile ORDER BY file#;
   SELECT group#, member FROM v$logfile ORDER BY group#, member;
   SHOW PARAMETER db_recovery_file_dest
   SHOW PARAMETER db_create_file_dest
   SHOW PARAMETER db_create_online_log_dest
   SHOW PARAMETER log_archive_dest
   EXIT

   The restored control-file entries may preserve source paths. An instructor-approved full recovery runbook must establish target mappings before restore, recover, or open writes. REPORT SCHEMA does not replace reviewing redo, control, FRA, OMF, and archival destinations. If the map is unexpected, preserve the evidence and correct the plan. Do not attempt an OPEN or a generic RESETLOGS workaround. See data repair concepts.

4. Compare the restored backup inventory with protected external records. If specific disk backup pieces were copied and are missing from this inventory, use only those verified exact filenames:

   CATALOG BACKUPPIECE '<EXACT_DATABASE_BACKUP_PIECE>';
   LIST BACKUP SUMMARY;
   RESTORE DATABASE PREVIEW SUMMARY;

   Run these commands at the same RMAN session and prompt. Repeat specific CATALOG commands only for individually verified required pieces. The target must be mounted. Cataloging checks the piece header and registers metadata. All pieces in each required set must be present. Investigate any identity or header error and retain the evidence. Verify accessibility and readability of the actual chosen recovery media, using the instructor's planned validation checks. Redo continuity and the required decryption material remain part of the recovery decision. Broad catalog-prefix discovery is outside this exercise. See CATALOG.

5. Stop at the data-file write boundary. Pass this bootstrap exercise when NOMOUNT and the control-file restore are demonstrated, the deliberately supplied source path is detected before a write, the missing newer backup inventory is identified, and the approved inventory and destination correction is evidenced. An authored checklist is not a recorded pass. Actual performance remains pending.

The later RESTORE, RECOVER, and OPEN procedure must use the complete rehearsed runbook, the resolved destination mappings, the target, and the required redo. Recovery with the backup control file requires RECOVER even if no data-file restore was needed. OPEN RESETLOGS follows successful documented recovery. Record the new incarnation, the database, container, and application checks, and the course's fresh baseline backup. Do not continue after an error by guessing an UNTIL value or adding RESETLOGS.

Optional parameter-file recovery. If protected settings are insufficient and the autobackup contains the original SPFILE, the approved procedure may restore it to a new explicit lab PFILE for review:

RESTORE SPFILE TO PFILE '<NEW_LAB_PFILE>'
  FROM AUTOBACKUP;

This is an alternative workflow at the approved NOMOUNT bootstrap stage, not an extra command after the main mounted drill. Before this command, confirm the DBID, the accessible autobackup format and location, the search date limits and channels, and the encryption needs. The PFILE is created on the RMAN client host. Review every source path, replace it with the approved lab path, then use the reviewed settings for restart. Never blindly restart from the original SPFILE in a recovery copy.

Cleanup and evidence. EXIT leaves RMAN. Manage the lab instance through the approved operator runbook. Restore the disposable configuration from its saved copy, or decommission only the designated recovery environment. Preserve original autobackups, trusted external records, original masters, and source storage. Capture the version and release update, identities, reviewed settings and map, real commands and output, failure interpretation, the missing-piece comparison, postchecks, and the cleanup outcome, using the course evidence template. No Oracle command in these notes was executed by the lesson author.

Recap

Start from reviewed settings, restore the control file, mount its recorded map, reconcile the missing backup inventory, and resolve every destination before data-file writes. Follow the documented recovery and opening path.

Quiz

1. What supplies settings for the initial NOMOUNT bootstrap?

A mounted control file that is already available The current PDB service alias Reviewed protected parameter settings in the lab PFILE A backup tag alone

2. What should the no-catalog bootstrap retain outside the failed host?

DBID, accessible autobackup discovery information, required piece records and keys when needed Only the database name and most recent backup date Only the latest service alias Only the RMAN tag

3. After mounting the restored control file, a data-file path points at source storage. What next?

Run RESTORE DATABASE immediately Guess a different UNTIL target Open with RESETLOGS to change the paths Stop before data-file writes and resolve the approved target map

4. What does CATALOG BACKUPPIECE do for a verified piece missing from the restored inventory?

Restores every data file from it Checks its header and registers its backup metadata Deletes the old incarnation Creates a new physical backup piece

5. What is required before opening after the documented backup-control-file recovery path?

No recovery when the data files already exist Any failed OPEN is enough justification Successful RECOVER to the approved target, followed by OPEN RESETLOGS Only a new listener alias

Names, paths, marker values, and expected results are teaching examples. Run the practice in the designated Oracle Database 19c lab, confirm the exact release update, and record what you actually observe against the stated success criteria.

AIOps Pro

https://www.apps-dba.com/ https://x.com/AIOpsPro https://www.youtube.com/@AIOpsPro