1 – Summary IO Statistics screen
This screen summarizes database I/O activity and indicates
transaction and verb execution rates.
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.
3 – Summary Object Statistics screen
This screen provides cumulative information for all database root
file objects.
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.
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.
6 – Summary Tx Statistics screen
This screen summarizes database transaction activity and
indicates transaction and verb execution rates.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
51 – AIJ Statistics screen
This screen monitors both logical and physical after-image
journaling activity.
52 – Group Commit Statistics screen
This screen monitors group commit activity.
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.
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.
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.
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.
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.
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.
59 – Fast Incr Backup Statistics screen
This screen displays statistics about the fast incremental backup feature.
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.
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.
62 – Hot Standby Statistics screen
This screen provides information about the performance and state
of the Hot Standby feature.
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.
64 – Hot Standby Network screen
This screen displays information about active Hot Standby
connections.
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.
66 – PIO Statistics Data Fetches screen
This screen provides statistics on how data page requests are
handled.
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.
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.
69 – PIO Statistics SPAM Fetches screen
This screen provides statistics on how SPAM page requests are
handled.
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.
71 – PIO Statistics Data Writes screen
This screen provides information concerning data file writes and
buffer unmarking activity (buffer writes to the disk).
72 – PIO Statistics SPAM Writes screen
This screen provides information concerning SPAM file writes.
73 – PIO Statistics File Access screen
This screen provides information concerning file access. The
stall times are displayed in hundredths of a second.
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.
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.
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.
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.
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.
79 – File IO Overview screen
This screen shows a summary of I/O activity for all data and
snapshot files.
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.
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.
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.
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.
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.
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.
86 – File IO Overview Total I Os screen
This screen shows the total synchronous and asynchronous read and
write counts.
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.
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.
89 – File IO Overview Total current I Os screen
This screen shows the total current synchronous and asynchronous
read and write counts.
90 – File IO Overview Unsorted current I Os screen
This screen shows the current synchronous and asynchronous read
and write counts in unsorted order.
91 – File IO Overview Unsorted total I O screen
This screen shows the total synchronous and asynchronous read and
write counts in unsorted order.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
115 – Locking area locks screen
This screen monitors the database physical area locks.
116 – Locking buffer page locks screen
This screen monitors the database page locks. Page locks are used
to manage the database page buffer pool.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
129 – Locking nowait transaction screen
This screen monitors the database nowait transaction lock.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
145 – File Lock Overview Unsorted screen
This screen shows locking statistics for all the active storage
area and snapshot files in unsorted order.
146 – File Lock Overview Locks screen
This screen shows locking statistics for all the active storage
area and snapshot files sorted by lock requests.
147 – File Lock Overview Promotions screen
This screen shows locking statistics for all the active storage
area and snapshot files sorted by promotion requests.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
170 – Row cache Latch requests screen
This screen displays the statistics for the number of latch
requests that have occurred.
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.
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).
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.
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.
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.
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.
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.
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.
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.
180 – Row cache vlm requests screen
This screen displays the number of VLM requests made.
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.
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.
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.
184 – Row cache hash misses screen
This screen displays the total number of times the row cache hash
table overflowed.
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.
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.
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.
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.
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.
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.
191 – RCS Statistics screen
This screen provides information about the run-time operation of
the Row Cache Server (RCS) process.
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.
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.
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.
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.
196 – Name Translation screen
This screen shows statistics on database dashboard updates and
logical name translation.
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.
198 – Object FILID object screen
This screen displays the statistics for the FILID object. The
FILID object contains the storage area information.
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.
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.
201 – Object AIJDB object screen
This screen displays the statistics for the AIJDB object. The
AIJDB object contains the AIJ control information.
202 – Object AIJFB object screen
This screen displays the statistics for the AIJFB object. The
AIJFB object contains the AIJ journal information.
203 – Object RTUPB object screen
This screen displays the statistics for the RTUPB object. The
RTUPB object contains information on active users.
204 – Object ACTIVE object screen
This screen displays the statistics for the ACTIVE object. The
ACTIVE object contains information on active transactions.
205 – Object CPT object screen
This screen displays the statistics for the CPT object. The CPT
object contains information on the corrupt page table.
206 – Object RCACHE object screen
This screen displays the statistics for the RCACHE object. The
RCACHE object contains the row cache information.
207 – Object CLIENT object screen
This screen displays the statistics for the CLIENT object. The
CLIENT object contains client-specific information.
208 – Object CLTSEQ object screen
This screen displays the statistics for the CLTSEQ object. The
CLTSEQ object contains the client sequence information.
209 – Object UTILITY object screen
This screen displays the statistics for the UTILITY object. The
UTILITY object contains information used by the RMU utility.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.