oracle - corrupt bkp

8/6/2019 Oracle - corrupt bkp

1/4

Checking backups for corruption Backup and Recovery Tips

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

Checking backups for corruption

If you use RMAN to perform backups, the contents of this paper dont apply to you. Beingan 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 anerror 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 areal 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, whichthe 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 tellit what files to check, and supply some other run-time parameters if needed. You mighttype something like this, therefore:

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

Note that you must tell dbverify what size Oracle blocks to expect when it scans the DataFile copy. If you miss that parameter out, dbverify will expect to find 2K blocks, and whenit encounters anything else, will simply abort with an error. Curiously, the error messagewill 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 doesnt simply go onto use the discovered block size for its continued work! One of lifes little mysteries, Iguess and we just have to live with it.

Youll also notice there a logfile parameter. Thats so that dbverifys work can be outputto a text file for later reading. If you miss it out, the results of the check are simplydisplayed on screen, which is probably not exactly what you want.

There are some other parameters that can be supplied, too. For example, you can requesta 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, youll want to check the logfile output. That willlook a bit like this:


2/4



DBVERIFY: R ELEASE 9.0.1.1.1 - P RODUCTION ON F RI OCT 19 09:21:30 2001

( C) COPYRIGHT 2001 ORACLE CORPORATION . A LL RIGHTS RESERVED .

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

DBVERIFY - V ERIFICATION COMPLETE

TOTAL P AGES EXAMINED : 83200TOTAL P AGES P ROCESSED (D ATA ) : 50807TOTAL P AGES F AILING (D ATA ) : 0TOTAL P AGES P ROCESSED (I NDEX ) : 7537TOTAL P AGES F AILING (I NDEX ) : 0TOTAL P AGES P ROCESSED (O THER ) : 1342

TOTAL P AGES P ROCESSED (S EG) : 0TOTAL P AGES F AILING (S EG) : 0TOTAL P AGES E MPTY : 23514TOTAL P AGES M ARKED CORRUPT : 0TOTAL P AGES I NFLUX : 0

Here, the word page means an Oracle block. So this report indicates that 83,200 blockswere looked at and the key bit is that none of them are reported as failing or markedcorrupt. That means this backup file can be considered clean, and thered be no

problems using it during a recovery.

In case youre wondering, the Total Pages Influx line is there because dbverify can beused to check for corruption in online Data Files, not just backup copies of them. Whenused for that purpose, its possible that DBWR is writing to a block just as dbverify wishesto check it at which point, dbverify gives up, and just declares that the block was beingchanged as it was being investigated.

Id go so far as to suggest that no Operating System-type backup can be consideredcomplete without running dbverify against every data file copy taken as part of the backup.Its desperately simple to run, relatively quick, and is the easiest way to find out yourbackups have problems before you start relying on them.

Now all the Oracle documentation states that dbverify can only be applied to cachemanaged files i.e., ones which are read into the Buffer Cache. So that theoretically rulesout 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 havenot run it against a 7 database, but you might give it a try and see if anything usefulresults. But as proof that it works in the 8s and 9s, I offer the following log file output:


3/4



DBVERIFY - V ERIFICATION STARTING : FILE =

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

P AGE 450 IS MARKED CORRUPT

***CORRUPT BLOCK RELATIVE DBA : 0 X200001 C2 ( FILE 128, BLOCK 450)B AD HEADER FOUND DURING DBV : D ATA IN BAD BLOCK -

TYPE : 32 FORMAT: 32 RDBA : 0 X20202020LAST CHANGE SCN : 0 X2020.20202020 SEQ : 0 X20 FLG : 0 X20CONSISTENCY VALUE IN TAIL : 0 X20202020CHECK VALUE IN BLOCK HEADER : 0 X2020, BLOCK CHECKSUM DISABLED SPARE 1: 0 X20, SPARE 2: 0 X20, SPARE 3: 0 X2020

***

DBVERIFY - V ERIFICATION COMPLETE

TOTAL P AGES EXAMINED : 450TOTAL P AGES P ROCESSED (D ATA ) : 0TOTAL P AGES F AILING (D ATA ) : 0TOTAL P AGES P ROCESSED (I NDEX ): 0TOTAL P AGES F AILING (I NDEX ): 0TOTAL P AGES P ROCESSED (O THER ): 0

TOTAL

P AGES

PROCESSED

(SEG

)

:

0TOTAL P AGES F AILING (S EG) : 0TOTAL P AGES E MPTY : 0TOTAL P AGES M ARKED CORRUPT : 450TOTAL P AGES I NFLUX : 0

Clearly, therefore, dbverify is a perfectly useful tool in ensuring that your Control Filebackups are free of corruption at least, demonstrably so in versions 8.0.5, 8.1.6, 8.1.7and 9.0.1.1. However, for anything earlier than these versions, youre really on your own.Try it and see. Dont 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 andcorruption-free (though it can obviously only be issued when the database is at least in theMOUNT stage).

So thats 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 Logswill also be copied, whatever type of backup you are doing, where they exist. How caneither of these types of Logs be checked for corruption?


4/4



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

If Log Miner encounters corruption during its analysis session (begun with the EXECUTEDBMS _ LOGMNR . START _ LOGMNR ( DICTFILENAME => HJRDICT . ORA ) command), then it simplybombs out with an error at which point you know you have a problem.

If you need to check Oracle 7 logs, however, Log Miner cant help you, and I know of noother Oracle-supplied tool that can (there are third-party tools that can do the job, butthey 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 practicerecoveries (which you should be doing anyway as a matter of ordinary precautionarymanagement). If the recoveries work, the Logs are clean. If not

oracle - corrupt bkp

Documents