2.2.24 Operands related to troubleshooting information

105) pd_cancel_dump = put | noput
This operand is designed to reduce the amount of troubleshooting information to be output.
Specifies whether troubleshooting information is to be collected in the following cases:
  • When SQL does not terminate within the monitoring time specified by the PDCWAITTIME operand in the client environment definition
  • When a UAP being executed is canceled by the pdcancel command
For details about the troubleshooting information to be collected, see the HiRDB Version 9 System Operation Guide and Table 2-4 Error information that is displayed in the event of abnormal termination in the section on the pd_dump_suppress_watch_time operand.
put:
Troubleshooting information is collected. Because the troubleshooting information is output to files under $PDDIR/spool, a space shortage might occur in the file system.
Note that the troubleshooting information that has been collected is automatically deleted by HiRDB at the following timings.
  • Every 24 hours while HiRDB is running (the deletion interval can be changed using the pd_spool_cleanup_interval operand).
  • When HiRDB is started (whether to delete the troubleshooting information can be changed using the pd_spool_cleanup operand).
For the HiRDB administrator to delete troubleshooting information, the administrator must execute the pdcspool command.
noput:
Do not collect troubleshooting information. Because no troubleshooting information will be collected, the load on the file system is reduced. Specify this option if UAP cancellation occurs frequently during normal operation and there is no need to investigate the causes.
Troubleshooting information might be acquired even though noput is specified in this operand. For details, see Table 2-4 Error information that is displayed in the event of abnormal termination in the section on the pd_dump_suppress_watch_time operand.
Notes
If a UAP is canceled by the pdcancel command with the -d option specified, troubleshooting information is collected regardless of the option specified for this operand.
106) pd_client_waittime_over_abort = Y | N
This operand is designed to reduce the amount of troubleshooting information to be output.
This operand specifies whether to collect the following types of troubleshooting information when the client maximum wait time (value of the PDCWAITTIME operand in the client environment definition) is exceeded during transaction execution.
  • Shared memory dump (collected only once)
  • Simple dump
  • Detailed information inside a unit
Troubleshooting information is collected into $PDDIR/spool/save.
Y:
Collect troubleshooting information. A shared memory dump is collected only when the maximum wait time of the first client after HiRDB activation is exceeded.
In the case of a HiRDB parallel server configuration, troubleshooting information is collected from the back-end server processes and dictionary server processes that are related to the connected front-end server processes. In the case of a HiRDB single server configuration, troubleshooting information is collected from the single server process.
N:
Do not collect troubleshooting information. In the case of a HiRDB parallel server configuration, troubleshooting information is not collected from the connected front-end server processes. Related back-end server processes and dictionary server processes are rolled back, and no troubleshooting information is collected from them. In the case of a HiRDB single server configuration, no troubleshooting information is collected from the single server process.
Notes
  • If troubleshooting information is maintained indefinitely in the file, it will use up file space. Note that the troubleshooting information that has been collected is automatically deleted by HiRDB at the following timings.
    [Figure]Every 24 hours while HiRDB is running (the deletion interval can be changed using the pd_spool_cleanup_interval operand).
    [Figure]When HiRDB is started (whether to delete the troubleshooting information can be changed using the pd_spool_cleanup operand).
    For the HiRDB administrator to delete troubleshooting information, the administrator must execute the pdcspool command.
  • Even when the client has exceeded its maximum wait time, it might not be possible to acquire troubleshooting information if the single server process or back-end server process that the client is connected to is in a critical state. Use the pdls -d rpc command to determine if a process is in a critical state.
Relationship to other operands
A HiRDB parallel server configuration can restrict the units that output shared memory dumps by specifying the pd_clt_waittime_over_dump_level operand, which can reduce the amount of output by shared memory dumps.
107) pd_clt_waittime_over_dump_level = all | shm_fesonly
This operand only applies to a HiRDB parallel server configuration. Its purpose is to reduces the amount of troubleshooting information that is output.
When Y (the default) is set in the pd_client_waittime_over_abort operand, the following troubleshooting information is acquired when the client's maximum wait time (value of the PDCWAITTIME operand in the client environment definition) is exceeded:
  • Shared memory dump (acquired only once)
  • Simple dump
  • Detailed information from within the unit
