2.2.5 Operands related to HiRDB processing

15) pd_dbsync_point = sync | commit
Specifies the timing for committing database updates to the file.
sync:
Commit database updates to the file at each synchronization point. This option enhances performance when a large number of transactions that update the same page occur between synchronization points. Because update information is not committed to the file when a COMMIT statement is issued, the input/output workload is reduced. Note that full recovery processing is slower than when commit is specified.
commit:
Commit database updates to the file when a COMMIT statement is issued. Because the database contents are guaranteed when the transaction is completed, there is no need to recover transaction processing from a synchronization point, thus reducing the time required for a full recovery. However, if a large number of transactions that update the same page occur between synchronization points, this option is slower than when the sync option is specified.
Note
In the following cases, either specify sync in this operand or omit this operand:
  • Real Time SAN Replication based on the hybrid method is used.
  • Real Time SAN Replication based on the log-only synchronous method is used.
Remarks
A LOB RDAREA is not affected by this operand. Directories are updated when the COMMIT statement is issued. Whether data is updated depends on whether a LOB global buffer has been allocated. If no LOB global buffer has been allocated, data is instantly updated when an update request is issued. If a LOB global buffer has been allocated, data is updated when the COMMIT statement is issued. However, if the global buffer becomes full, data is updated at that time.
Relationship to other operands
This operand is related to the pd_system_dbsync_point operand.
Effects on individual estimation formulas
If the value of the pd_dbsync_point 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
  • Formulas for shared memory used by a single server
  • Formulas for the size of the shared memory used by a dictionary server
  • Formulas for the size of the shared memory used by a back-end server
16) pd_system_dbsync_point = sync | commit
Specifies the timing for committing to file updates in the following types of RDAREAs:
  • Master directory RDAREA
  • Data directory RDAREA
  • Data dictionary RDAREAs
  • Data dictionary LOB RDAREAs
  • Registry RDAREAs
  • Registry LOB RDAREAs
sync:
Commit RDAREA updates to the file at each synchronization point. Because update information is not committed to the file when a COMMIT statement is issued, the processing performance of a definition SQL is slightly better than when the commit option is specified. However, full recovery processing is slower than when the commit option is specified.
commit:
Commit to file updates to the indicated types of RDAREAs when a COMMIT statement is issued. Because the contents of updates to the indicated types of RDAREAs are guaranteed when the transaction is completed, there is no need to recover these types of RDAREAs from a synchronization point, thus reducing the time required for a full recovery. However, the processing performance of a definition SQL is slightly lower than when sync is specified.
Relationship to other operands
This operand is related to the pd_dbsync_point operand. The following table shows the relationship to the pd_dbsync_point operand:
pd_dbsync_point specificationpd_system_dbsync_point specification
synccommit (default)
sync (default)Commits updates to all RDAREAs at a synchronization point.Commits updates to the indicated types of RDAREAs when a COMMIT statement is issued. Commits updates to other types of RDAREAs at a synchronization point.
commitCommits updates to all RDAREAs when a COMMIT statement is issued.
Effects on individual estimation formulas
If the value of the pd_system_dbsync_point operand is changed, the following estimation formulas are affected:
HiRDB Version 9 Installation and Design Guide:
  • Formulas for shared memory used by a single server
  • Formulas for the size of the shared memory used by a dictionary server
