Oracle DBA Lesson 32B — Restore a CDB and Recover Committed Work

Complete CDB recovery brings the root and its PDB data files to the latest recoverable committed state. The backup supplies earlier file contents. Surviving recovery changes bring later work back. The goal is a usable application service, verified against the agreed recovery-time objective.

Oracle DBA Lesson 32B — Restore a CDB and Recover Committed Work

Practical meaning

Restore supplies the earlier data-file contents. Complete recovery uses the required changes, including retained redo, to bring the root and all PDB data files forward. In this current-control-file example, successful complete recovery is followed by ordinary ALTER DATABASE OPEN;. The older committed marker checks the baseline. The later committed marker checks post-backup work. Required PDB states, service routing, and application checks establish usable service. Compare the elapsed restore, recovery, and verification time with the agreed RTO. See complete CDB recovery.

Lab conditions

Use the lab owner's designated Oracle 19c disposable single-instance CDB and its separately provisioned, disconnected recovery copy. Obtain the documented whole-CDB outage, ownership, reset and decommission, and target approval from 32A. This document does not authorize operating a source or production database. Recheck the release update, platform, privileges, media and channel access, available space, and any encryption keystore before running. Preserve a current control file and every required archived and online redo log. Missing logs, a backup control file, incomplete recovery, RAC, or changed file locations require a separately reviewed procedure rather than adapting this bounded example mechanically.

The owner must verify the recovery-only local SID and environment, data files, control files, redo, temporary files, archive and FRA destinations, the keystore, service endpoints, and aliases at the actual storage and mount level. The recovery copy must have no write-capable path or service route into the source environment. Matching names, or different directory strings alone, do not establish isolation. Default RESTORE writes the paths recorded in the control file and the repository. Confirm those paths already point to recovery storage. If relocation is needed, stop for the owner-approved SET NEWNAME and SWITCH plan. Confirm the required channels with SHOW ALL, the piece inventory and readability, and complete redo coverage, as in 31D. Preserve logs and inventory outside the recovery failure domain, and do so before any run.

The owner must confirm local OSDBA membership and SYSDBA authority for SQL*Plus shutdown, mount, and open, in the CDB root. RMAN uses the already verified local OSBACKUPDBA and SYSBACKUP target-root route. These are authentication routes that require those privileges, not permission granted by the lesson. The example local connections work only after the recovery-only environment is verified.

Marker preparation in the designated disposable source lab

Use COURSE_OWNER through the lab LABPDB application service. Reuse the course recovery_marker table. Verify its columns and choose fresh run-unique IDs. The following IDs are examples. If the table is absent, its owner may create recovery_marker(marker_id NUMBER PRIMARY KEY, marker_text VARCHAR2(80), created_at TIMESTAMP DEFAULT SYSTIMESTAMP) as part of the approved lab setup. Do not drop or overwrite existing work. Record the session service and container identity.

INSERT INTO recovery_marker(marker_id, marker_text)
	VALUES (3201, '32B baseline before backup');
	COMMIT;

Create and preserve the approved baseline RMAN database backup and the required redo in ARCHIVELOG mode. Retain its exact tag, job completion, selected pieces, file checkpoint information, and independent copy evidence. An owner-reviewed baseline example is BACKUP DATABASE PLUS ARCHIVELOG TAG 'L32B_BASELINE';. Ensure the configured control-file autobackup and the required SPFILE are preserved. Do not delete logs or change the retention policy for this drill.

Then commit a distinct later marker in the same PDB and service:

INSERT INTO recovery_marker(marker_id, marker_text)
	VALUES (3202, '32B committed after backup');
	COMMIT;
	SELECT marker_id, marker_text FROM recovery_marker
	WHERE marker_id IN (3201, 3202) ORDER BY marker_id;

The owner preserves the later commit's complete redo, including the tail in the online logs. A root SYSDBA ALTER SYSTEM ARCHIVE LOG CURRENT; followed by an approved RMAN BACKUP ARCHIVELOG ALL TAG 'L32B_LATER_REDO'; can preserve archived redo. Confirm the actual coverage, and confirm earlier pieces skipped by optimization. Through the owner's clone procedure, provision a coherent disconnected recovery copy with the latest current control file and the required online and archived redo. No hot filesystem-copy recipe is implied. Recheck the copy identity and all write boundaries before the recovery steps below. Keep the source-lab files untouched.

Restore and recover the verified disconnected copy

Capture the run ID, the UTC start, the backup inventory, and the target identity. Use SQL*Plus on the local recovery CDB root after the authority and environment preflight:

