Re: Recovering Dropped Tables with no Backup

> > This is exactly why one should make recurring exports.
>
> Even for an instance with ARCHIVELOG mode on?

One advantage of Export is that data block corruptions can be detected while exporting and the procedure will fail. You can then address the corruption in the table and attempt the Export again. I also find it much easier to use the Import utility to restore an accidentally dropped table as to doing an incomplete recovery with physical backups. At our site we're very fortunate and can do Full Exports AND Full O/S dumps on a nightly basis after close of business.

Since blocks are physically copied from the source to the destination on physical dumps, some data block corruptions MIGHT go undetected while copying the data files (it's rare, but anything at all can and will happen). The corruptions will be propogated to the backup copy of the data file. You will realize this AFTER you've restored the data files and attempt to recover the database.

IMHO there is no such thing as TOO many backups. Regardless of your choice for a primary backup method, a site's implementation should include physical backups and exports. Those methods validate different things about a database: Export validates that it's logically sound, Physical that it is physically sound.

Regards,

    Eugene Pokopac (Oracle DBA, Tucker GA) Received on Tue Sep 17 2002 - 09:23:49 CDT