Re: RMAN catalog question

From: David Robillard <>
Date: Fri, 20 Jul 2012 15:15:18 -0400
Message-ID: <>

Hello Bheem,

> We exactly do the same at our company what you said in your email.
> We have almost similar type of heterogeneous environment with a mix of various OS versions and DB versions.
> The only difference is even to backup 11.2 database we connect to RMAN using the target's binary (11.2) and not RMAN binary.

Yes, this works too. I didn't go that route because in a RAC environment, which node will run the cron job? Say node four is the one running your cron job and it happens to be down, then you won't have a backup for that particular moment. I thought about using DBMS_SCHEDULER to execute the backup job and storing the scripts on a shared NFS directory. But since I had all my scripts ready and it worked on the dedicated RMAN machine, I didn't do it. Or your organisation could use OEM to schedule backups, but I never got around to do that.

> I am interested in your script that you use to back up the RMAN database itself and the catalog. I appreciate if you can share that.

Sure, you can find the RMAN commands used to backup the RMAN catalog at this URL (make sure you edit the script to udpate the paths)

This file is used by calling the rman binary like this :


rman target / nocatalog log ${LOGFILE} append _at_${CATALOG} using ${DB_NAME} 2>&1 >${LOGFILE} And the above RMAN command is launched by cron that executes the script which uses the rman.conf file as it's configuration. Both the and rman.conf files are found at those URLs :

The file can be used with 10.2 and 11.2 databases. For 9.2 databases, I used and rman9i.conf files.

And please bear in mind that I've started working on those scripts in 2005. If it works for you, great! If you can enhance it, even better! :)

Finally, the RMAN 11.2 stored scripts are created with the daily.rman and production.rman files. Connect to RMAN and issue either...

RMAN> create global script 'daily' comment 'Daily NON-production RDBMS backup commands' from file '/path/to/daily.rman';


RMAN> create global script 'production' comment 'Daily PRODUCTION RDBMS backup commands' from file '/path/to/production.rman';

I used the « daily » keyword for non-production databases and the « production » keyword for the production databases. Probably a bit confusing, but it works.

> That's a great reply.

Thanks :)


David Robillard

> -----Original Message-----
> From: [] On Behalf Of David Robillard
> Sent: Friday, July 20, 2012 4:20 AM
> To: Michael Schmitt; Michael Dinh
> Cc: oracle-l mailing list
> Subject: Re: RMAN catalog question
> 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 >=
>> (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
Received on Fri Jul 20 2012 - 14:15:18 CDT

Original text of this message