2

I want to centralize all my Oracle's DB backup shell scripts in one server, and all of them are in different servers, architectures and DB versions. For this purpose I'm going to use the same server where the Recovery Catalog is installed, a rhel6 64bit with 11.2.0.3 DB, and schedule the backup shell scripts via crontab.

This is easily done executing, from the Recovery Catalog server, something like RMAN TARGET SYS@RemoteDBNetIdentifier CATALOG catalogowner@rmanCatalog

Problem is that, according with the compatibility matrix, RMAN client version must match DB target connected version. http://docs.oracle.com/cd/E11882_01/backup.112/e10643/compat003.htm#i634479

$ rman target sys@db_prod_1 catalog rman@rcat

Recovery Manager : Release 11.2.0.3.0 - Production on Jue Ago 22 13:27:52 2013

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Contraseña de la base de datos destino:
el paquete PL/SQL SYS.DBMS_BACKUP_RESTORE versión 11.02.00.01 de la base de datos TARGET no es actual
el paquete PL/SQL SYS.DBMS_RCVMAN versión 11.02.00.01 de la base de datos TARGET no es actual
conectado a la base de datos destino: DB_PROD_1 (DBID=943768957)
Contraseña de la base de datos del catálogo de recuperación:
conectado a la base de datos del catálogo de recuperación

RMAN> exit

But I don't want to install every single Oracle DB version in the recovery catalog server. So I tried to copy JUST the rman executable from the Oracle DB installations in the others servers to the Recovery Catalog server, but it didn't worked

$ scp oracle@SRV_PROD_1:/usr/oracle/product/11.2.0/bin/rman /usr/oracle/product/rman_bin/11.2.0.1/
rman                                    100%   14MB 209.6KB/s   01:06

$ cd product/rman_bin/11.2.0.1/
$ ./rman target sys@db_prod_1 catalog rman@rcat

Recovery Manager : Release 11.2.0.1.0 - Production on Jue Ago 22 13:51:27 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: fallo al inicializar el paquete del gestor de recuperación interno
RMAN-03000: fallo al inicializar el componente compilador del gestor de recuperación
RMAN-06035: versión incorrecta de recover.bsq; se esperaba 11.2.0.1 y se ha encontrado 11.2.0.3

It seems that I'd also need the recover.bsq file (which is in $ORACLE_HOME/ADMIN), but I want to be sure that I wont miss more files or face new problems when we'll have to perform a disaster recovery or something in the future.

What can I do?

How can I only install the different versions of RMAN client? There's another method to centralize all the backups work (I think that EM Cloud Control can achieve this, I didn't read about it, just figuring out, but we dont want to rely on a GUI web-based application to manage our backup strategy.)

Regards

5
  • Just wondering, why don't you use the rman on the target server?
    – Munchi
    Aug 22, 2013 at 13:15
  • Just an idea - use ssh to run rman on server you want to backup!? Then you won't have to follow version changes on Oracle servers and still have central place to manage backups. Aug 22, 2013 at 14:00
  • @MindaugasRiauba That could work, but then the parameters file passed to rman client (and also log file in log= parameter) will be created / has to exist in remote server. e.g. ssh oracle@SRV_PROD_1 "source ~/.bash_profile; rman" target / @parameterfile.par log="rman.log" In this case parameterfile.par must exist in SRV_PROD_1 and rman.log will be created also on SRV_PROD_1 . The goal is to keep both parameterfile.par and rman.log in the Recover Catalog server.
    – vegatripy
    Aug 22, 2013 at 15:43
  • NFS mount a single parfile location to each server. To be honest, just install Grid Control and use that - it's much easier!
    – Philᵀᴹ
    Aug 22, 2013 at 23:44
  • @vegatripy NFS already suggested and also you can scp files around. With rman copying you can run into OS compatibility problems. For example Oracle 12 binaries for RHEL7 may not run on your RHEL6 in a couple years. Aug 23, 2013 at 4:45

1 Answer 1

2

Forget copying binaries around. I would integrate remote RMAN executions into your normal backup application/solution (i.e. filesystem backup to fire a script) for the sake of consistency. Especially scheduling of backups would be easier.

Re: "In this case parameterfile.par must exist in SRV_PROD_1". Not a problem if you dig into RMAN's own CREATE SCRIPT syntax - you can store the run{ } script inside your catalog.

Re: "rman.log will be created also on SRV_PROD_1". Not a problem if you take a look at catalog schema contests - surely there is one large table per each catalog that holds the logs anyway (I can't remember if it's ROUT or RMAN_OUT?).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.