17) pd_process_terminator = resident | fixed | nonresident
If a HiRDB process is abnormally terminated, HiRDB starts a process that executes post-processing. This operand specifies whether the post-processing process is activated when HiRDB is started.
resident:
This option starts a single post-processing process when starting HiRDB. For a HiRDB parallel server configuration, a post-processing process is started in each unit.
If multiple processes terminate abnormally at the same time, post-processing processes up to the number specified by HiRDB are started and executed in parallel. If a new post-processing process cannot be started due to memory shortage, for example, post-processing is sequentially performed using the post-processing processes that are already active.
If the number of post-processing processes specified by HiRDB cannot be started due to a memory shortage, HiRDB (or the affected unit for a HiRDB parallel server configuration) might terminate abnormally.
fixed:
When starting HiRDB, this option starts the number of post-processing processes specified by the pd_process_terminator_max operand. For a HiRDB parallel server configuration, the number of post-processing processes specified by the pd_process_terminator_max operand are started in each unit. If post-processing processes cannot be started due to memory shortage, for example, HiRDB (or the applicable unit for a HiRDB parallel server configuration) is not started.
If a number of processes exceeding the value specified in the pd_process_terminator_max operand terminate abnormally at the same time, no additional post-processing processes are started. In this case, post-processing is sequentially performed using the post-processing processes that are already active.
nonresident:
This option does not start any post-processing process when starting HiRDB. A post-processing process is started whenever a process terminates abnormally.
If multiple processes terminate abnormally at the same time, post-processing processes are simultaneously started and executed in parallel. If post-processing processes cannot be started due to memory shortage, for example, HiRDB (or the applicable unit for a HiRDB parallel server configuration) might terminate abnormally in some cases.
Specification guidelines
  • To improve reliability, specify resident or fixed. Although fixed provides higher post-processing performance than resident, fixed requires more memory.
  • When nonresident is specified, post-processing processes are started on demand. Consequently, post-processing processes cannot be started if memory shortage occurs. Furthermore, if multiple processes terminate abnormally at the same time, multiple post-processing processes are started, resulting in performance degradation.
  • If you want to prevent HiRDB from terminating abnormally when a post-processing process cannot be started, we recommend that you specify fixed.
Note
You must be careful when changing the specification value to fixed. Because this option starts post-processing processes when starting HiRDB, it requires more memory. If memory shortage, for example, prevents post-processing processes from being started, HiRDB (or the applicable unit for a HiRDB parallel server configuration) cannot start.
18) pd_process_terminator_max = maximum-number-of-resident-post-processing-processes
~<unsigned integer>((1-100)) <<Max (3, [Figure](value of pd_max_users + value of pd_max_reflect_process_count) [Figure] 100[Figure])>>
Specify this operand if you have omitted the pd_process_terminator operand or specified fixed or it. Specify for the pd_process_terminator_max operand the number of post-processing processes to be started when starting HiRDB. If memory shortage, for example, prevents the specified number of post-processing processes from being started, HiRDB (or the applicable unit for a HiRDB parallel server configuration) cannot start.
Specification guidelines
The number of post-processing processes needed is proportional to the value of pd_max_users + pd_max_reflect_process_count. A small value might delay recovery processing, while a large value might use up memory unnecessarily.
19) pd_thdlock_wakeup_lock = Y | N
This operand can be used with the AIX and HP-UX editions only.
Specifies a thread lock release notification method. Specify Y in this operand to ensure that release notifications are transmitted.
Y:
When issuing a thread lock release notification, a new separate lock is temporarily obtained.
N:
When issuing a thread lock release notification, no new separate lock is temporarily obtained.
Specification guidelines
When multiple UAPs are executed concurrently, if the average SQL runtime is several dozen milliseconds but the maximum is one second or more, specify Y.
Notes
  • If you specify N or omit this operand, the SQL runtime might be delayed by about one second when multiple UAPs are executed concurrently.
  • If you specify Y, the SQL runtime might be delayed by several milliseconds when multiple UAPs are concurrently executed.
20) pd_pageaccess_mode = SNAPSHOT | NORMAL
Specifies the page access mode to be used for database search.
SNAPSHOT:
Uses a snapshot mode for page access. When the global buffer is accessed for the first time, rows that match the search condition are copied to the process private memory. During the second search request, a search result is returned by referencing the process private memory. For details about the snapshot mode, see the HiRDB Version 9 Installation and Design Guide.
NORMAL:
Uses a normal mode for page access. The global buffer is accessed for each search request.
Specification guidelines
If facilities for improving performance, such as the rapid grouping facility, cannot be used, consider using the snapshot mode. In normal search-SQL, the global buffer is accessed roughly the same number of times as the number of rows that match the specified search condition. Consequently, if search-SQLs are concurrently executed, accesses to the global buffer become concentrated, and as a result, the expected performance might not be obtained. In this case, using the snapshot mode can reduce the number of accesses by search-SQLs to the global buffer, and thus might improve the performance. However, using the snapshot mode increases the size of the process private memory used by HiRDB. For details about how to compute the size of process private memory when using the snapshot mode, see the HiRDB Version 9 Installation and Design Guide.
Effects on individual estimation formulas
If the value of the pd_pageaccess_mode operand is changed, the following estimation formulas are affected:
HiRDB Version 9 Installation and Design Guide:
  • Procedure for obtaining the size of the memory required when the snapshot method is used under Estimating the memory size required for a HiRDB single server configuration
  • Procedure for obtaining the size of the memory required when the snapshot method is used under Estimating the memory size required for a HiRDB parallel server configuration
