Cache Performance Test

This serves as a good measure of the processing capability of the database server.

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.

A global is a named multidimensional array that is used for storing data in a physical Cache 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.

This measure considers the rate of Set operations performed on this database instance since the last measurement period. 

This measure considers the number of kill operations per second performed on this database instance since the last measurement period. 

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.

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.

To provide database integrity and reliability, Cache 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.

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.

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.

Rather than writing directly from memory to the database, the Cache 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, Cache 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 Cache starts, it automatically checks the write image journal and runs a recovery procedure if it detects that an abnormal shutdown occurred. When Cache 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, Cache 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.