When making database backups, you must regularly perform a verify.
If you fail to verify backups, you might find that a backup cannot be used in the event of a database restore. Even if a backup is reported as successfully completed, this does not mean that it is always error-free.
There are the following types of verify:
? Backup tape readability
This verify checks the backup media (that is, usually tape). It checks the size of the backup files and whether the data can be read. In some cases, it also compares the backed-up data with the contents of the database files byte-by-byte.
? Database block consistency
This verify checks the database itself block-by-block, validating internal block consistency.
We recommend that, at least once in every backup cycle, you perform both types of verify. If possible, perform verify once a week, or even for every backup.
? Verify adds considerably to backup run times.
? Verify is mainly performed on complete backup volumes. A volume is first written and then verified.
This type of verify only checks the backup tape readability. The method and extent of a brbackup verify differs according to whether the backup is online or offline:
? Offline backup
After the backup the files are copied back to a temporary directory, compress_dir, and the contents are compared to the original data in the database byte by byte. This means that backup tape readability and size are checked.
? Online backup
After the backup the files are copied back to a temporary directory, compress_dir, but only the file sizes are compared. The byte-by-byte compare used in an offline backup is not possible with an online backup because the database is constantly changing as updates continue. This means that only backup tape readability and size are checked.
For more information, see brbackup -w|-verify.
This type of verify with BRRESTORE only checks the backup tape readability, separately from the backup, at a later time if you want. You can also perform this type of verify on another computer if the backups are available there.
BRRESTORE only checks whether the backup can be read and its size, not the contents. The files are only read, not restored.
For more information, see brrestore -w|-verify
This type of verify with BRARCHIVE only checks the backup tape readability. The extent of the check on archived offline redo log files depends on the type of BRARCHIVE backup:
? brarchive -s|-sc|-ss|-cs
The backed-up files are restored and compared with the originals byte by byte.
? brarchive -sd|-scd|-ssd|-cds
The backed-up files are restored and file sizes are checked. Since the originals were deleted, a check on the contents is not possible.
For more information, see -brarchive -w|-verify
The Oracle DBVERIFY tool is available for both types of verify, that is, backup tape readability (but without a byte-by-byte comparison) and database block consistency. This means you can recognize errors early (for example, ORA-1578), before they lead to the termination of a program in an application that accesses the blocks.
You can use DBVERIFY as follows:
? Database backup with subsequent restore to a temporary directory (compress_dir) and check on the Oracle block consistency:
brbackup -w use_dbv
? Online check of block consistency on the database files without backup:
brbackup -w only_dbv
Any number of these verify processes can run in parallel, using parameter exec_parallel, option -e.
? Temporary restore of a database backup (compress_dir) and verify of the database block consistency:
brrestore -w use_dbv
The restore implicitly checks the readability of the backup.
? You can now also verify backups on local disks – that is, using backup_dev_type = disk– with software compression (compress = yes).
A verify with DBVERIFY of database backups on tape – that is, using backup_dev_type = tape | tape_auto | tape_box | pipe | pipe_auto | pipe_box with software compression – is still not possible. However, this limitation is usually irrelevant since tape backups are normally performed with hardware compression, not software compression.
? Verify of BACKINT Backups
You can now fully verify third-party backups using the BACKINT interface, as specified above in “Verify of Backups with Oracle DBVERIFY”.
The files to be verified are loaded back to the temporary directories (or to a single directory) specified by the init<DBSID>.sap parameter compress_dir. DBVERIFY then compares them with the original files. You can perform the verify in several steps. The required free space must be at least 10% of the backup size (for databases greater than 1 TB, this is at least 100 GB), so that the number of steps required is not too great.
Since the verification in transaction DB13 always uses –w use_dbv, there is a change to the verify of BACKINT backups. The backup is always reloaded and verified. This doubles the runtime of the backup.
If you do not want to fully deactivate the verify, set the init<DBSID>.sap parameter compress_dir to point to a directory with a small amount of free space (less than 10% of the backup size). BRBACKUP then switches automatically to BACKINT query mode (only_conf).
Of course, you can perform BACKINT backup verification directly using the backup tool (if supported). Some backup tools offer special parameters in the BACKINT parameter file, init<SID>.utl, that you can use to activate the verification independent of the option -w|-verify. For more information, consult your BACKINT provider.
? Query only whether the backup is known, using the BACKINT query function:
brbackup -w only_conf
This option does what the option brbackup –w used to do, before the functionality of BACKINT verify was extended.
? Verify of RMAN Backups
You can also access an external backup tool using the Oracle Recovery Manager (RMAN) with the parameter backup_dev_type = rman_util. This also gives you a complete range of functions for verification:
0 The RMAN VALIDATE command is used for verifying backups. In this case, data is physically read by the backup medium and checked by RMAN for consistency.
0 The verification with DBVERIFY is no longer required because for each backup all saved database files are checked by RMAN for internal Oracle block consistency.