LEARN. PRACTICE. GROW.1. Retention is a recoverability rule
REDUNDANCY defines how many full or level-zero backups of each file are retained by policy, not how many days of history have been demonstrated. A recovery window expresses the interval for which recovery capability should be retained. A backup older than the start of that interval may still be needed with dependent incrementals and logs; deleting by file age ignores this chain. REPORT OBSOLETE identifies candidates under policy and metadata. It neither deletes them nor establishes that media remain accessible. Before authorized deletion, confirm recovery requirements, scope, effective policy and exceptions such as KEEP backups. For a funds service, a seven-day rule does not replace the business decision about longer retention or reconciliation.
2. Free space and recovery capability
Under recovery-area pressure, do not treat EXPIRED and OBSOLETE as synonyms. EXPIRED reflects unavailability observed by crosscheck; OBSOLETE follows retention policy. DELETE EXPIRED handles records corresponding to unavailable pieces and is not a general way to free space occupied by valid files. DELETE OBSOLETE can physically remove backups no longer required under the applicable policy. Archived redo has its own dependencies and deletion rules, including standby requirements when configured. Also check restore-point consumption and redo generation rate. Resolving the incident means restoring operational headroom without destroying the required recovery chain, identifying the decision owner and measuring the projected time until space fills again under the current workload. Confirm the exact command: DELETE ARCHIVELOG ALL considers archived-log deletion policy, not backup retention policy. DELETE OBSOLETE uses backup retention to determine obsolescence and does not use archived-log deletion policy for that decision. Do not assume both automatically apply the union of every rule.
3. A backup is a starting point
Consider a synthetic table with two rows totaling 350 at backup time. A third row of 150 is committed afterward. Reinstating the datafile from backup does not establish that the total of 500 was recovered: corresponding recovery must apply the required redo. The plan should identify affected files and required access mode instead of immediately choosing whole-database recovery. In an eligible isolated application tablespace, datafile restore and recovery can limit scope. Do not generalize the procedure to SYSTEM, active undo, databases without ARCHIVELOG or different topologies. Confirm version prerequisites and retain an authorized return path before making changes in real environments. Keep the recovery target separate from the time the backup job finished.
4. Accept the database and the service
The rehearsal should observe restoration, recovery application, the tablespace returning to its expected state and reads of control values. A completed command does not automatically validate services, jobs, privileges or external dependencies. Add a representative synthetic transaction and confirm idempotency or reconciliation before replaying financial batches. Measure time from the simulated incident start to service acceptance, including preparation, media retrieval and validation. RESTORE duration alone is not RTO. For RPO, compare the actual recovered point with the requirement rather than inferring zero loss from a successful daily backup. Record limits such as a small sample, local storage, no competing workload and use of the same Docker host for all stages.
5. Hand over evidence the next team can use
The handover package should identify version and edition, DBID, container, file, tag, handles, relevant configuration and per-stage results. Retain original scripts, outputs and acceptance criteria with fictional data. For a real database, separately document who retrieves media, who supplies keystores, which services may return and what authorization backup deletion requires. A local Free test does not establish Enterprise features, RAC, Data Guard or tape recovery. Comparing two rehearsals helps expose hidden dependencies and improve the runbook; it does not automatically turn a small environment into a production benchmark. Gaps should remain explicit with an owner and next check even when recovery of the synthetic rows has been demonstrated.
Backup: two rows totaling 350. Later: three rows totaling 500. Acceptance requires observing 500 after restore and recovery, alongside operational state.
Common pitfalls
Deleting by age alone; using DELETE EXPIRED as general cleanup; confusing restore with recovery; measuring RTO only by command time; equating local Free with production topology.
Related topics: Backup and recovery evidence · Selective recovery and isolated rehearsals · Patches, upgrades and handover
Protect the required chain and accept recovery through data and service outcomes, with explicit evidence limits.
Reference: Performing Complete Database Recovery · 1Z0-183 public objectives inspected 2026-09-30; revision date not published