Oracle RMAN RESTORE DATABASE VALIDATE Backup Check

calendar Feb 13, 2026 / · 7 min read · Oracle RMAN Database Backup Backup Validation Recovery Manager Database Administration Corruption Detection Oracle DBA v$database_block_corruption  ·
Share on: linkedin copy

Oracle RMAN Restore Database Validate - Check Backup Integrity

Purpose

A backup that has never been read back is only a guess. The night you need it is the wrong time to learn that a backup piece is missing or a block inside it is damaged. The RESTORE DATABASE VALIDATE command in Oracle Recovery Manager (RMAN) closes that gap. It reads the backups RMAN would use for a restore and checks them, but it writes no data files, so production stays untouched.

Oracle describes the VALIDATE option this way: RMAN identifies which backup sets, data file copies, and archived redo log files must be restored, and then validates them. No files are restored. For files on both disk and tape, RMAN reads all blocks in the backup piece or image copy, and the validation is identical to a real restore except that RMAN does not write output files.

This gives you evidence about your backup strategy without a restore window and without extra disk space. By default the command covers data files only. Oracle states that RESTORE DATABASE does not automatically include the control file and the server parameter file, so a real recovery needs separate RESTORE commands for them.

Code

1-- Validate the database backups RMAN would use in a restore
2RESTORE DATABASE VALIDATE;
3
4-- Validate with archived redo logs
5RESTORE ARCHIVELOG ALL VALIDATE;
6
7-- Check for logical corruption in addition to physical
8RESTORE DATABASE VALIDATE CHECK LOGICAL;

After a run, look at the corruption view:

1SELECT * FROM v$database_block_corruption;

Code Breakdown

RESTORE DATABASE VALIDATE

  1. Chooses the backups: By default, RESTORE chooses the most recent backup set or file copy, that is, the one that needs the least media recovery. RESTORE works from full backups, level 0 incremental backups, or image copies.
  2. Reads the backup pieces: RMAN reads all blocks in each backup piece or image copy, on disk or on tape.
  3. Checks the blocks: No output files are written.
  4. Reports the result: If you see no RMAN error stack, the validation passed. If a problem is found, RMAN shows an error stack.

RESTORE ARCHIVELOG ALL VALIDATE

Oracle's backup guide shows this command together with RESTORE DATABASE VALIDATE, so that both data files and archived redo logs are checked.

CHECK LOGICAL

Oracle says CHECK LOGICAL tests data and index blocks that pass the physical checks, for example a corrupted row piece or index entry. If RMAN finds logical corruption, it logs the block in the alert log and the server session trace file.

SELECT * FROM v$database_block_corruption

The view lists blocks marked corrupt by Oracle components such as RMAN commands, ANALYZE, and SQL queries.

Key Points

  • State: The database must be mounted or open. You do not have to take data files offline, because validation of backups only reads the backups and does not affect the production data files.
  • Scope: The command checks data file backups. It does not add the control file or the SPFILE.
  • Physical only by default: By default, RMAN does not check for logical corruption. Oracle describes a physical, or media, corruption as one where the database does not recognize the block at all: the checksum is invalid, the block contains all zeros, or the header and footer of the block do not match.
  • The corruption view has a condition: Per Oracle's RESTORE reference, if the total number of physical and logical corruptions detected in a file is less than its SET MAXCORRUPT setting, the RMAN command completes and the database populates V$DATABASE_BLOCK_CORRUPTION with corrupt block ranges. If MAXCORRUPT is exceeded, the command terminates without populating the views.
  • Default limit: Oracle's backup guide says the default for SET MAXCORRUPT is zero, meaning RMAN does not tolerate unmarked corrupt blocks of any kind.
  • Repaired blocks leave the view: If a BACKUP, RESTORE, or VALIDATE command detects that a block is no longer corrupted, it removes the repaired block from the view.

Insights and Best Practices

Validation Schedule

Pick a rhythm that fits how often your backups change and how much data loss you can accept, and write it into your backup runbook. Oracle does not publish a required frequency for this check, so the choice is yours.

Coverage

Run RESTORE ARCHIVELOG ALL VALIDATE beside the database check, because recovery needs the redo as well as the data files. Plan the control file and SPFILE separately, since RESTORE DATABASE does not include them. Add CHECK LOGICAL when you want the deeper test for logical corruption.

Reading the Corruption View

Do not assume the view always has rows after a failed validation. Read the RMAN output first and treat the view as a second record. A missing row does not prove a clean backup if the MAXCORRUPT limit was exceeded, and an empty view after a rerun can mean a block was repaired.

Differences from Other Validation Methods

  • BACKUP VALIDATE: RMAN reads the files to be backed up in their entirety, as in a real backup, but it does not produce any backup sets or image copies. It checks data files for physical and logical block corruption and confirms that all database files exist in the correct locations. Oracle says you cannot use the BACKUPSET, MAXCORRUPT, or PROXY parameters with it.
  • RESTORE VALIDATE: Checks that backups can be restored, by reading the backup pieces. RMAN chooses which backups to validate.
  • VALIDATE BACKUPSET: You choose which backup sets to test.

In short, BACKUP VALIDATE tests the live database files, while RESTORE VALIDATE tests the stored backups.

Interpreting Results

A successful run prints lines like the following. This sample is shaped after the example in Oracle's RESTORE reference, and your paths, tags and timings will differ:

1channel ORA_DISK_1: starting validation of datafile backup set
2channel ORA_DISK_1: reading from backup piece /path/to/backup
3channel ORA_DISK_1: piece handle=/path/to/backup tag=TAG20130301T161038
4channel ORA_DISK_1: restored backup piece 1
5channel ORA_DISK_1: validation complete, elapsed time: 00:00:16
6Finished restore at 01-MAR-13

Oracle's guidance is direct: the lack of error messages means RMAN has confirmed that it can use these backups successfully during a real restore and recovery.

Automation

Put the commands in a backup verification script and keep the RMAN log, so you can compare runs over time.

When to Run This

  • After a change to your backup job, media, or storage location
  • Before a planned change that depends on a restore, such as a migration
  • On the routine schedule you set in your runbook
  • When you want logical checks as well, with CHECK LOGICAL
  • After a corruption report, to see what the backups hold

Troubleshooting Common Issues

If validation fails, the error stack tells you which piece or file RMAN could not use. Work through these steps:

  • Read the first error in the stack. Later lines are often side effects of the first one.
  • Check the corruption view. Query V$DATABASE_BLOCK_CORRUPTION, keeping the MAXCORRUPT rule in mind.
  • Check the alert log. If CHECK LOGICAL found a logical corruption, RMAN logs the block in the alert log and the server session trace file.
  • Check the Automatic Diagnostic Repository. Oracle notes that the V$DATABASE_BLOCK_CORRUPTION view records intrablock corruptions, while the ADR tracks all types of corruptions.
  • Take a fresh backup if needed. If a piece cannot be repaired, plan a new backup before you rely on the old one.

References

Posts in this series