RMUDISPLAY72.HLB  —  Overview  Fields  PIO Statistics SPAM Fetches screen

1  –  fetch_for_read_field

    The number of SPAM page requests to the PIO subsystem where only
    read privileges are being requested for the page.

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

2  –  fetch_for_write_field

    The number of SPAM page requests to the PIO subsystem where
    update as well as read privileges are being requested for the
    page.

    The sum of the fetch for read and fetch for write fields equals
    the total number of SPAM 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 SPAM 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
    SPAM 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 SPAM
    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
    requires 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 of these 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 SPAM 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
    SPAM 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 SPAM
    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 SPAM 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.
Close Help