You mentioned "disk management" issues... A problem with disk is that you
are probably limited to only doing level 0 backups. If your recovery spans
multiple RMAN backups then it could be a real bear trying get everything
you need to recover if you're staging from disk to tape. You'd have to be
very careful about keep track of your tapes.
-----Original Message-----
Sent: Monday, June 03, 2002 11:43 AM
To: Multiple recipients of list ORACLE-L
Dennis ;
You are absolutely right - the DISK option has a big down side that I did
not catch :
In a disaster (computer room fire) the daily archive logs would be lost
leaving you without the ability to roll forward your database - and thus the
loss of data. Therefore if you were to go with the DISK option - you would
need to manually implement an remote disk or tape backup procedure for your
daily archive logs (not an easy task) - that is if your clients could not
live with the loss of any data.
The RMAN tape management option (as long as they are promptly stored in a
fire resistant safe) definitely has its advantages.
Good point !
========
As a side note on disaster recovery ; We perform a 'disaster recovery' test
here every 6 months.
This is a great sanity check - as it tests out our procedures and ability to
recover from a disaster.
In our last test we simulated a loss of a production server (computer room
lost due to fire) - and together with the SA's we rebuilt the box from the
ground up using the backups that we had in the fireproof safe. This
exercise also made it very clear to our clients that given our current
backup configuration - they would loose at most one days worth of
transactions (the archive logs).
It also confirmed the 'assumptions' that both the DBAs and SAs were making
about 'who was backing up and responsible for what'.
I highly recommend going thru this procedure at least once a year.
========
Your comment about implemented RMAN on disk first before implementing RMAN
with a MML - We took the following approach ;
If you plan on routing your backups directly to tape - take one step back
and begin by configuring RMAN to backup to disk first. Thus you will
eliminate the (major) problems associated with configuring the tape
interface. Once you have RMAN up and running on disk then implement the
tape interface. ie; Don't bite off to much at a time.
Thanks and good luck in your RMAN rollout!
_________________________
Patrick J. Howe
Oracle DBA
Illuminet. A Verisign Company.
4501 Intelco Loop SE
Olympia, WA 98507
Email : [EMAIL PROTECTED]
-----Original Message-----
Sent: Monday, June 03, 2002 8:48 AM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Pat
Excellent summary. I have only a few points to add. I must point out
that I am an RMAN novice, just getting brief spurts of time between other
people's priorities.
- If you use RMAN to back up to disk, I haven't figured an advantage to
backing archive logs up with RMAN. If anyone knows an advantage, I would
appreciate hearing it. Obviously if you are using RMAN to write to the MML,
it makes excellent sense to back up the archive logs, but writing to disk,
you just create an extra copy of your archive logs on disk, which eventually
gets copied to tape. RMAN will apply the archive logs, whether you've given
it charge of them or not. Since you are probably doing RMAN incremental
backups each day, you probably only need today's archive logs anyway.
- I appreciate your points on disaster recovery. This topic rarely seems
to come up with RMAN. We are into what might be termed "poor man's disaster
recovery". This isn't where you have a duplicate computer room in another
city (how do I apply to be the DBA at one of those facilities), but where
you take backup tapes offsite and your hardware vendor promises to find you
a replacement server somewhere to load your tapes into.
- The disaster recovery scenario our systems manager insists on is "your
server just burned to the floor, go get your backup tape from the offsite
vendor and go to a another location and get your system going." The key is
making sure that everything you need gets on that tape. I agree with you,
that when you rely on an MML, that is one more layer of uncertainty. How can
you make sure there isn't some key disk file the MML relies on, unless you
test the scenario.
- Someone on this list gave me the advice that it is easier to learn RMAN
by backing up to disk.
- A lot will depend on your site. I would expect that the larger the site,
the more benefit would be derived from and MML. And the more chance to get
payback from the training and learning.
- More disk space - when my system administrator realized by backing up to
disk he wouldn't need to learn how to interface Veritas to Oracle, he was
most enthusiastic about finding more disk space.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-----Original Message-----
Sent: Friday, May 31, 2002 4:05 PM
To: Multiple recipients of list ORACLE-L
I am currently wrestling with whether to implement 'rman disk backups' or
'rman tape backups'.
I have put together the following PRO's and CON's list so that I can weigh
my options.
I am putting this out to those on the list that are working with RMAN and
care to add to the points i have made.
It is open for discussion - I look forward to reading your responses.
PS : Either CC me on all question responses or I will get back to you on
Monday - I am currently in Oracle-L digest mode.
Thanks
TAPE
With this option rman directs the rman backup directly to tape.
PROs
- Disk Maintenance issues are not applicable ;
You do not have to be concerned about whether you have enough disk space for
your backups.
You do not have to setup, maintain and monitor daily cleanup jobs.
- Rman will be able to automate the recovery process for you ;
Rman knows where the backups reside (tape) and will recover them to disk -
as needed by the recovery process.
- Setting up a hourly remote copies of any new archive logs is easy - just
setup a tape archive copy.
CONs
- Recovery is slower (disk verse tape).
- When duplicating your database to a different server or in a true
disaster, where you have lost a server and you need to rebuild the instance
on a new server - You will have the added task (and time) of installing and
configuring the Media Management Layer (ie; Legato). Since your backups
reside on tape, the Media Management layer on the Oracle Server needs to be
installed and configured before you can talk with the backup server.
- You have to concern yourself about tape resource issues ;
A 'CROSSCHECK' or 'VERIFY' of your backup may keep the tape subsystem busy
loading, unloading and positioning tapes. If your tape subsystem is used
for other purposes other then your backup - then you could run into
resourcing issues around when and if you should be running these jobs.
- Also the submitting and scheduling of these tape backup jobs will probably
move out of the dba's control (cron) and into the tape management scheduling
group's control.
- With this option you must be use rman "Backups". Rman "Image copies" can
not be directed to tape.
DISK
With this option rman directs the rman backup directly to disk.
All of the Disk Pro's and Con's that I came up with were just the mirror
image of the Tape Con's and Pro's.
The catch with this option is you probably do not have enough disk space to
store all of your backups on disk, therefore you will need to put into place
a procedure that backs up your rman backup files to tape and then deletes
them from disk. Note that rman will still think that all of these backups
still reside on disk therefore it will become the dba's job to manage the
"backup-to-disk", "delete-from-disk" and the "recovery-from-tape" of these
rman backup datasets.
PROs
- Recovery is faster (disk verse tape) as long as the backup you want
resides on disk.
- When duplicating your database to a different server or in a true
disaster, where you have lost a server and you need to rebuild the instance
on a new server - You will not have the added task (and time) of installing
and configuring the Media Management Layer (ie; Legato Client). You would
use standard tape recovery procedures to recover your backups from tape -
then issue the rman recovery commands.
- You do not have to concern yourself about tape resource issues ;
You can schedule a 'CROSSCHECK' or 'VERIFY' of your backup without worrying
about impacting other outside resources.
- The dba is in total control of the tape backup scheduling.
- With this option you can use rman "Backups" or "Image copies".
CONs
- Disk Maintenance issues are applicable ;
You have to be concerned about whether you have enough disk space for your
backups.
You have to setup, maintain and monitor daily cleanup jobs.
- If the backup you want is not on disk Rman will not be able to automate
the recovery process for you ; Rman thinks that all the backups reside on
disk - he does not know that you have backed them up to tape and removed
them from the backup directory. Therefore it becomes the dba's job to
manage theses tasks.
- Setting up a manual hourly remote copy of any new archive logs is more
complex. This will give the dba more tape backups that he will have to
manage and keep track of.
_________________________
Patrick J. Howe
Oracle DBA
Illuminet. A Verisign Company.
4501 Intelco Loop SE
Olympia, WA 98507
Email : [EMAIL PROTECTED]
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Pat & Brenda Howe
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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: Orr, Steve
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).
