>From the rest of you message, I would say there is something wrong with the hardware setup of your database. If the setup is such that you can lose an entire database of nearly 4 TB, then your backup/restore speed is the LEAST of your problems. You disk striping and mirroring should prevent the lose of the database in the vent of a disk failure; I would even consider mirroring across more than one storage array so that you can survive the loss of an entire storage array.
If finances don't permit complete redundancy, the setup should be such that you never lose more than fraction of the database (i.e. a datafile or two ... or three). Then you only restore and recover the datafile(s) rather than the entire database. I can't imagine a setup where the loss of a disk, or even a controller, would cause the COMPLETE loss of a 4TB database. This whole thing looks very much like somebody screwed up and delete files. I suspect that a trip to Hell would reveal the "rm -rf *" command sitting at Satan's right hand. > -----Original Message----- > We are evaluating a "strange" way to "recover" a production DB. > This is a 3.7 TB database, -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephen Lee 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).
