LEARN. PRACTICE. GROW.1. Frame the question before choosing a command
During a fictional fund close, the backup job completed without error, but the team does not know whether recovery will succeed in the alternate environment. Separate four questions: does the repository know the pieces, can the channels reach them, are required blocks readable, and does the service recover within its deadline? LIST describes records; CROSSCHECK updates correspondence with media; validation reads content according to its options; a complete rehearsal writes files, applies recovery and checks the application. Evidence should identify database, container, file set, time, channel and outcome. A green result of unknown scope cannot justify accepting the funds service. Also reserve validation read capacity: not writing restored files does not mean no I/O or operational impact.
2. EXPIRED describes observed availability
CROSSCHECK checks disk backup headers and queries the media manager catalog for tape pieces. It does not read every block to establish integrity. If a path is unmounted or an SBT channel is misconfigured, a piece can appear EXPIRED without having been destroyed. Identify the access failure before deleting records. After restoring availability, repeat crosscheck and confirm whether status returns to AVAILABLE. The command itself removes neither files nor repository records. UNAVAILABLE is a separate state used to prevent selection; it must not be confused with a physical lookup outcome. Record which channel and device type were actually checked, because successful disk verification does not cover unrelated tape media.
3. PREVIEW, headers and contents answer different questions
RESTORE PREVIEW shows metadata-based selection; it does not read the pieces. A preview can still list a piece whose file was moved after backup until observed status is updated. VALIDATE HEADER adds selected-header checks without writing destination files. RESTORE VALIDATE reads blocks from backups selected for restoration, also without writing those files. VALIDATE BACKUPSET lets the operator select a specific set, whereas RESTORE selects according to the request, metadata and options. With multiple copies, successful validation may have used another piece. Retain handles and selection in logs to identify what was actually read. No error does not establish that every existing copy was read or that a different recovery destination is ready. In the lab, a FROM TAG-restricted preview found the datafile but no eligible archived-log chain. Logs had been backed up under another tag. Preparation was corrected to provide backups consistent with selection; AVAILABLE alone does not mean eligible for every command. Retain this kind of failure instead of declaring recovery demonstrated when only one file was listed.
4. Physical integrity is not business correctness
Physical checks look for issues such as invalid checksums or inconsistent block structures. CHECK LOGICAL adds supported logical checks within blocks; it does not establish that a payment amount is correct, that the application respected authorization, or that every relationship between blocks was checked. V$DATABASE_BLOCK_CORRUPTION and diagnostic records have scopes that need interpretation. MAXCORRUPT also changes what may be tolerated during a backup: success with marked blocks does not prove absence of corruption. When an error occurs, identify file, block, object and impact before choosing a repair. Application validation should add counts, control totals and representative transactions, using synthetic data in the rehearsal and retaining the expected values separately.
5. Design a rehearsal that detects false confidence
In an isolated lab, create a tablespace and small control table, record values and produce a backup with its own tag. Keep the log and identify the piece actually created. Simulate unavailability only for that lab piece while preserving a way to restore it. Compare preview, validation and crosscheck, then return the piece and repeat verification. Each result answers a different scope. Do not use this procedure to move production backups. A second rehearsal should test restore and recovery, with a post-backup write and reconciliation after applying redo. Keep executed results separate from planned tests and missing dependencies such as tape, a keystore or a separate recovery environment.
A moved piece may remain in preview, fail reading and become EXPIRED after crosscheck. These are different observations, not contradictory outcomes.
Common pitfalls
Confusing AVAILABLE with integrity; deleting records after a mount failure; treating preview as reading; confusing CHECK LOGICAL with financial reconciliation.
Related topics: Backup and recovery evidence · Selective recovery and isolated rehearsals · Patches, upgrades and handover
Match evidence to the question: inventory, availability, integrity and recovery each need their own proof.
Reference: Validating Database Files and Backups · 1Z0-183 public objectives inspected 2026-09-30; revision date not published