1  Overview
 

2  Keyboard

     [A]larm    - specify a duration that a process must stall
                  before it appears on the Stall Messages screen
     [B]ell     - activates or deactivates the alarm bell
     [B]rief    - select brief display
     [C]onfig   - configure the statistics screen
     [E]xit     - exit the Performance Monitor
     [F]ilter   - filter stall messages
     [F]ull     - select full display
     [G]raph    - display a histogram graph
     [H]elp     - display help
     [I]nput    - displays the Select Input Control menu
     [L]ockID   - display submenu of lock IDs
     [M]enu     - display main menu
     [N]ormal   - puts you back into the normal screen display
     [N]umbers  - display numeric statistics
     [O]ptions  - display report options
     [P]ause    - pause the display
     [P]ageInfo - display page information
     [R]efresh  - refreshes the screen
     [R]eset    - reset the statistics
     [S]et_rate - set the display update rate
     [S]tep     - advances by one record in the input file while
                  in paused mode
     [T]ime_plot- plot field's value by time
     [U]nreset  - reverse effect of Reset option
     [U]pdate   - change the value of a database attribute
     [W]rite    - write the screen to rmu.scr
     [X]_plot   - plot rate of current field
     [Y]ank     - select statistics field
     [Z]oom     - display detailed information about a specific item
     !          - invoke tools facility
     $          - invoke DCL command facility
     #          - display submenu for current screen
     +          - advance 'n' screens forward
     -          - advance 'n' screens backward
     ?          - display help
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     <help> or <PF2>                - display help
     <up-arrow> or <down-arrow>     - highlight a menu option
     <return>, <enter> or <select>  - select a menu option
     <control-W>                    - repaint the screen
     <control-Z>                    - cancel a menu or return to DCL
     <prev-screen> or <left-arrow>  - move to previous display
     <next-screen> or <right-arrow> - move to next display
     spacebar                       - advance to next display
                                      containing database activity
 

2  Screens
 

3  Summary_IO_Statistics_screen
   This screen summarizes database I/O activity and indicates
   transaction and verb execution rates.
 

3  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.
 

3  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.
 

3  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.
 

3  Summary_Tx_Statistics_screen
   This screen summarizes database transaction activity and
   indicates transaction and verb execution rates.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  AIJ_Statistics_screen
   This screen monitors both logical and physical after-image
   journaling activity.
 

3  Group_Commit_Statistics_screen
   This screen monitors group commit activity.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  Fast_Incr_Backup_Statistics_screen
This screen displays statistics about the fast incremental backup
feature.
 

3  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.
 

3  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.
 

3  Hot_Standby_Statistics_screen
   This screen provides information about the performance and state
   of the Hot Standby feature.
 

3  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.
 

3  Hot_Standby_Network_screen
   This screen displays information about active Hot Standby
   connections.
 

3  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.
 

3  PIO_Statistics__Data_Fetches_screen
   This screen provides statistics on how data page requests are
   handled.
 

3  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.
 

3  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.
 

3  PIO_Statistics__SPAM_Fetches_screen
   This screen provides statistics on how SPAM page requests are
   handled.
 

3  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.
 

3  PIO_Statistics__Data_Writes_screen
   This screen provides information concerning data file writes and
   buffer unmarking activity (buffer writes to the disk).
 

3  PIO_Statistics__SPAM_Writes_screen
   This screen provides information concerning SPAM file writes.
 

3  PIO_Statistics__File_Access_screen
   This screen provides information concerning file access. The
   stall times are displayed in hundredths of a second.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  File_IO_Overview_screen
   This screen shows a summary of I/O activity for all data and
   snapshot files.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  File_IO_Overview__Total_I_Os__screen_
   This screen shows the total synchronous and asynchronous read and
   write counts.
 

3  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.
 

3  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.
 

3  File_IO_Overview__Total_current_I_Os__screen_
   This screen shows the total current synchronous and asynchronous
   read and write counts.
 

3  File_IO_Overview__Unsorted_current_I_Os__screen_
   This screen shows the current synchronous and asynchronous read
   and write counts in unsorted order.
 

3  File_IO_Overview__Unsorted_total_I_O__screen_
   This screen shows the total synchronous and asynchronous read and
   write counts in unsorted order.
 

3  File_IO_Overview__Total_Discarded__screen_
   This screen shows the total synchronous and asynchronous read and
   write counts, sorted by descending total pages discarded.
 

3  File_IO_Overview__Current_Discarded__screen_
   This screen shows the total synchronous and asynchronous read and
   write counts, sorted by descending current pages discarded.
 

3  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
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  Locking__area_locks__screen_
   This screen monitors the database physical area locks.
 

3  Locking__buffer_page_locks__screen_
   This screen monitors the database page locks. Page locks are used
   to manage the database page buffer pool.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  Locking__nowait_transaction__screen_
   This screen monitors the database nowait transaction lock.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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).
 

3  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.
 

3  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.
 

3  File_Lock_Overview__Unsorted__screen_
   This screen shows locking statistics for all the active storage
   area and snapshot files in unsorted order.
 

3  File_Lock_Overview__Locks__screen_
   This screen shows locking statistics for all the active storage
   area and snapshot files sorted by lock requests.
 

3  File_Lock_Overview__Promotions__screen_
   This screen shows locking statistics for all the active storage
   area and snapshot files sorted by promotion requests.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  Row_cache__Latch_requests__screen_
   This screen displays the statistics for the number of latch
   requests that have occurred.
 

3  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.
 

3  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).
 

3  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.
 

3  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.
 

3  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.
 

3  Row_cache__insert_cache__screen_
   This screen displays the statistics for the number of times new
   rows have been inserted into the row cache.
 

3  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.
 

3  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.
 

3  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.
 

3  Row_cache__vlm_requests__screen_
   This screen displays the number of VLM requests made.
 

3  Row_cache____window_turns__screen_
   This screen displays the number of VLM requests made for which
   the VLM address range was not immediately available.
 

3  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.
 

3  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.
 

3  Row_cache__hash_misses__screen_
   This screen displays the total number of times the row cache hash
   table overflowed.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  RCS_Statistics_screen
   This screen provides information about the run-time operation of
   the Row Cache Server (RCS) process.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  Name_Translation_screen
   This screen shows statistics on database dashboard updates and
   logical name translation.
 

3  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.
 

3  Object__FILID_object__screen_
   This screen displays the statistics for the FILID object. The
   FILID object contains the storage area information.
 

3  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.
 

3  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.
 

3  Object__AIJDB_object__screen_
   This screen displays the statistics for the AIJDB object. The
   AIJDB object contains the AIJ control information.
 

3  Object__AIJFB_object__screen_
   This screen displays the statistics for the AIJFB object. The
   AIJFB object contains the AIJ journal information.
 

3  Object__RTUPB_object__screen_
   This screen displays the statistics for the RTUPB object. The
   RTUPB object contains information on active users.
 

3  Object__ACTIVE_object__screen_
   This screen displays the statistics for the ACTIVE object. The
   ACTIVE object contains information on active transactions.
 

3  Object__CPT_object__screen_
   This screen displays the statistics for the CPT object. The CPT
   object contains information on the corrupt page table.
 

3  Object__RCACHE_object__screen_
   This screen displays the statistics for the RCACHE object. The
   RCACHE object contains the row cache information.
 

3  Object__CLIENT_object__screen_
   This screen displays the statistics for the CLIENT object. The
   CLIENT object contains client-specific information.
 

3  Object__CLTSEQ_object__screen_
   This screen displays the statistics for the CLTSEQ object. The
   CLTSEQ object contains the client sequence information.
 

3  Object__UTILITY_object__screen_
   This screen displays the statistics for the UTILITY object. The
   UTILITY object contains information used by the RMU utility.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

3  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.
 

2  Fields
 

3  Summary_IO_Statistics_screen
 

4  transactions_field
   This field gives the number of completed database transactions.
   This is the count of the COMMIT and ROLLBACK statements that have
   executed.
 

4  verb_successes_field
   This field gives the number of completed verbs that returned a
   successful status code.
 

4  verb_failures_field
   This field gives the number of completed verbs that returned
   an error status code. Errors include end-of-collection and
   deadlocks, as well as all other exception conditions.
 

4  synch_data_reads_field
   This field gives the number of read-I/Os (queued I/O requests)
   issued to the database storage area for single-file and multifile
   databases and snapshot files. This operation reads database pages
   synchronously from the database.
 

4  synch_data_writes_field
   This field gives the number of write-I/Os (queued I/O requests)
   issued to the database storage area for single-file and multifile
   databases and snapshot files. This operation writes modified
   database pages synchronously back to the database.
 

4  asynch_data_reads_field
   This field gives the number of read-I/Os (queued I/O requests)
   issued to the database storage area for single-file and multifile
   databases and snapshot files. This operation reads database pages
   asynchronously from the database.
 

4  asynch_data_writes_field
   This field gives the number of write-I/Os (queued I/O requests)
   issued to the database storage area for single-file and multifile
   databases and snapshot files. This operation writes modified
   database pages asynchronously back to the database.
 

4  RUJ_file_reads_field
   This field gives the number of read-I/Os (queued I/O requests)
   issued to the database recovery-unit journal (.ruj) files. This
   operation reads before-image records from the .ruj file to roll
   back a verb or a transaction.
 

4  RUJ_file_writes_field
   This field gives the number of write-I/Os (queued I/O requests)
   issued to the database recovery-unit journal (.ruj) files. This
   operation writes before-image records to the .ruj file in case
   a verb or transaction must be rolled back. Before-images must be
   written to the RUJ file before the corresponding database page
   can be written back to the database.
 

4  AIJ_file_reads_field
   The number of read-I/Os issued to the database .aij file. If
   after-image journaling is not enabled for the database, this
   statistic will be zero.
 

4  AIJ_file_writes_field
   This field gives the total number of write-I/Os (queued I/O
   requests) issued to the database after-image journal (.aij) file.
   If after-image journaling is not enabled for the database, this
   statistic will be zero. This operation writes after-image records
   to the .aij file to facilitate rollforward recovery using the RMU
   Recover command.
 

4  ACE_file_reads_field
   This field gives the total number of read I/Os issued to the ACE
   file.
 

4  ACE_file_writes_field
   This field gives the total number of write I/Os issued to the ACE
   file.
 

4  root_file_reads_field
   This field gives the number of read-I/Os (queued I/O requests)
   issued to the database root (.rdb) file. Oracle Rdb reads the
   .rdb file when a new user attaches to the database and when an
   .rdb file control block needs to be updated because of database
   activity on another VMScluster node.
 

4  root_file_writes_field
   This field gives the number of write-I/Os (queued I/O requests)
   issued to the database root (.rdb) file. Oracle Rdb writes to
   the .rdb file when a user issues a COMMIT or ROLLBACK statement.
   Other events also cause updates to the .rdb file.
 

3  Summary_Locking_Statistics_screen
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   Each deadlock reported in the "rqst deadlocks" field is also
   reported in the "rqsts stalled" field. This is because each
   deadlocked request is also a stalled request.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is composed of two different
   types of blocking ASTs: those generated externally and those
   generated internally.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that the
   same work would have to be performed anyway if a blocking AST
   were to be received from the operating system. This algorithm
   serves as an optimistic code optimization; the process, assuming
   it would eventually receive a blocking AST for the particular
   lock, executes the blocking AST routine. The Performance Monitor
   does not differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

4  invalid_lock_block_field
   This field gives the number of invalid lock value blocks
   encountered during a lock request or lock promote operation.
 

4  ignored_lock_mode_field
   This field indicates the number of lock release operations that
   could not be performed due to the lock release being requested
   from AST context. The lock is instead demoted to NL mode, and can
   be released later.

   Note that there is no storage area specific statistic for ignored
   lock mode statistics.
 

3  Summary_Object_Statistics_screen
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   shared retrieval access.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object was
   actually updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Summary_Cache_Statistics_screen
 

4  latch_requests_field
   This field displays the total number of latch requests that
   have occurred. A latch is requested whenever an internal data
   structure needs to be atomically modified, and indicates a
   potential stall point. The duration of the latch is essentially
   non-measureable.
 

4  __retried_field
   This field indicates the latch could not be immediately acquired
   and the latch had to be requested again. This field provides
   an indication of the contention on the row cache. Ideally, this
   field should be as close to zero as possible.
 

4  cache_searches_field
   This field displays the total number of times the row cache was
   searched for a particular row (DBKEY). Values within this field
   are subdivided into the following fields:

      found in workset
      found in cache
      found too big
 

4  __found_in_workset_field
   This field indicates the particular row was found in the process'
   working set and no additional work was required to fetch the row.
   This is the ideal situation.
 

4  __found_in_cache_field
   This field indicates the particular row was not found in the
   process' working set, but was found in the global row cache. When
   this occurs, it is possible that the process will have to make
   room in the working set by removing an existing row to the global
   cache.
 

4  __found_too_big_field
   This field indicates the particular row was found in the global
   cache, but the row is now too large to fit into the specified
   cache buffer. At one time, the row fit into the cache, but it
   no longer does. Therefore, the cache effectiveness is reduced
   because a cache entry is reserved for the row but no row caching
   is possible.
 

4  insert_cache_field
   This field indicates the total number of times new rows have
   been inserted into the row cache. Values within this field are
   subdivided into the following fields:

      row too big
      cache full
      collision
 

4  __row_too_big_field
   This field indicates the row was initially too large to fit into
   the specified row cache buffer.
 

4  __cache_full_field
   This field indicates that all row cache entries were modified
   and could not be flushed to disk in order to make space for the
   new row. This is an indication that the row cache checkpointing
   intervals specified for the database may be too large.
 

4  __collision_field
   This field displays the total number of row cache hash table
   collisions that occurred when inserting new rows. This field
   provides an indication of the effectiveness of the cache size.
 

4  VLM_requests_field
   This field displays the number of VLM requests made.
 

4  __window_turns_field
   This field displays the number of VLM requests made for which the
   VLM address range was not immediately available.
 

4  skipped_dirty_slot_field
   This field displays the total number of cache entries that could
   not be replaced because the slot contained modified data rows.
   This field provides an indication of the relative amount of work
   required to find space in order to insert a new row into the
   cache.
 

4  skipped_inuse_slot_field
   This field displays the total number of cache entries that
   could not be replaced because the slot was referenced by other
   processes. This field provides an indication of the relative
   amount of work required to find space in order to insert a new
   row into the cache.
 

4  hash_misses_field
   This field displays the total number of times the row cache hash
   table overflowed.
 

4  cache_unmark_field
   This field displays the total number of times a row in the cache
   was flushed to disk, thus making it eligible to be replaced.
   However, this field does not indicate whether or not the row was
   emptied from the cache.
 

3  Summary_Cache_Unmark_Statistics_screen
 

4  latch_granted_field
   This field displays the number of times the row lock (latch) was
   granted.
 

4  latch_stalled_field
   This field displays the number of times the row lock stalled
   before being granted.
 

4  latch_deadlock_field
   This field displays the number of times the row lock stall
   resulted in a deadlock.
 

4  latch_demoted_field
   This field displays the number of times the row lock was
   released.
 

4  latch_stall_x100_field
   This field displays the row lock stall time (in hundredths of a
   second).
 

3  Summary_Tx_Statistics_screen
 

4  transactions_field
   This field gives the number of completed database transactions.
   This is the count of the COMMIT and ROLLBACK statements that have
   executed.
 

4  __committed_field
   This field identifies the actual number of transactions that
   committed successfully to the database.
 

4  __rolled_back_field
   This field identifies the actual number of transactions that were
   aborted and were not applied to the database.
 

4  ____duration_x100_field_
   This field identifies the duration of the transaction rollback
   operation, expressed in hundredths of a second displayed as a
   whole number. For example, the value 500 is actually 5 seconds.
 

4  __prepared_field
   This field identifies the number of distributed transactions
   that have successfully "prepared" themselves for subsequent
   transaction commit.
 

4  __not_modified_field
   This field identifies the number of committed transactions that
   did not modify any database objects. This field includes both
   read-only and read/write transactions.
 

4  verb_successes_field
   This field gives the number of completed verbs that returned a
   successful status code.
 

4  verb_failures_field
   This field gives the number of completed verbs that returned
   an error status code. Errors include end-of-collection and
   deadlocks, as well as all other exception conditions.
 

4  __duration_x100_field
   This field identifies the duration of the verb failure rollback
   operation, expressed in hundredths of a second displayed as a
   whole number. For example, the value 500 is actually 5 seconds.
 

4  checkpoints_field
   This field identifies the number of checkpoints performed by
   users. This field does not include the initial checkpoint when
   the user first attaches to the database.
 

4  ___duration_x100_field
   This field displays the checkpoint duration, expressed in
   hundredths of a second displayed as a whole number. For example,
   the value 500 is actually 5 seconds.
 

4  RUJ_file_reads_field
   This field displays the total number of read I/O operations
   performed on the RUJ journal during the transaction undo phase.
   The RUJ file is never written by the database recovery (DBR)
   process.

   This field includes both synchronous and asynchronous I/O read
   requests.
 

4  ____file_writes_field_
   This field displays the total number of write I/O operations
   performed on the RUJ journal during the transaction phase.

   This field includes both synchronous and asynchronous I/O read
   requests.
 

4  ____file_extend_field_
   This field identifies the number of times an RUJ file has been
   extended.
 

3  Record_Statistics_screen
 

4  record_marked_field
   This field gives the number of records marked. A record is marked
   when it is modified or it is erased, but not when it is stored.
   This field does not include records modified in a temporary
   table.
 

4  record_fetched_field
   This field gives the number of records, including snapshot
   records. This field does not include records retrieved from a
   temporary table.
 

4  ____fragmented_field_
   This subfield indicates the number of record fragments that
   Oracle Rdb had to fetch. A record is fragmented if it is too
   large to fit on one page. A fragmented record requires more
   CPU time and more virtual memory, and often requires additional
   I/O operations because each record fragment must be fetched. If
   this value is high compared to the number of records fetched,
   Oracle Corporation recommends that you use the RMU Analyze Areas
   command to further analyze the problem to see how many records
   are actually fragmented.
 