In the case of shared memory dumps, which produce a large amount of output, switchover can occur due to the computer being overwhelmed or the computer might slow down because of the burden of the shared memory dump acquisition processing.
Specifying shm_fesonly in this operand enables the units permitted to output shared memory dumps to be limited, thus reducing the amount of shared memory dump output.
all:
All units are to be permitted to output shared memory dumps (no restrictions). (The amount of shared memory dump output will not be reduced.)
shm_fesonly:
The units permitted to output shared memory dumps are to be restricted. (The amount of shared memory dump output will be reduced.) Only units defined as front-end servers will be permitted to output a shared memory dump.
The troubleshooting information that is output depending on the specification of this operand is explained in the following table.
Type of troubleshooting informationFES unit connected to the clientUnit accessed by the transactionOther units
Shared memory dumpall specified in this operandYYY
shm_fesonly specified in this operandYNN
Simple dumpYYN
Detailed information from within the unitYYY
Legend:
Y: Troubleshooting information is acquired.
N: Troubleshooting information is not acquired.
Note
Simple dumps and detailed information from within a unit are acquired regardless of the specification of this operand.
Application criterion
Normally, this operand need not be specified.
When there are many units and multiple units are allocated to a single server machine, acquisition processing for shared memory dumps might be executed concurrently for several units on the same server machine.
If this happens, the overhead of shared memory dump acquisition processing might overwhelm the computer or slow it down, causing switchover to occur. In such a case, specify shm_fesonly to reduce the workload on the machine.
The minimum required troubleshooting information will always be acquired even when shm_fesonly is specified.
108) pd_dump_suppress_watch_time = troubleshooting-information-output-suppression-time
~<unsigned integer>((0-3600)) <<0>> (seconds)
This operand is designed to reduce the amount of troubleshooting information to be output.
This operand specifies the amount of time (in seconds) during which to suppress outputting the troubleshooting information again (files under $PDDIR/spool) that is output when any of the following situations occurs.
  • The time specified in PDCWAITTIME is exceeded.
  • The UAP being executed is cancelled by the pdcancel command (except when the -d option is specified).
  • A process terminates abnormally.
Once troubleshooting information is output, no troubleshooting information is output again until the time specified by this operand has elapsed. For example, if 60 is specified for this operand, no troubleshooting information is output again until 60 seconds have passed because troubleshooting information was previously output.
Note that if 0 is specified in this operand, outputting of troubleshooting information is not suppressed.
Advantage
When there are multiple HiRDB server processes, timing out, for example, might cause them to terminate abnormally one after the other. If abnormal terminations of server processes occur successively, troubleshooting information, such as core files and simple dumps, are repeatedly collected, thus causing a space shortage on the disk on which the HiRDB directory is located. If such a shortage occurs, HiRDB might terminate abnormally. Therefore, specify this operand to make sure that no disk space shortage occurs.
Notes
  • When the -d option is specified for the pdcancel command, if abnormal termination is caused by an internal conflict, or if a signal is received from outside, troubleshooting information is collected regardless of the value specified for this operand.
  • The following table lists the error information that is displayed in the event of abnormal termination.

    Table 2-4 Error information that is displayed in the event of abnormal termination

    Cause of abnormal terminationError informationpd_dump_suppress_watch_time value
    0Not 0
    pd_cancel_dump value
    putnoputputnoput
    PDSWAITTIME overSave core fileNNNN
    Snapshot of errorNNNN
    Simple dump fileNNNN
    KFPA20009-W messageNNNN
    SQL runtime warning information fileNNNN
    PDSWATCHTIME overSave core fileNNNN
    Snapshot of errorNNNN
    Simple dump fileNNNN
    KFPA20009-W messageNNNN
    SQL runtime warning information fileNNNN
    PDCWAITTIME overpd_client_waittime
    _over_abort=Y
    Save core fileYYY+Y+
    Snapshot of errorYYY+Y+
    Snapshot 2 of errorYYY+Y+
    Simple dump fileYYY+Y+
    KFPA20009-W messageYYY+Y+
    SQL runtime warning information fileYYY+Y+
    Shared memory dump fileFFFF
    pd_client_waittime
    _over_abort=N
    Save core fileNNNN
    Snapshot of errorYNY+N
    Snapshot 2 of errorNNNN
    Simple dump fileYNY+N
    KFPA20009-W messageYNY+N
    SQL runtime warning information fileYNY+N
    Shared memory dump fileNNNN
    pdcancel command
    (-d option specified)
    Save core fileYYYY
    Snapshot of errorYYYY
    Simple dump fileYYYY
    KFPA20009-W messageYYYY
    SQL runtime warning information fileYYYY
    pdcancel command
    (-d option not specified)
    Save core fileNNNN
    Snapshot of errorYNY+N
    Simple dump fileYNY+N
    KFPA20009-W messageYNY+N
    SQL runtime warning information fileYNY+N
    Internal kill9#1Save core fileNNNN
    Snapshot of errorYNY+N
    Simple dump fileYNY+N
    KFPA20009-W messageYNY+N
    SQL runtime warning information fileYNY+N
    Internal kill3#2Save core fileYYY+Y+
    Snapshot of errorYYY+Y+
    Simple dump fileYYY+Y+
    KFPA20009-W messageYYY+Y+
    SQL runtime warning information fileYYY+Y+
    Abort#3Save core fileYYY+Y+
    Snapshot of errorYYY+Y+
    Simple dump fileYYY+Y+
    KFPA20009-W messageYYY+Y+
    SQL runtime warning information fileYYY+Y+
    Abort information fileYYY+Y+
    Other#4Save core fileDDDD
    Snapshot of errorYYYY
    Simple dump fileDDDD
    KFPA20009-W messageDDDD
    SQL runtime warning information fileDDDD
