Block Media Recovery, Validation, Corruption Detection, Crosschecks, and Backup Optimization

Learning outcomes

A nightly RMAN job exits with “Finished backup,” yet a month later a storage checksum failure exposes unreadable blocks in an old datafile. Another team runs CROSSCHECK every morning and calls that a restore test. These operations answer different questions. Recoverability needs media existence, readable/structurally valid blocks, usable backup pieces, required redo, encryption keys, and application-level restoration checks.

1. Physical and logical corruption are different failure classes

Physical corruption means the block structure cannot be trusted—for example invalid checksum, all-zero block, or inconsistent header/footer. Logical corruption means the physical block structure is intact but internal content is inconsistent, such as a malformed row piece or index entry.

RMAN validation checks physical corruption by default. CHECK LOGICAL adds intrablock logical checks. It cannot prove every interblock relational/business invariant in an application.

2. Mandatory non-destructive PDB validation

VALIDATE PLUGGABLE DATABASE FREEPDB1;VALIDATE CHECK LOGICAL  PLUGGABLE DATABASE FREEPDB1;

The command reads the PDB datafiles but does not create a backup. On success, RMAN reports validation completion and block counts. On detected corruption, RMAN records qualifying block ranges in V$DATABASE_BLOCK_CORRUPTION and writes diagnostic evidence to ADR.

3. Query the database corruption inventory

SELECT  con_id,  file#,  block#,  blocks,  corruption_change#,  corruption_typeFROM v$database_block_corruptionORDER BY con_id,file#,block#;

An empty result means no corrupt blocks are currently recorded in this view. It does not prove every byte, backup piece, index/table relationship, application invariant, or offsite copy is valid.

4. BACKUP VALIDATE reads files like a backup but writes no backup artifact

BACKUP VALIDATE  CHECK LOGICAL  PLUGGABLE DATABASE FREEPDB1;

BACKUP VALIDATE exercises the file-read path RMAN would use for backup and reports corruption, but it intentionally produces no backup set/image copy. Therefore it cannot prove that yesterday's backup piece is still readable today.

5. RESTORE VALIDATE tests existing backup artifacts

RESTORE PLUGGABLE DATABASE FREEPDB1 VALIDATE;

This is the correct escalation when the question is “can RMAN read the backup pieces needed for restore?” It can fail because a piece is missing/corrupt even while current database files validate successfully.

6. CROSSCHECK is an existence/status reconciliation, not a checksum scan

CROSSCHECK BACKUP;CROSSCHECK COPY;LIST EXPIRED BACKUP;LIST EXPIRED COPY;

CROSSCHECK asks the device/media manager whether each recorded artifact exists/accesses as expected and marks missing records EXPIRED. It does not read every data block in the piece to prove restoration integrity.

7. Block media recovery repairs selected corrupt blocks where possible

Block media recovery (BMR) restores only corrupt blocks from good backups/copies and applies redo to recover them. The rest of the datafile can remain online, reducing outage scope for isolated corruption. RMAN can recover blocks explicitly or all eligible blocks recorded in V$DATABASE_BLOCK_CORRUPTION.

RECOVER DATAFILE 7 BLOCK 12345;-- Or recover all eligible blocks in the corruption list:RECOVER CORRUPTION LIST;

Do not copy these numbers. Use exact file/block evidence from the target. Some logical corruptions cannot be fixed by BMR and may require object rebuild, table/tablespace recovery, or broader media recovery.

8. Deliberately wrong: corrupt a database block with an OS hex editor to practice BMR

Directly editing a datafile can damage neighboring blocks, metadata, encryption structures, or storage snapshots and can make an otherwise healthy lab unrecoverable. The mandatory course path never injects physical corruption into the only Free database.

9. Backup optimization avoids redundant backups under specific rules

CONFIGURE BACKUP OPTIMIZATION ON lets RMAN skip certain files that already have an identical usable backup on the same device type according to RMAN's documented rules. This can reduce I/O/storage, but it relies on repository/media state and retention needs.

SHOW BACKUP OPTIMIZATION;-- Optional:-- CONFIGURE BACKUP OPTIMIZATION ON;

Optimization is not deduplication proof and does not mean “never back up unchanged files again.” Retention, device type, recovery window, FORCE clauses, archived-log rules, and media expiration all influence whether RMAN skips an object.

10. Validation matrix

11. Production judgment

Schedule validation as part of a recoverability program, not as a replacement for restore drills. Use logical checks where their extra read/CPU cost fits the window, crosscheck storage/media catalogs, and act on V$DATABASE_BLOCK_CORRUPTION immediately. Keep checksums enabled and investigate underlying storage when corruption appears.

No pack or COMPATIBLE change is required for the mandatory validation path. Lesson 5 now moves from “are backups readable?” to the harder proof: can you meet a stated RPO/RTO, recover to a chosen point, duplicate into isolation, and unlock encrypted data after the original host is gone?

Authoritative references

• Validating Database Files and Backups — VALIDATE/BACKUP VALIDATE/RESTORE VALIDATE and corruption classes
• VALIDATE Reference — CHECK LOGICAL and PDB validation syntax
• Performing Block Media Recovery — BMR and V$DATABASE_BLOCK_CORRUPTION
• Maintaining RMAN Backups — CROSSCHECK/EXPIRED maintenance
• Configuring RMAN Environment — backup optimization policy