4  __record_stored_field
   This field gives the number of records stored in the database.
   This field does not include records stored in temporary tables.
 

4  _____fragmented_field_
   This subfield indicates the number of rows stored as fragmented
   records in the database. This number indicates that a page
   size is smaller than a record's uncompressed size (including
   overhead). You should use the RMU Analyze Areas command to
   further analyze the problem and then increase the page size for
   the storage area that has the problem.
 

4  __pages_checked_field
   This field indicates the number of pages checked in order to
   store a record. Ideally, very few candidate pages need to
   be checked when storing a record. However in certain cases,
   depending on record size, access method, locked space on a page,
   and SPAM thresholds, storing a record requires a number of page
   fetches.
 

4  _______saved_IO_field_
   This field gives the number of pages checked that did not result
   in an I/O because the page was already in the buffer. It is
   essentially a "for free" pages checked.
 

4  ______discarded_field_
   This field identifies the number of pages checked but discarded
   because the actual free space on that page did not meet the
   physical requirements needed to store a new record.
 

4  record_erased_field
   This field gives the number of records erased from the database.
   This field does not include records erased from temporary
   tables.
 

4  ___fragmented_field
   This subfield indicates the number of fragmented records erased
   from the database.
 

4  temp_record_marked_field
   This field gives the number of records marked in a temporary
   table. A record is marked when it is modified or it is erased,
   but not when it is stored.
 

4  temp_record_fetchd_field
   This field gives the number of records fetched from a temporary
   table.
 

4  temp_record_stored_field
   This field gives the number of records stored in a temporary
   table.
 

4  temp_record_erased_field
   This field gives the number of records erased from a temporary
   table.
 

3  Custom_Statistics_screen
 

4  database_binds_____field_
   This field displays the total number of database attaches on
   the current node. If a single process attaches to the database
   multiple times, this statistic is incremented by the actual
   number of attaches.
 

4  transactions_______field_
   This field gives the number of completed database transactions.
   This is the count of the COMMIT and ROLLBACK statements that have
   executed.
 

3  Snapshot_Statistics_screen
 

4  Total_transactions_field
   This field gives the total number of transactions that have been
   committed or rolled back, including read-only transactions.
 

4  R_O_transactions_field
   This field gives the total number of read-only transactions that
   have been committed or rolled back.
 

4  retrieved_record_field
   This field gives the number of records retrieved by read-only
   transactions.
 

4  __fetched_line_field
   This field gives the number of lines fetched by read-only
   transactions. To retrieve a single record, a transaction might
   actually check a number of lines, some of which may be empty.
 

4  ____read_snap_page_field_
   This field gives the number of snapshot pages fetched by read-
   only transactions. If this count is high relative to the other
   read fields, read-only transactions are fetching records that
   are being updated frequently, and the snapshot file is being used
   extensively.
 

4  stored_snap_record_field
   This field gives the number of records stored in the snapshot
   file by update transactions. Every snapshot record stored by an
   update transaction implies that a snapshot page was found and
   utilized. In the best case, this is a single-page fetch. The
   "page in use," "page too full," page conflict," and "extended
   file" subfields indicate some of the extra overhead involved
   in finding suitable snapshot pages on which to store snapshot
   records.
 

4  ____page_in_use_field_
   This field gives the number of pages fetched that were unsuitable
   for storing snapshot records because the page was owned by
   another transaction. A new snapshot page cannot be used again
   until the TSN that denotes the age of the page is less than the
   oldest active TSN in the database. This ensures that read-only
   transactions always find the correct version of a record.
 

4  ____page_too_full_field_
   This field gives the number of pages fetched that were unsuitable
   for storing snapshot records because there was not enough room on
   the snapshot page to include another version of a record. In this
   case, a new snapshot page must be fetched and linked with the
   full page. This allows read-only transactions to follow a chain
   of snapshot pages to find the correct version of a record.
 

4  ____page_conflict_field_
   This field gives the number of times a snapshot page fetch
   was requested but aborted due to a lock conflict with another
   process. When a page fetch conflicts with another process,
   another target page is fetched and checked so the lock conflict
   does not cost a disk I/O operation.
 

4  ____extended_file_field_
   This field gives the number of times the snapshot file has been
   extended. The snapshot file is extended when an update operation
   cannot find a suitable page on which to store a snapshot record
   after checking a certain number of pages.
 

3  Stall_Statistics__Aggregate_counts__screen_
 

4  miscellaneous______field_
   This field displays generic stalls, such as waiting for a
   bugcheck dump to complete.
 

4  records____________field__
   This field displays record-related stalls, such as waiting for
   record locks to be granted.
 

4  pages______________field__
   This field displays page-related stalls, such as waiting for
   storage area I/O to complete or page locks to be granted.
 

4  tables_____________field__
   This field displays table-related stalls, such as waiting for
   logical area locks to be granted.
 

4  storage_areas______field_
   This field displays stalls related to storage areas, such as
   waiting for storage areas to be created, deleted, truncated or
   opened.
 

4  database_rootfile__field
   This field displays stalls related to the database rootfile, such
   as waiting for rootfile I/O to complete or object locks to be
   granted.
 

4  recovery_journals__field
   This field displays journal-related stalls, such as opening,
   initializing or extending journals, as well as waiting for
   journal locks to be granted.
 

4  user_transactions__field
   This field displays transaction-related stalls, such as
   waiting for distributed transactions to commit, or waiting for
   checkpoints to complete.
 

4  hot_standby________field_
   This field displays stalls related to the Hot Standby feature.
 

4  database___________field__
   This field displays database-related stalls, such as waiting for
   the database freeze to complete.
 

3  Stall_Statistics__Aggregate_durations__screen_
 

4  miscellaneous______field_
   This field displays generic stalls, such as waiting for a
   bugcheck dump to complete.
 

4  records____________field__
   This field displays record-related stalls, such as waiting for
   record locks to be granted.
 

4  pages______________field__
   This field displays page-related stalls, such as waiting for
   storage area I/O to complete or page locks to be granted.
 

4  tables_____________field__
   This field displays table-related stalls, such as waiting for
   logical area locks to be granted.
 

4  storage_areas______field_
   This field displays stalls related to storage areas, such as
   waiting for storage areas to be created, deleted, truncated or
   opened.
 

4  database_rootfile__field
   This field displays stalls related to the database rootfile, such
   as waiting for rootfile I/O to complete or object locks to be
   granted.
 

4  recovery_journals__field
   This field displays journal-related stalls, such as opening,
   initializing or extending journals, as well as waiting for
   journal locks to be granted.
 

4  user_transactions__field
   This field displays transaction-related stalls, such as
   waiting for distributed transactions to commit, or waiting for
   checkpoints to complete.
 

4  hot_standby________field_
   This field displays stalls related to the Hot Standby feature.
 

4  database___________field__
   This field displays database-related stalls, such as waiting for
   the database freeze to complete.
 

3  AIJ_Statistics_screen
 

4  AIJ_file_writes_field
   This field gives the total number of write-I/Os (queued I/O
   requests) issued to the database after-image journal (.aij) file.
   The "data," "control," "file extend," and "switch over" counts
   further subdivide the statistic.
 

4  ____data_field_
   This field gives the number of write-I/Os to the database after-
   image journal file that contained only data records.
 

4  ____control_field_
   This field gives the number of write-I/Os to the database after-
   image journal file that contained OPEN, COMMIT, ROLLBACK, and
   checkpoint records. These writes may also include data records.
 

4  ____file_extend_field_
   This field gives the number of write-I/Os issued to the database
   after-image journal file to initialize new disk blocks when the
   file is extended.
 

4  ____switch_over_field_
   This field gives the number of times AIJ switch-over has occurred
   (the number of times journaling has switched from one journal
   file to another).
 

4  tx__block_span_field
   This field displays the number of blocks each transaction spans
   in the AIJ journal.
 

4  records_written_field
   This field gives the number of logical after-image journal
   records written to the after-image journal file. Because many
   logical records can be buffered into a single write-I/O, this
   number is usually much larger than the number of .aij file
   writes.

   No count is kept for the number of logical AIJ records read by
   the DBR process.
 

4  blocks_written_field
   This field gives the number of disk blocks written to the after-
   image journal file. Because many disk blocks may be written with
   a single write-I/O, this number may be larger than the number of
   .aij file writes. In addition, the same disk block can be written
   more than once, because it might not have been completely full
   the first time it was written.
 

4  ____filler_bytes_field_
   This field gives the number of filler bytes (bytes that contain
   nothing, that is, memory allocated but not used) needed to pad
   AIJ records to a disk block boundary. Filler bytes are necessary
   to ensure the readability of the after-image journal file in the
   event of a system failure during a write-I/O operation.
 

4  lock_rebuilds_field
   This field gives the number of times that the after-image journal
   lock value block had to be rebuilt. The AIJ lock value block
   contains the current end-of-file information about the after-
   image journal file. The lock value block can be lost when there
   is a VMScluster configuration change, or when a user process
   holding the lock terminates abnormally (with a Ctrl-Y/STOP, for
   example).
 

4  ____AIJ_file_reads_field_
   This field gives the number of read-I/Os executed during lock
   rebuilds. To rebuild the lock value block, the after-image
   journal file is read backwards to find the last record in the
   file.
 

4  shuffle_averted_field
   This field displays the number of times the group commit buffer
   has had a shuffle operation averted. The shuffle operation can be
   averted for a number of reasons, including setting the RDM$BIND_
   AIJ_SHUFFLE_DISABLED logical name to the value "0".
 

4  suspended_switch_field
   This field displays the number of times the AIJ switchover
   operation enters the suspended state.

   A database enters the "AIJ suspended" state when the AIJ switch-
   over operation cannot complete because there are no available
   AIJ journals. During this state, the DBA can add new AIJ
   journals or perform database backups, but all other AIJ-related
   activities are temporarily suspended until an AIJ journal becomes
   available.
 

3  Group_Commit_Statistics_screen
 

4  group_commits_field
   This field displays the number of group commit operations
   performed by the ALS process. Dividing the number of transactions
   by the number of groups gives the average group size (the inverse
   of the transaction average display.)
 

4  quick_flushes_field
   This field gives the number of times users requested their .aij
   records be flushed to the .aij file and those records had already
   been flushed by the cooperative actions of another user (group
   commit).
 

4  ARB_pool_searches_field
   This field gives the number of times the global after-image
   journal request block pool was searched. AIJ records are globally
   buffered using ARBs.
 

4  ____pre_allocation_field_
   This field gives the number of ARBs that are able to be pre-
   allocated, resulting in reduced transaction commit or rollback
   processing (increased throughput).
 

4  ____pool_empty_field_
   This field gives the number of times that the global after-image
   journal request block (ARB) pool was found to be empty. In this
   event, the active user must force a write operation to the after-
   image journal file to free an ARB.
 

4  cancel:_preemptive_field
   This field displays the number of times the background group-
   commit operation was canceled because there was no additional
   data to be formatted.
 

4  ___IO_free_format_field
   This field displays the number of times the foreground group-
   commit operation was canceled because there was no additional
   data to be formatted.
 

4  submit:_watchdog_field
   This field displays the number of times the ALS process attempted
   to perform a group-commit operation in anticipation of new work
   but found none.
 

4  ___io_completion_field
   This field displays the number of times the group-commit
   formatting was completed because the pending asynchronous I/O
   operation for the previous group-commit operation completed.
 

4  ___cache_overflows_field
   This field displays the number of times the 64-block .aij cache
   has overflowed.
 

4  ___cache_satisfied_field
   This field displays the number of times the group-commit
   formatting was completed because the cache-size constraints have
   been reached.
 

4  ___control_record_field
   This field displays the number of times the group-commit
   formatting was completed because of encountering a control
   record for which a process was waiting (and there was no I/O
   in progress).
 

4  ___DBR_recovery_field
   This field displays the number of times the group-commit
   formatting was completed because the current process is DBR and
   the database is frozen.
 

3  ALS_Statistics_screen
 

4  AIJ_file_writes_field
   This field gives the total number of write-I/Os (queued I/O
   requests) issued to the database after-image journal (.aij) file.
   The "data," "control," "file extend," and "switch over" counts
   further subdivide the statistic.
 

4  ____data_field_
   This field gives the number of write-I/Os to the database after-
   image journal file that contained only data records.
 

4  ____control_field_
   This field gives the number of write-I/Os to the database after-
   image journal file that contained OPEN, COMMIT, ROLLBACK, and
   checkpoint records. These writes may also include data records.
 

4  ____file_extend_field_
   This field gives the number of write-I/Os issued to the database
   after-image journal file to initialize new disk blocks when the
   file is extended.
 

4  ____switch_over_field_
   This field gives the number of times AIJ switch-over has occurred
   (the number of times journaling has switched from one journal
   file to another).
 

4  AIJ_Write_Time_field
   This field gives the time (in hundredths of a second) spent
   writing to the .aij file.
 

4  ALS_Hiber_Count_field
   This field displays the number of times the AIJ Log Server
   process spent hibernating while waiting for more work.
 

4  AIJ_Hiber_Time_field
   This field displays the amount of time (in hundredths of a
   second) that processes have spent hibernating while the AIJ log
   server processes their requests.
 

4  AIJ_Extend_Time_field
   This field gives the time (in hundredths of a second) spent
   extending the .aij file. An excessively high number often
   indicates a full disk or disk fragmentation, or may be an
   indication of the need for a larger allocation. Use the JOURNAL
   ALLOCATION IS clause of the SQL ALTER DATABASE statement to
   specify a larger allocation.
 

4  Group_Commits_field
   This field displays the number of group commit operations
   performed by the ALS process. Dividing the number of transactions
   by the number of groups gives the average group size (the inverse
   of the transaction average display.)
 

4  __ARBs_formatted_field
   This field displays the number of AIJ Request Blocks that were
   formatted by the ALS process.
 

4  __ARBs_background_field
   This field displays the number of AIJ Request Blocks that were
   formatted while asynchronous I/O was being performed to the AIJ
   journal.
 

4  premature_io_saved_field
   This field displays the number of I/Os saved by waiting for more
   work.
 

4  Cache_Overflows_field
   This field displays the number of times the 64-block .aij cache
   has overflowed.
 

3  2PC_Statistics_screen
 

4  total_tx_count_field
   This field displays the total number of transactions that have
   been committed or rolled back.
 

4  __2PC_tx_count_field
   This field displays the total number of distributed transactions
   that have been committed or rolled back.
 

4  total_tx_time_x100_field
   This field displays the total duration of all transactions,
   expressed in hundredths of a second.
 

4  __reg_tx_time_x100_field
   This field displays the total duration of all non-distributed
   transactions, expressed in hundredths of a second.
 

4  __2PC_tx_time_x100_field
   This field displays the total duration of all distributed
   transactions, expressed in hundredths of a second.
 

4  prepared_time_x100_field
   This field displays the total duration of the transaction
   resolution phase.
 

4  2PC_tx_resolved_field
   This field displays the total number of distributed transactions
   resolved by the database recovery process (DBR). This field
   indicates the number of processes that failed while in the
   prepared state.
 

4  ___2PC_committed_field
   This field displays the total number of distributed transactions
   that were committed.
 

4  ___2PC_aborted_field
   This field displays the total number of distributed transactions
   that were rolled back.
 

3  RUJ_Statistics_screen
 

4  RUJ_file_writes_field
   This field gives the number of write-I/Os (queued I/O requests)
   issued to the database recovery-unit journal (.ruj) files. This
   operation writes before-image records to the .ruj file in case
   a verb or transaction must be rolled back. Before-images must be
   written to the RUJ file before the corresponding database page
   can be written back to the database.
 

4  ____data_field_
   This field displays the total number of synchronous write I/O
   operations containing modified database data.
 

4  ____control_field_
   This field displays the total number of synchronous write I/O
   operations containing control (header) information.
 

4  ____file_extend_field_
   This field displays the total number of times the recovery-unit
   journal files have been extended.
 

4  records_written_field
   This field displays the number of journal records written to the
   recovery-unit journal (.ruj) file.
 

4  RUJ_file_reads_field
   This field gives the number of read-I/Os (queued I/O requests)
   issued to the database recovery-unit journal (.ruj) files. This
   operation reads before-image records from the .ruj file to roll
   back a verb or a transaction.
 

4  blocks_written_field
   This field gives the number of disk blocks written to the
   recovery-unit journal file. Because many disk blocks may be
   written with a single write-I/O, this number may be larger than
   the number of .ruj file writes. In addition, the same disk block
   can be written more than once, because it might not have been
   completely full the first time it was written.
 

4  _______read_field_
   This field displays the total number of 512-byte blocks that have
   been read from the .ruj files on this node.
 

4  cache_overflows_field
   This field displays the number of times the recovery-unit data
   cache has overflowed, causing a premature synchronous write I/O
   operation. Overflowing the data cache indicates update-intensive
   transactions.
 

4  DBKEY_cache_hits_field
   This field gives the number of times the same DBKEY (row) was
   modified within the same transaction and found in the DBKEY
   cache.
 

4  ______overflows_field_
   This field gives the number of times the DBKEY cache ran out of
   space and new space had to be allocated.
 

3  Fast_Incr_Backup_Statistics_screen
 

4  FIB_update_attempt_field
   This field displays the number of times the fast incremental
   backup (FIB) operation was attempted. The attempt does not always
   result in the SPAM page being updated.
 

4  FIB_map_updated_field
   This field displays the number of times the FIB map, a per-
   process data structure, was updated. This data structure
   indicates when each process no longer needs to update a
   particular SPAM page.
 

4  SPAM_page_updated_field
   This field displays the number of times a SPAM page was
   immediately modified to indicate that one or more pages in the
   SPAM interval have been modified since the last incremental
   backup. Each SPAM page update results in one synchronous read
   I/O and one synchronous write I/O operation.
 