Legend:
Y: Outputs error information. The specification of the pd_dump_suppress_watch_time operand is invalid.
N: Does not output error information.
Y+: Outputs error information. The specification of the pd_dump_suppress_watch_time operand is valid.
D: Error information might not be output depending on how the process is terminated.
F: After the unit is started, error information is output during the first dump.
The units that output shared memory dumps can be restricted by specifying shm_fesonly in the pd_clt_waittime_over_dump_level operand.
#1: Issuance of internal SIGKILL, such as abnormal termination of a UAP by OpenTP1. Does not include PDCWAITTIME over or abnormal termination by the pdcancel command.
#2: Issuance of internal SIGQUIT, such as error detection. Does not include PDCWAITTIME over or abnormal termination by the pdcancel command.
#3: HiRDB detects a conflict and executes abort().
#4: SIGSEGV, SIGBUS, receiving of a signal from outside, exit, and other unexpected errors.
109) pd_debug_info_netstat = Y | N
This operand is designed to reduce the amount of troubleshooting information to be output.
Specifies whether troubleshooting information (network information) is to be collected when a HiRDB process or HiRDB (unit) terminates abnormally.
Y: Collect network information.
N: Do not collect network information.
Troubleshooting information related to network information is output to the server-name-n.deb file under $PDDIR/spool/save. If the server name is unknown, the server name might be replaced with a number. n is a serial number between 1 and 3. The following are file name examples:
Examples
sdsl.deb
fes2.deb
Specification guidelines
  • Normally, this operand need not be specified.
  • Specifying N reduces the load on the network associated with collecting network information when a HiRDB process or HiRDB (unit) terminates abnormally. However, it might not be possible to identify the causes of errors.
110) pd_spool_cleanup_interval = troubleshooting-information-deletion-interval
~<unsigned integer>((0-744))<<24>> (times)
This operand is used for deleting the troubleshooting information and temporary work files that have been output. If these items are not deleted, they might cause a space shortage on the disk on which the HiRDB directory is located. If such a shortage occurs, HiRDB might terminate abnormally. Therefore, HiRDB regularly deletes the following files:
  • Troubleshooting information file (files in $PDDIR/spool)
  • Temporary work files (files in $PDDIR/tmp)
  • Files in the directory specified in the pd_tmp_directory operand
This operand specifies the deletion interval (hours). For example, if 48 is specified for this operand, these files are deleted every 48 hours. Normally (if this operand is omitted), files are deleted every 24 hours.
Note that time counting begins when HiRDB is normally started. When HiRDB is normally terminated, time counting also stops. Then, the count returns to 0 during the next normal startup.
Specify the files to be deleted using the pd_spool_cleanup_interval_level operand explained as follows.
Operand rule
If 0 is specified, files are not deleted.
Specification guidelines
If 24, 48, 72, and so on are specified for this operand, files are deleted at the predetermined time. Specify the time so that files are deleted during the time period that does not overload the system.
Notes
Even while HiRDB is stopped because of planned termination, forced termination, or abnormal termination, time counting continues. However, if the deletion time arrives while HiRDB is stopped, files are not deleted. Files are not deleted until the next deletion time. To restart HiRDB after deleting the files, execute the pdcspool command.
Remarks
The difference between the pd_spool_cleanup_interval and pd_spool_cleanup operands is as follows:
  • The pd_spool_cleanup_interval operand is related to regular deletion of troubleshooting information.
  • The pd_spool_cleanup operand is related to the deletion of troubleshooting information during HiRDB startup.
