Questions and Answers

This appendix discusses in question-and-answer format some of the topics concerning HiRDB system construction that can be easily misunderstood. The topics that are discussed are listed as follows:

Topic	Refer to
Installation directory	(1)
Error 1073	(2)
Method for determining the size of virtual memory	(3)
Use of a network drive	(4)
Host name specified in the pdstart operand of the system common definitions	(5)
HiRDB/Developer's Kit	(6)
Execution of the database definition utility (pddef)	(7)
Maximum size of a database	(8)
OpenTP1 and XA interface	(9)
Performance of FIX tables	(10)
Duplicate key index	(11)
Indexes	(12)
Index definition for a row-partitioned table	(13)
Handling of synchronization point dumps	(14)
Handling of status files	(15)-(18)
Maximum size of HiRDB file system area for work tables	(19)
HiRDB cannot be started by the pdstart command	(20)
Any particular unit cannot be started by the pdstart command	(21)
HiRDB startup using the pdstart command is slow	(22)
pdstart command results in an error (reason code=TIMEOUT)	(23)
Database definition utility (pddef) results in an error	(24)
CREATE TABLE statement LOB column definition	(25)

Organization of this section: (1) Installation directory; (2) Error 1073; (3) Method for determining the size of virtual memory; (4) Use of a network drive; (5) Host name specified in the pdstart operand of the system common definitions; (6) HiRDB/Developer's Kit; (7) Execution of the database definition utility (pddef); (8) Maximum size of a database; (9) OpenTP1 and XA interface; (10) Performance of FIX tables; (11) Duplicate key index; (12) How to use indexes; (13) Index definition for a partitioned table; (14) Handling of synchronization point dumps; (15) Handling of status files (dual status files); (16) Handling of status files (when an error occurs); (17) Handling of status files (status file definition); (18) Handling of status files (status file placement); (19) Peak capacity of a HiRDB file system area for work table files; (20) HiRDB cannot be started by the pdstart command; (21) Any particular unit cannot be started by the pdstart command; (22) HiRDB startup using the pdstart command is slow; (23) pdstart command results in an error (reason code=TIMEOUT); (24) Database definition utility (pddef) results in an error; (25) CREATE TABLE statement LOB column definition

(1) Installation directory

Question: Are there any points to be noted about the installation directory?

Answer

When specifying the name of the installation directory, note the following points. The pathname of the installation directory is set in the PDDIR environment variable.

Specify a character string that begins with the drive letter and consists of the following characters only:
Alphanumeric characters
_ (underscore)
. (period)
\ (backslash for separating paths)
Do not specify the drive letter only.
Do not use any double-byte character, or special symbol.
The length must be no greater than 128 bytes.
Use the name of the HiRDB directory that is specified in the pdunit system common definition operand.

(2) Error 1073

(3) Method for determining the size of virtual memory

(4) Use of a network drive

(5) Host name specified in the pdstart operand of the system common definitions

(6) HiRDB/Developer's Kit

Question: When do I need a HiRDB/Developer's Kit?

Answer: When creating a UAP on a machine on which a HiRDB server is installed, you do not need a HiRDB/Developer's Kit because the HiRDB server provides its facilities. You need a HiRDB/Developer's Kit when you create a UAP on a machine on which a HiRDB server is not installed.; You also need a HiRDB/Developer's Kit to create a UAP for a platform that is different from that for the HiRDB server.

(7) Execution of the database definition utility (pddef)

(8) Maximum size of a database

(9) OpenTP1 and XA interface

Question: When OpenTP1 is linked to HiRDB, why does transaction commit processing for a referencing-only SQL not seem to be passed via the XA interface?

Answer: When a referencing-only SQL is executed, the process is passed to HiRDB via the XA interface at the time of commit processing. However, it may not be apparent because fewer steps are required than in the case of an updating SQL.

(10) Performance of FIX tables

Question: How much difference in terms of performance is there between FIX tables and non-FIX tables?

Answer

It is difficult to say because performance depends on the number of columns and rows subject to manipulation; however, there has been a case where the execution time for retrieval of a large amount of data in one row of a FIX table was approximately two-thirds of the execution time for a table for which FIX was not specified.

