Re: CU lock type

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