21) pd_cmdhold_precheck = Y | N
Specifies whether to check for RDAREA hold before locking the RDAREA.
Y:
Checks for RDAREA hold before locking the RDAREA.
N:
Does not check for RDAREA hold before locking the RDAREA. Checking is performed after locking.
The following hold types are checked:
  • Command hold
  • Reference-possible hold
  • Reference-possible backup hold
Specification guidelines
Normally, omit this operand or specify Y. The following table describes the differences between Y and N specifications.
ItemY specifiedN specified
Processing by HiRDBDuring UAP or command# execution, HiRDB checks the hold status of all RDAREAs that might be accessed before locking the RDAREAs. For example, when accessing a table that is row-partitioned into RDAREAs 1 through 4, HiRDB checks the hold status of all four RDAREAs. However, when conditions are specified by key range partitioning or FIX hash partitioning, and the RDAREAs that might be accessed by the UAP are narrowed, no error results even when RDAREAs that cannot be accessed are on hold.During UAP or command# execution, HiRDB first locks RDAREAs and then checks the hold status of all RDAREAs that might be accessed. For example, assume that a table that is row-partitioned into RDAREAs 1 through 4 is to be accessed. If the target RDAREAs are narrowed using an index and if RDAREA 1 is to be accessed, HiRDB checks the hold status of RDAREA 1 only. This mode is used in HiRDB version 5.0 and earlier.
When a UAP accesses an RDAREA that is on holdBecause a hold check is performed before locking the RDAREA, the fact that the RDAREA is on hold can be detected more quickly than when N is specified.Because a hold check is performed after locking the RDAREA, the locked RDAREA might cause a timeout error (KFPA11770-E) if a UAP accesses the RDAREA that is on hold.
Additionally, if the access target RDAREA is on hold because data is being loaded or because it is being reorganized, the UAP might cause a hold error (KFPA11920-E).
When using a non-row partitioning index to narrow the access target RDAREAsYou must be careful when a table is row-partitioned but the index is not. When using a non-row partitioning index to narrow the access target RDAREAs. a hold error (KFPA11920-E) occurs, even when a non-access target RDAREA is on hold. In the example given for processing by HiRDB, the UAP causes a hold error (KFPA11920-E) if any of RDAREAs 1 through 4 is on hold.When using a non-row partitioning index to narrow the access target RDAREAs, the UAP or command can be executed even if a non-access target RDAREA is on hold. In the example given for processing by HiRDB, the UAP can be executed even if RDAREAs 2 through 4 are on hold.
#: Refers to UAPs and commands that cannot be executed if RDAREAs are on hold.
22) pd_db_io_error_action = dbhold | unitdown
Specifies the processing to be performed by HiRDB when an input/output error occurs in an RDAREA (excluding the master directory RDAREA). If an input/output error occurs in the master directory RDAREA, HiRDB (or a unit for a HiRDB parallel server configuration) always terminate abnormally regardless of the specification in this operand. For the actions to be taken when an RDAREA input/output error occurs, see the HiRDB Version 9 System Operation Guide.
An input/output error in this case refers to an error that occurs when a file manipulation attempt by HiRDB fails due to a cause that cannot be determined by HiRDB. When such an error occurs, -1544 is output as the error code returned in response to a HiRDB file system access request.
dbhold:
When an input/output error occurs in an RDAREA, the RDAREA is placed in an error shutdown state.
unitdown:
If an input/output error occurs in an RDAREA, HiRDB (or a unit for a HiRDB parallel server configuration) terminate abnormally. However, if an input/output error occurs again following an abnormal termination, the RDAREA is placed in an error shutdown state. To enable the specification of unitdown again, take one of the following actions:
  • Start HiRDB normally.
  • Execute the system reconfiguration command (pdchgconf command).