Performance is never reduced by specifying FIX; therefore, FIX should always be specified when all the following apply:

There are no variable-length columns
There are no column with the NULL value
No columns will be added

(11) Duplicate key index

Question: Is it permissible to define an index with duplicate keys? If it's permissible, are there any problems in doing so?

Answer: Such an index can be defined (non-UNIQUE attribute). However, an index with many instances of keys duplicated many times (more than 200 keys) in a column is not desirable in terms of performance because a special storage structure is required and there are many index pages to be accessed.

(12) How to use indexes

(13) Index definition for a partitioned table

(14) Handling of synchronization point dumps

Question: How many guaranteed-valid generations of synchronization point dump files should be provided?

Answer: Information such as the read operation start location in the system log file is acquired in the synchronization point dump file each time a synchronization point dump is collected in order to prepare for a full rerun. The portion of the system log file beginning at the location indicated in the synchronization point dump file is overwrite-protected, so that it will not be used during a full rerun.; The number of guaranteed-valid generations is the number of generations of the synchronization point dump file that are used to overwrite-protect the system log file. In other words, if the number of guaranteed-valid generations is 1, the system log file beginning at the location indicated by the most recent synchronization point dump file is placed in overwrite-protected status. If the number of guaranteed-valid generations is 2, the system log file beginning at the location indicated by the synchronization point dump file generation immediately preceding the most recent synchronization point dump file will be placed in overwrite-protected status.

(15) Handling of status files (dual status files)

Question: How is a pair of dual status files formed? In the figure below, if errors occur in version A of logical file 1 and in version B of logical file 2, can version B of logical file 1 and version A of logical file 2 be used to constitute a pair?

Answer: A pair of system files is never formed using different logical files. A logical file whose versions A and B are both normal is selected. If there is no logical file with normal versions A and B, either the unit is terminated abnormally or the system is placed in the single operation mode in order to continue processing according to the specification of pd_sts_singleoperation.

(16) Handling of status files (when an error occurs)

Question

There are two operands that determine the method for handling status files in the event there are no more logical files with normal versions A and B (either A or B is erroneous):

pd_syssts_singleoperation=stop|continue (for unit status file)
pd_sts_singleoperation=stop|continue (for server status file)

Which option (stop or continue) should be specified?

Answer

If you specify stop, HiRDB (the unit for HiRDB/Parallel Server) terminates abnormally. If you specify continue, the single operation takes effect on the status files.

Status files are important because they contain information that is needed for a full recovery. If you specify continue and an error occurs in the status file during single operation, the unit is shut down because the error is on both versions. In this case, full recovery is not possible because both versions of the current file are inaccessible. This operand should be specified according to the following guidelines:

Specify stop if guaranteeing a successful full recovery is more important than avoiding online shutdown.
Specify continue if an application requires uninterrupted online operation (in the worst case, the database must be rolled back to its backup copy or data loading must be re-executed instead of executing a full recovery).

(17) Handling of status files (status file definition)

Question: You say that 1-7 logical status files can be defined, but what if there is not enough room on the disk? What is a reasonable number of logical status files that should be provided?

Answer: Considering maintenance of disk integrity from error to recovery, at least three logical status files should be provided (dual files 3 = 6 files).; If there is not enough room on the disk, two logical status files are reasonable (dual files 2 = 4 physical files). If an error occurs in such a case, it must be recovered immediately.; If only one logical status file is provided and an error occurs in the status file, the database will have to be re-created.

(18) Handling of status files (status file placement)

Question: How should status files be placed on disks?

Answer

As a rule, no more than one physical status file should be placed on the same disk (if multiple files are placed on the same disk, using dual files or multiple logical files serves no purposes).

If two logical files are defined, the files should be distributed among four disks; if three logical files are defined, they should be distributed among six disks.

Reliability can be achieved with fewer disks by placing physical status files in a ring format, as shown in the following figure.

Example of placement of three logical files:

This placement configuration provides two generations with both versions available in the event of an error on one of the volumes.

