2.2.26 Operands related to global buffers

143) 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.
Relationship to other operands
If v6compatible or v7compatible is specified in the pd_sysdef_default_option operand, the default value for this operand is SEPARATE.
144) 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.
145) 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
  • Formulas for shared memory used by a unit controller under Estimating the memory size required for a HiRDB/Single Server
  • Formula for size of shared memory used by global buffers under Estimating the memory size required for a HiRDB/Parallel Server
  • Formulas for shared memory used by a unit controller under Estimating the memory size required for a HiRDB/Parallel Server
  • 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
146) pd_dbbuff_lock_release_detect = pipe | interval | switch
When the global buffer is accessed, a global buffer lock acquisition process occurs. This operand specifies the method that the process that is waiting for lock acquisition uses for detecting the lock release of the global buffer. This operand affects the processing performance when the access frequency to the same global buffer is high. The following table shows the processing mode for each operand specification and its characteristics.
SpecificationHiRDB processing mode and characteristicsCharacteristics
Response timeCPU usage
pipeLock-release processing uses a pipe file to inform the process waiting for lock acquisition of lock release.
Response time is not affected by the degree of job multiplexing. For this reason, the response time is constant compared to specifying interval or switch.
LongLow
intervalThe process waiting for lock acquisition checks at regular intervals whether the lock is still in effect.
Response time is affected by the degree of job multiplexing. For this reason, the greater the degree of job multiplexing, the longer the response time.
ShortHigh
switchThe basic processing mode is the same as for interval.
CPU usage is low compared to specifying interval because the CPU is used more efficiently.
Tuning, however, is more difficult compared to when interval is specified.
ShortMedium
Note
Response time and CPU usage indicate general trends only. They might vary depending on the execution environment and the value specified for the pd_dbbuff_lock_interval or pd_dbbuff_lock_spn_count operand.
Specification guidelines
  • If switch is specified when multiplexed UAP execution performance is notably slower than single unit performance, performance might improve.
  • Whether interval or switch is better to specify (which one improves performance) depends on the OS, machine performance, type of UAP processing, multiplexed UAP executions count, and other factors. However, performance is generally more stable when switch is specified.
Relationship to other operands
When interval or switch is specified in this operand, check the values specified in the following operands:
  • pd_dbbuff_lock_spn_count
  • pd_dbbuff_lock_interval
147) pd_dbbuff_lock_spn_count = number-of-spins-during-lock-acquisition-wait-processing
~<unsigned integer>((0-2147483646))<<100>>
Specifies the number of spins during lock acquisition wait processing when interval or switch is specified in the pd_dbbuff_lock_release_detect operand.
An overview of the lock acquisition processing for the global buffer is provided below. This operand specifies how many times step 1 is repeated.
  1. If the lock for the global buffer is released, the lock is acquired. If the lock is successfully acquired, the process is terminated. However, if the lock cannot be acquired, the process is repeated up to the number of times specified for this operand.
  2. If acquisition fails in step 1, the system sleeps for the amount of time specified in the pd_dbbuff_lock_interval operand (waits for the specified amount of time to elapse).
  3. Returns to step 1.
Condition
interval or switch must be specified in the pd_dbbuff_lock_release_detect operand.
Specification guidelines
Determine the value for this operand by referring to Lock release contention wait generation rate in global buffer lock release processing in the HiRDB Version 9 System Operation Guide.
Relationship to other operands
If this operand is specified, check the specification of the pd_dbbuff_lock_interval operand.
148) pd_dbbuff_lock_interval = interval-during-lock-acquisition-wait-processing
~<unsigned integer>((0-2147483647))<<1>>(milliseconds)
Specifies the interval during lock acquisition wait processing when interval or switch is specified in the pd_dbbuff_lock_release_detect operand.
An overview of the lock acquisition processing for the global buffer is provided below. For this operand, specify the time in step 2.
  1. If the lock for the global buffer is released, the lock is acquired. If the lock is successfully acquired, the process is terminated. However, if the lock cannot be acquired, the process is repeated up to the number of times specified for the pd_dbbuff_lock_spn_count operand.
  2. If acquisition fails in step 1, the system sleeps for the amount of time specified in this operand (waits for the specified amount of time to elapse).
  3. Returns to step 1.
Condition
interval or switch must be specified in the pd_dbbuff_lock_release_detect operand.
Specification guidelines
Determine the value for this operand by referring to Lock release contention wait generation rate in global buffer lock release processing in the HiRDB Version 9 System Operation Guide.
149) pd_dbbuff_wait_interval = global-buffer-occupation-state-check-interval
~<unsigned integer>((0-2147483647))(milliseconds)
This operand is applicable only to HiRDB/Parallel Server.
Specifies the interval at which the global buffer occupation state is to be checked. Specifying this operand changes the method of checking the global buffer occupation state.
When this operand is not specified
The following processing occurs:
[Figure]
When this operand is specified
The following processing occurs:
[Figure]
Specification guidelines
Specify this operand when all of the conditions listed below are satisfied. Performance might improve. Typically when this operand is used, a value of 1 is specified.
  • Global buffer lock-release wait has occurred. (You can check for this based on WAITL in the execution result of the pdbufls command.)
  • You want to improve performance, even if doing so increases the CPU usage rate.
If the CPU usage has become too high because 1 was specified in this operand, increase the value. If there is unused capacity in the CPU usage rate when 1 is specified in this operand, increase the pd_dbbuff_wait_spn_count operand value. Performance might improve.
150) pd_dbbuff_wait_spn_count = maximum-spin-loop-count-for-global-buffer-occupation-state-checking
~<unsigned integer>((0-2147483646))<<0>>
This operand is applicable only to HiRDB/Parallel Server.
Specifies the maximum spin loop count in an interval loop that can occur during global buffer occupation state checking. For details, see the description of the pd_dbbuff_wait_interval operand.
Specification guidelines
Normally, there is no need to specify this operand. Specify this operand when you specify 1 in the pd_dbbuff_wait_interval operand.
151) 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
152) 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
  • Calculation of required memory under Estimating the memory size required for a HiRDB/Parallel Server
  • 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