Re: Global Cache and Enqueue Services statistics
- From: Mark Burgess <mark@xxxxxxxxxxxxxxxxxxxxxxxxx>
- To: Amir.Hameed@xxxxxxxxx
- Date: Wed, 1 Aug 2012 15:55:21 +1000
Amir,
is there a particular EBS process that you are seeing this problem with?
Regards,
Mark
On 01/08/2012, at 2:53 PM, K Gopalakrishnan <kaygopal@xxxxxxxxx> wrote:
> Amir,
>
> The problem appears to be with Buffer busy waits at GC layer. 40 ms
> range for gc buffer acquire is way too high and do you care to send
> the awr to me.
>
> Without going to additional details, do you think you can test the
> same workload with _buffer_busy_wait_timeout=2. Just use ALTER SYSTEM.
>
> -Gopal
>
>
> On Mon, Jul 30, 2012 at 3:47 PM, Hameed, Amir <Amir.Hameed@xxxxxxxxx> wrote:
>> Hi Gaja,
>> Below are the top-5 wait events which are the same on all nodes:
>>
>> Top 5 Timed Foreground Events
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Avg
>> wait % DB
>> Event Waits Time(s) (ms) time Wait
>> Class
>> ------------------------------ ------------ ----------- ------ ------
>> ----------
>> db file sequential read 54,365,842 34,374 1 32.3 User
>> I/O
>> gc buffer busy acquire 461,651 18,904 41 17.8 Cluster
>> enq: TX - row lock contention 11,506 15,269 1327 14.4
>> Applicatio
>> DB CPU 11,476 10.8
>> gc current block busy 255,945 10,747 42 10.1 Cluster
>>
>> I am also investigating to see if the test was run the way it should have
>> been because of the ' enq: TX - row lock contention' event. I have also
>> identified statements that were suffering from the 'gc' waits shown above.
>> The underlying segments of those statements have 'freelist groups' defined
>> as '1'. This is an EBS system which has been around for a long time. It was
>> upgraded from 11.0.3 to 11i several years ago and that is most likely why
>> 'freelist groups' of most of the standard segments is '1'.
> --
> //www.freelists.org/webpage/oracle-l
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
