A successful recovery returns an agreed consistent data state and a service the application can use. The assessment combines preparation, recovery execution, data checks, application tests, and a measured comparison with the original requirements.
Oracle DBA Lesson 106 Part 1 — Demonstrate a recoverable database service
Define the result before starting
Record the failure being tested and the smallest appropriate recovery scope. A whole-container-database point-in-time recovery affects its pluggable databases. A problem confined to one table or one pluggable database calls for a separate scope decision.
Two requirements answer different business questions:
| Requirement | What it controls | Agreed limit |
|---|---|---|
| Recovery point objective, RPO | Tolerable data loss, often expressed as a time window | At most 5 minutes |
| Recovery time objective, RTO | Tolerable service downtime | At most 20 minutes |
Agree the clock, the timing start, and the acceptance endpoint. The clock starts when the controlled outage begins and stops when all required service tests have completed successfully. Include time spent diagnosing and fixing defects after the start, restoring files, applying recovery, opening the required databases, and verifying the service. Preparation performed before that start is recorded separately. A restore-phase duration alone cannot describe the complete interruption.
The scenario record contains:
- Exact database identity, incarnation, affected scope, isolated destination, and operator.
- Release Update, edition, platform, and eligibility for the selected recovery feature.
- Agreed consistent recovery boundary, acceptable data loss, and who approves intentional loss.
- RTO, clock and time zone, and the timing start and stop definitions.
- Backup pieces, archived redo, control-file and parameter-file information, storage capacity, channels, and key dependencies.
- Expected retained and excluded marker rows, established from committed work before the failure.
- Isolated application service, required PDB state, and read/write acceptance test.
- Abort conditions and the escalation owner.
- Actual observations, evidence locations, remaining risks, and the independent decision.
Establish a usable recovery path
Keep file locations and client routing separate from the source. Preserve the backups, metadata, and keys outside the failure domain being exercised.
Inventory the actual database identity and backup incarnation before selecting a target. A backup older than the target, the required changes through that target, and accessible decryption material must support the chosen path. Check storage and media-manager access from the recovery environment.
These RMAN checks serve different purposes:
# RMAN connected to the correctly identified isolated target.
# Use the verified stop SCN recorded for this scenario.
RUN {
SET UNTIL SCN <VERIFIED_STOP_SCN>;
RESTORE DATABASE PREVIEW;
RESTORE DATABASE VALIDATE;
}PREVIEW uses repository records to identify candidate recovery media. VALIDATE reads selected media without writing restored data files. Preserve the output, inspect all dependencies including required redo, and repeat failed checks after correction. A complete isolated recovery and application test supplies evidence beyond these checks.
See RESTORE: preview, validation and restore behavior and Validating database files and backups.
If a required backup piece is unavailable, detect and document the failure before restoring. Correct access or verify a suitable alternative, then repeat the relevant checks. Keep the agreed target and loss tolerance. A dependency that remains unresolved is an abort condition.
Use the recovery procedure appropriate to the scenario
Reuse the earlier tested backup and recovery drill for the actual failure. This whole-CDB point-in-time path applies to a disconnected CDB that is already MOUNTED, with intentional loss of later work:
# RMAN — isolated CDB; backups/redo/keys and target already verified.
RUN {
SET UNTIL SCN <VERIFIED_STOP_SCN>;
RESTORE DATABASE;
RECOVER DATABASE;
}
# SQL*Plus — only after the selected recovery completes successfully.
ALTER DATABASE OPEN RESETLOGS;
# RMAN — retain the new recovery-branch record.
LIST INCARNATION;SET UNTIL precedes both restore and recover so both use a compatible target. UNTIL SCN is an upper, noninclusive boundary; resolve the actual SCN from the recorded transaction history. A wall-clock example does not supply that SCN. RESETLOGS belongs to this incomplete-recovery path and establishes a new incarnation. Preserve earlier recovery records as policy requires and establish a fresh backup baseline.
See Database point-in-time recovery and incarnations, RECOVER: recovery prerequisites and target handling, SET: the selected recovery target, and UNTIL: noninclusive boundaries.
This sequence is not interchangeable with complete recovery, recovery using a lost control file, or a PDB-only recovery. Those paths have their own prerequisites, database states, and commands. Do not try RESETLOGS as a response to an unexplained error.
Prove the data boundary
Before the failure, record committed marker transactions on each side of the selected boundary. Markers 101 and 102 belong to the retained state. Marker 103 was committed after the selected target and must be excluded. Marker IDs themselves do not establish commit order or SCNs. Retain the actual commit and boundary evidence.
Through the isolated application service, run:
SELECT marker_id, marker_text
FROM recovery_marker
WHERE marker_id IN (101, 102, 103)
ORDER BY marker_id;Compare actual rows and their values with the pre-recorded expectations. Both required earlier rows must be present and the later row absent. Also account for legitimate later transactions lost by the recovery choice. Two matching marker IDs do not verify every application invariant. Add the representative rows, relationships, and integrity checks.
Prove the application service
Use the normal application connection path and its ordinary account. Inspect the actual session:
SELECT SYS_CONTEXT('USERENV','DB_NAME') AS db_name,
SYS_CONTEXT('USERENV','CON_NAME') AS con_name,
SYS_CONTEXT('USERENV','SERVICE_NAME') AS service_name
FROM dual;Compare the returned database, container, and service with the recorded isolated destination. Also check the required PDB state:
SELECT con_id, name, open_mode, restricted
FROM v$pdbs
ORDER BY con_id;For a writable application test, the intended PDB must support the required state and account access. READ WRITE alone does not establish correct client routing or application privileges.
See SYS_CONTEXT: session identity and V$PDBS: PDB state.
The unused scratch table recovery_probe has probe_id and probe_text, a unique probe_id, and only the application privileges needed for the test. Confirm its identity and emptiness before use. As the application account:
INSERT INTO recovery_probe (probe_id, probe_text)
VALUES (9001, 'recovery acceptance');
COMMIT;Open a fresh connection through the same isolated service, confirm its identity, and query:
SELECT probe_id, probe_text
FROM recovery_probe
WHERE probe_id = 9001;Check the returned value and application behavior. Committing and observing the row in a new connection verifies a permitted durable transaction across sessions. ROLLBACK after COMMIT cannot undo that committed insert.
Interpret data loss and complete restoration time
On one agreed clock, these same-day times fix the two intervals:
| Event | Time |
|---|---|
| Selected consistent data boundary, supported by the actual SCN record | 09:58 |
| Outage starts | 10:00 |
| All required service verification completes successfully | 10:18 |
The potential data-loss interval is 10:00 − 09:58 = 2 minutes, within the agreed five-minute tolerance. This describes the window of potentially lost committed work. Preserve the actual transaction evidence to determine what was lost.
Complete restoration is 10:18 − 10:00 = 18 minutes, within the twenty-minute deadline. Capture the actual start and end of preparation after the outage, restore, recover, open, and verification. Use nonoverlapping phase definitions or explicitly identify overlap. The governing elapsed result is the agreed outage-to-acceptance interval.
See High availability requirements: RPO and RTO.
If a limit is missed, record the miss, diagnose the slow phase or the loss boundary, make a justified improvement, and retest against the original requirement. A proposed plan or a shorter restore phase is not a measured pass.
Recap
A recoverable service is an agreed data boundary plus an application that can use it. Record the failure, the smallest fitting scope, the RPO and the RTO, and the clock that starts at the outage and stops when the required service tests succeed. A restore-phase duration is not that interval.
Inventory the database and the backup incarnation. RESTORE DATABASE PREVIEW selects media from the repository. RESTORE DATABASE VALIDATE reads that media without writing data files. Resolve an unavailable required piece, or verify a suitable alternative, before restore, and keep the agreed target.
For this whole-CDB point-in-time path, SET UNTIL SCN precedes both RESTORE DATABASE and RECOVER DATABASE on a disconnected CDB that is already mounted. UNTIL SCN is an upper, noninclusive boundary. OPEN RESETLOGS follows a successful incomplete recovery and creates a new incarnation. The sequence is not complete recovery, lost-control-file recovery, or a PDB-only recovery.
Markers 101 and 102 stay. Marker 103, committed after the target, is absent. Through the isolated service, the session's database, container, and service match the destination, and the PDB is in the required state. A committed insert into recovery_probe is visible from a fresh connection on that service. ROLLBACK after COMMIT does not undo it.
On this clock, the loss window is 2 minutes and complete restoration is 18 minutes, inside the 5-minute and 20-minute limits. A missed limit is recorded, diagnosed, improved, and retested against the original requirement.
No comments:
Post a Comment