Therefore, if you plan to run HiRDB continuously for 24 hours, consider specifying the pd_spool_cleanup_interval operand. If you plan to terminate HiRDB every day, consider specifying the pd_spool_cleanup operand.
111) pd_spool_cleanup_interval_level = number-of-days[,deletion-type]
This operand is used for deleting the troubleshooting information and temporary work files that have been output, and specifies the condition for regularly deleting the troubleshooting information and temporary work files.
number-of-days: ~<unsigned integer>((1-24855)) <<7>> (days)
Troubleshooting information files that are older than the number of days specified here are deleted. For example, if 3 is specified, all troubleshooting information files, except for those created within the last 3 days (or 3 days [Figure] 24 hours = 72 hours), are deleted.
deletion-type: <character string> <<all>>
Specifies the type of troubleshooting information file to be deleted.
all: All files are to be deleted.
dump: Only the files internally acquired by HiRDB are to be deleted.
The following are the types of troubleshooting information files that are deleted.
Troubleshooting information file typeDirectory namealldumpRemarks
Deadlock and timeout informationpdlckinfYNOutput when an error occurs during locking.
Access path informationpdsqldumpYNOutput when the access path display utility is used.
Save core filesaveYYOutput when a process is abnormally terminated.
Shared memory dump filepdshmdumpYYOutput when a process or unit is abnormally terminated.
Simple dump filespdsysdumpYYNone
pdsdsdumpYYNonexistent in a HiRDB parallel server configuration
pdfesdump
pddicdump
pdbesdump
YYNonexistent in a HiRDB single server configuration
System log file status information filepdjnlinfYNFiles under /pdjnlinf/errinf are not deleted.
Transaction information filepdtrninfYNOutput when Real Time SAN Replication is used.
Y: File is deleted.
N: File is not deleted.
Note:
Directory names under $PDDIR/spool are shown.
All temporary work files, except for those listed as follows, are deleted regardless of the deletion type specification. Parentheses indicate directory names under $PDDIR/tmp.
  • Current working directory (home) of the process in which HiRDB is to start
  • Shared memory information file (pdommenv)
  • Differential information files of the pdbufls command (files with names that begin with CMb)
Condition
A value other than 0 must be specified for the pd_spool_cleanup_interval operand.
Specification guidelines
  • Specify a value that is longer than the execution time of commands (including utilities). For example, if the execution of the pdcopy command, which collects backup, requires 24 hours (1 day), specify at least 2 for the number of days. If you do not specify a value that is longer than the execution time of the command, the temporary work files being used by the command are deleted, and thus the command might not run correctly.
  • If the specified value is too large, disk space might fill up; if the specified value is too small, information files needed for troubleshooting might be deleted.
Operand rule
If you specify a deletion type, you must also specify a number of days.
Note
If the TMPDIR environment variable is specified but the pd_tmp_directory operand is not specified, temporary work files used by commands and utilities will be output to the directory specified in the TMPDIR environment variable. Because temporary work files output to this directory are not subject to regular deletion, use the OS's rm command to delete them.
Remarks
The difference between the pd_spool_cleanup_interval_level and pd_spool_cleanup_level operands is as follows:
  • The pd_spool_cleanup_interval_level operand is related to regular deletion of troubleshooting information.
  • The pd_spool_cleanup_level operand is related to the deletion of troubleshooting information during HiRDB startup.
Therefore, if you plan to run HiRDB continuously for 24 hours, consider specifying the pd_spool_cleanup_interval_level operand. If you plan to terminate HiRDB every day, consider specifying the pd_spool_cleanup_level operand.
112) pd_spool_cleanup = normal | force | no
This operand is used for deleting the troubleshooting information that has been output.
Specifies whether troubleshooting information files (files under $PDDIR/spool) that were output previously by HiRDB are to be deleted when HiRDB is started. This operand is related to the pd_spool_cleanup_level operand, described as follows.
normal:
Delete the files when HiRDB is started normally or is restarted following a planned termination.
force:
Delete the files whenever HiRDB is started, regardless of the HiRDB activation mode.
no:
Do not delete the files.
Specification guidelines
If troubleshooting information files take up too much disk space, specify normal or force.
Note
Troubleshooting information that is output by a command or utility executed by a user other than the HiRDB administrator might not be deleted. In such a case, a user who is authorized to delete troubleshooting information files will have to use the OS's rm command to delete the files.
Remarks
The difference between the pd_spool_cleanup_interval and pd_spool_cleanup operands is as follows:
  • The pd_spool_cleanup_interval operand is related to regular deletion of troubleshooting information.
  • The pd_spool_cleanup operand is related to the deletion of troubleshooting information during HiRDB startup.
