Re: CU lock type

Johnatan,

cursor sharing is not being used

SQL> show parameter cursor

NAME                                 TYPE    VALUE

cursor_sharing                       string  EXACT
cursor_space_for_time                boolean TRUE

The v$session.current_address pointed to a function call. (select pkg.func(:var) from dual)
1 had the same sql call
the rest were executing a different statement which contained a different package (pkg2) call that referenced the current package in procedures, but not this particular function.

I just got from one of the developers:

"I noticed some invalid packages and was recompiling them just before that, I wonder if that was it"

Maybe it was some weird representation of 'library cache pin' wait, which is often a problem during recompiles and concurrent usage. (the application may easily attempt to execute code that's invalid)

Thanks

On Wed, 9 Jun 2004 18:13:04 +0000 (UTC), "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote:

>
>I hope Niall isn't watching, because this may be
>another problem with cursor_sharing.
>
>I've only seen 'CU' locks being used when
>cursor_sharing is invoked. The mechanism
>in 9i seems to be different from the mechanism
>in 8i, but the principle seems to be that the
>locks protect bind variable definitions whilst
>the cursor is being optimised.
>
>I've never seen them hang around - even when
>stressing a single cursor from multiple sessions;
>but then, I haven't tried to break the cursor, only
>test the latching costs.
>
>In 8i, you seem to get one CU lock per bind,
>in 9i it seems to be one CU lock per cursor.
>
>Taking a wild guess - possibly you've got some
>code where the same apparent cursor is used
>with different data types, and something has
>gone wrong in the internal handling of the locking;
>perhaps along the lines of not being able to acquire
>the locks whilst another session is executing the
>cursor.
>
>--
>Regards
>
>Jonathan Lewis
>
>http://www.jlcomp.demon.co.uk
>
>http://www.jlcomp.demon.co.uk/faq/ind_faq.html
>The Co-operative Oracle Users' FAQ
>
>http://www.jlcomp.demon.co.uk/seminar.html
>Optimising Oracle Seminar - schedule updated May 1st
>
>
>"NetComrade" <andreyNSPAM_at_bookexchange.net> wrote in message
>news:40c749fb.175577306_at_localhost...
>> Does anyone knows when this occurs?
>>
>> We had an issue today when such a lock has been 'held' for a few mins,
>> and other sessions were requesting the same resource in 'exclusive'
>> mode. Restarting app servers seemed to remove the problem.
>>
>> There isn't much information on this type of lock on Metalink besides
>> that it's a lock for "Cursor bind"
>>
>> I don't have much more info on the lock, except that v$lock.id1 was
>> -2060275828
>>
>> Thanks.
>> .......
>> We use Oracle 8.1.7.4 on Solaris 2.7 boxes
>> remove NSPAM to email
>
>

.......
We use Oracle 8.1.7.4 on Solaris 2.7 boxes remove NSPAM to email Received on Wed Jun 09 2004 - 14:14:47 CDT