4  SPAM_updt_deferred_field
   This field displays the number of times a SPAM page did not need
   to be immediately modified, but might have to be modified at a
   later time. In most cases, this statistic closely follows the FIB
   update attempt statistic.
 

3  Checkpoint_Statistics_screen
 

4  transactions_field
   The total number of transactions (both read/write and read-
   only transactions). This statistic represents all transactions
   (committed or rolled back) completed by all users of the
   database, including transactions that read from the database
   as well as transactions that modify the database.
 

4  checkpoints_field
   The total number of checkpoints. The total checkpoints
   category is further broken down into categories of reasons for
   checkpointing. The statistics for these categories are included
   in the "AIJ growth," "txn limit," "time limit," "rollback," "AIJ
   backup," and "global" subfields.

   Note that there may be more reasons for checkpoints than there
   are total checkpoints. For example, you might have a total count
   of 100 for checkpoints, but when you add the number of checkpoint
   reasons ("AIJ growth," "txn limit," "time limit," "rollback,"
   "AIJ backup," and "global"), the total could be greater than 100.
   This occurs because a single checkpoint may be triggered by more
   than one event. For example, a checkpoint may occur because of
   time and AIJ file growth. Although the total count columns for
   the "interval: seconds" and "interval: AIJ blks" fields are both
   incremented by one, the total count column for "checkpoints" is
   only incremented by one.
 

4  ____AIJ_growth_field_
   The number of checkpoints for all processes due to the .aij file
   growth checkpoint limit.
 

4  ____txn_limit_field_
   The number of checkpoints for all processes due to the logical-
   defined transaction limit.
 

4  ____time_limit_field_
   The number of checkpoints for all processes due to the time
   interval checkpoint limit.
 

4  ____rollback_field_
   The number of checkpoints automatically triggered by rollback of
   transactions that updated the database.
 

4  ____AIJ_backup_field_
   The number of system-generated checkpoints due to periodic
   backups to tape of the .aij file by the AIJ spooler.
 

4  ____global_field_
   The number of system-wide checkpoints, issued from an RMU
   Checkpoint, RMU Backup, or RMU Backup After_Journal command.
 

4  interval:_AIJ_blks_field
   This field displays the sum of the intervals between checkpoints
   due to AIJ growth in block checkpoints for all processes. For
   example, if Process 1 checkpoints at virtual block number (VBN)
   100, then checkpoints again at VBN 250, the AIJ block interval
   category is incremented by 150. If Process 2 checkpoints at VBN
   125, then checkpoints again at VBN 200, the AIJ block interval
   is incremented by an additional 75. Statistics for the other two
   interval categories are displayed in the "interval: tx count" and
   "interval: seconds" fields.

   If CHECKPOINT INTERVAL IS 1000 BLOCKS is specified with the SQL
   ALTER DATABASE statement, each process checkpoints when the .aij
   file has grown 1000 blocks since the process' last checkpoint.

   Keep in mind that checkpointing influences recovery time. The
   main reason to consult checkpoint statistics is to find the
   average interval per checkpoint. You can use the information in
   the total count column to compute this average. For each category
   of checkpoint reason, use the average interval per checkpoint to
   help you decide if a checkpointing interval should be adjusted,
   and by how much.

   If most of the checkpoints for a database are triggered by a
   particular checkpoint limit, that limit may be set too high,
   or the other two limits may be set too low. You can determine
   the average interval per checkpoint for each type of checkpoint
   limit. After you have this information, you can reset the limits
   so that each type of checkpoint limit triggers approximately the
   same number of checkpoints, which results in optimal performance.

   To compute the average interval in AIJ blocks, divide the
   total count for the AIJ block interval by the total number of
   checkpoints minus the number caused by AIJ backups. Although
   checkpoints caused by AIJ backups are counted in the total
   number of checkpoints, they are not counted in the total of AIJ
   block intervals. If the total count of AIJ block intervals is
   70000, the total count of checkpoints is 100, and the number
   of checkpoints caused by AIJ backups is 1, then the average AIJ
   block interval is 707:

         70000/(100 - 1) = 707

   The help for the "interval: tx count" field explains how to
   determine the average interval for transaction checkpoints.

   The help for the "interval: seconds" field explains how to
   determine the average interval for time checkpoints.
 

4  interval:_tx_count_field
   This field displays the sum of the intervals between checkpoints
   due to the transactions count checkpoint for all processes. For
   example, if Process 1 checkpoints after 20 transactions, the
   transactions count category is incremented by 20. If Process
   2 checkpoints after 30 transactions, the transactions count
   category is incremented by an additional 30. Statistics for the
   other two interval categories are displayed in the "interval: AIJ
   blks" and "interval: seconds" fields.

   The transactions limit for checkpoints is determined by the
   setting of the RDM$BIND_CKPT_TRANS_INTERVAL logical name. If
   RDM$BIND_CKPT_TRANS_INTERVAL is defined as a system logical set
   to 10, each process will checkpoint after 10 transactions unless
   a user redefines the RDM$BIND_CKPT_TRANS_INTERVAL logical to a
   different value. That is, if a user defines RDM$BIND_CKPT_TRANS_
   INTERVAL as a process logical and sets a value of 5, that user
   will checkpoint after 5 transactions.

   Keep in mind that checkpointing influences recovery time. The
   main reason to consult checkpoint statistics is to find the
   average interval per checkpoint. You can use the information in
   the total count column to compute this average. For each category
   of checkpoint reason, use the average interval per checkpoint to
   help you decide if a checkpointing interval should be adjusted,
   and by how much.

   If most of the checkpoints for a database are triggered by a
   particular checkpoint limit, that limit may be set too high,
   or the other two limits may be set too low. You can determine
   the average interval per checkpoint for each type of checkpoint
   limit. After you have this information, you can reset the limits
   so that each type of checkpoint limit triggers approximately the
   same number of checkpoints, which results in optimal performance.

   To compute the average transactions interval, divide the
   total count for transaction intervals by the total number of
   checkpoints. If the total count for transaction intervals is
   800 and the total number of checkpoints is 100, then the average
   number of transactions between checkpoints is 8.

         800 / 100 = 8

   The help for the "interval: AIJ blks" field explains how to
   determine the average interval for .aij file growth checkpoints.

   The help for the "interval: seconds" field explains how to
   determine the average interval for time checkpoints.
 

4  interval:_seconds_field
   This field displays the sum of the intervals between time in
   seconds checkpoints for all processes. For example, if Process
   1 checkpoints after 500 seconds, the time in seconds category is
   incremented by 500. If Process 2 checkpoints after 600 seconds,
   the time in seconds category is incremented by an additional 600.
   Statistics for the other two interval categories are displayed in
   the "interval: AIJ blks" and "interval: tx count" fields.

   If CHECKPOINT TIMED EVERY 600 SECONDS is specified with the
   SQL ALTER DATABASE statement, each process checkpoints every
   10 minutes.

   Keep in mind that checkpointing influences recovery time. The
   main reason to consult checkpoint statistics is to find the
   average interval per checkpoint. You can use the information in
   the total count column to compute this average. For each category
   of checkpoint reason, use the average interval per checkpoint to
   help you decide if a checkpointing interval should be adjusted,
   and by how much.

   If most of the checkpoints for a database are triggered by a
   particular checkpoint limit, that limit may be set too high,
   or the other two limits may be set too low. You can determine
   the average interval per checkpoint for each type of checkpoint
   limit. After you have this information, you can reset the limits
   so that each type of checkpoint limit triggers approximately the
   same number of checkpoints, which results in optimal performance.

   To compute the average time interval, divide the total count for
   seconds interval by the total number of checkpoints. If the total
   count for the seconds field is 59,300 and the total number of
   checkpoints is 100, the average number of seconds between each
   time-triggered checkpoint is 593.

         59,300 / 100 = 593

   The help for the "interval: AIJ blks" field explains how to
   determine the average interval for .aij file growth checkpoints.

   The help for the "interval: tx count" field explains how to
   determine the average interval for transaction checkpoints.
 

4  checkpoint_stall_field
   This field displays the checkpoint duration in seconds.
 

4  flushed_buffers_field
   This field displays the number of buffers flushed to disk during
   a checkpoint operation.
 

3  Recovery_Statistics_screen
 

4  process_attaches_field
   This field displays the total number of database attaches on
   the current node. If a single process attaches to the database
   multiple times, this statistic is incremented by the actual
   number of attaches.
 

4  process_failures_field
   This field displays the total number of processes that abnormally
   terminated and required database recovery.

   In the case of some other node failure, this statistic might
   indicate process failure on the other node that was actually
   recovered on this node.
 

4  DB_freeze_len_x100_field
   This field displays the total database freeze duration, expressed
   in hundredths of a second. During the database freeze, no
   database activity is permitted; the database is "frozen". The
   longer the duration, the more database performance bottlenecks
   may result.
 

4  Tx_REDO_count_field
   This field displays the total number of transactions that needed
   to be "redone".

   Transaction redo occurs when fast commit transaction processing
   is enabled. The fast commit feature contains several parameters
   that can be modified to control the overall redo duration, but at
   the expense of runtime performance.

   Transaction redo requires reading the AIJ journal from the failed
   process' checkpoint location and re-applying all subsequent
   committed database modifications for that process. This usually
   involves re-applying many committed transactions.

   The number of transactions redone is not as important as the
   amount of work required per transaction. In other words, a single
   long transaction requires the same redo processing as many short
   transactions.

   Transactions that are densely packed into a minimum AIJ interval
   are more efficiently redone than a transaction whose data
   spans a long range of AIJ blocks. In other words, long-running
   transactions that do only occasional infrequent database updates
   may be redone more efficiently as several short transactions.
   This is an application issue. However, total application
   throughput also affects this redo performance.

   Transaction redo is normally the longest portion of the process
   recovery operation.
 

4  __redo_time_x100_field
   This field displays the total time (in hundredths of a second)
   required for transactions that needed to be "redone".
 

4  Tx_UNDO_count_field
   This field displays the total number of transactions that needed
   to be "undone".

   Transaction undo requires reading the RUJ journal approximately
   twice, once forwards to determine the end of the current
   transaction, and then backwards from that location to the
   beginning of the RUJ file.

   Transaction undo is performed only on the transaction that was
   currently active, if any, at the time of process failure.
 

4  __undo_time_x100_field
   This field displays the total time (in hundredths of a second)
   required for transactions that needed to be "undone".
 

4  no_undo_needed_field
   This field displays the total number of transactions that did
   not need to be "undone". Occasionally, the failed process did
   not have any active transactions, thereby allowing the database
   recovery (DBR) process to avoid having to manually determine if a
   transaction needs being "undone".
 

4  Tx_committed_field
   This field displays the total number of transactions that were
   committed during the transaction undo phase. This normally
   occurs during the resolution phase of an in-progress distributed
   transaction. However, this event can also occur if an optimistic
   commit record was found in the AIJ journal that was not yet
   recorded in the process' recovery information.
 

4  Tx_rolled_back_field
   This field displays the total number of transactions that were
   rolled back during the transaction undo phase. This is the normal
   result of transaction undo.
 

4  No_resolve_needed_field
   This field displays the total number of transactions that did not
   need to be either committed or rolled back during the transaction
   undo phase. This normally occurs when fast commit transaction
   processing is enabled, where the RUJ file is examined to locate
   an active transaction, but none can be found.
 

4  AIJ_recover_x100_field
   This field displays the total time (in hundredths of a second)
   required to recover the in-progress AIJ flush operation, if any.
   This is normally a very fast operation.
 

4  GB_recover_x100_field
   This field displays the total time (in hundredths of a second)
   required to recover the global buffer information, if applicable.
   This is normally a very fast operation.
 

4  Cache_recover_x100_field
   This field displays the total time (in hundredths of a second)
   required to recover the row cache following RCS failure or node
   failure.

   Depending on the number and sizes of the active row caches, this
   can be a lengthy operation.
 

4  RUJ_file_reads_field
   This field displays the total number of read I/O operations
   performed on the RUJ journal during the transaction undo phase.
   The RUJ file is never written by the database recovery (DBR)
   process.
 

4  AIJ_file_reads_field
   This field displays the total number of read I/O operations
   performed on the AIJ journal during both the transaction redo
   and undo phases. If, during the transaction undo phase, the in-
   progress transaction is rolled back, a rollback record will be
   written to the AIJ journal.
 

3  Hot_Standby_Statistics_screen
 

4  AIJ_network_send_field
   This field displays the number of network messages sent.
 

4  AIJ_network_recv_field
   This field displays the number of network messages received.
 

4  Net_msg_processed_field
   This field displays the number of network messages processed.
   This field is only updated on the standby database, and is
   intended to be used as a comparison against the "AIJ network
   recv" field.
 

4  ____data_field_
   This field displays the number of data messages sent to the
   standby database or received from the master database.
 

4  ____control_field_
   This field displays the number of control (non-data) messages
   sent to the standby database or received from the master
   database.
 

4  ____checkpoints_field_
   This field displays the number of checkpoint operations
   performed.
 

4  Stall_time_x100_field
   This field displays the network I/O duration, in hundredths of
   seconds.
 

4  blocks_shipped_field
   This field displays the number of 512-byte blocks sent.
 

4  ______received_field_
   This field displays the number of 512-byte blocks received.
 

4  Stalled_MSN_found_field
   This field displays the number of stalled messages identified.
 

4  Network_Reconnect_field
   This field displays the number of times the network connection
   was lost between the master and standby databases. This statistic
   only applies to the master database. It could also indicate that
   the network object server (router) died prematurely.
 

4  Free_Network_Xmit_field
   This field displays the number of messages that have been sent
   for "free". That is, a group commit buffer that does not contain
   any transaction "commit" records can always be transmitted with a
   synchronization mode of "cold" since no replication of the buffer
   can be performed on the standby side. This is an indication of
   master database performance optimization.
 

3  Synchronization_Mode_Statistics_screen
 

4  transactions_field
   This field gives the number of completed database transactions.
   This is the count of the COMMIT and ROLLBACK statements that have
   executed.
 

4  cold_sync_send_field
   This field displays the number of cold mode messages sent to the
   standby database.
 

4  warm_sync_send_field
   This field displays the number of warm mode messages sent to the
   standby database.
 

4  hot_sync_send_field
   This field displays the number of hot mode messages sent to the
   standby database.
 

4  commit_sync_send_field
   This field displays the number of commit mode messages sent to
   the standby database.
 

4  cold_stall_x100_field
   This field displays the cold message duration, in hundredths of
   seconds.
 

4  warm_stall_x100_field
   This field displays the warm message duration, in hundredths of
   seconds.
 

4  hot_stall_x100_field
   This field displays the hot message duration, in hundredths of
   seconds.
 

4  commit_stall_x100_field
   This field displays the commit message duration, in hundredths of
   seconds.
 

4  Startup_Shutdown_field
   This field displays the number of times the hot standby feature
   was started or shut down.
 

4  Unexpected_Failure_field
   This field displays the number of times the hot standby feature
   was shutdown abnormally.
 

3  Recovery_Information_screen
 

4  transactions_field
   This field gives the number of completed database transactions.
   This is the count of the COMMIT and ROLLBACK statements that have
   executed.
 

4  _commit_field
   This field displays the number of transactions that have been
   committed to the standby database.
 

4  _rollback_field
   This field displays the number of transactions that have been
   rolled back prior to being applied to the standby database.
 

4  _prepared_field
   This field displays the number of distributed transactions that
   have been successfully prepared in anticipation of eventually
   being committed to the standby database.
 

4  Area_ready_field
   This field displays the number of physical storage areas that
   have been "readied" during the recovery operation.
 

4  AIJ_records_field
   This field displays the number of AIJ records applied.
 

4  _erase_mixed_field
   This field displays the number of "erase record" operations
   performed on a mixed-format storage area.
 

4  _erase_uniform_field
   This field displays the number of "erase record" operations
   performed on a uniform-format storage area.
 

4  _modify_mixed_field
   This field displays the number of "modify record" operations
   performed on a mixed-format storage area.
 

4  _modify_uniform_field
   This field displays the number of "modify record" operations
   performed on a uniform-format storage area.
 

4  SPAM_updated_field
   This field displays the number of SPAM page modifications that
   occurred as a result of the AIJ journal record. SPAM pages are
   typically modified due to a live data page changing its threshold
   information.
 

4  Num_failed_updates_field
   This field displays the number of failed updates that are
   currently pending REDO. In general, this field should always
   be zero. However, it may temporarily increase in value and
   subsequently return to zero.
 

4  TTl_failed_updated_field
   This field displays the total number of failed updates. A failed
   update is a database modification that cannot be immediately
   applied due primarily to the order in which AIJ journal records
   are recorded.
 

3  PIO_Statistics__Data_Fetches_screen
 

4  fetch_for_read_field
   The number of synchronous data page requests to the PIO subsystem
   where only read privileges are being requested for the page. If
   Oracle Rdb reads any area inventory pages (AIPs) and area bit map
   (ABM) pages while fetching the data page, the requests for the
   AIPs and ABM pages are included in the total count field.

   The sum of the fetch for read and fetch for write fields equals
   the total number of synchronous data page requests to the PIO
   subsystem.
 

4  fetch_for_write_field
   The number of data page requests to the PIO subsystem where
   update as well as read privileges are being requested for the
   page. If Oracle Rdb reads any AIPs and ABM pages while fetching
   the data page, the requests for the AIPs and ABM pages are
   included in the total count field.

   The sum of the fetch for read and fetch for write fields equals
   the total number of data page requests to the PIO subsystem.
 

4  in_LB:_all_ok_field
   The correct version of the requested page was found in the user's
   local buffer pool and the user already held the needed locks on
   that page.

   This line and the next four lines categorize data page requests
   to the PIO subsystem in terms of what work the subsystem had to
   do to satisfy the request. The sum of this line and the next four
   lines should be equal to the sum of the first two lines.

   The three lines with the LB heading further categorize those data
   page fetch requests to the PIO subsystem where the requested page
   was found in the user's local buffer pool.
 

