Prev: Copying Backup of 32-bit Win2000 10g Database into a 64 Bit Win2003 Server
Next: 11gR2 Or 10gR2 on Linux x64?
From: NetComrade on 14 Apr 2010 13:27
Can someone point me to exact list of things we'd lose w/o running w/
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
From: Michel Cadot on 14 Apr 2010 13:35

"NetComrade" <netcomrade(a)gmail.com> a �crit dans le message de news:
d8cc03c9-2e5e-4b01-8a2d-6a44de31c92a(a)q15g2000yqj.googlegroups.com...
| Can someone point me to exact list of things we'd lose w/o running w/
| 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

The exact list is in the documentation.

Regards
Michel


From: NetComrade on 14 Apr 2010 16:12
On Apr 14, 1:35 pm, "Michel Cadot" <micadot{at}altern{dot}org> wrote:

> 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.
From: Noons on 14 Apr 2010 21:14
On Apr 15, 6:12 am, NetComrade <netcomr...(a)gmail.com> wrote:

>
> 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.
From: Bob Jones on 14 Apr 2010 21:46

"NetComrade" <netcomrade(a)gmail.com> wrote in message
news:892a9daf-0f48-4544-b44d-9199540c3ed8(a)r18g2000yqd.googlegroups.com...
On Apr 14, 1:35 pm, "Michel Cadot" <micadot{at}altern{dot}org> wrote:

> > 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.

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.


 |  Next  |  Last
Pages: 1 2
Prev: Copying Backup of 32-bit Win2000 10g Database into a 64 Bit Win2003 Server
Next: 11gR2 Or 10gR2 on Linux x64?