Checking backups for corruption Backup and Recovery Tips

Checking backups for corruption

If you use RMAN to perform backups, the contents of this paper don’t apply to you. Being
an Oracle utility, RMAN knows the structure of Oracle blocks, and can therefore detect
corruption as it is backing things up. If any corruption is encountered, it will throw an
error stack the size of the Empire State Building, and proceed no further.

If you are using Operating System techniques to take your backups, though, then there is a
real risk that the resulting copies of Data Files and so forth might get corrupted as part of
the backup process –or that the Data Files themselves already contain corruption, which
the O/S just happily copies across, oblivious to its presence.

Fortunately, Oracle supplies a handy little utility called “dbverify” which can be used to
check the backed up copies of the Data Files for corruption, once the backup has finished.

This utility is run from the command line, by typing in the command dbv. You simply tell
it what files to check, and supply some other run-time parameters if needed. You might
type something like this, therefore:

C:\> DBV FILE=D:\BACKUPS\SYSTEM01.BKP BLOCKSIZE=8192 LOGFILE=DBVLOG.TXT

Note that you must tell dbverify what size Oracle blocks to expect when it scans the Data
File copy. If you miss that parameter out, dbverify will expect to find 2K blocks, and when
it encounters anything else, will simply abort with an error. Curiously, the error message
will tell you precisely what block size it did encounter –and you might well wonder why, if
it can identify the correct block size for the sake of error reporting, it doesn’t simply go on
to use the discovered block size for its continued work! One of life’s little mysteries, I
guess –and we just have to live with it.

You’ll also notice there a ‘logfile’ parameter. That’s so that dbverify’s work can be output
to a text file for later reading. If you miss it out, the results of the check are simply
displayed on screen, which is probably not exactly what you want.

There are some other parameters that can be supplied, too. For example, you can request
a check of parts of a Data File copy, by specifying the start and end block addresses. If
you need the complete list of available parameters, just type:

C:\> DBV HELP=Y

When dbverify has completed its work, you’ll want to check the logfile output. That will
look a bit like this:

Copyright © Howard Rogers 2001 24/10/2001 Page 1 of 4

Checking backups for corruption Backup and Recovery Tips

DBVERIFY: RELEASE 9.0.1.1.1 - PRODUCTION ON FRI OCT 19 09:21:30 2001

(C) COPYRIGHT 2001 ORACLE CORPORATION. ALL RIGHTS RESERVED.

DBVERIFY - VERIFICATION STARTING : FILE = D:\BACKUPS\ SYSTEM01.BKP

DBVERIFY - VERIFICATION COMPLETE

TOTAL PAGES EXAMINED : 83200

TOTAL PAGES PROCESSED (DATA) : 50807
TOTAL PAGES FAILING (DATA) : 0
TOTAL PAGES PROCESSED (INDEX) : 7537
TOTAL PAGES FAILING (INDEX) : 0
TOTAL PAGES PROCESSED (OTHER) : 1342
TOTAL PAGES PROCESSED (SEG) : 0
TOTAL PAGES FAILING (SEG) : 0
TOTAL PAGES EMPTY : 23514
TOTAL PAGES MARKED CORRUPT : 0
TOTAL PAGES INFLUX : 0

Here, the word “page” means an Oracle block. So this report indicates that 83,200 blocks
were looked at –and the key bit is that none of them are reported as “failing” or “marked
corrupt”. That means this backup file can be considered clean, and there’d be no
problems using it during a recovery.

In case you’re wondering, the “Total Pages Influx” line is there because dbverify can be
used to check for corruption in online Data Files, not just backup copies of them. When
used for that purpose, it’s possible that DBWR is writing to a block just as dbverify wishes
to check it –at which point, dbverify gives up, and just declares that the block was being
changed as it was being investigated.

I’d go so far as to suggest that no Operating System-type backup can be considered

complete without running dbverify against every data file copy taken as part of the backup.
It’s desperately simple to run, relatively quick, and is the easiest way to find out your
backups have problems before you start relying on them.

