Oracle DBA Lesson 32E — Recover One PDB While the CDB Stays Open

When the recovery problem is confined to one PDB, the recovery scope can stay with that tenant. In the path below, the root and the other PDBs remain open while LABPDB is closed, restored, recovered, and verified through its application service.

Oracle DBA Lesson 32E — Recover One PDB While the CDB Stays Open

How the scoped recovery works

Keep the administrative connection in CDB$ROOT and close only LABPDB. CLOSE IMMEDIATE ends its user sessions and rolls back unfinished work. Its mode becomes MOUNTED. The selected exercise uses the current control file and accessible SYSTEM files. Missing SYSTEM files require a different documented procedure with a CDB-wide mounted state.

RESTORE PLUGGABLE DATABASE LABPDB supplies the earlier backup contents. RECOVER PLUGGABLE DATABASE LABPDB applies the required recovery changes. After successful complete recovery in this path, ordinary PDB OPEN returns the tenant to READ WRITE. See complete PDB recovery.

Marker	How its committed state is verified
Committed before the selected backup	Present in the restored-and-recovered state.
Committed after that backup	Reconstructed from the required surviving redo.
Unfinished work when the PDB is closed	Rolled back by CLOSE IMMEDIATE.

Verify both committed markers through LABPDB's real service. Compare the root and unrelated-PDB state with the baseline, and test their actual services. Other tenants can remain open while restore I/O still affects shared host resources.

Practice: recover only the selected PDB

Use a fresh isolated copy approved through 32A, with its current control file. Do not reuse 32D's changed incarnation. The instructor confirms an Oracle 19c single-instance primary ARCHIVELOG CDB, the exact release update and edition, local undo, LABPDB, accessible SYSTEM files, root READ WRITE, verified LABPDB backups, and all archived and online redo required for complete recovery. Resolve encryption-key access if it applies and the media channels before the outage. Do not share source data, control, redo, or FRA storage, and do not register this copy in the recovery catalog. Coordinate only the LABPDB outage. Finish the exercise transactions, record the baseline states, and preserve independent logs. No file deletion is needed to manufacture damage.

SQL*Plus connects to the isolated CDB$ROOT as an approved SYSDBA operator. A confirmed local OSDBA account may use sqlplus / as sysdba. Alternatively, use the approved authentication mechanism for the isolated root. RMAN connects to that same root as an approved common SYSBACKUP or SYSDBA operator. A confirmed local OSBACKUPDBA route is shown below. Confirm authorization and OS membership rather than reading these commands as passwordless access.

Prepare committed markers and evidence

Connect COURSE_OWNER through the instructor-supplied isolated LABPDB service. Confirm SHOW USER, SHOW CON_NAME, and the SYS_CONTEXT identity. The alias must route to this copy. In the existing course recovery_marker table, first verify that 3201 and 3202 are unused. If either ID is already used, choose recorded unused IDs. The columns are marker_id, marker_text, and created_at. Use the established table and privileges.

SELECT marker_id FROM recovery_marker WHERE marker_id IN (3201,3202);
INSERT INTO recovery_marker(marker_id, marker_text, created_at)
VALUES (3201, 'Before selected backup', SYSTIMESTAMP);
COMMIT;

The instructor creates and records the chosen LABPDB backup with the verified Lesson 31 method, and retains its identity, control-file metadata, readable pieces, and the necessary redo. After that backup completes, commit the second marker:

INSERT INTO recovery_marker(marker_id, marker_text, created_at)
VALUES (3202, 'After selected backup', SYSTIMESTAMP);
COMMIT;
SELECT marker_id, marker_text FROM recovery_marker ORDER BY marker_id;

Retain redo spanning both commits and the complete-recovery endpoint, including needed online redo. Archive and backup handling follows the instructor's approved Lesson 31 plan. Do not use DELETE INPUT or media cleanup. Capture the actual before-images and logs outside the VM. The target marker numbers are authored exercise choices, and no rows have actually been inserted in this work.

Confirm root state, undo eligibility, and selected destinations

SPOOL lab32e_root_01.log
SHOW CON_NAME
SELECT dbid, name, log_mode, open_mode FROM v$database;
SELECT property_name, property_value FROM database_properties
WHERE property_name = 'LOCAL_UNDO_ENABLED';
SELECT con_id, name, open_mode FROM v$pdbs ORDER BY con_id;
SELECT con_id, file#, name FROM v$datafile ORDER BY con_id, file#;

Require CDB$ROOT, ARCHIVELOG, READ WRITE, and LOCAL_UNDO_ENABLED=TRUE for this selected course exercise. Do not change undo mode as a workaround. See CDB undo modes.

Record the actual CON_ID and inventory for LABPDB. Confirm every write destination through the underlying storage, and require its SYSTEM files to be accessible for this intact-copy path. If a SYSTEM file is missing, stop and select the documented §17.4.6 recovery procedure and outage. Do not widen the scope silently. Missing non-SYSTEM files can also cause CLOSE to fail and require the documented offline handling. Preserve the exact error. The intact-copy drill assumes no such missing file.

