1  –  locks_requested_field

    This field gives the number of lock requests (also referred to
    as enqueue lock requests) for new locks. Whether the lock request
    succeeds or fails, it is included in this count. The "rqsts not
    queued", "rqsts stalled", and "rqst deadlocks" counts provide
    further detail for enqueue lock requests statistics.

2  –  _rqsts_not_queued_field

    This field gives the number of enqueue lock requests for new
    locks that were rejected immediately because of a lock conflict.
    Oracle Rdb often requests a lock without waiting and, when a
    conflict is detected, resorts to a secondary locking protocol to
    avoid unnecessary deadlocks. This number is one measure of lock
    contention.

3  –  _rqsts_stalled_field

    This field gives the number of enqueue lock requests for new
    locks that were stalled because of a lock conflict. Whether or
    not the lock request ultimately succeeds, it is included in this
    count. This number is one measure of lock contention.

4  –  _rqst_timeouts_field

    This field shows the total number of lock requests that could not
    be granted because they timed out. These are typically logical
    areas.

5  –  _rqst_deadlocks_field

    This field gives the number of stalled enqueue lock requests
    for new locks that ultimately resulted in a deadlock. Most
    deadlocks are tried again and resolved by Oracle Rdb without the
    application program ever knowing there was a deadlock. Therefore,
    the number shown in this field does not necessarily reflect the
    number of deadlocks reported to the application program.

    The number reported in the "rqsts stalled" field is also included
    in this number.

6  –  locks_promoted_field

    This field gives the number of enqueue lock requests to promote
    an existing lock to a higher lock mode. Whether or not the lock
    request succeeds, it is included in this count. The "proms not
    queued," "proms stalled," and "prom deadlocks" counts provide
    further detail for the locks promotion statistics.

7  –  _proms_not_queued_field

    This field gives the number of enqueue lock requests to promote
    an existing lock that were rejected immediately because of a
    lock conflict. Oracle Rdb often requests a lock without waiting.
    When a conflict is detected, Oracle Rdb resorts to a secondary
    locking protocol to avoid unnecessary deadlocks. This number is
    one measure of lock contention.

8  –  _proms_stalled_field

    This field gives the number of enqueue lock requests to promote
    an existing lock to a higher lock mode that were stalled because
    of a lock conflict. Whether or not the lock request ultimately
    succeeds, it is included in this count. This number is one
    measure of lock contention.

9  –  _prom_timeouts_field

    This field shows the total number of lock promotions that could
    not be granted because they timed out. These are typically
    logical areas.

10  –  _prom_deadlocks_field

    This field gives the number of stalled enqueue lock requests to
    promote an existing lock that ultimately resulted in a deadlock.
    Most deadlocks are tried again and resolved by Oracle Rdb without
    the application program ever knowing there was a deadlock.
    Therefore, this number does not necessarily reflect the number
    of deadlocks reported to the application program.

11  –  locks_demoted_field

    This field gives the number of enqueue lock requests to demote
    an existing lock to a lower lock mode. These requests always
    succeed.

12  –  locks_released_field

    This field gives the number of deallocating lock requests to
    release an existing lock. These requests always succeed. The
    number of outstanding locks can be determined by the formula:
    (locks requested) - (rqsts not queued) - (rqst deadlocks) -
    (locks released).

13  –  blocking ASTs field

    This field gives the number of blocking ASTs, sometimes referred
    to as blasts, delivered to Oracle Rdb by the lock manager. A
    blocking AST is delivered to the holder of a lock when a lock
    conflict is detected, which is a good indication of contention
    problems. When Oracle Rdb receives a blocking AST, it often
    demotes or releases a lock in an attempt to avoid unnecessary
    deadlocks.

    The number of blocking ASTs reported is actually comprised of two
    different types of blocking ASTs, those blocking ASTs externally
    generated and those blocking ASTs internally generated.

    An externally generated blocking AST occurs when a blocking AST
    is actually received by the process from the operating system in
    response to some lock conflict with another process. A blocking
    AST routine is executed and the Performance Monitor records the
    blocking AST activity.

    An internally generated blocking AST occurs when a lock-blocking
    AST routine is executed by the process in anticipation that
    the same work would have to be performed anyway if a blocking
    AST were to be received from the operating system, even when
    no blocking AST from the operating system actually occurred.
    This algorithm serves as an optimistic code optimization; it is
    assumed that the process would eventually receive a blocking
    AST for the particular lock, so it optimistically executes
    the blocking AST routine. The Performance Monitor does not
    differentiate between these two types of blocking ASTs.

14  –  stall_time_x100_field

    This field gives the total time (in hundredths of a second)
    spent by all users waiting for a lock. Since more than one user
    can be waiting for a lock at the same time, this total can be
    greater than the actual elapsed clock time. This statistic gives
    a relative measure of work lost due to lock conflicts.