Charles, RMAN on a recovery catalog is just another database application, and figuring out performance issue in an RMAN recovery catalog database is the same as for any other database supporting a "3rd-party application" in which you have limited (or no) ability to modify the SQL. It could be as simple as coming up with a sensible stats-gathering plan, to adding appropriate indexes (after checking for Oracle patches that do the same), etc, but there is no sense guessing at it without gathering actual evidence. Employ SQL tracing in the recovery catalog database initiated with an AFTER LOGON database trigger such as the one here, interpret the output using TKPROF or Hotsos/Method-R profiler or TRCANLYZR, and rinse and repeat. Hope this helps... Tim Gorman consultant -> Evergreen Database Technologies, Inc. postal => P.O. Box 630791, Highlands Ranch CO 80163-0791 website => http://www.EvDBT.com/ email => Tim@xxxxxxxxx mobile => +1-303-885-4526 fax => +1-303-484-3608 Lost Data? => http://www.ora600.be/ for info about DUDE... On 10/13/2010 1:59 PM, Charles Schultz wrote: Thanks, Jared, looks like it could quite possibly be unpublished bug 7444008. I hate bugs. Still, I am curious, what exactly is the root problem?-- //www.freelists.org/webpage/oracle-l |