Hello Andrey You can use the DataBee (www.databee.com) to generate scripts for the creation of the database.
I think that you can create a small database, with the same sid and directory structure, on another machine and apply all the scripts there. Then you copy the files to a backup directory on the main server and let it wait. In case of need you just copy the files over the production database and restart the instance and you have a working database in a few seconds. Then you run the import and you are ready for production. You can then create the big tablespaces and import the historical data. Do not forget - the more time it take to import the historical data the less you have to do since some days already passed :-). Yechiel Adar Mehish ----- Original Message ----- To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent: Sunday, November 24, 2002 7:23 PM > Dear gurus! > We are evaluating a "strange" way to "recover" a production DB. > This is a 3.7 TB database, still growing, with LOTS of data inserted every 5 > minutes (and several partitions belonging to several tables get dropped each > day - we keep historical data for 90 days back), which we used to backup > with RMAN to HP Omniback controlled tapes. > We had a failure, and it took almost 48 hours to restore/recover the DB (in > addition to backed DB files, I had to restore thousands of archived logs > from tapes and apply them to the DB). > We can not afford to have the DB down for 2 days. > Now, we decided to give up RMAN hot backup, actually to give up backup (in > it's classic meaning) at all. > I'll explain why: It's very important for us to get the DB up & running ASAP > after a crash. We want the DB operating much more than we care about > historical data that reside in our DB. Our goal is to enable the inserts > (which run every 5 minutes, as I have stated) ASAP. > So, we plan to do the following backup/recovery procedures: > 1) We want to generate a script that will build the basics of the DB - > create the DB and the instance, build tablespaces, users, grants, roles > etc... > 2) We want to create a daily export of small (but the most important) > configuration tables, which can be imported very quickly after the crash and > rebuild of DB. > At this point the DB is operational. > 3) We can now import the large data tables - partition by partition. > And I don't care if THIS step will take 2 weeks. > What do you say? > Any reviews of my steps and the idea in general? > And, do you have a script that can re-engineer a DB (as in my step 1)? > Thanks a lot in advance. > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Andrey Bronfin > 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.com -- Author: Yechiel Adar 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).