Oracle RMAN Catalog vs. controlfile advantages
NetComrade
catalog?
After upgrade to 10.2.0.5 on Grid Control we have random job failures
w/o any clear cause, and prior to that we already had a number of
databases which had performance issues (resyncing with catalog
forever). Yes, we do have a number of patches to apply, but we are
rather tired of these issues, one of which is dealing with
increasingly useless Oracle support.
The number one issue is managing all backups centrally, but we have
this covered, since all jobs run from Grid anyway, and we parse RMAN
outputs for errors.
What functionality we'd be losing? I've googled, and some places say
some things like "some advanced commands are only available with
catalog", but they don't specify which.
Thanks
Michel Cadot
"NetComrade" <netco...@gmail.com> a �crit dans le message de news:
d8cc03c9-2e5e-4b01...@q15g2000yqj.googlegroups.com...
The exact list is in the documentation.
Regards
Michel
NetComrade
> The exact list is in the documentation.
>
if these are the 'benefits' then there is really only one=potentially
longer history.
You can also create a recovery catalog, an external Oracle database in
which to store this information. The control file has finite space for
records of backup activities, while a recovery catalog can store a
much longer history. The added complexity of operating a recovery
catalog database can be offset by the convenience of having the
extended backup history available if you have to do a recovery that
goes further back in time than the history in the control file.
There are also a few features of RMAN that only function when you use
a recovery catalog. For example, RMAN stored scripts are stored in the
recovery catalog, so commands related to them require the use of a
recovery catalog. Other RMAN commands are specifically related to
managing the recovery catalog and so are not available (and not
needed) if RMAN is not connected to a recovery catalog.
Noons
>
> if these are the 'benefits' then there is really only one=potentially
> longer history.
>
> You can also create a recovery catalog, an external Oracle database in
> which to store this information. The control file has finite space for
> records of backup activities, while a recovery catalog can store a
> much longer history. The added complexity of operating a recovery
> catalog database can be offset by the convenience of having the
> extended backup history available if you have to do a recovery that
> goes further back in time than the history in the control file.
Allow me to paint a scenario where recovery catalog might come in
useful.
If you refresh development ofr test dbs from a production backup and
you use the "duplicate database" rman comamnd to do so, then you must
keep in the production control file sufficient information for the
duplicate commaqnd to know where in time to recover a prior backup
to. Otherwise, it errors off with the "file not restored from a
sufficiently old backup".
Keeping that information in a separate catalog allows you to get on
with production cleanups after rman backups, while keping the ability
to duplicate from an earlier backup.
We've recently been in this quandary: used to duplicate our prod
backup within the "redundancy" window. Now we ned to duplicate from
up to 7 days before. For the time being we've stopped using
duplicate, back to just a restore from an ad-hoc backup. Which is a
bit of a pain as things like db names and such don't get reset
automagically.
Investigating at the moment the creation of a catalog db so we can go
back to duplicating.
Bob Jones
"NetComrade" <netco...@gmail.com> wrote in message
news:892a9daf-0f48-4544...@r18g2000yqd.googlegroups.com...
You are not losing much. It is a matter of which set of issues you rather
deal with, having recovery catalog or not? Often time with Oracle, moving
from one thing to another doesn't solve all the problems; it merely replaces
old problems with new ones.
sandeep pande
Hi,
Pls use below link
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1276847400346367990
Hope this helps
Sandy
sandeep pande
Hi,
I'm not sure what Grid Control issues would have to do with your RMAN
catalog issues, but for your resync issues there are documented cases
of cause and solutions on My Oracle Support, including RMAN catalog
best practices. If you have issues with Oracle Support I'd advise you
to escalate your issue, or ask for another analyst to be assigned. You
may even contact your Support and Sales representative for assistance.
Feedback is critical for support so when you get the feedback surveys
I encourage you to complete them so the Support Manager can be made
aware.
Functionality which you would lose include:
1. Single point of view - The RMAN catalog is a single point of backup/
recovery data from which you can also run reports, and manage your
backup/recovery processes. For a standby setup this is very important.
2. Extended history - A control file only keeps backup records for a
maximum period of time (default is 7 days). You can extend this
(CONTROL_FILE_KEEP_TIME) which will grow the controlfile, but using an
RMAN catalog you can retain the same backup/recovery data as long as
you have storage, and no catalog performance issues.
3. Script storage - RMAN catalog provides you with a central
repository to store your RMAN scripts which can either be global (all
database share that script), or local to an individual database. No
more using of shell scripts except for a wrapper, the actual RMAN
script is stored within the RMAN catalog.
Regards
Sandy