Now all the Oracle documentation states that dbverify can only be applied to ‘cache
managed files’ –i.e., ones which are read into the Buffer Cache. So that theoretically rules
out running it against the Control Files and seeing whether they are internally corrupt.
However, in Oracle version 8.0, 8i and 9i, you can run the tool against Control Files. I have
not run it against a 7 database, but you might give it a try and see if anything useful
results. But as proof that it works in the 8s and 9s, I offer the following log file output:

Copyright © Howard Rogers 2001 24/10/2001 Page 2 of 4

Checking backups for corruption Backup and Recovery Tips

DBVERIFY - VERIFICATION STARTING : FILE =

D:\ORACLE\ORADATA\HJR9\CONTROL03.CTL !NOTE IT’S A CONTROL FILE!!
[SNIP]

PAGE 450 IS MARKED CORRUPT

***
CORRUPT BLOCK RELATIVE DBA: 0X200001C2 (FILE 128, BLOCK 450)
BAD HEADER FOUND DURING DBV:
DATA IN BAD BLOCK -
TYPE: 32 FORMAT: 32 RDBA: 0X20202020
LAST CHANGE SCN: 0X2020.20202020 SEQ: 0X20 FLG: 0X20
CONSISTENCY VALUE IN TAIL: 0X20202020
CHECK VALUE IN BLOCK HEADER: 0X2020, BLOCK CHECKSUM DISABLED
SPARE1: 0X20, SPARE2: 0X20, SPARE3: 0X2020
***

DBVERIFY - VERIFICATION COMPLETE

TOTAL PAGES EXAMINED : 450

TOTAL PAGES PROCESSED (DATA) : 0
TOTAL PAGES FAILING (DATA) : 0
TOTAL PAGES PROCESSED (INDEX): 0
TOTAL PAGES FAILING (INDEX): 0
TOTAL PAGES PROCESSED (OTHER): 0
TOTAL PAGES PROCESSED (SEG) : 0
TOTAL PAGES FAILING (SEG) : 0
TOTAL PAGES EMPTY : 0
TOTAL PAGES MARKED CORRUPT : 450
TOTAL PAGES INFLUX : 0

Clearly, therefore, dbverify is a perfectly useful tool in ensuring that your Control File
backups are free of corruption… at least, demonstrably so in versions 8.0.5, 8.1.6, 8.1.7
and 9.0.1.1. However, for anything earlier than these versions, you’re really on your own.
Try it and see. Don’t forget, however, that the SQL command

ALTER DATABASE BACKUP CONTROLFILE TO ‘D:\BACKUPS\CONTROL01.BKP’;

…is guaranteed to result in a binary image of the Control File which is consistent and
corruption-free (though it can obviously only be issued when the database is at least in the
MOUNT stage).

So that’s Data Files and Control Files dealt with: how about the Redo Logs?

Online Redo Logs may be copied if you are taking cold backups, and Archived Redo Logs
will also be copied, whatever type of backup you are doing, where they exist. How can
either of these types of Logs be checked for corruption?
Copyright © Howard Rogers 2001 24/10/2001 Page 3 of 4
Checking backups for corruption Backup and Recovery Tips

Well, dbverify honestly cannot be used to verify redo log files, whether of the Online or
Archived variety (if you try it, you’ll get a report indicating that the entire file is corrupted,
which simply means it doesn’t understand their contents). Therefore, the only really
viable tool is Log Miner –and that was only introduced in Oracle 8.1.x (though it can be
used from there to examine 8.0.x-version logs).

If Log Miner encounters corruption during its analysis session (begun with the EXECUTE
DBMS_LOGMNR.START_LOGMNR(DICTFILENAME=>’HJRDICT.ORA’) command), then it simply
bombs out with an error –at which point you know you have a problem.

If you need to check Oracle 7 logs, however, Log Miner can’t help you, and I know of no
other Oracle-supplied tool that can (there are third-party tools that can do the job, but
they cost an arm and a leg –yet another reason for upgrading to a more recent version).

I can offer, therefore, no better suggestion than that you perform regular practice
recoveries (which you should be doing anyway as a matter of ordinary precautionary
management). If the recoveries work, the Logs are clean. If not…

Copyright © Howard Rogers 2001 24/10/2001 Page 4 of 4