RE: rman oddities

From: Ron Yount <ronwy_at_swbell.net>
Date: Mon, 03 Dec 2001 18:24:16 -0800
Message-ID: <F001.003D40D1.20011203174521@fatcity.com>

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-

<BLOCKQUOTE

style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid"> -----Original Message-----From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of Koivu, LisaSent: Monday, December 03, 2001 1:27 PMTo: Multiple recipients of list ORACLE-LSubject: 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 <FONT face=Arial

    size=1>To:     <FONT face=Arial 
    size=1>Multiple recipients of list ORACLE-L <FONT face=Arial 
    size=1>Subject:        <FONT 
    face=Arial size=1>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: <A target=_blank href="http://www.orafaq.com">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 Mon Dec 03 2001 - 20:24:16 CST