Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: RMAN - To Catalog or not to catalog, that is the question

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

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Wed, 9 Jun 2004 13:13:34 -0400
Message-ID: <KNEIIDHFLNJDHOOCFCDKMENKENAA.mwf@rsiz.com>


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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of DENNIS WILLIAMS Sent: Wednesday, June 09, 2004 10:59 AM
To: 'oracle-l_at_freelists.org'
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_at_lifetouch.com

-----Original Message-----

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of QuijadaReina, Julio C Sent: Wednesday, June 09, 2004 9:51 AM
To: oracle-l_at_freelists.org
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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of DENNIS WILLIAMS Sent: Wednesday, June 09, 2004 10:36 AM
To: 'oracle-l_at_freelists.org'
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_at_lifetouch.com

-----Original Message-----

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of QuijadaReina, Julio C Sent: Wednesday, June 09, 2004 9:34 AM
To: oracle-l_at_freelists.org
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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of DENNIS WILLIAMS Sent: Wednesday, June 09, 2004 9:46 AM
To: 'oracle-l_at_freelists.org'
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:

-----Original Message-----

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Smith, Ron L.
Sent: Wednesday, June 09, 2004 8:29 AM
To: oracle-l_at_freelists.org
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_at_freelists.org put 'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://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_at_freelists.org put
'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://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_at_freelists.org
put 'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
Received on Wed Jun 09 2004 - 12:16:37 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US