Running: The node is providing
all services that are appropriate for its role.

Stopping: The node is in
the process of stopping.

Stopped: The node is inactive.
Repair of a stopped node is prohibited.

Recovering: The node is
being recovered. When a node fails, the mirror node takes over the functions
of the failed node. The failed node tries to recover by using the data and
log records in main memory or on disk. The failed node uses the log records
from the mirror node to catch up with the transactions performed when it was
down. If recovery is successful, the node becomes active. If recovery fails,
the node state changes to repairing.

Repairing: The node is
being repaired. This operation reinitializes the node and copies the data
and log records from the mirror node. Repair is more time consuming than recovery.

Getting Device Information

Monitor free space in HADB data (disk storage) devices:

Routinely, to check the trend in disk space use.

As part of preventive maintenance: if the user load has increased
and you want to resize or scale the database configuration.

As part of scaling up the database: Before running hadbm
addnodes to add new nodes to the system, check whether there is
enough device space. Remember, you need around 40-50% free space on the existing
nodes to add nodes.

When you see messages in the history files and server.log file such as

No free blocks on data devices

No unreserved blocks on data devices .

Use the hadbm deviceinfo command to get information
about free space in data devices. This command displays the following information
for each node of the database:

To determine the space available for user data, take the total device
size, then subtract the space reserved for HADB: four times the LogBufferSize+ 1% of the device size. If you do not know
the size of the log buffer, use the command hadbm get logbufferSize.
For example, if the total device size is 128 MB and the LogBufferSize is
24 MB, the space available for user data is 128 – (4 x 24) = 32 MB.
Of the 32 MB, half is used for replicated data and around one percent is used
for the indices, and only 25 percent is available for the real user data.

The space available for user data is the difference between the total
size and reserved size. If the data is refragmented in the future, the free
size must be approximately equal to 50% of the space available for user data.
If refragmentation is not relevant, the data devices can be exploited to their
maximum. Resource consumption warnings are written to the history files when
the system is running short on device space.

For more information about tuning HADB, see the Sun Java System
Application Server Performance Tuning Guide.

Data Buffer Pool Information

Access: Cumulative number of accesses to
the data buffer from database, from start until now.

Misses: Cumulative number of page faults
that have occurred from database start until now.

Copy-on-Write: Cumulative number of pages
copied internally in the data buffer due to checkpointing.

When a user transaction performs an operation on a record, the page
containing the record must be in the data buffer pool. If it is not, a miss or a page fault occurs. The transaction then has to wait until
the page is retrieved from the data device file on the disk.

If the miss rate is high, increase the data buffer pool. Since the misses
are cumulative, run hadbm resourceinfo periodically and
use the difference between two runs to see the trend of miss rate. Do not
be concerned if free space is very small, since the checkpointing mechanism
will make new blocks available.

Lock Information

Waits: Number of transactions waiting to
acquire locks. This is cumulative.

One single transaction cannot use more than 25% of the available locks
on a node. Therefore, transactions performing operations in large scale should
be aware of this limitation. It is best to perform such transactions in batches,
where each batch must be treated as a separate transaction, that is, each
batch commits. This is needed because read operations running with repeatable
read isolation level, and delete, insert,
and update operations use locks that are released only
after the transaction terminates.

Example 3–18 Example lock information

Log Buffer Information

Log buffer information is:

NodeNo: Node Number

Available: amount of memory allocated for
the log buffer in MB

Free: amount of free memory in MB

Do not worry if free space is very small, since HADB starts compressing
the log buffer. HADB starts compression from the head of the ring buffer and
performs it on consecutive log records. Compression cannot proceed when HADB
encounters a log record that has not been executed by the node and received
by the mirror node