Re: Wait Event “cursor: pin s” in Oracle Applications

Kumar, you missed my first question which was ‘What are the duration of these waits?’ As Tanel suggested, it might just be that they happened instantaneously but have been left as the last wait event of the sessions because they are purely busy on CPU once they obtain the cursor pin.

Hope this helps,
Andy

On Wed, 19 Dec 2018 at 11:21, Luis Santos <lsantos_at_pobox.com> wrote:

> Mladen, you probably talking about the *_spin_count* parameter, which
> defaults to 2000.
>
> *--*
> *Att*
>
>
> *Luis Santos*
>
>
>
> Em ter, 18 de dez de 2018 às 22:06, Mladen Gogala <gogala.mladen_at_gmail.com>
> escreveu:
>
>> Well, waiting on the latch is always done as running on the CPU. Latches
>> are implemented using the "test and set lock" instruction. If the lock
>> cannot be set, the code will "wait" by executing an "idle loop" on the
>> CPU. Once upon a time, there was even an "underscore parameter" defining
>> the number of iterations in the loop. So, it is technically possible to be
>> both waiting and running on CPU. The main problem with wide spread latch
>> wait is an exorbitant CPU consumption. Waiting for a latch is most active
>> form of waiting there is, which negates the old joke that all computers
>> wait at the same speed.
>>
>> Regards
>> On 12/14/18 5:43 PM, Tanel Poder wrote:
>>
>> How did you determine that the sessions are *waiting* and not on CPU
>> (where v$session incorrectly shows the previous wait event)... which exact
>> query ... v$session ... or ASH?
>>
>> --
>> Tanel Poder
>> https://blog.tanelpoder.com
>>
>> On Fri, Dec 14, 2018 at 8:20 AM Kumar Madduri <ksmadduri_at_gmail.com>
>> wrote:
>>
>>> Hello:
>>> Oracle Applications 12.2 running against 12c database:
>>> User submitted the same concurrent program (with different parameters)
>>> and are running for long time . Noticed that all of the programs are on
>>> event 'cursor: pin s' and a set of sqls are the same (program 1 runs sql_id
>>> 1,
>>> program 2 runs sql_id 1,
>>> program 3 runs sql id 2,
>>> program 4 runs sql id 3
>>> and all of them are waiting on event "cursor: pin s" and that keeps
>>> rotating between different programs (at time t1 program 1 uses sql_id 1 ,
>>> at time t2 program 1 uses sql_id 2 but program 2 uses sql_ids 1 or 2 as
>>> well. I think you see the pattern there)
>>>
>>>
>>> --
>> Mladen Gogala
>> Database Consultant
>> Tel: (347) 321-1217
>>
>>

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