Appendix B. 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:

TopicRefer 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)

Question
Why didn't anything happen when I executed CREATE TABLE with the database definition utility (pddef)?
Answer
Check for blanks after the semicolon (;) in a pddef control statement. If there is a blank, that SQL statement will not execute.
Wrong: CREATE TABLE ;[Figure] [[Figure]: blank]
Correct: CREATE TABLE ;

(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 [Figure]16 [Figure]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 [Figure]16 [Figure]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

Question
If an index is defined for a table in a configuration in which HiRDB is accessed from DBPARTNER2, does DBPARTNER2 need to know about the index?
Answer
No. HiRDB handles DBPARTNER2 in the same manner as regular client UAPs.

(9) Index definition for a partitioned table

Question
When an index is defined for a table that is partitioned among multiple server machines, how should the index be placed?
Answer
The index should be defined in units of table partitions, shown as follows.
[Figure]

(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?
[Figure]
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 [Figure] 3 = 6 files).
If there is not enough room on the disk, two logical status files are reasonable (dual files [Figure] 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:
[Figure]
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
  1. 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).
  2. 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:
  1. A HiRDB directory set in the PDDIR environment variable was not registered in the OS with the pdsetup command.
  2. A prerequisite program process is not installed (applicable only to 02-00).
  3. The process server daemon will not start due to too few semaphores in the kernel.
Take the following action:
  1. Register the HiRDB directory into the OS with the pdsetup command.
  2. Install the prerequisite program process.
  3. 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:
  1. It took more time to start a unit than was expected.
  2. There is a specification error in the server common definition or in an individual server definition.
Take the following action:
  1. Increase the value specified in the pd_start_time_out operand, and re-enter the pdstart command.
  2. 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:
  1. HiRDB is not installed on the corresponding machine.
  2. HiRDB was not registered into the OS with the pdsetup command.
  3. The installation directory is linked to a shared disk.
Take the following action:
  1. Restart the machine, execute pdsetup -d to delete the machine from the OS, then re-execute pdsetup.
  2. If HiRDB is installed on that machine, execute pdsetup.
  3. 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
  1. 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.
  2. 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.