4  ___LB:_need_lock_field
   The correct version of the requested page was found in the user's
   local buffer pool but additional locking was required (that is,
   the user did not have the page locked in the needed mode).
 

4  ___LB:_old_version_field
   The requested page was found in the user's local buffer pool but
   it was an obsolete version of the page (that is, the page has
   been changed by another user since it was read into this user's
   local buffer). Thus, the page must be read again from disk. In
   addition, locks will need to be obtained for this page.
 

4  not_found:_read_field
   Because the requested page was not found in the buffer pool, it
   was read in from disk. This required obtaining appropriate locks
   on the page.

   This line and the "not found: synth" line further categorize data
   page fetch requests to the PIO subsystem in which the requested
   page did not reside in the user's buffer pool.
 

4  _________:_synth_field_
   Because the requested page was not found in the buffer pool, it
   was synthesized into the pool without being read from disk. This
   required obtaining appropriate locks on the page.

   A requested page that is synthesized is either:

   o  "Read" from a WORM storage area

   o  "Read" from a uniform format area and the clump is unallocated

   In both cases, the page does not actually have to be read from
   disk because the page contents are known (that is, Oracle Rdb can
   determine what a formatted unused page looks like). Therefore,
   rather than actually reading the page from disk, Oracle Rdb
   synthesizes the page (produces a properly formatted unused page).
   Page and buffer locking must still occur to keep other users from
   accessing the same page.
 

4  in_AS:_all_ok_field
   The correct version of the requested page was found in the user's
   allocate set and the user already held the needed locks on that
   page.

   This line and the next eight lines categorize data page requests
   to the PIO subsystem in terms of what work the subsystem had
   to do to satisfy the request. The sum of this line and the next
   eight lines should be equal to the sum of the first two lines.

   The four lines with the AS: heading further categorize those data
   page fetch requests to the PIO subsystem where the requested page
   was found in the user's allocate set.
 

4  ___AS:_lock_for_GB_field
   The page was found in the user's allocate set and the user held
   sufficient locks to satisfy the request. But because of global
   buffers, additional locking was needed to verify that the version
   was correct. The version was, in fact, correct, so the extra
   locking overhead was due solely to the fact that global buffers
   were being used.
 

4  ___AS:_need_lock_field
   The correct version of the requested page was found in the user's
   allocate set but additional locking was required (that is, the
   user did not have the page locked in the needed mode).
 

4  ___AS:_old_version_field
   The requested page was found in the user's allocate set but it
   was an obsolete version of the page (that is, the page has been
   changed by another user since it was added to the requestor's
   allocate set). Thus, the page must be read again from disk. In
   addition, locks will need to be obtained for this page.
 

4  in_GB:_need_lock_field
   The correct version of the page was found in the global buffer
   pool. It was necessary to bring this page into the user's
   allocate set and to obtain a lock on the page.

   This line and the GB: old version line further categorize data
   page fetch requests to the PIO subsystem in which the requested
   page was not found in the user's allocate set but was found in
   the global buffer pool.
 

4  ___GB:_old_version_field
   The page was found in the global buffer pool but it was the wrong
   version. Thus, a lock had to be obtained, the page had to be
   read in from disk to a global buffer, and that buffer had to be
   brought into the user's allocate set.
 

4  ___GB:_transferred_field
   The count of the number of data pages that were transferred from
   one process to another without being written to the disk. This
   field is active only when the "transfer via memory" feature is
   enabled.
 

3  PIO_Statistics__SPAM_Fetches_screen
 

4  fetch_for_read_field
   The number of SPAM page requests to the PIO subsystem where only
   read privileges are being requested for the page.

   The sum of the fetch for read and fetch for write fields equals
   the total number of SPAM page requests to the PIO subsystem.
 

4  fetch_for_write_field
   The number of SPAM page requests to the PIO subsystem where
   update as well as read privileges are being requested for the
   page.

   The sum of the fetch for read and fetch for write fields equals
   the total number of SPAM page requests to the PIO subsystem.
 

4  in_LB:_all_ok_field
   The correct version of the requested page was found in the user's
   local buffer pool and the user already held the needed locks on
   that page.

   This line and the next four lines categorize SPAM page requests
   to the PIO subsystem in terms of what work the subsystem had to
   do to satisfy the request. The sum of this line and the next four
   lines should be equal to the sum of the first two lines.

   The three lines with the "LB:" heading further categorize those
   SPAM page fetch requests to the PIO subsystem where the requested
   page was found in the user's local buffer pool.
 

4  ___LB:_need_lock_field
   The correct version of the requested page was found in the user's
   local buffer pool but additional locking was required (that is,
   the user did not have the page locked in the needed mode).
 

4  ___LB:_old_version_field
   The requested page was found in the user's local buffer pool but
   it was an obsolete version of the page (that is, the page has
   been changed by another user since it was read into this user's
   local buffer). Thus, the page must be read again from disk. In
   addition, locks will need to be obtained for this page.
 

4  not_found:_read_field
   Because the requested page was not found in the buffer pool, it
   was read in from disk. This required obtaining appropriate locks
   on the page.

   This line and the "not found: synth" line further categorize SPAM
   page fetch requests to the PIO subsystem in which the requested
   page did not reside in the user's buffer pool.
 

4  _________:_synth_field_
   Because the requested page was not found in the buffer pool, it
   was synthesized into the pool without being read from disk. This
   requires obtaining appropriate locks on the page.

   A requested page that is synthesized is either:

   o  "Read" from a WORM storage area

   o  "Read" from a uniform format area and the clump is unallocated

   In both of these cases, the page does not actually have to be
   read from disk because the page contents are known (that is,
   Oracle Rdb can determine what a formatted unused page looks
   like). Therefore, rather than actually reading the page from
   disk, Oracle Rdb synthesizes the page (produces a properly-
   formatted unused page). Page and buffer locking must still occur
   to keep other users from accessing the same page.
 

4  in_AS:_all_ok_field
   The correct version of the requested page was found in the user's
   allocate set and the user already held the needed locks on that
   page.

   This line and the next eight lines categorize SPAM page requests
   to the PIO subsystem in terms of what work the subsystem had
   to do to satisfy the request. The sum of this line and the next
   eight lines should be equal to the sum of the first two lines.

   The four lines with the "AS:" heading further categorize those
   SPAM page fetch requests to the PIO subsystem where the requested
   page was found in the user's allocate set.
 

4  ___AS:_lock_for_GB_field
   The page was found in the user's allocate set and the user held
   sufficient locks to satisfy the request. But because of global
   buffers, additional locking was needed to verify that the version
   was correct. The version was, in fact, correct, so the extra
   locking overhead was due solely to the fact that global buffers
   were being used.
 

4  ___AS:_need_lock_field
   The correct version of the requested page was found in the user's
   allocate set but additional locking was required (that is, the
   user did not have the page locked in the needed mode).
 

4  ___AS:_old_version_field
   The requested page was found in the user's allocate set but it
   was an obsolete version of the page (that is, the page has been
   changed by another user since it was added to the requestor's
   allocate set). Thus, the page must be read again from disk. In
   addition, locks will need to be obtained for this page.
 

4  in_GB:_need_lock_field
   The correct version of the page was found in the global buffer
   pool. It was necessary to bring this page into the user's
   allocate set and to obtain a lock on the page.

   This line and the "GB: old version" line further categorize SPAM
   page fetch requests to the PIO subsystem in which the requested
   page was not found in the user's allocate set but was found in
   the global buffer pool.
 

4  ___GB:_old_version_field
   The page was found in the global buffer pool but it was the wrong
   version. Thus, a lock had to be obtained, the page had to be
   read in from disk to a global buffer, and that buffer had to be
   brought into the user's allocate set.
 

4  ___GB:_transferred_field
   The count of the number of SPAM pages that were transferred from
   one process to another without being written to the disk. This
   field is active only when the "transfer via memory" feature is
   enabled.
 

3  PIO_Statistics__SPAM_Prefetches_screen
 

4  APF_start:_success_field
   The number of times a APF-initiated buffer fetch attempt was
   successful in fetching the buffer. This is possible only if an EX
   lock can be obtained for the whole buffer. A successful APF fetch
   may actually issue an asynchronous read or simply ensure that a
   buffer that was already in the buffer pool now moves to the front
   of the LRU queue. In the latter case, the buffer then becomes
   least likely to be removed from the buffer pool.
 

4  _________:_failure_field_
   The number of times a APF-initiated buffer fetch attempt failed
   due to locking conflicts. If an EX lock cannot be obtained on the
   whole buffer, then the fetch attempt will fail.
 

4  APF_I_O:_utilized_field
   If a buffer is fetched by APF, it is marked APF_FETCHED. If the
   buffer is accessed again, then this statistic is incremented
   to indicate that prefetching the buffer by APF was worthwhile.
   The statistic is incremented only the first time the buffer is
   accessed.
 

4  _______:_wasted_field_
   If a APF-fetched buffer is removed from the buffer pool without
   being accessed, then this statistic is incremented to indicate
   that fetching the buffer was not worthwhile.
 

4  DAPF_start:success_field
   The number of times a DAPF-initiated buffer fetch attempt was
   successful in fetching the buffer. This is possible only if an
   EX lock can be obtained for the whole buffer. A successful DAPF
   fetch may actually issue an asynchronous read or simply ensure
   that a buffer that was already in the buffer pool now moves to
   the front of the LRU queue. In the latter case, the buffer then
   becomes least likely to be removed from the buffer pool.
 

4  __________:failure_field__
   The number of times a DAPF-initiated buffer fetch attempt failed
   due to locking conflicts. If an EX lock cannot be obtained on the
   whole buffer, then the fetch attempt will fail.
 

4  DAPF_I_O:_utilized_field
   If a buffer is fetched by DAPF, it is marked DAPF_FETCHED. If
   the buffer is accessed again, then this statistic is incremented
   to indicate that prefetching the buffer by DAPF was worthwhile.
   The statistic is incremented only the first time the buffer is
   accessed.
 

4  ________:_wasted_field_
   If a DAPF-fetched buffer is removed from the buffer pool without
   being accessed, then this statistic is incremented to indicate
   that fetching the buffer was not worthwhile.
 

3  PIO_Statistics__Data_Prefetches_screen
 

4  APF_start:success_field
   The number of times a APF-initiated buffer fetch attempt was
   successful in fetching the buffer. This is possible only if an EX
   lock can be obtained for the whole buffer. A successful APF fetch
   may actually issue an asynchronous read or simply ensure that a
   buffer that was already in the buffer pool now moves to the front
   of the LRU queue. In the latter case, the buffer then becomes
   least likely to be removed from the buffer pool.
 

4  _________:_failure_field_
   The number of times a APF-initiated buffer fetch attempt failed
   due to locking conflicts. If an EX lock cannot be obtained on the
   whole buffer, then the fetch attempt will fail.
 

4  APF_I_O:_utilized_field
   If a buffer is fetched by APF, it is marked APF_FETCHED. If the
   buffer is accessed again, then this statistic is incremented
   to indicate that prefetching the buffer by APF was worthwhile.
   The statistic is incremented only the first time the buffer is
   accessed.
 

4  _______:_wasted_field_
   If a APF-fetched buffer is removed from the buffer pool without
   being accessed, then this statistic is incremented to indicate
   that fetching the buffer was not worthwhile.
 

4  DAPF_start:success_field
   The number of times a DAPF-initiated buffer fetch attempt was
   successful in fetching the buffer. This is possible only if an
   EX lock can be obtained for the whole buffer. A successful DAPF
   fetch may actually issue an asynchronous read or simply ensure
   that a buffer that was already in the buffer pool now moves to
   the front of the LRU queue. In the latter case, the buffer then
   becomes least likely to be removed from the buffer pool.
 

4  __________:failure_field__
   The number of times a DAPF-initiated buffer fetch attempt failed
   due to locking conflicts. If an EX lock cannot be obtained on the
   whole buffer, then the fetch attempt will fail.
 

4  DAPF_I_O:_utilized_field
   If a buffer is fetched by DAPF, it is marked DAPF_FETCHED. If
   the buffer is accessed again, then this statistic is incremented
   to indicate that prefetching the buffer by DAPF was worthwhile.
   The statistic is incremented only the first time the buffer is
   accessed.
 

4  ________:_wasted_field_
   If a DAPF-fetched buffer is removed from the buffer pool without
   being accessed, then this statistic is incremented to indicate
   that fetching the buffer was not worthwhile.
 

3  PIO_Statistics__SPAM_Access_screen
 

4  fetch_for_read_field
   This field displays the total number of times the SPAM page was
   fetched for retrieval.
 

4  _uniform_area_scan_field
   This field displays the total number of times the SPAM page was
   fetched for retrieval during a uniform area scan operation. This
   is primarily to check if SPAM thresholds need to be adjusted.
 

4  _record_store_fet_field
   This field displays the total number of times the SPAM page was
   fetched for retrieval during a record store operation. This is
   primarily to check if SPAM thresholds need to be adjusted.
 

4  _record_modify_fet_field
   This field displays the total number of times the SPAM page was
   fetched for retrieval during a record modification operation.
   This is primarily to check if SPAM thresholds need to be
   adjusted.
 

4  _record_erase_fet_field
   This field displays the total number of times the SPAM page was
   fetched for retrieval during a record erase operation. This is
   primarily to check if SPAM thresholds need to be adjusted.
 

4  fetch_for_write_field
   This field displays the total number of times the SPAM page was
   fetched for update.
 

4  _record_store_upd_field
   This field displays the total number of times the SPAM page
   was fetched for update during a record store operation. This
   is primarily to modify the SPAM thresholds.
 

4  _record_modify_upd_field
   This field displays the total number of times the SPAM page was
   fetched for update during a record modification operation. This
   is primarily to modify the SPAM thresholds.
 

4  _record_erase_upd_field
   This field displays the total number of times the SPAM page
   was fetched for update during a record erase operation. This
   is primarily to modify the SPAM thresholds.
 

4  fetch_for_update_field
   This field displays the total number of times the SPAM page was
   fetched for update.
 

4  _clump_allocate_field
   This field displays the total number of times the SPAM page was
   updated for a clump allocation operation.
 

4  _fast_incr__bkup_field
   This field displays the total number of times the SPAM page was
   updated for a fast incremental backup modification.
 

4  _threshold_update_field
   This field displays the total number of times the SPAM page was
   updated to change a data page's threshold information.
 

4  record_stored_field
   This field displays the number of records stored in the
   database.
 

4  record_marked_field
   This field displays the number of records marked. A record is
   marked when it is modified or it is erased, but not when it is
   stored.
 

4  record_erased_field
   This field displays the number of records erased from the
   database.
 

3  PIO_Statistics__Data_Writes_screen
 

4  unmark_buffer_field
   This field is incremented by one each time a modified buffer is
   written back to disk. Its value should be equal to the sum of
   the 14 following fields. These fields as well as the SPAM page
   field provide further detail about buffer unmark activity. Write
   operations of buffers that contain SPAM pages are included in the
   total although they are also counted separately by the SPAM page
   field.

   Note that unmarking one buffer may entail more than one I/O.
 

4  __transaction_field
   This field is incremented by one for each modified buffer that
   is written back to disk as a result of a COMMIT or ROLLBACK
   statement.
 

4  __pool_overflow_field
   This field is incremented by one for each modified buffer that
   is written back to disk as a result of a request to read in a new
   page from disk.
 

4  __blocking_AST_field
   This field is incremented by one for each modified buffer that
   is written back to disk in response to a blocking AST (that is, a
   page in the buffer was requested by another user).
 

4  __lock_quota_field
   This field is incremented by one for each modified buffer that is
   written back to disk due to a user reaching his lock quota.
 

4  __lock_conflict_field
   This field is incremented by one for each modified buffer that is
   written back to disk to reduce the possibility of a deadlock when
   Oracle Rdb discovers a lock conflict.
 

4  __user_unbind_field
   This field is incremented by one for each modified buffer that is
   written back to disk as a result of a user's detaching from the
   database. This includes database detaches that occur as part of
   an Oracle RMU operation.
 

4  __batch_rollback_field
   This field is incremented by one for each modified buffer that
   is written back to disk because of a failed or rolled back batch-
   update transaction.
 

4  __new_area_mode_field
   This field is incremented by one for each modified buffer that is
   written back to disk as a result of a physical area being readied
   in a new lock mode.
 

4  __larea_change_field
   This field is incremented by one for each modified buffer that
   is written back to disk as a part of creating, deleting, or
   extending a logical area.
 

4  __incr_backup_field
   This field is incremented by one for each modified buffer that
   is written back to disk to support the requirements of the
   incremental backup feature. These buffers are always SPAM page
   buffers.
 

4  __no_AIJ_access_field
   This field is incremented by one for each modified buffer that
   is written back to disk as a safety precaution after the failure
   of an I/O to the .aij file. The buffers are unmarked under such
   circumstances only when fast commit processing is enabled to
   ensure that all committed data is safely in the database.
 

4  __truncate_snaps_field
   This field is incremented by one for each modified buffer that
   is written back to disk as a part of an online snapshot file
   truncation.
 

4  __checkpoint_field
   This field is incremented by one for each modified buffer that is
   written back to disk as a result of a checkpoint.
 

4  __AIJ_backup_field
   This field is incremented by one for each modified buffer that
   is written back to disk to optimize the performance of the quiet-
   point backup of the .aij file.
 

3  PIO_Statistics__SPAM_Writes_screen
 

4  spam_page_field
   This field is incremented by one each time a modified buffer that
   contains a space management (SPAM) page is written back to disk.
   These write operations are also included in the "unmark buffer"
   field.
 

3  PIO_Statistics__File_Access_screen
 

4  area_ready_count_field
   This field displays the number of times a storage area is readied
   for read-only or read/write access. Readying a storage area may
   result in a file access (open) operation, but not always.
 

