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: Stephane Faroul
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Fink, Dan
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
