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-LI 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, PHPui 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