sqlplus /nolog
	CONNECT / AS SYSDBA
	SPOOL lab32b_states_01.log
	SHUTDOWN IMMEDIATE
	STARTUP MOUNT
	SPOOL OFF
	EXIT

Connect RMAN to that same recovery copy. The required channels and the selected backup metadata were verified before this stage:

rman log=lab32b_restore_recover_01.log
	CONNECT TARGET "/ AS SYSBACKUP";
	SHOW ALL;
	RESTORE DATABASE FORCE;
	RECOVER DATABASE;
	EXIT;

FORCE is restricted to this intact disposable recovery-copy drill. Ordinary restartable restore may skip a correctly located file whose header matches the control file. FORCE overrides that skip behavior so the clone's intact files are actually replaced. It does not relax redo requirements or authorize any other target. Confirm the actual selected baseline piece handles and file restoration in the log, not a skipped-file success. Choose the intended eligible backup through the owner-reviewed metadata and settings. Pause if RMAN selects another backup or unexpectedly skips a file. Do not copy FORCE to the source database. See RESTORE.

RECOVER requires every change needed from the restored checkpoints to the complete recovery point. Review media-recovery completion, the file and log messages, and any unresolved RMAN or ORA errors. Retained online redo may supply the latest tail. If recovery cannot complete, preserve the logs and stop for the owner rather than forcing an open. Open only after successful complete recovery with the retained current control file. Restored-control-file and PITR RESETLOGS paths are handled separately in 32C and 32D and are outside this exercise. See RECOVER.

In SQL*Plus, as root SYSDBA in the recovery environment:

ALTER DATABASE OPEN;
	SELECT name, open_mode FROM v$pdbs ORDER BY con_id;
	-- Only if LABPDB is observed mounted and is required for this check:
	ALTER PLUGGABLE DATABASE LABPDB OPEN;

Inspect every required PDB and reconcile unexpected state. If LABPDB is already in the required open mode, preserve that observed state rather than repeating OPEN. See V$PDBS and ALTER PLUGGABLE DATABASE.

Reconnect as COURSE_OWNER through the verified recovery-only LABPDB application service and retain the session, container, and service identity:

SELECT marker_id, marker_text FROM recovery_marker
	WHERE marker_id IN (3201, 3202) ORDER BY marker_id;

The expected criterion is both committed rows with their recorded text, including the post-backup row reconstructed from retained redo. This is a criterion, not a captured successful result. Verify the actual application service and the required business checks separately. Record the restore, redo recovery, and application verification start and end times, and the total elapsed seconds. Compare the measured sum with the agreed RTO. RTO is an acceptance target, not an assertion based on video length. End the sessions normally and preserve the evidence. Decommission only the disposable recovery copy under the owner's runbook.

Evidence and success criterion

Retain the target and write-boundary proof, the before and after marker records, the actual backup pieces and checkpoints, the redo inventory, the state, restore, and recovery logs, the required PDB and service identity, the application results, and the measured three-stage time. Pass only when the actual files are restored as intended, complete recovery succeeds, both committed markers and the required application services work, and the measured time is assessed against the agreed RTO. Actual values and the operational pass remain pending. Watching the video does not establish recovery proficiency.

Recap

Restore the earlier data-file contents, recover the required changes, open through the documented current-control-file path, and verify both committed markers and the application service. Measure the whole recovery interval.

Quiz

1. What does RESTORE contribute before complete recovery?

It reconstructs all post-backup commits without redo It supplies earlier physical data-file contents from selected backups It automatically proves application acceptance It changes only the service alias

2. Can complete recovery return a marker committed after the selected backup?

No. A restore is always limited to backup time Only if its row was already in the backup Only after deleting the current control file Yes, when the required redo and other recovery conditions are satisfied

3. After successful complete recovery with the retained current control file in this example, which opening is used?

ALTER DATABASE OPEN ALTER DATABASE OPEN RESETLOGS as a generic repair STARTUP NOMOUNT only ALTER PLUGGABLE DATABASE ALL CLOSE

4. Why is FORCE used in the intact disposable-copy drill?

To remove the need for archived redo To authorize writing to source storage To override restartable-restore skipping of matching intact files To grant SYSBACKUP

5. Which evidence demonstrates usable-service recovery?

Only the backup tag Successful restore and recovery, both committed markers, required services and application checks, and measured time Only a mounted root Only a successful media-validation log

Names, paths, marker values, and expected results in this lesson 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