RE: v$session_longops

  • From: Tanel Poder <tanel.poder.003@xxxxxxx>
  • To: gints.plivna@xxxxxxxxx, info@xxxxxxxxxxxxxxx
  • Date: Thu, 04 Oct 2007 00:20:38 +0800


The session longops array is split into multiple parts each having its own
freelist and latch.

Operations on each array are protected by separate "longop free list parent"
latches ( controlled by _num_longop_child_latches parameter ).

The max number of longop slots is "hardcoded" into Oracle using ksulomx_

SQL> oradebug dumpvar sga ksulomx_
ub4 ksulomx_ [380007E78, 380007E7C) = 000001F4     <<<--- 0x1F4 is 500 in

The longop array used by a session is probably determined by a MOD function
on SID or Oracle PID, so a session does not see all free slots, thus the
"oldest" longop slot doesn't necessarily get reused first.

Tanel Poder

> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx 
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Gints Plivna
> Sent: Wednesday, October 03, 2007 15:09
> To: info@xxxxxxxxxxxxxxx
> Cc: oracle-l@xxxxxxxxxxxxx
> Subject: Re: v$session_longops
> Jonathan Lewis has written an answer here about the maximum 
> number of entries:
> He said "The number of slots
> in v$session_longops for seems to be the lower of 500 
> and 2 x the sessions parameter."
> Of course you can quite easily test whether it is relevant 
> also for 10g for example.
> However I cannot say anything about the precise algorithm of 
> reuse of entries.


Other related posts: