This screen provides summary locking information for all
    processes activated to collect global statistics using the
    Process Monitoring facility.

    The processes displayed on this screen have previously activated
    their global statistics collection. Process global statistic
    collection can be either implicitly activated by the database
    monitor, or explicitly activated by the RMU Show Statistic
    utility.

    This screen provides the following information:

    o  Process.ID

       The process ID for the current process, assigned by the
       operating system, and the stream ID, assigned by the database.
       If "G" is appended to the process ID, the process had been
       activated for global statistics collection; this is the normal
       case. Server processes will be designated with the "s" tag.

    o  Lock.Rqsts

       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.

    o  prom.Rqsts

       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.

    o  Deadlocks

       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

    o  Blasted

       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 composed of two
       different types of blocking ASTs: those generated externally
       and those generated internally.

       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 RMU Show Statistic
       utility 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. This algorithm serves as an optimistic
       code optimization; the process, assuming it would eventually
       receive a blocking AST for the particular lock, executes the
       blocking AST routine. The RMU Show Statistic utility does not
       differentiate between these two types of blocking ASTs.

    o  Demotes

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

    o  Unlocks

       This field gives the number of deallocating lock requests to
       release an existing lock. These requests always succeed.