1 – Keyboard
[A]larm - specify a duration that a process must stall
before it appears on the Stall Messages screen
[B]ell - activates or deactivates the alarm bell
[B]rief - select brief display
[C]onfig - configure the statistics screen
[E]xit - exit the Performance Monitor
[F]ilter - filter stall messages
[F]ull - select full display
[G]raph - display a histogram graph
[H]elp - display help
[I]nput - displays the Select Input Control menu
[L]ockID - display submenu of lock IDs
[M]enu - display main menu
[N]ormal - puts you back into the normal screen display
[N]umbers - display numeric statistics
[O]ptions - display report options
[P]ause - pause the display
[P]ageInfo - display page information
[R]efresh - refreshes the screen
[R]eset - reset the statistics
[S]et_rate - set the display update rate
[S]tep - advances by one record in the input file while
in paused mode
[T]ime_plot- plot field's value by time
[U]nreset - reverse effect of Reset option
[U]pdate - change the value of a database attribute
[W]rite - write the screen to rmu.scr
[X]_plot - plot rate of current field
[Y]ank - select statistics field
[Z]oom - display detailed information about a specific item
! - invoke tools facility
$ - invoke DCL command facility
# - display submenu for current screen
+ - advance 'n' screens forward
- - advance 'n' screens backward
? - display help
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<help> or <PF2> - display help
<up-arrow> or <down-arrow> - highlight a menu option
<return>, <enter> or <select> - select a menu option
<control-W> - repaint the screen
<control-Z> - cancel a menu or return to DCL
<prev-screen> or <left-arrow> - move to previous display
<next-screen> or <right-arrow> - move to next display
spacebar - advance to next display
containing database activity
2 – Screens
2.1 – Summary IO Statistics screen
This screen summarizes database I/O activity and indicates
transaction and verb execution rates.
2.2 – Summary Locking Statistics screen
This screen monitors the total database locking activity.
The statistics in this screen are the totals for all types of
database locks.
2.3 – Summary Object Statistics screen
This screen provides cumulative information for all database root
file objects.
2.4 – Summary Cache Statistics screen
This screen provides cumulative information for all row caches in
the database.
The Summary Cache Statistics screen is recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is available when you replay a binary file using the
Input qualifier.
2.5 – Summary Cache Unmark Statistics screen
This screen provides row cache "unmark" statistics which describe
how rows in the row caches are written back to disk.
The Summary Cache Unmark Statistics screen is recorded in
the binary output file produced using the Output qualifier.
Consequently, this screen is available when you replay a binary
file using the Input qualifier.
2.6 – Summary Tx Statistics screen
This screen summarizes database transaction activity and
indicates transaction and verb execution rates.
2.7 – Record Statistics screen
This screen shows a summary of data row activity for storage
areas in the database. Data row activity includes modification
(marked), retrieval (fetch), store, or erase operations.
2.8 – Transaction Duration Total screen
You can view the Transaction Duration screen either graphically
or numerically. The default display presents a graph. Choose the
Numbers option by typing N to change the display from graph to
numbers. When in the numeric display, choose the Graph option by
typing G to change to the graphical display.
The Graph option of this screen presents a graph that indicates
the overall real-time processing performance of the database.
It shows the transaction rate (number per second, by default)
and the time required to complete transactions. The duration of
each transaction is measured from the first SQL SET TRANSACTION
statement to the completion of the COMMIT or ROLLBACK verb. In
addition to displaying average transaction duration, this screen
shows a graph of the transaction durations. As each transaction
completes, it is added to the cumulative histogram display. The
95 percentile response time is continuously updated to show the
time in which 95 percent or more of the transactions complete.
The screen gives an indication of subjective system response
time.
The Numbers option of this screen provides the exact number of
transactions in each of the 16 time categories. The numeric
display also shows the number of transactions that completed
and the number of transactions that did not complete within each
time category.
The information in the numeric version of the Transaction
Duration screen includes:
o Total transaction count
This is the total number of transactions represented by the
information on the screen. Reset the number of transactions
with the Reset option by typing R.
o Duration
This column contains the transaction duration categories.
For the short-duration transaction display, the format n-<m
means that each category includes transactions of n seconds to
less than but not including m seconds.
For the long-duration transaction display, the format n-<m
means that each category includes transactions of n minutes to
less than but not including m minutes.
o Tx.Count, %
The Tx. Count column contains the number of transactions in
each transaction duration category. The % column shows the
percentage of the total transactions in each transaction
duration category.
o #Complete, %
The #Complete column contains the total number of transactions
that completed by the end of the the time specified by
each transaction duration category. The % column shows the
percentage of the total transactions that completed by the end
of the time specified by each transaction duration category.
o #Incomplete, %
The #Incomplete column contains the total number of
transactions that did not complete before the end of the
time specified by each transaction duration category. The %
column shows the percentage of the total transactions that
did not complete before the end of the time specified by each
transaction duration category.
The Complete % and Incomplete % should always add up to 100%
for each transaction duration category.
o <- average
The <- average indicator on the right side of the screen
points to the transaction duration category that contains
the average transaction duration time. This indicator changes
at runtime to maintain an accurate indication of the average
transaction duration time.
You can use the Config menu option to configure the Transaction
Duration screen. Select this option, by typing the letter C,
to display the configuration submenu. The configuration submenu
provides the following options:
o Total transaction duration
Displays read-only and read/write transactions
o Read/Write transaction duration
Displays read/write transactions
o Read-Only transaction duration
Displays read-only transactions
o XXX duration transaction display
Displays either the short or long duration transaction
display. The option description changes depending on which
duration is currently being displayed.
If you collect statistics in an output file using the Output
qualifier for the RMU Show Statistics command, you can replay the
Transaction Duration screen by using the Input qualifier.
2.9 – Transaction Duration Read Write screen
You can view the Transaction Duration screen either graphically
or numerically. The default display presents a graph. Choose the
Numbers option by typing N to change the display from graph to
numbers. When in the numeric display, choose the Graph option by
typing G to change to the graphical display.
The Graph option of this screen presents a graph that indicates
the overall real-time processing performance of the database.
It shows the transaction rate (number per second, by default)
and the time required to complete transactions. The duration of
each transaction is measured from the first SQL SET TRANSACTION
statement to the completion of the COMMIT or ROLLBACK verb. In
addition to displaying average transaction duration, this screen
shows a graph of the transaction durations. As each transaction
completes, it is added to the cumulative histogram display. The
95 percentile response time is continuously updated to show the
time in which 95 percent or more of the transactions complete.
The screen gives an indication of subjective system response
time.
The Numbers option of this screen provides the exact number of
transactions in each of the 16 time categories. The numeric
display also shows the number of transactions that completed
and the number of transactions that did not complete within each
time category.
The information in the numeric version of the Transaction
Duration screen includes:
o Total transaction count
This is the total number of transactions represented by the
information on the screen. Reset the number of transactions
with the Reset option by typing R.
o Duration
This column contains the transaction duration categories.
For the short-duration transaction display, the format n-<m
means that each category includes transactions of n seconds to
less than but not including m seconds.
For the long-duration transaction display, the format n-<m
means that each category includes transactions of n minutes to
less than but not including m minutes.
o Tx.Count, %
The Tx. Count column contains the number of transactions in
each transaction duration category. The % column shows the
percentage of the total transactions in each transaction
duration category.
o #Complete, %
The #Complete column contains the total number of transactions
that completed by the end of the the time specified by
each transaction duration category. The % column shows the
percentage of the total transactions that completed by the end
of the time specified by each transaction duration category.
o #Incomplete, %
The #Incomplete column contains the total number of
transactions that did not complete before the end of the
time specified by each transaction duration category. The %
column shows the percentage of the total transactions that
did not complete before the end of the time specified by each
transaction duration category.
The Complete % and Incomplete % should always add up to 100%
for each transaction duration category.
o <- average
The <- average indicator on the right side of the screen
points to the transaction duration category that contains
the average transaction duration time. This indicator changes
at runtime to maintain an accurate indication of the average
transaction duration time.
You can use the Config menu option to configure the Transaction
Duration screen. Select this option, by typing the letter C,
to display the configuration submenu. The configuration submenu
provides the following options:
o Total transaction duration
Displays read-only and read/write transactions
o Read/Write transaction duration
Displays read/write transactions
o Read-Only transaction duration
Displays read-only transactions
o XXX duration transaction display
Displays either the short or long duration transaction
display. The option description changes depending on which
duration is currently being displayed.
If you collect statistics in an output file using the Output
qualifier for the RMU Show Statistics command, you can replay the
Transaction Duration screen by using the Input qualifier.
2.10 – Transaction Duration Read Only screen
You can view the Transaction Duration screen either graphically
or numerically. The default display presents a graph. Choose the
Numbers option by typing N to change the display from graph to
numbers. When in the numeric display, choose the Graph option by
typing G to change to the graphical display.
The Graph option of this screen presents a graph that indicates
the overall real-time processing performance of the database.
It shows the transaction rate (number per second, by default)
and the time required to complete transactions. The duration of
each transaction is measured from the first SQL SET TRANSACTION
statement to the completion of the COMMIT or ROLLBACK verb. In
addition to displaying average transaction duration, this screen
shows a graph of the transaction durations. As each transaction
completes, it is added to the cumulative histogram display. The
95 percentile response time is continuously updated to show the
time in which 95 percent or more of the transactions complete.
The screen gives an indication of subjective system response
time.
The Numbers option of this screen provides the exact number of
transactions in each of the 16 time categories. The numeric
display also shows the number of transactions that completed
and the number of transactions that did not complete within each
time category.
The information in the numeric version of the Transaction
Duration screen includes:
o Total transaction count
This is the total number of transactions represented by the
information on the screen. Reset the number of transactions
with the Reset option by typing R.
o Duration
This column contains the transaction duration categories.
For the short-duration transaction display, the format n-<m
means that each category includes transactions of n seconds to
less than but not including m seconds.
For the long-duration transaction display, the format n-<m
means that each category includes transactions of n minutes to
less than but not including m minutes.
o Tx.Count, %
The Tx. Count column contains the number of transactions in
each transaction duration category. The % column shows the
percentage of the total transactions in each transaction
duration category.
o #Complete, %
The #Complete column contains the total number of transactions
that completed by the end of the the time specified by
each transaction duration category. The % column shows the
percentage of the total transactions that completed by the end
of the time specified by each transaction duration category.
o #Incomplete, %
The #Incomplete column contains the total number of
transactions that did not complete before the end of the
time specified by each transaction duration category. The %
column shows the percentage of the total transactions that
did not complete before the end of the time specified by each
transaction duration category.
The Complete % and Incomplete % should always add up to 100%
for each transaction duration category.
o <- average
The <- average indicator on the right side of the screen
points to the transaction duration category that contains
the average transaction duration time. This indicator changes
at runtime to maintain an accurate indication of the average
transaction duration time.
You can use the Config menu option to configure the Transaction
Duration screen. Select this option, by typing the letter C,
to display the configuration submenu. The configuration submenu
provides the following options:
o Total transaction duration
Displays read-only and read/write transactions
o Read/Write transaction duration
Displays read/write transactions
o Read-Only transaction duration
Displays read-only transactions
o XXX duration transaction display
Displays either the short or long duration transaction
display. The option description changes depending on which
duration is currently being displayed.
If you collect statistics in an output file using the Output
qualifier for the RMU Show Statistics command, you can replay the
Transaction Duration screen by using the Input qualifier.
2.11 – Custom Statistics screen
This screen shows a customized display of any of the base
statistics information (for example, non-by-area and non-per-
process statistics).
The size of your Custom Statistics display determines the number
of statistics fields you can add to the display. The header and
horizontal menu take up eight lines of the Custom Statistics
display; you can add a statistics field on each of the remaining
lines, up to a maximum of 36 different fields. Each statistics
field is placed on a separate line of the display.
The Custom Statistics screen is an ordinary screen; information
can be displayed graphically as a histogram or in numeric tabular
format. Also, the Time_plot and X_plot options are available for
any of the selected statistics fields.
Initially, the Custom Statistics screen contains two statistics:
database binds and transactions. These statistics can be moved,
removed, replaced, or annotated.
There are two different methods available to populate the Custom
Statistics display: fields can either be Yanked from an existing
statistics display and implicitly Put on the Custom Statistics
display or you can manually create a statistics field. Oracle
Corporation recommends using the Yank and Put method, which is
easier.
To Yank and Put a statistics field, use the Yank menu option on
the statistics display page containing the statistics field you
wish to select. The Yank menu option is not available in the
Custom Statistics display.
When you select the Yank option by pressing Y, a menu of the
selectable fields is displayed; this menu is similar to the Help
on fields menu. Select the letter of the statistics field you
want to yank and that field will automatically appear on the
Custom Statistics display. Note that once you select a particular
statistics field, you cannot select it again unless you first
delete it from the Custom Statistics display. This means that the
field selection menu changes every time you select a field.
The selected field will be positioned on the first available row
of the Custom Statistics display. You cannot specify the row of
the Custom Statistics display on which the field will be placed
using the Yank and Put method. However, once the field has been
put on the Custom Statistics display, you can change the position
of that field.
The Yank and Put menu will automatically be canceled when you
have selected all the available statistics field on any given
display or when there are no more fields available on the Custom
Statistics display.
For more advanced users, you can also manually create a
statistics field. On the Custom Statistics display, you can
use the Config menu option to explicitly enter the index of
the specific statistics field, numbered from 1 to 1020. These
indexes are documented in the text file SYS$LIBRARY:RMU$SHOW_
STATISTICS.CDO (if you have installed multiple versions of Oracle
Rdb on your system, the text file is named SYS$LIBRARY:RMU$SHOW_
STATISTICSvv.CDO, where vv is the Oracle Rdb software version).
When selecting statistics files manually, the keyboard will
beep if you specify the index of an existing statistics field.
However, no error message is displayed.
When you select the configuration menu by typing C on the Custom
Statistics screen, the configuration submenu will be displayed.
The configuration submenu allows you to add, delete, move,
annotate, and compress statistics fields on the Custom Statistics
screen. The configuration menu varies according to the state of
the Custom Statistics screen but typically all of the following
options are displayed:
o Add a statistics field
When you select the Add menu option, you are prompted to
select the screen position where you want to place the
statistics field, the index of the statistics field, and the
title of the statistics field. The title you specify is then
appended with the respective index, in brackets, to show which
statistics have been manually selected.
This option is extremely useful for tracking statistics values
that are not normally displayed. For instance, the statistics
field that tracks the total number of bytes of VM allocated
is not actually displayed by any Performance Monitor screen.
However, you can select index number 16 and the number of
bytes of VM allocated is displayed on the Custom Statistics
screen.
o Delete a statistics field
When you select the Delete menu option, you are prompted to
select the statistics field you wish to delete.
o Move a statistics field
When you select the Move menu option, you are prompted
to select the statistics field to be moved and the screen
position where the selected field will be displayed.
o Annotate a statistics field
When you select the Annotate configuration menu option,
you will be prompted to select the statistics field to be
annotated. You will then be prompted to enter a new name
for the selected statistics field. Once you have annotated
a statistic field name, you cannot retrieve the original name
unless you delete the statistic field and re-yank it on to the
Custom Statistics screen.
o Compress the display
Selecting the Compress menu option eliminates all intervening
blank lines on the screen. This option is particularly useful
after deleting one or more statistics fields.
2.12 – Snapshot Statistics screen
This screen shows snapshot activity for both update and read-only
transactions. The "retrieved record", "fetched line", and "read
snap page" statistics relate to read-only transactions, and the
last five statistics are relevant for update transactions.
2.13 – Stall Messages screen
This screen shows a summary of database users' stall activity.
A user stalls whenever Oracle Rdb issues a system call on behalf
of the user's process. For example, a stall occurs while a user
waits for a lock or for completion of a physical disk read or
write.
By default, the Stall Messages screen shows all stalls, including
those of millisecond duration. When a high-performance, high-
volume online transaction processing (OLTP) application issues a
large number of I/Os on a high-speed disk device, a DBA may find
it impossible to differentiate between the many short millisecond
stalls of the OLTP application and the longer, more important
stalls that may be encountered by other applications using the
database.
By typing A to select the Alarm option from the Stall Messages
horizontal menu, you can specify a duration, in seconds, that
a process must stall before it appears on the Stall Messages
screen. For example, if you specify an alarm interval of 5
seconds, then only stalls of 5 seconds or longer duration will
appear on the Stall Messages screen. If you specify a value of 0
as the alarm interval, the default, all stalls will appear on the
Stall Messages screen.
By typing B once to select the Bell option from the horizontal
menu, you can activate the alarm bell option and the option will
be highlighted. Entering B again will deactivate the alarm bell
and the option will not be highlighted.
The alarm bell, even if activated, will be rung only if the alarm
option has also been activated.
When both the alarm and the alarm bell are activated, the alarm
bell will be sounded once per screen refresh (specified by the
Set_rate option) if there are any displayed stalls.
By typing F to select the filter option, you can control the
type of stall messages that are displayed. For example, you can
display processes that are stalled while writing to a certain
storage area.
The filter option allows you to enter a search string which is
used to filter the stall messages. Only those stall messages that
contain the specified search string are displayed. The search
string may contain one or both of the wildcard characters. The
asterisk wildcard character is mapped to zero or more characters
and the percent wildcard character is mapped to exactly one
character. Note that the search string is not case sensitive.
The filter menu option is highlighted when a search string is
actively filtering stall messages. To disable filtering, press
the Return key at the search string prompt.
Stall messages are not saved in the binary statistics file
created by the Output qualifier. Consequently, the Stall Messages
screen is not available when you replay a binary file using the
Input qualifier.
This screen lists database user processes and describes the most
recent stalls executed by users on the node from which the Show
Statistics command was issued. Because the stall messages are
sampled only at the screen update interval, most stalls are
missed. If the same stall message for a process persists, it
could indicate a problem. The screen also shows when a process is
writing a bugcheck dump; a bugcheck dump file name longer than 53
characters is truncated.
The Stall Messages screen shows only processes that are actively
stalling. Once a process finishes stalling, it disappears from
the screen. Processes that are still stalling ripple up to the
top of the screen. This means that the longest stalling processes
appear at the top of the screen. Newer stalls are added to the
bottom of the screen. Therefore, all users on the same node
share the same stall screen lines, and only the actively stalling
processes show up on the stall screen. This allows you to monitor
a relatively large number of stalling processes.
If there are more stalled processes than can fit on one page, the
notation "Page 1 of n" appears, where n is the total number of
pages. You can display successive pages by pressing the right
angle bracket (>) key or the Next Screen key. To display a
previous stall message page, press the left angle bracket (<)
key or the Prev Screen key.
A database with no stalls has a blank stall display.
You can force frequent screen updates by using a negative number
for the Time qualifier in the RMU Show Statistics command. For
example, Time=-10 refreshes the screen every 10/100 (1/10) of a
second. Note that you use a lot of system resources, particularly
on the smaller CPU machines, when you specify this time interval.
If more stalls are in progress than can fit on your screen, some
active stalls might not be displayed. Oracle Rdb attempts to
place as many active stall messages on the screen as possible.
You can use the Config menu option to configure the Stall
Messages screen. Select this option, by typing the letter C,
to display the configuration submenu. The configuration submenu
provides the following options:
o Display XXX Stall Time
Display either the actual stall time or the elapsed stall
time. The option description changes depending on which stall
time is currently being displayed.
o Set alarm interval
Specify a duration, in seconds, that a process must stall
before it appears on the Stall Messages screen.
o XXX alarm bell
Activate or deactivate the alarm bell. The option description
changes depending on whether the bell is activated.
o Filter Stall Messages
Display stall messages that contain the specified search
string.
The information shown in the screen includes:
o process
The process ID and the Oracle Rdb stream ID of the database
user. Normally the stream ID will be one (1). However, if
the user is attached to multiple databases or has explicitly
detached and attached to different database sessions during
the same image activation, the stream ID will uniquely
identify the database session. Stream ID values greater than
99 display as "**" to indicate an integer display overflow
on the screen; the [Z]oom function can be used to display the
full stream ID in this case. The Config menu allows you to
select sorting of database users by process ID.
Optionally, a single character following the stream ID field
indicates additional information about the process:
D - Database Recovery (DBR)
R - Server for a remote user
s - Database server (such as ABS, ALS, LCS, LRS, or RCS)
u - Attached for utility access
* - User process on another node in the cluster
A - Available for per-process monitoring
G - Actively being monitored
o T
The current transaction state. R indicates a read-only
transaction and W indicates a read/write transaction.
o since
By default, the time at which the current stall started.
The Config menu option allows you to display the elapsed stall
time or the actual stall time.
o stall reason
The reason for the stall. For example, "waiting for..."
messages indicate a stalled lock request (along with the
requested lock mode).
The following list describes all of the stall reason messages
that can appear on the Stall Messages screen, and a brief
explanation of what causes each of them. In most cases, the
messages are informational and should cause little concern:
o Extending .AIJ file
This message displays whenever the .aij file is logically
or physically extended, which should occur infrequently.
o Extending .RUJ file
This message displays whenever the .ruj file is physically
extended, which should occur infrequently.
o Extending storage area !UL
This message displays whenever a storage area file
(identified by its numeric identifier, which can be
determined using RMU Dump) is physically extended. You can
determine the numeric identifier for a database's storage
areas by using the RMU Dump command. This message should
occur infrequently. However, this message may occur more
frequently with WORM areas because WORM area pages cannot
be reused once they have been written.
o Reading .AIJ file
This message displays whenever the AIJ lock information
needs to be refreshed; this typically only occurs the first
time a user attaches to the database. The .aij file is read
to determine the AIJ logical EOF (not to be confused with
the OpenVMS logical EOF). It is also read by the database
recovery (DBR) process.
o Reading ROOT file
This message displays whenever the in-memory database root
information is determined to be out-of-date and must be
read again from the disk. This message normally occurs only
when a database parameter is modified by a user on line or
some information in the database root is modified by the
system (such as the AIJ sequence number).
o Reading .RUJ file
This message displays whenever an undo operation needs to
read the next RUJ page to acquire the rollback information
necessary to complete the operation. The .ruj file is read
one block at a time.
Sometimes a process that is not being rolled back receives
this message because it was necessary to read the RUJ file
in order to refresh cached recovery information.
o Reading pages !UL:!UL to !UL:!UL
This message displays whenever one or more pages is read
into either a user's local buffer or the global buffer.
One buffer full of pages is being read. The format string
"!UL:!UL" identifies the physical area and the page number.
o waiting for !AD (!AC)
This message displays whenever a process requests a lock
"with wait" and another process is holding the lock in an
incompatible mode. This message may indicate a database
hot spot and should be investigated using the RMU Show
Locks utility. The format string "!AD" identifies the lock
type (that is, storage area, page, MEMBIT, etc.) and the
string "!AC" identifies the requested lock mode (PR, CR,
EX, etc.).
The following list contains information on "waiting for"
messages:
o waiting for record or page
The "waiting for record" and "waiting for page" messages
display a process ID, the time, and the DBKEY for a
record or a page.
The DBKEYs in "waiting for record" messages are logical
DBKEYs. For example:
waiting for record 1:0:-4 (CR)
waiting for record 91:155:-1 (CW)
In this example of the "waiting for record" message, the
first two fields of the "waiting for record" message are
not shown. The first field of a "waiting for record"
message is the process ID of the stalled process,
and the second field is the time the stall began.
The third field in the "waiting for record" message
(the field with the "XX:YY:ZZ" format) represents the
DBKEY, and you can usually interpret it as "logical area
number:page number:line number." However, only positive
numbers represent the line number. When a negative
number appears, it refers to the record ALG (adjustable
lock granularity) locking level. By default, there are
three page locking levels and the negative numbers are
interpreted as follows:
o -4 indicates the complete logical area
o -3 normally indicates 1000 database pages range
o -2 normally indicates 100 database pages range
o -1 normally indicates 10 database pages range
For example, in the second line of the example, the
DBKEY occurs in logical area 91 in a range of 10
database pages, one of which is page 155.
When you have a logical area number and want to get the
physical area name for that logical area, follow these
steps:
o Issue the following command:
$ RMU/DUMP/LAREAS=RDB$AIP db-name
o Search the resulting dump for the logical area with
that number.
o Note the corresponding physical area number.
o Issue the following command:
$ RMU/DUMP/HEADER db-name
Look up the physical area number from the output of
the RMU Dump Header command to find the name of the
physical area.
You can also look up columns RDB$STORAGE_ID or
RDB$INDEX_ID in system relations RDB$RELATIONS,
RDB$INDICES and RDBVMS$STORAGE_MAP_AREAS to identify
the Oracle Rdb entity (table or index) that the DBKEY
represents. For a description of the system relations,
see the System_Relations help topic by issuing the
following command:
$ HELP SQL SYSTEM_RELATIONS
The page number field in the DBKEY is the number of the
page in the corresponding physical area; the line number
is the number of the record on that page.
The dbkeys in "waiting for page" messages are physical
dbkeys, for example:
waiting for page 1:727 (PW)
In this example of the "waiting for page" message, the
first two fields of the "waiting for page" message are
not shown. The first field of a "waiting for page"
message is the process ID of the stalled process, and
the second field is the time the stall began. The DBKEY
format for a "waiting for page" message is interpreted
as "physical area number:page number."
When you have a physical area number and want to get
the physical area name for the area, issue the RMU Dump
Header command. Then look up the physical area number
in the command output to find the name of the physical
area.
You can also get a conversion table by issuing the
following command:
$ RMU/ANALYZE/LAREAS/OPTION=DEBUG/END=1 -
_$ /OUTPUT=LAREA.LIS db-name
This command produces a printable file containing
all logical areas, logical id numbers and physical id
numbers for a database.
CR, CW, and PW in the previous examples are requested
lock modes of Concurrent Read, Concurrent Write, and
Protected Write. The following table shows the lock
compatibility between a current transaction and access
modes other transactions can specify:
Mode of Current Lock
Mode of ____________________
Requested SR SW PR PW EX
Lock
_______________________________
SR Y Y Y Y N
SW Y Y N N N
PR Y N Y N N
PW Y N N N N
EX N N N N N
_______________________________
Key to lock modes:
SR - Shared Read
SW - Shared Write
PR - Protected Read
PW - Protected Write
EX - Exclusive
Y - Locks are compatible
N - Locks are not compatible
______________________________
Shared Read (SR) and Shared Write (SW) in the table are
equivalent to Concurrent Read (CR) and Concurrent Write
(CW).
o waiting for DBKEY scope
This message displays when a database user who attached
using the DBKEY SCOPE IS TRANSACTION clause has a
read/write transaction in progress (giving the user the
database key scope lock in CW mode), and a second user
who specifies the DBKEY SCOPE IS ATTACH clause (which
would give the user the database key scope lock in PR
mode) tries to attach. In this situation, the second
user's process stalls until the first user's transaction
completes.
You can specify the database key scope at run time using
the DBKEY SCOPE IS clause of the SQL ATTACH statement.
If the DBKEY SCOPE IS clause is used with the SQL CREATE
DATABASE or SQL IMPORT statements, the setting is in
effect only for the duration of the session of the user
who issued the statement; the setting does not become a
database root file parameter.
o waiting for snapshot cursor
This message displays when a process tries to start a
read-only transaction when snapshots are deferred, there
is no current read-only transaction, and a read/write
transaction is active.
Waiting for snapshot cursor is a normal state if
snapshots are deferred. The waiting will end when all
read/write transactions started before the first read-
only transaction have finished.
o waiting for MEMBIT lock
For each database, a membership data structure is
maintained. The membership data structure keeps track of
the nodes that are accessing the database at any given
time. The membership data structure for a database is
updated when the first user process from a node attaches
to the database and when the last user process from a
node detaches from the database.
The "waiting for MEMBIT lock" message means that a
process is stalled because the database's membership
data structure is in the process of being updated.
o waiting for client lock
A client lock indicates that an Rdb metadata lock is in
use. The term client indicates that Rdb is a client of
the Rdb locking services. The metadata locks are used
to guarantee memory copies of the metadata (table, index
and column definitions) are consistent with the on-disk
versions.
The "waiting for client lock" message means the database
user is requesting an incompatible locking mode. For
example, when trying to drop a table which is in use,
the drop operation requests a PROTECTED WRITE lock
on the metadata object (such as a table) which is
incompatible with the existing PROTECTED READ lock
currently used by others of the table.
These metadata locks consist of three longwords. The
lock is displayed in text format first, followed by its
hexadecimal representation. The text version masks out
non-printable characters with a dot (.).
The leftmost value seen in the hexadecimal output
contains the id of the object. The id is described below
for tables, routines, modules and storage map areas.
o For tables and views, the id represents the unique
value found in the RDB$RELATION_ID column of the
RDB$RELATIONS system table for the given table.
o For routines, the id represents the unique
value found in the RDB$ROUTINE_ID column of the
RDB$ROUTINES system table for the given routine.
o For modules, the id represents the unique value found
in the RDB$MODULE_ID column of the RDB$MODULES system
table for the given module.
o For storage map areas, the id presents the physical
area id. The "waiting for client lock" message on
storage map areas is very rare. This may be raised
for databases which have been converted from versions
prior to Rdb 5.1.
The next value displayed signifies the object type. The
following table describes objects and their hexadecimal
type values.
Object Type Values
-------------------------------------
Object Hexadecimal Value
-------------------------------------
Tables or views 00000004
Routines 00000006
Modules 00000015
Storage map areas 0000000E
-------------------------------------
The last value in the hexadecimal output represents the
lock type. The value 55 indicates this is a client lock.
NOTE
Because the full client lock output is long,
it may require more space than is allotted for
the Stall.reason column and therefore can be
overwritten by the Lock.ID. column output.
For more detailed lock information, perform the
following steps:
1. Press the L option from the horizontal menu to
display a menu of lock IDs.
2. Select the desired lock ID.
o Writing .AIJ file
This message displays whenever a group commit process
writes the commit information to the .aij file. In a high
throughput environment, the write buffer length will be as
close to 64K as possible.
o Writing ROOT file
This message displays whenever the in-memory database
root information is modified by a user on line or some
information in the database root is modified by the system
(such as the AIJ sequence number).
o Writing .RUJ file
This message displays whenever a user process writes
data page modification information to the .ruj file. This
message always precedes the next message.
o Writing pages back to database
This message displays whenever one or more data pages is
written to the database. This is typically caused by a
request to access those pages from another process or by
detaching from the database.
o lock ID
The optional lock ID field is displayed only when the stall
is the result of a lock request. When other types of stalls
occur, such as stalls due to I/O activity, the lock ID field
is cleared from the screen.
When displayed, the lock ID field shows the lock
identification of the resource that is stalled. You can use
the lock identification number as input to the RMU Show Locks
command to obtain information about processes that own, are
blocking, or are waiting for locks.
2.14 – Active User Stall Messages screen
This screen helps you find current stalls that represent
potential deadlocks, which become database hot spots. The screen
also helps you determine what stalls were last encountered by any
user.
Active user stall messages are not saved in the binary statistics
file created by the Output qualifier. Therefore, this screen is
not available when you execute the RMU Show Statistics command in
replay mode (with the Input qualifier).
The Stall Messages screen and the Active User Stall Messages
screen have the same format. However, the Active User Stall
Messages screen provides information on currently stalled
processes and on processes that were stalled but are no longer
stalled. In contrast, the Stall Messages screen provides
information only on currently stalled processes. Like the Stall
Messages screen, the Active User Stall Messages screen shows
when a process writes a bugcheck dump; a bugcheck dump file name
longer than 53 characters is truncated.
If there are more stalled processes than can fit on one page, the
notation "Page 1 of n" appears, where n is the total number of
pages. You can display successive pages by pressing the right
angle bracket (>) key or the Next Screen key. To display a
previous page of the Active User Stall Messages screen, press
the left angle bracket (<) key or the Prev Screen key.
The information shown in the screen includes:
o process
The process ID and the Oracle Rdb stream ID of the database
user. Normally the stream ID is 1. However, if the user is
attached to multiple databases or has explicitly detached and
attached to different database sessions during the same image
activation, the stream ID will uniquely identify the database
session. Stream ID values greater than 99 display as "**" to
indicate an integer display overflow on the screen the [Z]oom
function can be used to display the full stream ID in this
case.
Optionally, a single character following the stream ID field
indicates additional information about the process:
D - Database Recovery (DBR)
R - Server for a remote user
s - Database server (such as ABS, ALS, LCS, LRS, or RCS)
u - Attached for utility access
* - User process on another node in the cluster
A - Available for per-process monitoring
G - Actively being monitored
o T
The current transaction state. R indicates a read-only
transaction and W indicates a read/write transaction.
o since
By default, the time at which the current stall started. If
the stall has already completed, the column headed "since" is
blank, but the stall reason remains on the screen.
The Config menu option allows you to display the elapsed stall
time or the actual stall time.
o stall reason
The reason for the stall. For example, "waiting for..."
messages indicate a stalled lock request (along with the
requested lock mode). If the stall is still in progress, the
"since" column indicates the time at which the stall started.
If the stall has already completed, the "since" column is
blank, but the stall reason remains on the screen until it is
replaced by information for another stall.
The following list describes all of the stall reason messages
that can appear on the Active User Stall Messages screen,
and a brief explanation of what causes each of them. In most
cases, the messages are informational and should cause little
concern:
o Extending .AIJ file
This message displays whenever the .aij file is logically
or physically extended, which should occur infrequently.
o Extending .RUJ file
This message displays whenever the .ruj file is physically
extended, which should occur infrequently.
o Extending storage area !UL
This message displays whenever a storage area file
(identified by its numeric identifier, which can be
determined using RMU Dump) is physically extended. You can
determine the numeric identifier for a database's storage
areas by using the RMU Dump command. This message should
occur infrequently. However, this message may occur more
frequently with WORM areas because WORM area pages cannot
be reused once they have been written.
o Reading .AIJ file
This message displays whenever the AIJ lock information
needs to be refreshed; this typically only occurs the first
time a user attaches to the database. The .aij file is read
to determine the AIJ logical EOF (not to be confused with
the OpenVMS logical EOF). It is also read by the database
recovery (DBR) process.
o Reading ROOT file
This message displays whenever the in-memory database root
information is determined to be out of date and must be
read again from the disk. This message normally occurs only
when a database parameter is modified by a user online or
some information in the database root is modified by the
system (such as the AIJ sequence number).
o Reading .RUJ file
This message displays whenever an undo operation needs to
read the next RUJ page to acquire the rollback information
necessary to complete the operation. The .ruj file is read
one block at a time.
Sometimes a process that is not being rolled back receives
this message because it was necessary to read the RUJ file
in order to refresh cached recovery information.
o Reading pages !UL:!UL to !UL:!UL
This message displays whenever one or more pages is read
into either a user's local buffer or the global buffer.
One buffer full of pages is being read. The format string
"!UL:!UL" identifies the physical area and the page number.
o waiting for !AD (!AC)
This message displays whenever a process requests a lock
"with wait" and another process is holding the lock in an
incompatible mode. This message may indicate a database
hot spot and should be investigated using the RMU Show
Locks utility. The format string "!AD" identifies the lock
type (that is, storage area, page, MEMBIT, etc.) and the
string "!AC" identifies the requested lock mode (PR, CR,
EX, etc.).
The following list contains information on "waiting for"
messages:
o waiting for record or page
The "waiting for record" and "waiting for page" messages
display a process ID, the time, and the DBKEY for a
record or a page.
The dbkeys in "waiting for record" messages are logical
dbkeys. For example:
waiting for record 1:0:-4 (CR)
waiting for record 91:155:-1 (CW)
In this example of the "waiting for record" message, the
first two fields of the "waiting for record" message are
not shown. The first field of a "waiting for record"
message is the process ID of the stalled process,
and the second field is the time the stall began.
The third field in the "waiting for record" message
(the field with the "XX:YY:ZZ" format) represents the
DBKEY, and you can usually interpret it as "logical
area number:page number:line number." However, only
positive numbers represent the line number. When a
negative number appears, it refers to the record ALG
(adjustable lock granularity) locking level. Negative
numbers are interpreted as follows:
o -4 indicates the complete logical area
o -3 normally indicates 1000 database pages range
o -2 normally indicates 100 database pages range
o -1 normally indicates 10 database pages range
For example, in the second line of the example, the
DBKEY occurs in logical area 91 in a range of 10
database pages, one of which is page 155.
When you have a logical area number and want to get the
physical area name for that logical area, follow these
steps:
o Issue the following command:
$ RMU/DUMP/LAREAS=RDB$AIP db-name
o Search the resulting dump for the logical area with
that number.
o Note the corresponding physical area number.
o Issue the following command:
$ RMU/DUMP/HEADER db-name
Look up the physical area number from the output of
the RMU Dump Header command to find the name of the
physical area.
You can also look up columns RDB$STORAGE_ID or
RDB$INDEX_ID in system relations RDB$RELATIONS,
RDB$INDICES and RDBVMS$STORAGE_MAP_AREAS to identify
the Oracle Rdb entity (table or index) that the DBKEY
represents. For a description of the system relations,
see the System_Relations help topic by issuing the
following command:
$ HELP SQL SYSTEM_RELATIONS
The page number field in the DBKEY is the number of the
page in the corresponding physical area; the line number
is the number of the record on that page.
The dbkeys in "waiting for page" messages are physical
dbkeys, for example:
waiting for page 1:727 (PW)
In this example of the "waiting for page" message, the
first two fields of the "waiting for page" message are
not shown. The first field of a "waiting for page"
message is the process ID of the stalled process, and
the second field is the time the stall began. The DBKEY
format for a "waiting for page" message is interpreted
as "physical area number:page number".
When you have a physical area number and want to get
the physical area name for the area, issue the RMU Dump
Header command. Then look up the physical area number
in the command output to find the name of the physical
area.
You can also get a conversion table by issuing the
following command:
$ RMU/ANALYZE/LAREAS/OPTION=DEBUG/END=1 -
_$ /OUTPUT=LAREA.LIS db-name
This command produces a printable file containing
all logical areas, logical id numbers and physical id
numbers for a database.
CR, CW, and PW in the previous examples are requested
lock modes of Concurrent Read, Concurrent Write, and
Protected Write. The following table shows the lock
compatibility between a current transaction and access
modes other transactions can specify:
Mode of Current Lock
Mode of ____________________
Requested SR SW PR PW EX
Lock
_______________________________
SR Y Y Y Y N
SW Y Y N N N
PR Y N Y N N
PW Y N N N N
EX N N N N N
_______________________________
Key to lock modes:
SR - Shared Read
SW - Shared Write
PR - Protected Read
PW - Protected Write
EX - Exclusive
Y - Locks are compatible
N - Locks are not compatible
______________________________
Shared Read (SR) and Shared Write (SW) in the table are
equivalent to Concurrent Read and Concurrent Write.
o waiting for DBKEY scope
This message displays when a database user who attached
using the DBKEY SCOPE IS TRANSACTION clause has a
read/write transaction in progress (giving the user the
database key scope lock in CW mode), and a second user
who specifies the DBKEY SCOPE IS ATTACH clause (which
would give the user the database key scope lock in PR
mode) tries to attach. In this situation, the second
user's process stalls until the first user's transaction
completes.
You can specify the database key scope at run time using
the DBKEY SCOPE IS clause of the SQL ATTACH statement.
If the DBKEY SCOPE IS clause is used with the SQL CREATE
DATABASE or SQL IMPORT statements, the setting is in
effect only for the duration of the session of the user
who issued the statement; the setting does not become a
database root file parameter.
o waiting for snapshot cursor
This message displays when a process tries to start a
read-only transaction when snapshots are deferred, there
is no current read-only transaction, and a read/write
transaction is active.
Waiting for snapshot cursor is a normal state if
snapshots are deferred. The waiting will end when all
read/write transactions started before the first read-
only transaction have finished.
o waiting for MEMBIT lock
For each database, a membership data structure is
maintained. The membership data structure keeps track of
the nodes that are accessing the database at any given
time. The membership data structure for a database is
updated when the first user process from a node attaches
to the database and when the last user process from a
node detaches from the database.
The "waiting for MEMBIT lock" message means that a
process is stalled because the database's membership
data structure is in the process of being updated.
o waiting for client lock
A client lock indicates that an Rdb metadata lock is in
use. The term client indicates that Rdb is a client of
the Rdb locking services. The metadata locks are used
to guarantee memory copies of the metadata (table, index
and column definitions) are consistent with the on-disk
versions.
The "waiting for client lock" message means the database
user is requesting an incompatible locking mode. For
example, when trying to drop a table which is in use,
the drop operation requests a PROTECTED WRITE lock
on the metadata object (such as a table) which is
incompatible with the existing PROTECTED READ lock
currently used by others of the table.
These metadata locks consist of three longwords. The
lock is displayed in text format first, followed by its
hexadecimal representation. The text version masks out
non-printable characters with a dot (.).
The leftmost value seen in the hexadecimal output
contains the id of the object. The id is described below
for tables, routines, modules and storage map areas.
o For tables and views, the id represents the unique
value found in the RDB$RELATION_ID column of the
RDB$RELATIONS system table for the given table.
o For routines, the id represents the unique
value found in the RDB$ROUTINE_ID column of the
RDB$ROUTINES system table for the given routine.
o For modules, the id represents the unique value found
in the RDB$MODULE_ID column of the RDB$MODULES system
table for the given module.
o For storage map areas, the id presents the physical
area id. The "waiting for client lock" message on
storage map areas is very rare. This may be raised
for databases which have been converted from versions
prior to Rdb 5.1.
The next value displayed signifies the object type. The
following table describes objects and their hexadecimal
type values.
Object Type Values
-------------------------------------
Object Hexadecimal Value
-------------------------------------
Tables or views 00000004
Routines 00000006
Modules 00000015
Storage map areas 0000000E
-------------------------------------
The last value in the hexadecimal output represents the
lock type. The value 55 indicates this is a client lock.
NOTE
Because the full client lock output can be long,
it may require more space than is allotted for
the Stall.reason column and therefore can be
overwritten by the Lock.ID. column output.
For more detailed lock information, perform the
following steps:
1. Press the L option from the horizontal menu to
display a menu of lock IDs.
2. Select the desired lock ID.
o Writing .AIJ file
This message displays whenever a group commit process
writes the commit information to the .aij file. In a high
throughput environment, the write buffer length will be as
close to 64K as possible.
o Writing ROOT file
This message displays whenever the in-memory database
root information is modified by a user on line or some
information in the database root is modified by the system
(such as the AIJ sequence number).
o Writing .RUJ file
This message displays whenever a user process writes
data page modification information to the .ruj file. This
message always precedes the next message.
o Writing pages back to database
This message displays whenever one or more data pages is
written to the database. This is typically caused by a
request to access those pages from another process or by
detaching from the database.
o lock ID
The optional lock ID field is displayed only when the stall
is the result of a lock request. When other types of stalls
occur, such as stalls due to I/O activity, the lock ID field
is cleared from the screen.
When displayed, the lock ID field shows the lock
identification of the resource that is stalled. You can use
the lock identification number as input to the RMU Show Locks
command to obtain information about processes that own, are
blocking, or are waiting for locks.
The Active User Stall Messages screen has the following
attributes:
o The Active User Stall Messages screen reserves an empty line
for each process that is accessing the database from another
node in the VMScluster. These empty lines are unavoidable
because it is always possible for a process on another node in
the VMScluster to attach to the database on the current node,
thus using the empty line.
o If a process is active and running on the same node as the
Performance Monitor, the process' PID displays.
o The process information remains on that line until it detaches
from the database.
o The process stall text remains on the screen until it is
replaced by a new stall message.
o An active stall is identified by the stall starting time
being displayed. If the stall is no longer active, the stall
starting time is not displayed, but the message text remains
displayed.
o It is possible to page to multiple screen displays; each
process' state is preserved and refreshed when the new page
is displayed. When there is more than one page of Active User
Stalled Messages output, the header section contains the page
number currently displayed and the total number of pages in
the screen. Use the left angle bracket (<) key to go to the
previous page and the right angle bracket (>) key to go to the
next page of the screen.
The Active User Stall Messages screen has several advantages over
the Stall Messages screen. The advantages are:
o The location of a process remains static; because it is fixed
on a given page, it is always easy to locate.
o The process' last stall message (and lock ID, if applicable)
are displayed, even if the process is not currently stalled;
this is useful for identifying possible hot spots.
However, the Active User Stall Messages screen does have the
following disadvantages:
o It is difficult (but possible) to isolate the source of
a potential deadlock or a long-duration stall; the Stall
Messages screen is more useful for this.
o It is difficult (but possible) to isolate the set of actively
stalled processes from the complete set of processes doing
normal database accesses.
The following compares the Stall Messages screen and the Active
User Stall Messages screen:
o Processes displayed?
o Stall Messages screen-Displays only actively stalled
processes on the current node.
o Active User Stall Messages screen-Displays all processes
attached to the database on the current node.
o Process location?
o Stall Messages screen-Dynamic. The position of the process
reflects the duration of the stall relative to other
processes.
o Active User Stall Messages screen-Static. The position of
the process remains fixed in the same location until the
process detaches from the database.
o Display sequence?
o Stall Messages screen-Processes are displayed in descending
stall-duration sequence.
o Active User Stall Messages screen-Processes are displayed
in a fixed but arbitrary sequence.
o Indication of active stall?
o Stall Messages screen-The process stall text is displayed.
o Active User Stall Messages screen-The process stall text
starting time is displayed.
o Indication of inactive stall?
o Stall Messages screen-The process stall text is not
displayed.
o Active User Stall Messages screen-The process stall text
starting time is erased (message text remains).
o Duration of display?
o Stall Messages screen-The stall message is displayed only
if the stall is active.
o Active User Stall Messages screen-The last stall message
remains displayed until the process stalls again)
You can force frequent screen updates by using a negative number
for the Time qualifier in the RMU Show Statistics command. For
example, Time=-10 refreshes the screen every 10/100 (1/10) of a
second. Note that you use a lot of system resources, particularly
on the smaller CPU machines, when you specify this time interval.
If there are more stalls in progress than can fit on your
screen, some current stalls might not be displayed. Oracle Rdb
attempts to place as many active stall messages on the screen as
possible.
2.15 – Process Accounting screen
This screen provides continuously updated OpenVMS accounting
information about local processes in a VMScluster environment.
This screen is an alternative to the OpenVMS SHOW PROCESS
/CONTINUOUS utility. The screen provides equivalent information,
except that all active database processes on a specific node can
be monitored at the same time.
This screen displays operating system accounting information,
thereby enabling a database administrator to evaluate the
system resources used by database processes. The values in the
Process Accounting screen are for all process activity, not
just the activity that occurs while in the database. Therefore,
this screen is useful for monitoring the complete application
behavior.
This screen displays dynamically changing process information
only. That is, quotas and other information that are fixed for
each process are not displayed because that information can be
obtained in other ways.
The Process Accounting screen has brief and full modes that
control the amount of information displayed for each active
database process.
You select brief mode by typing B. In brief mode, one line
per process is displayed, providing the following information:
process ID, process name, CPU time, remaining lock quota count,
page fault count, number of direct I/O operations, working set
size and virtual memory size.
You select full mode by typing F. In full mode, a second line
per process is displayed that provides the following additional
information: user name, image name, process state, page file
quota count, direct I/O quota count, number of buffered I/O
operations and buffered I/O quota count.
Note that information on the Process Accounting screen cannot
be reset. Because the information is gathered in real time, it
cannot be written to the output file (the Output qualifier will
not work with this screen) and therefore cannot be displayed
during input file replay (the Input qualifier will not work with
this screen).
If the information on all the local processes does not fit on a
single Process Accounting page, use the >Next_page and <Prev_page
keys to scroll between the multiple pages of process information.
The Process Accounting screen provides the following information
in both brief and full modes:
o Process ID-The process ID for the current process, assigned
by the operating system, and the stream ID, assigned by the
database. If the process has more than one active database
session, only the first active stream ID will be displayed
because the process accounting information is the same for
all active database sessions. Stream ID values greater than 99
display as "**" to indicate an integer display overflow on the
screen; the [Z]oom function can be used to display the full
stream ID in this case.
Optionally, a single character following the stream ID field
indicates additional information about the process:
D - Database Recovery (DBR)
R - Server for a remote user
s - Database server (such as ABS, ALS, LCS, LRS, or RCS)
u - Attached for utility access
* - User process on another node in the cluster
A - Available for per-process monitoring
G - Actively being monitored
o Process name-The name of the process.
o CPU time-The total accumulated CPU time since the process was
logged in.
o ENQ quota count-The remaining number of locks the process
may request. This field should not approach zero. If it
does approach zero, the ENQLM value should be raised for the
process.
o Page fault count-The total accumulated number of page faults.
o Number of direct I/O operations-The total accumulated count of
the direct I/O operations.
o Working set size-The total accumulated number of active pages
(512-byte pages) in the working set for the process.
o Virtual memory size-The total accumulated number of pages
(512-byte pages) of virtual memory allocated by the process.
This value includes the size of the database global section.
The Process Accounting screen provides the following information
fields only in full mode:
o User name-The name of the user (used when logging in to the
system).
o Image name-The name of the image file currently being executed
by the process.
o Process state-The current process state, which will be one of
the following keywords:
Keyword Description
CEF Common event flag wait
COM Computable
COMO Computable, out of balance set
CUR Current process
COLPG Collided page wait
FPG Free page wait
HIB Hibernate wait
HIBO Hibernate wait, out of balance set
LEF Local event flag wait
LEFO Local event flag wait, out of balance set
MWAIT Mutex and miscellaneous resource wait
PFW Page fault wait
SUSP Suspended
SUSPO Suspended, out of balance set
o Page file quota count-The remaining number of pages in the
paging file the process may request. This field should not
approach zero. If it does approach zero, the PGFLQUOTA value
should be raised for the process.
o Direct I/O quota count-The remaining number of direct I/O
operations the process may request. This field should not
approach zero. If it does approach zero, the DIOLM value
should be raised for the process.
o Number of buffered I/O operations-The total accumulated count
of the buffered I/O operations.
o Buffered I/O quota count-The remaining number of buffered
I/O operations the process may request. This field should
not approach zero. If it does approach zero, the BIOLM value
should be raised for this process.
2.16 – Checkpoint Information unsorted screen
This screen displays one line of information for each process
attached to the database on this node. There may be blank
lines in the display as processes detach from the database; in
this way, once a process has attached to the database, it will
maintain the same location in the screen until it detaches from
the database.
The oldest active checkpoint, quiet-point, and transaction are
highlighted to aid in identifying the process in each category.
Note that the highlighted items may be for separate processes.
You can use the Config menu option to configure the Checkpoint
Information screen. Select this option, by typing the letter C,
to display the configuration submenu. The configuration submenu
provides the following options:
o Display Transaction XXX Time
Displays either the transaction start time, or the transaction
elapsed time. The option description changes depending on
which transaction time is currently being displayed.
o Unsorted Display
Displays the screen in its default configuration.
o Sort by oldest active checkpoint
Sorts the screen display in ascending active checkpoint
sequence. This means that the oldest active checkpoint will
be displayed on the first line and the most recent checkpoint
will be displayed on the last line.
o Sort by oldest active transaction
Sorts the screen display in ascending transaction start time
sequence. This means that the oldest active transaction is
displayed on the first line and the most recently started
transaction is displayed on the last line.
o Sort by oldest quiet-point
Sorts the screen display in ascending quiet-point sequence.
This means that the oldest quiet-point will be displayed
on the first line and the most recent quiet-point will be
displayed on the last line.
This screen displays the following fields:
o Process.ID
This is the ID of the process attached to the database. The
number following the colon (":") differentiates multiple
attaches to the same database.
o Ckpt.Vno
This is the sequence number of the AIJ journal that contains
the most recent checkpoint information for the process.
Sequence numbers start with "0". If nothing is displayed,
the process has not yet performed a checkpoint operation; this
may occur if the "Fast Commit" feature is displayed, or if the
process actually has not performed a checkpoint operation, as
is typical of utilities.
o Ckpt.Vbn
This is the block number within the identified AIJ journal
that contains the most recent checkpoint information for the
process. If nothing is displayed, the process has not yet
performed a checkpoint operation.
This field sometimes contains two keywords:
o BACKUP-indicates that the checkpoint VBN has been moved
because of an AIJ backup operation. This keyword will only
occur if an extensible AIJ journal is backed up.
o ACKNWLDG-indicates that the process has "acknowledged" the
BACKUP indication and will perform a checkpoint operation
as soon as possible. Performing the checkpoint operation
will cause the block number to be re-displayed.
o QuietVno
This field contains the sequence number of the AIJ journal
that contains the most recent forced quiet-point for
this process. A forced quiet-point occurs when a database
operation, such as database backup or AIJ backup, acquires a
quiet-point on the database.
o ST
This field contains the transaction mode. The valid values
are:
o RO-indicates a read-only transaction.
o RW-indicates a read/write transaction.
o Tx.Seq
This field contains the transaction sequence number.
o Transaction Time
This field displays either the transaction start time or
the transaction elapsed time, depending on the screen
configuration selection. The transaction time information is
displayed for processes on the current node only, even though
checkpoint information may be displayed for processes on other
nodes.
2.17 – Checkpoint Information checkpoint screen
This screen displays one line of information for each process
attached to the database on this node. There may be blank
lines in the display as processes detach from the database; in
this way, once a process has attached to the database, it will
maintain the same location in the screen until it detaches from
the database.
The oldest active checkpoint, quiet-point, and transaction are
highlighted to aid in identifying the process in each category.
Note that the highlighted items may be for separate processes.
You can use the Config menu option to configure the Checkpoint
Information screen. Select this option, by typing the letter C,
to display the configuration submenu. The configuration submenu
provides the following options:
o Display Transaction XXX Time
Displays either the transaction start time, or the transaction
elapsed time. The option description changes depending on
which transaction time is currently being displayed.
o Unsorted Display
Displays the screen in its default configuration.
o Sort by oldest active checkpoint
Sorts the screen display in ascending active checkpoint
sequence. This means that the oldest active checkpoint will
be displayed on the first line and the most recent checkpoint
will be displayed on the last line.
o Sort by oldest active transaction
Sorts the screen display in ascending transaction start time
sequence. This means that the oldest active transaction is
displayed on the first line and the most recently started
transaction is displayed on the last line.
o Sort by oldest quiet-point
Sorts the screen display in ascending quiet-point sequence.
This means that the oldest quiet-point will be displayed
on the first line and the most recent quiet-point will be
displayed on the last line.
This screen displays the following fields:
o Process.ID
This is the ID of the process attached to the database. The
number following the colon (":") differentiates multiple
attaches to the same database.
o Ckpt.Vno
This is the sequence number of the AIJ journal that contains
the most recent checkpoint information for the process.
Sequence numbers start with "0". If nothing is displayed,
the process has not yet performed a checkpoint operation; this
may occur if the "Fast Commit" feature is displayed, or if the
process actually has not performed a checkpoint operation, as
is typical of utilities.
o Ckpt.Vbn
This is the block number within the identified AIJ journal
that contains the most recent checkpoint information for the
process. If nothing is displayed, the process has not yet
performed a checkpoint operation.
This field sometimes contains two keywords:
o BACKUP-indicates that the checkpoint VBN has been moved
because of an AIJ backup operation. This keyword will only
occur if an extensible AIJ journal is backed up.
o ACKNWLDG-indicates that the process has "acknowledged" the
BACKUP indication and will perform a checkpoint operation
as soon as possible. Performing the checkpoint operation
will cause the block number to be re-displayed.
o QuietVno
This field contains the sequence number of the AIJ journal
that contains the most recent forced quiet-point for
this process. A forced quiet-point occurs when a database
operation, such as database backup or AIJ backup, acquires a
quiet-point on the database.
o ST
This field contains the transaction mode. The valid values
are:
o RO-indicates a read-only transaction.
o RW-indicates a read/write transaction.
o Tx.Seq
This field contains the transaction sequence number.
o Transaction Time
This field displays either the transaction start time or
the transaction elapsed time, depending on the screen
configuration selection. The transaction time information is
displayed for processes on the current node only, even though
checkpoint information may be displayed for processes on other
nodes.
2.18 – Checkpoint Information transaction screen
This screen displays one line of information for each process
attached to the database on this node. There may be blank
lines in the display as processes detach from the database; in
this way, once a process has attached to the database, it will
maintain the same location in the screen until it detaches from
the database.
The oldest active checkpoint, quiet-point, and transaction are
highlighted to aid in identifying the process in each category.
Note that the highlighted items may be for separate processes.
You can use the Config menu option to configure the Checkpoint
Information screen. Select this option, by typing the letter C,
to display the configuration submenu. The configuration submenu
provides the following options:
o Display Transaction XXX Time
Displays either the transaction start time, or the transaction
elapsed time. The option description changes depending on
which transaction time is currently being displayed.
o Unsorted Display
Displays the screen in its default configuration.
o Sort by oldest active checkpoint
Sorts the screen display in ascending active checkpoint
sequence. This means that the oldest active checkpoint will
be displayed on the first line and the most recent checkpoint
will be displayed on the last line.
o Sort by oldest active transaction
Sorts the screen display in ascending transaction start time
sequence. This means that the oldest active transaction is
displayed on the first line and the most recently started
transaction is displayed on the last line.
o Sort by oldest quiet-point
Sorts the screen display in ascending quiet-point sequence.
This means that the oldest quiet-point will be displayed
on the first line and the most recent quiet-point will be
displayed on the last line.
This screen displays the following fields:
o Process.ID
This is the ID of the process attached to the database. The
number following the colon (":") differentiates multiple
attaches to the same database.
o Ckpt.Vno
This is the sequence number of the AIJ journal that contains
the most recent checkpoint information for the process.
Sequence numbers start with "0". If nothing is displayed,
the process has not yet performed a checkpoint operation; this
may occur if the "Fast Commit" feature is displayed, or if the
process actually has not performed a checkpoint operation, as
is typical of utilities.
o Ckpt.Vbn
This is the block number within the identified AIJ journal
that contains the most recent checkpoint information for the
process. If nothing is displayed, the process has not yet
performed a checkpoint operation.
This field sometimes contains two keywords:
o BACKUP-indicates that the checkpoint VBN has been moved
because of an AIJ backup operation. This keyword will only
occur if an extensible AIJ journal is backed up.
o ACKNWLDG-indicates that the process has "acknowledged" the
BACKUP indication and will perform a checkpoint operation
as soon as possible. Performing the checkpoint operation
will cause the block number to be re-displayed.
o QuietVno
This field contains the sequence number of the AIJ journal
that contains the most recent forced quiet-point for
this process. A forced quiet-point occurs when a database
operation, such as database backup or AIJ backup, acquires a
quiet-point on the database.
o ST
This field contains the transaction mode. The valid values
are:
o RO-indicates a read-only transaction.
o RW-indicates a read/write transaction.
o Tx.Seq
This field contains the transaction sequence number.
o Transaction Time
This field displays either the transaction start time or
the transaction elapsed time, depending on the screen
configuration selection. The transaction time information is
displayed for processes on the current node only, even though
checkpoint information may be displayed for processes on other
nodes.
2.19 – Checkpoint Information QuietPoint screen
This screen displays one line of information for each process
attached to the database on this node. There may be blank
lines in the display as processes detach from the database; in
this way, once a process has attached to the database, it will
maintain the same location in the screen until it detaches from
the database.
The oldest active checkpoint, quiet-point, and transaction are
highlighted to aid in identifying the process in each category.
Note that the highlighted items may be for separate processes.
You can use the Config menu option to configure the Checkpoint
Information screen. Select this option, by typing the letter C,
to display the configuration submenu. The configuration submenu
provides the following options:
o Display Transaction XXX Time
Displays either the transaction start time, or the transaction
elapsed time. The option description changes depending on
which transaction time is currently being displayed.
o Unsorted Display
Displays the screen in its default configuration.
o Sort by oldest active checkpoint
Sorts the screen display in ascending active checkpoint
sequence. This means that the oldest active checkpoint will
be displayed on the first line and the most recent checkpoint
will be displayed on the last line.
o Sort by oldest active transaction
Sorts the screen display in ascending transaction start time
sequence. This means that the oldest active transaction is
displayed on the first line and the most recently started
transaction is displayed on the last line.
o Sort by oldest quiet-point
Sorts the screen display in ascending quiet-point sequence.
This means that the oldest quiet-point will be displayed
on the first line and the most recent quiet-point will be
displayed on the last line.
This screen displays the following fields:
o Process.ID
This is the ID of the process attached to the database. The
number following the colon (":") differentiates multiple
attaches to the same database.
o Ckpt.Vno
This is the sequence number of the AIJ journal that contains
the most recent checkpoint information for the process.
Sequence numbers start with "0". If nothing is displayed,
the process has not yet performed a checkpoint operation; this
may occur if the "Fast Commit" feature is displayed, or if the
process actually has not performed a checkpoint operation, as
is typical of utilities.
o Ckpt.Vbn
This is the block number within the identified AIJ journal
that contains the most recent checkpoint information for the
process. If nothing is displayed, the process has not yet
performed a checkpoint operation.
This field sometimes contains two keywords:
o BACKUP-indicates that the checkpoint VBN has been moved
because of an AIJ backup operation. This keyword will only
occur if an extensible AIJ journal is backed up.
o ACKNWLDG-indicates that the process has "acknowledged" the
BACKUP indication and will perform a checkpoint operation
as soon as possible. Performing the checkpoint operation
will cause the block number to be re-displayed.
o QuietVno
This field contains the sequence number of the AIJ journal
that contains the most recent forced quiet-point for
this process. A forced quiet-point occurs when a database
operation, such as database backup or AIJ backup, acquires a
quiet-point on the database.
o ST
This field contains the transaction mode. The valid values
are:
o RO-indicates a read-only transaction.
o RW-indicates a read/write transaction.
o Tx.Seq
This field contains the transaction sequence number.
o Transaction Time
This field displays either the transaction start time or
the transaction elapsed time, depending on the screen
configuration selection. The transaction time information is
displayed for processes on the current node only, even though
checkpoint information may be displayed for processes on other
nodes.
2.20 – Active User Chart screen
This screen tracks the number of active users attached to the
database over a period of time.
The Active User Chart screen graphically portrays the number of
currently active users attached to the database over a measured
period of time. The slope of the line can be used to visually
identify the rate at which users attach to or detach from the
database.
The screen is also useful for determining when the configured
number of users is overly large for the number of users that are
actually attached to the database at any given moment.
The number of active users is portrayed as a percentage of the
maximum configured for the database, designated along the left-
hand side of the screen.
The screen refresh sample rate is identified at the bottom of
the screen. Directly above the screen refresh rate is a series
of timestamps. Each timestamp represents the time for the end of
each block.
Note that the rightmost timestamp displayed may not be the latest
time; this occurs because the output of the screen wraps around
to the leftmost edge after writing to the rightmost edge.
The current time is designated by the cursor along the bottom
horizontal axis. Everything to the right of the current time is
the end of the previous pass.
The graph output consists of a single numeric digit being written
once per the specified sample rate. The numeric digit corresponds
to the "nth" percentage of the particular percentage category.
If a digit is not displayed for a given cycle, this means that
there are no actively attached processes for the database, on any
node.
This screen is not recorded in the binary output file produced
using the Output qualifier. Consequently, this screen is
not available when you replay a binary file using the Input
qualifier.
2.21 – CPU Utilization sorted screen
This screen displays the current CPU utilization of each database
process on the node as a percentage of the total processor
utilization.
This screen displays one line of information for each database
process active on the node. If a process is attached to the
database multiple times, the screen displays only one line of
information.
If the number of displayable processes is greater than the number
of displayable lines, use the right arrow or up arrow and the
left arrow or right arrow to navigate through the display pages.
For each active database process, the CPU Utilization screen
shows the following:
o Process ID
o Process name
o CPU utilization percentage of that process
The histogram portion of the display shows the process'
utilization percentage in graph format.
Note that the displayed process CPU utilization, in addition to
the database-related processing, includes the CPU utilization
of ALL non-database related activities that the process also
performs. In order to track the exact CPU utilization of the
database-specific activity, Oracle Corporation recommends that
you use Oracle Trace.
By default, the processes on the screen appear in arbitrary
(unsorted) order. By selecting the Config option, you can
manually configure the CPU Utilization screen. Choose the Config
option by typing C to display the CPU Utilization Configuration
menu. This menu offers the following options:
o A. Unsorted Display
Option A displays the processes in unsorted order.
o B. Sort by CPU Utilization
Option B displays the processes sorted in order of descending
CPU utilization. This display configuration can be difficult
to view when the display rate is less than two seconds since
the process CPU utilizations vary at any given time. Oracle
Corporation recommends that you use the sorted display with a
display rate of two seconds or more.
The CPU Utilization screen is not saved by using the Output
qualifier, therefore it cannot be replayed using the Input
qualifier.
2.22 – CPU Utilization unsorted screen
This screen displays the current CPU utilization of each database
process on the node as a percentage of the total processor
utilization.
This screen displays one line of information for each database
process active on the node. If a process is attached to the
database multiple times, the screen displays only one line of
information.
If the number of displayable processes is greater than the number
of displayable lines, use the right arrow or up arrow and the
left arrow or right arrow to navigate through the display pages.
For each active database process, the CPU Utilization screen
shows the following:
o Process ID
o Process name
o CPU utilization percentage of that process
The histogram portion of the display shows the process'
utilization percentage in graph format.
Note that the displayed process CPU utilization, in addition to
the database-related processing, includes the CPU utilization
of ALL non-database related activities that the process also
performs. In order to track the exact CPU utilization of the
database-specific activity, Oracle Corporation recommends that
you use Oracle Trace.
By default, the processes on the screen appear in arbitrary
(unsorted) order. By selecting the Config option, you can
manually configure the CPU Utilization screen. Choose the Config
option, by typing C, to display the CPU Utilization Configuration
menu. This menu offers the following options:
o A. Unsorted Display
Option A displays the processes in unsorted order.
o B. Sort by CPU Utilization
Option B displays the processes sorted in order of descending
CPU utilization. This display configuration can be difficult
to view when the display rate is less than two seconds since
the process CPU utilizations vary at any given time. Oracle
Corporation recommends that you use the sorted display with a
display rate of two seconds or more.
The CPU Utilization screen is not saved by using the Output
qualifier, therefore it cannot be replayed using the Input
qualifier.
2.23 – Transaction Recovery Duration Estimate screen
This screen displays an estimate of the time it will take to roll
back a transaction, or to completely recover a failed process.
DISCLAIMER
The information provided in this screen is an estimate based
on previous process recovery operations and other factors
such as page contention and disk throughput.
Note that this information is an estimate only; the actual
process recovery duration may be more or less than described
on this screen.
Individual process failure recovery performance can vary
widely depending on many factors which cannot be accounted
for in the displayed estimate. These factors include lock
deadlock stalls, network delays, disk contention and many
other system factors such as lock remastering.
This screen displays the following fields:
o Process.ID - The process identifier of a process that has the
potential to roll back a transaction or require transaction
recovery in the event of process failure.
o RUJ.Sz - The number of blocks of RUJ information that have
been written by the process.
o Tx.Rollback - The estimate of the time it would require for
the process to roll back the transaction. Note that this is
different from the time it would take the DBR process to roll
back the transaction.
o DBR.Tx.Undo - The estimate of the time it would require for
the DBR process to undo the transaction. The DBR transaction
undo duration is typically less than it takes the process to
roll back the transaction, due to various optimizations and
simplifications in the DBR recovery algorithm.
o AIJ.Ckpt - If the fast commit feature is enabled, this is the
most recent checkpoint location in the AIJ journal for the
process.
o Pnd - If AIJ journaling is enabled, this is the number of
blocks of AIJ information that have been submitted, but not
yet written to the AIJ journal.
o DBR.Tx.Redo - If the fast commit feature is enabled, this is
the estimate of the time it would take the DBR process to redo
the previously committed transactions of the failed process to
the database.
o DB.Freeze.Tm - The estimate of the total time the database
would be frozen if the current process were to prematurely
terminate.
You can use the Config menu option to configure the Transaction
Recovery Duration Estimate screen. Select this option, by
typing the letter C, to display the configuration submenu. The
configuration submenu provides the following options:
o Unsorted Display
o Sort by oldest transaction rollback
o Sort by oldest DBR undo
o Sort by oldest DBR redo
o Sort by oldest database freeze
You can examine the past history of recovery operations by
issuing the RMU Dump Header command and reviewing the Database
Recovery section.
The Transaction Recovery Duration Estimate screen is not recorded
in the binary output file produced using the Output qualifier.
Consequently, this screen is not available when you replay a
binary file using the Input qualifier.
2.24 – AIJ Backup Activity screen
This screen displays information about each AIJ backup operation
being performed on the node.
The AIJ Backup Activity screen is also available during cluster-
wide statistics collection. This means you can monitor the
activities of all AIJ backup operations occurring on any node
accessing the database.
This screen displays the following fields:
o Process.ID - The process identifier of the AIJ backup process.
This process may be one of the following:
o AIJ backup server (ABS) in which case the process
identifier contains the "s" suffix.
o RMU Backup After_Journal command, in which case the process
identifier contains the "u" suffix.
Use the Zoom menu option to display additional information
about this process.
o Activity - The description of the backup activity being
performed by the AIJ backup utility. The following backup
activities are displayed:
o activation - The AIJ backup utility is being invoked by the
monitor if it is the ABS, or startup if the manual backup
command is being used.
o bind - The AIJ backup utility is binding to the database.
o start - The AIJ backup utility is starting the backup
operation.
o create bkup - The AIJ backup utility is creating a disk-
based backup file.
o create temp - The AIJ backup utility is creating a
temporary AIJ journal. This activity typically occurs
when the fast commit feature is used in conjunction with
extensible AIJ journals.
o record bkup - The AIJ backup utility is backing up an
extensible AIJ journal to disk, or any type of AIJ journal
to tape, using a record-by-record transfer algorithm.
o block bkup - The AIJ backup utility is backing up a fixed-
size (circular) AIJ journal to disk, using a 127-block
transfer algorithm.
o finish - The AIJ backup utility is completing the backup of
an AIJ journal.
o quiet-point - The AIJ backup utility is attempting to
acquire the quiet-point lock.
o record shfl - The AIJ backup utility is performing the
record shuffle operation used for extensible AIJ journals.
o unbind - The AIJ backup utility is unbinding from the
database.
o VBN - The current block number of the AIJ journal being
backed up. The block number is normally prefixed with the AIJ
sequence number, so it is easy to identify which AIJ journal
is being backed up.
o Operation - The activity-specific operation being performed by
the AIJ backup utility. This column contains messages similar
to those displayed by the Stall Messages screen.
o Lock.ID - Any lock the AIJ backup utility may be trying to
acquire. This lock is typically the quiet-point lock.
Use the LockID menu option to display additional information
about this lock.
The AIJ Backup Activity screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.25 – DBR Activity screen
This screen displays one line of information for each DBR process
active on the node. (If there is no active DBR process, the
screen is empty.)
If this screen is not used, the only method available to users
to determine if the DBR process is running is to use the RMU Show
Users utility. However, the RMU Show Users utility only indicates
that the DBR process is running; it does not indicate what type
of progress DBR is making in the recovery operation.
For each active DBR process, the DBR Activity screen shows the
following:
o The DBR process ID
o The activity being performed. (A list of these activities
appears later in this help display.)
o The operation being performed. (A list of these operations
appears later in this help display.)
o The lock ID, if any, being requested
Several significant restrictions apply to the DBR Activity
screen:
o The DBR Activity screen only shows information about
DBR processes running on that node. It does not display
information about DBR processes running on other nodes.
o The DBR Activity screen does not identify which user process
is being recovered. This information can be obtained from the
Active User Stall Messages screen.
o The DBR Activity screen is not logged to the RMU Show
Statistics output file, which means that it cannot be
replayed.
The DBR process currently records the following distinct
activities:
o Activation
The DBR process is being activated by the monitor.
o Database Attach
The DBR process is attaching to the database.
o AIJ Recovery
The DBR process is recovering any pending AIJ operations.
o Root Update
The DBR process is recovering any pending database root
information updates.
o GB Recovery
The DBR process is recovering any pending global buffer
transactions.
o Recovery Setup
The DBR process is initializing its recovery context
information.
o Transaction Redo
The DBR process is redoing committed transactions that have
not yet been flushed to the database.
o Transaction Undo
The DBR process is undoing uncommitted transactions that have
already been flushed to the database.
o Buffer Flush
The DBR process is flushing its cache buffers to the database.
o Database Detach
The DBR process is detaching from the database and terminating
the image.
For each activity recorded by the DBR process, a variety
of database operations are performed. These operations are
identified by the following messages:
o Extending storage area n
This message is displayed whenever a storage area (identified
by its numeric identifier n-see RMU Dump output) file
is physically extended. This message should occur only
occasionally; this message may occur more frequently when
you use WORM areas, as pages cannot be reused once they have
been written.
o Prepared, waiting to commit distributed transaction
This message is displayed whenever a database user
participating in a distributed transaction (coordinated
by DECdtm) is "Prepared to Commit or Roll Back," but has
not received the final transaction outcome from DECdtm. If
this message occurs frequently, you should look into the
possibility of a distributed deadlock. Distributed deadlock
can occur in a distributed transaction involving multiple
databases that are on two or more nonclustered machines.
o Reading .AIJ file block n
This message is displayed whenever AIJ lock information needs
to be refreshed; this typically occurs only the first time
a user attaches to the database. The .aij file is read to
determine the AIJ logical EOF (not to be confused with the
OpenVMS logical EOF). This operation also occurs when the DBR
process needs REDO information from the .aij file.
o Reading ROOT file
This message is displayed whenever the in-memory database root
information has been determined to be out-of-date and must be
re-read from the disk. This message normally occurs only when
a database parameter is modified by a user on line, or some
information in the database root is modified by the system
(such as the AIJ sequence number).
o Reading .RUJ file block n
This message is displayed whenever an UNDO operation needs
to read the next RUJ page to acquire the rollback information
necessary to complete the operation. The .ruj file is read one
block at a time, backwards. Thus, the identified block number
indicates the remaining number of blocks to be processed.
o Reading pages n:n to n:n
This message is displayed whenever one or more pages is read
into either the DBR process local buffer or the global buffer.
One full buffer of pages is being read. The format string n:n
identifies the physical area and the page number.
o Writing .AIJ file block n
This message is displayed whenever DBR actually writes commit
or rollback information to the .aij file. The write buffer can
be as close to 64,000 bytes in length as possible.
o Writing ROOT file
This message is displayed whenever the in-memory database root
information is modified by DBR.
o Writing pages back to database
This message is displayed whenever one or more data pages is
written to the database. This is typically caused by a request
to access those pages from another recovery process, or by
detaching from the database.
2.26 – Monitor Log screen
This screen allows you to view the monitor log online, even
when the disk-based logging is disabled because of disk space
problems. It also indicates when monitor logging is disabled.
The screen has the following features:
o It contains the actual monitor log information for the
corresponding database in exactly the same format as the disk-
based log. However, the display maximum is 79 characters;
therefore, entries longer than 79 characters are truncated.
o It contains up to the last 160 lines of the monitor log.
Blank lines are not shown in order to display as much log
information as possible.
Each page of the Monitor Log screen represents a view of the
actual monitor log, in reverse order. For example, page 1 on the
Monitor Log screen is the last page of the monitor log; page 2
is the second to last page of the monitor log, and so on. The
monitor log scrolls up as new entries are written.
Entries in the monitor log are comprised of major and minor
events. Major events have the format date/time - description.
Minor events have the format - description with no date field.
The Monitor Log screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this screen
is not available when you replay a binary file using the Input
qualifier.
2.27 – OPCOM Log screen
This screen allows you to view database-related OPCOM messages.
The screen identifies the last-broadcast message for each active
process. If a single process is attached to the database multiple
times, the OPCOM messages are displayed for the attach that
issued the broadcast.
2.28 – Defined Logicals screen
This screen shows all the logicals currently accessible to the
Performance Monitor, the name of the table in which they were
defined, and the associated logical value.
The displayed logical names are listed in suffix alphabetical
order for quick review. That is, the logical names are sorted
after removing the facility name (such as RDMS$, RDM$, SQL$).
This method of sorting is very useful, because in most cases the
facility name prefix is not known.
The Defined Logicals screen has two modes: brief or full. The
brief display mode is the default. You select brief mode by
typing B (displayed as Brief on the horizontal menu). When the
Defined Logicals screen is in brief mode, only those logicals
actually defined and accessible appear. The displayed table name
is the actual table where the logical resides, and the definition
is the logical's defined value. The screen is dynamically updated
as new logicals are defined on the system.
You select the full display mode by typing F (displayed as Full
on the horizontal menu). When the Defined Logicals screen is
in full mode, all known logicals are displayed, whether the
logical is defined or not. If the displayed logical is defined,
the table name and logical value are displayed as if the display
were in brief mode. If the logical is not defined, the table name
contains the name of the table where the logical should reside;
no definition is displayed. The full mode is useful for checking
the spelling of logical names and ensuring the logical is defined
in the proper table.
When more than one page of the Defined Logicals screen is output,
you view the succeeding pages of the Defined Logicals screen by
pressing the right angle bracket (>) key, as indicated by the
>Next_page option in the horizontal menu. Then, to move back to
previous Defined Logicals display pages, press the left angle
bracket (<) key, as indicated by the <Prev_page option in the
horizontal menu.
This screen shows the list of all logicals currently accessible
to the Performance Monitor; the screen is unable to show logicals
defined in another process' tables.
The Defined Logicals screen shows the values of logicals; it does
not allow you to modify the values of the logicals.
The output from the Defined Logicals screen is not written to the
output file; therefore, the output cannot be replayed using an
input file.
Due to screen width limitations, only the first 28 characters of
the logical name are displayed.
If you are using a multiversion product, the logicals displayed
do not contain the numerical suffix. For example, if the
multiversion variant of Oracle Rdb Version 6.1 is being used, the
61 suffix does not appear for any of the logicals in the Defined
Logicals screen.
2.29 – Lock Timeout History screen
The Lock Timeout History screen can be used to identify the
object that causes a timeout event.
The Stall Messages screen provides stall information, but when
a process times out while waiting for a lock, the stall is
terminated and the information is no longer available on the
Stall Messages screen.
For each active process on the current VMScluster node, the Lock
Timeout History screen shows the process ID, the time that the
process most recently timed out while waiting for a lock, the
reason for the most recent timeout experienced by the process,
and the number of timeouts experienced by the process since
attaching to the database.
The information shown in the screen includes:
o process ID
The process ID of each active process.
o occurred
The time that the process most recently timed out while
waiting for a lock. This field is blank if the process has
not experienced any timeouts.
o lock timeout reason
The event that caused the most recent timeout experienced
by the process. This field is blank if the process has not
experienced any timeouts. Note that the lock timeout reason
does not identify the cause of the timeout. The conflicting
process could be on a different VMScluster node. Rather, the
lock timeout reason provides historical information that can
help the DBA track down the timeout by other means, such as
using the RMU Show Locks utility or examining the application
transaction data flow analysis. The lock timeout reason
remains displayed for a process until the process is involved
in another timeout or detaches from the database. For more
information on interpreting the lock timeout reasons, see the
descriptions for the stall reasons in the help text for the
Stall Messages screen.
o timeout
The number of timeouts the process has experienced since
being attached to the database. This field is blank if the
process has not experienced any timeouts. This information
may be as useful as the lock timeout reason in determining
the importance of the timeout. For instance, if the database
has been active for a week and the number of timeouts is low,
the system may be operating efficiently. Timeouts are fairly
common in a database system, and not all timeouts are bad.
2.30 – Lock Deadlock History screen
The Lock Deadlock History screen can be used to identify the
object that causes a deadlock event.
The Stall Messages screen provides stall information, but when a
lock is deadlocked, the stall is terminated and the information
is no longer available on the Stall Messages screen.
For each active process on the current VMScluster node, the Lock
Deadlock History screen shows the process ID, the time that the
process was most recently involved in a deadlock, the reason for
the most recent deadlock, and the number of deadlocks the process
has encountered since attaching to the database.
The information shown in the screen includes:
o process ID
The process ID of each active process.
o occurred
The time that the process encountered the most recent
deadlock. This field is blank if the process has not
encountered any deadlocks.
o lock deadlock reason
The event that caused the most recent deadlock encountered
by the process. This field is blank if the process has not
encountered any deadlocks. Note that the lock deadlock reason
does not identify the cause of the deadlock. The conflicting
process could be on a different VMScluster node. Rather, the
lock deadlock reason provides historical information that can
help the DBA track down the deadlock by other means, such as
using the RMU Show Locks utility or examining the application
transaction data flow analysis. The lock deadlock reason
remains displayed for a process until the process is involved
in another deadlock or detaches from the database. For more
information on interpreting the lock deadlock reasons, see the
descriptions for the stall reasons in the help text for the
Stall Messages screen.
o deadlock
The number of deadlocks the process has encountered since
being attached to the database. This field is blank if the
process has not encountered any deadlocks. This information
may be as useful as the lock deadlock reason in determining
the importance of the deadlock. For instance, if the database
has been active for a week and the number of deadlocks is low,
the system may be operating efficiently. Deadlocks are fairly
common in a database system, and not all deadlocks are bad.
By using the Lock Deadlock History screen to examine the most
recent deadlocks, a DBA can more easily identify potential
database hot spots and application bottlenecks. Looking
at a screen full of deadlock information can help the DBA
differentiate between frequent and infrequent problems and
correlate common causes of the problems.
Some of the deadlocks that appear on the Lock Deadlock History
screen are page deadlocks. The lock deadlock reason "waiting
for page n:nnn" appears for page deadlocks. Although a page
deadlock is not necessarily a bad occurrence, it could indicate
a potential performance problem. Sometimes a process that is
experiencing a page deadlock appears on the Lock Deadlock History
screen, and a high number of deadlocks is reported for the
process. However, the lock deadlock reason gives the reason for
only the most recent deadlock, so all the reported deadlocks
for the process may not be for the indicated page. If the number
of deadlocks reported is high for the time the process has been
attached to the database, the DBA should examine the process in
detail. A high number of deadlocks for a process can indicate a
major design problem.
In general, record deadlocks are undesirable and the cause of
such deadlocks should be discovered and fixed. Page deadlocks are
not always bad, but they need to be analyzed.
2.31 – DBKEY Information screen
This screen displays, for each process attached to the database
on the node, the last retrieved DBKEY for each of the following
page categories:
data page
snapshot page
SPAM (space area management) page
AIP (area inventory page) page
ABM (area bitmap) page
If the attached process provides line number information as
part of the data page retrieval information, the line number
is displayed. Otherwise, only the area and page number are
displayed. For the snapshot, SPAM, AIP, and ABM pages, only the
area and page number are displayed.
The DBKEY Information screen is especially useful for identifying
collisions on hot pages.
The DBKEY Information screen is not recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is not available when you replay a binary file using the
Input qualifier.
2.32 – Stall Statistics Aggregate counts screen
This screen displays the number of stalls for every stall class.
You can use the Config menu option to configure the Stall
Statistics screen. You can display aggregate count information
or aggregate duration information.
2.33 – Stall Statistics Aggregate durations screen
This screen displays the total duration, in hundredths of
seconds, for every stall class.
Since certain types of stalls can be nested, the total stall
durations may be larger than actually occurred.
You can use the Config menu option to configure the Stall
Statistics screen. You can display aggregate count information
or aggregate duration information.
2.34 – Active Stall Counts screen
This screen identifies the number of processes currently stalled
in a particular stall class. Ideally, the number of stalled
processes for each class should be zero, which indicates that
no processes are stalled.
2.35 – Row Cache Overview unsorted screen
This screen provides summary Row Cache information for active
caches. This screen provides the following information:
o Cache.Name
This field displays the cache name.
o Searches
This field displayes the number of times the row cache was
searched for a specific row (DBKEY).
o Hit%
This field displays the percentage of cache searches that were
satistified by the cache (ie, the row was found in the cache).
o Full%
This field displays the percentage of the slots in the cache
that are not empty.
o Inserts
This field displays the number of times new rows have been
inserted into the row cache.
o Wrap
This field displays the number of times the row cache "insert
cursor" reached the end of the cache and started over at the
beginning of the cache.
o Slots
This field displays the total number of slots in the cache.
o len
This field displays the length (ie, width) of each slot in the
cache.
2.36 – Row Cache Overview searches screen
This screen provides summary Row Cache information for active
caches ordered by number of cache searches. This screen provides
the following information:
o Cache.Name
This field displays the cache name.
o Searches
This field displayes the number of times the row cache was
searched for a specific row (DBKEY).
o Hit%
This field displays the percentage of cache searches that were
satistified by the cache (ie, the row was found in the cache).
o Full%
This field displays the percentage of the slots in the cache
that are not empty.
o Inserts
This field displays the number of times new rows have been
inserted into the row cache.
o Wrap
This field displays the number of times the row cache "insert
cursor" reached the end of the cache and started over at the
beginning of the cache.
o Slots
This field displays the total number of slots in the cache.
o len
This field displays the length (ie, width) of each slot in the
cache.
2.37 – Row Cache Overview %hit screen
This screen provides summary Row Cache information for active
caches ordered by the cache search hit percentage. This screen
provides the following information:
o Cache.Name
This field displays the cache name.
o Searches
This field displayes the number of times the row cache was
searched for a specific row (DBKEY).
o Hit%
This field displays the percentage of cache searches that were
satistified by the cache (ie, the row was found in the cache).
o Full%
This field displays the percentage of the slots in the cache
that are not empty.
o Inserts
This field displays the number of times new rows have been
inserted into the row cache.
o Wrap
This field displays the number of times the row cache "insert
cursor" reached the end of the cache and started over at the
beginning of the cache.
o Slots
This field displays the total number of slots in the cache.
o len
This field displays the length (ie, width) of each slot in the
cache.
2.38 – Row Cache Overview %full screen
This screen provides summary Row Cache information for active
caches ordered by the cache fullness percentage. This screen
provides the following information:
o Cache.Name
This field displays the cache name.
o Searches
This field displayes the number of times the row cache was
searched for a specific row (DBKEY).
o Hit%
This field displays the percentage of cache searches that were
satistified by the cache (ie, the row was found in the cache).
o Full%
This field displays the percentage of the slots in the cache
that are not empty.
o Inserts
This field displays the number of times new rows have been
inserted into the row cache.
o Wrap
This field displays the number of times the row cache "insert
cursor" reached the end of the cache and started over at the
beginning of the cache.
o Slots
This field displays the total number of slots in the cache.
o len
This field displays the length (ie, width) of each slot in the
cache.
2.39 – Row Cache Overview inserts screen
This screen provides summary Row Cache information for active
caches ordered by number of cache inserts. This screen provides
the following information:
o Cache.Name
This field displays the cache name.
o Searches
This field displayes the number of times the row cache was
searched for a specific row (DBKEY).
o Hit%
This field displays the percentage of cache searches that were
satistified by the cache (ie, the row was found in the cache).
o Full%
This field displays the percentage of the slots in the cache
that are not empty.
o Inserts
This field displays the number of times new rows have been
inserted into the row cache.
o Wrap
This field displays the number of times the row cache "insert
cursor" reached the end of the cache and started over at the
beginning of the cache.
o Slots
This field displays the total number of slots in the cache.
o len
This field displays the length (ie, width) of each slot in the
cache.
2.40 – Row Cache Overview Alphabetical screen
This screen provides summary Row Cache information for active
caches ordered by cache names. This screen provides the following
information:
o Cache.Name
This field displays the cache name.
o Searches
This field displayes the number of times the row cache was
searched for a specific row (DBKEY).
o Hit%
This field displays the percentage of cache searches that were
satistified by the cache (ie, the row was found in the cache).
o Full%
This field displays the percentage of the slots in the cache
that are not empty.
o Inserts
This field displays the number of times new rows have been
inserted into the row cache.
o Wrap
This field displays the number of times the row cache "insert
cursor" reached the end of the cache and started over at the
beginning of the cache.
o Slots
This field displays the total number of slots in the cache.
o len
This field displays the length (ie, width) of each slot in the
cache.
2.41 – Row Cache Overview wraps screen
This screen provides summary Row Cache information for active
caches ordered by the count of cache insert cursor wraps. This
screen provides the following information:
o Cache.Name
This field displays the cache name.
o Searches
This field displayes the number of times the row cache was
searched for a specific row (DBKEY).
o Hit%
This field displays the percentage of cache searches that were
satistified by the cache (ie, the row was found in the cache).
o Full%
This field displays the percentage of the slots in the cache
that are not empty.
o Inserts
This field displays the number of times new rows have been
inserted into the row cache.
o Wrap
This field displays the number of times the row cache "insert
cursor" reached the end of the cache and started over at the
beginning of the cache.
o Slots
This field displays the total number of slots in the cache.
o len
This field displays the length (ie, width) of each slot in the
cache.
2.42 – Row Cache Overview SlotCount screen
This screen provides summary Row Cache information for active
caches ordered by the number of cache slots. This screen provides
the following information:
o Cache.Name
This field displays the cache name.
o Searches
This field displayes the number of times the row cache was
searched for a specific row (DBKEY).
o Hit%
This field displays the percentage of cache searches that were
satistified by the cache (ie, the row was found in the cache).
o Full%
This field displays the percentage of the slots in the cache
that are not empty.
o Inserts
This field displays the number of times new rows have been
inserted into the row cache.
o Wrap
This field displays the number of times the row cache "insert
cursor" reached the end of the cache and started over at the
beginning of the cache.
o Slots
This field displays the total number of slots in the cache.
o len
This field displays the length (ie, width) of each slot in the
cache.
2.43 – Row Cache Overview SlotSize screen
This screen provides summary Row Cache information for active
caches ordered by the size (width) of cache slots. This screen
provides the following information:
o Cache.Name
This field displays the cache name.
o Searches
This field displayes the number of times the row cache was
searched for a specific row (DBKEY).
o Hit%
This field displays the percentage of cache searches that were
satistified by the cache (ie, the row was found in the cache).
o Full%
This field displays the percentage of the slots in the cache
that are not empty.
o Inserts
This field displays the number of times new rows have been
inserted into the row cache.
o Wrap
This field displays the number of times the row cache "insert
cursor" reached the end of the cache and started over at the
beginning of the cache.
o Slots
This field displays the total number of slots in the cache.
o len
This field displays the length (ie, width) of each slot in the
cache.
2.44 – Process IO Overview screen
This screen provides summary I/O information for all processes
activated to collect global statistics using the Process
Monitoring facility.
The processes displayed on this screen have previously activated
their global statistics collection. Process global statistic
collection can be either implicitly activated by the database
monitor, or explicitly activated by the RMU Show Statistic
utility.
This screen provides the following information:
o Process.ID
The process ID for the current process, assigned by the
operating system, and the stream ID, assigned by the database.
If "G" is appended to the process ID, the process had been
activated for global statistics collection; this is the normal
case. Server processes will be designated with the "s" tag.
o Sync.Reads
This field gives the number of synchronous read QIOs (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.
o SyncWrites
This field gives the number of synchronous write QIOs (queued
I/O requests) issued to the database storage area for single-
file and multifile databases (.RDA) and snapshot files (.SNP).
This operation writes modified database pages synchronously
back to the database.
o Read.Stall
This field gives the time in hundredths of a second spent
reading database pages from the database rootfile (.RDB),
storage area (.RDA) files and snapshot (.SNP) files. An
excessively high number often indicates disk contention that
might be alleviated by moving some files to other disks.
This statistic field includes both synchronous and
asynchronous I/O read stall durations.
o WriteStall
This field gives the time in hundredths of a second spent
writing database pages to the database rootfile (.RDB),
storage area (.RDA) and snapshot (.SNP) files. An excessively
high number often indicates disk contention that might be
alleviated by moving some files to other disks.
This statistic field includes both synchronous and
asynchronous I/O read stall durations.
o AsyncReads
This field gives the number of asynchronous read QIOs (queued
I/O requests) issued to the database storage area for single-
file and multifile databases (.RDA) and snapshot (.SNP) files.
This operation reads database pages asynchronously from the
database.
o AsyncWrits
This field gives the number of asynchronous write QIOs (queued
I/O requests) issued to the database storage area for single-
file and multifile databases (.RDA) and snapshot files (.SNP).
This operation writes modified database pages asynchronously
back to the database.
2.45 – Process Journal IO Overview screen
This screen provides summary RUJ and AIJ journal I/O information
for all processes activated to collect global statistics using
the Process Monitoring facility.
The processes displayed on this screen have previously activated
their global statistics collection. Process global statistic
collection can be either implicitly activated by the database
monitor, or explicitly activated by the RMU Show Statistic
utility.
This screen provides the following information:
o Process.ID
The process ID for the current process, assigned by the
operating system, and the stream ID, assigned by the database.
If "G" is appended to the process ID, the process had been
activated for global statistics collection; this is the normal
case. Server processes will be designated with the "s" tag.
o RUJ.Reads
This field gives the number of read QIOs (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.
This statistic field includes both synchronous and
asynchronous I/O read requests.
o RUJ.Writes
This field gives the number of write QIOs (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.
This statistic field includes both synchronous and
asynchronous I/O write requests.
o RUJ.Extend
This field identifies the number of times an RUJ file has been
extended. Ideally, this value should be "0" or as close to "0"
as possible. Each RUJ file extension represents a performance
bottleneck that is easily resolved.
o AIJ.Reads
The number of read QIOs 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 statistic field includes both synchronous and
asynchronous I/O read requests.
o AIJ.Writes
This field gives the total number of write QIOs (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 after-image journal to facilitate
rollforward recovery using the RMU Recover utility.
This statistic field includes both synchronous and
asynchronous I/O write requests.
o AIJ.Extend
This field identifies the number of times an after-image
journal has been extended. Ideally, this value should be
"0" or as close to "0" as possible. Each AIJ file extension
represents a performance bottleneck that is easily resolved.
2.46 – Process Lock Overview screen
This screen provides summary locking information for all
processes activated to collect global statistics using the
Process Monitoring facility.
The processes displayed on this screen have previously activated
their global statistics collection. Process global statistic
collection can be either implicitly activated by the database
monitor, or explicitly activated by the RMU Show Statistic
utility.
This screen provides the following information:
o Process.ID
The process ID for the current process, assigned by the
operating system, and the stream ID, assigned by the database.
If "G" is appended to the process ID, the process had been
activated for global statistics collection; this is the normal
case. Server processes will be designated with the "s" tag.
o Lock.Rqsts
This field gives the number of lock requests, also referred
to as "enqueue" lock requests, for new locks. Whether the lock
request succeeds or fails, it is included in this count. The
"rqsts not queued", "rqsts stalled", and "rqst deadlocks"
counts provide further detail for enqueue lock requests
statistics.
o prom.Rqsts
This field gives the number of enqueue lock requests to
promote an existing lock to a higher lock mode. Whether
or not the lock request succeeds, it is included in this
count. The "proms not queued," "proms stalled," and "prom
deadlocks" counts provide further detail for the locks
promotion statistics.
o Deadlocks
This field gives the number of stalled enqueue lock requests
to promote an existing lock that ultimately resulted in a
deadlock. Most deadlocks are tried again and resolved
o Blasted
This field gives the number of blocking ASTs, sometimes
referred to as "blasts", delivered to Oracle Rdb by the lock
manager. A blocking AST is delivered to the holder of a lock
when a lock conflict is detected, which is a good indication
of contention problems. When Oracle Rdb receives a blocking
AST, it often demotes or releases a lock in an attempt to
avoid unnecessary deadlocks.
The number of blocking ASTs reported is composed of two
different types of blocking ASTs: those generated externally
and those generated internally.
An externally generated blocking AST occurs when a blocking
AST is actually received by the process from the operating
system in response to some lock conflict with another process.
A blocking AST routine is executed and the RMU Show Statistic
utility records the blocking AST activity.
An internally generated blocking AST occurs when a lock-
blocking AST routine is executed by the process in
anticipation that the same work would have to be performed
anyway if a blocking AST were to be received from the
operating system. This algorithm serves as an optimistic
code optimization; the process, assuming it would eventually
receive a blocking AST for the particular lock, executes the
blocking AST routine. The RMU Show Statistic utility does not
differentiate between these two types of blocking ASTs.
o Demotes
This field gives the number of enqueue lock requests to demote
an existing lock to a lower lock mode. These requests always
succeed.
o Unlocks
This field gives the number of deallocating lock requests to
release an existing lock. These requests always succeed.
2.47 – Process Transaction Overview screen
This screen provides summary transaction information for all
processes activated to collect global statistics using the
Process Monitoring facility.
The processes displayed on this screen have previously activated
their global statistics collection. Process global statistic
collection can be either implicitly activated by the database
monitor, or explicitly activated by the RMU Show Statistic
utility. This screen provides the following information:
o Process.ID
The process ID for the current process, assigned by the
operating system, and the stream ID, assigned by the database.
If "G" is appended to the process ID, the process had been
activated for global statistics collection; this is the normal
case. Server processes will be designated with the "s" tag.
o Transactns
This field displays the number of transactions started.
o TxCommited
This field displays the number of transactions committed.
o TxRollback
This field displays the number of transactions rolled back.
o Checkpoint
This field displays the number of checkpoints.
o VerbSucces
This field displays the number of successful verbs.
o VerbFailur
This field displays the number of failed verbs.
2.48 – Process Object Overview screen
This screen provides summary rootfile object information for
all processes activated to collect global statistics using the
Process Monitoring facility.
The processes displayed on this screen have previously activated
their global statistics collection. Process global statistic
collection can be either implicitly activated by the database
monitor, or explicitly activated by the RMU Show Statistic
utility.
This screen provides the following information:
o Process.ID
The process ID for the current process, assigned by the
operating system, and the stream ID, assigned by the database.
If "G" is appended to the process ID, the process had been
activated for global statistics collection; this is the normal
case. Server processes will be designated with the "s" tag.
o Objs.Shrd
This field displays the number of objects that are fetched for
shared retrieval access.
o Objs.Excl
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.
o Objs.Rfrsh
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.
o Objs.Updt
This field displays the number of objects whose information
was modified. Only objects fetched for exclusive access can be
modified.
o Objs.Write
This field displays the number of objects whose information
was written back to the database root file.
o Objs.Relsd
This field displays the number of objects whose shared or
exclusive access was released to other processes.
2.49 – Process Record Overview screen
This screen provides summary record access information for
all processes activated to collect global statistics using the
Process Monitoring facility.
The processes displayed on this screen have previously activated
their global statistics collection. Process global statistic
collection can be either implicitly activated by the database
monitor, or explicitly activated by the RMU Show Statistic
utility.
This screen provides the following information:
o Process.ID
The process ID for the current process, assigned by the
operating system, and the stream ID, assigned by the database.
If "G" is appended to the process ID, the process had been
activated for global statistics collection; this is the normal
case. Server processes will be designated with the "s" tag.
o RecFetched
This field gives the number of records fetched, including
snapshot records. This field does not include records
retrieved from a temporary table.
Note that this value may be more than the actual number of
records returned by a query. The reason is that queries may
fetch records during the search phase, and then refetch the
selected records so that they may be returned to the user.
Also, for uniform format storage areas, a sequential scan
needs to fetch the "next" record on each page of the clump,
even if there are no records on that page. In addition, every
page in a uniform format storage area incurs an extra fetch to
verify that there are no more records residing on that page.
o Rec.Marked
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.
o Rec.Stored
This field gives the number of records stored in the database.
This field does not include records stored in temporary
tables.
o Pag.Checkd
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.
o PagDiscard
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.
o Rec.Erased
This field gives the number of records erased from the
database. This field does not include records erased from
temporary tables.
2.50 – Process Snapshot Overview screen
This screen provides summary record access information for
all processes activated to collect global statistics using the
Process Monitoring facility.
The processes displayed on this screen have previously activated
their global statistics collection. Process global statistic
collection can be either implicitly activated by the database
monitor, or explicitly activated by the RMU Show Statistic
utility.
This screen provides the following information:
o Process.ID
The process ID for the current process, assigned by the
operating system, and the stream ID, assigned by the database.
If "G" is appended to the process ID, the process had been
activated for global statistics collection; this is the normal
case. Server processes will be designated with the "s" tag.
o SnpRecRtrv
This field gives the number of records retrieved by read-only
transactions.
o SnpLinFtch
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.
o SnpPagRead
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.
o SnpRecStor
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.
o SnpPagFull
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.
o SnpLckCnft
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.
2.51 – AIJ Statistics screen
This screen monitors both logical and physical after-image
journaling activity.
2.52 – Group Commit Statistics screen
This screen monitors group commit activity.
2.53 – LogMiner Information screen
This screen provides online information about all "continuous"
LogMiner(tm) (usually form the RMU /UNLOAD /AFTER_JOURNAL
/CONTINUOUS command) processes. Most of the information displayed
on the screen is obtained in real time, which means that the
display is automatically updated as "continuous" LogMiner
processes read and extract after-image journal files.
The LogMiner Information screen contains multiple pages, the
number of which is determined by the number of processes running
the "continuous" LogMiner. The pages can be scrolled by using the
right angle bracket (>) key to go to the next page, or by using
the left angle bracket (<) key to go to the previous page.
The following columns provide information about processes running
the "continuous" LogMiner.
o Process.ID - The process ID and Stream ID of the Continuous
LogMiner process.
o State - The current Continuous LogMiner processing state. One
of the following:
o Inactive - Processing has not yet completed initialization
o Hibernating - Waiting for after-image journal write
activity
o Polling - Sleep/poll state while waiting for after-image
journal writing activity; after a short while, if no after-
image journal writing occurs, the Continuous LogMiner will
enter the "Hibernating" state
o Extracting - Extracting changes from one or more
transactions from the after-image journal
o SeqNum - Sequence number of the journal currently being
processed
o CurrVBN - Virtual block number of the last AIJ block read
This screen is available only if the Continuous LogMiner feature
is enabled for the database.
You cannot use the information contained in this screen on the
Custom Statistics screen.
Because the AIJ Journal Information screen provides real-time
information, the output is not recorded in the binary output file
produced using the Output qualifier. Consequently, this screen
is not available when you replay a binary file using the Input
qualifier.
2.54 – AIJ Journal Information screen
This screen provides online information about all of a database's
after-image journals on the current node. Most of the information
displayed on the screen is obtained in real time, which means
that the display is automatically updated as AIJ database
parameters are modified, or as AIJ operations such as a backup
or journal switchover are performed.
You cannot use the information contained in this screen on the
Custom Statistics screen.
Because the AIJ Journal Information screen provides real-time
information, the output is not recorded in the binary output file
produced using the Output qualifier. Consequently, this screen
is not available when you replay a binary file using the Input
qualifier.
The AIJ Journal Information screen contains multiple pages,
the number of which is determined by the number of allocated
journal slots. The pages can be scrolled by using the right angle
bracket (>) key to go to the next page, or by using the left
angle bracket (<) key to go to the previous page.
The AIJ Journal Information screen contains information relating
to AIJ journaling in general and information on each individual
journal, including reserved AIJ journal slots.
The following fields provided in the AIJ Journal Information
screen header provide information that applies to all journals:
o Journaling
Displays "Enabled" when after-image journaling is enabled and
"Disabled" when after-image journaling is disabled.
o Shutdown
If highlighted, indicates that an AIJ switchover is in
progress and identifies the number of minutes remaining until
the after-image journaling system shutdown is complete. If
no switchover is in progress, the default shutdown time, in
minutes, is displayed. Note that this field displays shutdown
information for the current node only.
o Notify
Displays "Enabled" when system operator notification is
enabled and "Disabled" when system operator notification is
disabled. This field does not identify the specific operator
classes that are enabled.
o State
Displays "Accessible" when the AIJ journals can be written to
and "Inaccessible" when they cannot be written to.
o ALS
Provides information about the AIJ log server (ALS). If the
ALS is not running, it displays the startup mode for the ALS,
either "Automatic" or "Manual." If the ALS is running, this
field displays the value "Running."
o ABS
Displays "Enabled" when the AIJ backup server is enabled
for the database, "Disabled" when the AIJ backup server is
not enabled, "Suspended" when the AIJ backup server has been
manually suspended, and "Denied" when the AIJ backup server is
not permitted due to AIJ files being overwritten or in a data-
lost condition. Note that the AIJ backup server is not always
invoked even though it is enabled; output from the RMU Dump
Header command provides more information in those situations
where the AIJ backup server is enabled but not invoked.
o ACE
Displays "Enabled" when the AIJ cache on electronic disk (ACE)
is enabled and "Disabled" when the AIJ cache on electronic
disk is not enabled. This field does not identify the name of
the file that serves as the AIJ cache on the electronic disk.
o FC
Displays "Enabled" when the fast commit transaction processing
feature is enabled and "Disabled" when it is not enabled. The
fast commit options are not displayed.
o CTJ
Displays "Enabled" when the commit to journal optimization
feature is enabled and "Disabled" when it is not enabled. The
commit to journal optimization options are not displayed.
o ARB.Count
Displays the number of AIJ request blocks (ARBs) that are in
use for the database.
o ARB.Avail:
Displays the number of AIJ request blocks (ARBs) that are
available for the database.
The following information is provided for individual after-image
journals:
o After-image journal name
Identifies the name of the after-image journal (this is not
the journal filename). If the journal is not allocated,
identifies the number of the available journal slot. The
current journal is highlighted for quick identification.
o Sequence number
Identifies the sequence number of the journal. If the journal
is unused, "Unused" is displayed.
o AIJ size
Identifies the size, in blocks, of the current after-image
journal. This value typically corresponds to the after-
image journal allocation size for fixed-size journals. If the
physical end-of-file has not yet been established, the default
allocation size, in blocks, is displayed.
o Current end of file
Identifies the block number of the current end-of-file of
the current journal; this information is only displayed
for the current journal because it is meaningless for other
journals. This value corresponds to the location in the
journal being written with data. If the journal is current
but the logical end-of-file has not yet been established,
"Unknown" is displayed. If the journal is not current, "Empty"
is displayed.
o Status
Displays "Current" if the journal is currently being written
to, "Written" if it was written to in the past, or "Latent"
if it has not yet been written to. A journal that has been
written to and is not current should be backed up; the warning
"*BACKUP NEEDED*" is displayed to help identify when a journal
needs to be backed up.
o State
Displays "Backing Up" when the journal is in the process of
being backed up, "Overwritten" when the journal has been
overwritten, "Accessible" if the journal can be written to,
and "Inaccessible" when the journal cannot be written to.
Note that information on the AIJ Journal Information screen is
for the current node only. Because an after-image journal is
accessed by all nodes modifying the database, the information
for one node could become stale. Therefore, the Refresh option on
the horizontal menu at the bottom of the AIJ Journal Information
screen is provided. The Refresh option causes the current node's
information to be synchronized with all other nodes accessing the
database.
2.55 – AIJ Journal Growth Trend screen
This screen graphically portrays the size of the current AIJ
Journal over a measured period of time. The slope of the line
can be used to visually describe the amount of information being
written to the AIJ journal.
2.56 – ALS Statistics screen
This screen contains information specific to the operation of the
AIJ Log Server process.
The ALS Statistics screen is recorded in the binary output file
produced using the Output qualifier. Consequently, this screen
is available when you replay a binary file using the Input
qualifier.
2.57 – 2PC Statistics screen
This screen provides information about distributed transaction
performance and how it differs from non-distributed transaction
performance.
The 2PC Statistics screen is recorded in the binary output file
produced using the Output qualifier. Consequently, this screen
is available when you replay a binary file using the Input
qualifier.
2.58 – RUJ Statistics screen
This screen contains summary information for all active update
transactions on the current node.
The RUJ Statistics screen is recorded in the binary output file
produced using the Output qualifier. Consequently, this screen
is available when you replay a binary file using the Input
qualifier.
2.59 – Fast Incr Backup Statistics screen
This screen displays statistics about the fast incremental backup feature.
2.60 – Checkpoint Statistics screen
This screen shows transaction and checkpoint activity. Statistics
are displayed for all processes on the node for a particular
database. The total number of checkpoints, with a breakdown
of the reasons for checkpointing, is displayed. The sum of all
checkpoint intervals is also displayed, using three different
metrics. You can use this information to compute the average
interval between checkpoints, allowing you to decide if a
checkpointing interval should be adjusted, and by how much.
Some of the columns provided by the Checkpoint Statistics
screen measure events on a per second or per transaction basis.
These columns are useful for measuring frequently occurring
events such as I/O operations. Because checkpointing typically
occurs at a slower rate, you will find the most meaningful
checkpointing information in the total count column of the
Checkpoint Statistics screen. Oracle Corporation recommends that
you refer to this column when you use checkpoint statistics to
determine optimal checkpoint intervals.
2.61 – Recovery Statistics screen
This screen identifies various recovery phases and shows
information on how long each phase took to complete.
The Recovery Statistics screen is useful for identifying an
excessive number of abnormal process failures. In addition, the
screen is useful for determining the proper database attribute
and parameter settings to maximize runtime performance and
minimize recovery downtime.
Note that this screen provides global information on all failed
process recoveries, not on individual process recoveries.
The Recovery Statistics screen is recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is available when you replay a binary file using the Input
qualifier.
2.62 – Hot Standby Statistics screen
This screen provides information about the performance and state
of the Hot Standby feature.
2.63 – Synchronization Mode Statistics screen
This screen provides a breakdown of each type of synchronization
mode. The count and stall duration for each of the four
synchronization modes are displayed.
2.64 – Hot Standby Network screen
This screen displays information about active Hot Standby
connections.
2.65 – Recovery Information screen
This screen displays information about the Hot Standby recovery
operation, with regards to what type of recovery operations are
actually being performed.
2.66 – PIO Statistics Data Fetches screen
This screen provides statistics on how data page requests are
handled.
2.67 – PIO Statistics SPAM Prefetches screen
This screen provides statistics on asynchronous SPAM page
prefetching.
Asynchronous prefetching includes both traditional asynchronous
prefetching ( "APF") when pages are "known" to be needed
(as during a sequential scan of a storage area) and detected
asynchronous prefetching ( "DAPF") when a pattern of sequential
page access is noticed and pages are automatically prefetched in
anticipation.
2.68 – PIO Statistics DATA Prefetches screen
This screen provides statistics on asynchronous data page
prefetching.
Asynchronous prefetching includes both traditional asynchronous
prefetching ( "APF") when pages are "known" to be needed
(as during a sequential scan of a storage area) and detected
asynchronous prefetching ( "DAPF") when a pattern of sequential
page access is noticed and pages are automatically prefetched in
anticipation.
2.69 – PIO Statistics SPAM Fetches screen
This screen provides statistics on how SPAM page requests are
handled.
2.70 – PIO Statistics SPAM Access screen
This screen displays statistics about why the SPAM page was
accessed. You can identify excessive SPAM fetches by comparing
the "record store fet" field to the "record store upd" and
"record stored" fields.
The SPAM Access screen is recorded in the binary output file
produced using the Output qualifier. Consequently, this screen
is available when you replay a binary file using the Input
qualifier.
2.71 – PIO Statistics Data Writes screen
This screen provides information concerning data file writes and
buffer unmarking activity (buffer writes to the disk).
2.72 – PIO Statistics SPAM Writes screen
This screen provides information concerning SPAM file writes.
2.73 – PIO Statistics File Access screen
This screen provides information concerning file access. The
stall times are displayed in hundredths of a second.
2.74 – Asynchronous IO Statistics screen
This screen provides information concerning asynchronous reads
and writes to the database files. The stall times are displayed
in hundredths of a second.
2.75 – IO Stall Time seconds x100 screen
This screen shows a summary of I/O stall activity. All times are
displayed in hundredths of a second.
2.76 – GB utilization screen
This screen displays the utilization of each page in a global
buffer. Because there can be many times more buffers and pages
than displayable geography, this screen contains multiple pages.
Use the left angle bracket (<) key to go to the previous page
and the right angle bracket (>) key to go to the next page of the
screen.
This screen is organized in units of buffers. Each "|" delineates
a buffer. Each character between "|"s represents a single page.
A buffer can contain fewer than the maximum number of pages,
depending on the various storage area page sizes. Inadmissible
pages are marked using underscore ("_") and can be ignored.
The number of users sharing a particular page is known as the
share-count. This screen is based on a display-threshold that
is compared against the number of users sharing a particular
page. Initially, the display threshold value is 1. The display
threshold can be configured, as described below.
Page share-counts are identified as follows:
o Space (" ")- A page with a share-count less than the display-
threshold
o Dot (".")- A page with a share-count identical to the display-
threshold
o Digit from 2 through 9- A page with share-count that exceeds
the display-threshold but is less than ten, identified by the
respective digit
o Asterisk ("*")- A page with share-count that exceeds the
display-threshold by 10 or more
A row of "X"s delineates the end of the global buffer pool. All
blank lines following the row of "X"s can be ignored.
As a general measure of global buffer pool utilization when using
the default display-threshold, a display containing a lot of
blanks is not good; this probably indicates that the global
buffer pool is sized too large for the current number of users
accessing the database. A display containing a lot of dots (".")
is not good since this indicates non-sharing of pages; this
probably indicates that local buffers might be a better choice.
A display containing a lot of numeric digits is good, since
this indicates good page sharing. A display containing a lot
of asterisks ("*") is very good, since this indicates tremendous
page sharing.
You can use the "Config" menu option to filter the "GB
Utilization" display. Select this option, by typing the letter
C, to display the configuration submenu.
The configuration submenu contains a single option: "Filter
Utilization Display". Selecting this option will display the
prompt "Enter global buffer threshold (1+) [current=1]: ". The
threshold indicates the number of users sharing a page to be
displayed; for instance, if you entered "5" then only those pages
being accessed by 5 or more users will be displayed. Also, those
pages shared by exactly 5 users would be identified using a dot
(".") and those more than 5 would be identified using the digits
6 through 9 or the asterisk ("*") if more than nine users are
sharing a page.
This screen is not saved in the binary output file and cannot be
selected during binary file replay.
2.77 – GB hot page information screen
This screen displays a list of the "hottest", or most heavily
shared, pages in the global buffer pool. The list is sorted in
descending shared frequency and ascending starea:pageno sequence.
Since there can be many times more hot pages than displayable
geography, this screen contains multiple pages. Use the left
angle bracket (<) key to go to the previous page and the right
angle bracket (>) key to go to the next page of the screen.
The sorting sequence ensures that "page 1" contains the set of
"hottest" pages while "page n" contains the coldest pages.
This screen displays the following fields:
o Starea:PageNo- identifies the storage area number and the page
number in that storage area
o #Users- indicates the number of users sharing the page
o Version#- indicates the number of times the page has been
modified
o CkptVbn- indicates the page's current checkpoint VBN. This
field is not generally useful.
o Xfr- indicates whether or not the page is being transferred
to another user when an asterisk ("*") is displayed; this is
almost never indicated since the actual page transfer occurs
quickly.
This screen is not saved in the binary output file and cannot be
selected during binary file replay.
2.78 – GB Frequency Information screen
This screen graphically displays, in general terms, the
effectiveness of the global buffer pool for sharing of pages.
This screen contains the following fields of header information:
o Total Global Buffers- indicates the total number of buffers in
the database global buffer pool.
o Maximum Global Buffer Pages- indicates the maximum number
of pages that can reside in the global buffer pool. The
actual number of pages may be less than this value because
of different page sizes for different storage areas.
o Number of Unused Buffers- indicates the number of buffers that
are completely empty and do not contain ANY pages. This field
should always display the value "0"; any other value indicates
that the global buffer pool may be sized too large for the
currently running application.
o Number of Active Pages- indicates the actual number of pages
contained in the global buffer pool; this value will probably
be less than the Maximum Global Buffer Pages field. Active
pages can include unreferenced pages.
o Number of Unused Pages- indicates the number of pages in the
global buffer pool that are not currently referenced by any
process.
o Number of Unshared Pages- indicates the number of pages in the
global buffer pool referenced by exactly one process.
The histogram graphically displays the number of processes
referencing each page in the global buffer pool. Because of the
limited space on the histogram, each asterisk ("*") may represent
more than one page; the actual number of pages represented is
identified in the footer information.
This screen is not saved in the binary output file and cannot be
selected during binary file replay.
2.79 – File IO Overview screen
This screen shows a summary of I/O activity for all data and
snapshot files.
2.80 – File IO Overview Current Async Reads screen
This screen shows the current synchronous and asynchronous read
and write counts, sorted by descending current asynchronous read
count.
2.81 – File IO Overview Current Async Writes screen
This screen shows the current synchronous and asynchronous read
and write counts, sorted by descending current asynchronous write
count.
2.82 – File IO Overview Current Sync Reads screen
This screen shows the current synchronous and asynchronous read
and write counts, sorted by descending current synchronous read
count.
2.83 – File IO Overview Current Sync Writes screen
This screen shows the current synchronous and asynchronous read
and write counts, sorted by descending current synchronous write
count.
2.84 – File IO Overview Total Async Reads screen
This screen shows the total synchronous and asynchronous read
and write counts, sorted by descending total asynchronous read
count.
2.85 – File IO Overview Total Async Writes screen
This screen shows the total synchronous and asynchronous read
and write counts, sorted by descending total asynchronous write
count.
2.86 – File IO Overview Total I Os screen
This screen shows the total synchronous and asynchronous read and
write counts.
2.87 – File IO Overview Total Sync Reads screen
This screen shows the total synchronous and asynchronous read and
write counts, sorted by descending total synchronous read count.
2.88 – File IO Overview Total Sync Writes screen
This screen shows the total synchronous and asynchronous read
and write counts, sorted by descending total synchronous write
count.
2.89 – File IO Overview Total current I Os screen
This screen shows the total current synchronous and asynchronous
read and write counts.
2.90 – File IO Overview Unsorted current I Os screen
This screen shows the current synchronous and asynchronous read
and write counts in unsorted order.
2.91 – File IO Overview Unsorted total I O screen
This screen shows the total synchronous and asynchronous read and
write counts in unsorted order.
2.92 – File IO Overview Total Discarded screen
This screen shows the total synchronous and asynchronous read and
write counts, sorted by descending total pages discarded.
2.93 – File IO Overview Current Discarded screen
This screen shows the total synchronous and asynchronous read and
write counts, sorted by descending current pages discarded.
2.94 – File IO Overview Alphabetical screen
This screen shows the synchronous and asynchronous read and write
counts, sorted by storage area name.
You also have the following options:
o Display by storage area name within storage area type (data or
snapshot)
o Display all storage areas
o Display data storage areas only
o Display snapshot storage areas only
2.95 – Device IO Overview Current Async Reads screen
This screen shows the current synchronous and asynchronous read
and write counts, sorted by descending current asynchronous read
count. That is, the row with the highest asynchronous read I/O
rate is displayed first.
2.96 – Device IO Overview Current Async Writes screen
This screen shows the current synchronous and asynchronous read
and write counts, sorted by descending current asynchronous write
count. That is, the row with the highest asynchronous write I/O
rate is displayed first.
2.97 – Device IO Overview Current Sync Reads screen
This screen shows the current synchronous and asynchronous read
and write counts, sorted by descending current synchronous read
count. That is, the row with the highest synchronous read I/O
rate is displayed first.
2.98 – Device IO Overview Current Sync Writes screen
This screen shows the current synchronous and asynchronous read
and write counts, sorted by descending current synchronous write
count. That is, the row with the highest synchronous write I/O
rate is displayed first.
2.99 – Device IO Overview Total Async Reads screen
This screen shows the total synchronous and asynchronous read
and write counts, sorted by descending total asynchronous read
count. That is, the row with the most asynchronous read I/Os is
displayed first.
2.100 – Device IO Overview Total Async Writes screen
This screen shows the total synchronous and asynchronous read
and write counts, sorted by descending total asynchronous write
count. That is, the row with the most asynchronous write I/Os is
displayed first.
2.101 – Device IO Overview Total I Os screen
This screen shows the total synchronous and asynchronous read and
write counts, sorted by descending total read and write count.
That is, the row with the most total I/Os is displayed first.
2.102 – Device IO Overview Total Sync Reads screen
This screen shows the total synchronous and asynchronous read and
write counts, sorted by descending total synchronous read count.
That is, the row with the most synchronous read I/Os is displayed
first.
2.103 – Device IO Overview Total Sync Writes screen
This screen shows the total synchronous and asynchronous read
and write counts, sorted by descending total synchronous write
count. That is, the row with the most synchronous write I/Os is
displayed first.
2.104 – Device IO Overview Total current I Os screen
This screen shows the total current synchronous and asynchronous
read and write counts sorted by descending total read and write
rate order. That is, the row with the highest total I/O rate is
displayed first.
2.105 – Device IO Overview Unsorted current I Os screen
This screen shows the current synchronous and asynchronous read
and write counts in unsorted order. The devices are displayed in
alphabetical order.
2.106 – Device IO Overview Unsorted total I O screen
This screen shows the total synchronous and asynchronous read
and write counts in unsorted order. The devices are displayed in
alphabetical order.
2.107 – Device Information screen
This screen provides an online view of the storage-area
device information local to a particular database. The Device
Information screen has the following capabilities:
o Displays real-time information about all devices accessed by
the database.
o Displays information for devices on which the database root
file and storage areas (live and snapshot) reside.
o Displays information about all database root files and storage
areas except for AIJ, ACE, or RUJ devices.
When there is more than one page of the Device Information
screen, the header section contains the page number currently
displayed and the total number of pages in the screen. Use the
left angle bracket (<) key to go to the previous page and the
right angle bracket (>) key to go to the next page of the screen.
The Device Information screen contains the following information:
o Device.Name- The name of the device.
o Status- Any of the following status types might be displayed
in this column:
Mounted-Device is mounted and active
Valid-Device is software valid
Busy-Device is busy
MntVrfy-Device is undergoing Mount Verification
TimeOut-Device has timed out
PowerFl-Device has experienced power failure
Unknown-Device is in some unexpected state
o #Err- The number of hardware errors that have occurred on the
device since it was mounted.
o Volume.Label- The name of the device specified when it was
mounted.
o FreeBlock- The number of free (available) blocks on the
device. This number approaches zero (0) as the device becomes
full. This is one of the most important field in the screen.
o Max#Blocks- The total number of blocks in the device.
o %Full- The percentage of the disk that is full.
Note that the Device Information screen is available in replay
mode only if By Area information was recorded in the binary
output file. However, because the information is displayed
in real time, it does not reflect the time when the By Area
information was recorded.
2.108 – File IO Statistics screen
This screen allows you to display I/O statistics for each file in
the database. When you select "IO Statistics (by file)" from the
display menu, Oracle Rdb displays a list of files that comprise
the database and for which you can choose to view statistics.
With the exception of the all data/snap files screen, each screen
shows the I/O activity for a specific database file. The all data
/snap files screen shows a summary of I/O activity for all data
and snapshot files.
The information in this screen applies from the time that your
Performance Monitor session began, or since the accumulators were
last reset (using the [R]eset option). The following information
is displayed:
o total I/Os
The total number of I/O operations to the file being
displayed, broken down to the number of synchronous read,
synchronous write, extend, asynchronous read, and asynchronous
write operations. This number does not include creation or
truncation operations.
o rate per second
This section provides information on the rate at which
I/O operations are performed by the database. A single I/O
operation may access several blocks of information; thus, the
number of I/O operations does not correlate directly to the
volume of data manipulated. However, if the file is on a disk
by itself and this number is high (greater than 30 for RA8n
disks), the file may be a good candidate for partitioning.
This number also indicates how much use the file is getting,
and if the file should be on its own disk.
The information is partitioned into the following categories:
o max.
This category indicates the maximum number of operations
per second attained for synchronous read, synchronous
write, extend, asynchronous read, and asynchronous
write operations. The max. category is typically used to
differentiate peaks in performance from the system-wide
average. Note that no total figure is displayed for this
category.
o cur.
This category indicates the current number of operations
per second attained for synchronous read, synchronous
write, extend, asynchronous read, and asynchronous write
operations. This information is computed using the number
of I/O operations performed during the screen-update time
interval.
o avg...
This category indicates the average number of operations
per second attained for synchronous read, synchronous
write, extend, asynchronous read, and asynchronous
write operations. The avg. category is typically used
to determine overall system activity. Note that no total
figure is displayed for this category.
o total count
This category indicates the total number of synchronous
read, synchronous write, extend, asynchronous read, and
asynchronous write operations performed by the database.
The total count category serves as the basis for the Average
Per I/O categories. It is a good indicator of how much I/O
activity there is for a file and for comparing one file's
activity with other files in the database.
o average per trans
This category indicates the total number of synchronous read,
synchronous write, extend, asynchronous read, and asynchronous
write operations, based on the total number of application
transactions committed by all processes attached to the
database. The total number of committed transactions is
not displayed. The processing within a transaction and the
duration of a transaction for this category are determined
entirely by the application.
The average per trans category can indicate whether or not
certain transactions incur a high number of I/O operations to
accomplish a task. If you notice a number that is higher than
you expected, you should investigate further by using other
Performance Monitor options.
o blocks transferred
This section provides information on the volume of data
manipulated (transferred) by the database. Depending on the
operation, Oracle Rdb attempts to make an I/O operation do
as much work as possible by transferring as many blocks as
possible. The blocks transferred statistic shows how much work
is being done for each I/O operation. A number less than the
buffer size indicates that either SPAM pages are used heavily
(because they fill only one page), or there are contention
problems because Oracle Rdb resolves contention problems by
writing and reading pages rather than full buffers.
The information is partitioned into the following categories:
o avg. per I/O
This category indicates the average number of blocks
transferred for synchronous read, synchronous write,
extend, asynchronous read, and asynchronous write
operations, based on the total number of I/O operations
that have been performed by the database.
o total...
This category indicates the total number of blocks
transferred for synchronous read, synchronous write,
extend, asynchronous read, and asynchronous write
operations.
o stall time (x100)
This section provides information on how long processes wait
for the I/O operations to complete. Processes typically stall
due to contention for the disk by other processes. Stall time
is measured in hundredths of a second but is displayed as
whole numbers. Thus, a displayed value of 100 represents 1
second of stall time. A large number can indicate excessive
I/O activity to a file and that requests are becoming stacked
in a queue. This indicates the file is a good candidate for
partitioning or being placed on another disk. Normally, RA8n
disks should complete an I/O operation in 2/100 to 4/100 of a
second, while RD5n disks should complete an I/O operation in
5/100 to 8/100 of a second.
The information is partitioned into the following categories:
o avg. per I/O
This category indicates the average time stalled for
synchronous read, synchronous write, extend, asynchronous
read, and asynchronous write operations based on the number
of I/O operations that have been performed.
When you are displaying statistics for all data/snap files,
the value for the average stall time per I/O field may not
be what you expect if you have displayed the average stall
time per I/O for the individual .rda and .snp files in the
database. For example, it is possible for the average stall
time per I/O for the all data/snap files screen to be 1.1
when the average stall times per I/O for the .rda and .snp
files are 8.3, 5.7, 6.4, and 6.8, respectively.
Oracle Rdb issues write I/O operations in parallel,
asynchronously (this is a batch-write mechanism). This
means that the average stall time per I/O for the all data
/snap files screen is not the "average of the averages"
shown for the individual .rda and .snp files; this would
imply that the I/Os completed serially. Rather, the total
I/O stall time is "the average of the averages divided
by the number of I/Os;" the average for the all data/snap
files screen is usually a fraction of the individual file
averages because the stall time is amortized across all
I/Os issued in parallel.
For example, assume that Oracle Rdb does a batch-write
operation (all in parallel, of course) to four storage
areas. Assume that each individual storage area's I/O
operation takes 20 milliseconds. If the I/Os were done
serially, then the average stall time for all storage areas
would be 20 milliseconds. However, because the I/Os are
done in parallel, the average for all areas is actually 5
milliseconds (20 milliseconds divided by 4 I/O operations).
o total...
This category indicates the total time stalled for
synchronous read, synchronous write, extend, asynchronous
read, and asynchronous write operations.
Note that the accumulators on this screen can be reset using the
[R]eset option.
2.109 – Logical Area Statistics screen
This screen displays statistics about a specific table or index.
The output from the Logical Area Statistics screen is not written
to the output file; therefore, the output cannot be replayed
using an input file.
2.110 – Logical Area Overview Tables screen
This screen displays comparative information for all logical
areas of a particular type, on a single screen.
By default, the screen displays the four most useful statistic
fields for the respective logical area type. However, you may
configure both the statistic fields displayed as well as the type
of statistic information displayed.
The "system" logical area information can be filtered from the
display, which will result in application logical areas being
displayed only.
There is no way to "mix and match" different logical areas on the
same screen display. This is impossible because of the different
statistic information collected for different logical area types.
It is possible to zoom on a specific logical area and display its
relevant statistic information. This drill-down capability makes
the "Logical Area Overview" an extremely useful analytical tool
for identifying performance bottlenecks or potential problems.
This screen is not available if the/NOLOGICAL_AREA qualifier is
specified, or if the INPUT qualifier is specified.
This screen displays the following fields:
o Logical Area Name -This column displays the name of the
logical area, followed by a period ".", followed by the name
of the physical area (storage area) in which the logical area
partition resides.
A maximum of 20 characters is displayed when the screen width
is 80 columns, which typically results in the storage area
name being partially truncated. To display the entire storage
area name, it may be necessary to zoom on the logical area
using the Zoom on-screen menu option. Alternately, using a
width of more than 100 columns will allow the full area name
to be displayed.
For performance reasons, the logical area names are not sorted
in any particular order by default. You can configure the
screen to display the logical areas in alphabetical order.
Each logical area displayed represents a single partition of
that logical area. There is no method available to display the
logical areas aggregate statistic information.
o Statistic Field #1 - This column displays a user-selectable
statistic field appropriate for a table logical area. The
default statistic field is "record fetch."
o Statistic Field #2 - This column displays a user-selectable
statistic field appropriate for a table logical area. The
default statistic field is "record stored."
o Statistic Field #3 - This column displays a user-selectable
statistic field appropriate for a table logical area. The
default statistic field is "record erased."
o Statistic Field #4 - This column displays a user-selectable
statistic field appropriate for a table logical area. The
default statistic field is "pages discarded."
o Statistic Type - This column identifies the "type" of
statistic information being displayed. The following types
are available:
o CurTot - This column indicates the total number of
occurrences of the statistic since the database was opened
or the statistic collection information was reset; you can
reset this information using the "Reset" on-screen menu
option.
o CurRate - This column indicates the current occurrence-
per-second rate of the statistic during the last sample
interval (screen refresh); you can change the sample
interval using the "Set_rate" on-screen menu option.
o MaxRate - This column indicates the maximum occurrence-per-
second rate of the statistic since the RMU Show Statistic
utility was started or the statistic collection information
was reset; you can reset this information using the "Reset"
on-screen menu option.
o AvgRate - This column indicates the average occurrence-per-
second rate of the statistic since the database was opened
or the statistic collection information was reset; you can
reset this information using the "Reset" on-screen menu
option.
o PerTrans - This column indicates the transaction average
of the total-count column and the total number of completed
transactions.
Note the following:
o The "system" logical areas can be filtered from the "Logical
Area Overview" screen by selecting the "Display application
logical areas" option of the "Tools" menu. System logical
areas can be included on the screen by selecting the "Display
all logical areas" option of the "Tools" menu. Note that these
options are not available using the "Config" on-screen menu
option.
o The "Logical Area Overview" screen can also be configured to
display application logical areas only (no "system" logical
areas) using the configuration variable SYSTEM_LOGICAL_AREAS
with the keyword FALSE. Specifying the configuration variable
with the keyword TRUE, the default, will display all logical
areas, including "system" logical areas.
o The "Logical Area Overview" screen statistic type can be
specified using the configuration variable LOGICAL_OVERVIEW_
STAT with one of the following keywords: CUR_TOTAL, CUR_RATE,
MAX_RATE, AVG_RATE or PER_TRANS.
o The "Logical Area Overview" screen logical area type can be
specified using the configuration variable LOGICAL_OVERVIEW_
TYPE with one of the following keywords: TABLE, BTREE, HASH or
BLOB.
o When selecting statistic fields for the various columns using
the "Config" on-screen menu option, no validation is performed
to eliminate duplicate selections. This means you can display
the same statistic field in one or more columns at the same
time, if you so desire.
2.111 – Logical Area Overview Btree Indexes screen
This screen displays comparative information for all logical
areas of a particular type, on a single screen.
By default, the screen displays the four most useful statistic
fields for the respective logical area type. However, you may
configure both the statistic fields displayed as well as the type
of statistic information displayed.
The "system" logical area information can be filtered from the
display, which will result in application logical areas being
displayed only.
There is no way to "mix and match" different logical areas on the
same screen display. This is impossible because of the different
statistic information collected for different logical area types.
It is possible to zoom on a specific logical area and display its
relevant statistic information. This drill-down capability makes
the "Logical Area Overview" an extremely useful analytical tool
for identifying performance bottlenecks or potential problems.
This screen is not available if the/NOLOGICAL_AREA qualifier is
specified, or if the INPUT qualifier is specified.
This screen displays the following fields:
o Logical Area Name -This column displays the name of the
logical area, followed by a period ".", followed by the name
of the physical area (storage area) in which the logical area
partition resides.
A maximum of 20 characters is displayed with a screen width of
80 columns, which typically results in the storage area name
being partially truncated. To display the entire storage area
name, it may be necessary to zoom on the logical area using
the Zoom on-screen menu option. Alternate, a screen width of
more than 100 columns can be used to display the full area
name.
For performance reasons, the logical area names are not sorted
in any particular order by default. You can configure the
screen to display the logical areas in alphabetical order.
Each logical area displayed represents a single partition of
that logical area. There is no method available to display the
logical areas aggregate statistic information.
o Statistic Field #1 - This column displays a user-selectable
statistic field appropriate for a B-tree index logical area.
The default statistic field is "leaf fetches."
o Statistic Field #2 - This column displays a user-selectable
statistic field appropriate for a B-tree index logical area.
The default statistic field is "leaf insertion."
o Statistic Field #3 - This column displays a user-selectable
statistic field appropriate for a B-tree index logical area.
The default statistic field is "leaf removal."
o Statistic Field #4 - This column displays a user-selectable
statistic field appropriate for a B-tree index logical area.
The default statistic field is "pages discarded."
o Statistic Type - This column identifies the "type" of
statistic information being displayed. The following types
are available:
o CurTot - This column indicates the total number of
occurrences of the statistic since the database was opened
or the statistic collection information was reset; you can
reset this information using the "Reset" on-screen menu
option.
o CurRate - This column indicates the current occurrence-
per-second rate of the statistic during the last sample
interval (screen refresh); you can change the sample
interval using the "Set_rate" on-screen menu option.
o MaxRate - This column indicates the maximum occurrence-per-
second rate of the statistic since the RMU Show Statistic
utility was started or the statistic collection information
was reset; you can reset this information using the "Reset"
on-screen menu option.
o AvgRate - This column indicates the average occurrence-per-
second rate of the statistic since the database was opened
or the statistic collection information was reset; you can
reset this information using the "Reset" on-screen menu
option.
o PerTrans - This column indicates the transaction average
of the total-count column and the total number of completed
transactions.
Note the following:
o The "system" logical areas can be filtered from the "Logical
Area Overview" screen by selecting the "Display application
logical areas" option of the "Tools" menu. System logical
areas can be included on the screen by selecting the "Display
all logical areas" option of the "Tools" menu. Note that these
options are not available using the "Config" on-screen menu
option.
o The "Logical Area Overview" screen can also be configured to
display application logical areas only (no "system" logical
areas) using the configuration variable SYSTEM_LOGICAL_AREAS
with the keyword FALSE. Specifying the configuration variable
with the keyword TRUE, the default, will display all logical
areas, including "system" logical areas.
o The "Logical Area Overview" screen statistic type can be
specified using the configuration variable LOGICAL_OVERVIEW_
STAT with one of the following keywords: CUR_TOTAL, CUR_RATE,
MAX_RATE, AVG_RATE or PER_TRANS.
o The "Logical Area Overview" screen logical area type can be
specified using the configuration variable LOGICAL_OVERVIEW_
TYPE with one of the following keywords: TABLE, BTREE, HASH or
BLOB.
o When selecting statistic fields for the various columns using
the "Config" on-screen menu option, no validation is performed
to eliminate duplicate selections. This means you can display
the same statistic field in one or more columns at the same
time, if you so desire.
2.112 – Logical Area Overview Hash Indexes screen
This screen displays comparative information for all logical
areas of a particular type, on a single screen.
By default, the screen displays the four most useful statistic
fields for the respective logical area type. However, you may
configure both the statistic fields displayed as well as the type
of statistic information displayed.
The "system" logical area information can be filtered from the
display, which will result in application logical areas being
displayed only.
There is no way to "mix and match" different logical areas on the
same screen display. This is impossible because of the different
statistic information collected for different logical area types.
It is possible to zoom on a specific logical area and display its
relevant statistic information. This drill-down capability makes
the "Logical Area Overview" an extremely useful analytical tool
for identifying performance bottlenecks or potential problems.
This screen is not available if the /NOLOGICAL_AREA qualifier is
specified, or if the INPUT qualifier is specified.
This screen displays the following fields:
o Logical Area Name -This column displays the name of the
logical area, followed by a period ".", followed by the name
of the physical area (storage area) in which the logical area
partition resides.
A maximum of 20 characters is displayed when the screen width
is 80 columns, which typically results in the storage area
name being partially truncated. To display the entire storage
area name, it may be necessary to zoom on the logical area
using the Zoom on-screen menu option. Alternately, a screen
width of more than 100 columns can be used to display the
entire area name.
For performance reasons, the logical area names are not sorted
in any particular order by default. You can configure the
screen to display the logical areas in alphabetical order.
Each logical area displayed represents a single partition of
that logical area. There is no method available to display the
logical areas aggregate statistic information.
o Statistic Field #1 - This column displays a user-selectable
statistic field appropriate for a hashed index logical area.
The default statistic field is "hash index fetched."
o Statistic Field #2 - This column displays a user-selectable
statistic field appropriate for a hashed index logical area.
The default statistic field is "hash insertion."
o Statistic Field #3 - This column displays a user-selectable
statistic field appropriate for a hashed index logical area.
The default statistic field is "hash deletion."
o Statistic Field #4 - This column displays a user-selectable
statistic field appropriate for a hashed index logical area.
The default statistic field is "pages discarded."
o Statistic Type - This column identifies the "type" of
statistic information being displayed. The following types
are available:
o CurTot - This column indicates the total number of
occurrences of the statistic since the database was opened
or the statistic collection information was reset; you can
reset this information using the "Reset" on-screen menu
option.
o CurRate - This column indicates the current occurrence-
per-second rate of the statistic during the last sample
interval (screen refresh); you can change the sample
interval using the "Set_rate" on-screen menu option.
o MaxRate - This column indicates the maximum occurrence-per-
second rate of the statistic since the RMU Show Statistic
utility was started or the statistic collection information
was reset; you can reset this information using the "Reset"
on-screen menu option.
o AvgRate - This column indicates the average occurrence-per-
second rate of the statistic since the database was opened
or the statistic collection information was reset; you can
reset this information using the "Reset" on-screen menu
option.
o PerTrans - This column indicates the transaction average
of the total-count column and the total number of completed
transactions.
Note the following:
o The "system" logical areas can be filtered from the "Logical
Area Overview" screen by selecting the "Display application
logical areas" option of the "Tools" menu. System logical
areas can be included on the screen by selecting the "Display
all logical areas" option of the "Tools" menu. Note that these
options are not available using the "Config" on-screen menu
option.
o The "Logical Area Overview" screen can also be configured to
display application logical areas only (no "system" logical
areas) using the configuration variable SYSTEM_LOGICAL_AREAS
with the keyword FALSE. Specifying the configuration variable
with the keyword TRUE, the default, will display all logical
areas, including "system" logical areas.
o The "Logical Area Overview" screen statistic type can be
specified using the configuration variable LOGICAL_OVERVIEW_
STAT with one of the following keywords: CUR_TOTAL, CUR_RATE,
MAX_RATE, AVG_RATE or PER_TRANS.
o The "Logical Area Overview" screen logical area type can be
specified using the configuration variable LOGICAL_OVERVIEW_
TYPE with one of the following keywords: TABLE, BTREE, HASH or
BLOB.
o When selecting statistic fields for the various columns using
the "Config" on-screen menu option, no validation is performed
to eliminate duplicate selections. This means you can display
the same statistic field in one or more columns at the same
time, if you so desire.
2.113 – Logical Area Overview Blobs screen
This screen displays comparative information for all logical
areas of a particular type, on a single screen.
By default, the screen displays the four most useful statistic
fields for the respective logical area type. However, you may
configure both the statistic fields displayed as well as the type
of statistic information displayed.
The "system" logical area information can be filtered from the
display, which will result in application logical areas being
displayed only.
There is no way to "mix and match" different logical areas on the
same screen display. This is impossible because of the different
statistic information collected for different logical area types.
It is possible to zoom on a specific logical area and display its
relevant statistic information. This drill-down capability makes
the "Logical Area Overview" an extremely useful analytical tool
for identifying performance bottlenecks or potential problems.
This screen is not available if the/NOLOGICAL_AREA qualifier is
specified, or if the INPUT qualifier is specified.
This screen displays the following fields:
o Logical Area Name -This column displays the name of the
logical area, followed by a period ".", followed by the name
of the physical area (storage area) in which the logical area
partition resides.
A maximum of 20 characters is displayed when the screen width
is 80 columns, which typically results in the storage area
name being partially truncated. To display the entire storage
area name, it may be necessary to zoom on the logical area
using the Zoom on-screen menu option. Alternately, a screen
width of more than 100 columns can be used to display the
entire name.
For performance reasons, the logical area names are not sorted
in any particular order by default. You can configure the
screen to display the logical areas in alphabetical order.
Each logical area displayed represents a single partition of
that logical area. There is no method available to display the
logical areas aggregate statistic information.
o Statistic Field #1 - This column displays a user-selectable
statistic field appropriate for a blob logical area. The
default statistic field is "blob fetched."
o Statistic Field #2 - This column displays a user-selectable
statistic field appropriate for a blob logical area. The
default statistic field is "blob stored."
o Statistic Field #3 - This column displays a user-selectable
statistic field appropriate for a blob logical area. The
default statistic field is "blob erased."
o Statistic Field #4 - This column displays a user-selectable
statistic field appropriate for a blob logical area. The
default statistic field is "pages discarded."
o Statistic Type - This column identifies the "type" of
statistic information being displayed. The following types
are available:
o CurTot - This column indicates the total number of
occurrences of the statistic since the database was opened
or the statistic collection information was reset; you can
reset this information using the "Reset" on-screen menu
option.
o CurRate - This column indicates the current occurrence-
per-second rate of the statistic during the last sample
interval (screen refresh); you can change the sample
interval using the "Set_rate" on-screen menu option.
o MaxRate - This column indicates the maximum occurrence-per-
second rate of the statistic since the RMU Show Statistic
utility was started or the statistic collection information
was reset; you can reset this information using the "Reset"
on-screen menu option.
o AvgRate - This column indicates the average occurrence-per-
second rate of the statistic since the database was opened
or the statistic collection information was reset; you can
reset this information using the "Reset" on-screen menu
option.
o PerTrans - This column indicates the transaction average
of the total-count column and the total number of completed
transactions.
Note the following:
o The "system" logical areas can be filtered from the "Logical
Area Overview" screen by selecting the "Display application
logical areas" option of the "Tools" menu. System logical
areas can be included on the screen by selecting the "Display
all logical areas" option of the "Tools" menu. Note that these
options are not available using the "Config" on-screen menu
option.
o The "Logical Area Overview" screen can also be configured to
display application logical areas only (no "system" logical
areas) using the configuration variable SYSTEM_LOGICAL_AREAS
with the keyword FALSE. Specifying the configuration variable
with the keyword TRUE, the default, will display all logical
areas, including "system" logical areas.
o The "Logical Area Overview" screen statistic type can be
specified using the configuration variable LOGICAL_OVERVIEW_
STAT with one of the following keywords: CUR_TOTAL, CUR_RATE,
MAX_RATE, AVG_RATE or PER_TRANS.
o The "Logical Area Overview" screen logical area type can be
specified using the configuration variable LOGICAL_OVERVIEW_
TYPE with one of the following keywords: TABLE, BTREE, HASH or
BLOB.
o When selecting statistic fields for the various columns using
the "Config" on-screen menu option, no validation is performed
to eliminate duplicate selections. This means you can display
the same statistic field in one or more columns at the same
time, if you so desire.
2.114 – Locking total locks screen
This screen monitors the total database locking activity. The statistics in this screen are the totals for all types of database locks.
2.115 – Locking area locks screen
This screen monitors the database physical area locks.
2.116 – Locking buffer page locks screen
This screen monitors the database page locks. Page locks are used
to manage the database page buffer pool.
2.117 – Locking record locks screen
This screen monitors the database record locks. Record locks are
used to maintain the logical consistency of the database. All
record locks in the adjustable lock granularity tree are included
here.
2.118 – Locking SEQBLK lock screen
This screen monitors the database sequence block (SEQBLK) locks.
The SEQBLK locks maintain global transaction sequence numbers or
transaction and commit sequence numbers and control COMMIT and
ROLLBACK operations.
2.119 – Locking FILID locks screen
This screen monitors the database file identification (FILID)
locks. The FILID locks are used to maintain consistent end-of-
file information for .rdb, .rda, and .snp database files.
2.120 – Locking TSNBLK locks screen
This screen monitors the database transaction block (TSNBLK)
locks. The TSNBLK locks are used to 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.
2.121 – Locking RTUPB lock screen
This screen monitors the database run-time user process block
(RTUPB) lock. The RTUPB lock is used to maintain a consistent
list of the users who are attached to the database.
2.122 – Locking ACTIVE lock screen
This screen monitors the database ACTIVE user bit map lock. The
ACTIVE lock is used to maintain a consistent list (in bit map
form) of the users who are attached to the database.
2.123 – Locking MEMBIT lock screen
This screen monitors the database MEMBIT node bit map lock. The
MEMBIT lock is used to maintain a consistent list (in bit map
form) of the nodes on which the database is currently accessed.
2.124 – Locking AIJ locks screen
This screen monitors the after-image journal (AIJ) locks. The AIJ
locks are used to control reading and writing to the .aij file.
One global AIJ lock maintains current end-of-file information. In
addition, one local AIJ lock on each VMScluster node manages the
global AIJ buffers on that node.
2.125 – Locking snapshot locks screen
This screen monitors the database snapshot locks. The snapshot
locks are used to 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.
2.126 – Locking freeze lock screen
This screen monitors the database freeze lock. The freeze lock
is used to suspend database activity while a database recovery
process is running.
2.127 – Locking quiet point lock screen
This screen monitors 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.
2.128 – Locking logical area locks screen
This screen monitors database logical area locks. Logical area
locks are obtained when Oracle Rdb readies tables. Lock carryover
can help reduce the number of logical area locks.
2.129 – Locking nowait transaction screen
This screen monitors the database nowait transaction lock.
2.130 – Locking CLIENT locks screen
This screen monitors the database client information (CLIENT)
locks. The CLIENT locks are used to provide serialized access to
the database metadata stored in the system relations. The CLIENT
locks are also used to serialize operations such as creating
tables and indices.
2.131 – Locking locks requested screen
This screen monitors the number of enqueue lock requests for new
locks. Whether the lock request succeeds or fails, it is included
in these counts.
2.132 – Locking rqsts not queued screen
This screen monitors 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. These numbers are one measure of
lock contention.
2.133 – Locking rqsts stalled screen
This screen monitors the number of enqueue lock requests for
new locks that were stalled because of a lock conflict. Whether
the lock requests ultimately succeed or fail (resulting in a
deadlock), they are included in these counts. These numbers are
one measure of lock contention.
2.134 – Locking rqst timeouts screen
This screen monitors the total number of lock requests that
could not be granted because they timed out. These are typically
logical areas.
2.135 – Locking rqst deadlocks screen
This screen monitors the number of stalled enqueue lock requests
for new locks that ultimately resulted in a deadlock. Most
deadlocks are resolved and retried by Oracle Rdb transparently
to the application program, therefore these numbers do not
necessarily reflect the number of deadlocks reported to the
application program.
2.136 – Locking locks promoted screen
This screen monitors the number of enqueue lock requests to
promote an existing lock to a higher lock mode. Whether the lock
requests succeed or fail, they are included in these counts.
2.137 – Locking proms not queued screen
This screen monitors 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, and, when a conflict is detected, resorts to a secondary
locking protocol to avoid unnecessary deadlocks. These numbers
are one measure of lock contention.
2.138 – Locking proms stalled screen
This screen monitors 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 the lock requests ultimately
succeed or fail (resulting in a deadlock), they are included in
these counts. These numbers are one measure of lock contention.
2.139 – Locking prom timeouts screen
This screen monitors the number of lock promotions that could not
be granted because they timed out. These are typically logical
areas.
2.140 – Locking prom deadlocks screen
This screen monitors the number of stalled enqueue lock requests
to promote an existing lock to a higher lock mode that ultimately
resulted in a deadlock. Most deadlocks are resolved and retried
by Oracle Rdb transparently to the application program, therefore
these numbers do not necessarily reflect the number of deadlocks
reported to the application program.
2.141 – Locking locks demoted screen
This screen monitors the number of enqueue lock requests to
demote an existing lock to a lower lock mode. These requests
always succeed.
2.142 – Locking locks released screen
This screen monitors 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.143 – Locking blocking ASTs screen
This screen monitors 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. When Oracle Rdb receives a blocking
AST, it often demotes or releases a lock in an attempt to avoid
unnecessary deadlocks.
2.144 – Locking stall time x100 screen
This screen monitors 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. These statistics give
a relative measure of work lost due to lock conflicts.
2.145 – File Lock Overview Unsorted screen
This screen shows locking statistics for all the active storage
area and snapshot files in unsorted order.
2.146 – File Lock Overview Locks screen
This screen shows locking statistics for all the active storage
area and snapshot files sorted by lock requests.
2.147 – File Lock Overview Promotions screen
This screen shows locking statistics for all the active storage
area and snapshot files sorted by promotion requests.
2.148 – File Lock Overview LOCKS PROMOTES screen
This screen shows locking statistics for all the active storage
area and snapshot files sorted by lock requests and promotion
requests.
2.149 – File Lock Overview DEMOTES screen
This screen shows locking statistics for all the active storage
area and snapshot files sorted by locks that have been demoted.
2.150 – File Lock Overview unlocks screen
This screen shows locking statistics for all the active storage
area and snapshot files sorted by locks that have been released.
2.151 – File Lock Overview DEMOTES UNLOCKS screen
This screen shows locking statistics for all the active storage
area and snapshot files sorted by locks that have been demoted
and locks that have been released.
2.152 – File Lock Overview Total Locks screen
This screen shows locking statistics for all the active storage
area and snapshot files sorted by total lock requests.
2.153 – File Lock Overview Alphabetical screen
This screen shows locking statistics for all the active storage
area and snapshot files sorted alphabetically.
You also have the following options:
o Display by storage area name within storage area type (data or
snapshot)
o Display all storage areas
o Display data storage areas only
o Display snapshot storage areas only
2.154 – File Locking Statistics screen
This screen displays information about page locks that are
specific to storage areas and snapshot files. This information
is vital in determining which storage areas have the most
locking activity, and analyzing the validity of storage area
partitioning.
You cannot use the information contained on the Lock Statistics
(by file) screens on the Custom Statistics screen.
Use the left angle bracket (<) key to go to the previous page
and the right angle bracket (>) key to go to the next page of the
screen.
The Lock Statistics screens are recorded in the binary output
file produced using the Output qualifier. Consequently, the
screens are available when you replay a binary file using the
Input qualifier.
2.155 – General Information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The General Information screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.156 – Buffer Information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The Buffer Information screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.157 – Lock Information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The Lock Information screen is not recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is not available when you replay a binary file using the
Input qualifier.
2.158 – Storage Area Information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The Storage Area Information screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.159 – Row Cache Information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The Row Cache Information screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.160 – Journaling Information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The Journaling Information screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.161 – Journal information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The Journal Information screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.162 – Fast Commit Information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The Fast Commit screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this screen
is not available when you replay a binary file using the Input
qualifier.
2.163 – Hot Standby Information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The Hot Standby screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this screen
is not available when you replay a binary file using the Input
qualifier.
2.164 – Audit Information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The Audit Information screen is not recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is not available when you replay a binary file using the
Input qualifier.
2.165 – Active User Information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The Active User Information screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.166 – Statistics Event Information screen
This screen displays dynamic information that automatically
changes to reflect database parameter modifications.
However, because the information is local to the node from which
you are running the Performance Monitor, the modifications
you make to database parameters on other cluster nodes may
not be visible immediately on the local node. You can either
wait for the screen to eventually refresh itself, or you can
use the Refresh menu option to periodically refresh the screen
information.
You cannot use the information contained in this screen on the
Custom Statistics screen.
The Statistics Event Information screen is not recorded in
the binary output file produced using the Output qualifier.
Consequently, this screen is not available when you replay a
binary file using the Input qualifier.
2.167 – OPENVMS SYSGEN Parameters screen
This screen shows some of the OpenVMS SYSGEN parameters that are
useful for analyzing database performance characteristics.
The displayed parameters are listed in alphabetical order for
quick review.
The OpenVMS SYSGEN parameters are not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.168 – TSNBLK Allocation screen
This screen provides runtime information about the allocation of
TSNBLK entries in the database root file.
Each TSNBLK entry controls the allocation of processes to nodes,
and records the allocation and state of each process' TSN
information. Consequently, each TSNBLK entry contains valuable
information about the runtime state of the database.
The screen is not recorded in the binary output file, nor is it
available when replaying a binary input file.
This screen displays cluster-wide information. However,
information concerning nodes other than the current node may
occasionally become stale, as the Performance Monitor does not
automatically refresh the cluster information; it relies on
application processes to do this. If you believe the information
displayed is stale, use the Refresh menu option to force a
refresh of the cluster information; however, this is seldom
necessary.
This screen displays one line of information for each TSNBLK
entry. Each TSNBLK entry contains the following fields:
o TSNBLK This field identifies the TSNBLK entry number for easy
identification. This is not the block number where the TSNBLK
entry resides in the database root file.
o Nodename. This field identifies the name of the node to which
a TSNBLK is allocated. If the TSNBLK is not allocated to any
node, the name "available" is displayed.
Once a TSNBLK entry has been allocated to a particular node,
it remains allocated to that node until all processes assigned
to the TSNBLK have detached from the database.
o #Idle This field identifies the total number of idle processes
assigned to the TSNBLK entry. An idle process is one which
does not have an active transaction.
This field ideally should always display the value "0".
o #RwTx This field identifies the total number of processes
assigned to the TSNBLK entry that have an active read/write
transaction.
o #RoTx This field identifies the total number of processes
assigned to the TSNBLK entry that have an active read-only
transaction.
o #Actv This field identifies the total number of active
processes assigned to the TSNBLK entry. The value of this
field includes server processes.
o #Srvr This field identifies the total number of database
server processes assigned to the TSNBLK entry. Database
server processes include the ABS, ALS, LCS, LRS, RCS, and
DBR processes.
o #Free This field identifies the total number of processes that
remain to be assigned to the TSNBLK entry.
o CommitTSN This field identifies the last commit transaction
TSN for this TSNBLK entry.
o OldestTSN This field identifies the oldest active transaction
TSN for this TSNBLK entry.
Use the Zoom menu option to display additional information about
the processes assigned to a particular TSNBLK entry.
2.169 – Row Cache by cache screen
This screen provides summary information for a specific row
cache.
The Row Cache screen is written to the binary output file when
either the Option=Row_Cache or Option=All command qualifier
is specified. This screen is only available during replay when
either of these qualifiers was specified for the creation of the
binary input file.
2.170 – Row cache Latch requests screen
This screen displays the statistics for the number of latch
requests that have occurred.
2.171 – Row cache retried screen
This screen displays the statistics for the number of times
the latch had to be requested again. This screen provides an
indication of the contention on the row cache.
2.172 – Row cache cache searches screen
This screen displays the statistics for the number of times the
row cache was searched for a particular row (DBKEY).
2.173 – Row cache found in workset screen
This screen displays the statistics for the number of times the
row was found in the process' working set and no additional work
was required to fetch the row.
2.174 – Row cache found in cache screen
This screen displays the statistics for the number of times the
row was found in the global row cache.
2.175 – Row cache found too big screen
This screen displays the statistics for the number of times the
row was found in the global row cache, but the row was too large
to fit into the specified cache buffer. At one time, the row fit
into the cache. Therefore, the cache effectiveness is reduced
because a cache entry is reserved for the row but no row caching
is possible.
2.176 – Row cache insert cache screen
This screen displays the statistics for the number of times new
rows have been inserted into the row cache.
2.177 – Row cache row too big screen
This screen displays the statistics for the number of times rows
were too large to fit into the specified row cache buffer.
2.178 – Row cache cache full screen
This screen displays the statistics for all row cache entries
that 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.
2.179 – Row cache collision screen
This screen displays the statistics for the total number of row
cache hash table collisions that occurred when inserting new
rows. This screen provides an indication of the effectiveness of
the cache size.
2.180 – Row cache vlm requests screen
This screen displays the number of VLM requests made.
2.181 – Row cache window turns screen
This screen displays the number of VLM requests made for which
the VLM address range was not immediately available.
2.182 – Row cache skipped dirty slot screen
This screen displays the total number of cache entries that could
not be replaced because the slot contained modified data rows.
This screen provides an indication of the relative amount of
work required to find space in order to insert a new row into the
cache.
2.183 – Row cache skipped inuse slot screen
This screen displays the total number of cache entries that
could not be replaced because the slot was referenced by other
processes. This screen provides an indication of the relative
amount of work required to find space in order to insert a new
row into the cache.
2.184 – Row cache hash misses screen
This screen displays the total number of times the row cache hash
table overflowed.
2.185 – Row cache cache unmark screen
This screen 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.
2.186 – Row Cache Utilization screen
This screen provides utilization information in a graphical
format for each row in a specific row cache.
This screen is organized in units of cache entries. Each
character of the screen identifies a single cache entry.
The number of users sharing a particular row cache entry is known
as the share-count. This screen is based on a display-threshold
that is compared against the number of users sharing a particular
row. Initially, the display threshold value is 1. The display
threshold can be configured, as described below.
Cache entries are identified as follows:
o Space (" ")- Cache entry is empty
o Dot (".")- A cache entry with a share-count less than the
display-threshold
o Equal sign ("=")- A cache entry with a share-count identical
to the display-threshold
o Digit from 2 through 9- A cache entry with share-count that
exceeds the display-threshold but is less than ten, identified
by the respective digit
o Asterisk ("*")- A cache entry with share-count that exceeds
the display-threshold by 10 or more
o Highlighted entry- Cache entry has been modified
o T- Cache entry is too large for the buffer
A row of "X"s delineates the end of the row cache. All blank
lines following the row of "X"s can be ignored.
As a general measure of row cache utilization when using the
default display-threshold, a display containing a lot of blanks
or dots is very bad; this probably indicates that the row cache
is sized too large for the current number of users accessing
the database. A display containing a lot of equal signs (=)
is bad since this indicates non-sharing of rows; this probably
indicates that using a row cache may not be appropriate. A
display containing a lot of numeric digits is good, since
this indicates good row sharing. A display containing a lot
of asterisks (*) is great, since this indicates tremendous row
sharing.
You can use the Config menu option to filter the Row Cache
Utilization screen. Select this option, by typing the letter C,
to display the configuration submenu. The configuration submenu
contains a single option: "Filter Utilization Display". Selecting
this option will display the prompt "Enter row cache threshold
(0+) [current=1]: ". The threshold indicates the number of users
sharing a row to be displayed; for instance, if you entered "5"
then only those rows being accessed by 5 or more users will be
displayed. Also, those rows shared by exactly 5 users would be
identified using an equal sign (=) and those more than 5 would
be identified using the digits 6 through 9 or the asterisk (*) if
more than nine users are sharing a row.
When there is more than one page of the Row Cache Utilization
screen, the header section contains the page number currently
displayed and the total number of pages in the screen. Use the
left angle bracket (<) key to go to the previous page and the
right angle bracket (>) key to go to the next page of the screen.
The Row Cache Utilization screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.187 – Hot Row Information screen
This screen displays a list of the most frequently accessed rows
for a specific row cache.
The Hot Row Information screen contains a list of the hottest, or
most heavily shared, rows in the row cache. The list is sorted in
descending shared frequency and ascending DBKEY sequence.
The sorting algorithm ensures that the first displayed page
contains the set of hottest rows while the last displayed page
contains the coldest rows.
In order to display the largest possible amount of information,
the Hot Row Information screen is divided into two columns. The
information should be viewed from left-to-right, and top-to-
bottom. For example, the left column of row 1 contains the first
hottest row, while the right column of row 1 contains the second
hottest row, and so on.
This screen displays the following fields:
o Area:Page:Ln- identifies the DBKEY of the row
The value Empty:n indicates an empty cache entry with its
corresponding slot number for identification.
o #Users- indicates the number of users sharing the row
o D- indicates whether or not the row is dirty
The value Y indicates the row has been modified.
o O- indicates whether or not the row has overflowed
The value Y indicates the row size no longer fits into the
cache buffer.
When there is more than one page of the Hot Row Information
screen, the header section contains the page number currently
displayed and the total number of pages in the screen. Use the
left angle bracket (<) key to go to the previous page and the
right angle bracket (>) key to go to the next page of the screen.
The Hot Row Information screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.188 – Row Cache Status screen
This screen provides overall status for a specific row cache.
The Row Cache Status screen is not recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is not available when you replay a binary file using the
Input qualifier.
2.189 – Row Cache Queue Length screen
This screen helps you determine the relative CPU performance
impact of row caching. Poor CPU performance can result if many
hash table collisions occur.
This screen displays the following fields:
o Cache ID- the row cache identifier
o #Rows- the total number of rows in the row cache
o Table Size- the total number of hash table entries for the row
cache
Each character position of the screen identifies a specific hash
table entry. The character, if any, identifies the length of that
entry's queue. The asterisk (*) denotes a queue length of 10 or
more.
The line of "X"s indicates the end of the display. All blank
lines following the row of "X"s can be ignored.
Ideally, every space of the screen should be non-zero. A display
containing many long queues and a lot of blanks indicates poor
CPU utilization.
You can use the Config menu option to filter the Row Cache
Queue Length screen. Select this option, by typing the letter
C, to display the configuration submenu. The configuration
submenu contains a single option: "Filter Utilization Display".
Selecting this option will display the prompt "Enter row cache
threshold (0+) [current=1]: ". Any queue length which is less
than the specified utilization threshold will not be displayed.
By default, the utilization threshold is 0, so that all entries
on the screen are displayed, even those of length 0.
The number of rows in the row cache affects the size of the
corresponding hash table. Hash table queue lengths can be
controlled by increasing or decreasing the number of row cache
entries.
When there is more than one page of the Row Cache Queue Length
screen, the header section contains the page number currently
displayed and the total number of pages in the display. Use the
left angle bracket (<) key to go to the previous page and the
right angle bracket (>) key to go to the next page of the screen.
The Row Cache Queue Length screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.190 – Row Length Distribution screen
This screen graphically describes the distribution of the various
row lengths within a particular row cache. It is necessary
to know the distribution of the various row lengths in the
row cache to determine how well sized the row cache is. For
instance, knowing that each cache entry is wasting even 5 bytes
is significant if there are 100,000 entries in the cache.
The summary region displays three lines containing information
about the row cache and boundary row lengths. The first line
identifies the selected row cache name.
The second line identifies the number of rows whose lengths
were below the minimum selected row length (XXX-) or above the
maximum selected row length (XXX+++). Also, the 95th percentile
row length is displayed; this value indicates the row size that
95% of the rows in the cache are less than or equal to.
The third line identifies the lowest and highest row length in
the cache. Also, the 85th percentile row length is displayed;
this value indicates the row size that 85% of the row in the
cache are less than or equal to.
The information displayed is based on a scale that represents
the row lengths to be analyzed. Initially, the screen's scale
is based on the cache's specified row size. This scale can be
changed using the Config menu option.
Each vertical line of the screen identifies a row length bucket,
based on the selected screen scale. Each asterisk (*) in the
bucket represents a particular number of rows in the cache. Note
that a value of 10, for instance, means that up to 10 rows are
represented by that asterisk (*).
The number of collection buckets is based on the display width
of the terminal. By default, each bucket comprises 5 columns of
the display; the number of columns can be configured by the user
using the Config menu option. For example, setting the terminal
width to 132 columns will allow you to display more information
than with an 80-column terminal width. Decreasing the number of
columns per bucket will achieve the same effect on an 80-column
terminal width, but with a corresponding loss of precision.
Two sliding indicators are displayed along the bottom horizontal
axis; "A" indicates the average row size and "M" indicates the
median row size.
The configuration menu option allows you to fine-tune the
distribution parameters and the display appearance. The options
allow you more control over what row size information is
displayed. You can:
o Set the number of bucket columns
Decreasing the number of columns per bucket allows you to
display more row sizes. Conversely, increasing the number of
columns per bucket allows you to display fewer row sizes, but
with more accurate size reporting (i.e. better scaling) per
bucket. The minimum number of columns is 2 and the maximum is
10.
o Set the row length range values
Setting a specific row size range values allows you to
determine the actual row size display range, which is by
default based on the row cache database parameters.
o Eliminate/Include empty slots
The Row Length Distribution screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.191 – RCS Statistics screen
This screen provides information about the run-time operation of
the Row Cache Server (RCS) process.
2.192 – Index Statistics Retrieval screen
This screen monitors how much retrieval activity is taking place
in a database's sorted indexes. Oracle Rdb often uses direct
index lookups and index scans to access records in the database.
This screen monitors these operations as well as the number of
index nodes fetched.
2.193 – Index Statistics Insertion screen
This screen monitors the update activity of a database's sorted
indexes during insertions; that is, when you store or modify an
index key field or when you use the SQL CREATE INDEX statement on
a table. This screen also indicates in which type of index node
the insertions occur and displays node creations by node type.
By examining this screen, you can monitor how a database balances
its sorted indexes after insertions into the database.
2.194 – Index Statistics Removal screen
This screen monitors the update activity of a database's sorted
indexes when you perform any removal operation; that is, erase,
alter, or modify an index key field or drop or delete an index.
This screen indicates from which type of index node the removals
occur. It also shows node deletions by node type. This screen
lets you monitor how a database balances its sorted indexes when
nodes are removed from the indexes.
2.195 – Hash Index Statistics Screen
This screen monitors the update and retrieval activity of a
database's hashed indexes. It indicates the total number of key
insertions and deletions, the number of scans that were opened,
and for retrievals (successful fetches), the total number of
nodes (either bucket fragments or duplicate nodes) that were
fetched.
2.196 – Name Translation screen
This screen shows statistics on database dashboard updates and
logical name translation.
2.197 – Object KROOT object screen
This screen displays the statistics for the KROOT object. The
KROOT object contains the database control information that
describes all of the other database objects.
2.198 – Object FILID object screen
This screen displays the statistics for the FILID object. The
FILID object contains the storage area information.
2.199 – Object SEQBLK object screen
This screen displays the statistics for the SEQBLK object. The
SEQBLK object contains the information on the allocation of
sequence numbers such as transaction sequence numbers (TSNs)
and commit sequence numbers (CSNs).
The SEQBLK object also serializes access to the TSNBLK locks.
2.200 – Object TSNBLK object screen
This screen displays the statistics for the TSNBLK object. The
TSNBLK object contains the information on the last committed
transaction.
The number of TSNBLK objects is a function of the maximum number
of users in the database; there is one TSNBLK object for every 28
database users (rounded up). For example, a database containing a
maximum of 512 users would contain 19 TSNBLK objects.
2.201 – Object AIJDB object screen
This screen displays the statistics for the AIJDB object. The
AIJDB object contains the AIJ control information.
2.202 – Object AIJFB object screen
This screen displays the statistics for the AIJFB object. The
AIJFB object contains the AIJ journal information.
2.203 – Object RTUPB object screen
This screen displays the statistics for the RTUPB object. The
RTUPB object contains information on active users.
2.204 – Object ACTIVE object screen
This screen displays the statistics for the ACTIVE object. The
ACTIVE object contains information on active transactions.
2.205 – Object CPT object screen
This screen displays the statistics for the CPT object. The CPT
object contains information on the corrupt page table.
2.206 – Object RCACHE object screen
This screen displays the statistics for the RCACHE object. The
RCACHE object contains the row cache information.
2.207 – Object CLIENT object screen
This screen displays the statistics for the CLIENT object. The
CLIENT object contains client-specific information.
2.208 – Object CLTSEQ object screen
This screen displays the statistics for the CLTSEQ object. The
CLTSEQ object contains the client sequence information.
2.209 – Object UTILITY object screen
This screen displays the statistics for the UTILITY object. The
UTILITY object contains information used by the RMU utility.
2.210 – Object objects fetch shrd screen
This screen displays the statistics for the objects fetch shrd
collection category. This category shows the number of objects
that are fetched for the shared retrieval process.
2.211 – Object objects fetch excl screen
This screen displays the statistics for the objects fetch excl
collection category. This category shows the number of objects
fetched for exclusive access with the intention of subsequently
being updated. This statistic does not indicate that the object
was actually updated.
2.212 – Object objects refreshed screen
This screen displays the statistics for the objects refreshed
collection category. This category shows the number of objects
whose information was detected as being stale, so the information
was read again from the database root file.
2.213 – Object objects modified screen
This screen displays the statistics for the objects modified
collection category. This category shows the number of objects
whose information was modified. Only objects fetched for
exclusive access can be modified.
2.214 – Object objects written screen
This screen displays the statistics for the objects written
collection category. This category shows the number of objects
whose information was written back to the database root file.
2.215 – Object objects released screen
This screen displays the statistics for the objects released
collection category. This category shows the number of
objects whose shared or exclusive access was released to other
processes.
2.216 – IO_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.217 – LOCKING_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.218 – AIJ_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.219 – CHECKPOINT_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.220 – HOT_STANDBY_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.221 – Row CACHE DASHBOARD SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.222 – RUJ_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.223 – MONITOR_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.224 – ABS_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.225 – ALS_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.226 – DBR_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.227 – RCS_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.228 – PER_PROCESS_I_O_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.229 – PER_PROCESS_JOURNAL_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.230 – PER_PROCESS_ROW_CACHE_DASHBOARD_SCREEN
This screen displays the actual database parameter and attribute
settings being used by the processes attached to the database.
Optionally, users are allowed to dynamically update certain
database parameters and attributes on a single node at run time.
The net effect of these changes can be examined at run time
without having to restart database processes. These updates are
nonpersistent.
For example, when the RDM$BIND_BUFFERS logical name is defined
at the process level, there is no method available for the
database administrator (DBA) to examine its setting at runtime.
The same is true for any database logical name and most
interesting database attributes that affect runtime performance
of the database. However, the Database Dashboard provides this
information dynamically.
The Database Dashboard facility allows you to "drive" the
database faster or slower, and immediately see the impact of
increasing or decreasing certain database settings.
You can use the Update menu option, by typing the letter U, to
change the value of a database attribute. Before you can update
database attributes, you need to start your Performance Monitor
session with the Options=Update qualifier and you need OpenVMS
WORLD, BYPASS, and SYSNAM privileges.
CAUTION
You should use the Update option carefully. Oracle Rdb does
not perform error checking on the updated values.
Note that updates made to any attributes are not stored in the
database root file. The purpose of updating attributes is to
test and measure the effects of changes on the database, so that
you can later make persistent changes to appropriate database
attributes using interactive SQL.
Database attributes are updated on the current node only.
You can use the Config menu option, by typing the letter C, to
display the configuration submenu. The configuration submenu
provides the following options:
o Use XXX notification of change
Broadcast the changes to the database attributes and
parameters actively or passively. The option description
changes depending on which method of broadcast is current.
o Notify users of previous changes
Active notification means that all processes attached to the
database on the node will be immediately notified that a database
attribute setting has been modified and that they should reset
their individual parameter values. Passive notification means
that the user processes will be notified passively at intervals
determined by the database software. Passive notification is the
default, as it is non-intrusive to system performance.
The advantage of active notification is that each database user
on the node is immediately notified of the change and that the
new parameter settings are immediately used. The disadvantage
is that system performance may be temporarily impacted while the
users respond to the notification.
The advantage of passive notification is that there is no impact
on the system. The disadvantage is that you have no control over
when the individual processes will be notified that a particular
database parameter setting has changed.
When using passive notification, a broadcast notification can be
performed using the "Notify users of previous changes" option of
the Config submenu.
The Dashboard display contains the following columns:
o Current Value
This column contains the current value for each database
attribute. On global database screens, this is the default
value being used by all processes. On per-process screens,
this is the actual value being used by that particular
process.
o Previous Value
This column contains the previous value for each database
attribute. When a database attribute is dynamically updated,
this column will contain the value before it was modified.
o Lowest Value
This column contains the lowest value for each database
attribute.
o Highest Value
This column contains the highest value for each database
attribute.
o Original Value
This column contains the original value for each database
attribute. This column remains unchanged regardless of the
changes made to the database attribute.
o Chng Cnt
This column contains the count of the number of changes to
each database attribute. On global database screens, this
count is the number of times the particular database attribute
was updated by the user. On per-process screens, this count is
the number of times the actual process has updated its dynamic
information.
The dynamic updates that users make to the database are reflected
only in the Current Value column. The remaining columns reflect
changes made by the current user only.
You can display successive dashboards by pressing the right angle
bracket (>) key or the Next Screen key. To display a previous
dashboard, press the left angle bracket (<) key or the Prev
Screen key. Note that you cannot go to the per-process dashboard
screens.
The Dashboard screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this display
is not available when you replay a binary file using the Input
qualifier.
2.231 – Buffer Analysis Screen
This screen provides information about local and global buffer
performance.
The following information is examined:
o Asynchronous Prefetch status
o Detected Asynchronous Prefetch status
o Asynchronous Batch Write status
o Ratio of local buffers to allocate set
You can use the information in this screen to examine the
effectiveness of local and global buffers.
Information in the Buffer Analysis screen is displayed only if it
exceeds established threshold values or normal expectations. Note
that the items identified in this screen are not necessarily
indications of performance problems. The items may be an
indication of a performance problem, but in most cases, further
research is necessary.
The Buffer Analysis screen has a configuration submenu that
allows you to set thresholds for the following:
o LB/AS page hit threshold
The default threshold is 75. You can override the default
value with the RDM$BIND_STATS_LB_PAGE_HIT_RATIO logical name.
o GB pool hit threshold
The default threshold is 85. You can override the default
value with the RDM$BIND_STATS_GB_POOL_HIT_RATIO logical name.
o GB IO-saved threshold
The default threshold is 85. You can override the default
value with the RDM$BIND_STATS_GB_IO_SAVED_RATIO logical name.
Note that the Online Analysis facility uses the actual database
parameters and attributes specified using interactive SQL. The
Online Analysis facility does not use the Dashboard facility
because the Database Dashboard attributes are temporary settings.
Therefore, online changes made using the Dashboard facility are
not reflected in the analysis output. Yet, using the Dashboard
facility is the recommended method for testing potential database
attribute settings. You must use interactive SQL in order to make
the attribute settings persistent.
Also note that the Online Analysis facility is invoked at the
designated screen refresh interval. As the Online Analysis
facility is fairly CPU intensive, and the analysis results seldom
vary greatly over a miniscule period of time, it is recommended
that the screen refresh interval be set to 3 seconds or more.
The Buffer Analysis screen is not recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is not available when you replay a binary file using the
Input qualifier.
2.232 – Transaction Analysis Screen
This screen provides information about transaction performance.
The following information is examined:
o Ratio of verb successes to verb failures
o 95th percentile transaction duration
Information in the Transaction Analysis screen is displayed
only if it exceeds established threshold values or normal
expectations. Note that the items identified in this screen are
not necessarily indications of performance problems. The items
may be an indication of a performance problem, but in most cases,
further research is necessary.
The Transaction Analysis screen has a configuration submenu that
allows you to set thresholds for the following:
o Verb success threshold
The default threshold is 25. You can override the default
value with the RDM$BIND_STATS_VERB_SUCCESS_RATIO logical name.
o Transaction duration threshold
The default threshold is 15. You can override the default
value with the RDM$BIND_STATS_MAX_TX_DURATION logical name.
o Read/Write Transaction duration threshold
o Read-Only Transaction duration threshold
The default threshold is 15 seconds. You can override the
default value with the RDM$BIND_STATS_MAX_RO_TX_DURATION
logical name.
o Transaction duration percentile
The default threshold is 95. You can override the default
value with the RDM$BIND_STATS_MAX_TX_PERCENTILE logical name.
o Read/Write Transaction duration percentile
o Read-Only Transaction duration percentile
The default threshold is 95. You can override the default
value with the RDM$BIND_STATS_MAX_RO_TX_PERCENTILE logical
name.
Note that the Online Analysis facility uses the actual database
parameters and attributes specified using interactive SQL. The
Online Analysis facility does not use the Dashboard facility
because the Database Dashboard attributes are temporary settings.
Therefore, online changes made using the Dashboard facility are
not reflected in the analysis output. Yet, using the Dashboard
facility is the recommended method for testing potential database
attribute settings. You must use interactive SQL in order to make
the attribute settings persistent.
Also note that the Online Analysis facility is invoked at the
designated screen refresh interval. As the Online Analysis
facility is fairly CPU intensive, and the analysis results seldom
vary greatly over a miniscule period of time, it is recommended
that the screen refresh interval be set to 3 seconds or more.
The Transaction Analysis screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.233 – AIJ Analysis Screen
This screen provides information about AIJ journal performance.
The following information is examined:
o AIJ journaling status
o Database configuration
o Reserved journals
o AIJ log server (ALS) status
o Journal overwrite
o Default allocation
o AIJ backup server (ABS) and backup file names
You can use the information in this screen to ensure that AIJ
journals are on their own device. You can also examine the
AIJ request block to I/O ratio, blocks per I/O ratio, and the
formatting of the AIJ request block.
Information in the AIJ Analysis screen is displayed only if it
exceeds established threshold values or normal expectations. Note
that the items identified in this screen are not necessarily
indications of performance problems. The items may be an
indication of a performance problem, but in most cases, further
research is necessary.
The AIJ Analysis screen has a configuration submenu that allows
you to set thresholds for the following:
o Seconds to AIJ extend/switch
The default threshold is 60. You can override the default
value with the RDM$BIND_STATS_AIJ_SEC_TO_EXTEND logical name.
o ARBs per AIJ I/O
The default threshold is 2. You can override the default value
with the RDM$BIND_STATS_AIJ_ARBS_PER_IO logical name.
o Blocks per AIJ I/O
The default threshold is 2. You can override the default value
with the RDM$BIND_STATS_AIJ_BLKS_PER_IO logical name.
o Background ARB threshold
The default threshold is 50. You can override the default
value with the RDM$BIND_STATS_AIJ_BKGRD_ARB_RATIO logical
name.
o Cache overflow threshold
The default threshold is 10. You can override the default
value with the RDM$BIND_STATS_CACHE_OVF_RATIO logical name.
o Network bandwidth threshold
The default threshold is 60 seconds. You can override the
default value with the RDM$BIND_STATS_AIJ_NETWORK_BPS logical
name.
Note that the Online Analysis facility uses the actual database
parameters and attributes specified using interactive SQL. The
Online Analysis facility does not use the Dashboard facility
because the Database Dashboard attributes are temporary settings.
Therefore, online changes made using the Dashboard facility are
not reflected in the analysis output. Yet, using the Dashboard
facility is the recommended method for testing potential database
attribute settings. You must use interactive SQL in order to make
the attribute settings persistent.
Also note that the Online Analysis facility is invoked at the
designated screen refresh interval. As the Online Analysis
facility is fairly CPU intensive, and the analysis results seldom
vary greatly over a miniscule period of time, it is recommended
that the screen refresh interval be set to 3 seconds or more.
The AIJ Analysis screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this screen
is not available when you replay a binary file using the Input
qualifier.
2.234 – RUJ Analysis Screen
This screen provides information about RUJ journal performance.
The following information is examined:
o Ratio of synchronous to asynchronous write I/Os
Information in the RUJ Analysis screen is displayed only if it
exceeds established threshold values or normal expectations. Note
that the items identified in this screen are not necessarily
indications of performance problems. The items may be an
indication of a performance problem, but in most cases, further
research is necessary.
The RUJ Analysis screen has a configuration submenu that allows
you to set thresholds for the following:
o Synchronous RUJ I/O threshold
The default threshold is 10. You can override the default
value with the RDM$BIND_STATS_RUJ_SYNC_IO_RATIO logical name.
o RUJ extend threshold
Note that the Online Analysis facility uses the actual database
parameters and attributes specified using interactive SQL. The
Online Analysis facility does not use the Dashboard facility
because the Database Dashboard attributes are temporary settings.
Therefore, online changes made using the Dashboard facility are
not reflected in the analysis output. Yet, using the Dashboard
facility is the recommended method for testing potential database
attribute settings. You must use interactive SQL in order to make
the attribute settings persistent.
Also note that the Online Analysis facility is invoked at the
designated screen refresh interval. As the Online Analysis
facility is fairly CPU intensive, and the analysis results seldom
vary greatly over a miniscule period of time, it is recommended
that the screen refresh interval be set to 3 seconds or more.
The RUJ Analysis screen is not recorded in the binary output file
produced using the Output qualifier. Consequently, this screen
is not available when you replay a binary file using the Input
qualifier.
2.235 – Recovery Analysis Screen
This screen provides information about process failure recovery
performance.
The following information is examined:
o Ratio of DBR invocation to database attach
o Date and time of the last full database backup
Information in the Recovery Analysis screen is displayed only if
it exceeds established threshold values or normal expectations.
Note that the items identified in this screen are not necessarily
indications of performance problems. The items may be an
indication of a performance problem, but in most cases, further
research is necessary.
The Recovery Analysis screen has a configuration submenu that
allows you to set thresholds for the following:
o DBR invocation threshold
The default threshold is 15. You can override the default
value with the RDM$BIND_STATS_DBR_RATIO logical name.
o DBR recovery duration
o Full database backup threshold
The default threshold is 6. You can override the default value
with the RDM$BIND_STATS_FULL_BACKUP_INTRVL logical name.
Note that the Online Analysis facility uses the actual database
parameters and attributes specified using interactive SQL. The
Online Analysis facility does not use the Dashboard facility
because the Database Dashboard attributes are temporary settings.
Therefore, online changes made using the Dashboard facility are
not reflected in the analysis output. Yet, using the Dashboard
facility is the recommended method for testing potential database
attribute settings. You must use interactive SQL in order to make
the attribute settings persistent.
Also note that the Online Analysis facility is invoked at the
designated screen refresh interval. As the Online Analysis
facility is fairly CPU intensive, and the analysis results seldom
vary greatly over a miniscule period of time, it is recommended
that the screen refresh interval be set to 3 seconds or more.
The Recovery Analysis screen is not recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is not available when you replay a binary file using the
Input qualifier.
2.236 – Record Analysis Screen
This screen provides information about record storage and
retrieval performance.
The following information is examined:
o Ratio of global pages checked to pages discarded
o Ratio of global records stored to records fragmented
o Ratio of global records fetched to records fragmented
Information in the Record Analysis screen is displayed only if it
exceeds established threshold values or normal expectations. Note
that the items identified in this screen are not necessarily
indications of performance problems. The items may be an
indication of a performance problem, but in most cases, further
research is necessary.
The Record Analysis screen has a configuration submenu that
allows you to set thresholds for the following:
o Pages checked threshold
The default threshold is 10. You can override the default
value with the RDM$BIND_STATS_PAGES_CHECKED_RATIO logical
name.
o SPAM pages fetched threshold
o SPAM records stored threshold
o Records stored threshold
The default threshold is 20. You can override the default
value with the RDM$BIND_STATS_RECS_STORED_RATIO logical name.
o Records fetched threshold
The default threshold is 20. You can override the default
value with the RDM$BIND_STATS_RECS_FETCHED_RATIO logical name.
Note that the Online Analysis facility uses the actual database
parameters and attributes specified using interactive SQL. The
Online Analysis facility does not use the Dashboard facility
because the Database Dashboard attributes are temporary settings.
Therefore, online changes made using the Dashboard facility are
not reflected in the analysis output. Yet, using the Dashboard
facility is the recommended method for testing potential database
attribute settings. You must use interactive SQL in order to make
the attribute settings persistent.
Also note that the Online Analysis facility is invoked at the
designated screen refresh interval. As the Online Analysis
facility is fairly CPU intensive, and the analysis results seldom
vary greatly over a miniscule period of time, it is recommended
that the screen refresh interval be set to 3 seconds or more.
The Record Analysis screen is not recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is not available when you replay a binary file using the
Input qualifier.
2.237 – Area Analysis Screen
This screen provides information about storage area performance.
The following information is examined:
o Equally distributed storage areas within devices
o Storage areas whose I/O stalls exceed the database average
o Storage areas that have extended
Information in the Area Analysis screen is displayed only if it
exceeds established threshold values or normal expectations. Note
that the items identified in this screen are not necessarily
indications of performance problems. The items may be an
indication of a performance problem, but in most cases, further
research is necessary.
Note that the Online Analysis facility uses the actual database
parameters and attributes specified using interactive SQL. The
Online Analysis facility does not use the Dashboard facility
because the Database Dashboard attributes are temporary settings.
Therefore, online changes made using the Dashboard facility are
not reflected in the analysis output. Yet, using the Dashboard
facility is the recommended method for testing potential database
attribute settings. You must use interactive SQL in order to make
the attribute settings persistent.
Also note that the Online Analysis facility is invoked at the
designated screen refresh interval. As the Online Analysis
facility is fairly CPU intensive, and the analysis results seldom
vary greatly over a miniscule period of time, it is recommended
that the screen refresh interval be set to 3 seconds or more.
The Area Analysis screen is not recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is not available when you replay a binary file using the
Input qualifier.
2.238 – Locking Analysis Screen
This screen provides information about locking performance.
The following information is examined:
o Lock stalls, timeouts, and deadlocks
o Excessive timeouts or deadlocks
Information in the Locking Analysis screen is displayed only if
it exceeds established threshold values or normal expectations.
Note that the items identified in this screen are not necessarily
indications of performance problems. The items may be an
indication of a performance problem, but in most cases, further
research is necessary.
The Locking Analysis screen has a configuration submenu that
allows you to set thresholds for the following:
o Lock stall threshold
The default threshold is 2 seconds. You can override the
default value with the RDM$BIND_STATS_MAX_LOCK_STALL logical
name.
Note that the Online Analysis facility uses the actual database
parameters and attributes specified using interactive SQL. The
Online Analysis facility does not use the Dashboard facility
because the Database Dashboard attributes are temporary settings.
Therefore, online changes made using the Dashboard facility are
not reflected in the analysis output. Yet, using the Dashboard
facility is the recommended method for testing potential database
attribute settings. You must use interactive SQL in order to make
the attribute settings persistent.
Also note that the Online Analysis facility is invoked at the
designated screen refresh interval. As the Online Analysis
facility is fairly CPU intensive, and the analysis results seldom
vary greatly over a miniscule period of time, it is recommended
that the screen refresh interval be set to 3 seconds or more.
The Locking Analysis screen is not recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is not available when you replay a binary file using the
Input qualifier.
2.239 – Index Analysis Screen
This screen provides information about B-tree and hashed index
performance.
The following information is examined:
o B-tree duplicate indexes fetched
o B-tree depth
Information in the Index Analysis screen is displayed only if it
exceeds established threshold values or normal expectations. Note
that the items identified in this screen are not necessarily
indications of performance problems. The items may be an
indication of a performance problem, but in most cases, further
research is necessary.
The Index Analysis screen has a configuration submenu that allows
you to set thresholds for the following:
o B-tree duplicate fetch threshold
The default threshold is 15. You can override the default
value with the RDM$BIND_STATS_BTR_FETCH_DUP_RATIO logical
name.
o B-tree leaf node fetch threshold
The default threshold is 25. You can override the default
value with the RDM$BIND_STATS_BTR_LEF_FETCH_RATIO logical
name.
Note that the Online Analysis facility uses the actual database
parameters and attributes specified using interactive SQL. The
Online Analysis facility does not use the Dashboard facility
because the Database Dashboard attributes are temporary settings.
Therefore, online changes made using the Dashboard facility are
not reflected in the analysis output. Yet, using the Dashboard
facility is the recommended method for testing potential database
attribute settings. You must use interactive SQL in order to make
the attribute settings persistent.
Also note that the Online Analysis facility is invoked at the
designated screen refresh interval. As the Online Analysis
facility is fairly CPU intensive, and the analysis results seldom
vary greatly over a miniscule period of time, it is recommended
that the screen refresh interval be set to 3 seconds or more.
The Index Analysis screen is not recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is not available when you replay a binary file using the
Input qualifier.
2.240 – Row Cache Analysis Screen
This screen provides information about row cache effectiveness
and performance.
The following information is examined:
o Whether row caching is allowed
o Whether row caching is enabled
o Hash table queue lengths
Information in the Row Cache Analysis screen is displayed only if
it exceeds established threshold values or normal expectations.
Note that the items identified in this screen are not necessarily
indications of performance problems. The items may be an
indication of a performance problem, but in most cases, further
research is necessary.
The Row Cache Analysis screen has a configuration submenu that
allows you to set thresholds for the following:
o Hash table queue length threshold
The default threshold is 2 rows. You can override the default
value with the RDM$BIND_STATS_MAX_HASH_QUE_LEN logical name.
Note that the Online Analysis facility uses the actual database
parameters and attributes specified using interactive SQL. The
Online Analysis facility does not use the Dashboard facility
because the Database Dashboard attributes are temporary settings.
Therefore, online changes made using the Dashboard facility are
not reflected in the analysis output. Yet, using the Dashboard
facility is the recommended method for testing potential database
attribute settings. You must use interactive SQL in order to make
the attribute settings persistent.
Also note that the Online Analysis facility is invoked at the
designated screen refresh interval. As the Online Analysis
facility is fairly CPU intensive, and the analysis results seldom
vary greatly over a miniscule period of time, it is recommended
that the screen refresh interval be set to 3 seconds or more.
The Row Cache Analysis screen is not recorded in the binary
output file produced using the Output qualifier. Consequently,
this screen is not available when you replay a binary file using
the Input qualifier.
2.241 – Process Analysis Screen
This screen provides information about process effectiveness and
performance.
The following information is examined:
o Process n ENQLM <x.y> ratio below <x.y>% threshold
This message indicates that the process ENQCNT to ENQLM ratio
is below the corresponding threshold.
o Process n BIOLM <x.y> ratio below <x.y>R% threshold
This message indicates that the process BIOCNT to BIOLM ratio
is below the corresponding threshold.
o Process n DIOLM <x.y> ratio below <x.y>% threshold
This message indicates that the process DIOCNT to DIOLM ratio
is below the corresponding threshold.
o Process n PGFLQUOTA <x.y> ratio below <x.y>% threshold
This message indicates that the process PAGFILCNT to PGFLQUOTA
ratio is below the corresponding threshold.
The Process Analysis screen has a configuration submenu that
allows you to set thresholds for the following:
o BIOLM
The default BIOLM threshold is 25%. You can override the
default value with the RDM$BIND_STATS_PROC_BIOLM_RATIO logical
name.
o DIOLM
The default DIOLM threshold is 25%. You can override the
default value with the RDM$BIND_STATS_PROC_DIOLM_RATIO logical
name.
o ENQLM
The default ENQLM threshold is 25%. You can override the
default value with the RDM$BIND_STATS_PROC_ENQLM_RATIO logical
name.
o PGFLQUOTA
The default PGFLQUOTA threshold is 25%. You can override
the default value with the RDM$BIND_STATS_PROC_PGFLLM_RATIO
logical name.
o ASTLM
The default ASTLM threshold is 25%. You can override the
default value with the RDM$BIND_STATS_PROC_ASTLM_RATIO logical
name.
Note that the Online Analysis facility uses the actual database
parameters and attributes specified using interactive SQL. The
Online Analysis facility does not use the Dashboard facility
because the Database Dashboard attributes are temporary settings.
Therefore, online changes made using the Dashboard facility are
not reflected in the analysis output. Yet, using the Dashboard
facility is the recommended method for testing potential database
attribute settings. You must use interactive SQL in order to make
the attribute settings persistent.
Also note that the Online Analysis facility is invoked at the
designated screen refresh interval. As the Online Analysis
facility is fairly CPU intensive, and the analysis results seldom
vary greatly over a miniscule period of time, it is recommended
that the screen refresh interval be set to 3 seconds or more.
The Process Analysis screen is not recorded in the binary output
file produced using the Output qualifier. Consequently, this
screen is not available when you replay a binary file using the
Input qualifier.
3 – Fields
3.1 – Summary IO Statistics screen
3.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.
3.1.2 – verb_successes_field
This field gives the number of completed verbs that returned a
successful status code.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.1.12 – ACE file reads field
This field gives the total number of read I/Os issued to the ACE
file.
3.1.13 – ACE file writes field
This field gives the total number of write I/Os issued to the ACE
file.
3.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.
3.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.
3.2 – Summary Locking Statistics screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.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.
3.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.3 – Summary Object Statistics screen
3.3.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
shared retrieval access.
3.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.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.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.3.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.3.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.4 – Summary Cache Statistics screen
3.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.
3.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.
3.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
3.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.
3.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.
3.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.
3.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
3.4.8 – __row_too_big_field
This field indicates the row was initially too large to fit into
the specified row cache buffer.
3.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.
3.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.
3.4.11 – VLM requests field
This field displays the number of VLM requests made.
3.4.12 – __window_turns_field
This field displays the number of VLM requests made for which the
VLM address range was not immediately available.
3.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.
3.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.
3.4.15 – hash_misses_field
This field displays the total number of times the row cache hash
table overflowed.
3.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.
3.5 – Summary Cache Unmark Statistics screen
3.5.1 – latch_granted_field
This field displays the number of times the row lock (latch) was
granted.
3.5.2 – latch_stalled_field
This field displays the number of times the row lock stalled
before being granted.
3.5.3 – latch_deadlock_field
This field displays the number of times the row lock stall
resulted in a deadlock.
3.5.4 – latch_demoted_field
This field displays the number of times the row lock was
released.
3.5.5 – latch_stall_x100_field
This field displays the row lock stall time (in hundredths of a
second).
3.6 – Summary Tx Statistics screen
3.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.
3.6.2 – __committed_field
This field identifies the actual number of transactions that
committed successfully to the database.
3.6.3 – __rolled_back_field
This field identifies the actual number of transactions that were
aborted and were not applied to the database.
3.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.
3.6.5 – __prepared_field
This field identifies the number of distributed transactions
that have successfully "prepared" themselves for subsequent
transaction commit.
3.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.
3.6.7 – verb_successes_field
This field gives the number of completed verbs that returned a
successful status code.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.6.14 – ____file_extend_field_
This field identifies the number of times an RUJ file has been
extended.
3.7 – Record Statistics screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.7.10 – ___fragmented_field
This subfield indicates the number of fragmented records erased
from the database.
3.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.
3.7.12 – temp_record_fetchd_field
This field gives the number of records fetched from a temporary
table.
3.7.13 – temp_record_stored_field
This field gives the number of records stored in a temporary
table.
3.7.14 – temp_record_erased_field
This field gives the number of records erased from a temporary
table.
3.8 – Custom Statistics screen
3.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.
3.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.
3.9 – Snapshot Statistics screen
3.9.1 – Total transactions field
This field gives the total number of transactions that have been
committed or rolled back, including read-only transactions.
3.9.2 – R O transactions field
This field gives the total number of read-only transactions that
have been committed or rolled back.
3.9.3 – retrieved_record_field
This field gives the number of records retrieved by read-only
transactions.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.10 – Stall Statistics Aggregate counts screen
3.10.1 – miscellaneous______field_
This field displays generic stalls, such as waiting for a
bugcheck dump to complete.
3.10.2 – records____________field__
This field displays record-related stalls, such as waiting for
record locks to be granted.
3.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.
3.10.4 – tables_____________field__
This field displays table-related stalls, such as waiting for
logical area locks to be granted.
3.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.
3.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.
3.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.
3.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.
3.10.9 – hot_standby________field_
This field displays stalls related to the Hot Standby feature.
3.10.10 – database___________field__
This field displays database-related stalls, such as waiting for
the database freeze to complete.
3.11 – Stall Statistics Aggregate durations screen
3.11.1 – miscellaneous______field_
This field displays generic stalls, such as waiting for a
bugcheck dump to complete.
3.11.2 – records____________field__
This field displays record-related stalls, such as waiting for
record locks to be granted.
3.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.
3.11.4 – tables_____________field__
This field displays table-related stalls, such as waiting for
logical area locks to be granted.
3.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.
3.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.
3.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.
3.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.
3.11.9 – hot_standby________field_
This field displays stalls related to the Hot Standby feature.
3.11.10 – database___________field__
This field displays database-related stalls, such as waiting for
the database freeze to complete.
3.12 – AIJ Statistics screen
3.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.
3.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.
3.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.
3.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.
3.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).
3.12.6 – tx__block_span_field
This field displays the number of blocks each transaction spans
in the AIJ journal.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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".
3.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.
3.13 – Group Commit Statistics screen
3.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.)
3.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).
3.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.
3.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).
3.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.
3.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.
3.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.
3.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.
3.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.
3.13.10 – ___cache_overflows_field
This field displays the number of times the 64-block .aij cache
has overflowed.
3.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.
3.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).
3.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.
3.14 – ALS Statistics screen
3.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.
3.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.
3.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.
3.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.
3.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).
3.14.6 – AIJ Write Time field
This field gives the time (in hundredths of a second) spent
writing to the .aij file.
3.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.
3.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.
3.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.
3.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.)
3.14.11 – ARBs formatted field
This field displays the number of AIJ Request Blocks that were
formatted by the ALS process.
3.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.
3.14.13 – premature_io_saved_field
This field displays the number of I/Os saved by waiting for more
work.
3.14.14 – Cache Overflows field
This field displays the number of times the 64-block .aij cache
has overflowed.
3.15 – 2PC Statistics screen
3.15.1 – total_tx_count_field
This field displays the total number of transactions that have
been committed or rolled back.
3.15.2 – 2PC tx count field
This field displays the total number of distributed transactions
that have been committed or rolled back.
3.15.3 – total_tx_time_x100_field
This field displays the total duration of all transactions,
expressed in hundredths of a second.
3.15.4 – __reg_tx_time_x100_field
This field displays the total duration of all non-distributed
transactions, expressed in hundredths of a second.
3.15.5 – 2PC tx time x100 field
This field displays the total duration of all distributed
transactions, expressed in hundredths of a second.
3.15.6 – prepared_time_x100_field
This field displays the total duration of the transaction
resolution phase.
3.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.
3.15.8 – 2PC committed field
This field displays the total number of distributed transactions
that were committed.
3.15.9 – 2PC aborted field
This field displays the total number of distributed transactions
that were rolled back.
3.16 – RUJ Statistics screen
3.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.
3.16.2 – ____data_field_
This field displays the total number of synchronous write I/O
operations containing modified database data.
3.16.3 – ____control_field_
This field displays the total number of synchronous write I/O
operations containing control (header) information.
3.16.4 – ____file_extend_field_
This field displays the total number of times the recovery-unit
journal files have been extended.
3.16.5 – records_written_field
This field displays the number of journal records written to the
recovery-unit journal (.ruj) file.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.17 – Fast Incr Backup Statistics screen
3.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.
3.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.
3.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.
3.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.
3.18 – Checkpoint Statistics screen
3.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.
3.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.
3.18.3 – AIJ growth field
The number of checkpoints for all processes due to the .aij file
growth checkpoint limit.
3.18.4 – ____txn_limit_field_
The number of checkpoints for all processes due to the logical-
defined transaction limit.
3.18.5 – ____time_limit_field_
The number of checkpoints for all processes due to the time
interval checkpoint limit.
3.18.6 – ____rollback_field_
The number of checkpoints automatically triggered by rollback of
transactions that updated the database.
3.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.
3.18.8 – ____global_field_
The number of system-wide checkpoints, issued from an RMU
Checkpoint, RMU Backup, or RMU Backup After_Journal command.
3.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.
3.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.
3.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.
3.18.12 – checkpoint_stall_field
This field displays the checkpoint duration in seconds.
3.18.13 – flushed_buffers_field
This field displays the number of buffers flushed to disk during
a checkpoint operation.
3.19 – Recovery Statistics screen
3.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.
3.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.
3.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.
3.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.
3.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".
3.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.
3.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".
3.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".
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.20 – Hot Standby Statistics screen
3.20.1 – AIJ network send field
This field displays the number of network messages sent.
3.20.2 – AIJ network recv field
This field displays the number of network messages received.
3.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.
3.20.4 – ____data_field_
This field displays the number of data messages sent to the
standby database or received from the master database.
3.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.
3.20.6 – ____checkpoints_field_
This field displays the number of checkpoint operations
performed.
3.20.7 – Stall time x100 field
This field displays the network I/O duration, in hundredths of
seconds.
3.20.8 – blocks_shipped_field
This field displays the number of 512-byte blocks sent.
3.20.9 – ______received_field_
This field displays the number of 512-byte blocks received.
3.20.10 – Stalled MSN found field
This field displays the number of stalled messages identified.
3.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.
3.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.
3.21 – Synchronization Mode Statistics screen
3.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.
3.21.2 – cold_sync_send_field
This field displays the number of cold mode messages sent to the
standby database.
3.21.3 – warm_sync_send_field
This field displays the number of warm mode messages sent to the
standby database.
3.21.4 – hot_sync_send_field
This field displays the number of hot mode messages sent to the
standby database.
3.21.5 – commit_sync_send_field
This field displays the number of commit mode messages sent to
the standby database.
3.21.6 – cold_stall_x100_field
This field displays the cold message duration, in hundredths of
seconds.
3.21.7 – warm_stall_x100_field
This field displays the warm message duration, in hundredths of
seconds.
3.21.8 – hot_stall_x100_field
This field displays the hot message duration, in hundredths of
seconds.
3.21.9 – commit_stall_x100_field
This field displays the commit message duration, in hundredths of
seconds.
3.21.10 – Startup Shutdown field
This field displays the number of times the hot standby feature
was started or shut down.
3.21.11 – Unexpected Failure field
This field displays the number of times the hot standby feature
was shutdown abnormally.
3.22 – Recovery Information screen
3.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.
3.22.2 – _commit_field
This field displays the number of transactions that have been
committed to the standby database.
3.22.3 – _rollback_field
This field displays the number of transactions that have been
rolled back prior to being applied to the standby database.
3.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.
3.22.5 – Area ready field
This field displays the number of physical storage areas that
have been "readied" during the recovery operation.
3.22.6 – AIJ records field
This field displays the number of AIJ records applied.
3.22.7 – _erase_mixed_field
This field displays the number of "erase record" operations
performed on a mixed-format storage area.
3.22.8 – _erase_uniform_field
This field displays the number of "erase record" operations
performed on a uniform-format storage area.
3.22.9 – _modify_mixed_field
This field displays the number of "modify record" operations
performed on a mixed-format storage area.
3.22.10 – _modify_uniform_field
This field displays the number of "modify record" operations
performed on a uniform-format storage area.
3.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.
3.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.
3.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.
3.23 – PIO Statistics Data Fetches screen
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.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.
3.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.
3.24 – PIO Statistics SPAM Fetches screen
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.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.
3.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.
3.25 – PIO Statistics SPAM Prefetches screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.26 – PIO Statistics Data Prefetches screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.27 – PIO Statistics SPAM Access screen
3.27.1 – fetch_for_read_field
This field displays the total number of times the SPAM page was
fetched for retrieval.
3.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.
3.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.
3.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.
3.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.
3.27.6 – fetch_for_write_field
This field displays the total number of times the SPAM page was
fetched for update.
3.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.
3.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.
3.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.
3.27.10 – fetch_for_update_field
This field displays the total number of times the SPAM page was
fetched for update.
3.27.11 – _clump_allocate_field
This field displays the total number of times the SPAM page was
updated for a clump allocation operation.
3.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.
3.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.
3.27.14 – record_stored_field
This field displays the number of records stored in the
database.
3.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.
3.27.16 – record_erased_field
This field displays the number of records erased from the
database.
3.28 – PIO Statistics Data Writes screen
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.29 – PIO Statistics SPAM Writes screen
3.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.
3.30 – PIO Statistics File Access screen
3.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.
3.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.
3.30.3 – _normal_stall_x100_field
This field displays the total duration of the normal file-open
operation, in hundredths of seconds.
3.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.
3.30.5 – quick stall X100 field
This field displays the total duration of the quick file-open
operation, in hundreths of seconds.
3.31 – Asynchronous IO Statistics screen
3.31.1 – data_read_request_field
The number of requests issued to the PIO subsystem to read data
pages asynchronously.
3.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.
3.31.3 – spam_read_request_field
The number of requests issued to the PIO subsystem to read SPAM
pages asynchronously.
3.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.
3.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.
3.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.
3.31.7 – write IO field
The number of asynchronous writes done by the PIO subsystem to
write data and SPAM pages to the disk.
3.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.
3.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.
3.32 – IO Stall Time seconds x100 screen
3.32.1 – root_read_time_field
This field gives the time (in hundredths of a second) spent
reading the database root (.rdb) file.
3.32.2 – root_write_time_field
This field gives the time (in hundredths of a second) spent
writing to the database root (.rdb) file.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.32.9 – AIJ read time field
This field gives the time (in hundredths of a second) spent
reading records from the .aij file.
3.32.10 – AIJ write time field
This field gives the time (in hundredths of a second) spent
writing to the .aij file.
3.32.11 – AIJ hiber time field
This field shows the stall time spent hibernating for the AIJ I/O
to complete.
3.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.
3.32.13 – database_bind_time_field
This field gives the length of time users are attached to the
database.
3.33 – Logical Area Statistics screen
3.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.
3.33.2 – record_fetched_field
This field gives the number of records, including snapshot
records, fetched.
3.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.
3.33.4 – ___record_stored_field
This field gives the number of records stored in the database.
3.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.
3.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.
3.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.
3.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.
3.33.9 – _record_erased_field
This field gives the number of records erased from the database.
3.33.10 – ___fragmented_field
This subfield indicates the number of fragmented records erased
from the database.
3.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.
3.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.
3.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.
3.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.
3.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.
3.33.16 – _primary_entries_field
This field gives the number of unique keys found during the index
scan.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.33.29 – _leaf_removals_field
This field gives the number of unique index keys removed from the
leaf nodes during an SQL DELETE operation.
3.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.
3.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.
3.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.
3.33.33 – _dup__deletions_field
This field gives the number of duplicate node deletions within
the indexes.
3.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.
3.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.
3.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.
3.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.
3.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.
3.33.39 – bucket_fetched_field
This field gives the number of buckets fetched.
3.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.
3.33.41 – _bucket_stored_field
This field gives the number of buckets stored in the database.
3.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.
3.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.
3.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.
3.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.
3.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.
3.33.47 – _____duplicates_field_
This field gives the number of duplicate key updates in the
database's hashed indexes.
3.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.
3.33.49 – ____duplicates_field_
This field gives the number of duplicate key deletions in the
database's hashed indexes.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.34 – Locking total locks screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.35 – Locking area locks screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.36 – Locking buffer page locks screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.37 – Locking record locks screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.38 – Locking SEQBLK lock screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.39 – Locking FILID locks screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.40 – Locking TSNBLK locks screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.41 – Locking RTUPB lock screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.42 – Locking ACTIVE lock screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.43 – Locking MEMBIT lock screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.44 – Locking AIJ locks screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.45 – Locking snapshot locks screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.46 – Locking freeze lock screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.47 – Locking quiet point lock screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.48 – Locking logical area locks screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.49 – Locking nowait transaction screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.50 – Locking CLIENT locks screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.51 – Locking locks requested screen
3.51.1 – total_locks_field
This field gives statistics for all types of database locks.
3.51.2 – area_locks_field
This field gives statistics for database physical area locks.
3.51.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.51.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.52 – Locking rqsts not queued screen
3.52.1 – total_locks_field
This field gives statistics for all types of database locks.
3.52.2 – area_locks_field
This field gives statistics for database physical area locks.
3.52.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.52.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.53 – Locking rqsts stalled screen
3.53.1 – total_locks_field
This field gives statistics for all types of database locks.
3.53.2 – area_locks_field
This field gives statistics for database physical area locks.
3.53.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.53.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.54 – Locking rqst timeouts screen
3.54.1 – total_locks_field
This field gives statistics for all types of database locks.
3.54.2 – area_locks_field
This field gives statistics for database physical area locks.
3.54.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.54.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.55 – Locking rqst deadlocks screen
3.55.1 – total_locks_field
This field gives statistics for all types of database locks.
3.55.2 – area_locks_field
This field gives statistics for database physical area locks.
3.55.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.55.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.56 – Locking locks promoted screen
3.56.1 – total_locks_field
This field gives statistics for all types of database locks.
3.56.2 – area_locks_field
This field gives statistics for database physical area locks.
3.56.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.56.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.57 – Locking proms not queued screen
3.57.1 – total_locks_field
This field gives statistics for all types of database locks.
3.57.2 – area_locks_field
This field gives statistics for database physical area locks.
3.57.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.57.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.58 – Locking proms stalled screen
3.58.1 – total_locks_field
This field gives statistics for all types of database locks.
3.58.2 – area_locks_field
This field gives statistics for database physical area locks.
3.58.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.58.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.59 – Locking prom timeouts screen
3.59.1 – total_locks_field
This field gives statistics for all types of database locks.
3.59.2 – area_locks_field
This field gives statistics for database physical area locks.
3.59.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.59.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.60 – Locking prom deadlocks screen
3.60.1 – total_locks_field
This field gives statistics for all types of database locks.
3.60.2 – area_locks_field
This field gives statistics for database physical area locks.
3.60.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.60.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.61 – Locking locks demoted screen
3.61.1 – total_locks_field
This field gives statistics for all types of database locks.
3.61.2 – area_locks_field
This field gives statistics for database physical area locks.
3.61.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.61.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.62 – Locking locks released screen
3.62.1 – total_locks_field
This field gives statistics for all types of database locks.
3.62.2 – area_locks_field
This field gives statistics for database physical area locks.
3.62.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.62.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.63 – Locking blocking ASTs screen
3.63.1 – total_locks_field
This field gives statistics for all types of database locks.
3.63.2 – area_locks_field
This field gives statistics for database physical area locks.
3.63.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.63.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.64 – Locking stall time x100 screen
3.64.1 – total_locks_field
This field gives statistics for all types of database locks.
3.64.2 – area_locks_field
This field gives statistics for database physical area locks.
3.64.3 – buffer_page_locks_field
This field gives statistics for database page locks. Page locks
manage the database page buffer pool.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.64.16 – nowait_transaction_field
This field gives statistics for the database nowait transaction lock.
3.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.
3.65 – File Locking Statistics screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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).
3.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.
3.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.
3.66 – Row Cache by cache screen
3.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.
3.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.
3.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
3.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.
3.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.
3.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.
3.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
3.66.8 – __row_too_big_field
This field indicates the row was initially too large to fit into
the specified row cache buffer.
3.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.
3.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.
3.66.11 – VLM requests field
This field displays the number of VLM requests made.
3.66.12 – __window_turns_field
This field displays the number of VLM requests made for which the
VLM address range was not immediately available.
3.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.
3.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.
3.66.15 – hash_misses_field
This field displays the total number of times the row cache hash
table overflowed.
3.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.
3.67 – RCS Statistics screen
3.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.
3.68 – Index Statistics Retrieval screen
3.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.
3.68.2 – verb_successes_field
This field gives the number of intermediate recoverable
operations that returned a successful status code.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.68.9 – _primary_entries_field
This field gives the number of unique keys found during the index
scan.
3.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.
3.69 – Index Statistics Insertion screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.70 – Index Statistics Removal screen
3.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.
3.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.
3.70.3 – _leaf_removals_field
This field gives the number of unique index keys removed from the
leaf nodes during an SQL DELETE operation.
3.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.
3.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.
3.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.
3.70.7 – _dup__deletions_field
This field gives the number of duplicate node deletions within
the indexes.
3.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.
3.71 – Hash Index Statistics Screen
3.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.
3.71.2 – _____duplicates_field_
This field gives the number of duplicate key updates in the
database's hashed indexes.
3.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.
3.71.4 – ____duplicates_field_
This field gives the number of duplicate key deletions in the
database's hashed indexes.
3.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.
3.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.
3.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.
3.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.
3.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.
3.72 – Name Translation screen
3.72.1 – dashboard_updated__field
This field displays the number of times a user has received
notification that the database dashboard has been updated.
3.72.2 – name_translated_field
This field displays the number of times a logical name has been
translated.
3.72.3 – _____defaulted_field_
This field displays the number of times the default value was
used for a logical name.
3.73 – Object KROOT object screen
3.73.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.73.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.73.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.74 – Object FILID object screen
3.74.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.74.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.74.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.75 – Object SEQBLK object screen
3.75.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.75.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.75.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.76 – Object TSNBLK object screen
3.76.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.76.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.76.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.77 – Object AIJDB object screen
3.77.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.77.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.77.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.78 – Object AIJFB object screen
3.78.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.78.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.78.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.79 – Object RTUPB object screen
3.79.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.79.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.79.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.80 – Object ACTIVE object screen
3.80.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.80.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.80.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.81 – Object CPT object screen
3.81.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.81.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.81.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.82 – object RCACHE object screen
3.82.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.82.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.82.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.83 – Object CLIENT object screen
3.83.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.83.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.83.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.84 – Object CLTSEQ object screen
3.84.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.84.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.84.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.85 – Object UTILITY object screen
3.85.1 – objects_fetch_shrd_field
This field displays the number of objects that are fetched for
the shared retrieval process.
3.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.
3.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.
3.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.
3.85.5 – objects_written_field
This field displays the number of objects whose information was
written back to the database root file.
3.85.6 – objects_released_field
This field displays the number of objects whose shared or
exclusive access was released to other processes.
3.86 – Object objects fetch shrd screen
3.86.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
3.86.2 – FILID object field
This field displays the storage area information.
3.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).
3.86.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
3.86.5 – AIJDB object field
This field displays the AIJ control information.
3.86.6 – AIJFB object field
This field displays the AIJ journal information.
3.86.7 – RTUPB object field
This field displays information on active users.
3.86.8 – ACTIVE object field
This field displays information on active transactions.
3.86.9 – CPT object field
This field displays information on the corrupt page table.
3.86.10 – RCACHE object field
This field displays information on row caches.
3.86.11 – CLIENT object field
This field displays client-specific information.
3.86.12 – CLTSEQ object field
This field displays client sequence information.
3.86.13 – UTILITY object field
This field displays RMU utility information.
3.87 – Object objects fetch excl screen
3.87.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
3.87.2 – FILID object field
This field displays the storage area information.
3.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).
3.87.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
3.87.5 – AIJDB object field
This field displays the AIJ control information.
3.87.6 – AIJFB object field
This field displays the AIJ journal information.
3.87.7 – RTUPB object field
This field displays information on active users.
3.87.8 – ACTIVE object field
This field displays information on active transactions.
3.87.9 – CPT object field
This field displays information on the corrupt page table.
3.87.10 – RCACHE object field
This field displays information on row caches.
3.87.11 – CLIENT object field
This field displays client-specific information.
3.87.12 – CLTSEQ object field
This field displays client sequence information.
3.87.13 – UTILITY object field
This field displays RMU utility information.
3.88 – Object objects refreshed screen
3.88.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
3.88.2 – FILID object field
This field displays the storage area information.
3.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).
3.88.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
3.88.5 – AIJDB object field
This field displays the AIJ control information.
3.88.6 – AIJFB object field
This field displays the AIJ journal information.
3.88.7 – RTUPB object field
This field displays information on active users.
3.88.8 – ACTIVE object field
This field displays information on active transactions.
3.88.9 – CPT object field
This field displays information on the corrupt page table.
3.88.10 – RCACHE object field
This field displays information on row caches.
3.88.11 – CLIENT object field
This field displays client-specific information.
3.88.12 – CLTSEQ object field
This field displays client sequence information.
3.88.13 – UTILITY object field
This field displays RMU utility information.
3.89 – Object objects modified screen
3.89.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
3.89.2 – FILID object field
This field displays the storage area information.
3.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).
3.89.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
3.89.5 – AIJDB object field
This field displays the AIJ control information.
3.89.6 – AIJFB object field
This field displays the AIJ journal information.
3.89.7 – RTUPB object field
This field displays information on active users.
3.89.8 – ACTIVE object field
This field displays information on active transactions.
3.89.9 – CPT object field
This field displays information on the corrupt page table.
3.89.10 – RCACHE object field
This field displays information on row caches.
3.89.11 – CLIENT object field
This field displays client-specific information.
3.89.12 – CLTSEQ object field
This field displays client sequence information.
3.89.13 – UTILITY object field
This field displays RMU utility information.
3.90 – Object objects written screen
3.90.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
3.90.2 – FILID object field
This field displays the storage area information.
3.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).
3.90.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
3.90.5 – AIJDB object field
This field displays the AIJ control information.
3.90.6 – AIJFB object field
This field displays the AIJ journal information.
3.90.7 – RTUPB object field
This field displays information on active users.
3.90.8 – ACTIVE object field
This field displays information on active transactions.
3.90.9 – CPT object field
This field displays information on the corrupt page table.
3.90.10 – RCACHE object field
This field displays information on row caches.
3.90.11 – CLIENT object field
This field displays client-specific information.
3.90.12 – CLTSEQ object field
This field displays client sequence information.
3.90.13 – UTILITY object field
This field displays RMU utility information.
3.91 – Object objects released screen
3.91.1 – KROOT object field
This field displays the database control information that
describes all of the other database objects.
3.91.2 – FILID object field
This field displays the storage area information.
3.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).
3.91.4 – TSNBLK object field
This field displays the information on the last committed
transaction.
3.91.5 – AIJDB object field
This field displays the AIJ control information.
3.91.6 – AIJFB object field
This field displays the AIJ journal information.
3.91.7 – RTUPB object field
This field displays information on active users.
3.91.8 – ACTIVE object field
This field displays information on active transactions.
3.91.9 – CPT object field
This field displays information on the corrupt page table.
3.91.10 – RCACHE object field
This field displays information on row caches.
3.91.11 – CLIENT object field
This field displays client-specific information.
3.91.12 – CLTSEQ object field
This field displays client sequence information.
3.91.13 – UTILITY object field
This field displays RMU utility information.
3.92 – IO_DASHBOARD_SCREEN
3.92.1 – Buffer Count field
This field displays the default buffer count used by database
processes.
3.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.
3.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.
3.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.
3.92.5 – DAPF Depth Count field
This field displays the detected asynchronous pre-fetch depth
count setting.
3.92.6 – DAPF Start Count field
This field displays the detected asynchronous pre-fetch start
count.
3.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.
3.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.
3.92.9 – ABW Batch Max field
This field displays the asynchronous batch write maximum batch
size setting.
3.93 – locking DASHBOARD screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.94 – AIJ DASHBOARD screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.94.8 – ARB Count field
This field displays the number of after-image journal request
blocks (ARBs) that are in use for the database.
3.95 – Checkpoint DASHBOARD screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.96 – Hot standby DASHBOARD screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.97 – Row Cache DASHBOARD screen
3.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.
3.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.
3.97.3 – Latch Spin Count field
This field indicates the number of times a process trying to
acquire a latch should spin before hibernating.
3.98 – ruj DASHBOARD screen
3.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.
3.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.
3.99 – Monitor DASHBOARD screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.100 – ABS DASHBOARD screen
3.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.
3.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.
3.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.
3.101 – ALS DASHBOARD screen
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.102 – DBR DASHBOARD screen
3.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.
3.103 – RCS DASHBOARD screen
3.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.
3.103.2 – Batch Count field
This field displays the number of rows to be flushed to disk.
3.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.
3.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.
3.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.
3.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.
3.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.
3.103.8 – Cold Record Count field
This field displays the number of unmodified rows in the row
cache.
3.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.
3.104 – Per process i o DASHBOARD screen
3.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.
3.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.
3.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.
3.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.
3.104.5 – DAPF Depth Count field
This field displays the detected asynchronous prefetch depth
setting.
3.104.6 – DAPF Start Count field
This field displays the detected asynchronous prefetch start
count.
3.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.
3.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.
3.104.9 – ABW Batch Max field
This field displays the asynchronous batch write maximum batch
size setting.
3.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.
3.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.
3.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.
3.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.
3.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.
3.105 – Per process JOURNAL DASHBOARD screen
3.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.
3.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.
3.105.3 – AIJ Stall Interval field
This field displays the AIJ group commit stall time, in
milliseconds.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.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.
3.106 – Per Process Row Cache DASHBOARD screen
3.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.
3.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.
3.106.3 – Latch Spin Count field
This field indicates the number of times a process trying to
acquire a latch should spin before hibernating.