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
HiRDB/Developer's Kit	(1)
Execution of the database definition utility (pddef)	(2)
Maximum size of a database	(3)
Use of regular files and character special files	(4)
OpenTP1 and XA interface	(5)
Performance of FIX tables	(6)
Duplicate key index	(7)
How to use indexes	(8)
Index definition for a row-partitioned table	(9)
Response to pdsetup -d command	(10)
Handling of synchronization point dumps	(11)
Handling of status files	(12)-(15)
Peak capacity of a HiRDB file system area for work table files	(16)
HiRDB cannot be started by the pdstart command	(17)
Any particular unit cannot be started by the pdstart command	(18)
HiRDB startup using the pdstart command is slow	(19)
pdstart command results in an error (reason code=SETUP)	(20)
pdstart command results in an error (reason code=TIMEOUT)	(21)
A unit cannot be started by the pdstart command	(22)
Database definition utility (pddef) results in an error	(23)
CREATE TABLE statement LOB column definition	(24)

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

(1) 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.

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

(3) Maximum size of a database

Question: What is the maximum size of a HiRDB database?

Answer: One table can be divided and stored in a maximum of 512 RDAREAs, and one RDAREA can consist of a maximum of 16 HiRDB files.; The maximum size of a HiRDB file is approximately 2 GB; therefore, the maximum size of one HiRDB database is as follows:; 512 16 2 = approximately 16 terabytes (TB); A maximum of 16,000,000 RDAREAs can be used; therefore, the maximum total size of all databases is as follows:; 16,000,000 16 2 = approximately 512 petabytes (PB); HiRDB support large files. When you use a large file, the maximum size of one HiRDB file is 64 GB, thereby increasing the maximum size of a database.

(4) Use of regular files and character special files

Question: What is the difference between regular files and character special files? Which file system does HiRDB use?

Answer

A regular file uses a kernel buffer to input/output data, while a character special file uses a HiRDB buffer for direct input/output of data.

HiRDB supports both regular files and character special files, so the user can select the appropriate type. Character special files are usually used, but in the following cases better performance can be achieved by using regular files:

For files constituting an RDAREA that stores tables that are used mainly for retrieval of a large amount of data
For work table files

Because regular files are readily affected by system shutdown, character special files should be used for the following:

System log files
Synchronization point dump files
Status files
HiRDB files that constitute system RDAREAs
HiRDB files that constitute frequently updated user RDAREAs

Because HiRDB supports the prefetch facility, high-speed retrieval can be achieved when a character special file is used for an RDAREA that stores a table that is subject mainly to retrieval of a large amount of data.

(5) 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.

(6) 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

(7) 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.

(8) How to use indexes

(9) Index definition for a partitioned table

(10) Response to pdsetup -d command

Question: Which response, y or n, should be entered when pdsetup -d has been entered and the KFPS00036-Q message is displayed requesting a response?

Answer

If you respond with y, you will delete files and directories that HiRDB requires for execution. In such a case, the next time you execute the pdsetup command, copy the files required for execution from the installation directory. If you respond with n, the files and directories are not deleted.

In the following cases, you should respond with y:

When you are replacing the currently running HiRDB with the HiRDB that ran at the time of installation (when upgrading HiRDB, you must perform a normal shutdown using the pdstop command)
When you change the HiRDB administrator's authorization identifier
When there is an error in the files in the HiRDB operation directory, with a directory owner, or with a file mode, and they were changed or deleted

Note: If y is entered when the operation directory is different from the installation directory, the entire set of loaded files will be deleted from the operation directory. The set of loaded files will then be copied from the installation directory at the next pdsetup. Therefore, it takes some time to execute the command.

(11) 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.

(12) 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.

(13) 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).

(14) 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.

(15) 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.

(16) 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.

(17) HiRDB cannot be started by the pdstart command

Question: What is happening when HiRDB won't start when the pdstart command is entered and -prc results in abnormal termination with Psp4017?

Answer

Possible causes are:

HiRDB has not been set up correctly.
There is no access privilege to the /dev/HiRDB/pth directory or this directory does not exist.

Set up HiRDB correctly. After setting up HiRDB, check the access privilege for /dev/HiRDB/pth.

(18) 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?; When ps-ef is checked on the non-MGR unit, there is only pdprcd, and no other HiRDB daemon is started.

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.

(19) 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.

(20) pdstart command results in an error (reason code=SETUP)

Question: The pdstart command results in an error with the KFPS01801-E message. Why?

Answer

Following are possible reasons:

A HiRDB directory set in the PDDIR environment variable was not registered in the OS with the pdsetup command.
A prerequisite program process is not installed (applicable only to 02-00).
The process server daemon will not start due to too few semaphores in the kernel.

Take the following action:

Register the HiRDB directory into the OS with the pdsetup command.
Install the prerequisite program process.
Increase the number of semaphores defined in the system. Note that the specified value does not take effect until the system is restarted.

(21) 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 message output to syslogfile and correct the definition. Use pdsetup -d and enter y in response to the KFPS00036-Q message to delete HiRDB from the OS, then re-execute pdsetup.

(22) A unit cannot be started by the pdstart command

Question: When pdstart was executed, the KFPS01815-E message (errno=11, 13, 22) was output indicating that semaphore manipulation (semop, semctl) failed, making it impossible to start the unit. Why?

Answer

Following are possible reasons:

HiRDB is not installed on the corresponding machine.
HiRDB was not registered into the OS with the pdsetup command.
The installation directory is linked to a shared disk.

Take the following action:

Restart the machine, execute pdsetup -d to delete the machine from the OS, then re-execute pdsetup.
If HiRDB is installed on that machine, execute pdsetup.
Place the installation directories on a local disk at the local node.

Remarks: HiRDB cannot be used simply by copying its files from another environment; it must actually be installed.

(23) 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 as follows:

Bourne shell: PDUSER="authorization-identifier"/"password"; export PDUSER

C shell: setenv PDUSER "authorization-identifier"/"password"

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.

(24) 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.