Re: RMAN catalog

  • From: Guillermo Alan Bort <cicciuxdba@xxxxxxxxx>
  • To: Chris.Stephens@xxxxxxx
  • Date: Wed, 24 Mar 2010 15:27:03 -0300

Some time ago I designed a solution for a distributed RMAN catalog
infrastructure. It was a bit excessive, using RAC and Dataguard to remote
sites, plus the catalog replication mentioned in the first reply. So
basically, you had four active catalogs at any given time, all of them being
two-node RAC, and if the entire site got disconnected from the network, the
rest of the sites would fall on to the other rman catalogs. It was a very
solid solution, with built in reporting and independant of the backup
infrastructure (MML/Disk Backup).

However, for single sites, I've found that having an RMAN backup of the
catalog itself, plus a good backup of the controlfile is usually enough.
Someone in the list mentioned that RMAN when executing a cmdfile if it
cannot connect to the catalog will take the backup anyway, which gives you
time to restore the RMAN catalog to a new server without losing backups. You
will have to resync all databases afterwards, which may be a little
annoying. Perhaps a DataGuard would be a good solution for this.

hth
Alan.-


On Wed, Mar 24, 2010 at 2:39 PM, Stephens, Chris <Chris.Stephens@xxxxxxx>wrote:

> That's a very interesting proposition.
>
> I take advantage of the licensing exemption for a recovery catalog and grid
> control repository.
>
> Would it be legal to set up a non-licensed standby site for that database?
>  ...and to make use of features such as Active Dataguard?
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
> On Behalf Of Michael Dinh
> Sent: Wednesday, March 24, 2010 12:08 PM
> To: dbinsight@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
> Subject: RE: RMAN catalog
>
> Have multiple catalogs. Backup connecting to 1 catalog. At completion,
> connect to another catalog and resync.
>
> How about having DG for the catalog database?
>
>
> NOTICE OF CONFIDENTIALITY - This material is intended for the use of the
> individual or entity to which it is addressed, and may contain
> information that is privileged, confidential and exempt from disclosure
> under applicable laws.  BE FURTHER ADVISED THAT THIS EMAIL MAY CONTAIN
> PROTECTED HEALTH INFORMATION (PHI). BY ACCEPTING THIS MESSAGE, YOU
> ACKNOWLEDGE THE FOREGOING, AND AGREE AS FOLLOWS: YOU AGREE TO NOT
> DISCLOSE TO ANY THIRD PARTY ANY PHI CONTAINED HEREIN, EXCEPT AS
> EXPRESSLY PERMITTED AND ONLY TO THE EXTENT NECESSARY TO PERFORM YOUR
> OBLIGATIONS RELATING TO THE RECEIPT OF THIS MESSAGE.  If the reader of
> this email (and attachments) is not the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. Please notify the sender of the
> error and delete the e-mail you received. Thank you.
>
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Sam K
> Sent: Wednesday, March 24, 2010 9:57 AM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: RMAN catalog
>
> Hi All,
>
>         I am interested in knowing what the best practice is for
> backing up the RMAN catalog database.
> How often and the best backup method?
>
> What's the high availability solution if any, you have for the RMAN
> catalog DB
>
> We have around 400+ DB's backed up via RMAN
>
> --
> Regards
> Sam K
> --
> //www.freelists.org/webpage/oracle-l
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
> CONFIDENTIALITY NOTICE:
>        This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is privileged,
> confidential and exempt from disclosure under applicable law.  If the reader
> of this message is not the intended recipient or the employee or agent
> responsible for delivering this message to the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited.  If you have received this
> communication in error, please notify us immediately by email reply.
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>

Other related posts: