Getting Device Information

Monitoring the HADB involves making sure that there is enough free space for the growth of the database. To get information about disk storage devices on each active node, use the hadbm deviceinfo command. The syntax is as follows:

hadbm deviceinfo [--details] [dbname]

For example:

hadbm deviceinfo --details

The default dbname is hadb.

The information displayed for each node of the database includes:

To determine the space available for user data, take the total device size, then subtract 4 times the LogBufferSize. 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.

The difference between the total device size and the free size is the user data size. If the data may be refragmented in the future, the user data size should not exceed 50% of the space available for user data. If refragmentation is not relevant, close to 100% may be used. Resource consumption warnings are written to the history files when the system is running short on device space.

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

If the --details option is specified, additional information is displayed:

For example:

NodeNO Totalsize Freesize Usage NReads NWrites DeviceName 0 128 120 6% 10000 5000 /var/opt/hadb.data.0 1 128 124 3% 10000 5000 /var/opt/hadb.data.1 2 128 126 2% 9500 4500 /var/opt/hadb.data.2 3 128 126 2% 9500 4500 /var/opt/hadb.data.3

If you need additional information, you can use the hadbm resourceinfo command. This command displays HADB runtime resource information that helps to identify resource contention, which you can use to reduce performance bottlenecks. For details, see the Sun Java System Application Server System Deployment Guide and the Sun Java System Application Server Performance Tuning Guide. The syntax is as follows:

hadbm resourceinfo [--databuf] [--locks] [--logbuf] [--nilogbuf] [dbname]

The following database information is displayed based on the options you specify:

For example, data buffer pool information is as follows:

NodeNO Avail Free Access Misses Copy-on-Write

0 256 128 100000 50000 1000

1 256 128 110000 45000 950

Locks information is as follows:

For example:

NodeNO Avail Free Waits

0 50000 20000 10

1 50000 20000 0

No more than 50% of the allocated locks are used for primary recording operations. The other 50% are reserved for hot standby recording operations. To change the NumberOfLocks, see “Viewing and Modifying Configuration Attributes” on page 62.

Log buffer information is as follows:

For example:

NodeNO Avail Free

0 16 2

1 16 3

Node internal log device information is as follows:

For example:

NodeNO Avail Free

0 16 2

1 16 3


Maintaining the HADB Machines

The HADB achieves fault tolerance by replicating data on mirror nodes. Mirror nodes should be placed on separate DRUs in a production environment as described in "HADB Server Architecture".

A failure is an unexpected event such as a hardware failure, power failure, or operating system reboot. The HADB tolerates single failures: of one node, one machine (that has no mirror node pairs), one or more machines belonging to the same DRU, or even one entire DRU. However, the HADB does not automatically recover from a double failure, which is the simultaneous failure of one or more mirror node pairs. If a double failure occurs, you must clear the HADB and recreate its session store, which erases all its data.

Installing the entire HADB on a single machine is recommended only for development and test environments, because in this case any failure except a single node failure is a double failure.


Caution

Before performing any maintenance, make sure you know which nodes are mirror nodes so you don’t shut down a mirror node pair and make the database Non Operational. See "Getting the Status of the HADB".


Otherwise, to perform planned or unplanned maintenance on a single machine without interrupting HADB service:

  1. For planned maintenance, stop all nodes on the machine. See "Stopping a Node".
  2. Perform the maintenance procedure and get the machine up and running.
  3. Start all nodes on the machine if either of the following is true:
  4. Check whether the nodes are active and running. See "Getting the Status of the HADB".

To perform planned maintenance on all HADB machines without interrupting HADB service:

  1. For each spare machine in the first DRU, repeat the single machine procedure, one by one, for each machine.
  2. For each active machine in the first DRU, repeat the single machine procedure, one by one, for each machine.
  3. Repeat Step 1 and Step 2 for the second DRU.

To perform planned maintenance with HADB service interruption on all HADB machines, or when the entire HADB is on a single machine:

  1. Stop the HADB. See "Stopping the HADB".
  2. Perform the maintenance procedure and get all the machines up and running.
  3. Start the HADB. See "Starting the HADB". The data stored in the database before the stop is available again.

To perform unplanned maintenance in the event of a failure, first check the database status. See "Getting the Status of the HADB".


Legal Notices