1  –  fetch_for_read_field

    The number of synchronous data page requests to the PIO subsystem
    where only read privileges are being requested for the page. If
    Oracle Rdb reads any area inventory pages (AIPs) and area bit map
    (ABM) pages while fetching the data page, the requests for the
    AIPs and ABM pages are included in the total count field.

    The sum of the fetch for read and fetch for write fields equals
    the total number of synchronous data page requests to the PIO
    subsystem.

2  –  fetch_for_write_field

    The number of data page requests to the PIO subsystem where
    update as well as read privileges are being requested for the
    page. If Oracle Rdb reads any AIPs and ABM pages while fetching
    the data page, the requests for the AIPs and ABM pages are
    included in the total count field.

    The sum of the fetch for read and fetch for write fields equals
    the total number of data page requests to the PIO subsystem.

3  –  in LB: all ok field

    The correct version of the requested page was found in the user's
    local buffer pool and the user already held the needed locks on
    that page.

    This line and the next four lines categorize data page requests
    to the PIO subsystem in terms of what work the subsystem had to
    do to satisfy the request. The sum of this line and the next four
    lines should be equal to the sum of the first two lines.

    The three lines with the LB heading further categorize those data
    page fetch requests to the PIO subsystem where the requested page
    was found in the user's local buffer pool.

4  –  LB: need lock field

    The correct version of the requested page was found in the user's
    local buffer pool but additional locking was required (that is,
    the user did not have the page locked in the needed mode).

5  –  LB: old version field

    The requested page was found in the user's local buffer pool but
    it was an obsolete version of the page (that is, the page has
    been changed by another user since it was read into this user's
    local buffer). Thus, the page must be read again from disk. In
    addition, locks will need to be obtained for this page.

6  –  not_found:_read_field

    Because the requested page was not found in the buffer pool, it
    was read in from disk. This required obtaining appropriate locks
    on the page.

    This line and the "not found: synth" line further categorize data
    page fetch requests to the PIO subsystem in which the requested
    page did not reside in the user's buffer pool.

7  –  _________:_synth_field_

    Because the requested page was not found in the buffer pool, it
    was synthesized into the pool without being read from disk. This
    required obtaining appropriate locks on the page.

    A requested page that is synthesized is either:

    o  "Read" from a WORM storage area

    o  "Read" from a uniform format area and the clump is unallocated

    In both cases, the page does not actually have to be read from
    disk because the page contents are known (that is, Oracle Rdb can
    determine what a formatted unused page looks like). Therefore,
    rather than actually reading the page from disk, Oracle Rdb
    synthesizes the page (produces a properly formatted unused page).
    Page and buffer locking must still occur to keep other users from
    accessing the same page.

8  –  in AS: all ok field

    The correct version of the requested page was found in the user's
    allocate set and the user already held the needed locks on that
    page.

    This line and the next eight lines categorize data page requests
    to the PIO subsystem in terms of what work the subsystem had
    to do to satisfy the request. The sum of this line and the next
    eight lines should be equal to the sum of the first two lines.

    The four lines with the AS: heading further categorize those data
    page fetch requests to the PIO subsystem where the requested page
    was found in the user's allocate set.

9  –  AS: lock for GB field

    The page was found in the user's allocate set and the user held
    sufficient locks to satisfy the request. But because of global
    buffers, additional locking was needed to verify that the version
    was correct. The version was, in fact, correct, so the extra
    locking overhead was due solely to the fact that global buffers
    were being used.

10  –  AS: need lock field

    The correct version of the requested page was found in the user's
    allocate set but additional locking was required (that is, the
    user did not have the page locked in the needed mode).

11  –  AS: old version field

    The requested page was found in the user's allocate set but it
    was an obsolete version of the page (that is, the page has been
    changed by another user since it was added to the requestor's
    allocate set). Thus, the page must be read again from disk. In
    addition, locks will need to be obtained for this page.

12  –  in GB: need lock field

    The correct version of the page was found in the global buffer
    pool. It was necessary to bring this page into the user's
    allocate set and to obtain a lock on the page.

    This line and the GB: old version line further categorize data
    page fetch requests to the PIO subsystem in which the requested
    page was not found in the user's allocate set but was found in
    the global buffer pool.

13  –  GB: old version field

    The page was found in the global buffer pool but it was the wrong
    version. Thus, a lock had to be obtained, the page had to be
    read in from disk to a global buffer, and that buffer had to be
    brought into the user's allocate set.

14  –  GB: transferred field

    The count of the number of data pages that were transferred from
    one process to another without being written to the disk. This
    field is active only when the "transfer via memory" feature is
    enabled.