Published on

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Checking backups for corruption Backup and Recovery TipsChecking backups for corruptionIf you use RMAN to perform backups, the contents of this paper don’t apply to you. Beingan Oracle utility, RMAN knows the structure of Oracle blocks, and can therefore detectcorruption 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 ofthe 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 tocheck 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:BACKUPSSYSTEM01.BKP BLOCKSIZE=8192 LOGFILE=DBVLOG.TXTNote 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, ifit can identify the correct block size for the sake of error reporting, it doesn’t simply go onto use the discovered block size for its continued work! One of life’s little mysteries, Iguess –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 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. Ifyou need the complete list of available parameters, just type:C:> DBV HELP=YWhen dbverify has completed its work, you’ll want to check the logfile output. That willlook a bit like this:Copyright © Howard Rogers 2001 24/10/2001 Page 1 of 4
  2. 2. Checking backups for corruption Backup and Recovery TipsDBVERIFY: RELEASE - PRODUCTION ON FRI OCT 19 09:21:30 2001(C) COPYRIGHT 2001 ORACLE CORPORATION. ALL RIGHTS RESERVED.DBVERIFY - VERIFICATION STARTING : FILE = D:BACKUPS SYSTEM01.BKPDBVERIFY - VERIFICATION COMPLETETOTAL PAGES EXAMINED : 83200TOTAL PAGES PROCESSED (DATA) : 50807TOTAL PAGES FAILING (DATA) : 0TOTAL PAGES PROCESSED (INDEX) : 7537TOTAL PAGES FAILING (INDEX) : 0TOTAL PAGES PROCESSED (OTHER) : 1342TOTAL PAGES PROCESSED (SEG) : 0TOTAL PAGES FAILING (SEG) : 0TOTAL PAGES EMPTY : 23514TOTAL PAGES MARKED CORRUPT : 0TOTAL PAGES INFLUX : 0Here, 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 there’d be noproblems using it during a recovery.In case you’re 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, it’s 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.I’d 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.It’s 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:Copyright © Howard Rogers 2001 24/10/2001 Page 2 of 4
  3. 3. Checking backups for corruption Backup and Recovery TipsDBVERIFY - VERIFICATION STARTING : FILE =D:ORACLEORADATAHJR9CONTROL03.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 COMPLETETOTAL PAGES EXAMINED : 450TOTAL PAGES PROCESSED (DATA) : 0TOTAL PAGES FAILING (DATA) : 0TOTAL PAGES PROCESSED (INDEX): 0TOTAL PAGES FAILING (INDEX): 0TOTAL PAGES PROCESSED (OTHER): 0TOTAL PAGES PROCESSED (SEG) : 0TOTAL PAGES FAILING (SEG) : 0TOTAL PAGES EMPTY : 0TOTAL PAGES MARKED CORRUPT : 450TOTAL PAGES INFLUX : 0Clearly, 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 However, for anything earlier than these versions, you’re really on your own.Try it and see. Don’t forget, however, that the SQL commandALTER DATABASE BACKUP CONTROLFILE TO ‘D:BACKUPSCONTROL01.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 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 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?Copyright © Howard Rogers 2001 24/10/2001 Page 3 of 4
  4. 4. Checking backups for corruption Backup and Recovery TipsWell, dbverify honestly cannot be used to verify redo log files, whether of the Online orArchived 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 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 can’t 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…Copyright © Howard Rogers 2001 24/10/2001 Page 4 of 4