RE: Backup Strategy

Thanks for all the answers,
I'll have to find out what applies to our company, but you gave me a good
start.
Thomas, I haven't got a chance to read the doc. but I will, thanks a lot for
sharing it!
Guy, George, thanks a lot for your input, I'll have all that in mind.
Have a nice day!

I hope the replies you received were helpful - Guy and George gave great
replies - more and better reasons than I stated for determining what type of
backup plan you need to develop.

You didn't ask, but I would suggest the following for your current database:

Daily exports seem a bit much to me. Exports have limited use in any type
of recovery plan. They are good for restoring static tables - like code and
"lookup" type tables. They are not so good for relational tables, as they
may export data "in between" transactions so that restoring may not be
successfull because of relational constraints (like you export a parent
table, an insert occurs to the parent and child table, and then you export
the child table. Restoring the child table from the export will fail
because the parent record does not exist for the child record).

Weekly cold backups are a good plan.

I would add hot backups into the mix someplace - depending on how long a
backup takes to run. Something like Hot backups on Tues & Thurs , Archive
log backups every day of the week, with your Cold backup on Sat. This gives
you several chances during the week to perform a quick restore if needed.

The issue is how long can you *really* *afford* to be without the
database? The basis of any business analysis is cash. If your
organization would lose millions of dollars for every hour the database
is down, then it's probably worth spending a significant amount of money
on a failover (HA) or clustered (OPS) system, as Tom says. On the other
hand if they could manage without the database for 24 hours, then you
don't need to spend nearly as much money on recovery capability. What is
the probability of the database going down, due to failure of the
hardware? Of the software? Of user error?

If you did choose to recover from a hotbackup, you would need to apply a
full week of archived redo log in your present scenario. Try it on a
test system and see how long it takes. If it is within your recovery
time, then it's OK, if not then you will need to take the hotbackup more
frequently - this might mean buying a faster tape drive, or more hard
disks to use as a buffer. How long to restore Oracle itself onto fresh
hardware, so datafiles can be recovered? Similarly, how long does take
to do a full import into an otherwise empty database? How long would it
take to create an empty database on fresh hardware if you wanted to
import? If it's too long, then standby databases become necessary.

As you can see, there are many factors to consider, and there is no "one
true backup plan" that can be applied to all installations. You need to
understand recovery scenarios before planning backing up. But there is a
general approach that can be applied, which is:

Before you can decide on what your backup strategy will be, you really
need
to talk to the users of your database.

One of the most important pieces of information to get from your users
is
the "Mean Time to Recovery". Simply put, you ask the user how long they
can
afford to be without a database.

If they tell you "no more than 10 minutes", then you had better devise
and
implement an automatic fail-over (either hot-standby, or if you can
share
the disks, automatic fail-over).

If they tell you "no longer than 1 hour", then you had better make sure
that
your backup and recovery plan can restore the data files and recover the
database within the time frame.

There are probably a dozen different scenarious that you need to
consider.
Each one will lead to to different types of recovery scenarious. Each
one
will have a different cost (both in dollars and your time).

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).
--

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).
--

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).
--

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 Thu Oct 04 2001 - 10:09:10 CDT