2.2.26 Operands related to global buffers

128) pd_dbbuff_lru_option = SEPARATE | MIX
Specifies the LRU management method to be applied to global buffers. Note that MIX is assumed unconditionally when either of the following applies:
  • commit is specified in pd_dbsync_point
  • N is specified in pd_dbbuff_binary_data_lru
SEPARATE:
Manage the reference and update buffers with separate LRUs. If a global buffer shortage occurs, the reference buffer in the global buffer that was accessed first is purged from the memory. Specify this option when the number of references and updates per transaction is relatively small, as in an online job.
MIX:
Manage all global buffers with a single LRU. If a global buffer shortage occurs, the buffer in the global buffer that was accessed first is purged from the memory.
Specify this option when both a large number of retrievals and a large number of updates occur, as when an online job and a batch job coexist.
For details about the LRU management method for global buffers, see the manual HiRDB Version 9 Description.
129) pd_dbbuff_binary_data_lru = Y | N
Specifies whether LRU management is to be used for global buffers when executing a UAP that accesses a column for which BINARY type was specified. For details about setting the UAP to suppress LRU management of binary data to be accessed, see the HiRDB Version 9 Installation and Design Guide.
Y:
Applies LRU management to the branch row page at which binary data is stored and caches the page in a global buffer.
N:
Does not apply LRU management to the branch row page at which binary data is stored, but caches the page in a global buffer as the least recently accessed page, regardless of access frequency.
However, applies LRU management to the base row page and caches it in a global buffer.

When a UAP that accesses large amounts of large binary data using a global buffer is executed, the binary data is cached in the global buffer, so the contents most recently cached in the global buffer are pushed from memory, which can temporarily degrade performance. In such a case, if access frequency is low for binary data of a large size, this performance decline can be avoided by suppressing LRU management.
The table below describes LRU management and the advantages and disadvantages of each specification.
ItemOperand specification
YN
LRU managementWhen all global buffers are managed by the LRU method and there are insufficient global buffers, the least recently accessed global buffer in the global buffer pool is pushed from memory.LRU management of global buffer is suppressed for branch row pages that store binary data and the least recently accessed page is cached. When global buffers are insufficient, the global buffer of the branch row page that stores the binary data is pushed from memory.
AdvantageGlobal buffers are used evenly, regardless of the type of access data, so UAP performance is balanced.Binary data is pushed first from the global buffer, even if accessed after large binary data, so search performance is maintained for non-binary data.
DisadvantageWhen accessing after large binary data, the most recently accessed data is pushed from the global buffer, so search performance declines for non-binary data.
  • The buffer hit ratio declines in UAPs that access large binary data. That might increase the number of I/Os and decrease response performance.
  • When binary data is updated, the system log volume increases with frequent pushing out of binary-data branch rows.
Specification guidelines
  • Normally, this operand is not specified.
  • For systems that only accumulate without accessing binary data, specify N. For systems that frequently access binary data, specifying N in this operand has major disadvantages, so consider carefully before using it.
  • For systems that have tables that include the BINARY type, abstract data types that include BINARY type attributes, and large binary data (such as XML type data), specify N for this operand if there is almost no access to the large binary data. Because binary data is preferentially pushed from the global buffer regardless of how frequently a stored page is accessed, the frequency with which pages that store non-binary data are pushed out of the global buffer can be minimized.
Relationship to client environment definition
When NO is specified in PDDBBUFLRU in the client environment definition, LRU management is suppressed for all data that the specified UAP will access, regardless of the specification of this operand.
Relationship to other operands
If you specify N for this operand, MIX is assumed for the pd_dbbuff_lru_option operand, even if SEPARATE is specified in pd_dbbuff_lru_option.
130) pd_dbbuff_modify = Y | N
Specifies whether the global buffer is dynamically modified by the pdbufmod command while HiRDB is running. For details about dynamic modification of the global buffer, see the HiRDB Version 9 System Operation Guide.
Y: Dynamically modifies the global buffer.
N: Does not dynamically modify the global buffer.
Condition
If Y is specified for this operand (to dynamically modify the global buffer), HiRDB Advanced High Availability is required.
Relationship to other operands
This operand is related to the following operands:
  • SHMMAX
  • pdbuffer
  • pd_max_add_dbbuff_no
  • pd_max_add_dbbuff_shm_no
