That is a very helpful summary of which names imply OBJECT_ID and which names imply DATA_OBJECT_ID.

I would be interested in seeing any exceptions to Franck’s summary.

Your comment pretty well matches what I found when I started working with 10.2 in late 2005/early 2006. However, it seems that I have forgotten this fact once or twice, so I thought it best to document it in my Oracle Notes.

It is typically a lot faster (and less resource intensive) to use the OBJ# directly from the trace file to determine the object name, than it is to use the (named in 10g) P1, P2, and P3 parameters to find the object name. The 10g R2 Performance Tuning Guide, however, caused me a bit of confusion initially when I was trying to work with the OBJ# parameters found in 10046 trace files. I kept wondering what caused some lookups using the DATA_OBJECT_ID rather than the OBJECT_ID to work, while others failed – when I read Jonathan Lewis’ blog article (mentioned above) the cause was suddenly quite obvious.

What I’ve observed until now is that within dictionary tables, dictionary views, traces, dbms_xxx packages,…:
- OBJECT_ID, OBJ# or OBJN always refer to the logical object OBJECT_ID
- DATA_OBJECT_ID, DATAOBJ#, OBJD, OBJ, OBJECT_NUMBER always refer to physical segment DATA_OBJECT_ID

But rather than relying on that is is a good idea to test all queries with a moved table, in order to have different ID, (and move it into a transported tablespace in order to avoid another confusion between relative and absolute file numbers…)

Regards,
Franck.