Therefore, if you plan to run HiRDB continuously for 24 hours, consider specifying the pd_spool_cleanup_interval operand. If you plan to terminate HiRDB every day, consider specifying the pd_spool_cleanup operand.
113) pd_spool_cleanup_level = number-of-days[,deletion-type]
This operand is used for deleting the troubleshooting information that has been output, and specifies the condition for deleting the troubleshooting information files during HiRDB startup.
number-of-days: ~<unsigned integer>((0-24855)) <<7>> (days)
Specifies a number of days when troubleshooting information that is older than the specified number of days is to be deleted. For example, if 3 is specified, all troubleshooting information will be deleted except for the information that is fewer than 3 days old (3 days [Figure] 24 hours = 72 hours).
If 0 is specified, all troubleshooting information files are deleted.
deletion-type: <character string> <<all>>
Specifies the type of troubleshooting information to be deleted.
all: Delete all file types.
dump: Delete only files collected internally by HiRDB.
The following are the types of troubleshooting information files that are deleted:
Troubleshooting information file typeDirectory namealldumpRemarks
Deadlock and timeout informationpdlckinfYNOutput when an error occurs during locking.
Access path informationpdsqldumpYNOutput when the access path display utility is used.
Save core filesaveYYOutput when a process is abnormally terminated.
Shared memory dump filepdshmdumpYYOutput when a process or unit is abnormally terminated.
Simple dump filespdsysdumpYYNone
pdsdsdumpYYNonexistent in a HiRDB parallel server configuration
pdfesdump
pddicdump
pdbesdump
YYNonexistent in a HiRDB single server configuration
System log file status information filepdjnlinfYNFiles under /pdjnlinf/errinf are not deleted.
Transaction information filepdtrninfYNOutput when Real Time SAN Replication is used.
Y: File is deleted.
N: File is not deleted.
Note: Directory names under $PDDIR/spool are shown.
Condition
normal or force (default value) must be specified for the pd_spool_cleanup operand.
Operand rule
A number of days and a deletion type must both be specified.
Remarks
The difference between the pd_spool_cleanup_interval_level and pd_spool_cleanup_level operands is as follows:
  • The pd_spool_cleanup_interval_level operand is related to regular deletion of troubleshooting information.
  • The pd_spool_cleanup_level operand is related to the deletion of troubleshooting information during HiRDB startup.
Therefore, if you plan to run HiRDB continuously for 24 hours, consider specifying the pd_spool_cleanup_interval_level operand. If you plan to terminate HiRDB every day, consider specifying the pd_spool_cleanup_level operand.
114) pd_module_trace_max = maximum-number-of-module-traces-that-can-be-stored
~<unsigned integer>((126-16383))<<256>>
A HiRDB process records the history of the executed functions and macros inside the process private memory. This history is called a module trace. This operand specifies the number of module trace records. The content of this history is loaded into the core file and is output when a process error occurs.
Specification guideline
Normally, there is no need to specify this operand. If a maintenance engineer asks you to specify this operand for a performance check purpose or the like, follow the maintenance engineer's instructions.
Note
Process private memory of the following size is allocated to each process:
In the 32-bit mode: 64 + 48 [Figure] pd_module_trace_max operand value (bytes)
In the 64-bit mode: 64 + 64 [Figure] pd_module_trace_max operand value (bytes)
115) pd_module_trace_timer_level = 0 | 10 | 20
Specifies how to acquire the time to be output in module traces. The following table explains the meaning of the value specified for this operand.
Specified valueTime acquisition method
0Time is output in seconds at every module trace output location.
10Time is output in microseconds only at performance-critical module trace output locations, such as those before and after input/output processing, and time is output in seconds at other locations.
20Time is output in microseconds at every module trace output location.
Specification guideline
Normally, there is no need to specify this operand. If a maintenance engineer asks you to specify this operand for a performance check purpose or the like, follow the maintenance engineer's instructions.
Note
If you specify a value other than 0 for this operand, a function for acquiring time in microseconds is issued, and as a result, system performance might decline.
116) pd_pth_trace_max = maximum-number-of-stored-communication-traces
~<unsigned integer>((1024-8388608))<<1024>>
Specifies the maximum number of communication trace records to be used as troubleshooting information.
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.
Notes
Increasing the value of this operand increases the amount of process private memory secured by HiRDB processes.
Process private memory for communication traces is calculated based on this operand's value rounded up to the power of two. For details about memory requirements, see Calculation of required memory in the HiRDB Version 9 Installation and Design Guide.
Effects on individual estimation formulas
If the value of the pd_pth_trace_max 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