microsoft word - checking backups for corruption

Checking backups for corruption Backup and Recovery Tips

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

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:



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:



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?



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…

microsoft word - checking backups for corruption

Documents