Re: Database Verification

And in the extreme end of the spectrum, you might want to learn about block dumps in order to be prepared for the day when you have a corrupted block. The block dumps can show people - who know what they're looking for, ie have prepared - a lot of useful information. Might be a valuable piece of documentation for an iTAR, too.

Mogens

Fink, Dan wrote:

>Pui Ho,
> Stephane raises a good point, unfortunately, many operations groups
>stop at the backup. It is not the responsibility of operations to backup the
>database/system. It is the responsibility of operations to recover the
>database/system. There are many stories of backups that execute flawlessly,
>but they cannot be used to recover. An untested backup strategy is an
>invalid backup strategy.
> As for the corruption, export and dbverify each have
>advantages/disadvantages.
> Export performs a full table scan on each table in the exported
>schema. However, it does not export SYS objects and it does not read the
>indexes. It may/may not read rollback segments.
> Dbverify reads the header and footer of each block in the datafile.
>As I recall (from the Internals seminar 3 years ago), it does not read the
>bytes in between, so a corruption may be missed. It also may report
>incorrectly, if the block it is verifying is written at the same time.
>
> To guard against corruption, do 3 things.
> 1) Have a solid and tested recovery process
> 2) Run periodic exports (send output to /dev/null)
> 3) Run dbv on live datafiles (during slow times) and backup files
>(if kept on disk)
>
>Dan Fink
>
>-----Original Message-----
>Sent: Friday, January 17, 2003 6:59 AM
>To: Multiple recipients of list ORACLE-L
>
>
>
>
>>I am considering the appropriate way to do database
>>corruption prevention.
>>
>>Should I use one or more of the following as a
>>proactive measure ?
>> a) Export
>> b) DBVerify
>> c) Analyze table <table_name> validate structure
>>cascade
>>
>>Any advice ?
>>
>>Thanks,
>>
>>PH
>>
>>
>>
>
>Pui Ho,
>
> The only way you can be 'proactive' concerning corruption is to have a
>sound backup strategy - if you really feel nervous about your hardware,
>first change it, and then use archive logging and the rest; export is a bad
>solution, because it will be long to restore. By definition, a corruption
>doesn't give any warning (it's even worth than earthquakes). If you want to
>be very reactive, set something to regularly scan your alert.log file.
>
>Regards,
>
>Stephane Faroult
>Oriole
>
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?=
  INET: mln_at_miracleas.dk

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).