Re: parsing puzzle
- From: Thomas Roach <troach@xxxxxxxxx>
- To: jwc7744@xxxxxxxxx
- Date: Fri, 9 Apr 2010 20:06:52 -0400
You said *assume* which means educated guess, but it is still a guess, and I
think what is being said is to follow a method that eliminates the "guess"
work so that you "know" why your process or business task is running slow.
I have used AWR/Statspack with great success, but I have also been bitten by
it by wasting valuable time and resources on the wrong thing. This is
especially true on systems with many processes all running concurrently, but
when the payroll people are complaining that payroll is slow, sometimes it
can be hard to troubleshoot the issue with AWR alone.
Great thread though!
On Fri, Apr 9, 2010 at 5:14 PM, Joe A-C <jwc7744@xxxxxxxxx> wrote:
> But it seems that if the reports consistently show the same results you can
> assume that they are reliable. In my case I've looked at about 25 reports
> and they show the same top wait events when the system is slow. This is not
> the case when the system is performing ok.
>
> Also, even though the reports are not gathering data from every session it
> is taking a sampling of the sessions and as long as the sample is large
> enough then statistically I would think that they are representative of the
> whole. The key of course is the sampling size.
>
> I understand what you're saying about a particular session causing a
> problem but being buried in a lot of other data. I have in the past
> increased the intervals to 10 minutes which would seem to help this issue.
>
> The reports have always helped in the past but if they don't help soon in
> this case I'll be looking at other tools.
>
> Thanks.
>
>
> --- On *Fri, 4/9/10, Cary Millsap <cary.millsap@xxxxxxxxxxxx>* wrote:
>
>
> From: Cary Millsap <cary.millsap@xxxxxxxxxxxx>
> Subject: Re: parsing puzzle
> To: andrew.kerber@xxxxxxxxx
> Cc: Brandon.Allen@xxxxxxxxxxx, "Joe A-C" <jwc7744@xxxxxxxxx>, "
> oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
> Date: Friday, April 9, 2010, 4:57 PM
>
>
> It's just really difficult to tell when AWR results are useful and when
> they're not. That is what *unreliable* is, by definition. A problem with
> even small snapshot intervals is that you're snapping data from potentially
> thousands of sessions that can still bury the data you really need to be
> looking at from one special session that you're trying to diagnose.
>
> Cary Millsap
> Method R Corporation
> http://method-r.com
>
>
> On Fri, Apr 9, 2010 at 2:51 PM, Andrew Kerber
> <andrew.kerber@xxxxxxxxx<http://mc/compose?to=andrew.kerber@xxxxxxxxx>
> > wrote:
>
>> That seems unlikely, the wait events are consistent. However, If you want
>> a short term snapshot though, run this command:
>>
>> exec dbms_workload_repository.create_snapshot
>>
>> at whatever interval you want.
>>
>>
>> On Fri, Apr 9, 2010 at 2:22 PM, Allen, Brandon
>> <Brandon.Allen@xxxxxxxxxxx<http://mc/compose?to=Brandon.Allen@xxxxxxxxxxx>
>> > wrote:
>>
>>> Because they report instance-wide stats, they could be showing you wait
>>> events for processes that are completely unrelated to the problems you're
>>> trying to troubleshoot. And also since they are (usually) at infrequent
>>> intervals, transient problems can easily be buried by other more persistent
>>> events. For example, a session that hangs for 5 minutes blocked by another
>>> transaction's blocking lock - this 5 minute delay could be a major problem
>>> for some business critical function that you're trying to troubleshoot, but
>>> if you look at an AWR report over a 1 hour interval, those 5 minutes of
>>> waiting on the blocking lock/enqueue aren't likely to show up in your top
>>> wait events.
>>>
>>> Regards,
>>> Brandon
>>>
>>> -----Original Message-----
>>> From: Joe A-C
>>> [mailto:jwc7744@xxxxxxxxx<http://mc/compose?to=jwc7744@xxxxxxxxx>
>>> ]
>>>
>>> Why do you say that the AWR reports are likely to be misleading?
>>>
>>>
>>> Privileged/Confidential Information may be contained in this message or
>>> attachments hereto. Please advise immediately if you or your employer do not
>>> consent to Internet email for messages of this kind. Opinions, conclusions
>>> and other information in this message that do not relate to the official
>>> business of this company shall be understood as neither given nor endorsed
>>> by it.
>>> --
>>> //www.freelists.org/webpage/oracle-l
>>>
>>>
>>>
>>
>>
>> --
>> Andrew W. Kerber
>>
>> 'If at first you dont succeed, dont take up skydiving.'
>>
>
>
>
--
Thomas Roach
813-404-6066
troach@xxxxxxxxx
Other related posts:
