What about running RMAN in debug? Michael Dinh : XIFIN : 858.436.2929 NOTICE OF CONFIDENTIALITY - This material is intended for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable laws. BE FURTHER ADVISED THAT THIS EMAIL MAY CONTAIN PROTECTED HEALTH INFORMATION (PHI). BY ACCEPTING THIS MESSAGE, YOU ACKNOWLEDGE THE FOREGOING, AND AGREE AS FOLLOWS: YOU AGREE TO NOT DISCLOSE TO ANY THIRD PARTY ANY PHI CONTAINED HEREIN, EXCEPT AS EXPRESSLY PERMITTED AND ONLY TO THE EXTENT NECESSARY TO PERFORM YOUR OBLIGATIONS RELATING TO THE RECEIPT OF THIS MESSAGE. If the reader of this email (and attachments) is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. Please notify the sender of the error and delete the e-mail you received. Thank you. From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Gorman Sent: Wednesday, October 13, 2010 2:48 PM To: sacrophyte@xxxxxxxxx Cc: Jared Still; ORACLE-L Subject: Re: RMAN catalog operations taking 128 seconds per file - where is the bottleneck (and no guessing) 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<http://www.evdbt.com/tracetrg.sql>, 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<mailto: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<https://supporthtml.oracle.com/ep/faces/secure/km/BugSearch.jspx?bugId=7444008>. I hate bugs. Still, I am curious, what exactly is the root problem? On Wed, Oct 13, 2010 at 14:45, Jared Still <jkstill@xxxxxxxxx<mailto:jkstill@xxxxxxxxx>> wrote: On Wed, Oct 13, 2010 at 12:05 PM, Charles Schultz <sacrophyte@xxxxxxxxx<mailto:sacrophyte@xxxxxxxxx>> wrote: Good day, list, What would cause an RMAN catalog operation to last a relatively eternal 128 seconds? There are a number of notes on MOS regarding RMAN performance, you may want to check there. IIRC there are some indexing issues, though I can't recall any version #'s. Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist Oracle Blog: http://jkstill.blogspot.com Home Page: http://jaredstill.com -- Charles Schultz -- //www.freelists.org/webpage/oracle-l