Re: Why I don't like RMAN repositories

From: Norman Dunbar <oracle_at_dunbar-it.co.uk>
Date: Tue, 10 Dec 2013 21:42:06 +0000
Message-ID: <e093cb65-d6ee-4c72-8f6a-5bd1c19b6d96_at_email.android.com>



Hey Rich,

Just wondering. Given that you have "all" that work to do recatalogging when you have to do a restore and recovery, that's what you would be doing if your catalog was a SPOF and was lost, surely?

I know you'd have some details in the control file, and could recatalog the remainder, but i would tend to disagree that the catalog is actually a SPOF.

Your mileage, as they say, may vary.

I hadn't used a catalog until recently, but I can see how useful one can be, in addition to whatever is stored away in the control files. But I obviously cannot speak for everyone.

Cheers,
Norm.

Rich Jesse <rjoralist3_at_society.servebeer.com> wrote:
>Chris writes:
>
>> Out of curiosity, with nightly FULL rman backups of a production
>database,
>> why would you recommend a value greater than 7 for keep time?
>
>I was just thinking the same thing. My RMAN backups are to the FRA on
>disk,
>which are then picked up by "tape" (Tivoli) nightly. For the new
>production
>box, Tivoli will be picking up the FRA additions (arch logs) a few
>times
>during the day as well.
>
>RMAN is configured with a recovery window of 1 day. Our Tivoli tapes
>get
>shipped offsite daily, leaving the disk cache for short-term recovery.
>
>"The Plan" has been to manually restore from Tivoli back to the FRA on
>disk,
>catalog the restored files, then restore/recover from RMAN. Perhaps a
>little more manual work, but it works well for us.
>
>I still haven't seen any compelling information to make me want to use
>a
>recovery catalog for our environment. It adds a point of failure and
>additional complexity without giving us any benefits that I can see
>from the
>arguments here. Of course, YMMV...
>
>Rich
>
>--
>http://www.freelists.org/webpage/oracle-l

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Dec 10 2013 - 22:42:06 CET

Original text of this message