Re: SQL Performance Problem between 2 Databases WITH FIX included for this case
- From: Wolfgang Breitling <breitliw@xxxxxxxxxxxxx>
- To: ChrisDavid.Taylor@xxxxxxxxxxxxxxx
- Date: Tue, 17 Jan 2012 08:52:05 -0700
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)
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
