Re: Unknown lock type TC

I don't know what a TC is, but you could do the following - find a session which has lost a lot of time on TC locks (look in v$session_event for a high time_waited on enqueues) then hit the session with a 10046 trace at level 8. Wait a while, then search the trace file for WAIT #n name = 'enqueue' ela= p1=1413677060  (or perhaps 66 at the end).

This should give you a clue as to which cursor is suffering from the waits, and this may help.

--
Jonathan Lewis
http://www.jlcomp.demon.co.uk

Host to The Co-Operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

Author of:
Practical Oracle 8i: Building Efficient Databases

Screen saver or Life saver: http://www.ud.com
Use spare CPU to assist in cancer research.

Adon Keber wrote in message ...


>

>One of our applications are working badly and during research of a problem

>I have encountered lock type TC in v$lock

>

>First indication of problem was:

>

>select type,count(*)

>from v$lock

>group by type

>

>TY   COUNT(*)

>-- ----------

>MR         33

>PS          8

>RT          1

>TM          7

>TS          2

>TX          5

>

>It seems that some SELECT query locks itself somehow.

>Lock requested is usually S/ROW-X(SSX) and lock mode is EXCLUSIVE

>

>Final indication of strange problem is:

>

>SELECT ksqsttyp "Lock",

>  ksqstget "Gets",

>  ksqstwat "Waits"

>FROM X$KSQST where KSQSTWAT>0

>

>and result:

>

>Lo       Gets      Waits

>-- ---------- ----------

>PE    3934019          3

>PS    8389739          1

>TC    1331031       2649

>TM    3798880         64

>TX    1780228         18

>

>So applications are mainly waiting on TC lock.

>

>I couldn't find any reference of TC lock type except on metalink where

>Oracle's support person admits that he can't find reference of TC lock

>(Doc ID 101144.998)

>

>Thanks,

>adon

>

>