6.2.3 Operands related to system monitoring

8) pd_watch_pc_client_time = maximum-client-request-wait-time
~<unsigned integer>((0-65535)) (seconds)
Specifies in seconds the maximum amount of time for a server to wait for the next request from a HiRDB client after the HiRDB server returns a response to a request from a Windows-compatible HiRDB client.
If no request comes from the HiRDB client within the specified amount of time, it will be assumed that an error occurred at the client and the connection between the server and the client will be terminated forcibly. No notice of disconnection is sent to the HiRDB client in such a case.
The time that is monitored is the period between CONNECT and DISCONNECT (that is, the non-transaction status time), excluding the period between SQL execution startup and COMMIT or ROLLBACK.
Operand default value
If this operand is omitted, the value specified for the same operand in the server common definition takes effect. If the same operand is also omitted from the server common definition, 3600 is assumed.
Notes
  • When 0 is specified, the server waits indefinitely for the next request from the HiRDB client.
  • If a small value (up to 600, for example) is specified for this operand, the HiRDB client might detect server down during SQL execution and might not terminate correctly.
  • For a UNIX edition of a HiRDB client (including a Linux edition of a HiRDB client), time is not monitored regardless of the value specified for this operand. To monitor time for a UNIX edition of a HiRDB client, specify the PDSWATCHTIME client environment definition of the HiRDB client.
Relationship to client environment definition
The value of this operand can be modified for each client. To do so, the PDSWATCHTIME operand must be specified in the client environment definition. For details about the PDSWATCHTIME operand, see the HiRDB Version 9 UAP Development Guide.
9) pd_spd_syncpoint_skip_limit = maximum-number-of-skipped-synchronization-point-dumps
~<unsigned integer>((0, 2-100000))
If an event such as an endless loop occurs in a UAP, acquisition of synchronization point dumps might be skipped. If several synchronization point dumps are not acquired (instead, they are skipped), there will be an increase in the number of overwrite-disabled system log files, which might result in a shortage of system log file capacity and ultimately in abnormal termination of the unit.
If HiRDB is forcibly terminated or terminates abnormally when the number of system log files that cannot be overwritten has reached one-half or more of all system log files, a shortage of system log files occurs during rollback processing when HiRDB is restarted. In this case, HiRDB cannot be restarted unless new system log files are added. Any such restart processing will take a longer time than normal.
This operand specifies the maximum number of times synchronization point dumps can be skipped (number of skips per transaction). When the number of skipped synchronization point dumps reaches the specified operand value, the target transaction is cancelled forcibly and rolled back. This is called the skipped effective synchronization point dump monitoring facility.
If Real Time SAN Replication based on the log-only synchronous method is used, the skipped effective synchronization point dump monitoring facility cannot be used at the log application site regardless of this operand value.
For details about this facility, see the HiRDB Version 9 System Operation Guide.
Advantage
Specifying this operand provides a means of dealing with endless loops in UAPs.
Specification guidelines
  • To use the skipped effective synchronization point dump monitoring facility, specify 0. To not use this facility, omit the pd_spd_syncpoint_skip_limit operand.
  • Normally, specify 0 for this operand. When 0 is specified, HiRDB computes the upper limit for the skip count. If specifying 0 causes a problem or the KFPS02101-I message is issued, change the value of this operand. For guidelines on the value to specify, see the HiRDB Version 9 System Operation Guide.
  • If the specified value is too large, all system log files might be placed in overwrite disabled status. If this happens, HiRDB terminates abnormally.
  • If the specified value is too small, the number of transactions that are forcibly rolled back might increase.
  • Specify this value taking into account the value of pd_log_sdinterval and the number of times synchronization point dumps are acquired when the transaction with the longest execution time and largest log output volume is processed.
Operand default value
If this operand is omitted, the value specified for the same operand in the server common definition takes effect. If the same operand is also omitted from the server common definition, the skipped effective synchronization point dump monitoring facility is not used.
Notes
  • When this operand is specified, UAPs that are being executed in the no-log mode are also monitored. If the processing of a UAP being executed in the no-log mode is cancelled, the database cannot be automatically recovered, and thus RDAREAs are placed in the error shutdown state. Therefore, when specifying the upper limit, account also for the size of the system logs that are output from other transactions inside the server during the processing of UAPs that are executed in the no-log mode.
  • If a transaction is delayed due to a high workload, the skip count increases because a synchronization point dump cannot be acquired until the delayed transaction is completed.
  • If the skip count exceeds the upper limit, any process executing a transaction is forcibly terminated. In this case, the rollback logs, which are the logs output by these transactions, are output after the forced termination.
  • This facility does not monitor the commands pdload, pdmod, pdrorg, pdexp, pddbst, pdgetcst, pdrbal, pdvrup, pdmemdb, pdextfunc, pdconstck, pdreclaim, pdpgbfon, pdparaload, and pddefrev, and commands provided by plug-ins.