RE: RMAN - To Catalog or not to catalog, that is the question - oracle-l

RE: RMAN - To Catalog or not to catalog, that is the question

From: "Mark W. Farnham" <mwf@xxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Date: Wed, 9 Jun 2004 13:13:34 -0400
okay, I'll bite.

I think the distinction you're looking for in the technical underpinnings is
this:

Old hot backups -- Some OS utility reads database files while they are open.
The OS views the files as sectors on disk (raw, cooked, who cares,
irrelevant for this point) of, let's say 512 bytes. An Oracle block is,
let's say, 8192 bytes. So the OS tool accurately acquires a bunch of 512
byte chunks to any individual 512 byte chunk boundary and conveys that bunch
to the backup media nicely. But if you have the bad luck to collide with
dbwr such that some of the 512 byte components of an 8192 byte Oracle block
are written before the dbwr write and some others are in the next OS bunch,
your backup now contains an internally inconsistent Oracle database block,
often called a "fractured block." So then there appears the magical
ingenuity of Bill Bridge, et. al., and they say, okay, during a period a
tablespace is in backup, we'll log a whole copy of any block that is
modified the first time we see it written since the backup began. In this
way, we'll have something consistent to which to apply the logged datablock
deltas later in the update stream (if any). So you might have fractured
blocks in the database file backups, but the redo contains good starting
points. That's why if you fail during a backup you have to go to a previous
backup to roll forward from, but if your database just crashes the files on
disk marked in backup can be marked not in backup and everyone is happy
unless you actually crashed during a partially complete dbwr write of an
Oracle block.

RMAN - Reads real whole Oracle database blocks through Oracle's own
mechanisms, so it just doesn't care whether dbwr is at that point partially
done in dribbling the OS sector size components of the Oracle block on the
media.

Now Oracle Marketing folks were never happy with calling any of this stuff
"HOT," and I believe online backups are their term for all backups of a
database that has one or more open instances.

As for RMAN being worthwhile, if you've got an ability to only back up what
has changed (your licensed capabilities may vary), that can be a huge
benefit, as is reduced think time on recovery should everything go right
with an RMAN recovery. I'm just not willing to give up my suspenders quite
yet, and I still find remote physical standby recovery (and reporting clone
databases) to be useful.

So I would recommend figuring out how to do "hot" backups and keeping that
arrow in your quiver.

mwf

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of DENNIS WILLIAMS
Sent: Wednesday, June 09, 2004 10:59 AM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: RMAN - To Catalog or not to catalog, that is the question


Julio
   Thanks for the explanation. When I said "hot backups", I was referring to
the older , non-RMAN method of backing up Oracle while the database was
open. I tried that years ago. If this list was available then, I have no
doubt that I could have received some excellent advice that would have
helped me overcome my difficulties. But that is water under the bridge.
   To avoid confusion, I think Oracle has tried to suggest the term on-line
backup for RMAN backups while the database is open. That is the only type of
RMAN backup I have performed because I figured that was the only thing that
made RMAN worthwhile. And I appreciate the help that people on this list
provided in helping me understand the sometimes obscure RMAN documentation.
While I'm on topic of documentation, if you are going to tackle RMAN,
purchase Robert Freeman's great book Oracle9i RMAN Backup & Recovery.

Dennis Williams
DBA
Lifetouch, Inc.
dwilliams@xxxxxxxxxxxxx

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of QuijadaReina, Julio C
Sent: Wednesday, June 09, 2004 9:51 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: RMAN - To Catalog or not to catalog, that is the question


Dennis,

Thanks. Sorry, I should have elaborated a little bit more...In your post
you said:
>I never got hot backup working, so I can't respond to that issue.

And so, I just wanted to point out that in the process I use my prod db
is never shut down and that it is not too hard to get hot backups to
work with RMAN on 9.2.0 if you ever would like to try it ;-)

Regards,
Julio

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of DENNIS WILLIAMS
Sent: Wednesday, June 09, 2004 10:36 AM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: RMAN - To Catalog or not to catalog, that is the question

Julio
   Congratulations. Is there a point here somewhere?

Dennis Williams
DBA
Lifetouch, Inc.
dwilliams@xxxxxxxxxxxxx

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of QuijadaReina, Julio C
Sent: Wednesday, June 09, 2004 9:34 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: RMAN - To Catalog or not to catalog, that is the question


Dennis,

I have three databases on 9.2.0 (prod, train, and recovery catalog) and
use OS schedule jobs to run a couple of scripts, which do the following:

1. Connect to the target(my prod db) and recovery catalog. I use the
'cmdfile' switch to point to a text file with the backup commands for
RMAN to run. I also use the 'mslog' switch to create a log file that I
can go check after the backup.
2. In the text file I have RMAN commands to resync catalog and backup
prod db plus archivelog. This backs up a)datafiles, b)SPFILE, and c)
Control files 3. Backup recovery catalog

Once a week, I copy prod into train using the 'dup' command. And just
for giggles...I connect to train Monday morning to check I got a fresh
copy of prod and it has been faithful since.

At no point in this process a shut down my prod db.

Kind regards,
Julio


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of DENNIS WILLIAMS
Sent: Wednesday, June 09, 2004 9:46 AM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: RMAN - To Catalog or not to catalog, that is the question

Ron
    Joe and Fuad make some excellent points, so I won't repeat those.
    I never got hot backup working, so I can't respond to that issue.
Perhaps someone else on the list can. My gut reaction is that if you
have something that works, has been tested, and you trust, then stick
with that.

As far as RMAN catalog or not, I would make the following points:
   - Nocatalog (controlfile mode) was enhanced considerably in 9i.
   - Catalog can give you a central view of all backups across your
system.
For example, on 9i I went nocatalog and have a script that sends me the
success/failure. But if somehow the cron job stops working, I might not
notice that I didn't receive an email.
   - Catalog mode can make upgrades frustrating. In general the catalog
database must be kept at a level ahead of the target databases.
   - Even in catalog mode, the backup information is still stored in the
controlfile, so you can still perform a distaster recovery without using
the catalog. That is my standard procedure.


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On
Behalf Of Smith, Ron L.
Sent: Wednesday, June 09, 2004 8:29 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RMAN - To Catalog or not to catalog, that is the question


We are getting ready to start using RMAN on several new 9i Linux
databases.
I guess the first question would be is RMAN really that much better then
using home grown dynamic hot backup scripts?  We have developed these
for our Oracle/NT environment and they seem to work fine.
The second question would be should we use a recovery catalog?  The
catalog seems to add a lot of complexity to the setup and to a disaster
recovery plan.

Thanks!
Ron

Important Notice!
If you are not the intended recipient of this e-mail message, any use,
distribution or copying of the message is prohibited.
Please let me know immediately by return e-mail if you have received
this message by mistake, then delete the e-mail message.
Thank you.

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
References:
- RE: RMAN - To Catalog or not to catalog, that is the question
  - From: DENNIS WILLIAMS
RE: RMAN - To Catalog or not to catalog, that is the question

Other related posts:
