| Measurement |
Description |
Measurement
Unit |
Interpretation |
| Lines_executed |
The number of lines of code per second that were executed on the server
|
Lines/Sec
|
This serves as a good measure of the processing capability of the database server.
|
| Routine_loads |
The rate at which routine loads and saves occurred
|
Routines/Sec
|
Routines are small programs that run within a Cache database server. In a well-tuned environment, this number increases slowly, since most routine loads are satisfied by the routine cache memory without accessing the disk. Each routine load or save transfers up to 32 KB of data.
|
| New_global_references |
The rate of at which new global references were set in this database instance
|
Refs/Sec
|
A global is a named multidimensional array that is used for storing data in a physical Caché database. Data can be spread across many globals that exist in different databases on the same system or remote systems. Using a namespace, you can group closely related globals and databases, so that data can be easily referenced. Cross-referencing of data ensures better data storage and efficient query execution.
|
| New_global_sets |
The rate at which new globals were created in this database instance
|
Sets/Sec
|
This measure considers the rate of SET operations performed on this database instance since the last measurement period.
|
| New_global_kills |
The rate at which new globals were killed in this database instance
|
Kills/Sec
|
This measure considers the number of KILL operations per second performed on this database instance since the last measurement period.
|
| Logical_DB_block_reads |
The rate at which data blocks were read from the disk
|
Blocks/Sec
|
Globals are stored on disk within a series of data blocks; the size of each block (typically 8KB) is determined when the physical database is created. A high value for this measure indicates that direct disk accesses are high. In such a case your database might require some fine-tuning. Consider resizing your buffer pool to increase buffer accesses and reduce data retrievals from the disk.
|
| Physical_DB_block_reads |
The rate at which physical database blocks (2-KB or 8-KB) were read from disk for both global and routine references
|
Blocks/Sec
|
A high value for this measure indicates that direct disk accesses are high. In such a case your database might require some fine-tuning. Consider resizing your buffer pool to increase buffer accesses and reduce data retrievals from the disk.
|
| Physical_DB_block_writes |
The rate at which physical database blocks (2-KB or 8-KB) were written to disk for both global and routine references
|
Blocks/Sec
|
|
| New_DB_journal_entries |
The number of entries recorded in the journal during this measurement period
|
Number
|
To provide database integrity and reliability, Caché includes a number of journaling subsystems that keep track of physical and logical database updates. The journal management technology is also used to provide transaction support (a journal is used to perform transaction rollback operations) as well as database shadowing (a journal is used to synchronize a shadow server with a primary data server).This measure hence aids in effective audit tracking of your database, as it can tell you whether any modifications have been performed on the database - be it a set/kill/transaction event. Since the events for which journaling is needed is configurable, you might want to track critical changes to your database by enabling journaling.
|
| Lock_commands |
The number of LOCK commands that are were issued in the last measurement period
|
Number
|
|
| Lock_successes |
The number of LOCK commands that succeeded in the last measurement period
|
Number
|
When the attempt to lock a transaction succeeds, it means that other processes will be prevented from seeing the modifications to the transaction, until the transaction is committed.
|
| Lock_failures |
The number of LOCK commands that failed during the last measurement period
|
Number
|
A lock command typically fails when it is unable to acquire a lock on a transaction - this happens when the transaction to be locked is already locked by another process.
|
| Current_global_jobs |
The number of jobs currently counted 'in global'
|
Number
|
|
| Max_global_jobs |
The maximum number of jobs currently counted 'in global'
|
Number
|
|
| Throttle_wait_jobs |
The number of jobs required to wait for a throttle
|
Number
|
|
| Write_update_status |
Whether /not the write daemon has successfully updated the database
|
Boolean
|
Rather than writing directly from memory to the database, the Caché write daemon system process (WRTDMN) uses an intermediate file, the write image journal. This file is usually named cache.wij. Write image journaling technology uses a two-phase process of writing to the database, as follows:
- In the first phase, Caché records the changes needed to complete the update in the write image journal. Once all updates to the write image journal have been entered, a flag is set in the file and the second phase begins.
- In the second phase, the Write daemon writes the changes recorded in the write image journal to the database on disk. When this second phase completes, the Write daemon sets a flag in the write image journal to indicate it is empty.
When Caché starts, it automatically checks the write image journal and runs a recovery procedure if it detects that an abnormal shutdown occurred. When Caché indicates successful completion, the internal integrity of the database is restored.Recovery is necessary if a system crash or other major system malfunction occurs at either of the following points in the two-phase write protocol process:
- Before the Write daemon has completed writing the update to the write image journal. In this case, recovery discards the incomplete entry.
- After the update to the write image journal is complete but before the update(s) to the database is complete. In this case, recovery rewrites the updates from the write image journal file to the database.
Note: The two-phase write protocol safeguards structural database integrity, but it does not prevent data loss. If the system failure occurs prior to a complete write of an update to the write image journal, Caché does not have all the information it needs to perform a complete update to disk. That data is lost.
If the value of this measure is '1', it indicates that the daemon has written to the database successfully. The value '0', on the other hand, indicates an unsuccessful attempt to perform global updates.
|
| Users_updating |
The number of users performing global updates
|
Number
|
|
| Write_daemon_status |
The status of the write daemon.
|
Boolean
|
The value 1 indicates that the write demon is running, and the value 0 indicates that write demon is waiting for wakeup.
|