This chapter explains how to check the integrity of database files and backups. This chapter contains the following topics:
This section explains the basic concepts and tasks involved in RMAN validation.
The main purpose of RMAN validation is to check for corrupt blocks and missing files. You can also use RMAN to determine whether backups can be restored. You can use the following RMAN commands to perform validation:
VALIDATE
BACKUP ... VALIDATE
RESTORE ... VALIDATE
See Also:
Oracle Database Backup and Recovery Reference for VALIDATE
syntax
Oracle Database Backup and Recovery Reference for RESTORE ... VALIDATE
syntax
The database prevents operations that result in unusable backup files or corrupted restored data files. The database automatically does the following:
Blocks access to data files while they are being restored or recovered
Permits only one restore operation for each data file at a time
Ensures that incremental backups are applied in the correct order
Stores information in backup files to allow detection of corruption
Checks a block every time it is read or written in an attempt to report a corruption as soon as it has been detected
A corrupt block is a block that has been changed so that it differs from what Oracle Database expects to find. Block corruptions can be caused by several different failures including, but not limited to the following:
Faulty disks and disk controllers
Faulty memory
Oracle Database software defects
DB_BLOCK_CHECKSUM
is a database initialization parameter that controls the writing of checksums for the blocks in data files and online redo log files in the database (not backups). If DB_BLOCK_CHECKSUM
is typical
, then the database computes a checksum for each block during normal operations and stores it in the header of the block before writing it to disk. When the database reads the block from disk later, it recomputes the checksum and compares it to the stored value. If the values do not match, then the block is corrupt.
By default, the BACKUP
command computes a checksum for each block and stores it in the backup. The BACKUP
command ignores the values of DB_BLOCK_CHECKSUM
because this initialization parameter applies to data files in the database, not backups.
In a physical corruption, which is also called a media corruption, 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.
Note:
By default, the BACKUP
command computes a checksum for each block and stores it in the backup. If you specify the NOCHECKSUM
option, then RMAN does not perform a checksum of the blocks when creating the backup.
In a logical corruption, the contents of the block are logically inconsistent. Examples of logical corruption include corruption of a row piece or index entry. If RMAN detects logical corruption, then it logs the block in the alert log and server session trace file.
By default, RMAN does not check for logical corruption. If you specify CHECK LOGICAL
on the BACKUP
command, however, then RMAN tests data and index blocks for logical corruption, such as corruption of a row piece or index entry, and log them in the alert log located in the Automatic Diagnostic Repository (ADR). If you use RMAN with the following configuration when backing up or restoring files, then it detects all types of block corruption that are possible to detect:
In the initialization parameter file of a database, set DB_BLOCK_CHECKSUM=typical
so that the database calculates data file checksums automatically (not for backups, but for data files in use by the database)
Do not precede the BACKUP
command with SET MAXCORRUPT
so that RMAN does not tolerate any unmarked block corruptions.
In a BACKUP
command, do not specify the NOCHECKSUM
option so that RMAN calculates a checksum when writing backups
In BACKUP
and RESTORE
commands, specify the CHECK
LOGICAL
option so that RMAN checks for logical and physical corruption
You can use the SET MAXCORRUPT
command to set the total number of unmarked corruptions permitted in a file for RMAN backups. The default is zero, meaning that RMAN does not tolerate unmarked corrupt blocks of any kind.
If the MAXCORRUPT
limit is exceeded when RMAN encounters an unmarked corrupt block during a backup, then RMAN terminates the backup. Otherwise, RMAN writes the newly detected corrupt block to the backup with a special header indicating that the block is marked corrupt. You can use the VALIDATE
command to determine which blocks are marked as corrupt and to find any unmarked corrupt blocks.
Because RMAN allows marked corrupt blocks in a backup, and because RMAN can be instructed to allow unmarked corrupt blocks to be marked as corrupt in the backup (when MAXCORRUPT
is used), it is possible to restore a data file that has several blocks marked as corrupt. If you backup this restored data file (assuming no new corruptions have happened), even without MAXCORRUPT
setting, the backup succeeds. This is because the previously marked corruptions do not stop RMAN from completing the backup.
See Also:
Oracle Database Backup and Recovery Reference for SET
MAXCORRUPT
syntax
Oracle Database supports different techniques for detecting, repairing, and monitoring block corruption. The technique depends on whether the corruption is interblock corruption or intrablock corruption. In intrablock corruption, the corruption occurs within the block itself. This corruption can be either physical or logical. In an interblock corruption, the corruption occurs between blocks and can only be logical.
For example, the V$DATABASE_BLOCK_CORRUPTION
view records intrablock corruptions, while the Automatic Diagnostic Repository (ADR) tracks all types of corruptions. Table 16-1 summarizes how the database treats different types of block corruption.
Table 16-1 Detection, Repair, and Monitoring of Block Corruption
Response | Intrablock Corruption | Interblock Corruption |
---|---|---|
Detection |
All database utilities detect intrablock corruption, including RMAN (for example, the |
Only DBVERIFY and the |
Tracking |
The |
The database monitors this type of block corruption in ADR. |
Repair |
Repair techniques include block media recovery, restoring data files, recovering with incremental backups, and block newing. Block media recovery can repair physical corruptions, but not logical corruptions. Any RMAN command that fixes or detects that a block is repaired updates |
You must fix interblock corruption using manual techniques such as dropping an object, rebuilding an index, and so on. |
See Also:
You can use the VALIDATE
command to manually check for physical and logical corruptions in database files. This command performs the same types of checks as BACKUP VALIDATE
, but VALIDATE
can check a larger selection of objects. For example, you can validate individual blocks with the VALIDATE DATAFILE ... BLOCK
command.
When validating whole files, RMAN checks every block of the input files. If the backup validation discovers previously unmarked corrupt blocks, then RMAN updates the V$DATABASE_BLOCK_CORRUPTION
view with rows describing the corruptions.
Use VALIDATE BACKUPSET
when you suspect that one or more backup pieces in a backup set are missing or have been damaged. This command checks every block in a backup set to ensure that the backup can be restored. If RMAN finds block corruption, then it issues an error and terminates the validation. The command VALIDATE BACKUPSET
enables you to choose which backups to check, whereas the VALIDATE
option of the RESTORE
command lets RMAN choose.
To use VALIDATE to check database files and backups:
Start RMAN and connect to a target database.
See Also:
Execute the VALIDATE
command with the desired options.
For example, to validate all data files and control files (and the server parameter file if one is in use), execute the following command at the RMAN prompt:
RMAN> VALIDATE DATABASE;
Alternatively, you can validate a particular backup set by using the form of the command shown in the following example (sample output included).
RMAN> VALIDATE BACKUPSET 22; Starting validate at 17-AUG-13 using channel ORA_DISK_1 allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: SID=89 device type=SBT_TAPE channel ORA_SBT_TAPE_1: Oracle Secure Backup channel ORA_DISK_1: starting validation of datafile backup set channel ORA_DISK_1: reading from backup piece /disk1/oracle/work/orcva/RDBMS/backupset/2013_08_16/o1_mf_nnndf_ TAG20130816T153034_2g774bt2_.bkp channel ORA_DISK_1: piece handle=/disk1/oracle/work/orcva/RDBMS/backupset/2013_08_16/o1_mf_nnndf_ TAG20130816T153034_2g774bt2_.bkp tag=TAG20130816T153034 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: validation complete, elapsed time: 00:00:01 Finished validate at 17-AUG-13
The following example illustrates how you can check individual data blocks within a data file for corruption.
RMAN> VALIDATE DATAFILE 1 BLOCK 10; Starting validate at 17-AUG-13 using channel ORA_DISK_1 channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: specifying datafile(s) for validation input datafile file number=00001 name=/disk1/oracle/dbs/tbs_01.f channel ORA_DISK_1: validation complete, elapsed time: 00:00:01 List of Datafiles ================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 1 OK 0 2 127 481907 File Name: /disk1/oracle/dbs/tbs_01.f Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 36 Index 0 31 Other 0 58 Finished validate at 17-AUG-13
Make Parallel the Validation of a Data File
If you must validate a large data file, then RMAN can make the work parallel by dividing the file into sections and processing each file section in parallel. If multiple channels are configured or allocated, and if you want the channels to make parallel the validation, then specify the SECTION SIZE
parameter of the VALIDATE
command.
If you specify a section size that is larger than the size of the file, then RMAN does not create file sections. If you specify a small section size that would produce more than 256 sections, then RMAN increases the section size to a value that results in exactly 256 sections.
To make parallel the validation of a data file:
See Also:
Oracle Database Backup and Recovery Reference to learn about the VALIDATE
command
Check data files for physical and logical block corruption
Confirm that all database files exist and are in the correct locations
When you run BACKUP VALIDATE
, RMAN reads the files to be backed up in their entirety, as it does during a real backup. RMAN does not, however, actually produce any backup sets or image copies.
You cannot use the BACKUPSET
, MAXCORRUPT
, or PROXY
parameters with BACKUP VALIDATE
. To validate specific backup sets, run the VALIDATE
command.
To validate files with the BACKUP VALIDATE command:
See Also:
Oracle Database Backup and Recovery Reference for BACKUP
syntax
Performing Block Media Recoveryto learn how to repair corrupt blocks discovered by BACKUP
VALIDATE
You can run RESTORE
...
VALIDATE
to test whether RMAN can restore a specific file or set of files from a backup. RMAN chooses which backups to use.
The database must be mounted or open for this command. You do not have to take data files offline when validating the restore of data files, because validation of backups of the data files only reads the backups and does not affect the production data files.
When validating files on disk or tape, RMAN reads all blocks in the backup piece or image copy. RMAN also validates offsite backups. The validation is identical to a real restore operation except that RMAN does not write output files.
Note:
As an additional test measure, you can perform a trial recovery with the RECOVER ... TEST
command. A trial recovery applies redo in a way similar to normal recovery, but it is in memory only and it rolls back its changes after the trial.
To validate backups with the RESTORE command:
See Also:
Oracle Database Backup and Recovery Reference to learn about the RESTORE ... VALIDATE
command
RMAN enables you to validate multitenant container databases (CDBs) and pluggable databases (PDBs). All of the procedures in this chapter apply to CDBs, with the differences described in the following sections:
The steps to validate a CDB are similar to the ones used to validate a non-CDB. The only difference is that you must connect to the root as a common user with the common SYSBACKUP
or SYSDBA
privilege. Then, use the VALIDATE DATABASE
and RESTORE DATABASE VALIDATE
commands.
See Also:
The following command, when connected to the root, validates the whole CDB:
VALIDATE DATABASE;
The following command validates the root:
VALIDATE DATABASE ROOT;
Use one of the following techniques to validate PDBs:
Connect to the root and use the VALIDATE PLUGGABLE DATABASE
or RESTORE PLUGGABLE DATABASE VALIDATE
command. This enables you to validate one or more PDBs.
The following command, when connected to the root, validates the PDBs hr_pdb
and sales_pdb
.
VALIDATE PLUGGABLE DATABASE hr_pdb, sales_pdb;
Connect to the PDB and use the VALIDATE DATABASE
and RESTORE DATABASE VALIDATE
commands to validate only one PDB. The commands used here are the same commands that you would use for a non-CDB.
The following command, when connected to a PDB, validates the restore of the database.
RESTORE DATABASE VALIDATE;
See Also: