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:[EMAIL PROTECTED]]
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]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:[EMAIL PROTECTED]]
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" <[EMAIL PROTECTED]>
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: [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).
