Re: Why I don't like RMAN repositories

From: Andrew Kerber <andrew.kerber_at_gmail.com>
Date: Tue, 10 Dec 2013 09:18:18 -0600
Message-ID: <CAJvnOJYy3Xg9OJ5d4ZdiRgxStLP-2QgGSZi0ojK2aQxCuTu0ww_at_mail.gmail.com>



A couple of points, afaik you do not need an rman repository for dataguard. I have set up and managed a lot of standby's without a repository. In fact, I dont recall that I have ever used a repository with a standby.

In my experience, a repository is most useful in a large (tens of instances) environments for producing backup reports. For a small environment, there are really no advantages to a repository that I have found.

On Tue, Dec 10, 2013 at 9:09 AM, Chris Taylor < christopherdtaylor1994_at_gmail.com> wrote:

> 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 had a hard time imagining a scenario where you'd have to go back 21 days
> for a production recovery - I'm wondering if I'm missing some technical
> aspect here...
>
> Thanks,
> Chris
>
>
>
> On Tue, Dec 10, 2013 at 9:03 AM, Tim Gorman <tim_at_evdbt.com> wrote:
>
>> Coming late to the discussion, not sure if anyone else has made this
>> point...
>>
>> Having an RMAN repository (a.k.a. recovery catalog, etc) is belt and
>> suspenders (or belt and braces for many). There is always a "recovery
>> catalog" in the target database's control files, so you've always got a
>> belt to prevent your trousers from falling. If you don't set
>> CONTROL_FILE_RECORD_KEEP_TIME to at least 21, then it's more cheap string
>> than a belt, but it's a belt.
>>
>> A recovery catalog is a replicated copy of the recovery catalog with more
>> history, thus suspenders/braces in addition to the belt.
>>
>> It is not technical merit, but rather personal/corporate choice, that
>> determines whether one wears one or both.
>>
>>

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Dec 10 2013 - 16:18:18 CET

Original text of this message