Re: SQL Performance Problem between 2 Databases WITH FIX included for this case

From: Wolfgang Breitling <breitliw_at_centrexcc.com>
Date: Tue, 17 Jan 2012 08:52:05 -0700
Message-Id: <5B143554-29F8-4879-83D3-44829909322A_at_centrexcc.com>



But that requires that you start a trace ( with level 12 ) prior to executing the sql. The row counts and timing you can get from v$sql_plan and v$sql_plan_statistics and the wait events from v$session_event. I am not disputing the usefulness of a 10046 trace. I was merely replying to you comment about the 10053 trace. You need to use the appropriate tools for the task at hand and there are different ways to attack a problem. To analyze the performance of a single sql a 10046 trace would not be my first choice. Far too clumsy. The mentioned v$ views ( plus maybe a few more ) are sufficient for that. To analyze the performance of an entire transaction or job, of course I'd request a 10046 trace because nothing else gives you the full picture.

Regards
Wolfgang Breitling
Centrex Consulting Corporation
http://www.centrexcc.com

On 2012-01-16, at 3:33 PM, Taylor, Chris David wrote:

> I'm still partial to the 10046 due to all the information it gives you. Does Tom's bstat/estat script give execution plans with row counts and wait events and recursive sqls? If not, I can get all that at once :)
>
> (But I still have to remember to actually look at all of it and not get too single minded about a particular piece of it)
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jan 17 2012 - 09:52:05 CST

Original text of this message