RE: RMAN "rout" table
Date: Wed, 4 Jun 2008 21:36:06 -0400
I had manually applied the package changes that came with 10.2.0.4 onto a 10.2.0.3 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
- 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.
- 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
- Create a new rout table and only insert the last 7 days worth of data, adding all indexes and constraints, stats etc.
- Swap the names of the two tables
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of ~Jeff~
Sent: Wednesday, June 04, 2008 8:16 PM
Subject: RMAN "rout" table
Our (dev) RMAN catalog is on 10.2.0.4 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 10.2.0.3 which are supposedly fixed in 10.2.0.4, but is there something else we can do - maybe purge/rebuild "rout" ?
FWIW, the prod catalog "rout" table is much smaller and has no issues - also on 10.2.0.4, solaris 9.