Effects on individual estimation formulas
If the value of the pd_dbbuff_modify operand is changed, the following estimation formulas are affected:
HiRDB Version 9 Installation and Design Guide:
  • Formula for size of shared memory used by global buffers under Estimating the memory size required for a HiRDB single server configuration
  • Formulas for shared memory used by a unit controller under Estimating the memory size required for a HiRDB single server configuration
  • Formula for size of shared memory used by global buffers under Estimating the memory size required for a HiRDB parallel server configuration
  • Formulas for shared memory used by a unit controller under Estimating the memory size required for a HiRDB parallel server configuration
  • Determining the value of S under Determining the size of status files
  • Formula 2, Formula 4, Formula 5, and Formula 6 under Formulas for shared memory used by a single server
  • Formula 2, Formula 3, Formula 4, and Formula 5 under Formulas for the size of the shared memory used by a dictionary server
  • Formula 2, Formula 4, Formula 5, and Formula 6 under Formulas for the size of the shared memory used by a back-end server
131) pd_dbbuff_rate_updpage = deferred-write-trigger-request-rate
~<unsigned integer>((1-100) ) (%)
Specifies the trigger for deferred write, as a percentage of the number of buffers that have been updated.
Specification guidelines
Normally omit this operand. Deferred write processing might not always be completed within the synchronization point dump acquisition interval. You can specify this operand for such cases if you want to shorten the writing time by reducing the number of updated buffers and slightly reducing the updated buffer hit rate. A guideline for this operand's value is to use 50% (the initial value set by HiRDB) or determine the operand's value by referring to Tuning deferred write processing and Tuning the synchronization point processing time when deferred write processing is used in the HiRDB Version 9 System Operation Guide.
  • When this operand is specified, the trigger remains constant, so the update buffer hit rate might decline as update volume increases, thus delaying response.
Relationships to other operands
This operand has the following relationships with the pdbuffer operand's -y option:
  • The value set for the pd_dbbuff_rate_updpage operand applies to all the global buffers.
  • The value of the pdbuffer operand's -y option applies to each global buffer.
  • The pdbuffer operand's -y option takes precedence over the pd_dbbuff_rate_updpage operand.
  • If the pdbuffer operand's -y option is omitted, the number of update buffer sectors for deferred write trigger event depends on the specification of this operand, as shown below:
    pd_dbbuff_rate_updpage operand valueNumber of update buffer sectors for deferred write trigger event
    SpecifiedNumber of global buffer sectors[Figure] pd_dbbuff_rate_updpage operand value
    OmittedDetermined automatically by HiRDB
132) pd_dbbuff_trace_level = global-buffer-control-information-trace-acquisition-level
~<unsigned integer>((0-2147483647))<<0>>
Specifies the acquisition level for global buffer control information traces, as an unsigned integer. The acquisition level is calculated by totaling the level values that correspond to the different functions of the facility for acquiring global buffer control information traces. When 0 is specified, global buffer control information traces are not acquired. The facility for acquiring global buffer control information traces and its corresponding level value are shown below. For details about the facility for acquiring global buffer control information traces, see the HiRDB Version 9 System Operation Guide.
Facility for acquiring global buffer control information tracesLevel value
Facility for acquiring syncpoint output synchronization control information1
Specification guidelines
Normally, there is no need to specify this operand. If a maintenance engineer asks you to specify this operand for a reason such as performance checking, follow the maintenance engineer's instructions.
Effects on individual estimation formulas
If the value of the pd_dbbuff_trace_level operand is changed, the following estimation formulas are affected:
HiRDB Version 9 Installation and Design Guide:
  • Calculation of required memory under Estimating the memory size required for a HiRDB single server configuration
  • Calculation of required memory under Estimating the memory size required for a HiRDB parallel server configuration
  • Formula 5 under Formulas for shared memory used by a single server
  • Formula 4 under Formulas for the size of the shared memory used by a dictionary server
  • Formula 5 under Formulas for the size of the shared memory used by a back-end server