1 – Summary IO Statistics screen
1.1 – transactions_field
This field gives the number of completed database transactions.
This is the count of the COMMIT and ROLLBACK statements that have
executed.
1.2 – verb_successes_field
This field gives the number of completed verbs that returned a
successful status code.
1.3 – verb_failures_field
This field gives the number of completed verbs that returned
an error status code. Errors include end-of-collection and
deadlocks, as well as all other exception conditions.
1.4 – synch_data_reads_field
This field gives the number of read-I/Os (queued I/O requests)
issued to the database storage area for single-file and multifile
databases and snapshot files. This operation reads database pages
synchronously from the database.
1.5 – synch_data_writes_field
This field gives the number of write-I/Os (queued I/O requests)
issued to the database storage area for single-file and multifile
databases and snapshot files. This operation writes modified
database pages synchronously back to the database.
1.6 – asynch_data_reads_field
This field gives the number of read-I/Os (queued I/O requests)
issued to the database storage area for single-file and multifile
databases and snapshot files. This operation reads database pages
asynchronously from the database.
1.7 – asynch_data_writes_field
This field gives the number of write-I/Os (queued I/O requests)
issued to the database storage area for single-file and multifile
databases and snapshot files. This operation writes modified
database pages asynchronously back to the database.
1.8 – RUJ file reads field
This field gives the number of read-I/Os (queued I/O requests)
issued to the database recovery-unit journal (.ruj) files. This
operation reads before-image records from the .ruj file to roll
back a verb or a transaction.
1.9 – RUJ file writes field
This field gives the number of write-I/Os (queued I/O requests)
issued to the database recovery-unit journal (.ruj) files. This
operation writes before-image records to the .ruj file in case
a verb or transaction must be rolled back. Before-images must be
written to the RUJ file before the corresponding database page
can be written back to the database.
1.10 – AIJ file reads field
The number of read-I/Os issued to the database .aij file. If
after-image journaling is not enabled for the database, this
statistic will be zero.
1.11 – AIJ file writes field
This field gives the total number of write-I/Os (queued I/O
requests) issued to the database after-image journal (.aij) file.
If after-image journaling is not enabled for the database, this
statistic will be zero. This operation writes after-image records
to the .aij file to facilitate rollforward recovery using the RMU
Recover command.
1.12 – ACE file reads field
This field gives the total number of read I/Os issued to the ACE
file.
1.13 – ACE file writes field
This field gives the total number of write I/Os issued to the ACE
file.
1.14 – root_file_reads_field
This field gives the number of read-I/Os (queued I/O requests)
issued to the database root (.rdb) file. Oracle Rdb reads the
.rdb file when a new user attaches to the database and when an
.rdb file control block needs to be updated because of database
activity on another VMScluster node.
1.15 – root_file_writes_field
This field gives the number of write-I/Os (queued I/O requests)
issued to the database root (.rdb) file. Oracle Rdb writes to
the .rdb file when a user issues a COMMIT or ROLLBACK statement.
Other events also cause updates to the .rdb file.
2 – Summary Locking Statistics screen
2.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.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.
2.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.
2.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.
2.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.
2.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.
2.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.
2.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.
2.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.
2.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.
2.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.
2.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).
2.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.
2.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.
2.15 – invalid_lock_block_field
This field gives the number of invalid lock value blocks
encountered during a lock request or lock promote operation.
2.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.
3 – Summary Object Statistics screen
3.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
shared retrieval access.
3.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object was
actually updated.
3.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
3.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
3.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
4 – Summary Cache Statistics screen
4.1 – latch_requests_field
This field displays the total number of latch requests that
have occurred. A latch is requested whenever an internal data
structure needs to be atomically modified, and indicates a
potential stall point. The duration of the latch is essentially
non-measureable.
4.2 – __retried_field
This field indicates the latch could not be immediately acquired
and the latch had to be requested again. This field provides
an indication of the contention on the row cache. Ideally, this
field should be as close to zero as possible.
4.3 – cache_searches_field
This field displays the total number of times the row cache was
searched for a particular row (DBKEY). Values within this field
are subdivided into the following fields:
found in workset
found in cache
found too big
4.4 – __found_in_workset_field
This field indicates the particular row was found in the process'
working set and no additional work was required to fetch the row.
This is the ideal situation.
4.5 – __found_in_cache_field
This field indicates the particular row was not found in the
process' working set, but was found in the global row cache. When
this occurs, it is possible that the process will have to make
room in the working set by removing an existing row to the global
cache.
4.6 – __found_too_big_field
This field indicates the particular row was found in the global
cache, but the row is now too large to fit into the specified
cache buffer. At one time, the row fit into the cache, but it
no longer does. Therefore, the cache effectiveness is reduced
because a cache entry is reserved for the row but no row caching
is possible.
4.7 – insert_cache_field
This field indicates the total number of times new rows have
been inserted into the row cache. Values within this field are
subdivided into the following fields:
row too big
cache full
collision
4.8 – __row_too_big_field
This field indicates the row was initially too large to fit into
the specified row cache buffer.
4.9 – __cache_full_field
This field indicates that all row cache entries were modified
and could not be flushed to disk in order to make space for the
new row. This is an indication that the row cache checkpointing
intervals specified for the database may be too large.
4.10 – __collision_field
This field displays the total number of row cache hash table
collisions that occurred when inserting new rows. This field
provides an indication of the effectiveness of the cache size.
4.11 – VLM requests field
This field displays the number of VLM requests made.
4.12 – __window_turns_field
This field displays the number of VLM requests made for which the
VLM address range was not immediately available.
4.13 – skipped_dirty_slot_field
This field displays the total number of cache entries that could
not be replaced because the slot contained modified data rows.
This field provides an indication of the relative amount of work
required to find space in order to insert a new row into the
cache.
4.14 – skipped_inuse_slot_field
This field displays the total number of cache entries that
could not be replaced because the slot was referenced by other
processes. This field provides an indication of the relative
amount of work required to find space in order to insert a new
row into the cache.
4.15 – hash_misses_field
This field displays the total number of times the row cache hash
table overflowed.
4.16 – cache_unmark_field
This field displays the total number of times a row in the cache
was flushed to disk, thus making it eligible to be replaced.
However, this field does not indicate whether or not the row was
emptied from the cache.
5 – Summary Cache Unmark Statistics screen
5.1 – latch_granted_field
This field displays the number of times the row lock (latch) was
granted.
5.2 – latch_stalled_field
This field displays the number of times the row lock stalled
before being granted.
5.3 – latch_deadlock_field
This field displays the number of times the row lock stall
resulted in a deadlock.
5.4 – latch_demoted_field
This field displays the number of times the row lock was
released.
5.5 – latch_stall_x100_field
This field displays the row lock stall time (in hundredths of a
second).
6 – Summary Tx Statistics screen
6.1 – transactions_field
This field gives the number of completed database transactions.
This is the count of the COMMIT and ROLLBACK statements that have
executed.
6.2 – __committed_field
This field identifies the actual number of transactions that
committed successfully to the database.
6.3 – __rolled_back_field
This field identifies the actual number of transactions that were
aborted and were not applied to the database.
6.4 – ____duration_x100_field_
This field identifies the duration of the transaction rollback
operation, expressed in hundredths of a second displayed as a
whole number. For example, the value 500 is actually 5 seconds.
6.5 – __prepared_field
This field identifies the number of distributed transactions
that have successfully "prepared" themselves for subsequent
transaction commit.
6.6 – __not_modified_field
This field identifies the number of committed transactions that
did not modify any database objects. This field includes both
read-only and read/write transactions.
6.7 – verb_successes_field
This field gives the number of completed verbs that returned a
successful status code.
6.8 – verb_failures_field
This field gives the number of completed verbs that returned
an error status code. Errors include end-of-collection and
deadlocks, as well as all other exception conditions.
6.9 – __duration_x100_field
This field identifies the duration of the verb failure rollback
operation, expressed in hundredths of a second displayed as a
whole number. For example, the value 500 is actually 5 seconds.
6.10 – checkpoints_field
This field identifies the number of checkpoints performed by
users. This field does not include the initial checkpoint when
the user first attaches to the database.
6.11 – ___duration_x100_field
This field displays the checkpoint duration, expressed in
hundredths of a second displayed as a whole number. For example,
the value 500 is actually 5 seconds.
6.12 – RUJ file reads field
This field displays the total number of read I/O operations
performed on the RUJ journal during the transaction undo phase.
The RUJ file is never written by the database recovery (DBR)
process.
This field includes both synchronous and asynchronous I/O read
requests.
6.13 – ____file_writes_field_
This field displays the total number of write I/O operations
performed on the RUJ journal during the transaction phase.
This field includes both synchronous and asynchronous I/O read
requests.
6.14 – ____file_extend_field_
This field identifies the number of times an RUJ file has been
extended.
7 – Record Statistics screen
7.1 – record_marked_field
This field gives the number of records marked. A record is marked
when it is modified or it is erased, but not when it is stored.
This field does not include records modified in a temporary
table.
7.2 – record_fetched_field
This field gives the number of records, including snapshot
records. This field does not include records retrieved from a
temporary table.
7.3 – ____fragmented_field_
This subfield indicates the number of record fragments that
Oracle Rdb had to fetch. A record is fragmented if it is too
large to fit on one page. A fragmented record requires more
CPU time and more virtual memory, and often requires additional
I/O operations because each record fragment must be fetched. If
this value is high compared to the number of records fetched,
Oracle Corporation recommends that you use the RMU Analyze Areas
command to further analyze the problem to see how many records
are actually fragmented.
7.4 – __record_stored_field
This field gives the number of records stored in the database.
This field does not include records stored in temporary tables.
7.5 – _____fragmented_field_
This subfield indicates the number of rows stored as fragmented
records in the database. This number indicates that a page
size is smaller than a record's uncompressed size (including
overhead). You should use the RMU Analyze Areas command to
further analyze the problem and then increase the page size for
the storage area that has the problem.
7.6 – __pages_checked_field
This field indicates the number of pages checked in order to
store a record. Ideally, very few candidate pages need to
be checked when storing a record. However in certain cases,
depending on record size, access method, locked space on a page,
and SPAM thresholds, storing a record requires a number of page
fetches.
7.7 – saved IO field
This field gives the number of pages checked that did not result
in an I/O because the page was already in the buffer. It is
essentially a "for free" pages checked.
7.8 – ______discarded_field_
This field identifies the number of pages checked but discarded
because the actual free space on that page did not meet the
physical requirements needed to store a new record.
7.9 – record_erased_field
This field gives the number of records erased from the database.
This field does not include records erased from temporary
tables.
7.10 – ___fragmented_field
This subfield indicates the number of fragmented records erased
from the database.
7.11 – temp_record_marked_field
This field gives the number of records marked in a temporary
table. A record is marked when it is modified or it is erased,
but not when it is stored.
7.12 – temp_record_fetchd_field
This field gives the number of records fetched from a temporary
table.
7.13 – temp_record_stored_field
This field gives the number of records stored in a temporary
table.
7.14 – temp_record_erased_field
This field gives the number of records erased from a temporary
table.
8 – Custom Statistics screen
8.1 – database_binds_____field_
This field displays the total number of database attaches on
the current node. If a single process attaches to the database
multiple times, this statistic is incremented by the actual
number of attaches.
8.2 – transactions_______field_
This field gives the number of completed database transactions.
This is the count of the COMMIT and ROLLBACK statements that have
executed.
9 – Snapshot Statistics screen
9.1 – Total transactions field
This field gives the total number of transactions that have been
committed or rolled back, including read-only transactions.
9.2 – R O transactions field
This field gives the total number of read-only transactions that
have been committed or rolled back.
9.3 – retrieved_record_field
This field gives the number of records retrieved by read-only
transactions.
9.4 – __fetched_line_field
This field gives the number of lines fetched by read-only
transactions. To retrieve a single record, a transaction might
actually check a number of lines, some of which may be empty.
9.5 – ____read_snap_page_field_
This field gives the number of snapshot pages fetched by read-
only transactions. If this count is high relative to the other
read fields, read-only transactions are fetching records that
are being updated frequently, and the snapshot file is being used
extensively.
9.6 – stored_snap_record_field
This field gives the number of records stored in the snapshot
file by update transactions. Every snapshot record stored by an
update transaction implies that a snapshot page was found and
utilized. In the best case, this is a single-page fetch. The
"page in use," "page too full," page conflict," and "extended
file" subfields indicate some of the extra overhead involved
in finding suitable snapshot pages on which to store snapshot
records.
9.7 – ____page_in_use_field_
This field gives the number of pages fetched that were unsuitable
for storing snapshot records because the page was owned by
another transaction. A new snapshot page cannot be used again
until the TSN that denotes the age of the page is less than the
oldest active TSN in the database. This ensures that read-only
transactions always find the correct version of a record.
9.8 – ____page_too_full_field_
This field gives the number of pages fetched that were unsuitable
for storing snapshot records because there was not enough room on
the snapshot page to include another version of a record. In this
case, a new snapshot page must be fetched and linked with the
full page. This allows read-only transactions to follow a chain
of snapshot pages to find the correct version of a record.
9.9 – ____page_conflict_field_
This field gives the number of times a snapshot page fetch
was requested but aborted due to a lock conflict with another
process. When a page fetch conflicts with another process,
another target page is fetched and checked so the lock conflict
does not cost a disk I/O operation.
9.10 – ____extended_file_field_
This field gives the number of times the snapshot file has been
extended. The snapshot file is extended when an update operation
cannot find a suitable page on which to store a snapshot record
after checking a certain number of pages.
10 – Stall Statistics Aggregate counts screen
10.1 – miscellaneous______field_
This field displays generic stalls, such as waiting for a
bugcheck dump to complete.
10.2 – records____________field__
This field displays record-related stalls, such as waiting for
record locks to be granted.
10.3 – pages______________field__
This field displays page-related stalls, such as waiting for
storage area I/O to complete or page locks to be granted.
10.4 – tables_____________field__
This field displays table-related stalls, such as waiting for
logical area locks to be granted.
10.5 – storage_areas______field_
This field displays stalls related to storage areas, such as
waiting for storage areas to be created, deleted, truncated or
opened.
10.6 – database_rootfile__field
This field displays stalls related to the database rootfile, such
as waiting for rootfile I/O to complete or object locks to be
granted.
10.7 – recovery_journals__field
This field displays journal-related stalls, such as opening,
initializing or extending journals, as well as waiting for
journal locks to be granted.
10.8 – user_transactions__field
This field displays transaction-related stalls, such as
waiting for distributed transactions to commit, or waiting for
checkpoints to complete.
10.9 – hot_standby________field_
This field displays stalls related to the Hot Standby feature.
10.10 – database___________field__
This field displays database-related stalls, such as waiting for
the database freeze to complete.
11 – Stall Statistics Aggregate durations screen
11.1 – miscellaneous______field_
This field displays generic stalls, such as waiting for a
bugcheck dump to complete.
11.2 – records____________field__
This field displays record-related stalls, such as waiting for
record locks to be granted.
11.3 – pages______________field__
This field displays page-related stalls, such as waiting for
storage area I/O to complete or page locks to be granted.
11.4 – tables_____________field__
This field displays table-related stalls, such as waiting for
logical area locks to be granted.
11.5 – storage_areas______field_
This field displays stalls related to storage areas, such as
waiting for storage areas to be created, deleted, truncated or
opened.
11.6 – database_rootfile__field
This field displays stalls related to the database rootfile, such
as waiting for rootfile I/O to complete or object locks to be
granted.
11.7 – recovery_journals__field
This field displays journal-related stalls, such as opening,
initializing or extending journals, as well as waiting for
journal locks to be granted.
11.8 – user_transactions__field
This field displays transaction-related stalls, such as
waiting for distributed transactions to commit, or waiting for
checkpoints to complete.
11.9 – hot_standby________field_
This field displays stalls related to the Hot Standby feature.
11.10 – database___________field__
This field displays database-related stalls, such as waiting for
the database freeze to complete.
12 – AIJ Statistics screen
12.1 – AIJ file writes field
This field gives the total number of write-I/Os (queued I/O
requests) issued to the database after-image journal (.aij) file.
The "data," "control," "file extend," and "switch over" counts
further subdivide the statistic.
12.2 – ____data_field_
This field gives the number of write-I/Os to the database after-
image journal file that contained only data records.
12.3 – ____control_field_
This field gives the number of write-I/Os to the database after-
image journal file that contained OPEN, COMMIT, ROLLBACK, and
checkpoint records. These writes may also include data records.
12.4 – ____file_extend_field_
This field gives the number of write-I/Os issued to the database
after-image journal file to initialize new disk blocks when the
file is extended.
12.5 – ____switch_over_field_
This field gives the number of times AIJ switch-over has occurred
(the number of times journaling has switched from one journal
file to another).
12.6 – tx__block_span_field
This field displays the number of blocks each transaction spans
in the AIJ journal.
12.7 – records_written_field
This field gives the number of logical after-image journal
records written to the after-image journal file. Because many
logical records can be buffered into a single write-I/O, this
number is usually much larger than the number of .aij file
writes.
No count is kept for the number of logical AIJ records read by
the DBR process.
12.8 – blocks_written_field
This field gives the number of disk blocks written to the after-
image journal file. Because many disk blocks may be written with
a single write-I/O, this number may be larger than the number of
.aij file writes. In addition, the same disk block can be written
more than once, because it might not have been completely full
the first time it was written.
12.9 – ____filler_bytes_field_
This field gives the number of filler bytes (bytes that contain
nothing, that is, memory allocated but not used) needed to pad
AIJ records to a disk block boundary. Filler bytes are necessary
to ensure the readability of the after-image journal file in the
event of a system failure during a write-I/O operation.
12.10 – lock_rebuilds_field
This field gives the number of times that the after-image journal
lock value block had to be rebuilt. The AIJ lock value block
contains the current end-of-file information about the after-
image journal file. The lock value block can be lost when there
is a VMScluster configuration change, or when a user process
holding the lock terminates abnormally (with a Ctrl-Y/STOP, for
example).
12.11 – AIJ file reads field
This field gives the number of read-I/Os executed during lock
rebuilds. To rebuild the lock value block, the after-image
journal file is read backwards to find the last record in the
file.
12.12 – shuffle_averted_field
This field displays the number of times the group commit buffer
has had a shuffle operation averted. The shuffle operation can be
averted for a number of reasons, including setting the RDM$BIND_
AIJ_SHUFFLE_DISABLED logical name to the value "0".
12.13 – suspended_switch_field
This field displays the number of times the AIJ switchover
operation enters the suspended state.
A database enters the "AIJ suspended" state when the AIJ switch-
over operation cannot complete because there are no available
AIJ journals. During this state, the DBA can add new AIJ
journals or perform database backups, but all other AIJ-related
activities are temporarily suspended until an AIJ journal becomes
available.
13 – Group Commit Statistics screen
13.1 – group_commits_field
This field displays the number of group commit operations
performed by the ALS process. Dividing the number of transactions
by the number of groups gives the average group size (the inverse
of the transaction average display.)
13.2 – quick_flushes_field
This field gives the number of times users requested their .aij
records be flushed to the .aij file and those records had already
been flushed by the cooperative actions of another user (group
commit).
13.3 – ARB pool searches field
This field gives the number of times the global after-image
journal request block pool was searched. AIJ records are globally
buffered using ARBs.
13.4 – ____pre_allocation_field_
This field gives the number of ARBs that are able to be pre-
allocated, resulting in reduced transaction commit or rollback
processing (increased throughput).
13.5 – ____pool_empty_field_
This field gives the number of times that the global after-image
journal request block (ARB) pool was found to be empty. In this
event, the active user must force a write operation to the after-
image journal file to free an ARB.
13.6 – cancel:_preemptive_field
This field displays the number of times the background group-
commit operation was canceled because there was no additional
data to be formatted.
13.7 – IO free format field
This field displays the number of times the foreground group-
commit operation was canceled because there was no additional
data to be formatted.
13.8 – submit:_watchdog_field
This field displays the number of times the ALS process attempted
to perform a group-commit operation in anticipation of new work
but found none.
13.9 – ___io_completion_field
This field displays the number of times the group-commit
formatting was completed because the pending asynchronous I/O
operation for the previous group-commit operation completed.
13.10 – ___cache_overflows_field
This field displays the number of times the 64-block .aij cache
has overflowed.
13.11 – ___cache_satisfied_field
This field displays the number of times the group-commit
formatting was completed because the cache-size constraints have
been reached.
13.12 – ___control_record_field
This field displays the number of times the group-commit
formatting was completed because of encountering a control
record for which a process was waiting (and there was no I/O
in progress).
13.13 – DBR recovery field
This field displays the number of times the group-commit
formatting was completed because the current process is DBR and
the database is frozen.
14 – ALS Statistics screen
14.1 – AIJ file writes field
This field gives the total number of write-I/Os (queued I/O
requests) issued to the database after-image journal (.aij) file.
The "data," "control," "file extend," and "switch over" counts
further subdivide the statistic.
14.2 – ____data_field_
This field gives the number of write-I/Os to the database after-
image journal file that contained only data records.
14.3 – ____control_field_
This field gives the number of write-I/Os to the database after-
image journal file that contained OPEN, COMMIT, ROLLBACK, and
checkpoint records. These writes may also include data records.
14.4 – ____file_extend_field_
This field gives the number of write-I/Os issued to the database
after-image journal file to initialize new disk blocks when the
file is extended.
14.5 – ____switch_over_field_
This field gives the number of times AIJ switch-over has occurred
(the number of times journaling has switched from one journal
file to another).
14.6 – AIJ Write Time field
This field gives the time (in hundredths of a second) spent
writing to the .aij file.
14.7 – ALS Hiber Count field
This field displays the number of times the AIJ Log Server
process spent hibernating while waiting for more work.
14.8 – AIJ Hiber Time field
This field displays the amount of time (in hundredths of a
second) that processes have spent hibernating while the AIJ log
server processes their requests.
14.9 – AIJ Extend Time field
This field gives the time (in hundredths of a second) spent
extending the .aij file. An excessively high number often
indicates a full disk or disk fragmentation, or may be an
indication of the need for a larger allocation. Use the JOURNAL
ALLOCATION IS clause of the SQL ALTER DATABASE statement to
specify a larger allocation.
14.10 – Group Commits field
This field displays the number of group commit operations
performed by the ALS process. Dividing the number of transactions
by the number of groups gives the average group size (the inverse
of the transaction average display.)
14.11 – ARBs formatted field
This field displays the number of AIJ Request Blocks that were
formatted by the ALS process.
14.12 – ARBs background field
This field displays the number of AIJ Request Blocks that were
formatted while asynchronous I/O was being performed to the AIJ
journal.
14.13 – premature_io_saved_field
This field displays the number of I/Os saved by waiting for more
work.
14.14 – Cache Overflows field
This field displays the number of times the 64-block .aij cache
has overflowed.
15 – 2PC Statistics screen
15.1 – total_tx_count_field
This field displays the total number of transactions that have
been committed or rolled back.
15.2 – 2PC tx count field
This field displays the total number of distributed transactions
that have been committed or rolled back.
15.3 – total_tx_time_x100_field
This field displays the total duration of all transactions,
expressed in hundredths of a second.
15.4 – __reg_tx_time_x100_field
This field displays the total duration of all non-distributed
transactions, expressed in hundredths of a second.
15.5 – 2PC tx time x100 field
This field displays the total duration of all distributed
transactions, expressed in hundredths of a second.
15.6 – prepared_time_x100_field
This field displays the total duration of the transaction
resolution phase.
15.7 – 2PC tx resolved field
This field displays the total number of distributed transactions
resolved by the database recovery process (DBR). This field
indicates the number of processes that failed while in the
prepared state.
15.8 – 2PC committed field
This field displays the total number of distributed transactions
that were committed.
15.9 – 2PC aborted field
This field displays the total number of distributed transactions
that were rolled back.
16 – RUJ Statistics screen
16.1 – RUJ file writes field
This field gives the number of write-I/Os (queued I/O requests)
issued to the database recovery-unit journal (.ruj) files. This
operation writes before-image records to the .ruj file in case
a verb or transaction must be rolled back. Before-images must be
written to the RUJ file before the corresponding database page
can be written back to the database.
16.2 – ____data_field_
This field displays the total number of synchronous write I/O
operations containing modified database data.
16.3 – ____control_field_
This field displays the total number of synchronous write I/O
operations containing control (header) information.
16.4 – ____file_extend_field_
This field displays the total number of times the recovery-unit
journal files have been extended.
16.5 – records_written_field
This field displays the number of journal records written to the
recovery-unit journal (.ruj) file.
16.6 – RUJ file reads field
This field gives the number of read-I/Os (queued I/O requests)
issued to the database recovery-unit journal (.ruj) files. This
operation reads before-image records from the .ruj file to roll
back a verb or a transaction.
16.7 – blocks_written_field
This field gives the number of disk blocks written to the
recovery-unit journal file. Because many disk blocks may be
written with a single write-I/O, this number may be larger than
the number of .ruj file writes. In addition, the same disk block
can be written more than once, because it might not have been
completely full the first time it was written.
16.8 – _______read_field_
This field displays the total number of 512-byte blocks that have
been read from the .ruj files on this node.
16.9 – cache_overflows_field
This field displays the number of times the recovery-unit data
cache has overflowed, causing a premature synchronous write I/O
operation. Overflowing the data cache indicates update-intensive
transactions.
16.10 – DBKEY cache hits field
This field gives the number of times the same DBKEY (row) was
modified within the same transaction and found in the DBKEY
cache.
16.11 – ______overflows_field_
This field gives the number of times the DBKEY cache ran out of
space and new space had to be allocated.
17 – Fast Incr Backup Statistics screen
17.1 – FIB update attempt field
This field displays the number of times the fast incremental
backup (FIB) operation was attempted. The attempt does not always
result in the SPAM page being updated.
17.2 – FIB map updated field
This field displays the number of times the FIB map, a per-
process data structure, was updated. This data structure
indicates when each process no longer needs to update a
particular SPAM page.
17.3 – SPAM page updated field
This field displays the number of times a SPAM page was
immediately modified to indicate that one or more pages in the
SPAM interval have been modified since the last incremental
backup. Each SPAM page update results in one synchronous read
I/O and one synchronous write I/O operation.
17.4 – SPAM updt deferred field
This field displays the number of times a SPAM page did not need
to be immediately modified, but might have to be modified at a
later time. In most cases, this statistic closely follows the FIB
update attempt statistic.
18 – Checkpoint Statistics screen
18.1 – transactions_field
The total number of transactions (both read/write and read-
only transactions). This statistic represents all transactions
(committed or rolled back) completed by all users of the
database, including transactions that read from the database
as well as transactions that modify the database.
18.2 – checkpoints_field
The total number of checkpoints. The total checkpoints
category is further broken down into categories of reasons for
checkpointing. The statistics for these categories are included
in the "AIJ growth," "txn limit," "time limit," "rollback," "AIJ
backup," and "global" subfields.
Note that there may be more reasons for checkpoints than there
are total checkpoints. For example, you might have a total count
of 100 for checkpoints, but when you add the number of checkpoint
reasons ("AIJ growth," "txn limit," "time limit," "rollback,"
"AIJ backup," and "global"), the total could be greater than 100.
This occurs because a single checkpoint may be triggered by more
than one event. For example, a checkpoint may occur because of
time and AIJ file growth. Although the total count columns for
the "interval: seconds" and "interval: AIJ blks" fields are both
incremented by one, the total count column for "checkpoints" is
only incremented by one.
18.3 – AIJ growth field
The number of checkpoints for all processes due to the .aij file
growth checkpoint limit.
18.4 – ____txn_limit_field_
The number of checkpoints for all processes due to the logical-
defined transaction limit.
18.5 – ____time_limit_field_
The number of checkpoints for all processes due to the time
interval checkpoint limit.
18.6 – ____rollback_field_
The number of checkpoints automatically triggered by rollback of
transactions that updated the database.
18.7 – AIJ backup field
The number of system-generated checkpoints due to periodic
backups to tape of the .aij file by the AIJ spooler.
18.8 – ____global_field_
The number of system-wide checkpoints, issued from an RMU
Checkpoint, RMU Backup, or RMU Backup After_Journal command.
18.9 – interval: AIJ blks field
This field displays the sum of the intervals between checkpoints
due to AIJ growth in block checkpoints for all processes. For
example, if Process 1 checkpoints at virtual block number (VBN)
100, then checkpoints again at VBN 250, the AIJ block interval
category is incremented by 150. If Process 2 checkpoints at VBN
125, then checkpoints again at VBN 200, the AIJ block interval
is incremented by an additional 75. Statistics for the other two
interval categories are displayed in the "interval: tx count" and
"interval: seconds" fields.
If CHECKPOINT INTERVAL IS 1000 BLOCKS is specified with the SQL
ALTER DATABASE statement, each process checkpoints when the .aij
file has grown 1000 blocks since the process' last checkpoint.
Keep in mind that checkpointing influences recovery time. The
main reason to consult checkpoint statistics is to find the
average interval per checkpoint. You can use the information in
the total count column to compute this average. For each category
of checkpoint reason, use the average interval per checkpoint to
help you decide if a checkpointing interval should be adjusted,
and by how much.
If most of the checkpoints for a database are triggered by a
particular checkpoint limit, that limit may be set too high,
or the other two limits may be set too low. You can determine
the average interval per checkpoint for each type of checkpoint
limit. After you have this information, you can reset the limits
so that each type of checkpoint limit triggers approximately the
same number of checkpoints, which results in optimal performance.
To compute the average interval in AIJ blocks, divide the
total count for the AIJ block interval by the total number of
checkpoints minus the number caused by AIJ backups. Although
checkpoints caused by AIJ backups are counted in the total
number of checkpoints, they are not counted in the total of AIJ
block intervals. If the total count of AIJ block intervals is
70000, the total count of checkpoints is 100, and the number
of checkpoints caused by AIJ backups is 1, then the average AIJ
block interval is 707:
70000/(100 - 1) = 707
The help for the "interval: tx count" field explains how to
determine the average interval for transaction checkpoints.
The help for the "interval: seconds" field explains how to
determine the average interval for time checkpoints.
18.10 – interval:_tx_count_field
This field displays the sum of the intervals between checkpoints
due to the transactions count checkpoint for all processes. For
example, if Process 1 checkpoints after 20 transactions, the
transactions count category is incremented by 20. If Process
2 checkpoints after 30 transactions, the transactions count
category is incremented by an additional 30. Statistics for the
other two interval categories are displayed in the "interval: AIJ
blks" and "interval: seconds" fields.
The transactions limit for checkpoints is determined by the
setting of the RDM$BIND_CKPT_TRANS_INTERVAL logical name. If
RDM$BIND_CKPT_TRANS_INTERVAL is defined as a system logical set
to 10, each process will checkpoint after 10 transactions unless
a user redefines the RDM$BIND_CKPT_TRANS_INTERVAL logical to a
different value. That is, if a user defines RDM$BIND_CKPT_TRANS_
INTERVAL as a process logical and sets a value of 5, that user
will checkpoint after 5 transactions.
Keep in mind that checkpointing influences recovery time. The
main reason to consult checkpoint statistics is to find the
average interval per checkpoint. You can use the information in
the total count column to compute this average. For each category
of checkpoint reason, use the average interval per checkpoint to
help you decide if a checkpointing interval should be adjusted,
and by how much.
If most of the checkpoints for a database are triggered by a
particular checkpoint limit, that limit may be set too high,
or the other two limits may be set too low. You can determine
the average interval per checkpoint for each type of checkpoint
limit. After you have this information, you can reset the limits
so that each type of checkpoint limit triggers approximately the
same number of checkpoints, which results in optimal performance.
To compute the average transactions interval, divide the
total count for transaction intervals by the total number of
checkpoints. If the total count for transaction intervals is
800 and the total number of checkpoints is 100, then the average
number of transactions between checkpoints is 8.
800 / 100 = 8
The help for the "interval: AIJ blks" field explains how to
determine the average interval for .aij file growth checkpoints.
The help for the "interval: seconds" field explains how to
determine the average interval for time checkpoints.
18.11 – interval:_seconds_field
This field displays the sum of the intervals between time in
seconds checkpoints for all processes. For example, if Process
1 checkpoints after 500 seconds, the time in seconds category is
incremented by 500. If Process 2 checkpoints after 600 seconds,
the time in seconds category is incremented by an additional 600.
Statistics for the other two interval categories are displayed in
the "interval: AIJ blks" and "interval: tx count" fields.
If CHECKPOINT TIMED EVERY 600 SECONDS is specified with the
SQL ALTER DATABASE statement, each process checkpoints every
10 minutes.
Keep in mind that checkpointing influences recovery time. The
main reason to consult checkpoint statistics is to find the
average interval per checkpoint. You can use the information in
the total count column to compute this average. For each category
of checkpoint reason, use the average interval per checkpoint to
help you decide if a checkpointing interval should be adjusted,
and by how much.
If most of the checkpoints for a database are triggered by a
particular checkpoint limit, that limit may be set too high,
or the other two limits may be set too low. You can determine
the average interval per checkpoint for each type of checkpoint
limit. After you have this information, you can reset the limits
so that each type of checkpoint limit triggers approximately the
same number of checkpoints, which results in optimal performance.
To compute the average time interval, divide the total count for
seconds interval by the total number of checkpoints. If the total
count for the seconds field is 59,300 and the total number of
checkpoints is 100, the average number of seconds between each
time-triggered checkpoint is 593.
59,300 / 100 = 593
The help for the "interval: AIJ blks" field explains how to
determine the average interval for .aij file growth checkpoints.
The help for the "interval: tx count" field explains how to
determine the average interval for transaction checkpoints.
18.12 – checkpoint_stall_field
This field displays the checkpoint duration in seconds.
18.13 – flushed_buffers_field
This field displays the number of buffers flushed to disk during
a checkpoint operation.
19 – Recovery Statistics screen
19.1 – process_attaches_field
This field displays the total number of database attaches on
the current node. If a single process attaches to the database
multiple times, this statistic is incremented by the actual
number of attaches.
19.2 – process_failures_field
This field displays the total number of processes that abnormally
terminated and required database recovery.
In the case of some other node failure, this statistic might
indicate process failure on the other node that was actually
recovered on this node.
19.3 – DB freeze len x100 field
This field displays the total database freeze duration, expressed
in hundredths of a second. During the database freeze, no
database activity is permitted; the database is "frozen". The
longer the duration, the more database performance bottlenecks
may result.
19.4 – Tx REDO count field
This field displays the total number of transactions that needed
to be "redone".
Transaction redo occurs when fast commit transaction processing
is enabled. The fast commit feature contains several parameters
that can be modified to control the overall redo duration, but at
the expense of runtime performance.
Transaction redo requires reading the AIJ journal from the failed
process' checkpoint location and re-applying all subsequent
committed database modifications for that process. This usually
involves re-applying many committed transactions.
The number of transactions redone is not as important as the
amount of work required per transaction. In other words, a single
long transaction requires the same redo processing as many short
transactions.
Transactions that are densely packed into a minimum AIJ interval
are more efficiently redone than a transaction whose data
spans a long range of AIJ blocks. In other words, long-running
transactions that do only occasional infrequent database updates
may be redone more efficiently as several short transactions.
This is an application issue. However, total application
throughput also affects this redo performance.
Transaction redo is normally the longest portion of the process
recovery operation.
19.5 – __redo_time_x100_field
This field displays the total time (in hundredths of a second)
required for transactions that needed to be "redone".
19.6 – Tx UNDO count field
This field displays the total number of transactions that needed
to be "undone".
Transaction undo requires reading the RUJ journal approximately
twice, once forwards to determine the end of the current
transaction, and then backwards from that location to the
beginning of the RUJ file.
Transaction undo is performed only on the transaction that was
currently active, if any, at the time of process failure.
19.7 – __undo_time_x100_field
This field displays the total time (in hundredths of a second)
required for transactions that needed to be "undone".
19.8 – no_undo_needed_field
This field displays the total number of transactions that did
not need to be "undone". Occasionally, the failed process did
not have any active transactions, thereby allowing the database
recovery (DBR) process to avoid having to manually determine if a
transaction needs being "undone".
19.9 – Tx committed field
This field displays the total number of transactions that were
committed during the transaction undo phase. This normally
occurs during the resolution phase of an in-progress distributed
transaction. However, this event can also occur if an optimistic
commit record was found in the AIJ journal that was not yet
recorded in the process' recovery information.
19.10 – Tx rolled back field
This field displays the total number of transactions that were
rolled back during the transaction undo phase. This is the normal
result of transaction undo.
19.11 – No resolve needed field
This field displays the total number of transactions that did not
need to be either committed or rolled back during the transaction
undo phase. This normally occurs when fast commit transaction
processing is enabled, where the RUJ file is examined to locate
an active transaction, but none can be found.
19.12 – AIJ recover x100 field
This field displays the total time (in hundredths of a second)
required to recover the in-progress AIJ flush operation, if any.
This is normally a very fast operation.
19.13 – GB recover x100 field
This field displays the total time (in hundredths of a second)
required to recover the global buffer information, if applicable.
This is normally a very fast operation.
19.14 – Cache recover x100 field
This field displays the total time (in hundredths of a second)
required to recover the row cache following RCS failure or node
failure.
Depending on the number and sizes of the active row caches, this
can be a lengthy operation.
19.15 – RUJ file reads field
This field displays the total number of read I/O operations
performed on the RUJ journal during the transaction undo phase.
The RUJ file is never written by the database recovery (DBR)
process.
19.16 – AIJ file reads field
This field displays the total number of read I/O operations
performed on the AIJ journal during both the transaction redo
and undo phases. If, during the transaction undo phase, the in-
progress transaction is rolled back, a rollback record will be
written to the AIJ journal.
20 – Hot Standby Statistics screen
20.1 – AIJ network send field
This field displays the number of network messages sent.
20.2 – AIJ network recv field
This field displays the number of network messages received.
20.3 – Net msg processed field
This field displays the number of network messages processed.
This field is only updated on the standby database, and is
intended to be used as a comparison against the "AIJ network
recv" field.
20.4 – ____data_field_
This field displays the number of data messages sent to the
standby database or received from the master database.
20.5 – ____control_field_
This field displays the number of control (non-data) messages
sent to the standby database or received from the master
database.
20.6 – ____checkpoints_field_
This field displays the number of checkpoint operations
performed.
20.7 – Stall time x100 field
This field displays the network I/O duration, in hundredths of
seconds.
20.8 – blocks_shipped_field
This field displays the number of 512-byte blocks sent.
20.9 – ______received_field_
This field displays the number of 512-byte blocks received.
20.10 – Stalled MSN found field
This field displays the number of stalled messages identified.
20.11 – Network Reconnect field
This field displays the number of times the network connection
was lost between the master and standby databases. This statistic
only applies to the master database. It could also indicate that
the network object server (router) died prematurely.
20.12 – Free Network Xmit field
This field displays the number of messages that have been sent
for "free". That is, a group commit buffer that does not contain
any transaction "commit" records can always be transmitted with a
synchronization mode of "cold" since no replication of the buffer
can be performed on the standby side. This is an indication of
master database performance optimization.
21 – Synchronization Mode Statistics screen
21.1 – transactions_field
This field gives the number of completed database transactions.
This is the count of the COMMIT and ROLLBACK statements that have
executed.
21.2 – cold_sync_send_field
This field displays the number of cold mode messages sent to the
standby database.
21.3 – warm_sync_send_field
This field displays the number of warm mode messages sent to the
standby database.
21.4 – hot_sync_send_field
This field displays the number of hot mode messages sent to the
standby database.
21.5 – commit_sync_send_field
This field displays the number of commit mode messages sent to
the standby database.
21.6 – cold_stall_x100_field
This field displays the cold message duration, in hundredths of
seconds.
21.7 – warm_stall_x100_field
This field displays the warm message duration, in hundredths of
seconds.
21.8 – hot_stall_x100_field
This field displays the hot message duration, in hundredths of
seconds.
21.9 – commit_stall_x100_field
This field displays the commit message duration, in hundredths of
seconds.
21.10 – Startup Shutdown field
This field displays the number of times the hot standby feature
was started or shut down.
21.11 – Unexpected Failure field
This field displays the number of times the hot standby feature
was shutdown abnormally.
22 – Recovery Information screen
22.1 – transactions_field
This field gives the number of completed database transactions.
This is the count of the COMMIT and ROLLBACK statements that have
executed.
22.2 – _commit_field
This field displays the number of transactions that have been
committed to the standby database.
22.3 – _rollback_field
This field displays the number of transactions that have been
rolled back prior to being applied to the standby database.
22.4 – _prepared_field
This field displays the number of distributed transactions that
have been successfully prepared in anticipation of eventually
being committed to the standby database.
22.5 – Area ready field
This field displays the number of physical storage areas that
have been "readied" during the recovery operation.
22.6 – AIJ records field
This field displays the number of AIJ records applied.
22.7 – _erase_mixed_field
This field displays the number of "erase record" operations
performed on a mixed-format storage area.
22.8 – _erase_uniform_field
This field displays the number of "erase record" operations
performed on a uniform-format storage area.
22.9 – _modify_mixed_field
This field displays the number of "modify record" operations
performed on a mixed-format storage area.
22.10 – _modify_uniform_field
This field displays the number of "modify record" operations
performed on a uniform-format storage area.
22.11 – SPAM updated field
This field displays the number of SPAM page modifications that
occurred as a result of the AIJ journal record. SPAM pages are
typically modified due to a live data page changing its threshold
information.
22.12 – Num failed updates field
This field displays the number of failed updates that are
currently pending REDO. In general, this field should always
be zero. However, it may temporarily increase in value and
subsequently return to zero.
22.13 – TTl failed updated field
This field displays the total number of failed updates. A failed
update is a database modification that cannot be immediately
applied due primarily to the order in which AIJ journal records
are recorded.
23 – PIO Statistics Data Fetches screen
23.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.
23.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.
23.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.
23.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).
23.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.
23.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.
23.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.
23.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.
23.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.
23.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).
23.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.
23.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.
23.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.
23.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.
24 – PIO Statistics SPAM Fetches screen
24.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.
24.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.
24.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.
24.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).
24.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.
24.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.
24.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.
24.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.
24.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.
24.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).
24.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.
24.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.
24.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.
24.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.
25 – PIO Statistics SPAM Prefetches screen
25.1 – APF start: success field
The number of times a APF-initiated buffer fetch attempt was
successful in fetching the buffer. This is possible only if an EX
lock can be obtained for the whole buffer. A successful APF fetch
may actually issue an asynchronous read or simply ensure that a
buffer that was already in the buffer pool now moves to the front
of the LRU queue. In the latter case, the buffer then becomes
least likely to be removed from the buffer pool.
25.2 – _________:_failure_field_
The number of times a APF-initiated buffer fetch attempt failed
due to locking conflicts. If an EX lock cannot be obtained on the
whole buffer, then the fetch attempt will fail.
25.3 – APF I O: utilized field
If a buffer is fetched by APF, it is marked APF_FETCHED. If the
buffer is accessed again, then this statistic is incremented
to indicate that prefetching the buffer by APF was worthwhile.
The statistic is incremented only the first time the buffer is
accessed.
25.4 – _______:_wasted_field_
If a APF-fetched buffer is removed from the buffer pool without
being accessed, then this statistic is incremented to indicate
that fetching the buffer was not worthwhile.
25.5 – DAPF start:success field
The number of times a DAPF-initiated buffer fetch attempt was
successful in fetching the buffer. This is possible only if an
EX lock can be obtained for the whole buffer. A successful DAPF
fetch may actually issue an asynchronous read or simply ensure
that a buffer that was already in the buffer pool now moves to
the front of the LRU queue. In the latter case, the buffer then
becomes least likely to be removed from the buffer pool.
25.6 – __________:failure_field__
The number of times a DAPF-initiated buffer fetch attempt failed
due to locking conflicts. If an EX lock cannot be obtained on the
whole buffer, then the fetch attempt will fail.
25.7 – DAPF I O: utilized field
If a buffer is fetched by DAPF, it is marked DAPF_FETCHED. If
the buffer is accessed again, then this statistic is incremented
to indicate that prefetching the buffer by DAPF was worthwhile.
The statistic is incremented only the first time the buffer is
accessed.
25.8 – ________:_wasted_field_
If a DAPF-fetched buffer is removed from the buffer pool without
being accessed, then this statistic is incremented to indicate
that fetching the buffer was not worthwhile.
26 – PIO Statistics Data Prefetches screen
26.1 – APF start:success field
The number of times a APF-initiated buffer fetch attempt was
successful in fetching the buffer. This is possible only if an EX
lock can be obtained for the whole buffer. A successful APF fetch
may actually issue an asynchronous read or simply ensure that a
buffer that was already in the buffer pool now moves to the front
of the LRU queue. In the latter case, the buffer then becomes
least likely to be removed from the buffer pool.
26.2 – _________:_failure_field_
The number of times a APF-initiated buffer fetch attempt failed
due to locking conflicts. If an EX lock cannot be obtained on the
whole buffer, then the fetch attempt will fail.
26.3 – APF I O: utilized field
If a buffer is fetched by APF, it is marked APF_FETCHED. If the
buffer is accessed again, then this statistic is incremented
to indicate that prefetching the buffer by APF was worthwhile.
The statistic is incremented only the first time the buffer is
accessed.
26.4 – _______:_wasted_field_
If a APF-fetched buffer is removed from the buffer pool without
being accessed, then this statistic is incremented to indicate
that fetching the buffer was not worthwhile.
26.5 – DAPF start:success field
The number of times a DAPF-initiated buffer fetch attempt was
successful in fetching the buffer. This is possible only if an
EX lock can be obtained for the whole buffer. A successful DAPF
fetch may actually issue an asynchronous read or simply ensure
that a buffer that was already in the buffer pool now moves to
the front of the LRU queue. In the latter case, the buffer then
becomes least likely to be removed from the buffer pool.
26.6 – __________:failure_field__
The number of times a DAPF-initiated buffer fetch attempt failed
due to locking conflicts. If an EX lock cannot be obtained on the
whole buffer, then the fetch attempt will fail.
26.7 – DAPF I O: utilized field
If a buffer is fetched by DAPF, it is marked DAPF_FETCHED. If
the buffer is accessed again, then this statistic is incremented
to indicate that prefetching the buffer by DAPF was worthwhile.
The statistic is incremented only the first time the buffer is
accessed.
26.8 – ________:_wasted_field_
If a DAPF-fetched buffer is removed from the buffer pool without
being accessed, then this statistic is incremented to indicate
that fetching the buffer was not worthwhile.
27 – PIO Statistics SPAM Access screen
27.1 – fetch_for_read_field
This field displays the total number of times the SPAM page was
fetched for retrieval.
27.2 – _uniform_area_scan_field
This field displays the total number of times the SPAM page was
fetched for retrieval during a uniform area scan operation. This
is primarily to check if SPAM thresholds need to be adjusted.
27.3 – _record_store_fet_field
This field displays the total number of times the SPAM page was
fetched for retrieval during a record store operation. This is
primarily to check if SPAM thresholds need to be adjusted.
27.4 – _record_modify_fet_field
This field displays the total number of times the SPAM page was
fetched for retrieval during a record modification operation.
This is primarily to check if SPAM thresholds need to be
adjusted.
27.5 – _record_erase_fet_field
This field displays the total number of times the SPAM page was
fetched for retrieval during a record erase operation. This is
primarily to check if SPAM thresholds need to be adjusted.
27.6 – fetch_for_write_field
This field displays the total number of times the SPAM page was
fetched for update.
27.7 – _record_store_upd_field
This field displays the total number of times the SPAM page
was fetched for update during a record store operation. This
is primarily to modify the SPAM thresholds.
27.8 – _record_modify_upd_field
This field displays the total number of times the SPAM page was
fetched for update during a record modification operation. This
is primarily to modify the SPAM thresholds.
27.9 – _record_erase_upd_field
This field displays the total number of times the SPAM page
was fetched for update during a record erase operation. This
is primarily to modify the SPAM thresholds.
27.10 – fetch_for_update_field
This field displays the total number of times the SPAM page was
fetched for update.
27.11 – _clump_allocate_field
This field displays the total number of times the SPAM page was
updated for a clump allocation operation.
27.12 – _fast_incr__bkup_field
This field displays the total number of times the SPAM page was
updated for a fast incremental backup modification.
27.13 – _threshold_update_field
This field displays the total number of times the SPAM page was
updated to change a data page's threshold information.
27.14 – record_stored_field
This field displays the number of records stored in the
database.
27.15 – record_marked_field
This field displays the number of records marked. A record is
marked when it is modified or it is erased, but not when it is
stored.
27.16 – record_erased_field
This field displays the number of records erased from the
database.
28 – PIO Statistics Data Writes screen
28.1 – unmark_buffer_field
This field is incremented by one each time a modified buffer is
written back to disk. Its value should be equal to the sum of
the 14 following fields. These fields as well as the SPAM page
field provide further detail about buffer unmark activity. Write
operations of buffers that contain SPAM pages are included in the
total although they are also counted separately by the SPAM page
field.
Note that unmarking one buffer may entail more than one I/O.
28.2 – __transaction_field
This field is incremented by one for each modified buffer that
is written back to disk as a result of a COMMIT or ROLLBACK
statement.
28.3 – __pool_overflow_field
This field is incremented by one for each modified buffer that
is written back to disk as a result of a request to read in a new
page from disk.
28.4 – blocking AST field
This field is incremented by one for each modified buffer that
is written back to disk in response to a blocking AST (that is, a
page in the buffer was requested by another user).
28.5 – __lock_quota_field
This field is incremented by one for each modified buffer that is
written back to disk due to a user reaching his lock quota.
28.6 – __lock_conflict_field
This field is incremented by one for each modified buffer that is
written back to disk to reduce the possibility of a deadlock when
Oracle Rdb discovers a lock conflict.
28.7 – __user_unbind_field
This field is incremented by one for each modified buffer that is
written back to disk as a result of a user's detaching from the
database. This includes database detaches that occur as part of
an Oracle RMU operation.
28.8 – __batch_rollback_field
This field is incremented by one for each modified buffer that
is written back to disk because of a failed or rolled back batch-
update transaction.
28.9 – __new_area_mode_field
This field is incremented by one for each modified buffer that is
written back to disk as a result of a physical area being readied
in a new lock mode.
28.10 – __larea_change_field
This field is incremented by one for each modified buffer that
is written back to disk as a part of creating, deleting, or
extending a logical area.
28.11 – __incr_backup_field
This field is incremented by one for each modified buffer that
is written back to disk to support the requirements of the
incremental backup feature. These buffers are always SPAM page
buffers.
28.12 – no AIJ access field
This field is incremented by one for each modified buffer that
is written back to disk as a safety precaution after the failure
of an I/O to the .aij file. The buffers are unmarked under such
circumstances only when fast commit processing is enabled to
ensure that all committed data is safely in the database.
28.13 – __truncate_snaps_field
This field is incremented by one for each modified buffer that
is written back to disk as a part of an online snapshot file
truncation.
28.14 – __checkpoint_field
This field is incremented by one for each modified buffer that is
written back to disk as a result of a checkpoint.
28.15 – AIJ backup field
This field is incremented by one for each modified buffer that
is written back to disk to optimize the performance of the quiet-
point backup of the .aij file.
29 – PIO Statistics SPAM Writes screen
29.1 – spam_page_field
This field is incremented by one each time a modified buffer that
contains a space management (SPAM) page is written back to disk.
These write operations are also included in the "unmark buffer"
field.
30 – PIO Statistics File Access screen
30.1 – area_ready_count_field
This field displays the number of times a storage area is readied
for read-only or read/write access. Readying a storage area may
result in a file access (open) operation, but not always.
30.2 – normal_file_open_field
This field displays the number of times a storage area is opened
using the normal operating system mechanism. This typically
indicates the number of different storage areas that are
accessed.
30.3 – _normal_stall_x100_field
This field displays the total duration of the normal file-open
operation, in hundredths of seconds.
30.4 – quick_file_open_field
This field displays the number of times a "quick open" is used to
open the storage area file. This typically occurs for subsequent
opens by any user of a storage area file already opened by
another user, even on another node of the cluster.
30.5 – quick stall X100 field
This field displays the total duration of the quick file-open
operation, in hundreths of seconds.
31 – Asynchronous IO Statistics screen
31.1 – data_read_request_field
The number of requests issued to the PIO subsystem to read data
pages asynchronously.
31.2 – data read IO field
The number of asynchronous read I/O operations done by the PIO
subsystem to get data pages from the disk.
31.3 – spam_read_request_field
The number of requests issued to the PIO subsystem to read SPAM
pages asynchronously.
31.4 – spam read IO field
The number of asynchronous read I/O operations done by the PIO
subsystem to get SPAM pages from the disk.
31.5 – read_stall_count_field
The total number of times the PIO subsystem had to wait for the
completion of asynchronous read I/O operations.
31.6 – read_stall_time_field
The total time (in hundredths of a second) spent waiting for
asynchronous read requests to complete. A high number means the
number of buffers being prefetched is too low. You can specify
that more buffers be prefetched by specifying a higher value with
the RDM$BIND_APF_DEPTH logical name.
31.7 – write IO field
The number of asynchronous writes done by the PIO subsystem to
write data and SPAM pages to the disk.
31.8 – write_stall_count_field
The total number of times the PIO subsystem had to wait for the
completion of asynchronous write I/O.
31.9 – write_stall_time_field
The total time (in hundredths of a second) spent waiting for
asynchronous write requests to complete. An excessively high
number often indicates that the number of clean buffers being
maintained at the end of a process's least recently used queue of
buffers for replacement is too low. You can increase the number
of clean buffers being maintained at the end of a process's least
recently used queue of buffers for replacement by specifying a
higher value with the RDM$BIND_CLEAN_BUF_CNT logical name.
32 – IO Stall Time seconds x100 screen
32.1 – root_read_time_field
This field gives the time (in hundredths of a second) spent
reading the database root (.rdb) file.
32.2 – root_write_time_field
This field gives the time (in hundredths of a second) spent
writing to the database root (.rdb) file.
32.3 – data_read_time_field
This field gives the time (in hundredths of a second) spent
reading database pages from the .rdb, .rda, and .snp files. An
excessively high number often indicates disk contention that
might be alleviated by moving some files to other disks.
32.4 – data_write_time_field
This field gives the time (in hundredths of a second) spent
writing database pages to the .rdb, .rda, and .snp files. An
excessively high number often indicates disk contention that
might be alleviated by moving some files to other disks.
32.5 – data_extend_time_field
This field gives the time (in hundredths of a second) spent
extending the .rdb, .rda, and .snp files. A very high number
often indicates a full disk or disk fragmentation.
32.6 – RUJ read time field
This field gives the time (in hundredths of a second) spent
reading records from the .ruj files during verb or transaction
rollback. An excessively high number often indicates disk
contention that might be alleviated by moving some files to other
disks.
32.7 – RUJ write time field
This field gives the time (in hundredths of a second) spent
writing records to the .ruj files. An excessively high number
often indicates disk contention that might be alleviated by
moving some files to other disks.
32.8 – RUJ extend time field
This field gives the time (in hundredths of a second) spent
extending the .ruj files. An excessively high number often
indicates a full disk or disk fragmentation.
32.9 – AIJ read time field
This field gives the time (in hundredths of a second) spent
reading records from the .aij file.
32.10 – AIJ write time field
This field gives the time (in hundredths of a second) spent
writing to the .aij file.
32.11 – AIJ hiber time field
This field shows the stall time spent hibernating for the AIJ I/O
to complete.
32.12 – AIJ extend time field
This field gives the time (in hundredths of a second) spent
extending the .aij file. An excessively high number often
indicates a full disk or disk fragmentation, or may be an
indication of the need for a larger allocation. Use the JOURNAL
ALLOCATION IS clause of the SQL ALTER DATABASE statement to
specify a larger allocation.
32.13 – database_bind_time_field
This field gives the length of time users are attached to the
database.
33 – Logical Area Statistics screen
33.1 – record_marked_field
This field gives the number of records marked. A record is marked
when it is modified or it is erased, but not when it is stored.
33.2 – record_fetched_field
This field gives the number of records, including snapshot
records, fetched.
33.3 – _fragmented_field
This subfield indicates the number of record fragments that
Oracle Rdb had to fetch. A record is fragmented if it is too
large to fit on one page. A fragmented record requires more
CPU time and more virtual memory, and often requires additional
I/O operations because each record fragment must be fetched. If
this value is high compared to the number of records fetched,
Oracle Corporation recommends that you use the RMU Analyze Areas
command to further analyze the problem to see how many records
are actually fragmented.
33.4 – ___record_stored_field
This field gives the number of records stored in the database.
33.5 – __fragmented_field
This subfield indicates the number of rows stored as fragmented
records in the database. This number indicates that a page
size is smaller than a record's uncompressed size (including
overhead). You should use the RMU Analyze Areas command to
further analyze the problem and then increase the page size for
the storage area that has the problem.
33.6 – pages_checked_field
This field indicates the number of pages checked in order to
store a record. Ideally, very few candidate pages need to
be checked when storing a record. However in certain cases,
depending on record size, access method, locked space on a page,
and SPAM thresholds, storing a record requires a number of page
fetches.
33.7 – saved IO field
This field gives the number of pages checked that did not result
in an I/O because the page was already in the buffer. It is
essentially a "for free" pages checked.
33.8 – ____discarded_field_
This field identifies the number of pages checked but discarded
because the actual free space on that page did not meet the
physical requirements needed to store a new record.
33.9 – _record_erased_field
This field gives the number of records erased from the database.
33.10 – ___fragmented_field
This subfield indicates the number of fragmented records erased
from the database.
33.11 – node_fetches_field
This field gives the number of times Oracle Rdb fetched an
index node during index retrievals. This number includes the
number of leaf nodes and duplicate nodes fetched. Therefore, the
calculation for the number of upper-level index nodes accessed
is: this "node fetches" field minus the sum of the leaf and
duplicate node fetches. The result can indicate the depth of
the database indexes.
33.12 – _leaf_fetches_field
This field gives the number of times Oracle Rdb fetched bottom
level (leaf) nodes during index retrievals. This number, along
with the "index scans" field, can indicate the length of scans in
terms of index nodes accessed. There is one leaf node fetch for
each "index lookup" retrieval.
33.13 – _dup__fetches_field
This field gives the number of times Oracle Rdb fetched a
duplicate node (as opposed to a leaf node) during index
retrievals. This number can indicate the lengths of duplicate
node chains in the database indexes. When a duplicate node is
retrieved, the operation always includes one leaf fetch.
33.14 – index_lookups_field
This field gives the number of direct single-key retrievals
performed on the database indexes. This statistic shows up only
on unique key retrievals and not on duplicate key retrievals.
33.15 – index_scans_field
This field gives the number of scans, or range retrievals,
performed on the database indexes. In an index scan, Oracle Rdb
searches an index from top to bottom to find the starting point
(low value) of the retrieval. Oracle Rdb then searches the bottom
level nodes of the index, including duplicate nodes, until the
scan's end condition is met.
33.16 – _primary_entries_field
This field gives the number of unique keys found during the index
scan.
33.17 – _dup__entries_field
This field gives the number of duplicate keys found during the
index scans. If an index has two entries with the same key value,
the first one is a primary entry and the second is a duplicate
entry.
33.18 – node_insertions_field
This field gives the number of index entries inserted into all
index nodes. This number includes root, leaf, and duplicate
entries within user- and system-defined indexes.
This number is greater than the number of records being stored
in the database because it usually takes one to two insertions
into an index for each record for each index. The calculation of
node insertions minus the sum of the root, leaf, and duplicate
insertions yields the number of entries inserted into mid-level
nodes. This number and the "root insertions" field indicate
sorted balancing activity.
33.19 – _root_insertions_field
This field gives the number of entries inserted into the root
(top-level) index nodes. The number of insertions should be small
except for when you load the database. Also, if an index consists
of only one node, insertions into this node are not included in
this field, but are included in the "leaf insertions" field.
33.20 – _leaf_insertions_field
This field gives the number of unique keys inserted into the
database's indexes. This field indicates the number of entries
inserted into the leaf (bottom-level) index nodes.
33.21 – _dup__insertions_field
This field gives the number of duplicate index keys inserted
into the database's indexes. There should be a one-to-one
correspondence to the number of duplicate records being stored
in the tables.
33.22 – node_creations_field
This field gives the total number of index nodes created during
insertion of index entries into the index trees. This includes
root, leaf, and duplicate nodes created within user- and system-
defined indexes. Nodes are created three ways:
o When an index is first defined
o When a node cannot accommodate an insertion, causing it to
overflow into a new node (node splitting)
o When the first duplicate for a particular key is inserted into
an index, causing a duplicate node to be created
The total number of nodes created and the associated fields
should be relatively small, except for an initial load of the
database with indexes already defined, or for creation of indexes
on already-stored data.
33.23 – _root_splits_field
This field gives the number of times the root nodes have split
because they overflowed after an insertion. A root node split
causes the index to grow by one level-a parent node must be
created to point to the two "halves" of the overflowed root node.
Therefore, two nodes are created-the parent node and the node for
the second half of the root node. Increasing the number of tree
levels means Oracle Rdb must search more index nodes to access a
data row; this can result in additional I/O operations.
33.24 – _leaf_creations_field
This field gives the number of times a leaf (bottom level) node
was created because an existing leaf node had become full and
needed to accommodate another unique index key entry.
33.25 – _dup__creations_field
This field gives the number of times a duplicate node was created
to accommodate more duplicated entries within the duplicate index
node or on the first store of a duplicate key entry.
33.26 – index_creations_field
This field gives the number of times an index was created on
a particular table. This count is the number of CREATE INDEX
statements. Also, if an index is partitioned over three areas,
for example, there will be a count of three index creations.
33.27 – node_removals_field
This field gives the total number of index entries within the
root, leaf, and duplicate nodes that have been removed. This
removal can be triggered by erasing rows, deleting tables, or
deleting indexes. The calculation of node removals minus the sum
of the root, leaf, and duplicate node removals yields the number
of entries removed from mid-level nodes. A node is not deleted
until all its entries are removed.
33.28 – _root_removals_field
This field gives the number of index entries removed from a root
node due to deletion of entries within lower-level nodes. If an
index consists of only one node, removals from this node are not
included in this field, but are included in the "leaf removals"
field.
33.29 – _leaf_removals_field
This field gives the number of unique index keys removed from the
leaf nodes during an SQL DELETE operation.
33.30 – _dup__removals_field
This field gives the number of duplicate index keys removed from
duplicate nodes due to the deletion of duplicate records. This
should be a one-to-one correspondence to the number of erased
duplicate records within the database.
33.31 – node_deletions_field
This field gives the total number of index nodes deleted due
to an SQL DROP INDEX statement or when the nodes become empty
(except for the root node, which remains even when it is empty).
When an index is deleted, this number should be equal to the
total number of index nodes within the index. This field minus
the sum of leaf and duplicate node deletions yields the number of
mid-level node deletions.
33.32 – _leaf_deletions_field
This field gives the number of leaf (bottom level) nodes deleted
from the database's indexes. A leaf node is deleted only when it
becomes empty.
33.33 – _dup__deletions_field
This field gives the number of duplicate node deletions within
the indexes.
33.34 – index_destructions_field
This field gives the number of indexes deleted with an SQL
DROP INDEX statement. This count will be 1 if the index is not
partitioned. If an index that is partitioned over three areas is
deleted, for example, then the count will be 3. This count also
gives the number of root node deletions.
33.35 – __pages_checked_field
This field indicates the number of pages checked in order to
store a B-tree index node. Ideally, very few candidate pages
need to be checked when storing a B-tree index node. However,
in certain cases, depending on the size of the segment, locked
space on a page, and SPAM thresholds, storing a B-tree index node
requires a number of page fetches.
33.36 – saved IO field
This field gives the number of pages checked that did not result
in an I/O because the page was already in the buffer. It is
essentially a "for free" pages checked.
33.37 – ______discarded_field_
This field identifies the number of pages checked but discarded
because the actual free space on that page did not meet the
physical requirements needed to store a new B-tree index node.
33.38 – bucket_marked_field
This field gives the number of buckets marked. A bucket is marked
when it is modified or it is erased, but not when it is stored.
33.39 – bucket_fetched_field
This field gives the number of buckets fetched.
33.40 – ____fragmented_field_
This subfield indicates the number of bucket fragments that
Oracle Rdb had to fetch. A bucket is fragmented if it is too
large to fit on one page. A fragmented bucket requires more
CPU time and more virtual memory, and often requires additional
I/O operations because each bucket fragment must be fetched. If
this value is high compared to the number of buckets fetched,
Oracle Corporation recommends that you use the RMU Analyze Areas
command to further analyze the problem to see how many buckets
are actually fragmented.
33.41 – _bucket_stored_field
This field gives the number of buckets stored in the database.
33.42 – _____fragmented_field_
This subfield indicates the number of buckets stored as
fragmented buckets in the database. This number indicates that a
page size is smaller than a bucket's uncompressed size (including
overhead). You should use the RMU Analyze Areas command to
further analyze the problem and then increase the page size for
the storage area that has the problem.
33.43 – ___pages_checked_field
This field indicates the number of pages checked in order to
store a hashed index. Ideally, very few candidate pages need
to be checked when storing a hashed index. However, in certain
cases, depending on the size of the segment, locked space on a
page, and SPAM thresholds, storing a hashed index requires a
number of page fetches.
33.44 – saved IO field
This field gives the number of pages checked that did not result
in an I/O because the page was already in the buffer. It is
essentially a "for free" pages checked.
33.45 – _______discarded_field_
This field identifies the number of pages checked but discarded
because the actual free space on that page did not meet the
physical requirements needed to store a new hashed index.
33.46 – hash_insertions_field
This field gives the number of hash key insertions in the
database's hashed indexes. It includes unique key insertions
as well as duplicate key insertions.
33.47 – _____duplicates_field_
This field gives the number of duplicate key updates in the
database's hashed indexes.
33.48 – hash_deletions_field
This field gives the number of hash key deletions from the
database's hashed indexes. It includes unique key deletions as
well as duplicate key deletions.
33.49 – ____duplicates_field_
This field gives the number of duplicate key deletions in the
database's hashed indexes.
33.50 – hash_scans_field
This field gives the number of hashed index scans, including both
retrieval and update scans, that were opened on the database's
hashed indexes. A scan is defined as the sequential processing
of the records that meet the search criteria of a query. Hashed
scans then refer to the case where duplicate records are returned
that meet the search criteria of a query from a scan of the
hashed index.
33.51 – hash_index_fetches_field
This field gives the number of hashed index nodes that were
fetched on a successful search of the database's hashed indexes.
This includes fetches of duplicate nodes as well as bucket
fragment nodes.
33.52 – __bucket_fragments_field
This field gives the number of bucket fragments that were fetched
on a successful search of the database's hashed indexes.
33.53 – ___duplicate_nodes_field
This field gives the number of duplicate nodes that were fetched
on a successful search of the database's hashed indexes.
33.54 – blob_marked_field
This field gives the number of blob segments marked. A blob
segment is marked when it is erased or reused, but not when it
is stored.
33.55 – _blob_fetched_field
This field gives the number of blob segments fetched. This number
includes pointer segments in addition to actual user data.
33.56 – ______fragmented_field_
This subfield indicates the number of blob segment fragments that
Oracle Rdb had to fetch. A blob segment is fragmented if it is
too large to fit on one page. A fragmented blob segment requires
more CPU time and more virtual memory, and often requires
additional I/O operations because each blob segment fragment
must be fetched.
This number refers only to actual user data as pointer segments
are unlikely to fragment.
33.57 – _blob_stored_field
This field gives the number of blob segments stored in the
database. This number includes pointer segments in addition to
actual user data.
33.58 – _______fragmented_field_
This subfield indicates the number of rows stored as fragmented
blob segments in the database. This number indicates that a page
size is smaller than a blob segment.
This number refers only to actual user data as pointer segments
are unlikely to fragment.
33.59 – _pages_checked_field
This field indicates the number of pages checked in order to
store a blob segment. Ideally, very few candidate pages need to
be checked when storing a blob segment. However in certain cases,
depending on the size of the segment, locked space on a page, and
SPAM thresholds, storing a blob segment requires a number of page
fetches.
33.60 – saved IO field
This field gives the number of pages checked that did not result
in an I/O because the page was already in the buffer. It is
essentially a "for free" pages checked.
33.61 – _____discarded_field_
This field identifies the number of pages checked but discarded
because the actual free space on that page did not meet the
physical requirements needed to store a new blob segment.
33.62 – blob_erased_field
This field gives the number of blob segments erased from the
database. Note that the erase of blob segments is deferred until
COMMIT time.
33.63 – ________fragmented_field_
This subfield indicates the number of fragmented blob segments
erased from the database.
This number refers only to actual user data as pointer segments
are unlikely to fragment.
34 – Locking total locks screen
34.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.
34.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.
34.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.
34.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.
34.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.
34.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.
34.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.
34.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.
34.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.
34.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.
34.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.
34.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).
34.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.
34.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.
35 – Locking area locks screen
35.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.
35.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.
35.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.
35.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.
35.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.
35.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.
35.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.
35.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.
35.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.
35.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.
35.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.
35.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).
35.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.
35.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.
36 – Locking buffer page locks screen
36.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.
36.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.
36.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.
36.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.
36.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.
36.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.
36.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.
36.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.
36.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.
36.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.
36.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.
36.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).
36.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.
36.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.
37 – Locking record locks screen
37.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.
37.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.
37.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.
37.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.
37.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.
37.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.
37.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.
37.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.
37.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.
37.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.
37.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.
37.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).
37.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.
37.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.
38 – Locking SEQBLK lock screen
38.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.
38.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.
38.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.
38.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.
38.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.
38.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.
38.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.
38.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.
38.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.
38.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.
38.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.
38.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).
38.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.
38.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.
39 – Locking FILID locks screen
39.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.
39.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.
39.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.
39.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.
39.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.
39.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.
39.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.
39.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.
39.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.
39.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.
39.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.
39.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).
39.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.
39.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.
40 – Locking TSNBLK locks screen
40.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.
40.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.
40.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.
40.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.
40.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.
40.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.
40.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.
40.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.
40.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.
40.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.
40.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.
40.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).
40.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.
40.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.
41 – Locking RTUPB lock screen
41.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.
41.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.
41.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.
41.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.
41.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.
41.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.
41.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.
41.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.
41.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.
41.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.
41.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.
41.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).
41.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.
41.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.
42 – Locking ACTIVE lock screen
42.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.
42.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.
42.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.
42.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.
42.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.
42.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.
42.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.
42.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.
42.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.
42.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.
42.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.
42.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).
42.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.
42.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.
43 – Locking MEMBIT lock screen
43.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.
43.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.
43.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.
43.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.
43.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.
43.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.
43.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.
43.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.
43.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.
43.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.
43.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.
43.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).
43.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.
43.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.
44 – Locking AIJ locks screen
44.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.
44.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.
44.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.
44.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.
44.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.
44.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.
44.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.
44.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.
44.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.
44.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.
44.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.
44.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).
44.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.
44.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.
45 – Locking snapshot locks screen
45.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.
45.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.
45.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.
45.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.
45.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.
45.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.
45.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.
45.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.
45.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.
45.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.
45.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.
45.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).
45.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.
45.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.
46 – Locking freeze lock screen
46.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.
46.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.
46.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.
46.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.
46.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.
46.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.
46.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.
46.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.
46.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.
46.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.
46.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.
46.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).
46.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.
46.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.
47 – Locking quiet point lock screen
47.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.
47.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.
47.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.
47.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.
47.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.
47.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.
47.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.
47.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.
47.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.
47.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.
47.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.
47.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).
47.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.
47.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.
48 – Locking logical area locks screen
48.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.
48.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.
48.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.
48.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.
48.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.
48.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.
48.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.
48.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.
48.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.
48.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.
48.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.
48.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).
48.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.
48.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.
49 – Locking nowait transaction screen
49.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.
49.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.
49.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.
49.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.
49.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.
49.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.
49.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.
49.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.
49.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.
49.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.
49.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.
49.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).
49.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.
49.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.
50 – Locking CLIENT locks screen
50.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.
50.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.
50.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.
50.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.
50.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.
50.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.
50.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.
50.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.
50.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.
50.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.
50.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.
50.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).
50.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.
50.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.
51 – Locking locks requested screen
51.1 – total_locks_field
This field gives statistics for all types of database locks.
51.2 – area_locks_field
This field gives statistics for database physical area locks.
51.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
51.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
51.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
51.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
51.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
51.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
51.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
51.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the VMScluster nodes on which the database is currently
accessed.
51.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
51.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
51.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
51.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
51.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
51.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
51.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
52 – Locking rqsts not queued screen
52.1 – total_locks_field
This field gives statistics for all types of database locks.
52.2 – area_locks_field
This field gives statistics for database physical area locks.
52.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
52.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
52.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
52.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
52.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
52.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
52.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
52.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the VMScluster nodes on which the database is currently
accessed.
52.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
52.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
52.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
52.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
52.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
52.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
52.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
53 – Locking rqsts stalled screen
53.1 – total_locks_field
This field gives statistics for all types of database locks.
53.2 – area_locks_field
This field gives statistics for database physical area locks.
53.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
53.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
53.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
53.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
53.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
53.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
53.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
53.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
53.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
53.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
53.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
53.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
53.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
53.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
53.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
54 – Locking rqst timeouts screen
54.1 – total_locks_field
This field gives statistics for all types of database locks.
54.2 – area_locks_field
This field gives statistics for database physical area locks.
54.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
54.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
54.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
54.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
54.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
54.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
54.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
54.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
54.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
54.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
54.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
54.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
54.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
54.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
54.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
55 – Locking rqst deadlocks screen
55.1 – total_locks_field
This field gives statistics for all types of database locks.
55.2 – area_locks_field
This field gives statistics for database physical area locks.
55.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
55.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
55.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
55.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
55.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
55.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
55.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
55.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
55.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
55.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
55.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
55.14 – quiet_point_lock_field
This field gives statistics for the database quiet point-lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
55.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
55.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
55.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
56 – Locking locks promoted screen
56.1 – total_locks_field
This field gives statistics for all types of database locks.
56.2 – area_locks_field
This field gives statistics for database physical area locks.
56.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
56.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
56.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
56.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
56.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
56.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
56.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
56.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
56.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
56.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
56.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
56.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
56.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
56.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
56.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
57 – Locking proms not queued screen
57.1 – total_locks_field
This field gives statistics for all types of database locks.
57.2 – area_locks_field
This field gives statistics for database physical area locks.
57.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
57.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
57.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
57.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
57.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
57.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
57.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
57.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
57.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
57.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
57.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
57.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
57.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
57.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
57.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
58 – Locking proms stalled screen
58.1 – total_locks_field
This field gives statistics for all types of database locks.
58.2 – area_locks_field
This field gives statistics for database physical area locks.
58.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
58.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
58.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
58.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
58.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
58.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
58.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
58.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
58.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
58.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
58.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
58.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
58.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
58.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
58.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
59 – Locking prom timeouts screen
59.1 – total_locks_field
This field gives statistics for all types of database locks.
59.2 – area_locks_field
This field gives statistics for database physical area locks.
59.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
59.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
59.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
59.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
59.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
59.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
59.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
59.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
59.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
59.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
59.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
59.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
59.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
59.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
59.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
60 – Locking prom deadlocks screen
60.1 – total_locks_field
This field gives statistics for all types of database locks.
60.2 – area_locks_field
This field gives statistics for database physical area locks.
60.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
60.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
60.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
60.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
60.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
60.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
60.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
60.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
60.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
60.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
60.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
60.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
60.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
60.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
60.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
61 – Locking locks demoted screen
61.1 – total_locks_field
This field gives statistics for all types of database locks.
61.2 – area_locks_field
This field gives statistics for database physical area locks.
61.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
61.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
61.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
61.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
61.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
61.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
61.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
61.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
61.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
61.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
61.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
61.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
61.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
61.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
61.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
62 – Locking locks released screen
62.1 – total_locks_field
This field gives statistics for all types of database locks.
62.2 – area_locks_field
This field gives statistics for database physical area locks.
62.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
62.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
62.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
62.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
62.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
62.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
62.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
62.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
62.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
62.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
62.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
62.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
62.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
62.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
62.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
63 – Locking blocking ASTs screen
63.1 – total_locks_field
This field gives statistics for all types of database locks.
63.2 – area_locks_field
This field gives statistics for database physical area locks.
63.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
63.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
63.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
63.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
63.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
63.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
63.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
63.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
63.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
63.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
63.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
63.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
63.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
63.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
63.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
64 – Locking stall time x100 screen
64.1 – total_locks_field
This field gives statistics for all types of database locks.
64.2 – area_locks_field
This field gives statistics for database physical area locks.
64.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
64.4 – record_locks_field
This field gives statistics for database record locks. Record
locks maintain the logical consistency of the database. This set
of statistics includes all record locks in the adjustable lock
granularity tree.
64.5 – SEQBLK lock field
This field gives statistics for the database sequence block
(SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
or transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
64.6 – FILID locks field
This field gives statistics for the database file identification
(FILID) locks. The FILID locks maintain consistent end-of-file
information for the .rdb, .rda, and .snp database files.
64.7 – TSNBLK locks field
This field gives statistics for the database transaction block
(TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
operations on each VMScluster node. TSNBLK locks are also
used to control SQL SET TRANSACTION statements for read-only
transactions.
64.8 – RTUPB lock field
This field gives statistics for the database run-time user
process block (RTUPB) lock. The RTUPB locks maintain a consistent
list of the users who are attached to the database.
64.9 – ACTIVE lock field
This field gives statistics for the database ACTIVE user bit map
lock. The ACTIVE lock maintains a consistent list (in bit map
form) of the users who are attached to the database.
64.10 – MEMBIT lock field
This field gives statistics for the database MEMBIT node bit map
lock. The MEMBIT locks maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
64.11 – AIJ locks field
This field gives statistics for the after-image journal (AIJ)
locks. AIJ locks control reading from and writing to the
.aij file. One global AIJ lock maintains current end-of-file
information. In addition, there is one local AIJ lock on each
VMScluster node that manages the global AIJ buffer on that node.
64.12 – snapshot_locks_field
This field gives statistics for the database snapshot locks.
Snapshot locks manage the allocation of snapshot pages to users
who are updating the database. Snapshot locks are only used if
snapshots are enabled for a storage area.
64.13 – freeze_lock_field
This field gives statistics for the database freeze lock. The
freeze lock suspends database activity while a database recovery
process is running.
64.14 – quiet_point_lock_field
This field gives statistics for the database quiet-point lock.
The quiet-point lock suspends starting new transactions while
the AIJ despooler is trying to finish despooling the contents
of the primary .aij file when you use the RMU Backup After_
Journal command. The quiet-point lock also suspends starting new
transactions during the startup of an online RMU Backup command.
64.15 – logical_area_locks_field
Logical area locks are obtained when Oracle Rdb readies tables.
Lock carryover can help reduce the number of logical area locks.
64.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
64.17 – CLIENT locks field
This field monitors the database client information (CLIENT)
lock. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system tables. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
Note: This field is only displayed on terminal displays
containing more than 24 lines.
65 – File Locking Statistics screen
65.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.
65.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.
65.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.
65.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.
65.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.
65.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.
65.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.
65.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.
65.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.
65.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.
65.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.
65.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).
65.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.
65.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.
66 – Row Cache by cache screen
66.1 – latch_requests_field
This field displays the total number of latch requests that
have occurred. A latch is requested whenever an internal data
structure needs to be atomically modified, and indicates a
potential stall point. The duration of the latch is essentially
non-measureable.
66.2 – __retried_field
This field indicates the latch could not be immediately acquired
and the latch had to be requested again. This field provides
an indication of the contention on the row cache. Ideally, this
field should be as close to zero as possible.
66.3 – cache_searches_field
This field displays the total number of times the row cache was
searched for a particular row (DBKEY). Values within this field
are subdivided into the following fields:
found in workset
found in cache
found too big
66.4 – __found_in_workset_field
This field indicates the particular row was found in the process'
working set and no additional work was required to fetch the row.
This is the ideal situation.
66.5 – __found_in_cache_field
This field indicates the particular row was not found in the
process' working set, but was found in the global row cache. When
this occurs, it is possible that the process will have to make
room in the working set by removing an existing row to the global
cache.
66.6 – __found_too_big_field
This field indicates the particular row was found in the global
cache, but the row is now too large to fit into the specified
cache buffer. At one time, the row fit into the cache, but it
no longer does. Therefore, the cache effectiveness is reduced
because a cache entry is reserved for the row but no row caching
is possible.
66.7 – insert_cache_field
This field indicates the total number of times new rows have
been inserted into the row cache. Values within this field are
subdivided into the following fields:
row too big
cache full
collision
66.8 – __row_too_big_field
This field indicates the row was initially too large to fit into
the specified row cache buffer.
66.9 – __cache_full_field
This field indicates that all row cache entries were modified
and could not be flushed to disk in order to make space for the
new row. This is an indication that the row cache checkpointing
intervals specified for the database may be too large.
66.10 – __collision_field
This field displays the total number of row cache hash table
collisions that occurred when inserting new rows. This field
provides an indication of the effectiveness of the cache size.
66.11 – VLM requests field
This field displays the number of VLM requests made.
66.12 – __window_turns_field
This field displays the number of VLM requests made for which the
VLM address range was not immediately available.
66.13 – skipped_dirty_slot_field
This field displays the total number of cache entries that could
not be replaced because the slot contained modified data rows.
This field provides an indication of the relative amount of work
required to find space in order to insert a new row into the
cache.
66.14 – skipped_inuse_slot_field
This field displays the total number of cache entries that
could not be replaced because the slot was referenced by other
processes. This field provides an indication of the relative
amount of work required to find space in order to insert a new
row into the cache.
66.15 – hash_misses_field
This field displays the total number of times the row cache hash
table overflowed.
66.16 – cache_unmark_field
This field displays the total number of times a row in the cache
was flushed to disk, thus making it eligible to be replaced.
However, this field does not indicate whether or not the row was
emptied from the cache.
67 – RCS Statistics screen
67.1 – find_buffer_stall_field
This field gives the length of time (in hundredths of a second)
required to allocate a checkpoint buffer. Typically, this value
should be extremely small.
68 – Index Statistics Retrieval screen
68.1 – transactions_field
This field gives the number of completed database transactions.
This is the count of the COMMIT and ROLLBACK statements that have
executed.
68.2 – verb_successes_field
This field gives the number of intermediate recoverable
operations that returned a successful status code.
68.3 – verb_failures_field
This field gives the number of intermediate recoverable
operations that returned an error status code, including
deadlocks and other exception conditions.
68.4 – node_fetches_field
This field gives the number of times Oracle Rdb fetched an
index node during index retrievals. This number includes the
number of leaf nodes and duplicate nodes fetched. Therefore, the
calculation for the number of upper-level index nodes accessed
is: this "node fetches" field minus the sum of the leaf and
duplicate node fetches. The result can indicate the depth of
the database indexes.
68.5 – _leaf_fetches_field
This field gives the number of times Oracle Rdb fetched bottom
level (leaf) nodes during index retrievals. This number, along
with the "index scans" field, can indicate the length of scans in
terms of index nodes accessed. There is one leaf node fetch for
each "index lookup" retrieval.
68.6 – _dup__fetches_field
This field gives the number of times Oracle Rdb fetched a
duplicate node (as opposed to a leaf node) during index
retrievals. This number can indicate the lengths of duplicate
node chains in the database indexes. When a duplicate node is
retrieved, the operation always includes one leaf fetch.
68.7 – index_lookups_field
This field gives the number of direct single-key retrievals
performed on the database indexes. This statistic shows up only
on unique key retrievals and not on duplicate key retrievals.
68.8 – index_scans_field
This field gives the number of scans, or range retrievals,
performed on the database indexes. In an index scan, Oracle Rdb
searches an index from top to bottom to find the starting point
(low value) of the retrieval. Oracle Rdb then searches the bottom
level nodes of the index, including duplicate nodes, until the
scan's end condition is met.
68.9 – _primary_entries_field
This field gives the number of unique keys found during the index
scan.
68.10 – _dup__entries_field
This field gives the number of duplicate keys found during the
index scans. If an index has two entries with the same key value,
the first one is a primary entry and the second is a duplicate
entry.
69 – Index Statistics Insertion screen
69.1 – node_insertions_field
This field gives the number of index entries inserted into all
index nodes. This number includes root, leaf, and duplicate
entries within user- and system-defined indexes.
This number is greater than the number of records being stored
in the database because it usually takes one to two insertions
into an index for each record for each index. The calculation of
node insertions minus the sum of the root, leaf, and duplicate
insertions yields the number of entries inserted into mid-level
nodes. This number and the "root insertions" field indicate
sorted balancing activity.
69.2 – _root_insertions_field
This field gives the number of entries inserted into the root
(top-level) index nodes. The number of insertions should be small
except for when you load the database. Also, if an index consists
of only one node, insertions into this node are not included in
this field, but are included in the "leaf insertions" field.
69.3 – _leaf_insertions_field
This field gives the number of unique keys inserted into the
database's indexes. This field indicates the number of entries
inserted into the leaf (bottom-level) index nodes.
69.4 – _dup__insertions_field
This field gives the number of duplicate index keys inserted
into the database's indexes. There should be a one-to-one
correspondence to the number of duplicate records being stored
in the tables.
69.5 – node_creations_field
This field gives the total number of index nodes created during
insertion of index entries into the index trees. This includes
root, leaf, and duplicate nodes created within user- and system-
defined indexes. Nodes are created three ways:
o When an index is first defined
o When a node cannot accommodate an insertion, causing it to
overflow into a new node (node splitting)
o When the first duplicate for a particular key is inserted into
an index, causing a duplicate node to be created
The total number of nodes created and the associated fields
should be relatively small, except for an initial load of the
database with indexes already defined, or for creation of indexes
on already-stored data.
69.6 – _root_splits_field
This field gives the number of times the root nodes have split
because they overflowed after an insertion. A root node split
causes the index to grow by one level-a parent node must be
created to point to the two "halves" of the overflowed root node.
Therefore, two nodes are created-the parent node and the node for
the second half of the root node. Increasing the number of tree
levels means Oracle Rdb must search more index nodes to access a
data row; this can result in additional I/O operations.
69.7 – _leaf_creations_field
This field gives the number of times a leaf (bottom level) node
was created because an existing leaf node had become full and
needed to accommodate another unique index key entry.
69.8 – _dup__creations_field
This field gives the number of times a duplicate node was created
to accommodate more duplicated entries within the duplicate index
node or on the first store of a duplicate key entry.
69.9 – index_creations_field
This field gives the number of times an index was created on
a particular table. This count is the number of CREATE INDEX
statements. Also, if an index is partitioned over three areas,
for example, there will be a count of three index creations.
70 – Index Statistics Removal screen
70.1 – node_removals_field
This field gives the total number of index entries within the
root, leaf, and duplicate nodes that have been removed. This
removal can be triggered by erasing rows, deleting tables, or
deleting indexes. The calculation of node removals minus the sum
of the root, leaf, and duplicate node removals yields the number
of entries removed from mid-level nodes. A node is not deleted
until all its entries are removed.
70.2 – _root_removals_field
This field gives the number of index entries removed from a root
node due to deletion of entries within lower-level nodes. If an
index consists of only one node, removals from this node are not
included in this field, but are included in the "leaf removals"
field.
70.3 – _leaf_removals_field
This field gives the number of unique index keys removed from the
leaf nodes during an SQL DELETE operation.
70.4 – _dup__removals_field
This field gives the number of duplicate index keys removed from
duplicate nodes due to the deletion of duplicate records. This
should be a one-to-one correspondence to the number of erased
duplicate records within the database.
70.5 – node_deletions_field
This field gives the total number of index nodes deleted due
to an SQL DROP INDEX statement or when the nodes become empty
(except for the root node, which remains even when it is empty).
When an index is deleted, this number should be equal to the
total number of index nodes within the index. This field minus
the sum of leaf and duplicate node deletions yields the number of
mid-level node deletions.
70.6 – _leaf_deletions_field
This field gives the number of leaf (bottom level) nodes deleted
from the database's indexes. A leaf node is deleted only when it
becomes empty.
70.7 – _dup__deletions_field
This field gives the number of duplicate node deletions within
the indexes.
70.8 – index_destructions_field
This field gives the number of indexes deleted with an SQL
DROP INDEX statement. This count will be 1 if the index is not
partitioned. If an index that is partitioned over three areas is
deleted, for example, then the count will be 3. This count also
gives the number of root node deletions.
71 – Hash Index Statistics Screen
71.1 – hash_insertions_field
This field gives the number of hash key insertions in the
database's hashed indexes. It includes unique key insertions
as well as duplicate key insertions.
71.2 – _____duplicates_field_
This field gives the number of duplicate key updates in the
database's hashed indexes.
71.3 – hash_deletions_field
This field gives the number of hash key deletions from the
database's hashed indexes. It includes unique key deletions as
well as duplicate key deletions.
71.4 – ____duplicates_field_
This field gives the number of duplicate key deletions in the
database's hashed indexes.
71.5 – hash_scans_field
This field gives the number of hashed index scans, including both
retrieval and update scans, that were opened on the database's
hashed indexes. A scan is defined as the sequential processing
of the records that meet the search criteria of a query. Hashed
scans then refer to the case where duplicate records are returned
that meet the search criteria of a query from a scan of the
hashed index.
71.6 – hash_index_fetches_field
This field gives the number of hashed index nodes that were
fetched on a successful search of the database's hashed indexes.
This includes fetches of duplicate nodes as well as bucket
fragment nodes.
71.7 – __bucket_fragments_field
This field gives the number of bucket fragments that were fetched
on a successful search of the database's hashed indexes.
71.8 – ___duplicate_nodes_field
This field gives the number of duplicate nodes that were fetched
on a successful search of the database's hashed indexes.
71.9 – hash_bucket_stores_field
This field gives teh number of hash index buckets stored in the
index. A hash index bucket contains one or more hash keys.
72 – Name Translation screen
72.1 – dashboard_updated__field
This field displays the number of times a user has received
notification that the database dashboard has been updated.
72.2 – name_translated_field
This field displays the number of times a logical name has been
translated.
72.3 – _____defaulted_field_
This field displays the number of times the default value was
used for a logical name.
73 – Object KROOT object screen
73.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
73.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
73.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
73.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
73.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
73.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
74 – Object FILID object screen
74.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
74.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
74.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
74.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
74.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
74.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
75 – Object SEQBLK object screen
75.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
75.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
75.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
75.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
75.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
75.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
76 – Object TSNBLK object screen
76.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
76.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
76.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
76.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
76.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
76.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
77 – Object AIJDB object screen
77.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
77.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
77.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
77.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
77.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
77.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
78 – Object AIJFB object screen
78.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
78.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
78.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
78.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
78.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
78.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
79 – Object RTUPB object screen
79.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
79.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
79.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
79.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
79.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
79.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
80 – Object ACTIVE object screen
80.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
80.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
80.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
80.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
80.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
80.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
81 – Object CPT object screen
81.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
81.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
81.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
81.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
81.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
81.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
82 – object RCACHE object screen
82.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
82.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
82.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
82.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
82.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
82.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
83 – Object CLIENT object screen
83.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
83.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
83.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
83.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
83.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
83.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
84 – Object CLTSEQ object screen
84.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
84.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
84.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
84.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
84.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
84.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
85 – Object UTILITY object screen
85.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
85.2 – objects_fetch_excl_field
This field displays the number of objects that are fetched
for exclusive access with the intention of subsequently being
updated. This statistic does not indicate that the object
actually was updated.
85.3 – objects_refreshed_field
This field displays the number of objects whose information
in the global section was detected as being stale, so the
information was read again from the database root file.
85.4 – objects_modified_field
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
85.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
85.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
86 – Object objects fetch shrd screen
86.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
86.2 – FILID object field
This field displays the storage area information.
86.3 – SEQBLK object field
This field displays the information on the allocation of sequence
numbers such as transaction sequence numbers (TSNs) and commit
sequence numbers (CSNs).
86.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
86.5 – AIJDB object field
This field displays the AIJ control information.
86.6 – AIJFB object field
This field displays the AIJ journal information.
86.7 – RTUPB object field
This field displays information on active users.
86.8 – ACTIVE object field
This field displays information on active transactions.
86.9 – CPT object field
This field displays information on the corrupt page table.
86.10 – RCACHE object field
This field displays information on row caches.
86.11 – CLIENT object field
This field displays client-specific information.
86.12 – CLTSEQ object field
This field displays client sequence information.
86.13 – UTILITY object field
This field displays RMU utility information.
87 – Object objects fetch excl screen
87.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
87.2 – FILID object field
This field displays the storage area information.
87.3 – SEQBLK object field
This field displays the information on the allocation of sequence
numbers such as transaction sequence numbers (TSNs) and commit
sequence numbers (CSNs).
87.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
87.5 – AIJDB object field
This field displays the AIJ control information.
87.6 – AIJFB object field
This field displays the AIJ journal information.
87.7 – RTUPB object field
This field displays information on active users.
87.8 – ACTIVE object field
This field displays information on active transactions.
87.9 – CPT object field
This field displays information on the corrupt page table.
87.10 – RCACHE object field
This field displays information on row caches.
87.11 – CLIENT object field
This field displays client-specific information.
87.12 – CLTSEQ object field
This field displays client sequence information.
87.13 – UTILITY object field
This field displays RMU utility information.
88 – Object objects refreshed screen
88.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
88.2 – FILID object field
This field displays the storage area information.
88.3 – SEQBLK object field
This field displays the information on the allocation of sequence
numbers such as transaction sequence numbers (TSNs) and commit
sequence numbers (CSNs).
88.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
88.5 – AIJDB object field
This field displays the AIJ control information.
88.6 – AIJFB object field
This field displays the AIJ journal information.
88.7 – RTUPB object field
This field displays information on active users.
88.8 – ACTIVE object field
This field displays information on active transactions.
88.9 – CPT object field
This field displays information on the corrupt page table.
88.10 – RCACHE object field
This field displays information on row caches.
88.11 – CLIENT object field
This field displays client-specific information.
88.12 – CLTSEQ object field
This field displays client sequence information.
88.13 – UTILITY object field
This field displays RMU utility information.
89 – Object objects modified screen
89.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
89.2 – FILID object field
This field displays the storage area information.
89.3 – SEQBLK object field
This field displays the information on the allocation of sequence
numbers such as transaction sequence numbers (TSNs) and commit
sequence numbers (CSNs).
89.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
89.5 – AIJDB object field
This field displays the AIJ control information.
89.6 – AIJFB object field
This field displays the AIJ journal information.
89.7 – RTUPB object field
This field displays information on active users.
89.8 – ACTIVE object field
This field displays information on active transactions.
89.9 – CPT object field
This field displays information on the corrupt page table.
89.10 – RCACHE object field
This field displays information on row caches.
89.11 – CLIENT object field
This field displays client-specific information.
89.12 – CLTSEQ object field
This field displays client sequence information.
89.13 – UTILITY object field
This field displays RMU utility information.
90 – Object objects written screen
90.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
90.2 – FILID object field
This field displays the storage area information.
90.3 – SEQBLK object field
This field displays the information on the allocation of sequence
numbers such as transaction sequence numbers (TSNs) and commit
sequence numbers (CSNs).
90.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
90.5 – AIJDB object field
This field displays the AIJ control information.
90.6 – AIJFB object field
This field displays the AIJ journal information.
90.7 – RTUPB object field
This field displays information on active users.
90.8 – ACTIVE object field
This field displays information on active transactions.
90.9 – CPT object field
This field displays information on the corrupt page table.
90.10 – RCACHE object field
This field displays information on row caches.
90.11 – CLIENT object field
This field displays client-specific information.
90.12 – CLTSEQ object field
This field displays client sequence information.
90.13 – UTILITY object field
This field displays RMU utility information.
91 – Object objects released screen
91.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
91.2 – FILID object field
This field displays the storage area information.
91.3 – SEQBLK object field
This field displays the information on the allocation of sequence
numbers such as transaction sequence numbers (TSNs) and commit
sequence numbers (CSNs).
91.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
91.5 – AIJDB object field
This field displays the AIJ control information.
91.6 – AIJFB object field
This field displays the AIJ journal information.
91.7 – RTUPB object field
This field displays information on active users.
91.8 – ACTIVE object field
This field displays information on active transactions.
91.9 – CPT object field
This field displays information on the corrupt page table.
91.10 – RCACHE object field
This field displays information on row caches.
91.11 – CLIENT object field
This field displays client-specific information.
91.12 – CLTSEQ object field
This field displays client sequence information.
91.13 – UTILITY object field
This field displays RMU utility information.
92 – IO_DASHBOARD_SCREEN
92.1 – Buffer Count field
This field displays the default buffer count used by database
processes.
92.2 – APF Enabled field
This field indicates whether asynchronous prefetch operations are
enabled. The default value 1 indicates that asynchronous prefetch
operations are enabled and the value 0 indicates that they are
disabled. You can override the default value with the RDM$BIND_
APF_ENABLED logical name.
92.3 – APF Depth field
This field displays the asynchronous pre-fetch depth setting. You
can override the default value of 5 buffers with the RDM$BIND_
APF_DEPTH logical name.
92.4 – DAPF Enabled field
This field indicates whether detected asynchronous prefetch
operations are enabled. The default value 1 indicates that
detected asynchronous prefetch operations are enabled and the
value 0 indicates that they are disabled. You can override the
default value with the RDM$BIND_DAPF_ENABLED logical name.
92.5 – DAPF Depth Count field
This field displays the detected asynchronous pre-fetch depth
count setting.
92.6 – DAPF Start Count field
This field displays the detected asynchronous pre-fetch start
count.
92.7 – ABW Enabled field
This field indicates whether asynchronous batch write operations
are enabled. The default value 1 indicates that asynchronous
batch write operations are enabled and the value 0 indicates that
they are disabled. You can override the default value with the
RDM$BIND_ABW_ENABLED logical name.
92.8 – ABW Clean BufCount field
This field displays the asynchronous batch write clean buffer
count setting. You can override the default value of 5 buffers
with the RDM$BIND_CLEAN_BUF_CNT logical name.
92.9 – ABW Batch Max field
This field displays the asynchronous batch write maximum batch
size setting.
93 – locking DASHBOARD screen
93.1 – Lock Timeout Intvl field
This field displays the number of seconds for a process to wait
during a lock conflict before timing out. The default value is
2147483647 seconds. You can override the default value with the
RDM$BIND_LOCK_TIMEOUT_INTERVAL logical name.
93.2 – Ready AreaSerially field
This field indicates whether Oracle Rdb grants lock requests for
logical and physical areas in the order that the lock requests
were made. The default value 0 indicates that lock requests are
not granted serially. You can override the default value with the
RDM$BIND_READY_AREA_SERIALLY logical name.
93.3 – Snap Quiet Point field
This field indicates whether the snapshot locks acquire a quiet-
point lock. The default value 1 indicates that a quiet-point
lock is acquired and the value 0 indicates that a quiet-point
lock is not required. You can override the default value with the
RDM$BIND_SNAP_QUIET_POINT logical name.
93.4 – Hold Retrvl Locks field
This field indicates whether hold retrieval locks are enabled.
The default value 0 indicates that hold retrieval locks are
disabled and the value 1 indicates that they are enabled. You can
override the default value with the RDM$BIND_HRL_ENABLED logical
name.
93.5 – Coarse Buf Lockng field
This field indicates whether coarse buffer locking is enabled.
The default value 0 indicates that coarse buffer locking is
disabled and the value 1 indicates that it is enabled. You can
override the default value with the RDM$BIND_CBL_ENABLED logical
name.
94 – AIJ DASHBOARD screen
94.1 – Min IO Blocks field
This field displays the minimum AIJ group commit I/O buffer size,
in blocks. The default value is 8 blocks. You can override the
default value with the RDM$BIND_AIJ_IO_MIN logical name.
94.2 – Max IO Blocks field
This field displays the maximum AIJ group commit I/O buffer size,
in blocks. The default value is 127 blocks. You can override the
default value with the RDM$BIND_AIJ_IO_MAX logical name.
94.3 – AIJ Stall Interval field
This field displays the AIJ group commit stall time, in
milliseconds. The stall time permits a larger number of
transactions in the group commit operation. You can override
the default value with the RDM$BIND_AIJ_STALL logical name.
94.4 – Root Stall Intervl field
This field displays the TSNBLK group commit stall time, in
milliseconds. You can override the default value with the
RDM$BIND_COMMIT_STALL logical name.
94.5 – Switch Global Ckpt field
This field indicates whether to perform a global checkpoint after
an AIJ switch-over has occurred. The default value 1 indicates
that a global checkpoint will be performed and the value 0
indicates that a global checkpoint will not be performed. You can
override the default value with the RDM$BIND_AIJ_SWITCH_GLOBAL_
CKPT logical name.
94.6 – Check Control Recs field
This field indicates whether to check for control records during
AIJ cache formatting. The default value 1 indicates that Oracle
Rdb will check for control records and the value 0 indicates
that Oracle Rdb will not check for control records. You can
override the default value with the RDM$BIND_AIJ_CHECK_CONTROL_
RECS logical name.
94.7 – Cache Shuffle Dsbl field
This field indicates whether or not the group commit buffer
"cache shuffle" mechanism is disabled. The default value "0"
indicates that the cache shuffle mechanism is enabled, and the
value "1" indicates that the cache shuffle mechanism is disabled.
You can override the default value with the RDM$BIND_AIJ_SHUFFLE_
DISABLED logical name.
94.8 – ARB Count field
This field displays the number of after-image journal request
blocks (ARBs) that are in use for the database.
95 – Checkpoint DASHBOARD screen
95.1 – Ckpt Blocks field
This field indicates the number of AIJ blocks after which a
checkpoint will occur. The default value is 0 blocks. You can
override the default value with the RDM$BIND_CKPT_BLOCKS logical
name.
95.2 – Ckpt Time Interval field
This field indicates the amount of time, in seconds, after which
a checkpoint will occur. The default value is 0. You can override
the default value with the RDM$BIND_CKPT_TIME logical name.
95.3 – Ckpt Tx Interval field
This field indicates the number of committed transactions
after which a checkpoint will occur. By default, if you have
fast commit processing enabled, a process checkpoints when the
AIJ block size limit is reached or the time interval limit is
exceeded, whichever occurs first. You can specify the number of
transactions as the checkpoint trigger by defining the RDM$BIND_
CKPT_TRANS_INTERVAL logical name.
95.4 – CTJ Tx Interval field
This field indicates the number of transactions to be allocated
as a single batch when the commit to journal optimization feature
is enabled. You can specify the number of transactions to be
allocated by defining the RDM$BIND_TSN_INTERVAL logical name.
95.5 – RW Tx Ckpt Advance field
This field whether or not read/write transactions that modified
no data are eligable to checkpoint when the transaction commits.
The default value "0"indicates that such transactions do not
evaluate checkpointing when they commit, and the value "1"
idicates that they will. You can override the default value with
the RDM$BIND_RW_TX_CHECKPOINT_ADVANCE logical name.
96 – Hot standby DASHBOARD screen
96.1 – Network Timeout field
This field displays the amount of time, in seconds, after which
the Hot Standby network times out. The default is 120 seconds.
You can override the default with the RDM$BIND_HOT_NETWORK_
TIMEOUT logical name.
96.2 – Connect Timeout field
This field displays the amount of time, in minutes, to wait for
the connection to be made between the master and the standby
database. The default is 5 minutes. You can override the default
with the RDM$BIND_LCS_CONNECT_TIMEOUT logical name.
96.3 – Sync Commit Freq field
This field displays the Log Catch-up Server (LCS) process message
synchronization count, expressed as the number of messages after
which the LCS waits for the Log Rollforward Server (LRS) process
on the standby database to finish processing all previously
transmitted messages. The default is 64 messages. You can
override the default value with the RDM$BIND_LCS_SYNC_COMMIT_
MAX logical name.
96.4 – Data Sync Mode field
This field displays the current database synchronization mode.
0 = cold 1 = warm 2 = hot 3 = commit
You can override the default with the RDM$BIND_HOT_DATA_SYNC_MODE
logical name.
96.5 – Server Checkpoint field
This field displays the number of messages per server checkpoint
interval. The default is 100 messages. You can override the
default with the RDM$BIND_HOT_CHECKPOINT logical name.
96.6 – LCS Reopen Log Sec field
This field displays the amount of time, in seconds, that the LCS
process will wait before attempting to automatically reopen its
log file.
96.7 – LCS Reopen Log Siz field
This field displays the maximum file size that the LCS process
log file is allowed to grow before it is automatically reopened.
96.8 – Gap Timeout field
This field displays the amount of time, in minutes, to wait for
stalled MSN (gap) resolution. The default is 5 minutes. You can
override the default value with the RDM$BIND_LRS_GAP_TIMEOUT
logical name.
96.9 – Commit Queue Min field
This field displays the minimum number of committed transactions
the Log Rollforward Server (LRS) process on the standby database
will process in a single batch. Decreasing this value may cause
asynchronous pre-fetch stalls; increasing this value may cause
buffer turnover. The default is 10 transactions. You can override
the default value with the RDM$BIND_LRS_COMMIT_QUEUE_MIN logical
name.
96.10 – Commit Queue Cur field
This field displays the current number of committed transactions
the Log Rollforward Server (LRS) process on the standby database
will process in a single batch. This value dynamically floats
between the minimum and maximum dashboard values. The default
is 10 transactions. You can override the default value with the
RDM$BIND_LRS_COMMIT_QUEUE_CUR logical name.
96.11 – Commit Queue Max field
This field displays the maximum number of committed transactions
the Log Rollforward Server (LRS) process on the standby database
will process in a single batch. Decreasing this value may cause
asynchronous pre-fetch stalls; increasing this value may cause
buffer turnover. The default is 500 transactions. You can
override the default value with the RDM$BIND_LRS_COMMIT_QUEUE_
MAX logical name.
96.12 – Governor Enabled field
This field indicates whether the governor is enabled. The default
value 1 indicates that the governor is enabled and the value 0
indicates that it is disabled. You can override the default value
with the RDM$BIND_LRS_GOVERNOR_ENABLED logical name.
96.13 – LRS Reopen Log Sec field
This field displays the amount of time, in seconds, that the LRS
process will wait before attempting to automatically reopen its
log file.
96.14 – LRS Reopen Log Siz field
This field displays the maximum file size that the LRS process
log file is allowed to grow before it is automatically reopened.
96.15 – Suspend ABS field
This field indicates whether the ABS process is suspended as
a result of a Hot Standby (replication) failure. The default
value 1 indicates that the ABS process is suspended and the
value 0 indicates that the ABS process is not suspended. You
can override the default value with the RDM$BIND_HOT_ABS_SUSPEND
logical name.
97 – Row Cache DASHBOARD screen
97.1 – Insert Enabled field
This field indicates whether or not rows can be inserted into
the row cache. The default value 1 indicates that rows can be
inserted into the cache and the value 0 indicates that rows
cannot be inserted into the cache. You can override the default
value with the RDM$BIND_RCACHE_INSERT_ENABLED logical name.
97.2 – RCRL Count field
This field displays the number of reserved row cache slots. You
can override the default value of 20 slots with the RDM$BIND_
RCACHE_RCRL_COUNT logical name.
97.3 – Latch Spin Count field
This field indicates the number of times a process trying to
acquire a latch should spin before hibernating.
98 – ruj DASHBOARD screen
98.1 – RUJ Alloc Blocks field
This field indicates the number of blocks the .ruj file is
created with. The default value is 127 blocks. You can override
the default value with the RDM$BIND_RUJ_ALLOC_BLKCNT logical
name.
98.2 – RUJ Extend Blocks field
This field indicates the number of blocks the .ruj file is
extended by. The default value is 127 blocks. You can override
the default value with the RDM$BIND_RUJ_EXTEND_BLKCNT logical
name.
99 – Monitor DASHBOARD screen
99.1 – Max DBR Count field
This field displays the maximum number of database recovery (DBR)
processes that will be invoked following node failure. RDM$BIND_
MAX_DBR_COUNT logical name.
99.2 – ABS Priority field
This field displays the default priority that the detached ABS
process will be invoked with. You can initialize this field with
the RDM$BIND_ABS_PRIORITY logical name.
99.3 – ALS Priority field
This field displays the default priority that the detached ALS
process will be invoked with. You can initialize this field with
the RDM$BIND_ALS_PRIORITY logical name.
99.4 – DBR Priority field
This field displays the default priority that the detached DBR
server process will be invoked with. You can initialize this
field with the RDM$BIND_DBR_PRIORITY logical name.
99.5 – LCS Priority field
This field displays the default priority that the detached LCS
process will be invoked with. You can initialize this field with
the RDM$BIND_LCS_PRIORITY logical name.
99.6 – LRS Priority field
This field displays the default priority that the detached LRS
server process will be invoked with. You can initialize this
field with the RDM$BIND_LRS_PRIORITY logical name.
99.7 – RCS Priority field
This field displays the default priority that the detached
row cache server (RCS) process will be invoked with. You can
initialize this field with the RDM$BIND_RCS_PRIORITY logical
name.
100 – ABS DASHBOARD screen
100.1 – Quiet Point field
This field indicates whether the after-image journal backup
server (ABS) will perform a quiet-point after-image journal
backup.
The default value 0 indicates that a no-quiet-point backup will
be performed while 1 indicates that a quiet-point backup will be
performed. You can override the default value with the RDM$BIND_
ABS_QUIET_POINT logical name.
100.2 – Overwrite Allowed field
This field indicates whether the after-image journal backup
server (ABS) is allowed to reset overwritten AIJ journals.
The default value 0 indicates that the ABS cannot reset
overwritten journals while the value 1 indicates that the ABS
can reset overwritten journals. You can override the default
value with the RDM$BIND_ABS_OVERWRITE_ALLOWED logical name.
100.3 – OverwriteImmediate field
This field indicates whether journals should be immediately reset
if RDM$BIND_ABS_OVERWRITE_ALLOWED is enabled.
The default value 0 indicates that AIJ journals should not be
immediately reset. The value 1 indicates that AIJ journals should
be immediately reset depending on the value of the RDM$BIND_ABS_
OVERWRITE_ALLOWED logical name.
You can override the default value with the RDM$BIND_ABS_
OVERWRITE_IMMEDIATE logical name.
101 – ALS DASHBOARD screen
101.1 – AIJ Hiber Time field
This field displays the amount of time (in hundredths of a
second) that processes have spent hibernating while the AIJ log
server processes their requests.
101.2 – Switch Global Ckpt field
This field indicates whether to perform a global checkpoint after
an AIJ switch-over has occurred. The default value 1 indicates
that a global checkpoint will be performed and the value 0
indicates that a global checkpoint will not be performed. You can
override the default value with the RDM$BIND_AIJ_SWITCH_GLOBAL_
CKPT logical name.
101.3 – Check Control Recs field
This field indicates whether to check for control records during
AIJ cache formatting. The default value 1 indicates that Oracle
Rdb will check for control records and the value 0 indicates
that Oracle Rdb will not check for control records. You can
override the default value with the RDM$BIND_AIJ_CHECK_CONTROL_
RECS logical name.
101.4 – Emergency AIJ field
This field indicates whether the ALS process creates an emergency
AIJ journal if the AIJ switch-over operation enters the suspended
state. The default value 0 indicates that the creation of
emergency journals is disabled and the value 1 indicates that it
is enabled. You can override the default value with the RDM$BIND_
ALS_CREATE_AIJ logical name.
101.5 – ALS Log Reopen Sec field
This field displays the amount of time, in seconds, that the ALS
process will wait before attempting to automatically reopen its
log file.
101.6 – ALS Log Reopen Siz field
This field displays the maximum file size that the ALS process
log file is allowed to grow before it is automatically reopened.
102 – DBR DASHBOARD screen
102.1 – Buffer Count field
This field displays the default buffer count used by database
processes. You can initialize this field with the RDM$BIND_DBR_
BUFFER_CNT logical name.
103 – RCS DASHBOARD screen
103.1 – Ckpt Buffer Count field
This field indicates the number of buffers to be examined as
a single batch by the row cache server (RCS) process during a
checkpoint operation. You can override the default value of 15
buffers with the RDM$BIND_RCS_CKPT_BUFFER_CNT logical name.
103.2 – Batch Count field
This field displays the number of rows to be flushed to disk.
103.3 – Checkpoint field
This field indicates whether the row cache server (RCS) performs
a checkpoint. The default value 1 indicates a checkpoint is
performed and the value 0 indicates that a checkpoint is not
performed. You can override the default value with the RDM$BIND_
RCS_CHECKPOINT logical name.
103.4 – Ckpt Time Interval field
This field indicates the amount of time, in seconds, after which
a checkpoint will occur. The default value is 0. You can override
the default value with the RDM$BIND_CKPT_TIME logical name.
103.5 – Sweep Interval field
This field indicates the amount of time, in minutes between
sweeps. The default sweep interval is 1 minute. You can override
the default value with the RDM$BIND_RCS_SWEEP_INTERVAL logical
name.
103.6 – Low Cold Thshld field
This field indicates the number of unmarked records below which
the row cache server (RCS) sweep completes. You can override the
default value with the RDM$BIND_RCS_MIN_COLD logical name.
103.7 – High Cold Thshld field
This field indicates the number of marked records above which the
row cache server (RCS) sweep starts. You can override the default
value with the RDM$BIND_RCS_MAX_COLD logical name.
103.8 – Cold Record Count field
This field displays the number of unmodified rows in the row
cache.
103.9 – Abort Sweep field
This field indicates whether the sweep should be aborted. The
default value 0 indicates that the sweep should be continued and
the value 1 indicates that the sweep should be aborted.
104 – Per process i o DASHBOARD screen
104.1 – Buffer Count field
This field displays the actual buffer count used by database
processes. Updating this field has no effect on the process since
you cannot dynamically change the number of buffers.
104.2 – APF Enabled field
This field indicates whether asynchronous prefetch operations are
enabled. The default value 1 indicates that asynchronous prefetch
operations are enabled and the value 0 indicates that they are
disabled. You can override the default value with the RDM$BIND_
APF_ENABLED logical name.
104.3 – APF Depth field
This field displays the asynchronous prefetch depth setting. You
can override the default value of 5 buffers with the RDM$BIND_
APF_DEPTH logical name.
104.4 – DAPF Enabled field
This field indicates whether detected asynchronous prefetch
operations are enabled. The default value 1 indicates that
detected asynchronous prefetch operations are enabled and the
value 0 indicates that they are disabled. You can override the
default value with the RDM$BIND_DAPF_ENABLED logical name.
104.5 – DAPF Depth Count field
This field displays the detected asynchronous prefetch depth
setting.
104.6 – DAPF Start Count field
This field displays the detected asynchronous prefetch start
count.
104.7 – ABW Enabled field
This field indicates whether asynchronous batch write operations
are enabled. The default value 1 indicates that asynchronous
batch write operations are enabled and the value 0 indicates that
they are disabled. You can override the default value with the
RDM$BIND_ABW_ENABLED logical name.
104.8 – ABW Clean BufCount field
This field displays the asynchronous batch write clean buffer
count setting. You can override the default value of 5 buffers
with the RDM$BIND_CLEAN_BUF_CNT logical name.
104.9 – ABW Batch Max field
This field displays the asynchronous batch write maximum batch
size setting.
104.10 – Lock Timeout Intvl field
This field displays the number of seconds for a process to wait
during a lock conflict before timing out. The default value is
2147483647 seconds. You can override the default value with the
RDM$BIND_LOCK_TIMEOUT_INTERVAL logical name.
104.11 – Ready AreaSerially field
This field indicates whether Oracle Rdb grants lock requests for
logical and physical areas in the order that the lock requests
were made. The default value 0 indicates that lock requests are
not granted serially. You can override the default value with the
RDM$BIND_READY_AREA_SERIALLY logical name.
104.12 – Snap Quiet Point field
This field indicates whether the snapshot locks acquire a quiet-
point lock. The default value 1 indicates that a quiet-point
lock is acquired and the value 0 indicates that a quiet-point
lock is not required. You can override the default value with the
RDM$BIND_SNAP_QUIET_POINT logical name.
104.13 – Hold Retrvl Locks field
This field indicates whether hold retrieval locks are enabled.
The default value 0 indicates that hold retrieval locks are
disabled and the value 1 indicates that they are enabled. You can
override the default value with the RDM$BIND_HRL_ENABLED logical
name.
104.14 – Coarse Buf Lockng field
This field indicates whether coarse buffer locking is enabled.
The default value 0 indicates that coarse buffer locking is
disabled and the value 1 indicates that it is enabled. You can
override the default value with the RDM$BIND_CBL_ENABLED logical
name.
105 – Per process JOURNAL DASHBOARD screen
105.1 – Min AIJ IO Bytes field
This field displays the minimum AIJ group commit I/O buffer size,
in bytes. The default value is 4096 bytes. You can override the
default value with the RDM$BIND_AIJ_IO_MIN logical name.
105.2 – Max AIJ IO Bytes field
This field displays the maximum AIJ group commit I/O buffer size,
in bytes. The default value is 65024 blocks. You can override the
default value with the RDM$BIND_AIJ_IO_MAX logical name.
105.3 – AIJ Stall Interval field
This field displays the AIJ group commit stall time, in
milliseconds.
105.4 – Root Stall Intervl field
This field displays the TSNBLK group commit stall time, in
milliseconds. You can override the default value with the
RDM$BIND_COMMIT_STALL logical name.
105.5 – Switch Global Ckpt field
This field indicates whether to perform a global checkpoint after
an AIJ switch-over has occurred. The default value 1 indicates
that a global checkpoint will be performed and the value 0
indicates that a global checkpoint will not be performed. You can
override the default value with the RDM$BIND_AIJ_SWITCH_GLOBAL_
CKPT logical name.
105.6 – Check Control Recs field
This field indicates whether to check for control records during
AIJ cache formatting. The default value 1 indicates that Oracle
Rdb will check for control records and the value 0 indicates
that Oracle Rdb will not check for control records. You can
override the default value with the RDM$BIND_AIJ_CHECK_CONTROL_
RECS logical name.
105.7 – Ckpt Blocks field
This field indicates the number of AIJ blocks after which a
checkpoint will occur. The default value is 0 blocks. You can
override the default value with the RDM$BIND_CKPT_BLOCKS logical
name.
105.8 – Ckpt Time Interval field
This field indicates the amount of time, in seconds, after which
a checkpoint will occur. The default value is 0. You can override
the default value with the RDM$BIND_CKPT_TIME logical name.
105.9 – Ckpt Tx Interval field
This field indicates the number of committed transactions
after which a checkpoint will occur. By default, if you have
fast commit processing enabled, a process checkpoints when the
AIJ block size limit is reached or the time interval limit is
exceeded, whichever occurs first. You can specify the number of
transactions as the checkpoint trigger by defining the RDM$BIND_
CKPT_TRANS_INTERVAL logical name.
105.10 – CTJ TX Interval field
This field indicates the number of transactions to be allocated
as a single batch when the commit to journal optimization feature
is enabled. You can specify the number of transactions to be
allocated by defining the RDM$BIND_TSN_INTERVAL logical name.
105.11 – RW Tx Ckpt Advance field
This field whether or not read/write transactions that modified
no data are eligable to checkpoint when the transaction commits.
The default value "0"indicates that such transactions do not
evaluate checkpointing when they commit, and the value "1"
idicates that they will. You can override the default value with
the RDM$BIND_RW_TX_CHECKPOINT_ADVANCE logical name.
105.12 – RUJ Alloc Blocks field
This field indicates the number of blocks the .ruj file is
created with. The default value is 127 blocks. You can override
the default value with the RDM$BIND_RUJ_ALLOC_BLKCNT logical
name.
105.13 – RUJ Extend Blocks field
This field indicates the number of blocks the .ruj file is
extended by. The default value is 127 blocks. You can override
the default value with the RDM$BIND_RUJ_EXTEND_BLKCNT logical
name.
106 – Per Process Row Cache DASHBOARD screen
106.1 – Insert Enabled field
This field indicates whether or not rows can be inserted into
the row cache. The default value 1 indicates that rows can be
inserted into the cache and the value 0 indicates that rows
cannot be inserted into the cache. You can override the default
value with the RDM$BIND_RCACHE_INSERT_ENABLED logical name.
106.2 – RCRL Count field
This field displays the number of reserved row cache slots. You
can override the default value of 20 slots with the RDM$BIND_
RCACHE_RCRL_COUNT logical name.
106.3 – Latch Spin Count field
This field indicates the number of times a process trying to
acquire a latch should spin before hibernating.