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.
Each deadlock reported in the "rqst deadlocks" field is also
reported in the "rqsts stalled" field. This is because each
deadlocked request is also a stalled request.
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 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 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. 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 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.
15 – invalid_lock_block_field
This field gives the number of invalid lock value blocks
encountered during a lock request or lock promote operation.
16 – ignored_lock_mode_field
This field indicates the number of lock release operations that
could not be performed due to the lock release being requested
from AST context. The lock is instead demoted to NL mode, and can
be released later.
Note that there is no storage area specific statistic for ignored
lock mode statistics.