1  –  latch_requests_field

    This field displays the total number of latch requests that
    have occurred. A latch is requested whenever an internal data
    structure needs to be atomically modified, and indicates a
    potential stall point. The duration of the latch is essentially
    non-measureable.

2  –  __retried_field

    This field indicates the latch could not be immediately acquired
    and the latch had to be requested again. This field provides
    an indication of the contention on the row cache. Ideally, this
    field should be as close to zero as possible.

3  –  cache_searches_field

    This field displays the total number of times the row cache was
    searched for a particular row (DBKEY). Values within this field
    are subdivided into the following fields:

       found in workset
       found in cache
       found too big

4  –  __found_in_workset_field

    This field indicates the particular row was found in the process'
    working set and no additional work was required to fetch the row.
    This is the ideal situation.

5  –  __found_in_cache_field

    This field indicates the particular row was not found in the
    process' working set, but was found in the global row cache. When
    this occurs, it is possible that the process will have to make
    room in the working set by removing an existing row to the global
    cache.

6  –  __found_too_big_field

    This field indicates the particular row was found in the global
    cache, but the row is now too large to fit into the specified
    cache buffer. At one time, the row fit into the cache, but it
    no longer does. Therefore, the cache effectiveness is reduced
    because a cache entry is reserved for the row but no row caching
    is possible.

7  –  insert_cache_field

    This field indicates the total number of times new rows have
    been inserted into the row cache. Values within this field are
    subdivided into the following fields:

       row too big
       cache full
       collision

8  –  __row_too_big_field

    This field indicates the row was initially too large to fit into
    the specified row cache buffer.

9  –  __cache_full_field

    This field indicates that all row cache entries were modified
    and could not be flushed to disk in order to make space for the
    new row. This is an indication that the row cache checkpointing
    intervals specified for the database may be too large.

10  –  __collision_field

    This field displays the total number of row cache hash table
    collisions that occurred when inserting new rows. This field
    provides an indication of the effectiveness of the cache size.

11  –  VLM requests field

    This field displays the number of VLM requests made.

12  –  __window_turns_field

    This field displays the number of VLM requests made for which the
    VLM address range was not immediately available.

13  –  skipped_dirty_slot_field

    This field displays the total number of cache entries that could
    not be replaced because the slot contained modified data rows.
    This field provides an indication of the relative amount of work
    required to find space in order to insert a new row into the
    cache.

14  –  skipped_inuse_slot_field

    This field displays the total number of cache entries that
    could not be replaced because the slot was referenced by other
    processes. This field provides an indication of the relative
    amount of work required to find space in order to insert a new
    row into the cache.

15  –  hash_misses_field

    This field displays the total number of times the row cache hash
    table overflowed.

16  –  cache_unmark_field

    This field displays the total number of times a row in the cache
    was flushed to disk, thus making it eligible to be replaced.
    However, this field does not indicate whether or not the row was
    emptied from the cache.