4  normal_file_open_field
   This field displays the number of times a storage area is opened
   using the normal operating system mechanism. This typically
   indicates the number of different storage areas that are
   accessed.
 

4  _normal_stall_x100_field
   This field displays the total duration of the normal file-open
   operation, in hundredths of seconds.
 

4  quick_file_open_field
   This field displays the number of times a "quick open" is used to
   open the storage area file. This typically occurs for subsequent
   opens by any user of a storage area file already opened by
   another user, even on another node of the cluster.
 

4  __quick_stall_X100_field
   This field displays the total duration of the quick file-open
   operation, in hundreths of seconds.
 

3  Asynchronous_IO_Statistics_screen
 

4  data_read_request_field
   The number of requests issued to the PIO subsystem to read data
   pages asynchronously.
 

4  data_read_IO_field
   The number of asynchronous read I/O operations done by the PIO
   subsystem to get data pages from the disk.
 

4  spam_read_request_field
   The number of requests issued to the PIO subsystem to read SPAM
   pages asynchronously.
 

4  spam_read_IO_field
   The number of asynchronous read I/O operations done by the PIO
   subsystem to get SPAM pages from the disk.
 

4  read_stall_count_field
   The total number of times the PIO subsystem had to wait for the
   completion of asynchronous read I/O operations.
 

4  read_stall_time_field
   The total time (in hundredths of a second) spent waiting for
   asynchronous read requests to complete. A high number means the
   number of buffers being prefetched is too low. You can specify
   that more buffers be prefetched by specifying a higher value with
   the RDM$BIND_APF_DEPTH logical name.
 

4  write_IO_field
   The number of asynchronous writes done by the PIO subsystem to
   write data and SPAM pages to the disk.
 

4  write_stall_count_field
   The total number of times the PIO subsystem had to wait for the
   completion of asynchronous write I/O.
 

4  write_stall_time_field
   The total time (in hundredths of a second) spent waiting for
   asynchronous write requests to complete. An excessively high
   number often indicates that the number of clean buffers being
   maintained at the end of a process's least recently used queue of
   buffers for replacement is too low. You can increase the number
   of clean buffers being maintained at the end of a process's least
   recently used queue of buffers for replacement by specifying a
   higher value with the RDM$BIND_CLEAN_BUF_CNT logical name.
 

3  IO_Stall_Time__seconds_x100__screen_
 

4  root_read_time_field
   This field gives the time (in hundredths of a second) spent
   reading the database root (.rdb) file.
 

4  root_write_time_field
   This field gives the time (in hundredths of a second) spent
   writing to the database root (.rdb) file.
 

4  data_read_time_field
   This field gives the time (in hundredths of a second) spent
   reading database pages from the .rdb, .rda, and .snp files. An
   excessively high number often indicates disk contention that
   might be alleviated by moving some files to other disks.
 

4  data_write_time_field
   This field gives the time (in hundredths of a second) spent
   writing database pages to the .rdb, .rda, and .snp files. An
   excessively high number often indicates disk contention that
   might be alleviated by moving some files to other disks.
 

4  data_extend_time_field
   This field gives the time (in hundredths of a second) spent
   extending the .rdb, .rda, and .snp files. A very high number
   often indicates a full disk or disk fragmentation.
 

4  RUJ_read_time_field
   This field gives the time (in hundredths of a second) spent
   reading records from the .ruj files during verb or transaction
   rollback. An excessively high number often indicates disk
   contention that might be alleviated by moving some files to other
   disks.
 

4  RUJ_write_time_field
   This field gives the time (in hundredths of a second) spent
   writing records to the .ruj files. An excessively high number
   often indicates disk contention that might be alleviated by
   moving some files to other disks.
 

4  RUJ_extend_time_field
   This field gives the time (in hundredths of a second) spent
   extending the .ruj files. An excessively high number often
   indicates a full disk or disk fragmentation.
 

4  AIJ_read_time_field
   This field gives the time (in hundredths of a second) spent
   reading records from the .aij file.
 

4  AIJ_write_time_field
   This field gives the time (in hundredths of a second) spent
   writing to the .aij file.
 

4  AIJ_hiber_time_field
   This field shows the stall time spent hibernating for the AIJ I/O
   to complete.
 

4  AIJ_extend_time_field
   This field gives the time (in hundredths of a second) spent
   extending the .aij file. An excessively high number often
   indicates a full disk or disk fragmentation, or may be an
   indication of the need for a larger allocation. Use the JOURNAL
   ALLOCATION IS clause of the SQL ALTER DATABASE statement to
   specify a larger allocation.
 

4  database_bind_time_field
   This field gives the length of time users are attached to the
   database.
 

3  Logical_Area_Statistics_screen
 

4  record_marked_field
   This field gives the number of records marked. A record is marked
   when it is modified or it is erased, but not when it is stored.
 

4  record_fetched_field
   This field gives the number of records, including snapshot
   records, fetched.
 

4  _fragmented_field
   This subfield indicates the number of record fragments that
   Oracle Rdb had to fetch. A record is fragmented if it is too
   large to fit on one page. A fragmented record requires more
   CPU time and more virtual memory, and often requires additional
   I/O operations because each record fragment must be fetched. If
   this value is high compared to the number of records fetched,
   Oracle Corporation recommends that you use the RMU Analyze Areas
   command to further analyze the problem to see how many records
   are actually fragmented.
 

4  ___record_stored_field
   This field gives the number of records stored in the database.
 

4  __fragmented_field
   This subfield indicates the number of rows stored as fragmented
   records in the database. This number indicates that a page
   size is smaller than a record's uncompressed size (including
   overhead). You should use the RMU Analyze Areas command to
   further analyze the problem and then increase the page size for
   the storage area that has the problem.
 

4  pages_checked_field
   This field indicates the number of pages checked in order to
   store a record. Ideally, very few candidate pages need to
   be checked when storing a record. However in certain cases,
   depending on record size, access method, locked space on a page,
   and SPAM thresholds, storing a record requires a number of page
   fetches.
 

4  _____saved_IO_field_
   This field gives the number of pages checked that did not result
   in an I/O because the page was already in the buffer. It is
   essentially a "for free" pages checked.
 

4  ____discarded_field_
   This field identifies the number of pages checked but discarded
   because the actual free space on that page did not meet the
   physical requirements needed to store a new record.
 

4  _record_erased_field
   This field gives the number of records erased from the database.
 

4  ___fragmented_field
   This subfield indicates the number of fragmented records erased
   from the database.
 

4  node_fetches_field
   This field gives the number of times Oracle Rdb fetched an
   index node during index retrievals. This number includes the
   number of leaf nodes and duplicate nodes fetched. Therefore, the
   calculation for the number of upper-level index nodes accessed
   is: this "node fetches" field minus the sum of the leaf and
   duplicate node fetches. The result can indicate the depth of
   the database indexes.
 

4  _leaf_fetches_field
   This field gives the number of times Oracle Rdb fetched bottom
   level (leaf) nodes during index retrievals. This number, along
   with the "index scans" field, can indicate the length of scans in
   terms of index nodes accessed. There is one leaf node fetch for
   each "index lookup" retrieval.
 

4  _dup__fetches_field
   This field gives the number of times Oracle Rdb fetched a
   duplicate node (as opposed to a leaf node) during index
   retrievals. This number can indicate the lengths of duplicate
   node chains in the database indexes. When a duplicate node is
   retrieved, the operation always includes one leaf fetch.
 

4  index_lookups_field
   This field gives the number of direct single-key retrievals
   performed on the database indexes. This statistic shows up only
   on unique key retrievals and not on duplicate key retrievals.
 

4  index_scans_field
   This field gives the number of scans, or range retrievals,
   performed on the database indexes. In an index scan, Oracle Rdb
   searches an index from top to bottom to find the starting point
   (low value) of the retrieval. Oracle Rdb then searches the bottom
   level nodes of the index, including duplicate nodes, until the
   scan's end condition is met.
 

4  _primary_entries_field
   This field gives the number of unique keys found during the index
   scan.
 

4  _dup__entries_field
   This field gives the number of duplicate keys found during the
   index scans. If an index has two entries with the same key value,
   the first one is a primary entry and the second is a duplicate
   entry.
 

4  node_insertions_field
   This field gives the number of index entries inserted into all
   index nodes. This number includes root, leaf, and duplicate
   entries within user- and system-defined indexes.

   This number is greater than the number of records being stored
   in the database because it usually takes one to two insertions
   into an index for each record for each index. The calculation of
   node insertions minus the sum of the root, leaf, and duplicate
   insertions yields the number of entries inserted into mid-level
   nodes. This number and the "root insertions" field indicate
   sorted balancing activity.
 

4  _root_insertions_field
   This field gives the number of entries inserted into the root
   (top-level) index nodes. The number of insertions should be small
   except for when you load the database. Also, if an index consists
   of only one node, insertions into this node are not included in
   this field, but are included in the "leaf insertions" field.
 

4  _leaf_insertions_field
   This field gives the number of unique keys inserted into the
   database's indexes. This field indicates the number of entries
   inserted into the leaf (bottom-level) index nodes.
 

4  _dup__insertions_field
   This field gives the number of duplicate index keys inserted
   into the database's indexes. There should be a one-to-one
   correspondence to the number of duplicate records being stored
   in the tables.
 

4  node_creations_field
   This field gives the total number of index nodes created during
   insertion of index entries into the index trees. This includes
   root, leaf, and duplicate nodes created within user- and system-
   defined indexes. Nodes are created three ways:

   o  When an index is first defined

   o  When a node cannot accommodate an insertion, causing it to
      overflow into a new node (node splitting)

   o  When the first duplicate for a particular key is inserted into
      an index, causing a duplicate node to be created

   The total number of nodes created and the associated fields
   should be relatively small, except for an initial load of the
   database with indexes already defined, or for creation of indexes
   on already-stored data.
 

4  _root_splits_field
   This field gives the number of times the root nodes have split
   because they overflowed after an insertion. A root node split
   causes the index to grow by one level-a parent node must be
   created to point to the two "halves" of the overflowed root node.
   Therefore, two nodes are created-the parent node and the node for
   the second half of the root node. Increasing the number of tree
   levels means Oracle Rdb must search more index nodes to access a
   data row; this can result in additional I/O operations.
 

4  _leaf_creations_field
   This field gives the number of times a leaf (bottom level) node
   was created because an existing leaf node had become full and
   needed to accommodate another unique index key entry.
 

4  _dup__creations_field
   This field gives the number of times a duplicate node was created
   to accommodate more duplicated entries within the duplicate index
   node or on the first store of a duplicate key entry.
 

4  index_creations_field
   This field gives the number of times an index was created on
   a particular table. This count is the number of CREATE INDEX
   statements. Also, if an index is partitioned over three areas,
   for example, there will be a count of three index creations.
 

4  node_removals_field
   This field gives the total number of index entries within the
   root, leaf, and duplicate nodes that have been removed. This
   removal can be triggered by erasing rows, deleting tables, or
   deleting indexes. The calculation of node removals minus the sum
   of the root, leaf, and duplicate node removals yields the number
   of entries removed from mid-level nodes. A node is not deleted
   until all its entries are removed.
 

4  _root_removals_field
   This field gives the number of index entries removed from a root
   node due to deletion of entries within lower-level nodes. If an
   index consists of only one node, removals from this node are not
   included in this field, but are included in the "leaf removals"
   field.
 

4  _leaf_removals_field
   This field gives the number of unique index keys removed from the
   leaf nodes during an SQL DELETE operation.
 

4  _dup__removals_field
   This field gives the number of duplicate index keys removed from
   duplicate nodes due to the deletion of duplicate records. This
   should be a one-to-one correspondence to the number of erased
   duplicate records within the database.
 

4  node_deletions_field
   This field gives the total number of index nodes deleted due
   to an SQL DROP INDEX statement or when the nodes become empty
   (except for the root node, which remains even when it is empty).
   When an index is deleted, this number should be equal to the
   total number of index nodes within the index. This field minus
   the sum of leaf and duplicate node deletions yields the number of
   mid-level node deletions.
 

4  _leaf_deletions_field
   This field gives the number of leaf (bottom level) nodes deleted
   from the database's indexes. A leaf node is deleted only when it
   becomes empty.
 

4  _dup__deletions_field
   This field gives the number of duplicate node deletions within
   the indexes.
 

4  index_destructions_field
   This field gives the number of indexes deleted with an SQL
   DROP INDEX statement. This count will be 1 if the index is not
   partitioned. If an index that is partitioned over three areas is
   deleted, for example, then the count will be 3. This count also
   gives the number of root node deletions.
 

4  __pages_checked_field
   This field indicates the number of pages checked in order to
   store a B-tree index node. Ideally, very few candidate pages
   need to be checked when storing a B-tree index node. However,
   in certain cases, depending on the size of the segment, locked
   space on a page, and SPAM thresholds, storing a B-tree index node
   requires a number of page fetches.
 

4  _______saved_IO_field_
   This field gives the number of pages checked that did not result
   in an I/O because the page was already in the buffer. It is
   essentially a "for free" pages checked.
 

4  ______discarded_field_
   This field identifies the number of pages checked but discarded
   because the actual free space on that page did not meet the
   physical requirements needed to store a new B-tree index node.
 

4  bucket_marked_field
   This field gives the number of buckets marked. A bucket is marked
   when it is modified or it is erased, but not when it is stored.
 

4  bucket_fetched_field
   This field gives the number of buckets fetched.
 

4  ____fragmented_field_
   This subfield indicates the number of bucket fragments that
   Oracle Rdb had to fetch. A bucket is fragmented if it is too
   large to fit on one page. A fragmented bucket requires more
   CPU time and more virtual memory, and often requires additional
   I/O operations because each bucket fragment must be fetched. If
   this value is high compared to the number of buckets fetched,
   Oracle Corporation recommends that you use the RMU Analyze Areas
   command to further analyze the problem to see how many buckets
   are actually fragmented.
 

4  _bucket_stored_field
   This field gives the number of buckets stored in the database.
 

4  _____fragmented_field_
   This subfield indicates the number of buckets stored as
   fragmented buckets in the database. This number indicates that a
   page size is smaller than a bucket's uncompressed size (including
   overhead). You should use the RMU Analyze Areas command to
   further analyze the problem and then increase the page size for
   the storage area that has the problem.
 

4  ___pages_checked_field
   This field indicates the number of pages checked in order to
   store a hashed index. Ideally, very few candidate pages need
   to be checked when storing a hashed index. However, in certain
   cases, depending on the size of the segment, locked space on a
   page, and SPAM thresholds, storing a hashed index requires a
   number of page fetches.
 

4  ________saved_IO_field_
   This field gives the number of pages checked that did not result
   in an I/O because the page was already in the buffer. It is
   essentially a "for free" pages checked.
 

4  _______discarded_field_
   This field identifies the number of pages checked but discarded
   because the actual free space on that page did not meet the
   physical requirements needed to store a new hashed index.
 

4  hash_insertions_field
   This field gives the number of hash key insertions in the
   database's hashed indexes. It includes unique key insertions
   as well as duplicate key insertions.
 

4  _____duplicates_field_
   This field gives the number of duplicate key updates in the
   database's hashed indexes.
 

4  hash_deletions_field
   This field gives the number of hash key deletions from the
   database's hashed indexes. It includes unique key deletions as
   well as duplicate key deletions.
 

4  ____duplicates_field_
   This field gives the number of duplicate key deletions in the
   database's hashed indexes.
 

4  hash_scans_field
   This field gives the number of hashed index scans, including both
   retrieval and update scans, that were opened on the database's
   hashed indexes. A scan is defined as the sequential processing
   of the records that meet the search criteria of a query. Hashed
   scans then refer to the case where duplicate records are returned
   that meet the search criteria of a query from a scan of the
   hashed index.
 

4  hash_index_fetches_field
   This field gives the number of hashed index nodes that were
   fetched on a successful search of the database's hashed indexes.
   This includes fetches of duplicate nodes as well as bucket
   fragment nodes.
 

4  __bucket_fragments_field
   This field gives the number of bucket fragments that were fetched
   on a successful search of the database's hashed indexes.
 

4  ___duplicate_nodes_field
   This field gives the number of duplicate nodes that were fetched
   on a successful search of the database's hashed indexes.
 

4  blob_marked_field
   This field gives the number of blob segments marked. A blob
   segment is marked when it is erased or reused, but not when it
   is stored.
 

4  _blob_fetched_field
   This field gives the number of blob segments fetched. This number
   includes pointer segments in addition to actual user data.
 

4  ______fragmented_field_
   This subfield indicates the number of blob segment fragments that
   Oracle Rdb had to fetch. A blob segment is fragmented if it is
   too large to fit on one page. A fragmented blob segment requires
   more CPU time and more virtual memory, and often requires
   additional I/O operations because each blob segment fragment
   must be fetched.

   This number refers only to actual user data as pointer segments
   are unlikely to fragment.
 

4  _blob_stored_field
   This field gives the number of blob segments stored in the
   database. This number includes pointer segments in addition to
   actual user data.
 

4  _______fragmented_field_
   This subfield indicates the number of rows stored as fragmented
   blob segments in the database. This number indicates that a page
   size is smaller than a blob segment.

   This number refers only to actual user data as pointer segments
   are unlikely to fragment.
 

4  _pages_checked_field
   This field indicates the number of pages checked in order to
   store a blob segment. Ideally, very few candidate pages need to
   be checked when storing a blob segment. However in certain cases,
   depending on the size of the segment, locked space on a page, and
   SPAM thresholds, storing a blob segment requires a number of page
   fetches.
 

4  ______saved_IO_field_
   This field gives the number of pages checked that did not result
   in an I/O because the page was already in the buffer. It is
   essentially a "for free" pages checked.
 

4  _____discarded_field_
   This field identifies the number of pages checked but discarded
   because the actual free space on that page did not meet the
   physical requirements needed to store a new blob segment.
 

4  blob_erased_field
   This field gives the number of blob segments erased from the
   database. Note that the erase of blob segments is deferred until
   COMMIT time.
 

