| 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: Backup Strategy
Veronica,
Here is yet one more reply for you, but I think you'll be glad to get it.
Tom Cox put together an excellent paper on BU and Reco requirements, and it can be found at:
http://www.geocities.com/tbcox23/
Look for 'Backup and Recovery Metrics and Rules of Thumb' on that page and download the file.
It contains logical level backup strategies, 3 different example Service Level Agreements based on customer need, and example scripts.
Great piece of work.
Jared
Veronica Levin
<vlevin_at_victor To: Multiple recipients of list ORACLE-L
<ORACLE-L_at_fatcity.com>
ia.com.ni> cc:
Sent by: Subject: RE: Backup Strategy
root_at_fatcity.c
om
10/04/01 09:10
AM
Please respond
to ORACLE-L
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!
Saludos,
Veronica Levin Enriquez
Compañía Cervecera de Nicaragua
-----Mensaje original-----
De: Mercadante, Thomas F [mailto:NDATFM_at_labor.state.ny.us]
Enviado el: Jueves, 04 de Octubre de 2001 06:09 a.m.
Para: 'ORACLE-L_at_fatcity.com'
CC: Veronica Levin
Asunto: RE: Backup Strategy
Veronica,
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.
Hope this helps.
Tom Mercadante
Oracle Certified Professional
-----Original Message-----
Sent: Thursday, October 04, 2001 5:06 AM
To: Multiple recipients of list ORACLE-L
Hi Veronica,
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:
(cost of database failure/hour * recovery time * probability of database failure * safety factor) = amount to spend on preparation for recovery.
HTH, g
-----Original Message-----
Sent: Wednesday, October 03, 2001 10:26 PM
To: Multiple recipients of list ORACLE-L
Users can't afford to be without the database to work, that is for sure.
I know that there are a lot of recovery scenarios, and plans for them...
But I was talking about backups... how many, what type of backups, etc.
So far I've been doing ok with daily exports and weekly full backups,
just
wanted to hear if there is anything else I should be doing,
Saludos,
Veronica Levin Enriquez
Compañía Cervecera de Nicaragua
-----Mensaje original-----
De: Mercadante, Thomas F [mailto:NDATFM_at_labor.state.ny.us]
Enviado el: Miércoles, 03 de Octubre de 2001 01:17 p.m.
Para: 'ORACLE-L_at_fatcity.com'
CC: Veronica Levin
Asunto: RE: Backup Strategy
Veronica,
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).
hope this helps.
Tom Mercadante
Oracle Certified Professional
-----Original Message-----
Sent: Wednesday, October 03, 2001 2:00 PM
To: Multiple recipients of list ORACLE-L
Hi listers,
I was wondering how do you decide your backup strategy.....
I do daily full exports and weekly full backups with database in
archivelog
mode.
Plus weekly Operating System Backup.
Is this all I can do to ensure fast recovery of the database or server
when
it is needed?
Any input on this topic will be appreciated!
Saludos,
Veronica Levin Enriquez
Compañía Cervecera de Nicaragua
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Veronica Levin
INET: vlevin_at_victoria.com.ni
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Liststo: 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 REMOVE yourself from this mailing list, send an E-Mail message
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Liststo: 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 REMOVE yourself from this mailing list, send an E-Mail message
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Liststo: 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 REMOVE yourself from this mailing list, send an E-Mail message
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Liststo: 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 REMOVE yourself from this mailing list, send an E-Mail message
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: Jared.Still_at_radisys.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Liststo: 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 - 13:28:54 CDT
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
 |
 |