SYS.MONITOR
The MONITOR
table stores information about system performance. It contains a single row with statistics about certain events. For many columns, statistics are gathered starting from the time the database is loaded into memory and statistics are cleared when the database is unloaded from memory. With a ramPolicy
of manual
or always
, the database remains in memory when there are no application connections.
For some columns, statistics are gathered as needed. TimesTen does not gather statistics from the time of the first connection for these columns:
-
PERM_ALLOCATED_SIZE
-
PERM_IN_USE_SIZE
-
TEMP_ALLOCATED_SIZE
-
LAST_LOG_FILE
-
REPHOLD_LOG_FILE
-
REPHOLD_LOG_OFF
-
FIRST_LOG_FILE
-
CHECKPOINT_BYTES_WRITTEN
For most columns, the MONITOR
table is reset whenever there are no connections to the database. TimesTen does not reset the values of the following columns, even when there are no connections to the database:
-
PERM_ALLOCATED_SIZE
-
PERM_IN_USE_SIZE
-
TEMP_ALLOCATED_SIZE
-
LAST_LOG_FILE
-
REPHOLD_LOG_FILE
-
REPHOLD_LOG_OFF
-
FIRST_LOG_FILE
TimesTen frequently updates information in the MONITOR
table. To prevent these updates from slowing down the system, they are not protected by latches. Hence values in the MONITOR
table are not absolutely accurate. They can be used as a reliable indication of activities in the system.
Note:
See the SYS.SYSTEMSTATS
table if the desired statistic is not in the SYS.MONITOR
table. There are statistics that exist in both the SYS.MONITOR
table and in the SYS.SYSTEMSTATS
table.
Columns
Column name | Type | Description |
---|---|---|
|
|
Time at which the first connection was made |
|
|
Number of connects to the database |
|
|
Number of disconnects from the database |
|
|
Number of checkpoints taken |
|
|
Number of fuzzy checkpoints taken |
|
|
Number of database compactions |
|
|
Size in kilobytes of the memory allocated to the permanent region |
|
|
Size in kilobytes of the memory in the permanent region that is currently in use |
|
|
The highest amount (in kilobytes) of memory in use within the permanent region since the first connection to the database The value of this field can be reset to the current value of the |
|
|
Size in kilobytes of the memory allocated to the temporary region |
|
|
Size in kilobytes of the memory in the temporary region that is currently in use |
|
|
The highest amount (in kilobytes) of memory in use within the temporary region since the first connection to the database The value of this field can be reset to the current value of the |
|
|
Number of times TimesTen fetches data from the Oracle database into TimesTen using dynamic load |
|
|
Number of times TimesTen communicates with the Oracle database to dynamically load data into TimesTen This count also includes attempts to perform a dynamic load when there is no data to fetch from the Oracle database. |
|
|
Number of times TimesTen successfully finds the required data in TimesTen |
|
|
Number of successful passthrough executions |
|
|
Number of transactions started |
|
|
Number of durable and nondurable transactions committed |
|
|
Number of transactions committed durably |
|
|
Number of transactions rolled back |
|
|
Number of times log files were synchronized to disk |
|
|
Number of deadlocks |
|
|
Number of lock requests denied due to timeouts |
|
|
Number of lock requests granted without a wait |
|
|
Number of lock requests granted after a wait |
|
|
Number of commands prepared (compiled) |
|
|
Number of commands re-prepared |
|
|
Number of temporary indexes created during query execution |
|
|
Most recent log file present Same as |
|
|
Number of last log file held by replication |
|
|
Offset in last log file held by replication |
|
|
The number of replicated transactions generated on the local database that are being replicated to at least one peer database |
|
|
The number of replicated transactions that ran into a conflict when being applied on the local database |
|
|
The sum of all peer connections initiated by the local replication agent There is one connection for every peer relationship where the local database is the master. If a transport level failure results in the establishment of a new connection, this count is incremented. |
|
|
The number of retry attempts while trying to establish a new peer connection |
|
|
The number of the oldest existing (not yet purged) log file |
|
|
The number of bytes written to the log since first connect This value includes the sizes of actual log records plus any log overhead. |
|
|
The number of times that a log read could not be satisfied from the in-memory log buffer |
|
|
The number of times TimesTen has written the contents of the in-memory log buffer to the operating system This column does not count the number of times data was flushed to disk. It counts writes to the operating system's file buffers. |
|
|
The number of times a thread was delayed while trying to insert a log record into the log buffer because the log buffer was full Generally speaking, if this value is increasing, it indicates that the log buffer is too small. |
|
|
The number of bytes written to disk by the most recent checkpoint operation |
|
|
Number of |
|
|
Number of |
|
|
Total number of blocks written for all completed checkpoints To improve I/O efficiency, multiple blocks may be coalesced into a single write or a single block may be split across multiple writes. |
|
|
Total number of write operations issued by all completed and in-progress checkpoints |
|
|
Recovery status 1: When the database was initially loaded into RAM at This means that the previous time the database was in memory, the database did not shut down cleanly. When it was loaded into memory this time, the log was replayed and other operations were performed in an attempt to recover data. If 0: The database was previously shut down cleanly. Thus the database was restarted cleanly. |
|
|
0: Oracle mode |
See also