4  ________fragmented_field_
   This subfield indicates the number of fragmented blob segments
   erased from the database.

   This number refers only to actual user data as pointer segments
   are unlikely to fragment.
 

3  Locking__total_locks__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__area_locks__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__buffer_page_locks__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__record_locks__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__SEQBLK_lock__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__FILID_locks__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__TSNBLK_locks__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__RTUPB_lock__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__ACTIVE_lock__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__MEMBIT_lock__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__AIJ_locks__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__snapshot_locks__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__freeze_lock__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__quiet_point_lock__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__logical_area_locks__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__nowait_transaction__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__CLIENT_locks__screen_
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Locking__locks_requested__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the VMScluster nodes on which the database is currently
   accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking___rqsts_not_queued__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the VMScluster nodes on which the database is currently
   accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking___rqsts_stalled__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking___rqst_timeouts__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking___rqst_deadlocks__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet point-lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking__locks_promoted__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking___proms_not_queued__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking___proms_stalled__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking___prom_timeouts__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking___prom_deadlocks__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking__locks_demoted__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking__locks_released__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking__blocking_ASTs__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  Locking__stall_time_x100__screen_
 

4  total_locks_field
   This field gives statistics for all types of database locks.
 

4  area_locks_field
   This field gives statistics for database physical area locks.
 

4  buffer_page_locks_field
   This field gives statistics for database page locks. Page locks
   manage the database page buffer pool.
 

4  record_locks_field
   This field gives statistics for database record locks. Record
   locks maintain the logical consistency of the database. This set
   of statistics includes all record locks in the adjustable lock
   granularity tree.
 

4  SEQBLK_lock_field
   This field gives statistics for the database sequence block
   (SEQBLK) locks. The SEQBLK locks maintain global sequence numbers
   or transaction and commit sequence numbers and control COMMIT and
   ROLLBACK operations.
 

4  FILID_locks_field
   This field gives statistics for the database file identification
   (FILID) locks. The FILID locks maintain consistent end-of-file
   information for the .rdb, .rda, and .snp database files.
 

4  TSNBLK_locks_field
   This field gives statistics for the database transaction block
   (TSNBLK) locks. The TSNBLK locks control the COMMIT and ROLLBACK
   operations on each VMScluster node. TSNBLK locks are also
   used to control SQL SET TRANSACTION statements for read-only
   transactions.
 

4  RTUPB_lock_field
   This field gives statistics for the database run-time user
   process block (RTUPB) lock. The RTUPB locks maintain a consistent
   list of the users who are attached to the database.
 

4  ACTIVE_lock_field
   This field gives statistics for the database ACTIVE user bit map
   lock. The ACTIVE lock maintains a consistent list (in bit map
   form) of the users who are attached to the database.
 

4  MEMBIT_lock_field
   This field gives statistics for the database MEMBIT node bit map
   lock. The MEMBIT locks maintain a consistent list (in bit map
   form) of the nodes on which the database is currently accessed.
 

4  AIJ_locks_field
   This field gives statistics for the after-image journal (AIJ)
   locks. AIJ locks control reading from and writing to the
   .aij file. One global AIJ lock maintains current end-of-file
   information. In addition, there is one local AIJ lock on each
   VMScluster node that manages the global AIJ buffer on that node.
 

4  snapshot_locks_field
   This field gives statistics for the database snapshot locks.
   Snapshot locks manage the allocation of snapshot pages to users
   who are updating the database. Snapshot locks are only used if
   snapshots are enabled for a storage area.
 

4  freeze_lock_field
   This field gives statistics for the database freeze lock. The
   freeze lock suspends database activity while a database recovery
   process is running.
 

4  quiet_point_lock_field
   This field gives statistics for the database quiet-point lock.
   The quiet-point lock suspends starting new transactions while
   the AIJ despooler is trying to finish despooling the contents
   of the primary .aij file when you use the RMU Backup After_
   Journal command. The quiet-point lock also suspends starting new
   transactions during the startup of an online RMU Backup command.
 

4  logical_area_locks_field
   Logical area locks are obtained when Oracle Rdb readies tables.
   Lock carryover can help reduce the number of logical area locks.
 

4  nowait_transaction_field
This field gives statistics for the database nowait transaction
lock.
 

4  CLIENT_locks_field
   This field monitors the database client information (CLIENT)
   lock. The CLIENT locks are used to provide serialized access to
   the database metadata stored in the system tables. The CLIENT
   locks are also used to serialize operations such as creating
   tables and indices.

   Note: This field is only displayed on terminal displays
   containing more than 24 lines.
 

3  File_Locking_Statistics_screen
 

4  locks_requested_field
   This field gives the number of lock requests (also referred to
   as enqueue lock requests) for new locks. Whether the lock request
   succeeds or fails, it is included in this count. The "rqsts not
   queued", "rqsts stalled", and "rqst deadlocks" counts provide
   further detail for enqueue lock requests statistics.
 

4  _rqsts_not_queued_field
   This field gives the number of enqueue lock requests for new
   locks that were rejected immediately because of a lock conflict.
   Oracle Rdb often requests a lock without waiting and, when a
   conflict is detected, resorts to a secondary locking protocol to
   avoid unnecessary deadlocks. This number is one measure of lock
   contention.
 

4  _rqsts_stalled_field
   This field gives the number of enqueue lock requests for new
   locks that were stalled because of a lock conflict. Whether or
   not the lock request ultimately succeeds, it is included in this
   count. This number is one measure of lock contention.
 

4  _rqst_timeouts_field
   This field shows the total number of lock requests that could not
   be granted because they timed out. These are typically logical
   areas.
 

4  _rqst_deadlocks_field
   This field gives the number of stalled enqueue lock requests
   for new locks that ultimately resulted in a deadlock. Most
   deadlocks are tried again and resolved by Oracle Rdb without the
   application program ever knowing there was a deadlock. Therefore,
   the number shown in this field does not necessarily reflect the
   number of deadlocks reported to the application program.

   The number reported in the "rqsts stalled" field is also included
   in this number.
 

4  locks_promoted_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode. Whether or not the lock
   request succeeds, it is included in this count. The "proms not
   queued," "proms stalled," and "prom deadlocks" counts provide
   further detail for the locks promotion statistics.
 

4  _proms_not_queued_field
   This field gives the number of enqueue lock requests to promote
   an existing lock that were rejected immediately because of a
   lock conflict. Oracle Rdb often requests a lock without waiting.
   When a conflict is detected, Oracle Rdb resorts to a secondary
   locking protocol to avoid unnecessary deadlocks. This number is
   one measure of lock contention.
 

4  _proms_stalled_field
   This field gives the number of enqueue lock requests to promote
   an existing lock to a higher lock mode that were stalled because
   of a lock conflict. Whether or not the lock request ultimately
   succeeds, it is included in this count. This number is one
   measure of lock contention.
 

4  _prom_timeouts_field
   This field shows the total number of lock promotions that could
   not be granted because they timed out. These are typically
   logical areas.
 

4  _prom_deadlocks_field
   This field gives the number of stalled enqueue lock requests to
   promote an existing lock that ultimately resulted in a deadlock.
   Most deadlocks are tried again and resolved by Oracle Rdb without
   the application program ever knowing there was a deadlock.
   Therefore, this number does not necessarily reflect the number
   of deadlocks reported to the application program.
 

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

4  locks_released_field
   This field gives the number of deallocating lock requests to
   release an existing lock. These requests always succeed. The
   number of outstanding locks can be determined by the formula:
   (locks requested) - (rqsts not queued) - (rqst deadlocks) -
   (locks released).
 

4  blocking_ASTs_field
   This field gives the number of blocking ASTs, sometimes referred
   to as blasts, delivered to Oracle Rdb by the lock manager. A
   blocking AST is delivered to the holder of a lock when a lock
   conflict is detected, which is a good indication of contention
   problems. When Oracle Rdb receives a blocking AST, it often
   demotes or releases a lock in an attempt to avoid unnecessary
   deadlocks.

   The number of blocking ASTs reported is actually comprised of two
   different types of blocking ASTs, those blocking ASTs externally
   generated and those blocking ASTs internally generated.

   An externally generated blocking AST occurs when a blocking AST
   is actually received by the process from the operating system in
   response to some lock conflict with another process. A blocking
   AST routine is executed and the Performance Monitor records the
   blocking AST activity.

   An internally generated blocking AST occurs when a lock-blocking
   AST routine is executed by the process in anticipation that
   the same work would have to be performed anyway if a blocking
   AST were to be received from the operating system, even when
   no blocking AST from the operating system actually occurred.
   This algorithm serves as an optimistic code optimization; it is
   assumed that the process would eventually receive a blocking
   AST for the particular lock, so it optimistically executes
   the blocking AST routine. The Performance Monitor does not
   differentiate between these two types of blocking ASTs.
 

4  stall_time_x100_field
   This field gives the total time (in hundredths of a second)
   spent by all users waiting for a lock. Since more than one user
   can be waiting for a lock at the same time, this total can be
   greater than the actual elapsed clock time. This statistic gives
   a relative measure of work lost due to lock conflicts.
 

3  Row_Cache__by_cache__screen_
 

4  latch_requests_field
   This field displays the total number of latch requests that
   have occurred. A latch is requested whenever an internal data
   structure needs to be atomically modified, and indicates a
   potential stall point. The duration of the latch is essentially
   non-measureable.
 

4  __retried_field
   This field indicates the latch could not be immediately acquired
   and the latch had to be requested again. This field provides
   an indication of the contention on the row cache. Ideally, this
   field should be as close to zero as possible.
 

4  cache_searches_field
   This field displays the total number of times the row cache was
   searched for a particular row (DBKEY). Values within this field
   are subdivided into the following fields:

      found in workset
      found in cache
      found too big
 

4  __found_in_workset_field
   This field indicates the particular row was found in the process'
   working set and no additional work was required to fetch the row.
   This is the ideal situation.
 

4  __found_in_cache_field
   This field indicates the particular row was not found in the
   process' working set, but was found in the global row cache. When
   this occurs, it is possible that the process will have to make
   room in the working set by removing an existing row to the global
   cache.
 

4  __found_too_big_field
   This field indicates the particular row was found in the global
   cache, but the row is now too large to fit into the specified
   cache buffer. At one time, the row fit into the cache, but it
   no longer does. Therefore, the cache effectiveness is reduced
   because a cache entry is reserved for the row but no row caching
   is possible.
 

4  insert_cache_field
   This field indicates the total number of times new rows have
   been inserted into the row cache. Values within this field are
   subdivided into the following fields:

      row too big
      cache full
      collision
 

4  __row_too_big_field
   This field indicates the row was initially too large to fit into
   the specified row cache buffer.
 

4  __cache_full_field
   This field indicates that all row cache entries were modified
   and could not be flushed to disk in order to make space for the
   new row. This is an indication that the row cache checkpointing
   intervals specified for the database may be too large.
 

4  __collision_field
   This field displays the total number of row cache hash table
   collisions that occurred when inserting new rows. This field
   provides an indication of the effectiveness of the cache size.
 

4  VLM_requests_field
   This field displays the number of VLM requests made.
 

4  __window_turns_field
   This field displays the number of VLM requests made for which the
   VLM address range was not immediately available.
 

4  skipped_dirty_slot_field
   This field displays the total number of cache entries that could
   not be replaced because the slot contained modified data rows.
   This field provides an indication of the relative amount of work
   required to find space in order to insert a new row into the
   cache.
 

4  skipped_inuse_slot_field
   This field displays the total number of cache entries that
   could not be replaced because the slot was referenced by other
   processes. This field provides an indication of the relative
   amount of work required to find space in order to insert a new
   row into the cache.
 

4  hash_misses_field
   This field displays the total number of times the row cache hash
   table overflowed.
 

4  cache_unmark_field
   This field displays the total number of times a row in the cache
   was flushed to disk, thus making it eligible to be replaced.
   However, this field does not indicate whether or not the row was
   emptied from the cache.
 

3  RCS_Statistics_screen
 

4  find_buffer_stall_field
   This field gives the length of time (in hundredths of a second)
   required to allocate a checkpoint buffer. Typically, this value
   should be extremely small.
 

3  Index_Statistics__Retrieval__screen_
 

4  transactions_field
   This field gives the number of completed database transactions.
   This is the count of the COMMIT and ROLLBACK statements that have
   executed.
 

4  verb_successes_field
   This field gives the number of intermediate recoverable
   operations that returned a successful status code.
 

4  verb_failures_field
   This field gives the number of intermediate recoverable
   operations that returned an error status code, including
   deadlocks and other exception conditions.
 

4  node_fetches_field
   This field gives the number of times Oracle Rdb fetched an
   index node during index retrievals. This number includes the
   number of leaf nodes and duplicate nodes fetched. Therefore, the
   calculation for the number of upper-level index nodes accessed
   is: this "node fetches" field minus the sum of the leaf and
   duplicate node fetches. The result can indicate the depth of
   the database indexes.
 

4  _leaf_fetches_field
   This field gives the number of times Oracle Rdb fetched bottom
   level (leaf) nodes during index retrievals. This number, along
   with the "index scans" field, can indicate the length of scans in
   terms of index nodes accessed. There is one leaf node fetch for
   each "index lookup" retrieval.
 

4  _dup__fetches_field
   This field gives the number of times Oracle Rdb fetched a
   duplicate node (as opposed to a leaf node) during index
   retrievals. This number can indicate the lengths of duplicate
   node chains in the database indexes. When a duplicate node is
   retrieved, the operation always includes one leaf fetch.
 

4  index_lookups_field
   This field gives the number of direct single-key retrievals
   performed on the database indexes. This statistic shows up only
   on unique key retrievals and not on duplicate key retrievals.
 

4  index_scans_field
   This field gives the number of scans, or range retrievals,
   performed on the database indexes. In an index scan, Oracle Rdb
   searches an index from top to bottom to find the starting point
   (low value) of the retrieval. Oracle Rdb then searches the bottom
   level nodes of the index, including duplicate nodes, until the
   scan's end condition is met.
 

4  _primary_entries_field
   This field gives the number of unique keys found during the index
   scan.
 

4  _dup__entries_field
   This field gives the number of duplicate keys found during the
   index scans. If an index has two entries with the same key value,
   the first one is a primary entry and the second is a duplicate
   entry.
 

3  Index_Statistics__Insertion__screen_
 

4  node_insertions_field
   This field gives the number of index entries inserted into all
   index nodes. This number includes root, leaf, and duplicate
   entries within user- and system-defined indexes.

   This number is greater than the number of records being stored
   in the database because it usually takes one to two insertions
   into an index for each record for each index. The calculation of
   node insertions minus the sum of the root, leaf, and duplicate
   insertions yields the number of entries inserted into mid-level
   nodes. This number and the "root insertions" field indicate
   sorted balancing activity.
 

4  _root_insertions_field
   This field gives the number of entries inserted into the root
   (top-level) index nodes. The number of insertions should be small
   except for when you load the database. Also, if an index consists
   of only one node, insertions into this node are not included in
   this field, but are included in the "leaf insertions" field.
 

4  _leaf_insertions_field
   This field gives the number of unique keys inserted into the
   database's indexes. This field indicates the number of entries
   inserted into the leaf (bottom-level) index nodes.
 

4  _dup__insertions_field
   This field gives the number of duplicate index keys inserted
   into the database's indexes. There should be a one-to-one
   correspondence to the number of duplicate records being stored
   in the tables.
 

4  node_creations_field
   This field gives the total number of index nodes created during
   insertion of index entries into the index trees. This includes
   root, leaf, and duplicate nodes created within user- and system-
   defined indexes. Nodes are created three ways:

   o  When an index is first defined

   o  When a node cannot accommodate an insertion, causing it to
      overflow into a new node (node splitting)

   o  When the first duplicate for a particular key is inserted into
      an index, causing a duplicate node to be created

   The total number of nodes created and the associated fields
   should be relatively small, except for an initial load of the
   database with indexes already defined, or for creation of indexes
   on already-stored data.
 

4  _root_splits_field
   This field gives the number of times the root nodes have split
   because they overflowed after an insertion. A root node split
   causes the index to grow by one level-a parent node must be
   created to point to the two "halves" of the overflowed root node.
   Therefore, two nodes are created-the parent node and the node for
   the second half of the root node. Increasing the number of tree
   levels means Oracle Rdb must search more index nodes to access a
   data row; this can result in additional I/O operations.
 

4  _leaf_creations_field
   This field gives the number of times a leaf (bottom level) node
   was created because an existing leaf node had become full and
   needed to accommodate another unique index key entry.
 

4  _dup__creations_field
   This field gives the number of times a duplicate node was created
   to accommodate more duplicated entries within the duplicate index
   node or on the first store of a duplicate key entry.
 

4  index_creations_field
   This field gives the number of times an index was created on
   a particular table. This count is the number of CREATE INDEX
   statements. Also, if an index is partitioned over three areas,
   for example, there will be a count of three index creations.
 

3  Index_Statistics__Removal__screen_
 

4  node_removals_field
   This field gives the total number of index entries within the
   root, leaf, and duplicate nodes that have been removed. This
   removal can be triggered by erasing rows, deleting tables, or
   deleting indexes. The calculation of node removals minus the sum
   of the root, leaf, and duplicate node removals yields the number
   of entries removed from mid-level nodes. A node is not deleted
   until all its entries are removed.
 

4  _root_removals_field
   This field gives the number of index entries removed from a root
   node due to deletion of entries within lower-level nodes. If an
   index consists of only one node, removals from this node are not
   included in this field, but are included in the "leaf removals"
   field.
 

4  _leaf_removals_field
   This field gives the number of unique index keys removed from the
   leaf nodes during an SQL DELETE operation.
 

4  _dup__removals_field
   This field gives the number of duplicate index keys removed from
   duplicate nodes due to the deletion of duplicate records. This
   should be a one-to-one correspondence to the number of erased
   duplicate records within the database.
 

