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

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

Other related posts: