Re: SV - contention on RAC EXADATA

Hi,

This confirms our previous assumption that the problem of sequence due to the enormous consumption of CPU and problems with the assignment of free processor cycle. Fortunately we reduced CPU consumption (sql profiles,baselines, system statistics and more ...) and right now we don't see so huge waits on "enq: SV - contention".

According to what you wrote call nextval from sequence on RAC requires additional operations (two latch gets) on the CPU / memory - comparing to standalone instance.

enq: SV - contention - avg wait (ms) 0.22

previously we had avg wait (ms) ~13ms

The situation is so much better.

Pozdrawiam / Regards,
Paweł

On Fri, 17 Jun 2016 22:50:22 +0100
Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> wrote:

>
>
> Okay,
>
> I've got it now.
>
> Two things that put me off track:
> a) "enq: SV - contention" doesn't show up in session events, it's
> one of those "wait class other" events
> b) The SV enqueue doesn't show up in v$enqueue_stats.
>
> A call for nextval does two "global enqueue gets sync", one for a
> global SV enqueue and one for a global NB enqueue, and each get
> requires two latch gets.
> Strangely we don't see any waits for the NB enqueue - but I think the
> SV enqueue operations may be more expensive because they have to go
> through a get_value/put_value cycle.
>
> It certainly seems that the work required to get the SV enqueue is
> much higher than you might expect when only a single instance is
> running.
>
>
>
> Regards
>
> Jonathan Lewis
> http://jonathanlewis.wordpress.com/all-postings
>
>

--
http://www.freelists.org/webpage/oracle-l