RE: rman oddities

From: Koivu, Lisa <lisa.koivu_at_efairfield.com>
Date: Tue, 04 Dec 2001 06:50:30 -0800
Message-ID: <F001.003D490C.20011204062520@fatcity.com>

Yes I am aware of the importance of keeping previous incarnation backups. When I said orphan below I meant an rman datafile that was left out there from a backup that never completed, and therefore didn't register in the catalog. These incomplete rman datafiles are completely useless and need to be chased down and deleted manually. -----Original Message-----

From:   Ron  Yount [SMTP:ronwy_at_swbell.net]
Sent:   Monday, December 03, 2001 8:45 PM
To:     Multiple recipients of list ORACLE-L

Subject: RE: rman oddities

Hi,

I have seen some responses and discussions about 'orphaned' backups regarding RMAN after a recovery has been done. I would like to attempt to clarify why "old" backups being registered in the catalog are important, and very useful in a given situation for purposes of clarity.

Let say that:

1) January 1st, you start using RMAN to backup your database. 2) On February 1st, your favorite application team asks you to restore the database to 12:00 on January 28th due to some logical corruption of data that was caused by the application code (or careless user :-) .

3) You succeed in restoring to noon on 1/28. (Happy with the ease of using performing this with RMAN, but of course you inform the application owners that they owe you one.

4) They thank you, offer their first-born (if you feel so inclined) and return to their daily routine..... only to discover that the corruption did not start after 12:00 am on the 28th, it actually occurred during a batch load at 3:00 am on the 28th.

a) In RMAN terms, your backups up until Feb 1st comprise a set known as "incarnation" # 1. b) When you performed the restore, and obligatory "reset database" in rman after opening with "reset logs" you started a brand new incarnation... # 2.

c) Now you have a dilemma because the database (and RMAN believe that the current database was "born" at 12:00 noon on 1/28 and therefore will not know what to do with the inevitable request to restore it to 2:20 am on 1/28.... unless! you understand incarnations.

d) Since you understand incarnations, you have the option of telling rman to switch back to incarnation # 1. This allows you tell rman to restore to a new point in time anywhere between the 1st of January and the 1st of February.

So... all backups have a valid place in the never-ending reality that users expect a request to "just put it back to something else... that it once was..." to be simple and logical...

As an RMAN user, you will not let them down, nor find yourself talking to the overhead lights in a tongue that nobody can understand. :-)

HTH,
-Ron-

-----Original Message-----
From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of Koivu, Lisa Sent: Monday, December 03, 2001 1:27 PM
To: Multiple recipients of list ORACLE-L Subject: rman oddities

Hi Ruth, thanks so much for responding.

Yes, I wrote the scripts to do an arclog backup delete. I'm concerned about the arclogs hanging around after a restore and taking up disk space, along with unnecessarily inflating the size of my backup files. (I'm testing backup to disk right now)

It's more of a nice to know, not necessary. I'm seeing some weird stuff that I didn't expect and the monkey in me wants to know why... No, not the baby :) Here's some other odd behavior I've seen:

1. Instance failure during a backup leaves the rman files intact but the backup itself is not reflected in the catalog. The database recovers nicely from this since no tablespaces are in hotbackup mode (yesssssssss) The end result is "orphan" rman files that the catalog knows nothing about.

2. Initially these files are created the size of all datafiles combined. As the backup progresses, the size of the files shrink down considerably. For example, I allocate 3 channels to disk and setsize to 2GB, but the files start out at 1.5GB and shrink down to ~500 MB. I wonder if that behavior happens on tape? Anyone? I'll be able to test this later this week.

3. Can restore and recovery really be this easy? Sheesh

Thanks again for your response. And list, please correct me if I am wrong on any of this.

yours in Monkeying Around,
Lisa

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

From:   Ruth Gramolini [SMTP:rgramolini_at_tax.state.vt.us]
Sent:   Monday, December 03, 2001 1:17 PM
To:     Multiple recipients of list ORACLE-L

Subject: Re: rman restore & arclogs

Lisa,

We backup all archivlogs with the backup set and delete them. Delete is an rman option when you backup archivelogs. We don't have room to keep them. It is a bit of a pain to restore them but you learn to live with it.

Have a look at rman's tables and views. You should be able to query them and get what you want.

Yours in rman,
Ruth
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Monday, December 03, 2001 10:30 AM

> Good morning all -
>
> I've been practicing rman restores. It's a lot easier than I originally
> thought. I've noticed that when you restore and the arclogs are needed,
it
> restores them. Which is expected. However, when I take another backup,
> these arclogs are included in the backup set. This is unnecessary in my
> opinion and makes my backup files larger than they need to be.
>
> Is it standard practice to just delete the arclogs that were already in a
> backup set prior to taking the immediate backup after a recovery? I can
> verify what arclogs are where in the backup sets with a report.
>
> Any comments are appreciated. Thanks
>
> Lisa Koivu
> Oracle Database Monkey
> Fairfield Resorts, Inc.
> 954-935-4117
>
>

--
Please see the official ORACLE-L FAQ: <http://www.orafaq.com>
--
Author: Ruth Gramolini
  INET: rgramolini_at_tax.state.vt.us 


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: 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 Tue Dec 04 2001 - 08:50:30 CST