Specification guidelines
To determine the specification value for this operand, see Actions to be taken when an RDAREA input/output error occurs in the HiRDB Version 9 System Operation Guide.
Notes
  • HiRDB terminates abnormally if an input/output error occurs while unitdown is specified. Consequently, in the following cases, the processing target RDAREA might go onto error shutdown status:
    [Figure]The UAP or utility is executing in the pre-update log acquisition mode or the no-log mode.
    [Figure]The UAP or utility is being executed on a user LOB RDAREA that has been placed in the no-log mode by specification of NO in the RECOVERY operand of CREATE TABLE.
    If you use the facility for taking a unit down when a physical error is detected, avoid running these operations, if possible. If you need to run these operations, make a backup prior to running the UAP or utility in case recovery from an RDAREA error shutdown needs to be performed. For details about making back-ups, see the HiRDB Version 9 System Operation Guide.
  • If an input/output error occurs during the startup or termination process, HiRDB does not terminate abnormally even if unitdown is specified.
  • If the log-only synchronous method Real Time SAN Replication facility is being used, this operand is ignored, even when unitdown is specified at the time HiRDB is started at the log application site.
  • During recovery processing by the database recovery utility (pdrstr), HiRDB does not terminate abnormally even though unitdown is specified. In such a case, re-execute pdrstr to perform recovery.
Relationship to other operands
This operand is related to the following operands:
  • pd_mode_conf operand
  • pd_db_access_error_action operand
  • pd_db_hold_action operand
If unitdown is specified in more than one of the pd_db_io_error_action, pd_db_access_error_action, and pd_db_hold_action operands, the operand value that takes effect is determined in the following order:
  1. pd_db_io_error_action operand
  2. pd_db_access_error_action operand
  3. pd_db_hold_action operand
If more than one RDAREA input/output, file access, or physical error has occurred, determine the error that caused unitdown based on the above priority. In addition, see the message that is issued.
23) pd_connect_errmsg_hide = Y | N
Specifies whether to hide the error cause in the message that is output when a connection attempt fails.
Y: Hides the error cause when a connection attempt fails.
N: Does not hide the error cause when a connection attempt fails.
Depending on the value specified for this operand, the message that is output when a connection attempt fails might vary. The following table shows the details:
Error causeOutput message
pd_connect_errmsg
_hide = Y
pd_connect_errmsg
_hide = N (default value)
Invalid authorization identifier (the specified user does not exist)KFPA19632-EKFPA11561-E
Invalid password (the specified password is invalid)KFPA19632-EKFPA11560-E
24) pd_cancel_down_msgchange = Y | N
Specifies whether the error messages output when a server process is forcibly terminated are to be changed.
Y:
Changes the error messages to warning messages. The facility for changing error messages is called the facility for changing a process down message when cancelling a transaction.
N:
Does not change the error messages.
The following shows the relationship between the value of this operand and the error messages that are output:
ConditionMessages that are output
When Y (default value) is specifiedWhen N is specified
Server process is terminated forcibly for one of the following reasons#:
  • Intentional forced termination by the user
  • Forced termination caused by a timeout
  • Forced termination due to a failure at the client
  • KFPS01852-W
  • KFPO00115-W
  • KFPS01820-E
  • KFPO00105-E
Server process is terminated forcibly for some other reason
  • KFPS01820-E
  • KFPO00105-E
HiRDB cannot identify the cause of the forced termination of the server process
#: There are other causes that change the messages. For details, see Facility for changing the process-down message when a transaction is cancelled in the HiRDB Version 9 System Operation Guide.
Advantages
By specifying Y in this operand, you change the messages that are displayed for identifying the cause of forced termination of a server process.
Remarks
When the KFPS01820-E and KFPO00105-E messages are displayed, it is not possible to use the message IDs to distinguish between errors detected by HiRDB and errors resulting from an intentional user operation. To identify the cause, you must compare the process IDs that are displayed in the individual messages.
If JP1 is used to monitor messages, handling based on the KFPS01820-E and KFPO00105-E messages might be complicated because information about multiple messages cannot be compared. Specifying Y in this operand makes it easier to handle such messages because the output messages are classified by error cause. For this reason, it is recommended that you specify Y in this operand when you use JP1 to monitor messages.