4  node_deletions_field
   This field gives the total number of index nodes deleted due
   to an SQL DROP INDEX statement or when the nodes become empty
   (except for the root node, which remains even when it is empty).
   When an index is deleted, this number should be equal to the
   total number of index nodes within the index. This field minus
   the sum of leaf and duplicate node deletions yields the number of
   mid-level node deletions.
 

4  _leaf_deletions_field
   This field gives the number of leaf (bottom level) nodes deleted
   from the database's indexes. A leaf node is deleted only when it
   becomes empty.
 

4  _dup__deletions_field
   This field gives the number of duplicate node deletions within
   the indexes.
 

4  index_destructions_field
   This field gives the number of indexes deleted with an SQL
   DROP INDEX statement. This count will be 1 if the index is not
   partitioned. If an index that is partitioned over three areas is
   deleted, for example, then the count will be 3. This count also
   gives the number of root node deletions.
 

3  Hash_Index_Statistics_Screen
 

4  hash_insertions_field
   This field gives the number of hash key insertions in the
   database's hashed indexes. It includes unique key insertions
   as well as duplicate key insertions.
 

4  _____duplicates_field_
   This field gives the number of duplicate key updates in the
   database's hashed indexes.
 

4  hash_deletions_field
   This field gives the number of hash key deletions from the
   database's hashed indexes. It includes unique key deletions as
   well as duplicate key deletions.
 

4  ____duplicates_field_
   This field gives the number of duplicate key deletions in the
   database's hashed indexes.
 

4  hash_scans_field
   This field gives the number of hashed index scans, including both
   retrieval and update scans, that were opened on the database's
   hashed indexes. A scan is defined as the sequential processing
   of the records that meet the search criteria of a query. Hashed
   scans then refer to the case where duplicate records are returned
   that meet the search criteria of a query from a scan of the
   hashed index.
 

4  hash_index_fetches_field
   This field gives the number of hashed index nodes that were
   fetched on a successful search of the database's hashed indexes.
   This includes fetches of duplicate nodes as well as bucket
   fragment nodes.
 

4  __bucket_fragments_field
   This field gives the number of bucket fragments that were fetched
   on a successful search of the database's hashed indexes.
 

4  ___duplicate_nodes_field
   This field gives the number of duplicate nodes that were fetched
   on a successful search of the database's hashed indexes.
 

4  hash_bucket_stores_field
   This field gives teh number of hash index buckets stored in the
   index. A hash index bucket contains one or more hash keys.
 

3  Name_Translation_screen
 

4  dashboard_updated__field
   This field displays the number of times a user has received
   notification that the database dashboard has been updated.
 

4  name_translated_field
   This field displays the number of times a logical name has been
   translated.
 

4  _____defaulted_field_
   This field displays the number of times the default value was
   used for a logical name.
 

3  Object__KROOT_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__FILID_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__SEQBLK_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__TSNBLK_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__AIJDB_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__AIJFB_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__RTUPB_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__ACTIVE_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__CPT_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  object__RCACHE_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__CLIENT_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__CLTSEQ_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__UTILITY_object__screen_
 

4  objects_fetch_shrd_field
   This field displays the number of objects that are fetched for
   the shared retrieval process.
 

4  objects_fetch_excl_field
   This field displays the number of objects that are fetched
   for exclusive access with the intention of subsequently being
   updated. This statistic does not indicate that the object
   actually was updated.
 

4  objects_refreshed_field
   This field displays the number of objects whose information
   in the global section was detected as being stale, so the
   information was read again from the database root file.
 

4  objects_modified_field
   This field displays the number of objects whose information
   was modified. Only objects fetched for exclusive access can be
   modified.
 

4  objects_written_field
   This field displays the number of objects whose information was
   written back to the database root file.
 

4  objects_released_field
   This field displays the number of objects whose shared or
   exclusive access was released to other processes.
 

3  Object__objects_fetch_shrd__screen_
 

4  KROOT_object_field
   This field displays the database control information that
   describes all of the other database objects.
 

4  FILID_object_field
   This field displays the storage area information.
 

4  SEQBLK_object_field
   This field displays the information on the allocation of sequence
   numbers such as transaction sequence numbers (TSNs) and commit
   sequence numbers (CSNs).
 

4  TSNBLK_object_field
   This field displays the information on the last committed
   transaction.
 

4  AIJDB_object_field
   This field displays the AIJ control information.
 

4  AIJFB_object_field
   This field displays the AIJ journal information.
 

4  RTUPB_object_field
   This field displays information on active users.
 

4  ACTIVE_object_field
   This field displays information on active transactions.
 

4  CPT_object_field
   This field displays information on the corrupt page table.
 

4  RCACHE_object_field
   This field displays information on row caches.
 

4  CLIENT_object_field
   This field displays client-specific information.
 

4  CLTSEQ_object_field
   This field displays client sequence information.
 

4  UTILITY_object_field
   This field displays RMU utility information.
 

3  Object__objects_fetch_excl__screen_
 

4  KROOT_object_field
   This field displays the database control information that
   describes all of the other database objects.
 

4  FILID_object_field
   This field displays the storage area information.
 

4  SEQBLK_object_field
   This field displays the information on the allocation of sequence
   numbers such as transaction sequence numbers (TSNs) and commit
   sequence numbers (CSNs).
 

4  TSNBLK_object_field
   This field displays the information on the last committed
   transaction.
 

4  AIJDB_object_field
   This field displays the AIJ control information.
 

4  AIJFB_object_field
   This field displays the AIJ journal information.
 

4  RTUPB_object_field
   This field displays information on active users.
 

4  ACTIVE_object_field
   This field displays information on active transactions.
 

4  CPT_object_field
   This field displays information on the corrupt page table.
 

4  RCACHE_object_field
   This field displays information on row caches.
 

4  CLIENT_object_field
   This field displays client-specific information.
 

4  CLTSEQ_object_field
   This field displays client sequence information.
 

4  UTILITY_object_field
   This field displays RMU utility information.
 

3  Object__objects_refreshed__screen_
 

4  KROOT_object_field
   This field displays the database control information that
   describes all of the other database objects.
 

4  FILID_object_field
   This field displays the storage area information.
 

4  SEQBLK_object_field
   This field displays the information on the allocation of sequence
   numbers such as transaction sequence numbers (TSNs) and commit
   sequence numbers (CSNs).
 

4  TSNBLK_object_field
   This field displays the information on the last committed
   transaction.
 

4  AIJDB_object_field
   This field displays the AIJ control information.
 

4  AIJFB_object_field
   This field displays the AIJ journal information.
 

4  RTUPB_object_field
   This field displays information on active users.
 

4  ACTIVE_object_field
   This field displays information on active transactions.
 

4  CPT_object_field
   This field displays information on the corrupt page table.
 

4  RCACHE_object_field
   This field displays information on row caches.
 

4  CLIENT_object_field
   This field displays client-specific information.
 

4  CLTSEQ_object_field
   This field displays client sequence information.
 

4  UTILITY_object_field
   This field displays RMU utility information.
 

3  Object__objects_modified__screen_
 

4  KROOT_object_field
   This field displays the database control information that
   describes all of the other database objects.
 

4  FILID_object_field
   This field displays the storage area information.
 

4  SEQBLK_object_field
   This field displays the information on the allocation of sequence
   numbers such as transaction sequence numbers (TSNs) and commit
   sequence numbers (CSNs).
 

4  TSNBLK_object_field
   This field displays the information on the last committed
   transaction.
 

4  AIJDB_object_field
   This field displays the AIJ control information.
 

4  AIJFB_object_field
   This field displays the AIJ journal information.
 

4  RTUPB_object_field
   This field displays information on active users.
 

4  ACTIVE_object_field
   This field displays information on active transactions.
 

4  CPT_object_field
   This field displays information on the corrupt page table.
 

4  RCACHE_object_field
   This field displays information on row caches.
 

4  CLIENT_object_field
   This field displays client-specific information.
 

4  CLTSEQ_object_field
   This field displays client sequence information.
 

4  UTILITY_object_field
   This field displays RMU utility information.
 

3  Object__objects_written__screen_
 

4  KROOT_object_field
   This field displays the database control information that
   describes all of the other database objects.
 

4  FILID_object_field
   This field displays the storage area information.
 

4  SEQBLK_object_field
   This field displays the information on the allocation of sequence
   numbers such as transaction sequence numbers (TSNs) and commit
   sequence numbers (CSNs).
 

4  TSNBLK_object_field
   This field displays the information on the last committed
   transaction.
 

4  AIJDB_object_field
   This field displays the AIJ control information.
 

4  AIJFB_object_field
   This field displays the AIJ journal information.
 

4  RTUPB_object_field
   This field displays information on active users.
 

4  ACTIVE_object_field
   This field displays information on active transactions.
 

4  CPT_object_field
   This field displays information on the corrupt page table.
 

4  RCACHE_object_field
   This field displays information on row caches.
 

4  CLIENT_object_field
   This field displays client-specific information.
 

4  CLTSEQ_object_field
   This field displays client sequence information.
 

4  UTILITY_object_field
   This field displays RMU utility information.
 

3  Object__objects_released__screen_
 

4  KROOT_object_field
   This field displays the database control information that
   describes all of the other database objects.
 

4  FILID_object_field
   This field displays the storage area information.
 

4  SEQBLK_object_field
   This field displays the information on the allocation of sequence
   numbers such as transaction sequence numbers (TSNs) and commit
   sequence numbers (CSNs).
 

4  TSNBLK_object_field
   This field displays the information on the last committed
   transaction.
 

4  AIJDB_object_field
   This field displays the AIJ control information.
 

4  AIJFB_object_field
   This field displays the AIJ journal information.
 

4  RTUPB_object_field
   This field displays information on active users.
 

4  ACTIVE_object_field
   This field displays information on active transactions.
 

4  CPT_object_field
   This field displays information on the corrupt page table.
 

4  RCACHE_object_field
   This field displays information on row caches.
 

4  CLIENT_object_field
   This field displays client-specific information.
 

4  CLTSEQ_object_field
   This field displays client sequence information.
 

4  UTILITY_object_field
   This field displays RMU utility information.
 

3  IO_DASHBOARD_SCREEN
 

4  Buffer_Count_field
   This field displays the default buffer count used by database
   processes.
 

4  APF_Enabled_field
   This field indicates whether asynchronous prefetch operations are
   enabled. The default value 1 indicates that asynchronous prefetch
   operations are enabled and the value 0 indicates that they are
   disabled. You can override the default value with the RDM$BIND_
   APF_ENABLED logical name.
 

4  APF_Depth_field
   This field displays the asynchronous pre-fetch depth setting. You
   can override the default value of 5 buffers with the RDM$BIND_
   APF_DEPTH logical name.
 

4  DAPF_Enabled_field
   This field indicates whether detected asynchronous prefetch
   operations are enabled. The default value 1 indicates that
   detected asynchronous prefetch operations are enabled and the
   value 0 indicates that they are disabled. You can override the
   default value with the RDM$BIND_DAPF_ENABLED logical name.
 

4  DAPF_Depth_Count_field
   This field displays the detected asynchronous pre-fetch depth
   count setting.
 

4  DAPF_Start_Count_field
   This field displays the detected asynchronous pre-fetch start
   count.
 

4  ABW_Enabled_field
   This field indicates whether asynchronous batch write operations
   are enabled. The default value 1 indicates that asynchronous
   batch write operations are enabled and the value 0 indicates that
   they are disabled. You can override the default value with the
   RDM$BIND_ABW_ENABLED logical name.
 

4  ABW_Clean_BufCount_field
   This field displays the asynchronous batch write clean buffer
   count setting. You can override the default value of 5 buffers
   with the RDM$BIND_CLEAN_BUF_CNT logical name.
 

4  ABW_Batch_Max_field
   This field displays the asynchronous batch write maximum batch
   size setting.
 

3  locking_DASHBOARD_screen
 

4  Lock_Timeout_Intvl_field
   This field displays the number of seconds for a process to wait
   during a lock conflict before timing out. The default value is
   2147483647 seconds. You can override the default value with the
   RDM$BIND_LOCK_TIMEOUT_INTERVAL logical name.
 

4  Ready_AreaSerially_field
   This field indicates whether Oracle Rdb grants lock requests for
   logical and physical areas in the order that the lock requests
   were made. The default value 0 indicates that lock requests are
   not granted serially. You can override the default value with the
   RDM$BIND_READY_AREA_SERIALLY logical name.
 

4  Snap_Quiet_Point_field
   This field indicates whether the snapshot locks acquire a quiet-
   point lock. The default value 1 indicates that a quiet-point
   lock is acquired and the value 0 indicates that a quiet-point
   lock is not required. You can override the default value with the
   RDM$BIND_SNAP_QUIET_POINT logical name.
 

4  Hold_Retrvl_Locks_field
   This field indicates whether hold retrieval locks are enabled.
   The default value 0 indicates that hold retrieval locks are
   disabled and the value 1 indicates that they are enabled. You can
   override the default value with the RDM$BIND_HRL_ENABLED logical
   name.
 

4  Coarse_Buf_Lockng_field
   This field indicates whether coarse buffer locking is enabled.
   The default value 0 indicates that coarse buffer locking is
   disabled and the value 1 indicates that it is enabled. You can
   override the default value with the RDM$BIND_CBL_ENABLED logical
   name.
 

3  AIJ_DASHBOARD_screen
 

4  Min_IO_Blocks_field
   This field displays the minimum AIJ group commit I/O buffer size,
   in blocks. The default value is 8 blocks. You can override the
   default value with the RDM$BIND_AIJ_IO_MIN logical name.
 

4  Max_IO_Blocks_field
   This field displays the maximum AIJ group commit I/O buffer size,
   in blocks. The default value is 127 blocks. You can override the
   default value with the RDM$BIND_AIJ_IO_MAX logical name.
 

4  AIJ_Stall_Interval_field
   This field displays the AIJ group commit stall time, in
   milliseconds. The stall time permits a larger number of
   transactions in the group commit operation. You can override
   the default value with the RDM$BIND_AIJ_STALL logical name.
 

4  Root_Stall_Intervl_field
   This field displays the TSNBLK group commit stall time, in
   milliseconds. You can override the default value with the
   RDM$BIND_COMMIT_STALL logical name.
 

4  Switch_Global_Ckpt_field
   This field indicates whether to perform a global checkpoint after
   an AIJ switch-over has occurred. The default value 1 indicates
   that a global checkpoint will be performed and the value 0
   indicates that a global checkpoint will not be performed. You can
   override the default value with the RDM$BIND_AIJ_SWITCH_GLOBAL_
   CKPT logical name.
 

4  Check_Control_Recs_field
   This field indicates whether to check for control records during
   AIJ cache formatting. The default value 1 indicates that Oracle
   Rdb will check for control records and the value 0 indicates
   that Oracle Rdb will not check for control records. You can
   override the default value with the RDM$BIND_AIJ_CHECK_CONTROL_
   RECS logical name.
 

4  Cache_Shuffle_Dsbl_field
   This field indicates whether or not the group commit buffer
   "cache shuffle" mechanism is disabled. The default value "0"
   indicates that the cache shuffle mechanism is enabled, and the
   value "1" indicates that the cache shuffle mechanism is disabled.
   You can override the default value with the RDM$BIND_AIJ_SHUFFLE_
   DISABLED logical name.
 

4  ARB_Count_field
   This field displays the number of after-image journal request
   blocks (ARBs) that are in use for the database.
 

3  Checkpoint_DASHBOARD_screen
 

4  Ckpt_Blocks_field
   This field indicates the number of AIJ blocks after which a
   checkpoint will occur. The default value is 0 blocks. You can
   override the default value with the RDM$BIND_CKPT_BLOCKS logical
   name.
 

4  Ckpt_Time_Interval_field
   This field indicates the amount of time, in seconds, after which
   a checkpoint will occur. The default value is 0. You can override
   the default value with the RDM$BIND_CKPT_TIME logical name.
 

4  Ckpt_Tx_Interval_field
   This field indicates the number of committed transactions
   after which a checkpoint will occur. By default, if you have
   fast commit processing enabled, a process checkpoints when the
   AIJ block size limit is reached or the time interval limit is
   exceeded, whichever occurs first. You can specify the number of
   transactions as the checkpoint trigger by defining the RDM$BIND_
   CKPT_TRANS_INTERVAL logical name.
 

4  CTJ_Tx_Interval_field
   This field indicates the number of transactions to be allocated
   as a single batch when the commit to journal optimization feature
   is enabled. You can specify the number of transactions to be
   allocated by defining the RDM$BIND_TSN_INTERVAL logical name.
 

4  RW_Tx_Ckpt_Advance_field
   This field whether or not read/write transactions that modified
   no data are eligable to checkpoint when the transaction commits.
   The default value "0"indicates that such transactions do not
   evaluate checkpointing when they commit, and the value "1"
   idicates that they will. You can override the default value with
   the RDM$BIND_RW_TX_CHECKPOINT_ADVANCE logical name.
 

3  Hot_standby_DASHBOARD_screen
 

4  Network_Timeout_field
   This field displays the amount of time, in seconds, after which
   the Hot Standby network times out. The default is 120 seconds.
   You can override the default with the RDM$BIND_HOT_NETWORK_
   TIMEOUT logical name.
 

4  Connect_Timeout_field
   This field displays the amount of time, in minutes, to wait for
   the connection to be made between the master and the standby
   database. The default is 5 minutes. You can override the default
   with the RDM$BIND_LCS_CONNECT_TIMEOUT logical name.
 

4  Sync__Commit_Freq_field
   This field displays the Log Catch-up Server (LCS) process message
   synchronization count, expressed as the number of messages after
   which the LCS waits for the Log Rollforward Server (LRS) process
   on the standby database to finish processing all previously
   transmitted messages. The default is 64 messages. You can
   override the default value with the RDM$BIND_LCS_SYNC_COMMIT_
   MAX logical name.
 

