>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
How about doing the inserts in a seperate database and synch using
replication or home cooked scripts into your warehouse.
-Original Message-
Sent: zondag 24 november 2002 18:24
To: Multiple recipients of list ORACLE-L
Dear gurus!
We are evaluating a "strange" way to "recover" a producti
Andrey,
I am not sure I understand "We can now import the large data tables -
partition by partition..And I don't care if THIS step will take 2 weeks.".
Didn't you mention that you couldn't afford 48 hours of recovery?
Import is extremely slow, and I would not recommend exp/imp for backup
recover
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
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 o
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 bac