If another user PDB exists, capture its service identity and a read-only availability check before, during, and after the LABPDB outage, without changing that tenant. Root and open-mode evidence alone cannot certify another application's service. PDB$SEED is expected to retain its own baseline, commonly READ ONLY.

ALTER PLUGGABLE DATABASE LABPDB CLOSE IMMEDIATE;
SELECT name, open_mode FROM v$pdbs WHERE name = 'LABPDB';

CLOSE IMMEDIATE ends LABPDB user sessions and rolls back unfinished work. Committed markers must already be durable. Require actual MOUNTED before continuing. A close error remains a stop condition. Keep the root administrative session and the unrelated containers open. See ALTER PLUGGABLE DATABASE.

Restore and recover only LABPDB

rman log=lab32e_restore_01.log

CONNECT TARGET "/ AS SYSBACKUP";
RESTORE PLUGGABLE DATABASE LABPDB PREVIEW SUMMARY;

Confirm that the selected backup handles are the intended backup made before marker 3202, that their readability was established in Lesson 31, and that every LABPDB destination is isolated. If a later backup would already contain 3202, select and verify the instructor's recorded backup before this worked recovery. Do not invent redo evidence. Resolve the exact backup selection and tag mechanics in the runbook before the write. Confirm channels and keys, available restore and log-staging space, and redo continuity. PREVIEW is selection metadata and leaves the files in place.

RESTORE PLUGGABLE DATABASE LABPDB FORCE;
RECOVER PLUGGABLE DATABASE LABPDB;
EXIT

FORCE overrides restartable-restore skip behavior and writes the files for the selected PDB even though this copy's files are intact. It is authorized only after the isolated-copy plan is verified. The scoped named-PDB statement does not authorize any wider mutation. Require actual restored-file evidence and a successful recovery log. The current control file remains in use. The required redo recovers the later commit. This is complete recovery: no SET UNTIL, no PDB RESETLOGS, and no chosen loss of later valid transactions. Do not substitute an UNTIL AVAILABLE REDO whole-database workaround. If restore or recovery fails, preserve the errors and keep LABPDB unavailable until the documented cause is resolved. See RESTORE and RECOVER.

Open and verify through the real service

Only after successful complete recovery in this current-control-file scenario:

ALTER PLUGGABLE DATABASE LABPDB OPEN;
SELECT con_id, name, open_mode FROM v$pdbs ORDER BY con_id;
SPOOL OFF

Reconnect COURSE_OWNER to the isolated LABPDB service, then verify:

SELECT SYS_CONTEXT('USERENV','CON_NAME') AS container_name,
       SYS_CONTEXT('USERENV','SERVICE_NAME') AS service_name FROM dual;
SELECT marker_id, marker_text FROM recovery_marker
WHERE marker_id IN (3201,3202) ORDER BY marker_id;

Both committed marker rows must be observed, with the correct container and service identity. Compare the root, seed, and unrelated user-PDB modes with their baseline, and check any other user-PDB service during and after the outage. Measure the LABPDB outage and preserve the actual application results. Host I/O remains shared, so other tenants' capacity and latency may be affected even while they stay open. Pass requires actual scoped restoration, successful complete recovery, both commits, the correct service, unchanged unrelated modes, and a measured outage. Every acceptance item remains pending: no Oracle commands were executed. Retain or decommission only the isolated VM through its approved runbook, with no source-file deletion and no generic cleanup step.

Recap

Close only the selected PDB, restore its files, recover all required changes, and reopen it after success. Verify both commits through its service, and check the other containers and the shared-resource effects.

Quiz

1. Where is the administrative recovery connection in this named-PDB path?

Inside any unrelated PDB On the listener only In CDB$ROOT, targeting only LABPDB In a new recovery catalog by default

2. What does LABPDB CLOSE IMMEDIATE do in the exercise?

Ends its user sessions, rolls back unfinished work, and leaves it mounted Closes every PDB and shuts down the root Deletes the committed markers Changes the recovery incarnation

3. Does this complete-PDB path require whole-CDB shutdown or PDB OPEN RESETLOGS?

Yes, for every PDB recovery Only because the marker was committed later Yes, to keep other PDBs open No. The shown current-control-file path keeps the root open and uses ordinary PDB OPEN after recovery

4. What should the restored-and-recovered marker query show?

Only the before-backup marker Both committed markers, when the required complete-recovery redo survives Only an uncommitted row No rows because CLOSE IMMEDIATE deletes commits

5. Other PDBs stay open. What still needs observation?

Nothing. Open mode proves every application works Only their database open modes Their real service availability and shared-resource effects during the selected PDB outage Only LABPDB's alias spelling

Names, paths, marker values, and expected results are teaching examples. Perform the practice in the designated Oracle Database 19c lab, confirm the exact release update, and record actual observations against the stated success criteria.

AIOps Pro

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