Re: RMAN catalog question
Date: Fri, 20 Jul 2012 06:24:12 -0700
Message-ID: <CAENwkM517A2Ngs5_89NF_Sp_SicGNrjy_mY_P6xSgS6g-XBpiw_at_mail.gmail.com>
Hello David,
Great examples. At one company, I had set up 2 RMAN catalogs. Connect to 1 for backup and when completed, connect to the 2 and resync catalog.
Test and patch/upgrade 1 RMAN catalog first, when everything okay, then repeat for 2 catalog.
Separate catalog for production and non-production.
-Michael.
mdinh.wordpress.com
On Fri, Jul 20, 2012 at 4:20 AM, David Robillard <david.robillard_at_gmail.com>wrote:
> Hello Michael,
>
> > RMAN Compatibility Matrix [ID 73431.1] provides a little more details.
> > RMAN executeable <= target database (when backup 9i database, use 9i
> RMAN)
> > Catalog schema >= RMAN executeable
> > Catalog database >.2.0.3 (note 1)
> >
> > Based on the information, I would create the RMAN database and catalog
> using the latest and greatest release to ensure compatibilty.
>
> I agree.
>
> As a concrete example, I recently consolidated several database
> backups into a single RMAN catalog. The RMAN catalog was installed on
> a dedicated machine running 11.2. This machine was only used for RMAN.
> The target databases were a mix of 9.2, 10.2 and 11.2 RAC on various
> operating systems (RedHat 3, 4 and 5, Solaris 8, 9 and 10 plus Windows
> Server 2003 R2). Yes, RedHat 3 and Solaris 8 were still in production
> (!)
>
> To backup of the 11.2 RAC clusters, I used a cron job on the RMAN 11.2
> machine that would run a shell script which connected to a service
> name (and not an SID) on the RAC clusters. This script used the 11.2
> rman binary from the RMAN 11.2 machine to connect to the 11.2 RAC
> instances. I then used global RMAN stored scripts « execute script
> 'script_name' using 'db_unique_name' » to backup the clusters.
>
> To backup the 9.2 databases, I used a cron job on the 9.2 machines
> that called the local 9.2 rman executable. The 9.2 rman executable
> would then connect to the 11.2 RMAN catalog and use a different stored
> script from the one used with 11.2. The reason for that is that in 9.2
> the concept of global scripts doesn't exist yet. So you have to create
> a stored script for each and everyone one of your 9.2 databases that
> are going to use your 11.2 RMAN catalog.
>
> Finally, to backup the 10.2 databases, I again used a cron job (or
> scheduled task in Windows) that executed a shell script (or a batch
> file) which used the local 10.2 rman executable to connect to the 11.2
> RMAN catalog. This script then executed a global script stored in the
> catalog. In 10.2, we now have access to global scripts. Of course, you
> need a script for UNIX/Linux machines and a different one for the
> Windows target because the paths aren't the same.
>
> To backup the RMAN 11.2 catalog (let's not forget to do this :) I used
> yet another cron job that used the local RMAN 11.2 binary and
> connected to the catalog using « nocatalog ».
>
> Backup data for all of these databases (including the RMAN catalog
> backup data) was sent to a central NFS directory (or a Samba share
> from that same NFS server) which was subsequently sent to tape. Those
> tapes were then encrypted and sent offsite.
>
> As you can see, backup of the 11.2 targets is the other way around
> then from the 9.2 and 10.2 targets. I mean, in 11.2, I used the RMAN
> server's binary to connect to the targets. While for the 9.2 and 10.2,
> I used the target's binary to connect to the catalog. The reason is
> simple : when I used the RMAN machine's 11.2 rman executable to
> connect to a 9.2 or 10.2 database, you get an error.
>
> If you'd like to see the cron scripts and the RMAN stored scripts, let me
> know.
>
> HTH,
>
> David
> --
> David Robillard
> http://www.linkedin.com/in/davidrobillard
> http://itdavid.blogspot.ca/
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Jul 20 2012 - 08:24:12 CDT