Large BLOBs necessarily allocate many disk blocks, and thus create a high load on the node
internal log. This is normally not a problem, since each entry in the nilog is small.
Tuning InternalLogbuerSize
Begin with the default value. Look out for HIGH LOAD informational messages in the history les.
The relevant messages contain nilog, and a description of the internal resource contention that
occurred.
Use the following command to display node internal log buer information:
hadbm resourceinfo --nilogbuf
For example, the output might look something like this:
Node No. Avail Free Size
01111
11111
To change the size of the nilog buer, use the following command:
hadbm set InternalLogbufferSize
The hadbm restarts all the nodes, one by one, for the change to take eect. For more information
on using this command, see “Conguring HADB” in Sun GlassFish Enterprise Server 2.1 High
Availability Administration Guide
.
Note – If the size of the nilog buer is changed, the associated log device (located in the same
directory as the data devices) also changes. The size of the internal log buer must be equal to
the size of the internal log device. The command hadbm set InternalLogBufferSize ensures
this requirement. It stops a node, increases the InternalLogBufferSize, re initializes the
internal log device, and brings up the node. This sequence is performed on all nodes.
NumberOfLocks
Each row level operation requires a lock in the database. Locks are held until a transaction
commits or rolls back. Locks are set at the row (BLOB chunk) level, which means that a large
session state requires many locks. Locks are needed for both primary, and mirror node
operations. Hence, a BLOB operation allocates the same number of locks on two HADB nodes.
When a table refragmentation is performed, HADB needs extra lock resources. Thus, ordinary
user transactions can only acquire half of the locks allocated.
If the HADB node has no lock objects available, errors are written to the log le. .
TuningHADB
Chapter6 • TuningforHigh-Availability 113