| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: A way to restore a DB
Looks like your database is playing two roles. OLTP for heavily insertion
and keeping historical data as well for 90 days.
I would recommend separate the two functionalities. A small OLTP database
for insertion which only keeps a day or so worth of data. This way you
can recover it quickly. A large database for historical data. You can
transport
data between the two using varies methods depends on how soon you want it to
happen.
-----Original Message-----
Sent: Sunday, November 24, 2002 12:24 PM
To: Multiple recipients of list ORACLE-L
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: andreyb_at_elrontelesoft.com
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: ListGuru_at_fatcity.com (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).
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: ListGuru_at_fatcity.com (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). Received on Sun Nov 24 2002 - 17:28:38 CST
 |
 |