Thanks very much for the reply.

I thought the obj# of ‘enq: TX – index contention’ is the object id of the index. Like this I got in my trace file.

WAIT #9: nam=’enq: TX – index contention’ ela= 423 name|mode=1415053316 usn<<16 | slot=13041696 sequence=97164 obj#=243941 tim=1323553225899572

When it shows -1, it is difficult to find the exact index has this enqueue.

Thanks,
Fei

My experience with obj# in wait events is that the developers were not very consistent about cleaning up after themselves. It is pretty common to see events that are not related to individual objects that have an obj# (presumably because the developers didn’t clear the field), -1 is generally used when an obj# does not apply and the developers have taken the time to set it. But it could also be a case where the value -1 is still hanging around and was not set properly. It is also possible that it is just part a string variable that didn’t get cleared properly. For example the log file sync event, which clearly has no relation to a specific object, looks like this in a recent trace file I generated in 11.2.0.2:

WAIT #47177491275624: nam='log file sync' ela= 661 buffer#=24356 sync scn=816350767 p3=0 obj#=-1 tim=1323740791181536

Of course “log file sync” is not even supposed to have an obj# parameter.

SYS@dbm1> @valid_events
Enter value for event_name: log file sync

EVENT                                                            CLASS           P1                   P2                   P3
---------------------------------------------------------------- --------------- -------------------- -------------------- --------------------
log file sync                                                    Commit          buffer#              sync scn
|

By the way, it looks like the “enq: TX – index contention” event is not supposed to have the obj# parameter either.

SYS@dbm1> @valid_events
Enter value for event_name: %index content%

EVENT                                                            CLASS           P1                   P2                   P3
---------------------------------------------------------------- --------------- -------------------- -------------------- --------------------
enq: TX - index contention                                       Concurrency     name|mode            usn< <16 | slot       sequence
|

So I can only assume that this is just a bug and not really related to the event at all.

Kerry

Basically I want to know what does obj#=-1 mean. From what I can search online, it means the operation is upon no object in particular. But for my case, the wait is on index split, and suppose the obj# is the object_id of the specific index.

*** 2011-12-07 21:26:44.313
WAIT #13: nam=’enq: TX – index contention’ ela= 33006199 name|mode=1415053316 usn<<16 | slot=14876705 sequence=14555 obj#=-1 tim=1323322004313235
WAIT #13: nam='buffer busy waits' ela= 114 file#=19 block#=54725847 class#=1 obj#=259012 tim=1323322004313424

I hope I can get some feedback. And happy holidays.

Thanks,

select 
(select myfunction(x) from dual) x,
(select myfunction(y) from dual) y,
(select myfunction(z) from dual) z,
from some_table
...

of course these values were joined elsewhere which resulted in nested loops which resulted in the indented

FAST DUAL
 FAST DUAL
  FAST DUAL
...

output from XPLAN.

i’m just curious, what’s the sql to generate the lovely plan? :-)