Kevin Kempf's Blog

March 28, 2011

Makes me wonder if I want the upgrade..

Filed under: 11g, Oracle, RMAN — kkempf @ 8:09 am

RMAN Repository Upgrade 101

I know, I’m the last DBA on the planet who still uses and RMAN repository.  Perhaps it’s somewhat of a throwback, but there are situations where having one will save time recovering a database, and since I have to keep a database running for Enterprise Manager anyways, I just stick it there with that database.  No extra maintenance, just extra insurance.  Regardless, I upgraded my EM database to 11.2.0.2 and began receiving complaints when connecting to the catalog from an 11.2.0.2 database:
connected to recovery catalog database
PL/SQL package RCAT_USER.DBMS_RCVCAT version 11.02.00.01 in RCVCAT database is not current
PL/SQL package RCAT_USER.DBMS_RCVMAN version 11.02.00.01 in RCVCAT database is not current

Been down this road before

I connect to the recovery catalog, and type upgrade catalog (twice).  Error.

error creating set_site_key_for_single_site_dbs
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06004: ORACLE error from recovery catalog database: ORA-00001:
unique constraint (RMAN.SITE_TFATT_P) violated

Great.  I think every time I’ve tried to upgrade the catalog in 11g there’s been some kind of error.  This one was easy enough to find on My Oracle Support: Note 1221983.1 covers it well.  The fix?  Basically, manually edit $ORACLE_HOME/rdbms/admin/recover.bsq and correct their sql:

update site_tfatt set site_key = onesite_row.site_key where
tf_key in (select tf_key from df, dbinc
where dbinc.dbinc_key = df.dbinc_key
and dbinc.db_key = onesite_row.db_key);

becomes
update site_tfatt set site_key = onesite_row.site_key where
tf_key in (select tf_key from tf, dbinc
where dbinc.dbinc_key = tf.dbinc_key
and dbinc.db_key = onesite_row.db_key);

We all make typos right?

This error is well documented, and easy to find.  There’s nothing too alarming about it, except that this code could never have worked. Meaning, Oracle shipped code with their latest, flagship product, which somehow failed quality control in the grandest fashion.   It’s not some obscure combination of events which cause a blip in database performance or throw an error.  It’s code which could not ever work, could not ever be right.   It’s not some recent acquisition, some 3rd party conversion product which 7 people are interested in.  It’s RMAN!  It’s been around forever.   Makes me wonder, what else is wrong with this version of RCVCAT/RCVMAN?

Advertisements

Blog at WordPress.com.