Re: Mirrored disks Vs duplexed logs

jared_at_psnw.com (Jared Still) writes:

>Deleting a tablespace data file is an error that can be recovered from
>without data loss.
 

>Deleting a unarchived non-mirrored redo log file _will_ result in
>data loss.

So will deleting a tablespace data file. What do you think happens to the in progress, uncommitted transactions when the tablespace is taken offline due to an error writing to a data file? What will it cost to restart those transactions? What about the cost to the business of lost productivity, sales, etc. while the tablespace is being recovered? What about the application which has commited data even though its "transaction" is not complete? How difficult will it be to cleanup and restart that application?

Almost any database recovery will be costly for the business. Certainly mirrored redo logs will minimize the cost and pain and provide valuable protection against system failures. But I still maintain that it is silly to consider this feature as providing protection against incompetency.

It should also be noted that thanks to a "feature" of the UNIX filesystem the removal of a database file (whether tablespace data or redo log) will not immediately take down the database. The server processes for the instance which have the file open will be able to continue performing I/O to the file. An error will only be returned on the next attempt to open the file. Which, for a tablespace data file, will typically be on the next connection to the database (i.e., when the next oracle shadow is started). It's conceivable that the removal of a data file would not be noticed until the next instance warmstart. The loss of a redo log would be noticed the next time a switch to that log occurs, not when the next write to the log is performed by the ora_lgwr process.

-- 
Kurtis D. Rader, Senior Consultant           krader_at_sequent.com (email)
Sequent Computer Systems             +1 503/578-3714 (voice)  +65 223-5116 (fax)
80 Robinson Road, #18-03                   Currently on assignment in the
Singapore, 0106                                 Asia-Pacific region