Yes, there are issues with some fields in ASH not getting cleared out from previous waits which is unfortunate. Some fields such as

CURRENT_OBJ#
CURRENT_FILE#
CURRENT_BLOCK#
CURRENT_ROW#

only get populated for certain waits. Those waits are

Buffer Busy Waits
IO Waits
Enqueue TX

So for example, although it would be tempting to use these for something like “latch: cache buffers chains” it most likely will be misleading and left over from previous waits.

If there is a “-1″ in the current object especially withe current file and block being 0, I interpret that as the field actually being successfully cleared out.
Since above waits are TX enqueue waits i would expect the data to be dependable but I have found issues as well. For example with buffer busy waits on temporary table space header block, the object number is sometimes filled, when the problem is not a object per say. Here is output form ASH (the query is on ashmasters.com called ash_bbw.sql

Time P1 P2 OBJN OTYPE FN BLOCKN BLOCK_TYPE
—– — — —- —– — —— —————–
11:44 202 2 TOTO TABLE 1 60218 file header bloc

The P1 is the file number. This database only had 10 datafiles, so file #202 is a temporary file, not a data file. Temporary datafiles start counting at db_files+tempfile_number. The block type is correct but the CURRENT_OBJ#, CURRENT_FILE# , CURRENT_BLOCK# are all incorrect even though Oracle is suppose to fill these in for buffer busy waits AFAIK. Any know if Oracle clearly documents when CURRENT_OBJ# , CURRENT_FILE# ,CURRENT_BLOCK# are suppose to be filled in?
But the whole point of the above locking examples on index was to show that they have a distinct profile, at least in this version of Oracle, 10.2.0.3, but that due to the nature of ASH and instrumentation changes this profile might be different in different versions.
- Kyle

Nice test cases and observations.

In my experience, isolated tests cases which result in a “-1″ for object id will often result in a misleading object id in real-world scenarios because in the test case the “-1″ will be something that was not relevantly populated in the run up to the tested scenario whereas often in the real world, the immediately preceding event had an appropriate object id set and just not overwritten.

Not sure if that description makes as much sense as I’d like it to.
But, for example, I modelled a real-world ETL problem recently here:
https://orastory.wordpress.com/2012/11/02/modelling-a-simple-itl-problem/
where my test case resulted in a “-1″ object id but the real world ash capture was just am id from a previous wait that was not overwritten by the itl wait.

Cheers,
Dominic