RE: RMAN "rout" table

From: Ken Naim <>
Date: Wed, 4 Jun 2008 21:36:06 -0400
Message-ID: <D9C59348C47C440AA452B426A921C501@KenPC>

I had manually applied the package changes that came with onto a based on the meatlink note but what the note doesn't mention is the first time per database registered in that catalog it will go out and do a delete of all the records between 7 and 30 days old which can take a long time. And the space will not be reclaimed so performance does not improve as the resync did a full scan on that table on my system. My rout table was over 50 million records at that point so I created new catalogs in the same db (different schemas) and started performing backups using them and as we only had a 30 retention of backups we were completely moved over to it within a month. Ever since then I only backup a handful of databases to one catalog, as I have seen them compete for locks on simultaneous backups.  

If you need to keep the same catalog I would recommend that you

  1. Connect via every database registered in the catalog, and perform a resync. If the box is big enough add parallelism to the table to allow the delete to finish quicker.
  2. rebuild the table to shrink its footprint by moving it to another tablespace.

Or if you are brave and are willing to do some development and testing

  1. Create a new rout table and only insert the last 7 days worth of data, adding all indexes and constraints, stats etc.
  2. Swap the names of the two tables


From: [] On Behalf Of ~Jeff~
Sent: Wednesday, June 04, 2008 8:16 PM
Subject: RMAN "rout" table  

Hi all

Our (dev) RMAN catalog is on but still seems to be having issues with a large "rout" table (~4GB, 23M rows) causing "resync catalog" to fail after some hours and possibly to burn through 300M of redo every minute or two.

I see these bugs in which are supposedly fixed in, but is there something else we can do - maybe purge/rebuild "rout" ? < racle-l> &list=oracle-l

FWIW, the prod catalog "rout" table is much smaller and has no issues - also on, solaris 9.


Received on Wed Jun 04 2008 - 20:36:06 CDT

Original text of this message