As of version 15.1 ESD #3, Sybase IQ includes a mechanism that verifies an existing Sybase IQ version 12.6 or later database backup using the VERIFY clause of the RESTORE SQL statement. The verification process checks the specified archive for the same errors a restore process checks, but performs no write operations. All status and error messages are written to the server log file.
RESTORE DATABASE 'db_file' FROM 'archive_device' [ FROM 'archive_device' ]... [ CATALOG ONLY ] [ KEY key_spec ] [ [ RENAME dbspace-name TO 'new-dbspace-path']... | VERIFY [ COMPATIBLE ] ]
See “RESTORE statement” in Chapter 1, “SQL Statements” in Reference: Statements and Options for the complete RESTORE syntax, parameter descriptions, and usage.
RESTORE DATABASE <database_name.db> FROM '/sys1/dump/dmp1' FROM '/sys1/dump/dmp2' VERIFY
The VERIFY clause of the RESTORE command directs the server to validate the specified Sybase IQ database backup archives for a full, incremental, incremental since full, or virtual backup without performing any write operations.
You cannot use the RENAME clause with the VERIFY clause; an error is reported.
The backup verification process can run on a different host than the database host.
If you specify the COMPATIBLE clause with VERIFY, the compatibility of an incremental archive is checked with the existing database files. If the database files do not exist on the system on which you invoke RESTORE…VERIFY COMPATIBLE, an error is returned. If you specify COMPATIBLE while verifying a full backup, the keyword is ignored; no compatibility checks need to be made while restoring a full backup.
You must have the database and log files (.db and .log) to validate the backup of a read-only dbspace within a full backup. If you do not have these files, validate the entire backup by running RESTORE…VERIFY without the READONLY dbspace clause.
The verification of a backup archive is different than
the database consistency checker (DBCC) verify mode (
sp_iqcheckdb 'verify...'
). RESTORE
VERIFY validates the consistency of the backup archive
to be sure it can be restored, whereas DBCC validates the consistency
of the database data.
Run sp_iqcheckdb 'verify...'
before
taking a backup. If an inconsistent database is backed up, then
restored from the same backup archive, the data continues to be
in an inconsistent state, even if RESTORE VERIFY reports
a successful validation.
If you specify RESTORE VERIFY without COMPATIBLE for an incremental restore, Sybase IQ does not look for any dbspaces and does not perform any compatibility checks. No warning is reported, even if the files do not exist. The compatibility check is performed only when you include the COMPATIBLE clause.
If you specify RESTORE VERIFY COMPATIBLE for an incremental restore and the IQ catalog store or any of the Sybase IQ dbspaces do not exist, the compatibility check cannot be made; an error is reported and the operation fails.
During validation of an incremental backup, the RESTORE VERIFY COMPATIBLE process opens the Sybase IQ dbspaces in read-only mode to perform consistency checking. No dbspaces are modified.
In the case of incremental restores, if the database has been
modified or the particular incremental archive is not the correct
archive for the database, RESTORE VERIFY COMPATIBLE reports
the error Database has changed since last restore.
(SQLCODE
-1012008, SQLSTATE QUA08) or This restore cannot
immediately follow the previous restore.
(SQLCODE
-1012009, SQLSTATE QUA09).
The RESTORE VERIFY process verifies every stripe specified in the command. As the verification process checks stripes and their corresponding files, it reports progress in terms of the number of IQ blocks verified. After every 5000 IQ blocks verified, a message is written to the server log file with the percentage of the number of IQ blocks completed:
5000/100000 (5%) Blocks verified
A final message is written to the server log file when 100% of the IQ blocks are verified.
The messages RESTORE VERIFY Started
,
the number of IQ blocks to be verified, and RESTORE
VERIFY successfully completed
are also written in
the server log, when the verify action starts and completes, respectively.
For example:
I. 11/17 06:45:24. VERIFY RESTORE Started I. 11/17 06:45:24. Total number of IQ blocks to be verified: 764 I. 11/17 06:45:24. Total number of IQ blocks verified: 764/764 ( 100 % ) I. 11/17 06:45:24. VERIFY RESTORE Successfully Complete
If the verification process finds errors after which it can continue, the process continues checking the archive and logs information for the errors detected. The errors for which the verification can continue are:
Header of block to be restored appears to be corrupted. (SQLCODE -1012011l, SQLSTATE QUA11)
Media data appears corrupted (bad checksum). (SQLCODE -1012012, SQLSTATE QUA12)
Media meta data appears corrupted (boundary record). (SQLCODE -1012013, SQLSTATE QUA13)
Media meta data appear corrupted (multiple begin boundary records). (SQLCODE -1012014, SQLSTATE QUA14
If any of these errors are found and the verification process can continue to the end of the archive, this error is reported:
The verification of the provided archive has failed. Please check the server log for details of the errors thrown during verify.
If any error pertaining to RESTORE is found other than the errors above, the error that occurred is reported, and the verification process stops.
Must have DBA or BACKUP authority.
“RESTORE statement” in Chapter 1, “SQL Statements” in Reference: Statements and Options
“BACKUP statement” in Chapter 1, “SQL Statements” in Reference: Statements and Options
Chapter 12, “Data Backup, Recovery, and Archiving” in System Administration Guide: Volume 1