(19) Peak capacity of a HiRDB file system area for work table files

Question: How can I determine the peak capacity of a HiRDB file system area for work table files (back-end server definition: pdwork)?

Answer

Use the pdfstatfs command:

pdfstatfs -d name-of-HiRDB-file-system-area-for-work-table-files: The -d option displays the maximum utilization value for the allocated HiRDB file system area. The peak capacity value that is output is the maximum utilization value.; The maximum utilization value can be cleared with the pdfstatfs -c command:

pdfstatfs -c name-of-HiRDB-file-system-area-for-work-table-files: The -c option sets the maximum utilization value for the allocated HiRDB file system area to 0.

Notes: The -d and -c options of the pdfstatfs command are applicable only when the usage of the HiRDB file system area is WORK or UTL. If the usage is SYS or DB, this information is not displayed.; The -k option of the pdfmkfs command is used to specify the usage of a HiRDB file system area.

(20) HiRDB cannot be started by the pdstart command

(21) Any particular unit cannot be started by the pdstart command

Question: The pdstart command was entered, but a unit (other than the system manager unit) doesn't start. Why?

Answer: Check in the system common definition (pdsys) for the unit that cannot be started. The information defined with pdunit or pdstart probably does not match the information defined with pdsys for the MGR unit.; Correct pdsys for this unit and then restart the unit with pdstart -u.

(22) HiRDB startup using the pdstart command is slow

Question: The pdstart command terminated with the message, KFPS05078-I Unable to recognize HiRDB initialization Completion, but why does it take so long time (up to two hours) for all units to start?

Answer

If KFPS00608-W-314 is output more than once, check that the same host name is specified for pdunit and pdstart in pdsys for all units and that the specified host is correct (existing).
Check that all the hosts and networks specified with HiRDB are active.

(23) pdstart command results in an error (reason code=TIMEOUT)

Question: The pdstart command results in an error with the KFPS01861-E message (reason code=TIMEOUT). Why?

Answer

Following are possible reasons:

It took more time to start a unit than was expected.
There is a specification error in the server common definition or in an individual server definition.

Take the following action:

Increase the value specified in the pd_start_time_out operand, and re-enter the pdstart command.
Check the HiRDB messages output to the event log and correct the erroneous definition.

(24) Database definition utility (pddef) results in an error

Question: pdinit (database initialization utility) executed successfully, but pddef (definition utility) results in an error. What causes this?

Answer

Possible causes are:

If no response or connection error results, some information is probably missing in the environment variables.
Check the values set in PDHOST and PDNAMEPORT.

PDHOST: Specify the name of the host where HiRDB was started. This is the host name specified with pdstart in the HiRDB system common definition (pdsys).

PDNAMEPORT: This is the port number specified with pd_name_port in the HiRDB system common definition (pdsys).

If a connection error results, an invalid value may be set in the PDUSER environment variable.
Only one authorization identifier having the DBA privilege exists immediately after executing pdinit. Specify the authorization identifier and password in the PDUSER environment variable of the hirdb.ini file.

Notes

For details about the authorization identifier and password immediately after executing pdinit, see Options in Database Initialization Utility (pdinit) in the manual HiRDB Version 8 Command Reference.
When the PDUSER environment variable is set, the authorization identifier and password must each be enclosed in double quotation marks and the entire string must be enclosed in apostrophes. The same applies when any other HiRDB utility or UAP is executed.

(25) CREATE TABLE statement LOB column definition

Question: In a column definition using the CREATE TABLE statement, what is the difference in the memory requirements of HiRDB servers and HiRDB clients and in the volume of data transfer if you specify the LOB column maximum length (for example, 300 megabytes) as opposed to using the default (2 gigabytes)?

Answer: Whether or not the maximum length of LOB columns is specified, the memory requirements and the data transfer volume are the same. The memory requirements and data transfer volume when LOB columns are used for retrieval or updating depend not on the maximum length in the column definition, but on the actual length and the defined length of the embedded variables during retrieval or updating. If there is no limit on the storage of binary data, it can be limited by the maximum length of LOB columns.