4  Data_Sync_Mode_field
   This field displays the current database synchronization mode.

           0 = cold    1 = warm    2 = hot   3 = commit

   You can override the default with the RDM$BIND_HOT_DATA_SYNC_MODE
   logical name.
 

4  Server_Checkpoint_field
   This field displays the number of messages per server checkpoint
   interval. The default is 100 messages. You can override the
   default with the RDM$BIND_HOT_CHECKPOINT logical name.
 

4  LCS_Reopen_Log_Sec_field
   This field displays the amount of time, in seconds, that the LCS
   process will wait before attempting to automatically reopen its
   log file.
 

4  LCS_Reopen_Log_Siz_field
   This field displays the maximum file size that the LCS process
   log file is allowed to grow before it is automatically reopened.
 

4  Gap_Timeout_field
   This field displays the amount of time, in minutes, to wait for
   stalled MSN (gap) resolution. The default is 5 minutes. You can
   override the default value with the RDM$BIND_LRS_GAP_TIMEOUT
   logical name.
 

4  Commit_Queue_Min_field
   This field displays the minimum number of committed transactions
   the Log Rollforward Server (LRS) process on the standby database
   will process in a single batch. Decreasing this value may cause
   asynchronous pre-fetch stalls; increasing this value may cause
   buffer turnover. The default is 10 transactions. You can override
   the default value with the RDM$BIND_LRS_COMMIT_QUEUE_MIN logical
   name.
 

4  Commit_Queue_Cur_field
   This field displays the current number of committed transactions
   the Log Rollforward Server (LRS) process on the standby database
   will process in a single batch. This value dynamically floats
   between the minimum and maximum dashboard values. The default
   is 10 transactions. You can override the default value with the
   RDM$BIND_LRS_COMMIT_QUEUE_CUR logical name.
 

4  Commit_Queue_Max_field
   This field displays the maximum number of committed transactions
   the Log Rollforward Server (LRS) process on the standby database
   will process in a single batch. Decreasing this value may cause
   asynchronous pre-fetch stalls; increasing this value may cause
   buffer turnover. The default is 500 transactions. You can
   override the default value with the RDM$BIND_LRS_COMMIT_QUEUE_
   MAX logical name.
 

4  Governor_Enabled_field
   This field indicates whether the governor is enabled. The default
   value 1 indicates that the governor is enabled and the value 0
   indicates that it is disabled. You can override the default value
   with the RDM$BIND_LRS_GOVERNOR_ENABLED logical name.
 

4  LRS_Reopen_Log_Sec_field
   This field displays the amount of time, in seconds, that the LRS
   process will wait before attempting to automatically reopen its
   log file.
 

4  LRS_Reopen_Log_Siz_field
   This field displays the maximum file size that the LRS process
   log file is allowed to grow before it is automatically reopened.
 

4  Suspend_ABS_field
   This field indicates whether the ABS process is suspended as
   a result of a Hot Standby (replication) failure. The default
   value 1 indicates that the ABS process is suspended and the
   value 0 indicates that the ABS process is not suspended. You
   can override the default value with the RDM$BIND_HOT_ABS_SUSPEND
   logical name.
 

3  Row_Cache_DASHBOARD_screen
 

4  Insert_Enabled_field
   This field indicates whether or not rows can be inserted into
   the row cache. The default value 1 indicates that rows can be
   inserted into the cache and the value 0 indicates that rows
   cannot be inserted into the cache. You can override the default
   value with the RDM$BIND_RCACHE_INSERT_ENABLED logical name.
 

4  RCRL_Count_field
   This field displays the number of reserved row cache slots. You
   can override the default value of 20 slots with the RDM$BIND_
   RCACHE_RCRL_COUNT logical name.
 

4  Latch_Spin_Count_field
   This field indicates the number of times a process trying to
   acquire a latch should spin before hibernating.
 

3  ruj_DASHBOARD_screen
 

4  RUJ_Alloc_Blocks_field
   This field indicates the number of blocks the .ruj file is
   created with. The default value is 127 blocks. You can override
   the default value with the RDM$BIND_RUJ_ALLOC_BLKCNT logical
   name.
 

4  RUJ_Extend_Blocks_field
   This field indicates the number of blocks the .ruj file is
   extended by. The default value is 127 blocks. You can override
   the default value with the RDM$BIND_RUJ_EXTEND_BLKCNT logical
   name.
 

3  Monitor_DASHBOARD_screen
 

4  Max_DBR_Count_field
   This field displays the maximum number of database recovery (DBR)
   processes that will be invoked following node failure. RDM$BIND_
   MAX_DBR_COUNT logical name.
 

4  ABS_Priority_field
   This field displays the default priority that the detached ABS
   process will be invoked with. You can initialize this field with
   the RDM$BIND_ABS_PRIORITY logical name.
 

4  ALS_Priority_field
   This field displays the default priority that the detached ALS
   process will be invoked with. You can initialize this field with
   the RDM$BIND_ALS_PRIORITY logical name.
 

4  DBR_Priority_field
   This field displays the default priority that the detached DBR
   server process will be invoked with. You can initialize this
   field with the RDM$BIND_DBR_PRIORITY logical name.
 

4  LCS_Priority_field
   This field displays the default priority that the detached LCS
   process will be invoked with. You can initialize this field with
   the RDM$BIND_LCS_PRIORITY logical name.
 

4  LRS_Priority_field
   This field displays the default priority that the detached LRS
   server process will be invoked with. You can initialize this
   field with the RDM$BIND_LRS_PRIORITY logical name.
 

4  RCS_Priority_field
   This field displays the default priority that the detached
   row cache server (RCS) process will be invoked with. You can
   initialize this field with the RDM$BIND_RCS_PRIORITY logical
   name.
 

3  ABS_DASHBOARD_screen
 

4  Quiet_Point_field
   This field indicates whether the after-image journal backup
   server (ABS) will perform a quiet-point after-image journal
   backup.

   The default value 0 indicates that a no-quiet-point backup will
   be performed while 1 indicates that a quiet-point backup will be
   performed. You can override the default value with the RDM$BIND_
   ABS_QUIET_POINT logical name.
 

4  Overwrite_Allowed_field
   This field indicates whether the after-image journal backup
   server (ABS) is allowed to reset overwritten AIJ journals.

   The default value 0 indicates that the ABS cannot reset
   overwritten journals while the value 1 indicates that the ABS
   can reset overwritten journals. You can override the default
   value with the RDM$BIND_ABS_OVERWRITE_ALLOWED logical name.
 

4  OverwriteImmediate_field
   This field indicates whether journals should be immediately reset
   if RDM$BIND_ABS_OVERWRITE_ALLOWED is enabled.

   The default value 0 indicates that AIJ journals should not be
   immediately reset. The value 1 indicates that AIJ journals should
   be immediately reset depending on the value of the RDM$BIND_ABS_
   OVERWRITE_ALLOWED logical name.

   You can override the default value with the RDM$BIND_ABS_
   OVERWRITE_IMMEDIATE logical name.
 

3  ALS_DASHBOARD_screen
 

4  AIJ_Hiber_Time_field
   This field displays the amount of time (in hundredths of a
   second) that processes have spent hibernating while the AIJ log
   server processes their requests.
 

4  Switch_Global_Ckpt_field
   This field indicates whether to perform a global checkpoint after
   an AIJ switch-over has occurred. The default value 1 indicates
   that a global checkpoint will be performed and the value 0
   indicates that a global checkpoint will not be performed. You can
   override the default value with the RDM$BIND_AIJ_SWITCH_GLOBAL_
   CKPT logical name.
 

4  Check_Control_Recs_field
   This field indicates whether to check for control records during
   AIJ cache formatting. The default value 1 indicates that Oracle
   Rdb will check for control records and the value 0 indicates
   that Oracle Rdb will not check for control records. You can
   override the default value with the RDM$BIND_AIJ_CHECK_CONTROL_
   RECS logical name.
 

4  Emergency_AIJ_field
   This field indicates whether the ALS process creates an emergency
   AIJ journal if the AIJ switch-over operation enters the suspended
   state. The default value 0 indicates that the creation of
   emergency journals is disabled and the value 1 indicates that it
   is enabled. You can override the default value with the RDM$BIND_
   ALS_CREATE_AIJ logical name.
 

4  ALS_Log_Reopen_Sec_field
   This field displays the amount of time, in seconds, that the ALS
   process will wait before attempting to automatically reopen its
   log file.
 

4  ALS_Log_Reopen_Siz_field
   This field displays the maximum file size that the ALS process
   log file is allowed to grow before it is automatically reopened.
 

3  DBR_DASHBOARD_screen
 

4  Buffer_Count_field
   This field displays the default buffer count used by database
   processes. You can initialize this field with the RDM$BIND_DBR_
   BUFFER_CNT logical name.
 

3  RCS_DASHBOARD_screen
 

4  Ckpt_Buffer_Count_field
   This field indicates the number of buffers to be examined as
   a single batch by the row cache server (RCS) process during a
   checkpoint operation. You can override the default value of 15
   buffers with the RDM$BIND_RCS_CKPT_BUFFER_CNT logical name.
 

4  Batch_Count_field
   This field displays the number of rows to be flushed to disk.
 

4  Checkpoint_field
   This field indicates whether the row cache server (RCS) performs
   a checkpoint. The default value 1 indicates a checkpoint is
   performed and the value 0 indicates that a checkpoint is not
   performed. You can override the default value with the RDM$BIND_
   RCS_CHECKPOINT logical name.
 

4  Ckpt_Time_Interval_field
   This field indicates the amount of time, in seconds, after which
   a checkpoint will occur. The default value is 0. You can override
   the default value with the RDM$BIND_CKPT_TIME logical name.
 

4  Sweep_Interval_field
   This field indicates the amount of time, in minutes between
   sweeps. The default sweep interval is 1 minute. You can override
   the default value with the RDM$BIND_RCS_SWEEP_INTERVAL logical
   name.
 

4  Low_Cold_Thshld_field
   This field indicates the number of unmarked records below which
   the row cache server (RCS) sweep completes. You can override the
   default value with the RDM$BIND_RCS_MIN_COLD logical name.
 

4  High_Cold_Thshld_field
   This field indicates the number of marked records above which the
   row cache server (RCS) sweep starts. You can override the default
   value with the RDM$BIND_RCS_MAX_COLD logical name.
 

4  Cold_Record_Count_field
   This field displays the number of unmodified rows in the row
   cache.
 

4  Abort_Sweep_field
   This field indicates whether the sweep should be aborted. The
   default value 0 indicates that the sweep should be continued and
   the value 1 indicates that the sweep should be aborted.
 

3  Per_process_i_o_DASHBOARD_screen
 

4  Buffer_Count_field
   This field displays the actual buffer count used by database
   processes. Updating this field has no effect on the process since
   you cannot dynamically change the number of buffers.
 

4  APF_Enabled_field
   This field indicates whether asynchronous prefetch operations are
   enabled. The default value 1 indicates that asynchronous prefetch
   operations are enabled and the value 0 indicates that they are
   disabled. You can override the default value with the RDM$BIND_
   APF_ENABLED logical name.
 

4  APF_Depth_field
   This field displays the asynchronous prefetch depth setting. You
   can override the default value of 5 buffers with the RDM$BIND_
   APF_DEPTH logical name.
 

4  DAPF_Enabled_field
   This field indicates whether detected asynchronous prefetch
   operations are enabled. The default value 1 indicates that
   detected asynchronous prefetch operations are enabled and the
   value 0 indicates that they are disabled. You can override the
   default value with the RDM$BIND_DAPF_ENABLED logical name.
 

4  DAPF_Depth_Count_field
   This field displays the detected asynchronous prefetch depth
   setting.
 

4  DAPF_Start_Count_field
   This field displays the detected asynchronous prefetch start
   count.
 

4  ABW_Enabled_field
   This field indicates whether asynchronous batch write operations
   are enabled. The default value 1 indicates that asynchronous
   batch write operations are enabled and the value 0 indicates that
   they are disabled. You can override the default value with the
   RDM$BIND_ABW_ENABLED logical name.
 

4  ABW_Clean_BufCount_field
   This field displays the asynchronous batch write clean buffer
   count setting. You can override the default value of 5 buffers
   with the RDM$BIND_CLEAN_BUF_CNT logical name.
 

4  ABW_Batch_Max_field
   This field displays the asynchronous batch write maximum batch
   size setting.
 

4  Lock_Timeout_Intvl_field
   This field displays the number of seconds for a process to wait
   during a lock conflict before timing out. The default value is
   2147483647 seconds. You can override the default value with the
   RDM$BIND_LOCK_TIMEOUT_INTERVAL logical name.
 

4  Ready_AreaSerially_field
   This field indicates whether Oracle Rdb grants lock requests for
   logical and physical areas in the order that the lock requests
   were made. The default value 0 indicates that lock requests are
   not granted serially. You can override the default value with the
   RDM$BIND_READY_AREA_SERIALLY logical name.
 

4  Snap_Quiet_Point_field
   This field indicates whether the snapshot locks acquire a quiet-
   point lock. The default value 1 indicates that a quiet-point
   lock is acquired and the value 0 indicates that a quiet-point
   lock is not required. You can override the default value with the
   RDM$BIND_SNAP_QUIET_POINT logical name.
 

4  Hold_Retrvl_Locks_field
   This field indicates whether hold retrieval locks are enabled.
   The default value 0 indicates that hold retrieval locks are
   disabled and the value 1 indicates that they are enabled. You can
   override the default value with the RDM$BIND_HRL_ENABLED logical
   name.
 

4  Coarse_Buf_Lockng_field
   This field indicates whether coarse buffer locking is enabled.
   The default value 0 indicates that coarse buffer locking is
   disabled and the value 1 indicates that it is enabled. You can
   override the default value with the RDM$BIND_CBL_ENABLED logical
   name.
 

3  Per_process_JOURNAL_DASHBOARD_screen
 

4  Min_AIJ_IO_Bytes_field
   This field displays the minimum AIJ group commit I/O buffer size,
   in bytes. The default value is 4096 bytes. You can override the
   default value with the RDM$BIND_AIJ_IO_MIN logical name.
 

4  Max_AIJ_IO_Bytes_field
   This field displays the maximum AIJ group commit I/O buffer size,
   in bytes. The default value is 65024 blocks. You can override the
   default value with the RDM$BIND_AIJ_IO_MAX logical name.
 

4  AIJ_Stall_Interval_field
   This field displays the AIJ group commit stall time, in
   milliseconds.
 

4  Root_Stall_Intervl_field
   This field displays the TSNBLK group commit stall time, in
   milliseconds. You can override the default value with the
   RDM$BIND_COMMIT_STALL logical name.
 

4  Switch_Global_Ckpt_field
   This field indicates whether to perform a global checkpoint after
   an AIJ switch-over has occurred. The default value 1 indicates
   that a global checkpoint will be performed and the value 0
   indicates that a global checkpoint will not be performed. You can
   override the default value with the RDM$BIND_AIJ_SWITCH_GLOBAL_
   CKPT logical name.
 

4  Check_Control_Recs_field
   This field indicates whether to check for control records during
   AIJ cache formatting. The default value 1 indicates that Oracle
   Rdb will check for control records and the value 0 indicates
   that Oracle Rdb will not check for control records. You can
   override the default value with the RDM$BIND_AIJ_CHECK_CONTROL_
   RECS logical name.
 

4  Ckpt_Blocks_field
   This field indicates the number of AIJ blocks after which a
   checkpoint will occur. The default value is 0 blocks. You can
   override the default value with the RDM$BIND_CKPT_BLOCKS logical
   name.
 

4  Ckpt_Time_Interval_field
   This field indicates the amount of time, in seconds, after which
   a checkpoint will occur. The default value is 0. You can override
   the default value with the RDM$BIND_CKPT_TIME logical name.
 

4  Ckpt_Tx_Interval_field
   This field indicates the number of committed transactions
   after which a checkpoint will occur. By default, if you have
   fast commit processing enabled, a process checkpoints when the
   AIJ block size limit is reached or the time interval limit is
   exceeded, whichever occurs first. You can specify the number of
   transactions as the checkpoint trigger by defining the RDM$BIND_
   CKPT_TRANS_INTERVAL logical name.
 

4  CTJ_TX_Interval_field
   This field indicates the number of transactions to be allocated
   as a single batch when the commit to journal optimization feature
   is enabled. You can specify the number of transactions to be
   allocated by defining the RDM$BIND_TSN_INTERVAL logical name.
 

4  RW_Tx_Ckpt_Advance_field
   This field whether or not read/write transactions that modified
   no data are eligable to checkpoint when the transaction commits.
   The default value "0"indicates that such transactions do not
   evaluate checkpointing when they commit, and the value "1"
   idicates that they will. You can override the default value with
   the RDM$BIND_RW_TX_CHECKPOINT_ADVANCE logical name.
 

4  RUJ_Alloc_Blocks_field
   This field indicates the number of blocks the .ruj file is
   created with. The default value is 127 blocks. You can override
   the default value with the RDM$BIND_RUJ_ALLOC_BLKCNT logical
   name.
 

4  RUJ_Extend_Blocks_field
   This field indicates the number of blocks the .ruj file is
   extended by. The default value is 127 blocks. You can override
   the default value with the RDM$BIND_RUJ_EXTEND_BLKCNT logical
   name.
 

3  Per_Process_Row_Cache_DASHBOARD_screen
 

4  Insert_Enabled_field
   This field indicates whether or not rows can be inserted into
   the row cache. The default value 1 indicates that rows can be
   inserted into the cache and the value 0 indicates that rows
   cannot be inserted into the cache. You can override the default
   value with the RDM$BIND_RCACHE_INSERT_ENABLED logical name.
 

4  RCRL_Count_field
   This field displays the number of reserved row cache slots. You
   can override the default value of 20 slots with the RDM$BIND_
   RCACHE_RCRL_COUNT logical name.
 

4  Latch_Spin_Count_field
   This field indicates the number of times a process trying to
   acquire a latch should spin before hibernating.