RE: RMAN catalog operations taking 128 seconds per file - where is the bottleneck (and no guessing)
- From: Michael Dinh <mdinh@xxxxxxxxx>
- To: "'tim@xxxxxxxxx'" <tim@xxxxxxxxx>, "sacrophyte@xxxxxxxxx" <sacrophyte@xxxxxxxxx>
- Date: Wed, 13 Oct 2010 15:07:02 -0700
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
Other related posts:
