For UNIX Systems

Scalable Database Server

HiRDB Version 8

System Operation Guide

3000-6-354(E)

Contents

Notices

Preface

1. HiRDB Startup and Termination

1.1 Startup

1.1.1 Startup modes

1.1.2 Server machine where the pdstart command is executed

1.1.3 Automatic startup

1.1.4 Reduced activation (applicable to HiRDB/Parallel Server only)

1.1.5 Example (HiRDB normal startup)

1.1.6 Checking for startup completion

1.2 Termination

1.2.1 Termination modes

1.2.2 Server machine where the pdstop command is executed

1.2.3 Example (HiRDB normal termination)

1.2.4 Terminating HiRDB during OS shutdown

1.3 Special startup procedures

1.3.1 Startup procedure used to reinitialize a database (pdstart -i)

1.3.2 Startup procedure used in the event of an error in the master directory RDAREA (pdstart -r)

1.3.3 Startup procedure used when the front-end server is in SUSPEND status due to an error in a data dictionary RDAREA (pdstart -a)

1.4 Startup and termination of a unit (applicable to HiRDB/Parallel Server only)

1.5 Startup and termination of a server (applicable to HiRDB/Parallel Server only)

1.6 Notes on startup

1.6.1 Notes on HiRDB startup

1.6.2 Notes on forced startup of HiRDB (or a unit)

1.6.3 Notes on HiRDB startup processing errors (applicable to HiRDB/Parallel Server only)

1.7 Notes on termination

1.7.1 Notes on HiRDB termination

1.7.2 Notes on planned termination, forced termination, and abnormal termination

1.8 Reducing the HiRDB startup processing time

2. Security Definition

2.1 About security

2.2 Setting user privileges

2.2.1 Granting the DBA privilege to users who manage user privileges

2.2.2 Granting the CONNECT privilege, schema definition privilege, and RDAREA usage privilege to users who create tables

2.2.3 Granting CONNECT and access privileges to users who access tables (database)

2.3 Revoking user privileges

2.4 Setting a referencing privilege for data dictionary tables

3. Handling System Log Files

3.1 Basics

3.2 Unloading the system log

3.2.1 HiRDB/Single Server

3.2.2 HiRDB/Parallel Server

3.3 Operating without unloading the system log

3.3.1 HiRDB/Single Server

3.3.2 HiRDB/Parallel Server

3.4 Releasing checking of unload status

3.5 Procedures for manipulating system log files

3.5.1 Checking for files in swappable target status

3.5.2 When there is no file in swappable target status

3.5.3 Unloading the current file

3.5.4 Unloading a file in unload completed status

3.5.5 When the system log in a file in unload wait status is not needed

3.5.6 Changing a file's status

3.5.7 Increasing (or reducing) the system log file size during HiRDB operation

3.5.8 Adding a new system log file

3.5.9 Deleting a system log file

3.6 Status changes of system log files

3.7 Changing the system log file record length

3.7.1 Example 1 (system log unloading operation)

3.7.2 Example 2 (operation without unloading the system log)

3.8 Using the automatic log unloading facility

3.8.1 Overview of automatic log unloading facility

3.8.2 Environment setup

3.8.3 Application example 1 (using a single directory for unload log files)

3.8.4 Application example 2 (using two directories for unload log files)

3.8.5 Application example 3 (making a backup)

3.8.6 Creating a time series list of unload log files (identifying the unload log files required for database restoration)

3.8.7 Error handling

3.8.8 Notes on HiRDB termination

3.9 Monitoring the free area for system log files

3.9.1 What is monitoring the free area for system log files?

3.9.2 Environment setting

3.9.3 HiRDB processing when the percentage of free area falls below the warning value

3.9.4 Tasks performed by the HiRDB administrator when the percentage of free area falls below the warning value

3.9.5 Notes

3.9.6 Output of status information file for system log files

4. Handling Synchronization Point Dump Files

4.1 Basics

4.2 Setting the synchronization point dump interval

4.3 Procedures for manipulating synchronization point dump files

4.3.1 When the status of a synchronization point dump file has changed

4.3.2 When there are no overwrite enabled files

4.3.3 Increasing (or reducing) the synchronization point dump file size during HiRDB operation

4.3.4 Changing the file status

4.3.5 Adding a new synchronization point dump file

4.3.6 Deleting a synchronization point dump file

4.3.7 Obtaining the system log file corresponding to a synchronization point dump in file

4.3.8 Increasing the number of synchronization point dump file guaranteed-valid generations

4.4 Status changes of synchronization point dump files

5. Handling Status Files

5.1 Basics

5.2 Procedures for manipulating status files

5.2.1 When status files are swapped

5.2.2 When there are no spare files

5.2.3 Increasing (or reducing) the status file size during HiRDB operation

5.2.4 Changing the file status

5.2.5 Changing the current file

5.2.6 Adding a new status file

5.2.7 Deleting a status file

5.2.8 Checking the information in a status file

5.3 Status changes of status files

6. Backup Procedures

6.1 Backup

6.1.1 Basics

6.1.2 Optional items

6.2 Backup acquisition mode

6.3 RDAREAs to be backed up together

6.4 Examples of backup

6.4.1 Example 1 (backing up a system)

6.4.2 Example 2 (backing up a system)

6.4.3 Example 3 (backing up a system)

6.4.4 Example 4 (backing up a unit)

6.4.5 Example 5 (backing up a server)

6.4.6 Example 6 (Backing up RDAREAs)

6.5 Acquiring a differential backup

6.5.1 Differential backup facility overview

6.5.2 Preparations for using the differential backup facility

6.5.3 Examples of using the differential backup facility

6.5.4 Creating an accumulation-differential backup

6.5.5 Referencing the history file for differential backups

6.5.6 Restoring a differential backup management file

6.6 Example of shell for backing up after synchronization point dump validation

6.7 Backup acquisition using JP1/OmniBack II (applicable to HP-UX only)

6.7.1 System configuration example

6.7.2 Environment setup

6.7.3 Notes on backup acquisition

6.7.4 Example 1 (HiRDB/Single Server)

6.7.5 Example 2 (HiRDB/Parallel Server)

6.8 Backup acquisition using backup-hold (backup without using the pdcopy command)

6.8.1 About backup-hold

6.8.2 Example 1 (using another product's backup facilities)

6.8.3 Example 2 (using the mirror disk facility)

6.9 Backup acquisition when the frozen update command (pddbfrz command) is used

6.9.1 Operation subject to the frozen update command

6.9.2 Operation of the frozen update command (pddbfrz command)

6.9.3 Operation example

6.9.4 Checking for files with full data pages

6.9.5 Manipulating user LOB RDAREAs for which the frozen update command has been executed

6.9.6 Relationship between RDAREAs and automatic extensions

6.9.7 Notes

7. Operation Without Acquiring a Database Update Log

7.1 Database update log acquisition modes

7.2 Procedure for executing a UAP or utility in the pre-update log acquisition mode

7.3 Procedure for executing a UAP or utility in the no-log mode

8. Obtaining the System Operating Environment (Monitoring the System Status)

8.1 Using the message log to check the system execution status

8.1.1 Referencing the message log (message log output destination)

8.1.2 Using the message log files

8.1.3 Selecting a message log output method (applicable only to a HiRDB/Parallel Server)

8.1.4 Suppressing message output to syslogfile

8.2 When a UAP or utility execution takes too long

8.3 When HiRDB startup or termination processing takes too long

8.4 Obtaining RDAREA status

8.5 Obtaining shared memory utilization status

8.6 In the event of deadlock

8.6.1 Basics

8.6.2 Deadlock information that is output

8.6.3 Timeout information that is output

8.6.4 Resource types and resource information

8.6.5 Interpreting resource information

8.7 In the event of a shortage of locked resources management tables

8.8 Monitoring UAP status (skipped effective synchronization point dump monitoring facility)

8.9 Output of warning information about the time required for SQL execution (SQL runtime warning output facility)

8.9.1 Overview of the SQL runtime warning output facility

8.9.2 Using the SQL runtime warning output facility

8.9.3 Information output to the SQL runtime warning information file

8.9.4 Output of the KFPA20009-W message

8.9.5 Notes

8.10 Monitoring the execution time of UAPs and utilities (reducing the effects of nonresponding programs)

8.11 Monitoring resource utilization factors

8.12 Monitoring the status of server processes (message queue monitoring facility)

8.13 Monitoring the number of times server processes terminate abnormally (abnormal termination monitoring facility)

8.14 Monitoring the memory size of server processes (facility for monitoring the memory size of server processes)

9. Modifying the System Operating Environment

9.1 Modifying HiRDB system definitions

9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command)

9.2.1 Modification procedure

9.2.2 Notes on changing operand specification values

9.2.3 Notes on executing the system reconfiguration command

9.2.4 HiRDB status after the system reconfiguration command has executed

9.2.5 Relationship with other facilities

9.2.6 Actions to take when an error occurs

9.3 Adding, modifying, and deleting global buffers while HiRDB is running (dynamic updating of global buffers)

9.3.1 Overview of dynamic updating of global buffers

9.3.2 Application examples

9.4 Changing the number of server processes

9.5 Handling an increase in the number of users

9.6 Accommodating clients that cannot connect to HiRDB (connection frame guarantee facility for client groups)

9.7 Specifying a range of port numbers for use in communication processing

9.8 Changing the host name

9.9 Changing the deadlock priority value for commands

9.9.1 Deadlock priority value for commands

9.9.2 Environment assignment

9.9.3 Operation method

10. Handling HiRDB File System Areas

10.1 Obtaining information about a HiRDB file system area

10.2 Creating (initializing) a HiRDB file system area

10.3 Backing up a HiRDB file system area

10.4 Restoring a HiRDB file system area

10.5 Deleting a HiRDB file system area

11. Modifying the System Configuration

11.1 Adding a unit

11.1.1 Adding a unit while HiRDB is running

11.1.2 Adding a unit while HiRDB is stopped

11.2 Removing a unit

11.2.1 Removing a unit while HiRDB is running

11.2.2 Removing a unit while HiRDB is stopped

11.3 Moving a unit

11.3.1 Moving a unit while HiRDB is running

11.3.2 Moving a unit while HiRDB is stopped

11.4 Adding a server

11.4.1 Adding a server while HiRDB is running

11.4.2 Adding a server while HiRDB is stopped

11.5 Removing a server

11.5.1 Removing a server while HiRDB is running

11.5.2 Removing a server while HiRDB is stopped

11.6 Moving a server

11.6.1 Moving a server while HiRDB is running

11.6.2 Moving a server while HiRDB is stopped

11.7 Migrating a HiRDB/Single Server to a HiRDB/Parallel Server

11.7.1 Preparations for migration

11.7.2 Migration procedure

11.7.3 Points to be noted about migrating multiple user RDAREAs to different back-end servers

11.8 Migrating back-end servers for load balancing

11.8.1 Back-end server load balancing based on a scenario

11.8.2 Prerequisites and conditions for the target jobs

11.8.3 Using a scenario

11.8.4 Back-end server configuration examples

11.8.5 Preparations related to HiRDB

11.8.6 Back-end server load balancing performed by the user

12. Migrating Resources Between Systems

12.1 Migrating a table to another HiRDB system

12.1.1 Migrating a table to another HiRDB system

12.1.2 Example 1: Migrating a table

12.1.3 Example 2: Migrating tables of a schema

12.1.4 Example of a control statements file when migrating tables to a different schema

12.2 Migrating a stored procedure to another HiRDB system

12.2.1 Preparations for migrating a stored procedure to another HiRDB system

12.2.2 Example

13. Handling Tables

13.1 Checking table storage efficiency

13.1.1 Executing the database condition analysis utility on a regular basis

13.1.2 Messages indicating poor data storage efficiency

13.1.3 When expected retrieval performance cannot be achieved

13.2 Reorganizing a table

13.2.1 Table reorganization

13.2.2 Execution units for table reorganization

13.2.3 Selecting an update log acquisition mode for a database

13.2.4 Before reorganizing a table

13.3 Reorganizing a table (examples)

13.3.1 Example 1: Reorganizing a table (HiRDB/Single Server)

13.3.2 Example 2: Reorganizing a table (HiRDB/Parallel Server)

13.3.3 Example 3: Reorganizing an RDAREA

13.3.4 Example 4: Reorganizing a schema

13.3.5 Example 5: Reorganizing a table in which a LOB column is defined

13.3.6 Example 6: Reorganizing data dictionary tables

13.3.7 Example 7: Reorganizing in no-log mode

13.3.8 Example 8: Reorganizing a table in which an abstract data type is defined

13.4 Predicting table reorganization time (facility for predicting reorganization time)

13.4.1 Predicting reorganization time

13.4.2 Preparations for using the facility for predicting reorganization time

13.4.3 Operational flow

13.4.4 Notes on using the facility for predicting reorganization time

13.4.5 Stopping reorganization time prediction

13.4.6 Customizing reorganization time prediction

13.5 Deleting data from a table

13.6 Adding a column

13.6.1 Preparations for adding a column

13.6.2 Example 1: Adding a column to a table without the FIX attribute

13.6.3 Example 2: Adding a LOB column

13.6.4 Example 3: Adding an abstract data type column

13.6.5 Example 4: Adding a column to a table with the FIX attribute (unloading in DAT format)

13.6.6 Example 5: Adding a column to a table with the FIX attribute (unloading in binary format)

13.7 Deleting a column

13.7.1 Example: Deleting a column

13.8 Modifying a table's definition

13.8.1 Example: Changing the data size of a column

13.9 Changing a table name or column name

13.9.1 Example 1: Changing a table name

13.9.2 Example 2: Changing a column name

13.10 Increasing the number of table row partitions

13.10.1 Example 1: Increasing the number of row partitions in a table with key range partitioning

13.10.2 Example 2: Increasing the number of row partitions in a table with flexible hash partitioning

13.10.3 Example 3: Increasing the number of row partitions in a table with FIX hash partitioning

13.11 Increasing the number of table row partitions (using the hash facility for hash row partitioning)

13.11.1 Overview of the hash facility for hash row partitioning

13.11.2 Preparations for using the hash facility for hash row partitioning

13.11.3 Example: Increasing the number of row partitions in a rebalancing table

13.11.4 Using the rebalancing utility (when table rebalancing takes time)

13.11.5 Notes on a table with FIX hash partitioning

13.12 Changing a table's partitioning storage conditions

13.12.1 Purpose of changing partitioning storage conditions

13.12.2 Facilities used to change partitioning storage conditions

13.12.3 Prerequisites

13.12.4 How to change partitioning storage conditions (in the case of boundary value specification)

13.12.5 Splitting an RDAREA (in the case of boundary value specification)

13.12.6 Combining RDAREAs (in the case of boundary value specification)

13.12.7 How to change partitioning storage conditions (in the case of storage condition specification)

13.12.8 Splitting an RDAREA (in the case of storage condition specification)

13.12.9 Combining RDAREAs (in the case of storage condition specification)

13.12.10 Relationship with other facilities

13.13 Changing a table's partitioning storage conditions

13.13.1 Examples (in the case of boundary value specification)

13.13.2 Examples (in the case of storage condition specification)

13.13.3 Re-registering the data

13.13.4 Reusing RDAREAs

13.13.5 Examples of the database reorganization utility and database load utility

13.13.6 Splitting or combining a table containing a non-partitioning key index

13.13.7 Splitting or combining when an index is incomplete

13.13.8 Checking the number of items of data following splitting or combining

13.13.9 Operation when an error occurs

13.13.10 Handling when referential constraint and check constraint are used

13.14 Changing the hash function

13.14.1 Example 1: Flexible hash partitioning

13.14.2 Example 2: FIX hash partitioning

13.15 Changing a table's partitioning definition

13.15.1 Example 1 (changing from key range partitioning to hash partitioning and changing the partitioning key column)

13.15.2 Example 2 (changing from hash partitioning to key range partitioning)

13.15.3 Example 3 (allocating a different RDAREA each month)

13.16 Migrating data to another table

13.16.1 Example 1: Migrating data to a table with the same table definition

13.16.2 Example 2: Migrating data to a table with a different table definition

13.16.3 Specification examples of column structure information files

13.17 Deleting a table

13.18 Deleting a schema

13.19 Deleting an abstract data type

13.20 Creating a definition SQL from an existing table

13.21 Managing a list (narrowed search)

13.22 Standardizing spaces in table data

13.22.1 Overview of space conversion facility

13.22.2 Setting the space conversion level

13.22.3 Standardizing space characters in a table

13.22.4 Distributed database environment

13.23 Converting the sign portion of the decimal type

13.23.1 Overview of the facility for conversion to a decimal signed normalized number

13.23.2 Normalizing existing data

14. Handling Indexes

14.1 Improving index storage efficiency (index reorganization)

14.1.1 Overview of index reorganization

14.1.2 Example 1: Reorganizing an index

14.1.3 Actions when an error occurs during index reorganization

14.1.4 Example 2: When an RDAREA shortage occurs during index reorganization (execution in a mode other than no-log mode)

14.1.5 Example 3: When an RDAREA shortage occurs during index reorganization (execution in no-log mode)

14.2 Defining an index for a table that contains data

14.3 Deleting an index

14.4 Creating a definition SQL from an existing index

14.5 Reducing the number of index page splits (unbalanced index split)

14.6 Error handling during batch index creation

14.6.1 Example of recovery when reloading (data loading) was performed in the log acquisition mode or the pre-update log acquisition mode

14.6.2 Example of recovery when reloading (data loading) was performed in the no-log mode (when the RDAREA storing the index contains no other tables or indexes)

14.6.3 Example of recovery when reloading (data loading) was executed in the no-log mode (when the RDAREA storing the index contains other tables or indexes)

14.6.4 Example of recovery in the event of an error on the disk that contains the index storage RDAREA

14.7 Delayed batch creation of a plug-in index

14.7.1 Delayed batch creation of a plug-in index

14.7.2 Environment setup

14.7.3 Procedure during UAP execution

14.7.4 Notes

14.7.5 Error handling procedures

15. Handling RDAREAs

15.1 RDAREA space shortage

15.2 Creating an RDAREA (RDAREA addition)

15.2.1 Before adding an RDAREA

15.2.2 Example

15.3 Increasing the size of an RDAREA (RDAREA expansion)

15.3.1 Before expanding an RDAREA

15.3.2 Example

15.4 Increasing the size of an RDAREA or modifying its attributes (RDAREA reinitialization)

15.4.1 Before reinitializing an RDAREA

15.4.2 Example 1 (index is defined)

15.4.3 Example 2 (index is defined)

15.4.4 Example 3 (LOB column is defined)

15.4.5 Example 4 (LOB column is defined)

15.4.6 Example 5 (abstract data type is defined)

15.4.7 Example 6 (abstract data type is defined)

15.4.8 Example 7 (using a UAP, all RDAREAs associated with a table are reinitialized, and data is recovered)

15.4.9 Example 8 (using a UAP, all RDAREAs associated with a table are reinitialized, and data is recovered)

15.4.10 Example 9 (changing the disk layout for RDAREAs)

15.5 Modifying an RDAREA opening trigger attribute (RDAREA modification)

15.5.1 Before changing the RDAREA opening trigger attribute

15.5.2 Example

15.6 Deleting an RDAREA

15.6.1 Before deleting an RDAREA

15.6.2 Example

15.7 RDAREA automatic extension

15.7.1 Automatic extension of an RDAREA

15.7.2 Example

15.7.3 Handling space shortages in HiRDB file system areas

15.7.4 Actions to take when the number of extents reaches the maximum value

15.8 Moving an RDAREA (RDAREA migration)

15.8.1 Before moving RDAREAs

15.8.2 Example 1 (Moving RDAREAs to the back-end server on a new server machine)

15.8.3 Example 2 (Moving RDAREAs to a back-end server in a different unit)

15.8.4 Example 3 (Moving RDAREAs to a different back-end server in the same unit)

15.8.5 Example 4 (Moving RDAREAs containing a row-partitioned table)

15.8.6 Example 5 (Moving inner replica RDAREAs)

15.8.7 Example 6 (Moving RDAREAs containing an abstract data type)

15.9 Re-using used free pages and used free segments

15.9.1 Page and segment status

15.9.2 Reusing used free pages

15.9.3 Reusing used free segments

16. Handling Stored Procedures and Stored Functions

16.1 Before creating (registering) stored procedures or stored functions

16.2 Creating (registering) a stored procedure or stored function

16.3 Re-creating an invalidated stored procedure or stored function

16.4 Deleting a stored procedure or stored function

16.5 Creating a definition SQL from an existing stored procedure

17. Using Java Stored Procedures and Java Stored Functions

17.1 Overview of Java stored procedures and Java stored functions

17.2 System configuration for using Java stored procedures and Java stored functions

17.3 Environment setup

17.4 JAR file operations

17.4.1 When an error occurs in a JAR file

17.4.2 When the server configuration is modified (HiRDB/Parallel Server only)

18. Error Handling Procedures

18.1 HiRDB processing and the HiRDB administrator's action in the event of an error

18.1.1 Actions to be taken by the HiRDB administrator when an error occurs

18.1.2 Information collected by HiRDB when an error occurs

18.1.3 HiRDB processing in the event of an error

18.1.4 Handling of HiRDB process errors

18.1.5 Information inherited during a HiRDB restart

18.1.6 Facility for changing the process-down message when a transaction is cancelled

18.2 When a UAP does not execute correctly

18.3 When operation commands do not execute correctly

18.3.1 Actions to be taken when operation commands will not execute

18.3.2 Actions to be taken when an operation command results in a timeout while waiting for a response

18.4 When HiRDB does not start

18.4.1 When HiRDB does not start normally

18.4.2 When HiRDB does not restart

18.4.3 Actions to be taken in the event of an error in the master directory RDAREA

18.4.4 Actions to be taken in the event of other errors

18.5 When HiRDB does not terminate

18.6 Handling of system log file errors

18.6.1 Actions to be taken in the event of an error in the current file

18.6.2 Actions to be taken when HiRDB Datareplicator is being used

18.6.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file

18.7 Handling of synchronization point dump file errors

18.8 Handling of status file errors

18.8.1 Actions to be taken in the event of an error in the current file

18.8.2 Procedure for starting a HiRDB (unit) while there is an erroneous status file

18.8.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file

18.9 Handling of errors in files other than system files

18.9.1 Errors in the HiRDB system definitions file

18.9.2 Errors in the message log file

18.9.3 Errors in the statistics log file

18.9.4 Errors in the data linkage file (HiRDB Datareplicator)

18.10 When the OS terminates abnormally

18.11 Handling of errors while linked to an OLTP system

18.11.1 Actions to be taken when a communication error occurs while HiRDB is linked to an OLTP system

18.11.2 Actions to be taken when a transaction is placed in FORGETTING status due to an error

18.11.3 Actions to be taken when transactions remain resident due to inactivity of a unit with a front-end server

18.12 Handling of communication errors, CPU errors, and power failures

18.12.1 Handling of communication errors

18.12.2 Handling of CPU errors

18.12.3 Handling of a power failure

18.13 When HiRDB cannot be terminated because a user is still connected

18.13.1 Corrective procedure

18.13.2 Connected user data file and connected user details file

18.14 Actions when there is an undetermined transaction

18.14.1 Forcing determination of uncompleted transactions

18.14.2 Performing transaction determination manually on undetermined transactions

18.15 Handling of reduced activation (HiRDB/Parallel Server only)

18.16 Handling of disk errors

18.17 When a HiRDB (unit) terminates due to a system log file space shortage

18.17.1 Restart procedure

18.17.2 Determining the minimum number of system log files to be added

18.17.3 Creating a file in swappable target status

18.17.4 Creating a HiRDB file system area for system files

18.17.5 Determining the number of system log files to be used as input files during restart

18.17.6 Checking for synchronization point dump validation

18.18 When a utility terminates abnormally during execution of a reorganization with synchronization points set

18.18.1 Overview of actions

18.18.2 Example

18.18.3 Actions to be taken when a utility terminates abnormally before unload data files have been consolidated (HiRDB/Parallel Server only)

18.18.4 Notes

18.19 Actions when page destruction in an RDAREA is detected

18.19.1 Causes of page destruction

18.19.2 Actions to be taken

18.20 Actions to take when an RDAREA I/O error occurs

18.21 Checking the transaction completion type when an error occurs during commit processing (HiRDB/Parallel Server)

18.22 Actions to take when an error occurs while a local buffer is being used to update a shared table (HiRDB/Parallel Server only)

18.23 Actions to take when an error occurs in the system manager unit

18.24 Actions to take when a mismatch occurs between the original and the mirror duplicate

18.25 Recovery of HiRDB directory

18.25.1 When installation directory is available

18.25.2 When installation directory is not available

18.25.3 When a backup is available for the disk on which the HiRDB directory is located

18.26 Handling errors in the HiRDB file system areas

18.26.1 Unmanageable files and unreferenceable areas

18.26.2 Corruption of the area management information (applicable to HiRDB version 07-02 and earlier)

19. Database Recovery Procedures

19.1 Overview of database recovery

19.1.1 Database recovery point

19.1.2 Relationship to the backup acquisition mode

19.1.3 Relationship to the log acquisition mode

19.1.4 Notes on recovery of various types of RDAREAs

19.1.5 For users of 64-bit-mode HiRDB

19.2 Recovering a database to the point at which a backup was made

19.2.1 Example 1: Recovering all RDAREAs

19.2.2 Example 2: Recovering specified RDAREAs

19.2.3 Example 3: When JP1/OmniBack II is used for recovery

19.3 Recovering a database to the most recent synchronization point

19.3.1 Example 1: Recovering all RDAREAs

19.3.2 Example 2: Recovering specified RDAREAs

19.3.3 Example 3: Recovering specified RDAREAs (operation without unloading the system log)

19.3.4 Example 4: When JP1/OmniBack II is used for recovery)

19.4 Database recovery using the differential backup facility

19.4.1 Example 1: Recover to the most recent differential backup acquisition point

19.4.2 Example 2: Recover to the most recent synchronization point

19.4.3 Recovery when a differential backup management file is not available

19.5 Recovery procedure when the backup was not made with the pdcopy command

19.5.1 Example 1: Recovering all RDAREAs to the point at which a backup was made

19.5.2 Example 2: Recovering specified RDAREAs to the point at which a backup was made

19.5.3 Example 3: Recovering all RDAREAs to the most recent synchronization point

19.5.4 Example 4: Recovering specified RDAREAs

19.5.5 Example 5: Recovering the master directory RDAREA only

20. Obtaining Tuning Information

20.1 Collecting tuning information from the statistics log

20.1.1 Tuning information that can be collected from the statistics log

20.1.2 Preparing for collecting tuning information

20.1.3 Collecting tuning information

20.1.4 Shell script for creating unload statistics log files at a specified server machine

20.1.5 When linked to an OLTP system

20.2 Collecting tuning information from the system log

20.3 Using the database condition analysis utility to collect tuning information

21. Tuning

21.1 Tuning global buffer pools

21.1.1 Using the pdbufls command to collect statistical information

21.1.2 Using the statistics analysis utility to collect statistical information

21.2 Tuning deferred write processing

21.3 Tuning the synchronization point processing time when deferred write processing is used

21.3.1 Tuning procedure

21.3.2 How to interpret statistical information about deferred write processing

21.3.3 How to reduce the synchronization point processing time

21.4 Tuning the synchronization point dump interval

21.5 Tuning buffer lengths

21.5.1 Tuning the buffer length for table definition information

21.5.2 Tuning the buffer length for view analysis information

21.5.3 Tuning the buffer length for user privilege information

21.5.4 Tuning the buffer length for SQL objects

21.5.5 Tuning the buffer length for user-defined type information

21.5.6 Tuning the buffer length for routine definition information

21.5.7 Tuning the buffer length for registry information

21.6 Tuning the number of processes

21.6.1 Tuning the maximum number of active processes

21.6.2 Tuning the number of resident processes

21.6.3 Tuning the number of processes in asynchronous READ processing

21.7 Tuning indexes

21.8 Tuning the database

21.9 Tuning SQLs

21.10 Tuning the system's internal processing

22. Using the Security Audit Facility

22.1 Overview of the security audit facility

22.1.1 About the security audit facility

22.1.2 Triggers for collecting audit trails

22.1.3 Examples of audit trail collection

22.1.4 Information collected in an audit trail

22.1.5 Accessing an audit trail

22.1.6 System configuration requirements

22.1.7 Audited events

22.2 Information output to an audit trail file

22.3 Audit trail output patterns

22.3.1 Output patterns during privilege checking

22.3.2 Output patterns at event termination

22.3.3 Relationships among audit trails

22.4 Environment settings

22.4.1 Security audit facility operand specifications

22.4.2 Creation of the HiRDB file system area for the audit trail files

22.4.3 Auditor registration, creation of the RDAREA to store the audit trail table, and creation of the audit trail table

22.4.4 Audit event definition

22.5 Operating procedure

22.5.1 Actions performed by the HiRDB administrator

22.5.2 Actions performed by the auditor

22.6 Operation of audit trail files

22.6.1 Creation of audit trail files

22.6.2 Status of audit trail files

22.6.3 Swapping of audit trail files

22.7 Recording data in the audit trail table

22.7.1 Example 1: Data loading from specified audit trail files

22.7.2 Example 2: Data loading from all audit trail files in the HiRDB file system area

22.7.3 Procedure when an error occurs during data loading

22.8 Audit trail table columns

22.9 Narrowing the audit trails

22.10 Audit trail file error handling

22.11 Linkage with other facilities

22.12 Audit trail record items (during privilege checking)

22.13 Audit trail record items (at event termination)

22.14 Audit trail output destination unit during utility execution (HiRDB/Parallel Server only)

22.15 Notes on version upgrading

23. Using the Connection Security Facility

23.1 Overview of the connection security facility

23.1.1 About the connection security facility

23.1.2 Password character string restrictions

23.1.3 Limit on the number of consecutive certification failures

23.2 Setting password character string restrictions

23.3 Changing a password character string restriction

23.3.1 Special notes on changing password character string restrictions

23.3.2 Procedure for changing a password character string restriction

23.4 Releasing the password-invalid account lock state

23.4.1 Releasing individual users from password-invalid account lock state

23.4.2 Releasing all users from password-invalid account lock state

23.5 Checking for users who will be placed in password-invalid account lock state

23.6 Privilege granting or revocation for users in password-invalid account lock state

23.7 Cancelling the password character string restrictions

23.8 Relationships between password character string restrictions and other facilities

23.8.1 Notes on using a Directory Server linkage facility

23.8.2 Notes on using the security audit facility

23.9 Setting and cancelling the limit on number of consecutive certification failures

23.9.1 Setting a new limit on the number of consecutive certification failures

23.9.2 Cancelling the limit on the number of consecutive certification failures

23.9.3 Changing the limit on the number of consecutive certification failures

23.9.4 Checking the permitted number of consecutive certification failures and the account lock period

23.10 Checking for users in consecutive certification failure account lock state

23.11 Releasing consecutive certification failure account lock state

23.12 Notes on using the connection security facility

23.12.1 Releasing a double lock

23.12.2 Notes on restoring a dictionary RDAREA

24. Using the Directory Server Linkage Facility

24.1 Overview of the Directory Server linkage facility

24.1.1 About the Directory Server linkage facility

24.1.2 Directory servers that can be linked

24.1.3 Capabilities of the Directory Server linkage facility

24.2 System configuration

24.2.1 Software configuration

24.2.2 Example system configurations

24.3 Environment setup

24.3.1 Notes on HiRDB environment setup

24.3.2 Procedure for setting up environment for Directory Server linkage facility

24.3.3 Handling upper-case and lower-case letters specified in user IDs, passwords, and roles

24.4 User privileges setup

24.4.1 DBA privilege setup

24.4.2 Auditor privilege setup

24.4.3 CONNECT privilege setup

24.4.4 Schema definition privilege setup

24.4.5 RDAREA usage privilege setup

24.4.6 Table access privilege setup

24.5 Operating procedures

24.5.1 Adding, modifying, or deleting a user or role

24.5.2 Acquiring table access privileges information

24.5.3 Suspending the Directory Server linkage facility

24.6 Operations in the event of an error

24.7 Creating the HiRDB LDAP Option environment definition file

25. Using the System Switchover Facility

25.1 Overview of the system switchover facility

25.1.1 System switchover facility (standby system switchover facility)

25.1.2 Standby-less system switchover facilities

25.1.3 Application criteria for the system switchover facilities

25.1.4 Cluster software supported by HiRDB

25.1.5 Monitor mode and server mode

25.2 System configuration examples

25.2.1 System configuration examples of a HiRDB/Single Server (standby system switchover)

25.2.2 System configuration examples of a HiRDB/Parallel Server

25.2.3 System configuration examples of standby-less system switchover (1:1)

25.2.4 System configuration examples of standby-less system switchover (effects distributed)

25.3 IP address configuration examples

25.4 Handling of host names depending on whether or not IP addresses are inherited

25.4.1 HiRDB/Single Server

25.4.2 HiRDB/Parallel Server

25.5 HiRDB preparations

25.5.1 Conditions and notes

25.5.2 Preparing a shared disk unit

25.5.3 Creating HiRDB system definitions

25.5.4 Client environment definition specification

25.5.5 Specification examples of host names in HiRDB system definitions and client environment definitions

25.5.6 RDAREA creation

25.5.7 Definition of global buffers (standby-less system switchover (1:1) facility only)

25.5.8 Definition of global buffers (standby-less system switchover (effects distributed) facility only)

25.5.9 Using audit trail files

25.6 HA monitor preparations

25.6.1 sysdef definition statement

25.6.2 server definition statement

25.7 MC/ServiceGuard preparations

25.7.1 Package

25.7.2 Shell script for starting HiRDB

25.7.3 Shell script for terminating HiRDB

25.7.4 Shell script for generating a dummy process (services monitored by MC/ServiceGuard) (monitor mode only)

25.7.5 Package IP address

25.7.6 Example of grouped MC/ServiceGuard and HiRDB configuration

25.8 VERITAS Cluster Server preparations

25.8.1 Groups and resources

25.8.2 HiRDB resource type definition

25.8.3 Agent definition pre-preparation

25.8.4 Agent definition

25.8.5 Environment setup file creation

25.9 Sun Cluster preparations

25.9.1 Cluster startup

25.9.2 Shared disk setup (disk group creation)

25.9.3 Network setup (PNM setup)

25.9.4 Logical host creation

25.9.5 Service creation and registration

25.10 HACMP preparations

25.11 ClusterPerfect preparations

25.11.1 System configurations unable to perform system switchover

25.11.2 Network configuration examples

25.11.3 Scenario preparations

25.11.4 Shells used when setting HiRDB scenarios

25.12 Hitachi HA Toolkit Extension preparations (server mode only)

25.12.1 sysdef definition statement

25.12.2 server definition statement

25.13 Differences in the HiRDB operating procedures

25.13.1 Starting HiRDB (in the server mode)

25.13.2 Starting HiRDB (in the monitor mode)

25.13.3 Terminating HiRDB (in the server mode)

25.13.4 Terminating HiRDB (in the monitor mode)

25.13.5 Monitoring statuses

25.13.6 Handling of statistics log files

25.13.7 Notes on operations

25.13.8 Notes on using the standby-less system switchover facility

25.14 Planned system switchover

25.15 Grouped system switchover

25.16 Actions to be taken by the HiRDB administrator when errors occur

25.17 Operating procedures after system switchover

25.18 Reducing system switchover time (user server hot standby, rapid system switchover facility)

25.18.1 User server hot standby

25.18.2 Rapid system switchover facility

25.18.3 System configuration examples when using the rapid system switchover facility

25.18.4 Checking procedure when activation of standby system takes much time

25.18.5 Notes on using the rapid system switchover facility

25.19 Transaction queuing facility

25.20 System switchover when errors other than server failures occur

25.20.1 A large number of server processes has terminated abnormally

25.20.2 RDAREA I/O error (path error) has occurred

25.21 Actions to take when a stopped unit prevents switching of the system manager unit

25.21.1 Using reduced activation

25.21.2 Specifying the pd_ha_mgr_rerun operand

26. Using the Facility for Monitoring MIB Performance Information

26.1 Overview of the facility for monitoring MIB performance information

26.1.1 About the facility for monitoring MIB performance information

26.1.2 Objectives of the facility for monitoring MIB performance information

26.1.3 MIB definition file

26.1.4 MIB environment definition file

26.2 System configuration

26.3 Environment setup

26.4 MIB definition file

26.5 Server status table (hirServerStatusTable)

26.6 Work table HiRDB file system area table (hirFileSystemTable)

26.7 RDAREA table (hirRdareaStatusTable)

26.8 RDAREA details table (hirRdareaDetStatusTable)

26.9 Global buffer table (hirBufferStatusTable)

26.10 HiRDB file system area (RDAREAs) table (hirRdareaFileTable)

26.11 SYS statistics table (hirStatisInfSysTable)

26.12 Disk usage

27. Using a Distributed Database (applicable to HP-UX and AIX 5L only)

27.1 Overview of a distributed database

27.1.1 Scope of distributed database

27.1.2 Remote database access facility

27.1.3 Character codes environment

27.1.4 Handling of authorization identifiers

27.1.5 Handling of passwords

27.1.6 Notes on establishing connection with another node's HiRDB

27.2 Environment setup for a distributed database

27.2.1 HiRDB environment setup

27.2.2 DF/UX environment setup

27.2.3 DF/UX Extension environment setup

27.3 Distributed database security

27.4 Information output when a communication error occurs (Distributed Server facility only)

Appendixes

A. Q&A

A.1 System log files

A.2 Synchronization point dump files

A.3 Status files

A.4 Errors

A.5 Tables and indexes

A.6 HiRDB startup

A.7 HiRDB termination

A.8 Performance

A.9 Backup

A.10 RDAREA recovery

A.11 Other

B. Operations When Using a DVD-RAM Library Device

C. Information Needed for Troubleshooting

D. Notes on Running HiRDB Around the Clock

D.1 System reconfiguration command (pdchgconf command)

D.2 Specifying HiRDB system definitions

D.3 Making backups

D.4 Reorganizing databases

D.5 Reusing used free pages and free space within pages

D.6 Expanding RDAREAs

D.7 Dynamic updating of global buffers

D.8 Deleting troubleshooting information

D.9 System switchover facility

D.10 Program maintenance facility (upgrade to update version)

D.11 Recovery-unnecessary front-end server (HiRDB/Parallel Server only)

E. Using Performance Improvement Facilities

E.1 BES connection holding facility (HiRDB/Parallel Server only)

Index

[Trademarks]

All Rights Reserved. Copyright (C) 2007, Hitachi, Ltd.

Notices

Relevant program products

List of program products:
For the HP-UX 11.0, HP-UX 11i, or HP-UX 11i V2 (PA-RISC) operating system:

P-1B62-1182 HiRDB/Single Server Version 8 08-00
P-1B62-1382 HiRDB/Parallel Server Version 8 08-00
P-1B62-1582 HiRDB/Single Server Version 8(64) 08-00
P-1B62-1782 HiRDB/Parallel Server Version 8(64) 08-00
P-1B62-1B82 HiRDB/Run Time Version 8 08-00
P-1B62-1C82 HiRDB/Developer's Kit Version 8 08-00
P-1B62-1D82 HiRDB/Run Time Version 8(64) 08-00
P-1B62-1E82 HiRDB/Developer's Kit Version 8(64) 08-00
P-F1B62-11823 HiRDB Staticizer Option Version 8 08-00
P-F1B62-11825 HiRDB Non Recover Front End Server Version 8 08-00
P-F1B62-11826 HiRDB Advanced High Availability Version 8 08-00
P-F1B62-11827 HiRDB Advanced Partitioning Option Version 8 08-00

For the HP-UX 11i V2 (IPF) operating system:

P-1J62-1582 HiRDB/Single Server Version 8(64) 08-00
P-1J62-1782 HiRDB/Parallel Server Version 8(64) 08-00
P-1J62-1D82 HiRDB/Run Time Version 8(64) 08-00
P-1J62-1E82 HiRDB/Developer's Kit Version 8(64) 08-00
P-F1J62-11823 HiRDB Staticizer Option Version 8 08-00
P-F1J62-11825 HiRDB Non Recover Front End Server Version 8 08-00
P-F1J62-11826 HiRDB Advanced High Availability Version 8 08-00
P-F1J62-11827 HiRDB Advanced Partitioning Option Version 8 08-00

For the Solaris 8, 9 or 10 operating system:

P-9D62-1182 HiRDB/Single Server Version 8 08-00
P-9D62-1382 HiRDB/Parallel Server Version 8 08-00
P-9D62-1582 HiRDB/Single Server Version 8(64) 08-00
P-9D62-1782 HiRDB/Parallel Server Version 8(64) 08-00
P-9D62-1B82 HiRDB/Run Time Version 8 08-00
P-9D62-1C82 HiRDB/Developer's Kit Version 8 08-00
P-9D62-1D82 HiRDB/Run Time Version 8(64) 08-00
P-9D62-1E82 HiRDB/Developer's Kit Version 8(64) 08-00
P-F9D62-11823 HiRDB Staticizer Option Version 8 08-00
P-F9D62-11825 HiRDB Non Recover Front End Server Version 8 08-00
P-F9D62-11826 HiRDB Advanced High Availability Version 8 08-00
P-F9D62-11827 HiRDB Advanced Partitioning Option Version 8 08-00

For the AIX(R) 5L V5.1, V5.2 or V5.3 operating system:

P-1M62-1182 HiRDB/Single Server Version 8 08-00
P-1M62-1382 HiRDB/Parallel Server Version 8 08-00
P-1M62-1582 HiRDB/Single Server Version 8(64) 08-00
P-1M62-1782 HiRDB/Parallel Server Version 8(64) 08-00
P-1M62-1B82 HiRDB/Run Time Version 8 08-00
P-1M62-1C82 HiRDB/Developer's Kit Version 8 08-00
P-1M62-1D82 HiRDB/Run Time Version 8(64) 08-00
P-1M62-1E82 HiRDB/Developer's Kit Version 8(64) 08-00
P-F1M62-11823 HiRDB Staticizer Option Version 8 08-00
P-F1M62-11825 HiRDB Non Recover Front End Server Version 8 08-00
P-F1M62-11826 HiRDB Advanced High Availability Version 8 08-00
P-F1M62-11827 HiRDB Advanced Partitioning Option Version 8 08-00

For the Red Hat Linux 7.1, Red Hat Linux 7.2, Red Hat Enterprise Linux AS 2.1, Red Hat Enterprise Linux AS 3 (x86), Red Hat Enterprise Linux ES 3 (x86), Red Hat Enterprise Linux AS 4 (x86), Red Hat Enterprise Linux ES 4 (x86), Red Hat Enterprise Linux AS 3 (AMD64 & Intel EM64T),* Red Hat Enterprise Linux AS 4 (AMD64 & Intel EM64T), or Red Hat Enterprise Linux ES 4 (AMD64 & Intel EM64T) operating system:

P-9S62-1182 HiRDB/Single Server Version 8 08-00
P-9S62-1382 HiRDB/Parallel Server Version 8 08-00
P-9S62-1B82 HiRDB/Run Time Version 8 08-00
P-9S62-1C82 HiRDB/Developer's Kit Version 8 08-00
P-F9S62-11823 HiRDB Staticizer Option Version 8 08-00
P-F9S62-11825 HiRDB Non Recover Front End Server Version 8 08-00
P-F9S62-11826 HiRDB Advanced High Availability Version 8 08-00
P-F9S62-11827 HiRDB Advanced Partitioning Option Version 8 08-00

* Only operating systems that run on the Intel EM64T are supported.

For the Red Hat Enterprise Linux AS 3 (AMD64 & Intel EM64T),* Red Hat Enterprise Linux AS 4 (AMD64 & Intel EM64T), or Red Hat Enterprise Linux ES 4 (AMD64 & Intel EM64T) operating system:

P-9W62-1182 HiRDB/Single Server Version 8 08-00
P-9W62-1382 HiRDB/Parallel Server Version 8 08-00
P-9W62-1B82 HiRDB/Run Time Version 8 08-00
P-9W62-1C82 HiRDB/Developer's Kit Version 8 08-00

* Only operating systems that run on the Intel EM64T are supported.

For the Red Hat Enterprise Linux AS 3 (IPF) or Red Hat Enterprise Linux AS 4 (IPF) operating system:

P-9V62-1182 HiRDB/Single Server Version 8 08-00
P-9V62-1382 HiRDB/Parallel Server Version 8 08-00
P-9V62-1B82 HiRDB/Run Time Version 8 08-00
P-9V62-1C82 HiRDB/Developer's Kit Version 8 08-00
P-F9V62-11823 HiRDB Staticizer Option Version 8 08-00
P-F9V62-11825 HiRDB Non Recover Front End Server Version 8 08-00
P-F9V62-11826 HiRDB Advanced High Availability Version 8 08-00
P-F9V62-11827 HiRDB Advanced Partitioning Option Version 8 08-00

This edition of the manual is released for the preceding program products, which have been developed under a quality management system that has been certified to comply with ISO9001 and TickIT. This manual may also apply to other program products; for details, see Software Information or Before Installing.

Trademarks

ActiveX is a trademark of Microsoft Corp. in the U.S. and other countries.
AIX is a registered trademark of the International Business Machines Corp. in the U.S.
CORBA is a registered trademark of Object Management Group, Inc. in the United States.
DataStage, MetaBroker, MetaStage and QualityStage are trademarks of International Business Machines Corporation in the United States, other countries, or both.
DB2 is a registered trademark of the International Business Machines Corp. in the U.S.
HACMP/6000 is a trademark of the International Business Machines Corp. in the U.S.
HP-UX is a product name of Hewlett-Packard Company.
IBM is a registered trademark of the International Business Machines Corp. in the U.S.
Itanium is a registered trademark of Intel Corporation or its subsidiaries in the United States and other countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
JBuilder is a trademark of Borland Software Corporation in the United States and other countries.
Linux is a registered trademark of Linus Torvalds.
Lotus, 1-2-3 are registered trademarks of International Business Machines Corporation in the United States, other countries, or both.
Microsoft Access is a registered trademark of Microsoft Corporation in the U.S. and other countries.
Microsoft Excel is a product name of Microsoft Corp.
Microsoft is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Motif is a registered trademark of the Open Software Foundation, Inc.
MS-DOS is a registered trademark of Microsoft Corp. in the U.S. and other countries.
ODBC is Microsoft's strategic interface for accessing databases.
OLE is the name of a software product developed by Microsoft Corporation and the acronym for Object Linking and Embedding.
ORACLE is a registered trademark of Oracle Corporation.
Oracle8i is a trademark of ORACLE Corporation.
Oracle9i is a trademark of ORACLE Corporation.
Oracle 10g is a trademark of ORACLE Corporation.
OS/390 is a trademark of the International Business Machines Corp. in the U.S.
POSIX stands for Portable Operating System Interface for Computer Environment, which is a set of standard specifications published by the Institute of Electrical and Electronics Engineers, Inc.
RISC System/6000 is a registered trademark of the International Business Machines Corp. in the U.S.
Solaris is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.
Sun is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.
Sun Microsystems is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.
The right to use the trademark DCE in Japan is sub-licensed from OSF.
UNIFY2000 is a product name of Unify Corp.
UNIX is a registered trademark of The Open Group in the United States and other countries.
VERITAS is a trademark or registered trademark of Symantec Corporation in the U.S. and other countries.
Visual Basic is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Visual C++ is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Visual Studio is a registered trademark of Microsoft Corp. in the U.S. and other countries.
WebLogic is a registered trademark of BEA Systems, Inc.
Windows is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Windows NT is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Windows Server is a registered trademark of Microsoft Corp. in the U.S. and other countries.
X/Open is a registered trademark of X/Open Company Limited in the U.K. and other countries.
X Window System is a trademark of X Consortium, Inc.
The following program products include material copyrighted by Sun Microsystems, Inc.: P-9D62-1182, P-9D62-1382, P-9D62-1582, P-9D62-1782, P-9D62-1B82, P-9D62-1C82, P-9D62-1D82, P-9D62-1E82, P-F9D62-11823, P-F9D62-11825, P-F9D62-11826, and P-F9D62-11827.
The following program products include material copyrighted by UNIX System Laboratories, Inc.: P-9D62-1182, P-9D62-1382, P-9D62-1582, P-9D62-1782, P-9D62-1B82, P-9D62-1C82, P-9D62-1D82, P-9D62-1E82, P-F9D62-11823, P-F9D62-11825, P-F9D62-11826, and P-F9D62-11827.
Other product and company names mentioned in this document may be the trademarks of their respective owners. Throughout this document Hitachi has attempted to distinguish trademarks from descriptive terms by writing the name with the capitalization used by the manufacturer, or by writing the name with initial capital letters. Hitachi cannot attest to the accuracy of this information. Use of a trademark in this document should not be regarded as affecting the validity of the trademark.

Restrictions

Information in this document is subject to change without notice and does not represent a commitment on the part of Hitachi. The software described in this manual is furnished according to a license agreement with Hitachi. The license agreement contains all of the terms and conditions governing your use of the software and documentation, including all warranty rights, limitations of liability, and disclaimers of warranty.
Material contained in this document may describe Hitachi products not available or features not available in your country.
No part of this material may be reproduced in any form or by any means without permission in writing from the publisher.
Printed in Japan.

Edition history

Edition 1 (3000-6-354(E)): March 2007

Copyright

All Rights Reserved. Copyright (C) 2007, Hitachi, Ltd.

Preface

This manual describes the operating procedures for the HiRDB Version 8 scalable database server system.

Intended readers

This manual is intended for users who will be constructing or operating HiRDB Version 8 ("HiRDB") relational database systems.

It is assumed that readers of this manual have the following:

A basic knowledge of managing UNIX or Linux systems

A basic knowledge of SQL

This manual is based on the HiRDB Version 8 Description, which should be read before reading this manual.

Organization of this manual

This manual is organized as follows:

Chapter 1. HiRDB Startup and Termination

Explains the procedures for starting and terminating HiRDB, as well as the procedures for starting and terminating units and servers.

Chapter 2. Security Definition

Explains the HiRDB-provided security features and their operating procedures.

Chapter 3. Handling System Log Files

Explains the handling of system log files.

Chapter 4. Handling Synchronization Point Dump Files

Explains the handling of synchronization point dump files.

Chapter 5. Handling Status Files

Explains the handling of status files.

Chapter 6. Backup Procedures

Explains the procedures for making backups.

Chapter 7. Operation Without Acquiring a Database Update Log

Explains the procedures for executing a UAP or utility in the following modes:

Pre-update log acquisition mode

No-log mode

Chapter 8. Obtaining the System Operating Environment (Monitoring the System Status)

Explains how to obtain information about the system operating environment by monitoring the system status.

Chapter 9. Modifying the System Operating Environment

Explains how to modify the HiRDB system environment definitions.

Chapter 10. Handling HiRDB File System Areas

Explains how to create and delete HiRDB file system areas, obtain backups, and how to restore HiRDB file system areas.

Chapter 11. Modifying the System Configuration

Explains how to modify the unit or server configuration of a HiRDB/Parallel Server; also explains the procedures for migrating from a HiRDB/Single Server to a HiRDB/Parallel Server.

Chapter 12. Migrating Resources Between Systems

Explains how to migrate tables and stored procedures to another HiRDB system.

Chapter 13. Handling Tables

Explains the procedures for reorganizing tables, modifying table definitions, deleting tables, deleting abstract data types, and managing lists, as well as the space conversion facility and the facility for conversion to a decimal signed normalized number.

Chapter 14. Handling Indexes

Explains the procedures for reorganizing and deleting indexes, as well as unbalanced index splitting and delayed batch creation of plug-in indexes.

Chapter 15. Handling RDAREAs

Explains the procedures for adding, deleting, expanding, reinitializing, and automatically increasing RDAREAs, and how to modify the RDAREA opening trigger.

Chapter 16. Handling Stored Procedures and Stored Functions

Explains the procedures for registering stored procedures and stored functions, and the handling of stored procedures and stored functions when they are no longer valid.

Chapter 17. Using Java Stored Procedures and Java Stored Functions

Explains the environment setup and operating procedures for using Java stored procedures and Java stored functions.

Chapter 18. Error Handling Procedures

Explains the handling of errors.

Chapter 19. Database Recovery Procedures

Explains the procedures for recovering a database in the event that it is damaged by an error.

Chapter 20. Obtaining Tuning Information

Explains the procedures for obtaining tuning information.

Chapter 21. Tuning

Explains the tuning procedures.

Chapter 22. Using the Security Audit Facility

Explains the environment setup and operating procedures for the security audit facility.

Chapter 23. Using the Connection Security Facility

Explains how to use the connection security facility, which is designed to enhance the security of HiRDB systems.

Chapter 24. Using the Directory Server Linkage Facility

Explains the environment setup and operating procedures for the Directory Server linkage facility.

Chapter 25. Using the System Switchover Facility

Explains the environment setup and operating procedures for the system switchover facility.

Chapter 26. Using the Facility for Monitoring MIB Performance Information

Explains how to use the facility for monitoring MIB performance information, which uses MIB to collect HiRDB operation information.

Chapter 27. Using a Distributed Database (applicable to HP-UX and AIX 5L only)

Explains the environment setup and operating procedures for distributed databases.

Appendix A. Q & A

Provides in Q&A format the answers to frequently asked questions.

Appendix B. Operations When Using a DVD-RAM Library Device

Explains the procedures for using a DVD-RAM library unit as a storage device.

Appendix C. Information Needed for Troubleshooting

Explains the information needed to use problem-solving support or Q&A support services.

Appendix D. Notes on Running HiRDB Around the Clock

Explains the procedures for and provides notes about running HiRDB continuously around the clock.

Appendix E. Using Performance Improvement Facilities

Explains facilities designed to enhance system performance and how to use them.

Related publications

This manual is related to the following manuals, which should be read as required.

HiRDB (for UNIX)

For UNIX Systems HiRDB Version 8 Description (3000-6-351(E))

For UNIX Systems HiRDB Version 8 Installation and Design Guide (3000-6-352(E))

For UNIX Systems HiRDB Version 8 System Definition (3000-6-353(E))

For UNIX Systems HiRDB Version 8 Command Reference (3000-6-355(E))

HiRDB Staticizer Option Version 7 Description and User's Guide (3000-6-282(E))

For UNIX Systems HiRDB Version 8 Disaster Recovery System Configuration and Operation Guide (3000-6-364)*

HiRDB (for Windows)

For Windows Systems HiRDB Version 8 Description (3020-6-351(E))

For Windows Systems HiRDB Version 8 Installation and Design Guide (3020-6-352(E))

For Windows Systems HiRDB Version 8 System Definition (3020-6-353(E))

For Windows Systems HiRDB Version 8 System Operation Guide (3020-6-354(E))

For Windows Systems HiRDB Version 8 Command Reference (3020-6-355(E))

HiRDB (for both Windows and UNIX)

HiRDB Version 8 UAP Development Guide (3020-6-356(E))

HiRDB Version 8 SQL Reference (3020-6-357(E))

HiRDB Version 8 Messages (3020-6-358(E))

HiRDB Datareplicator Version 8 Description, User's Guide and Operator's Guide (3020-6-360(E))

HiRDB Dataextractor Version 8 Description, User's Guide and Operator's Guide (3020-6-362(E))

* This manual has been published in Japanese only; it is not available in English.

You must use the UNIX or the Windows manuals, as appropriate to the platform you are using.

Others

HiRDB External Data Access Version 7 Description and User's Guide (3000-6-284(E))

Distributed Database System DF/UX (3000-3-248(E))

JP1 Version 6 JP1/VERITAS NetBackup v4.5 Agent for HiRDB License Description and User's Guide (3020-3-D79(E))

HiCommand Tuning Manager - Agent for RAID (3020-3-E92(E))

HiCommand Tuning Manager - Agent for RAID Map (3020-3-E93(E))

For UNIX Systems Job Management Partner 1/Performance Management - Agent Option for Platform Description, User's Guide and Reference (3020-3-K65(E))

Job Management Partner 1/Performance Management/SNMP System Observer for Extended Resource Management (3020-3-F70(E))

Job Management Partner 1/Consolidated Management 2/Extensible SNMP Agent (3020-3-F92(E))

Organization of HiRDB manuals

The HiRDB manuals are organized as shown below. For the most efficient use of these manuals, it is suggested that they be read in the order they are shown, going from left to right.

Conventions: Abbreviations

Unless otherwise required, this manual uses the following abbreviations for product and other names.

Name of product or other entity
Representation

HiRDB/Single Server Version 8
HiRDB/Single Server
HiRDB or HiRDB Server

HiRDB/Single Server Version 8(64)

HiRDB/Parallel Server Version 8
HiRDB/Parallel Server

HiRDB/Parallel Server Version 8(64)

HiRDB/Developer's Kit Version 8
HiRDB/Developer's Kit
HiRDB Client

HiRDB/Developer's Kit Version 8(64)

HiRDB/Run Time Version 8
HiRDB/Run Time

HiRDB/Run Time Version 8(64)

HiRDB Datareplicator Version 8
HiRDB Datareplicator

HiRDB Dataextractor Version 8
HiRDB Dataextractor

HiRDB Text Search Plug-in Version 7
HiRDB Text Search Plug-in

HiRDB Spatial Search Plug-in Version 3
HiRDB Spatial Search Plug-in

HiRDB Staticizer Option Version 8
HiRDB Staticizer Option

HiRDB LDAP Option Version 8
HiRDB LDAP Option

HiRDB Advanced Partitioning Option Version 8
HiRDB Advanced Partitioning Option

HiRDB Advanced High Availability Version 8
HiRDB Advanced High Availability

HiRDB Non Recover Front End Server Version 8
HiRDB Non Recover FES

HiRDB Disaster Recovery Light Edition Version 8
HiRDB Disaster Recovery Light Edition

HiRDB External Data Access Version 8
HiRDB External Data Access

HiRDB External Data Access Adapter Version 8
HiRDB External Data Access Adapter

HiRDB Adapter for XML - Standard Edition
HiRDB Adapter for XML

HiRDB Adapter for XML - Enterprise Edition

HiRDB Control Manager
HiRDB CM

HiRDB Control Manager Agent
HiRDB CM Agent

Hitachi TrueCopy
TrueCopy

Hitachi TrueCopy basic

TrueCopy

TrueCopy remote replicator

JP1/Automatic Job Management System 2
JP1/AJS2

JP1/Automatic Job Management System 2 - Scenario Operation
JP1/AJS2-SO

JP1/Cm2/Extensible SNMP Agent
JP1/ESA

JP1/Cm2/Extensible SNMP Agent for Mib Runtime

JP1/Cm2/Network Node Manager
JP1/NNM

JP1/Integrated Management - Manager
JP1/Integrated Management or JP1/IM

JP1/Integrated Management - View

JP1/Magnetic Tape Access
EasyMT

EasyMT

JP1/Magnetic Tape Library
MTguide

JP1/NETM/DM
JP1/NETM/DM

JP1/NETM/DM Manager

JP1/Performance Management
JP1/PFM

JP1/Performance Management Agent for HiRDB
JP1/PFM-Agent for HiRDB

JP1/Performance Management - Agent for Platform
JP1/PFM-Agent for Platform

JP1/Performance Management/SNMP System Observer
JP1/SSO

JP1/VERITAS NetBackup BS v4.5
NetBackup

JP1/VERITAS NetBackup v4.5

JP1/VERITAS NetBackup BS V4.5 Agent for HiRDB License
JP1/VERITAS NetBackup Agent for HiRDB License

JP1/VERITAS NetBackup V4.5 Agent for HiRDB License

JP1/VERITAS NetBackup 5 Agent for HiRDB License

OpenTP1/Server Base Enterprise Option
TP1/EE

Virtual-storage Operating System 3/Forefront System Product
VOS3/FS
VOS3

Virtual-storage Operating System 3/Leading System Product
VOS3/LS

Extensible Data Manager/Base Extended Version 2
XDM basic program XDM/BASE E2
XDM/BASE E2

XDM/Data Communication and Control Manager 3
XDM Data communication control XDM/DCCM3
XDM/DCCM3

XDM/Relational Database XDM/RD
XDM/RD
XDM/RD

XDM/Relational Database Extended Version 2
XDM/RD E2
XDM/RD E2

VOS3 Database Connection Server
DB Connection Server

DB2 Universal Database for OS/390 Version 6
DB2

DNCWARE ClusterPerfect (Linux Version)
ClusterPerfect

Microsoft(R) Excel
Microsoft Excel or Excel

Microsoft(R) Visual C++(R)
Visual C++ or C++

Oracle 8i
ORACLE

Oracle 9i

Oracle 10g

Sun JavaTM System Directory Server
Sun Java System Directory Server or Directory Server

HP-UX 11i V2 (IPF)
HP-UX or HP-UX (IPF)

Red Hat Linux
Linux

Red Hat Enterprise Linux

Red Hat Enterprise Linux AS 3 (IPF)
Linux (IPF)
Linux

Red Hat Enterprise Linux AS 4 (IPF)

Red Hat Enterprise Linux AS 3(AMD64 & Intel EM64T)
Linux (EM64T)

Red Hat Enterprise Linux AS 4(AMD64 & Intel EM64T)

Red Hat Enterprise Linux ES 4(AMD64 & Intel EM64T)

turbolinux 7 Server for AP8000
Linux for AP8000

Microsoft(R) Windows NT(R) Workstation Operating System Version 4.0
Windows NT

Microsoft(R) Windows NT(R) Server Network Operating System Version 4.0

Microsoft(R) Windows(R) 2000 Professional Operating System
Windows 2000

Microsoft(R) Windows(R) 2000 Server Operating System

Microsoft(R) Windows(R) 2000 Datacenter Server Operating System

Microsoft(R) Windows(R) 2000 Advanced Server Operating System
Windows 2000 or Windows 2000 Advanced Server

Microsoft(R) Windows ServerTM 2003, Standard Edition
Windows Server 2003

Microsoft(R) Windows ServerTM 2003, Enterprise Edition

Microsoft(R) Windows ServerTM 2003 R2, Standard Edition
Windows Server 2003 R2 or Windows Server 2003

Microsoft(R) Windows ServerTM 2003 R2, Enterprise Edition

64 bit Version Microsoft(R) Windows ServerTM 2003, Enterprise Edition (IPF)
Windows Server 2003 (IPF) or Windows Server 2003

Microsoft(R) Windows ServerTM 2003, Standard x64 Edition
Windows Server 2003 or Windows Server 2003 x64 Editions
Windows (x64)

Microsoft(R) Windows ServerTM 2003, Enterprise x64 Edition

Microsoft(R) Windows ServerTM 2003 R2, Standard x64 Edition
Windows Server 2003, Windows Server 2003 R2 or Windows Server 2003 x64 Editions

Microsoft(R) Windows ServerTM 2003 R2, Enterprise x64 Edition

Microsoft(R) Windows(R) XP Professional x64 Edition
Windows XP or Windows XP x64 Edition

Microsoft(R) Windows(R) XP Professional Operating System
Windows XP Professional
Windows XP

Microsoft(R) Windows(R) XP Home Edition Operating System
Windows XP Home Edition

Single server
SDS

System manager
MGR

Front-end server
FES

Dictionary server
DS

Back-end server
BES

Windows 2000, Windows XP, and Windows Server 2003 may be referred to collectively as Windows.

The HiRDB directory path is represented as $PDDIR.

The hosts file means the hosts file stipulated by TCP/IP (including the /etc/hosts file).

This manual also uses the following abbreviations:

Abbreviation | Full name or meaning
ACK | Acknowledgement
ADM | Adaptable Data Manager
ADO | ActiveX Data Objects
ADT | Abstract Data Type
AP | Application Program
API | Application Programming Interface
ASN.1 | Abstract Syntax Notation One
BES | Back End Server
BLOB | Binary Large Object
BOM | Byte Order Mark
CD-ROM | Compact Disc - Read Only Memory
CGI | Common Gateway Interface
CLOB | Character Large Object
CMT | Cassette Magnetic Tape
COBOL | Common Business Oriented Language
CORBA(R) | Common ORB Architecture
CPU | Central Processing Unit
CSV | Comma Separated Values
DAO | Data Access Object
DAT | Digital Audio Taperecorder
DB | Database
DBM | Database Module
DBMS | Database Management System
DDL | Data Definition Language
DF for Windows NT | Distributing Facility for Windows NT
DF/UX | Distributing Facility/for UNIX
DIC | Dictionary Server
DLT | Digital Linear Tape
DML | Data Manipulate Language
DNS | Domain Name System
DOM | Document Object Model
DS | Dictionary Server
DTD | Document Type Definition
DTP | Distributed Transaction Processing
DWH | Data Warehouse
EUC | Extended UNIX Code
EX | Exclusive
FAT | File Allocation Table
FD | Floppy Disk
FES | Front End Server
FQDN | Fully Qualified Domain Name
FTP | File Transfer Protocol
GUI | Graphical User Interface
HBA | Host Bus Adapter
HD | Hard Disk
HTML | Hyper Text Markup Language
ID | Identification number
IP | Internet Protocol
IPF | Itanium(R) Processor Family
JAR | Java Archive File
Java VM | Java Virtual Machine
JDBC | Java Database Connectivity
JDK | Java Developer's Kit
JFS | Journaled File System
JFS2 | Enhanced Journaled File System
JIS | Japanese Industrial Standard code
JP1 | Job Management Partner 1
JRE | Java Runtime Environment
JTA | Java Transaction API
JTS | Java Transaction Service
KEIS | Kanji processing Extended Information System
LAN | Local Area Network
LDAP | Lightweight Directory Access Protocol
LIP | loop initialization process
LOB | Large Object
LRU | Least Recently Used
LTO | Linear Tape-Open
LU | Logical Unit
LUN | Logical Unit Number
LVM | Logical Volume Manager
MGR | System Manager
MIB | Management Information Base
MRCF | Multiple RAID Coupling Feature
MSCS | Microsoft Cluster Server
NAFO | Network Adapter Fail Over
NAPT | Network Address Port Translation
NAT | Network Address Translation
NIC | Network Interface Card
NIS | Network Information Service
NTFS | New Technology File System
ODBC | Open Database Connectivity
OLAP | Online Analytical Processing
OLE | Object Linking and Embedding
OLTP | On-Line Transaction Processing
OOCOBOL | Object Oriented COBOL
ORB | Object Request Broker
OS | Operating System
OSI | Open Systems Interconnection
OTS | Object Transaction Service
PC | Personal Computer
PDM II E2 | Practical Data Manager II Extended Version 2
PIC | Plug-in Code
PNM | Public Network Management
POSIX | Portable Operating System Interface for UNIX
PP | Program Product
PR | Protected Retrieve
PU | Protected Update
RAID | Redundant Arrays of Inexpensive Disk
RD | Relational Database
RDB | Relational Database
RDB1 | Relational Database Manager 1
RDB1 E2 | Relational Database Manager 1 Extended Version 2
RDO | Remote Data Objects
RiSe | Real time SAN replication
RM | Resource Manager
RMM | Resource Manager Monitor
RPC | Remote Procedure Call
SAX | Simple API for XML
SDS | Single Database Server
SGML | Standard Generalized Markup Language
SJIS | Shift JIS
SNMP | Simple Network Management Protocol
SQL | Structured Query Language
SQL/K | Structured Query Language/VOS K
SR | Shared Retrieve
SU | Shared Update
TCP/IP | Transmission Control Protocol/Internet Protocol
TM | Transaction Manager
TMS-4V/SP | Transaction Management System - 4V/System Product
UAP | User Application Program
UOC | User Own Coding
VOS K | Virtual-storage Operating System Kindness
VOS1 | Virtual-storage Operating System 1
VOS3 | Virtual-storage Operating System 3
WS | Workstation
WWW | World Wide Web
XDM/BASE E2 | Extensible Data Manager/Base Extended Version 2
XDM/DF | Extensible Data Manager/Distributing Facility
XDM/DS | Extensible Data Manager/Data Spreader
XDM/RD E2 | Extensible Data Manager/Relational Database Extended Version 2
XDM/SD E2 | Extensible Data Manager/Structured Database Extended Version 2
XDM/XT | Extensible Data Manager/Data Extract
XFIT | Extended File Transmission program
XML | Extensible Markup Language

Log representations

The OS log is referred to generically as syslogfile. syslogfile is the log output destination specified in /etc/syslog.conf. Typically, the following files are specified as syslogfile.

OS | File
HP-UX | /var/adm/syslog/syslog.log
Solaris | /var/adm/messages or /var/log/syslog
AIX 5L | /var/adm/ras/syslog
Linux | /var/log/messages

Conventions: Diagrams

This manual uses the following conventions in diagrams:

Conventions: Fonts and symbols

Font and symbol conventions are classified as:

General font conventions

Conventions in syntax explanations

These conventions are described below.

General font conventions

The following table lists the general font conventions:

Font
Convention

Bold
Bold type indicates text on a window, other than the window title. Such text includes menus, menu options, buttons, radio box options, or explanatory labels. For example, bold is used in sentences such as the following:

From the File menu, choose Open.

Click the Cancel button.

In the Enter name entry box, type your name.

Italics
Italics are used to indicate a placeholder for some actual text provided by the user or system. Italics are also used for emphasis. For example:

Write the command as follows:
copy source-file target-file

Do not delete the configuration file.

Code font
A code font indicates text that the user enters without change, or text (such as messages) output by the system. For example:

At the prompt, enter dir.

Use the send command to send mail.

The following message is displayed:
The password is incorrect.

Examples of coding and messages appear as follows (although there may be some exceptions, such as when coding is included in a diagram):

MakeDatabase
...
StoreDatabase temp DB32

In examples of coding, an ellipsis (...) indicates that one or more lines of coding are not shown for purposes of brevity.

Conventions in syntax explanations

Syntax definitions appear as follows:

StoreDatabase [temp|perm] (database-name ...)

The following table lists the conventions used in syntax explanations. The syntactical characters described below are used to provide a clear explanation of code syntax; you do not actually enter these characters.

Example font or symbol
Convention

StoreDatabase
Code-font characters must be entered exactly as shown.

database-name
This font style marks a placeholder that indicates where appropriate characters are to be entered in an actual command.

SD
Bold code-font characters indicate the abbreviation for a command.

perm
Underlined characters indicate the default value.

[ ]
Square brackets enclose an item or set of items whose specification is optional.
Example: pdbuffer [-p]
This example indicates that you can specify either pdbuffer or pdbuffer -p.

|
Only one of the options separated by a vertical bar can be specified at the same time.
Example: pdlogadfg -d sys | spd
This example indicates that you can specify either sys or spd for the -d option.

...
An ellipsis (...) indicates that the item or items enclosed in ( ) or [ ] immediately preceding the ellipsis may be specified as many times as necessary.
Example: pdbuffer -r RDAREA-name [,RDAREA-name] ...
This example indicates that following -r, you can specify RDAREA-name as many times as necessary.

()
Parentheses indicate the range of items to which the vertical bar (|) or ellipsis (...) is applicable.

{ }
A single pair of curly brackets encloses multiple items, one of which you must specify.
Example: pdbuffer [{-r RDAREA-name |
-i authorization-identifier.index-identifier | -o}]
This example indicates that you must specify one of the three options enclosed by the curly braces: -r RDAREA-name, -i authorization-identifier.index-identifier, or -o.

{{ }}
A double pair of curly brackets encloses multiple items, all of which you can specify multiple times as a unit.
Example: {{pdbuffer -a option-name}}
This example indicates that you can specify the above multiple times as follows:
pdbuffer -a option-name
pdbuffer -a option-name

~
A swung dash precedes the attributes of a user-specified value.

<< >>
A double pair of angle brackets encloses the default value assumed by the system when the specification is omitted.

< >
A single pair of angle brackets encloses the syntax element notation for a user-specified value.

(( ))
A double pair of parentheses encloses the permitted range of values that can be specified.

Syntactical element symbols

The following syntactical element symbols are used in this manual:

Syntactical element symbol | Meaning
<alphabetics> | The alphabetic characters (A-Z and a-z) and the underline (_)
<alphabetics and special characters> | The alphabetic characters (A-Z and a-z) and the special characters #, @, and \
<alphanumerics> | Alphabetics and the numeric digits (0-9)
<alphanumerics and special characters> | Alphabetics, special characters, and numeric digits
<unsigned integer> | Numeric value
<hexadecimal> | Numeric digits and A-F (or a-f)
<identifier>¹ | Alphanumeric character string beginning with an alphabetic character
<symbolic name> | Alphanumeric character string beginning with an alphabetic character or a special character
<character string> | Any string of characters
<path name>² | Includes symbolic names, forward slashes (/), and periods (.).

Note

All alphabetic characters must be single-byte characters. The syntactical element symbols are case sensitive.

¹ An RDAREA name is an alphanumeric character string beginning with an alphabetic character or special character, and can include alphanumeric characters, underscores (_), and spaces. If an RDAREA name includes a space, the entire name must be enclosed in double quotation marks (").

A host name is a character string that can include alphabetic characters (A to Z, a to z), numeric characters, periods (.), hyphens (-), and underscores (_). A host name can begin with a numeric character.

² Path names depend on the OS being used. Do not use a backslash (\) in HiRDB file system area names.

Notations used in formulas

The following notations are used in computational expressions:

Symbol
Meaning

Round up the result to the next integer.
Example: The result of 34 3 will be 12.

Discard digits following the decimal point.
Example: The result of 34 3 will be 11.

MAX
Select the largest value as the result.
Example: The result of MAX(3 6, 4 + 7) will be18.

MIN
Select the smallest value as the result.
Example: The result of MIN(3 6, 4 + 7) will be 11.

Conventions: KB, MB, GB, and TB

This manual uses the following conventions:

1 KB (kilobyte) is 1,024 bytes.

1 MB (megabyte) is 1,024² bytes.

1 GB (gigabyte) is 1,024³ bytes.

1 TB (terabyte) is 1,024⁴ bytes.

Conventions: Version numbers

The version numbers of Hitachi program products are usually written as two sets of two digits each, separated by a hyphen. For example:

Version 1.00 (or 1.0) is written as 01-00.

Version 2.05 is written as 02-05.

Version 2.50 (or 2.5) is written as 02-50.

Version 12.25 is written as 12-25.

The version number might be shown on the spine of a manual as Ver. 2.00, but the same version number would be written in the program as 02-00.

Important notes on this manual

The following facilities are explained, but they are not supported:

Distributed database facility

Server mode system switchover facility

User server hot standby

Rapid system switchover facility

Standby-less system switchover (1:1) facility

Standby-less system switchover (effects distributed) facility

HiRDB External Data Access facility

Inner replica facility (when described for the Windows version of HiRDB)

Updatable online reorganization (when described for the Windows version of HiRDB)

Sun Java System Directory Server linkage facility

Simple setup tool

The following products and option program products are explained, but they are not supported:

HiRDB Control Manager

HiRDB Disaster Recovery Light Edition

HiRDB External Data Access

HiRDB LDAP Option

Notes on printed manuals

Please note that even though the printed manuals are separated into Part I and Part II, the chapters and page numbers sequentially continue from Part I to Part II. Also, please note that the index is only included in Part II.

1. HiRDB Startup and Termination

This chapter describes the procedures for starting and terminating HiRDB.

In the case of a HiRDB/Parallel Server, HiRDB can be started and terminated at each unit and server.

This chapter contains the following sections:

Organization of this chapter

1.1 Startup

1.2 Termination

1.3 Special startup procedures

1.4 Startup and termination of a unit (applicable to HiRDB/Parallel Server only)

1.5 Startup and termination of a server (applicable to HiRDB/Parallel Server only)

1.6 Notes on startup

1.7 Notes on termination

1.8 Reducing the HiRDB startup processing time

1.1 Startup

Executor: HiRDB administrator

You use the pdstart command to start HiRDB. This section explains the following items related to the HiRDB startup modes and startup methods:

Startup modes

Server machine where the pdstart command is executed

Automatic startup

Reduced activation (applicable to HiRDB/Parallel Server only)

Example (HiRDB normal startup)

Checking for startup completion

Organization of this section

1.1.1 Startup modes

1.1.2 Server machine where the pdstart command is executed

1.1.3 Automatic startup

1.1.4 Reduced activation (applicable to HiRDB/Parallel Server only)

1.1.5 Example (HiRDB normal startup)

1.1.6 Checking for startup completion

1.1.1 Startup modes

HiRDB employs the concept of the startup modes listed in Table 1-1. The pdstart command's options depend on the startup mode.

Table 1-1 HiRDB startup modes

Startup mode
Execution command
Description of the startup mode
Previous termination mode

Normal startup
pdstart
This is the usual startup mode. In this mode, information that was in effect during the previous session is not inherited. However, the error shutdown status of RDAREAs is inherited.
Normal termination

Restart¹
This is the mode that is used (automatically) when the previous termination mode was one of those listed to the right. In this mode, the information that was in effect during the previous session is inherited.

Planned termination

Forced termination

Abnormal termination

Forced startup²
pdstart dbdestroy
This mode should not be used unless it is absolutely necessary. When HiRDB cannot be restarted, this mode is used to start HiRDB forcibly.

³
pdstart -i
This mode should not be used unless it is absolutely necessary; it is used when a database is being reinitialized.

pdstart -r
This mode should not be used unless it is absolutely necessary; it is used in the event of an error in the master directory RDAREA.

pdstart -a
This mode should not be used unless it is absolutely necessary; it is used when the front-end server is in SUSPEND status.

¹ Section 1.7.2 Notes on planned termination, forced termination, and abnormal termination should be read before HiRDB is restarted.

² Section 1.6.2 Notes on forced startup of HiRDB (or a unit) should be read before forced startup is executed.

³ For details on using these startup methods, see 1.3 Special startup procedures.

1.1.2 Server machine where the pdstart command is executed

To start a HiRDB/Single Server, the pdstart command must be executed at the server machine where the single server is defined. To start a utility special unit, the pdstart command must be executed at the server machine where the utility special unit is defined.

To start a HiRDB/Parallel Server, the pdstart command must be executed at the server machine where the system manager is defined.

1.1.3 Automatic startup

HiRDB can be started automatically by specifying the pd_mode_conf operand in the system common definition. Automatic startup means that HiRDB is started automatically when OS is started. The method of starting HiRDB by entering the pdstart command is called manual startup.

Notes

If HiRDB (or the unit) terminates abnormally when HiRDB has been set up with the pd_mode_conf operand to start automatically, it will restart automatically. However, if it cannot restart in three consecutive attempts, it will terminate abnormally.

If HiRDB terminates abnormally during startup or termination processing, manual startup must be used to start it.

In the case of automatic startup of a HiRDB/Parallel Server (pd_mode_conf=AUTO specified), all units must start within 20 minutes from the time the first unit starts. If all units do not start within 20 minutes, the HiRDB startup process will terminate. This 20-minute time limit can be changed with the pd_reduced_check_time operand.
Note that the time limit does not apply when HiRDB is being restarted after the unit or the operating system has terminated abnormally.

1.1.4 Reduced activation (applicable to HiRDB/Parallel Server only)

Normally, a HiRDB/Parallel Server cannot be started unless all its units start. However, the reduced activation facility enables a HiRDB/Parallel Server to be started at the available units even if some units cannot be started due to an error. To use this facility, the following operands must be specified:

pd_start_level

pd_start_skip_unit

For details on the reduced activation facility, see 18.15 Handling of reduced activation (HiRDB/Parallel Server only).

1.1.5 Example (HiRDB normal startup)

In this example, HiRDB is started normally.

Organization of this subsection

(1) Entering the pdstart command to start HiRDB normally:

(2) The results of executing the pdstart command are displayed:

(3) Entering the pdls command to check HiRDB's operational status:

(4) The results of executing the pdls command are displayed:

(1) Entering the pdstart command to start HiRDB normally:

pdstart

(2) The results of executing the pdstart command are displayed:

139 14:56:33 unt1 _rdm     KFPS05210-I HiRDB system initialization
process complete

(3) Entering the pdls command to check HiRDB's operational status:

pdls

(4) The results of executing the pdls command are displayed:

HOSTNAME(145750)     UNITID  SVID      STATUS   STARTTIME
k95x620              unt1    ********  ACTIVE   145632
k95x620              unt1    sds01     ACTIVE   145632

Explanation

ACTIVE in the STATUS column indicates that HiRDB has been started successfully.

This example of execution results of the pdls command is for HiRDB/Single Server.

1.1.6 Checking for startup completion

This section explains how to check whether startup of HiRDB (or a unit) has been completed.

Organization of this subsection

(1) Checking for HiRDB startup completion

(2) Checking for completion of startup of a unit

(1) Checking for HiRDB startup completion

(a) Checking the termination status of the pdls -d svr command

After you have executed the pdstart command, execute the pdls -d svr command from any unit and note its termination status. Table 1-2 shows the action that must be taken by the HiRDB administrator based on the termination status of the pdls -d svr command.

Table 1-2 Termination status of the pdls -d svr command and required actions

Termination status of the pdls -d svr command
Action to be taken by the HiRDB administrator

0
You can execute an application (SQL).

4
HiRDB startup may still be underway; execute the pdls -d svr command at approximately 5-second intervals until the termination status is no longer 4. You should execute the pdls -d svr command over a period of time roughly equivalent to the value specified in the pd_system_complete_wait_time operand.

8
An error occurred during HiRDB startup. See the message that is output to syslogfile and remove the error cause; then restart HiRDB.

(b) Checking the termination status of the pdstart command

To start HiRDB from the unit in which the system manager is located, execute the pdstart command. If the termination status of the pdstart command is 0, you can execute an application (SQL).

If the termination status of the pdstart command is not 0, an error occurred during HiRDB startup. See the message that is output to syslogfile and remove the error cause; then restart HiRDB.

(2) Checking for completion of startup of a unit

After you have executed the pdstart -q command, execute the pdls -d ust command on the unit and note its termination status. Table 1-3 shows the action that must be taken by the HiRDB administrator based on the termination status reported by the pdls -d ust command.

Table 1-3 Termination status of the pdls -d ust command and required actions

Termination status of the pdls -d ust command
Action to be taken by the HiRDB administrator

0
The unit is running. If the unit where the command was executed contains a front-end server, you can execute an application (SQL) for which this unit's front-end server is specified in the PDFESHOST and PDSERVICEGRP operands in the client environment definition.

4
HiRDB startup may still be underway; execute the pdls -d ust command at approximately 5-second intervals until the termination status is no longer 4. You should execute the pdls -d ust command over a period of time roughly equivalent to the value specified in the pd_system_complete_wait_time operand.

8 or 12
An error occurred during unit startup. See the message that is output to syslogfile and remove the error cause; then restart the unit.

16
The operation may be incorrect. First use the pdsetup command to register HiRDB in the OS, then restart the unit.

1.2 Termination

Executor: HiRDB administrator

You use the pdstop command to terminate HiRDB. This section explains the following items related to the HiRDB termination modes and termination methods:

Termination modes

Server machine where the pdstop command is executed

Example (HiRDB normal termination)

Terminating HiRDB during OS shutdown

Organization of this section

1.2.1 Termination modes

1.2.2 Server machine where the pdstop command is executed

1.2.3 Example (HiRDB normal termination)

1.2.4 Terminating HiRDB during OS shutdown

1.2.1 Termination modes

HiRDB employs the concept of the termination modes listed in Table 1-4. The pdstop command's options depend on the termination mode.

Table 1-4 HiRDB termination modes

Termination mode
Input command
Description of the termination mode

Normal termination¹
pdstop
This is the normal termination mode. This mode prohibits CONNECT requests and terminates HiRDB once all user processes have terminated.
If HiRDB cannot be terminated even by executing the pdstop command because a utility is still running, the KFPS05074-E error message is output. The pdstop command terminates with return code 8.

Planned termination¹,²,³
pdstop -P
This mode prohibits acceptance of any new transactions and terminates HiRDB after all transactions, including utilities, have terminated.

Forced termination
pdstop -f
This mode terminates HiRDB immediately without waiting for completion of current transactions. Current transactions become subject to rollback⁴ during the subsequent HiRDB restart.

Abnormal termination

This is the mode in which HiRDB is terminated because of an error. HiRDB is terminated immediately without waiting for completion of current transactions. Current transactions become subject to rollback⁴ during the subsequent HiRDB restart.

¹ If HiRDB is linked to an OLTP system, the OLTP system must be terminated before normal or planned termination of HiRDB is executed. Otherwise, an attempt to terminate HiRDB by normal or planned termination may fail, because transaction processing cannot be executed on the OLTP system.

² When planned termination of HiRDB is executed, the system resources held by the HiRDB server processes are released after all the active transactions are terminated in the single server or front-end server. It may take a minute or so for this release processing to be completed after all transactions at a unit have terminated.

³ If planned termination of HiRDB has not been completed within 15 minutes of entering the pdstop -P command because a utility or transaction is still executing, the KFPS05072-W message is output and the pdstop -P command is terminated with return code 4. In such a case, planned termination processing is still in effect, and HiRDB will be terminated once the utility or transaction has terminated.

⁴ Current transactions become subject to rollback during a HiRDB restart except in the following cases:

The database load utility or database reorganization utility was executing in the no-log mode.

The UAP was executing in the no-log mode.

In such a case, the HiRDB administrator must restore the RDAREAs from backup copies or re-execute the utility after HiRDB has been restarted. For details on how to restore RDAREAs, see 19.2 Recovering a database to the point at which a backup was made.

1.2.2 Server machine where the pdstop command is executed

To terminate a HiRDB/Single Server, the pdstop command must be executed at the server machine where the single server is defined. To terminate a utility special unit, the pdstop command must be executed at the server machine where the utility special unit is defined.

To terminate a HiRDB/Parallel Server, the pdstop command must be executed at the server machine where the system manager is defined.

1.2.3 Example (HiRDB normal termination)

In this example, a HiRDB/Single Server that is currently running is terminated normally.

Organization of this subsection

(1) Enter the pdls command to check HiRDB's operational status:

(2) The results of executing the pdls command are displayed:

(3) Enter the pdls command to check whether or not there are any users connected to HiRDB:

(4) The results of executing the pdls command are displayed:

(5) Enter the pdstop command to terminate HiRDB normally:

(6) The results of executing the pdstop command are displayed:

(1) Enter the pdls command to check HiRDB's operational status:

pdls

(2) The results of executing the pdls command are displayed:

HOSTNAME(140814)    UNITID  SVID      STATUS   STARTTIME
k95x620             unt1    ********  ACTIVE   140812
k95x620             unt1    sds01     ACTIVE   140812

Explanation

ACTIVE in the STATUS column indicates that HiRDB is running.

(3) Enter the pdls command to check whether or not there are any users connected to HiRDB:

pdls -d prc

(4) The results of executing the pdls command are displayed:

HOSTNAME : k95x620(141028)
STATUS   PID   UID   GID   SVID   TIME      PROGRAM    C-PID

 L      205   0     0     sds01  999999
 L      201   0     0     sds01  999999
 L      194   0     0     sds01  999999
 L      206   0     0     sds01  999999
 L      198   0     0     sds01  999999
 L      142   0     0     sds01  999999
 L      209   0     0     sds01  999999
 L      212   0     0     sds01  999999

Explanation

If a user is connected to HiRDB, a UAP identifier is shown in the PROGRAM column. In this example, there are no users currently connected to HiRDB. HiRDB cannot be terminated if any user is still connected.

For example, if HiRDB SQL Executer remains in use (i.e., HiRDB is still connected), HiRDB cannot be terminated. To terminate HiRDB, you must first terminate HiRDB SQL Executer.

The identifier that is displayed in the PROGRAM column is the UAP identification name specified in the PDCLTAPNAME operand of the client environment definition. If the PDCLTAPNAME operand was omitted, Unknown is displayed.

(5) Enter the pdstop command to terminate HiRDB normally:

pdstop

(6) The results of executing the pdstop command are displayed:

129 14:15:20 unt1 _rdm     KFPS01841-I HiRDB unit unt1 terminated.
mode = NORMAL
129 14:15:20 unt1 _rdm     KFPS01850-I HiRDB system terminated.
mode = NORMAL

1.2.4 Terminating HiRDB during OS shutdown

If an OS shutdown occurs during HiRDB operation, databases may be damaged depending on the shutdown's timing. This subsection describes how to terminate HiRDB when the OS is shut down. In the case of the AIX 5L version of HiRDB, an OS shutdown does not damage databases.

There are two ways to terminate HiRDB during an OS shutdown; you use the pdsetup command to specify the appropriate settings. Normally, you use the settings for explicit forced termination of HiRDB during an OS shutdown.

Organization of this subsection

(1) Explicit forcible termination of HiRDB during an OS shutdown

(2) Terminating HiRDB normally during OS shutdown, or terminating HiRDB during OS shutdown depending on whether or not termination of the OS is forced

(1) Explicit forcible termination of HiRDB during an OS shutdown

For explicit forcible termination of HiRDB during an OS shutdown, execute the following pdsetup command:

pdsetup -k on HiRDB-directory-name

(2) Terminating HiRDB normally during OS shutdown, or terminating HiRDB during OS shutdown depending on whether or not termination of the OS is forced

To terminate HiRDB normally during OS shutdown, or to terminate HiRDB during OS shutdown depending on whether or not the OS is terminated forcibly, execute the following pdsetup command:

pdsetup -k off HiRDB-directory-name

(a) Terminating HiRDB normally during OS shutdown

Specific conditions must be met in order to terminate HiRDB normally. You must also create and register an rc script.

Conditions for normal termination

To terminate HiRDB normally, the following conditions must be met:

No users can be connected to HiRDB.

There can be no uncompleted transactions.

In the case of a HiRDB/Parallel Server, no unit that does not contain the system manager can have been terminated forcibly or abnormally.

Creating and registering an rc script

Create and register the following rc script:

Contents of the rc script

Create an rc script that executes the following procedure:

Terminates all clients connected to HiRDB.

Executes the pdstop command to effect normal termination of HiRDB.

If normal termination fails in step 2 (return code is not 0), executes the pdstop -f command to terminate HiRDB forcibly.

Location where the rc script is registered

Register the created rc script at the following location:

Platform
Location of registration

HP-UX
/sbin/init.d/xxxx
/sbin/rc1.d/Kyyyxxxx
(Symbolic link to sbin/init.d/xxxx)

Solaris
/etc/init.d/xxxx
/etc/rc0.d/Kyyyxxxx
/etc/rc1.d/Kyyyxxxx
(Symbolic link to etc/init.d/xxxx)

Linux
/etc/init.d/xxxx
/etc/rc0.d/Kyyyxxxx
/etc/rc1.d/Kyyyxxxx
/etc/rc6.d/Kyyyxxxx
(Symbolic link to etc/init.d/xxxx)

Legend:

xxxx:

Any name

Kyyyxxxx:

K indicates the script that is to run during termination. yyy indicates a numeric value in the range from 000 to 999; the rc scripts are executed in ascending order of this value. xxxx indicates any name.

(b) Terminating HiRDB during OS shutdown depending on whether or not the OS termination is forced

If HiRDB termination depends on whether or not termination of the OS was performed forcibly, databases may be damaged depending on when the shutdown occurs. For this reason, you should make sure that you perform explicit forced termination of HiRDB during an OS shutdown.

1.3 Special startup procedures

In addition to normal startup, restart, and forced startup, the following startup procedures are also available:

Startup procedure used to reinitialize a database

Startup procedure used in the event of an error in the master directory RDAREA

Startup procedure used in the event of an error in a data dictionary RDAREA

Note

You must exercise caution when you use the HA monitor's system switchover facility on an HP-UX, or AIX-5L version of a HiRDB/Parallel Server. You must use the following procedure to release the HA monitor's monitoring status, and then you must execute a special startup procedure:

Procedure

Check the status of each unit (whether it is the running system or a standby system).*

If the primary unit is in standby status, use the HA monitor's monswap command to switch the systems so that the primary unit becomes the running system. In other words, return the systems to their status when use of the system switchover facility began.

Enter the pdstop command to terminate HiRDB on the running system.

If a HiRDB is running as a server system having no HA monitor interface (in the monitor mode), use the monend command of the HA monitor to stop the HiRDB on the standby system.

* If IP addresses are not inherited, the pdls -d ha command can be used to check the status.

Organization of this section

1.3.1 Startup procedure used to reinitialize a database (pdstart -i)

1.3.2 Startup procedure used in the event of an error in the master directory RDAREA (pdstart -r)

1.3.3 Startup procedure used when the front-end server is in SUSPEND status due to an error in a data dictionary RDAREA (pdstart -a)

1.3.1 Startup procedure used to reinitialize a database (pdstart -i)

To reinitialize a database (re-execute the database initialization utility), the pdstart -i command is used to start HiRDB.

When plug-ins are used

If plug-ins are being used, the pdplugin operand must be deleted from the system common definition before the pdstart -i command is executed. Otherwise, the registry information will be lost. After the database initialization utility has been executed, the registry-related environment must be redefined.

1.3.2 Startup procedure used in the event of an error in the master directory RDAREA (pdstart -r)

If an error occurs in the master directory RDAREA, HiRDB cannot be started by any of the normal startup methods. In such a case, the pdstart -r command must be used to start HiRDB.

When HiRDB has been started with the pdstart -r command, only the following utilities can be executed; no other operations are possible:

Database recovery utility

Database copy utility

The HiRDB administrator must use one of these utilities to restore the master directory RDAREA. Once the master directory RDAREA has been restored, HiRDB can be restarted and application processing can be resumed.

For details on the actions to be taken when HiRDB cannot be restarted due to an error in the master directory RDAREA, see 18.4.2 When HiRDB does not restart.

1.3.3 Startup procedure used when the front-end server is in SUSPEND status due to an error in a data dictionary RDAREA (pdstart -a)

If an error occurs in a data dictionary RDAREA during HiRDB startup, the front-end server is placed in SUSPEND status.* In such a case, the HiRDB administrator must restore the data dictionary RDAREA and release the front-end server from SUSPEND status.

The pdstart -a command is used to start HiRDB, which will release the front-end server from SUSPEND status.

* This is the status in which the front-end server is waiting for recovery of the data dictionary RDAREA.

1.4 Startup and termination of a unit (applicable to HiRDB/Parallel Server only)

Executor: HiRDB administrator

When a HiRDB/Parallel Server is being used, each unit can be started and terminated independently.

Organization of this section

(1) Unit startup procedures

(2) Unit termination procedures

(3) Unit startup and termination procedures

(1) Unit startup procedures

HiRDB can be started at a unit with the commands listed in Table 1-5.

Table 1-5 Startup procedures for a unit

Startup mode
Execution command
Description of the startup mode
Previous termination mode

Normal startup
pdstart -u
pdstart -x
This startup mode is used to restart a unit after it terminated normally during HiRDB operation. Information that was in effect during the previous session is not inherited.
Normal termination

Restart¹
The restart mode is used (automatically) when the previous termination mode was one of those listed to the right. In this mode, the information that was in effect during the previous session is inherited.
Forced termination
Abnormal termination

Forced startup²
pdstart -u dbdestroy
pdstart -x dbdestroy
This mode should not be used unless it is absolutely necessary. This mode starts the unit forcibly without restoring the database.

¹ Section 1.7.2 Notes on planned termination, forced termination, and abnormal termination should be read before restarting.

² Section 1.6.2 Notes on forced startup of HiRDB (or a unit) should be read before forced startup is executed.

(2) Unit termination procedures

HiRDB can be terminated at a unit with the commands listed in Table 1-6.

Table 1-6 Termination procedures for a unit

Termination mode
Input command
Description of the termination mode

Normal termination
pdstop -u
pdstop -x
This mode prohibits any more CONNECT requests to this unit, disconnects all UAPs currently connected to the unit, then terminates the unit.
If the unit cannot be terminated, even by executing the pdstop -u or pdstop -x command, because a utility is still running, the KFPS05070-E error message is output. The pdstop -u or pdstop -x command terminates with return code 8.

Forced termination¹
pdstop -f -u
pdstop -f -x
This mode terminates the unit immediately without waiting for completion of current transactions. Current transaction become subject to rollback² during the subsequent restart.

Abnormal termination

This is the mode in which the unit is terminated because of an error. The unit is terminated immediately without waiting for completion of current transactions. Current transactions become subject to rollback² during the subsequent restart.

¹ Section 1.7.2 Notes on planned termination, forced termination, and abnormal termination should be read before restarting.

² Current transactions become subject to rollback during a HiRDB restart except in the following cases:

The database load utility or database reorganization utility was executing in the no-log mode.

The UAP was executing in the no-log mode.

In such a case, the HiRDB administrator must restore the RDAREAs from backup copies or re-execute the utility after HiRDB has been restarted. For details on how to restore RDAREAs, see 19.2 Recovering a database to the point at which a backup was made.

(3) Unit startup and termination procedures

To start and terminate a unit:

Enter the pdstart command to start and run HiRDB:
pdstart

Because an error occurred in the unit, enter the pdstop -u command to terminate the unit normally (if the unit did not terminate abnormally):
pdstop -u unit-identifier

After the error has been corrected, enter the pdstart -u command to restart the unit:
pdstart -u unit-identifier

1.5 Startup and termination of a server (applicable to HiRDB/Parallel Server only)

Executor: HiRDB administrator

When a HiRDB/Parallel Server is being used, each server can be started and terminated independently. This section explains the server startup and termination procedures, which are applicable to the following types of servers:

Front-end servers

Dictionary servers

Back-end servers

Organization of this section

(1) Server startup procedure

(2) Server termination procedure

(3) Server startup and termination procedures

(1) Server startup procedure

HiRDB can be started at a server with the command shown in Table 1-7.

Table 1-7 Startup procedure for a server

Startup mode | Execution command | Description of the startup mode | Previous termination mode
Normal startup | pdstart -s | This startup mode is used to restart a server after it terminated normally during HiRDB operation. Information that was in effect during the previous session is not inherited. | Normal termination

(2) Server termination procedure

HiRDB can be terminated at a server with the command shown in Table 1-8.

Table 1-8 Termination procedure for a server

Termination mode | Input command | Description of the termination mode
Normal termination | pdstop -s | This mode prohibits acceptance of any new transactions and terminates the server after all current transaction processing has been completed.

(3) Server startup and termination procedures

To start and terminate a server:

Enter the pdstart command to start and run HiRDB:
pdstart

Because an error occurred in a server, enter the pdstop -s command to terminate the server normally (if the server did not terminate abnormally):
pdstop -s server-name

After the error has been corrected, enter the pdstart -s command to restart the server:
pdstart -s server-name

1.6 Notes on startup

This section discusses important points to be kept in mind when HiRDB is started. The following topics are covered:

Notes on HiRDB startup

Notes on forced startup of HiRDB (or a unit)

Notes on HiRDB startup processing errors (applicable to HiRDB/Parallel Server only)

Organization of this section

1.6.1 Notes on HiRDB startup

1.6.2 Notes on forced startup of HiRDB (or a unit)

1.6.3 Notes on HiRDB startup processing errors (applicable to HiRDB/Parallel Server only)

1.6.1 Notes on HiRDB startup

Organization of this subsection

(1) Do not stop the pdstart command forcibly

(1) Do not stop the pdstart command forcibly

Event

Because there was no response to the entered pdstart command, the window from which the pdstart command was entered was closed, then HiRDB terminated abnormally.

Cause

If the pdstart command is stopped forcibly, HiRDB terminates abnormally because conformity among shared resources is lost. HiRDB also terminates abnormally if the window is closed while waiting for a response from the pdstart command.

Action

Do not close the window from which the pdstart command is entered until the pdstart command has terminated.

The same applies to the other operation commands and utilities. Do not close the window while waiting for a response from a command or utility or while executing a command or utility.

1.6.2 Notes on forced startup of HiRDB (or a unit)

When HiRDB (or a unit) is started forcibly, the information that was in effect during the previous session is not inherited. Therefore, HiRDB cannot restore the database to its status during the previous session. Instead, the HiRDB administrator must restore the database's status.

When HiRDB is started forcibly, all RDAREAs (including system RDAREAs) that were updated during the previous session are corrupted.

The corrupted RDAREAs must be recovered with the database recovery utility before forced startup. HiRDB operations cannot be guaranteed unless the RDAREAs are recovered.

Procedure

The following is the procedure for recovering corrupted RDAREAs:

Check the KFPS01262-I message that was output when HiRDB restart failed.

Check in the KFPS01262-I message the group name of the system log's input starting file and check the system log that is created thereafter.*

Recover the RDAREAs using the system log checked in step 2 as the input to the database recovery utility (pdrstr command). RDAREAs can be recovered only from the system log.

* The pdlogls -d sys command is used to check the system log.

pdlogls -d sys

Group    Type Server   Gen No. Status  Run ID    Block No.
logfg01  sys  sds             1 cnu---u 35108db8        1        2
logfg02  sys  sds             4 cn---cu 3510ecba       10        0
logfg03  sys  sds             1 cn----- 3510ecba        1        3
logfg04  sys  sds             2 cn----- 3510ecba        4        8
logfg05  sys  sds             3 cn----- 3510ecba        9        f
logfg06  sys  sds             0 cn----- 00000000​        0        0

Explanation

If logfg04 and 5 are displayed in the KFPS01262-I message as the fg name and block number, respectively, it is clear from Run ID, Gen No., and Block No. that the system log files were used in the following order:

logfg04 logfg05 logfg02

This means that the system log file to be used has the same Run ID as the file group displayed in the KFPS01262-I message and a generation number greater than displayed under Gen No..

This method is not applicable when the HiRDB/Parallel Server is started and terminated individually at each server.

1.6.3 Notes on HiRDB startup processing errors (applicable to HiRDB/Parallel Server only)

This section provides notes on errors during unit startup. You should consult this section when the following conditions are applicable.

Organization of this subsection

(1) Conditions

(2) Notes

(1) Conditions

All of conditions 1, 2, and 3 or all of conditions 1, 2, and 4 must be satisfied:

A HiRDB/Parallel Server is being used.

Multiple servers are defined at the unit whose startup processing failed.

The startup mode is normal startup or restart after planned termination.

The startup mode is restart after forced termination or abnormal termination, and pd_log_rerun_swap=Y is specified.

(2) Notes

When a unit is started, HiRDB starts all servers at the unit concurrently. If an invalid system definition operand is detected or an error occurs in one of the servers, startup of the entire unit fails. In such a case, the following events may occur:

At a server whose startup processing is completed, allocation of the current system log file is completed (the KFPS01221-I message is output)

At a server whose startup processing is not completed, the current system log file is not allocated (the KFPS01221-I message is not output)

In such a case, HiRDB allocates a new current file the next time unit startup is performed. The current file allocated during the previous unit startup is closed (it is not reused). The HiRDB administrator must take one of the actions described below in order to reallocate this closed system log file as the current file.

(a) Not reinitializing the system log file

After executing pdlogunld or pdlogchg for the corresponding system log file, one of the actions listed below can be taken, depending on HiRDB's activity status:

HiRDB's activity status | HiRDB administrator's action
During HiRDB operation | Execute the pdlogopen command on the corresponding system log file.
Before normal startup of unit | No action is required. This file is identified as the available current system log file during unit startup.
Before unit restart | After the unit is restarted, execute the pdlogopen command on the corresponding system log file.

(b) Reinitializing the system log file

Procedure

Execute the pdlogunld or pdlogchg command on the corresponding system log file:
pdlogunld -d sys -s b001 -g syslogfgp03 -o /unld/unldlog01

Use the pdlogrm command to delete the corresponding system log file.
pdlogrm -d sys -s b001 -f /unt1/sysfile01/log01

Use the pdloginit command to initialize the corresponding system log file:
pdloginit -d sys -s b001 -f /unt1/sysfile01/log01 -n 5000

1.7 Notes on termination

This section discusses important points to be kept in mind when HiRDB is terminated. The following topics are covered:

Notes on HiRDB termination

Notes on planned termination, forced termination, and abnormal termination

Organization of this section

1.7.1 Notes on HiRDB termination

1.7.2 Notes on planned termination, forced termination, and abnormal termination

1.7.1 Notes on HiRDB termination

Organization of this subsection

(1) HiRDB cannot be terminated normally if there are uncompleted transactions or connected users

(2) Do not stop the pdstop command forcibly

(3) Note the shutdown command execution timing

(1) HiRDB cannot be terminated normally if there are uncompleted transactions or connected users

Event

Normal termination of HiRDB failed.

Cause

HiRDB cannot be terminated normally if there are transactions that have not been completed or if there are connected users.

Action

Before terminating HiRDB normally, check for any connected users or transactions that have not been completed:

The pdls -d prc command is used to check for connected users

The pdls -d trn command is used to check transaction status

If no user is connected but there is a transaction processing, the following commands can be entered to complete the transaction:

Use the pdcmt command to commit the transaction

Use the pdrbk command to roll back the transaction

For details on how to terminate HiRDB normally when transactions have not been completed or users are still connected, see 18.14 Actions when there is an undetermined transaction.

(2) Do not stop the pdstop command forcibly

Event

The window from which the pdstop command was entered was closed because there was no response from the command, and HiRDB terminated abnormally.

Cause

If the pdstop command is stopped forcibly, HiRDB terminates abnormally because conformity among shared resources is lost. HiRDB also terminates abnormally if the window is closed while waiting for a response from the pdstop command.

Action

Do not close the window from which the pdstop command is entered until the pdstop command has terminated.

This also applies to the other operation commands and utilities; i.e., do not close the window while waiting for a response from any command or utility or while a command or utility is executing.

(3) Note the shutdown command execution timing

Event

When the pdstop and shutdown commands were executed consecutively in this order as a shell script, the system server terminated abnormally.

Cause

When the pdstop command terminates, the system server has not yet terminated. If the shutdown command is executed while the system server is still engaged in termination processing, the system server terminates abnormally.

Action

Do not execute the shutdown command immediately after the pdstop command. To execute the shutdown command after the pdstop command, execute the following commands in the order shown:

pdstop

sleep 60

shutdown

If the system server terminates abnormally, the HiRDB startup mode after the next OS boot-up is restart. During a restart, HiRDB restores the system to its status at the time of the OS shutdown, which means that the restart operation may take a long time. For notes on restarting HiRDB, see 1.7.2 Notes on planned termination, forced termination, and abnormal termination.

1.7.2 Notes on planned termination, forced termination, and abnormal termination

The points discussed below must be taken into consideration when HiRDB planned termination, forced termination, or abnormal termination has occurred.

Organization of this subsection

(1) The HiRDB version must not be changed

(2) Only part of the HiRDB system definition can be modified

(3) The server configuration cannot be modified (applicable to HiRDB/Parallel Server only)

(4) Addition, deletion, and modification of global buffers

(5) Global buffer allocated to an RDAREA that was added during HiRDB operation

(6) Status files cannot be deleted, modified, or initialized

(7) Synchronization point dump files cannot be added, deleted, modified, or initialized

(8) System log files cannot be deleted or modified

(9) Swapping the current system log files

(10) Input error in the system log file during restart

(11) Notes on restart after planned termination

(12) Forced termination may result in abnormal termination of unit

(1) The HiRDB version must not be changed

The HiRDB version must not be changed when planned termination, forced termination, or abnormal termination of HiRDB has occurred. If the version is changed, HiRDB restart will fail. HiRDB must be terminated normally before the HiRDB version can be changed.

(2) Only part of the HiRDB system definition can be modified

When planned termination, forced termination, or abnormal termination of HiRDB has occurred, some of the HiRDB system definition operands cannot be modified. For details on the operands that cannot be modified, see the manual HiRDB Version 8 System Definition.

HiRDB/Parallel Server

If any unit terminates abnormally during a normal or planned termination, the HiRDB system definitions should not be modified before the next startup. If they are modified, HiRDB startup will probably fail; even if HiRDB startup is successful, HiRDB will not operate normally.

(3) The server configuration cannot be modified (applicable to HiRDB/Parallel Server only)

The HiRDB server configuration should not be modified when planned termination, forced termination, or abnormal termination of HiRDB has occurred. The pdstart and pdunit operands cannot be modified in the system common definition before the restart. If they are modified, HiRDB restart will fail.

HiRDB must be terminated normally before the HiRDB server configuration can be modified. In such a case, the following files must be reinitialized (otherwise, HiRDB startup may fail):

All system log files

All synchronization point dump files

All unit status files

All server status files

(4) Addition, deletion, and modification of global buffers

When HiRDB is terminated forcibly or abnormally, the types of global buffer manipulation listed in Table 1-9 are not available.

Table 1-9 Unavailable global buffer manipulations when HiRDB is terminated forcibly or abnormally

Global buffer manipulation
Normal or planned termination
Forced or abnormal termination

Addition of global buffer
(addition of pdbuffer operand)
Y
NA

Deletion of global buffer
(deletion of pdbuffer operand)
Y
NA

Modification of global buffer
(modification of pdbuffer operand)
Y
NA

Y: Available

[NA]: Not available

(5) Global buffer allocated to an RDAREA that was added during HiRDB operation

In the case of a global buffer allocated to an RDAREA that was added during HiRDB operation, whether or not it is inherited at the next startup is determined by the termination mode, as shown in Table 1-10.

Table 1-10 Inheritance of global buffer allocated to RDAREA that was added during HiRDB operation

Condition | Normal or planned termination | Forced or abnormal termination
Whether or not global buffer allocated to a RDAREA that was added during HiRDB operation is inherited. | Not inherited | Inherited

(6) Status files cannot be deleted, modified, or initialized

When planned termination, forced termination, or abnormal termination of HiRDB occurs, the types of status file manipulations listed in Table 1-11 are not available.

Table 1-11 Unavailable status file manipulations in the event of planned, forced, or abnormal termination

Status file manipulation | Normal termination | Planned, forced, or abnormal termination
Addition of status file | Y | Y
Deletion of status file | Y | NA
Modification of status file | Y | NA
Initialization of status file | Y | NA

Y: Available

[NA]: Not available (if executed, restart fails)

After planned, forced, or abnormal termination

The following operands can be added:

pd_syssts_file_name_1 to pd_syssts_file_name_7

pd_sts_file_name_1 to pd_sts_file_name_7

These operands cannot be deleted or modified. If deleted or modified, restart of the corresponding unit fails.

(7) Synchronization point dump files cannot be added, deleted, modified, or initialized

When planned termination, forced termination, or abnormal termination of HiRDB occurs, the types of synchronization point dump file manipulations listed in Table 1-12 are not available.

Table 1-12 Unavailable synchronization point dump file manipulations in the event of planned, forced, or abnormal termination

Synchronization point dump file manipulation | Normal termination | Planned, forced, or abnormal termination
Addition of synchronization point dump file | Y | NA
Deletion of synchronization point dump file | Y | NA
Modification of synchronization point dump file | Y | NA
Initialization of synchronization point dump file | Y | NA

Y: Available

NA: Not available (if executed, restart fails)

After planned, forced, or abnormal termination

The following operands cannot be added, deleted, or modified:

pdlogadfg -d spd

pdlogadpf -d spd

If these operands are added, deleted, or modified by mistake, restart of the corresponding unit fails.

A synchronization point dump file that was added during the previous HiRDB session will be inherited after a HiRDB restart.

(8) System log files cannot be deleted or modified

When planned termination, forced termination, or abnormal termination of HiRDB occurs, the types of system log file manipulations listed in Table 1-13 are not available.

Table 1-13 Unavailable system log file manipulations in the event of planned, forced, or abnormal termination

System log file manipulation | Normal termination | Planned, forced, or abnormal termination
Addition of system log file | Y | Y
Deletion of system log file | Y | NA
Modification of system log file | Y | NA
Initialization of system log file | Y | Y*

Y: Available.

NA: Not available (if executed, restart fails)

* The system log files listed below must not be initialized; if they are initialized by mistake, restart of the corresponding unit fails (or, in the event restart is successful, the database contents will be corrupted):

The last system log file used during the previous HiRDB session

Any system log file that is overwrite-disabled

After planned, forced, or abnormal termination

The following operands can be added:

pdlogadfg -d sys

pdlogadpf -d sys

These operands cannot be deleted or modified; if they are deleted or modified, restart of the corresponding unit fails.

(9) Swapping the current system log files

Whether or not swapping of the current system log file occurs during a HiRDB restart depends on the specification of the pd_log_rerun_swap operand, as shown in Table 1-14.

Table 1-14 Current system log file swapping conditions

Specification of pd_log_rerun_swap operand | Normal or planned termination | Forced or abnormal termination
pd_log_rerun_swap=Y | Y | Y
pd_log_rerun_swap=N | Y | NA
pd_log_rerun_swap operand omitted | Y | NA

Y: System log file swapping is performed when HiRDB is restarted. The current file in effect during the previous termination is swapped out, and a new current file is allocated.

NA: System log file swapping is not performed when HiRDB is restarted. The current file in effect during the previous termination is retained as the current file. However, the current system log file is swapped out at the HiRDB restart in the following cases:

An error occurred in the current file in effect during the previous termination

Unload was executed during HiRDB termination (pdlogunld or pdlogchg command was executed)

(10) Input error in the system log file during restart

At a HiRDB restart, HiRDB uses the last synchronization point validated during the previous session as the system log input start point. It recovers the database and transactions by reading sequentially all applicable system log files. If at least one system log file was lost due to an error (if dual system log files are used and both versions A and B were lost), restart fails; or, even if restart is successful, the database becomes invalid.

If unload log files have been acquired for those lost system log files, the database can be recovered by the database recovery utility using the backup copy and the unload log files.

If no unload log file is available, system log information cannot be used for database recovery. In such a case, either the database must be restored to the point where the last backup was made and then the same applications must be re-executed, or the database must be re-created.

(11) Notes on restart after planned termination

At a HiRDB restart, HiRDB uses the last synchronization point validated during the previous session as the system log input start point. If an error occurs in the last valid synchronization point dump file or status file, the system log input start point may be moved farther back in time to another valid synchronization point. Figure 1-1 shows an example of moving back the system log input start point.

Figure 1-1 Example of moving back the system log input point

Explanation

If planned termination is executed between the system log input start point determined in this manner and the latest system log file, the following must be noted.

If a HiRDB system definition is modified after a planned termination and prior to restart, the restart will fail. In such a case, restart will fail even if the HiRDB system definitions are restored later to their status before the planned termination.

In such a case, normal startup of the unit must be executed forcibly, and then the database recovery utility (pdrstr) must be executed to recover the database from its backup copy and unload log files.

(12) Forced termination may result in abnormal termination of unit

If HiRDB is terminated forcibly (by the pdstop -f command), a HiRDB unit may terminate abnormally with abort code Polkcrt. This is because a process in critical status was terminated during forced termination processing. However, this event can be ignored, because it does not cause any operational problems. Even a process in critical status terminates immediately during forced termination processing, resulting in this event. However, such a process is restarted the next time the pdstart command is entered (the database is recovered from the system log).

1.8 Reducing the HiRDB startup processing time

Executor: HiRDB administrator

Normally, startup processing of resident processes is executed during HiRDB startup processing. As the number of resident processes increases, the HiRDB startup processing time also increases. As a guideline, it takes approximately one second to start one process in a server machine with a performance rating of about 100 MIPS.

When the system switching facility is used, it may be desirable to consider reducing the HiRDB startup processing time.

The number of resident processes is determined by the value of the first parameter in the pd_process_count operand.

Organization of this section

(1) Procedure for reducing the startup processing time

(2) Example

(3) Notes

(1) Procedure for reducing the startup processing time

The second parameter in the pd_process_count operand is specified. The following describes the processing depending on whether or not the second parameter is specified.

(a) Second parameter not specified (pd_process_count = 500 specified)

All resident processes are started during HiRDB startup processing. In this case, HiRDB cannot start unless all the resident processes (500 processes in this example) start successfully. If a server machine with a performance rating of approximately 100 MIPS is used in this example, it takes some 500 seconds to start all the resident processes during HiRDB startup processing.

(b) Second parameter is specified (pd_process_count = 500,50 specified)

Some resident processes are started during HiRDB startup processing, and the rest are started after HiRDB startup processing is completed. In this case, HiRDB starts if some of the resident processes (50 processes in this example) start successfully. If a 100-MIPS server machine is used in this example, it takes some 50 seconds to start the resident processes during HiRDB startup processing. The remaining resident processes (450 processes in this example) are started after HiRDB startup processing is completed.

(2) Example

Assume that the following system is used:

One that requires 200 resident processes

For OpenTP1's SPP (50 processes), one for which processing is executed concurrently with HiRDB startup processing

System definition

pd_process_count=200,50

Explanation

200 is specified in the first parameter as the total number of resident processes.

50 is specified in the second parameter in order to obtain the resident processes for OpenTP1's SPP immediately after HiRDB startup.

In the case of a HiRDB/Parallel Server, the pd_process_count operand is specified in the front-end server definition.

(3) Notes

When this facility is used, the PDCWAITTIME operand's value in the client environment definition should be evaluated.

Reason

If more UAPs need to execute immediately after HiRDB startup than the value of the second parameter in pd_process_count, their transaction processing will not be executed until after all the remaining resident processes have been started. If the value of the PDCWAITTIME operand in the client environment definition is too small, some of the UAPs may result in timeouts.

For details on the PDCWAITTIME operand, see the manual HiRDB Version 8 UAP Development Guide.

2. Security Definition

HiRDB provides security features in order to protect databases from damage and unauthorized use. This chapter describes the security definition procedures.

This chapter contains the following sections:

Organization of this chapter

2.1 About security

2.2 Setting user privileges

2.3 Revoking user privileges

2.4 Setting a referencing privilege for data dictionary tables

2.1 About security

HiRDB provides security features in order to protect databases from unauthorized access. The security features are based on the concept of user privileges that prohibit access to a database by a user who does not have the required privilege.

Organization of this section

(1) Types of user privileges

(2) Relationship to a falsification prevented table

(3) Relationship to an audit trail table

(1) Types of user privileges

Table 2-1 lists the user privileges.

Table 2-1 User privileges

Type of user privilege
Description
What users who have this privilege can do
Who can grant this privilege

H
D
S

DBA privilege
This privilege is required in order to grant or revoke the DBA, CONNECT, and schema definition privileges.

Grant the DBA, CONNECT, and schema definition privileges to other users.

Revoke the DBA, CONNECT, and schema definition privileges of other users.

Define schemas for other users.
When a schema is defined, the schema's owner can define base tables, view tables, indexes, abstract data types, foreign tables,² foreign indexes,² stored procedures, stored functions, and triggers.

Drop other users' schemas, base tables, view tables, indexes, abstract data types, foreign tables,² foreign indexes,² stored procedures, stored functions, and triggers.

Define user mapping.²

Define and change foreign servers.²

Define items related to the connection security facility.

Connect to HiRDB (has the CONNECT privilege¹).

Y
Y
N

Audit privilege
This privilege must be granted to auditors. Users with this privilege set audit privileges when the security audit facility is being used. For details about the security audit facility, see 22. Using the Security Audit Facility.
Users with the audit privilege have the following privileges:

CONNECT privilege¹

Schema definition privilege

Access audit trail tables.³

Load data into audit trail tables.

Grant and revoke SELECT privileges for audit trail tables.

Delete audit trail tables.

Modify the passwords of auditors.

Define and delete audit events.

Y
N
N

CONNECT privilege
This privilege is required to use HiRDB. An error results when a user who does not have the CONNECT privilege attempts to use HiRDB.
Connect to databases.
N
Y
N

Schema definition privilege
This privilege is required to define a schema.

Define your own schema.
When a schema is defined, the schema's owner can define base tables, view tables, indexes, abstract data types, foreign tables,² foreign indexes,² stored procedures, stored functions, and triggers.

Drop the schema owner's own schemas, base tables, view tables, indexes, abstract data types, foreign tables,² foreign indexes,² stored procedures, stored functions, and triggers.

N
Y
N

RDAREA usage privilege
This privilege is required to use a private RDAREA, but is not needed for creating tables and indexes in public RDAREAs.
Create tables and indexes in a private RDAREA.
Y
Y
N

Access privilege
This privilege is required to access tables (base tables, view tables, and foreign tables). There are four access privilege types; the types are set at the table level:
Access the tables of other users.
N
N
Y

SELECT privilege
Search for (SELECT) a table.
N
N
Y

INSERT privilege
Add (INSERT) row data into a table.
N
N
Y

DELETE privilege
Delete (DELETE) row data from a table.
N
N
Y

UPDATE privilege
Update (UPDATE) row data in a table.
N
N
Y

Legend:

H: HiRDB administrator

D: User with DBA privilege

S: Schema owner

Y: Capable of granting privileges

N: Not capable of granting privileges

¹ The CONNECT privilege is not required for use of the directory server linkage facility. For details about the directory server linkage facility, see 24. Using the Directory Server Linkage Facility.

² These operations are applicable when you are using the HiRDB External Data Access facility. For details about the HiRDB External Data Access facility, see the manual HiRDB External Data Access Version 7 Description and User's Guide.

³ You cannot add data to or delete data from an audit trail table (INSERT or UPDATE).

(2) Relationship to a falsification prevented table

The falsification prevention facility is a security function that is provided in addition to the table access privileges. When the falsification prevention option (INSERT ONLY) is specified for a table that is being defined, the defined table becomes a falsification prevented table.

The objectives and features of falsification prevented tables are as follows:

Objectives

Prevent accidental deletion and updating of data.

Prevent data from illegal updating and deletion.

Features

Users with the UPDATE privilege cannot update these tables; even the owners of these tables cannot update them.

Users with the DELETE privilege cannot delete from these tables data that has not reached the deletion prevention time limit; even the owners of these tables cannot delete such data.

Users with the INSERT privilege can insert rows into these tables.

Users with the SELECT privilege can search these tables.

For details about the falsification prevention facility, see the manual HiRDB Version 8 Installation and Design Guide.

(3) Relationship to an audit trail table

HiRDB supports a facility that registers the results of security-related checking into an audit trail table as an audit trail when an event that accesses a HiRDB resource occurs. This facility is called the security audit facility. An audit trail table records who accessed which resource when, and whether or not the security check was successful. An audit trail table can be used for auditing illegal accesses.

To prevent illegal modification of audit trail tables, the users who are permitted to operate an audit trail table are limited to those shown in Table 2-2.

Table 2-2 Users who are permitted to operate an audit trail table

Operation on the audit trail table
Permitted users

Referencing of data (SELECT)

Auditor

Users who have the SELECT privilege for the audit trail table

Deletion of data (DELETE and PURGE)
Auditor

Addition or modification of data (INSERT or UPDATE)
None

For details about the security audit facility, see 22. Using the Security Audit Facility.

2.2 Setting user privileges

Figure 2-1 shows the procedure for setting user privileges.

Figure 2-1 Procedure for setting user privileges

Directory server linkage facility

When the directory server linkage facility is being used, the CONNECT privilege need be granted. For details about the directory server linkage facility, see 24. Using the Directory Server Linkage Facility.

Setting the audit privilege

For details about setting the audit privilege, see 22.4.3(1) Register the auditor.

Organization of this section

2.2.1 Granting the DBA privilege to users who manage user privileges

2.2.2 Granting the CONNECT privilege, schema definition privilege, and RDAREA usage privilege to users who create tables

2.2.3 Granting CONNECT and access privileges to users who access tables (database)

2.2.1 Granting the DBA privilege to users who manage user privileges

Executor: HiRDB administrator

The GRANT statement, which is a definition SQL statement, is used to grant the DBA privilege to a user who will manage user privileges. This task is required when the user who will manage user privileges is not a HiRDB administrator.

Example

Grant the DBA privilege to the user who will manage user privileges (authorization identifier: USER001, password: HIRDB001):

 GRANT DBA TO USER001 IDENTIFIED BY HIRDB001

2.2.2 Granting the CONNECT privilege, schema definition privilege, and RDAREA usage privilege to users who create tables

Executor: HiRDB administrator or user who manages user privileges (user with DBA privilege)

The GRANT statement, which is a definition SQL statement, is used to grant the following privileges to users who will creates tables:

CONNECT privilege

Schema definition privilege

RDAREA usage privilege*

* This privilege is required in order to create tables in private RDAREAs; it is not required in order to create tables in public RDAREAs.

Example

Grant the CONNECT, schema definition, and RDAREA usage privileges (RDAREA name: RDAREA01) to a table creator (authorization identifier: USER002, password: HIRDB002):

 GRANT CONNECT TO USER002 IDENTIFIED BY HIRDB002
 GRANT SCHEMA TO USER002
 GRANT RDAREA RDAREA01 TO USER002

Organization of this subsection

(1) Granting a schema definition privilege without using the GRANT statement

(2) Granting an RDAREA usage privilege without using the GRANT statement

(3) Changing a private RDAREA to a public RDAREA

(1) Granting a schema definition privilege without using the GRANT statement

A schema can be defined for a user to whom the schema definition privilege is to be granted. The schema definition privilege is then granted to the user that defined the schema.

(2) Granting an RDAREA usage privilege without using the GRANT statement

When defining a private RDAREA,* the HiRDB administrator can grant the RDAREA usage privilege to that private RDAREA.

* The following utilities and control statements are used:

Database initialization utility's CREATE RDAREA statement with the USER USED BY operand specified

Database structure modification utility's CREATE RDAREA statement with the USER USED BY operand specified

(3) Changing a private RDAREA to a public RDAREA

After revoking RDAREA usage privileges to a private RDAREA, use the GRANT statement, which is a definition SQL statement, to change the RDAREA. For details about revoking RDAREA usage privileges, see 2.3(4) Revoking RDAREA usage privileges.

Example

Redefine the private RDAREA named RDAREA02 as a public RDAREA:

 GRANT RDAREA RDAREA02 TO PUBLIC

2.2.3 Granting CONNECT and access privileges to users who access tables (database)

Organization of this subsection

(1) Granting CONNECT privileges

(2) Granting access privileges

(1) Granting CONNECT privileges

Executor: HiRDB administrator or user who manages user privileges (user with DBA privilege)

The GRANT statement, which is a definition SQL statement, is used to grant the CONNECT privilege to users who will access database tables.

Example

Grant the CONNECT privilege to a user (authorization identifier USER003, password HIRDB003) who will access tables:

 GRANT CONNECT TO USER003 IDENTIFIED BY HIRDB003

(2) Granting access privileges

Executor: Table owner

The GRANT statement, which is a definition SQL statement, is used by a table's owner to grant access privileges to users who will access the table.

Example 1

Grant only the SELECT privilege for a table (authorization-identifier.table-identifier USER002.T001) to a user (authorization identifier USER004) who is to be permitted only to make retrievals from the table:

 GRANT SELECT ON USER002.T001 TO USER004

Example 2

Grant the SELECT and UPDATE privileges for a table (authorization-identifier.table-identifier USER002.T001) to a user (authorization identifier USER005) who is to be permitted to retrieve and update the table:

 GRANT SELECT,UPDATE ON USER002.T001 TO USER005

Example 3

Grant the SELECT, UPDATE, and INSERT privileges for a table (authorization-identifier.table-identifier USER002.T001) to a user (authorization identifier USER006) who is to be permitted to retrieve, update, add to, and delete the table:

 GRANT ALL ON USER002.T001 TO USER006

Notes

A table owner can grant to another user only the access privileges to that table that the owner has been granted. Table 2-3 lists the access privileges granted to a table owner.

A table owner cannot grant to another user access privileges to a view table that was defined from a table that belongs to a different user.

Table 2-3 Table owner's access privileges

Type of table | Table owner's access privileges | Can provide access privileges?
Base table | All access privileges | Yes
Foreign table | All access privileges | Yes
Read-only view table defined from a base table or foreign table that belongs to the user¹ | SELECT privileges | Yes
Updatable view table defined from a base table or foreign table that belongs to the user² | All access privileges | Yes
Read-only view table defined from a base table or foreign table that belongs to another user1,3 | SELECT privileges | No
Updatable view table defined from a base table or foreign table that belongs to another user2,3 | All access privileges the user has for base tables or foreign tables | No

Legend:

Yes: The user can grant and revoke the access privileges of other users.

No: The user cannot grant or revoke the access privileges of other users.

Note

You can grant to other users only those access privileges to a foreign table that you have for the base table of that foreign table (table at a foreign server). If you attempt to grant access privileges you do not have, an error results.

¹ A read-only view table is a view table for which any of the following information is specified in the view definition:

DISTINCT, set function, literal, or arithmetic operation is specified in the SELECT clause.

The same base table column or foreign table column is specified in the SELECT clause more than once.

Tables are joined.

GROUP BY clause is specified.

HAVING clause is specified.

READ ONLY clause is specified.

² An updatable view table is a view table to which the read-only attribute is not assigned.

³ To define a view table from a table that belongs to another user, you must have SELECT privileges for that table.

2.3 Revoking user privileges

Organization of this section

(1) Revoking DBA privileges

(2) Revoking CONNECT privileges

(3) Revoking schema definition privileges

(4) Revoking RDAREA usage privileges

(5) Revoking access privileges

(1) Revoking DBA privileges

Executor: HiRDB administrator

The REVOKE statement, which is a definition SQL statement, is used to revoke the DBA privilege.

Example

Revoke the DBA privilege of the user who manages user privileges (authorization identifier: USER001):

 REVOKE DBA FROM USER001

(2) Revoking CONNECT privileges

Executor: HiRDB administrator or user who manages user privileges (user with DBA privilege)

The REVOKE statement, which is a definition SQL statement, is used to revoke the CONNECT privilege.

Example

Revoke the CONNECT privilege of the user whose authorization identifier is USER003:

 REVOKE CONNECT FROM USER003

(3) Revoking schema definition privileges

Executor: HiRDB administrator or user who manages user privileges (user with DBA privilege)

The REVOKE statement, which is a definition SQL statement, is used to revoke the schema definition privilege.

Example

Revoke the schema definition privilege of the user whose authorization identifier is USER002:

 REVOKE SCHEMA FROM USER002

Note

The schema definition privilege of a user who has defined a schema cannot be revoked. When a schema definition privilege is to be revoked, a check should be made to ensure that no schema has been defined by that user.

(4) Revoking RDAREA usage privileges

Executor: HiRDB administrator or user who manages user privileges (user with DBA privilege)

The REVOKE statement, which is a definition SQL statement, is used to revoke the RDAREA usage privilege.

Example

Revoke the RDAREA usage privilege for the RDAREA named RDAREA01 of the user whose authorization identifier is USER002:

 REVOKE RDAREA RDAREA01 FROM USER002

Note

The RDAREA usage privilege of a user who has defined a table or index in the specified RDAREA cannot be revoked. When an RDAREA usage privilege is to be revoked, a check should be made to ensure that no table or index has been defined in the RDAREA by that user.

(5) Revoking access privileges

Executor: Table owner

The REVOKE statement, which is a definition SQL statement, is used to revoke access privileges.

Example

Revoke the DELETE privilege for a table (authorization-identifier.table-identifier USER002.T001) that was granted to the user with authorization identifier USER004:

 REVOKE UPDATE ON USER002.T001 TO USER004

Note

When the SELECT table access privilege is revoked, all the user's view tables defined from that table are deleted.

2.4 Setting a referencing privilege for data dictionary tables

Executor: HiRDB administrator

To enhance system security, you can set a reference privilege for data dictionary tables in order to restrict access to the data dictionary tables. You set the reference privilege for data dictionary tables by specifying limited in the following utility control statements:

Database initialization utility: dicinf operand of define system statement

Database structure modification utility: dicinf operand of alter system statement

Table 2-4 shows the relationship between the dicinf operand value and the data dictionary tables that can be referenced.

Table 2-4 Relationship between the dicinf operand value and the data dictionary tables that can be referenced

Data dictionary table | dicinf operand value
limited | unlimited
DBA privilege holders | Auditor | General users
SQL_PHYSICAL_FILES | All | All | Table information about HiRDB files that comprise RDAREAs for which the general user has usage privileges. | All
SQL_RDAREAS | All | All | Table information about RDAREAs for which the general user has usage privileges. | All
SQL_TABLES | All¹ | All¹ | Table information about tables for which the general user has access privileges. | All
SQL_COLUMNS | All¹ | All¹ | Table information about columns in tables for which the general user has access privileges. | All
SQL_INDEXES | All¹ | All¹ | Table information about indexes for tables for which the general user has access privileges. | All
SQL_USERS | All | All | None | None
SQL_RDAREA_PRIVILEGES | All | All | Table information about RDAREAs for which the general user has access privileges. | All
SQL_TABLE_PRIVILEGES | All¹ | All¹ | Table information about tables for which the general user has access privileges. | All
SQL_DIV_TABLE | All¹ | All¹ | All
SQL_INDEX_COLINF | All¹ | All¹ | Table information about indexes for tables for which the general user has access privileges. | All
SQL_TABLE_STATISTICS | All | All | Table statistical information about tables for which the general user has access privileges. | All
SQL_COLUMN_STATISTICS | All | All | Column statistical information about tables for which the general user has access privileges. | All
SQL_INDEX_STATISTICS | All | All | Index statistical information about tables for which the general user has access privileges. | All
SQL_VIEW_TABLE_USAGE | All | All | Table information about view tables for which the general user has access privileges. | All
SQL_VIEWS | All | All | All
SQL_DIV_INDEX | All¹ | All¹ | Table information about indexes for tables for which the general user has access privileges. | All
SQL_DIV_COLUMN | All² | All² | Table information about tables for which the general user has access privileges. | All
SQL_REFERENTIAL_CONSTRAINTS | All | All | Constraint information about tables for which the general user has access privileges. | All
SQL_ALIASES | All | All | All | All
SQL_ROUTINES | All | All | All | All
SQL_ROUTINE_RESOURCES | All | All | All | All
SQL_ROUTINE_PARAMS | All | All | All | All
SQL_DATATYPES | All | All | All | All
SQL_DATATYPE_DESCRIPTORS | All | All | All | All
SQL_TABLE_RESOURCES | All | All | All | All
SQL_PLUGINS | All | All | All | All
SQL_PLUGIN_ROUTINES | All | All | All | All
SQL_PLUGIN_ROUTINE_PARAMS | All | All | All | All
SQL_REGISTRY | All | All | All | All
SQL_INDEX_TYPES | All | All | All | All
SQL_INDEX_DATATYPE | All | All | All | All
SQL_INDEX_FUNCTION | All | All | All | All
SQL_TYPE_RESOURCES | All | All | All | All
SQL_INDEX_RESOURCES | All | All | All | All
SQL_INDEX_TYPE_FUNCTION | All | All | All | All
SQL_EXCEPT | All¹ | All¹ | Table information about indexes for tables for which the general user has access privileges. | All
SQL_FOREIGN_SERVERS | All | All | Table information about foreign servers that can be accessed. | All
SQL_USER_MAPPINGS | All | All | Table mapping information given to the general user. | All
SQL_IOS_GENERATIONS | All | All | All | All
SQL_PARTKEY | All | All | Table information about tables for which the general user has access privileges. | All
SQL_PARTKEY_DIVISION | All | All | Table information about tables for which the general user has access privileges. | All
SQL_TRIGGERS | All | All | Table information about triggers defined by the general user. | All
SQL_TRIGGER_COLUMNS | All | All | All
SQL_TRIGGER_DEF_SOURCE | All | All | All
SQL_TRIGGER_USAGE | All | All | All
SQL_AUDITS | None | All | None | None
SQL_KEYCOLUMN_USAGE | All | All | Table information about tables for which the general user has access privileges. | All
SQL_TABLE_CONSTRAINTS | All | All | All
SQL_CHECKS | All | All | All
SQL_CHECK_COLUMNS | All | All | All
SQL_DIV_TYPE | All | All | All
SQL_SYSPARAMS | All | All | None | None

All: All columns can be referenced.

None: No columns can be referenced.

¹ The base table of the data dictionary table cannot be referenced.

² The base table of the data dictionary table can also be referenced.

3. Handling System Log Files

This chapter describes the procedures for handling the system log files.

This chapter contains the following sections:

Organization of this chapter

3.1 Basics

3.2 Unloading the system log

3.3 Operating without unloading the system log

3.4 Releasing checking of unload status

3.5 Procedures for manipulating system log files

3.6 Status changes of system log files

3.7 Changing the system log file record length

3.8 Using the automatic log unloading facility

3.9 Monitoring the free area for system log files

3.1 Basics

This section provides an overview of the system log files. The user must understand system log files before actually handling them.

Organization of this section

(1) System log is used for error recovery and tuning information

(2) HiRDB manages the system log files by status

(3) HiRDB administrator's task

(4) Status changes of system log files

(5) Selecting a system log file handling method

(6) When an error occurs in a system log file

(7) Commands used to manipulate system log files

(1) System log is used for error recovery and tuning information

Information about the updates made to the database (system log information) is stored in a system log file. This system log information is used for the following purposes:

If HiRDB or a UAP terminates abnormally, HiRDB uses the system log to recover the database and transactions.

If an error occurs in the database, the HiRDB administrator uses the system log in conjunction with the database recovery utility to recover the database. The system log provides the input to the database recovery utility.

When the HiRDB administrator performs system tuning, the system log is used as the input information for this tuning (input to the statistics analysis utility).

(2) HiRDB manages the system log files by status

HiRDB manages system log files according to the statuses listed in Table 3-1.

Table 3-1 System log file statuses

Status
Description

Current
File to which the system log is being output. There is always only one file in this status.

Standby (swappable)
File that is not currently the target file for output of the system log, but is available to be swapped in as the current file when any of the following occurs:
The existing current file reaches its capacity
An error occurs in the existing current file
The pdlogswap command is entered
All of the following conditions must be applicable to a file in this status.

Overwrite enabled
Status of a file that does not include the system log required for full system recovery (system log corresponding to the synchronization point dumps for the number of guaranteed-valid generations).

Unload completed
Status of a file whose acquired system log has been unloaded to an unload log file.

Extraction completed state (HiRDB Datareplicator)
Status of a file for which the HiRDB Datareplicator on the source machine has completely read the system log. This status is applicable only when the HiRDB Datareplicator is being used. With HiRDB, the extraction status is checked when a synchronization point dump is acquired. In other words, the extraction completed status results when the HiRDB Datareplicator on the source machine has completely read the system log and synchronization points have been generated.

Overwriting permitted status for online reorganization (HiRDB Staticizer Option)
Status of a file that does not include the system log required for update processing. This status is applicable when updatable online reorganization is being performed.

Standby (unswappable)
File to which the system log will not be output (file that will not become the current file). The current file is in post-swapping status. One of the following conditions must be satisfied for this status to result.

Overwrite disabled state
Status of a file that includes the system log required for full system recovery (system log corresponding to the synchronization point dumps for the number of guaranteed-valid generations).

Unload wait state
Status of a file whose acquired system log has not been unloaded to the unload log file.

Extracting status (HiRDB Datareplicator)
Status of a file for which the HiRDB Datareplicator on the source machine has not completely read the system log (unread data remains). This status is applicable only when the HiRDB Datareplicator is being used.

Overwriting denied status for online reorganization (HiRDB Staticizer Option)
Status of a file that includes the system log required for update processing. This status is applicable when updatable online reorganization is being performed.

Reserved
File to which the system log will not be output.

(3) HiRDB administrator's task

System log information is output during HiRDB operation. When one system log file is filled, the output destination is changed to another file whose status makes it a swappable target. When this happens, the current file is placed in unswappable target status and the selected swappable target file becomes the current file. This is called system log file swapping. Thus, the status of system log files changes during HiRDB operation.

The HiRDB administrator must operate the system log files so that a swappable file always exists. If file swapping is needed, but there are no swappable files available, HiRDB (the unit for a HiRDB/Parallel Server) terminates abnormally.

HiRDB provides a function for monitoring the free area for system log files. For details about this function, see 3.9 Monitoring the free area for system log files.

(4) Status changes of system log files

When HiRDB is operating, the status of the system log files changes as described below. It is assumed here that updatable online reorganization of the HiRDB Staticizer Option is not being used, which means that system log files will not be in overwriting permitted status for online organization or overwriting denied status for online reorganization. For details about the statuses of system log files when updatable online reorganization is being used, see the HiRDB Staticizer Option Version 7 Description and User's Guide.

(a) HiRDB is started normally

When HiRDB is started normally, all system log files for which ONL is specified with the pdlogadfg -d sys operand are opened. Of the opened files, the first file that was specified in the pdlogadfg operand becomes the current file, and the other opened files are placed in swappable target status. The files that did not open because of an opening error and files for which ONL was not specified are placed in reserved status. When HiRDB is restarted, the current file that was in effect during the previous session is inherited.

(b) File status changes when system log files are swapped

When the current file becomes full, the output destination changes to a file in swappable target status; i.e., system log files are swapped. When this happens, file status changes as follows:

(c) File status changes when a synchronization point dump is validated

When system log files are swapped, HiRDB executes synchronization point dump validation processing. Once the synchronization point dumps have been validated, the system log information collected prior to this validation processing is no longer needed for a HiRDB restart. When none of the system log information stored in the file is needed, the file status changes from overwrite disabled to overwrite enabled.

If a transaction is executing during synchronization point dump validation processing, the synchronization point dump will not be validated until the transaction has terminated.

(d) File status changes when system log information is unloaded or a system log file is released

The HiRDB administrator executes the operations described here.

When the pdlogunld command is executed to unload the system log information contained in a file that is in unload wait status, the file status changes from unload wait to unload completed. The system log information that is unloaded here can be used if it is necessary to recover the database.

If the system is being operated without unloading system log information and the pdlogchg -z command is executed to release a system log file, the file's status changes from unload wait to unload completed.

(e) File status changes when HiRDB Datareplicator at the extracted side completes extraction of system log information

When HiRDB Datareplicator at the extracted side completes extraction of system log information, the file's status changes from extracting status to extraction completed status.

Note

HiRDB checks the extraction status each time it acquires a synchronization point dump. A system log file is placed in extraction completed status at the next synchronization point after the system log has been read in its entirety by HiRDB Datareplicator at the extracted side.

(f) File is then placed in swappable target status

Because the file is now in the following statuses, it changes from being an unswappable target to a swappable target:

Overwrite enabled

Unload completed

Extraction completed status

The HiRDB administrator must handle the system log files in such a manner that there is always an available swappable target.

(5) Selecting a system log file handling method

There are different methods for handling the system log files, as shown in Table 3-2. The HiRDB administrator must select one of these methods.

Table 3-2 System log file handling methods

Operation
Handling method
Database recovery procedure

System log unloading*
Any file in unload wait status must be unloaded.
For details, see 3.2 Unloading the system log.
The database is recovered from a backup and unload log files.
The database can be restored to the point at which the backup was made or to any synchronization point since the backup was made.

Without unloading the system log
Any file in unload wait status is released (there is no need to unload it).
Backups must be made at each server.
For details, see 3.3 Operating without unloading the system log.
The database is recovered from a backup and the system log information acquired since the backup was made.
The database can be restored to the point at which the backup was made or to any synchronization point since the backup was made.

Releasing check of unload status
Because there are no files in unload wait status, there is no need to unload system log files.
For details, see 3.4 Releasing checking of unload status.
The database is recovered from a backup.
The database can be restored only to the point at which the backup was made.

* If the system switchover facility is being used, create an unload log file on a shared disk (character special file).

When an unload log file is created as a regular file, it must be shared by the primary and secondary systems. Therefore, in the case of HP-UX, JFS must be installed.

(6) When an error occurs in a system log file

For details on how to handle errors in system log files, see 18.6 Handling of system log file errors.

Frequently asked questions concerning system log file error handling procedures are answered in Q&A format in A.1 System log files.

(7) Commands used to manipulate system log files

Table 3-3 lists the commands that are provided for manipulating system log files. These commands are used by the HiRDB administrator.

Table 3-3 Commands used to manipulate system log files

Command
Description

pdloginit
Initializes a system log file.

pdlogls
Displays information about a system log file

pdlogunld

Unloads the contents of a system log file into an unload log file

Changes the system log file's status from unload wait to unload completed

pdlogchg
Forcibly places a system log file in the following statuses:

Unload completed

Extraction completed status

pdlogswap
Swaps system log files; places the current file in unswappable target status.

pdlogopen
Opens a system log file.
Places a reserved file in overwrite enabled status.

pdlogcls
Closes a system log file.
Places an overwrite enabled file in reserved status.

pdlogrm
Deletes a system log file.

3.2 Unloading the system log

Executor: HiRDB administrator

The pdlogunld command is used to unload into an unload log file the information needed for database recovery. In the event of an error in the database, the database recovery utility uses this unload log file to recover the database.

The HiRDB administrator must ensure than any file in unload wait status is unloaded.

Automatic log unloading facility

Normally, an unload log file is created by using the pdlogunld command to unload the system log files. This process can be automated by using the automatic log unloading facility. For details on the automatic log unloading facility, see 3.8 Using the automatic log unloading facility.

Note

If the system switchover facility is being used, create an unload log file on a shared disk (character special file).

When an unload log file is created as a regular file, it must be shared by the primary and secondary systems. Therefore, in the case of HP-UX, JFS must be installed.

Organization of this section

3.2.1 HiRDB/Single Server

3.2.2 HiRDB/Parallel Server

3.2.1 HiRDB/Single Server

Database recovery in the event of an error

If an error occurs in the database in the operating environment in which system logs are unloaded, the database is recovered from a backup copy and the unload log files that contain system log information collected since the backup was made. For details on the database recovery procedure, see 19. Database Recovery Procedures.

Example

Figure 3-1 shows the procedure for unloading a system log at a HiRDB/Single Server.

Figure 3-1 Procedure for unloading a system log (HiRDB/Single Server)

Notes

¹ The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 5 is explained in paragraph (5) below.

² Perform Steps 1 to 3 each time system log file swapping occurs.

Organization of this subsection

(1) Check the file status when the system log files are swapped

(2) Unload the system log

(3) Check the status of the system log file

(4) Swap the system log files

(5) Make a backup

(6) Check the status of the system log file

(7) Unload the system log

(1) Check the file status when the system log files are swapped

When a system log file becomes full, it is swapped with another file. When system log file swapping occurs, the KFPS01221-I and KFPS01222-I messages are output to the message log file and the syslogfile. The pdlogls command can be used to check the status of the system log file:

pdlogls -d sys

Explanation

Because the log01 file has been filled with the system log, the system log output destination changes from log01 to log02 (the system log files are swapped). As a result, log01 is placed in the following statuses:

Overwrite disabled

Unload wait

(2) Unload the system log

Use the pdlogunld command to unload the file (log01) that is in unload wait status.

pdlogunld -d sys -g log01 -o /unld/unldlog01

(3) Check the status of the system log file

The pdlogls command is used to check the status of the system log file (log01):

pdlogls -d sys

Explanation

Once the system log has been unloaded, the file status changes from unload wait to unload completed.

When the system log files are swapped, synchronization point dump validation processing is executed. When the synchronization point dumps have been validated, the file status changes from overwrite disabled to overwrite enabled.

As a result, the file status changes from unswappable target to swappable target.

Important

If system log file swapping occurs when there is no file in swappable target status, the HiRDB/Single Server terminates abnormally. For this reason, the HiRDB administrator must ensure that there is always available a file in swappable target status. When there are no files in swappable target status, HiRDB outputs the KFPS01224-I message to the message log file and to the syslogfile.

(4) Swap the system log files

Before a backup copy is made, the pdlogswap command is used to swap the system log files. System log files are swapped in order to physically separate the system logs needed for database restoration. The system log files storing the system log information needed for database restoration are those that become primary from this point on.

pdlogswap -d sys -w

(5) Make a backup

The pdcopy command (database copy utility) is used to back up all RDAREAs:

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode (r or s).

-a: Specifies that all RDAREAs are to be backed up.

-b: Specifies the name of the backup file.

Important

If the backup copy made in this step is used subsequently to recover the RDAREAs, the unload log files containing system log information subsequent to this current file are used as input to the database recovery utility.

(6) Check the status of the system log file

The pdlogls command is used to check the status of the system log file:

pdlogls -d sys

(7) Unload the system log

Use the pdlogunld command to unload the file (log02) that is in unload wait status.

pdlogunld -d sys -g log02 -o /unld/unldlog02

3.2.2 HiRDB/Parallel Server

Database recovery in the event of an error

If a database error occurs in the operating environment in which system logs are unloaded, the database is recovered from a backup copy and the unload log files that contain system log information collected since the backup was made. For details on the database recovery procedure, see 19. Database Recovery Procedures.

System log for a front-end server

System log information for a front-end server need not be unloaded because it is not required for database recovery. The specification pd_log_unload_check=N in the front-end server definition releases checking of system log file unload status for the front-end server. This eliminates the need to unload the front-end server's system log file. When pd_log_unload_check=N is not specified, one of the following actions must be taken for a file in unload wait status at the front-end server:

Execute the pdlogunld command to unload the system log information and place the file in unload completed status

Execute the pdlogchg command to forcibly change the file's status to unload completed

Example

Figure 3-2 shows the procedure for unloading a system log at a HiRDB/Parallel Server.

Figure 3-2 Procedure for unloading a system log (HiRDB/Parallel Server)

Notes

¹ The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 5 is explained in paragraph (5) below.

² Perform Steps 1 to 3 each time system log file swapping occurs.

Organization of this subsection

(1) Check the file status when the system log files are swapped

(2) Unload the system log

(3) Check the status of the system log file

(4) Swap the system log files

(5) Make a backup

(6) Check the status of the system log file

(7) Unload the system log

(1) Check the file status when the system log files are swapped

When a system log file becomes full, it is swapped with another file. When system log file swapping occurs, the KFPS01221-I and KFPS01222-I messages are output to the message log file and the syslogfile. The pdlogls command can be used to check the status of the system log file:

pdlogls -d sys -s bes1

Explanation

Because the log01 file has been filled with the system log, the system log output destination changes from log01 to log02 (the system log files are swapped). As a result, log01 is placed in the following statuses:

Overwrite disabled

Unload wait

(2) Unload the system log

Use the pdlogunld command to unload the file (log01) that is in unload wait status.

pdlogunld -d sys -s bes1 -g log01 -o /unld/unldlog01

(3) Check the status of the system log file

The pdlogls command is used to check the status of the system log file (log01):

pdlogls -d sys -s bes1

Explanation

Once the system log has been unloaded, the file status changes from unload wait to unload completed.

When the system log files are swapped, synchronization point dump validation processing is executed. When the synchronization point dumps have been validated, the file status changes from overwrite disabled to overwrite enabled.

As a result, the file status changes from unswappable target to swappable target.

Important

If system log file swapping occurs when there is no file in swappable target status, the unit terminates abnormally. For this reason, the HiRDB administrator must ensure that there is always available a file in swappable target status. When there are no files in swappable target status, HiRDB outputs the KFPS01224-I message to the message log file and to the syslogfile.

(4) Swap the system log files

Before a backup copy is made, the pdlogswap command is used to swap the system log files; in this example, the system log file for a back-end server (bes1) is swapped because the RDAREAs in bes1 are to be backed up.

System log files are swapped in order to physically separate the system logs needed for database restoration. The system log files storing the system log information needed for database restoration are those that become primary from this point on.

pdlogswap -d sys -s bes1 -w

(5) Make a backup

The pdcopy command (database copy utility) is used to back up in units of servers:

pdcopy -m /rdarea/mast/mast01 -M r -s bes1 -b /pdcopy/backup01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode (r or s).

-s: Specifies that all RDAREAs on back-end server bes1 are to be backed up.

-b: Specifies the name of the backup file.

Important

If the backup copy made in this step is used subsequently to recover the RDAREAs, the unload log files containing system log information subsequent to this current file are used as input to the database recovery utility.

(6) Check the status of the system log file

The pdlogls command is used to check the status of the system log file at the back-end server (bes1):

pdlogls -d sys -s bes1

(7) Unload the system log

Use the pdlogunld command to unload the file (log02) that is in unload wait status.

pdlogunld -d sys -s bes1 -g log02 -o /unld/unldlog02

3.3 Operating without unloading the system log

Executor: HiRDB administrator

When the system operating environment requires unloading of system log files, a filled system log file must be unloaded in timely fashion in order to be prepared for the possibility of a database error. This operating environment requires high CPU and input/output workload and complex actions by the HiRDB administrator. Alternatively, the database can be recovered from an error by using system log information as input to the database recovery utility without having to unload the system log. This operating environment is called operation without unloading the system log. Operation without unloading the system log has the following advantages.

Advantages

Because it is not necessary to unload system log information, the CPU and input/output workload are reduced and the HiRDB administrator's responsibilities are simplified.

There is no need to provide disk space for storing unload log files.

The HiRDB administrator does not need to unload files that are in unload wait status. However, the database must be backed up periodically, and the obtained log point information file must be used to release the system log files.

Log point concept

Operating without unloading the system log employs the log point concept.

When a database is to be recovered from an error, system log information obtained before a backup of the database was made is not needed. The point separating the needed system log information from the unneeded system log information is called a log point. A log point is set when a backup is made by the database copy utility.

When a log point is set during the backup operation by the database copy utility, the log point information shown in Figure 3-3 is output to the log point information file. This information is used to release the system log files.

Figure 3-3 Log point information

Explanation:

HiRDB identifier

Unit identifier

Type of log

Name of server at which log was acquired

LAN-ID of server at which log was acquired

LAN-ID of log server that set the log point information

Name of first file group that contains log information following the log point

Generation number of first file group that contains log information following the log point

Number of first block that contains log information following the log point

Number of times header was updated during allocation of the current file

Usage begin time

Organization of this section

3.3.1 HiRDB/Single Server

3.3.2 HiRDB/Parallel Server

3.3.1 HiRDB/Single Server

Backup acquisition units

A backup is made of the entire system (all RDAREAs). The obtained log point information file is used to release the system log files.

Backup acquisition interval

A backup should be made daily at a specified time.

The backup acquisition interval depends on the system log file size; the larger the system log file size, the longer the backup acquisition interval can be. The backup acquisition interval should be set so that the system will never run out of files in swappable target status.

Number of system log files

The total number of system log files should be more than double the number of system log files needed for one day.

For example, if two system log files are used per day, no fewer than four system log files should be provided.

Database recovery in the event of an error

If a database error occurs during operation without unloading the system log, the database must be recovered from its backup copy and the unload log files that contain system log information obtained since the backup was made. For details on the database recovery procedure, see 19. Database Recovery Procedures.

Example

Figure 3-4 shows the procedure for operation without unloading the system log at a HiRDB/Single Server.

Figure 3-4 Procedure for operation without unloading the system log (HiRDB/Single Server)

Note

The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 5 is explained in paragraph (5) below.

Organization of this subsection

(1) Swap the system log files

(2) Check the status of the system log file

(3) Make a backup

(4) Release the system log file

(5) Check the status of the system log file

(6) Check for files in swappable target status

(1) Swap the system log files

Before a backup copy is made, the pdlogswap command is used to swap the system log files.

System log files are swapped in order to physically separate the system logs needed for database restoration. The system log files storing the system log information needed for database restoration are those that become primary from this point on:

pdlogswap -d sys -w

(2) Check the status of the system log file

The pdlogls command is used to check the status of the system log file:

pdlogls -d sys

Explanation

Files log01 and log02 were used today, so these two files are in unload wait status.

Synchronization point dumps have been validated because the system log files were swapped by the pdlogswap -w command. In this manner, files log01 and log02 are placed in overwrite enabled status.

(3) Make a backup

The pdcopy command (database copy utility) is used to back up all RDAREAs; log point information is also obtained by specifying the -z option:

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01
-z /pdcopy/logpoint01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies r as the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up.

-b: Specifies the name of the backup file.

-z: Specifies the name of the log point information file.

In the event of an error in the log point information file

If an error occurs in the log point information file, it must be re-created using the backup file obtained in this step; the pdrstr -z command (database recovery utility) is used to re-create a log point information file:

pdrstr -b /pdcopy/backup01 -z /pdcopy/logpoint01

(4) Release the system log file

The pdlogchg command is used to release the system log files that predate the log point (log01 and log 02); the log point information file obtained in step (3) is specified in the -z option:

pdlogchg -z /pdcopy/logpoint01

(5) Check the status of the system log file

The pdlogls command is used to check the status of the system log file:

pdlogls -d sys

Explanation

Once the system log file has been released, the file status changes from unload wait to unload completed.

The file is now in overwrite enabled and unload completed status; therefore, it changes from unswappable target to swappable target.

(6) Check for files in swappable target status

The pdlogls command is used to check for files in swappable target status:

pdlogls -d sys

Important

If system log file swapping occurs when there is no file in swappable target status, the HiRDB/Single Server terminates abnormally. For this reason, the HiRDB administrator must ensure that there is always available a file in swappable target status.

When there is no file in swappable target status, HiRDB outputs the KFPS01224-I message to the message log file and the syslogfile.

3.3.2 HiRDB/Parallel Server

Backup acquisition units

A backup must be made at each back-end server and dictionary server. The log point information file obtained for each server is used to release the respective server's system log files.

Backup acquisition interval

Backups should be made daily at a specified time.

The backup acquisition interval depends on the system log file size; the larger the system log file size, the longer the backup acquisition interval can be. The backup acquisition interval should be set so that the system will never run out of files in swappable target status.

Number of system log files

The total number of system log files for each server should be more than double the number of system log files needed for one day by the server.

For example, if two system log files are used per day at a back-end server, no fewer than four system log files should be provided for that back-end server.

System log files for a front-end server

System log information for a front-end server is not needed for database recovery; therefore, pd_log_unload_check=N should be specified in the front-end server definition. When this specification is made, checking of system log file unload status is released for the front-end server. This eliminates the need to release the front-end server's system log files. When pd_log_unload_check=N is not specified, the pdlogchg command must be used at the front-end server to change the file status from unload wait to unload completed.

Database recovery in the event of an error

If a database error occurs during operation without unloading the system log, the database must be recovered from its backup copy and the unload log files that contain system log information obtained since the backup was made. For details on the database recovery procedure, see 19. Database Recovery Procedures.

Example

Figure 3-5 shows the procedure for operation without unloading the system log at a HiRDB/Parallel Server.

Figure 3-5 Procedure for operation without unloading the system log (HiRDB/Parallel Server)

Note

The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 5 is explained in paragraph (5) below.

Organization of this subsection

(1) Swap the system log files

(2) Check the status of the system log file

(3) Make a backup

(4) Release the system log file

(5) Check the status of the system log file

(6) Check for files in swappable target status

(1) Swap the system log files

Before a backup copy is made, the pdlogswap command is used to swap the system log files at the server that is to be backed up.

System log files are swapped in order to physically separate the system logs needed for database restoration. The system log files storing the system log information needed for database restoration are those that become primary from this point on:

pdlogswap -d sys -s bes1 -w

(2) Check the status of the system log file

The pdlogls command is used to check the status of the system log file:

pdlogls -d sys -s bes1

Explanation

Files log01 and log02 were used today, so these two files are in unload wait status.

Synchronization point dumps have been validated because the system log files were swapped by the pdlogswap -w command. In this manner, files log01 and log02 are placed in overwrite enabled status.

(3) Make a backup

The pdcopy command (database copy utility) is used to back up all RDAREAs in the back-end server (bes1); log point information is also obtained by specifying the -z option:

pdcopy -m /rdarea/mast/mast01 -M r -s bes1 -b /pdcopy/bes1bkup01
-z /pdcopy/bes1logp01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies r as the backup acquisition mode.

-s: Specifies that all RDAREAs in the back-end server (bes1) are to be backed up.

-b: Specifies the name of the backup file.

-z: Specifies the name of the log point information file.

In the event of an error in the log point information file

If an error occurs in the log point information file, it must be re-created using the backup file obtained in this step; the pdrstr -z command (database recovery utility) is used to re-create a log point information file:

pdrstr -b /pdcopy/bes1bkup01 -z /pdcopy/bes1logp01

(4) Release the system log file

The pdlogchg command is used to release the system log files that predate the log point (log01 and log02); the log point information file obtained in step (3) is specified in the -z option:

pdlogchg -z /pdcopy/bes1logp01 -x host01

(5) Check the status of the system log file

The pdlogls command is used to check the status of the system log file at the back-end server (bes1).

pdlogls -d sys -s bes1

Explanation

Once the system log file has been released, the file status changes from unload wait to unload completed.

The file is now in overwrite enabled and unload completed status; therefore, it changes from unswappable target to swappable target.

(6) Check for files in swappable target status

The pdlogls command is used to check for files in swappable target status:

pdlogls -d sys -s bes1
pdlogls -d sys -s bes2
pdlogls -d sys -s bes3
pdlogls -d sys -s bes4
pdlogls -d sys -s dic

Important

If system log file swapping occurs when there is no file in swappable target status, the unit terminates abnormally. For this reason, the HiRDB administrator must ensure that there is always available a file in swappable target status. When there is no file in swappable target status, HiRDB outputs the KFPS01224-I message to the message log file and the syslogfile.

3.4 Releasing checking of unload status

Executor: HiRDB administrator

HiRDB keeps track of the unload status of system log files and protects files in unload wait status from being overwritten. The HiRDB administrator is responsible for changing the status of such files to unload completed either by unloading them or by releasing them.

When system log information (unload logs) is not used for database recovery, neither the system log unload operation (execution of pdlogunld command) nor the system log release operation (execution of pdlogchg command) is necessary. In such a case, checking by HiRDB of the unload status of system logs should be released. This eliminates the system log file unload and release operations from the HiRDB administrator's responsibilities.

Organization of this section

(1) Swappable conditions

(2) Advantages

(3) Criteria

(4) Notes

(5) Environment setup

(6) Procedure

(7) In the event of an error in a system log file

(1) Swappable conditions

When checking of unload status has been released, there are only three swappable conditions:

Overwrite enabled

Extraction completed status (HiRDB Datareplicator)

Overwriting permitted status for online reorganization (HiRDB Staticizer Option)

The unload status is no longer used to determine whether a system log file is a swappable target.

(2) Advantages

Operations are simpler because the system log file unload and release operations are eliminated.

There is no need to provide space for storing unload log files.

(3) Criteria

This operating environment is used principally for referencing-based databases.

For example, this operating environment should be employed if a database can be recovered as described below without having to use system log information:

Database can be recovered simply by reloading the data.

Database can be recovered from a backup copy.

Data updated since the backup was made can be restored by reexecuting the UAPs or utilities.

HiRDB/Parallel Server

This operating environment can be applied to each server individually. This means that it can be used for any back-end server that satisfies the criteria.

There is never a need to unload system log information from a front-end server because such information is not required for database recovery. Therefore, this operating environment should always be used for a front-end server.

(4) Notes

(a) Database recovery

If this operating environment is used when system log information is needed for database recovery, it will not be possible to recover the database.

(b) System log file size

If one transaction updates a large amount of data, all system log files may be used by this transaction alone. In such a case, HiRDB prohibits overwriting of all system log files (places them in overwrite disabled status). As a result, there will be no system log file that can be allocated as the current file.

(c) Restrictions on the pdlogunld and pdlogchg commands

The following commands cannot be used while HiRDB is operating:

pdlogunld (except when the -f option is specified)

pdlogchg (except when the -R option is specified)

While HiRDB is inactive, these commands can be used normally (all options are available).

HiRDB must not be started while the pdlogunld or pdlogchg command is executing; otherwise, the pdlogunld or pdlogchg command may terminate with an error. An unload log file may be created even though the pdlogunld command has terminated with an error; however, such an unload log file cannot be used for database recovery.

(5) Environment setup

To use this operating environment, the following specification must be made in each server's definition in the HiRDB system definitions:

pd_log_unload_check=N

In the case of a HiRDB/Single Server, this operand is specified in the single server definition; in the case of a HiRDB/Parallel Server, this option is specified in the server common definition or in the following individual server definitions:

Front-end server definition

Back-end server definition

Dictionary server definition

(6) Procedure

The pdlogls command is used to check for files in swappable target status. There is no need to unload or release system log files.

Procedure for executing a database-updating UAP

Use the following procedure for executing a database-updating UAP.

Use the pdlogswap command to swap the system log files:
pdlogswap -d sys -s b001

Use the pdcopy command (database copy utility) to back up the RDAREAs:
pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01

Execute the UAP.

This procedure is not necessary if the data can be stored again in the table and the UAP and all other subsequent processing can be reexecuted.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(7) In the event of an error in a system log file

When an error occurs in a system log file, it is placed in standby status and will not be allocated as the current file during subsequent HiRDB operation. Erroneous system log files include not only files containing a physical error but also the following files:

When forced normal startup (pdstart dbdestroy or pdstart -i) is executed after an HiRDB abnormal termination, the system log file that was used as the current file during the previous HiRDB session.

When unit startup failed due to an error during normal startup processing, the system log file that was allocated as the current file during the previous startup processing (applicable to the server for which the current file was allocated before completion of startup).

An erroneous system log file cannot be allocated as the current file.

A system log file allocated as the current file during the previous HiRDB session can be reallocated as the current file by executing the pdlogchg or pdlogunld command.

It is possible for a system log file that contains a physical error to be allocated as the current file during the next HiRDB session by executing the pdlogchg or pdlogunld command. However, if an erroneous system log file is actually used as the current file, HiRDB will terminate abnormally. In such a case, the error must be corrected before the pdlogchg or pdlogunld command is executed.

3.5 Procedures for manipulating system log files

Executor: HiRDB administrator

This section describes the procedures for manipulating system log files. The following topics are covered:

Checking for files in swappable target status

When there is no file in swappable target status

Unloading the current file

Unloading a file in unload completed status

When the system log in a file in unload wait status is not needed

Changing a file's status

Increasing (or reducing) the system log file size during HiRDB operation

Adding a new system log file

Deleting a system log file

Organization of this section

3.5.1 Checking for files in swappable target status

3.5.2 When there is no file in swappable target status

3.5.3 Unloading the current file

3.5.4 Unloading a file in unload completed status

3.5.5 When the system log in a file in unload wait status is not needed

3.5.6 Changing a file's status

3.5.7 Increasing (or reducing) the system log file size during HiRDB operation

3.5.8 Adding a new system log file

3.5.9 Deleting a system log file

3.5.1 Checking for files in swappable target status

The pdlogls command is used to check for files in swappable target status.

If there is no file in swappable target status, one must be created; see 3.5.2 When there is no file in swappable target status for details.

If swapping of system log files occurs when there are no files in swappable target status, HiRDB (the unit for a HiRDB/Parallel Server) terminates abnormally. When there is no file in swappable target status, HiRDB outputs a message to that effect.

3.5.2 When there is no file in swappable target status

The pdlogls command is used to check for files in overwrite enabled status.

Organization of this subsection

(1) When there is a file in overwrite enabled status

(2) When there is no file in overwrite enabled status

(1) When there is a file in overwrite enabled status

If there is a file in overwrite enabled status, it should be placed in unload completed status, thus creating a file in swappable target status. There are two ways to change a file's status from unload wait to unload completed:

Use the pdlogunld command to unload the file

Use the pdlogchg command to discard the system log information in the file

Care must be exercised in executing the pdlogchg command on a file that contains system log information that is required for system or database recovery. If the file is overwritten, system log information required for system and database recovery will be lost, in which case it will not be possible to recover the database in the event of an error.

If you are using the HiRDB Datareplicator, you must release the extracting status. When you are using the updatable online reorganization function of the HiRDB Staticizer Option, you must release the overwriting denied status for online reorganization. If you do not release these statuses, it will not be possible for the file to be placed in swappable target status.

(2) When there is no file in overwrite enabled status

Add a system log file. For details, see 3.5.8 Adding a new system log file.

3.5.3 Unloading the current file

To unload the current file during database recovery, for example, execute the pdlogunld -f command. However, the status of the file may not change even though the pdlogunld -f command is executed.

3.5.4 Unloading a file in unload completed status

Use the procedure explained below to unload a file in unload completed status.

Procedure

Use the pdlogcls command to close the file to be unloaded (place it in reserved status).
pdlogcls -d sys -s b001 -g syslog01

Use the pdlogunld -f command to execute the unload function. Note that the status of the file will not change.
pdlogunld -d sys -s b001 -g syslog01 -f

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

3.5.5 When the system log in a file in unload wait status is not needed

If the system log in a file in unload wait status is not needed, the pdlogchg command can be used to change the file's status from unload wait to unload completed.

3.5.6 Changing a file's status

Organization of this subsection

(1) Changing the file used as the current file

(2) Placing a reserved file in overwrite enabled status

(3) Reserving a file in overwrite enabled status

(4) Changing a file from extracting status to extraction completed status

(5) Changing a file from overwriting denied status for online reorganization to operating permitted status for online reorganization

(1) Changing the file used as the current file

To use a different file as the current file, the pdlogswap command is executed to swap files. The current file is placed in unswappable target status, and a file in swappable target status becomes the current file. This command should be used when the system log information contained in the current file is needed.

The pdlogswap command cannot be executed if there are no files that can be placed in swappable target status.

(2) Placing a reserved file in overwrite enabled status

The pdlogopen command can be used to place a reserved file in overwrite enabled status. When normal startup of HiRDB is executed, such a file will become overwrite disabled.

(3) Reserving a file in overwrite enabled status

The pdlogcls command can be used to reserve a file that is in overwrite enabled status. If there is only one file in overwrite enabled status, it cannot be reserved. A file in overwrite disabled status must not be reserved if it contains system log information needed for system recovery.

(4) Changing a file from extracting status to extraction completed status

The pdlogchg -R command can be used to forcibly change a file's status from extracting to extraction completed. When the file status is changed forcibly in this manner, the system log required by the HiRDB Datareplicator cannot be extracted. Also, the file may not be synchronized to the target database, or data linkage may not be performed. You should execute the pdlogchg -R command only in cases such as when an error occurs and it is necessary to re-create the system log file. You should not execute the pdlogchg -R command in any other cases.

(5) Changing a file from overwriting denied status for online reorganization to operating permitted status for online reorganization

The pdlogchg -G command can be used to forcibly change a file from overwriting denied status for online reorganization to overwriting permitted status for online reorganization. When the file status is changed forcibly in this manner, the system log required for update processing will be lost, and it may not be possible to perform updatable online reorganization. You should execute the pdlogchg -G command only in cases such as when an error occurs and it is necessary to re-create the system log file. You should not execute the pdlogchg -R command in any other cases.

3.5.7 Increasing (or reducing) the system log file size during HiRDB operation

Use the procedure explained below to increase the system log file size.

Procedure

Use the pdlogs command to check the status of the system log files.
pdlogls -d sys -s b001

Use the pdlogcls command to reserve files that can be placed in swappable target status.
pdlogcls -d sys -s b001 -g syslog01

Use the pdlogrm command to delete reserved files.
pdlogrm -d sys -s b001 -f /sysfile01/syslog1a
pdlogrm -d sys -s b001 -f /sysfile01/syslog1b

Use the pdloginit command to re-create the system log files deleted in step 3.
In such a case, increase the record count to a value greater than that for the previous system log files. When reducing the file size, also reduce the record count.
pdloginit -d sys -s b001 -f /sysfile01/syslog1a -n 5000
pdloginit -d sys -s b001 -f /sysfile01/syslog1b -n 5000

Use the pdlogopen command to place the files created in step 4 in swappable target status.
pdlogopen -d sys -s b001 -g syslog01

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

Note

When you change files in swappable target status to reserved status, be sure not to change all of them. If swapping of system log files occurs when there are no files in swappable target status, HiRDB (or the unit for a HiRDB/Parallel Server) terminates abnormally. You should make sure that there is still at least one swappable target file when you change the system log file size.

3.5.8 Adding a new system log file

This section explains the procedure for adding a new system log file.

Before a system log file is added, it is recommended that the system log file design guidelines be reviewed; for details, see the manual HiRDB Version 8 Installation and Design Guide.

Organization of this subsection

(1) When HiRDB can be terminated normally

(2) When HiRDB cannot be terminated normally

(1) When HiRDB can be terminated normally

Procedure

Use the pdfstatfs command to check for free space in the HiRDB file system area for creating system log files.
pdfstatfs /sysfile01
If there is no free space, create a new HiRDB file system area. For details about creating a HiRDB file system area, see 10.2 Creating (initializing) a HiRDB file system area.

Use the pdstop command to terminate HiRDB normally.

Add one of the operands listed below to the HiRDB system definition. Specify in the operand the system log files added in step 4.
pdlogadfg -d sys operand
pdlogadpf -d sys operand

Use the pdloginit command to add (initialize) system log files.
pdloginit -d sys -s b001 -f /sysfile01/syslog1a -n 5000
pdloginit -d sys -s b001 -f /sysfile01/syslog1b -n 5000

Use the pdconfchk command to check the HiRDB system definition. If an error is detected, correct the HiRDB system definition.

Use the pdstart command to start HiRDB normally.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(2) When HiRDB cannot be terminated normally

You can use the pdchgconf system reconfiguration command to change the HiRDB system definition. However, HiRDB Advanced High Availability must have been installed to use this command.

Procedure

Use the pdfstatfs command to check for free space in the HiRDB file system area for creating system log files.
pdfstatfs /sysfile01
If there is no free space, create a new HiRDB file system area. For details about creating a HiRDB file system area, see 10.2 Creating (initializing) a HiRDB file system area.

Create the $PDDIR/conf/chgconf directory.

Copy the HiRDB system definition files being used to the directory created in step 2.

Add one of the following operands to the HiRDB system definition in the $PDDIR/conf/chgconf directory. Specify in this operand the system log files that will be added in step 5.
pdlogadfg -d sys operand
pdlogadpf -d sys operand

Use the pdloginit command to add (initialize) system log files.
pdloginit -d sys -s b001 -f /sysfile01/syslog1a -n 5000
pdloginit -d sys -s b001 -f /sysfile01/syslog1b -n 5000

Use the pdconfchk command to check the HiRDB system definition in the $PDDIR/conf/chgconf directory. If an error is detected, correct the HiRDB system definition and re-execute the pdconfchk command.

Use the pdchgconf command to replace the HiRDB system definition with the modified HiRDB system definition.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

Remarks

When you use the procedure described here to add system log files, the system log files are swapped while the pdchgconf command is being executed. If there are no files in swappable target status, an added system log file is swapped in.

3.5.9 Deleting a system log file

The pdlogrm command is used to delete a reserved system log file. Only a reserved system log file can be deleted.

Delete the operands listed below as necessary. Delete the operands corresponding to the system log files that were deleted using the pdlogrm command.

pdlogadfg -d sys operand

pdlogadpf -d sys operand

If these operands are not deleted, the deleted system log files will become virtual files.

3.6 Status changes of system log files

Tables 3-4 to 3-7 list the status changes for system log files while HiRDB is operating.

Remarks

The status transitions listed in these tables assume that the relevant events were processed normally.

HiRDB manages the status of system log files only while it is operating.

The status of system log files displayed by the pdlogls command does not change even if the pdlogunld or pdlogchg command is executed on reserved files. To view the status of the system log files, execute the pdlogopen command then execute the pdlogls command.

Table 3-4 Status changes of system log files while HiRDB is operating (part 1)

Event | Status of system log files
Current | Standby (unload wait)
Overwrite enabled | Overwrite disabled
Enable | Disable | Enable | Disable
C | I | C | I | C | I | C | I
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Swapping occurred when system log file area was full | 9 |  |  |  |  |  |  |  |
Error in current file caused file swapping to occur | Error occurred during nonduplexing, or error occurred in A and B systems during duplexing | 25 |  |  |  |  |  |  |  |
Error occurred in one system during duplexing | Single system can operate | 9 |  |  |  |  |  |  |  |
Single system cannot operate | 25 |  |  |  |  |  |  |  |
pdlogswap command was executed | 9 |  |  |  |  |  |  |  |
Validation of synchronization point dump |  |  |  |  |  | 2 | 3 | 4 | 5
Unloading by the automatic log unloading facility was completed |  | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17
All data extraction by HiRDB Datareplicator was completed |  |  | 2 |  | 4 |  | 6 |  | 8
Reading of all data in system log files by update processing of updatable online reorganization was completed (pd_log_org_reflected_logpoint=release is specified) |  |  |  | 2 | 3 |  |  | 6 | 7
Update processing of updatable online reorganization was completed |  |  |  | 2 | 3 |  |  | 6 | 7
Overwriting denied status for online reorganization was released by full detection of a system log file (pd_log_org_no_standby_file_opr=continue is specified) |  |  |  | 2 | 3 |  |  | 6 | 7
pdlogunld command was executed |  | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17
pdlogchg command was executed |  | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17
pdlogchg -R was executed |  |  | 2 |  | 4 |  | 6 |  | 8
pdlogchg -G was executed |  |  |  | 2 | 3 |  |  | 6 | 7
pdlogopen command was executed* |  |  |  |  |  |  |  |  |
pdlogcls command was executed* |  | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25

Legend:

Enable: Overwriting permitted status for online reorganization

Disable: Overwriting denied status for online reorganization

C: Extraction complete

I: Extraction incomplete

: Does not apply, or status does not change.

n: Status to which system log file changes after occurrence of the event.

For example, 1 indicates that after the event occurs, the status of the system log file changes to current (status No. 1).

Note: See Tables 3-5 to 3-7 for system log file status Nos. 10 and higher.

* Applies when the -a or -b option is not specified.

Table 3-5 Status changes of system log files while HiRDB is operating (part 2)

Event | Status of system log files
Standby (unload wait)
Overwrite enabled | Overwrite disabled
Enable | Disable | Enable | Disable
C | I | C | I | C | I | C | I
10 | 11 | 12 | 13 | 14 | 15 | 16 | 17
Swapping occurred when system log file area was full | 1 |  |  |  |  |  |  |
Error in current file caused file swapping to occur | Error occurred during nonduplexing, or error occurred in A and B systems during duplexing | 1 |  |  |  |  |  |  |
Error occurred in one system during duplexing | Single system can operate | 1 |  |  |  |  |  |  |
Single system cannot operate | 1 |  |  |  |  |  |  |
pdlogswap command was executed | 1 |  |  |  |  |  |  |
Validation of synchronization point dump |  |  |  |  | 10 | 11 | 12 | 13
Unloading by the automatic log unloading facility was completed |  |  |  |  |  |  |  |
All data extraction by HiRDB Datareplicator was completed |  | 10 |  | 12 |  | 14 |  | 16
Reading of all data in system log files by update processing of updatable online reorganization was completed (pd_log_org_reflected_logpoint=release is specified) |  |  | 10 | 11 |  |  | 14 | 15
Update processing of updatable online reorganization was completed |  |  | 10 | 11 |  |  | 14 | 15
Overwriting denied status for online reorganization was released by full detection of a system log file (pd_log_org_no_standby_file_opr=continue is specified) |  |  | 10 | 11 |  |  | 14 | 15
pdlogunld command was executed |  |  |  |  |  |  |  |
pdlogchg command was executed |  |  |  |  |  |  |  |
pdlogchg -R was executed |  | 10 |  | 12 |  | 14 |  | 16
pdlogchg -G was executed |  |  | 10 | 11 |  |  | 14 | 15
pdlogopen command was executed* |  |  |  |  |  |  |  |
pdlogcls command was executed* | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33

Legend:

Enable: Overwriting permitted status for online reorganization

Disable: Overwriting denied status for online reorganization

C: Extraction complete

I: Extraction incomplete

: Does not apply, or status does not change.

n: Status to which system log file changes after occurrence of the event.

For example, 1 indicates that after the event occurs, the status of the system log file changes to current (status No. 1).

Note: See Table 3-4 for system log file status Nos. 1-9 and Tables 3-6 and 3-7 for system log file status Nos. 18 and higher.

* Applies when the -a or -b option is not specified.

Table 3-6 Status changes of system log files while HiRDB is operating (part 3)

Event | Status of system log files
Reserved and unload wait state
Overwrite enabled | Overwrite disabled
Enable | Disable | Enable | Disable
C | I | C | I | C | I | C | I
18 | 19 | 20 | 21 | 22 | 23 | 24 | 25
Swapping occurred when system log file area was full |  |  |  |  |  |  |  |
Error in current file caused file swapping to occur | Error occurred during nonduplexing, or error occurred in A and B systems during duplexing |  |  |  |  |  |  |  |
Error occurred in one system during duplexing | Single system can operate |  |  |  |  |  |  |  |
Single system cannot operate |  |  |  |  |  |  |  |
pdlogswap command was executed |  |  |  |  |  |  |  |
Validation of synchronization point dump |  |  |  |  | 18 | 19 | 20 | 21
Unloading by the automatic log unloading facility was completed | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33
All data extraction by HiRDB Datareplicator was completed |  | 18 |  | 20 |  | 22 |  | 24
Reading of all data in system log files by update processing of updatable online reorganization was completed (pd_log_org_reflected_logpoint=release is specified) |  |  | 18 | 19 |  |  | 22 | 23
Update processing of updatable online reorganization was completed |  |  | 18 | 19 |  |  | 22 | 23
Overwriting denied status for online reorganization was released by full detection of a system log file (pd_log_org_no_standby_file_opr=continue is specified) |  |  | 18 | 19 |  |  | 22 | 23
pdlogunld command was executed | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33
pdlogchg command was executed | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33
pdlogchg -R was executed |  | 18 |  | 20 |  | 22 |  | 24
pdlogchg -G was executed |  |  | 18 | 19 |  |  | 22 | 23
pdlogopen command was executed* | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
pdlogcls command was executed* |  |  |  |  |  |  |  |

Legend:

Enable: Overwriting permitted status for online reorganization

Disable: Overwriting denied status for online reorganization

C: Extraction complete

I: Extraction incomplete

: Does not apply, or status does not change.

n: Status to which system log file changes after occurrence of the event.

For example, 1 indicates that after the event occurs, the status of the system log file changes to current (status No. 1).

Note: See Tables 3-4 and 3-5 for system log file status Nos. 1-17 and Table 3-7 for system log file status Nos. 26 and higher.

* Applies when the -a or -b option is not specified.

Table 3-7 Status changes of system log files while HiRDB is operating (part 4)

Event | Status of system log files
Reserved and unload wait state
Overwrite enabled | Overwrite disabled
Enable | Disable | Enable | Disable
C | I | C | I | C | I | C | I
26 | 27 | 28 | 29 | 30 | 31 | 32 | 33
Swapping occurred when system log file area was full |  |  |  |  |  |  |  |
Error in current file caused file swapping to occur | Error occurred during nonduplexing, or error occurred in A and B systems during duplexing |  |  |  |  |  |  |  |
Error occurred in one system during duplexing | Single system can operate |  |  |  |  |  |  |  |
Single system cannot operate |  |  |  |  |  |  |  |
pdlogswap command was executed |  |  |  |  |  |  |  |
Validation of synchronization point dump |  |  |  |  | 26 | 27 | 28 | 29
Unloading by the automatic log unloading facility was completed |  |  |  |  |  |  |  |
All data extraction by HiRDB Datareplicator was completed |  | 26 |  | 28 |  | 30 |  | 32
Reading of all data in system log files by update processing of updatable online reorganization was completed (pd_log_org_reflected_logpoint=release is specified) |  |  | 26 | 27 |  |  | 30 | 31
Update processing of updatable online reorganization was completed |  |  | 26 | 27 |  |  | 30 | 31
Overwriting denied status for online reorganization was released by full detection of a system log file (pd_log_org_no_standby_file_opr=continue is specified) |  |  | 26 | 27 |  |  | 30 | 31
pdlogunld command was executed |  |  |  |  |  |  |  |
pdlogchg command was executed |  |  |  |  |  |  |  |
pdlogchg -R was executed |  | 26 |  | 28 |  | 30 |  | 32
pdlogchg -G was executed |  |  | 26 | 27 |  |  | 30 | 31
pdlogopen command was executed* | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17
pdlogcls command was executed* |  |  |  |  |  |  |  |

Legend:

Enable: Overwriting permitted status for online reorganization

Disable: Overwriting denied status for online reorganization

C: Extraction complete

I: Extraction incomplete

: Does not apply, or status does not change.

n: Status to which system log file changes after occurrence of the event.

For example, 1 indicates that after the event occurs, the status of the system log file changes to current (status No. 1).

Note: See Tables 3-4 to 3-6 for system log file status Nos. 1-25.

* Applies when the -a or -b option is not specified.

3.7 Changing the system log file record length

Executor: HiRDB administrator

The system log file record length can be changed. The record length must be 1024, 2048, or 4096 bytes. The system log size can be reduced by selecting a short record length.

The current record length can be determined by executing the pdlogls command.

Notes

The same record length must be set for all system log files.

When 1024 or 2048 is specified as the system log file record length, that record length must be specified in the pd_log_rec_leng operand. A system log file cannot be opened if its record length does not match the length specified in the pd_log_rec_leng operand.

Organization of this section

3.7.1 Example 1 (system log unloading operation)

3.7.2 Example 2 (operation without unloading the system log)

3.7.1 Example 1 (system log unloading operation)

This example changes the system log file record length from 4096 bytes to 1024 bytes.

Conditions

HiRDB is in normally terminated status.

If data is linked to HiRDB Datareplicator, HiRDB Datareplicator has been terminated after all data has been extracted from the most recent system log file.

Procedure

Organization of this subsection

(1) Start HiRDB with the pdstart -r command

(2) Back up all RDAREAs with the pdcopy command

(3) Terminate HiRDB normally with the pdstop command

(4) Unload the system log file in unload wait status with the pdlogunld command

(5) Add the pd_log_rec_leng operand

(6) Delete system log files with the pdlogrm command

(7) Re-create system log files with the pdloginit command

(8) Start HiRDB with the pdstart command

(1) Start HiRDB with the pdstart -r command

pdstart -r

(2) Back up all RDAREAs with the pdcopy command

pdcopy -m /rdarea/mast/mast01 -M x -a -b /pdcopy/backup01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode. Because pdstart -r was used to start HiRDB, there is no need to place the RDAREAs in shutdown and closed status even if x is specified.

-a: Specifies that all RDAREAs are to be backed up.

-b: Specifies the name of the backup file.

(3) Terminate HiRDB normally with the pdstop command

pdstop

(4) Unload the system log file in unload wait status with the pdlogunld command

pdlogunld -d sys -g log1 -o /unld/unldlog1

(5) Add the pd_log_rec_leng operand

The pd_log_rec_leng operand must be added as follows in the server definition:

       :
set pd_log_rec_leng = 1024
         :

Explanation

Specifies the system log file record length (1024).

(6) Delete system log files with the pdlogrm command

pdlogrm -d sys -f /sysfile_a/log1a
pdlogrm -d sys -f /sysfile_b/log1b
pdlogrm -d sys -f /sysfile_a/log2a
pdlogrm -d sys -f /sysfile_b/log2b
pdlogrm -d sys -f /sysfile_a/log3a
pdlogrm -d sys -f /sysfile_b/log3b
pdlogrm -d sys -f /sysfile_a/log4a
pdlogrm -d sys -f /sysfile_b/log4b

Explanation

When dual system log files are being used, the B versions of the system log files must also be deleted.

(7) Re-create system log files with the pdloginit command

pdloginit -d sys -f /sysfile_a/log1a -n 2000 -l 1024
pdloginit -d sys -f /sysfile_b/log1b -n 2000 -l 1024
pdloginit -d sys -f /sysfile_a/log2a -n 2000 -l 1024
pdloginit -d sys -f /sysfile_b/log2b -n 2000 -l 1024
pdloginit -d sys -f /sysfile_a/log3a -n 2000 -l 1024
pdloginit -d sys -f /sysfile_b/log3b -n 2000 -l 1024
pdloginit -d sys -f /sysfile_a/log4a -n 2000 -l 1024
pdloginit -d sys -f /sysfile_b/log4b -n 2000 -l 1024

Explanation

Specifies the new record length (1024) in the -l option.

(8) Start HiRDB with the pdstart command

pdstart

If data is linked to HiRDB Datareplicator, HiRDB Datareplicator must also be started.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

3.7.2 Example 2 (operation without unloading the system log)

This example changes the system log file record length from 4096 bytes to 1024 bytes.

Conditions

HiRDB is in normally terminated status.

If data is linked to HiRDB Datareplicator, HiRDB Datareplicator has been terminated after all data has been extracted from the most recent system log file.

Procedure

Organization of this subsection

(1) Start HiRDB with the pdstart command

(2) Back up all RDAREAs with the pdcopy command

(3) Terminate HiRDB normally with the pdstop command

(4) Release the system log in unload wait status with the pdlogchg command

(5) Add the pd_log_rec_leng operand

(6) Delete system log files with the pdlogrm command

(7) Re-create system log files with the pdloginit command

(8) Start HiRDB with the pdstart command

(9) Back up all RDAREAs with the pdcopy command

(1) Start HiRDB with the pdstart command

pdstart

(2) Back up all RDAREAs with the pdcopy command

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01
-z /pdcopy/logpoint01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. In the case of a HiRDB/Parallel Server, data cannot be backed up by specifying -a; instead, -s must be specified to back up RDAREAs in units of servers.

-b: Specifies the name of the backup file.

-z: Specifies the name of the log point information file.

(3) Terminate HiRDB normally with the pdstop command

pdstop

(4) Release the system log in unload wait status with the pdlogchg command

pdlogchg -d sys -g log1 -z /pdcopy/logpoint01

(5) Add the pd_log_rec_leng operand

The pd_log_rec_leng operand must be added as follows in the server definition:

         :
set pd_log_rec_leng = 1024
         :

Explanation

Specifies the system log file record length (1024).

(6) Delete system log files with the pdlogrm command

pdlogrm -d sys -f /sysfile_a/log1a -u
pdlogrm -d sys -f /sysfile_b/log1b -u
pdlogrm -d sys -f /sysfile_a/log2a -u
pdlogrm -d sys -f /sysfile_b/log2b -u
pdlogrm -d sys -f /sysfile_a/log3a -u
pdlogrm -d sys -f /sysfile_b/log3b -u
pdlogrm -d sys -f /sysfile_a/log4a -u
pdlogrm -d sys -f /sysfile_b/log4b -u

Explanation

Specify -u for the forced deletion option.

When dual system log files are being used, the B versions of the system log files must also be deleted.

(7) Re-create system log files with the pdloginit command

pdloginit -d sys -f /sysfile_a/log1a -n 2000 -l 1024
pdloginit -d sys -f /sysfile_b/log1b -n 2000 -l 1024
pdloginit -d sys -f /sysfile_a/log2a -n 2000 -l 1024
pdloginit -d sys -f /sysfile_b/log2b -n 2000 -l 1024
pdloginit -d sys -f /sysfile_a/log3a -n 2000 -l 1024
pdloginit -d sys -f /sysfile_b/log3b -n 2000 -l 1024
pdloginit -d sys -f /sysfile_a/log4a -n 2000 -l 1024
pdloginit -d sys -f /sysfile_b/log4b -n 2000 -l 1024

Explanation

Specifies the new record length (1024) in the -l option.

(8) Start HiRDB with the pdstart command

pdstart

If data is linked to HiRDB Datareplicator, HiRDB Datareplicator must also be started.

(9) Back up all RDAREAs with the pdcopy command

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02
-z /pdcopy/logpoint02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. In the case of a HiRDB/Parallel Server, data cannot be backed up by specifying -a; instead, -s must be specified to back up RDAREAs in units of servers.

-b: Specifies the name of the backup file.

-z: Specifies the name of the log point information file.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

3.8 Using the automatic log unloading facility

Executor: HiRDB administrator

Unloading system log files means that the pdlogunld command is entered to unload system log files that are waiting to be unloaded. If this step is skipped, there will be no system log files that are eligible to be swapped in (swappable target status files) and HiRDB will terminate abnormally.

HiRDB provides a facility, called the automatic log unloading facility, for unloading system log files automatically. If frequent unloading of system log files is anticipated, use of the automatic log unloading facility should be considered.

This section assumes that the reader is familiar with the system log unloading operations.

Organization of this section

3.8.1 Overview of automatic log unloading facility

3.8.2 Environment setup

3.8.3 Application example 1 (using a single directory for unload log files)

3.8.4 Application example 2 (using two directories for unload log files)

3.8.5 Application example 3 (making a backup)

3.8.6 Creating a time series list of unload log files (identifying the unload log files required for database restoration)

3.8.7 Error handling

3.8.8 Notes on HiRDB termination

3.8.1 Overview of automatic log unloading facility

When the automatic log unloading facility is used, HiRDB unloads automatically the system log files that are waiting to be unloaded. Unload log files are created under a directory created in advance by the HiRDB administrator (this directory is called the directory for unload log files). Figure 3-6 shows the operation of the automatic log unloading facility.

Figure 3-6 Automatic log unloading facility

Explanation

When a system log file in unload wait status is generated, it is unloaded automatically. Unload log files are created under the directory for unload log files.

The HiRDB administrator should transfer the unload log files to a separate medium at regular intervals.

When multiple directories for unload log files are created, the output destination of unload log files is switched to another directory whenever one directory's disk becomes full.

Organization of this subsection

(1) HiRDB administrator's tasks

(2) Relationship to other facilities

(3) Names of created unload log files

(4) When multiple directories for unload log files are created

(1) HiRDB administrator's tasks

The automatic log unloading facility stops operating when unload log files cannot be created in the directory for unload log files because of a full disk, disk error, etc. To prevent this from happening, the HiRDB administrator should transfer the unload log files in the directory for unload log files to a separate medium on a regular basis. At the same time, unneeded unload log files should be deleted.

When multiple directories for unload log files are created, the automatic log unloading facility stops only when unload log files cannot be created in any of the directories.

(2) Relationship to other facilities

The automatic log unloading facility cannot be used when HiRDB is not set to check the unload status of system log files (when pd_log_unload_check = N is specified).

(3) Names of created unload log files

The format of the names of the unload log files that are created by the automatic log unloading facility is shown below (the names of created unload log files are displayed in the KFPS01212-I message):

server-name_server-run-ID-and-generation-number_file-group-name

Example

The names of unload log files created by the automatic log unloading facility can be checked by entering the pdlogatul command.

(4) When multiple directories for unload log files are created

When there are multiple unload log file directories, unload log files that cannot be created in one directory because of a full disk, disk error, etc., are created in another directory. HiRDB selects the directories to be used in the order of their specification in the pd_log_auto_unload_path operand.

For example, if pd_log_auto_unload_path = "Directory 1","Directory 2","Directory 3",... is specified, HiRDB uses Directory 1 first, then Directory 2, then Directory 3, etc. However, if Directory 2 is not available because of a disk error, etc., Directory 3 is used after Directory 1.

When HiRDB is started normally, Directory 1 is used first, assuming that there are no unload log files in Directory 1. If Directory 1 contains unload log files, Directory 2 is used.

When HiRDB is restarted, the directory that was being used when HiRDB was terminated is used.

Note

You should note the following point when you create multiple directories for unload log files:

If no empty directory is available when HiRDB is started normally, the automatic log unloading facility stops operating.

3.8.2 Environment setup

To use the automatic log unloading facility, the following environment settings are required:

Creation of directories for unload log files

Specification of pd_log_auto_unload_path operand

Organization of this subsection

(1) Creation of directories for unload log files

(2) Specification of the pd_log_auto_unload_path operand

(1) Creation of directories for unload log files

The HiRDB administrator creates directories for unload log files. It is wise to check the availability of disk space before creating a directory. If the amount of available disk space is small, creation of the directory may result in a disk space shortage.

A HiRDB file system area for utilities must be created in order to create a directory for unload log files in an HiRDB file system area.

(a) Required disk space

The required disk space can be determined from the following formula:

Required disk space (bytes) =

total-number-of-records-in-system-log-files-to-be-unloaded

system-log-file-record-length

number-of-unload-log-files-to-be-created-in-directories 1.2

Notes

Note that the disk space requirement computed here is not for a single directory; it is the total disk space requirement for all directories if multiple directories are created.

When the disk space available for a single directory is not adequate, multiple directories should be created.

(b) Number of directories for unload log files

Although 128 directories for unload log files can be created, creating too many is not advisable. Four directories at the most are recommended so that their management does not become cumbersome. While a single directory is easy to manage, the automatic log unloading facility will stop if the disk becomes full or an error occurs.

When multiple directories are available, the automatic log unloading facility does not stop as long as unload log files can be created in at least one of the directories. For this reason, the directories should be created in different partitions.

(c) Important

In a multi-HiRDB configuration, different sets of directories must be created for the different HiRDBs. If the same directory is specified for more than one HiRDB, it may not be possible to determine the HiRDB to which each unload log file belongs.

Files other than unload log files must not be created in a directory for unload log files. If other types of files are created in such a directory, HiRDB may delete those files.

(d) Creating unload log files in a HiRDB file system area

To create unload log files in a HiRDB file system area, a HiRDB file system area must be created with the pdfmkfs command. Table 3-8 provides guidelines for the options that are specified in the pdfmkfs command.

Table 3-8 Guidelines for options to be specified in the pdfmkfs command (when unload log files are to be created in a HiRDB file system area)

pdfmkfs command option
Specification guideline

-k
Specify UTL as the usage objective.

-n
For the HiRDB file system area length, specify the value determined by the following formula:
total-number-of-records-in-system-log-files-to-be-unloaded
system-log-file-record-length
number-of-unload-log-files-to-be-created 1.2 1048576​

-l
For the maximum files count, specify the number of unload log files to be created.

-e
For the maximum increments count, specify the number of unload log files to be created 10.

(2) Specification of the pd_log_auto_unload_path operand

Specify in the pd_log_auto_unload_path operand the directories that have been created for unload log files.

When unload log files are to be created in an HiRDB file system area, specify the name of the HiRDB file system area.

3.8.3 Application example 1 (using a single directory for unload log files)

In this application example, a single directory for unload log files is provided.

This directory for unload log files stores one week's worth of unload log files, so the unload log files are transferred to another medium once a week. Thus, unload log files are transferred to another medium on a regular basis.

3.8.4 Application example 2 (using two directories for unload log files)

In this application example, the automatic log unloading facility operates under the following conditions:

Two directories for unload log files have been created.

When the directories are switched because one of them has become full, the unload log files in the full directory are transferred to another medium.

Organization of this subsection

(1) When a disk becomes full, the directory for unload log files is changed

(2) Transferring all unload log files in a directory to another medium

(1) When a disk becomes full, the directory for unload log files is changed

When a disk becomes full, the destination directory is switched to Directory 2 for unload log files. When this occurs, the KFPS01151-I message is output:

KFPS01151-I bes1 changed auto log unload directory from /unlddir1/bes1
to /unlddir2/bes1.reason=1665

Explanation

The directory for unload log files has been switched from /unlddir1/bes1 to /unlddir2/bes1.

(2) Transferring all unload log files in a directory to another medium

Move all the unload log files in /unlddir1/bes1 onto another medium.

Repetitions of steps (1) and (2) are used to transfer unload log files to other media.

3.8.5 Application example 3 (making a backup)

In this application example, a backup is made. The procedure is the same regardless of the number of directories for unload log files that are used.

Organization of this subsection

(1) Verifying that the automatic log unloading facility is operating

(2) Swapping system log files

(3) Verifying that unloading of the system log has been completed

(4) Making a backup of all RDAREAs with the pdcopy command

(5) Checking the name of the unload log file for the current system log files

(1) Verifying that the automatic log unloading facility is operating

Enter the pdlogatul command to verify that the automatic log unloading facility is operating (in the case of a HiRDB/Parallel Server, you must perform this check at all servers for which the backup is to be made):

pdlogatul -d sys

HOSTNAME:host01(105321)
SERVER_NAME:sds1
AUTO_LOG_UNLOAD  NOW_UNLOAD_LOG_GROUP  CREATE_DIR
        ACTIVE               logfg02  /unlddir1/bes1
CURRENT LOG GENERATION INFO.
LOG_GROUP  GEN_NO. SERVER_RUN_ID RUN_ID    UNLOAD_FILE_NAME
logfg03        15   3a765d82      3a765d6d  sds1_3a765d820015_logfg03

Explanation

AUTO_LOG_UNLOAD

Indicates whether or not the automatic log unloading facility is operating. ACTIVE indicates that the facility is operating.

NOW_UNLOAD_LOG_GROUP

Shows the file group name of system log files that are being unloaded. **** is displayed if no files are being unloaded.

CREATE_DIR

Shows the name of the directory for unload log files that is currently being used. In this example, /unlddir1/bes1 is being used.

LOG_GROUP

Shows the file group name of the current system log files.

GEN_NO

Shows the generation number of the current system log files.

SERVER_RUN_ID

Shows the server run ID of the current system log files.

RUN_ID

Shows the run ID of the current system log files.

UNLOAD_FILE_NAME

Shows the unload log file name when the current system log files are unloaded by the automatic log unloading facility.

(2) Swapping system log files

Before a backup is made, use the pdlogswap command to swap the system log files. In the case of a HiRDB/Parallel Server, swap the system log files on all servers for which the backup is to be made.

System log files are swapped in order to physically separate the system log information needed for database restoration. The system log files storing the system log information needed for database restoration are those that become primary from this point on.

pdlogswap -d sys -w

(3) Verifying that unloading of the system log has been completed

Enter the pdlogls command to check the status of the system log files (in the case of a HiRDB/Parallel Server, check the status of the system log files at all servers for which the backup is to be made):

pdlogls -d sys

HOSTNAME : host01(153027)
Group    Type Server   Gen No. Status  Run ID    Block No.
logfg01  sys  sds1           13 os----u 3a765d6d      eff      fc8
logfg02  sys  sds1           14 os----u 3a765d6d      fc9     1092
logfg03  sys  sds1           15 osu-b-u 3a765d6d     1093     115b
logfg04  sys  sds1           16 oc-d--u 3a765d6d     115c     1226

Explanation

A file for which u is displayed in the third column under Status is a system log file waiting to be unloaded. When a file's unloading is completed, - is displayed. In this example, file logfg03 is waiting to be unloaded.

Wait until there are no more system log files waiting to be unloaded (i.e., execute the pdlogls command until all system log files have been unloaded).

(4) Making a backup of all RDAREAs with the pdcopy command

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01
-z /pdcopy/logpoint01 -p /pdcopylist/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing-permitted mode as the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up.

-b: Specifies the name of the backup file.

-z: Specifies the name of the log point information file.

-p: Specifies the file name for the pdcopy command's processing results listing.

Remarks

Specifying the -z option is recommended when the automatic log unloading facility is being used. When the -z option is specified, the following information is output in LOG FILE INFORMATION of the pdcopy command's processing results listing:

Name of the server for which the backup was made (SERVER NAME)

Server run ID when the backup was made (SERVER RUN ID)

Generation number of the current system log files when the backup was made (GENERATION NO)

File group name of the current system log files when the backup was made (FILE NAME)

This information makes it possible to identify the unload log file name for the current system log files when the backup was made. Based on this unload log file name, the unload log files required for database restoration are identified. For details on how to identify the unload log files required for database restoration, see 3.8.6 Creating a time series list of unload log files (identifying the unload log files required for database restoration).

Note that because the -z option cannot be specified in the cases listed below, you must in these cases perform the operation explained in (5) below to determine the unload log file name for the current system log files when a backup was made:

HiRDB was started with the pdstart -r command

Backup is not made on a server-by-server basis

(5) Checking the name of the unload log file for the current system log files

Use the pdlogatul command to check the name of the unload log file for the current system log files (in the case of a HiRDB/Parallel Server, perform this check for all servers for which backup is made):

pdlogatul -d sys

HOSTNAME:host01(105528)
SERVER_NAME:sds1
AUTO_LOG_UNLOAD  NOW_UNLOAD_LOG_GROUP  CREATE_DIR
        ACTIVE                  ****  /unlddir1/bes1
CURRENT LOG GENERATION INFO.
LOG_GROUP  GEN_NO.  SERVER_RUN_ID  RUN_ID    UNLOAD_FILE_NAME
logfg04        16   3a765d82       3a765d6d  sds1_3a765d820016_logfg04

Explanation

UNLOAD_FILE_NAME

Shows the unload log file name when the current system log files are unloaded by the automatic log unloading facility.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

3.8.6 Creating a time series list of unload log files (identifying the unload log files required for database restoration)

To restore a database, it is necessary to specify in the pdrstr command the unload log files in time series (according to generations). Therefore, before transferring the unload log files to another medium, create a time series list of unload log files. When the database is restored, refer to this list to identify the required unload log files.

This section explains how to create a time series list of unload log files and how to identify the unload log files required for database restoration.

Organization of this subsection

(1) When a single directory for unload log files is used

(2) When multiple directories for unload log files are used

(3) When unload log files are not arranged in time series order

(4) Notes

(1) When a single directory for unload log files is used

Because the names of the unload log files created by the automatic log unloading facility are in the format shown below, the unload log files in the directory for unload log files are arranged in time series order:

server-name_server-run-ID-and-generation-number_file-group-name

Figure 3-7 shows how to create a time series list of unload log files.

Figure 3-7 Creating a time series list of unload log files (using a single directory for unload log files)

Explanation

The files in the directory for unload log files is added to the time series list of unload log files without modification.

Example (identifying the unload log files required for database restoration)

The following is assumed for this example: the server run ID of the system log files when the backup was made was 3a765d82, the generation number was 12, and the file group name was logfg04. The unload log files required for database restoration under these assumptions are identified from the time series list.

The time series list of unload log files is shown below:

Explanation

Because the server run ID of the system log files at the time the backup was made was 3a765d82, the generation number was 12, and the file group name was logfg04, the unload log file name is bes1_3a765d820012_logfg04. For database restoration, all unload log files beginning with this file will be required.

(2) When multiple directories for unload log files are used

Because the names of the unload log files created by the automatic log unloading facility are in the format shown below, the unload log files in the directory for unload log files are arranged in time series order:

server-name_server-run-ID-and-generation-number_file-group-name

Figure 3-8 shows how to create a time series list of unload log files.

Figure 3-8 Creating a time series list of unload log files (using multiple directories for unload log files)

Explanation

The files in Directories 1 and 2 for unload log files are added to the time series list of unload log files without modification.

Although this example shows Directory 1 followed by Directory 2 in the time series of unload log files, the reverse order (Directory 2 first, followed by Directory 1) is also possible. Which files are older in terms of generation can be determined by checking the names of the unload log files in the directories.

Example (identifying the unload log files required for database restoration)

The following is assumed for this example: the server run ID of the system log files when the backup was made was 3a765d82, the generation number was 12, and the file group name was logfg04. The unload log files required for database restoration under these assumptions are identified from the time series list.

The time series list of unload log files is shown below:

Explanation

Because the server run ID of the system log files at the time the backup was made was 3a765d82, the generation number was 12, and the file group name was logfg04, the unload log file name is bes1_3a765d820012_logfg04. For database restoration, all unload log files beginning with this file will be required.

(3) When unload log files are not arranged in time series order

Care must be taken when 0000 is shown as the generation number for a system log file. When generation numbers are in the range from ffff to 0000 under the same server run ID, the unload log files are not arranged in time series order. An example follows in which unload log files are not arranged in time series order.

Files in a directory for unload log files

bes1_3a765d820000_logfg04    "0000" is shown.
bes1_3a765d820001_logfg01
bes1_3a765d820002_logfg02
bes1_3a765d82fffe_logfg02
bes1_3a765d82ffff_logfg03

In this case, the unload log files were created in the sequence shown below, so they must be used in this sequence:

bes1_3a765d82fffe_logfg02

bes1_3a765d82ffff_logfg03

bes1_3a765d820000_logfg04

bes1_3a765d820001_logfg01

bes1_3a765d820002_logfg02

Remarks

The situation explained above may occur because HiRDB is running 24 hours a day and the server run ID does not change.

(4) Notes

You must check that there are no missing files in the time series list of unload log files. When the server run ID is the same, either the generation numbers increment by 1 or different file group names are used under the same generation number.

If this is not the case, an unload log file may be missing. If a required unload log file is missing, it is necessary to unload again the system log files for the missing information. If the system log files have already been overwritten and unload log files cannot be created, the database cannot be restored to the most recent synchronization point. In such a case, the database can be restored only to the point where the most recent backup was made.

3.8.7 Error handling

Table 3-9 shows the actions that can be taken when an error occurs while the automatic log unloading facility is being used.

Table 3-9 Handling of errors when the automatic log unloading facility is used

Error detail
Corrective action

An error has occurred on the disk containing a directory for unload log files.
Because the unload log files may become unavailable, stop operations and make backups. Make backups for the RDAREAs under all servers that are using the directory for unload log files in which the error occurred.
Once the disk on which the error occurred has been restored, the automatic log unloading facility can be used again.

The disk containing a directory for unload log files has become full.
If a single directory for unload log files is being used, stop the automatic log unloading facility, transfer the unload log files in the directory to another medium, then use the pdlogatul command to start the automatic log unloading facility.
If multiple directories for unload log files are being used, switch directories. If the disks for all directories become full, stop the automatic log unloading facility, transfer the unload log files in the directories to another medium, then use the pdlogatul command to start the automatic log unloading facility.

The automatic log unloading facility has stopped (KFPS01150-E message is output)
First correct the error, then use the pdlogatul command to restart the automatic log unloading facility. If HiRDB is restarted, the automatic log unloading facility will be restarted automatically even if the pdlogatul command is not executed.
It is possible that the error occurred because the unload log files cannot be used due to the fact that all directories for unload log files have reached one of the following statuses:

Disk full*

Disk error

Wrong permission

Nonexistent directory

Unload log files created during the previous operation of HiRDB are still present.

If none of the above is applicable, notify maintenance personnel after collecting the following information:

Syslogfile

All files under $PDDIR/spool

pdlogls command's execution results

Backup of the HiRDB system definition file

* If the unloading process fails because of a disk space shortage, HiRDB deletes an incomplete unload log file. Because this file is deleted after the disk became full during unload log file creation, the disk may now appear to have available space.

3.8.8 Notes on HiRDB termination

If the pdstop command is executed while unload processing is underway, the normal or planned termination of HiRDB is carried out after the unload processing is completed. To terminate HiRDB normally immediately without waiting for completion of unload processing, enter the pdlogatul -t command to stop the automatic log unloading facility, then execute the pdstop command. In such a case, the system log files waiting to be unloaded will be unloaded automatically when HiRDB is started subsequently.

If HiRDB is terminated forcibly, unload processing is cancelled immediately.

3.9 Monitoring the free area for system log files

Executor: HiRDB administrator

This section describes how to monitor the free area for system log files. The following is described:

What is monitoring of the free area for system log files?

Environment setting

HiRDB processing when the percentage of free area falls below the warning value

Tasks the HiRDB administrator must perform when the percentage of free area falls below the warning value

Notes

Output of status information file for system log files

Organization of this section

3.9.1 What is monitoring the free area for system log files?

3.9.2 Environment setting

3.9.3 HiRDB processing when the percentage of free area falls below the warning value

3.9.4 Tasks performed by the HiRDB administrator when the percentage of free area falls below the warning value

3.9.5 Notes

3.9.6 Output of status information file for system log files

3.9.1 What is monitoring the free area for system log files?

Organization of this subsection

(1) Function overview

(2) Functional differences between levels 1 and 2

(3) Percentage of free area for system log files

(4) Percentage of free area for system log files at which the monitoring function activates (warning value)

(1) Function overview

While HiRDB operation is underway, database update logs are accumulated in system log files. When all system log files become full, no more database update logs can be output and the operation of HiRDB cannot continue; as a result, HiRDB terminates abnormally. To avoid a service interrupt due to abnormal termination of HiRDB, the HiRDB administrator should constantly monitor the amount of free space available for system log files.

HiRDB provides a facility for this purpose (monitoring the free area for system log files). When this facility is used, HiRDB monitors the percentage of free area in the system log files and issues a warning message or limits database usage according to a usage level specified by the HiRDB administrator. Either of the following levels can be selected for use by this facility:

Level 1

When the percentage of free area available for system log files falls below the warning value, the KFPS01162-W warning message is output.

Level 2

When the percentage of free area available for system log files falls below the warning value, all transactions at the server are forcibly terminated and scheduling of new transactions is suppressed, which reduces the output to the system log files; the KFPS01160-E message is output.

(2) Functional differences between levels 1 and 2

Table 3-10 shows the functional differences between levels 1 and 2.

Table 3-10 Functional differences between levels 1 and 2

Functional item | Level 1 | Level 2
Monitors percentage of free area for system log files | Yes | Yes
Outputs error or warning message | Yes | Yes
Suppresses scheduling of new transactions | No | Yes
Forcibly terminates all transactions at the server | No | Yes
Acquires synchronization point | No | Yes

(3) Percentage of free area for system log files

The following formula is used by HiRDB to determine the percentage of free area that is available for system log files:

Percentage (%) of free area for system log files =

Free area in system log files (free area in system log files + update log amount) 100%

The free area in system log files is the sum of the available system log output area in the current file and all areas of log files that are in swappable target status. The update log amount is the system log information from a synchronization point to the most recent log block. Figure 3-9 illustrates the concept of free area in system log files.

Figure 3-9 Concept of free area in system log files

Explanation

The lightly shaded area in files is the update log amount.

The white area in files is the free area.

The darkly shaded area in files is system logs that cannot be overwritten, and thus are not subject to rollback. Therefore, this area is not included in either the update log volume or the free area in the system log files.

(4) Percentage of free area for system log files at which the monitoring function activates (warning value)

The percentage of free area for system log files at which the function for monitoring the free area for system log files activates (warning value) is the value at which the database can be relied on to be safely recovered from a system failure (value at which no system log file shortage will occur during database recovery). The warning value depends on the type of server. Table 3-11 shows the percentage of free area for system log files at which the function for monitoring the free area for system log files activates (warning value).

Table 3-11 Percentage of free area for system log files at which the function for monitoring the free area activates (warning value)

Type of server | Percentage of free area for system log files at which the function for monitoring the free area activates (warning value)
HiRDB/Single Server | 67%
HiRDB/Parallel Server | Front-end server | 30%
Dictionary server | 67%
Back-end server

3.9.2 Environment setting

Organization of this subsection

(1) Selecting a level

(2) Setting the level

(1) Selecting a level

To reduce the possibility of insufficient free area for system log files causing HiRDB to terminate abnormally, Hitachi recommends that you set level 2. However, when you set level 2 and an inadequacy of free area for system log files develops, all transactions at the server will be forcibly terminated. For this reason, it is important to design the system log files carefully. For details about designing system log files, see the manual HiRDB Version 8 Installation and Design Guide.

(2) Setting the level

Use the pd_log_remain_space_check operand to specify the level you have selected. Level 1 is set when warn (the default value) is specified in this operand; level 2 is set when safe is specified.

3.9.3 HiRDB processing when the percentage of free area falls below the warning value

Organization of this subsection

(1) Level 1

(2) Level 2

(1) Level 1

When the percentage of free area for system log files becomes less than the warning value, the KFPS01162-W warning message is output.

(2) Level 2

(a) Suppressing scheduling of new transactions

The KFPS01160-E message is output when scheduling of new transactions at the server is suppressed. Transactions occurring within an operation command or a utility are also suppressed. The KFPA19703-E message (with reason=TRNPAUSE) is output subsequently to the UAPs engaged in transaction processing at the server and an error is returned for each UAP. An operation command or utility terminates abnormally. Transactions can continue to be processed by other servers, but if a transaction branches from another server to the affected server, the KFPA19703-E message (with reason=TRNPAUSE) is output to the UAP and an error is returned.

(b) Forcibly terminating all transactions at the server

Transactions currently being processed at the affected server are forcibly terminated. The KFPA11722-E message (with reason=SERVER PROCESS DOWN) is output to the forcibly-terminated transactions and an error is returned. However, the transactions listed below are not subject to forced termination; in the case of these transactions, the KFPS01163-W message is output and HiRDB waits for the transactions' processing to terminate:

Transactions engaged in commit or rollback processing

Transactions waiting for determination of the second commit phase

Transactions in the no-log mode

Even when a system log file error occurs during processing by a transaction other than those listed above, the transaction may not be forcibly terminated.

(c) Acquiring a synchronization point

Synchronization points are acquired for the number of times equal to the number of guaranteed-valid generations + 1. When a synchronization point cannot be immediately validated, HiRDB waits for validation of the synchronization point to be completed without skipping its acquisition. When a synchronization point is acquired, the percentage of free area for system log files increases. If an increasing percentage of free area reaches the warning value, scheduling of new transactions resumes and the KFPS01161-I message is output.

3.9.4 Tasks performed by the HiRDB administrator when the percentage of free area falls below the warning value

The HiRDB administrator must perform the tasks explained in this section.

Organization of this subsection

(1) Identify the server affected by the free area insufficiency

(2) Confirm the status of the system log files

(3) Place system log files in swappable target status

(4) Determine the forcibly terminated transactions (only for level 2)

(5) When the KFPS01163-W message is output (only for level 2)

(6) Identify the cause of insufficient area for system log files

(7) Revise the design of the system log files

(8) Ensure that the pdlogswap command is not executed

(1) Identify the server affected by the free area insufficiency

Check the KFPS01160-E or KFPS01162-W message to identify the server that has insufficient free area. If an error occurred with the pdlogcls command, the server specified by this command is the affected server.

Handling level 2 limits

This server is in a status in which new transactions can no longer be scheduled. The HiRDB administrator can execute the pdls -d svr command to determine the server that is in this status. The STATUS entry in the command's execution results shows TRNPAUSE for the server that is in scheduling suppression status.

(2) Confirm the status of the system log files

Execute the pdlogls command on the system log files at the applicable server to determine their status.

(3) Place system log files in swappable target status

Perform the tasks listed below to increase the number of system log files in swappable target status:

If there are reserved files, place them in swappable target status.

If there are files in unload wait status, place them in unload completed status.

If there are files in extracting status, place them in extraction completed status.

If there are files in overwriting denied status for online reorganization, place them in overwriting permitted status for online reorganization.

(4) Determine the forcibly terminated transactions (only for level 2)

Refer to the KFPS00993-I message to check the transactions that were forcibly terminated. The REQUEST entry in this message shows log_remain_check for transactions that were forcibly terminated. Once the KFPS01161-I message is output, scheduling of new transactions has resumed, and the forcibly terminated transactions must be re-executed.

(5) When the KFPS01163-W message is output (only for level 2)

The KFPS01163-W message is output if there are transactions that are not subject to forced termination. HiRDB waits for the processing by these transactions to terminate. Do not use a command such as pdcancel to forcibly terminate these transactions, because this may cause error shutdowns in RDAREAs.

You can use the following procedure to identify the UAPs, operation commands, and utilities that issued transactions that continue to operate:

Procedure

Refer to the KFPS01160-E or KFPS01163-W message to identify the name of the affected server.

Use the pdls -d trn -a -s server-name command to acquire the required transaction information. In -s server-name, specify the server name identified in 1.

Refer to PROGRAM or C-PID in the command execution results to identify the UAP, operation command, or utility that issued a transaction.

(6) Identify the cause of insufficient area for system log files

Use the status information file for system log files to identify the cause of the area insufficiency for system log files. For details, see 3.9.6 Output of status information file for system log files.

(7) Revise the design of the system log files

If the function for monitoring the free area for system log files activates more than once, there may be a defect in the design of the system log files (such as the number of files or the file size). In this case, you should revise the design of the system log files. For details about designing system log files, see the manual HiRDB Version 8 Installation and Design Guide.

(8) Ensure that the pdlogswap command is not executed

If the pdlogswap command is used to swap system log files while the percentage of free area is less than the warning value, HiRDB is more likely to terminate forcibly because there are no files in swappable target status. Therefore, you should not execute the pdlogswap command.

3.9.5 Notes

Organization of this subsection

(1) Notes applicable to levels 1 and 2

(2) Notes applicable only to level 2

(1) Notes applicable to levels 1 and 2

When the pdlogswap command is used to swap system log files, the percentage of free area for system log files decreases. If the number of system log files is small, care is required because the amount of log information increases dramatically.

Thought should be given to the advisability of executing the pdlogswap command consecutively, because the percentage of free area for system log files decreases.

When an error occurs in a swappable target file, the percentage of free area for system log files decreases. If the number of system log files is small, care is required because the percentage of free area decreases dramatically.

If HiRDB terminates abnormally while it is restarting, the HiRDB restart must be performed again. Because availability of swappable target system log files is even more important in this circumstance, an area insufficiency for system log files may cause HiRDB to terminate abnormally. When you design your system log files, you must take into account abnormal situations such as this, and you must realize that using the function for monitoring the free area for system log files does not prevent insufficiencies from occurring.

(2) Notes applicable only to level 2

When the pdlogcls command is used to close a swappable target file, the percentage of free area for the system log files decreases. If this causes the percentage of free area to fall below the warning value, the specified file will not close. In such a case, the KFPS01280-E will be output (with reason code 712) and the pdlogcls command will terminate abnormally.

3.9.6 Output of status information file for system log files

This section describes how to use the status information file for system log files to identify the cause of an area insufficiency for the system log files.

Organization of this subsection

(1) Content of status information file for system log files

(2) How to identify the cause of an area insufficiency for the system log files

(1) Content of status information file for system log files

When the percentage of free area for the system log files falls below the warning value, a status information file for system log files is output. This file acquires the status of the system log files, synchronization points, and transactions. The status information file for system log files is created in the $PDDIR/spool/pdjnlinf directory. The file name is as shown below:

pdsnap.server-name.time-issued

Remarks

If acquisition of the date or time information fails, the time issued becomes 999999999999.

If a file with the same name already exists, that file is overwritten.

If you change the file name, it may not be possible to use the pdcspool command to delete the file.

Output contents of status information file for system log files

The following example lists the output contents of a status information file for system log files. In this example, the percentage of free area at back-end server bes1 is below the warning value.

pdsnap.bes1.030415124350​    <- File name¹
Date:2003/04/15             <- Date issued¹
Time:12:43:50               <- Time issued¹
pdlogls -d sys -e -s bes1   <- Command issued internally by HiRDB
Execution result of the pdlogls command
     :

pdlogls -d spd -e -s bes1
Execution result of the pdlogls command
     :

pdls -d trn -a -s bes1
Execution result of the pdls command
     :

pdls -d svr
Execution result of the pdls command²
     :

¹ If acquisition of the date or time failed, 99...99 is displayed. Change the file name as necessary.

² In the case of a HiRDB/Parallel Server, only information for units at the applicable server is displayed.

(2) How to identify the cause of an area insufficiency for the system log files

Use the status information file for system log files to identify the cause of the area insufficiency for the system log files. The method of identifying the cause is described below.

(a) Identify the status information file for the system log files

Identify the status information file for the system log files from the KFPS01160-E or KFPS01162-W message.

Example: When the KFPS01160-E message is output

KFPS01160-E HRDB Insufficient system log space. Transaction service stopped. Transactions terminate by force, server = bes1, output file name = pdsnap.bes1.030401084500

The following is the name of the status information file for the system log files in this case:

$PDDIR/spool/pdjnlinf/pdsnap.bes1.030401084500

(b) Acquire the status of the system log files

Refer to the contents of the status information file for the system log files and check the status of the system log files. The STATUS entry in the output results of the pdlogls -d sys command shows the status of the system log files.

(c) Causes of area insufficiency for system log files

The cause can be inferred from the status of the system log files. Table 3-12 describes the causes of free area insufficiencies in system log files.

Table 3-12 Causes of free area insufficiencies for system log files

Status of system log files
Causes of insufficient free area for system log files

Many files are in unload wait status
System log files may not have been unloaded. You must unload system log files regularly.

Many files are in overwrite disabled status
One of the following causes may be applicable:

When numerous updates are performed within a single transaction, the update log size increases and the percentage of free area for system log files decreases. You should split up such transactions into multiple transactions. If this is not possible, increase the available area for system log files.

If a transaction is not settled for a long period of time, no synchronization point will be acquired. During such a period, the update log size increases and the percentage of free area for system log files decreases. If there are such transactions, either revise the server's maximum wait time (value of the PDSWAITTIME operand in the client environment definition or value of the pd_watch_pc_client_time operand) or use the skipped effective synchronization point dump monitoring facility.

Many files are in extracting status
Extraction processing may not have been applied to the system log files. Either revise the design of the system log files or revise the operation method for data linkage that uses the HiRDB Datareplicator.

Many files are in overwriting denied status for online reorganization
Update processing of updatable online reorganization may not have been applied. Either revise the design of the system log files or revise the method of operating updatable online reorganization of the inner replica facility.

4. Handling Synchronization Point Dump Files

This chapter describes the procedures for handling the synchronization point dump files.

This chapter contains the following sections:

Organization of this chapter

4.1 Basics

4.2 Setting the synchronization point dump interval

4.3 Procedures for manipulating synchronization point dump files

4.4 Status changes of synchronization point dump files

4.1 Basics

This section provides an overview of the synchronization point dump files. The user must understand synchronization point dump files before actually handling them.

Organization of this section

(1) What are synchronization point dump files?

(2) Status of synchronization point dump files

(3) Status of synchronization point dump files during HiRDB startup

(4) Synchronization point dump file status changes

(5) Relationship between number of guaranteed valid generations and file status

(6) Commands used to manipulate synchronization point dump files

(1) What are synchronization point dump files?

If HiRDB terminates abnormally and recovery processing must be performed with only the system logs, all system logs from the time of HiRDB startup will be required and system recovery will take a long time. By establishing points at regular intervals while HiRDB is operating and saving the HiRDB management information needed for recovery at each such point, the system logs prior to each point will no longer be needed and system recovery time will be shortened. Such a point is called a synchronization point. The HiRDB management information acquired at a synchronization point is called a synchronization point dump. The file that stores a synchronization point dump is called a synchronization point dump file.

HiRDB applies to a database at a given synchronization point all the database updates since either the previous synchronization point or since HiRDB startup. It is the responsibility of the HiRDB administrator to create synchronization point dump files before errors occur.

(2) Status of synchronization point dump files

HiRDB uses the statuses shown in Table 4-1 to manage the synchronization point dump files.

Table 4-1 Synchronization point dump file statuses

Status
Description

Writing
File is currently being used for output of a synchronization point dump.

Overwrite enabled
File is overwritable because it does not contain a synchronization point dump that would be needed for system recovery. A file in this status is not a guaranteed valid generation.

Overwrite disabled
File is not overwritable because it contains a synchronization point dump that would be needed for system recovery. A file in this status is a guaranteed valid generation

Reserved
File is closed and is not subject to output of synchronization point dumps.
When a synchronization point dump file name has been specified in the HiRDB system definition but no corresponding synchronization point dump file has been created, that file is also placed in reserved status.

(3) Status of synchronization point dump files during HiRDB startup

When HiRDB is started, all the synchronization point dump files for which ONL was specified in the pdlogadfg -d spd operand are opened and placed in overwrite enabled status.

A file that cannot be opened or for which ONL was not specified is placed in reserved status.

(4) Synchronization point dump file status changes

When a synchronization point dump is acquired and validated,* the status of the synchronization point dump file changes. A synchronization point dump is collected at the following times:

When server startup or restart processing is completed

When server termination preparation processing is completed

When system log files are swapped

When the number of blocks of system log information specified in the pd_log_sdinterval operand have been collected since the last synchronization point dump acquisition

When the amount of time specified in the pd_log_sdinterval operand has elapsed since the last synchronization point dump acquisition

When the pdlogsync command is executed

* When a synchronization point dump is validated, the KFPS02183-I message is output. However, if N is specified in the pd_spd_assurance_msg operand, the KFPS02183-I message is not output.

(5) Relationship between number of guaranteed valid generations and file status

HiRDB stores one synchronization point dump generation in one synchronization point dump file. When all the provided files are filled with synchronization point dumps, new data is written over the existing data in the first file.

HiRDB places the file containing the previous synchronization point dump generation in overwrite disabled status. If the number of guaranteed valid generations is set to 2, HiRDB places the files containing the last two generations in overwrite disabled status. Figures 4-1 and 4-2 show the changes in file status that result when a synchronization point dump is output.

Figure 4-1 Changes in file status when a synchronization point dump is output (number of guaranteed valid generations = 1)

Figure 4-2 Changes in file status when a synchronization point dump is output (number of guaranteed-valid generations = 2)

(6) Commands used to manipulate synchronization point dump files

Table 4-2 lists the commands that are provided for manipulating synchronization point dump files.

Table 4-2 Commands used to manipulate synchronization point dump files

Command | Description
pdloginit | Initializes a synchronization point dump file.
pdlogadpf | Allocates a synchronization point dump file to a file group specified in the HiRDB system definition.
pdlogopen | Opens a synchronization point dump file; also places an overwrite enabled file in reserved status.
pdlogcls | Closes a synchronization point dump file; also places a reserved file in overwrite enabled status.
pdlogls | Displays information about synchronization point dump files.
pdlogrm | Deletes a synchronization point dump file.
pdlogsync | Acquires a synchronization point dump.

4.2 Setting the synchronization point dump interval

Executor: HiRDB administrator

Organization of this section

(1) Setting the interval using the pd_log_sdinterval operand

(2) Guidelines for determining the interval

(3) Example of setting a synchronization point dump interval

(1) Setting the interval using the pd_log_sdinterval operand

The pd_log_sdinterval operand is used to set the synchronization point dump interval. The following considerations are taken into account in order to set the synchronization point dump interval:

Amount of system log information that is output
A synchronization point dump can be acquired each time the number of blocks of system log information that have been output since the last synchronization point dump was validated equals a value specified in the pd_log_sdinterval operand.

Elapsed time
A synchronization point dump can be acquired when the amount of time that has elapsed since the last synchronization point dump was validated equals a value specified in the pd_log_sdinterval operand.

(2) Guidelines for determining the interval

When the synchronization point dump interval is short, the time required for database recovery during a HiRDB restart is reduced. However, online performance may be degraded because synchronization point dumps are acquired more frequently.

On the other hand, when the synchronization point dump interval is long, the time required for database recovery during a HiRDB restart is increased. However, online performance may be improved because synchronization point dumps are acquired less frequently.

The synchronization point dump interval can be determined by checking the item labeled SYNC POINT GET INTERVAL in the statistics analysis utility's system activity statistical information.

For details on tuning the synchronization point dump interval, see 21.4 Tuning the synchronization point dump interval.

(3) Example of setting a synchronization point dump interval

This example assumes a system that has few updating transactions during the day shift (0900 to 1800 hours) and many updating transactions at night (1800 to 0900 hours):

Explanation

During the shift in which there are few updating transactions (0900 to 1800 hours), obtain synchronization point dumps based on elapsed time.

During the shift in which there are many updating transactions (1800 to 0900 hours), obtain synchronization point dumps based on the amount of system log information that is output.

If additional synchronization point dumps are needed, use the pdlogsync command as necessary.

4.3 Procedures for manipulating synchronization point dump files

Executor: HiRDB administrator

This section describes the procedures for manipulating synchronization point dump files. The following topics are covered:

When the status of a synchronization point dump file has changed

When there are no overwrite enabled files

Increasing (or reducing) the synchronization point dump file size during HiRDB operation

Changing the file status

Adding a new synchronization point dump file

Deleting a synchronization point dump file

Obtaining the system log file corresponding to a synchronization point dump file

Increasing the number of synchronization point dump file guaranteed valid generations

Frequently asked questions about the handling of synchronization point dump files are answered in Q&A format in A.2 Synchronization point dump files.

Organization of this section

4.3.1 When the status of a synchronization point dump file has changed

4.3.2 When there are no overwrite enabled files

4.3.3 Increasing (or reducing) the synchronization point dump file size during HiRDB operation

4.3.4 Changing the file status

4.3.5 Adding a new synchronization point dump file

4.3.6 Deleting a synchronization point dump file

4.3.7 Obtaining the system log file corresponding to a synchronization point dump in file

4.3.8 Increasing the number of synchronization point dump file guaranteed-valid generations

4.3.1 When the status of a synchronization point dump file has changed

The HiRDB administrator must use the pdlogls command to check that there is an overwrite enabled file. If there is no overwrite enabled file, a reserved file should be placed in overwrite enabled status. If a synchronization point dump needs to be output, but there are no overwrite enabled files, HiRDB (or the unit for a HiRDB/Parallel Server) terminates abnormally. When HiRDB runs out of overwrite enabled files, it outputs a message to that effect to the message log file.

4.3.2 When there are no overwrite enabled files

Overwriting of a reserved file must be enabled by means of one of the methods described below. If there are no reserved files, you must add synchronization point dump files. For details, see 4.3.5 Adding a new synchronization point dump file.

Organization of this subsection

(1) When there is a synchronization point dump file entity

(2) When there is no synchronization point dump file entity

(1) When there is a synchronization point dump file entity

There is a synchronization point dump file entity when a synchronization point dump file has been created by the pdloginit command.

Procedure

Use the pdlogls command to check the reserved files.
pdlogls -d spd -s b001

Use the pdlogopen command to enable overwriting of a reserved file that has an entity.
pdlogopen -d spd -s b001-g syncfg01

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(2) When there is no synchronization point dump file entity

There is no synchronization point dump file entity when a file group name has been specified in the pdlogadfg operand but no synchronization point dump file has been created by specifying the pdloginit command.

Procedure

Use the pdlogls command to check the reserved files.
pdlogls -d spd -s b001

Use the pdloginit command to create a synchronization point dump file. Assign to the created synchronization point dump file a synchronization point dump file name specified in the HiRDB system definition.
pdloginit -d spd -s b001 -f /sysfile01/sync01 -n 5000

Use the pdlogadpf command to associate the synchronization point dump file created in step 2 with the file group specified by the pdlogadfg operand.
pdlogadpf -d spd -s b001 -g syncfg01 -a /sysfile01/sync01

Use the pdlogopen command to enable overwriting of the synchronization point dump file created in step 2.
pdlogopen -d spd -s b001 -g syncfg01

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

4.3.3 Increasing (or reducing) the synchronization point dump file size during HiRDB operation

If a space shortage occurs in a synchronization point dump file, the following procedure can be used during HiRDB operation to increase the synchronization point dump file size:

Procedure

Use the pdlogls command to check the status of the synchronization point dump files.
pdlogls -d spd -s b001

Use the pdlogcls command to make an overwrite enabled file into a reserved file.
pdlogcls -d spd -s b001 -g syncfg01

Use the pdlogrm command to delete the reserved file.
pdlogrm -d spd -s b001 -f /sysfile01/sync01

Use the pdloginit command to re-create the synchronization point dump file deleted in step 3.
Then, increase the record count to a value greater than the record count for the synchronization point dump file before the change. To decrease the file size, decrease the record count.
pdloginit -d spd -s b001 -f /sysfile01/sync01 -n 5000

Use the pdlogopen command to enable overwriting of the synchronization point dump file created in step 4.
pdlogopen -d spd -s b001 -g syncfg01

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

Note

When you change overwrite enabled files into reserved files, make sure that you do not change all overwrite enabled files into reserved files. If a synchronization point dump needs to be output while there are no overwrite enabled files, HiRDB (or the unit for a HiRDB/Parallel Server) will terminate abnormally. Therefore, it is important to leave at least one overwrite enabled file when you change the size of a synchronization point dump file.

4.3.4 Changing the file status

The pdlogopen command is used to place a reserved file in overwrite enabled status. The pdlogcls command is used to make an overwrite enabled file into a reserved file.

4.3.5 Adding a new synchronization point dump file

This section explains the procedure for adding a new synchronization point dump file. Before a synchronization point dump file is added, it is recommended that the synchronization point dump file design guidelines be reviewed; for details, see the manual HiRDB Version 8 Installation and Design Guide.

Organization of this subsection

(1) When HiRDB can be terminated normally

(2) When HiRDB cannot be terminated normally

(1) When HiRDB can be terminated normally

Procedure

Use the pdfstatfs command to check for free space in the HiRDB file system area in which the synchronization point dump file will be created.
pdfstatfs /sysfile01
If there is no free space, create a new HiRDB file system area. For details, see 10.2 Creating (initializing) a HiRDB file system area.

Use the pdstop command to terminate HiRDB normally.

Add one of the operands listed below, as appropriate, to the HiRDB system definition. Specify in this operand the synchronization point dump file to be added in step 4.
pdlogadfg -d spd operand
pdlogadpf -d spd operand

Use the pdloginit command to add (initialize) the synchronization point dump file.
pdloginit -d spd -s b001 -f /sysfile01/sync01 -n 5000

Use the pdconfchk command to check the HiRDB system definition. If an error is detected, correct the HiRDB system definition and re-execute the pdconfchk command.

Use the pdstart command to terminate HiRDB normally.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(2) When HiRDB cannot be terminated normally

Use the pdchgconf system reconfiguration command to change the HiRDB system definition. Note that HiRDB Advanced High Availability must have been installed in order to use this command.

Procedure

Use the pdfstatfs command to check for free space in the HiRDB file system area in which the synchronization point dump file will be created.
pdfstatfs /sysfile01
If there is no free space, create a new HiRDB file system area. For details, see 10.2 Creating (initializing) a HiRDB file system area.

Create the $PDDIR/conf/chgconf directory.

Copy the HiRDB system definition file currently being used to the directory created in step 2.

Add one of the operands listed below, as appropriate, to the HiRDB system definition in the $PDDIR/conf/chgconf directory. Specify in this operand the synchronization point dump file to be added in step 5.
pdlogadfg -d spd operand
pdlogadpf -d spd operand

Use the pdloginit command to add (initialize) the synchronization point dump file.
pdloginit -d spd -s b001 -f /sysfile01/sync01 -n 5000

Use the pdconfchk command to check the HiRDB system definition in the $PDDIR/conf/chgconf directory. If an error is detected, correct the HiRDB system definition and re-execute the pdconfchk command.

Use the pdchgconf command to replace the existing HiRDB system definition with the modified system definition.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

4.3.6 Deleting a synchronization point dump file

The pdlogrm command is used to delete a reserved synchronization point dump file. Only a reserved synchronization point dump file can be deleted.

Delete the applicable operand listed below. You delete the operand that corresponds to the synchronization point dump file deleted with the pdlogrm command.

pdlogadfg -d spd operand

pdlogadpf -d spd operand

If this operand is not deleted, the deleted synchronization point dump file will become a virtual file.

4.3.7 Obtaining the system log file corresponding to a synchronization point dump in file

The pdlogls command is used to obtain the system log file that corresponds to the synchronization point dump in a synchronization point dump file.

4.3.8 Increasing the number of synchronization point dump file guaranteed-valid generations

The procedure for increasing the number of guaranteed-valid generations for synchronization point dump files is described below.

Organization of this subsection

(1) When HiRDB can be terminated normally

(2) When HiRDB cannot be terminated normally

(1) When HiRDB can be terminated normally

Procedure

Use the pdlogls command to check the number of synchronization point dump files. Confirm that the number of files is at least one more than the number of guaranteed-valid generations after the change. If there are not enough synchronization point dump files, you must add files.
pdlogls -d spd -s b001

Use the pdstop command to terminate HiRDB normally.

Add one of the operands listed below, as appropriate, to the HiRDB system definition. Specify in this operand the synchronization point dump file to be added in step 4.
pdlogadfg -d spd operand
pdlogadpf -d spd operand
Also, specify in the pd_spd_assurance_count operand the number of guaranteed-valid generations.

Use the pdloginit command to add (initialize) the synchronization point dump file.
pdloginit -d spd -s b001 -f /sysfile01/sync01 -n 5000

Use the pdconfchk command to check the HiRDB system definition. If an error is detected, correct the HiRDB system definition and re-execute the pdconfchk command.

Use the pdstart command to start HiRDB normally.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(2) When HiRDB cannot be terminated normally

Use the pdchgconf system reconfiguration command to change the HiRDB system definition. Note that HiRDB Advanced High Availability must have been installed in order to use this command.

Procedure

Use the pdlogls command to check the number of synchronization point dump files. Confirm that the number of files is at least one more than the number of guaranteed-valid generations after the change. If there are not enough synchronization point dump files, you must add files.
pdlogls -d spd -s b001

Create the $PDDIR/conf/chgconf directory.

Copy the HiRDB system definition file currently being used to the directory created in step 2.

Add one of the operands listed below, as appropriate, to the HiRDB system definition in the $PDDIR/conf/chgconf directory. Specify in this operand the synchronization point dump file to be added in step 5.
pdlogadfg -d spd operand
pdlogadpf -d spd operand
Also, specify in the pd_spd_assurance_count operand the number of guaranteed-valid generations.

Use the pdloginit command to add (initialize) the synchronization point dump file.
pdloginit -d spd -s b001 -f /sysfile01/sync01 -n 5000

Use the pdconfchk command to check the HiRDB system definition in the $PDDIR/conf/chgconf directory. If an error is detected, correct the HiRDB system definition and re-execute the pdconfchk command.

Use the pdchgconf command to replace the existing HiRDB system definition with the modified system definition.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

4.4 Status changes of synchronization point dump files

Table 4-3 and Table 4-4 show the synchronization point dump file status changes during HiRDB operation.

Table 4-3 Status changes of synchronization point dump files while HiRDB is operating (when synchronization point dump files are not duplicated)

Event | Status of synchronization point dump file
Open | Closed
Overwrite enabled | Now writing | Overwrite disabled | Reserved
1 | 2 | 3 | 4
Synchronization point dump is being output | 2 |  |  |
Synchronization point dump was validated |  | 3 | 1* |
Synchronization point dump output error occurred |  | 4 |  |
pdlogcls command was executed* | 4 |  |  |
pdlogopen command was executed* |  |  |  | 1

Legend:

: Does not apply, or status does not change.

n: Status to which synchronization dump file changes after occurrence of the event.

For example, 1 indicates that after the event occurs, the status of the synchronization dump file changes to overwrite enabled (status No. 1).

Note: The status transitions listed in this table assume that the relevant events were processed normally.

* Among files in overwrite disabled status, the indicated status changes are from the oldest generation.

Table 4-4 Status changes of synchronization point dump files while HiRDB is operating (when synchronization point dump files are duplicated)

Event
Status of system log files

Overwrite enabled
Now writing
Overwrite disabled
Rsr vd

Both open
Sys A open
Sys A clsd
Both open
Sys A open
Sys A clsd
Both open
Sys A open
Sys A clsd
Both clsd

Sys B clsd
Sys B open
Sys B clsd
Sys B open
Sys B clsd
Sys B open

1
2
3
4
5
6
7
8
9
10

A synchronization point dump was just acquired
4
5
6

Synchronization point dump was validated

7
8
9
1*
2*
3*

Output error occurred in A system file

6
10

Output error occurred in B system file

5

10

pdlog cls executd
(with -a or -b)
Omit ted
10
10
10

-a
3
10

-b
2

10

pdlog open executd
(with -a or -b)
Omit ted

1
1

7
7
1

-a

1

7
2

-b

1

7

3

Legend:

: Does not apply, or status does not change.

n: Status to which synchronization dump file changes after occurrence of the event.

For example, 1 indicates that after the event occurs, the status of the synchronization dump file changes to overwrite enabled (status No. 1).

Note: The status transitions listed in this table assume that the relevant events were processed normally.

* Among files in overwrite disabled status, the indicated status changes are from the oldest generation.

5. Handling Status Files

This chapter describes the procedures for handling the status files.

This chapter contains the following sections:

Organization of this chapter

5.1 Basics

5.2 Procedures for manipulating status files

5.3 Status changes of status files

5.1 Basics

Information needed for a HiRDB restart is stored in status files. This section provides an overview of the status files. The user must understand status files before actually handling them.

Organization of this section

(1) Status of status files

(2) Status of status files during HiRDB startup

(3) Status file status changes

(4) Status file swapping

(5) Commands used to manipulate status files

(1) Status of status files

HiRDB uses the status shown in Table 5-1 to manage the status files.

Table 5-1 Status file statuses

Status
Description

Current
File is currently being used for output of system status information.

Spare
File is not currently being used for output of system status information, but it can be swapped with the current file if the current file becomes unavailable due to an I/O error. This file is in open status.

Reserved
File is closed and is not currently subject to output of system status information.
A file is also placed in reserved status when its name has been specified in the HiRDB system definition but no status file has actually been created.

Shutdown
File has been shut down due to an error.

(2) Status of status files during HiRDB startup

When HiRDB is started normally, the first status file specified in the following system definition operands becomes the current file; all other status files become spare files:

pd_syssts_file_name_1 to pd_syssts_file_name_7 (unit status files)

pd_sts_file_name_1 to pd_sts_file_name_7 (server status files)

Notes

A file resulting in an open error is placed in reserved status. A file that cannot be opened due to an error is placed in shutdown status.

When HiRDB is restarted, the file that was being used as the current file in the previous session is inherited.

(3) Status file status changes

When status files are swapped, the status of the status files changes. Status files are swapped at the following times:

When an error occurs in the current status file

When a space shortage occurs in the current status file

When the pdstsswap command is executed

(4) Status file swapping

If an error occurs in either of the file versions, A or B, of the current file, HiRDB copies the contents of the normal file version into a spare file (the same information is contained in both versions A and B of the current file). HiRDB then places the spare file in current status and places in shutdown status the file that was being used as the current file. This processing is called status file swapping. If there is no spare file when HiRDB needs to perform status file swapping, the unit terminates abnormally. Figure 5-1 shows status file swapping.

Figure 5-1 Status file swapping

(5) Commands used to manipulate status files

Table 5-2 lists the commands that are provided for manipulating status files.

Table 5-2 Commands used to manipulate status files

Command name
Description

pdstsinit
Initializes a status file.

pdstsopen

Opens a status file; also places a reserved file in spare status.

Opens an initialized status file.

pdstscls
Closes a status file; also places a spare file in reserved status.

pdstsswap
Swaps status files and places the former current file in spare status.

pdstsrm
Deletes a status file.

5.2 Procedures for manipulating status files

Executor: HiRDB administrator

This section describes the procedures for manipulating status files. The following topics are covered:

When status files are swapped

When there are no spare files

Increasing (or reducing) the status file size during HiRDB operation

Changing the file status

Changing the current file

Adding a new status file

Deleting a status file

Checking the information in a status file

Frequently asked questions about the handling of status files are answered in Q&A format in A.3 Status files.

Organization of this section

5.2.1 When status files are swapped

5.2.2 When there are no spare files

5.2.3 Increasing (or reducing) the status file size during HiRDB operation

5.2.4 Changing the file status

5.2.5 Changing the current file

5.2.6 Adding a new status file

5.2.7 Deleting a status file

5.2.8 Checking the information in a status file

5.2.1 When status files are swapped

When status files are swapped, the HiRDB administrator must use the pdls -d sts command to check the following:

If there is a spare file

File record utilization factor

Organization of this subsection

(1) Checking to see if there is a spare file

(2) Checking the file record utilization factor

(1) Checking to see if there is a spare file

The HiRDB administrator must check that there is a spare file. If there is no spare file, a reserved file must be placed in spare status. If an error occurs in the current status file while there is no spare file, either the status file is placed in the single-operation mode or the unit terminates abnormally.

(2) Checking the file record utilization factor

If a space shortage occurs in the current status file, HiRDB selects a spare file whose size is greater than the current file and swaps the files. If there is no spare file that is larger than the current file, the unit terminates abnormally. When the largest file is being used as the current file, its record utilization factor should be checked.

5.2.2 When there are no spare files

Use one of the following methods to place a reserved file in spare status. If there are no reserved files, you must add status files. For details, see 5.2.6 Adding a new status file.

Organization of this subsection

(1) When there is a status file entity

(2) When there is no status file entity

(1) When there is a status file entity

There is a status file entity when a status file has been created by the pdstsinit command.

Procedure

Use the pdls command to check the reserved files with entities.
pdls -d sts -s b001

Use the pdstsopen command to place a reserved file in spare status.
pdstsopen -s b001 -n sstsfg01

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(2) When there is no status file entity

There is no status file entity when a status file has been specified in the HiRDB system definition but no status file has been created by specifying the pdstsinit command.

Procedure

Use the pdls command to check the virtual reserved files. Such a file's status is displayed as NONE.
pdls -d sts -s b001

Use the pdstsinit command to create status files. Assign to the created status files status file names specified in the HiRDB system definition.
pdstsinit -s b001 -f /sysfile01/ssts1a -l 4096 -c 1000
pdstsinit -s b001 -f /sysfile01/ssts1b -l 4096 -c 1000

Use the pdstsopen command to open the status file created in step 2.
pdstsopen -s b001 -n sstsfg01

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

5.2.3 Increasing (or reducing) the status file size during HiRDB operation

If the record utilization factor is high, the following procedure can be used to increase the status file size:

Procedure

Use the pdls command to check the following:
Spare status files (files with status displayed as STANDBY)
Record count in the status files
pdls -d sts -s b001

Use the pdstscls command to make spare files into reserved files.
pdstscls -s b001 -n sstsfg01

Use the pdstsrm command to delete the reserved files.
pdstsrm -s b001 -f /sysfile01/ssts1a
pdstsrm -s b001 -f /sysfile01/ssts1b

Use the pdstsinit command to re-create the status files deleted in step 3.
Then, specify a record count greater than the record count for the status files before the change.
pdstsinit -s b001 -f /sysfile01/ssts1a -l 4096 -c 1000
pdstsinit -s b001 -f /sysfile01/ssts1b -l 4096 -c 1000

Use the pdstsopen command to place the status files created in step 4 in spare status.
pdstsopen -s b001 -n sstsfg01

Use the pdstsswap command to swap out the current file. Then use steps 1-5 of this procedure to increase the size of the file that was the current file.
pdstsswap -s b001

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

Note

When you change spare files into reserved files, do not change all files into reserved files. If status files need to be swapped and there are no spare files, HiRDB (or the unit for a HiRDB/Parallel Server) terminates abnormally. Therefore, you must check that you will still have at least one spare file when you change the size of status files.

You should be careful about specifying the pd_syssts_last_active_file or pd_sts_last_active_file operand. You must change the value specified in these operands before the next HiRDB startup because the current file was changed in step 6. If the value is not changed, it will not be possible for HiRDB (or the unit for a HiRDB/Parallel Server) to start.

5.2.4 Changing the file status

The pdstsopen command is used to place a reserved file in spare status. The pdstscls command is used change a spare file into a reserved file.

5.2.5 Changing the current file

To use a different file as the current file, the pdstsswap command is used to swap status files. The current file becomes a spare file.

5.2.6 Adding a new status file

This section explains the procedure for adding a new status file. Before a status file is added, it is recommended that the status file design guidelines be reviewed; for details, see the manual HiRDB Version 8 Installation and Design Guide.

Organization of this subsection

(1) When HiRDB can be terminated normally

(2) When HiRDB cannot be terminated normally

(1) When HiRDB can be terminated normally

Procedure

Use the pdfstatfs command to check for free space in the HiRDB file system area in which status files are to be created.
pdfstatfs /sysfile01
If there is no free space, create a new HiRDB file system area. For details, see 10.2 Creating (initializing) a HiRDB file system area.

Use the pdstop command to terminate HiRDB normally.

Add the applicable operand listed below to the HiRDB system definition. Specify in this operand the status files to be created in step 4.
pd_syssts_file_name operand (for unit status files)
pd_sts_file_name operand (for server status files)

Use the pdstsinit command to add (initialize) the status files.
pdstsinit -s b001 -f /sysfile01/ssts1a -l 4096 -c 1000
pdstsinit -s b001 -f /sysfile01/ssts1b -l 4096 -c 1000

Use the pdconfchk command to check the HiRDB system configuration. If errors are detected, correct the HiRDB system definition and re-execute the pdconfchk command.

Use the pdstart command to start HiRDB normally.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(2) When HiRDB cannot be terminated normally

Use the pdchgconf system reconfiguration command to change the HiRDB system definition. Note that HiRDB Advanced High Availability must have been installed in order to use this command.

Procedure

Use the pdfstatfs command to check for free space in the HiRDB file system area in which status files are to be created.
pdfstatfs /sysfile01
If there is no free space, create a new HiRDB file system area. For details, see 10.2 Creating (initializing) a HiRDB file system area.

Create the $PDDIR/conf/chgconf directory.

Copy the HiRDB system definition files currently being used to the directory created in step 2.

Add the applicable operand listed below to the HiRDB system definition in the $PDDIR/conf/chgconf directory. Specify in this operand the status files to be added in step 5.
pd_syssts_file_name operand (for unit status files)
pd_sts_file_name operand (for server status files)

Use the pdstsinit command to add (initialize) the status files.
pdstsinit -s b001 -f /sysfile01/ssts1a -l 4096 -c 1000
pdstsinit -s b001 -f /sysfile01/ssts1b -l 4096 -c 1000

Use the pdconfchk command to check the HiRDB system definition in the $PDDIR/conf/chgconf directory. If an error is detected, correct the HiRDB system definition and re-execute the pdconfchk command.

Use the pdchgconf command to replace the existing HiRDB system definition with the modified system definition.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

5.2.7 Deleting a status file

The pdstsrm command is used to delete a reserved file or a file that is in shutdown status. Neither the current nor a spare file can be deleted.

Delete one of the following operands, as applicable. You should delete the operand that correspond to the status files to be deleted by the pdstsrm command.

pd_syssts_file_name operand (for unit status files)

pd_sts_file_name operand (for server status files)

If these operands are not deleted, the deleted status files become virtual files. Therefore, if stop (the default) is specified in the following operands, HiRDB (or the unit for a HiRDB/Parallel Server) cannot be started.

pd_syssts_initial_error

pd_sts_initial_error

5.2.8 Checking the information in a status file

Organization of this subsection

(1) Checking the information in a logical file

(2) Checking information in a physical file

(1) Checking the information in a logical file

When you execute the pdls -d sts command, the following information is displayed:

Logical file name

Logical file status

Record usage rate within the file

Number of contiguous free records within the file

Number of managed records within the file

Active physical file

Physical file status

Record size

Number of records

Physical file name

(2) Checking information in a physical file

When you execute the pdcat -d sts command, the following information is displayed:

Initialization date and time

Date and time when the current file was selected

Record size

Number of records

Record usage rate within the file

Number of contiguous free records within the file

Number of managed records within the file

5.3 Status changes of status files

Figure 5-2 and Table 5-3 show the status file status changes during HiRDB operation.

Figure 5-2 Status file status changes during HiRDB operation

Table 5-3 Status file status changes during HiRDB operation

Event | Status of status file
Open | Closed
Current | Spare | Reserved | Hold
ACTIVE* | STAND BY* | CLOSE* | NONE* | BLOCK ADE*
1 | 2 | 3 | 4 | 5
Shortage of space for status files occurred | 2 | 1 |  |  |
pdstsswap command was executed | 2 | 1 |  |  |
pdstscls command was executed |  | 3 |  |  |
pdstsopen command was executed |  |  | 2 |  |
Output error occurred | Single system | 5 |  |  |  |
Dual sys- tems | Spare files exist | 5 |  |  |  |
No spare files exist | Single system opera- tion possi- ble | Both systems opera- ting |  |  |  |  |
Single system opera- ting | 5 |  |  |  |
Single system operation not possible | 5 |  |  |  |

Legend:

: Does not apply, or status does not change.

n: Status to which status file changes after occurrence of the event.

For example, 1 indicates that after the event occurs, the status of the status file changes to current (status No. 1).

Note

The status transitions listed in this table assume that the relevant events were processed normally.

Even if the pdstsinit command or pdstsrm command is executed on reserved or hold files, the status of status files displayed by the pdls command does not change.

* Indicates the execution result (status of the status files) of the pdls -d sts command.

6. Backup Procedures

The HiRDB administrator must back up the database in order to be prepared for possible errors. This chapter describes the backup procedures.

This chapter contains the following sections:

Organization of this chapter

6.1 Backup

6.2 Backup acquisition mode

6.3 RDAREAs to be backed up together

6.4 Examples of backup

6.5 Acquiring a differential backup

6.6 Example of shell for backing up after synchronization point dump validation

6.7 Backup acquisition using JP1/OmniBack II (applicable to HP-UX only)

6.8 Backup acquisition using backup-hold (backup without using the pdcopy command)

6.9 Backup acquisition when the frozen update command (pddbfrz command) is used

6.1 Backup

The HiRDB administrator must back up data in order to be prepared for possible errors. The database copy utility (pdcopy command) is used to make backups. This section explains the basics of making backups.

For details about optional functions related to making backups (such as a function whose objective is to reduce the amount of time required to make backups), see 6.1.2 Optional items.

Organization of this section

6.1.1 Basics

6.1.2 Optional items

6.1.1 Basics

Organization of this subsection

(1) Backup unit

(2) Backup timing

(3) Server machine to be used to store a backup file

(4) Backing up RDAREAs without using the database copy utility

(5) List RDAREAs

(6) Creating a backup file in a character special file

(7) Backup file size (important)

(8) Checking a backup file's contents

(9) Note

(1) Backup unit

The backup unit is specified in an option of the database copy utility. Data can be backed up in the following units:

By system (all RDAREAs)

By unit (all RDAREAs in a unit)*

By server (all RDAREAs in a server)*

By RDAREA (individual RDAREAs)

* Function applicable to HiRDB/Parallel Servers only.

(2) Backup timing

Data should be backed up daily. If this is not possible, data should be backed up at the following times:

Before and after executing the database load utility or database reorganization utility in the no-log mode or the pre-update log acquisition mode

After executing the database structure modification utility

Before and after executing the dictionary import/export utility (before and after importing table definition information or stored procedures)

After executing the optimizing information collection utility

After recovering RDAREAs with the database recovery utility (applicable when an unload log or system log information is used as the input information)

After executing a definition SQL or the PURGE TABLE statement

After updating a large amount of table data

After registering a plug-in (after executing the pdplgrgst command)

When utilization of a plug-in is disabled (after the pdplugin operand is deleted from the system common definition)

Before installing a new version of HiRDB*

Before and after executing a UAP in the no-log mode (PDDBLOG=NO)

* The following RDAREAs should be backed up:

Master directory RDAREA

Data directory RDAREA

Data dictionary RDAREAs

(3) Server machine to be used to store a backup file

A backup file can be created in any server machine on which HiRDB is running. There is no requirement that a backup file be created in the same server machine where the RDAREAs being backed up are located. A server machine containing a device such as CMT or DAT may be used.

The server machine to be used to store a backup file can be specified in an option of the database copy utility (pdcopy command).

(4) Backing up RDAREAs without using the database copy utility

When an RDAREA is backed up without using the database copy utility, the following must be completed before the backup operation is started:

Use the pdhold -c command to place the RDAREA in shutdown and closed status.

Use the pdhold -b command to place the RDAREA in backup-hold status.

Terminate HiRDB normally.

(5) List RDAREAs

List RDAREAs cannot be backed up. There is no need to make such backups, because lists can be re-created easily as long as the tables used for the lists are available.

(6) Creating a backup file in a character special file

If a character special file is used for a backup file, the character special file must be placed in a HiRDB file system area for utilities. To do this, UTL must be specified in the -k option of the pdfmkfs command.

(7) Backup file size (important)

If a message reporting a disk space shortage is output during execution of the database copy utility even though ample disk space has been provided, the following are possible causes:

Use of large files has not been specified (pd_large_file_use = Y is not displayed).

The maximum kernel parameter value has been exceeded.

In such a case, specify use of large files or change the kernel parameter value. You can also avoid the problem by creating multiple backup files. However, if the OS does not support large files, you must keep the disk partition size to 2 GB or smaller to be able to handle multiple files.

(8) Checking a backup file's contents

You can use the pdbkupls command to check the backup information collected by the database copy utility. For example, you can check the information listed below (for details about the information that can be checked, see the manual HiRDB Version 8 Command Reference):

Backup acquisition date

Names of RDAREAs for which backup was collected

Value specified for the backup acquisition mode (-M option)

(9) Note

Do not restore from backup information collected by the database copy utility on another HiRDB. For the method of migrating data to another HiRDB, see 12.1 Migrating a table to another HiRDB system.

6.1.2 Optional items

Organization of this subsection

(1) Differential backup facility

(2) Backup-hold

(3) Frozen update command (pddbfrz command)

(4) NetBackup linkage facility

(5) Linkage to JP1/OmniBack II (applicable to HP-UX only)

(1) Differential backup facility

The differential backup facility collects as a backup only the information changed since the previous backup was made. Therefore, this facility reduces the amount of time it takes to make the backup. If the database is large and the amount of data updating has been small, consider use of the differential backup facility. For details on how to use the differential backup facility, see 6.5 Acquiring a differential backup.

(2) Backup-hold

In the following cases, you must apply backup-hold to RDAREAs subject to being backed up.

When a backup is to be made without entering the pdcopy command (when making a backup using another product's facilities)

When the Logical Volume Manager (LVM) is used for the database (to execute the pdcopy command in the updatable mode, the target RDAREAs must be backed up and held)

For details on backup-hold, see 6.8 Backup acquisition using backup-hold (backup without using the pdcopy command).

(3) Frozen update command (pddbfrz command)

The frozen update command applies to user LOB RDAREAs. It is a function for placing in frozen update status HiRDB files with full data pages (all updating completed). Once HiRDB files are in frozen update status, they do not need to be backed up again. This means that the amount of time required to make subsequent backups of the user LOB area is reduced. For details about making backups when the frozen update command is used, see 6.9 Backup acquisition when the frozen update command (pddbfrz command) is used.

(4) NetBackup linkage facility

When you use the NetBackup linkage facility, you can create backup files to be used by the database copy utility (pdcopy) or the database recovery utility (pdrstr) on a medium that is managed by the NetBackup server. The JP1/VERITAS NetBackup Agent for HiRDB License is required in order to use the NetBackup linkage facility. For details about the NetBackup linkage facility, see the manual JP1/VERITAS NetBackup v4.5 Agent for HiRDB License Description and User's Guide.

Note

The NetBackup linkage facility cannot be used under the HP-UX (IPF), Linux (IPF) or Linux (EM64T).

(5) Linkage to JP1/OmniBack II (applicable to HP-UX only)

When JP1/OmniBack II is used, various media such as DLTs can be used as the backup destination. However, JP1/OmniBack II cannot be used for a 64-bit-mode HiRDB. For details on how to make backups using JP1/OmniBack II, see 6.7 Backup acquisition using JP1/OmniBack II (applicable to HP-UX only).

6.2 Backup acquisition mode

Organization of this section

(1) Backup acquisition modes

(2) Relationship to the database update log acquisition mode

(1) Backup acquisition modes

The desired backup acquisition mode can be selected by specifying the -M option of the database copy utility (pdcopy command). Table 6-1 lists the backup acquisition modes.

Table 6-1 Backup acquisition modes

Backup acquisition mode (-M option specification)
Description of mode
Point to which RDAREAs can be restored

Referencing/updating-impossible mode (x)
RDAREAs being backed up cannot be referenced or updated while the backup is being made. Subject RDAREAs must be placed in shutdown and closed status with the pdhold -c command before the backup is made.
Using a backup made in this mode, the database can be restored to the point when the backup was made.
If a system log is used, the database can be restored to any synchronization point after the backup was made.

Referencing-permitted mode (r)
RDAREAs being backed up can only be referenced during backup processing; they cannot be updated.

Updatable mode (s)¹
RDAREAs being backed up can be referenced and updated during backup processing.
A database cannot be restored to the point when the backup was made. It can be restored only to a synchronization point subsequent to the point when the backup was made. Therefore, database restoration requires both the backup and the system log² from a synchronization point immediately prior to when the backup was made.

¹

When the updatable mode is specified, the RDAREAs to be backed up must have been created in a character special file; an RDAREA created in a regular file cannot be backed up in the updatable mode.

Do not make a backup in the updatable mode during execution of a UAP (including utilities) in the no-log mode or pre-update log acquisition mode.

To execute the pdcopy command in the updatable mode when the Logical Volume Manager (LVM) is used for the database, the target RDAREAs must be backed up and held. For details on backup-hold, see 6.8 Backup acquisition using backup-hold (backup without using the pdcopy command).

2 The run ID and generation number of the system log file needed to recover the RDAREA are output to the database copy utility's processing results output file.

Notes

A backup made after an RDAREA structure change must be made in one of the following backup acquisition modes:

Referencing/updating-impossible mode (x)

Referencing-permitted mode (r)

(2) Relationship to the database update log acquisition mode

The backup acquisition mode that can be specified for backup processing depends on the database update log acquisition mode, as shown in Table 6-2. For details on the database update log acquisition mode, see 7. Operation Without Acquiring a Database Update Log.

Table 6-2 Backup acquisition mode depending on the database update log acquisition mode

Database update log acquisition mode
Specifiable backup acquisition mode (-M option specification)

Log acquisition mode
Referencing/updating-impossible mode (x)
Referencing-permitted mode (r)
Updatable mode (s)

Pre-update log acquisition mode
Referencing/updating-impossible mode (x)
Referencing-permitted mode (r)

No-log mode

Notes

Do not make a backup in the updatable mode (-M s specification) during execution of a UAP (including utilities) in the no-log mode or pre-update log acquisition mode.

After execution of a UAP (including utilities) in the no-log mode or pre-update log acquisition mode, make the backup in one of the following modes:

Referencing/updating-impossible mode (-M x specification)

Referencing-permitted mode (-M r specification)

6.3 RDAREAs to be backed up together

The HiRDB administrator must back up not only RDAREAs that have been processed, but also RDAREAs that have been updated as a result of that processing. Table 6-3 lists the RDAREAs that should be backed up together.

Table 6-3 RDAREAs to be backed up together

Processing executed since previous backup
Type of RDAREA to be backed up

MST
DIR
DIC
DIC
LOB
USR
USR
LOB
REG
REG
LOB
LOB
indx
LOB
data

ALTER
PROCEDURE

Y
Y

ALTER
ROUTINE

Y
Y

ALTER
TABLE
Y¹
Y¹
Y

Y

ALTER
TRIGGER

Y
Y

CREATE
FUNCTION

Y
Y

CREATE
INDEX
Y
Y
Y

Y

Y¹⁵

CREATE
PROCEDURE

Y
Y

CREATE
SCHEMA,
CREATE
CONNECTION
SECURITY

Y

CREATE
TABLE
Y
Y²
Y
Y³⁴
Y
Y⁹

Y¹⁶

CREATE
TRIGGER

Y
Y

CREATE
TYPE

Y
Y²⁴

CREATE
VIEW
Y

Y

DROP
CONNECTION
SECURITY

Y

DROP
DATA TYPE

Y
Y²⁴

DROP
FUNCTION

Y
Y

DROP
INDEX
Y
Y
Y

Y

Y¹⁷

DROP
PROCEDURE

Y
Y

DROP
SCHEMA
Y³
Y³
Y
Y¹⁴
Y
Y¹⁰

Y¹⁸
Y¹⁹

DROP
TABLE
Y
Y⁸
Y
Y³⁴
Y
Y⁹

Y²⁰
Y²¹

DROP
TRIGGER

Y
Y

DROP
VIEW
Y

Y

Definition SQL other than above
Y⁷

Y

PURGE
TABLE

Y³⁵

Y
Y⁹

Y²⁰
Y²¹

Other data manipulation SQL

Y¹³
Y¹³

Y²²
Y²³

Database load utility

Y³⁵

Y
Y⁹

Y²⁰
Y²¹

Database structure modif utility
RDAREA addition
Y

Y
Y³⁰
Y⁵

Y¹¹
Y¹¹

RDAREA expansion
Y

Y
Y³⁰
Y⁵
Y¹¹
Y²⁵
Y²⁶
Y¹¹
Y¹¹

RDAREA deletion
Y

Y

RDAREA re-initial
Y
Y⁴
Y
Y³⁰
Y⁵
Y11, 12
Y²⁵
Y²⁶

Database reorg utility
Reload

Y6, 35
Y⁶
Y
Y³¹

Y²⁰
Y²¹

Reorg

Y³⁶

Y³⁶

Re-create an index

Y³²

Y³³
Y³³

Index reorg

Y

Dict import/export utility
Import table definition info
Y
Y
Y
Y³⁴
Y
Y⁹

Import of stored procedure

Y
Y

Integrity check utility

Y³⁵

Y³⁵

Optimizing information collection utility

Y

Registry facility initialization utility

Y²⁵
Y²⁶

Rebalancing utility

Y
Y
Y
Y⁹

Y²⁰
Y²¹

Database definition utility
Same as definition SQL

pdplgrgst command

Y
Y

pdorend command

Y³⁶

Y³⁶

Deletion of plug-in
Y
Y
Y
Y
Y
Y²⁷
Y
Y
Y²⁸
Y²⁹

modif: modification

re-initial: re-initialization

reorg: reorganization

Re-create: Re-creating

Dict: Dictionary

info: information

Y: RDAREAs to be backed up together

MST: Master directory RDAREA

DIR: Data directory RDAREA

DIC: Data dictionary RDAREA

DIC LOB: Data dictionary LOB RDAREA

USR: User RDAREA

USR LOB: User LOB RDAREA

REG: Registry RDAREA

REG LOB: Registry LOB RDAREA

LOB indx: User LOB RDAREA (applicable if plug-in index is stored)

LOB data: User LOB RDAREA (applicable if abstract data type is stored)

Note

To back up a data dictionary LOB RDAREA for storing objects, either the -M option of the database copy utility must be omitted or x or r must be specified in the -M option.

¹ Required if a column comprising the index was deleted or a column with a low ID was deleted from the index columns. The column IDs can be obtained by searching the COLUMN_ID column of the SQL_COLUMNS dictionary table.

² Required if a row-partitioned table or cluster key was defined.

³ Required if a table or index was defined for a schema that was deleted.

⁴ Required if an index is stored in an RDAREA that was deleted.

⁵ Required if a user RDAREA was processed.

⁶ Required if a dictionary table was reorganized.

⁷ Required if a view table was deleted because access privilege to the base table was lost by REVOKE access-privilege.

⁸ Required in the following cases:

A row-partitioned table was deleted

An index was defined for a table that was deleted

A cluster key was defined for a table that was deleted

⁹ Required if a LOB column is defined for a table that was processed.

¹⁰ Required if a schema that was deleted contained a table for which a LOB column was defined.

¹¹ Required if a user LOB RDAREA was processed.

¹² Required if a user RDAREA that contained a table for which a LOB column was defined was initialized.

¹³ If no LOB column is defined for the updated table, the user RDAREAs that contain this table must be backed up. If a LOB column is defined for the updated table, the RDAREAs listed in Table 6-4 must be backed up.

¹⁴ Required if a routine, a table for which a CASCADE referential constraint action was defined, or a trigger was defined in a schema that is subject to deletion.

¹⁵ Required if a plug-in index was created.

¹⁶ Required if an abstract data type was defined for a table has the LOB attribute.

¹⁷ Required if a plug-in index was deleted.

¹⁸ Required if a schema that was deleted contained a table for which a plug-in index was defined.

¹⁹ Required if a schema that was deleted contained a table for which the LOB attribute was defined.

²⁰ Required if a plug-in index was defined for a table that was processed.

²¹ Required if the LOB attribute was defined for a table that was processed.

²² Required if an attribute for which a plug-in index was defined was updated.

²³ Required if the LOB attribute was updated.

²⁴ Required if there was a function definition specified with an SQL procedure.

²⁵ Required if a registry RDAREA was processed.

²⁶ Required if a registry LOB RDAREA was processed.

²⁷ Required if the LOB attribute was defined for a table for which an abstract data type provided by a plug-in was defined.

²⁸ Required if a plug-in index was defined.

²⁹ Required if the LOB attribute was defined for an abstract data type provided by a plug-in.

³⁰ Required if a data dictionary LOB RDAREA was processed.

³¹ Required if a LOB column was defined for the target table. Also, in cases where only a LOB column structure base table is reconfigured (-j option is not specified), the LOB column must be acquired together with the user RDAREA.

³² The table storage RDAREA and the index storage RDAREA must be acquired as a pair.

³³ Also in cases where plug-in indexes are subject to processing, the table storage RDAREAs (user RDAREAs) must be acquired in preparation for no-log hold.

³⁴ Required if a referential constraint's action is CASCADE.

³⁵ Required if a referencing table, a referenced table, or a table for which a check constraint was defined is the processing target.

³⁶ Required if the check pending status is changed.

Table 6-4 RDAREAs to be backed up when a LOB column is defined for an updated table

Updating type and condition | For user | For user LOB
INSERT statement | Data exists in a column other than LOB column. | LOB column is null. | Y |
LOB column contains data. | Y | Y
DELETE statement | Data exists in a column other than LOB column. | LOB column is null. | Y |
LOB column contains data. | Y | Y
UPDATE statement | Updating occurred in a column other than LOB column. | LOB column was not updated. | Y |
LOB column was updated. | Y | Y
No updating occurred in a column other than LOB column. | LOB column was updated. | Null value was updated to some data. | Y | Y
Data was updated to null. | Y | Y
Data A was updated to data B. |  | Y

Y: Backup must be collected.

: Backup need not be collected.

6.4 Examples of backup

Executor: HiRDB administrator

Organization of this section

6.4.1 Example 1 (backing up a system)

6.4.2 Example 2 (backing up a system)

6.4.3 Example 3 (backing up a system)

6.4.4 Example 4 (backing up a unit)

6.4.5 Example 5 (backing up a server)

6.4.6 Example 6 (Backing up RDAREAs)

6.4.1 Example 1 (backing up a system)

All RDAREAs are backed up during operation of a HiRDB/Single Server.

Organization of this subsection

(1) Using the pdlogswap command to swap the system log files

(2) Using the pdcopy command to back up all RDAREAs

(1) Using the pdlogswap command to swap the system log files

System log files are swapped in order to physically separate the system logs required for database restoration. To restore the RDAREAs from the backup copy to be created in step (2), the system log collected subsequently (the system log in the file to be used as the current file after swapping) will be used as input information.

pdlogswap -d sys -w

(2) Using the pdcopy command to back up all RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01
-z /pdcopy/logpoint01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing-permitted mode as the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up.

-b: Specifies the name of the backup file.

-z: Specifies the name of the log point information file. Specify this option when operation without unloading the system log or the automatic log unloading facility is being used.

-p: Specifies the output file name for the pdcopy command's processing results listing.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

6.4.2 Example 2 (backing up a system)

All RDAREAs are backed up during operation of a HiRDB/Parallel Server.

Organization of this subsection

(1) Using the pdlogswap command to swap system log files at all back-end servers and the dictionary server

(2) Using the pdcopy command to back up all RDAREAs

(1) Using the pdlogswap command to swap system log files at all back-end servers and the dictionary server

System log files are swapped in order to physically separate the system logs required for database restoration. To restore the RDAREAs from the backup copy to be created in step (2), the system log collected subsequently (the system log in the file to be used as the current file after swapping) will be used as input information.

pdlogswap -d sys -s bes1 -w
pdlogswap -d sys -s bes2 -w
pdlogswap -d sys -s dic -w

(2) Using the pdcopy command to back up all RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing-permitted mode as the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output file name for the pdcopy command's processing results listing.

Remarks

When the automatic log unloading facility is being used, execute the pdlogatul command to record the unload log file name that corresponds to the current system log file when the backup is being made.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

6.4.3 Example 3 (backing up a system)

HiRDB is terminated, then the pdstart -r command is used to start HiRDB and all RDAREAs are backed up.

Note

A log point information file cannot be created when this method is used. This method should not be used when the system is operating without unloading the system log.

Organization of this subsection

(1) Entering the pdstop command to terminate HiRDB normally

(2) Entering the pdstart -r command to start HiRDB

(3) Using the pdcopy command to back up all RDAREAs

(4) Entering the pdstop command to terminate HiRDB normally

(5) Entering the pdstart command to start HiRDB normally

(1) Entering the pdstop command to terminate HiRDB normally

pdstop

(2) Entering the pdstart -r command to start HiRDB

pdstart -r

(3) Using the pdcopy command to back up all RDAREAs

pdcopy -m /rdarea/mast/mast01 -M x -a -b /pdcopy/backup01 -p pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing/updating-impossible mode as the backup acquisition mode. Because the pdstart -r command was used to start HiRDB, there is no need to place the RDAREAs in shutdown and closed status even if x is specified.

-a: Specifies that all RDAREAs are to be backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output file name for the pdcopy command's processing results listing.

Remark

When the automatic log unloading facility is being used, execute the pdlogatul command to record the unload log file name that corresponds to the current system log file when backup is being made.

(4) Entering the pdstop command to terminate HiRDB normally

pdstop

(5) Entering the pdstart command to start HiRDB normally

pdstart

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

6.4.4 Example 4 (backing up a unit)

All RDAREAs in a unit are backed up during operation of a HiRDB/Parallel Server.

Organization of this subsection

(1) Using the pdlogswap command to swap the system log files in the unit

(2) Using the pdcopy command to back up the entire unit

(1) Using the pdlogswap command to swap the system log files in the unit

System log files are swapped in order to physically separate the system logs required for database restoration. To restore the RDAREAs from the backup copy to be created in step (2), the system log collected subsequently (the system log in the file to be used as the current file after swapping) will be used as input information.

pdlogswap -d sys -s bes1 -w
pdlogswap -d sys -s bes2 -w

(2) Using the pdcopy command to back up the entire unit

pdcopy -m /rdarea/mast/mast01 -M r -u UNT1 -b /pdcopy/backup01
-p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing-permitted mode as the backup acquisition mode.

-u: Specifies that all RDAREAs under the unit (UNT1) are to be backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output file name for the pdcopy command's processing results listing.

Remarks

When the automatic log unloading facility is being used, execute the pdlogatul command to record the unload log file name that corresponds to the current system log file when backup is being made.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

6.4.5 Example 5 (backing up a server)

All RDAREAs in a back-end server (bes1) are backed up during operation of a HiRDB/Parallel Server. A log point information file is also obtained, because the system is operating without unloading the system log.

Organization of this subsection

(1) Using the pdlogswap command to swap the system log files in the server that is to be backed up

(2) Using the pdcopy command to back up the entire server

(1) Using the pdlogswap command to swap the system log files in the server that is to be backed up

System log files are swapped in order to physically separate the system logs required for database restoration. To restore the RDAREAs from the backup copy to be created in step (2), the system log collected subsequently (the system log in the file to be used as the current file after swapping) will be used as input information.

pdlogswap -d sys -s bes1 -w

(2) Using the pdcopy command to back up the entire server

pdcopy -m /rdarea/mast/mast01 -M r -s bes1 -b /pdcopy/backup01
-z /pdcopy/logpoint01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing-permitted mode as the backup acquisition mode.

-s: Specifies that all RDAREAs under the back-end server (bes1) are to be backed up.

-b: Specifies the name of the backup file.

-z: Specifies the name of the log point information file. Specify this option when operation without unloading the system log or the automatic log unloading facility is used.

-p: Specifies the output file name for the pdcopy command's processing results listing.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

6.4.6 Example 6 (Backing up RDAREAs)

Specified RDAREAs (rdarea01 and rdarea02) are backed up during HiRDB operation.

Organization of this subsection

(1) Using the pdhold -c command to place the RDAREAs to be backed up in shutdown and closed status

(2) Using the pdlogswap command to swap the system log files at the server that contains the RDAREAs to be backed up

(3) Using the pdcopy command to back up specified RDAREAs

(4) Using the pdrels -o command to release shutdown and open RDAREAs

(1) Using the pdhold -c command to place the RDAREAs to be backed up in shutdown and closed status

This operation is necessary when x (referencing/updating-impossible) is specified as the backup acquisition mode; it is not necessary when r (referencing-permitted mode) or s (updatable mode) is specified as the backup acquisition mode.

pdhold -r rdarea01,rdarea02 -c

(2) Using the pdlogswap command to swap the system log files at the server that contains the RDAREAs to be backed up

System log files are swapped in order to physically separate the system logs needed for database restoration. To restore the RDAREAs from the backup copy to be created in step (3), the system log information collected subsequently (the system log information in the file to be used as the current file after swapping) will be used as input information.

pdlogswap -d sys -s bes1 -w

(3) Using the pdcopy command to back up specified RDAREAs

pdcopy -m /rdarea/mast/mast01 -M x -r rdarea01,rdarea02
-b /pdcopy/backup01 -p /pdcopy01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing/updating-impossible mode as the backup acquisition mode.

-r: Specifies the RDAREAs (rdarea01 and rdarea02) that are to be backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output file name for the pdcopy command's processing results listing.

Remarks

When the automatic log unloading facility is being used, execute the pdlogatul command to record the unload log file name that corresponds to the current system log file when backup is being made.

(4) Using the pdrels -o command to release shutdown and open RDAREAs

This operation is necessary when x (referencing/updating-impossible) is specified as the backup acquisition mode; it is not necessary when r (referencing-permitted mode) or s (updatable mode) is specified as the backup acquisition mode.

pdrels -r rdarea01,rdarea02 -o

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

6.5 Acquiring a differential backup

Executor: HiRDB administrator

This section explains making backups with the differential backup facility. The following items are explained in this section:

Differential backup facility overview

Preparations for using the differential backup facility

Operation example of the differential backup facility

Creating an accumulation-differential backup

Referencing the history file for differential backups

Restoring a differential backup management file

Organization of this section

6.5.1 Differential backup facility overview

6.5.2 Preparations for using the differential backup facility

6.5.3 Examples of using the differential backup facility

6.5.4 Creating an accumulation-differential backup

6.5.5 Referencing the history file for differential backups

6.5.6 Restoring a differential backup management file

6.5.1 Differential backup facility overview

Because backups are acquired in units of RDAREAs, both updated pages and unupdated pages are included in a backup. When you use the differential backup facility, only pages updated since the last time a backup was made are included in a new backup. When you make a backup of only the material that differs from the previous backup, the backup processing time is reduced. If the database is large but only a small amount of data has been updated, you should consider using the differential backup facility. Figure 6-1 provides an overview of the differential backup facility.

Figure 6-1 Overview of the differential backup facility

Explanation

RDAREAs 1-3 are backed up on Sunday. All pages in RDAREAs 1-3 that are currently in use are backed up. This backup is called a full backup, and the RDAREAs in the group that is backed up are referred to as the differential backup group.

Update processing is performed during the workday on Monday.

RDAREAs 1-3 are backed up after the workday is over on Monday. At this time, only the updated pages in RDAREAs 1-3 are backed up. Such a backup is called a differential backup.

Update processing is performed during the workday on Tuesday.

RDAREAs 1-3 are backed up after the workday is over on Tuesday. At this time, only the updated pages in RDAREAs 1-3 are backed up.

Recovering the database

For details about recovering the database when you use the differential backup facility, see 19.4 Database recovery using the differential backup facility.

Remarks

You can also use the differential backup facility when operating without unloading the system log.

Notes

You store all backup files (full backup files, differential backup files, and accumulation-differential backup files) from the same differential backup group on the same server machine. For details about accumulation-differential backup files, see 6.5.4 Creating an accumulation-differential backup.

A differential backup cannot be made of LOB RDAREAs. Rather, all pages that are in use must be backed up every time a backup is made.

If the configuration of an RDAREA has changed, a full backup of the RDAREA must be made again. A backup made before an RDAREA's configuration was changed cannot be used to restore the RDAREA.

You must use JP1/OmniBack II or the NetBackup linkage facility to back up RDAREAs onto a tape device. If you do not use JP1/OmniBack II or the NetBackup linkage facility, it will not be possible to back up RDAREAs onto a tape device.

When you use JP1/OmniBack II to back up RDAREAs, do not update bar list files after the pdcopy command terminates. Also, do not do this without specifying protection for the bar list files.

6.5.2 Preparations for using the differential backup facility

Organization of this subsection

(1) Creating a HiRDB file system area for storing differential backup management files

(2) Differential backup group for RDAREAs

(1) Creating a HiRDB file system area for storing differential backup management files

A file called the differential backup management file is output whenever a backup is made. This file stores information about the differential backup, which is used while the backup is being made and when the backup is used by HiRDB for database restoration.

You use the pdfmkfs command to create a HiRDB file system area for storing differential backup management files; for a HiRDB/Parallel Server, you must create the HiRDB file system area in the unit in which the system manager is defined:

pdfmkfs -n 10 -l 4096 -e 60000 -k UTL /pdcopy/admfile

Explanation

-n: Specifies in megabytes the size of the HiRDB file system area.

-l: Specifies the maximum number of files.

-e: Specifies the number of increments.

-k: Specifies the purpose of the HiRDB file system area (a HiRDB file system area for utilities).

/pdcopy/admfile:

Specifies a name for the HiRDB file system area. Differential backup management files will be created in this HiRDB file system area. The name of the differential backup management file is the same as the backup group name.

Notes

Differential backup management files are important files because they contain information about the differential backups that are made. Without these files, the differential backup facility cannot be used and the database cannot be restored. For this reason, it is important not to delete this HiRDB file system area or the differential backup management files it contains. Each time a backup is made, you can use the pdfbkup command to back up the differential backup management files.

When the system switchover facility is being used, you must create this HiRDB file system area (as a character special file) on the hard disk that is shared by the primary and secondary systems. If the HiRDB file system area is created as a regular file, the following steps must be taken:

Procedure

Create HiRDB file system areas with the same name in the primary and secondary systems.

Each time a backup is made, use the pdfbkup command to back up the differential backup management files.

Use ftp, etc., to copy into the secondary system the backup of the differential backup management files that you created in Step 2.

Use the pdfrstr command to restore the differential backup management files in the secondary system.

Remarks

Backup files and differential backup management files can be stored in the same HiRDB file system area.

(2) Differential backup group for RDAREAs

A group of RDAREAs to which the differential backup facility is applied is called a differential backup group. This section explains how to group RDAREAs.

(a) Restoring RDAREAs to the most recent differential backup acquisition point, or restoring RDAREAs using an unload log file (system log files)

In this case, it is possible to restore a specific RDAREA in a differential backup group. When the database contains a large amount of data, grouping all RDAREAs together for the purpose of making backups makes it time-consuming to restore a specific RDAREA. This is because of the amount of time required to load the backup files sequentially.

Therefore, grouping RDAREAs into manageable groups and making backups by group is recommended. For example, when a disk error occurs, RDAREAs are restored one disk at a time. Therefore, the RDAREAs stored on the same disk can constitute a group.

(b) Restoring RDAREAs to other than the most recent differential backup acquisition point (restoring RDAREAs using only full backup files)

In this case, it is not possible to restore a specific RDAREA in a differential backup group. All RDAREAs in the group must be restored.

Therefore, it is recommended that RDAREAs that are related constitute each group. For example, one group of RDAREAs might store the data of the same table, while another group of RDAREAs might store the indexes for this table. In this way, both the RDAREAs for the table and the RDAREAs for the indexes can be restored at the same time with a single execution of the pdrstr command.

Notes

When RDAREAs are restored to other than the most recent differential backup acquisition point by using only the full backup files, the information for differential backups subsequent to the restoration point in the differential backup management files becomes invalid. Consequently, it will not be possible to restore RDAREAs to the most recent differential backup acquisition point. Note that differential backup information is not invalidated when an error occurs during restoration.

6.5.3 Examples of using the differential backup facility

The following procedure for applying the differential backup facility is illustrated by the examples later in this section:

Procedure

To apply the differential backup facility:

Select the RDAREAs to which the differential backup facility is to be applied (determine the differential backup group).

Make a full backup of the RDAREAs to be backed up.

Make differential backups of the RDAREAs to be backed up (for example, make a backup once a day).

Make a full backup of the RDAREAs being backed up on a regular basis (for example, make a full backup once a week).

The operation example of the differential backup facility assumes the following conditions:

Conditions

The differential backup facility is applied to the two user RDAREAs rdarea01 and rdarea02.

A full backup is made once a week (on Sunday).

Update information only is collected as a differential backup every day (Monday through Saturday).

Organization of this subsection

(1) Making a full backup (on Sunday)

(2) Making a backup of the differential backup management file (every Sunday)

(3) Making a differential backup (daily, Monday through Saturday)

(4) Making a backup of the differential backup management file (daily, Monday through Saturday)

(1) Making a full backup (on Sunday)

Use the pdcopy command to make a full backup:

pdcopy -m /rdarea/mast/mast01 -M r -r rdarea01,rdarea02 -g 'backupg1(S)'
-b /pdcopy/backup01 -d a -K /pdcopy/admfile -L 5 -o /pdcopy/rfile

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing-permitted mode as the backup acquisition mode.

-r: Specifies the RDAREAs to be backed up.

The RDAREA group specified here becomes the backup group. The RDAREAs constituting the group cannot be changed subsequently.

-g: Specifies a name for the differential backup group.

When the first full backup is made, (S) must be specified in the differential backup group name. The differential backup group name specified in this option is used when subsequent differential backups are made.

When (S) is specified, the entire differential backup group name must be enclosed in apostrophes (e.g., 'backupg1(S)'). However, the enclosing apostrophes must not be used when the -g option is specified in a control statements file.

-b: Specifies a name for the backup file (full backup file name).

-d: Specifies the backup type:

a: Full backup

b: Accumulation-differential backup since the most recent full backup

c: Accumulation-differential backup since either the previously collected accumulation-differential backup or the previously collected full backup, whichever is most recent

d: Differential backup

For details on accumulation-differential backups, see 6.5.4 Creating an accumulation-differential backup.

-K: Specifies the name of the HiRDB file system area in which the differential backup management file is to be stored.

-L: Specifies (in megabytes) the size of the differential backup management file.

-o: Specifies the name of the history file for differential backups.

For details on the history file for differential backups, see 6.5.5 Referencing the history file for differential backups.

(2) Making a backup of the differential backup management file (every Sunday)

Use the pdfbkup command to make a backup of the created differential backup management file:

pdfbkup /pdcopy/admfile/backupg1 /backup/pdcopy/admfile/backupg1

Explanation

/pdcopy/admfile/backupg1:

Specifies the name of the differential backup management file. This name is the same as the differential backup group name.

/backup/pdcopy/admfile/backupg1:

Specifies a name for the backup file of the differential backup management file.

(3) Making a differential backup (daily, Monday through Saturday)

Use the pdcopy command to make a differential backup:

pdcopy -m /rdarea/mast/mast01 -M r -g backupg1 -b /pdcopy/backup02
-d d -K /pdcopy/admfile -o /pdcopy/rfile

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing-permitted mode as the backup acquisition mode.

-g: Specifies the name of the differential backup group; (S) need not be specified.

-b: Specifies a name for the backup file (differential backup file name).

-d: Specifies the backup type:

a: Full backup

b: Accumulation-differential backup since the most recent full backup

c: Accumulation-differential backup since either the previously collected accumulation-differential backup or the previously collected full backup, whichever is most recent

d: Differential backup

For details on accumulation-differential backup, see 6.5.4 Creating an accumulation-differential backup.

-K: Specifies the name of the HiRDB file system area in which the differential backup management file is to be stored.

-o: Specifies the name of the history file for differential backups.

For details on the history file for differential backups, see 6.5.5 Referencing the history file for differential backups.

(4) Making a backup of the differential backup management file (daily, Monday through Saturday)

Use the pdfbkup command to make a backup of the created differential backup management file:

pdfbkup -r /pdcopy/admfile/backupg1 /backup/pdcopy/admfile/backupg1

Explanation

-r: Specifies that the last backup of the differential backup management file is to be overwritten.

/pdcopy/admfile/backupg1:

Specifies the name of the differential backup management file. This name is the same as the differential backup group name.

/backup/pdcopy/admfile/backupg1:

Specifies a name for the backup file of the differential backup management file.

6.5.4 Creating an accumulation-differential backup

To create an accumulation-differential backup, you execute the pdcopy command with c specified in the -d option. Creating an accumulation-differential backup may reduce the size of the backup file to be used for restoration. For example, if the same page is updated every day, all the update information for that page is merged, so the size of the backup file to be used for restoration is reduced. Figure 6-2 illustrates the concept of an accumulation-differential backup.

Figure 6-2 Concept of an accumulation-differential backup

Explanation

When the accumulation-differential backup is made on Wednesday, the differential backups made on Monday and Tuesday will not be used for database restoration. The backups necessary for database restoration are the full backup and the accumulation-differential backup made on Wednesday.

Whether an accumulation-differential backup is to be made from the full backup or the previously collected accumulation-differential backup is specified in the -d option of the pdcopy command.

Organization of this subsection

(1) Precautions

(2) Examples of making accumulation-differential backups

(1) Precautions

Once an accumulation-differential backup is created, you should use the pdfbkup command to make a backup of the differential backup management files.

(2) Examples of making accumulation-differential backups

As an example, you might wish to perform the following operations when making accumulation differential backups:

Make a full backup on Sunday.

Make differential backups on Monday and Tuesday.

On Wednesday, make an accumulation-differential backup for Monday through Wednesday.*

Make differential backups on Thursday and Friday.

On Saturday, make an accumulation-differential backup for Thursday through Saturday.*

* Following is an example of specifying the pdcopy command for the above Wednesday and Saturday tasks:

pdcopy -m /rdarea/mast/mast01 -M r -g backupg1 -b /pdcopy/backup03
-d c -K /pdcopy/admfile -o /pdcopy/rfile

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing-permitted mode as the backup acquisition mode.

-g: Specifies the name of the differential backup group; (S) need not be specified.

-b: Specifies a name for the backup file (accumulation-differential backup file name).

-d: Specifies the backup type:

a: Full backup

b: Accumulation-differential backup since the most recent full backup

c: Accumulation-differential backup since either the previously collected accumulation-differential backup or the previously collected full backup, whichever is most recent

d: Differential backup

-K: Specifies the name of the HiRDB file system area in which the differential backup management file is to be stored.

-o: Specifies the name of the history file for differential backups.

6.5.5 Referencing the history file for differential backups

The history file for differential backups contains differential backup acquisition information in time series order. This file can be referenced with the pdcopy command. The statistical information file can be referenced with an OS text editor, etc.The following is an example of the output from a history file for differential backups:

Explanation

pdcopy command's execution date

HiRDB identifier

Name of the HiRDB file system area containing the differential backup management file

Backup group name

Backup group's creation date

Date of the most recent update of the backup group

Names of the RDAREAs belonging to the backup group

Backup type:
a: Full backup
b: Accumulation-differential backup since the most recent full backup
c: Accumulation-differential backup collected since either the previously collected accumulation-differential backup or the previously collected full backup, whichever is most recent
d: Differential backup

Backup acquisition start time

Backup acquisition completion time

Backup acquisition mode:
x: Updating/referencing-impossible mode
r: Referencing-permitted mode
s: Updatable mode

Backup file type:
u: Regular file
i: HiRDB file system area for backup files
o: JP1/OmniBack II object

Backup file name or object name:
Displayed in the format host-name:backup-file-name
If the name is an object name, it is followed by (-G bar-list-file-name).

6.5.6 Restoring a differential backup management file

If an error occurs in a differential backup management file, the differential backup facility cannot be used. Therefore, in the event of an error in a differential backup management file, one of the following methods must be used to correct the error:

Restore the differential backup management file from a backup.

Make a new full backup with (S) specified in the differential backup group name.

6.6 Example of shell for backing up after synchronization point dump validation

Example

While the system is operating without unloading the system log, data is backed up after a synchronization point dump has been validated so that the system log files created before the backup can be released:

#!/bin/sh
$PDDIR/bin/pdlogsync -d sys -w
if [ $status = 0 ] ; then
   $PDDIR/bin/pdcopy -m host2:/dbarea/area1/rdmt1 -i -p /usr/ofile
   -f /usr/seifile/cofl01
   -z /usr/logpoint/logp01
else
   echo "synchronization-point-dump-validation-error"
fi

Explanation

Because the -w option is specified in the pdlogsync command, the synchronization point dump has been validated if the return code is 0.

When the synchronization point dump is validated, the database copy utility (pdcopy command) is used to execute backup processing. If validation failed, backup processing is not executed.

6.7 Backup acquisition using JP1/OmniBack II (applicable to HP-UX only)

When JP1/OmniBack II is used, various media such as DLT can be used as the backup destination. This section explains the use of JP1/OmniBack II to make backups. This section assumes that the reader is familiar with JP1/OmniBack II.

Conditions

Use of JP1/OmniBack II Version 05-20 is assumed.

JP1/OmniBack II cannot be used in 64-bit-mode HiRDB.

Organization of this section

6.7.1 System configuration example

6.7.2 Environment setup

6.7.3 Notes on backup acquisition

6.7.4 Example 1 (HiRDB/Single Server)

6.7.5 Example 2 (HiRDB/Parallel Server)

6.7.1 System configuration example

Organization of this subsection

(1) HiRDB/Single Server

(2) HiRDB/Parallel Server

(1) HiRDB/Single Server

Figures 6-3 and 6-4 show examples of a system configuration when JP1/OmniBack II is used to make backups.

Figure 6-3 System configuration example for backup made using JP1/OmniBack II: JP1/OmniBack II handles communications between server machines

Explanation

JP1/OmniBack II must be installed at each server machine.

Figure 6-4 System configuration example for backup made using JP1/OmniBack II: HiRDB handles communications between server machines

Explanation

When HiRDB handles communications between server machines, JP1/OmniBack II must be installed at the server machine in which the utility special unit is located.

(2) HiRDB/Parallel Server

Figures 6-5 and 6-6 show examples of a system configuration when JP1/OmniBack II is to be used to make backups.

Figure 6-5 System configuration example for backup made using JP1/OmniBack II: JP1/OmniBack II handles communications between server machines

Explanation

JP1/OmniBack II must be installed at each server machine.

Figure 6-6 System configuration example for backup made using JP1/OmniBack II: HiRDB handles communications between server machines

Explanation

When HiRDB handles communications between server machines, JP1/OmniBack II must be installed at the server machine in which the backup device is located.

6.7.2 Environment setup

The following environment settings are required in order to make backups.

Organization of this subsection

(1) Obtaining a license for and installing JP1/OmniBack II

(2) Distributing the disk agent and media agent

(3) Registering users into JP1/OmniBack II

(4) Creating a logical device

(5) Creating a directory for storing barlist files

(6) Creating a barlist file

(7) Setting automatic processing of the mount prompt

(1) Obtaining a license for and installing JP1/OmniBack II

Obtain a license for and install JP1/OmniBack II. For details on licensing, see the materials included with the JP1/OmniBack II software.

After installing JP1/OmniBack II, execute the pdsetup command in each server machine. In this step, specify OmniBack in the -p option. If the pdsetup command has already been executed, first execute the pdsetup -d command, then execute the pdsetup command. For details on the pdsetup command, see the manual HiRDB Version 8 Command Reference. OmniBack must be specified in the -p option for all server machines comprising HiRDB.

(2) Distributing the disk agent and media agent

For details about distributing the disk agent and media agent, see the manual for JP1/OmniBack II.

(3) Registering users into JP1/OmniBack II

Register the HiRDB administrator as a JP1/OmniBack II user in the admin user class.

(4) Creating a logical device

For details about creating a logical device, see the manual for JP1/OmniBack II.

(5) Creating a directory for storing barlist files

Create the applicable directory listed below (directory for storing barlist files) in the server machine in which the cell manager of JP1/OmniBack II is located:

HP-UX: /etc/opt/omni/barlists/stream

Set up the directory privileges, etc., as follows:

User: root

Group: sys

Privilege: 0755

(6) Creating a barlist file

Create a barlist file in the directory created in Step (5). Set up the barlist file privilege, etc., as follows:

User: root

Group: sys

Privilege: 0644

Up to 64 alphanumeric characters can be used for a barlist file name; the following is an example of creating a barlist file:

BARLIST "barlist-file-name"                      1
DEFAULTS
{
}
DEVICE "logical-device-name"                     2
{
}
CLIENT HiRDB host-name                           3
{
  -public                                        4
} -protect protection-specification              5

Explanation

Specifies a name for the barlist file.
Example:
BARLIST "DLT01FILE"

Specifies the name of the logical device.
Example:
DEVICE "DLT01"

Specifies the name of the host where the disk agent is located.
Example:
CLIENT HiRDB host01

This is required.

Specifies the object protection type; no protection, specified duration, until a specified date, or permanent protection can be specified.
Example:
-protect: none

none: No protection

days n: Specify for n a protection duration in terms of number of days.

weeks n: Specify for n a protection duration in terms of number of weeks.

until Date: Specify for date the date on which protection is to expire (use the format YYYY/MM/DD).

permanent: Specify for permanent protection.

About object protection specification

When object protection is specified, the medium cannot be reused until protection for all objects on the medium has been released. Because this fact should be taken into consideration when protection is specified, the following guidelines for specifying protection are provided:

Guidelines

If the medium is to be overwritten each time, specify there be no protection (none). In this case, only one object can be stored on the medium.

When protection is specified, multiple objects can be stored on the same medium. In this case, store objects with approximately the same protection expiration dates. This makes it possible for the medium to be reused efficiently, because protection of all objects on the medium will expire at about the same time.

(7) Setting automatic processing of the mount prompt

Set automatic processing of JP1/OmniBack II's mount prompt. For details about automatic processing of the mount prompt, see the manual for JP1/OmniBack II.

6.7.3 Notes on backup acquisition

Organization of this subsection

(1) Backup acquisition units

(2) Checking the status of JP1/OmniBack II

(3) Backup acquisition example

(1) Backup acquisition units

If there is a large volume of data, do not back up all RDAREAs into a single object. If all RDAREAs are backed up into a single object, restoration of a specific RDAREA will take a long time because the RDAREAs must be loaded sequentially. Therefore, it is recommended that RDAREAs be divided into groups for making backups.

For example, when a disk error occurs, RDAREAs are restored one disk at a time, so it is recommended that the backup of a single disk be collected into a single object.

(2) Checking the status of JP1/OmniBack II

Execute the omnistat command of JP1/OmniBack II to check the status of JP1/OmniBack II during execution of the pdcopy or pdrstr command.

(3) Backup acquisition example

In this example, multiple backup generations are saved.

Conditions

Slots 1, 2, and 3 of the DLT library are defined in logical device 1 of JP1/OmniBack II.

Slots 4, 5, and 6 of the DLT library are defined in logical device 2 of JP1/OmniBack II.

Operation example

The first backup is collected as object 1 on November 30, 2000, into logical device 1. The protection expiration date is set to December 13, 2000.

The second backup is collected as object 2 on December 7, 2000, into logical device 2. The protection expiration date is set to December 20, 2000.

The third backup is collected as object 1 on December 14, 2000, into logical device 1. The protection expiration date is set to December 27, 2000.

When the protection expiration dates are specified in this overlapping manner, the medium is reused efficiently.

Note that if permanent protection is specified, you must use JP1/OmniBack II's omnidb command to release object protection when the third and subsequent backups are made.

6.7.4 Example 1 (HiRDB/Single Server)

All RDAREAs are backed up during operation of a HiRDB/Single Server. The system configuration is shown in Figure 6-3.

Organization of this subsection

(1) Using the pdlogswap command to swap system log files

(2) Using the pdcopy command to back up all RDAREAs

(1) Using the pdlogswap command to swap system log files

System log files are swapped in order to physically separate the system logs required for database restoration. To restore the RDAREAs from the backup copy to be created in step (2), the system log collected subsequently (the system log in the file to be used as the current file after swapping) will be used as input information.

pdlogswap -d sys -w

(2) Using the pdcopy command to back up all RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -k o -b host02:backup001 -G DLT01
-z /lopoint/point01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up.

-k: Specifies the backup file type. o is specified because backup is to be made into a JP1/OmniBack II object.

-b: Specifies the name of the JP1/OmniBack II object as the backup file name. The format is host-name:object-name.

-G: Specifies the barlist file name.

-z: Specifies the name of the log point information file. Specify this option when operation without unloading the system log or the automatic log unloading facility is being used.

-p: Specifies the file name for the pdcopy command's processing results listing.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

6.7.5 Example 2 (HiRDB/Parallel Server)

RDAREAs under a unit are backed up during operation of a HiRDB/Parallel Server.

The system configuration is shown in Figure 6-3 System configuration example for backup made using JP1/OmniBack II: JP1/OmniBack II handles communications between server machines. The RDAREAs under unit UNT2 in server machine 2 are backed up. The backup is to be stored in a JP1/OmniBack II object in server machine 3.

Organization of this subsection

(1) Using the pdlogswap command to swap system log files under the unit

(2) Using the pdcopy command to back up the unit

(1) Using the pdlogswap command to swap system log files under the unit

System log files are swapped in order to physically separate the system logs needed for database restoration. To restore the RDAREAs from the backup copy to be created in step (2), the system log collected subsequently (the system log in the file to be used as the current file after swapping) will be used as input information.

pdlogswap -d sys -s bes3 -w

(2) Using the pdcopy command to back up the unit

pdcopy -m /rdarea/mast/mast01 -M r -u UNT2 -k o -b host03:backup002 -G DLT02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-u: Specifies that all RDAREAs under unit UNT2 are to be backed up.

-k: Specifies the backup file type. o is specified because backup is to be made into a JP1/OmniBack II object.

-b: Specifies the name of the JP1/OmniBack II object as the backup file name. The format is host-name:object-name.

-G: Specifies the barlist file name.

Remarks

When the automatic log unloading facility is being used, execute the pdlogatul command to record the name of the unload log file that corresponds to the current system log file when backup is being made.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

6.8 Backup acquisition using backup-hold (backup without using the pdcopy command)

This section explains how to make a backup without using the pdcopy command (making a backup using another product's facilities). When a backup is made without using the pdcopy command, the RDAREAs must be backed up and held.

For details on how to restore a database without using the pdcopy command, see 19.5 Recovery procedure when the backup was not made with the pdcopy command.

Organization of this section

6.8.1 About backup-hold

6.8.2 Example 1 (using another product's backup facilities)

6.8.3 Example 2 (using the mirror disk facility)

6.8.1 About backup-hold

In the following cases, the target RDAREAs must be backed up and held:

When a backup is made without using the pdcopy command (when backup is made using another product's facilities; e.g., when a backup is made using the backup acquisition facility of JP1/OmniBack II)

When the Logical Volume Manager is used for the database (to execute the pdcopy command in the updatable mode, the target RDAREAs must be backed up and held)

When RDAREAs are backed up and held, the backup can be made even during an online session. Specify the -b option in the pdhold command to back up and hold RDAREAs.

Organization of this subsection

(1) Types of backup-hold

(2) Conditions (RDAREA configuration)

(3) Notes

(4) Relationship to lock

(5) Volume of system log information output during updatable backup-hold

(6) Determining the system logs needed for database restoration

(1) Types of backup-hold

The four types of backup-hold are explained in Table 6-5.

Table 6-5 Types of backup-hold

Backup-hold type
Explanation

Reference-possible backup-hold
During backup-hold, RDAREAs that have been backed up and held can be referenced; an updating attempt results in an SQL error (-920).
Characteristics and precautions

Using the backup made here, the database can be restored to the backup acquisition point.

No deadlock with an updating transaction occurs.

If a no-log-mode updating transaction is executed for an RDAREA that is in reference-possible backup-hold status, the updating transaction goes into lock-release wait status for the RDAREA, causing an error after lock release. As a result, the RDAREA goes into error shutdown status.

Reference-possible backup-hold (update WAIT mode)
During backup-hold, RDAREAs that have been backed up and held can be referenced; an updating attempt goes into lock-release wait status until the backup-hold is released.
Characteristics and precautions

Using the backup made here, the database can be restored to the backup acquisition point.

Specify in the pd_lck_wait_timeout operand or the PDCWAITTIME operand of the client environment definition a time value that is longer than the backup-hold period. If the updating transaction times out, an SQL error (-770) occurs.

Deadlock may occur with an updating transaction. To ensure that the updating transaction does not terminate with an error, specify pd_deadlock_priority_use = Y. If deadlock occurs, all locks in the backup-hold collected by the pdhold command are released, and the same backup-hold processing is attempted again for up to five times. If deadlock results on the fifth retry, all locks in the backup-hold collected by the pdhold command are released, and the pdhold command terminates in an error.

If a no-log-mode updating transaction times out or terminates in an error after a deadlock, an updated RDAREA goes into error shutdown status.

Updatable backup-hold
During backup-hold, RDAREAs that have been backed up and held can be referenced and updated. Even while an updating transaction is being executed, an RDAREA is placed immediately in updatable backup-hold status without placing the pdhold command in wait status.
Characteristics and precautions

The database cannot be restored to the backup acquisition point; it can only be restored to a synchronization point after the backup acquisition point. To restore the database, the backup and the system log from a synchronization point immediately prior to backup acquisition are required.

If an updating transaction in the pre-update log acquisition mode or the no-log mode is executed between the previous synchronization point and the current time, do not apply updatable backup-hold; the database cannot be restored using this backup.

Updatable backup-hold (WAIT mode)
During backup-hold, RDAREAs that have been backed up and held can be referenced and updated. If an updating transaction is being executed, the pdhold command is kept waiting until the transaction terminates.
Characteristics and precautions

When the contents of a buffer that was updated by an update transaction occurring during backup-hold are applied to an RDAREA, the KFPH00157-W message is output when backup-hold is released. When this message has been output, the database cannot be restored to the backup acquisition point; it can only be restored to a synchronization point subsequent to the backup acquisition point. Therefore, to restore the database, you must have a system log from the time at which execution of the backup hold command began.

If the KFPH00157-W message was not output, you can use the backup made here to recover the database to its status at the time of the backup. However, if the backup was made in the pdcopy command's updatable mode (-M s specified), the database cannot be restored to the backup acquisition point; it can only be restored to a synchronization point after the backup acquisition point. To restore the database, the backup and the system log from the synchronization point immediately prior to backup acquisition are required.

An updating transaction in the pre-update log acquisition mode or the no-log mode is placed in lock-release wait status at the RDAREA that has been backed up and held. Therefore, specify in the pd_lck_wait_timeout operand or the PDCWAITTIME operand of the client environment definition a time value that is longer than the backup-hold period. If the updating transaction times out, it terminates in an error.

Deadlock may occur between an updating transaction in the pre-update log acquisition mode and an updating transaction in the no-log mode. To ensure that the updating transaction does not terminate in an error, specify pd_deadlock_priority_use=Y. If deadlock occurs, all locks in the backup-hold collected by the pdhold command are released, and the same backup-hold processing is attempted again for up to five times. If deadlock results on the fifth retry, all locks in the backup-hold collected by the pdhold command are released, and the pdhold command terminates in an error.

If an updating transaction in the pre-update log acquisition mode or the no-log mode times out or terminates in an error after a deadlock, an updated RDAREA goes into error shutdown status.

Reference note

Reference-possible backup hold and reference-possible backup hold (update WAIT mode) are also referred to as committing a database; they are required when the inner replica facility is used. For details about the inner replica facility, see the manual HiRDB Staticizer Option Version 7 Description and User's Guide.

(2) Conditions (RDAREA configuration)

Place the files comprising the RDAREAs to be backed up on a disk, so that they can all be backed up in a single backup operation.

When creating a HiRDB file system area for RDAREAs in a regular file, specify the -i option in the pdfmkfs command.

To restore the database to the most recent synchronization point after an error has occurred (including restoration with a range specified), the master directory RDAREA and other RDAREAs must be restored separately. Therefore, take one of the following measures so that the master directory RDAREA can be restored separately:

Create a partition and logical volume for storing the master directory RDAREA only, thus enabling backup exclusively for the master directory RDAREA.

Use the pdcopy command to back up the RDAREAs in the partition containing the master directory RDAREA.

(3) Notes

If HiRDB is terminated abnormally or forcibly while the disk being used by HiRDB is being backed up, that backup becomes invalid. In this case, make the backup again.

If the RDAREA is in updatable backup hold or updatable backup hold (WAIT mode) status, RDAREA automatic extension is suppressed. For this reason, you should refrain from executing a job to add or update a large volume of data that requires allocation of new pages while the RDAREA is in either of these hold statuses. To cancel suppression of RDAREA automatic extension, use the pdrels command to release the RDAREA from the hold.

When you use a function other than the pdcopy command (i.e., a function provided by a different product) to make a backup, do not execute the database structure modification utility (pdmod command) while the backup processing is underway.

If HiRDB is terminated abnormally or forcibly during backup-hold, the backup-hold may not be inherited when HiRDB is restarted, depending on the backup-hold type. In this case, make a backup by implementing the backup-hold again. Table 6-6 shows the backup-hold inheritance status during HiRDB reactivation.

Table 6-6 Backup-hold inheritance states during HiRDB reactivation

Backup-hold type | Backup-hold status inheritance during reactivation
Reference-possible backup-hold | Yes
Reference-possible backup-hold (update WAIT mode) | No
Updatable backup-hold | No
Updatable backup-hold (WAIT mode) | No

Yes: Status is inherited.

No: Status is not inherited.

(4) Relationship to lock

(a) Lock-release timeout during backup-hold

Note that a lock-release timeout might occur when the following backup-hold modes are used:

Reference-possible backup-hold (update WAIT mode)

Updatable backup-hold

Updatable backup-hold (WAIT mode)

For a reference-possible backup-hold (update WAIT mode), an updating transaction waits for lock release at the RDAREA that has been backed up and held (resource type 0602) until the backup-hold is released. In the updatable backup-hold and updatable backup-hold (WAIT mode) modes, an updating transaction in the no-log mode or pre-update log acquisition mode waits for lock release at the RDAREA that has been backed up and held (resource type 0602) until the backup-hold is released.

Consequently, if the value specified in the pd_lck_wait_timeout operand or the PDCWAITTIME operand of the client environment definition is shorter than the time between backup-hold and its release, the updating transaction terminates in an error. If such an error occurs, change the specification values of these operands.

Backup acquisition in these modes is recommended when the mirror disk facility with a short duration between shutdown and release (the time needed for dividing the logical volume only) is used for making backups.

(b) Deadlock during backup-hold

Note that a deadlock might occur when backup and hold is applied to multiple RDAREAs in the following modes:

Reference-possible backup-hold (update WAIT mode)

Updatable backup-hold

Updatable backup-hold (WAIT mode)

In the reference-possible backup-hold (update WAIT mode) mode, deadlock with an updating transaction may occur. In the updatable backup-hold and updatable backup-hold (WAIT mode) modes, deadlock may occur with an updating transaction in the no-log mode or pre-update log acquisition mode. To ensure that the updating transaction does not terminate in an error, specify pd_deadlock_priority_use = Y. In this case, if deadlock occurs, the pdhold command terminates in an error. Therefore, re-execute the pdhold command after a short while. If multiple RDAREAs are specified in the pdhold command, backup-and-hold processing for all RDAREAs becomes invalid. If multiple RDAREAs are backed up and held using the pdhold command multiple times, deadlock may occur in the RDAREAs that have been backed up and held. In this case, first release the RDAREAs that have been backed up and held and then re-execute the pdhold command. Therefore, when applying backup and hold to multiple RDAREAs, specify multiple RDAREAs in a single pdhold command (repeat execution of the command until successful).

In the case of a HiRDB/Parallel Server, global deadlock can occur if RDAREAs on different servers are specified. HiRDB cannot detect global deadlock, so the transactions result in timeout errors. To avoid global deadlock, execute the pdhold command in units of servers when you specify more than one RDAREA.

(5) Volume of system log information output during updatable backup-hold

When the database is updated during updatable backup-hold, the volume of system log information that is output increases by the amount determined by the following formula:

Note

If HiRDB is terminated abnormally or forcibly during backup-hold, the backup-hold is not inherited during HiRDB reactivation (except when reference-possible backup-hold is used). Consequently, the amount of system log information indicated by this formula is not output in this case.

a: Number of RDAREAs updated during updatable backup-hold

Si: RDAREA page size (bytes)

Ti: Number of pages updated in the RDAREAs updated during updatable backup-hold

The number of updated pages in the RDAREAs is determined according to the following procedure.

Procedure

To determine the number of updated pages in the RDAREAs:

Execute the statistics analysis utility (HiRDB file statistical information related to database operations) at the following times:
At the start of updatable backup-hold
At the release of updatable backup-hold

Refer to the number of synchronous WRITEs (SYNC-W) and determine the number of updated pages from the difference.

(6) Determining the system logs needed for database restoration

To restore the database to the most recent synchronization point (including restoration with a range specified), the system logs after the backup acquisition are needed. Table 6-7 shows how to determine the system logs needed for database restoration.

Table 6-7 Determining the system logs needed for database restoration (when backup-hold is being used)

Condition
Determining the system logs needed for database restoration

Referencing-possible backup-hold

Referencing-possible backup-hold (update WAIT mode)

The system log subsequent to when the backup was made is needed. Before making a backup, execute the pdlogls command to record the following information about the current system log:

System log service run ID (Run ID)

System log file generation number (Gen No.)

System log file's file group name (Group)

Also record the date and time of backup. Specify this time if the -T option is to be specified in the pdrstr command.

Updatable backup hold (WAIT mode)
The system log from the point at which execution of the backup hold command began is required. Before executing backup hold, execute the pdlogls command to record the following information:

System log service run ID (Run ID)

System log file generation number (Gen No.)

System log file's file group name (Group)

Also record the date and time at which execution of backup hold began. Specify this time if the -T option is to be specified in the pdrstr command.

Updatable backup-hold
Refer to the KFPS02183-I message, which indicates the starting position of the system logs needed for database restoration.*
The system log file file group name, generation number, and synchronization point dump acquisition start time indicated in the KFPS02183-I message output before the updatable backup-hold indicate the starting position of the system logs needed for database restoration. The system log service run ID can be checked with the pdlogls command.
Specify the synchronization dump acquisition start time if the -T option is to be specified in the pdrstr command.

The Logical Volume Manager (LVM) is used and the pdcopy command is executed in the updatable mode.
Refer to the pdcopy command's processing results listing.

* When pd_spd_assurance_msg=N is specified, the KFPS02183-I message is not output.

6.8.2 Example 1 (using another product's backup facilities)

Back up RDAREAs (rdarea01 and rdarea02) while HiRDB is operating. Use another product's backup facility to back up the HiRDB file system area that comprises these RDAREAs.

Organization of this subsection

(1) Using the pdhold command to back up and hold the RDAREAs to be backed up

(2) Making the backup

(3) Using the pdrels command to release backup and hold of RDAREAs

(1) Using the pdhold command to back up and hold the RDAREAs to be backed up

pdhold -r rdarea01,rdarea02 -b -w

Explanation

-r: Specifies the RDAREAs to be backed up.

-b -w: Specifies reference-possible backup hold (update WAIT mode).

(2) Making the backup

Use another product's backup facility to back up the HiRDB file system area that comprises the RDAREAs (rdarea01 and rdarea02).

Remarks

When the automatic log unloading facility is being used, execute the pdlogatul command to record the unload log file name that corresponds to the current system log file.

(3) Using the pdrels command to release backup and hold of RDAREAs

pdrels -r rdarea01,rdarea02

It is recommended that, after the command has executed, you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

6.8.3 Example 2 (using the mirror disk facility)

This example assumes that data is mirrored using the Logical Volume Manager (LVM) and a mirror facility (it is assumed that the reader is familiar with LVM). For details on data mirroring using LVM and execution of online backup through logical volume partitioning, see the appropriate HP-UX manual). Figure 6-7 shows an example of backup using a mirror facility.

To avoid input/output contention between the backup disk and the online disk when mirroring is used, separate the I/O channels.

Figure 6-7 Example of backup using a mirror facility

The two RDAREAs rdarea01 and rdarea02 are backed up while HiRDB is running.

Organization of this subsection

(1) Using the pdhold command to back up and hold the RDAREAs to be backed up

(2) Partitioning the mirrored logical volume

(3) Using the pdrels command to release backup and hold of RDAREAs

(4) Making the backup from the offline logical volume

(1) Using the pdhold command to back up and hold the RDAREAs to be backed up

pdhold -r rdarea01,rdarea02 -b -w

Explanation

-r: Specifies the RDAREAs to be backed up.

-b -w: Specifies reference-possible backup hold (update WAIT mode).

(2) Partitioning the mirrored logical volume

The logical volume containing the HiRDB files comprising the RDAREAs to be backed up is partitioned.

(3) Using the pdrels command to release backup and hold of RDAREAs

pdrels -r rdarea01,rdarea02

(4) Making the backup from the offline logical volume

The backup is made from the offline logical volume. When a mirror facility is used to make a backup, backup-hold occurs only during logical volume partitioning. Therefore, the amount of physical log information for the pages to be output is reduced.

Remarks

When the automatic log unloading facility is being used, execute the pdlogatul command to record the unload log file name that corresponds to the current system log file.

6.9 Backup acquisition when the frozen update command (pddbfrz command) is used

The function that supports reducing the amount of time required to back up user LOB RDAREAs provides the frozen update command (pddbfrz command). This section describes how to back up user LOB RDAREAs when you use the frozen update command.

Organization of this section

6.9.1 Operation subject to the frozen update command

6.9.2 Operation of the frozen update command (pddbfrz command)

6.9.3 Operation example

6.9.4 Checking for files with full data pages

6.9.5 Manipulating user LOB RDAREAs for which the frozen update command has been executed

6.9.6 Relationship between RDAREAs and automatic extensions

6.9.7 Notes

6.9.1 Operation subject to the frozen update command

Under the following operational conditions, the frozen update command (pddbfrz command) can be used in conjunction with backing a up user LOB RDAREA as quickly as possible:

A method other than the database copy utility (pdcopy command) is used to back up the user LOB RDAREA.

Backup is in units of HiRDB files.

Updating and deletion of registered LOB data do not normally occur (the typical operation is to add LOB data).

The user LOB RDAREA to be backed up consists of multiple HiRDB files.

6.9.2 Operation of the frozen update command (pddbfrz command)

When the frozen update command is executed, all HiRDB files with full data pages (completely allocated pages) in the user LOB RDAREA are placed in frozen update status. Data in HiRDB files that are in frozen update status cannot be updated or deleted. Figure 6-8 provides an overview of the processing by the frozen update command.

Figure 6-8 Overview of frozen update command processing

Explanation

The user LOB RDAREA consists of HiRDB files 1-4. Files 2 and 3 have full data pages. For details about checking for HiRDB files with full data pages, see 6.9.4 Checking for files with full data pages.

When the frozen update command is executed for this user LOB RDAREA, HiRDB files 2 and 3 are placed in frozen update status. HiRDB files placed in frozen update status are displayed in the KFPH27024-I message.

HiRDB files 1 and 4 are in permit update status.

Organization of this subsection

(1) Using the frozen update command in order to make backups

(2) Procedure for making a backup

(3) Releasing frozen update status

(4) Checking for HiRDB files in frozen update status

(5) HiRDB files that cannot be placed in frozen update status

(1) Using the frozen update command in order to make backups

Figure 6-9 shows how to use the frozen update command in order to make backups.

Figure 6-9 Using the frozen update command in order to make backups

Explanation

The frozen update command is executed before making backups, thereby placing HiRDB files 2 and 3 in frozen update status.

Back up all HiRDB files (HiRDB files 1-4) when the first backup is made.

Because HiRDB files 2 and 3 are in frozen update status, their contents will not change after that first backup is made. Thus, it will not be necessary to back up HiRDB files 2 and 3 when the next backup is made; only HiRDB files 1 and 4 will need to be backed up.

Remarks

Because the lead HiRDB file (HiRDB file 1 in Figure 6-9) contains management records, write transactions always occur in it even if its data portion is full. Consequently, the lead HiRDB file is never placed in frozen update status and must always be backed up.

(2) Procedure for making a backup

The procedure for making a backup is described below. For an operation example, see 6.9.3 Operation example.

Procedure

Use the frozen update command to place the HiRDB files with full data pages in frozen update status.

Use the KFPH27024-I message or the database condition analysis utility (pddbst command) to check the HiRDB files that are in frozen update status.

Make a backup. Include all HiRDB files in the first backup. In the second and subsequent backups, include only the HiRDB files that are in permit update status; it will not be necessary to include the HiRDB files that are in frozen update status.

(3) Releasing frozen update status

To release a HiRDB file from frozen update status, execute the pddbfrz -d command.

Reinitializing RDAREAs also releases frozen update status.

(4) Checking for HiRDB files in frozen update status

Execute the database condition analysis utility (the pddbst command) to check which HiRDB files are in frozen update status.

(5) HiRDB files that cannot be placed in frozen update status

The following HiRDB files cannot be placed in frozen update status:

HiRDB files in other than user LOB RDAREAs

Lead HiRDB files in user LOB RDAREAs

HiRDB files in user LOB RDAREAs that store plug-in indexes

HiRDB files in unused user LOB RDAREAs (without any table definitions)

HiRDB files with logical files created by data type plug-ins*

* In the case of user LOB RDAREAs used by data type plug-ins, HiRDB files with logical files used by plug-ins cannot be placed in frozen update status. A logical file is normally found only in the lead HiRDB file, but when expansion of the logical files occurs, a logical file may be found in an HiRDB file other than the lead file. Therefore, if you are using data type plug-ins, you should estimate the size for the lead HiRDB file so that it can store logical files for plug-ins created by CREATE TABLE.

6.9.3 Operation example

This section provides an example of backing up a user LOB RDAREA (LOB001) under the following operational conditions:

The user LOB RDAREA (LOB001) consists of three HiRDB files.

As data is added, HiRDB files are added and the user LOB RDAREA (LOB001) is expanded.

Organization of this subsection

(1) Execute the frozen update command on the user LOB RDAREA (LOB001)

(2) Make a backup

(3) Make backups regularly

(4) Add HiRDB files and expand the user LOB RDAREA (LOB001)

(5) Make a backup

(6) Use the database condition analysis utility (pddbst command) to check for full data pages

(7) If more files with full data pages have been issued, execute the frozen update command

(8) Make a backup

(9) Make backups regularly

(1) Execute the frozen update command on the user LOB RDAREA (LOB001)

pddbfrz -r LOB001

Explanation

The HiRDB file with full data pages (file02) is placed in frozen update status. Refer to the KFPH27024-I message or use the database condition analysis utility (pddbst command) to confirm the HiRDB files that have been placed in frozen update status.

(2) Make a backup

Back up the user LOB RDAREA (LOB001) using some method other than the database copy utility. Make the backup in units of the HiRDB files comprising the user LOB RDAREA (LOB001).

Explanation

All the HiRDB files are backed up (file01, file 02, and file 03).

For details about making a backup using methods other than the database copy utility (pdcopy command), see 6.8 Backup acquisition using backup-hold (backup without using the pdcopy command).

(3) Make backups regularly

Make backups on a regular schedule, such as once a week.

Explanation

Only the HiRDB files in permit update status are backed up (file01 and file 03). You do not need to back up the HiRDB file in frozen update status (file02).

(4) Add HiRDB files and expand the user LOB RDAREA (LOB001)

For details about expanding the user LOB RDAREA (LOB001), see 15.3 Increasing the size of an RDAREA (RDAREA expansion).

Explanation

A HiRDB file (file04) is added and the user LOB RDAREA (LOB001) is expanded.

(5) Make a backup

After expanding the user LOB RDAREA (LOB001), back it up. Always make a backup, even if the number of segments used in a file is 0; for the reason, see 6.9.7 Notes.

Explanation

HiRDB files in permit update status (file01, file 03, and file 04) are backed up. Backing up the HiRDB file in frozen update status (file 02) is not necessary.

(6) Use the database condition analysis utility (pddbst command) to check for full data pages

When LOB data is added, additional HiRDB files with full data pages may be issued. Use the database condition analysis utility (pddbst command) to check for files with full data pages. For details about checking for files with full data pages, see 6.9.4 Checking for files with full data pages.

pddbst -r LOB001

(7) If more files with full data pages have been issued, execute the frozen update command

If more files with full data pages have been issued, as determined in step (6), execute the frozen update command.

pddbfrz -r LOB001

Explanation

HiRDB files with full data pages (file02 and file03) are placed in frozen update status. Refer to the KFPH27024-I message or use the data condition analysis utility (pddbst command) to confirm the HiRDB files that have been placed in frozen update status.

(8) Make a backup

Back up the user LOB RDAREA.

Explanation

HiRDB files file01, file03, and file04 are backed up; it is not necessary to back up HiRDB file file02.

(9) Make backups regularly

Make backups on a regular schedule, such as once a week.

Explanation

Only the HiRDB files in permit update status are backed up (file01 and file04). You do not need to back up the HiRDB files in frozen update status (file02 and file03).

6.9.4 Checking for files with full data pages

You use the database condition analysis utility (pddbst command) to execute physical analysis of RDAREAs in order to determine if there are HiRDB files that are full.

Execution example of the database condition analysis utility

RD Area Name   : LOB001
   :
   :
Freeze Specified : Y
 HiRDB File Name : /rdarea/lob001/file01
  File Size      :       8192 segments   Extent Count :   1/ 24
  Segment        :       8190/      8192
  Freeze Status  : U
 HiRDB File Name : /rdarea/lob001/file02
  File Size      :       8192 segments   Extent Count :   1/ 24
  Segment        :       8000/      8192
  Freeze Status  : F    2001/12/06    20:37:05
 HiRDB File Name : /rdarea/lob001/file03
  File Size      :       8192 segments   Extent Count :   1/ 24
  Segment        :       1000/      8192
  Freeze Status  : U

Explanation

The information in the underlined portions above tells you that the HiRDB file currently being used (where date is being stored currently) is /rdarea/lob001/file03. Therefore, the previous HiRDB file (/rdarea/lob001/file02) has become full.

Remarks

LOB data is stored in consecutive pages as much as possible, so if data will not fit onto a single page, there may be some pages at the end of the HiRDB file that are not usable, as shown in this example.

When LOB data is deleted, the page that was used does not become 100% free. This is why the example shows 8000 out of 8192 segments.

When the page of the HiRDB file being used (such as in /rdarea/lob001/file03) is the last page, that HiRDB file is also considered to be full.

Other items in the example that relate to frozen update status are explained below.

Freeze Specified: Indicates whether or not the frozen update command has been executed for the RDAREA:

Y: Frozen update command has been executed.

N: Frozen update command has not been issued.

Freeze Status: Indicates whether the HiRDB file is in frozen update status of permit update status:

F: File is in frozen update status.

U: File is in permit update status.

6.9.5 Manipulating user LOB RDAREAs for which the frozen update command has been executed

Some manipulations cannot be executed on user LOB RDAREAs for which the frozen update command has been executed, as indicated in Table 6-8. If you must execute on a LOB RDAREA a manipulation that Table 6-8 shows cannot be executed, use the frozen update command with the -d option specified to release the user LOB RDAREA's frozen update status. After executing the manipulation, you must back up all HiRDB files in the user LOB RDAREAs again.

Table 6-8 Manipulations executable on user LOB RDAREAs for which the frozen update command has been executed

Manipulation | Status of HiRDB files
Frozen update status | Permit update status
SQL (data manipulation) | INSERT |  | Yes
UPDATE | No | Yes
DELETE | No | Yes
SQL (table manipulation) | PURGE TABLE | No | No
DROP TABLE | No | No
Database load utility | Add mode |  | Yes
Load mode | No | No
Database reorganization utility (table reorganization, table reloading) | No | No
Rebalancing utility | No | No
Database structure modification utility | Yes | Yes
Database recovery utility | Yes | Yes
Operation command | Yes | Yes

Legend:

Yes: Can be executed

No: Cannot be executed

: Not applicable.

6.9.6 Relationship between RDAREAs and automatic extensions

If an automatic extension is set up for the last HiRDB file of a user LOB RDAREA and that HiRDB file is placed in frozen update status, the automatic extension of the RDAREA is disabled. If you add HiRDB files and extend the user LOB RDAREA, the automatic extension is operable.

You cannot set up an RDAREA automatic extension if the last HiRDB file of the user LOB RDAREA is in frozen update status. You must add HiRDB files and set up the RDAREA automatic extension when you extend the user LOB RDAREA.

6.9.7 Notes

Organization of this subsection

(1) HiRDB files to be backed up

(2) Timing at which status changes to frozen update status

(1) HiRDB files to be backed up

You should back up HiRDB files in frozen update status at least once. The management area of HiRDB files that are not in frozen update status is used regardless of whether data pages are being used. Even if the database condition analysis utility (pddbst command) is executed and the results indicate that no HiRDB files are in use, be sure that you always have a backup of the HiRDB files.

(2) Timing at which status changes to frozen update status

The status of the HiRDB files changes only when the frozen update command is executed. If a HiRDB file does not have full data pages when the frozen update command is executed but its data pages become full later after data has been added, its status will not change (that is, it will not change to frozen update status). The status of such a HiRDB file will change only if you execute the frozen update command again after the file's data pages have become full.

7. Operation Without Acquiring a Database Update Log

This chapter describes the procedures for executing a UAP or utility in the pre-update log acquisition and no-log modes.

This chapter contains the following sections:

Organization of this chapter

7.1 Database update log acquisition modes

7.2 Procedure for executing a UAP or utility in the pre-update log acquisition mode

7.3 Procedure for executing a UAP or utility in the no-log mode

7.1 Database update log acquisition modes

HiRDB collects in a system log file historical information on database updating by UAPs and utilities*. The user can specify that such a database update log not be collected. Processing time is reduced when a database update log is not collected, thereby reducing the UAP or utility execution time.

* Applies to the following utilities only:

Database load utility

Database reorganization utility

Rebalancing utility

Organization of this section

(1) Database update log acquisition modes

(2) Specifying the database update log acquisition mode

(3) RECOVERY operand

(4) Operational differences depending on the database update log acquisition mode

(5) Notes on backup (important)

(1) Database update log acquisition modes

Three database update log acquisition modes are available during UAP or utility execution:

Log acquisition mode

Database update log information necessary for rollback and rollforward is acquired.

Pre-update log acquisition mode

Database update log information necessary for rollback only is acquired.

No-log mode

Database update log information is not acquired.

(2) Specifying the database update log acquisition mode

Table 7-1 lists the database update log acquisition modes.

Table 7-1 Database update log acquisition modes

Condition | Specification of database update log acquisition mode
UAP | Specify the database update log acquisition mode in the PDDBLOG operand of the client environment definition. The log acquisition mode or the no-log mode can be specified; the pre-update log acquisition mode cannot be specified.
Database load utility | Specify the database update log acquisition mode in the -l option of the database load utility.
Database reorganization utility | Specify the database update log acquisition mode in the -l option of the database reorganization utility.
Rebalancing utility | Specify the database update log acquisition mode in the -l option of the rebalancing utility. The log acquisition mode or the no-log mode can be specified; the pre-update log acquisition mode cannot be specified.
User LOB RDAREA being used | For the data stored in a user LOB RDAREA, specify the database update log acquisition mode in the RECOVERY operand of CREATE TABLE.

(3) RECOVERY operand

The database update log acquisition mode specified with the RECOVERY operand may be changed by the specification of the PDDBLOG operand or the -l option. Table 7-2 shows the relationship between the RECOVERY operand and the PDDBLOG operand or -l option.

Table 7-2 Relationship between the RECOVERY operand and the PDDBLOG operand or -l option

PDDBLOG operand or -l option specification
RECOVERY operand specification
Value assumed during UAP (or utility) execution

ALL
a
(Log acquisition mode)
ALL
ALL

PARTIAL
PARTIAL

NO
NO

p
(Pre-update log acquisition mode)*
ALL
PARTIAL

PARTIAL
PARTIAL

NO
NO

NO
n
(No-log mode)
ALL
NO

PARTIAL
NO

NO
NO

ALL or a: Log acquisition mode

PARTIAL or p: Pre-update log acquisition mode

NO or n: No-log mode

* The pre-update log acquisition mode cannot be specified with the PDDBLOG operand.

(4) Operational differences depending on the database update log acquisition mode

The database update log acquisition mode that is used determines how the following operations are performed:

HiRDB processing and administrator actions when a UAP or utility terminates abnormally

Database recovery point

(a) HiRDB processing and administrator actions when a UAP or utility terminates abnormally

Table 7-3 describes the HiRDB processing and administrator actions when a UAP or utility terminates abnormally.

Table 7-3 HiRDB processing and administrator actions when a UAP or utility terminates abnormally

Database update log acquisition mode | HiRDB processing | User's action
Log acquisition mode | Rolls back any updated RDAREA to its status before the UAP executed or to its status immediately before the abnormal termination. | If the RDAREA was rolled back to its status before the UAP executed, re-execute the UAP. If it was rolled back to its status immediately before the abnormal termination, re-execute the processing subsequent to the synchronization point.
Pre-update log acquisition mode
No-log mode | Does not perform rollback. Places any updated RDAREA in error shutdown status (logless hold). The contents of the RDAREA are damaged. | Use the database recovery utility to restore the RDAREA from a backup made before the UAP executed, and then re-execute the UAP.

(b) Database recovery point

Table 7-4 shows the point to which the database can be recovered by the database recovery utility.

Table 7-4 Database recovery point

Database update log acquisition mode | Database recovery point
Log acquisition mode | Backup acquisition point or any synchronization point subsequent to the backup acquisition point
Pre-update log acquisition mode | Backup acquisition point
No-log mode

(5) Notes on backup (important)

Do not make a backup in the updatable mode (-M s specified) during execution of a UAP (including utilities) in the no-log mode or the pre-update log acquisition mode.

After execution of a UAP (including utilities) in the no-log mode or the pre-update log acquisition mode, make a backup in one of the following modes:

Referencing/updating-impossible mode (-M x specified)

Referencing-permitted mode (-M r specified)

7.2 Procedure for executing a UAP or utility in the pre-update log acquisition mode

Executor: HiRDB administrator

This section explains the procedure for executing a UAP or utility in the pre-update log acquisition mode. In the case of a UAP, the pre-update log acquisition mode can be used only for a user LOB RDAREA (RECOVERY operand of CREATE TABLE).

This section focuses on the operations when a utility is executed in the pre-update log acquisition mode.

Organization of this section

(1) Advantages

(2) Criteria

(3) Notes (important)

(4) Operating procedure

(1) Advantages

In this mode, database update logs are not collected after an RDAREA is updated, so processing time is reduced by a comparable amount of time, which reduces UAP or utility execution time (as compared with execution in the log acquisition mode).

(2) Criteria

This is the default mode; its use is recommended when the database load utility or database reorganization utility is executed.

(3) Notes (important)

(a) Back up any updated RDAREAs after you execute the UAP or utility

If the system log information used as input by the pdrstr command for recovery of an RDAREA includes any logs that were collected in the pre-update log acquisition mode, the pdrstr command will result in an error. Consequently, unless you back up the RDAREA before executing the UAP or utility, you will not be able to recover that RDAREA to its most recent status, if the need arises to do so (with the pdrstr command). This means that you will not be able to restore updates that occurred after the UAP or utility executed; you will only be able to restore the RDAREA to its status before the UAP or utility executed.

(b) Ensure no other users can update the RDAREA you are updating

Assume that tables T1 and T2 are stored in RDAREA1, table T1 is updated in the pre-update log acquisition mode and table T2 is updated in the log acquisition mode. If the need arises to recover RDAREA1 with the pdrstr command, it will not be possible to restore this RDAREA to its most recent status because the pdrstr command can only recover table T1 to a synchronization point prior to the updating. This is because execution of the pdrstr command results in an error if the system log information used for input includes any logs collected in the pre-update log acquisition mode.

Therefore, before executing a utility, use the pdhold command to place the RDAREA to be updated on hold. For a UAP, do not update an RDAREA that may be updated by other users.

(4) Operating procedure

For details about using the database reorganization utility in the pre-update log acquisition mode, see 13.2.3 Selecting an update log acquisition mode for a database and 13.3 Reorganizing a table (examples).

7.3 Procedure for executing a UAP or utility in the no-log mode

Executor: HiRDB administrator

This section explains the procedure for executing a UAP or utility in the no-log mode.

Organization of this section

(1) Advantages

(2) Criteria

(3) Notes (important)

(4) Relationship with other facilities

(5) Operating procedure

(6) In the event of abnormal termination of a UAP or utility

(1) Advantages

Because database update log information is not collected, the processing time is reduced, thereby reducing the UAP or utility execution time.

(2) Criteria

When a UAP that adds, updates, or deletes a large amount of data is to be executed

When a large amount of data is loaded

When table data involving a large number of tables is reorganized (reloaded)

When RDAREAs that are subject to UAP update processing in the no-log mode can be placed in exclusive use status

(3) Notes (important)

When PDDBLOG=NO is specified in the client environment definition, a table that is updated by a UAP running in the no-log mode is placed in lock mode (EX). Such a table must not be updated concurrently by another UAP.

When PDDBLOG=NO is specified (or specification is omitted) in the client environment definition and an RDAREA contains a user LOB RDAREA that is to be updated by a UAP running in the no-log mode, the user LOB RDAREA must not be updated concurrently by another UAP if NO is specified in the RECOVERY operand in the table definition. If it is updated by another UAP and the UAP in the no-log mode terminates abnormally, the update by the other UAP is invalidated.

If a UAP or utility that is running in the no-log mode terminates abnormally, any RDAREA storing a table updated by the UAP or utility is placed in error shutdown status (logless hold). HiRDB will not restore such an RDAREA; it must be restored by the HiRDB administrator. Therefore, any RDAREA placed in error shutdown status by a no-log mode UAP or utility that terminated abnormally cannot be accessed by other UAPs or utilities until the HiRDB administrator has restored it. In addition, the RDAREA can be restored only to its status at the time a backup was made.

Synchronization point dumps are not collected while a UAP or utility is executing in the no-log mode. If a system failure occurs while a UAP or utility is executing in the no-log mode concurrently with another UAP or utility, more time is required for system restart. Therefore, while a UAP or utility is being executed in the no-log mode, it is best that no other UAP or utility be executing.

(4) Relationship with other facilities

When CREATE INDEX is executed by the database definition utility and the table for which the index is to be created contains row data, the index is created in the batch mode during execution of CREATE INDEX. If PDDBLOG=NO is specified in the client environment definition in such a case, the index will be created in the batch mode without database update log information being collected. The HiRDB administrator must therefore apply the operating procedures for the no-log mode.

An RDAREA's error shutdown status is inherited at the next normal startup of HiRDB. Its open or closed status is also inherited.

(5) Operating procedure

For details about using the database reorganization utility in the no-log acquisition mode, see 13.2.3 Selecting an update log acquisition mode for a database and 13.3.7 Example 7: Reorganizing in no-log mode.

The following is the operating procedure for executing a UAP in the no-log mode:

Procedure

Use the pdcopy command to back up the RDAREA to be updated.

Execute the UAP in the no-log mode.

Use the pdlogswap command to swap system log files.

Use the pdcopy command to back up the updated RDAREA.

Note

If there are backup and system log files that can be used to restore the RDAREA to its status before the UAP was executed, you do not need to make the backup described in step 1. An exception to this is that you must always back up any user LOB RDAREA for which a plug-in index has been created in the batch mode.

(6) In the event of abnormal termination of a UAP or utility

When a UAP or utility terminates abnormally, any RDAREA that the abnormally terminated UAP or utility has updated is placed in error shutdown status (logless hold). The HiRDB administrator must recover RDAREAs that are in error shutdown status. For details about recovering RDAREAs, see 19.2 Recovering a database to the point at which a backup was made.

(a) Identifying RDAREAs placed in error shutdown status

The pddbls command can be used to identify RDAREAs that have been placed in error shutdown status.

(b) When data was not backed up before a UAP or utility was executed

When the data was not backed up before a UAP or utility was executed, a range specification must be used to recover the applicable RDAREAs; For details on recovery using a range specification, see 19.3 Recovering a database to the most recent synchronization point.

The input information for such recovery is the most recent backup copy of the RDAREAs that are in error shutdown status and the unload log file containing the information collected subsequently to the backup (system log file).

The UAP's execution start time is specified as the recovery end time in the -T option of the database copy utility.

After the database has been recovered by this procedure, the UAP or utility can be re-executed.

(c) Restoring an RDAREA from its initial data (in the event of abnormal termination of a UAP)

The following is the procedure for recovering an RDAREA from its initial data without using the database recovery utility. However, if the program that terminated abnormally is a utility, this procedure cannot be used to recover an affected RDAREA.

Procedure

Use the PURGE TABLE statement to delete all table row data that was updated by the UAP.

Use the pdrels command to release the RDAREA from error shutdown status.

Use the database load utility (pdload command) to store the initial data in the table again.

(d) Restoring an RDAREA from its initial data (in the event of abnormal termination of a utility)

The following is the procedure for recovering an RDAREA from its initial data without using the database recovery utility when the program that terminated abnormally is a utility.

Procedure

Use the pdclose command to close the RDAREA to be recovered.

Use the pdmod command to re-initialize the RDAREA.

Use the pdopen command to open the RDAREA.

Use the pdload command to reload the initial data into the table.

Use the pdrels command to release the RDAREA from error shutdown status.

8. Obtaining the System Operating Environment (Monitoring the System Status)

This chapter explains how to obtain information about the system operating environment (monitoring the system status).

This chapter contains the following sections:

Organization of this chapter

8.1 Using the message log to check the system execution status

8.2 When a UAP or utility execution takes too long

8.3 When HiRDB startup or termination processing takes too long

8.4 Obtaining RDAREA status

8.5 Obtaining shared memory utilization status

8.6 In the event of deadlock

8.7 In the event of a shortage of locked resources management tables

8.8 Monitoring UAP status (skipped effective synchronization point dump monitoring facility)

8.9 Output of warning information about the time required for SQL execution (SQL runtime warning output facility)

8.10 Monitoring the execution time of UAPs and utilities (reducing the effects of nonresponding programs)

8.11 Monitoring resource utilization factors

8.12 Monitoring the status of server processes (message queue monitoring facility)

8.13 Monitoring the number of times server processes terminate abnormally (abnormal termination monitoring facility)

8.14 Monitoring the memory size of server processes (facility for monitoring the memory size of server processes)

8.1 Using the message log to check the system execution status

Executor: HiRDB administrator

The system's execution status can be determined by checking the message log. The message log provides a historical record of HiRDB messages for the following purposes:

For checking message issued by HiRDB

For checking on errors or the causes of an error in the event of a HiRDB failure

Organization of this section

8.1.1 Referencing the message log (message log output destination)

8.1.2 Using the message log files

8.1.3 Selecting a message log output method (applicable only to a HiRDB/Parallel Server)

8.1.4 Suppressing message output to syslogfile

8.1.1 Referencing the message log (message log output destination)

Messages that are issued by HiRDB are output as message logs to message log files (under the file name $PDDIR/spool/pdlog1 or pdlog2) and to syslogfile.

You can view messages that have been output to message log files by executing the pdcat command. To view messages that have been output to syslogfile, you must use the procedure provided by the OS.

Reference note

When the pdcat command is executed, HiRDB merges the message log information contained in the message log files and outputs the messages in chronological order.

For a HiRDB/Parallel Server, you can select a message log output method (whether to output to the server machine of the system manager or to each server machine). For details, see 8.1.3 Selecting a message log output method (applicable only to a HiRDB/Parallel Server).

8.1.2 Using the message log files

HiRDB uses two message log files (pdlog1 and pdlog2) alternately. When one message log file becomes full, HiRDB stops writing messages to that file and starts writing messages to the other file. When this occurs, existing messages in the latter file are erased.

Figure 8-1 shows message log file swapping.

Figure 8-1 Message log file swapping

Explanation

When the pdlog1 message log file becomes full, the message log output destination is switched to pdlog2. When this occurs, existing messages in pdlog2 are erased.

Reference note

To determine which message log file is the current file, use the OS's ls command to check the date and time of the most recent update in each file. The file with the most recent update date and time is the current message log file.

Message log files are not swapped at the time of HiRDB startup (all startup modes). Messages continue to be output to the message log file that was the output destination when HiRDB was previously terminated.

Action to be taken by the HiRDB administrator when message log files are swapped
When the message log files are swapped, the KFPS01910-I message is output to the message log file that is about to be swapped. To save the message logs in the message log file that is about to be swapped, you must make a backup of that message log file.

Changing the message log file size
You use the pd_mlg_file_size operand to specify the message log file size. Change the size as needed.

8.1.3 Selecting a message log output method (applicable only to a HiRDB/Parallel Server)

If the system manager unit shuts down or a communication error occurs between the system manager unit and other units, message logs cannot be output normally and the following problems may arise:

No messages are displayed.

The order in which messages are displayed changes.

Message log information is output to syslogfile at the unit that issued the message, but its output is delayed.

To avoid these problems, you should consider use of message log output dispersion.

Reference note

For a HiRDB/Parallel Server, message log files are output normally to the server machine where the system manager is defined.

Organization of this subsection

(1) Message log output dispersion

(2) Criteria for selecting a message log output method

(3) Environment settings

(4) Notes on selecting message log output dispersion

(1) Message log output dispersion

For a HiRDB/Parallel Server, you can select one of the following message log output methods (message log output destinations):

Message logs are output to the message log files and to syslogfile of the server machine where the system manager is defined.

Message logs are output to the message log files and to syslogfile of a server machine. In this case, a message is output to the server machine that issued the message.

Normally, message logs are output using method 1. If desirable, you may change to method 2. Method 2 is called message log output dispersion.

You use the pd_mlg_msg_log_unit operand to select the desired method. If this operand is omitted, the default is method 1.

Figures 8-2 and 8-3 show the message output methods.

Figure 8-2 Normal message log output method (method 1)

Figure 8-3 Message log output method when message log output dispersion is used (method 2)

Reference note

When you use the pdcat command to view message logs, you will view the message logs of the unit in which the pdcat command is executed. For this reason, if message log output dispersion is used, you must execute the pdcat command at the unit where the desired message logs to be viewed are located.

(2) Criteria for selecting a message log output method

Table 8-1 shows the message log output methods; Table 8-2 shows the advantages and disadvantages of each message log output method.

Table 8-1 Message log output methods

Method selected* | Condition | Message log output destination
Method 1 (manager) | During normal operation | Message logs are output to the message log files and to syslogfile of the server machine where the system manager is defined.
When an error or communication error occurs at the manager unit | Message logs are output to syslogfile of each server machine. Only some message log information is output. Also, the correct message logs may not be output.
Method 2 (local) | During normal operation | Message logs are output to the message log files and to syslogfile of each server machine.
When an error or communication error occurs at the manager unit

* The value in parentheses ( ) is the value specified in the pd_mlg_msg_log_unit operand.

Table 8-2 Advantages and disadvantages of the message log output methods

Method selected* | Advantage | Disadvantage
Method 1 (manager) | Because message logs can be centrally managed from the server machine of the system manager, the job of monitoring messages is simpler than when local is specified. | If the system manager unit shuts down or a communication error occurs between the system manager unit and other units, the correct message logs may not be output.
Method 2 (local) | Correct message logs are output even if the system manager unit shuts down or a communication error occurs between the system manager unit and other units. | Because message logs are output to each server machine, the job of monitoring messages is more complicated than when manager is specified.

* The value in parentheses ( ) is the value specified in the pd_mlg_msg_log_unit operand.

(3) Environment settings

The following shows the environment settings for using message log output dispersion:

Procedure

Because message log files are created in each server machine, you must re-evaluate your estimate of message log file size. Specify the revised result in the pd_mlg_file_size operand.

Specify local in the pd_mlg_msg_log_unit operand.

Synchronize the time-zone settings in all server machines.

Reference note

If the time-zone settings are not synchronized among the server machines, the times in the additional information in the message logs that are output to the various server machines will be different. Therefore, when you view the message logs, you will have to take into account the time-zone differences among the server machines.

(4) Notes on selecting message log output dispersion

When you use JP1/BASE (or JP1/SES) to monitor messages, you must monitor syslogfile of all server machines.

When you specify PD_MLOG for the records to be collected by JP1/Performance Management - Agent Option for HiRDB, only the message logs that are output by the server machine where the system manager is defined are collected.

8.1.4 Suppressing message output to syslogfile

HiRDB outputs information such as error information, transaction information, and system file information to syslogfile as messages that indicate the system's operating status. Although these types of information are important for determining the operating status of HiRDB, a large volume of message information may be output depending on the operating environment, making it difficult and time-consuming to find relevant messages. You can improve message retrieval efficiency by suppressing unnecessary messages from being output to syslogfile.

Organization of this subsection

(1) Environment settings

(2) Processing when message output is suppressed

(3) Exceptions to message output suppression

(4) Usage examples

(5) Notes

(6) Relationship to other facilities (applicable only to a HiRDB/Parallel Server)

(1) Environment settings

You use the pdmlgput operand to specify the messages that are to be suppressed. This operand can also be used to specify the following:

Suppress output of all messages

Specify the messages that are to be output

(2) Processing when message output is suppressed

When message output suppression is specified, the specified messages are not output to syslogfile. Suppressed messages are output to the message log files. Table 8-3 shows the differences in message output processing depending on whether or not message output suppression is in effect.

Table 8-3 Differences in message output processing depending on whether or not message output suppression is in effect

Output suppression specification | Server machine in which the system manager is defined | Server machine in which the system manager is not defined
syslogfile | Message log file | syslogfile | Message log file
Output suppression is not specified | Y | Y | Y¹ | N
Output suppression is specified | N | Y² | N | Y1,3

Legend:

Y: Messages are output.

N: Messages are not output.

Note

For a HiRDB/Single Server, use the columns for Server machine in which the system manager is defined.

¹ For a HiRDB/Parallel Server, message logs are output to syslogfile and the message log files of the server machine where the system manager is defined. However, in the following cases, messages may not be output at all or may be output to syslogfile of the server machine that issued the messages:

The system monitor unit has not started yet or has encountered an error.

The message log server has terminated abnormally or has not been restarted yet.

The server machine is a standby system.

² Messages that are normally output to both syslogfile and the message log files are now output only to the message log files.

³ For a HiRDB/Parallel Server, pdlog1 and pdlog2 (message log files) are created under $PDDIR/spool of the server machine in which the system manager is not defined, and messages that used to be output to syslogfile are now output to these message log files.

(3) Exceptions to message output suppression

In the cases below, message output is not suppressed; instead, messages are output to syslogfile.

(a) When an error occurs in a message log file

When an error occurs in a message log file, an error message is output to syslogfile. Messages that cannot be output to the message log file because of the error are output to syslogfile.

(b) When the HiRDB system definition contains an error

Messages that report a HiRDB system definition error are not suppressed. Such error messages are output to syslogfile.

(c) Messages that are output when commands are executed

Messages that are output when the following commands are executed are not suppressed:

pdsetup

pdplgset

pdlodsv

pddbadset

(4) Usage examples

(a) Example 1

No messages are output to syslogfile and all messages are output to the message log files. The following an example of specifying the pdmlgput operand for this case:

pdmlgput -s N -c ALL

(b) Example 2

The KFPS01820 and KFPS00105 messages are not output to syslogfile, but instead are output to the message log files. The following is an example of specifying the pdmlgput operand for this case:

pdmlgput -s N -m KFPS01820,KFPS00105

(c) Example 3

Only the KFPH00211 and KFPH00212 messages are output to syslogfile and all other messages are output to the message log files. The following is an example of specifying the pdmlgput operand for this case:

pdmlgput -s N -c ALL                          ...1
pdmlgput -s Y -m KFPH00211, KFPH00212         ...2

Explanation

No messages are to be output to syslogfile and all messages are to be output to the message log files.

The KFPH00211 and KFPH00212 messages are to be output to both syslogfile and the message log files.

(5) Notes

(a) Processing when a message log file becomes full

When a message log file's capacity (value of the pd_mlg_file_size operand) is reached, the output destination for messages is swapped to the other message log file. When this swapping occurs, the KFPS01910-I message is output to syslogfile. If output of the KFPS01910-I message is suppressed, it is output to the message log file that was being used before swapping. If you are monitoring the message log file, you must swap the monitoring-target message log file whenever the KFPS01910-I message is output.

(b) Message log file size

When message output suppression is in effect, you must allocate a sufficient size for the message log file. You use the pd_mlg_file_size operand to specify a message log file size (the default is 1024 KB).

When message output suppression is in effect, a large volume of messages may be output to the message log file depending on the operating environment. Therefore, if the message log file size is insufficient, message log files are overwritten frequently, and there is a possibility that important messages, such as system operating status and troubleshooting information, that are output only to message log files may be erased.

(6) Relationship to other facilities (applicable only to a HiRDB/Parallel Server)

Table 8-4 shows the processing by HiRDB when message output suppression is used in combination with message log output dispersion.

Table 8-4 Processing by HiRDB when message output suppression is used in combination with message log output dispersion

Condition
Message output destination

When message output suppression is not used
When message output suppression is used

Message log output dispersion
Not used

Message log file of the server machine where the system manager is defined

syslogfile of the server machine where the system manager is defined

Message log file of the server machine where the system manager is defined

Used

Message log file of each server machine

syslogfile of each server machine

Message log file of each server machine

8.2 When a UAP or utility execution takes too long

Executor: HiRDB administrator

When the processing time of a UAP or utility takes longer than expected, an operation command should be used to check the execution status of the UAP or utility. Figure 8-4 shows the procedure for checking UAP or utility execution status.

It must be noted that the execution status of the following utilities cannot be checked using the procedure shown in Figure 8-4:

Database initialization utility

Database copy utility

Database recovery utility

Statistics analysis utility

For these utilities, the pdls -d prc command can be used to check only whether or not processing by the utility is underway.

Figure 8-4 Procedure for checking the UAP or utility execution status

Figure 8-5 Procedure for determining the user who is causing a WAIT status

8.3 When HiRDB startup or termination processing takes too long

Executor: HiRDB administrator

If HiRDB startup or termination processing takes too long, the pdls -d svr command can be used to check the execution status of the HiRDB startup or termination processing. For details about interpreting the execution results of this command, see the manual HiRDB Version 8 Command Reference.

8.4 Obtaining RDAREA status

Executor: HiRDB administrator

Before a UAP or utility is executed, the HiRDB administrator should determine whether or not the RDAREAs to be processed are available for UAP or utility execution. The pddbls command is used to check RDAREA status.

Notes

If many RDAREAs have been defined, specifying the ALL option in the pddbls command will result in a long command processing time. In this case, either the RDAREA names or the server name should be specified.

The -b option is specified to display only RDAREAs in shutdown status.

8.5 Obtaining shared memory utilization status

Executor: HiRDB administrator

Organization of this section

(1) Checking the shared memory utilization status

(2) Determining whether or not shared memory space can be saved

(1) Checking the shared memory utilization status

The utilization status of shared memory can be obtained by the pdls -d mem command.

(2) Determining whether or not shared memory space can be saved

If a process will not execute because of a shortage of shared memory space, the utilization status of the shared memory should be checked. If the problem is with the OS, check if it is possible to use an OS function to resolve the problem.

For example, if the problem is with an OS parameter, correct the parameter. For details on the values to be specified in the OS parameters, see the manual HiRDB Version 8 Installation and Design Guide.

If the problem cannot be solved with an OS function, determine if it is possible to save shared memory space used by HiRDB; the procedure for making this determination is shown in Figure 8-6.

Figure 8-6 Procedure for determining whether or not shared memory space can be saved

¹ This is in the execution results from the pdls -d mem command.

2 For details of global buffer design, see the manual HiRDB Version 8 Installation and Design Guide.

3 For specification guidelines for these operands, see the manual HiRDB Version 8 System Definition.

⁴ The system reconfiguration command (pdchgconf command) can be used to change HiRDB system definitions while HiRDB is running. Note that HiRDB Advanced High Availability is required in order to use this command. For details about changing HiRDB system definitions while HiRDB is running, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

8.6 In the event of deadlock

Executor: HiRDB administrator

This section describes the information that is output in the event of a deadlock or timeout. The following topics are covered:

Basics

Deadlock information that is output

Timeout information that is output

Resource types and resource information

Interpreting resource information

Organization of this section

8.6.1 Basics

8.6.2 Deadlock information that is output

8.6.3 Timeout information that is output

8.6.4 Resource types and resource information

8.6.5 Interpreting resource information

8.6.1 Basics

When a deadlock or timeout occurs, HiRDB outputs the information shown in Table 8-5.

Table 8-5 Information output when a deadlock or timeout occurs

Output information
Description

Deadlock information

This is information that is output about a deadlock that has occurred between transactions within a server.

For a HiRDB/Parallel Server, a deadlock between servers is reported as timeout information.

For more information on deadlock, see the manual HiRDB Version 8 UAP Development Guide.

Timeout information
This is information that indicates that the lock-release wait time has elapsed.

Organization of this subsection

(1) Output destination of deadlock and timeout information

(2) Actions to be taken by the HiRDB administrator

(3) Referencing deadlock and timeout information

(4) Using deadlock and timeout information

(5) Deleting unneeded deadlock/timeout information files

(1) Output destination of deadlock and timeout information

Deadlock information and timeout information are output to the following files, which are called the deadlock/timeout information files:

$PDDIR/spool/pdlckinf/file-name

The file-name is determined by HiRDB as follows on the basis of the date and time the deadlock or timeout occurred:

(2) Actions to be taken by the HiRDB administrator

To output deadlock/timeout information, the following specifications must be made in the system common definition:

Specify in the pd_lck_deadlock_info operand that deadlock information and timeout information are to be output.

Specify a lock-release wait time value in the pd_lck_wait_timeout operand.

(3) Referencing deadlock and timeout information

When the following messages are output, the deadlock or timeout information should be referenced:

KFPA11911-E (Message indicating that deadlock has occurred)

KFPS00441-I (Message indicating that deadlock information has been output)

KFPS00451-I (Message indicating that timeout information has been output)

Deadlock or timeout information can be referenced with an OS command (cat command, vi command, etc.). The KFPS00441-I and KFPS00451-I messages display the file name to be specified in these commands. For details on the cat and vi commands, see the OS manual.

For details on the deadlock and timeout information that is output, see 8.6.2 Deadlock information that is output and 8.6.3 Timeout information that is output.

(4) Using deadlock and timeout information

It may be possible to reduce the frequency of deadlock and timeout occurrences by changing the UAP access sequence or widening the UAP lock range. It is important to use the deadlock and timeout information that is output to reevaluate the resources that cause the deadlock or timeout. For details on the actions to be taken with respect to the resources that result in deadlock or timeout, see the manual HiRDB Version 8 UAP Development Guide.

(5) Deleting unneeded deadlock/timeout information files

HiRDB does not delete deadlock/timeout information files. Such files must be deleted by the HiRDB administrator when the files are no longer needed. The following deletion procedures are provided:

(a) With a HiRDB command

The pdcspool command can be used to delete unneeded deadlock/timeout information files. However, the pdcspool command deletes all troubleshooting information files under $PDDIR/spool. To delete only deadlock/timeout information files, use the method described below in (c) With an OS command.

(b) With a HiRDB function

If all is specified in the pd_spool_cleanup_interval_level operand, HiRDB deletes deadlock/timeout information files periodically. The default is that HiRDB deletes them every 24 hours, but you can change this deletion interval with the pd_spool_cleanup_interval operand.

If all is also specified in the pd_spool_cleanup_level operand, HiRDB also deletes deadlock/timeout information files when it starts.

(c) With an OS command

Use an OS function (OS's rm command, etc.) to delete a deadlock/timeout information file. For details on the rm commands, see the OS manual.

8.6.2 Deadlock information that is output

Figure 8-7 shows the deadlock information that is output.

Figure 8-7 Deadlock information that is output

The following explains the deadlock information that is output:

deadlock-detection-date-and-time
Displays the date and time (mmm dd hh:mm:ss yyyy) when HiRDB detected the deadlock.

Information on the server that sent the transaction that resulted in deadlock

Items 2 to 14 provide information about the first resource that was occupied by the transaction that resulted in the deadlock.

UAP-identification-information
Displays the identification name of the UAP connected to the server that sent the transaction that resulted in the deadlock.
The information displayed here corresponds to the PROGRAM information displayed by the pdls -d prc or pdls -d trn command. Some utilities cannot display this information; in this case, ******** is displayed. Rerun is displayed for a transaction that is being restored during restart processing.

server-name
Displays the name of the server that sent the transaction that resulted in the deadlock.

process-ID
Displays the ID of the server process that sent the transaction that resulted in the deadlock.

transaction-identifier
Displays the identifier of the transaction that resulted in the deadlock.
If the identifier begins with _cmd, the lock was secured by the pdhold command. If the identifier begins with _utl, the lock was secured by the pdcopy command.

Information about all resources occupied by the transaction that resulted in deadlock

Items 6 to 9 provide information about all resources occupied by the transaction that caused the deadlock. If this transaction did not occupy any resources, these items are left blank.

server-name
Displays the name of the server used by the transaction that resulted in the deadlock to issue the resource occupancy request.

lock-mode
Displays the lock mode applied to the resource that was occupied by the transaction that resulted in the deadlock. For details on the lock modes, see the manual HiRDB Version 8 UAP Development Guide.

occupied-resource-type
Displays the type of resource that was occupied by the transaction that resulted in the deadlock. For details on the resource types, see 8.6.4 Resource types and resource information.

occupied-resource-information
Displays information about the resource that was occupied by the transaction that resulted in the deadlock. For details on the resource information, see 8.6.4 Resource types and resource information.

Information about the resource that caused the transaction that resulted in the deadlock to be placed in lock-release wait status

Items 10 to 14 provide information about the resource that caused the deadlock.

server-name
Displays the name of the server used by the transaction that resulted in the deadlock to issue the resource occupancy request.

lock-mode
Displays the lock mode the transaction that resulted in the deadlock attempted to apply to the resource in lock-release wait status. For details on the lock modes, see the manual HiRDB Version 8 UAP Development Guide.

locked-resource-type
Displays the type of resource that caused the transaction that resulted in the deadlock to be placed in lock-release wait status. For details on the resource types, see 8.6.4 Resource types and resource information.

locked-resource-information
Displays information about the resource that caused the transaction that resulted in the deadlock to be placed in lock-release wait status. For details on the resource types, see 8.6.4 Resource types and resource information.

lock-occurrence-time
Displays the time (hh:mm:ss) the transaction that resulted in the deadlock was placed in lock-release wait status.

Information about the server that sent the transaction involved in deadlock

Items 15 to 29 provide information about the first resource that was occupied by the transaction involved in the deadlock. This information may be output more than once.

UAP-identification-information
Displays the identification name of the UAP connected to the server that sent the transaction involved in the deadlock.
The information displayed here corresponds to the PROGRAM information displayed by the pdls -d prc or pdls -d trn command. Some utilities cannot display this information; in this case, ******** is displayed. Rerun is displayed for a transaction that is being restored during restart processing.

server-name
Displays the name of the server that sent the transaction involved in the deadlock.

process-ID
Displays the ID of the server process that sent the transaction involved in the deadlock.

transaction-identifier
Displays the identifier of the transaction involved in the deadlock.

Information about all resources occupied by the transaction involved in deadlock

Items 19 to 22 provide information about all resources that caused the deadlock. If this transaction did not occupy any resources, these items are left blank.

server-name
Displays the name of the server used by the transaction involved in the deadlock to issue the resource occupancy request.

lock-mode
Displays the lock mode applied to the resource that was occupied by the transaction involved in the deadlock. For details on the lock modes, see the manual HiRDB Version 8 UAP Development Guide.

occupied-resource-type
Displays the type of resource that was occupied by the transaction involved in the deadlock. For details on the resource types, see 8.6.4 Resource types and resource information.

occupied-resource-information
Displays information about the resource that was occupied by the transaction involved in the deadlock. For details on the resource information, see 8.6.4 Resource types and resource information.

Information about the resource that caused the transaction involved in the deadlock to be placed in lock-release wait status

Items 23 to 29 provide information about the resource that caused the deadlock.

server-name
Displays the name of the server used by the transaction involved in the deadlock to issue the resource occupancy request.

lock-mode
Displays the lock mode the transaction involved in the deadlock attempted to apply to the resource in lock-release wait status. For details on the lock modes, see the manual HiRDB Version 8 UAP Development Guide.

locked-resource-type
Displays the type of resource that caused the transaction involved in the deadlock to be placed in lock-release wait status. For details on the resource types, see 8.6.4 Resource types and resource information.

locked-resource-information
Displays information about the resource that caused the transaction involved in the deadlock to be placed in lock-release wait status. For details on the resource types, see 8.6.4 Resource types and resource information.

lock-occurrence-time
Displays the time (hh:mm:ss) the transaction involved in the deadlock was placed in lock-release wait status.

user-identifier
Displays the serial number assigned dynamically by HiRDB to identify the individual user.

deadlock-priority-value
Displays the deadlock priority value for the transaction that resulted in the deadlock.

Figure 8-8 shows an output example of deadlock information.

Figure 8-8 Output example of deadlock information

8.6.3 Timeout information that is output

Figure 8-9 shows the timeout information that is output.

Figure 8-9 Timeout information that is output

The following explains the timeout information that is output:

timeout-detection-date-and-time
Displays the date and time (mmm dd hh:mm:ss yyyy) when HiRDB detected the timeout.

Information on the server that sent the transaction that resulted in the timeout

Items 2 to 13 provide information about the first resource that was occupied by the transaction that resulted in the timeout.

UAP-identification-information
Displays the identification name of the UAP connected to the server that sent the transaction that resulted in the timeout. If the transaction was sent by a utility, the name of the utility is displayed.
The information displayed here corresponds to the PROGRAM information displayed by the pdls -d prc or pdls -d trn command. Some utilities cannot display this information; in this case, ******** is displayed. Rerun is displayed for a transaction that is being restored during restart processing.

server-name
Displays the name of the server that sent the transaction that resulted in the timeout.

process-ID
Displays the ID of the server process that sent the transaction that resulted in the timeout.

transaction-identifier
Displays the identifier of the transaction that resulted in the timeout.
If the identifier begins with _cmd, the lock was secured by the pdhold command. If the identifier begins with _utl, the lock was secured by the pdcopy command.

Information about all resources occupied by the transaction that resulted in the timeout

Items 6 to 9 provide information about all resources occupied by the transaction that caused the timeout. If this transaction did not occupy any resources, these items are left blank.

server-name
Displays the name of the server used by the transaction that resulted in the timeout to issue the resource occupancy request.

lock-mode
Displays the type of lock mode applied to the resource that was occupied by the transaction that resulted in the timeout. For details on the lock modes, see the manual HiRDB Version 8 UAP Development Guide.

occupied-resource-type
Displays the type of resource that was occupied by the transaction that resulted in the timeout. For details on the resource types, see 8.6.4 Resource types and resource information.

occupied-resource-information
Displays information about the resource that was occupied by the transaction that resulted in the timeout. For details on the resource information, see 8.6.4 Resource types and resource information.

Information about the resource that caused the transaction that resulted in the timeout to be placed in lock-release wait status

Items 10 to 13 provides information about the resource that caused the transaction that resulted in the timeout to be placed in lock-release wait status.

server-name
Displays the name of the server used by the transaction resulting in the timeout to issue the resource occupancy request.

lock-mode
Displays the lock mode the transaction that resulted in the timeout attempted to apply to the resource in lock-release wait status. For details on the lock modes, see the manual HiRDB Version 8 UAP Development Guide.

locked-resource-type
Displays the type of resource that caused the transaction that resulted in the timeout to be placed in lock-release wait status. For details on the resource types, see 8.6.4 Resource types and resource information.

locked-resource-information
Displays information about the resource that caused the transaction that resulted in the timeout to be placed in lock-release wait status. For details on the resource types, see 8.6.4 Resource types and resource information.

Information about the server that sent the transaction that caused the timeout

Items 14 to 27 provide information about the first resource that was occupied by the transaction that caused the timeout. This information may be output more than once.

UAP-identification-information
Displays the identification name of the UAP connected to the server that sent the transaction that caused the timeout. If the transaction was sent by a utility, the name of the utility is displayed.
The information displayed here corresponds to the PROGRAM information displayed by the pdls -d prc or pdls -d trn command. Some utilities cannot display this information; in this case, ******** is displayed. Rerun is displayed for a transaction that is being restored during restart processing.

server-name
Displays the name of the server that sent the transaction that caused the timeout.

process-ID
Displays the ID of the server process that sent the transaction that caused the timeout.

transaction-identifier
Displays the identifier of the transaction that caused the timeout.

Information about all resources occupied by the transaction that caused the timeout

Items 18 to 21 provide information about all resources that caused the timeout. If this transaction did not occupy any resources, these items are left blank.

server-name
Displays the name of the server used by the transaction that caused the timeout to issue the resource occupancy request.

lock-mode
Displays the lock mode applied to the resource that was occupied by the transaction that caused the timeout. For details on the lock modes, see the manual HiRDB Version 8 UAP Development Guide.

occupied-resource-type
Displays the type of resource that was occupied by the transaction that caused the timeout. For details on the resource types, see 8.6.4 Resource types and resource information.

occupied-resource-information
Displays information about the resource that was occupied by the transaction that caused the timeout. For details on the resource information, see 8.6.4 Resource types and resource information.

Information about the resource that caused the transaction that caused the timeout to be placed in lock-release wait status

Items 22 to 27 provide information about the resource that caused the timeout. Item wait and the subsequent items may not be displayed.

server-name
Displays the name of the server used by the transaction that caused the timeout to issue the resource occupancy request.

lock-mode
Displays the lock mode the transaction that caused the timeout attempted to apply to the resource in lock-release wait status. For details on the lock modes, see the manual HiRDB Version 8 UAP Development Guide.

locked-resource-type
Displays the type of resource that caused the transaction that caused the timeout to be placed in lock-release wait status. For details on the resource types, see 8.6.4 Resource types and resource information.

locked-resource-information
Displays information about the resource that caused the transaction that caused the timeout to be placed in lock-release wait status. For details on the resource types, see 8.6.4 Resource types and resource information.

user-identifier
Displays the serial number assigned dynamically by HiRDB to identify the individual user.

deadlock-priority-value
Displays the deadlock priority value for the transaction that resulted in the deadlock.

Figure 8-10 shows an output example of timeout information.

Figure 8-10 Output example of timeout information

8.6.4 Resource types and resource information

Table 8-6 shows the resource types and resource information included in the deadlock or timeout information.

Table 8-6 Resource types and resource information

Resource type
Type name
Resource name 1
Resource name 2
Resource information
Contents

0001
RDAR
RDAREA

Digits 1-8: RDAREA number
Digits 9-28: Fixed to 00
RDAREA

0002
TABL
Table name

Digits 1-8: Table number
Digits 9-16: Generation number
Digits 17-28: Fixed to 00
Table

0003
INDX
Index name
RDAREA name
Digits 1-8: Index number
Digits 9-16: RDAREA number
Digits 17-28: Fixed to 00
Index

0004
PAGE
Table name or index name
RDAREA name
For HP-UX, Solaris, and AIX 5L versions
Digits 1-6: RDAREA number
Digits 7-8: File number
Digits 9-16: Page number
Digits 17-24: Table number or index number
Digits 25-28: Fixed to 00
For Linux version
Digits 1-2: File number
Digits 3-8: RDAREA number
Digits 9-16: Page number
Digits 17-24: Table number or index number
Digits 25-28: Fixed to 00
Page

0007
ROW
Table name
RDAREA name
For HP-UX, Solaris, and AIX 5L versions
Digits 1-6: RDAREA number
Digits 7-8: File number
Digits 9-14: Page number
Digits 15-16: Slot number
Digits 17-24: Table number
Digits 25-28: Fixed to 00
For Linux version
Digits 1-2: File number
Digits 3-8: RDAREA number
Digits 9-10: Slot number
Digits 11-16: Page number
Digits 17-24: Table number
Digits 25-28: Fixed to 00
Row

0008
NWROW
Table name
RDAREA name
For HP-UX, Solaris, and AIX 5L versions
Digits 1-6: RDAREA number
Digits 7-8: File number
Digits 9-14: Page number
Digits 15-16: Slot number
Digits 17-24: Table number
Digits 25-28: Fixed to 00
For Linux version
Digits 1-2: File number
Digits 3-8: RDAREA number
Digits 9-10: Slot number
Digits 11-16: Page number
Digits 17-24: Table number
Digits 25-28: Fixed to 00
Row (for controlling WITHOUT LOCK NOWAIT retrieval)

000B
TABN
Table name

Digits 1-8: Table number
Digits 9-16: Generation number
Digits 17-28: Fixed to 00
Table (during NO WAIT retrieval)

000C
NKEY
Index name

Digits 1-8: Index number
Digits 9-28: Fixed to 00
Key value (NULL)

000D
DKEY
Index name

Digits 1-8: Index number
Digits 9-28: Key value or encoded key value
Key value (non-NULL)

000E
LFID
RDAREA name
Logical file number
Digits 1-8: RDAREA number
Digits 9-16: Logical file number
Digits 17-28: Fixed to 00
Logical file

000F
IXIF
Index name
RDAREA name
Digits 1-8: Index number
Digits 9-16: RDAREA number
Digits 17-28: Fixed to 00
Index information file

0010
TRWT
Table name
Name of the RDAREA storing the index
Digits 1-8: Table number
Digits 9-16: Number of the RDAREA storing the index
Digits 17-28: Fixed to 00
Transaction completion pending

0011
SHWT
Table name
(**** is output if the system is waiting for RDAREA update completion)
RDAREA name
For HP-UX, Solaris, and AIX 5L versions
Digits 1-6: RDAREA number
Digits 7-8: File number
Digits 9-14: Page number
Digits 15-16: Slot number
Digits 17-24: Table number
Digits 25-28: Fixed to 00
For Linux version
Digits 1-2: File number
Digits 3-8: RDAREA number
Digits 9-10: Slot number
Digits 11-16: Page number
Digits 17-24: Table number
Digits 25-28: Fixed to 00
If the system is waiting for RDAREA update completion, all digits except for the RDAREA number are 0.
Shared RDAREA transaction completion pending

0102
RRAMB
RDAREA name

Digits 1-8: RDAREA number
Digits 9-28: Fixed to 00
RDAREA management information

0111
MFCB

Digits 1-8: Page number
Digits 9-12: File number
Digits 13-28: Fixed to 00
Master directory segment information

0112
MTCB
Table name

Digits 1-8: Table number
Digits 9-28: Fixed to 00
Master directory table information

0113
MICB
Index name

Digits 1-8: Index number
Digits 9-28: Fixed to 00
Master directory index information

0121
RATM
Table name
RDAREA name
Digits 1-8: RDAREA number
Digits 9-16: Table number or table management number
Digits 17-28: Fixed to 00
Dictionary table information or user directory table information

0122
RAIM
RDAREA name

Digits 1-8: RDAREA number
Digits 9-16: Index number or index management number
Digits 17-28: Fixed to 00
Dictionary index information or user directory index information

0132
SBMB
RDAREA name

Digits 1-8: RDAREA number
Digits 9-16: Segment number
Digits 17-20: File number
Digits 21-28: Fixed to 00
Dictionary segment information or user directory segment information

0143
RDLF
RDAREA name
Last file number
Digits 1-8: RDAREA number
Digits 9-12: Last file number
Digits 13-28: Fixed to 00
RDAREA increment

0152
SGMB
RDAREA name

Digits 1-8: RDAREA number
Digits 9-16: Page number
Digits 17-20: File number
Digits 21-28: Fixed to 00
Database copy utility

0300
MENT
RDAREA name

Digits 1-8: RDAREA number
Digits 9-16: Page number
Digits 17-20: File number
Digits 21-24: Entry number
Digits 25-28: Fixed to 00
User LOB RDAREA management information

0301
LOBID
RDAREA name

Digits 1-8: RDAREA number
Digits 9-16: LOB number
Digits 17-28: Fixed to 00
User LOB RDAREA management information

0601
RDAS
RDAREA name

Digits 1-8: RDAREA number
Digits 9-28: Fixed to 00
Database condition analysis utility

0602
HOLD
RDAREA name

Digits 1-8: RDAREA number
Digits 9-28: Fixed to 00
Backup-hold RDAREA

0603
INRP
Server name

Bytes 1-8 indicate the server name. If the server name does not occupy 8 bytes, the unused bytes are filled with NULLs.
Inner replica configuration management information

0604
RPGP
Original RDAREA name

Digits 1-8: RDAREA number
Digits 9-28: Fixed to 00
Replica group configuration management information

0900
PLGR

Digits 1-8: Plug-in ID
Digits 9-28: Plug-in's unique resource number
Plug-in resource number

2002
ROMB

Digits 1-14: SQL object number
Digits 15-28: Fixed to 00
SQL object management information

2003
SPCH

Fixed to 'SPCH'
Extra digits are zero-filled.
SQL object cache

3001
PTBL
"****"
"****"
Digits 1-8: Table number
Digits 9-28: Fixed to 00
Pre-processing table

3001
AUDL
"****"
"****"
Fixed to AUDL
Audit trail information pool

3005
DICT
"****"
"****"
Fixed to 'DICT'
Extra digits are zero-filled.
Dictionary table

3006
VIEW
"****"
"****"
Digits 1-8: View table number
Digits 9-28: Fixed to 00
View table

3008
TBPL
"****"
"****"
Bytes 1-5¹ are an authorization identifier.
Bytes 6-14² are a table identifier.
Table definition information buffer

3009
ALAS
"****"
"****"
Bytes 1-5¹ are an authorization identifier.
Bytes 6-14² are a table alias.
Table alias definition information buffer

3010
AUTH
"****"
"****"
Bytes 1-14 bytes are an authorization identifier.
User privilege information buffer

3011
OBJI
"****"
"****"
Routine object number
Routine object

3012
DTYP
"****"
"****"
Fixed to 'DTYP'
Extra digits are zero-filled.
Data type definition information

3013
RTPL
"****"
"****"
Bytes 1-12 are a routine identifier.
Bytes 13-14 are a parameters count.
Routine definition information buffer

3014
TPPL
"****"
"****"
Bytes1-5¹ are an authorization identifier.
Bytes 6-14² are a data type identifier.
User-defined type information buffer

3015
DICR
"****"
"****"
Fixed to DICR
Dictionary RDAREA modification

3016
CONS
"****"
"****"
Fixed to CONSEC
CONNECT-related security definition information

5001
DICU

Fixed to 'DICTMODUTL'
Extra digits are zero-filled.
Database structure modification utility

5002
LCBF
RDAREA name

Digits 1-8: RDAREA number
Digits 9-28: Fixed to 00

5003
EXP1

Fixed to 'EXPIMPMDL'
Extra digits are zero-filled.
Database import/export utility

5004
RBAL
Table name

Digits 1-8: Table number
Digits 9-28: Fixed to 00
Rebalancing utility

5005
RRAMB
Server name

Digits 1-16: Server name
Digits 17-28: Fixed to 00
ZRRAMB updates

5006
RCLM
RDAREA name
Table name or index name
Digits 1-8: RDAREA number
Digits 9-16: Table number or index number
Digits 17-28: Fixed to 00
Free page release utility

: Not applicable

Notes

The resource type is displayed in hexadecimal (4 digits).

The resource information is displayed in hexadecimal (28 digits). For details on interpreting resource information, see 8.6.5 Interpreting resource information.

The RDAREA name corresponding to an RDAREA number can be referenced with the pddbls command.

The generation number is displayed if the table has been duplicated with the inner replica facility.

¹ Authorization identifiers (6 bytes or longer) are output in the following format:

first-3-bytes-of-authorization-identifier + last-2-bytes-of-authorization-identifier

For example, if the authorization identifier is k87m341, k8741 is output.

Note that the information is in ASCII codes and one byte is output as two digits.

² Table identifiers, table aliases, and data type identifiers (10 bytes or longer) are output in the following format:

first-5-bytes-of-table-identifier-or-table-alias + last-4-bytes-of-table-identifier-or-table-alias

For example, if the table identifier is TABLE002498, TABLE2498 is output.

Note that the information is in ASCII codes, and one byte is output as two digits.

8.6.5 Interpreting resource information

Resource information is displayed in hexadecimal (28 digits). If multiple resource information items are specified, they are displayed consecutively in the order of their specification. If the resource information is fewer than 28 digits, the extra digits are zero-filled. All characters are in ASCII codes, and one byte is output as two digits.

Note

For the HP-UX, Solaris, and AIX 5L versions of HiRDB, resource information is output in big endian format. For the Linux version of HiRDB, resource information is output in little endian format.

Figure 8-11 shows an output example of resource information (when the resource type is 0007).

Figure 8-11 Resource information output example (when the resource type is 0007)

Organization of this subsection

(1) Determining the RDAREA name from an RDAREA number

(2) Determining the index name from an index number

(3) Determining the table name (view table name) from a table number (view table number)

(1) Determining the RDAREA name from an RDAREA number

The following shows how to determine the RDAREA name from the RDAREA number that is output in the resource information:

Procedure

If the output information is in little endian format, convert it to big endian format. Suppose that 03000000 is output as the RDAREA number. Convert it to big endian format as shown below.

The RDAREA number becomes 3.

Because the RDAREA number that is output in the resource information is in hexadecimal, convert it to decimal.

Use the pddbls command to determine the RDAREA name that corresponds to the RDAREA number.

(2) Determining the index name from an index number

The following shows how to determine the index name from the index number that is output in the resource information:

Procedure

If the output information is in little endian format, convert it to the big endian format. Suppose that 0a010300 is output as the index number. Convert it to big endian format as shown below.

The index number becomes 3010a.

Because the index number that is output in the resource information is in hexadecimal, convert it to decimal.

Retrieve the INDEX_ID column of the SQL_INDEXES dictionary table and determine the index name that corresponds to the index number.
For details about how to retrieve the SQL_INDEXES dictionary table, see the manual HiRDB Version 8 UAP Development Guide.

(3) Determining the table name (view table name) from a table number (view table number)

The following shows how to determine the table name (view table name) from the table number (view table number) that is output in the resource information:

Procedure

If the output information is in little endian format, convert it to big endian format. Suppose that 7c000200 is output as the table number. Convert it to big endian format as shown below.

The table number becomes 2007c.

Because the table number (view table number) that is output in the resource information is in hexadecimal, convert it to decimal.

Retrieve the TABLE_ID column of the SQL_TABLES dictionary table and determine the table name (view table name) that corresponds to the table number (view table number).
For details about how to retrieve the SQL_TABLES dictionary table, see the manual HiRDB Version 8 UAP Development Guide.

8.7 In the event of a shortage of locked resources management tables

Executor: HiRDB administrator

When there are too few locked resources management tables, HiRDB outputs the KFPS00443-I message and locked resources management table information. The locked resources management table information is output to a directory at the unit where the shortage occurred ($PDDIR/spool/pdlckinf). The HiRDB administrator must reference this information and take appropriate action to resolve the problem.

Organization of this section

(1) Names of locked resources management table data files

(2) Locked resources management table information

(3) Key items to be checked

(4) Action to be taken

(1) Names of locked resources management table data files

Locked resources management table information is output to a file each time a shortage of locked resources management tables occurs. The name of this output file is output-date-and-time.mem, where mem is a file descriptor. In the event of a shortage of locked resources management tables occurring at 09:16:02 on October 3, the name of the output file would be Oct3091602.mem. This file name is displayed in the KFPS00447-I message.

Deleting unneeded locked resources management table data files

HiRDB does not delete locked resources management table data files. Unneeded files must be deleted by the HiRDB administrator (using the OS's rm command, etc.). For details on the rm command, see the applicable OS manual.

(2) Locked resources management table information

Figure 8-12 shows the locked resources management table information that is output.

Figure 8-12 Locked resources management table information that is output

Explanation

Date and time the shortage of locked resources management tables was detected (mmm dd hh:mm:ss yyyy).

Type of affected locked resources management tables:
RESOURCE
Tables used for managing resource names. These tables are shared among multiple users. Therefore, the sum of the tables used by all users may exceed the actual number of tables.
OCP/WAIT
Tables used for managing shared or wait status. These tables are not shared among multiple users.
The following shows the difference between RESOURCE and OCP/WAIT:

Total number of available locked resources management tables.
Information about the user who was involved in the shortage of locked resources management tables:

UAP identification information¹

Server name

Process ID

Transaction identifier

User identification number

Deadlock priority value

Client's IP address

Client's process ID

Number of tables currently used
Information about another user when the shortage of locked resources management tables occurred (user whose usage factor of locked resources management tables is 10% or higher):

UAP identification information¹

Server name

Process ID

Transaction identifier

User identification number

Deadlock priority value

Client's IP address²

Client's process ID²

Number of tables currently used
Information about other users when the shortage of locked resources management tables occurred (users whose usage factor of locked resources management tables is less than 10%):

Number of users whose usage factor of locked resources management tables is less than 10%

¹ Displays in 30 bytes the name of the client UAP that was connected.

This is the PROGRAM information that is output by the pdls -d prc or the pdls -d trn command. This information is not displayed for some utilities, in which case ******** is displayed. If the transaction is being recovered by restart processing, Rerun is displayed.

² This information is not displayed when the HiRDB version of the client library linked to the connected client UAP is 4.0 04-00 or earlier. This information may not be displayed for a back-end server or dictionary server, in which case ******** is displayed as the client IP address and 0 is displayed as the process ID.

(3) Key items to be checked

Following are the key items that should be checked in the locked resources management table information:

3. Total number of available locked resources management tables

21. Number of tables currently used

The HiRDB administrator can determine from this information the UAPs using the locked resources management tables and their table usage factors. The number of locked resources management tables used is equal to the number of lock requests issued by UAPs. Therefore, a UAP for which the 21. Number of tables currently used value is too high may have issued too many lock requests. The number of lock requests issued by a UAP depends on the SQL; for the number of lock requests for each SQL (the estimated number of locked resources), see the manual HiRDB Version 8 System Definition.

(4) Action to be taken

(a) When there is a UAP issuing too many lock requests

A UAP that is issuing too many lock requests should be modified so that it does not issue so many lock requests.

The PDLOCKLIMIT operand in the client environment definition can also be used to set a maximum number of lock requests that can be issued by any UAP.

(b) When there is no UAP issuing too many lock requests

It may be that too few locked resources management tables are available. The following actions can be taken in this case:

When there is not enough shared memory space available at the unit (shared memory cannot be increased)

Do not execute concurrently many UAPs that use locked resources management tables.

When there is enough shared memory space at the unit (shared memory can be increased)

Modify the HiRDB system definition. The operand to be modified depends on the type of server. The server at which there are too few locked resources management tables can be determined from the 5. Server name information in the locked resources management table information.

When a shortage of locked resources management tables has occurred at the front-end server, the value of the pd_fes_lck_pool_size operand in the front-end server definition should be increased.

When a shortage of locked resources management tables has occurred at a server other than the front-end server, the value of the pd_lck_pool_size operand in the corresponding server definition should be increased.

Note

Before the HiRDB system definition is modified, the entire HiRDB or the entire unit whose definition is to be modified must be terminated normally, then the HiRDB system definition can be modified. If only the applicable server is terminated with the pdstop -s, modifications made to the definition will not be effective.

8.8 Monitoring UAP status (skipped effective synchronization point dump monitoring facility)

When a UAP updates a database continuously because of an infinite loop, many overwrite disabled system log files are created because the synchronization point dumps cannot be validated. Once all the system log files have been placed in overwrite disabled status, HiRDB terminates abnormally.

If HiRDB is terminated abnormally or forcibly while more than half of all system log files are in overwrite disabled status, HiRDB cannot be restarted because there are too few system log files for rollback processing. In this case, new system log files must be added in order to restart HiRDB. This also results in a longer restart processing time.

To avoid such problems, HiRDB provides the skipped effective synchronization point dumps monitoring facility.

Organization of this section

(1) Skipped effective synchronization point dumps monitoring facility

(2) Value to be specified in the pd_spd_syncpoint_skip_limit operand

(3) Calculation methods

(4) When the value of the pd_spd_syncpoint_skip_limit operand is not appropriate

(5) When not to use the skipped effective synchronization point dumps monitoring facility

(6) Transactions that are not rolled back

(7) Notes

(8) If HiRDB Datareplicator is being used

(1) Skipped effective synchronization point dumps monitoring facility

If a UAP experiences an infinite loop, synchronization point dump validation processing may not be executed consecutively (synchronization point dump validation processing may be skipped). When the number of consecutively skipped validations reaches a set value, the offending transaction is stopped forcibly and rollback processing is performed. This capability is provided by the skipped effective synchronization point dumps monitoring facility. To use this facility, specify the pd_spd_syncpoint_skip_limit operand.

(2) Value to be specified in the pd_spd_syncpoint_skip_limit operand

Normally, the pd_spd_syncpoint_skip_limit operand is set to 0. When its value is 0, HiRDB calculates automatically the maximum number of times skipping is permitted. However, if system instability occurs with 0 specified, one of the methods shown in (3) below can be used to calculate an appropriate value for this operand.

When any one of the following conditions is satisfied, the value calculated by either of the methods described in (3) will provide a more precise result than the value HiRDB calculates:

There are five or fewer generations of system log files that can be used as current files.

Transactions that take a long time to process are being executed concurrently.

Data replication transaction processing takes a long time to complete on the HiRDB being updated (when linked with HiRDB Datareplicator).

Also in the following cases you should not use automatic calculation, but should calculate a value using one of the methods described in (3):

The KFPS02101-I message is issued.

HiRDB terminated abnormally with abort code Psspc01.

(3) Calculation methods

The following two calculation methods are provided; use one of them to calculate an appropriate value to use:

Method based on the byte count of the output system logs

Method based on the byte count of all system logs

Specify in the pd_spd_syncpoint_skip_limit operand a value that is slightly smaller than the value obtained by these calculations. The value specified in this operand takes effect following the first synchronization point dump validation performed after the next HiRDB startup (or restart).

(a) Method based on the byte count of the output system logs

Use the following formula to obtain the value:

Formula

{( a b c) d} - 1

a:

Sum (in bytes) of the system log information output by the transaction that updates the largest volume of database data and the system log information output by other transactions that are executing concurrently. For details about how to obtain the byte count of system logs, see the manual HiRDB Version 8 Installation and Design Guide.

When HiRDB Datareplicator is being used

When data replication transaction processing on the HiRDB being updated takes a long time, this monitoring facility may roll back the data replication transaction on the HiRDB being updated. Therefore, you must also add the byte count of system logs output by data replication transaction processing. Add the value obtained by the following formula:

byte-count-of-system-logs-output-by-data-replication-transaction- processing = (byte-count-of-system-logs-output-by-the-transaction-that-updates-the- largest-amount-of-database-data)

represents the log volume output by transactions as specified in the cmtintvl operands (trncmtintvl and tblcmtintvl) of the HiRDB Datareplicator replication environment definitions.

b:

System log file record length. You can obtain the record length with the pdlogls command.

c:

Average number of records in a system log block. Normally, this is roughly 3 4096 b. You can use the following formula to obtain a precise value:

average-length-of-system-log-output-block b

You can obtain the average length of the system log output blocks from the system activity statistical information produced by the statistics analysis utility (OUTPUT BLOCK LENGTH).

d:

Value of the first parameter of the pd_log_sdinterval operand (which specifies the synchronization point dump acquisition interval in terms of the volume of system logs that are output).

(b) Method based on the byte count of all system logs

Use the following formula to obtain the value:

Formula

{(a b c) d} e

a:

Number of system log files that can placed in swappable target status while HiRDB is running.

b:

Number of records in a system log file. If the number of records differs between files, use the average number of records.

c:

Ratio of skipped synchronization point dump validations. Use the ratio of the number of files placed in overwrite disabled status to the total number of system log files.

For a HiRDB/Single Server, use a value of 0.333 or less. If the number of guaranteed-valid generations is 2, use a value of 0.167 or less.

For a back-end server, use a value of 0.333 or less. If the number of guaranteed-valid generations is 2, use a value of 0.167 or less.

For the dictionary server, use a value of approximately 0.5.

For a front-end server, use a value of approximately 0.7.

d:

Normally, this is roughly 3 4096 f. You can use the following formula to obtain a more precise value:

average-length-of-system-log-output-block f

You can obtain the average length of the system log output blocks from the system activity statistical information produced by the statistics analysis utility (OUTPUT BLOCK LENGTH).

e:

Value of the first parameter of the pd_log_sdinterval operand (which specifies the synchronization point dump acquisition interval in terms of the volume of system logs that are output).

f:

System log file record length. You can obtain the record length with the pdlogls command.

(4) When the value of the pd_spd_syncpoint_skip_limit operand is not appropriate

If the specified value is too large, it may not be possible to overwrite any of the system log files. If this happens, HiRDB terminates abnormally and cannot be restarted unless new system log files are added.

If the specified value is too small, there may be an increase in the number of transactions that are rolled back forcibly.

(5) When not to use the skipped effective synchronization point dumps monitoring facility

During batch processing that involves updating of a large amount of data and the amount of system log information that is output before the commit statement is issued is more than one-third of the total size of all system log files.

When the sum of the amount of system log information output by the transaction that updates the largest amount of database data and the amount of system log information output by transactions that execute concurrently is more than one-third of the total size of all system log files.

For details on obtaining the amount of system log information, see the manual HiRDB Version 8 Installation and Design Guide.

(6) Transactions that are not rolled back

Even if the number of consecutively skipped synchronization dump points exceeds the value specified in the pd_spd_syncpoint_skip_limit operand, the following transactions are not rolled back:

Transactions that are already being rolled back.

Transactions waiting for a phase 2 commit completion instruction from OpenTP1.

Transactions generated by a utility.

(7) Notes

If you execute the pdlogswap command several times consecutively while HiRDB is running, the number of system log files that can be used as primary files decreases. This tends to increase the probability that a unit will terminate abnormally, due to there being an insufficient number of system log files.

(8) If HiRDB Datareplicator is being used

If data replication transaction processing on the HiRDB being updated (target HiRDB) takes a long time, the skipped effective synchronization point dumps monitoring facility may roll back the data replication transaction. If this happens, the target HiRDB issues the KFPS00993-I message (REQUEST= abnormal_tran_end), and the instance of the HiRDB Datareplicator on the target HiRDB side issues the KFRB03007-W and KFRB03013-I messages. The following shows how to handle this situation:

Procedure

Use the pdstop command to terminate the target HiRDB normally.*

Change the value of the pd_spd_syncpoint_skip_limit operand. For details about an appropriate value to specify, see (3)(a) Method based on the byte count of the output system logs.

Determine whether the number of system log file generations satisfies the following condition; if it does not, add enough system log files to satisfy this condition:
value-of-ps_spd_syncpoint_skip_limit-operand-after-change number-of-system-log-file-generations 3

Use the pdstart command to start the target HiRDB normally.

Use the hdsrfctl command of the HiRDB Datareplicator on the target HiRDB side to re-execute the data reflection transaction.

* When you use the system reconfiguration command (pdchgconf command), you do not need to restart HiRDB normally, because the pdchgconf command allows you to modify HiRDB system definitions while HiRDB is running. Note that HiRDB Advanced High Availability is required in order to use this command. For details about modifying HiRDB system definitions while HiRDB is running, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

Figure 8-13 shows the operational flow when a data replication transaction is rolled back forcibly by the skipped effective synchronization point dumps monitoring facility.

Figure 8-13 Operational flow when a data replication transaction is forcibly rolled back by the skipped effective synchronization point dumps monitoring facility

8.9 Output of warning information about the time required for SQL execution (SQL runtime warning output facility)

If SQL execution time exceeds either of the limits listed below, warning information about that SQL can be output.

A percentage of the client maximum wait time (value of PDCWAITTIME operand) that has been set

Amount of elapsed time that constitutes trigger for output of a warning to a file

In the following explanations, PDCWAITTIME refers to the client maximum wait time, and a PDCWAITTIME timeout is an exceedance of the client maximum wait time.

Organization of this section

8.9.1 Overview of the SQL runtime warning output facility

8.9.2 Using the SQL runtime warning output facility

8.9.3 Information output to the SQL runtime warning information file

8.9.4 Output of the KFPA20009-W message

8.9.5 Notes

8.9.1 Overview of the SQL runtime warning output facility

After SQL execution, HiRDB determines the SQL execution time. If this amount of time exceeds a preset elapsed time for output of warning information, the following warning information about that SQL is output; this facility is called the SQL runtime warning output facility:

SQL runtime warning information file

Warning message (KFPA20009-W message)

Organization of this subsection

(1) Reasons for using the SQL runtime warning output facility

(2) Setting the elapsed time basis for output of warning information

(3) SQL statements monitored by the SQL runtime warning output facility

(4) Actions when warning information is output

(5) Conditions under which warning information is output

(6) Relationship between PDCWAITTIME and the SQL runtime warning output facility

(1) Reasons for using the SQL runtime warning output facility

The SQL runtime warning output facility can be used for the following purposes:

To detect in advance the possibility of a PDCWAITTIME timeout occurring for a UAP whose response time to HiRDB server processes has increased, due to an increase in the volume of data

To collect for use as tuning data information on SQL code whose response wait time meets or exceeds a specific value

(2) Setting the elapsed time basis for output of warning information

The amount of time on the basis of which warning information is to be output is called the elapsed time basis for output of warning information. When SQL execution time exceeds the elapsed time basis for output of warning information, warning information is output. The elapsed time basis for output of warning information is determined as either of the following:

A percentage of the value specified in the PDCWAITTIME operand

An elapsed time trigger for output of a warning to a file; you can specify a very precise output trigger time value (in milliseconds, for example).

(3) SQL statements monitored by the SQL runtime warning output facility

The SQL runtime warning output facility monitors all SQL statements except for CONNECT statements.

(4) Actions when warning information is output

When information warning that a PDCWAITTIME timeout may occur is output, you should take the following actions based on the output information:

Determine if lockout has occurred.

Determine if a network failure has occurred.

Tune the SQL code.

Increase the value specified in the PDCWAITTIME operand.

Check if the execution time of the SQL code has increased because of an increase in the number of data transactions.

(5) Conditions under which warning information is output

When the SQL runtime warning output facility is being used, warning information may be output, even when the execution time of SQL code is less than the set time. Warning information (message only) may also be output, even when the SQL runtime warning output facility is not being used. Table 8-7 describes the conditions under which warning information is output by the SQL runtime warning output facility.

Table 8-7 Conditions under which warning information is output by the SQL runtime warning output facility

Condition | Warning information that is output
SQL runtime warning information file | KFPA20009-W message
When the SQL runtime warning output facility is being used | The SQL execution time meets or exceeds the set time. | Yes | Yes
Server process is terminated forcibly due to a PDCWAITTIME timeout. | Part | Part
Server process is terminated forcibly for some other reason. | Part | Part
When the SQL runtime warning output facility is not being used | The SQL execution time meets or exceeds the set time. | No | No
Server process is terminated forcibly due to a PDCWAITTIME timeout. | No | Part
Server process is terminated forcibly for some other reason. | No | Part

Legend:

Yes: The indicated information is output.

Part: The indicated information is partially output.

In addition, the SQL runtime warning information file or the KFPA20009-W message may not be output depending on the timing of the forced termination.

Note, also, that you can suppress re-output of the SQL runtime information file and the KFPA20009-W message with the pd_dump_suppress_watch_time operand.

No: The indicated information is not output.

Note

When SQL execution time exceeds the value in the PDCWAITTIME operand, the server process is terminated forcibly regardless of whether the SQL runtime warning output facility is being used.

(6) Relationship between PDCWAITTIME and the SQL runtime warning output facility

Figures 8-14 and 8-15 illustrate the relationship between PDCWAITTIME and the SQL runtime warning output facility.

Figure 8-14 Relationship between PDCWAITTIME and the SQL runtime warning output facility (1 of 2)

Figure 8-15 Relationship between PDCWAITTIME and the SQL runtime warning output facility (2 of 2)

Explanation

The range of measuring SQL execution time is from the time a request sent from a client is received by the server until the execution result in response to the request is returned.

When the SQL execution result is returned to the client, HiRDB determines the SQL execution time. If the SQL execution time equals or exceeds the set time, the warning information is output.

8.9.2 Using the SQL runtime warning output facility

To use the SQL runtime warning output facility, you must specify the following:

PDCWAITTIME operand

Percentage of the value specified in the PDCWAITTIME operand or the amount of elapsed time that constitutes the trigger for output of warning information to a file

Output directory for the SQL runtime warning information files

Maximum size of an SQL runtime warning information file

Organization of this subsection

(1) Specifying the PDCWAITTIME operand

(2) Specifying a percentage of the value specified in the PDCWAITTIME operand or an amount of elapsed time that is to constitute a trigger for output of a warning to a file

(3) Specifying the output directory for the SQL runtime warning information files

(4) Specifying the maximum size of an SQL runtime warning information file

(1) Specifying the PDCWAITTIME operand

Specify the client maximum wait time in the PDCWAITTIME operand of the client environment definitions. If you specify 0 (or nothing) in the PDCWAITTIME operand, the SQL runtime warning output facility is not applied to SQL statements executed from that HiRDB client.

For details about the PDCWAITTIME operand, see the manual HiRDB Version 8 UAP Development Guide.

(2) Specifying a percentage of the value specified in the PDCWAITTIME operand or an amount of elapsed time that is to constitute a trigger for output of a warning to a file

Use the following operands to specify the conditions under which warning information is to be output:

PDCWAITTIMEWRNPNT operand (client environment definition)

pd_cwaittime_wrn_pnt operand (HiRDB system definition)

(a) Specifying a percentage of the value specified in the PDCWAITTIME operand

Specify in the PDCWAITTIMEWRNPNT and pd_cwaittime_wrn_pnt operands a percentage (between 0 and less than 100) of the value specified in the PDCWAITTIME operand. For example, if you specify 90 (%) in the PDCWAITTIMEWRNPNT and pd_cwaittime_wrn_pnt operands when 100 (seconds) is specified in the PDCWAITTIME operand, HiRDB monitors the SQL execution time once the SQL begins executing. If the SQL execution time is determined to be 90 or more seconds, warning information is output.

You can specify an unsigned integer or an unsigned decimal number (a number that includes a decimal point and up to six decimal places).

(b) Specifying an amount of elapsed time that is to constitute a trigger for output of warning information to a file

Specify in the above operands a value between 0 and less than the value specified in the PDCWAITTIME operand as the amount of elapsed time that is to constitute the trigger for output of SQL runtime warning information.

If the value specified in the PDCWAITTIMEWRNPNT operand is greater than the value specified in the PDCWAITTIME operand, an error occurs during a connection request.

Note

The PDCWAITTIMEWRNPNT operand specification takes precedence over specification of the pd_cwaittime_wrn_pnt operand.

If 0 is specified in the PDCWAITTIMEWRNPNT operand, the SQL runtime warning output facility does not monitor SQL statements executed from that HiRDB client.

Reference note

HiRDB determines the amount of elapsed time for output of warning information from the following formulas based on the values in the above operands:

When an unsigned integer is used to specify a percentage of the PDCWAITTIME operand:
elapsed-time-basis-for-output-of-warning-information = MAX( (a b) 100 , 1)
a: Value of the PDCWAITTIME operand
b: Value of the PDCWAITTIMEWRNPNT or pd_cwaittime_wrn_pnt operand (whichever was applied, in accordance with the precedence level of these operands)

When an unsigned decimal number is used to specify a percentage of the PDCWAITTIME operand:
elapsed-time-basis-for-output-of-warning-information = (a b) 100
a: Value of the PDCWAITTIME operand
b: Value of the PDCWAITTIMEWRNPNT or pd_cwaittime_wrn_pnt operand (whichever was applied, in accordance with the precedence level of these operands)
Note that up to six decimal places are valid for the elapsed time basis for output of warning information. The seventh and subsequent decimal places are truncated.

When an amount of elapsed time that is to constitute a trigger for output of warning information to a file is specified:
elapsed-time-basis-for-output-of-warning-information = absolute-value-of-time-that-constitutes-trigger-for-output-of-warning-information-to-file
The accuracy of the timer used by HiRDB in a server depends on the platform. Therefore, if the timer's accuracy is low, warning information may not be output in some cases, even though the actual SQL execution time exceeded the elapsed time basis for output of warning information.

(3) Specifying the output directory for the SQL runtime warning information files

Specify the output directory for the SQL runtime warning information files in the pd_cwaittime_report_dir operand. Two files are created in this directory, pdcwwrn1 and pdcwwrn2.

Do not specify this operand if you do not wish to have SQL runtime warning information files output. If omitted, only the KFPA20009-W message will be issued.

Note that if the OS detects an error, such as a file system error or that the user does not have write privileges for the directory or file, no warning will be output to the SQL runtime warning information file. In such a case, execution processing of the SQL code will continue.

(4) Specifying the maximum size of an SQL runtime warning information file

Specify the pd_cwaittime_report_size operand to change the maximum size for SQL runtime warning information files. The value specified in this operand is the size of one SQL runtime warning information file. When you specify this value, take into account that two SQL runtime warning information files are created. For example, if you specify 10,000, then two files, each with a maximum size of 10,000 bytes, will be created in the directory.

Remarks

When the amount of data output to the first file exceeds the value set in this operand, output will switch to the other file. If the amount of data output to the second file exceeds this value, output will switch back to the first file. Output will continue to switch between the two files in this manner. Each time output is switched to a file that has already been used, the existing information in it is overwritten.

If the amount of SQL runtime warning information that is output in a single output session exceeds the maximum file size, some of the information will be lost. Such SQL runtime warning information is output only to the point at which the file becomes full. When this happens, a hash mark (#) is output at the end of the SQL runtime warning information.

8.9.3 Information output to the SQL runtime warning information file

Organization of this subsection

(1) Viewing the SQL runtime warning information file

(2) Output format of SQL runtime warning information

(1) Viewing the SQL runtime warning information file

You can view SQL runtime warning information with any text editor or software capable of opening a text file.

Note that, in a HiRDB/Parallel Server environment, the warning information is output to the server machine running the front-end server to which the UAP that issued the offending SQL is connected.

Remarks

To determine which SQL runtime warning information file is the current file, use an OS command (ls command, for instance) to check the update dates and times of the files. The file with the most recent update date and time is the one that is being used currently.

The output target file after HiRDB starts is the one with the most recent update date and time.

SQL runtime warning information is written to the file starting at the previous ending position, which means that warning information is displayed in the file chronologically.

Because the current SQL runtime warning information file is closed when an SQL statement has executed, you can use OS commands to back up or view the file while SQL code is not executing, without worrying about interfering with the file while it is being written to. Even when SQL code is being executed, you can manipulate the other file (the one not being used) without having to worry about destroying the file that is being written to.

(2) Output format of SQL runtime warning information

The following shows the output format of the SQL runtime warning information (when an unsigned integer is used to specify a percentage of the PDCWAITTIME operand):

** SQL CWAITTIME WARNING INFORMATION 07-01    2002/07/04 14:32:22 **
 REASON(01)
 CWAITIME(600) CWAITTIME_WRN_PNT(70) CWAITTIME_WRN_TIME(420)

* UAP INFORMATION *
 UAP_NAME(userprog1) CLTPID(408)
 IP_ADDR(196.12.42.146) SERVICE_NAME(service1)
 USERID(hiuser01) START_TIME(2002/07/03 20:24:42)

* SERVER INFORMATION *
 HOST(host03) PORT(1146)
 SVRNAME(fes1) SVRPID(905)

* SQL INFORMATION *
 OPTIMIZE_LEVEL(132768) ADDITIONAL_OPTIMIZE_LEVEL(3)
 ISOLATION_LEVEL(2)
 SQLOBJ_SIZE(2608) SQLCOUNT(1)

CNCTNO     SQL-       OP   SEC  SQL   SQL   START-TIME          END-TIME EXEC-
          COUNTER    CODE NO   CODE  WARN                               TIME
---------- ---------- ---- ---- ----- ----- ------------------- -------- -----
       10         10 AUI2 1890     0 -0000 2002/07/04 14:32:22 14:39:30   428

* SQL MESSAGE *
 "*" [*]

* SQL STATEMENT *
 DELETE FROM ZAIKO WHERE ZNO=1

The following shows the output format of the SQL runtime warning information (when an unsigned decimal number is used to specify a percentage of the PDCWAITTIME operand or an amount of elapsed time that is to constitute a trigger for output of warning information to a file is specified):

** SQL CWAITTIME WARNING INFORMATION 07-01    2002/07/04 14:32:22.100000 **
 REASON(01)
 CWAITIME(600) CWAITTIME_WRN_PNT(70.001000) CWAITTIME_WRN_TIME(420.006000)

* UAP INFORMATION *
 UAP_NAME(userprog1) CLTPID(408)
 IP_ADDR(196.12.42.146) SERVICE_NAME(service1)
 USERID(hiuser01) START_TIME(2002/07/03 20:24:42)

* SERVER INFORMATION *
 HOST(host03) PORT(1146)
 SVRNAME(fes1) SVRPID(905)

* SQL INFORMATION *
 OPTIMIZE_LEVEL(132768) ADDITIONAL_OPTIMIZE_LEVEL(3)
 ISOLATION_LEVEL(2)
 SQLOBJ_SIZE(2608) SQLCOUNT(1)

CNCTNO     SQL-       OP   SEC  SQL   SQL  
          COUNTER    CODE NO   CODE  WARN  
---------- ---------- ---- ---- ----- -----
       10         10 AUI2 1890     0 -0000

START-TIME                 END-TIME        EXEC-TIME

-------------------------- --------------- ------------
2002/07/04 14:32:22.122222 14:39:30.822223   428.700001

* SQL MESSAGE *
 "*" [*]

* SQL STATEMENT *
 DELETE FROM ZAIKO WHERE ZNO=1

Table 8-8 explains the SQL runtime warning information that is output.

Table 8-8 Description of SQL runtime warning information that is output

Output information
Header name
Description
Maximum number of characters (bytes)
Output?

Cond. 1
Cond. 2

HiRDB version
SQL CWAITTIME WARNING INFORMATION
HiRDB version, in the format VV-RR-ZZ. If there is no ZZ, it is not output.
8
Y
Y

Output time
Displays the time at which the warning was written into the SQL runtime warning information file, in one of the following formats:

YYYY/MM/DD hh:mm:ss

YYYY/MM/DD hh:mm:ss.uuuuuu (where uuuuuu is microseconds)

19 or 26
Y
Y

Reason code
REASON
Reason the warning was output to the SQL runtime warning information file:

00: The server process was terminated forcibly because the UAP was terminated forcibly.

01: The SQL execution time exceeded the set time.

2
Y
Y

Value of PDCWAITTIME operand
CWAITIME
Value (in seconds) set for the PDCWAITTIME operand in the client environment definitions.
5
Y
Y

Percentage specified in operand, or amount of elapsed time
CWAITTIME_
WRN_PNT
Displays the percentage (%) specified in the PDCWAITTIMEWRNPNT operand or the pd_cwaittime_wrn_pnt operand, or amount of time (seconds). The value that is output is the one that was applied, in accordance with the precedence level of the operands.
2 or 12
Y
Y

Elapsed time basis for output of warning information
CWAITTIME_
WRN_TIME
Amount of time (seconds) on the basis of which warning information was output.¹
5 or 12
Y
Y

Name of UAP
UAP_NAME
UAP name specified in the PDCLTAPNAME operand of the client environment definitions.
30
Y
Y

Process number
CLTPID
Client process number.
10
Y
Y

IP address
IP_ADDR
IP address of the client that executed the UAP.
15
Y
Y

Service name
SERVICE_
NAME
Depending on the type of UAP, the service name is indicated as follows:

For an OpenTP1 UAP
In the case of a service in which an OpenTP1 SUP (Service Utilization Program) has issued a request to an SPP (Service Provider Program), or a service in which TP1/Message Control is issuing a request to an MHP (Message Handling Program), the name of the service is output. In any other case, an asterisk (*) is output.

For other than an OpenTP1 UAP
An asterisk (*) is output.

31
S
S

Authorization identifier
USERID
Name of the connected user.
8
Y
Y

UAP start time
START_TIME
Time execution of the UAP started, in the format YYYY/MM/DD hh:mm:ss.
19
Y
Y

Host name
HOST
Name of the host on which the server process is running.
30
Y
Y

Port number
PORT
Communications port number used by the server process.
5
Y
S

Server name
SVRNAME
Name of the server. For a HiRDB/Single Server, the name of the single server is output; for a HiRDB/Parallel Server, the name of the front-end server is output.
8
Y
Y

Process number
SVRPID
Process number of the server process.
10
Y
Y

SQL optimization option
OPTIMIZE_
LEVEL
Value (in decimal) of the SQL optimization option. If this value cannot be obtained, an asterisk (*) is output.
10
Y
Y

SQL extension optimizing option
ADDITIONAL_
OPTIMIZE_LEVEL
Value (in decimal) of the SQL extension optimizing option. If this value cannot be obtained, an asterisk (*) is output.
10
Y
Y

Data guarantee level
ISOLATION_
LEVEL
Value set as the data guarantee level. If this value cannot be obtained, an asterisk (*) is output.
10
Y
Y

Size of SQL object
SQLOBJ_SIZE
Size (in bytes) of the SQL object. If this value cannot be obtained, an asterisk (*) is output.
10
S
N

SQL processed lines count
SQLCOUNT
Number of lines processed by the SQL code (the number of lines read by a SELECT statement, for example). If this value cannot be obtained, an asterisk (*) is output. For details about what is output, see the manual HiRDB Version 8 SQL Reference.
10
S
N

Connection sequence number
CNCTNO
Sequence number that increments each time a server receives a CONNECT request.
10
Y
Y

SQL counter
SQL-COUNTER
Sequence number that increments each time an SQL statement is received. If this value cannot be obtained, an asterisk (*) is output.
10
Y
N

Operation code
OP CODE
Operation code that corresponds to the SQL code. If this value cannot be obtained, an asterisk (*) is output.
4
Y
N

Section number
SEC NO
Section number that corresponds to the SQL code. If this value cannot be obtained, an asterisk (*) is output.
4
S
N

SQLCODE
SQL CODE
SQLCODE resulting from execution of the SQL statement. If this value cannot be obtained, an asterisk (*) is output.
5
Y
N

Warning information
SQL WARN
Warning information (in hexadecimal).² If this value cannot be obtained, an asterisk (*) is output.
5
Y
N

SQL start time
START-TIME
Displays the date and time the SQL execution request was received from the client, in one of the following formats:

YYYY/MM/DD hh:mm:ss YYYY/MM/DD

hh:mm:ss.uuuuuu (where uuuuuu is microseconds)

If this value cannot be obtained, an asterisk (*) is output.
19 or 26
Y
S

SQL end time
END-TIME
Displays the end time of processing in response to the request received from the client, in one of the following formats:

hh:mm:ss

hh:mm:ss.uuuuuu (where uuuuuu is microseconds)

If the server process was terminated forcibly, this value indicates the time at which processing ended.
8 or 15
Y
Y

SQL execution time
EXEC-TIME
Amount of time required to process the request received from the client (in seconds). If the server process was terminated forcibly, this value indicates the amount of time until processing ended. If this value cannot be obtained, an asterisk (*) is output.
5 or 12
Y
S

SQL message
SQL MESSAGE
Message output while the SQL code was executing. If this value cannot be obtained, an asterisk (*) is output.
254
S
N

Information in square brackets is system maintenance information. If this value cannot be obtained, an asterisk (*) is output.
21
Y
S

SQL statement
SQL STATEMENT
SQL statement. If a comment has been inserted in the SQL statement, or if an SQL optimization option has been specified, this information is also included in the output. If this value cannot be obtained, an asterisk (*) is output.
2,000,000
S
S

Legend:

Cond. 1: The SQL execution time reached the set time.

Cond. 2: The server process was terminated forcibly before SQL execution reached the set time.

Y: Always output

S: Sometimes output

N: Never output

¹ The following formula is used to obtain the time basis for output of warning information:

When an unsigned integer is used to specify a percentage of the PDCWAITTIME operand:

elapsed-time-basis-for-output-of-warning-information = MAX( (a b) 100 , 1)

a: Value of PDCWAITTIME operand

b: Value of PDCWAITTIMEWRNPNT operand or pd_cwaittime_wrn_pnt operand (whichever was applied, in accordance with the precedence level of these operands)

When an unsigned decimal number is used to specify a percentage of the PDCWAITTIME operand:

a: Value of the PDCWAITTIME operand

b: Value of the PDCWAITTIMEWRNPNT operand or pd_cwaittime_wrn_pnt operand (whichever was applied, in accordance with the precedence level of these operands)

Note that up to six decimal places are valid for the elapsed time basis for output of warning information. The seventh and subsequent decimal places are truncated.

When the amount of elapsed time that becomes a trigger for output of warning information to a file is specified:

elapsed-time-basis-for-output-of-warning-information = absolute-value-of-time-that-becomes-trigger-for-output-of-warning-information-to-file

² Starting from the left side, one bit is allocated for each of 16 warning items (SQLWARN0 to SQLWARNF). A 1 is set for a warning item whose warning flag is set, and a 0 is set for a warning item whose warning flag is not set. From this, a 16-bit hexadecimal number is obtained. This 16-bit hexadecimal value is then output as a 4-digit hexadecimal number. If one or more warning flags are set, W is prefixed to the 4-digit hexadecimal number. If no warning flags are set, a hyphen (-) is prefixed to the hexadecimal number.

Example 1: If the warning information is as shown in the following, WC040 is output:

Example 2: If the warning information is a shown in the following, -0000 is output:

8.9.4 Output of the KFPA20009-W message

The KFPA20009-W message is output to the message log file and the syslogfile.

Normally, the KFPA20009-W message (reason code = 01) is not re-issued at the same unit within a five-minute period.

However, it may be issued more than once within five minutes if the SQL runtime warning information output conditions are satisfied simultaneously by multiple server processes.

8.9.5 Notes

Even when it is not producing warning information, the SQL runtime warning output facility increases the number of system calls issued because the facility still must obtain SQL start times and execution times.

Depending on the exact time at which SQL runtime warning information is output, both of the conditions for output of a SQL runtime warning information file explained in 8.9.1(5) Conditions under which warning information is output may be satisfied. This means that SQL runtime warning information may be output twice for the same SQL statement.

A small period of time elapses from when the client issues a processing request until the SQL runtime warning output facility begins measuring the SQL execution time, and from when the facility has finished measuring the SQL execution time until its execution results arrive at the client, due to output processing, communications processing, and other factors handled by the facility. If this processing time takes too long due to the network or I/O load, the following behaviors may occur:

Even though the client wait time satisfied the conditions for output of a SQL runtime warning information file, no SQL runtime warning information file was output.

Although the server process was terminated forcibly due to a PDCWAITTIME timeout, the SQL execution time that was output to the SQL runtime warning information file does not satisfy the conditions for warning information to be output.

8.10 Monitoring the execution time of UAPs and utilities (reducing the effects of nonresponding programs)

This section explains how to minimize the effects when an error occurs that causes a UAP or utility to stop responding.

When an error (such as a communications error, an intermittent failure such as a power flicker, or a disk error) occurs during execution of an overnight batch job or other process, causing a UAP or a utility to stop responding, execution of other UAPs and utilities may be affected adversely or even stopped. In the worst case, the effects may extend to online operations on the following business day. To minimize the adverse effects of UAPs or utilities that are not responding, you can specify the following operands:

PDCWAITTIME operand of the client environment definitions

pdf_utl_exec_time operand of the system command definitions

The PDCWAITTIME operand is used to monitor UAP execution time. If a UAP or utility does not terminate once the time specified in this operand has elapsed, that UAP or utility is terminated forcibly. This minimizes adverse effects on other UAPs or utilities. In these operands, we recommend you specify a time that assumes a high probability of such errors occurring.

For details about the PDCWAITTIME operand of the client environment definitions, see the manual HiRDB Version 8 UAP Development Guide.

8.11 Monitoring resource utilization factors

A warning message can be output when a resource utilization factor shown in Table 8-9 reaches a specified value. Whether or not the warning messages are to be output is specified in system common definition operands. These operands can also be used to specify output trigger values for the warning messages. For example, a warning message can be output when a resource's utilization factor reaches 90%.

Table 8-9 Resources whose utilization factors can be monitored

Operand specified* | Monitored resource | Output warning message
pd_max_users_wrn_pnt | Maximum number of concurrent connections, as specified in the pd_max_users operand | KFPS05123-W
pd_max_access_tables_wrn_pnt | Number of base table that can access as specified in the pd_max_access_tables operand
pd_max_rdarea_no_wrn_pnt | Maximum number of RDAREAs, as specified in the pd_max_rdarea_no operand
pd_max_file_no_wrn_pnt | Maximum number of HiRDB files comprising an RDAREA, as specified in the pd_max_file_no operand
pdwork_wrn_pnt | HiRDB file system areas for work table files, as specified in the pdwork operand
pd_max_list_users_wrn_pnt | Maximum number of users who can create lists, as specified in pd_max_list_users
pd_max_list_count_wrn_pnt | Maximum number of lists that can be created by a user, as specified in pd_max_list_count
pd_aud_file_wrn_pnt | Number of audit trail files that cannot be swapped
pd_rdarea_list_no_wrn_pnt | Number of lists created in a server | KFPH22023-W

* When pd_watch_resource = AUTO is specified, the warning message is output when a resource utilization factor shown in Table 8-9 exceeds 80%. In this case, the operands shown in Table 8-9 need not be specified. To change message output triggers (to values other than 80%), use these operands to specify the appropriate output trigger values.

8.12 Monitoring the status of server processes (message queue monitoring facility)

A server on which server processing is down may experience degraded responses to UAPs, and even system freezes. This section explains how to use the message queue monitoring facility to monitor for server processes that are down.

Server processing down means that the server process has entered a state in which it is unable to perform any processing at all, due to CPU load-induced degradation of processing performance, I/O delay arising from an I/O error, or some other extreme condition.

Organization of this section

(1) Overview of message queue monitoring facility

(2) Action to be taken when the warning message is issued

(3) Taking steps to prevent server processing from going down

(4) Remarks

(1) Overview of message queue monitoring facility

HiRDB's server process allocation processing uses a message queue. When server processing is down, messages can no longer be read from the message queue. Under HiRDB, if messages cannot be read from the message queue once a specified amount of time has been reached (which is called the message queue monitoring time), a warning message (KFPS00888-W message) and an error message (KFPS00889-E message) are issued. This capability is provided by the message queue monitoring facility. When these messages are issued, server processing may have gone down.

The message queue monitoring time is normally 600 seconds (10 minutes). You can change this time with the pd_queue_watch_time operand.

(2) Action to be taken when the warning message is issued

When the warning message is issued, the possibility exists that server processing has gone down, so you should take one of the following actions:

Restart the unit

Cancel transactions

(a) Restarting the unit

You can restore the server process that went down by restarting the unit in which it was running. Normally, when the message queue monitoring time is exceeded, HiRDB terminates forcibly the unit whose server processing has gone down.

If you do not want the unit to be terminated forcibly, specify continue in the pd_queue_watch_timeover_action operand.

(b) Cancelling transactions

If you do not take the action described in (a) above (including when you cannot), use the pdcancel command to stop the transactions that are executing on the server whose processing is down. If there were no transactions, use the OS's kill command to terminate the server that stopped responding. Afterwards, identify the cause of the server process no-response and take appropriate action.

(3) Taking steps to prevent server processing from going down

Table 8-10 shows the causes of message queue stagnation and the corrective measures for the server whose message queue is being monitored.

Table 8-10 Causes of message queue stagnation and corrective measures

Cause | Server process being monitored | Corrective measure
FES | BES | DS | SDS
Messages cannot be read from the message queue because of a high CPU load. | Y | Y | Y | Y | Check the cause of the CPU overload and take appropriate corrective action.
Messages cannot be read from the message queue because an I/O error is delaying input/output. | Y | Y | Y | Y | Check the cause of the I/O error and take appropriate corrective action.
If the number of concurrent connection requests exceeds the value of the pd_max_users operand, the number of processes available for reading messages from the message queue is insufficient (this tends to occur when the high-speed connection facility is used). | Y |  |  | Y | Either reduce the number of concurrent connection requests or connect normally without using the high-speed connection facility. Alternatively, increase the value of the pd_max_users operand.
The number of processes available for reading messages from the message queue is insufficient when the number of active back-end servers or dictionary servers is smaller than the number of active front-end servers or utility servers (this tends to occur in a multiple front-end server environment). |  | Y | Y |  | Ensure that the correct values are specified in the pd_max_bes_process, pd_max_dic_process, and pd_max_users operands. Alternatively, reduce the number of connections.

Legend:

Y: Applicable

: Not applicable

Reference note

The number of HiRDB server processes that can be active is restricted by the following operands:

pd_max_server_process
If the number of active servers in a unit is large, carefully estimate the value to be specified for this operand. Also, if the standby-less system switchover facility is used, the estimate must take system switchover into account.

pd_max_bes_process
If multiple front-end servers or the standby-less system switchover (1:1) facility is used, carefully estimate the value to be specified for this operand.

pd_max_dic_process
If multiple front-end servers are used, carefully estimate the value to be specified for this operand.

pd_ha_max_server_process
If the standby-less system switchover (effects distributed) facility is used, carefully estimate the value to be specified for this operand.

pd_max_users
If the number of concurrent connections is large, an appropriate value must be specified.

(4) Remarks

You can use the pdls -d scd command to determine the time at which the last message was read from the message queue.

8.13 Monitoring the number of times server processes terminate abnormally (abnormal termination monitoring facility)

If server processes terminate abnormally often, servers may not be able to accept new services. However, because HiRDB itself does not usually terminate abnormally when a server process does, frequent server process abnormal terminations could bring online operations to an effective halt. To prevent this from occurring, the abnormal termination monitoring facility has been made available.

Organization of this section

(1) Overview of the abnormal termination monitoring facility

(2) Application range of the abnormal termination monitoring facility

(3) Specifying the abnormal termination monitoring facility

(4) Notes

(1) Overview of the abnormal termination monitoring facility

If the number of times that a server process is terminated abnormally in a specified amount of time reaches the value specified in the pd_down_watch_proc operand, HiRDB (or the associated unit for a HiRDB/Parallel Server) also terminates abnormally. This capability is provided by the abnormal termination monitoring facility.

We recommend that you use this facility in conjunction with the system switchover facility. This way, if HiRDB terminates abnormally because server processes have terminated abnormally more than the specified number of times, the system will be switched over quickly. If this monitoring facility is not used, HiRDB does not terminate abnormally, and the system is not switched over.

Even if you do not use this facility, you can restart HiRDB, which will refresh memory and other resources, leading to improved processing efficiency.

If HiRDB terminates abnormally due to the abnormal termination monitoring facility, the KFPS-01821-E and KFPS00729-E messages are issued.

(2) Application range of the abnormal termination monitoring facility

This facility monitors processes that have terminated abnormally due to a PDCWAITTIME timeout or an abort. For a HiRDB/Single Server, it counts the number of times that single server processes terminate abnormally. For a HiRDB/Parallel Server, it counts the total number of times that front-end, back-end, and dictionary server processes in the unit terminates abnormally. Table 8-11 lists the factors that may cause server processes to terminate abnormally and indicates which of these are counted as an abnormal termination.

Table 8-11 Causes of abnormal termination of server processes and which are counted as an abnormal termination

Cause of abnormal termination of a server process | Counted as an abnormal termination?
Single server process | Front-end server process | Dictionary server process | Back-end server process
The value of the PDCWAITTME operand in the client environment definitions was exceeded. | Y | Y | N¹ | N¹
The pdcancel command was executed. | N | N² | N | N
An internal forced termination occurred (HiRDB issued SIGKILL internally to stop the process). | Y³ | Y³ | N¹ | N¹
An abort occurred. | Y | Y | Y | Y
Rollback occurred on an XA-connected UAP. | Y | Y | N | N
An abnormal termination other than the above occurred. | Y | Y | Y | Y

Legend:

Y: Counted as an abnormally terminating process

N: Not counted as an abnormally terminating process

¹ If an error is detected during a transaction branch, any abnormal termination of a front-end server process generated from that transaction branch is counted.

² If the pdcancel command is used to terminate forcibly a back-end server process or a dictionary server process, front-end server processes are terminated forcibly internally. In such a case, abnormal termination of the front-end server processes may be counted.

³ If an error is detected during a global transaction issued by an OLTP system, any abnormal termination of a single server process or a front-end server process generated from that global transaction is counted.

(3) Specifying the abnormal termination monitoring facility

You use the pd_down_watch_proc operand to specify the period over which the number of server process abnormal terminations is to be monitored and the maximum number of times that server processes are to be allowed to terminate abnormally.

Example: pd_down_watch_proc = 1000, 60

In this case, the number of times server processes terminate abnormally is monitored in 60-second intervals. If the number of times server processes terminate abnormally in any 60-second interval exceeds 1000, HiRDB terminates abnormally.

(4) Notes

The KFPS01820-E message is issued when a server process terminates abnormally. The KFPS01820-E message is also issued when the pdcancel command is used to terminate a server process abnormally; however, in this case, the abnormal termination is not counted.

Use of a mutual system switchover configuration may actually cause traffic to increase, negating any benefits from this facility. The reason for this is because, if system switchover executes, multiple instances of HiRDB will become active on a single server machine. When you use the abnormal termination monitoring facility, we recommend that you restart HiRDB on the same system as the instance of HiRDB that terminated abnormally.

8.14 Monitoring the memory size of server processes (facility for monitoring the memory size of server processes)

This section explains the use of the facility for monitoring the memory size of server processes.

This facility need not be used in Linux.

Organization of this section

(1) Overview

(2) Advantages

(3) Application standard

(4) Specification of the facility for monitoring the memory size of server processes

(5) Notes

(1) Overview

When the amount of work memory being used by a server process exceeds a given value, the process is terminated at the time shown in Table 8-12. This is called the facility for monitoring the memory size of server processes.

Table 8-12 Time of termination of a server process by the facility for monitoring the memory size of server processes

Server type | Process name | Process termination time
Single server | pdsds | At UAP disconnection¹
Front-end server | pdfes
Dictionary server | pddic | At transaction completion²
Back-end server pdbes | pdbes

¹ For purposes of this facility, UAP disconnection means any of the following:

When the UAP terminates

When the UAP issues a DISCONNECT statement

When an OpenTP1 user server process that uses the HiRDB XA connection client library terminates

When a transaction being executed in the user server process is completed (committed or rolled back) when transaction is specified in the trn_rm_open_close_scope operand in an OpenTP1 user server that uses the HiRDB XA connection client library

During data commitment by HiRDB Datareplicator, when no commitment request is received before a certain amount of time (value specified in the target system's discintvl definition parameter) elapses after the end of the commitment information queue file has been detected

² For purposes of this facility, transaction completion means any of the following:

When a UAP disconnection as explained in footnote 1 above occurs

When the UAP issues a COMMIT or ROLLBACK statement

When the UAP is rolled back internally by an SQL error

When a transaction being executed in the user server process is completed (committed or rolled back) in an OpenTP1 user server that uses the HiRDB XA connection client library

The amount of memory being used by SQL processing, etc., is monitored by this facility. The amount of memory allocated at the time of HiRDB activation is not monitored. Figure 8-16 shows the monitoring range of this facility.

Figure 8-16 Monitoring range of facility for monitoring the memory size of server processes

(2) Advantages

The facility for monitoring the memory size of server processes addresses the following problem:

The amount of memory used by server-resident processes in given SQL processing has become large, resulting in system memory shortages.

HiRDB releases unneeded memory. However, even when a program releases memory, the OS uses the memory management function in the applicable process to retain the memory area. Consequently, a process size that has grown large by using a large area even once never shrinks. Resident processes especially continue to impact the system. Because the facility for monitoring the memory size of server processes can terminate even resident processes, the memory shortage problem can be prevented.

This facility does not affect execution of jobs currently being used.

(3) Application standard

You should use this facility when the amount of memory used by HiRDB server processes becomes large, resulting in memory shortages.

(4) Specification of the facility for monitoring the memory size of server processes

To use the facility for monitoring the memory size of server processes, specify the maximum amount of memory to be used by a server process in the pd_svr_castoff_size operand in the server definition.

(5) Notes

If the pd_work_buff_mode operand is omitted or if pool is specified, the value of the pd_work_buff_size operand will be included in the memory size allocated when HiRDB starts. Consequently, the value of the pd_work_buff_size operand will not be monitored by this facility. Therefore, this facility may not have much effect if a large value is specified in the pd_work_buff_size operand.

In the cases shown in Table 8-13, the facility for monitoring the memory size of server processes will not have any effect because server processes that use large amounts of memory cannot be terminated.

Table 8-13 Cases in which facility for monitoring the memory size of server processes is not effective

Condition
Ineffective cases

Single server or front-end server

A UAP connected to a server process that uses a large amount of memory does not issue a DISCONNECT statement (including when HiRDB SQL Executor does not disconnect from HiRDB).

Many OpenTP1 user server processes that do not use the HiRDB XA connection client library do not issue DISCONNECT statements, increasing the amount of memory used by the connected server processes.

Many OpenTP1 user server processes remain that use the HiRDB XA connection client library and for which process is specified in the trn_rm_open_close_scope operand, increasing the amount of memory used by the connected server processes. (In this case, the facility for monitoring the memory size of server processes is applied when the user server processes terminate and are disconnected.)

Dictionary server or back-end server

A UAP connected to a server process that uses a large amount of memory does not issue a COMMIT or ROLLBACK statement (including when HiRDB SQL Executor does not issue a COMMIT or ROLLBACK statement).

Many OpenTP1 user server processes that do not use the HiRDB XA connection client library do not issue a COMMIT or ROLLBACK statement, increasing the memory size of the connected server processes.

Many transactions being executed in the user server processes in an OpenTP1 user server that use the HiRDB XA connection client library are uncompleted (committed or rolled back), increasing the amount of memory used by the connected server processes. (In this case, the facility for monitoring the memory size of server processes is applied when the transactions are completed.)

9. Modifying the System Operating Environment

This chapter explains the procedures for modifying the system operating environment.

This chapter contains the following sections:

Organization of this chapter

9.1 Modifying HiRDB system definitions

9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command)

9.3 Adding, modifying, and deleting global buffers while HiRDB is running (dynamic updating of global buffers)

9.4 Changing the number of server processes

9.5 Handling an increase in the number of users

9.6 Accommodating clients that cannot connect to HiRDB (connection frame guarantee facility for client groups)

9.7 Specifying a range of port numbers for use in communication processing

9.8 Changing the host name

9.9 Changing the deadlock priority value for commands

9.1 Modifying HiRDB system definitions

Executor: HiRDB administrator

This section explains how to modify HiRDB system definitions (other than UAP environment definitions; for details about modifying UAP environment definitions, see the manual HiRDB Version 8 System Definition).

Organization of this section

(1) Modification procedure

(2) Notes

(3) Notes on the HiRDB/Parallel Server

(4) When linked to HiRDB Datareplicator

(1) Modification procedure

To modify the HiRDB execution environment, you must modify HiRDB system definitions. The following shows the procedure used to modify HiRDB system definitions. In this procedure, $PDDIR/conf indicates the directory that stores the unit control information definition file, while $PDCONFPATH indicates the directory that stores all other HiRDB system definition files.

Procedure

Create subdirectories in the $PDDIR/conf and $PDCONFPATH directories. For this example, the subdirectories are named work.

Copy the unit control information definition file into the $PDDIR/conf/work directory. Copy the other HiRDB system definition files into the $PDCONFPATH/work directory.

Modify the HiRDB system definitions that you copied into the $PDDIR/conf/work and $PDCONFPATH/work directories.

Use the pdconfchk -d work command to check the HiRDB system definitions in the $PDDIR/conf/work and $PDCONFPATH/work directories. If errors are detected, correct each erroneous HiRDB system definition, and then execute the pdconfchk command again.

Use the pdstop command to terminate HiRDB normally.

Use the pdlogunld command to unload any system log files that are in unload wait status.

Copy any HiRDB system definitions files that you modified in step 3 into the $PDDIR/conf or $PDCONFPATH directory, replacing the current HiRDB system definition files.

If you changed the value specified in either of the following operands, use the pdloginit command to initialize the system log files:
pd_log_dual
pdstart

Use the pdstart command to start HiRDB normally.

(2) Notes

In the case of a HiRDB/Parallel Server, you must create subdirectories in the $PDDIR/conf and $PDCONFPATH directories in each unit and check the HiRDB system definitions in all of the units.

HiRDB system definitions that are being used by HiRDB must not be modified during operation. If modifications or deletions are made in such a situation, operation of the HiRDB cannot be guaranteed.

When HiRDB is terminated with planned, forced, or abnormal termination, some of the HiRDB system definition operands cannot be modified; for the operands that cannot be modified, see the manual HiRDB Version 8 System Definition.

After you have modified the HiRDB system definitions, back up the files in the $PDDIR/conf directory. To be prepared for the possibility of an error on the disk storing the HiRDB directory, you must back up the files in the HiRDB directory (files in $PDDIR/conf). You will need such a backup to recover the HiRDB directory if an error does occur. If the $PDCONFPATH directory is also in the HiRDB directory, back it up as well.

If you use the system reconfiguration command (pdchgconf command), you do not need to terminate HiRDB normally, because the pdchgconf command enables you to change HiRDB system definitions while HiRDB is running. Note that HiRDB Advanced High Availability is required in order to use this command. For details about changing HiRDB system definitions while HiRDB is running, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

If you are using the standby-less system switchover facility, do not modify HiRDB system definitions in the normal BES unit until you have used the pdstop -u command to terminate normally both the normal BES unit and the alternate BES unit. After you have modified HiRDB system definitions, copy the unit control information definition file and the back-end server definition files from the normal BES unit to the alternate BES unit. For details, see 25.5.3(2) Standby-less system switchover (1:1) facility.

(3) Notes on the HiRDB/Parallel Server

When a system common definition is modified, the same changes must be made in the system common definition at every server machine.

If any unit terminates abnormally during normal or planned termination processing, no HiRDB system definition modifications should be made before the next startup. If modifications are made, HiRDB startup will probably fail (if HiRDB does start, it will not operate correctly).

(4) When linked to HiRDB Datareplicator

Before any of the following operands are added, modified, or deleted, HiRDB Datareplicator must be terminated:

pd_log_dual

pd_log_max_data_size

pdlogadfg -d sys

pdlogadpf -d sys

HiRDB Datareplicator can be started again after the changes have been made. If these operands are added, modified, or deleted while HiRDB Datareplicator is running, data extraction by HiRDB Datareplicator may fail.

9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command)

Executor: HiRDB administrator

This section explains how to modify HiRDB system definitions with the system reconfiguration command (pdchgconf command). The system reconfiguration command enables you to modify HiRDB system definitions while HiRDB is running, which eliminates the need to terminate HiRDB normally. To use this command, however, HiRDB Advanced High Availability must be installed.

Organization of this section

9.2.1 Modification procedure

9.2.2 Notes on changing operand specification values

9.2.3 Notes on executing the system reconfiguration command

9.2.4 HiRDB status after the system reconfiguration command has executed

9.2.5 Relationship with other facilities

9.2.6 Actions to take when an error occurs

9.2.1 Modification procedure

The following procedures show how to modify HiRDB system definitions with the system reconfiguration command.

Procedure

Create a $PDDIR/conf/chgconf directory.

Copy the current HiRDB system definition files into the directory that you created in step 1.

Modify the HiRDB system definitions in the $PDDIR/conf/chgconf directory.

Use the pdconfchk -d command to check the HiRDB system definitions in the $PDDIR/conf/chgconf directory. If errors are detected, correct each erroneous HiRDB system definition, and then execute the pdconfchk command again.

Use the pdchgconf command to replace the current HiRDB system definitions with the HiRDB system definitions that you modified. When the pdchgconf command is entered, the HiRDB system definition files currently being used (the unchanged files) are moved into the $PDDIR/conf/backconf directory, and the modified HiRDB system definition files in the $PDDIR/conf/chgconf directory are copied into the $PDDIR/conf directory.

After you execute this command, we recommend that you check that the execution results are correct. For details about checking command execution results, see the manual HiRDB Version 8 Command Reference.

Notes

Assign HiRDB administrator write and access privileges for the $PDDIR/conf, $PDDIR/conf/chgconf, and $PDDIR/conf/backconf directories, and for all files under these directories.

If a transaction or a utility remains active continuously for 15 minutes after the pdchgconf command has been entered, the command terminates abnormally.

9.2.2 Notes on changing operand specification values

Organization of this subsection

(1) Operands whose specification values cannot be changed

(2) Operands that cannot be deleted

(3) Invalid operands

(4) Operands whose specification values affect system parameters

(5) Note on changing the pd_rpl_init_start operand

(6) Operands required by prerequisite products

(1) Operands whose specification values cannot be changed

The specification values of the following operands cannot be changed:

pd_system_id

pd_master_file_name

If the values specified in these operands are changed, the database must be initialized. Consequently, the system reconfiguration command should not be used to change these HiRDB system definitions.

(2) Operands that cannot be deleted

The following operands cannot be changed:

pdlogadfg -d sys and pdlogadpf -d sys (only operands associated with system log files that are current or overwrite disabled cannot be deleted)

pdlogadfg -d spd and pdlogadpf -d spd (only operands associated with synchronization point dump files that are being written or are overwrite disabled cannot be deleted)

pd_syssts_file_name_1 to 7 (only operands associated with status files for the primary unit cannot be deleted)

pd_sts_file_name_1 to 7 (only operands associated with status files for the primary server cannot be deleted)

(3) Invalid operands

Specification of operands related to reduced activation has no effect.

(4) Operands whose specification values affect system parameters

Changing the values specified in some operands requires changing values specified in operating system parameters as well. Examples of such operands are pd_max_users and SHMMAX. For a change to an operating system parameter to take effect, the machine must be restarted. In such a case, we recommend that you do not use the system reconfiguration command to modify HiRDB system definitions. Instead, terminate HiRDB normally, and then make the changes.

(5) Note on changing the pd_rpl_init_start operand

You must pay special attention if you use the pdrplstart or pdrplstop command to change the execution status of the HiRDB Datareplicator data extraction facility. Whether or not you will be able to execute the system reconfiguration command may depend on the value of the pd_rpl_init_start operand.

Table 9-1 shows the executability of the system reconfiguration command depending on the pd_rpl_init_start operand's value and the data extraction facility's status.

Table 9-1 Executability of the system reconfiguration command depending on the pd_rpl_init_start operand value and the data extraction facility status

Value of pd_rpl_init_start before change | Execution status of the HiRDB Datareplicator data extraction facility | Value of pd_rpl_init_start after change | Executability of the system reconfiguration command
Y | Running | Y | Yes
N (default) | No
Stopped (by means of the pdrplstop command) | Y | No
N (default) | Yes
N (default) | Stopped | Y | No
N (default) | Yes
Running (by means of the pdrplstart command) | Y | Yes
N (default) | No

Legend:

Yes: The pd_rpl_init_start operand can be changed.

No: The pd_rpl_init_start operand cannot be changed.

(6) Operands required by prerequisite products

To set up or remove optional program products or plug-ins, you must stop HiRDB. This means that you may not be able to use the system reconfiguration command to delete operands or change specification values required by prerequisite products, such as optional program products and plug-ins.

9.2.3 Notes on executing the system reconfiguration command

Note on system log files (important)

When you execute the system reconfiguration command, system log files are swapped. Therefore, before you execute the pdchgconf command, check that swappable target files are available. If you execute the pdchgconf command when no swappable target files are available, HiRDB terminates abnormally. If this happens, prepare a swappable target file, and restart HiRDB with the pdstart command.

Environments in which the system reconfiguration command cannot be executed

The system reconfiguration command cannot be executed when any one of the following conditions applies:

HiRDB was started with the pdstart -r command.

A unit or server is stopped (including in reduced activation).*

An ongoing network communications failure has occurred between units.*

An updatable online reorganization session is executing.

The pdrplstop command is executing.

* This is applicable to a HiRDB/Parallel Server only.

Reference note

When a recovery-unnecessary front-end server is used, the environments in which the system reconfiguration command cannot be executed differ. For details, see 9.2.5(3) Relationship with a recovery-unnecessary front-end server (HiRDB/Parallel Server only).

Restrictions and limitations on executing the system configuration command

Do not execute any other command or utility while the system reconfiguration command is executing. If you do, an error message stating that HiRDB has stopped may be issued.

Cursors cannot be held when the system reconfiguration command is executed. Therefore, do not execute the command while a UAP that uses a holdable cursor is executing.

The UNTIL DISCONNECT lock specification cannot be retained when the system reconfiguration command is executed. Therefore, do not execute the command while a UAP that uses the LOCK statement of the UNTIL DISCONNECT specification is executing.

Responses to UAPs are slower than normal while the system reconfiguration command is executing.

If you execute the system reconfiguration command while using a HiRDB client of version 07-00 or earlier, the HiRDB server is disconnected from that HiRDB client. Therefore, if you are using HiRDB clients of version 07-00 or earlier, be careful to execute the system reconfiguration command only when doing so will not interfere with normal operations.

Notes on linkage with HiRDB Datareplicator

If you add or delete a unit or server while HiRDB is linked to HiRDB Datareplicator, you must rebuild the extraction environment of HiRDB Datareplicator. Furthermore, if a HiRDB transaction adds, updates, or deletes the extracted database while the extraction environment of HiRDB Datareplicator is being rebuilt, a mismatch with the target database occurs. For this reason, do not execute the system reconfiguration command while the extraction environment of HiRDB Datareplicator is being rebuilt.

9.2.4 HiRDB status after the system reconfiguration command has executed

After the system reconfiguration command has executed, HiRDB is in the same status it would be when it restarts normally. This means that the following events occur:

System log files are swapped.

Message log files are swapped. To retain messages in the message log file, back up the message log file before you execute the system reconfiguration command.

Global buffers assigned with the database structure modification utility become invalid.

Global buffers modified dynamically by the pdbufmod command become invalid.

The time count of the cleanup interval for troubleshooting information specified with the pd_spool_cleanup_interval operand resets to 0.

If normal or force (default) is specified in the pd_spool_cleanup operand, troubleshooting information that has already been output is deleted.

Any statistical information collection change made with the pdstbegin or pdstend command becomes invalid, and the values specified in the pd_statistics and pdstbegin operands take effect.

Any resident process count change made with the pdchprc command becomes invalid, and the specification in the HiRDB system definitions takes effect.

If the pd_db_io_error_action=unitdown specification becomes invalid due to recurrence of an I/O error after HiRDB (or a unit in the case of a HiRDB/Parallel Server) terminates abnormally, the unitdown specification takes effect.

Lists used for narrowed searches are lost.

9.2.5 Relationship with other facilities

Organization of this subsection

(1) Relationship with HiRDB Datareplicator (HiRDB/Parallel Server only)

(2) Relationship with system switchover facilities

(3) Relationship with a recovery-unnecessary front-end server (HiRDB/Parallel Server only)

(1) Relationship with HiRDB Datareplicator (HiRDB/Parallel Server only)

Because HiRDB Datareplicator definitions and other values are updated when a unit or back-end server configuration is modified, you must stop HiRDB Datareplicator before performing such a change. The following shows the procedure for modifying the configuration of a unit or back-end server.

Procedure

Use the pdrplstop command to disconnect HiRDB Datareplicator.

Use the HiRDB Datareplicator hdestop command to stop the data extraction facility.

If Y is specified in the pd_rpl_init_start operand, change it to N.

Change the configuration of the unit or back-end server, and execute the system reconfiguration command. For details about changing the configuration of a unit or back-end server, see 11. Modifying the System Configuration.

Reconfigure the extraction environment of HiRDB Datareplicator.

Use the HiRDB Datareplicator hdestart command to start the data extraction facility.

Use the pdrplstart command to connect HiRDB Datareplicator.

If you changed pd_rpl_init_start to N in step 3, change N back to Y, and then execute the system reconfiguration command.

(2) Relationship with system switchover facilities

(a) Standby system switchover facility

Execute the system reconfiguration command only when the primary system is the same as the running system. In addition, use the system reconfiguration command only to change HiRDB system definitions on the primary (running) system. Change HiRDB system definitions on the secondary system by copying the HiRDB system definition files from the primary system to the secondary system. The following procedures show how to modify HiRDB system definitions when the standby system switchover facility is being used.

Procedure 1: When your cluster software is HA Monitor and the standby system switchover facility is in the server mode:

Execute the system reconfiguration command on the primary system. This causes the secondary system HiRDB to stop automatically.

After the system reconfiguration command processing finishes, copy the HiRDB system definition files from the primary system to the secondary system.

On the secondary system, execute the pdstart command (pdstart -q for a HiRDB/Parallel Server) to start the secondary system HiRDB.

Procedure 2: When Hitachi HA Toolkit Extension is being used:

Stop the secondary system HiRDB.

Execute the system reconfiguration command on the primary system.

After the system reconfiguration command processing finishes, copy the HiRDB system definition files from the primary system to the secondary system.

On the secondary system, execute the pdstart command (pdstart -q for a HiRDB/Parallel Server) to start the secondary system HiRDB.

Procedure 3: When the standby switchover facility is in the monitor mode:

Execute the system reconfiguration command on the primary system.

After the system reconfiguration command processing finishes, copy the HiRDB system definition files from the primary system to the secondary system.

(b) Standby-less system switchover facility

The following procedures show how to modify HiRDB system definitions when the standby-less system switchover facility is being used. Note that the system reconfiguration command cannot be used when the system has alternated (while the alternate BES is the active system).

Procedure 1: When the cluster software is HA Monitor:

Copy the following HiRDB system definitions into the $PDDIR/conf/chgconf directory in the alternate BES unit:
Back-end server definitions for the normal BES
Unit control information definitions for the normal BES unit

Execute the system reconfiguration command.

Procedure 2: When Hitachi HA Toolkit Extension is being used:

Copy the following HiRDB system definitions into the $PDDIR/conf/chgconf directory in the alternate BES unit:
Back-end server definitions for the normal BES
Unit control information definitions for the normal BES unit

Use the pdstop -q -c command to release the wait status of the alternate portion.

Execute the system reconfiguration command. Note that executing the system reconfiguration command automatically places the alternate portion whose wait status was released in step 2 back into wait status.

(c) Notes (for both standby and standby-less system switchover facilities)

Note 1 applies when the standby system switchover facility is being used, and note 2 applies when the standby-less switchover facility is being used. Note 3 applies for both facilities.

Because the HiRDB system definitions on the primary system do not match the definitions on the secondary system while the system reconfiguration command is executing, the system cannot be switched over by means of a planned system switchover or as a result of a server failure.

Because the back-end server definitions and the unit control information definitions on the normal BES unit do not match the equivalent definitions on the alternate BES unit while the system reconfiguration command is executing, the system cannot be switched by means of a planned system switchover or as a result of a server failure.

If all of the following conditions apply, set up a shell that does not reposition IP addresses before you execute the system reconfiguration command:
The system is configured as a HiRDB/Parallel Server.
The cluster software is HA monitor.
The system switchover facility is in the server mode.
The configuration is set up for inheriting IP addresses.

(3) Relationship with a recovery-unnecessary front-end server (HiRDB/Parallel Server only)

(a) Conditions under which the system reconfiguration command can be executed

When a recovery-unnecessary front-end server is used, the environments in which the system reconfiguration command can be executed differ. If any of the following conditions is satisfied, the system reconfiguration command cannot be executed:

The pdstart -r command was used to start HiRDB.

Some units or servers have been shut down (including reduced activation).*

A communication error has occurred between units in the network.

Updatable online reorganization is being executed.

The pdrplstop command is executing.

The pd_mode_conf operand is set to AUTO.

The front-end server in a stopped unit ceases to be a recovery-unnecessary front-end server after a system definition change.

* Not including a recovery-unnecessary front-end server.

Hint

The system reconfiguration command can be executed even if the recovery-unnecessary front-end server is not active. However, all units other than the recovery-unnecessary front-end server must be active. In addition, all servers in the active units must also be active.

(b) Note

Executing the system reconfiguration command also reconfigures the HiRDB system definition of units that are stopped (recovery-unnecessary front-end server units). During this process, stopped units are started in order to modify their HiRDB system definition.

9.2.6 Actions to take when an error occurs

Organization of this subsection

(1) If an error occurs when the system reconfiguration command is executed

(2) If HiRDB cannot be started using the changed HiRDB system definitions

(3) If the KFPS04665-W message is output

(1) If an error occurs when the system reconfiguration command is executed

Figure 9-1 shows the actions to take if an error occurs when the system reconfiguration is executed.

Figure 9-1 Action to take if an error occurs when the system reconfiguration command is executed

(a) If an error occurs during the configuration change pre-processing stage

If an error occurs during this interval, determine the cause of the error based on the message that is issued. In addition, use the pdls command to check if HiRDB has stopped. If it has stopped, use the pdstart command to start HiRDB. In this case, HiRDB starts using the unchanged HiRDB system definitions.

A message or an abort code may be issued accompanying a HiRDB termination processing failure. In this case, take action based on the message or abort code that is issued.

(b) If an error occurs during the HiRDB system definition change processing stage

If an error occurs during this interval, check the usage status of the disk containing the HiRDB directory; also check the access privileges to the HiRDB system definition files. In addition, use the pdls command to check if HiRDB has stopped. If it has stopped, copy the unchanged HiRDB system definition files in the $PDDIR/conf/backconf directory into the $PDDIR/conf directory and recover the system. Then use the pdstart command to start HiRDB.

If a unit or server has been moved, check its connection to the disk.

(c) If an error occurs during the HiRDB system definition change post-processing stage

If an error occurs during this interval, the system reconfiguration command automatically restores the unchanged HiRDB system definitions. Determine the cause of the error based on the message that is issued. Then check the HiRDB system definitions in the $PDDIR/conf directory.

In addition, use the pdls command to check that HiRDB is running. If it is not running, use the pdstart command to start HiRDB. To start HiRDB using the changed HiRDB system definitions, copy the HiRDB system definition files in the $PDDIR/conf/chgconf directory into $PDDIR/conf, and then start HiRDB.

A message or an abort code may be issued accompanying a HiRDB startup processing failure. If this happens, there may be a problem with the changed HiRDB system definitions or environment, so take the following actions:

Use the pdconfchk command to check the changed HiRDB system definitions.

Based on the message, secure the resources needed to run the modified system configuration.

Note that the system reconfiguration command cannot be used if an operating system parameter needs to be changed.

If a unit or server has been moved, the system reconfiguration command may not be able to restore the unchanged HiRDB system definitions. Check the connections to the disk. To start HiRDB using the unchanged HiRDB system definitions, copy the HiRDB system definitions from the $PDDIR/conf/backconf directory. To start HiRDB using the changed HiRDB system definitions, copy the HiRDB system definitions from the $PDDIR/conf/chgconf directory. Then use the pdstart command to start HiRDB.

(2) If HiRDB cannot be started using the changed HiRDB system definitions

If HiRDB cannot be started using the changed HiRDB system definitions, the unchanged definitions are restored automatically, and another attempt is made to start HiRDB. If HiRDB does not start using the unchanged HiRDB system definitions either, take action based on the error messages that are issued.

(3) If the KFPS04665-W message is output

If the KFPS04665-W message is output, take action in accordance with the following procedure:

Procedure

Identify the unit indicated by the KFPS04665-W message.

Execute the pdls -d svr command to check the unit's status. Check the status in the execution results and determine whether STOP(A) is indicated for any unit.

If there is a unit with STOP(A), forcibly terminate that unit with the pdstop -z command.

Replace the HiRDB system definition files under $PDDIR/conf and $PDCONFPATH for the unit indicated in the KFPS04665-W message with the modified HiRDB system definition files.

Start the unit with the pdstart -u command.

9.3 Adding, modifying, and deleting global buffers while HiRDB is running (dynamic updating of global buffers)

Executor: HiRDB administrator

This section explains how to use the pdbufmod command to add, modify, and delete global buffers while HiRDB is running.

Organization of this section

9.3.1 Overview of dynamic updating of global buffers

9.3.2 Application examples

9.3.1 Overview of dynamic updating of global buffers

You use the pdbufmod command to add, modify, and delete global buffers while HiRDB is running. This is called dynamic updating of global buffers. For example, you can perform global updating of global buffers for the following purposes:

To assign a global buffer to an RDAREA that has been added

To modify a global buffer already assigned to an RDAREA

To modify global buffer definitions based on the results of tuning

Note that HiRDB Advanced High Availability must be installed in order to perform dynamic updating of global buffers.

Organization of this subsection

(1) Limitations on the validity of dynamic updating of global buffers

(2) Before performing the dynamic update operation

(3) Notes

(1) Limitations on the validity of dynamic updating of global buffers

Global buffers that have been updated dynamically become invalid when HiRDB terminates normally or with a planned termination. Therefore, while HiRDB is stopped, you must use the pdbuffer operand to define any global buffers that were updated dynamically. Note also that when you use the system reconfiguration command (pdchgconf command), you can change values specified in the pdbuffer operand while HiRDB is running. For details about using the system reconfiguration command to change HiRDB system definitions, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

In addition, before terminating HiRDB normally or with a planned termination, you should save the execution results of the pdbufls -k def command (global buffer definition information). You can then refer to this information to update the pdbuffer operand.

(2) Before performing the dynamic update operation

Before updating global buffers dynamically, you must first complete the operations described in the following subsections.

(a) Specify HiRDB system definitions

Specify Y in the pd_dbbuff_modify operand.

If fixed is specified in the pd_dbbuff_attribute operand (default value in the 32-bit mode), the shared memory used by a global buffer that is added or modified by this function is fixed in real memory. Therefore, consider carefully the size of the real memory before adding or modifying global buffers. If the size of the real memory is inadequate, specify free in the pd_dbbuff_attribute operand.

Re-estimate the value specified in the SHMMAX operand.

(b) Perform memory-related preparations

When this function is used, the space needed for the shared memory resources listed below increases. To accommodate this increase, you must re-estimate the shared memory size requirements. For details about estimating shared memory size requirements, see the manual HiRDB Version 8 Installation and Design Guide.
Shared memory used by global buffers
Shared memory used by a single server
Shared memory used by the dictionary server
Shared memory used by back-end servers

The space required by status files increases. To accommodate this increase, you must re-estimate the status file size requirements. For details about estimating status file size requirements, see the manual HiRDB Version 8 Installation and Design Guide.

Re-estimate the shmmax, shmmni, and shmseg operating system parameters (on Solaris, the shminfo_shmmax, shminfo_shmmin, and shminfo_shmseg parameters; on Linux, the SHMMAX, SHMMIN, and SHMSEG parameters). For details about estimating operating system parameters, see the manual HiRDB Version 8 Installation and Design Guide.

(3) Notes

(a) Relationship with other facilities

You cannot perform dynamic updating of global buffers while you are using the rapid system switchover facility or the standby-less system switchover facility. To use these facilities, execute the system reconfiguration command (pdchgconf command) to change the values specified in the pdbuffer operand so that global buffers are assigned. Use of the pdchgconf command enables you to modify HiRDB system definitions while HiRDB is running. However, HiRDB Advanced High Availability must be installed in order to use this command. For details about changing HiRDB system definitions while HiRDB is running, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

(b) Exclusion control

While dynamic updating of global buffers is being performed (while the pdbufmod command is executing), the associated RDAREAs are locked by placing them in exclusion mode (EX). This means that transactions that attempt to access these RDAREAs are placed in wait status.

(c) Maximum number of global buffers

To set the maximum number of global buffers, use the pd_max_add_dbbuff_no and pd_max_add_dbbuff_shm_no operands.

You can determine the number of global buffers by counting the number of global buffers displayed in the execution results of the pdbufls -k def command. For a HiRDB/Parallel Server, count the number of global buffers associated with the server name (header name: SVID).

(d) Maximum number of shared memory segments used for global buffers

When you update a global buffer dynamically (when a global buffer is added or when a global buffer modification increases memory requirements), a new shared memory segment is secured, and the dynamically updated global buffer is assigned to this shared memory segment. To set the shared memory segments, use the pd_max_add_dbbuff_no and pd_max_add_dbbuff_shm_no operands. For a HiRDB/Parallel Server, set the value for each server. You can determine the number of shared memory segments by counting the number of shared memory segments displayed in the execution results of the pdbufls -k mem command. For a HiRDB/Parallel Server, count the number of shared memory segments associated with the server name (header name: SHM-OWNER).

If the number of shared memory segments exceeds the maximum, update the pdbuffer operand with the definition information for the dynamically updated global buffers. Then, starting HiRDB normally will reduce the number of shared memory segments.

Note that if the size of the shared memory used by a dynamically updated global buffer is greater than the value in the SHMMAX operand, the shared memory that is being used by the global buffer will consist of more than one shared memory segment. You can use the following formula to obtain the number of shared memory segments that have been allocated:

size-of-shared-memory-used-by-the-dynamically-updated-global-buffer value-in-SHMMAX-operand

For details about shared memory used by global buffers, see the manual HiRDB Version 8 Installation and Design Guide.

9.3.2 Application examples

This section provides application examples illustrating how to use the pdbufmod command to add, modify, and delete global buffers.

Organization of this subsection

(1) Example 1: Adding a global buffer

(2) Example 2: Adding a global buffer and changing an RDAREA's global buffer assignment

(3) Example 3: Setting an RDAREA global buffer assignment

(4) Example 4: Changing an RDAREA global buffer assignment

(5) Example 5: Deleting a global buffer

(6) Example 6: Deleting a global buffer to which an RDAREA is assigned

(7) Example 7: Separating an RDAREA from a global buffer

(8) Example 8: Changing a global buffer definition

(1) Example 1: Adding a global buffer

In this example, a global buffer (gbuf01) is added, and an RDAREA (RDAREA1) added for that global buffer is assigned.

pdbufmod -k add -a gbuf01 -r RDAREA1 -n 1000

Explanation

-k add: Specifies addition of a global buffer.

-a: Specifies a name for the global buffer being added.

-r: Specifies an RDAREA to assign.

-n: Specifies the number of buffer sectors for the global buffer.

(2) Example 2: Adding a global buffer and changing an RDAREA's global buffer assignment

In this example, a global buffer (gbuf02) is added. At the same time, the global buffer to which an RDAREA (RDAREA1) is assigned (the RDAREA global buffer assignment) is changed from gbuf01 to gbuf02.

pdbufmod -k add -a gbuf02 -r RDAREA1 -n 1000

Explanation

-k add: Specifies addition of a global buffer.

-a: Specifies a name for the global buffer to be added.

-r: Specifies an RDAREA to assign.

-n: Specifies the number of buffer sectors for the global buffer.

(3) Example 3: Setting an RDAREA global buffer assignment

In this example, an added RDAREA (RDAREA1) is assigned to an existing global buffer (gbuf01).

pdbufmod -k add -a gbuf01 -r RDAREA1

Explanation

-k add: Specifies assignment of an RDAREA to an existing global buffer.

-a: Specifies the name of the target global buffer.

-r: Specifies the RDAREA to be assigned.

(4) Example 4: Changing an RDAREA global buffer assignment

In this example, the global buffer assignment of an RDAREA (RDAREA1) is changed from gbuf01 to gbuf02. Both gbuf01 and gbuf02 are existing global buffers.

pdbufmod -k add -a gbuf02 -r RDAREA1

Explanation

-k add: Specifies assignment of an RDAREA to an existing global buffer.

-a: Specifies the name of the target global buffer.

-r: Specifies the RDAREA to be assigned.

(5) Example 5: Deleting a global buffer

In this example, a global buffer (gbuf01) to which no RDAREA is assigned is deleted.

pdbufmod -k del -a gbuf01

Explanation

-k del: Specifies deletion of a global buffer.

-a: Specifies the name of the global buffer to be deleted.

(6) Example 6: Deleting a global buffer to which an RDAREA is assigned

In this example, a global buffer (gbuf01) to which an RDAREA (RDAREA1) is assigned is deleted.

pdhold -r RDAREA1 -c                              1
pdbufmod -k del -a gbuf01                         2

Explanation

The RDAREA is placed in shutdown status. Note, however, that this operation is not needed if gbuf01 is an index global buffer.

The global buffer is deleted.

(7) Example 7: Separating an RDAREA from a global buffer

In this example, an RDAREA (RDAREA1) is separated from a global buffer (gbuf01).

pdhold -r RDAREA1 -c                              1
pdbufmod -k del -r RDAREA1                        2

Explanation

The RDAREA is placed in shutdown status.

The RDAREA is separated from the global buffer.

(8) Example 8: Changing a global buffer definition

In this example, the number of buffer sectors comprising a global buffer (gbuf01) is changed from 1,000 to 2,000.

pdbufmod -k upd -a gbuf01 -n 2000

Explanation

-k upd: Specifies a change in a global buffer definition.

-a: Specifies the name of the global buffer whose definition is to be changed.

-n: Specifies the number of buffer sectors after the change.

The pdbufmod command can be used to change the following items:

Number of buffer sectors

Buffer size

Maximum number of concurrently executing prefetch processes

Maximum number of concurrent input pages

Updated input page rate during deferred write trigger

9.4 Changing the number of server processes

This section explains the procedures for changing the number of server processes. The following topics are covered:

Operands for specifying the number of server processes

Procedures for changing the number of server processes

Examples of operation when the number of server processes is changed

Organization of this section

(1) Operands for specifying the number of server processes

(2) Procedures for changing the number of server processes

(3) Examples of operation when the number of server processes is changed

(4) Notes (applicable to HiRDB/Parallel Server only)

(1) Operands for specifying the number of server processes

(a) Operands for specifying the maximum number of active processes

The maximum number of server processes that can be started by HiRDB (maximum number of active processes) is determined by the HiRDB system definition operands shown in Table 9-2.

Table 9-2 Operands for specifying the maximum number of active processes

Type of server | Definition type | Operand
Single server | System common definition | pd_max_users
Front-end server | System common definition | pd_max_users
Dictionary server | Dictionary server definition or server common definition | pd_max_dic_process¹
Back-end server | Back-end server definition or server common definition | pd_max_bes_process²

Notes

If there are multiple front-end servers, processing requests are sent from those servers to the dictionary server and back-end servers. This may result in a concentration of the number of processes that exceeds the value specifiable in the pd_max_users operand in the system common definition. The resulting concentration of processes is the product of the value specified in the pd_max_users operand number of front-end servers). Therefore, when multiple front-end servers are used, estimate a maximum number of processes appropriate to the concentration level of processing must be determined, and then the pd_max_dic_process and pd_max_bes_process operands can be specified.

Even when only one front-end server is used, if more operations related to RDAREAs or global buffers (pdbufls, pddbls, pdopen, pdclose, pdhold, and pdrels) are executed concurrently than the value of pd_max_users, processing exceeding the value of pd_max_users may be concentrated on the dictionary server. In this case also, the maximum number of processes appropriate to the concentration level of processing should be specified.

¹ When the pd_max_dic_process operand is omitted, the value of the pd_max_users operand in the system common definition is assumed.

² When the pd_max_bes_process operand is omitted, the value of the pd_max_users operand in the system common definition is assumed.

(b) Operand for specifying the number of resident processes

The number of server processes generated during HiRDB startup (that is, the number of resident processes) is determined by the value of the pd_process_count operand.

If there will be many processing requests in the system, setting the number of resident processes to a large value will enable all processing to be started immediately. If the number of resident processes is set to a small value and more processing requests are issued than there are resident processes, HiRDB will process the requests by starting as many server processes as possible up to the specified maximum number of active processes. In this case, processing cannot be started until these processes have started. However, when the number of resident processes is set to a larger value, more memory is required in order to keep server processes always active. Therefore, the number of resident processes should be set to an appropriate value taking into account the concentration level of processing and the required memory size.

(2) Procedures for changing the number of server processes

The following two methods are available for changing the number of server processes:

Changing with the pdchprc command

Changing with HiRDB system definitions

(a) Changing with the pdchprc command

You can use the pdchprc command to change the maximum number of active processes and the maximum number of resident processes. However, changing the number of processes with the pdchprc command is temporary; such a change remains in effect only until HiRDB is stopped or until the pdchprc command is executed again.

(b) Changing with HiRDB system definitions

You can also change the number of server processes by directly changing the values in the operands listed in Table 9-2 and in the pd_process_count operand. Note, however, that before you can change a value in an operand listed in Table 9-2, you must either terminate HiRDB normally or perform a planned termination. If you change a value in an operand shown in Table 9-2 after HiRDB has been terminated forcibly or after HiRDB has terminated abnormally, an error will occur when you attempt to restart HiRDB and HiRDB will not restart. This does not apply to changing only the value in the pd_process_count operand.

Use of the system reconfiguration command (pdchgconf command) enables you to modify HiRDB system definitions while HiRDB is running. Note that HiRDB Advanced High Availability must be installed in order to use this command. For details about changing HiRDB system definitions while HiRDB is running, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

(3) Examples of operation when the number of server processes is changed

The pdchprc command can be used during HiRDB operation to change temporarily the maximum number of active processes and the number of resident processes. Examples are provided below.

(a) Reducing the number of server processes for batch processing

After online applications have terminated, this example reduces temporarily the number of resident server processes during night-shift batch processing. Processing requests are issued concurrently during online application processing, but because there should be no such concurrent processing requests during night-shift batch processing, there is no need to keep many server processes active. It should be sufficient to activate only as many server processes as are required by night-shift batch processing.

Figure 9-2 shows the procedure for reducing the number of server processes for batch processing.

Figure 9-2 Reducing the number of server processes for batch processing

(b) Reduced system operation in a mutual system switchover environment

In a mutual system switchover environment, it is possible after system switchover occurs for multiple HiRDBs to be running on a single server machine, resulting in a temporary increase in memory usage. An increase in memory usage of this type can be minimized by using the pdchprc command to reduce the number of HiRDB server processes.

Figure 9-3 shows the procedure for achieving reduced system operation in a mutual system switching environment.

Figure 9-3 Reduced system operation in a mutual system switching environment

(4) Notes (applicable to HiRDB/Parallel Server only)

Problems may result if the pdchprc command is used to set the maximum number of server processes to 0. For example, when the maximum number of server processes is set to 0 for a front-end server that is located in the same unit as the system manager, the following utilities can no longer be executed:

Database structure modification utility

Database load utility

Database reorganization utility

Database condition analysis utility

Optimizing information collection utility

9.5 Handling an increase in the number of users

When the number of users increases, the values of the following operands should be increased:

pd_max_users

pd_max_server_process

We recommend you keep this point in mind during the discussion that follows. If you omit the pd_max_server_process operand, HiRDB automatically calculates a value for this operand.

Organization of this section

(1) Shared memory for HiRDB increases

(2) More HiRDB ports are used

(3) Fewer locked resources can be allocated within a unit

(4) More semaphores and semaphore identifiers are used (applicable to HiRDB/Single Server only)

(5) Synchronization point dump file and status file sizes increase

(6) Exceeding the number of users authorized at the time of the HiRDB purchase

(1) Shared memory for HiRDB increases

The size of the shared memory used by HiRDB increases, which may result in shared memory allocation errors. In such a case, the shmget() system call error is reported with the KFPO00113-E message. Appropriate action must be taken on the basis of this message.

If errno=22, increase the value of the shmmax, shminfo_shmmax, or SHMMAX OS system parameter.

If errno=12, add more memory or terminate another program.

For details on how to modify the OS system parameters, see the applicable OS manual. When a system parameter is modified, the new value does not take effect until the OS is rebooted.

For information on determining values for shared memory and semaphores, see the manual HiRDB Version 8 Installation and Design Guide.

(2) More HiRDB ports are used

As the number of users increases, the number of ports used by HiRDB also increases. If the number of ports becomes inadequate, processing may be interrupted or the communications processing of other programs may be affected adversely. The number of ports assigned automatically by the operating system depends of the OS, so you should check the network-related settings on each server machine. For details about the number of ports that HiRDB uses, see the manual HiRDB Version 8 Installation and Design Guide.

If the number of ports assigned automatically by the OS is inadequate, use the pd_registered_port operand to specify a range of port numbers to be used by HiRDB. For details, see 9.7 Specifying a range of port numbers for use in communication processing.

In addition, if the maximum number of concurrent connections is too large (if the value in the pd_max_users operand is too large), specify 1 in the PDTCPCONOPT operand in the client environment definition to reduce the number of ports used by UAPs when they connect to HiRDB. For details about the PDTCPCONOPT operand, see the manual HiRDB Version 8 UAP Development Guide.

(3) Fewer locked resources can be allocated within a unit

The number of locked resources that can be allocated within a unit is reduced, which may result in output of the KFPS00443-E message indicating a lock error. In such a case, the value of the pd_lck_pool_size operand should be increased in order to allocate a sufficient locked area.

(4) More semaphores and semaphore identifiers are used (applicable to HiRDB/Single Server only)

In the case of a HiRDB/Single Server, more semaphores and semaphore identifiers are used, which means that the semget() system call error is reported with the KFPS01815-E or KFPO00107-E message. Appropriate action must be taken on the basis of the message:

errno=22
Increase the value of the semmns, seminfo_semmns, or SEMMNS OS system parameter.

errno=28
Increase the value of semmni, seminfo_semmni, or SEMMNI OS system parameter.

In the case of a HiRDB/Parallel Server, an increased number of users has no effect on the number of semaphores or semaphore identifiers.

(5) Synchronization point dump file and status file sizes increase

The synchronization point dump file and status file sizes increase. For information on determining the sizes of synchronization point dump files and status files, see the manual HiRDB Version 8 Installation and Design Guide.

(6) Exceeding the number of users authorized at the time of the HiRDB purchase

If the number of users that were authorized at the time HiRDB was purchased is exceeded, HiRDB must be upgraded.

9.6 Accommodating clients that cannot connect to HiRDB (connection frame guarantee facility for client groups)

When the number of clients connected to HiRDB equals the value specified in the pd_max_users operand (maximum number of concurrent connections), new clients cannot be connected to HiRDBeven clients who need to execute important applications. In such a case, the connection frame guarantee facility for client groups should be used.

Organization of this section

(1) Connection frame guarantee facility for client groups

(2) User can define a desired client group

(3) Environment setup

(4) Notes

(5) Relationship to monitoring the resources utilization factor

(1) Connection frame guarantee facility for client groups

The clients who connect to HiRDB can be assigned to groups, and HiRDB connection frames are guaranteed for each client group. The following are the HiRDB-set client groups (the character strings in parentheses are the names of these client groups):

X/Open XA interface client group (XA)

This is a group for clients who use the X/Open XA interface to access HiRDB. Whether from a PC or a work station, if a client accesses HiRDB via the X/Open XA interface, the client belongs to the X/Open XA interface client group.

Distributed client group (DF)

This is a group for clients who use the distributed database facility to access HiRDB from other nodes. Whether from a PC or a work station, if a client accesses HiRDB using the distributed database facility, the client belongs to the distributed client group.

PC client group (PC)

This is a group for Windows and Linux clients.

WS client group (WS)

This is a group for UNIX clients.

Mainframe client group (MF)

This is a group for VOS3 clients.

Note

The character strings in parentheses designate the client group name.

Any client who belongs to a client group for which connection frames have been specified can establish connection to HiRDB until the guaranteed minimum connections count is reached, even though accesses to HiRDB are concentrated among clients belonging to other client groups. Figure 9-4 shows the connection frame guarantee facility for client groups.

Figure 9-4 Connection frame guarantee facility for client groups

(2) User can define a desired client group

The client groups listed above are defined by HiRDB. The user can also define up to 10 client groups:

(3) Environment setup

The following operands must be specified in order to use the connection frame guarantee facility for client groups:

pdcltgrp operand in the system common definition

PDCLTGRP operand in the client environment definition*

* This operand is used to define a user-specified client group.

The environment setup procedure is explained below by way of examples.

Example 1

Allocate 5 user connection frames for work station clients and 10 user connection frames for mainframe system clients.

Assume that pd_max_users=100 has been specified.

Specifications in the system common definition

pdcltgrp -g WS -u 5
pdcltgrp -g MF -u 10

Example 2

Set user-specified client groups, and allocate 5 user connection frames to group A and 15 user connection frames to groups B; assume that pd_max_users=100 has been specified:

Specifications in the system common definition

pdcltgrp -g A -u 5
pdcltgrp -g B -u 15

Client environment definition for group A

PDCLTGRP = A

Client environment definition for group B

PDCLTGRP = B

Example 3

Allocate 5 user connection frames to mainframe clients. Also set user-specified client groups and allocate 5 user connection frames to group A and 15 user connection frames to group B; assume that pd_max_users=100 has been specified:

Specifications in the system common definition

pdcltgrp -g MF -u 5
pdcltgrp -g A -u 5
pdcltgrp -g B -u 15

Client environment definition for group A

PDCLTGRP = A

Client environment definition for group B

PDCLTGRP = B

Note

If the values in the pdcltgrp operand and the PDCLTGRP operand do not match, the user-specified client group will be ignored.

(4) Notes

The number of free-usage frames should not be set too small. If there are too few such frames, a utility or UAP connection error may occur due to an excessive number of connected users.

Check that the sum of the guaranteed numbers of connected users specified with the -u option of the pdcltgrp operand does not exceed the value of the pd_max_users operand. If the value of the pd_max_users operand is exceeded, processing of HiRDB startups is discontinued.

A utility (except for the database definition utility) cannot belong to a client group.

A mainframe client cannot belong to a user-specified client group.

To specify an X/Open XA interface client group (XA), the HiRDB client's version must be one of the following:

04-05 (neither 05-00 nor 05-01 supports this specification)

05-02 or later

To specify a PC client group (PC) or work station client group (WS), the HiRDB client's version must be the following:

04-00 or later

(5) Relationship to monitoring the resources utilization factor

When the pd_max_users utilization factor is being monitored,* both the pd_max_users operand utilization factor and the free-usage frames utilization factor are monitored. There must be at least 10 free-usage frames.

* Applicable when either of the following operands is specified:

pd_watch_resource = AUTO

pd_max_users_wrn_pnt

The following example shows when error messages are to be output when the pd_max_users utilization factor is being monitored.

Example

This example specifies that the message is to be output when the pd_max_users utilization factor reaches 80%:

9.7 Specifying a range of port numbers for use in communication processing

The ports to be used for communication between a HiRDB server and a HiRDB client or between HiRDB servers are assigned automatically by the OS. If a large volume of communication occurs, a shortage of ports may interrupt communication processing or may have an adverse effect on the communication processing of other programs. To prevent such problems from occurring, it is possible to specify a range of port numbers to be used by HiRDB for communication processing.

It is not necessary to specify this facility if only a small number of ports will be used for communication processing. This facility is applicable to server-to-server communication, and will not necessarily be applicable to all processes under HiRDB. The port numbers assigned by the OS will be used for communication processing such as the processing of commands.

For the Linux versions of HiRDB, consider whether or not to specify a range of port numbers. For other OS versions of HiRDB, you do not need to specify a range of port numbers.

Organization of this section

(1) Number of ports used by HiRDB

(2) Specifying a port number range

(3) Notes

(1) Number of ports used by HiRDB

For details about the number of ports used by HiRDB, see the manual HiRDB Version 8 Installation and Design Guide.

(2) Specifying a port number range

Use the pd_registered_port operand to specify a range of port numbers.

(3) Notes

It is important to ensure that the port number specified in the pd_registered_port operand do not duplicate any of the following port numbers (if there is a duplication in port numbers, an error may occur and it will not be possible to start HiRDB):

Port number specified in the pd_name_port operand

Port number specified in the pd_service_port operand

Port number specified in the -p option of the pdunit operand

Port numbers registered in /etc/services

Port number specified in the PDCLTRCVPORT operand in the client environment definition (when the HiRDB client resides in the same server machine as the HiRDB server)

Port number being used by another program

If Y, C, or W is specified in the pd_registered_port_check operand, HiRDB checks the port numbers in 4 for any duplications. If N is specified in the pd_registered_port_check operand, HiRDB will not check port numbers, and the HiRDB administrator must make the check for duplicated port numbers.

Hint

In a multi-HiRDB environment, ensure that the range of reserved port numbers for each HiRDB (the range specified in the pd_registered_port operand) does not duplicate any other range of port numbers.

If the system switchover facility is used and multiple units exist on a single server machine, specify the pd_registered_port operand of the unit control information definition instead of the system common definition. Ensure that the range of reserved port numbers for each unit does not duplicate any other range of port numbers.pd_registered_port_level.

You can use operands to specify the target range for the HiRDB reserved port facility. For details, see the manual HiRDB Version 8 System Definition.

9.8 Changing the host name

Executor: HiRDB administrator

This section explains the procedure for changing the host name (changing the computer name) of HiRDB while it is active.

Procedure

Use the pdstop command to terminate HiRDB normally.

Change the pd_mode_conf operand.

Use the pdlogunld command to unload system logs.

Change the host name.

Restart the server machine.

Change HiRDB system definitions.

Initialize the system files.

Change the pd_mode_conf operand.

Use the pdstart command to start HiRDB normally.

The procedure step numbers above correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this section

(1) Use the pdstop command to terminate HiRDB normally

(2) Correct the pd_mode_conf operand

(3) Use the pdlogunld command to unload system logs

(4) Rename the host

(5) Reboot the server machine

(6) Change HiRDB system definitions

(7) Initialize the system files

(8) Change the pd_mode_conf operand

(9) Use the pdstart command to start HiRDB normally

(1) Use the pdstop command to terminate HiRDB normally

pdstop

(2) Correct the pd_mode_conf operand

If AUTO was specified in the pd_mode_conf operand, change the specification to MANUAL2.

(3) Use the pdlogunld command to unload system logs

Unload the system log files waiting to be unloaded. The status of system log files can be checked with the pdlogls command:

pdlogunld -d sys -g log01 -o /unld/unldlog01

(4) Rename the host

Rename the host (change the computer name).

(5) Reboot the server machine

Reboot the server machine.

In the case of an HiRDB/Parallel Server, reboot all server machines whose host has been renamed.

(6) Change HiRDB system definitions

Change the host name specified in the following operands in the HiRDB system definition:

-x option in pdunit operand

-x option in pdstart operand

pd_hostname operand

(7) Initialize the system files

Initialize the system log files, synchronization point dump files, and status files (delete them, then create them again). In the case of a HiRDB/Parallel Server, initialize all system files in the unit where the host name was changed.

pdlogrm -d sys -f /sysfile01/syslog1a                    1
pdloginit -d sys -f /sysfile01/syslog1a -n 5000          2
pdlogrm -d spd -f /sysfile01/sync1                       3
pdloginit -d spd -f /sysfile01/sync1 -n 5000             4
pdstsrm  -f /sysfile01/usts1a                            5
pdstsinit -f /sysfile01/usts1a -c 5000                   6
pdstsrm  -f /sysfile01/ssts1a                            7
pdstsinit -f /sysfile01/ssts1a -c 5000                   8

Explanation

Deletes system log files.

Re-creates system log files.

Deletes synchronization point dump file.

Re-creates synchronization point dump files.

Deletes unit status files.

Re-creates unit status files.

Deletes server status files.

Re-creates server status files.

(8) Change the pd_mode_conf operand

If the specification of the pd_mode_conf operand was changed to MANUAL2 in step (2), change it back to AUTO.

(9) Use the pdstart command to start HiRDB normally

pdstart

9.9 Changing the deadlock priority value for commands

This section explains how to change the deadlock priority value for the following commands:

pdhold -b (referencing-possible backup hold)

pdhold -s (synchronization hold)

pddbchg (replica status switching of a replica RDAREA)

pdorbegin (database commit after online reorganization)

pdorend (reflection processing after online reorganization)

Organization of this section

9.9.1 Deadlock priority value for commands

9.9.2 Environment assignment

9.9.3 Operation method

9.9.1 Deadlock priority value for commands

The deadlock priority value for commands is normally lower than the deadlock priority value for a UAP. Therefore, if deadlock occurs, it is the command that terminates in an error. To prevent commands from terminating in an error, you can set the deadlock priority value for commands to be higher than the deadlock priority value for a UAP. When you increase the command deadlock priority value, the error occurs in the transaction when deadlock occurs.

Organization of this subsection

(1) Commands for which the deadlock priority value can be changed

(2) List of deadlock priority values

(1) Commands for which the deadlock priority value can be changed

You can change the deadlock priority value for the following commands:

pdhold -b (referencing-possible backup hold)

pdhold -s (synchronization hold)

pddbchg (replica status switching of a replica RDAREA)

pdorbegin (database commit after online reorganization)

pdorend (reflection processing after online reorganization)

(2) List of deadlock priority values

Table 9-3 lists the deadlock priority values.

Table 9-3 Deadlock priority values

Type and condition | Deadlock priority value
UAP | Value of PDDLKPRIO in client environment definition | 96 | 96
64 | 64
32 | 32
Omitted | When X/Open XA interface is used | 96
When X/Open XA interface is not used and a distributed server is used for the distributed databases | 64
Utility | 64
Command | pdhold -b, pdhold -s, pddbchg, pdorbegin, pdorend | Value of pd_command_deadlock_priority*
Other commands | 64

* You can specify in this operand a deadlock priority value of 32, 64, 96, or 120. If this operand is omitted, the deadlock priority value is either 64 or 120 depending on the type of locked resource.

Reference note

A smaller deadlock priority value indicates a higher processing priority, and a larger deadlock priority value indicates a lower processing priority.

If two transactions have the same deadlock priority value, the first one that executes is accorded the higher priority.

9.9.2 Environment assignment

You specify the following operands to change the deadlock priority value for commands:

pd_deadlock_priority_use
Specifies whether or not the deadlock priority value for commands is to be changed. To change the deadlock priority value, specify Y.

pd_command_deadlock_priority
Specifies a deadlock priority value for commands. The values that can be specified are 32, 64, 96, and 120.

9.9.3 Operation method

Organization of this subsection

(1) Procedure for changing the deadlock priority value

(2) Operand specification example

(1) Procedure for changing the deadlock priority value

The following describes the procedure for changing the deadlock priority value:

Procedure

Check the deadlock priority value (value of the PDDLKPRIO operand in the client environment definition) of the transaction that may cause deadlock.

Specify Y in the pd_deadlock_priority_use operand.

Specify a deadlock priority value for commands in the pd_command_deadlock_priority operand.

Hint

The following are specification guidelines for the pd_command_deadlock_priority operand:

To cause an error in the transaction when deadlock occurs, ensure that the operand specification values satisfy the following condition:
value of pd_command_deadlock_priority < value of PDDLKPRIO

To cause an error in the command when deadlock occurs, ensure that the operand specification values satisfy the following condition:
value of pd_command_deadlock_priority > value of PDDLKPRIO

(2) Operand specification example

An example of specifying operands is provided for the following outcome:

When deadlock occurs between a transaction of UAP1 and a command, an error is to be caused in the transaction.

When deadlock occurs between a transaction of UAP2 and a command, an error is to be caused in UAP2.

Example of operand specifications:

Specifying the client environment definition for executing UAP1

PDDLKPRIO 32

Specifying the client environment definition for executing UAP2

PDDLKPRIO 96

Specifying the system common definition

pd_deadlock_priority_use = Y
pd_command_deadlock_priority = 64

10. Handling HiRDB File System Areas

This chapter explains the procedures for handling HiRDB file system areas and HiRDB files.

This chapter contains the following sections:

Organization of this chapter

10.1 Obtaining information about a HiRDB file system area

10.2 Creating (initializing) a HiRDB file system area

10.3 Backing up a HiRDB file system area

10.4 Restoring a HiRDB file system area

10.5 Deleting a HiRDB file system area

10.1 Obtaining information about a HiRDB file system area

Executor: HiRDB administrator

The commands shown in Table 10-1 can be used to obtain information about a HiRDB file system area.

Table 10-1 Commands used to display information about a HiRDB file system area

Command name
Purpose

pdfstatfs

To obtain the size of the HiRDB file system area

To obtain the amount of unused space in the HiRDB file system area

To obtain the number of HiRDB files created in the HiRDB file system area

To obtain the number of HiRDB files that can still be created in the HiRDB file system area

pdfls

To check the HiRDB files contained in the HiRDB file system area

To obtain the owner name, access privileges, record length, number of records, and update closure date and time of a HiRDB file

To obtain the lock status of a HiRDB file

For details on the information displayed by executing the pdfstatfs and pdfls commands, see the manual HiRDB Version 8 Command Reference.

10.2 Creating (initializing) a HiRDB file system area

This section explains how to create (initialize) a HiRDB file system area.

A character special file or a regular file can be used as a HiRDB file system area by initializing the file with the pdfmkfs command. Following is the procedure for creating a HiRDB file system area:

Procedure

Link the file name symbolically.

Change the owner and access privileges for the HiRDB file system area (applicable to character special files).

Initialize the HiRDB file system area.

Organization of this section

(1) Link the file name symbolically

(2) Change the owner and access privileges for the HiRDB file system area (applicable to character special files)

(3) Initialize the HiRDB file system area

(1) Link the file name symbolically

Executor: Superuser

It is recommended that the name of a HiRDB file system area be a name linked symbolically by the OS's ln command to the entity name of the character special file or regular file, rather than using the entity name itself. This simplifies the following operations:

Recovery of the HiRDB file system area onto a different hard disk in the event of a hard disk error

Modification of RDAREA structure

For information on the ln command, refer to the OS manual..

(2) Change the owner and access privileges for the HiRDB file system area (applicable to character special files)

Executor: Superuser

The owner and access privileges for the HiRDB file system area should be changed so that the file system area can be protected from access by unauthorized users.

Table 10-2 lists the owners and access privileges to be specified for a HiRDB file system area.

Table 10-2 Owners and access privileges to be set for HiRDB file system area

Owner or access privileges | Information to be set | Command to be executed*
Owner | User ID | HiRDB administrator | chown command
Group ID | HiRDB group | chgrp command
Access privileges | Owner | rw (both read and write permitted) | chmod command
Group | rw (both read and write permitted)
Other | (access not permitted)

* These are OS commands; see the OS manual.

(3) Initialize the HiRDB file system area

Executor: HiRDB administrator

The pdfmkfs command is used to initialize the character special file or regular file so that it can be used as a HiRDB file system area. For details on HiRDB file system area design guidelines, see the manual HiRDB Version 8 Installation and Design Guide.

Following is an example of executing the pdfmkfs command:

Example

pdfmkfs -n 25 -l 5 -k DB -e 5 /svr01DB001

Explanation

-n: Specifies in megabytes the size of the HiRDB file system area.

This size must not exceed the size of the partition; if it is larger than the partition size, the subsequent physical partition may be damaged.

-l: Specifies the maximum number of HiRDB files that can be created in the HiRDB file system area.

-k: Specifies the usage of the HiRDB file system area:

DB: HiRDB file system area for RDAREAs

SYS: HiRDB file system area for system files

WORK: HiRDB file system area for work table files

UTL: HiRDB file system area for utilities

SVR: HiRDB file system area for all purposes (except for utilities)

-e: Specifies the maximum number of secondary allocations for the HiRDB files.

/svr01DB001: Specifies a name for the HiRDB file system area (character special file or regular file) that is to be created. If this is a character special file, specify a symbolically linked name.

Duplicating the HiRDB file system area using a mirror disk

If the HiRDB file system area is to be duplicated using a mirror disk, the following should be done:

3050RX group or 3500/3xx
Specify in the pdfmkfs command the name of the character special file on the master disk (/dev/rdsk/rdskxxx) or the name linked symbolically to it.

3500 series (except 3500/3xx)
Specify in the pdfmkfs command the mirror special file name (/dev/mirror/rdskxxx) or the name linked symbolically to it.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

10.3 Backing up a HiRDB file system area

Executor: HiRDB administrator

The pdfbkup command is used to back up a HiRDB file system area. The pdfbkup command should be used in the following cases:

When a HiRDB file system area is to be defragmented

When attributes, such as the capacity of a HiRDB file system area and the number of files, are to be changed

When the contents of a HiRDB file system area should be stored in order to prepare for possible errors (backing up a database in units of HiRDB file system areas, rather than in units of RDAREAs)

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

10.4 Restoring a HiRDB file system area

Executor: HiRDB administrator

A HiRDB file system area can be restored from a backup copy created with the pdfbkup command. The pdfrstr command can be used to restore a HiRDB file system area in the following cases:

When a HiRDB file system area has been defragmented

When attributes, such as the capacity of a HiRDB file system area and the number of files, are to be changed

When it is necessary to restore a HiRDB file system area from a backup copy because of an error*

* To restore a database to the synchronization point immediately before the error, the HiRDB file system area must be restored and then the database recovery utility must be executed to restore the database using the unload log only.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

10.5 Deleting a HiRDB file system area

Executor: HiRDB administrator

Organization of this section

(1) Deleting a HiRDB file constituting an RDAREA

(2) Deleting a system file

(1) Deleting a HiRDB file constituting an RDAREA

The database structure modification utility (pdmod command) is used to delete a HiRDB file or to change the size of a HiRDB file that is a constituent of an RDAREA.

There is no need to terminate HiRDB to re-create a HiRDB file deleted by the database structure modification utility.

Notes

The pdfrm command must be used with caution because it deletes forcibly any specified HiRDB file regardless of the RDAREA structure.

The pdfrm command cannot be used during HiRDB operation to delete a HiRDB file in a HiRDB file system area that is in use by HiRDB. The pdfrm command should be used only after HiRDB has been terminated.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(2) Deleting a system file

The operation commands listed in Table 10-3 are used to delete system files.

Table 10-3 Commands used to delete system files

Command | Type of system file
pdlogrm -d sys | System log file
pdlogrm -d spd | Synchronization point dump file
pdstsrm | Status file

Notes

If a system file cannot be deleted with the applicable command shown in Table 10-3, the reason for the deletion failure should be determined. If it is safe to delete the file, the pdfrm command can be used.

A deleted HiRDB file can be re-created with an operation command without having to terminate HiRDB.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11. Modifying the System Configuration

This chapter explains how to modify the unit or server configuration of a HiRDB/Parallel Server. It also explains the procedures for migrating from a HiRDB/Single Server to a HiRDB/Parallel Server.

This chapter contains the following sections:

Organization of this chapter

11.1 Adding a unit

11.2 Removing a unit

11.3 Moving a unit

11.4 Adding a server

11.5 Removing a server

11.6 Moving a server

11.7 Migrating a HiRDB/Single Server to a HiRDB/Parallel Server

11.8 Migrating back-end servers for load balancing

11.1 Adding a unit

Executor: HiRDB administrator

This section explains how to add a unit to a HiRDB/Parallel Server.

Organization of this section

11.1.1 Adding a unit while HiRDB is running

11.1.2 Adding a unit while HiRDB is stopped

11.1.1 Adding a unit while HiRDB is running

Add unit 3 to a HiRDB/Parallel Server. The added unit contains a front-end server (FES3) and a back-end server (BES3). The procedure is detailed below.

Use of the system reconfiguration command (pdchgconf command) eliminates the need to terminate HiRDB normally. Note that HiRDB Advanced High Availability must be installed in order to use this command.

Organization of this subsection

(1) Deploy a new server machine

(2) Create updated HiRDB system definitions

(3) Use the pdloginit and pdstsinit commands to create the system files required for unit 3

(4) Use the pdconfchk command to check the updated HiRDB system definitions

(5) Use the pdchgconf command to modify the HiRDB system definitions

(6) Use the pdmod command to add or move RDAREAs

(7) Modify client environment definitions

(1) Deploy a new server machine

Deploy a new server machine, and install and set up HiRDB. For details about installing and setting up HiRDB, see the manual HiRDB Version 8 Installation and Design Guide.

Check that the following are the same as in your existing units:

HiRDB version

Addressing mode (32-bit or 64-bit mode)

POSIX library version installed/not installed

Character codes

Installation status of optional program products and related products

(2) Create updated HiRDB system definitions

Use the procedure explained below to create HiRDB system definitions that reflect the change in the unit configuration. If you plan to add or move RDAREAs as explained in step (6), update the global buffer definitions as well.

Procedure

Create a $PDDIR/conf/chgconf directory.

Copy the current HiRDB system definition files into the directory you created in step 1.

Modify the HiRDB system definitions that are in the $PDDIR/conf/chgconf directory.

Copy the HiRDB definition files in the $PDDIR/conf/chgconf directory to the $PDDIR/conf directory. Perform the operation in step 4 only for the server machine of the unit to be added.

Note

Do not change the pdstart operand value for a server in the existing units (units 1 and 2). If it is changed, you must take additional actions, such as initializing system files. For details about the actions to be taken when the pdstart operand value is changed, see the description of the pdstart operand in the manual HiRDB Version 8 System Definition.

(3) Use the pdloginit and pdstsinit commands to create the system files required for unit 3

pdloginit -d sys -s fes3 -f /sysarea/log01 -n 5000 -D         1
  :
pdloginit -d spd -s fes3 -f /sysarea/sync01 -n 5000 -D        2
  :
pdstsinit -s fes3 -f /sysarea/ssts01 -c 3000 -D               3
  :
pdstsinit -u UNT3 -f /sysarea/usts01 -c 3000 -D               4
  :

Explanation

Creates system log files for FES3 and BES3.

Creates synchronization point dump files for FES3 and BES3.

Creates server status files for FES3 and BES3.

Creates unit status files for unit 3.

Because these commands are executed in unit 3 rather than in unit 1 (system manager unit), the -D option must be specified for the pdloginit and pdstsinit commands.

(4) Use the pdconfchk command to check the updated HiRDB system definitions

pdconfchk -d chgconf

Check the HiRDB system definitions in the $PDDIR/conf/chgconf directory. If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(5) Use the pdchgconf command to modify the HiRDB system definitions

pdchgconf

Replace the HiRDB system definitions with the updated HiRDB system definitions.

(6) Use the pdmod command to add or move RDAREAs

If necessary, you can add or move RDAREAs to BES3. For details about adding RDAREAs, see 15.2 Creating an RDAREA (RDAREA addition); for details about moving RDAREAs, see 15.8 Moving an RDAREA (RDAREA migration).

If you did not modify the global buffer definitions in step (2), use the pdbufmod command to update the global buffers dynamically.

(7) Modify client environment definitions

If necessary, specify the following client environment definition operands for the front-end server (FES3) that you added:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.1.2 Adding a unit while HiRDB is stopped

Add unit 3 to a HiRDB/Parallel Server. The added unit contains a front-end server (FES3) and a back-end server (BES3). The procedure is detailed below.

Organization of this subsection

(1) Deploy a new server machine

(2) Use the pdstop command to stop HiRDB normally

(3) Modify HiRDB system definitions

(4) Use the pdloginit and pdstsinit commands to create the system files required for unit 3

(5) Use the pdconfchk command to check the HiRDB system definitions

(6) Use the pdstart command to start HiRDB normally

(7) Use the pdmod command to add or move RDAREAs

(8) Modify client environment definitions

(1) Deploy a new server machine

Deploy a new server machine, and install and set up HiRDB. For details about installing and setting up HiRDB, see the manual HiRDB Version 8 Installation and Design Guide.

Check that the following are the same as in your existing units:

HiRDB version

Addressing mode (32-bit or 64-bit mode)

POSIX library version installed/not installed

Character codes

Installation status of optional program products and related products

(2) Use the pdstop command to stop HiRDB normally

pdstop

Check that HiRDB terminates normally.

(3) Modify HiRDB system definitions

Create HiRDB system definitions that reflect the change in the unit configuration. If you plan to add or move RDAREAs as explained in step (7), update the global buffer definitions as well.

Note

Do not change the pdstart operand value for a server in the existing units (units 1 and 2). If it is changed, you must take additional actions, such as initializing system files. For details about the actions to be taken when the pdstart operand value is changed, see the description of the pdstart operand in the manual HiRDB Version 8 System Definition.

(4) Use the pdloginit and pdstsinit commands to create the system files required for unit 3

pdloginit -d sys -s fes3 -f /sysarea/log01 -n 5000          1
  :
pdloginit -d spd -s fes3 -f /sysarea/sync01 -n 5000         2
  :
pdstsinit -s fes3 -f /sysarea/ssts01 -c 3000                3
  :
pdstsinit -u UNT3 -f /sysarea/usts01 -c 3000                4
  :

Explanation

Creates system log files for FES3 and BES3.

Creates synchronization point dump files for FES3 and BES3.

Creates server status files for FES3 and BES3.

Creates unit status files for unit 3.

(5) Use the pdconfchk command to check the HiRDB system definitions

pdconfchk

If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(6) Use the pdstart command to start HiRDB normally

pdstart

(7) Use the pdmod command to add or move RDAREAs

If necessary, you can add or move RDAREAs to BES3. For details about adding RDAREAs, see 15.2 Creating an RDAREA (RDAREA addition); for details about moving RDAREAs, see 15.8 Moving an RDAREA (RDAREA migration).

(8) Modify client environment definitions

If necessary, specify the following client environment definition operands for the front-end server (FES3) that you added:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.2 Removing a unit

Executor: HiRDB administrator

This section explains how to remove a unit from a HiRDB/Parallel Server.

Organization of this section

11.2.1 Removing a unit while HiRDB is running

11.2.2 Removing a unit while HiRDB is stopped

11.2.1 Removing a unit while HiRDB is running

Remove unit 3 from a HiRDB/Parallel Server. The procedure is detailed below.

Use of the system reconfiguration command (pdchgconf command) eliminates the need to terminate HiRDB normally. Note that HiRDB Advanced High Availability must be installed in order to use this command.

Notes

You cannot remove a unit that contains the system manager or dictionary server.

You cannot remove a unit if there would be no more front-end servers.

You cannot remove a unit if there would be no more back-end servers.

Organization of this subsection

(1) Use the pdmod command to delete or move the RDAREAs of BES3

(2) Modify client environment definitions

(3) Create updated HiRDB system definitions

(4) Use the pdconfchk command to check the updated HiRDB system definitions

(5) Use the pdchgconf command to modify the HiRDB system definitions

(6) Use the pdlogrm and pdstsrm commands to delete the unit 3 system files

(1) Use the pdmod command to delete or move the RDAREAs of BES3

For details about deleting RDAREAs, see 15.6 Deleting an RDAREA; for details about moving RDAREAs, see 15.8 Moving an RDAREA (RDAREA migration).

(2) Modify client environment definitions

Check if the following operands of the client environment definitions are specified; if the front-end server (FES3) that you plan to remove is specified in these operands, change their values as appropriate:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

(3) Create updated HiRDB system definitions

Use the procedure explained below to create HiRDB system definitions that reflect the change in the unit configuration.

Procedure

Create a $PDDIR/conf/chgconf directory.

Copy the current HiRDB system definition files into the directory that you created in step 1.

Modify the HiRDB system definitions that are in the $PDDIR/conf/chgconf directory.

If you are using the HiRDB External Data Access facility

If a back-end server for connecting to foreign servers is in the unit to be removed, delete the definitions related to foreign servers. If you remove the unit without deleting the foreign server-related definitions, either the configuration change will fail or an error will occur when an attempt is made to access a table or an index stored in an RDAREA of the unit that was removed.

(4) Use the pdconfchk command to check the updated HiRDB system definitions

pdconfchk -d chgconf

Check the HiRDB system definitions in the $PDDIR/conf/chgconf directory. If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(5) Use the pdchgconf command to modify the HiRDB system definitions

pdchgconf

Replace the HiRDB system definitions with the updated HiRDB system definitions.

(6) Use the pdlogrm and pdstsrm commands to delete the unit 3 system files

pdlogrm -d sys -s fes3 -f /sysarea/log01 -D          1
  :
pdlogrm -d spd -s fes3 -f /sysarea/sync01 -D         2
  :
pdstsrm -s fes3 -f /sysarea/ssts01 -D                3
  :
pdstsrm -u UNT3 -f /sysarea/usts01  -D               4
  :

Explanation

Deletes the system log files for FES3 and BES3.

Deletes the synchronization point dump files for FES3 and BES3.

Deletes the server status files for FES3 and BES3.

Deletes the unit status files for unit 3.

Because these commands are executed in unit 3 rather than in unit 1 (system manager unit), the -D option must be specified for the pdloginit and pdstsinit commands.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.2.2 Removing a unit while HiRDB is stopped

Remove unit 3 from a HiRDB/Parallel Server. The procedure is detailed below.

Notes

Do not remove a unit containing the system manager or dictionary server.

Do not remove a unit if there would be no more front-end servers.

Do not remove a unit if there would be no more back-end servers.

Organization of this subsection

(1) Use the pdmod command to delete or move the RDAREAs of BES3

(2) Modify client environment definitions

(3) Use the pdstop command to stop HiRDB normally

(4) Use the pdlogrm and pdstsrm commands to delete the unit 3 system files

(5) Modify HiRDB system definitions

(6) Use the pdconfchk command to check the HiRDB system definitions

(7) Use the pdstart command to start HiRDB normally

(1) Use the pdmod command to delete or move the RDAREAs of BES3

For details about deleting RDAREAs, see 15.6 Deleting an RDAREA; for details about moving RDAREAs, see 15.8 Moving an RDAREA (RDAREA migration).

(2) Modify client environment definitions

Check if the following operands in the client environment definitions are specified; if the front-end server (FES3) that you plan to remove is specified in these operands, change their values as appropriate:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

(3) Use the pdstop command to stop HiRDB normally

pdstop

Check that HiRDB terminates normally.

(4) Use the pdlogrm and pdstsrm commands to delete the unit 3 system files

pdlogrm -d sys -s fes3 -f /sysarea/log01           1
  :
pdlogrm -d spd -s fes3 -f /sysarea/sync01          2
  :
pdstsrm -s fes3 -f /sysarea/ssts01                 3
  :
pdstsrm -u UNT3 -f /sysarea/usts01                 4
  :

Explanation

Deletes the system log files for FES3 and BES3.

Deletes the synchronization point dump files for FES3 and BES3.

Deletes the server status files for FES3 and BES3.

Deletes the unit status files for unit 3.

(5) Modify HiRDB system definitions

Create HiRDB system definitions that reflect the change in the unit configuration.

Note when the HiRDB External Data Access facility is used

If a unit to be deleted contains a back-end server for external connection, delete definitions about the external server. If the unit is deleted without deleting the external server-related definitions, the configuration change may fail or an attempt to access a table or index stored in an RDAREA on the unit to be deleted will result in an error.

(6) Use the pdconfchk command to check the HiRDB system definitions

pdconfchk

If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(7) Use the pdstart command to start HiRDB normally

pdstart

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.3 Moving a unit

Executor: HiRDB administrator

This section explains how to move a unit within a HiRDB/Parallel Server.

Note

If a heterogeneous system configuration is employed and a unit containing a back-end server is to be moved, observe the following rule:

Make sure that the same platform is used at the server machines before and after moving the unit containing the back-end server. Do not move a unit to a different platform.

Organization of this section

11.3.1 Moving a unit while HiRDB is running

11.3.2 Moving a unit while HiRDB is stopped

11.3.1 Moving a unit while HiRDB is running

Move a unit of a HiRDB/Parallel Server. The procedure is detailed below.

Use of the system reconfiguration command (pdchgconf command) eliminates the need to terminate HiRDB normally. Note that HiRDB Advanced High Availability must be installed in order to use this command.

Notes

You cannot move a system manager unit.

The disk on which you create the system files and the RDAREAs for the unit to be moved must be shared by means of a SAN or other storage network system between both the current server machine and the new server machine.

You can move a unit only if you are using the HP-UX or AIX version of HiRDB. This is because OS commands must be used during the configuration change to disconnect and connect the shared disk, which means that units can be moved only on operating systems that provide such commands (HP-UX and AIX).

Organization of this subsection

(1) Deploy a new server machine

(2) Prepare shells for disconnecting and connecting the shared disk

(3) Create updated HiRDB system definitions

(4) Use the pdconfchk command to check the updated HiRDB system definitions

(5) Use the pdchgconf command to modify the HiRDB system definitions

(6) Modify client environment definitions

(1) Deploy a new server machine

Deploy a new server machine, and install and set up HiRDB. For details about installing and setting up HiRDB, see the manual HiRDB Version 8 Installation and Design Guide.

Check that the following are the same as in your existing units:

HiRDB version

Addressing mode (32-bit or 64-bit mode)

POSIX library version installed/not installed

Character codes

Installation status of optional program products and related products

(2) Prepare shells for disconnecting and connecting the shared disk

Prepare the shells from which you will disconnect and connect the shared disk. Execute the shells as a superuser. For safety's sake, do not include in these shells any commands other than commands for disconnecting and connecting the disk.

Shell on current server machine

Create a shell ($PDDIR/conf/chgconf/diskdiscon.sh) containing the command for disconnecting the disk storing the system files and RDAREAs from the current server machine. The following shows an example on HP-UX:

/usr/sbin/vgchange -a n device-name

Shell on new server machine

Create a shell ($PDDIR/conf/chgconf/diskcon.sh) containing the command for connecting the disk storing the system files and RDAREAs onto the new server machine. The following shows an example on HP-UX:

/usr/sbin/vgchange -a y device-name

(3) Create updated HiRDB system definitions

Use the procedure explained below to create HiRDB system definitions that reflect the change in the unit configuration.

Procedure

Create a $PDDIR/conf/chgconf directory.

Copy the current HiRDB system definition files into the directory that you created in step 1.

Modify the HiRDB system definitions that are in the $PDDIR/conf/chgconf directory.

(4) Use the pdconfchk command to check the updated HiRDB system definitions

pdconfchk -d chgconf

Check the HiRDB system definitions in the $PDDIR/conf/chgconf directory. If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(5) Use the pdchgconf command to modify the HiRDB system definitions

pdchgconf

Replace the HiRDB system definitions with the updated HiRDB system definitions. At this time, the shells that you created in step (2) for disconnecting and connecting the disk are executed.

Note

If system reconfiguration processing fails, the pdchgconf command may end in an error without replacing the HiRDB system definitions. If the pdchgconf command ends in an error, check the files in the $PDDIR/conf directory.

(6) Modify client environment definitions

Check if the following operands in the client environment definitions are specified; if the front-end server (FES1) that you moved is specified in these operands, change their values as appropriate:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.3.2 Moving a unit while HiRDB is stopped

Move a unit of a HiRDB/Parallel Server. The procedure is detailed below.

Note

Because moving the system manager unit has far-ranging effects, we recommend that you do not move the system manager unit.

Organization of this subsection

(1) Deploy a new server machine

(2) Use the pdrorg command to unload the table data on BES1, one RDAREA at a time

(3) Use the pdstop command to stop HiRDB normally

(4) Use the pdlogls command to check the status of the system log files in the source unit

(5) Use the pdlogunld command to unload any system log files in unload wait status

(6) Use the pdlogrm and pdstsrm commands to delete the system files in the source unit

(7) Modify HiRDB system definitions

(8) Use the pdloginit and pdstsinit commands to create the system files needed for the target unit

(9) Use the pdconfchk command to check the HiRDB system definitions

(10) Use the pdstart command to start HiRDB normally

(11) Use the pdcopy command to back up all RDAREAs

(12) Use the pdmod command to re-initialize the RDAREAs in the target unit

(13) Use the pdrorg command to reload the table data in the target unit, one RDAREA at a time

(14) Use the pdcopy command to back up all RDAREAs

(15) Modify client environment definitions

(1) Deploy a new server machine

Deploy a new server machine, and install and set up HiRDB. For details about installing and setting up HiRDB, see the manual HiRDB Version 8 Installation and Design Guide.

Check that the following are the same as in your existing units:

HiRDB version

Addressing mode (32-bit or 64-bit mode)

POSIX library version installed/not installed

Character codes

Installation status of optional program products and related products

(2) Use the pdrorg command to unload the table data on BES1, one RDAREA at a time

For details about unloading table data on a per-RDAREA basis, see the manual HiRDB Version 8 Command Reference.

(3) Use the pdstop command to stop HiRDB normally

pdstop

Check that HiRDB terminates normally.

(4) Use the pdlogls command to check the status of the system log files in the source unit

pdlogls -d sys -s bes1

(5) Use the pdlogunld command to unload any system log files in unload wait status

pdlogunld -d sys -s bes1 -g log01 -o /unld/unldlog01

(6) Use the pdlogrm and pdstsrm commands to delete the system files in the source unit

pdlogrm -d sys -s fes1 -f /sysarea/log01           1
  :
pdlogrm -d spd -s fes1 -f /sysarea/sync01          2
  :
pdstsrm -s fes1 -f /sysarea/ssts01                 3
  :
pdstsrm -u UNT1 -f /sysarea/usts01                 4
  :

Explanation

Deletes the system log files (for FES1 and BES1) in the source unit.

Deletes the synchronization point dump files (for FES1 and BES1) in the source unit.

Deletes the server status files (for FES1 and BES1) in the source unit.

Deletes the unit control files in the source unit.

(7) Modify HiRDB system definitions

Create HiRDB system definitions that reflect the changes in the unit configuration.

(8) Use the pdloginit and pdstsinit commands to create the system files needed for the target unit

pdloginit -d sys -s fes1 -f /sysarea/log01 -n 5000          1
  :
pdloginit -d spd -s fes1 -f /sysarea/sync01 -n 5000         2
  :
pdstsinit -s fes1 -f /sysarea/ssts01 -c 3000                3
  :
pdstsinit -u UNT1 -f /sysarea/usts01 -c 3000                4
  :

Explanation

Creates system log files for FES1 and BES1.

Creates synchronization point dump files for FES1 and BES1.

Creates server status files for FES1 and BES1.

Creates unit status files for unit 1.

(9) Use the pdconfchk command to check the HiRDB system definitions

pdconfchk

If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(10) Use the pdstart command to start HiRDB normally

pdstart

(11) Use the pdcopy command to back up all RDAREAs

For details about making backups, see 6.4 Examples of backup.

(12) Use the pdmod command to re-initialize the RDAREAs in the target unit

For details about re-initializing RDAREAs, see 15.4 Increasing the size of an RDAREA or modifying its attributes (RDAREA reinitialization).

(13) Use the pdrorg command to reload the table data in the target unit, one RDAREA at a time

Use the unload data file that you created in step (2) as input data. For details about reloading on a per-RDAREA basis, see the manual HiRDB Version 8 Command Reference.

(14) Use the pdcopy command to back up all RDAREAs

For details about making backups, see 6.4 Examples of backup.

(15) Modify client environment definitions

Check if the following operands in the client environment definitions are specified; if the front-end server (FES1) that you moved is specified in these operands, change their values as appropriate:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.4 Adding a server

Executor: HiRDB administrator

This section explains how to add a server to a HiRDB/Parallel Server.

Organization of this section

11.4.1 Adding a server while HiRDB is running

11.4.2 Adding a server while HiRDB is stopped

11.4.1 Adding a server while HiRDB is running

Add a front-end server (FES3) and a back-end server (BES3) to unit 3. The procedure is detailed below.

Use of the system reconfiguration command (pdchgconf command) eliminates the need to terminate HiRDB normally. Note that HiRDB Advanced High Availability must be installed in order to use this command.

Organization of this subsection

(1) Check the memory requirements for unit 3

(2) Create updated HiRDB system definitions

(3) Use the pdloginit and pdstsinit commands to create the system files required for FES3 and BES4

(4) Use the pdconfchk command to check the updated HiRDB system definitions

(5) Use the pdchgconf command to modify the HiRDB system definitions

(6) Use the pdmod command to add or move RDAREAs

(7) Modify client environment definitions

(1) Check the memory requirements for unit 3

To add the servers, you must re-estimate the memory requirements for unit 3. You may also need to modify operating system parameters of the OS. For details about memory requirements and evaluating operating system parameters, see the manual HiRDB Version 8 Installation and Design Guide.

Note that you must restart the OS for changes to operating system parameters to take effect, which means that HiRDB must be terminated normally. In this example, we assume that there are no operating system parameters to be changed.

(2) Create updated HiRDB system definitions

Use the procedure explained below to create HiRDB system definitions that reflect the change in the server configuration. If you plan to add or move RDAREAs as explained in step (6), update the global buffer definitions as well.

Procedure

Create a $PDDIR/conf/chgconf directory.

Copy the current HiRDB system definition files into the directory you created in step 1.

Modify the HiRDB system definitions that are in the $PDDIR/conf/chgconf directory.

(3) Use the pdloginit and pdstsinit commands to create the system files required for FES3 and BES4

pdloginit -d sys -s fes3 -f /sysarea/log01 -n 5000 -D         1
  :
pdloginit -d spd -s fes3 -f /sysarea/sync01 -n 5000 -D        2
  :
pdstsinit -s fes3 -f /sysarea/ssts01 -c 3000 -D               3
  :

Explanation

Creates system log files for FES3 and BES4.

Creates synchronization point dump files for FES3 and BES4.

Creates server status files for FES3 and BES4.

Because these commands are executed in unit 3 rather than in unit 1 (system manager unit), the -D option must be specified for the pdloginit and pdstsinit commands.

(4) Use the pdconfchk command to check the updated HiRDB system definitions

pdconfchk -d chgconf

Check the HiRDB system definitions in the $PDDIR/conf/chgconf directory. If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(5) Use the pdchgconf command to modify the HiRDB system definitions

pdchgconf

Replace the HiRDB system definitions with the updated HiRDB system definitions.

(6) Use the pdmod command to add or move RDAREAs

If necessary, you can add or move RDAREAs to BES4. For details about adding RDAREAs, see 15.2 Creating an RDAREA (RDAREA addition); for details about moving RDAREAs, see 15.8 Moving an RDAREA (RDAREA migration).

If you did not modify the global buffer definitions in step (2), use the pdbufmod command to update the global buffers dynamically.

(7) Modify client environment definitions

If necessary, specify the following operands in the client environment definitions for the front-end server (FES3) that you added:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.4.2 Adding a server while HiRDB is stopped

Add a front-end server (FES3) and a back-end server (BES4) to unit 3. The procedure is detailed below.

Organization of this subsection

(1) Check the memory requirements for unit 3

(2) Use the pdstop command to stop HiRDB normally

(3) Use the pdlogls command to check the status of the system log files in unit 3

(4) Use the pdlogunld command to unload any system log files in unload wait status

(5) Use pdlogrm and pdstsrm commands to delete the system files required for unit 3

(6) Modify HiRDB system definitions

(7) Use the pdloginit and pdstsinit commands to create the system files required for unit 3

(8) Use the pdconfchk command to check the HiRDB system definitions

(9) Use the pdstart command to start HiRDB normally

(10) Use the pdmod command to add or move RDAREAs

(11) Modify client environment definitions

(1) Check the memory requirements for unit 3

To add the servers, you must re-estimate the memory requirements for unit 3. You may also need to modify operating system parameters of the OS. For details about memory requirements and evaluating operating system parameters, see the manual HiRDB Version 8 Installation and Design Guide.

(2) Use the pdstop command to stop HiRDB normally

pdstop

Check that HiRDB terminates normally.

(3) Use the pdlogls command to check the status of the system log files in unit 3

pdlogls -d sys -s bes3

(4) Use the pdlogunld command to unload any system log files in unload wait status

pdlogunld -d sys -s bes3 -g log01 -o /unld/unldlog01

If you decide not to unload the system logs, use the pdcopy command to back up all RDAREAs. For details about making backups, see 6.4 Examples of backup.

(5) Use pdlogrm and pdstsrm commands to delete the system files required for unit 3

pdlogrm -d sys -s bes3 -f /sysarea/log01           1
  :
pdlogrm -d spd -s bes3 -f /sysarea/sync01          2
  :
pdstsrm -s bes3 -f /sysarea/ssts01                 3
  :
pdstsrm -u UNT3 -f /sysarea/usts01                 4
  :

Explanation

Deletes system log files for BES3.

Deletes synchronization point dump files for BES3.

Deletes server status files for BES3.

Deletes unit status files for unit 3.

(6) Modify HiRDB system definitions

Create HiRDB system definitions that reflect the changes in the server configuration. If you plan to add or move RDAREAs in step (10), also modify the global buffer definitions.

(7) Use the pdloginit and pdstsinit commands to create the system files required for unit 3

pdloginit -d sys -s fes3 -f /sysarea/log01 -n 5000          1
  :
pdloginit -d spd -s fes3 -f /sysarea/sync01 -n 5000         2
  :
pdstsinit -s fes3 -f /sysarea/ssts01 -c 3000                3
  :
pdstsinit -u UNT3 -f /sysarea/usts01 -c 3000                4
  :

Explanation

Creates system log files for FES3, BES3, and BES4.

Creates synchronization point dump files for FES3, BES3, and BES4.

Creates server status files for FES3, BES3, and BES4.

Creates unit status files for unit 3.

Because you re-create the status files, the error shutdown status of RDAREAs is not inherited. If necessary, use the pdhold command to place RDAREAs in shutdown status again.

(8) Use the pdconfchk command to check the HiRDB system definitions

pdconfchk

If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(9) Use the pdstart command to start HiRDB normally

pdstart

(10) Use the pdmod command to add or move RDAREAs

If necessary, you can add or move RDAREAs to BES4. For details about adding RDAREAs, see 15.2 Creating an RDAREA (RDAREA addition); for details about moving RDAREAs, see 15.8 Moving an RDAREA (RDAREA migration).

(11) Modify client environment definitions

If necessary, specify the following operands in the client environment definitions for the front-end server (FES3) that you added:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.5 Removing a server

Executor: HiRDB administrator

This section explains how to remove a server from a HiRDB/Parallel Server.

Organization of this section

11.5.1 Removing a server while HiRDB is running

11.5.2 Removing a server while HiRDB is stopped

11.5.1 Removing a server while HiRDB is running

Remove a front-end server (FES3) and a back-end server (BES3) from a HiRDB/Parallel Server. The procedure is detailed below.

Use of the system reconfiguration command (pdchgconf command) eliminates the need to terminate HiRDB normally. Note that HiRDB Advanced High Availability must be installed in order to use this command.

Notes

You cannot remove the system manager or dictionary server.

You cannot remove a front-end server if there would be no more front-end servers.

You cannot remove a back-end server if there would be no more back-end servers.

Organization of this subsection

(1) Use the pdmod command to delete or move the RDAREAs of BES4

(2) Modify client environment definitions

(3) Create updated HiRDB system definitions

(4) Use the pdconfchk command to check the updated HiRDB system definitions

(5) Use the pdchgconf command to modify the HiRDB system definitions

(6) Use the pdlogrm and pdstsrm commands to delete the FES3 and BES4 system files

(1) Use the pdmod command to delete or move the RDAREAs of BES4

For details about deleting RDAREAs, see 15.6 Deleting an RDAREA; for details about moving RDAREAs, see 15.8 Moving an RDAREA (RDAREA migration).

(2) Modify client environment definitions

Check if the following operands in the client environment definitions are specified; if the front-end server (FES3) that you plan to remove is specified in these operands, change their values as appropriate:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

(3) Create updated HiRDB system definitions

Use the procedure explained below to create HiRDB system definitions that reflect the change in the server configuration.

Procedure

Create a $PDDIR/conf/chgconf directory.

Copy the current HiRDB system definition files into the directory that you created in step 1.

Modify the HiRDB system definitions that are in the $PDDIR/conf/chgconf directory.

If you are using the HiRDB External Data Access facility

If you plan to remove a back-end server for connecting to foreign servers, delete the definitions related to foreign servers. If you remove the server without deleting the foreign server-related definitions, either the configuration change will fail or an error will occur when an attempt is made to access a table or an index stored in an RDAREA of the server that was removed.

(4) Use the pdconfchk command to check the updated HiRDB system definitions

pdconfchk -d chgconf

Check the HiRDB system definitions in the $PDDIR/conf/chgconf directory. If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(5) Use the pdchgconf command to modify the HiRDB system definitions

pdchgconf

Replace the HiRDB system definitions with the updated HiRDB system definitions.

(6) Use the pdlogrm and pdstsrm commands to delete the FES3 and BES4 system files

pdlogrm -d sys -s fes3 -f /sysarea/log01 -D          1
  :
pdlogrm -d spd -s fes3 -f /sysarea/sync01 -D         2
  :
pdstsrm -s fes3 -f /sysarea/ssts01 -D                3
  :

Explanation

Deletes the system log files for FES3 and BES4.

Deletes the synchronization point dump files for FES3 and BES4.

Deletes the server status files for FES3 and BES4.

Because these commands are executed in unit 3 rather than in unit 1 (system manager unit), the -D option must be specified in the pdloginit and pdstsinit commands.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.5.2 Removing a server while HiRDB is stopped

Remove a front-end server (FES3) and a back-end server (BES3) from a HiRDB/Parallel Server. The procedure is detailed below.

Notes

Do not remove the system manager or dictionary server manager.

Do not remove a front-end server if there would be no more front-end servers.

Do not remove a back-end server if there would be no more back-end servers.

Organization of this subsection

(1) Use the pdmod command to delete or move the RDAREAs of BES4

(2) Modify client environment definitions

(3) Use the pdstop command to stop HiRDB normally

(4) Use the pdlogls command to check the status of the system log files in unit 3

(5) Use the pdlogunld command to unload any system log files in unload wait status

(6) Use the pdlogrm and pdstsrm commands to delete the unit 3 system files

(7) Change the HiRDB system definition

(8) Use the pdloginit and pdstsinit commands to create the system files needed for unit 3

(9) Use the pdconfchk command to check the HiRDB system definitions

(10) Use the pdstart command to start HiRDB normally

(1) Use the pdmod command to delete or move the RDAREAs of BES4

For details about deleting RDAREAs, see 15.6 Deleting an RDAREA; for details about moving RDAREAs, see 15.8 Moving an RDAREA (RDAREA migration).

(2) Modify client environment definitions

Check if the following operands in the client environment definitions are specified; if the front-end server (FES3) that you plan to remove is specified in these operands, change their values as appropriate:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

(3) Use the pdstop command to stop HiRDB normally

pdstop

Check that HiRDB terminates normally.

(4) Use the pdlogls command to check the status of the system log files in unit 3

pdlogls -d sys -s bes3

(5) Use the pdlogunld command to unload any system log files in unload wait status

pdlogunld -d sys -s bes3 -g log01 -o /unld/unldlog01

(6) Use the pdlogrm and pdstsrm commands to delete the unit 3 system files

pdlogrm -d sys -s fes3 -f /sysarea/log01            1
  :
pdlogrm -d spd -s fes3 -f /sysarea/sync01           2
  :
pdstsrm -s fes3 -f /sysarea/ssts01                  3
  :
pdstsrm -u UNT3 -f /sysarea/usts01                  4
  :

Explanation

Deletes the system log files for FES3, BES3, and BES4.

Deletes the synchronization point dump files for FES3, BES3, and BES4.

Deletes the server status files for FES3, BES3, and BES4.

Deletes the unit status files for unit 3.

(7) Change the HiRDB system definition

Create HiRDB system definitions that reflect the changes in the server configuration.

Note when the HiRDB External Data Access facility is used

If a back-end server for external server connection is deleted, delete definitions about the external server. If the unit is deleted without deleting the external server-related definitions, the configuration change may fail or an attempt to access a table or index stored in an RDAREA on the unit to be deleted will result in an error.

(8) Use the pdloginit and pdstsinit commands to create the system files needed for unit 3

pdloginit -d sys -s bes3 -f /sysarea/log01 -n 5000          1
  :
pdloginit -d spd -s bes3 -f /sysarea/sync01 -n 5000         2
  :
pdstsinit -s bes3 -f /sysarea/ssts01 -c 3000                3
  :
pdstsinit -u UNT3 -f /sysarea/usts01 -c 3000                4
  :

Explanation

Creates system log files for BES3.

Creates synchronization point dump files for BES3.

Creates server status files for BES3.

Creates unit status files for unit 3.

Because you re-created the status files, the error shutdown status of the RDAREAs is not inherited. If necessary, use the pdhold command to place RDAREAs in shutdown status again.

(9) Use the pdconfchk command to check the HiRDB system definitions

pdconfchk

If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(10) Use the pdstart command to start HiRDB normally

pdstart

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.6 Moving a server

Executor: HiRDB administrator

This section explains how to move a server within a HiRDB/Parallel Server.

Note

If a heterogeneous system configuration is employed and a back-end server is to be moved, observe the following rule:

Make sure that the same platform is used at the server machines before and after moving the back-end server. Do not move a back-end server to a different platform.

Organization of this section

11.6.1 Moving a server while HiRDB is running

11.6.2 Moving a server while HiRDB is stopped

11.6.1 Moving a server while HiRDB is running

Move a HiRDB/Parallel Server front-end server (FES1) and back-end server (BES1). The procedure is detailed below.

Use of the system reconfiguration command (pdchgconf command) eliminates the need to terminate HiRDB normally. Note that HiRDB Advanced High Availability must be installed in order to use this command.

Notes

You cannot move a system manager.

The disk on which you create the system files and the RDAREAs for the server to be moved must be shared by means of a SAN or other storage network system between both the current server machine and the new server machine.

You can move a server only if you are using the HP-UX or AIX versions of HiRDB. This is because OS commands must be used during the configuration change to disconnect and connect the shared disk, which means that servers can be moved only on operating systems that provide such commands (HP-UX and AIX).

Organization of this subsection

(1) Determine the memory requirements for unit 2

(2) Prepare shells for disconnecting and connecting the shared disk

(3) Create updated HiRDB system definitions

(4) Use the pdconfchk command to check the updated HiRDB system definitions

(5) Use the pdchgconf command to modify the HiRDB system definitions

(6) Modify client environment definitions

(1) Determine the memory requirements for unit 2

To move the servers, you must re-estimate the memory requirements for unit 2. You may also need to modify operating system parameters of the OS. For details about memory requirements and evaluating operating system parameters, see the manual HiRDB Version 8 Installation and Design Guide.

Note that you must restart the OS for changes to operating system parameters to take effect, which means that HiRDB must be terminated normally. In this example, we assume no operating system parameters are to be changed.

(2) Prepare shells for disconnecting and connecting the shared disk

Prepare the shells from which you will disconnect and connect the shared disk. Execute the shells as a superuser. For safety's sake, do not include in these shells any commands other than commands for disconnecting and connecting the disk.

Shell on current server machine

Create a shell ($PDDIR/conf/chgconf/diskdiscon.sh) containing the command for disconnecting the disk storing the system files and RDAREAs from the current server machine. The following shows an example on HP-UX:

/usr/sbin/vgchange -a n device-name

Shell on new server machine

Create a shell ($PDDIR/conf/chgconf/diskcon.sh) containing the command for connecting the disk storing the system files and RDAREAs onto the new server machine. The following shows an example on HP-UX:

/usr/sbin/vgchange -a y device-name

(3) Create updated HiRDB system definitions

Use the procedure explained below to create HiRDB system definitions that reflect the change in the server configuration.

Procedure

Create a $PDDIR/conf/chgconf directory.

Copy the current HiRDB system definition files into the directory that you created in step 1.

Modify the HiRDB system definitions that are in the $PDDIR/conf/chgconf directory.

(4) Use the pdconfchk command to check the updated HiRDB system definitions

pdconfchk -d chgconf

Check the HiRDB system definitions in the $PDDIR/conf/chgconf directory. If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(5) Use the pdchgconf command to modify the HiRDB system definitions

pdchgconf

Replace the HiRDB system definitions with the updated HiRDB system definitions. At this time, the shells that you created in step (1) for disconnecting and connecting the disk are executed.

Note

If system reconfiguration processing fails, the pdchgconf command may end in an error without replacing the HiRDB system definitions. If the pdchgconf command ends in an error, check the connection state of the disks and the files in the $PDDIR/conf directory.

(6) Modify client environment definitions

Check if the following operands in the client environment definitions are specified; if the front-end server (FES1) that you moved is specified in these operands, change their values as appropriate:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.6.2 Moving a server while HiRDB is stopped

Move a HiRDB/Parallel Server front-end server (FES1) and back-end server (BES1). The procedure is detailed below.

Note

Because moving the system manager has far-ranging effects, we recommend that you do not move the system manager.

Organization of this subsection

(1) Determine the memory requirements for unit 2

(2) Use the pdrorg command to unload the table data on BES1, one RDAREA at a time

(3) Use the pdstop command to stop HiRDB normally

(4) Use the pdlogls command to check the status of the system log files in unit 1

(5) Use the pdlogunld command to unload any system log files in unload wait status

(6) Use the pdlogrm and pdstsrm commands to delete all system files from units 1 and 2

(7) Change the HiRDB system definition

(8) Use the pdloginit and pdstsinit commands to create the system files required for units 1 and 2

(9) Use the pdconfchk command to check the HiRDB system definitions

(10) Use the pdstart command to start HiRDB normally

(11) Use the pdcopy command to back up all RDAREAs

(12) Use the pdmod command to re-initialize the RDAREAs on BES1

(13) Use the pdrorg command to reload the table data in the unit that was moved, one RDAREA at a time

(14) Use the pdcopy command to back up all RDAREAs

(15) Modify client environment definitions

(1) Determine the memory requirements for unit 2

To move the servers, you must re-estimate the memory requirements for unit 2. You may also need to modify operating system parameters of the OS. For details about memory requirements and evaluating operating system parameters, see the manual HiRDB Version 8 Installation and Design Guide.

(2) Use the pdrorg command to unload the table data on BES1, one RDAREA at a time

For details about unloading table data on a per-RDAREA basis, see the manual HiRDB Version 8 Command Reference.

(3) Use the pdstop command to stop HiRDB normally

pdstop

Check that HiRDB terminates normally.

(4) Use the pdlogls command to check the status of the system log files in unit 1

pdlogls -d sys -s bes1
pdlogls -d sys -s bes2

(5) Use the pdlogunld command to unload any system log files in unload wait status

pdlogunld -d sys -s bes1 -g log01 -o /unld/unldlog01
pdlogunld -d sys -s bes2 -g log02 -o /unld/unldlog02

If you decide not to unload the system logs, use the pdcopy command to back up all RDAREAs. For details about making backups, see 6.4 Examples of backup.

(6) Use the pdlogrm and pdstsrm commands to delete all system files from units 1 and 2

pdlogrm -d sys -s fes1 -f /sysarea/log01           1
  :
pdlogrm -d spd -s fes1 -f /sysarea/sync01          2
  :
pdstsrm -s fes1 -f /sysarea/ssts01                 3
  :
pdstsrm -u UNT1 -f /sysarea/usts01                 4
  :

Explanation

Deletes the system log files for FES1, and BES1 to BES3.

Deletes the synchronization point dump files for FES1, and BES1 to BES3.

Deletes the server status files for FES1, and BES1 to BES3.

Deletes the unit status files for units 1 and 2.

(7) Change the HiRDB system definition

Create HiRDB system definitions that reflect the change in the server configuration.

(8) Use the pdloginit and pdstsinit commands to create the system files required for units 1 and 2

pdloginit -d sys -s fes1 -f /sysarea/log01 -n 5000          1
  :
pdloginit -d spd -s fes1 -f /sysarea/sync01 -n 5000         2
  :
pdstsinit -s fes1 -f /sysarea/ssts01 -c 3000                3
  :
pdstsinit -u UNT1 -f /sysarea/usts01 -c 3000                4
  :

Explanation

Creates system log files for FES1, and BES1 to BES3.

Creates synchronization point dump files for FES1, and BES1 to BES3.

Creates server status files for FES1, and BES1 to BES3.

Creates unit status files for units 1 and 2.

Because you re-created the status files, the error shutdown status of the RDAREAs is not inherited. If necessary, use the pdhold command to place RDAREAs in shutdown status again.

(9) Use the pdconfchk command to check the HiRDB system definitions

pdconfchk

If errors are detected, correct the HiRDB system definitions, and then execute the pdconfchk command again.

(10) Use the pdstart command to start HiRDB normally

pdstart

(11) Use the pdcopy command to back up all RDAREAs

For details about making backups, see 6.4 Examples of backup.

(12) Use the pdmod command to re-initialize the RDAREAs on BES1

For details about re-initializing RDAREAs, see 15.4 Increasing the size of an RDAREA or modifying its attributes (RDAREA reinitialization).

(13) Use the pdrorg command to reload the table data in the unit that was moved, one RDAREA at a time

Use the unload data file that you created in step (2) as input data. For details about reloading on a per-RDAREA basis, see the manual HiRDB Version 8 Command Reference.

(14) Use the pdcopy command to back up all RDAREAs

For details about making backups, see 6.4 Examples of backup.

(15) Modify client environment definitions

Check if the following operands in the client environment definitions are specified; if the front-end server (FES1) that you moved is specified in these operands, change their values as appropriate:

PDFESHOST

PDSERVICEGRP

PDSERVICEPORT

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

11.7 Migrating a HiRDB/Single Server to a HiRDB/Parallel Server

This section explains the procedures for migrating a HiRDB/Single Server to a HiRDB/Parallel Server.

The following items are explained:

Preparations for migration

Migration procedure

Notes on migrating multiple user RDAREAs to different back-end servers

Organization of this section

11.7.1 Preparations for migration

11.7.2 Migration procedure

11.7.3 Points to be noted about migrating multiple user RDAREAs to different back-end servers

11.7.1 Preparations for migration

Organization of this subsection

(1) Using the database structure modification utility (pdmod command) for migration

(2) Notes

(1) Using the database structure modification utility (pdmod command) for migration

The database structure modification utility (pdmod command) is used to migrate a HiRDB/Single Server to a HiRDB/Parallel Server. The RDAREAs are migrated from the single server to the dictionary and back-end servers by executing the alter HiRDB mode to parallel statement provided by the database structure modification utility.

Figure 11-1 shows migration of RDAREAs using the database structure modification utility.

Figure 11-1 Migration of RDAREAs using the database structure modification utility

(2) Notes

(a) Backing up data before migration

The pdfbkup command should be used to back up the HiRDB files and HiRDB file system areas that contain the following RDAREAs:

User RDAREAs

User LOB RDAREAs

(b) Handling of stored procedures and stored functions

When a system is migrated from a HiRDB/Single Server to a HiRDB/Parallel Server, stored procedures and stored functions (stored functions for user-defined functions) created for the HiRDB/Single Server are no longer valid. The stored procedures and stored functions must be re-created with ALTER ROUTINE after migration to the HiRDB/Parallel Server has been completed.

(c) Handling of user LOB RDAREAs

User LOB RDAREAs containing LOB data and the user RDAREAs containing the LOB column structure base table for the LOB data must be placed on the same back-end server. Otherwise, the back-end servers may terminate abnormally when the RDAREAs are accessed.

It can be verified that the RDAREAs have been placed on the same back-end server by referencing the SQL_RDAREA, SQL_TABLES, and SQL_DIV_COLUMN dictionary tables after migration has been completed.

(d) Handling of RDAREAs for lists

RDAREAs for lists and user LOB RDAREAs containing the base table for the lists must be placed on the same back-end server.

11.7.2 Migration procedure

Executor: HiRDB administrator and superuser

Figure 11-2 shows a model for migration from a HiRDB/Single Server to a HiRDB/Parallel Server.

Figure 11-2 Model for migration from HiRDB/Single Server to HiRDB/Parallel Server

The procedure for migrating from a HiRDB/Single Server to a HiRDB/Parallel Server is explained below.

Organization of this subsection

(1) Execute the database structure modification utility

(2) Terminate HiRDB normally

(3) Set up the HiRDB/Parallel Server environment

(4) Migrate the user RDAREAs, user LOB RDAREAs, and list RDAREAs to the other server machine

(5) Start HiRDB normally

(6) Re-create the stored procedures and stored functions

(1) Execute the database structure modification utility

The alter HiRDB mode to parallel statement of the database structure modification utility (pdmod command) is used to modify the RDAREAs for the HiRDB/Parallel Server. For examples of using this utility, see the manual HiRDB Version 8 Command Reference.

(2) Terminate HiRDB normally

The pdstop command is entered to terminate the HiRDB/Single Server normally (the termination must be a normal termination).

(3) Set up the HiRDB/Parallel Server environment

The HiRDB/Parallel Server environment is set up. For details on HiRDB/Parallel Server environment setup, see the manual HiRDB Version 8 Installation and Design Guide.

The following points should be noted about environment setup:

A different HiRDB directory must be used than the one for the HiRDB/Single Server.

The system files for the HiRDB/Single Server must not be used; new system files must be created for the HiRDB/Parallel Server.

The server machine used by the HiRDB/Single Server (existing server machine) must be defined as the dictionary server.

(4) Migrate the user RDAREAs, user LOB RDAREAs, and list RDAREAs to the other server machine

At this point, the user RDAREAs, user LOB RDAREAs, and list RDAREAs are still at the server machine used for the HiRDB/Single Server (existing server machine). There are two ways to migrate the user RDAREAs, user LOB RDAREAs, and list RDAREAs to the other server machine:

Using HiRDB operation commands

Using OS commands

(a) Using HiRDB operation commands

RDAREAs can be migrated in units of HiRDB file system areas or in units of HiRDB files by using HiRDB operation commands.

Figure 11-3 shows the procedure for migrating RDAREAs to another server using HiRDB operation commands.

Figure 11-3 Procedure for migrating RDAREAs to another server using HiRDB operation commands

Rules and notes on migration

The HiRDB identifier cannot be changed (the value of pd_system_id in the system common definition cannot be changed).

The HiRDB file system areas must be created in the target server machine under the same names as were used in the source server machine.

The lengths of the HiRDB file system areas in the target server machine must be set so as to be equal to or greater than the lengths of the HiRDB file system areas in the source server machine.

When a HiRDB file is restored, the HiRDB file system area created in the target server machine must be large enough to store the file.

The HiRDB file system areas in the source server machine should not be deleted immediately after migration has been completed. Startup and operation of the HiRDB/Parallel Server should be checked before the HiRDB file system areas are deleted from the source server machine.

(b) Using OS commands

The following OS commands can be used to migrate RDAREAs to another server machine:

tar or cp command

rcp command

RDAREAs can be migrated in units of HiRDB file system areas by using OS commands.

Using the tar or cp command

Figure 11-4 shows the procedure for migrating RDAREAs to another server machine using the tar or cp command.

Figure 11-4 Procedure for migrating RDAREAs to another server machine using the tar or cp command

Notes

The HiRDB file system areas must be created in the target server machine under the same names as were used in the source server machine.

If a file to be migrated is a character special file, the partition size in the target server machine must be set to be equal to or greater than the partition size in the source server machine.

The HiRDB file system areas in the source server machine should not be deleted immediately after migration has been completed. Startup and operation of the HiRDB/Parallel Server should be checked before the HiRDB file system areas are deleted from the source server machine.

Using the rcp command

Figure 11-5 shows the procedure for migrating RDAREAs to another server machine using the rcp command.

Figure 11-5 Procedure for migrating RDAREAs to another server machine (using the rcp command)

Notes

The HiRDB file system areas must be created in the target server machine under the same names as were used in the source server machine.

If a file to be migrated is a character special file, the partition size in the target server machine must be set to be equal to or greater than the partition size in the source server machine.

The HiRDB file system areas in the source server machine should not be deleted immediately after migration has been completed. Startup and operation of the HiRDB/Parallel Server should be checked before the HiRDB file system areas are deleted from the source server machine.

(5) Start HiRDB normally

The pdstart command is entered to start the HiRDB/Parallel Server normally.

(6) Re-create the stored procedures and stored functions

If stored procedures and stored functions (stored functions for user-defined functions) have been created, ALTER ROUTINE must be used to re-create them.

This step is necessary because when a HiRDB/Single Server is migrated to a HiRDB/Parallel Server, the existing stored procedures and stored functions are no longer valid.

11.7.3 Points to be noted about migrating multiple user RDAREAs to different back-end servers

Organization of this subsection

(1) Non-partitioned table

(2) Row-partitioned table

(1) Non-partitioned table

If a table and its index are stored in different RDAREAs, those RDAREAs should be placed in the same back-end server. After executing the database structure modification utility, dictionary tables (SQL_RDAREAS, SQL_TABLES, and SQL_INDEXES tables) should be referenced to check that the RDAREAs have migrated to the same back-end server.

(2) Row-partitioned table

If a table and its index are stored in different RDAREAs, those RDAREAs should be placed in the same back-end server. After the database structure modification utility has executed, dictionary tables (SQL_RDAREAS, SQL_TABLES, SQL_DIV_TABLE, SQL_INDEXES, and SQL_DIV_INDEX tables) should be referenced to check that the RDAREAs have been migrated into the same back-end server.

When a non-partitioning index is defined for a table, the table cannot be migrated into multiple back-end servers. To migrate such a table into multiple back-end servers, the non-partitioning index must be deleted before migration; it can then be redefined after the migration. Figure 11-6 shows the procedure for migrating a table for which a non-partitioning index is defined.

Figure 11-6 Procedure for migrating a table with a non-partitioning index defined

Explanation

The STOCK table is row-partitioned into RDAREA1 and RDAREA2. Index 1 is row-partitioned. Index 2 is not row-partitioned. To migrate the STOCK table into multiple back-end servers, delete Index 2, migrate the table, then define Index 2.

11.8 Migrating back-end servers for load balancing

This section explains the procedure for migrating back-end servers in order to balance the workload.

Organization of this section

11.8.1 Back-end server load balancing based on a scenario

11.8.2 Prerequisites and conditions for the target jobs

11.8.3 Using a scenario

11.8.4 Back-end server configuration examples

11.8.5 Preparations related to HiRDB

11.8.6 Back-end server load balancing performed by the user

11.8.1 Back-end server load balancing based on a scenario

If, for example, some jobs have peak demand at the end of each month, the workload may become concentrated on specific back-end servers, slowing down the overall job-processing speed. In such a case, you can dynamically modify the positioning of back-end servers according to the fluctuations in their workload, thereby balancing the workload among the individual units.

Note that the back-end server load balancing explained here assumes the following:

Use of the standby-less system switchover (effects distributed) facility to migrate back-end servers

Execution of a scenario created by JP1/AJS2-SO on JP1/AJS2

Execution of a scenario that uses HiRDB CM

In the case of a HiRDB policy operation, a scenario template is converted to a scenario and executed as shown in Figure 11-7.

Terminology

Scenario: Object that is formed by a networking scenario job by assigning to it an execution sequence. A scenario is registered into JP1/AJS2 and can then be executed.

Scenario template: Template for a scenario that consists of procedures only, and in which the environmental information (parameters) necessary for executing the scenario are defined as scenario variables. A scenario template is used as a component for creating a scenario.

Scenario variable values: User (system)-specific information (including HiRDB identifier, host name, server name, and unit identifier of the migration destination) that is added when a scenario is created from a scenario template.

Jobnet: Set of jobs to which an execution sequence is assigned by JP1/AJS2. When a jobnet is executed, the jobs constituting the jobnet are executed automatically according to the execution sequence.

Figure 11-7 Using a scenario for back-end server load balancing

Explanation

Create a scenario (JP1/AJS2 jobnet) by entering a scenario template and scenario variable values into JP1/AJS2-SO. This step is performed only once the first time the scenario is to be executed.

Register the created scenario (jobnet) into JP1/AJS2 and execute it.

The jobnet executes HiRDB CM commands.

The HiRDB CM commands request processing by the HiRDB CM server.

The HiRDB CM server requests processing by the HiRDB CM Agent of the server machine where the system manager is defined.

The HiRDB CM Agent of the server machine where the system manager is defined executes HiRDB commands and HA monitor commands, or requests processing by the HiRDB CM Agents of other units.

For details about HiRDB CM, see the Help section in HiRDB CM.

11.8.2 Prerequisites and conditions for the target jobs

To balance back-end server workload based on a scenario, the prerequisites and the conditions for the target jobs described below must be satisfied.

Prerequisites

HiRDB/Parallel Server consisting of multiple units.

The standby-less system switchover (effects distributed) facility is used (or can be used).

Conditions for the target jobs

At least two different jobs are executed by a single HiRDB.

The back-end servers used primarily by the individual jobs (back-end servers that become overloaded) constitute only some of the available back-end servers.

The back-end servers used primarily by the individual jobs (back-end servers that become overloaded) are mutually exclusive in terms of the processing of the individual jobs.*

The peak periods (times) of the individual jobs do not overlap.

The load fluctuations of each job can be predicted or anticipated.

Transactions of the jobs that use a back-end server to be migrated terminate within short periods (at least there is no transaction that will remain uncompleted for a long time when the back-end server is to be moved).

While a back-end server is being migrated, transactions that use that back-end server can be queued temporarily or cancelled.

* Because the objective is to balance the load among individual units by migrating back-end servers, the individual jobs need not be completely exclusive.

Reference note

A back-end server is migrated when its load is high. Consequently, transactions may be placed on hold temporarily or may be cancelled, thus affecting the jobs adversely.

The unit to which a back-end server is to be migrated may also have an unexpectedly high processing load. For this reason, the back-end server load may not be balanced even after back-end server migration.

11.8.3 Using a scenario

This section explains how to use a scenario for back-end server load balancing.

Organization of this subsection

(1) Regular execution of a scenario by JP1/AJS2

(2) Monitoring back-end server workload by JP1/PFM and scenario execution based on a user operation

(3) Monitoring back-end server workload by JP1/PFM and automatic scenario execution

(1) Regular execution of a scenario by JP1/AJS2

You can use JP1/AJS2 to execute a scenario by specifying the time of or a time period for back-end server load balancing. Figure 11-8 shows a typical execution of a scenario by JP1/AJS2.

Figure 11-8 Typical execution of a scenario by JP1/AJS2

Characteristics

This method is effective when you can predict the time or time period when the back-end server workload tends to become uneven.

Because you can specify the time of or time period for migrating a back-end server, it is easy to create an operation plan.

This method can be used with the minimum product configuration for policy operation.

(2) Monitoring back-end server workload by JP1/PFM and scenario execution based on a user operation

You use JP1/PFM to monitor the workload of back-end servers. When the workload exceeds a preset value, this fact is reported as an event to JP1/IM-CC and displayed in JP1/IM-View. An operator monitors this and uses a GUI operation to execute a scenario. Figure 11-9 shows monitoring of the workload of back-end servers by JP1/PFM and scenario execution based on a user operation.

Figure 11-9 Monitoring the workload of back-end serves by JP1/PFM and scenario execution based on a user operation

Characteristics

You can balance back-end server workload dynamically.

You can change back-end server workload semi-automatically.

Because a back-end server is migrated after the operator confirms the need for migration, flexible and safe operation is ensured.

(3) Monitoring back-end server workload by JP1/PFM and automatic scenario execution

You use JP1/PFM to monitor the workload of back-end servers. When the workload exceeds a preset value, a scenario is executed automatically by JP1/AJS2. Figure 11-10 shows monitoring of the workload of back-end servers by JP1/PFM and automatic scenario execution.

Figure 11-10 Monitoring of the workload of back-end servers by JP1/PFM and automatic scenario execution

Characteristics

You can balance back-end server workload dynamically.

No operator action is required; the back-end server workload is adjusted automatically.

11.8.4 Back-end server configuration examples

This section provides examples of back-end server configurations when load balancing is performed.

Organization of this subsection

(1) Configuration example 1: Two jobs, three units, four back-end servers

(2) Configuration example 2: Two jobs, four units, 14 back-end servers

(1) Configuration example 1: Two jobs, three units, four back-end servers

Job assumptions

The two jobs are a job for keeping track of hours worked and a job for settling business travel expenses.

Two back-end servers are allocated to each job and are used exclusively for that job.

During normal operations, the travel expenses job requires higher performance.

At the end of the month, the workload of the work hours job increases.

At the end of the month, the work hours job is given higher priority than the travel expenses job.

Figure 11-11 shows the back-end server configuration when load balancing is performed.

Figure 11-11 Back-end server configuration when load balancing is performed for Example 1 (two jobs, three units, four back-end servers)

Note

The number in parentheses indicates the switching priority of each back-end server within the unit. This is the same as the value of the standbypri operand of the standby server (standby is specified in the inital operand) for each server specified in the servers definition of the HA monitor for each server machine.

Note that (0) indicates the primary system. In this case, online must be specified in the inital operand of the servers definition for the applicable server machine or server and the standbypri operand must not be specified.

Explanation

At the end of the month when the workload of the work hours job increases, back-end servers are migrated to balance the job load.

This scenario is achieved by combining two basic scenarios for migrating back-end servers.

When the priority order shown in the figure is specified, you can prevent the load from becoming unbalanced among the back-end servers even if an error occurs after back-end server migration.

(2) Configuration example 2: Two jobs, four units, 14 back-end servers

Job assumptions

The two jobs are a job for keeping track of hours worked and a job for settling business travel expenses.

Eight back-end servers are allocated to the work hours job and six back-end servers are allocated to the travel expenses job, and all back-end servers are used exclusively for their allocated job.

During normal operations, the two jobs require the same level of performance.

At the end of the month, the workload of the work hours job increases.

Even at the end of the month, the performance of the travel expenses job must not be slowed down if at all possible.

Figure 11-12 shows the back-end server configuration when load balancing is performed.

Figure 11-12 Back-end server configuration when load balancing is performed for Example 2 (two jobs, four units, and 14 back-end servers)

Note

The number in parentheses indicates the switching priority of each back-end server within the unit. This is the same as the value of the standbypri operand of the standby server (standby is specified in the inital operand) for each server specified in the servers definition of the HA monitor for each server machine.

Note that (0) indicates the primary system. In this case, online must be specified in the inital operand of the servers definition for the applicable server machine or server and the standbypri operand must not be specified.

Explanation

At the end of the month when the workload of the work hours job increases, back-end servers are migrated to balance the job load.

This scenario is achieved by combining three basic scenarios for migrating back-end servers.

11.8.5 Preparations related to HiRDB

The HiRDB-related preparations explained in this subsection are required.

Organization of this subsection

(1) Applying the standby-less system switchover (effects distributed) facility

(2) Selecting whether to apply the transaction queuing facility

(1) Applying the standby-less system switchover (effects distributed) facility

You must apply the standby-less system switchover (effects distributed) facility. For details about this facility, see 25. Using the System Switchover Facility.

(2) Selecting whether to apply the transaction queuing facility

Select whether or not the transaction queuing facility is to be applied. Guidelines on applying this facility are provided below. For details about the transaction queuing facility, see 25.19 Transaction queuing facility.

(a) Processing method when the transaction queuing facility is used

The processing method when the transaction queuing facility is used is explained below.

Processing method

When a back-end server is migrated, startups of new transactions for that back-end server are put on hold.

Waits for termination of transactions being processed by the back-end server that is to be migrated. When there are no more transactions being processed by the back-end server to be migrated, the back-end server is migrated.

Transactions put on hold in 1 are started.

Note that you can specify the transaction queuing wait time in the pd_ha_trn_queuing_wait_time operand. If termination of a back-end server is delayed for a considerable period because of a transaction that requires a long time to execute, transaction queuing is cancelled when the transaction queuing wait time is exceeded and migration of the back-end server is cancelled. In such a case, the transactions that were placed on hold in 1 are restarted.

(b) Processing method when the transaction queuing facility is not used

A back-end server is migrated without placing startups of new transactions on hold and without waiting for transactions currently executing to terminate.

(c) Advantages and disadvantages of the transaction queuing facility

Table 11-1 shows the advantages and disadvantages of the transaction queuing facility.

Table 11-1 Advantages and disadvantages of the transaction queuing facility

Application of the transaction queuing facility
Advantages
Disadvantages

Applied
Transaction errors can be avoided during back-end server migration (except when back-end server startup takes a long time).

Transactions can become queued during back-end server migration.

Back-end server migration can take longer than when the transaction queuing facility is not applied.

Back-end server migration may be cancelled if there is a transaction that executes over an extended period.

Not applied

Transactions are not queued during back-end server migration.

A back-end server can be migrated even when there is a transaction that executes over an extended period.

Back-end server migration takes less time than when the transaction queuing facility is applied.

A transaction that is executing at the time of back-end server migration terminates with an error.

A transaction that starts during back-end server migration terminates with an error.

Reference note

Because the transaction queuing facility is also used for the system switchover at the time of system failure, you may want to consider using this facility together with the system switchover facility.

(d) Setting up the transaction queuing facility

To use the transaction queuing facility, you must specify queuing in the pd_ha_transaction operand.

You must also specify the sum of the times described below as the transaction queuing wait time in the pd_ha_trn_queuing_wait_time operand.

Maximum queuing time for transactions that occur during back-end server migration

Time in the back-end server migration scenario between forced server termination (which basically is the time at which the KFPS01843-I message is output when the pdstop -s -f command is entered) and completion of server startup (issuance of the KFPS01813-I message)

If the transaction queuing facility is not used, specify error in the pd_ha_transaction operand or omit this operand.

11.8.6 Back-end server load balancing performed by the user

You can use commands to balance the workload of the back-end servers.

Organization of this subsection

(1) Operating procedure

(2) Error handling procedure

(3) Notes

(1) Operating procedure

The operating procedure depends on whether an HA monitor or Hitachi HA Toolkit Extension is used. This subsection describes the operating procedure. If you are moving multiple back-end servers, see (3)(a) Automating the moving of back-end servers.

(a) When an HA monitor is used

1. Check the status of the server to be moved.

At the unit where the system manager is located, execute the pdls -d ha -s server-name -a command and check the displayed information (standard output) for the following:

The back-end server to be moved is active (ONL) at the source unit.

The back-end server to be moved is in standby (SBY) or inactive (STP) status at the target unit.

2. Start the transaction queuing facility at the back-end server that is to be moved.

Start the transaction queuing facility by executing the pdtrnqing -s server-name command at the back-end server's source unit. There is no need to perform this operation if queuing was not specified in the pd_ha_transaction operand.

Make sure that the command terminates normally with return code 0 or with warning with return code 4. Return code 0 means that the transaction queuing facility has started successfully. Return code 4 means that the pd_ha_transaction operand specification resulted in an error. If the return code is 8 or 12, terminate the procedure because a failure has occurred.

3. Forcibly terminate the back-end server that is to be moved.

Forcibly terminate the back-end server by executing the pdstop -f -s server-name command at the unit containing the system manager. Make sure that the command's return code is 0. If the return code is not 0, terminate the procedure because a failure has occurred.

4. Start the back-end server being moved at the target unit.

At the unit containing the system manager, execute the pdstart -s server-name -u target-unit-identifier command. Make sure that the command's return code is 0. If the return code is not 0, terminate the procedure because a failure has occurred.

5. Check the status of the back-end server being moved.

At the unit containing the system manager, execute the pdls -d ha -s server-name -a command to check the displayed information (standard output) and return code for the following:

Check that the back-end server is waiting for startup of the running system (WIT) in the target unit. If the back-end server is waiting for startup of the running system (WIT) in the target unit, proceed to step 6.

Check that the back-end server is in active status (ONL) at the target unit. Proceed to step 7 only if the back-end server is in active status (ONL) at the target unit.

If neither of the above is true, cancel the procedure because a failure has occurred.

6. Resume startup of the back-end server at the target unit.

At the target unit, the super user must execute the monact server-name command and make sure that the command's return code is 0. If the return code is not 0, terminate the procedure because a failure has occurred.

7. Release the transaction queuing facility at the back-end server being moved.

At the back-end server's target unit, execute the pdtrnqing -d -s server-name command to release the transaction queuing facility. If queuing was omitted in the pd_ha_transaction operand, there is no need to perform this operation.

Check that the command's return code is 0. If the return code is not 0, terminate the procedure because a failure has occurred.

(b) When Hitachi HA Toolkit Extension is used

1. Check the status of the server to be moved.

See 1. in (a) When an HA monitor is used.

2. Start the transaction queuing facility at the back-end server that is to be moved.

See 2. in (a) When an HA monitor is used.

3. Use the cluster software system switchover command to move the back-end server.

Use the cluster software system switchover command to switch over to the system at the target unit.

4. Check the status of the back-end server.

At the unit containing the system manager, execute the pdls -d ha -s server-name -a command to check the displayed information (standard output) and the return code for the following:

The back-end server is active (ONL) at the target unit.

5. Release the transaction queuing facility at the back-end server being moved.

See 7. in (a) When an HA monitor is used.

(2) Error handling procedure

If an error occurs while the back-end server is being moved, check the syslogfile and the messages in the standard output and standard error output, and eliminate the cause of the error.

If a failure occurs after the transaction queuing facility has started, execute the following command at the unit containing the system manager in order to release the transaction queuing facility:

pdtrnqing -d -f -s server-name

When this command is executed, the transaction queuing facility is released. Because this action is a protective measure against illegal operation of the transaction queuing facility as a result of the failure, a processing request occurs for the back-end server that has not been started, which results in an SQL error.

(3) Notes

(a) Automating the moving of back-end servers

To use the transaction queuing facility to move multiple back-end servers, you can automate the procedure as follows:

Start the transaction queuing facility

Move the back-end servers

Release the transaction queuing facility

If you attempt to do this manually, the processing of moving the back-end servers may take too much time and a timeout may occur in the transaction queuing facility, resulting in a transaction error.

(b) Moving multiple back-end servers

If you use the transaction queuing facility to move multiple back-end servers, execute (1) Operating procedure for each server. Do not execute this procedure for multiple servers at the same time. If multiple back-end servers are moved concurrently, transactions accessing those back-end servers are queued and they may not be able to terminate. In such a case, the pdtrnqing command may result in an error.

12. Migrating Resources Between Systems

This chapter explains the procedures for migrating tables and stored procedures to another HiRDB system.

This chapter contains the following sections:

Organization of this chapter

12.1 Migrating a table to another HiRDB system

12.2 Migrating a stored procedure to another HiRDB system

12.1 Migrating a table to another HiRDB system

Executor: HiRDB administrator

The dictionary import/export utility and the database reorganization utility enable a table that is currently in use to be migrated to another HiRDB system. This facility can be used to achieve the following:

Migrating a database from a test system to the actual system

Migrating a database created in one HiRDB system to another HiRDB system

During system reconstruction, storing existing database information and restoring it after the system has been reconstructed

Organization of this section

12.1.1 Migrating a table to another HiRDB system

12.1.2 Example 1: Migrating a table

12.1.3 Example 2: Migrating tables of a schema

12.1.4 Example of a control statements file when migrating tables to a different schema

12.1.1 Migrating a table to another HiRDB system

Organization of this subsection

(1) Limitations

(2) Information to be migrated

(3) Notes on RDAREAs (Important)

(4) Migration procedure

(1) Limitations

A table for which an abstract data type is defined cannot be migrated to another HiRDB system. Some abstract data types provided by a plug-in can be migrated to another HiRDB system, depending on the plug-in type. To determine whether or not an abstract data type can be migrated, refer to the applicable plug-in manual. To migrate an abstract data type, the same plug-in as is used at the source HiRDB system is required at the target HiRDB system.

If the character codes used differ between the source system and the target system, you will not be able to use the database reorganization utility to reload table data on the target system. In such a case, instead of reloading, you must use the database load utility to load the data.

A falsification prevented table cannot be moved to another HiRDB system, nor can its table data be reloaded on the target system.

You cannot use the database copy utility and database recovery utility to migrate data. Do not attempt to migrate data by restoring a backup made on the migration-source system to the migration-destination system.

(2) Information to be migrated

The following information is migrated:

Table definition information

Table data

(a) Procedure for migrating table definition information

The dictionary import/export utility (pdexp command) is used to migrate table definition information in dictionary tables currently in use to another HiRDB system. The following table definition information is subject to migration:

Base table definition (applicable only for tables that do not contain abstract data types)

View table definitions

Index definitions

Comment information

Table alias definitions

Figure 12-1 shows the procedure for migrating table definition information with the dictionary import/export utility.

Figure 12-1 Migration of table definition information with the dictionary import/export utility

(b) Procedure for migrating table data

The database reorganization utility (pdrorg command) is used to migrate table data that is currently in use to another HiRDB system. Figure 12-2 shows the procedure for migrating table data with the database reorganization utility.

Figure 12-2 Migration of table data with the database reorganization utility

(3) Notes on RDAREAs (Important)

Before table definition information is migrated, RDAREAs with the same names as in the source system must be created in the target system.

If there are differences between the migration source system and the migration target system in the names of the RDAREAs for storing the table to be migrated or in the configurations of the servers for storing the RDAREAs, the -g option must be specified when the database reorganization utility (pdrorg command) is executed. Figure 12-3 shows an example of system configurations for which the -g option must be specified.

Figure 12-3 Example of system configuration requiring the -g option

(4) Migration procedure

Figure 12-4 provides an overview of the procedure for migrating a table to another HiRDB system.

Figure 12-4 Procedure for migrating a table to another HiRDB system

12.1.2 Example 1: Migrating a table

This example migrates a table (TABLE1) from HiRDB system A to HiRDB system B.

A LOB column is defined for TABLE1.

An index (INDEX1) is defined for TABLE1.

It is assumed that RDAREAs with the same names (RDAREA1 to RDAREA6) have already been created in the target system.

Organization of this subsection

(1) Enter the pdhold command to shut down RDAREA1 to RDAREA6

(2) Create the control statements file for the pdrorg command

(3) Use the pdrorg command to unload data for TABLE1

(4) Use the pdrels command to release RDAREA1 to RDAREA6 from shutdown status

(5) Create the control statements file for the pdexp command

(6) Use the pdexp command to export table definition information for TABLE1

(7) Store the unload data file and export file on a medium such as CMT

(8) Store the unload data file and export file in the target system

(9) Use the pddef command to define a schema for the user who owns TABLE1

(10) Use pdcopy command to back up the data

(11) Use the pdexp command to import table definition information for TABLE1

(12) Use the pdhold command to shut down RDAREA1 to RDAREA6

(13) Create the control statements file for the pdrorg command

(14) Use the pdrorg command to reload data for TABLE1

(15) Use the pdcopy command to back up the data

(16) Use the pdrels command to release RDAREA1 to RDAREA6 from shutdown status

(1) Enter the pdhold command to shut down RDAREA1 to RDAREA6

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

(2) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

(a) HiRDB/Single Server

unload /pdrorg/unfile1

Explanation

Specifies the name of the unload data file.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1

Explanation

Specifies the name of the unload data file for bes1.

(3) Use the pdrorg command to unload data for TABLE1

pdrorg -k unld -j -g -t TABLE1 /pdrorg/rorg01

Explanation

-k: Specifies unld in order to unload data.

-j: Specifies that the table that is to be unloaded is one of the following:

A table containing a LOB column

A table in which an abstract data type with the LOB attribute is defined

-g: Specifies that TABLE1 is a row-partitioned table on a server of the HiRDB/Parallel Server. A single unload data file is created.

-t: Specifies the name of the table that is to be unloaded.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (2).

(4) Use the pdrels command to release RDAREA1 to RDAREA6 from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

(5) Create the control statements file for the pdexp command

The following are the contents of the control statements file (/pdexp/exp01):

-t USR01.TABLE1

Explanation

USR01: Name of the schema that owns TABLE1.

TABLE1: Name of the table to be exported.

(6) Use the pdexp command to export table definition information for TABLE1

pdexp -e /pdexp/expfile1 -f /pdexp/exp01

Explanation

-e: Specifies the name of the file to be exported.

-f: Specifies the name of the control statements file for the pdexp command created in step (5).

(7) Store the unload data file and export file on a medium such as CMT

The unload data file created in step (3) and the export file created in step (6) are stored on a medium such as CMT.

The operations at the source system (HiRDB system A) are now complete.

(8) Store the unload data file and export file in the target system

The operations from this point on are performed at the target system (HiRDB system B).

The unload data file and export file stored on a medium such as CMT are copied into the target system.

(9) Use the pddef command to define a schema for the user who owns TABLE1

pddef
  CREATE SCHEMA AUTHORIZATION USR01;

(10) Use pdcopy command to back up the data

pdcopy -m /rdarea/mast/mast01 -M r
-r RDMAST,RDDIR,RDDIC,RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6
-b /pdcopy/backup01 -p /pdcopy/list01

Explanation

The RDAREAs are backed up as a safeguard in the event of errors during database migration. The following RDAREAs must be backed up:

Master directory RDAREA

Data directory RDAREA

Data dictionary RDAREAs

User RDAREAs and user LOB RDAREAs for storing the imported table (RDAREA1 to RDAREA6)

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-r: Specifies the names of the RDAREAs to be backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination for the pdcopy command's processing results listing.

(11) Use the pdexp command to import table definition information for TABLE1

pdexp -i /pdexp/expfile1

Explanation

-i: Specifies the name of the file to be imported.

(12) Use the pdhold command to shut down RDAREA1 to RDAREA6

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

(13) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

(a) HiRDB/Single Server

unload /pdrorg/unfile1                           1
idxwork /pdrorg/idxwork                          2
sort /sortwork,8192                              3

Explanation

Specifies the name of the unload data file.

Specifies the name of the directory in which to create an index information file. The index information file is created under this directory.

Specifies the name of the work directory for sorting.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1                     1
idxwork bes1 /pdrorg/idxwork                    2
sort bes1 /sortwork,8192                        3
idxwork bes2 /pdrorg/idxwork                    4
sort bes2 /sortwork,8192                        5

Explanation

Specifies the name of the unload data file (for bes1).

Specifies the name of the directory in which an index information file is to be created (for bes1). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes1).

Specifies the name of the directory in which an index information file is to be created (for bes2). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes2).

(14) Use the pdrorg command to reload data for TABLE1

pdrorg -k reld -j -g -t TABLE1 /pdrorg/rorg01

Explanation

To re-create the index (INDEX1) at the same time, the -i option is omitted and the index batch creation mode is used.

-k: Specifies reld in order to reload data.

-j: Specifies that the table that is to be reloaded is one of the following:

A table containing a LOB column

A table in which an abstract data type with the LOB attribute is defined

-g: Specifies that TABLE1 is a row-partitioned table on a server of the HiRDB/Parallel Server. A single unload data file is created.

-t: Specifies the name of the table to be reloaded.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (13).

(15) Use the pdcopy command to back up the data

pdcopy -m /rdarea/mast/mast01 -M r
-r RDMAST,RDDIR,RDDIC,RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6
-b /pdcopy/backup02 -p /pdcopy/list02

Explanation

The following RDAREAs must be backed up:

Master directory RDAREA

Data directory RDAREA

Data dictionary RDAREAs

User RDAREAs and user LOB RDAREAs for storing the imported table (RDAREA1 to RDAREA6)

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-r: Specifies the names of the RDAREAs to be backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(16) Use the pdrels command to release RDAREA1 to RDAREA6 from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

12.1.3 Example 2: Migrating tables of a schema

This example migrates to HiRDB system B all tables in HiRDB system A owned by the user with authorization identifier USR01. It is assumed that RDAREAs with the same names have been created in the migration target system. Unloading and reloading of the tables is performed by schema (all tables in the specified schema are unloaded and reloaded).

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs storing data to be migrated

(2) Create the control statements file for the pdrorg command

(3) Use the pdrorg command to unload tables by schema

(4) Use the pdrels command to release RDAREAs from shutdown status

(5) Create the control statements file for the pdexp command

(6) Use the pdexp command to export table definition information on all tables

(7) Store the unload data file and export file on a medium such as CMT

(8) Store the unload data file and export file at the migration target system

(9) Use the pddef command to define a schema (authorization identifier: USR01)

(10) Use the pdcopy command to back up the data

(11) Use the pdexp command to import table definition information

(12) Use the pdhold command to shut down RDAREA1-RDAREA6

(13) Create the control statements file for the pdrorg command

(14) Use the pdrorg command to reload all tables

(15) Use the pdcopy command to back up the data

(16) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs storing data to be migrated

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,...

(2) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

(a) HiRDB/Single Server

unload /pdrorg/unfile1

Explanation

Specifies the name of the unload data file.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1

Explanation

Specifies the name of the unload data file. Because the -g option is assumed, the unload data file is created at one location.

(3) Use the pdrorg command to unload tables by schema

pdrorg -k unld -t USR01.all /pdrorg/rorg01

Explanation

-k: Specifies unld for unloading.

-t: Specifies the authorization identifier of the schema whose tables are to be unloaded.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (2).

Remarks

When tables are unloaded by schema, the -j option (unloading with LOB data present) is assumed. In the case of a HiRDB/Parallel Server, the -g option (unload data file standardization) is also assumed.

(4) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,...

(5) Create the control statements file for the pdexp command

The following are the contents of the control statements file (/pdexp/exp01):

-t USR01.TABLE1
-t USR01.TABLE2

Explanation

USR01: Name of the schema to which TABLE1 and TABLE2 belong.

TABLE1,TABLE2: Names of the tables being exported.

(6) Use the pdexp command to export table definition information on all tables

pdexp -e /pdexp/expfile1 -f /pdexp/exp01

Explanation

-e: Specifies the name of the file that is to be exported.

-f: Specifies the name of the control statements file for the pdexp command that was created in step (5).

(7) Store the unload data file and export file on a medium such as CMT

The unload data file created in step (3) and the export file created in step (6) are stored on a medium such as CMT.

Operations at the migration source system (HiRDB system A) have now been completed.

(8) Store the unload data file and export file at the migration target system

The operations from here on are performed at the migration target system (HiRDB system B).

The unload data file and export file that have been stored on a medium such as CMT are now stored at the migration target system.

(9) Use the pddef command to define a schema (authorization identifier: USR01)

This operation is not necessary if the tables are being migrated to a different schema (a schema other than USR01).

pddef
  CREATE SCHEMA AUTHORIZATION USR01;

(10) Use the pdcopy command to back up the data

pdcopy -m /rdarea/mast/mast01 -M r
-r RDMAST,RDDIR,RDDIC,RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6
-b /pdcopy/backup01 -p /pdcopy/list01

Explanation

A backup is made as a safeguard in the event errors occur during database migration. The following RDAREAs are backed up:

Master directory RDAREA

Data directory RDAREA

Data dictionary RDAREA

User RDAREAs and user LOB RDAREAs that store the tables being imported (RDAREA1-RDAREA6)

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-r: Specifies the names of the RDAREAs to be backed up.

-b: Specifies a name for the backup file.

-p: Specifies the output destination for the pdcopy command's processing results listing.

(11) Use the pdexp command to import table definition information

pdexp -i /pdexp/expfile1

Explanation

-i: Specifies the name of the export file.

(12) Use the pdhold command to shut down RDAREA1-RDAREA6

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,...

(13) Create the control statements file for the pdrorg command

Shown below are the contents of the control statements file (/pdrorg/rorg01).

If the tables are to be migrated to a different schema (a schema other than USR01), the contents of the control statements file will be different. For an example of a control statements file when tables are migrated to a different schema, see 12.1.4 Example of a control statements file when migrating tables to a different schema.

(a) HiRDB/Single Server

unload /pdrorg/unfile1                        1
idxwork /pdrorg/idxwork                       2
sort /sortwork,8192                           3

Explanation

Specifies the name of the unload data file.

Specifies the name of the directory in which an index information file is to be created. The index information file is created under this directory.

Specifies the name of the work directory for sorting.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1                     1
idxwork bes1 /pdrorg/idxwork                    2
sort bes1 /sortwork,8192                        3
idxwork bes2 /pdrorg/idxwork                    4
sort bes2 /sortwork,8192                        5

Explanation

Specifies the name of the unload data file. Because the -g option is assumed, the unload data file is created at one location.

Specifies the name of the directory in which an index information file is to be created (for bes1). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes1).

Specifies the name of the directory in which an index information file is to be created (for bes2). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes2).

(14) Use the pdrorg command to reload all tables

pdrorg -k reld -t USR01.all /pdrorg/rorg01

Explanation

Because an index (INDEX1) is re-created simultaneously, the -i option is omitted and indexes are created in the batch index creation mode.

-k: Specifies reld for reloading.

-t: Specifies the authorization identifier of the schema to be reloaded. If the tables are to be migrated to a different schema (a schema other than USR01), specify the authorization identifier at the migration target. For example, if the tables were to be migrated to authorization identifier USR02, the specification would be -t USR02.all.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (13).

Remarks

When tables are unloaded by schema, the -j option (unloading with LOB data present) is assumed. In the case of a HiRDB/Parallel Server, the -g option (unload data file standardization) is also assumed.

(15) Use the pdcopy command to back up the data

pdcopy -m /rdarea/mast/mast01 -M r
-r RDMAST,RDDIR,RDDIC,RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6
-b /pdcopy/backup02 -p /pdcopy/list02

Explanation

The following RDAREAs are backed up:

Master directory RDAREA

Data directory RDAREA

Data dictionary RDAREA

User RDAREAs and user LOB RDAREAs that store the tables being imported (RDAREA10-RDAREA6)

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-r: Specifies the names of the RDAREAs to be backed up.

-b: Specifies a name for the backup file.

-p: Specifies the output destination for the pdcopy command's processing results listing.

(16) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

12.1.4 Example of a control statements file when migrating tables to a different schema

An example of a control statements file of the database reorganization utility for migrating tables to a different schema is shown below. The authorization identifier of the migration source schema is USR01 and that of the migration target schema is USR02.

Organization of this subsection

(1) HiRDB/Single Server

(2) HiRDB/Parallel Server

(3) Example of the pdrorg command

(1) HiRDB/Single Server

unload /pdrorg/unfile1                           1
idxwork /pdrorg/idxwork                          2
sort /sortwork,8192                              3
tblname USR01                                    4

Explanation

Specifies the name of the unload data file.

Specifies the name of the directory in which an index information file is to be created. The index information file is created under this directory.

Specifies the name of the work directory for sorting.

Specifies the authorization identifier of the migration source schema.

(2) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1                     1
idxwork bes1 /pdrorg/idxwork                    2
sort bes1 /sortwork,8192                        3
idxwork bes2 /pdrorg/idxwork                    4
sort bes2 /sortwork,8192                        5
tblname USR01                                   6

Explanation

Specifies the name of the unload data file. Because the -g option is assumed, the unload data file is created at one location.

Specifies the name of the directory in which an index information file is to be created (for bes1). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes1).

Specifies the name of the directory in which an index information file is to be created (for bes2). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes2).

Specifies the authorization identifier of the migration source schema.

(3) Example of the pdrorg command

pdrorg -k reld -t USR02.all /pdrorg/rorg01

Explanation

-t: Specifies the authorization identifier of the schema that is to be unloaded.

12.2 Migrating a stored procedure to another HiRDB system

Executor: HiRDB administrator

The dictionary import/export utility enables a stored procedure that is currently in use to be migrated to another HiRDB system. This facility can be used to achieve the following:

Migrating a stored procedure from a test system to the actual system

Migrating a stored procedure created in one HiRDB system to another HiRDB system

During system reconstruction, storing an existing stored procedure and restoring it after the system has been reconstructed

Organization of this section

12.2.1 Preparations for migrating a stored procedure to another HiRDB system

12.2.2 Example

12.2.1 Preparations for migrating a stored procedure to another HiRDB system

Organization of this subsection

(1) Limitations

(2) Information to be migrated

(3) Rules for migration

(4) Migration procedure

(1) Limitations

A procedure (stored procedure) specified in CREATE TYPE cannot be migrated to another HiRDB system.

(2) Information to be migrated

The following information is migrated:

Table definition information and table data

Stored procedure

(a) Procedure for migrating table definition information and table data

The table definition information and the table data for the table that is used by a stored procedure are migrated to the target system; for the migration procedure, see 12.1 Migrating a table to another HiRDB system.

This procedure can be skipped if the target system already contains the table definition information and table data for the table that is used by the stored procedure.

(b) Procedure for migrating the stored procedure

The dictionary import/export utility (pdexp command) to used to migrate a stored procedure from the data dictionary LOB RDAREAs to the target HiRDB system. Figure 12-5 shows the procedure for migrating a stored procedure with the dictionary import/export utility.

Figure 12-5 Migration of a stored procedure with the dictionary import/export utility

(3) Rules for migration

The stored procedure and the table definition information cannot be migrated at the same time. The table definition information should be migrated first, then the stored procedure can be migrated.

Before migration is performed, the table that is to be migrated and a schema for the stored procedure must be defined in the target system.

Before migration is performed, the data dictionary LOB RDAREAs must be created in the target system.

(4) Migration procedure

Figure 12-6 provides an overview of the procedure for migrating a stored procedure.

Figure 12-6 Procedure for migrating a stored procedure

12.2.2 Example

This example migrates a stored procedure (routine identifier PROC1) and a table (TABLE1) used by the PROC1 stored procedure from HiRDB system A to HiRDB system B.

A LOB column is defined for TABLE1.

An index (INDEX1) is defined for TABLE1.

It is assumed that RDAREAs with the same names (RDAREA1 to RDAREA6) have already been created in the target system.

Organization of this subsection

(1) Enter the pdhold command to shut down RDAREA1 to RDAREA6

(2) Create the control statements file for the pdrorg command

(3) Use the pdrorg command to unload data for TABLE1

(4) Use the pdrels command to release RDAREA1 to RDAREA6 from shutdown status

(5) Create the control statements file for the pdexp command

(6) Use the pdexp command to export table definition information for TABLE1

(7) Create the control statements file for the pdexp command

(8) Use the pdexp command to export the stored procedure

(9) Store the unload data file and export files on a medium such as CMT

(10) Store the unload data file and export files in target system

(11) Use the pddef command to define a schema for the user who owns PROC1 and TABLE1

(12) Use the pdcopy command to back up data

(13) Use the pdexp command to import table definition information for TABLE1

(14) Use the pdhold command to shut down RDAREA1 to RDAREA6

(15) Create the control statements file for the pdrorg command

(16) Use the pdrorg command to reload data for TABLE1

(17) Use the pdcopy command to back up the data

(18) Use the pdrels command to release RDAREA1 to RDAREA6 from shutdown status

(19) Use the pdexp command to import the stored procedure

(1) Enter the pdhold command to shut down RDAREA1 to RDAREA6

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

(2) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

(a) HiRDB/Single Server

unload /pdrorg/unfile1

Explanation

Specifies the name of the unload data file.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1              1
unload bes2:/pdrorg/unfile2              2

Explanation

Specifies the name of the unload data file at a back-end server (bes1).

Specifies the name of the unload data file at a back-end server (bes2).

(3) Use the pdrorg command to unload data for TABLE1

pdrorg -k unld -j -t TABLE1 /pdrorg/rorg01

Explanation

-k: Specifies unld in order to unload data.

-j: Specifies that a table containing a LOB column is to be unloaded.

-t: Specifies the name of the table to be unloaded.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (2).

(4) Use the pdrels command to release RDAREA1 to RDAREA6 from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

(5) Create the control statements file for the pdexp command

The following are the contents of the control statements file (/pdexp/exp01):

-t USR01.TABLE1

Explanation

USR01: Name of the schema that owns TABLE1

TABLE1: Name of the table to be exported

(6) Use the pdexp command to export table definition information for TABLE1

pdexp -e /pdexp/expfile1 -f /pdexp/exp01

Explanation

-e: Specifies the name of the file to be exported.

-f: Specifies the name of the control statements file for the pdexp command created in step (5).

(7) Create the control statements file for the pdexp command

The following are the contents of the control statements file (/pdexp/exp02):

-p USR01.PROC1

Explanation

USR01: Name of the schema that owns PROC1

PROC1: Name of the stored procedure to be exported

(8) Use the pdexp command to export the stored procedure

pdexp -e /pdexp/expfile2 -f /pdexp/exp02

Explanation

-e: Specifies the name of the file to be exported.

-f: Specifies the name of the control statements file for the pdexp command created in step (7).

(9) Store the unload data file and export files on a medium such as CMT

The unload data file created in step (3) and the export files created in steps (6) and (8) are stored on a medium such as CMT.

The operations at the source system (HiRDB system A) are now completed.

(10) Store the unload data file and export files in target system

The operations from this point on are performed at the target system (HiRDB system B).

The unload data file and export files stored on a medium such as CMT are copied into the target system.

(11) Use the pddef command to define a schema for the user who owns PROC1 and TABLE1

pddef
  CREATE SCHEMA AUTHORIZATION USR01;

(12) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r
-r RDMAST,RDDIR,RDDIC,DICLOB,RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,
RDAREA6 -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

The RDAREAs are backed up as a safeguard in the event of errors during database migration. The following RDAREAs must be backed up:

Master directory RDAREA

Data directory RDAREA

Data dictionary RDAREAs

Data dictionary LOB RDAREAs

User RDAREAs and user LOB RDAREAs for storing the imported table (RDAREA1 to RDAREA6)

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-r: Specifies the names of the RDAREAs to be backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination for the pdcopy command's processing results listing.

(13) Use the pdexp command to import table definition information for TABLE1

pdexp -i /pdexp/expfile1

Explanation

-i: Specifies the name of the file to be imported.

(14) Use the pdhold command to shut down RDAREA1 to RDAREA6

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

(15) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg02):

(a) HiRDB/Single Server

unload /pdrorg/unfile1                           1
idxwork /pdrorg/idxwork                          2
sort /sortwork,8192                              3

Explanation

Specifies the name of the unload data file.

Specifies the name of the directory in which an index information file is to be created. The index information file is created under this directory.

Specifies the name of the work directory for sorting.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1                     1
idxwork bes1 /pdrorg/idxwork                    2
sort bes1 /sortwork,8192                        3
unload bes2:/pdrorg/unfile2                     4
idxwork bes2 /pdrorg/idxwork                    5
sort bes2 /sortwork,8192                        6

Explanation

Specifies the name of the unload data file (for bes1).

Specifies the name of the directory in which an index information file is to be created (for bes1). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes1).

Specifies the name of the unload data file (for bes2).

Specifies the name of the directory in which an index information file is to be created (for bes2). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes2).

(16) Use the pdrorg command to reload data for TABLE1

pdrorg -k reld -j -t TABLE1 /pdrorg/rorg01

Explanation

To re-create the index (INDEX1) at the same time, the -i option is omitted and the index batch creation mode is used.

-k: Specifies reld in order to reload data.

-j: Specifies that a table containing a LOB column is to be reloaded.

-t: Specifies the name of the table to be reloaded.

/pdrorg/rorg02: Specifies the name of the control statements file for the pdrorg command created in step (15).

(17) Use the pdcopy command to back up the data

pdcopy -m /rdarea/mast/mast01 -M r
-r RDMAST,RDDIR,RDDIC,DICLOB,RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,
RDAREA6 -b /pdcopy/backup02 -p /pdcopy/list02

Explanation

The following RDAREAs must be backed up:

Master directory RDAREA

Data directory RDAREA

Data dictionary RDAREAs

Data dictionary LOB RDAREAs

User RDAREAs and user LOB RDAREAs for storing the imported table (RDAREA1 to RDAREA6)

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-r: Specifies the names of the RDAREAs to be backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(18) Use the pdrels command to release RDAREA1 to RDAREA6 from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

(19) Use the pdexp command to import the stored procedure

pdexp -i /pdexp/expfile2

Explanation

-i: Specifies the name of the file to be imported.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13. Handling Tables

This chapter explains the procedures for handling tables.

It contains the following sections:

Organization of this chapter

13.1 Checking table storage efficiency

13.2 Reorganizing a table

13.3 Reorganizing a table (examples)

13.4 Predicting table reorganization time (facility for predicting reorganization time)

13.5 Deleting data from a table

13.6 Adding a column

13.7 Deleting a column

13.8 Modifying a table's definition

13.9 Changing a table name or column name

13.10 Increasing the number of table row partitions

13.11 Increasing the number of table row partitions (using the hash facility for hash row partitioning)

13.12 Changing a table's partitioning storage conditions

13.13 Changing a table's partitioning storage conditions

13.14 Changing the hash function

13.15 Changing a table's partitioning definition

13.16 Migrating data to another table

13.17 Deleting a table

13.18 Deleting a schema

13.19 Deleting an abstract data type

13.20 Creating a definition SQL from an existing table

13.21 Managing a list (narrowed search)

13.22 Standardizing spaces in table data

13.23 Converting the sign portion of the decimal type

13.1 Checking table storage efficiency

Executor: HiRDB administrator or DBA privilege holder

As data is added or deleted repeatedly, order is lost in the placement of rows, resulting in a reduction in the data retrieval or data storage efficiency. The HiRDB administrator should check regularly for deterioration in data storage efficiency. If the data storage efficiency does deteriorate, take one of the following actions:

Reorganize the table.

Increase the size of the RDAREA.

Release used free pages or used free segments.

Reference note

HiRDB identifies the tables, indexes, and RDAREAs that require these operations. For details, see 13.4 Predicting table reorganization time (facility for predicting reorganization time).

Organization of this section

13.1.1 Executing the database condition analysis utility on a regular basis

13.1.2 Messages indicating poor data storage efficiency

13.1.3 When expected retrieval performance cannot be achieved

13.1.1 Executing the database condition analysis utility on a regular basis

The database condition analysis utility (pddbst command) should be executed periodically in order to check the data storage efficiency.

Organization of this subsection

(1) Checking table storage efficiency

(2) Checking index storage efficiency

(3) Checking cluster key and clustering data page storage efficiency

(4) Checking data storage efficiency in RDAREAs

(1) Checking table storage efficiency

Table storage efficiency is checked by executing the database condition analysis utility's condition analysis by table. The obtained information is used to determine whether or not the following procedures are necessary:

Table reorganization

Releasing used free pages or used free segments

Deletion of unneeded rows

Changing the table row partitioning storage conditions

Changing the hash function

Re-creating or reorganizing indexes

Expansion, re-initialization, addition, or deletion of RDAREAs

Condition analysis by table cannot be applied to a table for which an abstract data type is defined. In such a case, condition analysis by RDAREA (physical analysis) must be used in order to check the table's data storage efficiency.

(2) Checking index storage efficiency

Index storage efficiency is checked by executing the database condition analysis utility's condition analysis by index. The obtained information is used to determine whether or not the following procedures are necessary:

Re-creating or reorganizing indexes

Releasing used free pages or used free segments

Reducing the number of index page splits

Note, however, that condition analysis by index does not obtain information on plug-in indexes.

(3) Checking cluster key and clustering data page storage efficiency

Cluster key and clustering data page storage efficiency are checked by executing the database condition analysis utility's cluster key and clustering data page storage condition analysis. The obtained information is used to determine whether or not the following procedures are necessary:

Table reorganization

Redefinition of a table with a cluster key specified and without the index component column containing many duplicated data items

Reevaluation of the column structure in the index definition

(4) Checking data storage efficiency in RDAREAs

Data storage efficiency in RDAREAs is checked by executing the database condition analysis utility's condition analysis by RDAREA. The obtained information is used to determine whether or not the following procedures are necessary:

Table reorganization

Re-creating or reorganizing indexes

Releasing used free pages or used free segments.

Changing the table row partitioning storage conditions

Changing the hash function

Expansion, re-initialization, addition, or deletion of RDAREAs

Other methods for checking RDAREA utilization status

The pddbls -a command can be used to check RDAREA utilization status.

The RDAREA utilization status that is output during backup processing by the database copy utility (pdcopy command) can also be used to check the RDAREA storage efficiency.

13.1.2 Messages indicating poor data storage efficiency

When the data storage efficiency becomes poor, HiRDB outputs the following messages:

KFPA12300-I or KFPH00211-I

KFPH00212-I

KFPH22017-I

Organization of this subsection

(1) KFPA12300-I or KFPH00211-I is output

(2) KFPH00212-I is output

(3) KFPH22017-I is output

(1) KFPA12300-I or KFPH00211-I is output

If an RDAREA begins to run out of free space, the KFPA12300-I or KFPH00211-I message is output (indicating the last file in the RDAREA or the overall RDAREA utilization factor).

Action to be taken by the HiRDB administrator

Execute the pddbls -a command or the database condition analysis utility's condition analysis by RDAREA to determine whether or not the RDAREA structure should be modified; for details on RDAREA structure modification, see 15. Handling RDAREAs.

(2) KFPH00212-I is output

When the table retrieval efficiency or storage efficiency has become degraded, the KFPH00212-I message is output.

Action to be taken by the HiRDB administrator

Use conditional analysis by table in the database condition analysis utility to take one of the following actions:

Reorganize the table

Release used free pages and used free segments

For details about reorganizing a table, see 13.2 Reorganizing a table and 13.3 Reorganizing a table (examples); for details about releasing used free pages and used free segments, see 15.9 Re-using used free pages and used free segments.

In the cases listed below, however, you must first use the database structure modification utility (pdmod command) to change the structure of the RDAREA (for details about changing the structure of an RDAREA, see 15. Handling RDAREAs):

This message is issued frequently for tables in the same RDAREA.

This message is issued while a table is being reorganized or immediately after it has been reorganized.

This message is issued while an index is being reorganized or immediately after it has been reorganized.

(3) KFPH22017-I is output

When LOB data retrieval efficiency or storage efficiency is reduced, the KFPH22017-I message is output.

Action to be taken by the HiRDB administrator

Execute the database condition analysis utility's condition analysis by table and determine whether or not table reorganization is called for; for details on table reorganization, see 13.2 Reorganizing a table and 13.3 Reorganizing a table (examples).

The RDAREA to be reorganized depends on the RDAREA type displayed in the KFPH22017-I message:

User LOB RDAREA
Reorganize the LOB data in the user LOB RDAREA.

Data dictionary LOB RDAREA
Reorganize the dictionary tables for the following stored procedures and stored functions:
SQL_ROUTINES
SQL_ROUTINE_RESOURCES
SQL_ROUTINE_PARAMS

13.1.3 When expected retrieval performance cannot be achieved

If expected retrieval performance cannot be achieved, the database condition analysis utility should be executed to check the data storage condition. Based on this information, whether or not the data storage condition should be improved must be evaluated.

To improve the system performance, system tuning may be necessary based on the statistical information that is obtained by executing the following commands:

Statistics analysis utility (pdstedit command)

pdbufls command

For details about system tuning, see 20. Obtaining Tuning Information and 21. Tuning.

13.2 Reorganizing a table

Executor: HiRDB administrator and table owner (or user with DBA privilege)

Organization of this section

13.2.1 Table reorganization

13.2.2 Execution units for table reorganization

13.2.3 Selecting an update log acquisition mode for a database

13.2.4 Before reorganizing a table

13.2.1 Table reorganization

As data is added or deleted repeatedly, the data storage efficiency becomes poor, which has an adverse effect on data retrieval performance. To avoid this, tables should be reorganized periodically with the pdrorg command (database reorganization utility). Figure 13-1 provides an overview of table reorganization processing.

Figure 13-1 Overview of table reorganization processing

Explanation

The table data is copied into an unload data file; this is called table data unloading. The data is then stored back into the table; this is called reloading. This entire process is called table reorganization.

If an index is defined for the table, the index information is output to an index information file when the data is reloaded. HiRDB uses that information to create the index in the batch mode, thus also reorganizing the index.

13.2.2 Execution units for table reorganization

Table reorganization can be executed in the following units:

By table

By RDAREA

By schema

Organization of this subsection

(1) Reorganization by table

(2) Reorganization by RDAREA

(3) Reorganization by schema

(1) Reorganization by table

Reorganization processing can be performed on an entire table; this is the method that is usually used. Reorganization by table is executed when the results of executing the database condition analysis utility indicate that the entire table needs to be reorganized. Figure 13-2 illustrates reorganization of an entire table.

Figure 13-2 Reorganization of an entire table

Note: The data indicated by shading is subject to reorganization.

Explanation

The table to be reorganized is specified in the -t option of the database reorganization utility.

(2) Reorganization by RDAREA

Reorganization by RDAREA reorganizes the RDAREAs in which the table is stored. This method can be used only on tables that are row-partitioned. Reorganization of RDAREAs is executed when the results of the database condition analysis utility indicate that to reorganizing only a portion of a row-partitioned table would suffice. This reduces the processing time compared with reorganization of the entire table. Figure 13-3 illustrates reorganization of an RDAREA.

Figure 13-3 Reorganization of an RDAREA

Note: The data indicated by shading is subject to reorganization.

Explanation

The table to be reorganized is specified in the -t option and the RDAREAs to be reorganized are specified in the -r option of the database reorganization utility.

Reference note

If an RDAREA satisfying all of the conditions listed below is reorganized by RDAREA, a non-partitioning key index will not be created. To create a non-partitioning key index, the database reorganization utility (re-creating an index) must be executed again.

The table to be reorganized has row partitioning within a server.

A non-partitioning key index is defined for the table to be reorganized.

The non-partitioning key index is not row-partitioned.

Figure 13-4 shows an example in which a non-partitioning key index is not created during reorganization by RDAREA.

Figure 13-4 Example in which a non-partitioning key index is not created during reorganization by RDAREA

Explanation

Even though reorganization by RDAREA is applied to RDAREA1, a non-partitioning key index is not created. Index information will simply be output to an index information file. To create a non-partitioning key index, the index must be re-created with the database reorganization utility. Thus, reorganization by table, rather than by RDAREA, is recommended in such a case.

(3) Reorganization by schema

This processing reorganizes all tables in a schema in the batch mode. Reorganization by schema can be used when you wish to reorganize all the tables you own on a batch basis. Figure 13-5 illustrates reorganization of a schema.

Figure 13-5 Reorganization of a schema

Note: The data indicated by shading is subject to reorganization.

Explanation

The authorization identifier of the schema to be reorganized is specified in the -t option of the database reorganization utility. The specification format is -t authorization-identifier.all.

13.2.3 Selecting an update log acquisition mode for a database

The following three update log acquisition modes are provided for reorganizing a database when the database reorganization utility is executed:

Log acquisition mode

Pre-update log acquisition mode (default)

No-log mode

For details about the applicability of these modes, see 7.1 Database update log acquisition modes.

Organization of this subsection

(1) Mode selection criteria

(2) Differences in operating methods

(3) Conditions under which a backup is not needed before reorganizing

(1) Mode selection criteria

In most cases, select the default mode, which is the pre-update log acquisition mode. Consider using another mode only under the following conditions:

Condition | Mode to select
There is a large amount of data to be reorganized, and it will take a long time. | No-log mode
There is very little table data to be reorganized. | Log acquisition mode

(2) Differences in operating methods

The manner in which database reorganization is performed depends on the mode that is selected, as shown in Figure 13-6.

Figure 13-6 Differences in how tables are reorganized depending on the database update log acquisition mode

¹ This step is required when the no-log mode is selected. The backup that is obtained is used to recover the RDAREA in the event the pdrorg command terminates abnormally while the no-log mode is in effect. However, you need not make this backup if the conditions described in (3) Conditions under which a backup is not needed before reorganizing are satisfied.

² This step is required when the pre-update log acquisition mode or the no-log mode is selected. If you do not make a backup at this point, the RDAREAs cannot be recovered to their most recent status with the pdrstr command in the event the need to recover them arises (they cannot be recovered to include the updates implemented by the pdrorg command). The RDAREAs can be recovered only to their status at the time the pdrorg command is executed.

Tip

When the pre-update log acquisition mode or the no-log mode is selected, keep the RDAREAs to be reorganized in shutdown status from steps 1 through 4 (in Figure 13-6). Otherwise, if the need arises to recover the RDAREAs with the pdrstr command, any updates to the RDAREAs that were performed before the backup is made in step 4 will not be recovered. You will only be able to recover the RDAREAs to the point at which the pdrorg command is executed. This is because if the system log files that the pdrstr command uses as input contain logs collected in the pre-update log acquisition mode or the no-log mode, the pdrstr command that is used to recover the RDAREAs will terminate in an error.

(3) Conditions under which a backup is not needed before reorganizing

Normally in the no-log mode, a backup must be made before the pdrorg command is executed. However, if either of the conditions described in 1 and 2 below is satisfied, it is not necessary to make the backup because the RDAREAs can be recovered to their status at the time the pdrorg command executed even if the command terminates abnormally. We do recommended, however, that in general you make a backup, because recovering RDAREAs is simpler if a backup is available.

No.
Condition
How to recover the RDAREAs if an error occurs

1
Unload data can be used to recover the RDAREAs to their status at the time the pdrorg command was executed.
If the RDAREAs contain only the table to be reorganized and its indexes.
Recover with the database reorganization utility (pdmod command) in order to re-initialize the RDAREAs that are being reorganized, and then reload the data.

If all of the following conditions are satisfied:

The table being reorganized contains LOB data.

The RDAREAs contain only a LOB column structure base table being reorganized.

The unload data was obtained by specifying the -j option.

Recover with the database reorganization utility (pdmod command) in order to re-initialize the RDAREAs that are being reorganized, and then specify the -j option.

2
The backup and the system logs can be used to recover the RDAREAs to their status at the time the pdrorg command was executed.
Recover with the pdclose command in order to close the RDAREAs that are being reorganized, the pdlogswap command to swap the system log files, and then the database recovery utility (pdrstr command) to input the system logs output up to this point.

13.2.4 Before reorganizing a table

Organization of this subsection

(1) Reorganizing a table in which a LOB column is defined

(2) Reorganizing a table in which an abstract data type is defined

(3) Reorganizing a table containing a large quantity of data

(4) Reorganizing a table in an RDAREA that is full

(5) When HiRDB Datareplicator is used to link data

(6) Creating an unload data file in a character special file

(7) Size of the file used during reorganization

(8) After reorganization has been completed

(1) Reorganizing a table in which a LOB column is defined

A LOB column structure base table and the LOB data can be reorganized at the same time. It is also possible to reorganize only the LOB column structure base table or only the LOB data. To reorganize at the same time both a table in which a LOB column is defined and the LOB data, Hitachi recommends that the -j option be specified in the pdrorg command.

(2) Reorganizing a table in which an abstract data type is defined

Not all tables in which an abstract data type is defined can be reorganized, as shown in Table 13-1.

Table 13-1 Reorganizability of a table in which an abstract data type is defined

Condition | Reorganizability
Abstract data type provided by a plug-in | Without LOB attribute | Can be reorganized.
With LOB attribute | Only column structure base tables of abstract data type can be reorganized.#
User-defined abstract data type | Can be reorganized.

#: If the plug-in has the UNLOAD facility or the constructor parameter reverse generation facility, the entire table can be reorganized by specifying the -j option.

(3) Reorganizing a table containing a large quantity of data

When a table containing a large quantity of data is to be reorganized, you must consider whether or not reorganization with synchronization points set should be executed.

Normally, while a table is being reorganized, transactions cannot be reconciled until storage processing of all the data has been completed. This means that synchronization point dumps cannot be obtained during execution of the database reorganization utility. If HiRDB terminates abnormally during reorganization of a large quantity of data, it will take a long time to restart HiRDB. To resolve this problem, you can set synchronization points at intervals of any number of data items during storage of the data (reload processing) in order to reconcile transactions. This is called reorganization with synchronization points set.

To perform reorganization with synchronization points set, you must specify a synchronization point lines count, which is the number data items to be stored before a synchronization point is set. This value is specified in the option statement of the database reorganization utility.

Note

Use of this facility reduces processing efficiency because synchronization point processing is also executed.

If the utility terminates abnormally, the error handling that will be required will depend on the timing of the termination; for the error handling methods, see 18.18 When a utility terminates abnormally during execution of a reorganization with synchronization points set.

If a table is row-partitioned into multiple back-end servers, you should consolidate the unload data files (by specifying the -g option in the database reorganization utility). If this is not done, the error handling should the utility terminate abnormally will become quite complicated; for details, see 18.18.3 Actions to be taken when a utility terminates abnormally before unload data files have been consolidated (HiRDB/Parallel Server only).

Because data is stored on a new page for each synchronization point, the number of pages needed for storing data is greater than would be the case if this facility were not used. Therefore, do not use this facility to reorganize a table that is full. If it is used in such a case, a space shortage may cause an error in the database reorganization utility.

Reorganization with synchronization points set cannot be performed on falsification prevented tables.

(4) Reorganizing a table in an RDAREA that is full

The value specified in the PCTFREE operand of CREATE TABLE is used as the percentage of unused space to be left in each page when a table is reorganized. Therefore, if a table in an RDAREA that is full is reorganized, an RDAREA space shortage may occur during table reorganization. To prevent this, you should specify the tblfree and idxfree operands in the option statement of the database reorganization utility (pdrorg command), and change the percentage of unused space per page specified in the PCTFREE operand of CREATE TABLE.

You use the tblfree operand to specify a percentage of unused space in the table, and you use the idxfree operand to specify a percentage of unused space in its indexes.

It must be noted that these are temporary measures that are used when an RDAREA cannot be expanded immediately before table reorganization. In preparation for data updating, you should use the database structure modification utility (pdmod command) to expand the RDAREA so that reorganization can be performed within the value specified in the PCTFREE operand of CREATE TABLE.

(5) When HiRDB Datareplicator is used to link data

When the database reorganization utility is executed on an extracted database, n or p should be specified in the -l option (which specifies execution of the database reorganization utility in the no-log mode or the pre-update log acquisition mode).

When the database reorganization utility is executed in the log acquisition mode, only some of the update information is transferred from the extracted database to the target database, thereby losing conformity between the two databases.

(6) Creating an unload data file in a character special file

To create an unload data file in a character special file, the character special file must be created in a HiRDB file system area for utilities. To do this, UTL must be specified in the -k option of the pdfmkfs command.

(7) Size of the file used during reorganization

If a message reporting a disk space shortage is output during execution of the database reorganization utility, even though ample disk space is available, the following are possible causes:

Use of large files is not specified (pd_large_file_use = Y is not displayed).

The upper limit of the kernel parameter has been exceeded.

In this case, specify use of large files or change the kernel parameter value. You can also avoid the problem by creating multiple unload data files. However, if the OS does not support large files, you must keep the disk partition size to 2 GB or smaller to be able to handle multiple files.

(8) After reorganization has been completed

If necessary, the optimizing information collection utility (pdgetcst command) should be executed after reorganization has been completed. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

13.3 Reorganizing a table (examples)

Executor: HiRDB administrator and table owner (or user with DBA privilege)

This section presents and explains examples of table reorganization. The following is a list of the examples:

Example 1: Reorganizing a table (HiRDB/Single Server)

Example 2: Reorganizing a table (HiRDB/Parallel Server)

Example 3: Reorganizing an RDAREA

Example 4: Reorganizing a schema

Example 5: Reorganizing a table in which a LOB column is defined

Example 6: Reorganizing data dictionary tables

Example 7: Reorganizing in no-log mode

Example 8: Reorganizing a table in which an abstract data type is defined

Organization of this section

13.3.1 Example 1: Reorganizing a table (HiRDB/Single Server)

13.3.2 Example 2: Reorganizing a table (HiRDB/Parallel Server)

13.3.3 Example 3: Reorganizing an RDAREA

13.3.4 Example 4: Reorganizing a schema

13.3.5 Example 5: Reorganizing a table in which a LOB column is defined

13.3.6 Example 6: Reorganizing data dictionary tables

13.3.7 Example 7: Reorganizing in no-log mode

13.3.8 Example 8: Reorganizing a table in which an abstract data type is defined

13.3.1 Example 1: Reorganizing a table (HiRDB/Single Server)

This example reorganizes a row-partitioned table (TABLE1) by table. The conditions for this reorganization are as follows:

TABLE1 is row-partitioned in user RDAREAs (RDAREA1 and RDAREA2).

A row partitioning index (INDEX1) and a non-partitioning key index (INDEX2) are defined for TABLE1.

INDEX1 is row-partitioned in user RDAREAs (RDAREA3 and RDAREA4).

INDEX2 is stored in a user RDAREA (RDAREA5).

The indexes are created in the batch mode (default) when the table is reorganized.

The table is reorganized in the pre-update log acquisition mode (default).

Note: The shaded data will be reorganized.

Procedure

Use the pdhold command to shut down the RDAREAs to be reorganized.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reorganize the table.

Back up the RDAREAs that were reorganized.

Use the pdrels command to release the shutdown status of the RDAREAs.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Hint

Because you are using the pdrorg command in the pre-update log acquisition mode, you must make a backup after executing the pdrorg command, as described in step 4.

Because you are using the pdrorg command in the pre-update log acquisition mode, keep the RDAREAs being reorganized in shutdown status from step 1 through step 4.

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be reorganized

(2) Create the control statements file for the pdrorg command

(3) Use the pdrorg command to reorganize the table

(4) Back up the RDAREAs that were reorganized

(5) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be reorganized

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5

(2) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

unload /pdrorg/unfile1                        1
idxwork /pdrorg/idxwork                       2
sort /sortwork,8192                           3

Explanation

Specifies the name of the unload data file.

Specifies the name of the directory in which an index information file is to be created. The index information file is created under this directory.

Specifies the name of the work directory for sorting.

(3) Use the pdrorg command to reorganize the table

pdrorg -k rorg -t TABLE1 /pdrorg/rorg01

Explanation

Because two indexes (INDEX1 and INDEX2) are to be re-created simultaneously in the batch mode, the -i option is omitted and the indexes are created in the batch index creation mode.

-k: Specifies rorg for reorganization.

-t: Specifies the name of the table that is to be reorganized.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (2).

(4) Back up the RDAREAs that were reorganized

Back up the RDAREAs that were reorganized (RDAREA1 to RDAREA5). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(5) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.3.2 Example 2: Reorganizing a table (HiRDB/Parallel Server)

This example reorganizes a row-partitioned table (TABLE1) by table. The conditions for this reorganization are as follows:

TABLE1 is row-partitioned in user RDAREAs (RDAREA1 and RDAREA2).

A row partitioning index (INDEX1) is defined for TABLE1. INDEX1 is row-partitioned in user RDAREAs (RDAREA3 and RDAREA4).

The index is created in the batch mode (default) when the table is reorganized.

The table is reorganized in the pre-update log acquisition mode (default).

Note: The data indicated by shading is subject to reorganization.

Procedure

Use the pdhold command to shut down the RDAREAs to be reorganized.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reorganize the table.

Back up the RDAREAs that were reorganized.

Use the pdrels command to release the RDAREAs from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Hint

Because you are using the pdrorg command in the pre-update log acquisition mode, you must make a backup after executing the pdrorg command, as described in step 4.

Because you are using the pdrorg command in the pre-update log acquisition mode, keep the RDAREAs being reorganized in shutdown status from steps 1 through 4.

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be reorganized

(2) Create the control statements file for the pdrorg command

(3) Use the pdrorg command to reorganize the table

(4) Back up the RDAREAs that were reorganized

(5) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be reorganized

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4

(2) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

unload bes1:/pdrorg/unfile1                  1
idxwork bes1 /pdrorg/idxwork                 2
sort bes1 /sortwork,8192                     3
unload bes2:/pdrorg/unfile2                  4
idxwork bes2 /pdrorg/idxwork                 5
sort bes2 /sortwork,8192                     6

Explanation

Specifies the name of the unload data file (for bes1).

Specifies the name of the directory in which an index information file is to be created (for bes1). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes1).

Specifies the name of the unload data file (for bes2).

Specifies the name of the directory in which an index information file is to be created (for bes2). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes2).

(3) Use the pdrorg command to reorganize the table

pdrorg -k rorg -t TABLE1 /pdrorg/rorg01

Explanation

Because indexes (INDEX1 and INDEX2) are to be re-created simultaneously in the batch mode, the -i option is omitted and indexes are created in the batch index creation mode.

-k: Specifies rorg for reorganization.

-t: Specifies the name of the table that is to be reorganized.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (2).

(4) Back up the RDAREAs that were reorganized

Back up the RDAREAs that were reorganized (RDAREA1 to RDAREA4). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(5) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.3.3 Example 3: Reorganizing an RDAREA

This example reorganizes a row-partitioned table (TABLE1) by RDAREA. The conditions for this reorganization are as follows:

TABLE1 is row-partitioned in user RDAREAs (RDAREA1 and RDAREA2).

An index (INDEX1) is defined for TABLE1. INDEX1 is row-partitioned in user RDAREAs (RDAREA3 and RDAREA4).

The data to be reorganized is the table data in RDAREA1 and the index data in RDAREA3.

The table is reorganized in the pre-update log acquisition mode (default).

Note: The shaded data will be reorganized.

Procedure

Use the pdhold command to shut down the RDAREAs to be reorganized.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reorganize the table.

Back up the RDAREAs that were reorganized.

Use the pdrels command to release the RDAREAs from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Hint

Because you are using the pdrorg command in the pre-update log acquisition mode, you must make a backup after executing the pdrorg command, as described in step 4.

Because you are using the pdrorg command in the pre-update log acquisition mode, keep the RDAREAs being reorganized in shutdown status from steps 1 through 4.

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be reorganized

(2) Create the control statements file for the pdrorg command

(3) Use the pdrorg command to reorganize the table

(4) Back up the RDAREAs that were reorganized

(5) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be reorganized

pdhold -r RDAREA1,RDAREA3

(2) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

(a) HiRDB\Single Server

unload /pdrorg/unfile1                        1
idxwork /pdrorg/idxwork                       2
sort /sortwork,8192                           3

Explanation

Specifies the name of the unload data file.

Specifies the name of the directory in which an index information file is to be created. The index information file is created under this directory.

Specifies the name of the work directory for sorting.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1                    1
idxwork bes1 /pdrorg/idxwork                   2
sort bes1 /sortwork,8192                       3

Explanation

Specifies the name of the unload data file (for bes1).

Specifies the name of the directory in which an index information file is to be created (for bes1). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes1).

(3) Use the pdrorg command to reorganize the table

pdrorg -k rorg -t TABLE1 -r RDAREA1 /pdrorg/rorg01

Explanation

Because the index data of INDEX1 stored in RDAREA3 is also to be re-created simultaneously, the -i option is omitted and the index is created in the batch index creation mode.

-k: Specifies rorg for reorganization.

-t: Specifies the name of the table that is to be reorganized.

-r: Specifies the name of the RDAREA in which the table (TABLE1) that is to be reorganized is stored.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (2).

(4) Back up the RDAREAs that were reorganized

Back up the RDAREAs that were reorganized (RDAREA1 and RDAREA3). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(5) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA3

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.3.4 Example 4: Reorganizing a schema

This example reorganizes all tables owned by user USR01. The following are the conditions for this reorganization:

The indexes are created in the batch mode (default) when the tables are reorganized.

The tables are reorganized in the pre-update log acquisition mode (default).

Note: The data indicated by shading is subject to reorganization.

Procedure

Use SQL to check for RDAREAs to be reorganized.

Use the pdhold command to shut down the RDAREAs to be reorganized.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reorganize the tables.

Back up the RDAREAs that were reorganized.

Use the pdrels command to release the RDAREAs from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Hint

Because you are using the pdrorg command in the pre-update log acquisition mode, you must make a backup after executing the pdrorg command, as described in step 5.

Because you are using the pdrorg command in the pre-update log acquisition mode, keep the RDAREAs being reorganized in shutdown status from steps 2 through 5.

Organization of this subsection

(1) Use SQL to check for RDAREAs to be reorganized

(2) Use the pdhold command to shut down RDAREAs to be reorganized

(3) Create the control statements file for the pdrorg command

(4) Use the pdrorg command to reorganize the table

(5) Back up the RDAREAs that were reorganized

(6) Use the pdrels command to release RDAREAs from shutdown status

(1) Use SQL to check for RDAREAs to be reorganized

SELECT DISTINCT(RDAREA_NAME) FROM MASTER.SQL_TABLES            1
    WHERE TABLE_SCHEMA=USR01 AND RDAREA_NAME IS NOT NULL;
SELECT DISTINCT(RDAREA_NAME) FROM MASTER.SQL_DIV_TABLE         2
    WHERE TABLE_SCHEMA=USR01;
SELECT DISTINCT(RDAREA_NAME) FROM MASTER.SQL_INDEXES           3
    WHERE TABLE_SCHEMA=USR01 AND RDAREA_NAME IS NOT NULL;
SELECT DISTINCT(RDAREA_NAME) FROM MASTER.SQL_DIV_INDEX         4
    WHERE TABLE_SCHEMA=USR01;

Explanation

Retrieves RDAREAs that store non-row-partitioned tables.

Retrieves RDAREAs that store row-partitioned tables.

Retrieves RDAREAs that store non-row-partitioned indexes.

Retrieves RDAREAs that store row-partitioned indexes.

(2) Use the pdhold command to shut down RDAREAs to be reorganized

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,...

(3) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

(a) HiRDB/Single Server

unload /pdrorg/unfile1                        1
idxwork /pdrorg/idxwork                       2
sort /sortwork,8192                           3

Explanation

Specifies the name of the unload data file.

Specifies the name of the directory in which an index information file is to be created. The index information file is created under this directory.

Specifies the name of the work directory for sorting.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1                  1
idxwork bes1 /pdrorg/idxwork                 2
sort bes1 /sortwork,8192                     3
idxwork bes2 /pdrorg/idxwork                 4
sort bes2 /sortwork,8192                     5

Explanation

Specifies the name of the unload data file. Because the -g option is assumed, the unload data file is created at one location.

Specifies the name of the directory in which an index information file is to be created (for bes1). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes1).

Specifies the name of the directory in which an index information file is to be created (for bes2). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes2).

(4) Use the pdrorg command to reorganize the table

pdrorg -k rorg -t USR01.all /pdrorg/rorg01

Explanation

Because indexes (INDEX1 and INDEX2) are to be re-created simultaneously, the -i option is omitted and the indexes are created in the batch index creation mode.

-k: Specifies rorg for reorganization.

-t: Specifies the authorization identifier of the schema that is to be reorganized.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (2).

Remarks

When reorganization by schema is specified, the -j option (reorganization when LOB data is present) and the -g option (unload data file standardization) are assumed.

(5) Back up the RDAREAs that were reorganized

Back up the RDAREAs that were reorganized (RDAREA1 to RDAREA8). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(6) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.3.5 Example 5: Reorganizing a table in which a LOB column is defined

This example reorganizes by table a table (TABLE1) in which a LOB column is defined; the LOB data is reorganized at the same time. The conditions for this reorganization are as follows:

The LOB column structure base table is row-partitioned in user RDAREAs (RDAREA1 and RDAREA2).

The LOB data is row-partitioned in user LOB RDAREAs (RDAREA3 and RDAREA4).

An index (INDEX1) is defined for TABLE1. INDEX1 is row-partitioned in user RDAREAs (RDAREA5 and RDAREA6).

The index is created in the batch mode (default) when the table is reorganized.

The table is reorganized in the pre-update log acquisition mode (default).

Note: The data indicated by shading is subject to reorganization.

Procedure

Use the pdhold command to shut down the RDAREAs to be reorganized.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reorganize the table.

Back up the RDAREAs that were reorganized.

Use the pdrels command to release the RDAREAs from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Hint

Because you are using the pdrorg command in the pre-update log acquisition mode, you must make a backup after executing the pdrorg command, as described in step 4.

Because you are using the pdrorg command in the pre-update log acquisition mode, keep the RDAREAs being reorganized in shutdown status from steps 1 through 4.

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be reorganized

(2) Create the control statements file for the pdrorg command

(3) Use the pdrorg command to reorganize the table

(4) Back up the RDAREAs that were reorganized

(5) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be reorganized

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

(2) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

(a) HiRDB/Single Server

unload /pdrorg/unfile1                        1
idxwork /pdrorg/idxwork                       2
sort /sortwork,8192                           3

Explanation

Specifies the name of the unload data file.

Specifies the name of the directory in which an index information file is to be created. The index information file is created under this directory.

Specifies the name of the work directory for sorting.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1                   1
idxwork bes1 /pdrorg/idxwork                  2
sort bes1 /sortwork,8192                      3
unload bes2:/pdrorg/unfile2                   4
idxwork bes2 /pdrorg/idxwork                  5
sort bes2 /sortwork,8192                      6

Explanation

Specifies the name of the unload data file (for bes1).

Specifies the name of the directory in which an index information file is to be created (for bes1). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes1).

Specifies the name of the unload data file (for bes2).

Specifies the name of the directory in which an index information file is to be created (for bes2). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes2).

(3) Use the pdrorg command to reorganize the table

pdrorg -k rorg -j -t TABLE1 /pdrorg/rorg01

Explanation

Because an index (INDEX1) is also to be re-created simultaneously, the -i option is omitted and the index is created in the batch index creation mode.

-k: Specifies rorg for reorganization.

-j: Specifies that the table to be reorganized contains a LOB column.

-t: Specifies the name of the table that is to be reorganized.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (2).

(4) Back up the RDAREAs that were reorganized

Back up the RDAREAs that were reorganized (RDAREA1 to RDAREA6). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(5) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.3.6 Example 6: Reorganizing data dictionary tables

This example reorganizes data dictionary tables that are stored in the data dictionary RDAREA (DATADIC) and in a data dictionary LOB RDAREA (DATALOB). Reorganize the dictionary table in the pre-update log acquisition mode (default).

Procedure

Use the pdhold command to shut down the data dictionary RDAREA and data dictionary LOB RDAREA.

Back up the data dictionary RDAREA and the data dictionary LOB RDAREA.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reorganize the dictionary table.

Back up the data dictionary RDAREA and the data dictionary LOB RDAREA.

Use the pdrels command to release the data dictionary RDAREA and data dictionary LOB RDAREA from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Hint

Because you are using the pdrorg command in the pre-update log acquisition mode, keep the data dictionary RDAREA and data dictionary LOB RDAREA being reorganized in shutdown status from steps 1 through 5.

Organization of this subsection

(1) Use the pdhold command to shut down the data dictionary RDAREA and data dictionary LOB RDAREA

(2) Back up the data dictionary RDAREA and the data dictionary LOB RDAREA

(3) Create the control statements file for the pdrorg command

(4) Use the pdrorg command to reorganize the data dictionary table

(5) Back up the data dictionary RDAREA and the data dictionary LOB RDAREA

(6) Use the pdrels command to release the data dictionary RDAREA and data dictionary LOB RDAREA from shutdown status

(7) Note

(1) Use the pdhold command to shut down the data dictionary RDAREA and data dictionary LOB RDAREA

You will be backing up the RDAREAs while they are in shutdown status. After you have backed them up, keep the RDAREAs in shutdown status so that other users do not update their contents.

pdhold -r DATADIC,DATALOB

(2) Back up the data dictionary RDAREA and the data dictionary LOB RDAREA

To be prepared for the possibility that the RDAREAs will prove to be too small during reorganization, back up the data dictionary RDAREA and the data dictionary LOB RDAREA. If the size of the data dictionary RDAREA or the data dictionary LOB RDAREA becomes insufficient during reorganization, you will have to be able to recover the RDAREAs from a backup. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(3) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

unload /pdrorg/unfile1                       1
lobunld /pdrorg/unfile2                      2

Explanation

Specifies the name of the unload data file for the data dictionary RDAREA.

Specifies the name of the unload data file for the data dictionary LOB RDAREA.

(4) Use the pdrorg command to reorganize the data dictionary table

pdrorg -k rorg -c dic /pdrorg/rorg01

Explanation

-k: Specifies rorg in order to execute reorganization.

-c: Specifies that a data dictionary table is to be reorganized.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (3).

(5) Back up the data dictionary RDAREA and the data dictionary LOB RDAREA

Back up the data dictionary RDAREA and the data dictionary LOB RDAREA (DATADIC and DATALOB). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(6) Use the pdrels command to release the data dictionary RDAREA and data dictionary LOB RDAREA from shutdown status

pdrels -r DATADIC,DATALOB

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(7) Note

Exercise caution if the following error occurs during the reorganization of a dictionary table:

Although unloading was completed, during reloading a capacity shortage occurred in the data dictionary RDAREA.

In such a case, use the procedure explained below to reorganize the dictionary table.

Procedure

Using the backup made before reorganizing, execute the database recovery utility to recover the data dictionary RDAREA and the data dictionary LOB RDAREA.

Use the database reorganization utility to expand or add the data dictionary RDAREA and the data dictionary LOB RDAREA.

Reorganize the dictionary table again.
Using the unload data file created before the error occurred (before the RDAREAs were expanded or added), perform everything but reloading.

13.3.7 Example 7: Reorganizing in no-log mode

This example reorganizes a row-partitioned table (TABLE1) by table. The conditions for this reorganization are as follows:

TABLE1 is row-partitioned in user RDAREAs (RDAREA1 and RDAREA2).

An index (INDEX1) is defined for TABLE1. INDEX1 is row-partitioned in user RDAREAs (RDAREA3 and RDAREA4).

The index is to be created in the batch mode when the table is reorganized.

The table is to be reorganized in the pre-update log acquisition mode or the no-log mode.

Note: The data indicated by shading is subject to reorganization.

Procedure

Use the pdhold command to shut down the RDAREAs to be reorganized.

Back up the RDAREAs to be reorganized.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reorganize the table.

Back up the RDAREAs that were reorganized.

Use the pdrels command to release the RDAREAs from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Hint

Because you are using the pdrorg command in the no-log mode, you must make a backup before you execute the pdrorg command. This backup will be used to recover the RDAREAs if the pdrorg command terminates abnormally. However, you need not make this backup if certain conditions are met. For details about these conditions, see 13.2.3(3) Conditions under which a backup is not needed before reorganizing.

Because you are using the pdrorg command in the no-log mode, you must make a backup after executing the pdrorg command, as described in step 5.

Because you are using the pdrorg command in the no-log mode, keep the RDAREAs being reorganized in shutdown status from steps 1 through 5.

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be reorganized

(2) Back up the RDAREAs to be reorganized

(3) Create the control statements file for the pdrorg command

(4) Use the pdrorg command to reorganize the table

(5) Back up the RDAREAs that were reorganized

(6) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be reorganized

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4

(2) Back up the RDAREAs to be reorganized

Back up the RDAREAs to be reorganized (RDAREA1 to RDAREA4). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(3) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

(a) HiRDB/Single Server

unload /pdrorg/unfile1                        1
idxwork /pdrorg/idxwork                       2
sort /sortwork,8192                           3

Explanation

Specifies the name of the unload data file.

Specifies the name of the directory in which an index information file is to be created. The index information file is created under this directory.

Specifies the name of the work directory for sorting.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1                  1
idxwork bes1 /pdrorg/idxwork                 2
sort bes1 /sortwork,8192                     3
unload bes2:/pdrorg/unfile2                  4
idxwork bes2 /pdrorg/idxwork                 5
sort bes2 /sortwork,8192                     6

Explanation

Specifies the name of the unload data file (for bes1).

Specifies the name of the directory in which an index information file is to be created (for bes1). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes1).

Specifies the name of the unload data file (for bes2).

Specifies the name of the directory in which an index information file is to be created (for bes2). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes2).

(4) Use the pdrorg command to reorganize the table

pdrorg -k rorg -t TABLE1 -l n /pdrorg/rorg01

Explanation

To re-create the index (INDEX1) at the same time, the -i option is omitted and the index batch creation mode is used.

-k: Specifies rorg in order to execute reorganization.

-t: Specifies the name of the table to be reorganized.

-l: Specifies the no-log mode (n).

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (2).

(5) Back up the RDAREAs that were reorganized

Back up the RDAREAs that were reorganized (RDAREA1 to RDAREA4). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(6) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.3.8 Example 8: Reorganizing a table in which an abstract data type is defined

This example reorganizes a table (TABLE1) in which is defined an abstract data type (GEOMETRY or FILELINK type) without the LOB attribute. For an example of reorganizing with an abstract data type (SGMLTEXT type) and the LOB attribute, see 13.3.5 Example 5: Reorganizing a table in which a LOB column is defined. The following are the conditions for this reorganization:

TABLE1 is row-partitioned in user RDAREAs (RDAREA1 and RDAREA2)

The table is reorganized in the pre-update log acquisition mode (default).

Note: The data indicated by shading is subject to reorganization.

Procedure

Use the pdhold command to shut down the RDAREAs to be reorganized.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reorganize the table.

Back up the RDAREAs that were reorganized.

Use the pdrels command to release the RDAREAs from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Hint

Because you are using the pdrorg command in the pre-update log acquisition mode, you must make a backup after executing the pdrorg command, as described in step 4.

Because you are using the pdrorg command in the pre-update log acquisition mode, keep the RDAREAs being reorganized in shutdown status from steps 1 through 4.

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be reorganized

(2) Create the control statements file for the pdrorg command

(3) Use the pdrorg command to reorganize the table

(4) Back up the RDAREAs that were reorganized

(5) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be reorganized

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

(2) Create the control statements file for the pdrorg command

The following are the contents of the control statements file (/pdrorg/rorg01):

(a) HiRDB/Single Server

unload /pdrorg/unfile1                        1
idxwork /pdrorg/idxwork                       2
sort /sortwork,8192                           3

Explanation

Specifies the name of the unload data file.

Specifies the name of the directory in which an index information file is to be created. The index information file is created under this directory.

Specifies the name of the work directory for sorting.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1                  1
idxwork bes1 /pdrorg/idxwork                 2
sort bes1 /sortwork,8192                     3
unload bes2:/pdrorg/unfile2                  4
idxwork bes2 /pdrorg/idxwork                 5
sort bes2 /sortwork,8192                     6

Explanation

Specifies the name of the unload data file (for bes1).

Specifies the name of the directory in which an index information file is to be created (for bes1). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes1).

Specifies the name of the unload data file (for bes2).

Specifies the name of the directory in which an index information file is to be created (for bes2). The index information file is created under this directory.

Specifies the name of the work directory for sorting (for bes2).

(3) Use the pdrorg command to reorganize the table

pdrorg -k rorg -t TABLE1 /pdrorg/rorg01

Explanation

-k: Specifies rorg for reorganization.

-t: Specifies the name of the table that is to be reorganized.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command created in step (2).

(4) Back up the RDAREAs that were reorganized

Back up the RDAREAs that were reorganized (RDAREA1 to RDAREA6). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(5) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5,RDAREA6

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.4 Predicting table reorganization time (facility for predicting reorganization time)

Executor: User with DBA privilege

This section explains how to predict the time at which it will be necessary to reorganize a table (including indexes) or expand an RDAREA. The following items are explained:

Predicting reorganization time

Preparations for using the facility for predicting reorganization time

Operational flow

Notes on using the facility for predicting reorganization time

Stopping reorganization time prediction

Customizing reorganization time prediction

Organization of this section

13.4.1 Predicting reorganization time

13.4.2 Preparations for using the facility for predicting reorganization time

13.4.3 Operational flow

13.4.4 Notes on using the facility for predicting reorganization time

13.4.5 Stopping reorganization time prediction

13.4.6 Customizing reorganization time prediction

13.4.1 Predicting reorganization time

In the past, to determine when it was necessary to reorganize tables and indexes or to expand RDAREAs, the user had to make a comprehensive evaluation of the tables to be reorganized, and of the timing for reorganization based on messages that were output, and of the execution results of the pddbst command. This meant that there was a risk that tables that didn't need to be reorganized were reorganized, and that tables that needed to be reorganized were not reorganized because output messages were not read.

To simplify these operations, HiRDB can now predict when reorganization will become necessary. This is called the facility for predicting reorganization time. Figure 13-7 provides an overview of the facility for predicting reorganization time.

Figure 13-7 Overview of the facility for predicting reorganization time

* The scheduled date on which an RDAREA will need to be maintained is called the scheduled database maintenance date. For an overview of how HiRDB analyzes prediction data, see 13.4.6(1) HiRDB's analysis of prediction data.

Reorganization time prediction is divided into the following two phases:

Phase 1: Collection of reorganization time prediction data

The pddbst command is executed regularly to accumulate database analysis results in a database state analyzed table.

When any of the SQL statements or commands listed below is executed, database management history information is output to a database management table:
Definition SQL (DROP SCHEMA, DROP TABLE, DROP INDEX, ALTER TABLE)
Data manipulation SQL (PURGE TABLE)
pdrorg command
pdreclaim command
pdload command
pdmod command

Phase 2: Analysis of reorganization time prediction data
Using the database state analyzed table and the database management table as input information, the pddbst command is executed to analyze the reorganization time prediction data. The user views the execution results of the pddbst command and takes one of the actions listed below, as appropriate. Note that RDAREA automatic extension is performed automatically by HiRDB if automatic extension was specified when the RDAREA was created (no user action is required).

Execution of the pdrorg command to reorganize a table or index

Execution of the pdreclaim command to release free pages and segments that are being used

Execution of the pdmod command to extend an RDAREA

RDAREA automatic extension

Execution of the pdmod command to re-initialize an RDAREA

Reference note

Prediction levels 1 and 2 are supported by the facility for predicting reorganization time. Prediction level 1 is used principally to monitor space shortages in RDAREAs. Prediction level 2 is used to monitor the effect of poor data storage efficiency on online performance as well as to monitor space shortages in RDAREAs.

Because the primary purpose of the facility for predicting reorganization time is to prevent RDAREA space shortages, this facility predicts reorganization time by assuming the maximum amount of data storage after reorganization. For example, a branched row (where data is partitioned and stored on multiple pages) is assumed to remain a branched row after reorganization. Therefore, when determining whether to reorganize a table or extend an RDAREA, the facility tends to predict RDAREA extension.

13.4.2 Preparations for using the facility for predicting reorganization time

Before using the facility for predicting reorganization time, the preparations explained in this subsection must be performed.

Organization of this subsection

(1) Creating a data dictionary RDAREA for storing the database state analyzed table and database management table

(2) Specifying the pd_rorg_predict operand

(3) Estimating the size of the system log file

(1) Creating a data dictionary RDAREA for storing the database state analyzed table and database management table

After estimating the size of the data dictionary RDAREA for storing the database state analyzed table and the database management table, use the database structure modification utility (pdmod command) to create a data dictionary RDAREA.

For details about how to estimate the size of a data dictionary RDAREA for storing a database state analyzed table and database management table, see the manual HiRDB Version 8 Installation and Design Guide.

Reference note

If a space shortage occurs in the data dictionary RDAREA for storing the database state analyzed table and database management table, HiRDB cannot predict reorganization time (although such a space shortage does not cause an error in SQL statements or commands).

If the initial estimate results in a space shortage because a table has been extended, extend the data dictionary RDAREA that stores the database state analyzed table and database management table.

(2) Specifying the pd_rorg_predict operand

Specify Y in the pd_rorg_predict operand.

(3) Estimating the size of the system log file

Whenever the database state analyzed table or the database management table is updated, a system log is output. For this reason, you must re-estimate the size of the system log file. For details about how to estimate the size of the system log file, see the manual HiRDB Version 8 Installation and Design Guide.

Reference note

For a HiRDB/Parallel Server, system log information is output to system log files at the dictionary server.

13.4.3 Operational flow

This subsection describes the operational flow for predicting the reorganization timing. For prediction level 1, see (1); for prediction level 2, see (1) and (2).

Organization of this subsection

(1) For prediction level 1

(2) For prediction level 2

(1) For prediction level 1

Figure 13-8 shows the operational flow for predicting table reorganization time.

Figure 13-8 Operational flow for predicting table reorganization time

(a) Collecting data for predicting reorganization time

Execute the command shown below to collect data for predicting reorganization time and to store the data in the database state analyzed table. You should execute this command on a daily basis to accumulate data for predicting reorganization time.

pddbst -k logi -r ALL -e 1

Note

The operation in step (a) must be performed at least four times before going on to step (b); otherwise, the pddbst command terminates in an error. In determining the number of times step (a) has been performed, you cannot count an execution of the command if there has been no change in RDAREA status since the last time the command was executed. In other words, an execution of step (a) counts only if there has been a change in RDAREA status. For details, see 13.4.4(2)(a) When prediction data has not been collected correctly.

Reference note

If the data storage status has changed significantly, there is a high probability that reorganization will be required. Therefore, after you update a large volume of data, Hitachi recommends that you perform the operations in steps (a) and (b).

(b) Checking for RDAREAs whose scheduled database maintenance date is approaching

Execute the command shown below to check for RDAREAs that are close to their scheduled database maintenance date. You should execute this command on a daily basis.

pddbst -k pred -r ALL -e 1

A listing is produced of RDAREAs that are close to their scheduled database maintenance dates. An example follows:

Output example

pddbst 07-02       ***** Rdarea resource forecast *****     2005/05/15 11:07:10
No         Date        RdareaName                       ResKind  
---------- ----------- -------------------------------- ----------
        1 2005/05/31  "RDUSER01"                       Segment
        2 2005/06/01  "RDUSER02"                       Segment
---------- ----------- -------------------------------- ----------

Explanation

Date: Displays the scheduled database maintenance dates.

RdareaName: Displays the RDAREAs that will require maintenance.

Note

Because a scheduled database maintenance date is simply an estimate, an RDAREA space shortage may occur before the scheduled date depending on operations.

Reference note

It may take a considerable amount of time for the pddbst command in step (c) to execute. To avoid adverse effects on online jobs, you should execute the operations in steps (b) and (c) during time periods when online jobs will not be affected adversely.

If the execution time of the operation in step (c) does not pose a problem, you may skip the operation in step (b) and perform only the operation in step (c).

(c) Identifying the resources that require maintenance and the maintenance methods

If the results of step (b) identify RDAREAs that are close to their scheduled database maintenance dates, execute the command shown below to check for the tables, indexes, and RDAREAs that require maintenance.

pddbst -k pred -r ALL -e 1 -m

Tables, indexes, and RDAREAs that need to be maintained are listed, together with the appropriate maintenance method for each RDAREA. An output example follows:

Output example

pddbst 07-02       ***** Rdarea resource forecast *****     2005/05/15 11:07:10
No         Date        RdareaName                       ResKind  
---------- ----------- -------------------------------- ----------
        1 2005/05/31  "RDUSER01"                       Segment
        2 2005/06/01  "RDUSER02"                       Segment
---------- ----------- -------------------------------- ----------

pddbst 07-02       ***** Maintenance Information *****      2005/05/15 11:07:10
No          : 1
Rdarea Name : "RDUSER01"
Method      :          ...[1]
Segment     : 42560
--------------------------------------------------------------------------------------
Reclaim      Reorganize   Type Name                                        Date
------------- ------------ ---- ------------------------------------------- ----------
     28089 *       9363    T   "k1234567​"."table01"   ...[2]               2005/05/31
         0        12342 *  T   "k1234567​"."table02"   ...[3]               2005/05/31
       851         7235 *  I   "k1234567​"."index01"   ...[4]               2005/05/31
         3          -10    T   "k1234567​"."table10"   ...[5]               2005/05/31
======================================================================================
No          : 2
Rdarea Name : "RDUSER02"
Method      : Expand   ...[6]
Segment     : 1523
--------------------------------------------------------------------------------------
Reclaim      Reorganize   Type Name                                        Date
------------- ------------ ---- ------------------------------------------- ----------
       228         1035    T   "k1234567​"."table01"                        2005/06/03
         0          121    T   "k1234567​"."table03"                        2005/06/03
        30           60    I   "k1234567​"."index07"                        2005/06/03
======================================================================================

Explanation

For RDAREA RDUSER01, there is no entry in the Method field, so no maintenance is necessary for this RDAREA.

There is an asterisk (*) in the Reclaim field for the table named table01 in RDAREA RDUSER01. This means that the pdreclaim command can be used to release free pages and segments that are being used.

There is an asterisk (*) in the Reorganize field for the table named table02 in RDAREA RDUSER01. This means that the pdrorg command can be used to reorganize this table.

There is an asterisk (*) in the Reorganize field for the index named index01 in RDAREA RDUSER01. This means that the pdrorg command can be used to reorganize this index.

There is no asterisk (*) shown for the table named table10 in RDAREA RDUSER01. This means that no maintenance is necessary for this table.

For RDAREA RDUSER02, an RDAREA maintenance method is shown in the Method field. The following entries can appear in the Method field:
Expand: Expand the RDAREA. In this example, the number of segments that need to be expanded is 1523, as shown in the Segment field.
Extend: HiRDB will extend the RDAREA automatically.
Reinit: Re-create the database (unload the data from the RDAREA, reinitialize the RDAREA, and then reload the unloaded data).
No display: No maintenance is necessary for the RDAREA.

Reference note

The meanings of the other headers follow:
Type: Indicates the resource type:
T: Table
I: Index
L: LOB RDAREA
Name: Table name or index name.
Date: Scheduled maintenance date.

The number of segments shown is the minimum number of segments that need to be expanded by the scheduled maintenance date. It is advisable to expand more segments than the indicated number. Note that there is a limit to the number of times an RDAREA can be expanded.

(d) Maintaining the database

Pursuant to instructions issued by HiRDB, you should take one of the following actions, as appropriate:

Reorganize a table.

Reorganize an index.

Expand an RDAREA.

Reinitialize an RDAREA.

Note

Do not perform the operation in step (a) while any of the operations in step (d) is underway. Otherwise, correct predictions cannot be made.

(2) For prediction level 2

For the collection of reorganization time prediction data under prediction level 1, the facility collects information for the RDAREAs only; therefore, only the directory pages are subject to analysis. Under prediction level 2, on the other hand, the facility also collects information for each table and each index, so the data and index pages also require analysis. This means that the execution time required for pddbst to collect prediction data is longer under prediction level 2 than under prediction level 1.

If reorganization time prediction data is collected under prediction level 2 while an online job is executing, there may be adverse effects on the application. To minimize the effects on the online job application, you can choose one (or both) of the following execution methods:

Interval analysis

Merge analysis

For details about interval analysis and merge analysis, see the manual HiRDB Version 8 Command Reference.

13.4.4 Notes on using the facility for predicting reorganization time

Organization of this subsection

(1) Resources that are excluded from predictions

(2) Cases in which correct prediction cannot be made

(3) Prediction trend

(4) When a user-defined abstract data type exists

(5) Limits during prediction

(6) Reorganizing the database state analyzed table and the database management table

(7) Prediction accuracy

(8) Relationship between database recovery and prediction of reorganization timing

(1) Resources that are excluded from predictions

The following type of user LOB RDAREA is excluded from reorganization time prediction:

User LOB RDAREA that stores a plug-in index

(2) Cases in which correct prediction cannot be made

Correct reorganization time prediction cannot be made in the cases explained below.

(a) When prediction data has not been collected correctly

For the facility for predicting reorganization time to be able to execute, at least four rounds of prediction data reflecting data storage status changes must have been accumulated. In addition, if prediction data is not collected regularly, it may not be possible to make valid predictions. For example, if prediction data is collected only for the first four days of the week in a system that is updated at the end of each week, valid predictions will not be forthcoming.

Reference note

The more regularly prediction data is collected, the higher the prediction accuracy becomes.

(b) Operation in which data storage status changes abruptly

Because HiRDB predicts future usage based on the historical record of the percentages of segments used in an RDAREA, it cannot make valid predictions if the data storage status changes abruptly. Figure 13-9 shows an example.

Figure 13-9 Example in which valid prediction cannot be made due to abrupt changes in the data storage status

Note: For the standard value, see 13.4.6 Customizing reorganization time prediction.

(c) When a table is stored in an RDAREA that does not have an optimum page size

When a table is stored in an RDAREA that does not have an optimum page size matching the table row length, reorganization time cannot be predicted correctly. For example, reorganization may be performed on a table that will not benefit from reorganization, or a reorganization instruction may be issued immediately following reorganization.

(d) Operation in which both the original RDAREA and a replica RDAREA coexist in the current RDAREA

Reorganization time prediction is targeted at the original RDAREA. A replica RDAREA is not the target of reorganization time prediction. Results of a command and SQL analysis for the replica RDAREA are not incorporated into the database state analyzed table or database management table. Therefore, correct prediction results cannot be computed if both the original RDAREA and the replica RDAREA coexist in the current RDAREA.

(e) Rebalancing table in which key values are not balanced

When you define a rebalancing table, you should select a hash function and a partitioning key that result in a uniform distribution of the data. If the key values are not balanced, too much data may be stored in a particular hash group (segment), and as a result, correct prediction will not be possible.

(3) Prediction trend

If a table satisfies all of the following conditions, the prediction is likely to call for RDAREA expansion:

Variable-length character strings (VARCHAR, NVARCHAR, or MVARCHAR) are defined in the table.

The no-split option is not defined for these variable-length character strings.

The data was stored using a method other than by data-loading with the pdload command.

(4) When a user-defined abstract data type exists

If a user-defined abstract data type (an abstract data type that is not provided by a plug-in) is defined for a table, reorganization by the pdrorg command or release of free pages being used by the pdreclaim command cannot be executed. Consequently, no reorganization instruction will be issued. If an RDAREA contains only such a table, only an RDAREA expansion or re-initialization instruction can be issued.

(5) Limits during prediction

If a variable-length character string (VARCHAR, NVARCHAR, or MVARCHAR) whose actual length is 255 bytes or less branches to another page (for example, the case in which data of 256 bytes or larger is updated so that it becomes 255 bytes or smaller), reorganization can cancel the branching and improve storage efficiency and access efficiency. However, because the data length information is not collected, it cannot be incorporated into the prediction.

In the case of a table that has the data type of variable-length character string for which NO SPLIT is not specified, if there is a large amount of data whose actual length is shorter than the page length, many pages with poor usage rate result even immediately after reorganization. As a result, customization by the standard value definition file becomes necessary.

(6) Reorganizing the database state analyzed table and the database management table

When the dictionary table is reorganized, both the database state analyzed table and the database management table are also subject to reorganization. Reorganize these tables together with other dictionary tables. There is no need to reorganize only the database state analyzed table and the database management table.

Reference note

When a large number of tables and indexes are deleted, invalid areas are created in the indexes that are defined to improve access efficiency to the two tables. However, because these areas are reused when new tables and indexes are defined, there is no need to reorganize these areas if the data dictionary RDAREA has sufficient capacity.

(7) Prediction accuracy

In the case of prediction level 1, when there is only one resource in an RDAREA (for example, only a single table is stored in the RDAREA), prediction is made based on the information in the database state analyzed table and database management table. When there are multiple resources in an RDAREA, prediction is made based on the information in the database state analyzed table only. Therefore, prediction accuracy is higher in the first case than in the second.

(8) Relationship between database recovery and prediction of reorganization timing

The reorganization timing is predicted on the basis of the database's history. If the database is not restored after a failure to its most recent status (such as when the database is restored to the point where a backup was made), correct prediction cannot be achieved. In such a case, correct prediction can be obtained by resetting the base information for prediction. This is called resetting the accumulated condition analysis results. For details about resetting the accumulated condition analysis results, see the manual HiRDB Version 8 Command Reference.

13.4.5 Stopping reorganization time prediction

To stop reorganization time prediction, change the specification value for the pd_rorg_predict operand to N. To resume reorganization time prediction, change the operand value back to Y.

To completely terminate use of reorganization time prediction and to use the data dictionary RDAREA that stores the database state analyzed table and database management table as a user RDAREA, first use the pdmod command to delete the data dictionary RDAREA that stores the database state analyzed table and database management table (do not delete them while the pddbst command is executing); then, either change the specification value for the pd_rorg_predict operand to N or delete this operand.

13.4.6 Customizing reorganization time prediction

Organization of this subsection

(1) HiRDB's analysis of prediction data

(2) Customizing the standard value

(1) HiRDB's analysis of prediction data

HiRDB predicts a scheduled database maintenance date based on the historical trend of the percentage of segments used in an RDAREA. Figure 13-10 provides an overview of how HiRDB analyzes prediction data.

Figure 13-10 Overview of how HiRDB analyzes prediction data

Explanation

The date on which the percentage of segments being used in the RDAREA is predicted to exceed the standard value (the default is 80%) is used as the scheduled database maintenance date.

You can change the standard value in the standard value definition file. For details about the standard value definition file, see the manual HiRDB Version 8 Command Reference.

(2) Customizing the standard value

If the standard value is not appropriate for your operations, such as when the storage conditions change before the predicted database maintenance date because initial data loading is performed periodically, you can change the standard value to customize the reorganization time prediction performed by HiRDB.

13.5 Deleting data from a table

Executor: Table owner or DELETE privilege holder

The DELETE or the PURGE TABLE statement is used to delete an unneeded row from a table.

Hint

When a row is deleted from a view table, the corresponding row is deleted from its base table.

For falsification prevented tables, only rows whose deletion prevented duration has elapsed can be deleted.

Organization of this section

(1) Deleting a selected row

(2) Deleting all rows

(1) Deleting a selected row

To delete a selected row, the WHERE clause must be specified in the DELETE statement.

(2) Deleting all rows

To delete all rows from a table, the following SQL must be executed:

DELETE statement with the WHERE clause not specified

PURGE TABLE statement

Points to be considered

When all rows are to be deleted from a table that contains many rows, the PURGE TABLE statement deletes rows faster than the DELETE statement.

When many rows are to be deleted with the DELETE statement, the lock mode should be set by first executing the LOCK statement with EXCLUSIVE specified in order to reduce the overhead for exclusive control.

Deleting many rows with the DELETE statement has no effect on the free space in the user RDAREAs, because the segments remain allocated. To create free space, the PURGE TABLE statement must be used.

13.6 Adding a column

Executor: HiRDB administrator and table owner

You add a column to a table by executing ALTER TABLE with the ADD operand specified.

Organization of this section

13.6.1 Preparations for adding a column

13.6.2 Example 1: Adding a column to a table without the FIX attribute

13.6.3 Example 2: Adding a LOB column

13.6.4 Example 3: Adding an abstract data type column

13.6.5 Example 4: Adding a column to a table with the FIX attribute (unloading in DAT format)

13.6.6 Example 5: Adding a column to a table with the FIX attribute (unloading in binary format)

13.6.1 Preparations for adding a column

Organization of this subsection

(1) Notes on adding a column to a table with the FIX attribute

(2) Notes

(1) Notes on adding a column to a table with the FIX attribute

A column cannot be added to a table with the FIX attribute in which data is stored. If it is necessary to add a column to a table with the FIX attribute in which data is stored, you must use the following procedure:

Procedure

Use the pdrorg command to unload the table data.

Use the PURGE TABLE statement to delete the table data.

Use the ALTER TABLE statement to add a column.

Use the pdhold command to shut down RDAREAs storing the table.

Use the pdload command to load the table data.

Use the pdcopy command to back up the table.

Use the pdrels command to release the RDAREAs from shutdown status.

Notes

Either DAT or binary format can be used for unloading the table's data in step 1. It is preferable to use DAT format because it is a simpler operation.

If the table contains character data that cannot be converted to DAT format (0x00 and 0x0a), the table data cannot be unloaded in DAT format; binary format must be used in such a case.

For an example of unloading a table in DAT format, see 13.6.5 Example 4: Adding a column to a table with the FIX attribute (unloading in DAT format).

For an example of unloading a table in binary format, see 13.6.6 Example 5: Adding a column to a table with the FIX attribute (unloading in binary format).

(2) Notes

Columns cannot be added to falsification prevented tables.

Adding a column to a table invalidates any stored routines that use that table. If this happens, use the ALTER PROCEDURE or ALTER ROUTINE statement to re-create each stored routine.

Adding a NOT NULL column to a table specified in a trigger SQL statement invalidates the trigger. If this happens, use the ALTER TRIGGER or ALTER ROUTINE statement to re-create the trigger.

After the column has been added to the table, execute the optimizing information collection utility (pdgetcst command) if necessary. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

13.6.2 Example 1: Adding a column to a table without the FIX attribute

This example adds a column (C4) to a table without the FIX attribute (TABLE01).

Organization of this subsection

(1) Use ALTER TABLE to add column C4

(1) Use ALTER TABLE to add column C4

ALTER TABLE TABLE01 ADD C4 INTEGER;

In this case, the null value is stored in column C4.

13.6.3 Example 2: Adding a LOB column

This example adds a BLOB type column (C4) to a table (TABLE01). The data for column C4 is stored in user LOB RDAREAs (ULOB01 and ULOB02).

Organization of this subsection

(1) Use ALTER TABLE to add column C4

(1) Use ALTER TABLE to add column C4

ALTER TABLE TABLE01 ADD C4 BLOB(1M) IN ((ULOB1),(ULOB2));

In this case, the null value is stored in column C4.

13.6.4 Example 3: Adding an abstract data type column

A column (C4) of the SGMLTEXT type is added to a table (TABLE01). The data for column C4 is stored in user LOB RDAREAs (ULOB01 and ULOB02).

Organization of this subsection

(1) Use ALTER TABLE to add column C4

(1) Use ALTER TABLE to add column C4

ALTER TABLE TABLE01 ADD C4 SGMLTEXT
   ALLOCATE(SGMLTEXT IN ((ULOB1),(ULOB2))
   PLUGIN plug-in-option;

ALTER TABLE TABLE01 ADD C4 SGMLTEXT
   ALLOCATE(SGMLTEXT IN ((ULOB1),(ULOB2)))
   PLUGIN plug-in-option;

In this case, the null value is stored in column C4.

13.6.5 Example 4: Adding a column to a table with the FIX attribute (unloading in DAT format)

This example adds a column (C4) to a table with the FIX attribute (TABLE01).

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

(2) Use the pdrorg command to unload data from TABLE01

(3) Use the pdrels command to release RDAREAs from shutdown status

(4) Use the PURGE TABLE statement to delete data from TABLE01

(5) Use the ALTER TABLE statement to add column C4

(6) Create the column structure information file (/pdload/column01)

(7) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

(8) Load data into TABLE01

(9) Back up the RDAREAs in which data was loaded

(10) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

pdhold -r RDAREA1,RDAREA2,...

(2) Use the pdrorg command to unload data from TABLE01

pdrorg -k unld -W dat -t TABLE01 -g /pdrorg/unld01

Explanation

-k: Specifies unld for unloading.

-W dat: Specifies that the unload data file is to be used as the input file (DAT format) for the pdload command.

-t: Specifies the name of the table that is to be unloaded.

-g: Specifies that TABLE01 is row-partitioned between servers in a HiRDB\Parallel Server. Specifying the -g option consolidates the unload data files (into a single file).

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command.

(3) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,...

(4) Use the PURGE TABLE statement to delete data from TABLE01

PURGE TABLE TABLE01;

(5) Use the ALTER TABLE statement to add column C4

ALTER TABLE TABLE01 ADD C4 INTEGER WITH DEFAULT;

The WITH DEFAULT operand must be specified in this step. In this case, 0 is stored in column C4.

(6) Create the column structure information file (/pdload/column01)

C1
C2
C3

Because the format of the column structure of the input data file created in step (2) differs from the column structure of TABLE01, a column structure information file is needed for data loading.

Note on specifying a column structure information file

When a column structure information file is specified after a column has been added, it is important not to specify the added column. That way, HiRDB will detect that the input data does not contain any data for that column and will store the default value or the NULL value in the added column. Because the NULL value cannot be stored in a table with the FIX attribute, the default value must be stored in such a case by specifying the WITH DEFAULT operand when the column is added with an ALTER TABLE statement.

(7) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

pdhold -r RDAREA1,RDAREA2,...

(8) Load data into TABLE01

pdload -c /pdload/column01 TABLE01 /pdload/load01

Explanation

-c /pdload/column01: Specifies the name of the column structure information file created in step (6).

TABLE01: Specifies the name of the table into which the data is to be loaded.

/pdload/load01: Specifies the name of the control statements file for the pdload command.

(9) Back up the RDAREAs in which data was loaded

Because you loaded data in the pre-update acquisition mode (default), back up the RDAREAs in which data was loaded. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(10) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.6.6 Example 5: Adding a column to a table with the FIX attribute (unloading in binary format)

This example adds a column (C4) to a table with the FIX attribute (TABLE01). It is assumed that the table contains character data (0x00 and 0x0a) that cannot be converted to DAT format.

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

(2) Use the pdrorg command to unload data from TABLE01

(3) Use the pdrels command to release RDAREAs from shutdown status

(4) Use the PURGE TABLE statement to delete data from TABLE01

(5) Use the ALTER TABLE statement to add column C4

(6) Create the column structure information file (/pdload/column01)

(7) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

(8) Load data into TABLE01

(9) Back up the RDAREAs in which data was loaded

(10) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

pdhold -r RDAREA1,RDAREA2,...

(2) Use the pdrorg command to unload data from TABLE01

pdrorg -k unld -W bin -t TABLE01 -g /pdrorg/unld01

Explanation

-k: Specifies unld for unloading.

-W bin: Specifies that the unload data file is to be used as the input file (binary format) for the pdload command. Because TABLE01 contains character data (0x00 and 0x0a) that cannot be converted to DAT format, the data is converted to binary format and unloaded.

-t: Specifies the name of the table that is to be unloaded.

-g: Specifies that TABLE01 is row-partitioned between servers in a HiRDB/Parallel Server. Specifying the -g option consolidates the unload data files (into a single file).

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command.

(3) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,...

(4) Use the PURGE TABLE statement to delete data from TABLE01

PURGE TABLE TABLE01;

(5) Use the ALTER TABLE statement to add column C4

ALTER TABLE TABLE01 ADD C4 INTEGER WITH DEFAULT;

The WITH DEFAULT operand must be specified in this step. In this case, 0 is stored in column C4.

(6) Create the column structure information file (/pdload/column01)

C1,type=char(4)
C2,type=char(10)
C3,type=integer

A column structure information file in which the data types of TABLE01 are specified is created.

Although a binary format file was created in step (2), it is treated as a fixed-size data format file because the table has the FIX attribute. Therefore, a column structure information file necessary for unloading data from a fixed-size data format file is created. This way, data can be loaded into TABLE01, which has a column structure that is different from the column structure of the input data file.

Note on specifying a column structure information file

When a column structure information file is specified after a column has been added, it is important not to specify the added column. That way, HiRDB will detect that the input data does not contain any data for that column and will store the default value or the NULL value in the added column. Because the NULL value cannot be stored in a table with the FIX attribute, the default value must be set in such a case by specifying the WITH DEFAULT operand when the column is added with an ALTER TABLE statement.

(7) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

pdhold -r RDAREA1,RDAREA2,...

(8) Load data into TABLE01

pdload -a -c /pdload/column01 TABLE01 /pdload/load01

Explanation

-a: Specifies that the input file is a fixed-size data format file.

-c /pdload/column01: Specifies the name of the column structure information file created in step (6).

TABLE01: Specifies the name of the table into which the data is to be loaded.

/pdload/load01: Specifies the name of the control statements file for the pdload command.

(9) Back up the RDAREAs in which data was loaded

Because you loaded data in the pre-update acquisition mode (default), back up the RDAREAs in which data was loaded. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(10) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.7 Deleting a column

Executor: HiRDB administrator and table owner

You delete a column from a table by executing ALTER TABLE with the DROP operand specified.

Notes

A column of a table in which data is stored cannot be deleted.

A column for which a cluster key is defined cannot be deleted.

A LOB column cannot be deleted.

If an abstract data type is defined for a table, none of the columns in that table can be deleted.

Columns cannot be deleted from falsification prevented tables.

Deleting a column from a table invalidates any stored routines that use that table. If this happens, use the ALTER PROCEDURE or ALTER ROUTINE statement to re-create each stored routine.

Deleting a column from a table specified in a trigger SQL statement invalidates the trigger. In addition, deleting a column that is accessed by the trigger action condition or from within an SQL statement using an old and new values correlation name invalidates the trigger. If this happens, use the ALTER TRIGGER or ALTER ROUTINE statement to re-create the trigger.

After the column has been deleted from the table, execute the optimizing information collection utility (pdgetcst command) if necessary. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

Organization of this section

13.7.1 Example: Deleting a column

13.7.1 Example: Deleting a column

This example deletes a column (C4) from a table (TABLE01).

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

(2) Use the pdrorg command to unload data from TABLE01

(3) Use the pdrels command to release RDAREAs from shutdown status

(4) Use the PURGE TABLE statement to delete data from TABLE01

(5) Use the ALTER TABLE statement to delete column C4

(6) Create the column structure information file (/pdload/column01)

(7) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

(8) Load data into TABLE01

(9) Back up the RDAREAs in which data was loaded

(10) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

pdhold -r RDAREA1,RDAREA2,...

(2) Use the pdrorg command to unload data from TABLE01

pdrorg -k unld -W dat -t TABLE01 -g /pdrorg/unld01

Explanation

-k: Specifies unld for unloading.

-W dat:

Specifies that the unload data file is to be used as the input file (DAT format) for the pdload command.

If the table contains character data (0x00 and 0x0a) that cannot be converted to DAT format, the table data cannot be unloaded in DAT format. In such a case, the data must be unloaded in binary format (-W bin specified); note that the operations in the steps beginning with step (6) will be different. See 13.6.6 Example 5: Adding a column to a table with the FIX attribute (unloading in binary format).

-t: Specifies the name of the table that is to be unloaded.

-g: Specifies that TABLE01 is row-partitioned between servers in a HiRDB/Parallel Server. Specifying the -g option consolidates the unload data files (into a single file).

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command.

(3) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,...

(4) Use the PURGE TABLE statement to delete data from TABLE01

PURGE TABLE TABLE01;

(5) Use the ALTER TABLE statement to delete column C4

ALTER TABLE TABLE01 DROP C4;

(6) Create the column structure information file (/pdload/column01)

C1
C2
C3
*skipdata*

Because the format of the column structure of the input data file created in step (2) is different from the column structure of TABLE01, a column structure information file is needed for data loading.

(7) Use the pdhold command to shut down RDAREAs in which TABLE01 is stored

pdhold -r RDAREA1,RDAREA2,...

(8) Load data into TABLE01

pdload -c /pdload/column01 TABLE01 /pdload/load01

Explanation

-c /pdload/column01: Specifies the name of the column structure information file created in step (6).

TABLE01: Specifies the name of the table into which the data is to be loaded.

/pdload/load01: Specifies the name of the control statements file for the pdload command.

(9) Back up the RDAREAs in which data was loaded

Because you loaded data in the pre-update acquisition mode (default), back up the RDAREAs in which data was loaded. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(10) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA1,RDAREA2,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.8 Modifying a table's definition

Executor: Table owner

You modify a table's definition by executing ALTER TABLE with the CHANGE operand specified. The following definitions can be modified:

Data size of a variable-length character string

Change from CHAR to MCHAR

Maximum number of elements in repetition columns

Changing the non-NULL value constraint without a default value to one with a default value

Changing a cluster key without the uniqueness constraint to one with the uniqueness constraint

Changing a cluster key with the uniqueness constraint to one without the uniqueness constraint

Minimum unit of locked resources for the table

Hash function

Notes

The definition of a LOB column cannot be modified.

The definition of an abstract data type column cannot be modified.

Changing the definition of a table invalidates any stored routines that use that table. If this happens, use the ALTER PROCEDURE or ALTER ROUTINE statement to re-create each stored routine.

Changing the definition of a table specified in a trigger SQL statement invalidates the trigger. In addition, deleting a column that is accessed by the trigger action condition or from within an SQL statement using an old and new values correlation name invalidates the trigger. If the trigger becomes invalid, use the ALTER TRIGGER or ALTER ROUTINE statement to re-create the trigger.

After a table's definition has been changed, execute the optimizing information collection utility (pdgetcst command) if necessary. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

Organization of this section

13.8.1 Example: Changing the data size of a column

13.8.1 Example: Changing the data size of a column

This example changes the definition size of the DATA01 column in the TABLE01 table from VARCHAR(150) to VARCHAR(200).

Organization of this subsection

(1) Use the ALTER TABLE statement to change the definition of column DATA01

(1) Use the ALTER TABLE statement to change the definition of column DATA01

ALTER TABLE TABLE01 CHANGE DATA01 VARCHAR(200);

13.9 Changing a table name or column name

Executor: Table owner

You modify a table name or column name by executing ALTER TABLE with the RENAME operand specified.

Note

The table name or column name of a falsification prevented table cannot be changed.

Changing a table name or column name invalidates any stored routines that use that table. If this happens, use the ALTER PROCEDURE or ALTER ROUTINE statement to re-create each stored routine.

Changing a table name or column name of a table specified in a trigger SQL statement invalidates the trigger. If this happens, use the ALTER TRIGGER or ALTER ROUTINE statement to re-create the trigger.

The table name of a table that defines a trigger cannot be changed.

The column names of the following columns cannot be changed in a table that defines a trigger:
Trigger event column
Column that is referenced by a trigger action condition using an old and new values correlation name
Column that is referenced by a trigger SQL statement using an old and new values correlation name

Organization of this section

13.9.1 Example 1: Changing a table name

13.9.2 Example 2: Changing a column name

13.9.1 Example 1: Changing a table name

This example changes the name of a table from TABLE01 to TABLE02.

Organization of this subsection

(1) Use the ALTER TABLE statement to change a table's name

(1) Use the ALTER TABLE statement to change a table's name

ALTER TABLE TABLE01 RENAME TABLE TO TABLE02;

13.9.2 Example 2: Changing a column name

This example changes the name of column C1 in table TABLE01 to C2.

Organization of this subsection

(1) Use the ALTER TABLE statement to change a column's name

(1) Use the ALTER TABLE statement to change a column's name

ALTER TABLE TABLE01 RENAME COLUMN FROM C1 TO C2;

13.10 Increasing the number of table row partitions

Executor: HiRDB administrator and table owner (or user with DBA privilege)

When the amount of data in a table increases significantly because data is added repeatedly, processing performance for the table may become degraded. In such a case, it is advisable to increase the number of table row partitions.

Notes

In the case of a table with key range partitioning, first use DROP TABLE to delete the table, then use CREATE TABLE to redefine the table. While you are redefining the table, you can increase the number of table row partitions.

In a table with hash partitioning, you use ALTER TABLE to increase the number of table row partitions.

Increasing the number of row partitions in a table invalidates any stored routines that use that table. If this happens, use the ALTER PROCEDURE or ALTER ROUTINE statement to re-create each stored routine.

Increasing the number of row partitions in a table specified in a trigger SQL statement invalidates the trigger. If this happens, use the ALTER TRIGGER or ALTER ROUTINE statement to re-create the trigger.

After the number of table row partitions has been increased, execute the optimizing information collection utility (pdgetcst command) if necessary. Note, however, that this utility cannot be applied to an abstract data type. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

Organization of this section

13.10.1 Example 1: Increasing the number of row partitions in a table with key range partitioning

13.10.2 Example 2: Increasing the number of row partitions in a table with flexible hash partitioning

13.10.3 Example 3: Increasing the number of row partitions in a table with FIX hash partitioning

13.10.1 Example 1: Increasing the number of row partitions in a table with key range partitioning

This example increases from 2 to 3 the number of row partitions for table TABLE01. Its index (INDX01) is partitioned likewise. TABLE01 is key-range partitioned.

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be unloaded

(2) Use the pdrorg command to unload data from TABLE01

(3) Use the pdrels command to release RDAREAs from shutdown status

(4) Use the DROP TABLE statement to delete TABLE01

(5) Use the CREATE TABLE and CREATE INDEX statements to redefine TABLE01 and INDEX01, respectively

(6) Use the pdhold command to shut down RDAREAs to be reloaded

(7) Use the pdrorg command to reload data into TABLE01

(8) Back up the RDAREAs in which data was reloaded

(9) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be unloaded

pdhold -r RDAREA01,RDAREA02,...

(2) Use the pdrorg command to unload data from TABLE01

pdrorg -k unld -j -t TABLE01 -g /pdrorg/unld01

Explanation

-k: Specifies unld for unloading.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be unloaded.

-t: Specifies the name of the table that is to be unloaded.

-g: Specifies that TABLE01 is row-partitioned between servers in a HiRDB/Parallel Server. Specifying the -g option consolidates the unload log data (into a single file).

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command.

(3) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

(4) Use the DROP TABLE statement to delete TABLE01

DROP TABLE TABLE01;

(5) Use the CREATE TABLE and CREATE INDEX statements to redefine TABLE01 and INDEX01, respectively

CREATE TABLE TABLE01 ...
   IN ((RDAREA01),(RDAREA02),(RDAREA03)) ...;
CREATE INDEX INDX01 ...
   IN ((RDAREA11),(RDAREA12),(RDAREA13));

(6) Use the pdhold command to shut down RDAREAs to be reloaded

pdhold -r RDAREA01,RDAREA02,...

(7) Use the pdrorg command to reload data into TABLE01

pdrorg -k reld -j -t TABLE01 -g /pdrorg/reld01

Explanation

-k: Specifies reld for reloading.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be reloaded.

-t: Specifies the name of the table that is to be reloaded.

-g: If the -g option was specified in step (2), specify it here as well.

/pdrorg/reld01: Specifies the name of the control statements file for the pdrorg command.

(8) Back up the RDAREAs in which data was reloaded

Because you reloaded data in the pre-update acquisition mode (default), back up the RDAREAs in which data was reloaded. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(9) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.10.2 Example 2: Increasing the number of row partitions in a table with flexible hash partitioning

This example increases from 2 to 3 the number of row partitions for table TABLE01. Its index (INDEX01) is partitioned likewise. TABLE01 is flexible hash partitioned.

It is assumed that this table does not use the hash facility for hash row partitioning.

Organization of this subsection

(1) Use the ALTER TABLE statement to add RDAREA03 to TABLE01

(1) Use the ALTER TABLE statement to add RDAREA03 to TABLE01

ALTER TABLE TABLE01 ADD RDAREA RDAREA03;

In this step, no data is stored in RDAREA03. Data that will be added subsequently will be stored using a hash function.

When the hash facility for hash row partitioning is used, data will be stored in RDAREA03, and this will prevent an imbalance in the amount of data stored in the existing RDAREAs and in the newly added RDAREA. For an example of the hash facility for hash row partitioning, see 13.11 Increasing the number of table row partitions (using the hash facility for hash row partitioning).

13.10.3 Example 3: Increasing the number of row partitions in a table with FIX hash partitioning

This example increases from 2 to 3 the number of row partitions in table TABLE01. Its index (INDEX01) is partitioned likewise. TABLE01 is FIX hash partitioned.

It is assumed that this table does not use the hash facility for hash row partitioning. When this hash facility is used, an RDAREA can be added with an ALTER TABLE statement even if the table contains data. Consequently, there is no need to unload and reload the table data. For an example of the hash facility for hash row partitioning, see 13.11 Increasing the number of table row partitions (using the hash facility for hash row partitioning).

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be unloaded

(2) Use the pdrorg command to unload data from TABLE01

(3) Use the pdrels command to release RDAREAs from shutdown status

(4) Use the PURGE TABLE statement to delete TABLE01's data

(5) Use the ALTER TABLE statement to add RDAREA03 to TABLE01

(6) Use the pdhold command to shut down RDAREAs to be reloaded

(7) Use the pdrorg command to reload data into TABLE01

(8) Back up the RDAREAs in which data was reloaded

(9) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be unloaded

pdhold -r RDAREA01,RDAREA02,...

(2) Use the pdrorg command to unload data from TABLE01

pdrorg -k unld -j -t TABLE01 -g /pdrorg/unld02

Explanation

-k: Specifies unld for unloading.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be unloaded.

-t: Specifies the name of the table that is to be unloaded.

-g: Specifies that TABLE01 is row-partitioned between servers in a HiRDB/Parallel Server. Specifying the -g option consolidates the unload data files (into a single file).

/pdrorg/unld02: Specifies the name of the control statements file for the pdrorg command.

(3) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

(4) Use the PURGE TABLE statement to delete TABLE01's data

PURGE TABLE TABLE01;

To increase the number of row partitions in a table with FIX hash partitioning, the data in the table must be deleted.

(5) Use the ALTER TABLE statement to add RDAREA03 to TABLE01

ALTER TABLE TABLE01 ADD RDAREA RDAREA03;

(6) Use the pdhold command to shut down RDAREAs to be reloaded

pdhold -r RDAREA01,RDAREA02,...

(7) Use the pdrorg command to reload data into TABLE01

pdrorg -k reld -j -t TABLE01 -g /pdrorg/reld02

Explanation

-k: Specifies reld for reloading.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be reloaded.

-t: Specifies the name of the table that is to be reloaded.

-g: If the -g option was specified in step (2), specify it here as well.

/pdrorg/reld02: Specifies the name of the control statements file for the pdrorg command.

(8) Back up the RDAREAs in which data was reloaded

Because you reloaded data in the pre-update acquisition mode (default), back up the RDAREAs in which data was reloaded. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(9) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.11 Increasing the number of table row partitions (using the hash facility for hash row partitioning)

Executor: HiRDB administrator and table owner

This section explains how to increase the number of row partitions using the hash facility for hash row partitioning. The following items are explained here:

Overview of hash facility for hash row partitioning

Preparations for using hash facility for hash row partitioning

Example: Increasing the number of row partitions in a rebalancing table

Using the rebalancing utility (when table rebalancing takes time)

Notes on a table with FIX hash partitioning

Organization of this section

13.11.1 Overview of the hash facility for hash row partitioning

13.11.2 Preparations for using the hash facility for hash row partitioning

13.11.3 Example: Increasing the number of row partitions in a rebalancing table

13.11.4 Using the rebalancing utility (when table rebalancing takes time)

13.11.5 Notes on a table with FIX hash partitioning

13.11.1 Overview of the hash facility for hash row partitioning

When the data volume in a table with hash partitioning has increased and an RDAREA is added (i.e., when the number of table row partitions is increased), an imbalance will occur between the amount of data in the existing RDAREAs and the amount of data in the newly added RDAREA. When the hash facility (rebalancing facility) for hash row partitioning is used, such an imbalance in the amount of data in the RDAREAs can be corrected. Figure 13-11 shows the hash facility for hash row partitioning.

Note that the hash facility for hash row partitioning can be applied to both FIX hashing and flexible hashing.

Figure 13-11 Hash facility for hash row partitioning

Explanation

Because data has filled the hash partitioned table, an RDAREA for storing the hash partitioned table is added (the number of table row partitions is increased). No data is placed in the added RDAREA, resulting in a data volume imbalance.

The rebalancing utility (pdrbal command) is executed to correct the data volume imbalance. Executing this utility relocates data by moving it by hash group. This is called table rebalancing.
When the hash facility for hash row partitioning is used, HiRDB divides the data into 1024 groups (called a hash group) based on the hashing result of the partitioning key. RDAREA segments are allocated to these groups to store the data. Data relocating is also carried out using the hash group as the unit.

Organization of this subsection

(1) Application criteria

(2) Note

(3) Procedure

(1) Application criteria

When the data volume is expected to increase and RDAREAs are likely to be added in the future#

When it is difficult to re-create a table because of a large amount of data

#: An RDAREA cannot be added to a table with FIX hash partitioning if data is stored in it (this applies to a table with FIX hash partitioning that uses one of the hash functions HASH1 to HASH6). However, with the rebalancing facility, an RDAREA can be added to a table with FIX hash partitioning that uses one of the hash functions HASHA to HASHF.

(2) Note

The amount of data in each hash group depends on the hashing result of the hash function. Therefore, if the partitioning key values are not distributed evenly, the data volume will also be uneven among the hash groups, and it may not be possible to divide the data evenly among the RDAREAs.

(3) Procedure

Following is an overview of the procedure for applying the hash facility for hash row partitioning:

Procedure

To apply the has facility:

When a hash partitioned table is defined, define it as a rebalancing table.

To increase the number of table row partitions, add an RDAREA to be used to store the table's data.

Rebalance the table by executing the rebalancing utility.#

#: The execution modes shown in Table 13-2 are available for the rebalancing utility.

Table 13-2 Rebalancing utility execution modes

Execution mode
Explanation

Shared mode
Table can be accessed while it is being rebalanced.
In a very large database, table rebalancing may take as long as several days. Access to the table can be permitted while rebalancing is underway. However, because table access and table rebalancing are being executed simultaneously, the efficiency of both processes is degraded. To minimize such degradation, it is possible to divide the rebalancing process into multiple segments to be executed at times when the operational workload is low.

Exclusive mode
Table cannot be accessed while it is being rebalanced.
Because only rebalancing is executed, processing efficiency is higher than in the shared mode. If it is possible to suspend accesses to the table, executing the rebalancing utility in the exclusive mode is recommended.
The rebalancing process can be divided into multiple segments in the exclusive mode as well.

13.11.2 Preparations for using the hash facility for hash row partitioning

Organization of this subsection

(1) Defining a rebalancing table

(2) RDAREAs for storing a rebalancing table

(3) Defining an index for a rebalancing table

(4) Global buffer

(1) Defining a rebalancing table

You must specify in CREATE TABLE one of HASHA to HASHF as the hash function. A table for which one of these hash functions is specified is called a rebalancing table. For details on the hash functions HASHA to HASHF, see the manual HiRDB Version 8 SQL Reference.

CREATE TABLE TABLE01
   (PCODE DEC(5) NOT NULL,PNAME NCHAR(15), ... ) HASH HASHF BY PCODE
    IN (RDAREA01,RDAREA02);
CREATE INDEX INDX01 ...
    IN ((RDAREA11),(RDAREA12));

(2) RDAREAs for storing a rebalancing table

RDAREAs in which a rebalancing table is stored can accommodate only the rebalancing table; other tables or indexes cannot be stored in these RDAREAs.

An RDAREA for storing a rebalancing table requires the following number of segments: 1024 partitioning-RDAREAs-count. This condition must be satisfied when the RDAREAs are created.

In estimating the size of an RDAREA, you should add some margin to the number of segments computed from 1024 partitioning-RDAREAs-count.

Unused segments are needed in order to store data in a rebalancing table. For this reason, the RDAREA full error will result even if the RDAREA contains free pages. Therefore, you should manage the remaining space in the RDAREA by number of unused segments, rather than by number of free pages.

(3) Defining an index for a rebalancing table

An RDAREA for storing a rebalancing table can store only that rebalancing table; other tables or indexes cannot be stored. Therefore, when CREATE INDEX is specified for a rebalancing table, the names of the RDAREAs for storing the index cannot be omitted. If they are omitted, an RDAREA that stores the rebalancing table will be assumed, resulting in an error. An RDAREA that stores the rebalancing table must not be specified for an index.

A cluster key index cannot be defined.

(4) Global buffer

For each RDAREA that is storing the table, you must set the global buffer sectors count to at least 1024 partitioning-RDAREAs-count 2. Otherwise, the effects of buffering will not be realized.

13.11.3 Example: Increasing the number of row partitions in a rebalancing table

This example increases from 2 to 3 the number of row partitions in rebalancing table TABLE01. Its index (INDX01) is partitioned likewise.

Note

In order to execute the rebalancing utility, the number of RDAREAs storing indexes must match the number of RDAREAs storing tables.

Organization of this subsection

(1) Use the pdfmkfs command to create a HiRDB file system area for RDAREAs

(2) Use the pdmod command to add RDAREAs

(3) Use the ALTER TABLE statement to increase the number of table row partitions

(4) Use the pdrbal command to rebalance the table

(5) Use the pdgetcst command to collect optimization information for the table

(1) Use the pdfmkfs command to create a HiRDB file system area for RDAREAs

pdfmkfs -n 50 -l 10 -k DB -i /rdarea/area03
pdfmkfs -n 50 -l 10 -k DB -i /rdarea/area13

Explanation

-n: Specifies in megabytes the size of the HiRDB file system area. Use the database condition analysis utility (pddbst command) to analyze the status of the existing RDAREAs, and, taking existing RDAREAs into account, estimate the size of the RDAREAs to be added from the volume of data to be migrated.

-l: Specifies the maximum number of HiRDB files to be created in the HiRDB file system area.

-k: Specifies the purpose of the HiRDB file system area. Specify DB to create a HiRDB file system area for RDAREAs.

-i: Specifies that the entire HiRDB file system area is to be initialized. When the -i option is specified, the entire area is allocated. When the -i option is omitted, only management information for the HiRDB file system area is created.

/rdarea/area03: Specifies a name for the HiRDB file system area that is to be created for RDAREAs to be used to store tables.

/rdarea/area13: Specifies the name of the HiRDB file system area that is to be created for RDAREAs to be used to store indexes.

(2) Use the pdmod command to add RDAREAs

pdmod -a /pdmod/create01

Explanation

-a: Specifies the name of the control statements file for the pdmod command. Below is an example of a control statements file. For details on the operands, see the manual HiRDB Version 8 Command Reference.

create rdarea RDAREA03
  globalbuffer gbuf03
  for user used by PUBLIC
  server name bes1
  page 4096 characters
  storage control segment 10 pages
  file name "/rdarea/area03/file01"
     initial 1000 segments;
create rdarea RDAREA13
  globalbuffer gbuf13
  for user used by PUBLIC
  server name bes1
  page 4096 characters
  storage control segment 10 pages
  file name "/rdarea/area13/file01"
     initial 1000 segments;

(3) Use the ALTER TABLE statement to increase the number of table row partitions

ALTER TABLE TABLE01
   ADD RDAREA RDAREA03
     FOR INDEX INDX01 IN RDAREA13;

An RDAREA for storing table data (RDAREA03) and an RDAREA for storing indexes (RDAREA13) have been added. The number of row partitions in TABLE01 has now been increased from 2 to 3.

(4) Use the pdrbal command to rebalance the table

(a) Execution in shared mode

pdrbal -k share -t TABLE01 -c 100 /pdrbal/cfile01

Explanation

-k: Specifies share for execution in the shared mode.

-t: Specifies the name of the rebalancing table.

-c: Specifies the unit of commitment.

/pdrbal/cfile01: Specifies the name of the control statements file for the pdrbal command. The following are the contents of the control statements file:

report /tmp/output
execstop time,9:00

Explanation

report: Specifies the output destination for the execution results of the pdrbal command.

execstop: Specifies the execution time for the pdrbal command.

(b) Execution in exclusive mode

pdrbal -k exclusive -t TABLE01 -l a /pdrbal/cfile01

Explanation

-k: Specifies exclusive for execution in the exclusive mode.

-t: Specifies the name of the rebalancing table.

-l: Specifies the method for collecting the database updates log. In this example, the log acquisition mode is specified.

/pdrbal/cfile01: Specifies the name of the control statements file for the pdrbal command. The following are the contents of the control statements file:

report /tmp/output
idxwork /index/work
sort /sort/work

Explanation

report: Specifies the output destination for the execution results of the pdrbal command.

idxwork: Specifies the name of the directory for output of the index information file.

sort: Specifies the name of the work directory for sorting.

(5) Use the pdgetcst command to collect optimization information for the table

If necessary, use the optimizing information collection utility (pdgetcst command) to collect optimization information for the table. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

pdgetcst -t TABLE01 -l /pdgetcst/output

Explanation

-t: Specifies the name of the table for which optimization information is to be collected.

-l: Specifies the output destination for the execution results of the pdgetcst command.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.11.4 Using the rebalancing utility (when table rebalancing takes time)

This section explains how to use the rebalancing utility when table rebalancing (processing by the rebalancing utility) takes time.

Organization of this subsection

(1) Shared mode

(2) Exclusive mode

(1) Shared mode

When the shared mode is specified, accesses to the table being rebalanced are permitted while rebalancing is being executed. This mode is effective when online operations must continue around the clock; the explanation here assumes around-the-clock operations.

Guidelines on usage

Execute the rebalancing utility at times when the operational workload is relatively light.

If the rebalancing utility's processing cannot be completed in a single operation, divide the task into multiple segments for execution of the rebalancing utility.

Application example

Because the workload is relatively light between 21:00 and 9:00, specify that the rebalancing utility will be executed at 21:00, and specify with the execstop time operand in the control statements file that the utility is to execute for up to 12 hours.

Example of command

pdrbal -k share -t TABLE01 -c 100 /pdrbal/cfile01

Contents of control statements file

execstop time,12:00

Return code

If rebalancing processing is not completed within 12 hours (is still executing at 9:00), the rebalancing utility terminates with return code 4 and the rebalancing processing terminates. Execute the rebalancing utility again at 21:00. Repeat each day until rebalancing is completed and return code 0 is returned.

(2) Exclusive mode

When the exclusive mode is specified, the table being rebalanced cannot be accessed while the rebalancing utility is executing.

Guidelines on usage

Execute the rebalancing utility at times when accesses to the rebalancing table can be suspended.

If the rebalancing utility's processing cannot be completed in a single operation, divide the task into multiple segments for execution of the rebalancing utility.

Application example

Because accesses to the table to be rebalanced can be suspended between 23:00 and 5:00, specify that the rebalancing utility will be executed at 23:00, and specify with the execstop time operand in the control statements file that the utility is to execute for up to 6 hours.

Example of command

pdrbal -k exclusive -t TABLE01 /pdrbal/cfile01

Contents of control statements file

execstop time,6:00

Return code

If rebalancing processing is not completed within 6 hours (is still executing at 5:00), the rebalancing utility terminates with return code 4 and the rebalancing processing terminates. Execute the rebalancing utility again at 23:00. Repeat each day until rebalancing is completed and return code 0 is returned.

Notes on defining an index

If an index defined for a table is processed in the batch index creation mode, the rebalancing utility may not terminate at the time specified in the execstop time operand. This is because the rebalancing utility cannot stop until index creation is completed. Therefore, for processing the index in the batch index creation mode, increase the value specified for the execstop time operand to provide extra time.

13.11.5 Notes on a table with FIX hash partitioning

When the hash facility for hash row partitioning is applied to a table with FIX hash partitioning, the performance of the following retrieval processes will decline while table rebalancing is being executed:

Retrieval in which a condition is specified for a partitioning key

Retrieval in which all partitioning keys are included in the columns specified as the GROUP BY clause

An index for which UNIQUE is specified cannot be updated while rebalancing is being executed.

13.12 Changing a table's partitioning storage conditions

Executor: HiRDB administrator and table owner

You can use ALTER TABLE to change the partitioning storage conditions for a table that was row-partitioned using key range partitioning.# Changing a table's partitioning storage conditions enables you to reuse RDAREAs that have been storing obsolete data, thus reducing your workload because you do not have to delete tables and re-create them.

#

ALTER TABLE is used to change a table's partitioning storage conditions when the following partitioning methods have been used:

Boundary value specification

Storage condition specification (only when the equal sign (=) is used as the comparison operator in the storage conditions)

HiRDB Advanced Partitioning Option must be installed in order to change a table's partitioning storage conditions.

Organization of this section

13.12.1 Purpose of changing partitioning storage conditions

13.12.2 Facilities used to change partitioning storage conditions

13.12.3 Prerequisites

13.12.4 How to change partitioning storage conditions (in the case of boundary value specification)

13.12.5 Splitting an RDAREA (in the case of boundary value specification)

13.12.6 Combining RDAREAs (in the case of boundary value specification)

13.12.7 How to change partitioning storage conditions (in the case of storage condition specification)

13.12.8 Splitting an RDAREA (in the case of storage condition specification)

13.12.9 Combining RDAREAs (in the case of storage condition specification)

13.12.10 Relationship with other facilities

13.12.1 Purpose of changing partitioning storage conditions

The amount of data stored in a row-partitioned table increases over time. As a result, it becomes desirable to erase old data. However, if the data registration date/time, for example, is specified as the partitioning key, simply deleting old data cannot make the RDAREA that was storing the old data available for reuse. In the past, to reuse an RDAREA that was storing old data, you had to perform the following operations:

Unload all data from the table that was to be modified.

Delete the table that was to be modified.

Specify new partitioning storage conditions and re-create the table.

Reload the data into the re-created table.

While these operations were being performed, jobs that access the table being modified had to be stopped temporarily. Because all data had to first be unloaded from the table that was to be modified, and then had to be reloaded, a long time was required for these operations, and the impact on jobs that were stopped could be significant.

Now, by using the ALTER TABLE to change the partitioning storage conditions of a row-partitioned table, you can reduce the amount of time it takes to make an RDAREA reusable.

Organization of this subsection

(1) Overview of changing partitioning storage conditions (in the case of boundary value specification)

(2) Overview of changing partitioning storage conditions (in the case of storage condition specification)

(1) Overview of changing partitioning storage conditions (in the case of boundary value specification)

Figure 13-12 provides an overview of changing partitioning storage conditions (in the case of boundary value specification).

Figure 13-12 Overview of changing partitioning storage conditions (in the case of boundary value specification)

Explanation

The combine facility combines the 1999 and 2000 storage conditions (definition information), which are stored in RDAREAs R01 and R02, respectively, and stores them in RDAREA R02. At this time, the data from R01 can be deleted.

The split facility splits the storage condition (definition information) for 2002 into the data for 2002 and the data for 2003. As a result, the 2002 data is stored in R04 and the data for 2003 and beyond can be stored in R01, which previously stored the data for 1999, thereby reusing R01.

Therefore, in step 1, all that is needed is to unload the data from R01 and R02 and then, after the partitioning storage conditions have been changed, to reload the data from R02 only. In step 2, all that is needed is to unload the data from R04 and load data into R04 and R01 after the partitioning storage conditions have been changed. It was also possible to delete the contents of R01 in step 1. If it turned out that R04 did not contain any data for 2003 and beyond, there would be no need for unloading and reloading, and thus the RDAREA configuration could be modified quite quickly. This makes it possible to recycle and reuse RDAREAs that store data that increases in volume as new ascending key values are added.

(2) Overview of changing partitioning storage conditions (in the case of storage condition specification)

Figure 13-13 provides an overview of changing partitioning storage conditions (in the case of storage condition specification).

Figure 13-13 Overview of changing partitioning storage conditions (in the case of storage condition specification)

Explanation

The table is row-partitioned with a storage condition specification that uses the branch name as the key value. When branches need to be deleted or added due to restructuring, data for a single branch can be split into multiple branches or data for multiple branches can be combined into a single branch.

Because the Berkeley and Oakland branches are combined, the data from these branches is combined in RDAREA R02 and the data in RDAREA R01 is deleted.

Because the San Jose branch is split from the San Francisco branch, the data in RDAREA R04 is split. The data for the San Jose branch is stored in R04 and the data for the San Francisco branch is stored in RDAREA R05.

Hint

In 1., data must be unloaded only from R01 and R02. There is no need to unload data from R03 or R04.

In 2., data must be unloaded only from R04. There is no need to unload data from R02 or R03.

13.12.2 Facilities used to change partitioning storage conditions

This subsection describes the facilities used to change a table's partitioning storage conditions.

Organization of this subsection

(1) Split facility

(2) Combine facility

(1) Split facility

The split facility changes (splits) a table partitioning storage condition and stores the data from a single RDAREA into multiple RDAREAs. Figures 13-14 and 13-15 provide an overview of the split facility.

Figure 13-14 Overview of the split facility (in the case of boundary value specification)

Figure 13-15 Overview of the split facility (in the case of storage condition specification)

When a table is split, the data stored in the RDAREA that is to be split is deleted. Therefore it is necessary to first unload the data from the RDAREA that stores data under the old partitioning storage conditions, and then reload this data into the RDAREAs that will store the data under the new partitioning storage conditions. However, there is one exception: if the pre-splitting RDAREA is to be used as a post-splitting RDAREA without any change, you can keep the data that was stored before splitting without unloading and reloading it.

If you do not use the pre-splitting RDAREA as a post-splitting RDAREA, you cannot keep the data that was stored in the pre-splitting RDAREA.

(2) Combine facility

The combine facility changes (combines) partitioning storage conditions for a table and stores data from multiple RDAREAs into a single RDAREA. Figures 13-16 and 13-17 provide an overview of the combine facility.

Figure 13-16 Overview of the combine facility (in the case of boundary value specification)

Figure 13-17 Overview of the combine facility (in the case of storage condition specification)

When RDAREAs are combined, the data stored in the RDAREAs that are to be combined is deleted. Therefore it is necessary to first unload the data from the RDAREAs to be combined that store data under the old partitioning storage conditions, and then to reload this data into the RDAREA that will store the data under the new, combined partitioning storage conditions. However, there is one exception: if one of the pre-combination RDAREAs is to be used as the post-combination RDAREA, you can keep the data that was stored in it before combining.

If you do not use a pre-combining RDAREA as the post-combining RDAREA, you cannot keep the data that was stored in any of the pre-combining RDAREAs. To set the data that was stored in the pre-combining RDAREAs in the newly added RDAREA, you must unload the data from all RDAREAs before combining and then reload this data after combining.

13.12.3 Prerequisites

Organization of this subsection

(1) Table partitioning method

(2) Applicability by table type

(3) Required products

(4) Other applicability issues

(1) Table partitioning method

Key range partitioning is the prerequisite. Table 13-3 shows for each table partitioning method whether or not the partitioning storage conditions can be changed.

Table 13-3 Table partitioning methods for which partitioning storage conditions can be changed

Table partitioning method | Applicability
Key range partitioning | Storage condition specification | Only = is used as the comparison operator for storage conditions | Y
A condition other than = is used as the comparison operator for storage conditions | N
Boundary values specification | Other than below | Y
Matrix partitioning | N
Hash partitioning (including rebalancing) | FIX hash not specified | N#
FIX hash specified

Legend:

Y: Can be changed.

N: Cannot be changed.

#

Only RDAREA addition is supported by the ALTER TABLE definition SQL statement with ADD RDAREA specified.

(2) Applicability by table type

Partitioning storage conditions cannot be changed for the following types of tables:

Non-partitioned table: Because there are no partitioning storage conditions for a non-partitioned table, change is not possible.

Falsification-prevented table: Depending on the specified change in the partitioning storage conditions, data in the target table in the RDAREA may be deleted. Because data deletion is the same as data falsification, the partitioning storage conditions for a falsification prevented table cannot be changed.

Table containing an abstract data type: The partitioning storage conditions of a table containing an abstract data type cannot be changed.

(3) Required products

To change partitioning storage conditions, HiRDB Advanced Partitioning Option must be installed. If you attempt to change the partitioning storage conditions (CHANGE RDAREA of ALTER TABLE) and this product has not been set up, the KFPA11948-E message will be displayed and ALTER TABLE will terminate with an error.

(4) Other applicability issues

(a) Indexes

If an index has been defined for a table whose partitioning storage conditions are to be changed, it may not be possible to change the partitioning storage conditions depending on the index definition conditions. Table 13-4 shows for each type of index whether or not the partitioning storage conditions can be changed.

Table 13-4 Index types for which partitioning storage conditions can be changed

Index type
Partitioned/Non-partitioned index
Applicability

Cluster key index
Partitioned key index
Y#¹

Primary key index
(including an index for which a primary key and cluster key are defined)

B-tree index
Partitioned key index
Y#¹

Non-partitioned key index
Y#1, #²

Plug-in index
Not applicable
N

Legend:

Y: Can be changed.

N: Cannot be changed.

#1

Depending on the partitioning conditions for the index storage RDAREAs, it may not be possible to change the partitioning storage conditions. Table 13-5 Whether or not the partitioning storage conditions can be changed depending on the partitioning conditions for the index storage RDAREAs shows whether or not the partitioning storage conditions can be changed depending on the partitioning conditions for the index storage RDAREAs.

#2

If the index storage RDAREAs have a 1-to-1 partition correspondence with the table storage RDAREAs, the partitioning storage conditions can be changed. Table 13-6 Applicability of changing partitioning storage conditions for a non-partitioning key index shows whether or not change to the partitioning storage conditions is applicable for a non-partitioning key index.

Table 13-5 Whether or not the partitioning storage conditions can be changed depending on the partitioning conditions for the index storage RDAREAs

Partitioning conditions for the index storage RDAREAs | Whether or not the partitioning storage conditions can be changed
Split | Combine
Partitioning key index | Index storage RDAREAs are partitioned. | Y | Y#¹
Index storage RDAREAs are not partitioned. | N#² | N#³
Non-partitioning key index | Partitioning is performed in such a manner that the table storage RDAREAs and index storage RDAREAs have a 1-to-1 correspondence. | Index storage RDAREAs are partitioned. | Y | Y#¹
Index storage RDAREAs are not partitioned. | N#² | N#³
Other | N | N

Legend:

Y: Partitioning storage conditions can be changed.

N: Partitioning storage conditions cannot be changed.

#1

If the total number of index storage RDAREAs is reduced after combining to a single index storage RDAREA, the partitioning storage conditions can no longer be changed because the row-partitioned index has been converted to a non-row-partitioned index.

#2

The partitioning storage conditions cannot be changed because the non-row-partitioned index is converted to a row-partitioned index.

#3

A row-partitioned index can be changed to a non-row-partitioned index only when the target table is stored in a single RDAREA. Therefore, the partitioning storage conditions cannot be changed.

If the partitioning storage conditions cannot be changed due to the relationship between index storage RDAREAs and table storage RDAREAs, delete the applicable index first, execute ALTER TABLE, and then re-define the index.

Figures 13-18 and 13-19 show cases in which a table storage RDAREA cannot be split.

Figure 13-18 Case in which a table storage RDAREA cannot be split (part 1)

Figure 13-19 Case in which a table storage RDAREA cannot be split (part 2)

Table 13-6 Applicability of changing partitioning storage conditions for a non-partitioning key index

Table RDAREAs | Index RDAREAs
Row partitioning between servers | Row partitioning within servers | Row partitioning between servers | No row partitioning between servers
Yes | Yes | Y | N
No |  | Y#
No | Yes | Y | N
No |  |

Legend:

Y: Can be changed.

N: Cannot be changed.

: Not applicable.

#: Cannot be changed if multiple partitioning storage conditions are stored in the same RDAREA.

(b) RDAREAs storing LOB and indexes

If RDAREAs storing LOB and indexes are defined for a table whose partitioning storage conditions are to be changed, these RDAREAs must also be partitioned or combined along with the table in the same manner.

(c) RDAREAs after change

RDAREAs after the change cannot be used for the following purposes:

RDAREA that is not a user RDAREA cannot be used as a table or index RDAREA

RDAREA that is not a user LOB RDAREA cannot be used as a BLOB column RDAREA

Shared RDAREA

RDAREA for storing a rebalancing table or resources related to a rebalancing table

RDAREA of a replica generation when the inner replica facility is used (must be an RDAREA of the original generation)

13.12.4 How to change partitioning storage conditions (in the case of boundary value specification)

To change the partitioning storage conditions, specify CHANGE RDAREA in the ALTER TABLE statement. Splitting and combining cannot be executed at the same time. To execute both splitting and combining, use two separate ALTER TABLE statements.

Organization of this subsection

(1) Partitioning storage conditions before combining

(2) Combining partitioning storage conditions

(3) Splitting a partitioning storage condition

(1) Partitioning storage conditions before combining

The following shows an example of partitioning storage conditions before combining or splitting:

CREATE FIX TABLE "T1"("C1" INT,"C2" CHAR(10)) PARTITIONED BY "C1"
IN(("TA1")100,("TA2")200,("TA3")400,("TA4")500,("TA5")600,("TA6"))
CREATE INDEX "I1" ON "T1"("C1")
IN(("IA1"),("IA2"),("IA3"),("IA4"),("IA5"),("IA6"))

(2) Combining partitioning storage conditions

The following example combines boundary values 100 and 200 into 200:

ALTER TABLE "T1" CHANGE RDAREA
((100),(200)) INTO "TA2"
FOR INDEX "I1" INTO "IA2"

(3) Splitting a partitioning storage condition

The following example splits the storage range of 600 (& above) into 600 and 700 (& above):

ALTER TABLE "T1" CHANGE RDAREA
((MAX)) INTO (("TA6")700,("TA1"))
FOR INDEX "I1" INTO (("IA6"),("IA1"))

13.12.5 Splitting an RDAREA (in the case of boundary value specification)

The split facility splits into multiple RDAREAs the data stored in a specified range of a table that is partitioned by boundary values. The details of the split facility are explained below.

Organization of this subsection

(1) Maximum values

(2) Determining the RDAREA for splitting

(3) Determining the RDAREAs to be used after splitting

(4) Correspondence between a table and RDAREAs other than for the table

(5) Handling the data in an RDAREA to be split

(1) Maximum values

Table 13-7 shows maximum values for the split facility.

Table 13-7 Maximum values for the split facility (in the case of boundary value specification)

Item | Maximum value | What happens when the maximum value is exceeded
Number of RDAREAs that can be split | 1 | Causes an error in ALTER TABLE.
Number of RDAREAs into which an RDAREA can be split in a single operation | 16
Total number of RDAREAs following splitting | 1024
Total number of specified boundary values following splitting (including other) | 3000

(2) Determining the RDAREA for splitting

The RDAREA that satisfies a specified storage condition is selected for splitting, based on a partitioning boundary value that is specified in CHANGE RDAREA of the ALTER TABLE definition SQL. Because specification of a boundary value identifies the target RDAREA, there is no need to specify the RDAREA itself. Table 13-8 shows the specification of ALTER TABLE and how the RDAREA to be split is determined.

Table 13-8 ALTER TABLE specification and determination of RDAREA to be split

Specification | Condition | Can be specified? | Determination of RDAREA to be split
Boundary value | The specified boundary value is specified in the table definition | Y | RDAREA that stores the specified boundary value range becomes the target for splitting.
The specified boundary value is not specified in the table definition | N |
'MAX' |  | Y | RDAREA that stores partitioning key values that are greater than the maximum boundary value becomes the target for splitting.

Legend:

Y: Can be specified.

N: Cannot be specified.

: Not applicable.

(3) Determining the RDAREAs to be used after splitting

The RDAREAs to be used for storing data after splitting are determined on the basis of the post-splitting boundary values and RDAREAs specified in CHANGE RDAREA of ALTER TABLE. Note that the post-splitting boundary values that are specified must be in ascending order, and the maximum value of the specified boundary values must be greater than the pre-splitting boundary value. Additionally, all partitioned boundary values must be within the range of the pre-splitting storage conditions. Table 13-9 shows the ALTER TABLE specification values and how the RDAREAs to be used after splitting are determined. Figure 13-20 shows the boundary value conditions before and after splitting.

Table 13-9 ALTER TABLE specification values and the method of determining the RDAREAs to be used after splitting

Pre-splitting boundary values
Post-splitting boundary values specification
Condition
Can be specified?
Determination of post-splitting RDAREAS

Minimum boundary value (1. in the figure)
Boundary values
Post-splitting boundary value is smaller than the minimum boundary value (4. in the figure)
Y
Specified storage conditions and RDAREAs are used to select the post-splitting RDAREAs.

Post-splitting boundary value is equal to or greater than the minimum boundary value (1., 2., 3., and 5. in the figure)
N
Causes an error in ALTER TABLE.

Omitted
None
Y
RDAREA specified to store the maximum value range among the post-splitting storage conditions

Intermediate or maximum boundary value (2. in the figure)
Boundary values
Post-splitting boundary value is equal to or smaller than the boundary value that precedes the pre-splitting boundary value (1. and 4. in the figure when the pre-splitting boundary value is 200)
N
Causes an error in ALTER TABLE.

Post-splitting boundary value is smaller than the pre-splitting boundary value and is greater than the preceding boundary value (5. in the figure when the pre-splitting boundary value is 200)
Y
Specified storage conditions and RDAREAs are used to select the post-splitting RDAREAs.

Post-splitting boundary value is equal to or greater than the pre-splitting boundary value (200 when the pre-splitting boundary value is 200)
N
Causes an error in ALTER TABLE.

Omitted
None
Y
RDAREA specified to store the maximum value range among the post-splitting storage conditions

'MAX'
(3. in the figure)
Boundary values
Post-splitting boundary value is smaller than the maximum boundary value (1., 2., 4., and 5. in the figure)
N
Causes an error in ALTER TABLE.

Post-splitting boundary value is greater than the maximum boundary value (3. in the figure)
Y
Specified storage conditions and RDAREAs are used to select the post-splitting RDAREAs.

Omitted
None
Y
RDAREA specified to store the data that is greater than the maximum boundary value.

Legend:

Y: Can be specified.

N: Cannot be specified.

Figure 13-20 Boundary value conditions before and after splitting

The post-splitting RDAREAs may include (reuse) the pre-splitting RDAREA or may be all newly created. Furthermore, after splitting, multiple (non-contiguous) storage ranges can be stored in the same RDAREA. During this process, depending on the specifications, the system can automatically combine boundary values or cause an error in ALTER TABLE. The following describes the system actions:

Splits into RDAREAs as specified.
If it is specified that contiguous storage ranges after splitting not be stored in the same RDAREA, the system splits the storage ranges as specified.

Automatically combines storage ranges.
If the RDAREAs storing the storage ranges preceding and succeeding the storage range to be split are specified as the RDAREAs to be used after splitting, the system automatically combines contiguous boundary values in the following cases:

When the RDAREA storing the range preceding the storage range to be split is the same as the RDAREA for storing the beginning storage range after splitting

When the RDAREA storing the range succeeding the storage range to be split is the same as the RDAREA for storing the last storage range after splitting

Causes an error in ALTER TABLE.
You cannot execute a split that stores multiple contiguous boundary values in the same RDAREA after the specified splitting. If such an attempt is made, the system causes an error in ALTER TABLE. In this case, you must modify and re-execute ALTER TABLE so that it combines the boundary value ranges and stores them in a single RDAREA.

Table 13-10 shows the system's action for storing multiple storage ranges in the same RDAREA.

Table 13-10 System action for storing multiple storage ranges in the same RDAREA

Specification of RDAREAs after splitting
One of the specified RDAREAs that is being used is outside the splitting target storage range
Results of splitting/combining
System action

If the focus is placed only on the specified post-splitting RDAREAs, multiple contiguous boundary values are not stored in the same RDAREA.

RDAREAs that are not used in the pre-splitting table are specified.

Splits into the RDAREAs as specified.
Corresponds to Example 1-1 in Figure 13-21.

RDAREAs that are used in the pre-splitting table are specified.

Being used only in the splitting target storage range.

Splits into the RDAREAs as specified.
Corresponds to Example 1-2 in Figure 13-21.

Being used outside the splitting target storage range.
Specified as the leading RDAREA after splitting.
Same as the RDAREA immediately preceding the splitting target storage range
Combines the storage range with the immediately preceding boundary value.
Corresponds to Example 2-1 in Figure 13-23.

Different from the RDAREA immediately preceding the splitting target storage range
Splits into the RDAREAs as specified.
Corresponds to Example 1-3 in Figure 13-21.

Specified in the middle of the splitting.

Splits into the RDAREAs as specified.
Corresponds to Example 1-4 in Figure 13-22.

Specified at the end of the splitting.
Same as the RDAREA immediately succeeding the splitting target storage range
Combines the storage range with the immediately succeeding boundary value.
Corresponds to Example 2-2 in Figure 13-23.

Different from the RDAREA immediately succeeding the splitting target storage range
Splits into the RDAREAs as specified.
Corresponds to Example 1-5 in Figure 13-22.

If the focus is placed only on the specified post-splitting RDAREAs, multiple contiguous boundary values can be stored in the same RDAREA.

Causes an error in ALTER TABLE.
Corresponds to Example 3-1 in Figure 13-24.

Legend:

: Not applicable.

Figure 13-21 Example 1 of system action when storing multiple storage ranges in the same RDAREA (1 of 2)

Figure 13-22 Example 1 of system action when storing multiple storage ranges in the same RDAREA (2 of 2)

Figure 13-23 Example 2 of system action when storing multiple storage ranges in the same RDAREA

Figure 13-24 Example 3 of system action when storing multiple storage ranges in the same RDAREA

(4) Correspondence between a table and RDAREAs other than for the table

When, for example, a partitioning key index is defined for a table, the index data also must be stored in RDAREAs. If the partitioning storage conditions are changed for the table, the index must be split in the same way that the table RDAREAs are partitioned. Table 13-11 shows how to specify a table and RDAREAs other than for the table (combining storage conditions when partitioning boundary values). If more than one unit of a resource such as is shown in Table 13-11 is defined, the specification method must be applied to each of them. If any specification is incorrect, the system causes an error in ALTER TABLE. Figure 13-25 shows an example of the correspondence between a table and RDAREAs other than for the table. In this example, the table's contents and the contents of the RDAREAs other than for the table are split into three.

Table 13-11 Specifying a table and RDAREAs other than for the table (combining storage conditions when partitioning boundary values)

Resource name
Specification method

Column
BLOB column
Specify these resources so that they correspond to the table RDAREAs on a one-to-one basis.
If a table RDAREA is specified more than once, specify the resources more than once also so that they correspond to the specified tables. If the existing table RDAREA is to be used after the change, you must specify the RDAREAs for storing the existing indexes and LOB data so that they correspond to the same boundary values.

Index
Cluster key index
Primary key index (including an index for which the primary key and a cluster key are defined)
B-tree index

Figure 13-25 Example of the correspondence between a table and RDAREAs other than for the table

(5) Handling the data in an RDAREA to be split

The general rule is that when a storage range is split based on a boundary value, the system automatically deletes the applicable table's existing table data from the RDAREA. However, under some conditions, you can specify that the data is to be retained.

Deleting data
When a storage range is split based on a boundary value, some of the data in the RDAREA to be split will likely become data that will not be stored in that RDAREA after splitting. Therefore, all the data in the RDAREA in the storage range that is to be split must be deleted. Note that only the data in the table whose partitioning storage conditions are to be changed is deleted; data of other tables contained in that RDAREA is not deleted. One of the following methods is used to delete the data from the RDAREA:

Deleting all definition information
If the pre-splitting RDAREA is not used for the table after splitting has taken place, all information about the pre-splitting RDAREA is deleted from the dictionary (MASTER.SQL_DIV_TABLE) containing the RDAREA information used by the table for each of the storage conditions. Table information that is managed within the RDAREA is also deleted. As a result, all data from the splitting-target table that existed in the RDAREA is deleted. In concept, this is equivalent to executing DROP TABLE for the RDAREA.

Deleting data only
If the pre-splitting RDAREA will still be used for the table after splitting, the dictionary information and information managed within the RDAREA is not deleted, and only the table's data in the RDAREA is deleted. If an RDAREA that is to be used after splitting is already being used for another storage range, the data in this other storage range is also deleted. In concept, this is equivalent to executing PURGE TABLE for that RDAREA.

Note that when data in an RDAREA is deleted, all data in the following corresponding RDAREAs is also deleted:

Index keys in an index RDAREA

Data in a BLOB column RDAREA

Additionally, if the inner replica facility is being used, all generation data is deleted.

Saving data
As explained in 1. Deleting data, when a storage range is split based on a boundary value, the general rule is that the table's data in the pre-splitting RDAREA is deleted. However, the data in the RDAREA can be used as is if all the conditions listed below are satisfied, and therefore it is possible to avoid deletion of such data:

The pre-splitting RDAREA is to be used without modification as a post-splitting RDAREA.

All the existing data is at or below the boundary value for the pre-splitting RDAREA.

All data in the pre-splitting RDAREA will be within the storage range for the same RDAREA after splitting.

To instruct that the data in the RDAREA is not to be deleted, you must specify the WITHOUT PURGE clause in ALTER TABLE. Table 13-12 shows whether or not the data is deleted depending on the specification of the WITHOUT PURGE clause. Note that the system does not check whether or not all the data in the RDAREA matches the storage ranges after splitting.

Table 13-12 WITHOUT PURGE clause specification and data handling

Use of the RDAREA after splitting | Can the WITHOUT PURGE clause be specified? | Action when the WITHOUT PURGE clause is specified | Action when the WITHOUT PURGE clause is not specified
Pre-splitting RDAREA will be used as a post-splitting RDAREA. | Yes | Does not delete the data from the pre-splitting RDAREA. | Deletes the data from the pre-splitting RDAREA.
Pre-splitting RDAREA will not be used as a post-splitting RDAREA. | No | Not applicable

Figure 13-26 shows an example of not specifying the WITHOUT PURGE clause. In this example, the table's data is deleted from the pre-splitting RDAREA because the WITHOUT PURGE clause is not specified.

Figure 13-26 Example of an RDAREA from which data is deleted because WITHOUT PURGE is not specified

Notes on cases in which data is not deleted
There may be data in the pre-splitting RDAREA that will not be within the applicable storage range after splitting (this type of data validity is not checked during execution of ALTER TABLE). Consequently, as a result of a change in partitioning storage conditions, data outside the new storage range may exist in the post-splitting RDAREA. When this happens, HiRDB may not function correctly during SQL execution.
For this reason, you must be careful about using the WITHOUT PURGE clause when you change partitioning storage conditions. If you cannot guarantee that all data in the pre-splitting RDAREA will be within the new storage range of that RDAREA after splitting, you should unload the data from the pre-splitting RDAREA, execute the change in partitioning storage conditions without specifying the WITHOUT PURGE clause, and then load the unloaded data into the split RDAREAs. For details about how to recover from a mistake in a splitting operation, see 13.13.9(2) Recovery procedure when data not satisfying the post-splitting storage condition remains.
Figure 13-27 shows examples of handling data in the post-splitting RDAREAs when WITHOUT PURGE is specified. These examples illustrate valid and invalid specifications of WITHOUT PURGE.

Figure 13-27 Examples of handling data in the post-splitting RDAREAs (valid and invalid specifications of WITHOUT PURGE)

Notes on deleting data
If the pre-splitting RDAREA contains data that will be stored in another storage range, data in this other storage range will also be deleted. This holds true, regardless of whether or not the pre-splitting RDAREA will be used as a post-splitting RDAREA. Figure 13-28 shows examples of RDAREA data deletion.

Figure 13-28 Examples of RDAREA data deletion

13.12.6 Combining RDAREAs (in the case of boundary value specification)

Organization of this subsection

(1) Maximum and minimum values

(2) Determining the RDAREAs for combining

(3) Determining the RDAREA to be used after combining

(4) Correspondence between a table and RDAREAs other than for the table

(5) Handling the data in the RDAREAs to be combined

(1) Maximum and minimum values

Table 13-13 shows the maximum and minimum values for the combine facility.

Table 13-13 Maximum and minimum values for the combine facility

Item | Maximum and minimum values | What happens when the maximum or minimum value is exceeded?
Number of RDAREAs that can be combined | 2-16 (minimum is 2, maximum is 16) | Causes an error in ALTER TABLE.
Number of RDAREAs following a single combining operation | 1 (fixed)
Total number of RDAREAs in the combined table | 2 (minimum)

(2) Determining the RDAREAs for combining

All RDAREAs that satisfy specified storage conditions are selected for combining, based on multiple boundary values specified in CHANGE RDAREA of ALTER TABLE. Because specification of boundary values identifies the target RDAREAs, there is no need to specify the RDAREAs themselves. The multiple boundary values must be specified in ascending order; they must also be specified to account for all the contiguous storage conditions defined for the table. For example, if boundary values 10, 20, 30, and 40 are defined in a table definition, specifying 10, 30, and 40 (and skipping specification of 20) will cause an error in ALTER TABLE.

Table 13-14 shows the specification of ALTER TABLE and how the RDAREAs to be combined are determined.

Table 13-14 ALTER TABLE specification and determination of RDAREAs to be combined

Specification | Condition 1 | Condition 2 | Action
Boundary values | Boundary values are specified in the table definition. | Boundary values are specified in the order in which they are defined. | RDAREAs that satisfy the specified storage conditions become the RDAREAs that will be combined.
Boundary values are not specified in their definition order. | Causes an error in ALTER TABLE.
No boundary values are specified in the table definition. | None | Causes an error in ALTER TABLE.
'MAX' | Boundary value specified immediately before is the maximum boundary value in the table definition. | None | RDAREA storing data with partitioning key values greater than the maximum boundary value will be combined.
Boundary value specified immediately before is not the maximum boundary value in the table definition. | None | Causes an error in ALTER TABLE.

(3) Determining the RDAREA to be used after combining

The post-combination RDAREA specified in CHANGE RDAREA of ALTER TABLE becomes the RDAREA that stores all the specified pre-combination storage conditions. Because the boundary value after the combining operation is a merger of the boundary values that were combined, there is no need to specify it. For example, if the boundary values are 10, 20, 30, and 40, and a combining operation combines 20 and 30, the new boundary values become 10, 30, and 40. In this case, all data that is greater than 10 but equal to or smaller than 30 satisfies the storage condition for the combined RDAREA.

The post-combination RDAREA may be one of the pre-combination RDAREAs or may be a different RDAREA. Table 13-15 shows the RDAREAs that can be specified as the post-combination RDAREA.

Table 13-15 RDAREAs that can be specified as the post-combination RDAREA

RDAREA | Can be used as the post-combination RDAREA?
Any one of the pre-combination RDAREAs |  | Yes
None of the pre-combination RDAREAs | RDAREA that is already being used for a boundary value of the same table (but not a boundary value that is being combined). | Yes
RDAREA that is not being used for this table (a newly created RDAREA). | Yes

Legend:

: Not applicable

You can combine RDAREAs so that multiple storage conditions are stored in one RDAREA after combining. However, you cannot combine RDAREAs such that all data is stored in a single RDAREA after combining. Figure 13-29 shows an example of a combining operation that is not allowed (which combines all data into a single RDAREA).

Figure 13-29 Example of a combining operation that is not allowed (which combines all data into a single RDAREA)

You cannot combine RDAREAs such that the post-combination RDAREA also stores the preceding or succeeding storage range. In this case, you must combine the RDAREAs by also including the preceding or succeeding RDAREA. Figure 13-30 shows an example of a combining operation that is not allowed (where the post-combination RDAREA is the same RDAREA that stores the preceding storage range).

Figure 13-30 Example of a combining operation that is not allowed (the post-combination RDAREA also stores the preceding storage range)

(4) Correspondence between a table and RDAREAs other than for the table

When, for example, a partitioning key index is defined for a table, the index data also must be stored in RDAREAs. If the partitioning storage conditions are changed for the table, the index must be partitioned in the same way that the table RDAREAs are partitioned. Table 13-16 shows how to specify a table and RDAREAs other than for the table (combining storage conditions when partitioning boundary values). If more than one unit of a resource such as is shown in Table 13-16 is defined, the specification method must be applied to each of them. If any specification is incorrect, the system causes an error in ALTER TABLE. Figure 13-31 shows an example of the correspondence between a table and RDAREAs other than for the table.

Table 13-16 Specifying a table and RDAREAs other than for the table (combining storage conditions when partitioning boundary values)

Resource name
Specification method

Column
BLOB column
Specify these resources so that they correspond to the table RDAREAs on a one-to-one basis.
If duplicate table RDAREAs are specified, specify duplicate resources so that they correspond to the table. If an existing table RDAREA is to be used after the change, you must specify RDAREAs for storing the existing indexes and LOB data so that they correspond to the same boundary values.

Index
Cluster key index
Primary key index (including an index for which the primary key and a cluster key are defined)
B-tree index

Figure 13-31 Example of the correspondence between a table and RDAREAs other than for the table

(5) Handling the data in the RDAREAs to be combined

The general rule is that when storage ranges are combined based on boundary values, the system automatically deletes the applicable table's existing table data from the RDAREAs. However, under some conditions, you can specify that data is to be retained.

Deleting data
When storage ranges are combined based on boundary values, pre-combination RDAREAs may no longer be used by the table after combining. Therefore, the system automatically deletes the data in those RDAREAs. Note that only the data in the table whose partitioning storage conditions are to be changed is deleted; data of other tables contained in the RDAREA is not deleted. One of the following methods is used to delete the data from the RDAREA:

Deleting all definition information
If a pre-combination RDAREA will not be used for the table after combining, all information about the pre-combination RDAREA is deleted from the RDAREA information in the dictionary table (SQL_DIV_TABLE) used for the table's applicable storage condition. Table information that is managed within the RDAREA is also deleted. As a result, all data from the combination-target table that existed in the RDAREA is deleted. In concept, this is equivalent to executing DROP TABLE for the RDAREA.

Deleting data only
If a pre-combination RDAREA is to be used as the RDAREA for the combined storage ranges, the dictionary information and information managed within the RDAREA is not deleted, and only the table's data in the RDAREA is deleted. If the RDAREA to be used for the combined storage ranges is already being used for another storage range, the data in this other storage range is also deleted. In concept, this is equivalent to executing PURGE TABLE for that RDAREA.

Note that when data in an RDAREA is deleted, all data in the following corresponding RDAREAs is also deleted:

Index keys in an index RDAREA

Data in a BLOB column RDAREA

Additionally, if the inner replica facility is being used, all generation data is deleted.

Saving data
As explained in 1. Deleting data, when storage ranges are combined based on boundary values, the general rule is that the table's data in the pre-combination RDAREAs is deleted. However, the data in an RDAREA can be used as is if the condition listed below is satisfied, and therefore it is possible to avoid deletion of such data:

The pre-combination RDAREA is to be used without modification as the post-combination RDAREA.

To instruct that the data in the RDAREA is not to be deleted, you must specify the WITHOUT PURGE clause in ALTER TABLE. Table 13-17 shows whether or not the date is deleted depending on the specification of the WITHOUT PURGE clause.

Table 13-17 WITHOUT PURGE clause specification and data handling

Use of the RDAREA after combining | Can the WITHOUT PURGE clause be specified? | Action when the WITHOUT PURGE clause is specified. | Action when the WITHOUT PURGE clause is not specified.
One of the pre-combination RDAREAs will be used as the post-combination RDAREA | Yes | Does not delete the data from the RDAREA to be re-used after combining; deletes data from the other pre-combination RDAREAs. | Deletes the data from all pre-combination RDAREAs.
No pre-combination RDAREA will be used as the post-combination RDAREA (a different RDAREA from any of the pre-combination RDAREAs is to be used as the post-combination RDAREA) | No | Causes an error in ALTER TABLE.

Figure 13-32 shows the RDAREAs from which data is deleted during combining.

Figure 13-32 RDAREAs from which data is deleted during combining

Notes on cases in which data is not deleted
If you specify WITHOUT PURGE to save the data, then you unload all the data before combining and reload it into the post-combination RDAREA, the data saved by the WITHOUT PURGE specification will have been registered twice. For this reason, you must not execute unloading and post-combination reloading of the data of an RDAREA if that RDAREA's data is being saved by specification of WITHOUT PURGE.
Even if you specify WITHOUT PURGE, the data in any pre-combination RDAREA that is not used as the post-combination RDAREA is deleted. Also, if an RDAREA containing a storage range to be combined is not to be used as the post-combination RDAREA and that pre-combination RDAREA also contains a storage range that is not included in the combining operation, the data in this other storage range will also be deleted. Therefore, to combine one or more selected storage ranges in an RDAREA that stores multiple storage ranges, it is necessary to change the partitioning storage conditions without specifying WITHOUT PURGE, and then reload the combined RDAREA with the data that has been unloaded.
Figure 13-33 shows examples of handling data in the RDAREAs to be combined when WITHOUT PURGE is specified.

Figure 13-33 Examples of handling data in the RDAREAs to be combined (when WITHOUT PURGE is specified)

Notes on deleting data
As explained in the notes on not deleting data, if there is an RDAREA that is being used for a storage range that is not to be included in the combining operation, as well as for a storage range that will be included in the combining operation, and this RDAREA will not become the post-combination RDAREA, the data in the other storage range is also deleted. For this reason, Hitachi recommends in this case that you unload all data from the RDAREAs to be combined, change the partitioning storage conditions without specifying WITHOUT PURGE, and then reload the combined RDAREA with the data that has been unloaded.

13.12.7 How to change partitioning storage conditions (in the case of storage condition specification)

To change the partitioning storage conditions, specify CHANGE RDAREA in the ALTER TABLE statement. Splitting and combining cannot be executed at the same time. To execute both splitting and combining, use two separate ALTER TABLE statements.

Organization of this subsection

(1) Partitioning storage conditions before combining

(2) Combining partitioning storage conditions

(3) Splitting a partitioning storage condition

(1) Partitioning storage conditions before combining

The following shows an example of partitioning storage conditions before combining or splitting:

CREATE FIX TABLE "T1"("C1" CHAR(10),"C2"...
IN(("TA1")"C1"='Berkeley branch',("TA2")"C1"='Oakland branch',("TA3")"C1"='Sausalito branch',
   ("TA4")"C1"=('San Francisco branch','San Jose branch'),("TA5"))
CREATE INDEX "I1" ON "T1"("C1")
IN(("IA1"),("IA2"),("IA3"),("IA4"),("IA5"))

(2) Combining partitioning storage conditions

The following example combines data from the Berkeley and Oakland branches into the same RDAREA:

ALTER TABLE "T1" CHANGE RDAREA PARTITIONED CONDITION (("TA1"),("TA2")) INTO ("TA1")
FOR INDEX "I1" INTO "IA1"

(3) Splitting a partitioning storage condition

The following example splits the data for the San Francisco and San Jose branches into separate RDAREAs:

ALTER TABLE "T1" CHANGE RDAREA PARTITIONED CONDITION
(("TA4")) INTO (("TA4")"C1"=('San Francisco branch'),("TA6")"C1"=('San Jose branch'))
FOR INDEX "I1" INTO (("IA4"),("IA6"))

13.12.8 Splitting an RDAREA (in the case of storage condition specification)

Organization of this subsection

(1) Rules for changing storage conditions

(2) RDAREA with OTHERS specified

(3) Determining the RDAREAs to be used after splitting

(4) How to specify a post-split storage condition

(5) When a resource such as a partitioning key index has been defined for the table

(6) Handling of data in the split-target RDAREA

(1) Rules for changing storage conditions

This subsection describes the rules for changing storage conditions.

(a) Maximum value

When you change storage conditions, you must observe the maximum values shown in Table 13-18.

Table 13-18 Maximum values for the split facility (in the case of storage condition specification)

Item | Maximum value | What happens when the maximum value is exceeded
Number of RDAREAs that can be split | 1 | Causes an error in ALTER TABLE.
Number of RDAREAs into which an RDAREA can be split in a single operation | 16
Total number of RDAREAs following splitting | 1,024
Total number of storage conditions after splitting (including RDAREAs with no storage condition specified) | 15,000

(b) Rules for splitting

The RDAREA to be split must satisfy specific conditions. Table 13-19 describes whether or not an RDAREA can be split.

Table 13-19 Determination of whether or not an RDAREA can be split

RDAREA to be split#¹ | Storage condition defined for table | Whether or not splittable | Description
RDAREA for which storage condition is specified | Only one storage condition is specified for the RDAREA. | N | Causes in an error in ALTER TABLE.
Multiple storage conditions are specified for the RDAREA. | Y | An example of splitting an RDAREA with storage conditions specified is shown in Figure 13-34 Example of splitting an RDAREA with storage conditions specified.
RDAREA for which no storage condition is specified | -- | Y | An example of splitting an RDAREA with no storage condition specified is shown in Figure 13-35 Example of splitting an RDAREA with no storage condition specified.
RDAREA with OTHERS specified#² | Storage conditions are specified for all RDAREAs. | Y | An example of splitting an RDAREA with OTHERS specified is shown in Figure 13-36 Example of splitting an RDAREA with OTHERS specified.
There is an RDAREA with no storage condition specified. | N | An example where an RDAREA with OTHERS specified cannot be split is shown in Figure 13-37 Example where an RDAREA with OTHERS specified cannot be split.

Legend:

Y: Can be split.

N: Cannot be split.

--: Not applicable.

#1

The RDAREA to be split is the one specified in the pre-change RDAREA information list for CHANGE RDAREA in the ALTER TABLE statement.

#2

For details about an RDAREA with OTHERS specified, see 13.12.8(2) RDAREA with OTHERS specified.

Figure 13-34 Example of splitting an RDAREA with storage conditions specified

Figure 13-35 Example of splitting an RDAREA with no storage condition specified

Figure 13-36 Example of splitting an RDAREA with OTHERS specified

Figure 13-37 Example where an RDAREA with OTHERS specified cannot be split

(2) RDAREA with OTHERS specified

When storage conditions are specified, you can split a dummy RDAREA with no entity. You can also split an RDAREA into an RDAREA with entity and a dummy RDAREA. Such a dummy RDAREA with no entity is called an RDAREA with OTHERS specified. RDAREAs with OTHERS specified are treated as RDAREAs with no storage condition specified during split or combine processing. The following describes how to use an RDAREA with OTHERS specified.

You can add an RDAREA with new storage conditions specified as well as an RDAREA with no storage condition specified
The system performs split processing treating an RDAREA with OTHERS specified as an RDAREA with no storage condition specified. This makes it possible to add an RDAREA with new storage conditions specified as well as an RDAREA with no storage condition specified. For an example, see Figure 13-36 Example of splitting an RDAREA with OTHERS specified.

You can delete an RDAREA with no storage condition specified and add new storage conditions
If you have split an RDAREA with no storage condition specified or an RDAREA with OTHERS specified, you can specify an RDAREA with OTHERS specified as one of the RDAREAs resulting after splitting. Because an RDAREA with OTHERS specified is treated as an RDAREA with no storage condition specified, you can delete the RDAREA with no storage condition specified or add new storage conditions by specifying an RDAREA with OTHERS specified together with an RDAREA with storage conditions specified. For an example, see 13.12.8(3) Determining the RDAREAs to be used after splitting.

(3) Determining the RDAREAs to be used after splitting

The RDAREAs to be used to store data are determined by the RDAREAs and the post-split storage conditions specified in CHANGE RDAREA in the ALTER TABLE statement. The RDAREAs obtained after splitting may include the RDAREA subject to splitting or new RDAREAs. However, the same name cannot be specified for an RDAREA obtained after splitting.

The following describes whether or not the split-target RDAREA can be included in the post-split RDAREAs.

(a) When multiple storage conditions have been specified for the split-target RDAREA

Table 13-20 shows whether or not the split-target RDAREA (for which multiple storage conditions have been specified) can be included in the post-split RDAREAs.

Table 13-20 Whether or not the split-target RDAREA (for which multiple storage conditions have been specified) can be included in the post-split RDAREAs

Conditions for the post-split RDAREAs that are specified in CHANGE RDAREA in ALTER TABLE | Whether or not post-split RDAREAs can be specified
When there is an RDAREA with no storage condition specified | When storage conditions have been specified for all RDAREAs
When the split-target RDAREA is not specified | Only new RDAREAs are specified. | Y (see Figure 13-38 Case where splitting is supported (part 1))
An RDAREA with a storage condition specified is included. | N (see Figure 13-40 Case where splitting is not supported (part 1))
An RDAREA with no storage condition specified is included. | N (see Figure 13-40 Case where splitting is not supported (part 1)) | --
An RDAREA with OTHERS specified is specified. | N (see Figure 13-41 Case where splitting is not supported (part 2))
When the split-target RDAREA is specified | All RDAREAs are new other than the split-target RDAREA. | Y (see Figure 13-39 Case where splitting is supported (part 2))
An RDAREA with a storage condition specified is included. | N (see Figure 13-40 Case where splitting is not supported (part 1))
An RDAREA with no storage condition specified is included. | N (see Figure 13-40 Case where splitting is not supported (part 1)) | --
An RDAREA with OTHERS specified is specified. | N (see Figure 13-41 Case where splitting is not supported (part 2))

Legend:

Y: Can be split.

N: Cannot be split.

--: Not applicable.

Figure 13-38 Case where splitting is supported (part 1)

Figure 13-39 Case where splitting is supported (part 2)

Figure 13-40 Case where splitting is not supported (part 1)

Figure 13-41 Case where splitting is not supported (part 2)

(b) When no storage condition has been specified for the split-target RDAREA

Table 13-21 shows whether or not the split-target RDAREA (for which no storage condition has been specified) can be included in the post-split RDAREAs.

Table 13-21 Whether or not the split-target RDAREA (for which no storage condition has been specified) can be included in the post-split RDAREAs

Conditions for the post-split RDAREAs that are specified in CHANGE RDAREA in ALTER TABLE | Whether or not post-split RDAREAs can be specified
When there is an RDAREA with no storage condition specified | When storage conditions have been specified for all RDAREAs
When the split-target RDAREA is not specified | Only new RDAREAs are specified. | No RDAREA with OTHERS specified is included. | Y (see Figure 13-42 Case where splitting is supported (part 3)) | --
An RDAREA with OTHERS specified is included. | Y (see Figure 13-43 Case where splitting is supported (part 4)) | --
An RDAREA with a storage condition specified is included. | N (see Figure 13-46 Case where splitting is not supported (part 3)) | --
When the split-target RDAREA is specified | All RDAREAs are new other than the split-target RDAREA. | No RDAREA with OTHERS specified is included. | Y (see Figure 13-44 Case where splitting is supported (part 5)) | --
An RDAREA with OTHERS specified is included. | Y (see Figure 13-45 Case where splitting is supported (part 6)) | --
An RDAREA with a storage condition specified is included. | N (see Figure 13-46 Case where splitting is not supported (part 3)) | --

Legend:

Y: Can be split.

N: Cannot be split.

--: Not applicable.

Figure 13-42 Case where splitting is supported (part 3)

Figure 13-43 Case where splitting is supported (part 4)

Note

In this example, data other than 'A', 'B', 'C', 'D', and 'E' can no longer be referenced or inserted after splitting. Therefore, caution is required if you specify OTHERS for a post-split RDAREA.

Figure 13-44 Case where splitting is supported (part 5)

Figure 13-45 Case where splitting is supported (part 6)

Note

In this example, data other than 'A', 'B', 'C', 'D', and 'E' can no longer be referenced or inserted after splitting. Therefore, caution is required if you specify OTHERS for a post-split RDAREA.

Figure 13-46 Case where splitting is not supported (part 3)

(c) When OTHERS is specified for the split-target RDAREA

Table 13-22 shows whether or not the split-target RDAREA (with OTHERS specified) can be included in the post-split RDAREAs.

Table 13-22 Whether or not the split-target RDAREA (with OTHERS specified) can be included in the post-split RDAREAs

Conditions for the post-split RDAREAs that are specified in CHANGE RDAREA in ALTER TABLE | Whether or not post-split RDAREAs can be specified
When there is an RDAREA with no storage condition specified | When storage conditions have been specified for all RDAREAs
The post-split RDAREAs include an RDAREA with OTHERS specified | Only new RDAREAs are specified. | N | Y (see Figure 13-47 Case where splitting is supported (part 7))
An RDAREA with a storage condition specified is included. | N | N (see Figure 13-49 Case where splitting is not supported (part 4))
The post-split RDAREAs include no RDAREA with OTHERS specified | Only new RDAREAs are specified. | N | Y (see Figure 13-48 Case where splitting is supported (part 8))
An RDAREA with a storage condition specified is included. | N | N (see Figure 13-49 Case where splitting is not supported (part 4))

Legend:

Y: Can be split.

N: Cannot be split.

--: Not applicable.

Figure 13-47 Case where splitting is supported (part 7)

Figure 13-48 Case where splitting is supported (part 8)

Figure 13-49 Case where splitting is not supported (part 4)

(4) How to specify a post-split storage condition

You must specify a post-split storage condition for the split-target RDAREA, and the specified storage condition must satisfy all the following conditions:

The specified partitioning key value exists in the table definition.

The data type of the column specified in a single storage condition can be compared with the data type of a literal.

There is duplication of post-split storage conditions.

Table 13-23 shows whether or not a post-split storage condition can be specified.

Table 13-23 Whether or not a post-split storage condition can be specified

Split-target RDAREA | Post-split storage condition | Specifiable
RDAREA for which storage conditions are specified | A storage condition applicable to the split-target RDAREA is specified. | All storage conditions are specified. | Y
At least one storage condition is not specified. | N
Storage conditions that are not included in the split-target RDAREA are specified. | N
No storage conditions are specified. | N
RDAREA for which no storage condition is specified | A storage condition already specified in the table definitions is included. | N
The storage conditions already specified in the table definitions are not included. | There is an RDAREA with no storage condition specified. | Y
There is no RDAREA with no storage condition specified. | N
RDAREA with OTHERS specified | The storage condition already specified in the table definitions is included. | N
The storage conditions already specified in the table definitions are not included. | Y

Legend:

Y: Can be specified.

N: Cannot be specified.

You can specify one or more post-split storage conditions for each post-split RDAREA.

(5) When a resource such as a partitioning key index has been defined for the table

If a resource such as a partitioning key index has been defined for a table whose storage conditions are to be changed, you must also split the index storage RDAREAs when you split table storage RDAREAs. Table 13-24 shows the resources that are subject to splitting when storage conditions are changed.

Figure 13-50 shows an example of splitting when a resource such as a partitioning key index has been defined for the table.

Table 13-24 Resources subject to splitting when storage conditions are changed

Resource defined for the table | Splitting method
Index | Split in such a manner that the index storage RDAREAs have a 1-to-1 correspondence with the table storage RDAREAs.
Cluster key
Primary key
LOB column

Figure 13-50 Example of splitting when a resource such as a partitioning key index has been defined for the table

During split processing, the following rules apply:

If multiple resources have been defined, all resources are subject to splitting.

If the specification for splitting is invalid, ALTER TABLE results in an error.

There can be no duplication of names among the index storage RDAREAs and LOB column storage RDAREAs obtained after storage conditions have been changed.

(6) Handling of data in the split-target RDAREA

When ALTER TABLE is executed, data is normally deleted from the split-target RDAREA. Data is also deleted from the following corresponding RDAREAs:

Index data in the index storage RDAREA

Lob data in the LOB column storage RDAREA

Reference note

The reason for deleting data from the split-target RDAREA is as follows:

Part of the data in the split-target RDAREA may no longer satisfy the storage conditions for the RDAREA obtained after splitting.

Note that data is not deleted from RDAREAs that are not the split target.

Figure 13-51 shows the data that is deleted during split processing.

Figure 13-51 Data that is deleted during split processing

(a) Case in which data is not deleted

If the following conditions are all satisfied, data can be retained because data in the split-target RDAREA may be usable as is:

The split-target RDAREA is to be used after split processing.

The split-target RDAREA contains only data that satisfies the post-splitting storage conditions.

The split-target index storage RDAREA or LOB column storage RDAREA also satisfies conditions 1 and 2.

If data is not to be deleted, specify WITHOUT PURGE in ALTER TABLE. If use of the split-target RDAREA after split processing is not specified but WITHOUT PURGE is specified, ALTER TABLE results in an error.

Figure 13-52 shows the case where WITHOUT PURGE takes effect, and Figure 13-53 shows the case where WITHOUT PURGE results in an error.

Figure 13-52 Case where WITHOUT PURGE takes effect

#

If RD01 contains data that is ='B' before split processing, the data that does not satisfy the storage condition remains in RD01 after split processing. Therefore, you must make sure that RD01 does not contain data that is ='A' before split processing.

Figure 13-53 Case where WITHOUT PURGE results in an error

(b) Notes about specifying WITHOUT PURGE

If split processing is performed with WITHOUT PURGE specified, HiRDB does not check whether or not all the data in the RDAREA satisfies the post-splitting storage conditions. If the RDAREA contains data that does not satisfy the storage conditions, HiRDB does not function correctly during SQL execution. Therefore, when you change the storage conditions specifying WITHOUT PURGE, check the data in the split-target RDAREA.

Hint

Normally, do not specify WITHOUT PURGE when you change storage conditions. For details about how to change storage conditions, see 13.13 Changing a table's partitioning storage conditions.

(c) Notes about specifying OTHERS for post-split RDAREAs

If both of the conditions listed below are satisfied, storage conditions are specified for all post-split RDAREAs (there will be no RDAREA with no storage condition specified after split processing):

An RDAREA with no storage condition specified is to be split.

An RDAREA with OTHERS specified is specified as a post-split RDAREA.

Any data that does not satisfy the post-splitting storage conditions will have no storage RDAREA. Figure 13-54 shows an example where there is no storage RDAREA for data after split processing.

Figure 13-54 Example where there is no storage RDAREA for data after split processing

#

Data whose storage condition is not ='C' will have no storage RDAREA after split processing.

13.12.9 Combining RDAREAs (in the case of storage condition specification)

Organization of this subsection

(1) Rules for changing storage conditions

(2) RDAREA with OTHERS specified

(3) How to determine the combined RDAREA

(4) When a resource such as a partitioning key index has been defined for the table

(5) Handling of data in a combination-target RDAREA

(1) Rules for changing storage conditions

This subsection describes the rules for changing storage conditions.

(a) Maximum and minimum values

When you change storage conditions, you must observe the maximum and minimum values shown in Table 13-25.

Table 13-25 Maximum and minimum values for the combine facility

Item | Maximum value | Minimum value | Result when the value is not within the range of the minimum and maximum values
Number of RDAREAs that can be combined in a single operation | 16 | 2 | Causes an error in ALTER TABLE.
Number of RDAREAs that are combined after execution of ALTER TABLE | 1 (fixed)
Total number of RDAREAs resulting from combining | -- | 1

Legend:

--: Not applicable.

(b) Rules for combining

The RDAREAs to be combined must satisfy specific conditions. Table 13-26 describes whether or not RDAREAs can be combined.

Table 13-26 Determination of whether or not RDAREAs can be combined

RDAREAs to be combined | Whether or not combinable | Description
The combination-target RDAREAs are specified in the table definition. | Y | RDAREAs can be combined.
The combination-target RDAREAs contain an RDAREA that is not specified in the table definition. | N | Causes an error in ALTER TABLE.
RDAREA with OTHERS specified# | Storage conditions have been specified for all RDAREAs. | Y | An example of combining an RDAREA with OTHERS specified is shown in Figure 13-55 Example of combining an RDAREA with OTHERS specified.
There is an RDAREA with no storage condition specified. | N | Causes an error in ALTER TABLE. An example in which an RDAREA with OTHERS specified cannot be combined is shown in Figure 13-56 Example where an RDAREA with OTHERS specified cannot be combined.

Legend:

Y: Can be combined.

N: Cannot be combined.

#

For details about an RDAREA with OTHERS specified, see 13.12.9(2) RDAREA with OTHERS specified.

Figure 13-55 Example of combining an RDAREA with OTHERS specified

Figure 13-56 Example where an RDAREA with OTHERS specified cannot be combined

(2) RDAREA with OTHERS specified

When storage conditions are specified, you can combine dummy RDAREAs with no entity. You can also integrate an RDAREA in a dummy RDAREA. Such a dummy RDAREA with no entity is called an RDAREA with OTHERS specified. RDAREAs with OTHERS specified are treated as RDAREAs with no storage condition specified during split or combine processing. The following describes how to use RDAREAs with OTHERS specified.

You can delete existing storage conditions and create an RDAREA with no storage condition specified.
By including an RDAREA with OTHERS specified in the combination-target RDAREAs, you can delete existing storage conditions and create an RDAREA with no storage condition specified. For an example, see Figure 13-55 Example of combining an RDAREA with OTHERS specified.

You can delete RDAREAs with storage conditions specified.
If combination-target RDAREAs include an RDAREA with no storage condition specified or an RDAREA with OTHERS specified, you can specify the RDAREA with OTHERS specified as the RDAREA resulting after combine processing. Because an RDAREA with OTHERS specified is treated as an RDAREA with no storage condition specified, you can delete an RDAREA with storage conditions specified by combining an RDAREA with OTHERS specified and the RDAREA with storage conditions specified. For an example, see 13.12.9(3) How to determine the combined RDAREA.

(3) How to determine the combined RDAREA

You specify the combined RDAREA in CHANGE RDAREA of ALTER TABLE. This RDAREA stores the data that satisfies all storage conditions for the combination-target RDAREAs. The resulting combined RDAREA may be one of the combination-target RDAREAs or a newly provided RDAREA.

Note that the RDAREAs may not be combined depending on the conditions during combine processing. This subsection describes the permitted and prohibited combinations of combination-target RDAREAs and post-combination RDAREA.

(a) Total number of post-combination RDAREAs

There is a condition on the total number of post-combination RDAREAs. Table 13-27 shows and describes the relationship between the conditions during combine processing and the total number of post-combination RDAREAs.

Table 13-27 Relationship between the conditions during combine processing and the total number of post-combination RDAREAs

Condition during combine processing | Total number of post-combination RDAREAs
Condition for combination-target table | Condition for combination-target RDAREAs. | 1 | 2 or more
There is an RDAREA with no storage condition specified. | There is an RDAREA with OTHERS specified. | N#1
There is no RDAREA with OTHERS specified. | There is an RDAREA with no storage condition specified. | N (see Figure 13-62 Case where combine processing is not supported (part 1)) | Y (see Figure 13-57 Case where combine processing is supported (part 1))
There is no RDAREA with no storage condition specified. | -- | Y (see Figure 13-58 Case where combine processing is supported (part 2))
There is no RDAREA with no storage condition specified. | There is an RDAREA with OTHERS specified. | N (see Figure 13-63 Case where combine processing is not supported (part 2)) | Y (see Figure 13-59 Case where combine processing is supported (part 3))
There is no RDAREA with OTHERS specified. | Y#² (see Figure 13-60 Case where combine processing is supported (part 4)) | Y (see Figure 13-61 Case where combine processing is supported (part 5))

Legend:

Y: Can be combined.

N: Cannot be combined.

--: Not applicable.

#1

If the combination-target table has an RDAREA with no storage condition specified, an RDAREA with OTHERS specified cannot be specified as a combination-target RDAREA.

#2

RDAREAs cannot be combined if an index has been defined for the combination-target table.

Figure 13-57 Case where combine processing is supported (part 1)

Figure 13-58 Case where combine processing is supported (part 2)

Figure 13-59 Case where combine processing is supported (part 3)

Figure 13-60 Case where combine processing is supported (part 4)

Figure 13-61 Case where combine processing is supported (part 5)

Figure 13-62 Case where combine processing is not supported (part 1)

Figure 13-63 Case where combine processing is not supported (part 2)

(b) When combining only RDAREAs with storage conditions specified

Table 13-28 lists and describes the specification conditions for the post-combination RDAREA and whether or not combine processing is supported (when only RDAREAs with storage conditions specified are to be combined).

Table 13-28 Specification conditions for the post-combination RDAREA and whether or not combine processing is supported (when only RDAREAs with storage conditions specified are to be combined)

Specification condition for post-combination RDAREA | Whether or not combine processing is supported
No combination-target RDAREA is used after combine processing. | One of the table storage RDAREAs is specified as the post-combination RDAREA. | N (RDAREA specification error)
An RDAREA other than a table storage RDAREAs is specified as the post-combination RDAREA. | Y (see Figure 13-64 Case where combine processing is supported (part 6))
An RDAREA with OTHERS specified is specified as the post-combination RDAREA. | N (see Figure 13-66 Case where combine processing is not supported (part 3))
A combination-target RDAREA is used after combine processing. | Y (see Figure 13-65 Case where combine processing is supported (part 7))

Legend:

Y: Can be combined.

N: Cannot be combined.

Figure 13-64 Case where combine processing is supported (part 6)

Figure 13-65 Case where combine processing is supported (part 7)

Figure 13-66 Case where combine processing is not supported (part 3)

(c) When an RDAREA with no storage condition specified is to be combined

Table 13-29 lists and describes the specification conditions for the post-combination RDAREA and whether or not combine processing is supported (when an RDAREA with no storage condition specified is to be combined).

Table 13-29 Specification conditions for the post-combination RDAREA and whether or not combine processing is supported (when an RDAREA with no storage condition specified is to be combined)

Specification condition for post-combination RDAREA | Conditions for table storage RDAREA after combine processing
When there is an RDAREA with no storage condition specified | When there is no RDAREA with no storage condition specified
No combination-target RDAREA is used after combine processing. | One of the table storage RDAREAs is specified as the post-combination RDAREA. | N (RDAREA specification error) | --
An RDAREA other than one of the table storage RDAREAs is specified as the post-combination RDAREA. | Y (see Figure 13-67 Case where combine processing is supported (part 8)) | --
An RDAREA with OTHERS specified is specified as the post-combination RDAREA. | Y (see Figure 13-68 Case where combine processing is supported (part 9)) | --
A combination-target RDAREA is used after combine processing. | Y (see Figure 13-69 Case where combine processing is supported (part 10)) | --

Legend:

Y: Can be combined.

N: Cannot be combined.

--: Not applicable.

Figure 13-67 Case where combine processing is supported (part 8)

Figure 13-68 Case where combine processing is supported (part 9)

Figure 13-69 Case where combine processing is supported (part 10)

(d) When an RDAREA with OTHERS specified is to be combined

Table 13-30 lists and describes the specification conditions for the post-combination RDAREA and whether or not combine processing is supported (when an RDAREA with OTHERS specified is to be combined).

Table 13-30 Specification conditions for the post-combination RDAREA and whether or not combine processing is supported (when an RDAREA with OTHERS specified is to be combined)

Specification condition for post-combination RDAREA | Conditions for table storage RDAREA after combine processing
When there is an RDAREA with no storage condition specified | When there is no RDAREA with no storage condition specified
No combination-target RDAREA is used after combine processing. | An RDAREA with storage conditions specified is specified as the post-combination RDAREA. | N (OTHERS cannot be specified) | N (specified RDAREA is not a target of combine processing)
An RDAREA other than one of the table storage RDAREAs is specified as the post-combination RDAREA. | N (OTHERS cannot be specified) | Y (see Figure 13-70 Case where combine processing is supported (part 11))
An RDAREA with OTHERS specified is specified as the post-combination RDAREA. | N (OTHERS cannot be specified) | Y (see Figure 13-71 Case where combine processing is supported (part 12))
A combination-target RDAREA is used after combine processing. | An RDAREA with storage conditions specified is specified as the post-combination RDAREA. | N (OTHERS cannot be specified) | Y (see Figure 13-70 Case where combine processing is supported (part 11))
An RDAREA with OTHERS specified is specified as the post-combination RDAREA. | N (OTHERS cannot be specified) | Y (see Figure 13-71 Case where combine processing is supported (part 12))

Legend:

Y: Can be combined.

N: Cannot be combined.

Figure 13-70 Case where combine processing is supported (part 11)

Figure 13-71 Case where combine processing is supported (part 12)

(4) When a resource such as a partitioning key index has been defined for the table

If a resource such as a partitioning key index has been defined for the combination-target table, you must combine not only the table storage RDAREAs but also the index storage RDAREAs. Table 13-31 shows the resources that must be combined at the same time.

Figure 13-72 shows an example of combining when a resource such as a partitioning key index has been defined for the table.

Table 13-31 Resources subject to combining when storage conditions are changed

Resource defined for the table | Combining method
Index | Combine so that the index storage RDAREAs have a 1-to-1 correspondence with the table storage RDAREAs.
Cluster key
Primary key
LOB column

Figure 13-72 Example of combining when a resource such as a partitioning key index has been defined for the table

The following rules apply to combine processing:

If multiple resources have been defined, all resources are subject to combining.

If the specification for combining is invalid, ALTER TABLE results in an error.

(5) Handling of data in a combination-target RDAREA

When ALTER TABLE is executed, data is normally deleted from a combination-target RDAREA. Data is also deleted from the following corresponding RDAREAs:

Index data in index storage RDAREAs

Lob data in LOB column storage RDAREAs

Reference note

The reason for deleting data from combination-target RDAREAs is as follows:

Combination-target RDAREAs may no longer be used after combine processing.

Note that data is not deleted from RDAREAs that are not combination targets.

Figure 13-73 shows the data that is deleted during combine processing.

Figure 13-73 Data that is deleted during combine processing

(a) Case in which data is not deleted

If the following conditions are all satisfied, data can be retained because data in the combination-target RDAREA may be usable as is:

The combination-target RDAREA is to be used after combine processing.

The combination-target index storage RDAREA or LOB column storage RDAREA also satisfies condition 1.

If data is not to be deleted, you must specify WITHOUT PURGE in ALTER TABLE. If use of a combination-target RDAREA after combine processing is not specified but WITHOUT PURGE is specified, ALTER TABLE results in an error. Figure 13-74 shows the processing when WITHOUT PURGE is specified.

Figure 13-74 Processing when WITHOUT PURGE is specified

Explanation:

Because RDAREAs are combined into RD02, the data in RD02 (whose storage condition is ='B') is not deleted. The data in RD03 and RD04 (whose storage conditions are ='C' and ='D') is deleted.

Note

If data is saved with WITHOUT PURGE specified and the pre-combination data is unloaded and then loaded into the post-combination RDAREA, that data is registered twice. Therefore, if you save data with WITHOUT PURGE specified, do not perform data unloading or data loading.

In the case of Figure 13-74, if the data in RD02 (whose storage condition is ='B') is unloaded and then loaded into the post-combination RDAREA, the data is registered twice.

(b) Notes about combining into an RDAREA with OTHERS specified

If combine processing is performed when both the following conditions are satisfied, there will be no RDAREA for storing pre-combination data:

A combination-target RDAREA is an RDAREA with no storage condition specified or OTHERS specified.

The data is to be combined into an RDAREA with OTHERS specified.

Figures 13-75 and 13-76 show the cases where there will be no RDAREA for storing data after combine processing.

Figure 13-75 Case where there will be no RDAREA for storing data after combine processing (part 1)

Figure 13-76 Case where there will be no RDAREA for storing data after combine processing (part 2)

13.12.10 Relationship with other facilities

Organization of this subsection

(1) Invalidating related resources

(2) Referential constraint and check constraint

(3) Inner replica facility

(4) Concurrent execution with a utility

(1) Invalidating related resources

If a routine has been defined for a table whose partitioning storage conditions are changed, the routine is invalidated. This also includes a routine created using a trigger definition (including a trigger routine created internally by HiRDB in a referential constraint operation).

You must use ALTER ROUTINE to re-create the invalidated routine.

(2) Referential constraint and check constraint

For details about the handling when partitioning storage conditions are changed for a referenced table, a referencing table, and a check constraint table, see 13.13.10 Handling when referential constraint and check constraint are used.

(3) Inner replica facility

When the inner replica facility is used, you must synchronize the generation numbers of all the tables whose partitioning storage conditions are to be changed and the RDAREAs storing the related resources. If referential constraint is used, you must synchronize the generation numbers of all RDAREAs storing referencing tables and referenced tables. Note that when partitioning storage conditions are changed, data is deleted from all generations of RDAREAs.

(4) Concurrent execution with a utility

You cannot change partitioning storage conditions while a utility that updates the database is executing (such as the database load utility or the database reorganization utility). If you change partitioning storage conditions at such a time, data that does not satisfy the partitioning storage conditions may be registered in the database.

13.13 Changing a table's partitioning storage conditions

This section describes how to change a table's partitioning storage conditions.

Organization of this section

13.13.1 Examples (in the case of boundary value specification)

13.13.2 Examples (in the case of storage condition specification)

13.13.3 Re-registering the data

13.13.4 Reusing RDAREAs

13.13.5 Examples of the database reorganization utility and database load utility

13.13.6 Splitting or combining a table containing a non-partitioning key index

13.13.7 Splitting or combining when an index is incomplete

13.13.8 Checking the number of items of data following splitting or combining

13.13.9 Operation when an error occurs

13.13.10 Handling when referential constraint and check constraint are used

13.13.1 Examples (in the case of boundary value specification)

This subsection describes how to change a table's partitioning storage conditions (in the case of boundary value specification).

You should always make a backup before you change a table's partitioning storage conditions.

Organization of this subsection

(1) Example 1 (basic split operation)

(2) Example 2 (splitting an RDAREA without deleting its data and using the pre-split RDAREA after splitting)

(3) Example 3 (operation in which the split-target RDAREA is being used for another boundary value)

(4) Example 4 (operation in which a pre-combination RDAREA is used as the post-combination RDAREA)

(5) Example 5 (operation in which no pre-combination RDAREA is used as the post-combination RDAREA)

(6) Example 6 (operation in which a combination-target RDAREA is being used for another boundary value)

(1) Example 1 (basic split operation)

This section explains how to split a data storage range by creating new RDAREAs when a space shortage occurs in the RDAREA for a given storage range. You may use the original RDAREAs as post-splitting RDAREAs or you may create completely new RDAREAs. This subsection describes an example of the basic split operation (in which the original RDAREA is used).

Note: The numbers in the figure (1. through 3.) correspond to the numbers in the procedure below.

Procedure

Use the database reorganization utility (pdrorg) to unload the table data from the RDAREA (R02) whose storage condition is to be changed and save it in a format that can be used as the input to the database load utility (pdload).

Use ALTER TABLE to specify the new partitioning boundary values. During this process, data in the splitting-target RDAREAs (R02 and RI02) is deleted.

Using the unload data file created in step 1 as the input file, execute the database load utility (pdload) to load data in the addition mode into the split RDAREAs for storing the partitioned boundary values on an RDAREA-by-RDAREA basis.
Because the unload data file contains data that does not match the split storage conditions, data error information is output. If you do not need the data error information, you can suppress its output by specifying divermsg=off in the option statement.

Check the number of items of data after the data has been loaded. For details, see 13.13.8 Checking the number of items of data following splitting or combining.

Use ALTER ROUTINE to re-create the routines and triggers that were invalidated in step 2.

(2) Example 2 (splitting an RDAREA without deleting its data and using the pre-split RDAREA after splitting)

This section explains how to create new RDAREAs for future use for data in RDAREAs that increase in size over time. In this case, it is assumed that the RDAREA to be split does not store data with a larger value than the post-splitting boundary value.

This subsection describes an example of splitting an RDAREA without deleting its data and using the pre-split RDAREA after splitting. In this example, the registration date is used as the partitioning key, and it is assumed that no data for 2005 and beyond is stored in R03. The example creates in the table a new RDAREA for storing data for 2005 and beyond.

Note: The numbers in the figure (1. and 2.) correspond to the numbers in the procedure below.

Procedure

Confirm that the RDAREA containing the splitting-target boundary value contains only data for the post-splitting storage condition (SELECT MAX(partitioning-key-column-name) FROM table-name WHERE partitioning-key-column-name > post-splitting-boundary-value). If data other than data that satisfies the post-splitting storage condition (data for 2005 and beyond) is present, use the procedure in 13.13.1(1) Example 1 (basic split operation) above.
If you do not execute this step and data not satisfying the post-splitting storage condition remains, you can implement a recovery procedure. For details about this procedure, see 13.13.9(2) Recovery procedure when data not satisfying the post-splitting storage condition remains.

Use ALTER TABLE to specify the new partitioning boundary values. For this step, specify WITHOUT PURGE.

Use ALTER ROUTINE to re-create the routines and triggers that were invalidated in step 2.

(3) Example 3 (operation in which the split-target RDAREA is being used for another boundary value)

If the splitting-target RDAREA is being used for another boundary value (storage range), the data for the other boundary value is also deleted. For this reason, when the splitting-target RDAREA is being used for another boundary value, you must be careful when you use the database load utility (pdload) to load the data that was unloaded by the database reorganization utility (pdrorg) before splitting.

This subsection describes an example of the operation when the split-target RDAREA is being used for another boundary value.

Note: The numbers in the figure (1. through 3.) correspond to the numbers in the procedure below.

Procedure

Use the database reorganization utility (pdrorg) to unload the table data from the RDAREA whose storage condition is to be changed and save it in a format that can be used as the input to the database load utility (pdload). During this process, data for '2002-12-31' or earlier is also unloaded.

Use ALTER TABLE to specify the new partitioning boundary values. During this process, data in the splitting-target RDAREAs (R01 and RI01) (including data for '2002-12-31' or earlier) is deleted.

Using the unload data file created in step 1 as the input file, execute the database load utility (pdload) to load data in the addition mode into the split RDAREAs for storing the partitioned boundary values on an RDAREA-by-RDAREA basis. During this process, you must load data into R01 as well because the data in R01 was also deleted in step 2.
Because the unload data file contains data that does not match the split storage conditions, data error information is output. If you do not need the data error information, you can suppress its output by specifying divermsg=off in the option statement.

Check the number of items of data after the data has been loaded. For details, see 13.13.8 Checking the number of items of data following splitting or combining.

Use ALTER ROUTINE to re-create the routines and triggers that were invalidated in step 2.

(4) Example 4 (operation in which a pre-combination RDAREA is used as the post-combination RDAREA)

This section explains how to combine data storage ranges into a single RDAREA when RDAREAs in a contiguous storage have much free space. The post-combination RDAREA may use one of the pre-combination RDAREAs or some other RDAREA.

This subsection describes an example of the operation when one of the pre-combination RDAREAs is used as the post-combination RDAREA.

Note: The numbers in the figure (1. through 3.) correspond to the numbers in the procedure below.

Procedure

Use the database reorganization utility (pdrorg) to unload the table data from all combination-target RDAREAs that will not be used after combining (R03 and R04) and save it in a format that can be used as the input to the database load utility (pdload).

Use ALTER TABLE to specify the boundary values to be combined. Specify WITHOUT PURGE for R02 because this is the RDAREA that will be used again after combining.

Using all unload data files created in step 1 as the input files, execute the database load utility (pdload) to load data in the addition mode into the combined RDAREA for storing the combined boundary values. You must be careful during this process because if you load data in the creation mode, the data in R02 before combining will be deleted. If you load data in the creation mode by mistake, use a backup to restore the system to its status before you executed ALTER TABLE, then start over from the beginning.

Check the number of items of data after the data has been loaded. For details, see 13.13.8 Checking the number of items of data following splitting or combining.

Use ALTER ROUTINE to re-create the routines and triggers that were invalidated in step 2.

(5) Example 5 (operation in which no pre-combination RDAREA is used as the post-combination RDAREA)

This example combines a data storage range into a single RDAREA because there is a large amount of free space in the RDAREAs for the particular contiguous storage range. One of the pre-combination RDAREAs may or may not be used as the post-combination RDAREA.

This subsection describes an example of the operation when no pre-combination RDAREA is used as the post-combination RDAREA.

Note: The numbers in the figure (1. through 3.) correspond to the numbers in the procedure below.

Procedure

Use the database reorganization utility (pdrorg) to unload the table data from all combination-target RDAREAs (R02, R03, and R04) and save it in a format that can be used as the input to the database load utility (pdload).

Use ALTER TABLE to specify the boundary values to be combined.

Using all the unload data files created in step 1 as the input files, execute the database load utility (pdload) to load data in the addition mode into the combined RDAREA for storing the combined boundary values, on an RDAREA-by-RDAREA basis.

Check the number of items of data after the data has been loaded. For details, see 13.13.8 Checking the number of items of data following splitting or combining.

Use ALTER ROUTINE to re-create the routines and triggers that were invalidated in step 2.

(6) Example 6 (operation in which a combination-target RDAREA is being used for another boundary value)

If a combination-target RDAREA is also being used for another boundary value (storage range), the data for the other boundary value is also deleted. Therefore, you must be careful to use the database load utility (pdload) after combining to load the data that was unloaded by the database reorganization utility (pdrorg) before combining into the RDAREA whose data was deleted.

This subsection describes an example of the operation when a combination-target RDAREA is being used for another boundary value.

Note: The numbers in the figure (1. through 4.) correspond to the numbers in the procedure below.

Procedure

Use the database reorganization utility (pdrorg) to unload the table data from all combination-target RDAREAs and save it in a format that can be used as the input to the database load utility (pdload). During this process, data for '2002-12-31' or earlier is also unloaded.

Use ALTER TABLE to specify the boundary values to be combined. During this process, data in the RDAREA (R01) being used for the other boundary value is also deleted.

Using all unload data files created in step 1 as the input files, execute the database load utility (pdload) to load data in the addition mode into the combined RDAREA for storing the combined boundary values, on an RDAREA-by-RDAREA basis.

The data in R01, which is being used for the other boundary value, has been deleted. Therefore, using the unload data file containing the data from R01 as the input, use the database load utility (pdload) to add the data in the addition mode on an RDAREA-by-RDAREA basis.

Check the number of items of data after the data has been loaded. For details, see 13.13.8 Checking the number of items of data following splitting or combining.

Use ALTER ROUTINE to re-create the routines and triggers that were invalidated in step 2.

13.13.2 Examples (in the case of storage condition specification)

This subsection describes how to change a table's partitioning storage conditions (in the case of storage condition specification).

You should always make a backup before you change a table's partitioning storage conditions.

Organization of this subsection

(1) Example 1 (splitting an RDAREA for which storage conditions with multiple values have been specified)

(2) Example 2 (adding partitioning storage conditions)

(3) Example 3 (splitting an RDAREA without deleting its data and using the pre-split RDAREA after splitting)

(4) Example 4 (changing the partitioning storage conditions and then combining RDAREAs)

(5) Example 5 (deleting partitioning storage conditions)

(6) Example 6 (performing split and combine operations consecutively)

(1) Example 1 (splitting an RDAREA for which storage conditions with multiple values have been specified)

This example changes the partitioning storage conditions and splits RDAREA R02 because it does not have sufficient free space.

Note: The numbers in the figure (1. through 3.) correspond to the numbers in the procedure below.

Use the database reorganization utility (pdrorg) to unload the table data from the RDAREA (R02) whose storage conditions are to be changed, and save it in a format that can be used as the input to the database load utility (pdload).

Use ALTER TABLE to split the RDAREA. During this process, data in the split-target RDAREAs (R02 and RI02) is deleted.

Perform data loading into the RDAREA (R02) using the addition mode of the database load utility (pdload). Perform this operation for each RDAREA using the unload data file created in step 1 as the input file.
Because the unload data file contains data that does not match the split storage conditions, data error information is output. If you do not need the data error information, you can suppress its output by specifying divermsg=off in the option statement.

Check the number of items of data after the data has been loaded. For details, see 13.13.8 Checking the number of items of data following splitting or combining.

Use ALTER ROUTINE to re-create the routines and triggers that were disabled in step 2.

(2) Example 2 (adding partitioning storage conditions)

This example adds a partitioning storage condition for a table that uses the branch code as the partitioning key (the partitioning storage condition will be branch code '5').

Provide new RDAREAs (R04 and RI04) to store the data whose branch code is '5'.

Extract the data whose branch code is '5' from the RDAREA with no storage condition specified (R03) and store it in the new RDAREA (R04).

Use the pre-split RDAREA also after splitting.

Note: The numbers in the figure (1. through 3.) correspond to the numbers in the procedure below.

Use the database reorganization utility (pdrorg) to unload the table data from the RDAREA (R03) whose storage conditions are to be changed and save it in a format that can be used as the input to the database load utility (pdload).

Use ALTER TABLE to split the RDAREA. During this process, data in the split-target RDAREAs (R03 and RI03) is deleted.

Perform data loading into the RDAREAs (R03 and R04) using the addition mode of the database load utility (pdload). Perform this operation for each RDAREA using the unload data file created in step 1 as the input file.
Because the unload data file contains data that does not match the split storage conditions, data error information is output. If you do not need the data error information, you can suppress its output by specifying divermsg=off in the option statement.

Check the number of items of data after the data has been loaded. For details, see 13.13.8 Checking the number of items of data following splitting or combining.

Use ALTER ROUTINE to re-create the routines and triggers that were disabled in step 2.

(3) Example 3 (splitting an RDAREA without deleting its data and using the pre-split RDAREA after splitting)

This example changes the partitioning storage conditions for a table that uses the branch code as the partitioning key. It performs the splitting operation as follows:

Splits the RDAREA without deleting its data.

Provides new RDAREAs (R04 and RI04) to store the data whose branch code is '5'.

Use the pre-split RDAREA also after splitting.

This example assumes that RDAREA R03 does not already contain data whose branch code is '5'.

Note: The numbers in the figure (1. and 2.) correspond to the numbers in the procedure below.

Make sure that the split-target table does not contain any data that matches the storage condition to be added (storage condition = '5').
If the table contains data whose storage condition = '5', split it using the method described in 13.13.2(2) Example 2 (adding partitioning storage conditions). If you do not split the table with this method and the data that does not satisfy the storage condition remains after the splitting operation, you must recover the data using the method described in 13.13.9(2) Recovery procedure when data not satisfying the post-splitting storage condition remains.

Use ALTER TABLE to split the RDAREA. In this case, specify WITHOUT PURGE.

Use ALTER ROUTINE to re-create the routines and triggers that were disabled in step 2.

(4) Example 4 (changing the partitioning storage conditions and then combining RDAREAs)

This example combines into R02 the storage conditions that have been split into RDAREAs R02, R03, and R04.

Note: The numbers in the figure (1. through 3.) correspond to the numbers in the procedure below.

Use the database reorganization utility (pdrorg) to unload data from the RDAREAs (R03 and R04) in a format that can be used as the input to the database load utility (pdload).

Use ALTER TABLE to combine the RDAREAs. In this case, specify WITHOUT PURGE because R02 will be used as is after the combine operation.

Perform data loading into RDAREA R02 using the addition mode of the database load utility (pdload). Perform this operation for each RDAREA using the unload data file created in step 1 as the input file.
Note that if data loading is performed in the creation mode, data is deleted from the pre-combination R02. If you have performed data loading in the creation mode by mistake, restore the data from a backup to its status immediately before execution of ALTER TABLE, and then perform the procedure again.

Check the number of items of data after the data has been loaded. For details, see 13.13.8 Checking the number of items of data following splitting or combining.

Use ALTER ROUTINE to re-create the routines and triggers that were disabled in step 2.

(5) Example 5 (deleting partitioning storage conditions)

This example combines into R03 the storage conditions that have been split into RDAREAs R03, R04, and R05, and then deletes the storage conditions for R03 and R04.

Note: The numbers in the figure (1. through 3.) correspond to the numbers in the procedure below.

If you do not need the data in RDAREAs R03 and R04 whose storage conditions are to be deleted, you can skip steps 1 and 3 (unloading and data loading).

Use the database reorganization utility (pdrorg) to unload data from RDAREAs R03 and R04 in a format that can be used as the input to the database load utility (pdload).

Use ALTER TABLE to combine the RDAREAs.

Perform data loading into RDAREA R05 using the addition mode of the database load utility (pdload). Perform this operation for each RDAREA using the unload data file created in step 1 as the input file.

Check the number of items of data after the data has been loaded. For details, see 13.13.8 Checking the number of items of data following splitting or combining.

Use ALTER ROUTINE to re-create the routines and triggers that were disabled in step 2.

(6) Example 6 (performing split and combine operations consecutively)

This example splits RDAREA R01 into R01 and R04 and then combines RDAREAs R02 and R04 into R02.

Note: The numbers in the figure (1. through 4.) correspond to the numbers in the procedure below.

Use the database reorganization utility (pdrorg) to unload data from RDAREA R01 in a format that can be used as the input to the database load utility (pdload).

Use ALTER TABLE to split the RDAREA.

Use ALTER TABLE to combine the RDAREAs.

Perform data loading into RDAREAs R01 and R02 using the addition mode of the database load utility (pdload). Perform this operation for each RDAREA using the unload data file created in step 1 as the input file.
Because the unload data file contains data that does not match the split storage conditions, data error information is output. If you do not need the data error information, you can suppress its output by specifying divermsg=off in the option statement.

Check the number of items of data after the data has been loaded. For details, see 13.13.8 Checking the number of items of data following splitting or combining.

Use ALTER ROUTINE to re-create the routines and triggers that were disabled in steps 2 and 3.

Reference note

Normally, it would be necessary to unload data from R02 and R04 before performing step 3. However, when two SQL statements are executed consecutively to perform split and combine operations, as in this example, unloading is not needed prior to step 3 because the unload data files created in step 1 can be used as input information for data loading in step 4.

13.13.3 Re-registering the data

It was explained in 13.13.1 Examples (in the case of boundary value specification) and 13.13.2 Examples (in the case of storage condition specification) that data that has been unloaded is loaded by executing the database load utility (pdload) for each RDAREA after a split operation and registration. This operation allows parallel execution of the database load utility (pdload) on multiple RDAREAs for data loading, thereby minimizing the impact of job stoppage. This operation also provides an advantage, in that the lock set during execution of the database load utility (pdload) is limited to the RDAREAs into which the data is to be loaded, and jobs that access other RDAREAs are not affected.

However, there are also disadvantages. Because the user must determine accurately the RDAREAs into which data is to be re-registered, the operation is prone to mistakes. Also, the database load utility (pdload) must be executed multiple times when it is necessary to register data into multiple RDAREAs.

For this reason, if it is possible to allocate sufficient job stoppage time and to halt access to the tables that are to be split or combined for the duration of the stoppage, Hitachi recommends that you load data with the database load utility (pdload) on a table-by-table basis, and not on an RDAREA-by-RDAREA basis.

13.13.4 Reusing RDAREAs

In the case of a database in which the volume of data increases over time, you can reuse RDAREAs by deleting data from RDAREAs storing old data and reusing those RDAREAs to store new data. Figure 13-77 shows an example of reusing an RDAREA.

Figure 13-77 Example of reusing an RDAREA

Note: The numbers in the figure (1. and 2.) correspond to the numbers in the procedure below.

Procedure

The combine facility for partitioning storage conditions is used to combine into RDAREA R02 the data for 2002 and earlier, which is stored in R01 and R02. During this process, the system deletes all data from R01.

The split facility for partitioning storage conditions can be used to split the data for 2004 and beyond, and to store the data for 2004 in R04 and the data for 2005 and beyond in R01; this means that R01, which had been used to store the data for 2001 and earlier, is reused.

Figure 13-78 shows the procedure for reusing RDAREAs.

Figure 13-78 Procedure for reusing RDAREAs

Note: The numbers in the figure (1. and 2.) correspond to the numbers in the procedure below.

Procedure

To separate R01 from the table, use ALTER TABLE to combine the minimum boundary value ('2001-12-31') into the boundary value ('2002-12-31') that is one increment greater than the minimum boundary value. For the post-combination RDAREAs, specify the RDAREAs (R02 and RI02) that will store the boundary value that is one increment greater than the minimum boundary value. Because the data in R02 must be retained, specify WITHOUT PURGE. As a result, R01 becomes separated from the table in terms of definition, and the data is deleted from the table in R01.

Use ALTER TABLE to split the RDAREA (R04) storing values greater than the maximum boundary value at a value ('2004-12-31') that is equal to or greater than the maximum value of the partitioning keys stored in that RDAREA. For the post-splitting RDAREAs, specify the RDAREAs (R04 and RI04) that used to store values greater than the maximum boundary value and the RDAREAs (R01 and RI01) that used to store values smaller than the minimum boundary value. Because the data in R04 must be retained, specify WITHOUT PURGE.
Note that if there is data for '2005-1-1' and beyond in R04, there is a possibility that data not matching the storage conditions may remain in R04. For details, see 13.13.1(2) Example 2 (splitting an RDAREA without deleting its data and using the pre-split RDAREA after splitting).

13.13.5 Examples of the database reorganization utility and database load utility

Organization of this subsection

(1) Example of the database reorganization utility (pdrorg)

(2) Example of the database load utility (pdload)

(1) Example of the database reorganization utility (pdrorg)

The database reorganization utility (pdrorg) must unload data on an RDAREA-by-RDAREA basis and save it in a format that can be used as the input to the database load utility (pdload). Figure 13-79 shows an example of the database reorganization utility. In this example, the required unload data files are created before the table's partitioning storage conditions are changed.

Figure 13-79 Example of the database reorganization utility

(a) Unloading R02

The following is an example of the control statement for unloading R02, as well as the command line:

Control statement (control_file1)

  unload /pdrorg/unld01

Command line

  pdrorg -k unld -r R02 -W bin -j -t T1 control_file1

Explanation

-k: Specifies unld for unloading.

-r: Specifies the name of the RDAREA to be unloaded.

-W bin: Specifies unloading of data into a format that can be used by the database load utility. This option must be specified.

-j: Specifies that the table to be unloaded contains an abstract data type that has a BLOB column or LOB attribute.

-t: Specifies the table identifier of the table to be unloaded.

control_file1: Specifies the name the control statement file.

(b) Unloading R03

The following is an example of the control statement for unloading R03, as well as the command line:

Control statement (control_file2)

  unload /pdrorg/unld02

Command line

  pdrorg -k unld -r R03 -W bin -j -t T1 control_file2

Explanation

-k: Specifies unld for unloading.

-r: Specifies the name of the RDAREA to be unloaded.

-W bin: Specifies unloading of data into a format that can be used by the database load utility. This option must be specified.

-j: Specifies that the table to be unloaded contains an abstract data type that has a BLOB column or LOB attribute.

-t: Specifies the table identifier of the table to be unloaded.

control_file2: Specifies the name of the control statement file.

(2) Example of the database load utility (pdload)

The database load utility (pdload) must execute on the unload data files created by the database reorganization utility (pdrorg) on an RDAREA-by-RDAREA basis in the addition mode. Figure 13-80 shows an example of the database load utility. In this example, a database is created from a table whose partitioning storage conditions have been changed.

Figure 13-80 Example of the database load utility

(a) Combining R01 and R02 into R06

The following is an example of the control statement for combining R01 and R02 into R06, as well as the command line:

Control statement (control_file)

option divermsg=off
source R06 /pdrorg/unld01,/pdrorg/unld02

Command line

pdload -W -b T1 control_file

Explanation

-W: Specifies use of a file output by the database reorganization utility as the input file. This option must be specified.

-b: Specifies that the input file is binary. This must option be specified.

T1: Specifies the identifier of the target table.

control_file: Specifies the name of the control statement file.

13.13.6 Splitting or combining a table containing a non-partitioning key index

If a table contains a non-partitioning key index that does not correspond on a one-to-one basis to the table RDAREAs, that table cannot be split or combined.

Procedure

Delete the non-partitioning key index.

Unload the table data from the RDAREAs to be split or combined.

Use ALTER TABLE to specify boundary values or the RDAREA to be split.

Use the database load utility to load data from the unload data file created in step 2 into the split or combined RDAREAs.

Redefine the non-partitioning key index.

13.13.7 Splitting or combining when an index is incomplete

Once the database load utility has executed, you must not change partitioning storage conditions before indexes are re-created.

If you change partitioning storage conditions while indexes are incomplete, you must use the database reorganization utility to re-create the indexes.

13.13.8 Checking the number of items of data following splitting or combining

Before you can change partitioning storage conditions, you must unload data; after you have changed the partitioning storage conditions, you must reload the data. It is important that you check that the original number of items of data before the change matches the number of items of data after the data has been re-registered. The two methods described below are provided for this purpose. If you need a highly accurate check of the number of data items, Hitachi recommends that you use the second method.

Using the number of data items output by the utility

Record the number of items of data that were unloaded, which is indicated in the KFPL00723-I message that is output when the database reorganization utility has executed.

After you change the partitioning storage conditions, record the number of items of data that are loaded, which is indicated in the KFPL00723-I message that is output during data loading. If you load data into multiple RDAREAs, record the grand total.

Make sure that the number of data items in step 1 matches the number of data items in step 2.

Executing the database condition analysis utility before and after a change in partitioning storage conditions
You can check the number of items of data stored in RDAREAs by executing a condition analysis for each table with the database condition analysis utility (pddbst).

Execute a condition analysis for each table with the database condition analysis utility (pddbst) and record the grand total of the values shown as the Row Count for each target RDAREA, as indicated in the example shown below.

pddbst -t table-name -s

The following are the execution results:

RD Area Name   : RD002
 Server        : bes1
 Status        :
 Original RD Area Name : RD002
 Generation Number :  0   Replica RD Area Count :  0
 History1 Hold Status :      Hold Code :     0  Hold Time :
 History2 Hold Status :      Hold Code :     0  Hold Time :
 Job Name      :         Line Count :                Index Method :
 Unused Segment:       3999
 Search Mode : INS   Segment Reuse :          - segments
 Reuse Search Failure :          0/         0
         Used(Full)       Used(      Full)        Sum
 Segment 100%(  0%)          1(         0)          1
 Page     30%(  0%)          3(         0)         10
 Row Count     :                   200

RD Area Name   : RD004
 Server        : bes2
 Status        :
 Original RD Area Name : RD004
 Generation Number :  0   Replica RD Area Count :  0
 History1 Hold Status :      Hold Code :     0  Hold Time :
 History2 Hold Status :      Hold Code :     0  Hold Time :
 Job Name      :         Line Count :                Index Method :
 Unused Segment:       3999
 Search Mode : INS   Segment Reuse :          - segments
 Reuse Search Failure :          0/         0
         Used(Full)       Used(      Full)        Sum
 Segment 100%(  0%)          1(         0)          1
 Page     20%(  0%)          2(         0)         10
 Row Count     :                   100

After you change the partitioning storage conditions and use the database load utility to load the data, use the same procedure as in step 1 and again record the grand total.

Check that the grand total obtained in step 1 matches the grand total obtained in step 2.

If the numbers of data items do not match, the following are possible causes and corrective measures:

Possible cause | Corrective measure
When the database load utility was executed to load data, the creation mode was used. You must use the addition mode. | You must use a backup to restore the system, then re-execute the utility.
Data loading was not executed for the RDAREA into which the data was supposed to be loaded. | Load data from the unload data file into the correct RDAREA.

13.13.9 Operation when an error occurs

Organization of this subsection

(1) Rollback when an error occurs

(2) Recovery procedure when data not satisfying the post-splitting storage condition remains

(1) Rollback when an error occurs

If processing terminates abnormally during execution of ALTER TABLE, no recovery operation is required because the table changes are rolled back. You can simply re-execute ALTER TABLE.

However, once execution of ALTER TABLE has been completed, RDAREA data may have been deleted. Therefore, you cannot restore the system to its status before execution of ALTER TABLE if you did not make backup.

For this reason, it is important to make a backup in advance of performing any of these operations so that the system can be restored from the backup if necessary. You should make a backup of the following:

Master directory

Data directory

Dictionary RDAREAs (including dictionary LOB RDAREAs)

RDAREAs whose partitioning conditions are to be changed (including index RDAREAs and LOB RDAREAs). If the inner replica facility is used, you should back up all generations of RDAREAs whose partitioning conditions are to be changed.

(2) Recovery procedure when data not satisfying the post-splitting storage condition remains

If WITHOUT PURGE was wrongly specified, data may remain that does not match the storage conditions after splitting. In such a case, data retrieval operations on the basis of a partitioning key may not be possible and may terminate in an error. Figure 13-81 shows an example of the recovery procedure when data not satisfying the post-splitting storage condition remains. This example shows the recovery procedure when data that should have been stored in R04 remains instead in R03.

Figure 13-81 Example of the recovery procedure when data not satisfying the post-splitting storage condition remains

Note: The numbers in the figure (1. through 4.) correspond to the numbers in the procedure below.

Procedure

Unload the table data from the RDAREA into which the incorrect data is stored, and save it in a format that can be used as the input to the database load utility.

Unload the table data from the RDAREA into which the data should have been stored, and save it in a format that can be used as the input to the database load utility.

Using the unload data file created in step 1 as the input file, execute the database load utility in the creation mode for the RDAREA that stores the wrong data on an RDAREA-by-RDAREA basis.
Because the unload data file contains data that does not match the split storage conditions, data error information is output. If you do not need the data error information, you can suppress its output by specifying divermsg=off in the option statement.

Using the unload data files created in steps 1 and 2 as the input files, execute the database load utility in the creation mode for the RDAREAs that should have stored the data on an RDAREA-by-RDAREA basis.
Because the unload data files contain data that does not match the split storage conditions, data error information is output. If you do not need the data error information, you can suppress its output by specifying divermsg=off in the option statement.

13.13.10 Handling when referential constraint and check constraint are used

Organization of this subsection

(1) Changing the partitioning storage conditions of a referenced table

(2) Changing partitioning storage conditions for a referencing table

(3) Changing partitioning storage conditions for a table for which check constraint has been defined

(1) Changing the partitioning storage conditions of a referenced table

When a partitioning storage condition is changed, table data may be deleted. Consequently, when the partitioning storage conditions of a referenced table are changed, matching between the referenced table and the referencing table cannot be guaranteed.

When WITHOUT PURGE can be used during splitting, table data will not be deleted. However, as explained in 13.13.9(2) Recovery procedure when data not satisfying the post-splitting storage condition remains, if data remains that does not match the storage conditions after the partitioning storage conditions have been changed, that data cannot be retrieved. As a result, a mismatch occurs between this data and the data in the referencing table. The following shows an example.

Explanation:

In this example, R03 for the referenced table contains the data 2004-12-30 and this data also exists in the referencing table. Therefore, the referential constraint is satisfied.

If WITHOUT PURGE is specified, the data 2004-12-30 remains in R03 that is to store the data 2001-12-31 through 2002-12-31. In this case, the referenced table cannot be searched for the data 2004-12-30, and the referential constraint is not satisfied.

If pd_check_pending=USE is specified in the system definition and the partitioning storage condition is changed for a referenced table, the referencing table is placed in check pending status whether or not WITHOUT PURGE is specified. If pd_check_pending=NOUSE is specified, the referencing table is placed in non-check pending status. Therefore, if you have changed the partitioning storage conditions, you must check the table's integrity and release the table from check pending status. For details, see the manual HiRDB Version 8 Installation and Design Guide.

(2) Changing partitioning storage conditions for a referencing table

The following describes the operation when partitioning storage conditions are changed for a referencing table.

When pd_check_pending=USE is specified in the system definition
If you have changed the partitioning storage conditions for a referencing table, an RDAREA from which table data has been deleted is placed in non-check pending status. If all RDAREAs containing the subject table are placed in non-check pending status, the table is released from check pending status (the value of the CHECK_PEND columns in the SQL_TABLES and SQL_REFERENTIAL_CONSTRAINTS tables becomes the null value).

When pd_check_pending=NOUSE is specified in the system definition
If you have changed the partitioning storage conditions for a referencing table, an RDAREA whose table data has been deleted is placed in non-check pending status.

(3) Changing partitioning storage conditions for a table for which check constraint has been defined

The following describes the operation when partitioning storage conditions are changed for a table for which check constraint has been defined.

When pd_check_pending=USE is specified in the system definition
If you have changed the partitioning storage conditions for a table for which check constraint has been defined, an RDAREA from which table data has been deleted is placed in non-check pending status. If all RDAREAs containing the subject table are placed in non-check pending status, the table is released from check pending status (the value of the CHECK_PEND2 columns in the SQL_TABLES and SQL_CHECKS tables becomes the null value).

When pd_check_pending=NOUSE is specified in the system definition
If you have changed the partitioning storage conditions for a table for which check constraint has been defined, an RDAREA whose table data has been deleted is placed in non-check pending status.

13.14 Changing the hash function

Executor: HiRDB administrator and table owner

When there are significant differences from one RDAREA to another in terms of the number of rows stored in the RDAREAs, processing efficiency for the table may degrade. In such a case, you can improve the table's processing efficiency by changing the hash function so as to equalize the numbers of rows stored in the RDAREAs.

Notes

Changing the hash function of a table invalidates any stored routines that use that table. If this happens, use the ALTER PROCEDURE or ALTER ROUTINE statement to re-create each stored routine.

Changing the hash function of a table specified in a trigger SQL statement invalidates the trigger. If this happens, use the ALTER TRIGGER or ALTER ROUTINE statement to re-create the trigger.

After the hash function has been changed, execute the optimizing information collection utility (pdgetcst command) if necessary. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

The hash function can be changed for a table in which an abstract data type of a plug-in that has the constructor reverse generation function is defined. For example, the hash function of a table in which the following abstract data type is defined can be changed:

SGMLTEXT (because the LOB attribute is present, the -j option must be specified)

Organization of this section

13.14.1 Example 1: Flexible hash partitioning

13.14.2 Example 2: FIX hash partitioning

13.14.1 Example 1: Flexible hash partitioning

This example changes to HASH6 the hash function of table TABLE01. TABLE01 is flexible hash partitioned.

Organization of this subsection

(1) Use the ALTER TABLE statement to change the hash function

(1) Use the ALTER TABLE statement to change the hash function

ALTER TABLE TABLE01 CHANGE HASH HASH6;

13.14.2 Example 2: FIX hash partitioning

This example changes to HASH6 the hash function of table TABLE01. TABLE01 is flexible hash partitioned.

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be unloaded

(2) Use the pdrorg command to unload data from TABLE01

(3) Use the pdrels command to release RDAREAs from shutdown status

(4) Use the PURGE TABLE statement to delete TABLE01's data

(5) Use the ALTER TABLE statement to change the hash function

(6) Use the pdhold command to shut down RDAREAs to be reloaded

(7) Use the pdrorg command to reload data into TABLE01

(8) Back up the RDAREAs in which data was reloaded

(9) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be unloaded

pdhold -r RDAREA01,RDAREA02,...

(2) Use the pdrorg command to unload data from TABLE01

pdrorg -k unld -j -t TABLE01 -g /pdrorg/unld02

Explanation

-k: Specifies unld for unloading.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be unloaded.

-t: Specifies the name of the table that is to be unloaded.

-g: Specifies that TABLE01 is row-partitioned between servers in a HiRDB/Parallel Server. Specifying the -g option consolidates the unload data files (into a single file).

/pdrorg/unld02: Specifies the name of the control statements file for the pdrorg command.

(3) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

(4) Use the PURGE TABLE statement to delete TABLE01's data

PURGE TABLE TABLE01;

When the hash function of a table with FIX hash partitioning is changed, the table data must be deleted.

(5) Use the ALTER TABLE statement to change the hash function

ALTER TABLE TABLE01 CHANGE HASH HASH6;

(6) Use the pdhold command to shut down RDAREAs to be reloaded

pdhold -r RDAREA01,RDAREA02,...

(7) Use the pdrorg command to reload data into TABLE01

pdrorg -k reld -j -t TABLE01 -g /pdrorg/reld02

Explanation

-k: Specifies reld for reloading.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be reloaded.

-t: Specifies the name of the table that is to be reloaded.

-g: If the -g option was specified in step (2), specify it here as well.

/pdrorg/reld02: Specifies the name of the control statements file for the pdrorg command.

(8) Back up the RDAREAs in which data was reloaded

Because you reloaded data in the pre-update acquisition mode (default), back up the RDAREAs in which data was reloaded. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(9) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.15 Changing a table's partitioning definition

Executor: HiRDB administrator and table owner (or user with DBA privilege)

This section explains how to change the partitioning definition of a table. The following partitioning definition changes are explained:

Changing from key range partitioning to hash partitioning

Changing the partitioning key column

Changing from hash partitioning to key range partitioning

Allocating a different RDAREA each month

Reference note

After the table partitioning method has been changed, execute the optimizing information collection utility (pdgetcst command) if necessary. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

Organization of this section

13.15.1 Example 1 (changing from key range partitioning to hash partitioning and changing the partitioning key column)

13.15.2 Example 2 (changing from hash partitioning to key range partitioning)

13.15.3 Example 3 (allocating a different RDAREA each month)

13.15.1 Example 1 (changing from key range partitioning to hash partitioning and changing the partitioning key column)

Changing the row partitioning method of a table (TABLE01) from key range partitioning to hash partitioning

Changing the partitioning key column of a table (TABLE01)

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be unloaded

(2) Use the pdrorg command to unload data from TABLE01

(3) Use the pdrels command to release RDAREAs from shutdown status

(4) Use the DROP TABLE statement to delete TABLE01

(5) Use the CREATE TABLE statement to redefine the partitioning method for TABLE01

(6) Use the CREATE INDEX statement to redefine the index

(7) Use the pdhold command to shut down RDAREAs into which data is to be loaded

(8) Use the pdload command to load data into TABLE01

(9) Back up the RDAREAs in which data was loaded

(10) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be unloaded

pdhold -r RDAREA01,RDAREA02,...

(2) Use the pdrorg command to unload data from TABLE01

pdrorg -k unld -W bin -j -t TABLE01 -g /pdrorg/unld01

Explanation

-k: Specifies unld for unloading.

-W bin: Specifies that the unload data file is to be used as the input file (binary format) for the pdload command.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be unloaded.

-t: Specifies the name of the table that is to be unloaded.

-g: Specifies that TABLE01 is row-partitioned between servers in a HiRDB/Parallel Server. Specifying the -g option consolidates the unload data files (into a single file).

/pdrorg/unld01: Specifies the name of the control information file for the pdrorg command.

(3) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

(4) Use the DROP TABLE statement to delete TABLE01

DROP TABLE TABLE01;

(5) Use the CREATE TABLE statement to redefine the partitioning method for TABLE01

CREATE TABLE TABLE01 ... ;

(6) Use the CREATE INDEX statement to redefine the index

CREATE INDEX INDX01 ... ;

(7) Use the pdhold command to shut down RDAREAs into which data is to be loaded

pdhold -r RDAREA01,RDAREA02,...

(8) Use the pdload command to load data into TABLE01

pdload -b -W TABLE01 /pdload/load01

Explanation

-b: Specifies that data in binary format is to be loaded.

-W: Specifies that an input data file in binary format, created with the pdrorg command, is to be used.

TABLE01: Specifies the name of the table into which the data is to be loaded.

/pdload/load01: Specifies the name of the control information file for the pdload command.

(9) Back up the RDAREAs in which data was loaded

Because you loaded data in the pre-update acquisition mode (default), back up the RDAREAs in which data was loaded. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(10) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.15.2 Example 2 (changing from hash partitioning to key range partitioning)

The procedure described below can be used to change the row partitioning method from key range partitioning to hash partitioning. This procedure can be used only when no change is made to the structure of the columns containing the partitioning key.

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be unloaded

(2) Use the pdrorg command to unload data from TABLE01

(3) Use the pdrels command to release RDAREAs from shutdown status

(4) Use the DROP TABLE statement to delete TABLE01

(5) Use the CREATE TABLE statement to redefine the partitioning method for TABLE01

(6) Use the CREATE INDEX statement to redefine the index

(7) Use the pdhold command to shut down RDAREAs to be reloaded

(8) Use the pdrorg command to reload data into TABLE01

(9) Back up the RDAREAs in which data was reloaded

(10) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be unloaded

pdhold -r RDAREA01,RDAREA02,...

(2) Use the pdrorg command to unload data from TABLE01

pdrorg -k unld -j -t TABLE01 -g /pdrorg/unld02

Explanation

-k: Specifies unld for unloading.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be unloaded.

-t: Specifies the name of the table that is to be unloaded.

-g: Specifies that TABLE01 is row-partitioned between servers in a HiRDB/Parallel Server. Specifying the -g option consolidates the unload data files (into a single file).

/pdrorg/unld02: Specifies the name of the control information file for the pdrorg command.

(3) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

(4) Use the DROP TABLE statement to delete TABLE01

DROP TABLE TABLE01;

(5) Use the CREATE TABLE statement to redefine the partitioning method for TABLE01

CREATE TABLE TABLE01 ... ;

(6) Use the CREATE INDEX statement to redefine the index

CREATE INDEX INDX01 ... ;

(7) Use the pdhold command to shut down RDAREAs to be reloaded

pdhold -r RDAREA01,RDAREA02,...

(8) Use the pdrorg command to reload data into TABLE01

pdrorg -k reld -j -t TABLE01 -g /pdrorg/reld02

Explanation

-k: Specifies reld for reloading.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be reloaded.

-t: Specifies the name of the table that is to be reloaded.

-g: If the -g option was specified in step (2), specify it here as well.

/pdrorg/reld02: Specifies the name of the control information file for the pdrorg command.

(9) Back up the RDAREAs in which data was reloaded

Because you reloaded data in the pre-update acquisition mode (default), back up the RDAREAs in which data was reloaded. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(10) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.15.3 Example 3 (allocating a different RDAREA each month)

This example assumes that data for five recent months (May through September 2005) is stored. The example uses the hash function HASH0 to delete the data for the oldest month, May 2005, from the RDAREA and then stores the data for the most recent month, October 2005.

Figure 13-82 provides an overview of Example 3 (method for allocating a different RDAREA each month).

Figure 13-82 Overview of Example 3 (method for allocating a different RDAREA each month)

Organization of this subsection

(1) Identify the RDAREA that contains the data for May 2005, which is to be deleted

(2) Use the pdhold command to shut down the RDAREA to be unloaded

(3) Use the pdrorg command to unload data from RDA1 for the ORDER table

(4) Use the pdload command to perform data loading on RDA1 with a data count of 0

(5) Use the pdrels command to release the RDAREA from shutdown status

(1) Identify the RDAREA that contains the data for May 2005, which is to be deleted

(a) Execute the hash function for table partitioning

Use the HiRDB-provided hash function for table partitioning to identify the RDAREA that contains the data for May 2005, which is to be deleted. The table below shows the arguments of the hash function for table partitioning. For details about the hash function for table partitioning, see the manual HiRDB Version 8 UAP Development Guide.

Argument
Specification value

hashcode (hash function code)
p_rdb_HASH0

ncol (number of partitioning key columns)
1

collst (partitioning key specification order and data type code, and data length code)
Data type code: PDSQL_CHAR
Data length code: 8

dadlst (data stored in the partitioning key)
Year, month, date

ndiv (number of table partitions)
5

ncspace (national character for the double-byte space used at the HiRDB servers)
ncspace[0]: 0x81
ncspace[1]: 0x40

flags (space conversion level and whether or not the facility for conversion to a DECIMAL signed normalized number is to be used)
0

rdno (partitioning condition specification order or serial number in the partitioning key)
None

Note:

This example assumes that the character encoding type, space conversion level, and the facility for conversion to a DECIMAL signed normalized number are all omitted.

When the above hash function for table partitioning is executed, rdno=1 is returned as the partitioning condition specification order.

(b) Execute the SQL statement

Based on the result of the hash function for table partitioning, execute the following SQL statement to find the name of the RDAREA:

SELECT RDAREA_NAME
   FROM MASTER.SQL_DIV_TABLE
     WHERE TABLE_SCHEMA='USER1' /* user name         */
       AND TABLE_NAME='ORDER'   /* name of hash-partitioned table */
       AND DIV_NO=1                 /* partitioning condition specification order */

When this SQL statement is executed, RDA1 is returned as the name of the RDAREA to be deleted.

(2) Use the pdhold command to shut down the RDAREA to be unloaded

pdhold -r RDA1

(3) Use the pdrorg command to unload data from RDA1 for the ORDER table

pdrorg -k unld -t ORDER -r RDA1 /pdrorg/unld03

Explanation

-k: Specifies unld for unloading.

-t: Specifies the name of the table to be unloaded.

-r: Specifies the name of the target RDAREA in order to unload only the specified RDAREA.

/pdrorg/unld03: Specifies the name of the control information file for the pdrorg command. The following shows the contents of the control information file:

unload bes1:/pdrorg/unload_file

/* bes1: Name of server that contains unload data file  */
/* /pdrorg/unload_file: Name of unload data file */

(4) Use the pdload command to perform data loading on RDA1 with a data count of 0

To delete the data for May 2005 (the data in RDA1), which is the oldest data, execute data loading with a data count of 0. If a non-partitioning key index has been defined for the partitioned table, you must create the non-partitioning key index in the batch mode after executing pdload.

pdload -d ORDER /pdload/load03

Explanation

-d: Specifies that the existing data is to be deleted and then data loading is to be performed.

ORDER: Specifies the name of the data on which data loading is to be performed.

/pdload/load03: Specifies the name of the control information file for the pdload command. The following shows the contents of the control information file:

source RDA1 /pdload/load_file

/* RDA1: Name of RDAREA on which data loading is to be performed        */
/* /pdload/load_file: Name of input data file */

(5) Use the pdrels command to release the RDAREA from shutdown status

pdrels -r RDA1

After executing the command, you should check the execution results for errors. For details about how to check the command's execution results, see the manual HiRDB Version 8 Command Reference.

After the command has executed, you can store data in RDA1 by using a program such as a UAP to insert the data for October 2005.

13.16 Migrating data to another table

Executor: HiRDB administrator, DBA privilege holder, and table owner

Data can be moved to another table by executing the pdrorg or pdload command. The migration method depends on whether or not the migration source table and the migration target table have identical definitions. The table definitions are considered to be identical when all the following are true:

Both are either FIX or non-FIX tables.

They have the same number of columns.

Their column definitions are the same (same column names, data types, NULL or NOT NULL, data sizes, sequence of column definitions, repetitions counts).

Figure 13-83 shows how to migrate data to a table with the same table definition as the source table. Figure 13-84 shows how to migrate data to a table with a different table definition.

Figure 13-83 Migrating data to a table with the same table definition

Figure 13-84 Migrating data to a table with a different table definition

Important

After data migration, execute the optimizing information collection utility (pdgetcst command) for the migration destination table if necessary. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

If you wish to migrate to another HiRDB system a table that has columns of the abstract data type, you must apply the constructor parameter reverse generation function when you use the database reorganization utility (pdrorg command) to unload data of the abstract data type.

Organization of this section

13.16.1 Example 1: Migrating data to a table with the same table definition

13.16.2 Example 2: Migrating data to a table with a different table definition

13.16.3 Specification examples of column structure information files

13.16.1 Example 1: Migrating data to a table with the same table definition

TABLE1 and TABLE2 have the same table definition. This example moves (copies) the data from TABLE1 to TABLE2.

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be unloaded and RDAREAs to be reloaded

(2) Use the pdrorg command to unload data from TABLE01

(3) Use the pdrorg command to load data into TABLE02

(4) Back up the RDAREAs in which data was reloaded

(5) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be unloaded and RDAREAs to be reloaded

pdhold -r RDAREA01,RDAREA02,...

(2) Use the pdrorg command to unload data from TABLE01

pdrorg -k unld -j -t TABLE01 -g /pdrorg/unld01

Explanation

-k: Specifies unld for unloading.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be unloaded.

-t: Specifies the name of the table that is to be unloaded.

-g: Specifies that TABLE01 is row-partitioned between servers in a HiRDB/Parallel Server. Specifying the -g option consolidates the unload data files (into a single file).

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command.

(3) Use the pdrorg command to load data into TABLE02

pdrorg -k reld -j -t TABLE02 -g /pdrorg/reld01

Explanation

-k: Specifies reld for reloading.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be reloaded.

-t: Specifies the name of the table that is to be reloaded.

-g: If the -g option was specified in step (2), specify it here as well.

/pdrorg/reld01: Specifies the name of the control statements file for the pdrorg command. Because the data will be reloaded into another table, specify a tblname statement. The following is an example of specifying a tblname statement:

tblname TABLE01

(4) Back up the RDAREAs in which data was reloaded

Because you reloaded data in the pre-update acquisition mode (default), back up the RDAREAs in which data was reloaded. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(5) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.16.2 Example 2: Migrating data to a table with a different table definition

This example moves (copies) the data from TABLE1 to TABLE2. The table definitions of TABLE1 and TABLE2 differ as follows:

Organization of this subsection

(1) Use the pdhold command to shut down RDAREAs to be unloaded and RDAREAs to be reloaded

(2) Create the control statements file for the pdrorg command

(3) Use the pdrorg command to unload data from TABLE01

(4) Create the column structure information file (/pdload/column01)

(5) Create the control statements file for the pdload command

(6) Use the pdload command to load data into TABLE02

(7) Back up the RDAREAs in which data was loaded

(8) Use the pdrels command to release RDAREAs from shutdown status

(1) Use the pdhold command to shut down RDAREAs to be unloaded and RDAREAs to be reloaded

pdhold -r RDAREA01,RDAREA02,...

(2) Create the control statements file for the pdrorg command

The contents of the control statements file (/pdrorg/rorg01) are shown below.

(a) HiRDB/Single Server

unload /pdrorg/unfile1                                1
unld_func type=sgmltext,func=unsgmltext(sgmltext)     2

Explanation

Specifies the name of the unload data file.

Specifies information on the constructor parameter reverse generation function, because the SGMLTEXT type is defined for the table.

(b) HiRDB/Parallel Server

unload bes1:/pdrorg/unfile1                          1
unld_func type=sgmltext,func=unsgmltext(sgmltext)    2

Explanation

Specifies the name of the unload data file.

Specifies information on the constructor parameter reverse generation function, because the SGMLTEXT type is defined for the table.

(3) Use the pdrorg command to unload data from TABLE01

pdrorg -k unld -W bin -j -t TABLE01 -g /pdrorg/rorg01

Explanation

-k: Specifies unld for unloading.

-W bin: Specifies use of the unload data file as the input file (binary format) for the pdload command.

-j: Specifies that a LOB column or a column with the LOB attribute is defined in the table that is to be unloaded.

-t: Specifies the name of the table that is to be unloaded.

-g: Specifies that TABLE01 is row-partitioned between servers in a HiRDB/Parallel Server. Specifying the -g option consolidates the unload data files (into a single file).

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command.

(4) Create the column structure information file (/pdload/column01)

*skipdata*,type=integer
C5
C6,func=(sgmltext,param=blob)
C7

Because the column structure of the input data file created in step (3) differs from the column structure of TABLE02, a column structure information file is needed for data loading. For an example of specifying a column structure information file, see 13.16.3 Specification examples of column structure information files.

(5) Create the control statements file for the pdload command

The contents of the control statements file (/pdload/load01) are shown below.

(a) HiRDB/Single Server

source /pdrorg/unfile1

Explanation

Specifies the name of the unload data file created in step (3).

(b) HiRDB/Parallel Server

source bes1:/pdrorg/unfile1

Explanation

Specifies the name of the unload data file created in step (3).

(6) Use the pdload command to load data into TABLE02

pdload -k d -b -W -c /pdload/column01 TABLE02 /pdload/load01

Explanation

-k d: Specifies that the input data contains BLOB data.

-b: Specifies that data in binary format is to be loaded.

-W: Specifies that an input data file in binary format, created with the pdrorg command, is to be used.

-c /pdload/column01: Specifies the name of the column structure information file created in step (4).

TABLE02: Specifies the name of the table into which the data is to be loaded.

/pdload/load01: Specifies the name of the control statements file for the pdload command.

(7) Back up the RDAREAs in which data was loaded

Because you loaded data in the pre-update acquisition mode (default), back up the RDAREAs in which data was loaded. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(8) Use the pdrels command to release RDAREAs from shutdown status

pdrels -r RDAREA01,RDAREA02,...

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

13.16.3 Specification examples of column structure information files

This section provides specification examples of column structure information files.

Organization of this subsection

(1) Example 1: When a column is deleted

(2) Example 2: When a column is added

(3) Example 3: When the column sequence has been changed

(1) Example 1: When a column is deleted

Specification example of a column structure information file

C4
*skipdata*,type=char(4)
C5

Explanation

The skipdata statement is specified because the migration destination table does not have the CHAR-type column.

(2) Example 2: When a column is added

Specification example of a column structure information file

C3
C5

Explanation

Column C4 has been added to the migration destination table. The added column C4 is not described in the column structure information file.

When a column has been added, it is important that it not be specified in the column structure information file. That way, HiRDB detects that the input data does not contain data for that column, and it stores the default or NULL value in the added column. In the case of a table with the FIX attribute, the NULL value cannot be stored, so HiRDB stores the default value if the WITH DEFAULT operand was specified in the ALTER TABLE statement when the column was added.

(3) Example 3: When the column sequence has been changed

Specification example of a column structure information file

C5
C4
C6

Explanation

Because columns C4 and C5 have been reversed, C5 is specified before C4.

13.17 Deleting a table

Executor: Table owner or DBA privilege holder

DROP TABLE is used to delete an unneeded table. Because the data stored in the table is deleted, free space is created in the user RDAREAs, enabling the user RDAREAs to be used more efficiently.

Notes

When a table is deleted, the following resources are also deleted:
Indexes for the table
View tables created from the table
Access privileges to the table
Triggers defined for the table

Deleting a table invalidates any stored routines that use that table.

Deleting a table specified in a trigger SQL statement invalidates the trigger.

Falsification prevented tables containing data cannot be deleted.

13.18 Deleting a schema

Executor: Schema owner or DBA privilege holder

DROP SCHEMA is used to delete a schema.

Organization of this section

(1) Resources that are deleted when a schema is deleted

(2) Other users' resources that are affected

(3) When a schema cannot be deleted

(1) Resources that are deleted when a schema is deleted

When a schema is deleted, the schema owner's resources are also deleted. This means that the following resources are deleted:

Tables

Indexes

View tables

Comments

Access privileges

Abstract data types

Index type

Stored procedures

Stored functions

Trigger

Foreign table

Foreign index

(2) Other users' resources that are affected

View tables are deleted

Because the schema owner's tables and view tables are deleted, all view tables created from any of those tables or view tables are also deleted.

Access privileges are revoked

Because the schema owner's tables and view tables are deleted, all access privileges for those tables and view tables are revoked.

Stored routines and triggers become invalid

Because the schema owner's tables, view tables, indexes, abstract data types, stored routines, and triggers are deleted, stored routines and triggers that use any of these resources become invalid.

(3) When a schema cannot be deleted

Your schema cannot be deleted if a user is accessing an abstract data type that is defined in a table you own.

The schema of a user who owns a falsification prevented table that contains data cannot be deleted.

13.19 Deleting an abstract data type

Executor: Table owner or DBA privilege holder

DROP DATA TYPE is used to delete an abstract data type.

Note

An abstract data type cannot be deleted while it is being used by any resource (table, index, or another abstract data type).

Organization of this section

(1) When an abstract data type cannot be deleted

(2) Subtypes cannot be deleted

(1) When an abstract data type cannot be deleted

If a data type or its parent data type to be deleted satisfies any of the conditions listed below, WITH PROGRAM must be specified in DROP DATA TYPE; otherwise, the deletion processing will fail:

The data type is specified in an SQL parameter in a procedure or function.

The data type is specified for a function's return value.

The data type is specified in an argument or return value of a function that is called from a procedure or another function.

The data type is specified in a procedure, function, or trigger (if an abstract data type is being accessed by a component specification, this includes all data types used to build the abstract data type).

Deleting an abstract data type invalidates any stored routine or trigger that satisfies the above conditions. If this happens, use the ALTER PROCEDURE, ALTER ROUTINE, or ALTER TRIGGER statement to re-create the stored routines and stored triggers.

(2) Subtypes cannot be deleted

A data type cannot be deleted if its parent data type is used in a table definition.

A data type also cannot be deleted if the data type itself or its parent data type is used in another abstract data type.

13.20 Creating a definition SQL from an existing table

Executor: HiRDB administrator or DBA privilege holder

The pddefrev command can be used to create a definition SQL from an existing table.

This command is useful for creating a table that uses an existing table's definition. A definition SQL created with the pddefrev command is used as input information to the database definition utility (pddef command).

Reference note

A table for which an abstract data type is defined cannot be processed by the pddefrev command (a definition SQL cannot be created from it).

13.21 Managing a list (narrowed search)

Executor: HiRDB administrator and table owner (or user with DBA privilege)

This section explains how to manage a list to be used for narrowed search. The following points should be noted when a list is used.

Organization of this section

(1) All lists are deleted when HiRDB terminates

(2) When the base table of a list is recovered with the database recovery utility

(3) When an RDAREA storing the base table of a list is re-initialized

(4) Operations that invalidate a list

(5) Some commands cannot be used for a list or list RDAREA.

(6) Notes on termination of the dictionary server

(7) Command for checking list information (pdlistls command)

(8) Notes on using the inner replica facility

(9) Changes when initializing (deleted) lists

(1) All lists are deleted when HiRDB terminates

When HiRDB terminates (including abnormal termination), all lists are deleted, rendering a search using one of the lists impossible. If a list is needed, it must be re-created with the ASSIGN LIST statement.

HiRDB/Parallel Server

When a unit terminates, all lists in that unit are deleted.

When a server terminates, all lists in that server are deleted.

(2) When the base table of a list is recovered with the database recovery utility

When the base table of a list is recovered to the most recent synchronization point, that list can be used as is. However, if the base table is not recovered to the most recent synchronization point (e.g., it is recovered to the status when a backup was made), the base table may no longer match the list, and the list must be re-created with the ASSIGN LIST statement.

(3) When an RDAREA storing the base table of a list is re-initialized

When an RDAREA storing the base table of a list is re-initialized, you must do one of the following:

Re-create the list with the ASSIGN LIST statement.

Delete the list with the DROP LIST statement.

(4) Operations that invalidate a list

When any of the following processing is performed on the base table of a list, the retrieval results for the list become invalid, and the list must be re-created with the ASSIGN LIST statement:

Table reorganization

Data loading into the table in the creation mode

Execution of the PURGE TABLE statement

(5) Some commands cannot be used for a list or list RDAREA.

The following commands cannot be used for a list or list RDAREA:

Database load utility

Database reorganization utility

Database copy utility

Database recovery utility

Database condition analysis utility (only physical analysis of an RDAREA is possible)

(6) Notes on termination of the dictionary server

To reduce overhead during list creation and deletion, HiRDB maintains list management information in the memory of a dictionary server. Consequently, list management information is lost when the dictionary server or the unit in which the dictionary server is located is terminated. When this occurs, all lists that have been created become invalid and must be re-created with the ASSIGN LIST statement.

Once the dictionary server is restarted and until the transactions that use lists of other users that were being executed before the dictionary server was terminated have been completely recovered, processes that use the lists may cause the KFPA11998-E error message, list operation not completed, to be output.

(7) Command for checking list information (pdlistls command)

List information can be checked by executing the pdlistls command. The following information is displayed:

List name

List owner

Name of the list's base table

Owner of the list's base table

pd_max_list_users value (maximum number of list owners)

pd_max_list_count value (maximum number of lists that can be created by one user)

(8) Notes on using the inner replica facility

Exercise caution if the RDAREA being accessed is to be changed when a replica RDAREA has been defined for an RDAREA that contains a base table of a list. If the RDAREA being accessed is changed with the current database switch command (pddbch command) or with the PDDBACCS operand in the client environment definitions, the search results are invalid except in the following cases:

The RDAREA being accessed when the list is searched matches the RDAREA that was accessed when the list was created.

The RDAREA being accessed when the list is searched is duplicated from the data in the RDAREA that was accessed when the list was created.

Use one of the following methods to search such a list:

Use the RDAREA that was accessed when the list was created.

Use an RDAREA that is duplicated from the data in the RDAREA that was accessed when the list was created.

Re-create the list in the current RDAREA being accessed.

For details about the inner replica facility, see the manual HiRDB Staticizer Option Version 7 Description and User's Guide.

(9) Changes when initializing (deleted) lists

As explained in (1) above, lists are deleted when HiRDB terminates. Deletion (and initialization) processing on these lists is performed during HiRDB startup, which means that the more lists that are created, the longer it takes for HiRDB to start. For this reason, we recommend that you consider changing the time at which lists are initialized in the following cases:

When you wish to minimize HiRDB startup time

When you wish to minimize system switchover time (using user server hot standby or the rapid system switchover facility)

The list initialization time can be changed as follows with the pd_list_initialize_timing operand:

Initialize lists when the ASSIGN LIST statement is executed (DEFER specification).

Initialize lists when the standby HiRDB is started (STANDBY specification).

(a) Initializing lists when the ASSIGN LIST statement is executed

With this specification, lists are initialized when the ASSIGN LIST statement is executed, rather than when HiRDB starts. This, of course, adds to the initialization overhead when an ASSIGN LIST statement is executed. To minimize the initialization processing overhead, set the list RDAREA size and maximum number of lists so that they are as small as possible. To accommodate creation of a large number of lists, create additional list RDAREAs. This enables you to distribute the initialization processing overhead when the ASSIGN LIST statement is executed.

(b) Initializing lists when the standby HiRDB is started (rapid system switchover facility only)

With this specification, lists are initialized when the standby HiRDB starts. Lists are not initialized when the system is switched over. Lists are not initialized when the ASSIGN LIST statement is executed after the system has been switched over either. Because of this, increase the list RDAREA size and maximum number of lists to reduce the number of list RDAREAs that are created. However, you must first perform the preparatory work explained below.

Preparatory work

You will need lists on both the running system and the standby system. Create them on each of the local disks. You can use either one of the following methods:

Copy the lists created on the running HiRDB to the standby HiRDB

Copy all HiRDB file system areas that contain list RDAREAs on the running HiRDB onto the local disk on the standby system.

Link so that all HiRDB file names defined in the list RDAREAs point to the HiRDB files system areas that were created in step 1.

Use the re-initialization function of the database structure modification utility (pdmod command)

Use the pdstop command to terminate the HiRDB on the running system normally.

Use the pdfmkfs command to create HiRDB file system areas for creating list RDAREAs. Create the same number of list RDAREAs with the same settings as those on the running system.

Link so that all HiRDB file names defined in the list RDAREAs point to the HiRDB files system areas created in step 2.

Use the pdstart command to start the HiRDB on the standby system normally. Because the HiRDB file system areas on the standby HiRDB contain no HiRDB files at this time, the list RDAREAs are opened and placed in error shutdown status.

Use the pdmod command to re-initialize all list RDAREAs. When doing so, specify only the names of the RDAREAs that are being initialized.

Use the pdrels command to release all list RDAREAs from shutdown status.

Use the pdstop command to terminate the standby HiRDB normally.

13.22 Standardizing spaces in table data

Executor: HiRDB administrator and table owner (or user with DBA privilege)

This section explains how to standardize spaces when both double-byte and single-byte spaces are present in table data. The space conversion facility is used to standardize spaces.

Organization of this section

13.22.1 Overview of space conversion facility

13.22.2 Setting the space conversion level

13.22.3 Standardizing space characters in a table

13.22.4 Distributed database environment

13.22.1 Overview of space conversion facility

When data is compared, one double-byte space and two single-byte spaces are not recognized as the same data. Therefore, when blanks are represented in table data by both one double-byte space and two single-byte spaces, the retrieval results may be inaccurate.

Example

The following are not recognized as being the same data items:

The double-byte space character being discussed here is coded as shown below. Two single-byte space characters are coded as X'2020'.

Shift-JIS Kanji Code: X'8140'

EUC Japanese Kanji Code or EUC Chinese Kanji Code: X'A1A1'

Unicode (UTF-8):# X'E38080'

#: NCHAR and NVARCHAR cannot be used if the character codes are Unicode (UTF-8).

Organization of this subsection

(1) Space conversion levels

(2) Notes

(1) Space conversion levels

As shown in Table 13-32, three levels of space character conversion are provided by the space conversion facility.

Table 13-32 Space conversion levels

Level
Explanation

Level 0
No space conversion.

Level 1
Converts as follows data spaces that occur in literals, embedded variables, and ? parameters in the data manipulation SQL and data spaces stored by utilities:

When a character string literal is being handled as a national character string literal, two single-byte spaces in succession are converted into one double-byte space; a single occurrence of a single-byte space is not converted.

When a character string literal is being handled as a mixed character string literal, one double-byte space is converted into two single-byte spaces.

When data is being stored in a column of the national character type and when data is being compared with a value expression of the national character type, two single-byte spaces in succession in an embedded variable or ? parameter are converted into one double-byte space; a single occurrence of a single-byte space is not converted.

When data is being stored in a column of the mixed character type and when data is being compared with a value expression of the mixed character type, one double-byte space in an embedded variable or ? parameter is converted into two single-byte spaces.

Level 3
Adds the following processing to the processing of space conversion level 1:

During retrieval of data of a value expression of the national character type, a single double-byte space is converted into two single-byte spaces.

Figure 13-85 illustrates Level 1 processing; Figure 13-86 illustrates Level 3 processing.

Figure 13-85 Level 1 processing

Figure 13-86 Level 3 processing

(2) Notes

When the space conversion level is changed, a UAP's retrieval results may not be the same after the change as they were before the change. For this reason, it is not advisable to change the space conversion level if a change in UAP retrieval results is not acceptable.

If sorting is performed when Level 3 is specified, HiRDB will perform space conversion on the sort results, and the expected results may not be obtained in all cases.

If national character data is retrieved when Level 3 is specified, performance may be poorer than with Level 0 or 1. For example, performance is degraded when large-sized data is retrieved, such as data of the type NVARCHAR (2000). This is because of the overhead involved in converting double-byte spaces into single-byte spaces.

When data is being stored in a column of a cluster key, space conversion may cause a uniqueness error. In such a case, you must either store the data without performing space conversion or standardize the space characters in the existing data (For details on standardizing the space characters in existing data, see 13.22.3 Standardizing space characters in a table).

Spaces in a national character string are converted in units of two characters, beginning at the beginning of the string.

If you are using HiRDB External Data Access, the character codes must be compatible with the character codes on the DBMS of the foreign server. If they are not compatible, unexpected results may be returned.

The following must be noted when Level 1 or 3 is specified as the space conversion level:

When determining the storage target RDAREA using a UAP that uses a hash function for table partitioning on a hash partitioned table, specify a space conversion level in the argument of the hash function for table partitioning. If no space conversion level is specified, the result of the hash function for table partitioning may be corrupt.

When a UAP is used to apply key range partitioning to a table (and the partitioning key is national character data or mixed character data), convert the partitioning key values with the space conversion function. Otherwise, the key range partitioning results may be invalid.

For details on the hash function for table partitioning and the space conversion function, see the manual HiRDB Version 8 UAP Development Guide.

13.22.2 Setting the space conversion level

The desired space conversion level can be specified in any of the following operands:

pd_space_level operand in the system common definition

PDSPACELVL operand in the client environment definition

spacelvl operand in the option statement of the database load utility

spacelvl operand in the option statement of the database reorganization utility

13.22.3 Standardizing space characters in a table

The procedure for standardizing space characters is explained below.

Procedure

To standardize space characters:

Standardize the codes used to represent space characters in the existing data, as explained in (1) below.

Specify pd_space_level=1 in the system common definition.
This specification standardizes the space characters in the data to be stored from now on (by means of data loading or INSERT).

Retrieve data by specifying PDSPACELVL=3 in the client environment definition as needed.

Organization of this subsection

(1) Standardizing space characters in existing data

(2) Standardizing space characters in new data

(3) Migrating table data to another system

(4) Using data unloaded with the -W option specified in a UAP

(1) Standardizing space characters in existing data

Figure 13-87 illustrates the procedure for standardizing the space characters in existing data.

Figure 13-87 Procedure for standardizing space characters in existing data

Explanation

To standardize the space characters in existing data, use the database reorganization utility (pdrorg command) to reorganize the table. Specify spacelvl=1 in the option statement of the pdrorg command.

For details on reorganizing a table, see 13.2 Reorganizing a table and 13.3 Reorganizing a table (examples).

(2) Standardizing space characters in new data

Figure 13-88 illustrates the procedure for standardizing the space characters in new data.

Figure 13-88 Procedure for standardizing space characters in new data

Explanation

To standardize the space characters in new data, specify spacelvl=1 in the option statement when the data is loaded with the database load utility (pdload command). If the spacelvl operand in the option statement is omitted, the value specified in the pd_space_level operand in the system common definition will be assumed.

For details on loading data, see the manual HiRDB Version 8 Command Reference.

(3) Migrating table data to another system

Figure 13-89 illustrates the procedure for standardizing the space characters when table data is migrated to another system.

Figure 13-89 Procedure for standardizing space characters when table data is migrated to another system

Explanation

In the case of table data that is migrated to another system, specify spacelvl=1 in the option statement of the database reorganization utility (pdrorg command) when the data is loaded at the migration destination system.

For details on migrating table data to another system, see 12.1 Migrating a table to another HiRDB system.

(4) Using data unloaded with the -W option specified in a UAP

Figure 13-90 illustrates the procedure for converting space characters when data unloaded with the -W option specified is used by a UAP (i.e., when this UAP performs comparison processing). In this case, the space characters in the table must already be standardized.

Figure 13-90 Using data unloaded with the -W option specified in a UAP

Explanation

When the data is unloaded, specify spacelvl=3 in the option statement of the database reorganization utility (pdrorg command). Each double-byte space in the national character data is converted into two single-byte spaces.

The comparison processing of national character data by the UAP is carried out in units of single-byte spaces.

13.22.4 Distributed database environment

Organization of this subsection

(1) Data substitution or comparison

(2) Data retrieval

(1) Data substitution or comparison

During data substitution or comparison, the space conversion level of the distributed server is applied; the space conversion level of the distributed client is ignored.

If the distributed server is XDM/RD or XDM/RD E2, the specification in the KEIS CODE SPACE LEVEL operand of the RD environment definition is applied.

(2) Data retrieval

(a) When space conversion level of distributed client is 0 or 1

When data is retrieved with pd_space_level=0 or 1 (or PDSPACELVL=0 or 1) specified in the distributed client, the space conversion level of the distributed server is applied; the space conversion level of the distributed client is ignored.

For example, when Level 3 is specified in the distributed server, each double-byte space in national character data is converted into two single-byte spaces.

If the distributed server is XDM/RD or XDM/RD E2, the specification in the KEIS CODE SPACE LEVEL operand of the RD environment definition is applied.

(b) When space conversion level of distributed client is 3

When data is retrieved with pd_space_level=3 (or PDSPACELVL=3) specified in the distributed client, the space conversion level of the distributed server is not applied. In this case, HiRDB at the distributed client converts each double-byte space in the retrieval results into two single-byte spaces. One double-byte space is also converted into two single-byte spaces when the data type of the column to be accessed is national character data, mixed character data, or character data. Consequently, the spaces in the retrieval results data returned to the UAP are always single-byte spaces.

13.23 Converting the sign portion of the decimal type

Executor: HiRDB administrator and table owner (or user with DBA privilege)

The three data formats decimal, day interval, and time interval are signed, packed formats consisting of an integer portion and a sign portion. Normally, HiRDB stores as is in a database the sign that is input from a UAP or utility,# using X'C' (positive), X'D' (negative), or X'F' (positive) as valid values for the sign portion of signed packed data. HiRDB also treats +0 (sign portion X'C' or X'F') and -0 (sign portion X'D') as different values.

The facility for conversion to a decimal signed normalized number is used to convert the sign portion of decimal, day interval, and time interval signed packed format data. This section explains how to use the facility for conversion to a decimal signed normalized number to convert the sign portion of signed packed format data.

#: Format conversion during SQL execution or computation may also result in sign conversion. The sign may also be converted when a multicolumn index is used.

Organization of this section

13.23.1 Overview of the facility for conversion to a decimal signed normalized number

13.23.2 Normalizing existing data

13.23.1 Overview of the facility for conversion to a decimal signed normalized number

Organization of this subsection

(1) Specification of the sign portion of the signed packed format

(2) Rules for converting the sign portion of signed packed format data

(3) Application criteria

(4) Environment setting

(5) Notes

(1) Specification of the sign portion of the signed packed format

Table 13-33 shows the specification of the sign portion of signed packed format data in HiRDB.

Table 13-33 Specification of the sign portion of the signed packed format data

Sign portion | Meaning
X'C' | Indicates a positive value.
X'D' | Indicates a negative value.
X'F' | Indicates a positive value.

(2) Rules for converting the sign portion of signed packed format data

When the facility for conversion to a decimal signed normalized number is used, the sign portion of signed packed format data is converted at the time of data input according to the rules described in Tables 13-34 and 13-35. This conversion of the sign portion is called normalization of the sign portion. Once the sign portion is normalized, +0 and -0 can be handled as the same value.

Table 13-34 Rules for converting the sign portion of the signed packed format data (for non-0 data)

Sign portion of embedded variable data | Without normalization | With normalization
X'A' | Error | Converted to X'C'
X'B' | Error | Converted to X'D'
X'C' | No conversion | No conversion
X'D' | No conversion | No conversion
X'E' | Error | Converted to X'C'
X'F' | No conversion | Converted to X'C'
X'0' to X'9' | Error | Error

Table 13-35 Rules for converting the sign portion of the signed packed format data (for 0 data)

Sign portion of 0 data | Without normalization | With normalization
X'A' | Error | Converted to X'C'
X'B' | Error
X'C' | No conversion
X'D' | No conversion
X'E' | Error
X'F' | No conversion

(3) Application criteria

To use in HiRDB a UAP that specifies the sign portion in a different way, it may be desirable to use the facility for conversion to a decimal signed normalized number. This facility should be used only after checking carefully the sign conversion rules.

For example, when an XDM/RD or XDM/RD E2 UAP is moved to HiRDB, it may be appropriate to use the facility for conversion to a decimal signed normalized number, because XDM/RD and HiRDB specify the decimal signed portion differently.

(4) Environment setting

To use the facility for conversion to a decimal signed normalized number, specify Y in the pd_dec_sign_normalize operand in the system common definition.

If possible, this operand should be specified when HiRDB is first installed. To normalize the signed portion while HiRDB is already being used, it is necessary to reload the data of tables for which the decimal type is defined.

(5) Notes

When an SQL statement is executed while there is both normalized data and data that has not been normalized, corruption of the database or of the execution results may result. Thus, if you change the specification value of the pd_dec_sign_normalize operand, data must be reloaded and the normalization status must be standardized by executing the database reorganization utility (pdrorg command) and database load utility (pdload command); for details, see 13.23.2 Normalizing existing data.

The following points must be noted when the facility for conversion to a decimal signed normalized number is used:

When you determine a storage destination RDAREA while using a UAP that uses a hash function for table partitioning on a hash partitioned table, specify use of the facility for conversion to a decimal signed normalized number in the arguments of the hash function for table partitioning. Otherwise, the results of the hash function for table partitioning may be invalid.

When a UAP is used to apply key range partitioning to a table with key range partitioning (the partitioning key is decimal data), you should use the facility for conversion to a decimal signed normalized number to convert the partitioning key values. If the partitioning key values are not converted, the key range partitioning results may be invalid.

For details on the hash function for table partitioning and of the facility for conversion to a decimal signed normalized number, see the manual HiRDB Version 8 UAP Development Guide.

13.23.2 Normalizing existing data

A table (TABLE01) contains a decimal-type column. This decimal sign portion is normalized.

Organization of this subsection

(1) Specify pd_dec_sign_normalize=Y

(2) Use the pdrorg command to unload data from TABLE01

(3) Use the pdload command to load data into TABLE01

(1) Specify pd_dec_sign_normalize=Y

Use the pdstop command to terminate HiRDB normally. Once stopped, specify Y in the pd_dec_sign_normalize operand, and then use the pdstart command to start HiRDB normally.

The system reconfiguration command (pdchgconf command) can be used to change HiRDB system definitions while HiRDB is running. Note that HiRDB Advanced High Availability must be installed in order to use this command. For details about changing HiRDB system definitions while HiRDB is running, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

(2) Use the pdrorg command to unload data from TABLE01

pdrorg -k unld -W bin -j -t TABLE01 -g /pdrorg/unld01

Explanation

-k: Specifies unld for unloading.

-W bin: Specifies that the unload data file is to be used as the input file (binary format) for the pdload command.

-j: Specifies that a LOB column is defined in the table that is to be unloaded.

-t: Specifies the name of the table that is to be unloaded.

-g: Specifies that TABLE01 is row-partitioned between servers in a HiRDB/Parallel Server. Specifying the -g option consolidates the unload data files (into a single file).

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command.

(3) Use the pdload command to load data into TABLE01

pdload -d -b -W TABLE01 /pdload/load01

Explanation

-d: Specifies the creation mode.

-b: Specifies that the data to be loaded is in binary format.

-W: Specifies that a binary-format input data file, created with the pdrorg command, is to be used.

TABLE01: Specifies the name of the table into which the data is to be loaded.

/pdload/load01: Specifies the name of the control statements file for the pdload command.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

Supplemental

A binary input file (-W bin) is used in the procedure described above. However, if a DAT input file (-W dat) is used, the sign is first converted into characters during unloading. Then, the conversion performed during data loading normalizes the signed portion automatically. Therefore, the signed portion is normalized regardless of the value specified in the pd_dec_sign_normalize operand.

14. Handling Indexes

This chapter explains the procedures for handling indexes.

It contains the following sections:

Organization of this chapter

14.1 Improving index storage efficiency (index reorganization)

14.2 Defining an index for a table that contains data

14.3 Deleting an index

14.4 Creating a definition SQL from an existing index

14.5 Reducing the number of index page splits (unbalanced index split)

14.6 Error handling during batch index creation

14.7 Delayed batch creation of a plug-in index

14.1 Improving index storage efficiency (index reorganization)

This section explains how to improve index storage efficiency (index reorganization).

Organization of this section

14.1.1 Overview of index reorganization

14.1.2 Example 1: Reorganizing an index

14.1.3 Actions when an error occurs during index reorganization

14.1.4 Example 2: When an RDAREA shortage occurs during index reorganization (execution in a mode other than no-log mode)

14.1.5 Example 3: When an RDAREA shortage occurs during index reorganization (execution in no-log mode)

14.1.1 Overview of index reorganization

When data is deleted (DELETE) or updated (UPDATE) repeatedly, index storage efficiency deteriorates, reducing the efficiency of index-based retrievals. Any of the following measures can be taken with the database reorganization utility to prevent this:

Index reorganization

Index re-creation

Table reorganization

This section explains index reorganization, which is the best measure in terms of performance. Figure 14-1 provides an overview of index reorganization processing.

Figure 14-1 Overview of index reorganization processing

Explanation

An index information file is created by retrieving index key information, and the index is rearranged based on this information. This is called index reorganization. Index reorganization can be executed by index or by index RDAREA.

Organization of this subsection

(1) Application range

(2) Application criteria

(3) When to use index reorganization and when to use table reorganization

(4) Difference from index re-creation

(5) Notes on index reorganization

(6) Reducing the reorganization execution time

(7) Reorganizing an index in an RDAREA that has insufficient free space

(1) Application range

Reorganization of a plug-in index cannot be executed.

(2) Application criteria

Index reorganization is used for freeing the unusable areas in index storage pages that have resulted from addition, deletion, or updating of a large volume of data.

(3) When to use index reorganization and when to use table reorganization

Use index reorganization when there has been frequent data updating (UPDATE).

Use table reorganization when there has been frequent data deletion (DELETE) or addition (INSERT).

When reorganizing a table would take too much time, reorganizing its indexes only can reduce retrieval time.

(4) Difference from index re-creation

In index re-creation, the table's data is retrieved. In contrast, the table's data is not retrieved in index reorganization. For this reason, index reorganization requires less processing time than re-creation,* sorting is not required, and processing performance is improved.

* Processing time is reduced when the following condition is satisfied:

number-of-used-pages-in-RDAREAs-storing-table > number-of-used-pages-in-RDAREAs-storing-index

(5) Notes on index reorganization

When multiple indexes in the same RDAREA are reorganized simultaneously, the pdhold command must be used to shut down the RDAREA before executing the reorganization. Then, after index reorganization is completed, the pdrels command must be used to release the RDAREA's shutdown status.

(6) Reducing the reorganization execution time

If no database update log is being collected during index reorganization (no-log mode or pre-update log acquisition mode is in effect), there is a commensurate reduction in processing time. Collection of a database update log is specified with the -l option of the pdrorg command. The default is the pre-update log acquisition mode.

(7) Reorganizing an index in an RDAREA that has insufficient free space

When an index is reorganized, a percentage of unused area per page can be specified in the PCTFREE operand of CREATE TABLE or CREATE INDEX. However, if the index being reorganized is in an RDAREA that has insufficient free space to accommodate the specified percentage of unused area, the RDAREA can run out of space during index reorganization processing. To prevent this, you should specify the idxfree operand in the option statement of the database reorganization utility (pdrorg), and use the PCTFREE operand of CREATE TABLE or CREATE INDEX to change the percentage of unused area per page.

Note that this is a temporary measure that is used when the RDAREA cannot be immediately expanded before index reorganization. In preparation for data updating, you should use the database structure modification utility (pdmod command) to expand the RDAREA so that reorganization can be performed that is within the value specified in the PCTFREE operand of CREATE TABLE.

14.1.2 Example 1: Reorganizing an index

In this example, an index (INDEX01) defined for a table (TABLE01) is reorganized. The following conditions apply at the time of reorganization:

The RDAREA storing the index is RDAREA1

RDAREA1 contains INDEX01 only

Reorganization is performed in the pre-update log acquisition mode

Organization of this subsection

(1) Use the pdhold command to shut down the RDAREA to be reorganized

(2) Use the pdrorg to reorganize the index

(3) Back up the RDAREA that was reorganized

(4) Use the pdrels command to release the RDAREA from shutdown status

(1) Use the pdhold command to shut down the RDAREA to be reorganized

pdhold -r RDAREA1

(2) Use the pdrorg to reorganize the index

pdrorg -k ixor -t TABLE01 /pdrorg/rorg01

Explanation

-k: Specifies ixor, which is used to reorganize the index.

-t: Specifies the name of the table for which the index is defined.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command. The following shows an example of a control statements file specification:

idxname name=INDEX01
idxwork bes1 /pdrorg

INDEX01: Index identifier

bes1: Name of the server on which the index information file is created (specified when a HiRDB/Parallel Server is being used)

/pdrorg: Name of the directory in which the index information file is created

(3) Back up the RDAREA that was reorganized

Because you reorganized the index in the pre-update acquisition mode (default), back up the RDAREA containing the index that was reorganized (RDAREA1). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(4) Use the pdrels command to release the RDAREA from shutdown status

pdrels -r RDAREA1

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

14.1.3 Actions when an error occurs during index reorganization

This section explains the actions that can be taken when an error occurs during index reorganization and the pdrorg command terminates abnormally. The operational procedure after the pdrorg command has terminated abnormally is explained below:

Procedure

To perform corrective actions:

Check if the KFPL00715-I message has been output to the message log file or the syslogfile. This message indicates that index loading has started; if it has been output, an index information file has been created.

If the KFPL00715-I message has not been output, execute the pdrorg command (index reorganization) again. However, in the case of abnormal termination due to entry of the pdcancel command, etc., the index key information may have been lost, rendering re-execution of index reorganization impossible. In such a case, execute index re-creation (-k ixrc specification).

If the KFPL00715-I message has been output, perform the following operation using the created index information file as the input file:

When index reorganization is being executed in a mode other than the no-log mode:
Use the pdrorg command to create the index in the batch mode(-k ixmk specification).

When index reorganization is being executed in the no-log mode:
The RDAREAs that store the index are in error shutdown status, so their error shutdown status must be released by using the pdmod command to reinitialize the RDAREAs. Then use the pdrorg command to re-create the index (-k ixrc specification).

Notes

One of the common errors that may occur during index reorganization is a space shortage in an RDAREA storing the index. The actions to be taken in such a case are explained in 14.1.4 Example 2: When an RDAREA shortage occurs during index reorganization (execution in a mode other than no-log mode) and 14.1.5 Example 3: When an RDAREA shortage occurs during index reorganization (execution in no-log mode).

However, if a value other than 0 was specified in the PCTFREE operand during index definition, specifying the idxfree operand in the option statement of the pdrorg command may be sufficient without having to expand the index-storage RDAREA.

14.1.4 Example 2: When an RDAREA shortage occurs during index reorganization (execution in a mode other than no-log mode)

A space shortage in an index-storage RDAREA during index reorganization has caused the pdrorg command to terminate abnormally.

Organization of this subsection

(1) Increase the size of the RDAREA storing the index

(2) Use the pdhold command to shut down the RDAREA storing the index

(3) Use the pdrorg command to create the index in the batch mode

(4) Back up the RDAREA storing the index

(5) Use the pdrels command to release the RDAREA from shutdown status

(1) Increase the size of the RDAREA storing the index

For details about increasing the size of RDAREAs, see 15.3 Increasing the size of an RDAREA (RDAREA expansion).

(2) Use the pdhold command to shut down the RDAREA storing the index

pdhold -r RDAREA1

(3) Use the pdrorg command to create the index in the batch mode

Using as input information the index information file that was output during index reorganization, perform batch index creation (-k ixmk specification).

pdrorg -k ixmk -t TABLE01 /pdrorg/rorg01

Explanation

-k: Specifies ixmk, which is used to perform batch creation of the index.

-t: Specifies the name of the table for which the index is defined.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command. The following shows an example of a control statements file specification:

index INDEX01 RDAREA1 /pdrorg/index_inf01

INDEX01: Index identifier

RDAREA1: Name of the RDAREA storing the index

/pdrorg/index_inf01: Name of the index information file

(4) Back up the RDAREA storing the index

Because you created the index in the batch mode in the pre-update acquisition mode (default), back up the RDAREA storing the index (RDAREA1). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(5) Use the pdrels command to release the RDAREA from shutdown status

pdrels -r RDAREA1

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

14.1.5 Example 3: When an RDAREA shortage occurs during index reorganization (execution in no-log mode)

A space shortage in an index-storage RDAREA during index reorganization has caused the pdrorg command to terminate abnormally.

Organization of this subsection

(1) Re-initialize the RDAREA storing the index

(2) Use the pdhold command to release the RDAREAs storing the index and the table

(3) Use the pdrorg command to re-create the index

(4) Back up the RDAREAs storing the index and the table

(5) Use the pdrels command to release the RDAREAs storing the index and the table from shutdown status

(1) Re-initialize the RDAREA storing the index

Because the RDAREA storing the index is in error shutdown status, use the pdmod command to re-initialize the RDAREA storing the index and release it from error shutdown status. While doing so, increase the size of the RDAREA storing the index. For details about re-initializing RDAREAs, see 15.4 Increasing the size of an RDAREA or modifying its attributes (RDAREA reinitialization).

(2) Use the pdhold command to release the RDAREAs storing the index and the table

pdhold -r RDAREA1,RDAREA2

(3) Use the pdrorg command to re-create the index

All indexes stored in the re-initialized RDAREA must be re-created.

pdrorg -k ixrc -t TABLE01 /pdrorg/rorg01

Explanation

-k: Specifies ixrc, which is used to re-create the index.

-t: Specifies the name of the table for which the index is defined.

/pdrorg/rorg01: Specifies the name of the control statements file for the pdrorg command. The following shows an example of a control statements file specification:

idxname name=INDEX01
idxwork bes1 /pdrorg
sort bes1 /tmp/sortwork/,8192

INDEX01: Index identifier

bes1: Name of the server on which the index information file is created (specified when a HiRDB/Parallel Server is being used)

/pdrorg: Name of the directory in which the index information file is created

bes1: Name of the server on which the work file for sorting is created (specified when a HiRDB/Parallel Server is being used)

/tmp/sortwork/: Name of the work directory for sorting

(4) Back up the RDAREAs storing the index and the table

Back up the RDAREAs storing the index and the table (RDAREA1 and RDAREA2). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(5) Use the pdrels command to release the RDAREAs storing the index and the table from shutdown status

pdrels -r RDAREA1,RDAREA2

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

14.2 Defining an index for a table that contains data

Executor: Table owner

An index can be added to a table that already contains data in order to modify the table processing procedure or to improve table retrieval performance.

Note

An index (B-tree index) cannot be defined for a column for which an abstract data type is defined (however, this does not apply in the case of an abstract data type provided by a plug-in).

Organization of this section

(1) Index addition procedure

(2) Reducing index creation time (EMPTY option)

(1) Index addition procedure

The following is the procedure for defining an index for a table that contains data:

Procedure

To define an index:

Use CREATE INDEX to define the index. If a UAP is accessing the table while the index is being defined, the UAP is placed in lock-release wait status.

If necessary, the optimizing information collection utility (pdgetcst command) should be executed after the index has been defined. Plug-in indexes are not processed by the optimizing information collection utility. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

Defining an index invalidates the index information of any stored routines that use the table for which that index is defined. If this happens, use the ALTER PROCEDURE or ALTER ROUTINE statement to re-create each stored routine.
In addition, defining an index for a table specified in a trigger SQL statement invalidates the index information of that trigger. If this happens, use the ALTER TRIGGER or ALTER ROUTINE statement to re-create the trigger.

(2) Reducing index creation time (EMPTY option)

When an index is to be defined for a table that has a large amount of data, it will take a considerable amount of time to create the index entity (to execute CREATE INDEX), and it will not be possible to execute any other definition SQL during this period.

However, if CREATE INDEX is executed with the EMPTY option specified, an index definition is created without creating the actual index entity. This is called an unfinished index. Because the index entity is not created, execution of CREATE INDEX is completed immediately, so that execution of other definition SQLs is not delayed.

Note that the EMPTY option can also be specified for a plug-in index.

Reference note

Because no index entity has been created for an unfinished index, the unfinished index cannot be used for retrieval processing, nor can a column be updated in a table for which an unfinished index is defined (if updating is attempted, an SQL error results).

The database condition analysis utility (pddbst command) can be used to determine whether or not an index is unfinished. In the case of condition analysis by index or by RDAREA (logical analysis), an unfinished index is indicated under the status heading; in the case of cluster key and clustering data page storage condition analysis, an unfinished index is reported in a warning message.

The index re-creation facility (-k ixrc) of the database reorganization utility (pdrorg command) is used to create an index entity. When an unfinished index's index entity is created, the unfinished status is released. If the table is deleted in its entirety by the PURGE TABLE statement, all indexes for the table are released from unfinished status.

An index for a partitioned table is also partitioned and stored in multiple RDAREAs, and the unfinished status is managed for each partitioned index. The database reorganization utility (pdrorg command) can create the index entity for each RDAREA that stores a part of the index. When only a part of the partitioned index is created, SQLs may or may not execute successfully, depending on the specified conditions.

14.3 Deleting an index

Executor: HiRDB administrator and table owner (or user with DBA privilege)

When changes are made to the processing procedure for a table that contains data, it may develop that some indexes are no longer needed because they are associated with table retrieval conditions that are no longer applicable. If such unneeded indexes are retained, extra processing time is required for them when rows or columns are added or updated. It is more efficient if unneeded indexes are deleted immediately.

The following is the procedure for deleting an index:

Procedure

To delete an index:

Use DROP INDEX to delete the index. If a UAP is accessing the table while the index is being deleted, the UAP is placed in lock-release wait status.

If necessary, the optimizing information collection utility (pdgetcst command) should be executed after the index has been deleted. Plug-in indexes are not processed by the optimizing information collection utility. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

When an index is deleted, any stored routines that use the deleted index become invalid, and the index information of any stored routines that use the table for which the deleted index is defined become invalid. If this happens, use the ALTER PROCEDURE or ALTER ROUTINE statement to re-create each stored routine.
In addition, if an index that is used by a trigger is deleted, the trigger becomes invalid. Deleting an index for a table specified in a trigger SQL statement invalidates the index information of that trigger. If this happens, use the ALTER TRIGGER or ALTER ROUTINE statement to re-create the trigger.

If any index-only global buffer is assigned to the deleted index, delete that global buffer. The procedure explained below is used to delete a global buffer.

Deleting a global buffer

Use one of the following methods to delete a global buffer:

Terminate HiRDB normally, and then change the pdbuffer operand specification (delete the pdbuffer operand associated with the index that was deleted).

Use the system reconfiguration command (pdchgconf command) to change the pdbuffer operand specification (delete the pdbuffer operand associated with the index that was deleted). This method eliminates the need to terminate HiRDB normally. Note that HiRDB Advanced High Availability must be installed in order to use this command. For details about changing HiRDB system definitions using the system reconfiguration command, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

Use the pdbufmod command to delete the global buffer. For details about deleting global buffers with the pdbufmod command, see 9.3 Adding, modifying, and deleting global buffers while HiRDB is running (dynamic updating of global buffers). To use this method to delete global buffers, both of the following conditions must be satisfied
HiRDB Advanced High Availability is installed.
The value Y is specified in the pd_dbbuff_modify operand.
When you use this method, the information associated with the deleted global buffer becomes invalid if HiRDB is terminated normally or through a planned termination. Therefore, change the pdbuffer operand specification while HiRDB is stopped (delete the pdbuffer operand associated with the index that was deleted). If you do not change the pdbuffer operand specification, an error will occur when HiRDB starts, because the global buffer is not assigned to any index.

14.4 Creating a definition SQL from an existing index

Executor: HiRDB administrator or a user with DBA privilege

The pddefrev command can be used to create a definition SQL from an existing index.

This command is useful for creating a new index by using an existing index's definition. A definition SQL created with the pddefrev command is used as the input information to the database definition utility (pddef command).

Reference note

Plug-in indexes are not processed by the pddefrev command (a definition SQL cannot be created).

14.5 Reducing the number of index page splits (unbalanced index split)

Executor: Table owner

Organization of this section

(1) Index page splitting

(2) Unbalanced index split

(1) Index page splitting

HiRDB indexes are based on a B-tree structure. When there is not enough space to add a key value to an index page, index page splitting occurs. Index page splitting is the method used by HiRDB to obtain additional free space when there is not enough space to add a key value to an index page. This method involves dividing the index information in the index page into two equal-sized halves and moving the latter half to a new page. Figure 14-2 shows an example of a typical index page split

Figure 14-2 Example of index page splitting

(a) Increase in the amount of log information due to index page splitting

As data is added to a table that has an index, key values are also added to the index pages. If the percentage of unused space in the index pages is small, index page splitting may occur frequently. Frequent index page splitting results in an increase in the amount of log information due to changes made to the index structure.

(b) Reducing the frequency of index page splits

The frequency of index page splits can be reduced by changing the percentage of unused space in the index pages; the percentage value is obtained from the index page split information acquired by executing the statistics analysis utility (pdstedit command). The percentage of unused space in the index pages is changed by modifying the value of the PCTFREE operand in the CREATE INDEX definition SQL. When this is done, the index must then be redefined.

For details on using the index page split information acquired by the statistics analysis utility, see 21.7 Tuning indexes.

(2) Unbalanced index split

In the case of normal index page splitting, adding consecutive key values reduces the index page data storage efficiency. For this situation, an unbalanced index split can be used. Unbalanced index split is a method for dividing unevenly the index information in an index page, rather than dividing it uniformly into two equal-size halves. This method improves the data storage efficiency when consecutive key values are added.

When unbalanced index split is specified, the ratio used for dividing the index information in an index page is determined by the location in the page at which a new key value is to be inserted.

If the insertion location is in the first half of the index page, the key value is expected to be added in the first part of the page. Therefore, the first portion is stored in the page on the left-hand side using as the split location the next key value that is greater than the key being added.

If the location of the key value to be added is in the second half of the index page, the key is expected to be added in the latter part of the page. Therefore, the latter portion is stored in the page on the right-hand side using as the split location the key value that is being added. Figure 14-3 shows an example of an unbalanced index split when a key value is to be added in the latter half of an index page.

Figure 14-3 Example of an unbalanced index split

(a) Scope of an unbalanced index split

Unbalanced index split is applicable only to leaf pages other than the last page. During rollback, regular index page splitting is used instead of an unbalanced index split. In this case, a page is split at a 50:50 ratio.

On the last leaf page, data is divided on the basis of the value specified in the PCTFREE operand in the CREATE INDEX definition SQL statement in order to handle addition of key values in ascending order for data loading, etc.

(b) Criteria for an unbalanced index split

Unbalanced index split is effective when it is applied to an index that satisfies the following conditions:

There is balance in terms of duplication of key values.

Lengths of key values are close to uniform.

Consecutive intermediate key values are added frequently.

(c) Specification

To use unbalanced index split, UNBALANCED SPLIT is specified as the index option in the CREATE INDEX or CREATE TABLE definition SQL statement.

14.6 Error handling during batch index creation

Executor: HiRDB administrator

When batch index creation is specified during data loading or reloading (during execution of the database load utility or database reorganization utility), batch index creation processing is executed once data loading or reload processing is completed. When batch index creation is specified during data loading or reloading, batch index creation processing is executed once data load or reload processing is completed. If an error occurs during the batch index creation processing (KFPL00716-I message is output), the table data is in completed status but the index data is in incomplete status. Figure 14-4 shows the procedure for recovering the index data in this situation.

Figure 14-4 Procedure for recovering index data

Organization of this section

14.6.1 Example of recovery when reloading (data loading) was performed in the log acquisition mode or the pre-update log acquisition mode

14.6.2 Example of recovery when reloading (data loading) was performed in the no-log mode (when the RDAREA storing the index contains no other tables or indexes)

14.6.3 Example of recovery when reloading (data loading) was executed in the no-log mode (when the RDAREA storing the index contains other tables or indexes)

14.6.4 Example of recovery in the event of an error on the disk that contains the index storage RDAREA

14.6.1 Example of recovery when reloading (data loading) was performed in the log acquisition mode or the pre-update log acquisition mode

Example

A table for which an index is defined was reloaded. However, because the size of the RDAREA storing the index was too small at this time (or a sort processing error occurred), an error occurs during batch index creation. When a sort processing error occurs, the KFPL15062-E message is issued.

Data was loaded in the addition mode into a table for which a plug-in index is defined. However, because the size of the RDAREA storing the index was too small at this time, an error occurs during batch plug-in index creation.

In such a case, the data is in the following status:

Organization of this subsection

(1) Use the pdmod command to increase the size of the RDAREA storing the index

(2) Use the pdhold command to shut down the RDAREA storing the index

(3) Use the pdrorg command to create the index in the batch mode

(4) Back up the RDAREA storing the index

(5) Use the pdrels command to release the RDAREA from shutdown status

(1) Use the pdmod command to increase the size of the RDAREA storing the index

If an error occurs because the RDAREA is too small, use the pdmod command to increase the size of the RDAREA storing the index (RDAREA2). For details about increasing the size of RDAREAs, see 15.3 Increasing the size of an RDAREA (RDAREA expansion).

Do not perform this operation when a sort processing error occurs. Take remedial action based on the error message that was issued.

(2) Use the pdhold command to shut down the RDAREA storing the index

pdhold -r RDAREA2

This operation is not required if the RDAREA is already shut down.

(3) Use the pdrorg command to create the index in the batch mode

pdrorg -k ixmk -t TABLE1 /pdrorg/rorg01

Using as input information the index information file that was created when reloading (or data loading) was performed, create the index in the batch mode.

(4) Back up the RDAREA storing the index

Because you created the index in the batch mode in the pre-update acquisition mode (default), back up the RDAREA storing the index (RDAREA2). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(5) Use the pdrels command to release the RDAREA from shutdown status

pdrels -r RDAREA2

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

14.6.2 Example of recovery when reloading (data loading) was performed in the no-log mode (when the RDAREA storing the index contains no other tables or indexes)

Example

A table for which an index is defined was reloaded. However, because the size of the RDAREA storing the index was too small at this time (or a sort processing error occurred), an error occurs during batch index creation. When a sort processing error occurs, the KFPL15062-E message is issued.

Data was loaded in the addition mode into a table for which a plug-in index is defined. However, because the size of the RDAREA storing the index was too small at this time, an error occurs during batch plug-in index creation.

In such a case, the data is in the following status:

Organization of this subsection

(1) Check the message

(2) Use the pdmod command to re-initialize the RDAREA storing the index

(3) Use the pdmod command to increase the size of the RDAREA storing the index

(4) Use the pdhold command to shut down the RDAREA storing the index

(5) Use the pdrorg command to re-create the index

(6) Back up the RDAREA storing the index

(7) Use the pdrels command to release the RDAREA from shutdown status

(1) Check the message

If you are loading data, check if the KFPL00703-I message was issued. If you are reloading, check if the KFPL00714-I or KFPL00734-I message was issued. If one of these messages has been issued, the table data is in completed status. In this case, use the pdrels command to release the RDAREA storing the table data (RDAREA1) from shutdown status.

pdrels -r RDAREA1

(2) Use the pdmod command to re-initialize the RDAREA storing the index

Use the pdmod command to re-initialize the RDAREA storing the index (RDAREA2). For details about re-initializing RDAREAs, see 15.4 Increasing the size of an RDAREA or modifying its attributes (RDAREA reinitialization).

(3) Use the pdmod command to increase the size of the RDAREA storing the index

If an error occurs because the RDAREA is too small, use the pdmod command to increase the size of the RDAREA storing the index (RDAREA2). For details about increasing the size of RDAREAs, see 15.3 Increasing the size of an RDAREA (RDAREA expansion).

Do not perform this operation when a sort processing error occurs. Take remedial action based on the error message that was issued.

(4) Use the pdhold command to shut down the RDAREA storing the index

pdhold -r RDAREA2

This operation is not required if the RDAREA is already shut down.

(5) Use the pdrorg command to re-create the index

pdrorg -k ixrc -t TABLE1 /pdrorg/rorg02

(6) Back up the RDAREA storing the index

Because you re-created the index in the pre-update acquisition mode (default), back up the RDAREA storing the index (RDAREA2). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(7) Use the pdrels command to release the RDAREA from shutdown status

pdrels -r RDAREA2

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

14.6.3 Example of recovery when reloading (data loading) was executed in the no-log mode (when the RDAREA storing the index contains other tables or indexes)

Example

A table for which an index is defined was reloaded. However, because the size of the RDAREA storing the index was too small at this time (or a sort processing error occurred), an error occurs during batch index creation. When a sort processing error occurs, the KFPL15062-E message is issued.

Data was loaded in the addition mode into a table in which a plug-in index is defined. However, because the size of the RDAREA storing the index was too small at this time, an error occurs during batch plug-in index creation.

In such a case, the data is in the following status:

Organization of this subsection

(1) Check the message

(2) Use the pdrstr command to recover the RDAREA storing the index

(3) Use the pdmod command to increase the size of the RDAREA storing the index

(4) Use the pdhold command to shut down the RDAREA storing the index

(5) Use the pdrorg command to re-create the index

(6) Back up the RDAREA storing the index

(7) Use the pdrels command to release the RDAREA from shutdown status

(1) Check the message

If you are loading data, check if the KFPL00703-I message was issued. If you are reloading, check if the KFPL00714-I or KFPL00734-I message was issued. If one of these messages has been issued, the table data is in completed status. In this case, use the pdrels command to release the RDAREA storing the table data (RDAREA1) from shutdown status.

pdrels -r RDAREA1

(2) Use the pdrstr command to recover the RDAREA storing the index

Recover the RDAREA storing the index (RDAREA2). For details about recovering RDAREAs, see 19. Database Recovery Procedures.

(3) Use the pdmod command to increase the size of the RDAREA storing the index

If an error occurs because the RDAREA is too small, use the pdmod command to increase the size of the RDAREA storing the index (RDAREA2). For details about increasing the size of RDAREAs, see 15.3 Increasing the size of an RDAREA (RDAREA expansion).

Do not perform this operation when a sort processing error occurs. Take remedial action based on the error message that was issued.

(4) Use the pdhold command to shut down the RDAREA storing the index

pdhold -r RDAREA2

This operation is not required if the RDAREA is already shut down.

(5) Use the pdrorg command to re-create the index

pdrorg -k ixrc -t TABLE1 /pdrorg/rorg03

(6) Back up the RDAREA storing the index

Because you re-created the index in the pre-update acquisition mode (default), back up the RDAREA storing the index (RDAREA2). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(7) Use the pdrels command to release the RDAREA from shutdown status

pdrels -r RDAREA2

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

14.6.4 Example of recovery in the event of an error on the disk that contains the index storage RDAREA

Example

Reload processing was executed on a table for which an index is defined. An error occurred during batch index creation because of an error on the disk that contains the index storage RDAREA.

Data load processing was executed in the addition mode on a table for which a plug-in index is defined. An error occurred during batch creation of plug-in index because of an error on the disk that contains the index storage RDAREA.

In such a case, the data is in the following status:

Organization of this subsection

(1) Check the message

(2) Take action to remedy the disk error

(3) Use the pdhold command to shut down the RDAREA storing the index

(4) Use the pdrstr command to recover the RDAREA storing the index

(5) Use the pdrorg command to re-create the index

(6) Back up the RDAREA storing the index

(7) Use the pdrels command to release the RDAREA from shutdown status

(1) Check the message

If you are loading data, check if the KFPL00703-I message was issued. If you are reloading, check if the KFPL00714-I or KFPL00734-I message was issued. If one of these messages has been issued, the table data is in completed status. In this case, use the pdrels command to release the RDAREA storing the table data (RDAREA1) from shutdown status. This operation is not required if reloading (or data loading) was performed in the no-log mode.

pdrels -r RDAREA1

(2) Take action to remedy the disk error

Perform troubleshooting to locate and remedy the disk error.

(3) Use the pdhold command to shut down the RDAREA storing the index

pdhold -r RDAREA2

This operation is required only if reloading (or data loading) was performed in the log acquisition mode or the pre-update log acquisition mode.

(4) Use the pdrstr command to recover the RDAREA storing the index

Recover the RDAREA storing the index (RDAREA2). For details about recovering RDAREAs, see 19. Database Recovery Procedures.

Do not release the RDAREA from shutdown even after it has been recovered.

(5) Use the pdrorg command to re-create the index

pdrorg -k ixrc -t TABLE1 /pdrorg/rorg05

(6) Back up the RDAREA storing the index

Because you re-created the index in the pre-update acquisition mode (default), back up the RDAREA storing the index (RDAREA2). For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(7) Use the pdrels command to release the RDAREA from shutdown status

pdrels -r RDAREA2

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

14.7 Delayed batch creation of a plug-in index

Executor: HiRDB administrator

Organization of this section

14.7.1 Delayed batch creation of a plug-in index

14.7.2 Environment setup

14.7.3 Procedure during UAP execution

14.7.4 Notes

14.7.5 Error handling procedures

14.7.1 Delayed batch creation of a plug-in index

When a large amount of row data is added to (or updated in) a table for which a plug-in index is defined, key values are added to the plug-in index. This may have an adverse effect on the performance of plug-in index key value addition processing.

Instead, when row data is added, plug-in index data addition processing can be skipped, and the database reorganization utility can be used later to execute plug-in index data addition processing in the batch mode. This is called delayed batch creation of a plug-in index. Figure 14-5 provides an overview of delayed batch creation of a plug-in index.

Figure 14-5 Delayed batch creation of a plug-in index

* When the system switchover facility is being used, create the index information file in a HiRDB file system area (character special file) on the shared disk.

Organization of this subsection

(1) Requirements

(2) Advantages

(3) Scope of application

(4) Criteria

(5) Limitations

(1) Requirements

The plug-in that is being used must support delayed batch creation of plug-in index. This facility cannot be used if it is not supported by the plug-in.

At the time this manual was issued, only the following plug-in supports this facility:

HiRDB Text Search Plug-in

(2) Advantages

Because data addition processing for the plug-in index can be skipped, the UAP execution time for adding or updating a large amount of row data (table data creation time) is reduced.

(3) Scope of application

This facility can be applied only to row addition or update processing. In other words, it is applicable to the following SQL statements:

INSERT statement

UPDATE statement

This facility is not applicable to row deletion processing (DELETE statement).

(4) Criteria

This facility is applied to batch processing that involves addition or updating of a large amount of data in a table for which an eligible plug-in index is defined.

When the HiRDB Text Search Plug-in is used, this facility is effective for batch processing that involves addition or updating of a large amount of data in a table for which the plug-in index defined. However, if the plug-in index is to be updated and then the contents are to be referenced during online processing, the differential index facility that is provided by HiRDB Text Search Plug-in is effective.

(5) Limitations

The following limitations apply to delayed batch creation of plug-in index:

(a) The plug-in index is not usable for retrieving an added or updated row until batch creation of the plug-in index is completed

Once the UAP has executed, conformity between the table's data and the plug-in index's data is lost until batch creation of plug-in index has been completed.*

If the plug-in index is used to retrieve an added or updated row during this period of nonconformity, an invalid result will probably be returned. For this reason, it is important that the plug-in index not be used to retrieve added or updated rows until batch creation of plug-in index is completed.

Valid processing results can be obtained as long as the plug-in index is not used. Also, the plug-in index can still be used to retrieve a row that was not added or updated by the UAP.

* When data is added, the plug-in index's data remains in the same status it was in before the UAP executed. When data is updated, the plug-in index's data is placed in deleted status until it is updated.

Thus, for an added or updated row, there is a loss of conformity between its table data and its plug-in index data.

(b) An ordinary UAP cannot update the plug-in index until batch creation of the plug-in index is completed

The plug-in index cannot be updated by an ordinary UAP (UAP for which delayed batch creation of plug-in index is not specified) until batch creation of plug-in index is completed. However, the PURGE TABLE statement can be executed.

(c) UAPs cannot be executed concurrently on the same table

The index information files are placed in the lock mode (EX). Therefore, UAPs that use this facility cannot be executed concurrently on the same table.

(d) No more data loading can be executed until batch creation of the plug-in index is completed

Data loading cannot be performed until batch creation of the plug-in index is completed. However, if the table is row-partitioned, you can use the delayed batch creation facility to perform UAP-based processing and to load additional data into RDAREAs in which no data is stored.

14.7.2 Environment setup

The environment setup procedure depends on whether the index information file is to be created in a regular file or in a HiRDB file system area. It is usually created in a regular file, but it must be created in a HiRDB file system area when the system switchover facility is being used.

Organization of this subsection

(1) Creating the index information file under a regular file (usual procedure)

(2) Creating the index information file in a HiRDB file system area (when the system switchover facility is being used)

(1) Creating the index information file under a regular file (usual procedure)

(a) Create a directory for the index information files

A directory for the index information files must be created. The index information files are created in this directory.

Hint

Index information files become very large. Create this directory on a disk that has sufficient free space. For details about the size of index information files, see 14.7.4(1) Index information files.

To avoid duplication of file names, no other files (other than index information files) should be placed in this directory.

Because HiRDB creates and deletes files in this directory, the HiRDB administrator must have write privilege for this directory.

(b) Specify the pd_plugin_ixmk_dir operand

Correct the HiRDB system definition. First, terminate HiRDB normally.

HiRDB/Single Server

The name of the directory created in (a) is specified in the pd_plugin_ixmk_dir operand of the single server definition.

HiRDB/Parallel Server

The name of the directory created in (a) is specified in the pd_plugin_ixmk_dir operand in the back-end server definition for the back-end server that contains the table that is to be processed. If the table is row-partitioned and stored in multiple servers, the pd_plugin_ixmk_dir operand must be specified in the back-end server definition of each such back-end server.

(c) Specify PDPLGIXMK=YES in the client environment definition

PDPLGIXMK=YES must be specified in the client environment definition (for details of the PDPLGIXMK operand, see the manual HiRDB Version 8 UAP Development Guide).

(2) Creating the index information file in a HiRDB file system area (when the system switchover facility is being used)

(a) Create a HiRDB file system area for the index information file

pdfmkfs -n 50 -l 256 -k UTL -e 60000 /hd001/ixdir

Explanation

-l option specifies the number of RDAREAs (number of RDAREAs in the server) that will store the plug-in indexes to be updated by this facility.

-k option specifies UTL.

-e option specifies 60000.

The HiRDB file system area created here must be used only for index information files to be used in delayed batch creation of plug-in indexes.

Create the HiRDB file system area in a character special file on the shared disk.

Index information files become very large. Create this directory on a disk that has sufficient free space. For details about the size of index information files, see 14.7.4(1) Index information files.

To avoid duplication of file names, do not store any files other than index information files in this HiRDB file system area.

Creation and deletion of files in the HiRDB file system area created here are performed by HiRDB. Therefore, the HiRDB administrator's write privilege is required for this HiRDB file system area.

(b) Specify the pd_plugin_ixmk_dir operand

Correct the HiRDB system definition. First, terminate HiRDB normally.

HiRDB/Single Server

Specify the name of the HiRDB file system area created in step (a) in the pd_plugin_ixmk_dir operand of the single server definition; specify this name as an absolute path name.

HiRDB/Parallel Server

Specify the name of the HiRDB file system area created in step (a) in the pd_plugin_ixmk_dir operand of the back-end server definition for the back-end server in which the target table is located; specify this name as an absolute path name. If the table is row-partitioned between servers, specify the pd_plugin_ixmk_dir operand in the back-end server definition of each such back-end server.

(c) Add operands to the client environment definition

Specify the following operands in the client environment definition (for details of these operands, see the manual HiRDB Version 8 UAP Development Guide):

Operand | Explanation
PDPLGIXMK | Specifies whether or not delayed batch creation of plug-in indexes can be performed; specify YES.
PDPLGPFSZ | Specifies the initial size of index information files for delayed batch creation.
PDPLGPFSZEXP | Specifies the size increase increment for index information files for delayed batch creation. When an index becomes full, its size is increased by the value specified here.

Guideline for estimating the number of updatable plug-in indexes

If the PDPLGPFSZ and PDPLGPFSZEXP operands are omitted, 8192 KB is used as the default for both operands. The number of updatable plug-in indexes in such a case will be as follows:

Plug-in used | Without incremental increases | With incremental increases
HiRDB Text Search Plug-in | 215,000 indexes | 5,160,000 indexes

Specification example of the PDPLGPFSZ and PDPLGPFSZEXP operands

Shown below is a specification example of the above operands when multiple plug-in indexes are updated.

Example

File size of plug-in index 1: 10240 KB

File size of plug-in index 2: 81920 KB

Example of specifying the PDPLGPFSZ and PDPLGPFSZEXP operands for this case:

  PDPLGPFSZ=10240
  PDPLGPFSZEXP=10240

With these specifications, the file size of plug-in index 2 is increased seven times, and file areas can be used without any waste of space. Note that each file can be increased in size up to 23 times.

14.7.3 Procedure during UAP execution

The following is the procedure from UAP execution to delayed batch creation of plug-in index:

Execute the UAP. When the UAP executes, information about the plug-in index is output to the index information file. The name of the created index information file is provided in the KFPH25100-I message.

Use the pdhold command to shut down the plug-in index storage RDAREA:
pdhold -r RDAREA1

Use the pdrorg command to specify creation of the plug-in index in the batch mode (the index information file created in step 1 is used as the input):
pdrorg -k ixmk -t TABLE1 /pdrorg/rorg06

Use the pdrels command to release the plug-in index storage RDAREA from shutdown status:
pdrels -r RDAREA1

14.7.4 Notes

Organization of this subsection

(1) Index information files

(2) Backup

(3) Deadlock on index information files

(4) Stored procedures and stored functions

(1) Index information files

(a) Number of files created

An index information file is created for each RDAREA that stores the plug-in index. Therefore, the number of index information files created equals the number of RDAREAs that store the plug-in index updated by the UAP.

(b) Names of created files

The names to be assigned to index information files are determined by the index identifiers and RDAREA names (according to the rules shown below). These index information file names are specified in the control statements file of the database reorganization utility (pdrorg command).

Condition
Index information file name

When all the following conditions are satisfied:

index-identifier-length + RDAREA-name-length < 30 bytes

The index identifier and RDAREA name are character strings, as explained in the note below.

index-identifier.RDAREA-name

When all the following conditions are satisfied:

index-identifier-length + RDAREA-name-length 30 bytes

The index identifier and RDAREA name are character strings, as explained in the note below.

index-ID.RDAREA-ID.leading-portion-of-index-identifier*

The index identifier and RDAREA name consist of character strings other than as explained in the note below.
index-ID.RDAREA-ID

Note

A character string consists of the characters A to Z, a to z, 0 to 9, period (.), underline (_), and @. It is recommended that index identifiers and RDAREA names be assigned according to this rule.

* First 12 bytes of the index identifier

When the inner replica facility is being used

When a replica RDAREA contains a plug-in index, the index information file name is determined according to the following conditions:

Condition
Index information file name

The name of the directory containing the index information file is specified in the pd_plugin_ixmk_dir operand.
index-identifier.original-RDAREA-name.RDAREA-generation-number

Both of the following conditions are satisfied:

index-identifier-length = RDAREA-name-length < 27 bytes

The index identifier and the RDAREA name are character strings, as explained in the note below.

The following condition is satisfied:

index-identifier-length + RDAREA-name-length 27 bytes

The index identifier and the RDAREA name are character strings, as explained in the note below.

index-ID.RDAREA-ID.leading-portion-of-index-identifier*.RDAREA-generation-number

The index identifier or the RDAREA name consists of a character string other than that explained in the note below.
index-ID.RDAREA-ID.RDAREA-generation-number

Note

A character string consists of the characters A to Z, a to z, 0 to 9, period (.), underline (_), and @. It is recommended that index identifiers and RDAREA names be assigned according to this rule.

* First 9 bytes of the index identifier

(c) Size of a created file

The size of an index information file will be large. The size of one file can be determined from the following formula:

(12 + E) (A + B + C D) + 1024 (bytes)

A: Number of row data items added (number of data items updated by INSERT statement)

B: Number of row data items updated (number of data items updated by UPDATE statement)

C: Number of UAPs specifying delayed batch creation of plug-in index

D: Number of COMMIT statements issued in the UAP

E: Depends on the type of plug-in; for the HiRDB Text Search Plug-in, the value is 27.

(d) File deletion

Index information files are deleted automatically by HiRDB when they are no longer needed. The files are deleted at the following times:

When batch creation of plug-in index is completed successfully

When re-creation of plug-in index has been executed

The files are deleted automatically only when this processing is executed; otherwise, such files must be deleted manually by the user.

(2) Backup

Once the UAP executes, conformity is lost between the table's data and the plug-in index's data until batch creation of plug-in index is completed. Thus, a backup of the data should not be made during this time.

(3) Deadlock on index information files

If more than one UAP specifying delayed batch creation of plug-in index is executed on the same row-partitioned table, deadlock may occur on the index information files.

(4) Stored procedures and stored functions

Delayed batch creation of plug-in index is not supported for stored procedures and stored functions created under HiRDB Version 5.0 05-02 or earlier. If an attempt is made in such a case to execute delayed batch creation of plug-in index by specifying PDPLGIXMK=YES, the KFPA11537-E message will be output and an error will result. When this happens, one of the following actions should be taken:

To execute delayed batch creation of a plug-in index
Execute ALTER ROUTINE or ALTER PROCEDURE on the stored procedures and stored functions that update the plug-in index.

To not execute delayed batch creation of a plug-in index
Execute the UAP with PDPLGIXMK=NO specified.

14.7.5 Error handling procedures

Organization of this subsection

(1) Error in an index information file

(2) Error during UAP execution

(3) Error during batch creation of a plug-in index

(1) Error in an index information file

If an error occurs in an index information file after the UAP has executed but before batch creation of plug-in indexes is completed, delayed batch creation of plug-in indexes cannot be executed. In such a case, the plug-in index must be created by one of the following methods:

Use the database reorganization utility to re-create the plug-in index

Execute DROP INDEX, then execute CREATE INDEX to create the plug-in index

If there is a large number of data items, either method will require a considerable amount of time because the amount of plug-in index data is equivalent to the number of data items added by the UAP plus the number of data items contained initially in the table.

Therefore, a directory with sufficient disk space must be provided in order to avoid a space shortage for the index information files.

(2) Error during UAP execution

Rollback executed

Appropriate action to correct the error must be taken, then the UAP can be re-executed.

Rollback not executed

If the UAP was executed in the no-log mode, rollback is not executed. In such a case, the database must be restored with the database recovery utility, then the UAP can be re-executed.

(3) Error during batch creation of a plug-in index

Appropriate action to correct the error must be taken, then the database reorganization utility can be executed to create the plug-in index in the batch mode.

15. Handling RDAREAs

This chapter explains the procedures for handling RDAREAs.

It contains the following sections:

Organization of this chapter

15.1 RDAREA space shortage

15.2 Creating an RDAREA (RDAREA addition)

15.3 Increasing the size of an RDAREA (RDAREA expansion)

15.4 Increasing the size of an RDAREA or modifying its attributes (RDAREA reinitialization)

15.5 Modifying an RDAREA opening trigger attribute (RDAREA modification)

15.6 Deleting an RDAREA

15.7 RDAREA automatic extension

15.8 Moving an RDAREA (RDAREA migration)

15.9 Re-using used free pages and used free segments

15.1 RDAREA space shortage

Executor: HiRDB administrator

If a table is subjected to many data additions and deletions, a shortage of space may occur in the table's storage RDAREA. HiRDB issues the following messages for a table whose data retrieval efficiency or storage efficiency has been reduced:

KFPA12300-I

KFPH00211-I

KFPH00212-I

Organization of this section

(1) When to increase the size of an RDAREA

(2) Using the pddbls command to obtain the number of unused segments in the RDAREA

(3) Space shortage in a list RDAREA

(4) Using the facility for RDAREA automatic extension

(1) When to increase the size of an RDAREA

The size of an existing RDAREA should be increased or a new RDAREA should be created in the following cases:

When any of these messages is output frequently for a table stored in a particular RDAREA

When any of these messages is output during or immediately after table reorganization

When any of these messages is output during or immediately after index reorganization

In such a case, the database structure modification utility (pdmod command) should be used to increase the size of the RDAREA or to create a new RDAREA.

(2) Using the pddbls command to obtain the number of unused segments in the RDAREA

The pddbls command can be used determine how much unused space remains in RDAREA (number of unused segments).

Example

Use the pddbls command to check the number of unused segments in the RDAREA named RDAREA1:

pddbls -r RDAREA1 -a

STATE OF RDAREA
   RDAREA        ID       STATUS                 TYPE
                          OPNMODE
   RDAREA1       4        OPEN                   USER
                          INITIAL
   SEGMENT   75 / 700

Explanation

SEGMENT displays the number of unused segments, followed by the total number of segments. The number of unused segments is the remaining available space in the RDAREA.

In this example, the number of unused segments is 75, and the total number of segments is 700. When the number of unused segments is low, the RDAREA should be expanded.

(3) Space shortage in a list RDAREA

If execution of an ASSIGN LIST statement results in the number of created lists exceeding the number of lists that can be created in the RDAREA (KFPA11812-E message is output), you must use the database structure modification utility to add a list RDAREA.

If execution of an ASSIGN LIST statement results in a shortage of RDAREA pages (KFPA11756-E message is output), you must use one of the following methods to increase the RDAREA size:

RDAREA addition

RDAREA expansion

RDAREA reinitialization

When the size of a list RDAREA is expanded by means of RDAREA reinitialization, the lists stored in that list RDAREA are deleted and must be re-created with the ASSIGN LIST statement.

(4) Using the facility for RDAREA automatic extension

When an RDAREA space shortage occurs, the RDAREA can be extended automatically if space is available in the HiRDB file system area; this is called RDAREA automatic extension (for details on RDAREA automatic extension, see 15.7 RDAREA automatic extension).

15.2 Creating an RDAREA (RDAREA addition)

Executor: HiRDB administrator

A new RDAREA can be added by using the create rdarea statement of the database structure modification utility (pdmod command).

Organization of this section

15.2.1 Before adding an RDAREA

15.2.2 Example

15.2.1 Before adding an RDAREA

Organization of this subsection

(1) RDAREAs that can be added

(2) When to add an RDAREA

(3) Notes

(4) Allocating a global buffer

(5) Rules for using stored procedures and stored functions

(1) RDAREAs that can be added

The following RDAREAs can be added:

Data dictionary LOB RDAREA

Data dictionary RDAREAs*

User RDAREAs

User LOB RDAREAs

List RDAREAs

* These are the data dictionary RDAREAs for storing dictionary tables used for routine management.

(2) When to add an RDAREA

A new RDAREA should be added in the following cases:

When a new table or index is to be created in a new RDAREA, rather than in an existing RDAREA

When free space is to be created in an existing RDAREA by moving part of a table or index to a new RDAREA

When a narrowed search is to be performed or when the number of created lists exceeds the maximum (add a list RDAREA)

(3) Notes

When adding an RDAREA, keep in mind the values of the following operands. If either of these operand values is exceeded, RDAREAs cannot be added.

Maximum number of RDAREAs, as specified in the pd_max_rdarea operand

Maximum number of HiRDB files comprising RDAREAs, as specified in the pd_max_file_no operand

(4) Allocating a global buffer

If you plan to use the RDAREA that was added right away, you must allocate a global buffer by means of one of the methods described below.

(a) Allocating a global buffer when the pdmod command is executed

With this method, you allocate global buffers using the globalbuffer operand of the create rdarea statement in the pdmod command. However, this method can be used only to allocate existing global buffers (global buffers that have been specified with the -r or -o option of the pdbuffer operand). This method cannot be used in any of the following cases (in these cases, you must use one of the methods described in (b) or (c) below):

When the page length of the RDAREA being added is equal to or greater than the buffer size of the global buffer

When an index or LOB global buffer is being allocated

When a newly added global buffer is being allocated

Global buffers that are allocated using this method become invalid when HiRDB terminates normally or by means of a planned termination, so you will have to change the pdbuffer operand specification while HiRDB is stopped. Note also that you may be able to use the system reconfiguration command (pdchgconf command) to change the value specified in the pdbuffer operand while HiRDB is running.

Reference note

If you do not change the value specified in the pdbuffer operand, the RDAREA that was added will be allocated a global buffer specified with the -o option when HiRDB is started subsequently.

If you restart HiRDB, a global buffer specified with the globalbuffer operand remains allocated.

(b) Allocating a global buffer with the pdbufmod command

With this method, you allocate global buffers with the pdbufmod command. This method can also be used to allocate newly added global buffers. However, in order to add global buffers using this method, both of the following conditions must be satisfied:

HiRDB Advanced High Availability is installed.

The value Y is specified in the pd_dbbuff_modify operand.

For details about allocating global buffers with the pdbufmod command, see 9.3 Adding, modifying, and deleting global buffers while HiRDB is running (dynamic updating of global buffers).

(c) Allocating a global buffer with the system reconfiguration command (pdchgconf command)

With this method, you allocate global buffers by using the system reconfiguration command (pdchgconf command) to change the value specified in the pdbuffer operand. You can also use this method to allocate newly added global buffers, in addition to existing global buffers. Note that HiRDB Advanced High Availability must be installed in order to use this command.

For details about changing HiRDB system definitions using the system reconfiguration command, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

(5) Rules for using stored procedures and stored functions

When a data dictionary LOB RDAREA is added, a data dictionary table for routine management is also created. If there is not enough space in the data dictionary RDAREA, it must first be expanded.

When a data dictionary LOB RDAREA is added, data dictionary RDAREAs for storing the data dictionary table for routine management can also be added at the same time.

When a data dictionary LOB RDAREA is added, two RDAREAs must be added at the same time.

15.2.2 Example

This example adds a user RDAREA named RDAREA1.

Procedure

Use the pdfmkfs command to create a HiRDB file system area for the RDAREA. This operation is not required if you add the RDAREA to an existing HiRDB file system area.

Create a control statements file for the pdmod command.

Use the pdmod command to add the RDAREA.

Use the pdcopy command to back up data.

Use the pdbufmod command to allocate a global buffer.

Update the pdbuffer operand.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Use the pdfmkfs command to create a HiRDB file system area for the RDAREA

(2) Create the control statements file for the pdmod command

(3) Use the pdmod command to add the RDAREA

(4) Use the pdcopy command to back up data

(5) Use the pdbufmod command to allocate a global buffer

(6) Update the pdbuffer operand

(1) Use the pdfmkfs command to create a HiRDB file system area for the RDAREA

pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area01

Explanation

A HiRDB file system area (/rdarea/area01) is created for the RDAREA.

-n: Specifies in megabytes the size of the HiRDB file system area.

-l: Specifies the maximum number of HiRDB files that can be created in the HiRDB file system area.

-k: Specifies DB to create a HiRDB file system area for RDAREAs.

-i: Specifies that the HiRDB file system area is to be initialized.

/rdarea/area01: Specifies the name of the HiRDB file system area to be created.

(2) Create the control statements file for the pdmod command

A control statements file (/pdmod/create01) that contains the pdmod command's create rdarea statement is created. The following are the contents of the control statements file:

create rdarea RDAREA1                              1
  globalbuffer gbuf01                             2
  for user used by PUBLIC                         3
  server name bes1                                4
  page 4096 characters                            5
  storage control segment 10 pages                6
  file name "/rdarea/area01/file01"               7
     initial 1000 segments;                       8

Explanation

Specifies a name for the RDAREA to be created (RDAREA1).

Specifies the global buffer (gbuf01) to be allocated for RDAREA1. Because a global buffer specified with this operand will not be allocated when HiRDB is started subsequently, you will have to change the value specified in the pdbuffer operand. Note that if you allocate a global buffer in step (5) below, you need not specify this operand.

Specifies that RDAREA1 is to be a public RDAREA.

Specifies the name of the server to which the RDAREA is to be added; this option is specified only in the case of a HiRDB/Parallel Server.

Specifies the page length.

Specifies the segment size.

Specifies the HiRDB file that is to constitute the RDAREA; /rdarea/rdarea01 is the HiRDB file system area created in step (1).

Specifies the number of HiRDB file segments.

(3) Use the pdmod command to add the RDAREA

pdmod -a /pdmod/create01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (2).

(4) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is reinitialized, the contents of the master directory RDAREA and the data dictionary RDAREA are updated. Therefore, all RDAREAs are backed up here.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(5) Use the pdbufmod command to allocate a global buffer

This step adds a new global buffer (gbuf01) and allocates it to RDAREA1.

pdbufmod -k add -a gbuf01 -r RDAREA1 -n 1000

Explanation

-k add: Specifies that a global buffer is to be added.

-a: Specifies the name of the global buffer being added.

-r: Specifies the RDAREA for which the global buffer is being allocated.

-n: Specifies the sector count of the global buffer.

Note, however, to use the pdbufmod command, both of the following conditions must be satisfied:

HiRDB Advanced High Availability is installed.

The value Y is specified in the pd_dbbuff_modify operand.

(6) Update the pdbuffer operand

The global buffer allocated in this procedure becomes invalid if HiRDB is terminated normally or through a planned termination. Therefore, change the pdbuffer operand specification while HiRDB is stopped. An example of the pdbuffer operand specification follows:

                        :
pdbuffer -a gbuf01 -r RDAREA1,RDAREA2,RDAREA3 -n 1000
                        :

Explanation

The added RDAREA (RDAREA1) is assigned to a global buffer (gbuf01).

Note that you can use the system reconfiguration command (pdchgconf command) to change the pdbuffer operand specification while HiRDB is running. However, to use the system reconfiguration command, you must have HiRDB Advanced High Availability. For details about changing HiRDB system definitions using the system reconfiguration command, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.3 Increasing the size of an RDAREA (RDAREA expansion)

Executor: HiRDB administrator

The expand rdarea statement of the database structure modification utility (pdmod command) can be used to increase (expand) the size of an RDAREA. RDAREA expansion means increasing the size of an RDAREA while retaining the data stored in it. An RDAREA is expanded by adding HiRDB files to the existing RDAREA.

Organization of this section

15.3.1 Before expanding an RDAREA

15.3.2 Example

15.3.1 Before expanding an RDAREA

Organization of this subsection

(1) RDAREAs that can be expanded

(2) When to expand an RDAREA

(3) Notes

(1) RDAREAs that can be expanded

The following RDAREAs can be expanded:

User RDAREAs

User LOB RDAREAs

Master directory RDAREA

Data directory RDAREA

Data dictionary RDAREAs

Data dictionary LOB RDAREAs

Registry RDAREA

Registry LOB RDAREA

List RDAREAs

(2) When to expand an RDAREA

RDAREA expansion should be performed under the following circumstances:

The number of rows in a table has increased to the point that no more data can be stored.

RDAREA reinitialization cannot be used to increase the size of the RDAREA (for details on RDAREA reinitialization, see 15.4 Increasing the size of an RDAREA or modifying its attributes (RDAREA reinitialization)).

The RDAREA can contain multiple HiRDB files.

(3) Notes

If you increase the number of HiRDB files, keep in mind the value in the pd_max_file_no operand. If the number of all HiRDB files in the RDAREAs exceeds the value in this operand, RDAREAs cannot be added.

You must handle the RDAREA's status as expanded below:

If the RDAREA is in error shutdown status, eliminate the cause of the error shutdown, and then use the pdrels command to release the error shutdown status.

If the RDAREA is in closed status, use the pdopen command to place it in open status.

15.3.2 Example

This example expands a user RDAREA named RDAREA1.

Procedure

Use the pdfmkfs command to create a HiRDB file system area for the RDAREA. Perform this option only if the HiRDB file system area of the RDAREA you plan to expand does not have enough free space.

Create a control statements file for the pdmod command.

Use the pdmod command to expand the RDAREA.

Use the pdcopy command to back up data.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Use the pdfmkfs command to create a HiRDB file system area for the RDAREA

(2) Create the control statements file for the pdmod command

(3) Use pdmod command to expand the RDAREA

(4) Use the pdcopy command to back up data

(1) Use the pdfmkfs command to create a HiRDB file system area for the RDAREA

pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area11

Explanation

A HiRDB file system area (/rdarea/area11) is created for the RDAREA.

-n: Specifies in megabytes the size of the HiRDB file system area.

-l: Specifies the maximum number of HiRDB files that can be created in the HiRDB file system area.

-k: Specifies DB to create a HiRDB file system area for RDAREAs.

-i: Specifies that the HiRDB file system area is to be initialized.

/rdarea/area11: Specifies a name for the HiRDB file system area to be created.

(2) Create the control statements file for the pdmod command

A control statements file (/pdmod/expand01) that contains the pdmod command's expand rdarea statement is created. The following are the contents of the control statements file:

expand rdarea RDAREA1                              1
  file name "/rdarea/area11/file01"               2
     initial 1000 segments;                       3

Explanation

Specifies the RDAREA (RDAREA1) to be expanded.

Specifies the HiRDB file to be added; /rdarea/rdarea11 is the HiRDB file system area created in step (1).

Specifies the number of segments for the HiRDB file.

(3) Use pdmod command to expand the RDAREA

pdmod -a /pdmod/expand01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (2).

(4) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02
-p /pdcopy/list02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is reinitialized, the contents of the master directory RDAREA and the data dictionary RDAREA are updated. Therefore, all RDAREAs are backed up here.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.4 Increasing the size of an RDAREA or modifying its attributes (RDAREA reinitialization)

Executor: HiRDB administrator

The initialize rdarea statement of the database structure modification utility (pdmod command) can be used to increase (expand) the size of an RDAREA or to modify its attributes (reinitialize it). RDAREA reinitialization means erasing all data in an RDAREA in order to increase its size or to modify its attributes (e.g., to increase the size of an HiRDB file constituting the RDAREA or to modify the segment size).

By reinitializing an RDAREA, you can change the HiRDB files that constitute the RDAREA and change the disk layout for RDAREAs. For the procedure, see 15.4.10 Example 9 (changing the disk layout for RDAREAs).

Note that the master directory RDAREA, data dictionary RDAREAs, and data directory RDAREA cannot be reinitialized. To change the disk layout for these RDAREAs, you must use the database initialization utility to initialize the database again. For details about how to migrate a database, see 12. Migrating Resources Between Systems.

Organization of this section

15.4.1 Before reinitializing an RDAREA

15.4.2 Example 1 (index is defined)

15.4.3 Example 2 (index is defined)

15.4.4 Example 3 (LOB column is defined)

15.4.5 Example 4 (LOB column is defined)

15.4.6 Example 5 (abstract data type is defined)

15.4.7 Example 6 (abstract data type is defined)

15.4.8 Example 7 (using a UAP, all RDAREAs associated with a table are reinitialized, and data is recovered)

15.4.9 Example 8 (using a UAP, all RDAREAs associated with a table are reinitialized, and data is recovered)

15.4.10 Example 9 (changing the disk layout for RDAREAs)

15.4.1 Before reinitializing an RDAREA

Organization of this subsection

(1) RDAREAs that can be reinitialized

(2) When to reinitialize an RDAREA

(3) Notes

(4) Initializing a registry RDAREA or registry LOB RDAREA

(1) RDAREAs that can be reinitialized

The following RDAREAs can be reinitialized:

User RDAREAs

User LOB RDAREAs

Data dictionary LOB RDAREA (for storing objects only)

Registry RDAREA

Registry LOB RDAREA

List RDAREAs

(2) When to reinitialize an RDAREA

RDAREA reinitialization should be performed under the following circumstances:

The number of rows in a table has increased to the point that no more data can be stored.

The HiRDB file structure needs to be modified (number of files, size of a HiRDB file).

The HiRDB file organization (HiRDB file name) is to be changed.

(3) Notes

Back up the RDAREA being reinitialized before and after reinitialization. If an error occurs in the RDAREA after it has been initialized, it cannot be recovered from a backup made before it was reinitialized.

Because all the data is erased from an RDAREA when it is reinitialized, it is important to unload the data in advance with the database reorganization utility (pdrorg command).

An RDAREA to be reinitialized should be placed in shutdown and closed status with the pdhold command.

If you increase the number of HiRDB files, pay attention to the value of the pd_max_file_no operand. If the number of all HiRDB files in RDAREAs exceeds the value of this operand, RDAREAs cannot be added.

When a user LOB RDAREA is reinitialized, data for the LOB column structure base table remains unchanged. A LOB column is treated as data with a length of 0.

If a data dictionary LOB RDAREA for storing stored objects is reinitialized, all SQL objects must be re-created with ALTER PROCEDURE ALL.

When a list RDAREA is reinitialized, all lists in that list RDAREA are deleted. Therefore, to execute a narrowed search, re-create the lists with the ASSIGN LIST statement.

The database reorganization utility (pdrorg command) cannot be executed for a list RDAREA.

An RDAREA containing a falsification prevented table cannot be reinitialized.

When a data dictionary LOB RDAREA (for storing objects) is reinitialized, the SQL_DIV_COLUMN data dictionary table should be referenced to check the name of the data dictionary LOB RDAREA. The following is an example of this referencing:
Example

  SELECT RDAREA_NAME FROM MASTER.SQL_DIV_COLUMN
     WHERE TABLE_SCHEMA='HiRDB'
       AND TABLE_NAME='SQL_ROUTINES'
       AND COLUMN_NAME='ROUTINE_OBJECT'

(4) Initializing a registry RDAREA or registry LOB RDAREA

When a registry RDAREA or registry LOB RDAREA is reinitialized, the registry information used by plug-ins must be reregistered.

When a registry LOB RDAREA is reinitialized, the registry RDAREA must also be reinitialized.

15.4.2 Example 1 (index is defined)

In this example, a user RDAREA (RDAREA1) is reinitialized and, at the same time, the capacity of the RDAREA is increased.

One table (TABLE1) is stored in RDAREA1.

An index (INDEX1) is defined for TABLE1; this index is stored in a different user RDAREA (RDAREA2).

Procedure

Use the pdfstatfs command to determine if the HiRDB file system area has free space.

Prepare a HiRDB file system area.

Use the pdhold command to shut down RDAREA1.

Use the pdcopy command to back up data.

Create a control statements file for the pdrorg command.

Use the pdrorg command to unload the data from TABLE1.

Use the pdclose command to close RDAREA1.

Create a control statements file for the pdmod command.

Use the pdmod command to reinitialize (increase the size of) RDAREA1.

Use the pdopen command to open RDAREA1.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reload data for TABLE1.

Use the pdcopy command to back up data.

Use the pdrels command to release RDAREA1 from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

(2) Prepare a HiRDB file system area

(3) Use the pdhold command to shut down RDAREA1

(4) Use the pdcopy command to back up data

(5) Create the control statements file for the pdrorg command

(6) Use the pdrorg command to unload the data from TABLE1

(7) Use the pdclose command to close RDAREA1

(8) Create the control statements file for the pdmod command

(9) Use the pdmod command to reinitialize (increase the size of) RDAREA1

(10) Use the pdopen command to open RDAREA1

(11) Create the control statements file for the pdrorg command

(12) Use the pdrorg command to reload data for TABLE1

(13) Use the pdcopy command to back up data

(14) Use the pdrels command to release RDAREA1 from shutdown status

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

pdfstatfs /rdarea/area01

(2) Prepare a HiRDB file system area

Assume you determined in step (1) that the HiRDB files system area has no free space. In order to increase the size of the RDAREA when you reinitialize it, you must use one of the following methods to prepare a HiRDB file system area:

Allocate a new HiRDB file system area that is larger than the existing HiRDB file system area.

Allocate a new HiRDB file system area in addition to the existing HiRDB file system area.

Expand the existing HiRDB file system area.

This example uses method 1 to prepare a HiRDB file system area.

pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area02

(3) Use the pdhold command to shut down RDAREA1

pdhold -r RDAREA1

(4) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown explained in section 6.3. In this example, all RDAREAs are backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(5) Create the control statements file for the pdrorg command

A control statements file containing the pdrorg command's unload statement (/pdrorg/unld01) is created. The following are the contents of the control statements file:

unload /unld/unldfile

Explanation

The name of the unload file is specified.

(6) Use the pdrorg command to unload the data from TABLE1

pdrorg -k unld -t TABLE1 /pdrorg/unld01

Explanation

-k: Specifies unld in order to unload.

-t: Specifies the name of the table to be unloaded.

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command created in step (5).

(7) Use the pdclose command to close RDAREA1

pdclose -r RDAREA1

(8) Create the control statements file for the pdmod command

A control statements file that contains the pdmod command's initialize rdarea statement (/pdmod/init01) is created. The following are the contents of the control statements file:

initialize rdarea RDAREA1                               1
  with reconstruction                                  2
  file name "/rdarea/area02/file01"                    3
     initial 3000 segments;                            4

Explanation

The newly created HiRDB file system area is allocated for RDAREA1.

Specifies the RDAREA (RDAREA1) to be reinitialized.

Because the file structure is being changed from what it was before reinitialization, specify with reconstruction.

Specifies the HiRDB file that is to constitute the RDAREA.

Specifies the number of segments for the HiRDB file.

(9) Use the pdmod command to reinitialize (increase the size of) RDAREA1

pdmod -a /pdmod/init01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (8).

(10) Use the pdopen command to open RDAREA1

pdopen -r RDAREA1

(11) Create the control statements file for the pdrorg command

A control statements file containing the pdrorg command's unload, index, and sort statements (/pdrorg/reld01) is created. The following are the contents of the control statements file:

unload /unld/unldfile                           1
index INDEX1 /unld/index_inf                    2
sort /tmp/sortwork/,8192                        3

Explanation

Specifies the name of the unload file.

Specifies the index identifier (INDEX1) and the name of the index information file (/unld/index_inf).

Specifies the name of the sort work directory.

(12) Use the pdrorg command to reload data for TABLE1

pdrorg -k reld -t TABLE1 /pdrorg/reld01

Explanation

To create the index (INDEX1) at the same time, the -i option is omitted in order to execute in the batch index creation mode.

-k: Specifies reld in order to reload.

-t: Specifies the name of the table to be reloaded.

/pdrorg/reld01: Specifies the name of the control statements file for the pdrorg command created in step (11).

(13) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

(14) Use the pdrels command to release RDAREA1 from shutdown status

pdrels -r RDAREA1

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.4.3 Example 2 (index is defined)

In this example, a user RDAREA (RDAREA2) is reinitialized and, at the same time, the capacity of the RDAREA is increased.

One table (TABLE1) is stored in RDAREA1.

An index (INDEX1) is defined for TABLE1; this index is stored in a different user RDAREA (RDAREA2).

Procedure

Use the pdfstatfs command to determine if the HiRDB file system area has free space.

Prepare a HiRDB file system area.

Use the pdhold command to place RDAREA2 in shutdown and closed status.

Use the pdcopy command to back up data.

Create a control statements file for the pdmod command.

Use the pdmod command to reinitialize (increase the size of) RDAREA1.

Use the pdopen command to open RDAREA2.

Create a control statements file for the pdload command.

Use the pdload command to create an index in the batch mode (execute batch index creation without loading any data items).

Use the pdcopy command to back up data.

Use the pdrels command to release RDAREA2 from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

(2) Prepare a HiRDB file system area

(3) Use the pdhold command to place RDAREA2 in shutdown and closed status

(4) Use the pdcopy command to back up data

(5) Create the control statements file for the pdmod command

(6) Use the pdmod command to reinitialize (increase the size of) RDAREA2

(7) Use the pdopen command to open RDAREA2

(8) Create the control statements file for the pdload command

(9) Use the pdload command to create an index in batch mode (execute batch index creation with loading of no data items)

(10) Use the pdcopy command to back up data

(11) Use the pdrels command to release RDAREA2 from shutdown status

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

pdfstatfs /rdarea/area01

(2) Prepare a HiRDB file system area

Assume you determined in step (1) that the HiRDB files system area has no free space. In order to increase the size of the RDAREA when you reinitialize it, you must use one of the following methods to prepare a HiRDB file system area:

Allocate a new HiRDB file system area that is larger than the existing HiRDB file system area.

Allocate a new HiRDB file system area in addition to the existing HiRDB file system area.

Expand the existing HiRDB file system area.

This example uses method 1 to prepare a HiRDB file system area.

pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area02

(3) Use the pdhold command to place RDAREA2 in shutdown and closed status

pdhold -r RDAREA2 -c

(4) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(5) Create the control statements file for the pdmod command

A control statements file that contains the pdmod command's initialize rdarea statement (/pdmod/init01) is created. The following are the contents of the control statements file:

initialize rdarea RDAREA2                               1
  with reconstruction                                  2
  file name "/rdarea/area02/file01"                    3
     initial 3000 segments;                            4

Explanation

The newly created HiRDB file system area is allocated for RDAREA2.

Specifies the RDAREA to be reinitialized (RDAREA2).

Because the file structure is being changed from what it was before reinitialization, specify with reconstruction.

Specifies the HiRDB file that is to constitute the RDAREA.

Specifies the number of segments for the HiRDB file.

(6) Use the pdmod command to reinitialize (increase the size of) RDAREA2

pdmod -a /pdmod/init01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (5).

(7) Use the pdopen command to open RDAREA2

pdopen -r RDAREA2

(8) Create the control statements file for the pdload command

A control statements file containing the pdload command's source, index, and sort statements (/pdload/load01) is created. The following are the contents of the control statements file:

source /load/loadfile error=/tmp/err          1
index INDEX1 /load/index_inf                  2
sort /tmp/sortwork/,8192                      3

Explanation

Specifies the input data file and error information file.

Specifies the index identifier (INDEX1) and the name of the index information file (/load/index_inf).

Specifies the name of the sort work directory.

(9) Use the pdload command to create an index in batch mode (execute batch index creation with loading of no data items)

pdload TABLE1 /pdload/load01

Explanation

The index (INDEX1) is to be created in the batch mode with loading of no data items. The -i option is omitted in order to execute in the batch index creation mode.

TABLE1: Specifies the name of the table for which data loading is to be executed.

/pdrorg/load01: Specifies the name of the control statements file for the pdload command created in step (8).

(10) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

(11) Use the pdrels command to release RDAREA2 from shutdown status

pdrels -r RDAREA2

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

An RDAREA storing a plug-in index can also be reinitialized in the same manner in order to increase its size.

15.4.4 Example 3 (LOB column is defined)

In this example, a user RDAREA (RDAREA1) is reinitialized and, at the same time, the capacity of the RDAREA is increased.

The LOB column structure base table of a table (TABLE1) is stored in RDAREA1.

The LOB data is stored in a user LOB RDAREA (RDAREA2).

An index (INDEX1) is defined for TABLE1; this index is stored in a different user RDAREA (RDAREA3).

Procedure

Use the pdfstatfs command to determine if the HiRDB file system area has free space.

Prepare a HiRDB file system area.

Use the pdhold command to shut down RDAREA1 and RDAREA2.

Use the pdcopy command to back up data.

Create a control statements file for the pdrorg command.

Use the pdrorg command to unload the data from TABLE1.

Use the pdclose command to close RDAREA1.

Create a control statements file for the pdmod command.

Use the pdmod command to reinitialize (increase the size of) RDAREA1.

Use the pdopen command to open RDAREA1.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reload data for TABLE1.

Use the pdcopy command to back up data.

Use the pdrels command to release RDAREA1 and RDAREA2 from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

(2) Prepare a HiRDB file system area

(3) Use the pdhold command to shut down RDAREA1 and RDAREA2

(4) Use the pdcopy command to back up data

(5) Create the control statements file for the pdrorg command

(6) Use the pdrorg command to unload the data from TABLE1

(7) Use the pdclose command to close RDAREA1

(8) Create the control statements file for the pdmod command

(9) Use the pdmod command to reinitialize (increase the size of) RDAREA1

(10) Use the pdopen command to open RDAREA1

(11) Create the control statements file for the pdrorg command

(12) Use the pdrorg command to reload data for TABLE1

(13) Use the pdcopy command to back up data

(14) Use the pdrels command to release RDAREA1 and RDAREA2 from shutdown status

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

pdfstatfs /rdarea/area01

(2) Prepare a HiRDB file system area

Assume you determined in step (1) that the HiRDB files system area has no free space. In order to increase the size of the RDAREA when you reinitialize it, you must use one of the following methods to prepare a HiRDB file system area:

Allocate a new HiRDB file system area that is larger than the existing HiRDB file system area.

Allocate a new HiRDB file system area in addition to the existing HiRDB file system area.

Expand the existing HiRDB file system area.

This example uses method 1 to prepare a HiRDB file system area.

pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area02

(3) Use the pdhold command to shut down RDAREA1 and RDAREA2

pdhold -r RDAREA1,RDAREA2

(4) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(5) Create the control statements file for the pdrorg command

A control statements file containing the pdrorg command's unload statement (/pdrorg/unld01) is created. The following are the contents of the control statements file:

unload /unld/unldfile1

Explanation

Specifies the name of the unload file.

(6) Use the pdrorg command to unload the data from TABLE1

pdrorg -k unld -j -t TABLE1 /pdrorg/unld01

Explanation

-k: Specifies unld in order to unload.

-j: Specifies that the table to be unloaded contains a LOB column.

-t: Specifies the name of the table to be unloaded.

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command created in step (5).

(7) Use the pdclose command to close RDAREA1

pdclose -r RDAREA1

(8) Create the control statements file for the pdmod command

A control statements file that contains the pdmod command's initialize rdarea statement (/pdmod/init01) is created. The following are the contents of the control statements file:

initialize rdarea RDAREA1                               1
  with reconstruction                                  2
  file name "/rdarea/area02/file01"                    3
     initial 3000 segments;                            4

Explanation

The newly created HiRDB file system area is allocated for RDAREA1.

Specifies the RDAREA (RDAREA1) to be reinitialized.

Because the file structure is being changed from what it was before reinitialization, specify with reconstruction.

Specifies the HiRDB file that is to constitute the RDAREA.

Specifies the number of segments for the HiRDB file.

(9) Use the pdmod command to reinitialize (increase the size of) RDAREA1

pdmod -a /pdmod/init01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (8).

(10) Use the pdopen command to open RDAREA1

pdopen -r RDAREA1

(11) Create the control statements file for the pdrorg command

A control statements file containing the pdrorg command's unload, index and sort statements (/pdrorg/reld01) is created. The following are the contents of the control statements file:

unload /unld/unldfile                        1
index INDEX1 /unld/index_inf                 2
sort /tmp/sortwork/,8192                     3

Explanation

Specifies the name of the unload file.

Specifies the index identifier (INDEX1) and the name of the index information file (/unld/index_inf).

Specifies the name of the sort work directory.

(12) Use the pdrorg command to reload data for TABLE1

pdrorg -k reld -j -t TABLE1 /pdrorg/reld01

Explanation

To create the index (INDEX1) at the same time, the -i option is omitted in order to execute in the batch index creation mode.

-k: Specifies reld in order to reload.

-j: Specifies that the table to be reloaded contains a LOB column.

-t: Specifies the name of the table to be reloaded.

/pdrorg/reld01: Specifies the name of the control statements file for the pdrorg command created in step (11).

(13) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

(14) Use the pdrels command to release RDAREA1 and RDAREA2 from shutdown status

pdrels -r RDAREA1,RDAREA2

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.4.5 Example 4 (LOB column is defined)

In this example, a user LOB RDAREA (RDAREA2) is reinitialized and, at the same time, the capacity of the RDAREA is increased.

The LOB column structure base table of a table (TABLE1) is stored in RDAREA1.

The LOB data is stored in a user LOB RDAREA (RDAREA2).

Procedure

Use the pdfstatfs command to determine if the HiRDB file system area has free space.

Prepare a HiRDB file system area.

Use the pdhold command to shut down RDAREA1 and RDAREA2.

Use the pdcopy command to back up data.

Create a control statements file for the pdrorg command.

Use the pdrorg command to unload the data from TABLE1.

Use the pdclose command to close RDAREA2.

Create a control statements file for the pdmod command.

Use the pdmod command to reinitialize (increase the size of) RDAREA2.

Use the pdopen command to open RDAREA2.

Use the pdrorg command to reload data for TABLE1.

Use the pdcopy command to back up data.

Use the pdrels command to release RDAREA1 and RDAREA2 from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

(2) Prepare a HiRDB file system area

(3) Use the pdhold command to shut down RDAREA1 and RDAREA2

(4) Use the pdcopy command to back up data

(5) Create the control statements file for the pdrorg command

(6) Use the pdrorg command to unload LOB data

(7) Use the pdclose command to close RDAREA2

(8) Create the control statements file for the pdmod command

(9) Use the pdmod command to reinitialize (increase the size of) RDAREA2

(10) Use the pdopen command to open RDAREA2

(11) Use the pdrorg command to reload data of TABLE1

(12) Use the pdcopy command to back up data

(13) Use the pdrels command to release RDAREA1 and RDAREA2 from shutdown status

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

pdfstatfs /rdarea/area01

(2) Prepare a HiRDB file system area

Assume you determined in step (1) that the HiRDB files system area has no free space. In order to increase the size of the RDAREA when you reinitialize it, you must use one of the following methods to prepare a HiRDB file system area:

Allocate a new HiRDB file system area that is larger than the existing HiRDB file system area.

Allocate a new HiRDB file system area in addition to the existing HiRDB file system area.

Expand the existing HiRDB file system area.

This example uses method 1 to prepare a HiRDB file system area.

pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area02

(3) Use the pdhold command to shut down RDAREA1 and RDAREA2

pdhold -r RDAREA1,RDAREA2

(4) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(5) Create the control statements file for the pdrorg command

A control statements file containing the pdrorg command's unload statement (/pdrorg/unld01) is created. The following are the contents of the control statements file:

unload /unld/unldfile

Explanation

Specifies the name of the unload file.

(6) Use the pdrorg command to unload LOB data

pdrorg -k unld -j -t TABLE1 /pdrorg/unld01

Explanation

-k: Specifies unld in order to unload.

-j: Specifies that the table to be unloaded contains a LOB column.

-t: Specifies the name of the table to be unloaded.

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command created in step (5).

(7) Use the pdclose command to close RDAREA2

pdclose -r RDAREA2

(8) Create the control statements file for the pdmod command

A control statements file that contains the pdmod command's initialize rdarea statement (/pdmod/init01) is created. The following are the contents of the control statements file:

initialize rdarea RDAREA2                               1
  with reconstruction                                  2
  file name "/rdarea/area02/file01"                    3
     initial 3000 segments;                            4

Explanation

The newly created HiRDB file system area is allocated for RDAREA2.

Specifies the RDAREA to be reinitialized (RDAREA2).

Because the file structure is being changed from what it was before reinitialization, specify with reconstruction.

Specifies the HiRDB file that is to constitute the RDAREA.

Specifies the number of segments for the HiRDB file.

(9) Use the pdmod command to reinitialize (increase the size of) RDAREA2

pdmod -a /pdmod/init01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (8).

(10) Use the pdopen command to open RDAREA2

pdopen -r RDAREA2

(11) Use the pdrorg command to reload data of TABLE1

pdrorg -k reld -j -t TABLE1 /pdrorg/unld01

Explanation

-k: Specifies reld in order to reload.

-j: Specifies that the table to be reloaded contains a LOB column.

-t: Specifies the name of the table to be reloaded.

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command created in step (5).

(12) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

(13) Use the pdrels command to release RDAREA1 and RDAREA2 from shutdown status

pdrels -r RDAREA1,RDAREA2

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.4.6 Example 5 (abstract data type is defined)

In this example, a user RDAREA (RDAREA1) is reinitialized and, at the same time, the capacity of the RDAREA is increased.

RDAREA1 contains the abstract data type column structure base table of a table (TABLE1). The abstract data type provided by the plug-in (SGMLTEXT type) is defined in TABLE1.

The SGML TEXT data is stored in a user LOB RDAREA (RDAREA2).

The plug-in index is stored in a user LOB RDAREA (RDAREA3).

Procedure

Use the pdfstatfs command to determine if the HiRDB file system area has free space.

Prepare a HiRDB file system area.

Use the pdhold command to shut down RDAREA1 and RDAREA2.

Use the pdcopy command to back up data.

Create a control statements file for the pdrorg command.

Use the pdrorg command to unload the data from TABLE1.

Use the pdclose command to close RDAREA1.

Create a control statements file for the pdmod command.

Use the pdmod command to reinitialize (increase the size of) RDAREA1.

Use the pdopen command to open RDAREA1.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reload data for TABLE1.

Use the pdcopy command to back up data.

Use the pdrels command to release RDAREA1 and RDAREA2 from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

(2) Prepare a HiRDB file system area

(3) Use the pdhold command to shut down RDAREA1 and RDAREA2

(4) Use the pdcopy command to back up data

(5) Create the control statements file for the pdrorg command

(6) Use the pdrorg command to unload data from TABLE1

(7) Use the pdclose command to close RDAREA1

(8) Create the control statements file for the pdmod command

(9) Use the pdmod command to reinitialize (extend the size of) RDAREA1

(10) Use the pdopen command to open RDAREA1

(11) Create the control statements file for the pdrorg command

(12) Use the pdrorg command to reload data into TABLE1

(13) Use the pdcopy command to back up data

(14) Use the pdrels command to release shutdown status of RDAREA1 and RDAREA2

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

pdfstatfs /rdarea/area01

(2) Prepare a HiRDB file system area

Assume you determined in step (1) that the HiRDB files system area has no free space. In order to increase the size of the RDAREA when you reinitialize it, you must use one of the following methods to prepare a HiRDB file system area:

Allocate a new HiRDB file system area that is larger than the existing HiRDB file system area.

Allocate a new HiRDB file system area in addition to the existing HiRDB file system area.

Expand the existing HiRDB file system area.

This example uses method 1 to prepare a HiRDB file system area.

pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area02

(3) Use the pdhold command to shut down RDAREA1 and RDAREA2

pdhold -r RDAREA1,RDAREA2

(4) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(5) Create the control statements file for the pdrorg command

A control statements file (/pdrorg/unld01) is created for the unload statement of the pdrorg command. The following are the contents of the control statements file:

unload /unld/unldfile1

Explanation

Specifies the name of the unload file.

(6) Use the pdrorg command to unload data from TABLE1

pdrorg -k unld -j -t TABLE1 /pdrorg/unld01

Explanation

-k: Specifies unld for unloading.

-j: Specifies that one of the following types of tables is to be unloaded:

Table containing a LOB column

Table in which is defined an abstract data type with the LOB attribute

-t: Specifies the name of the table that is to be unloaded.

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command created in step (5).

(7) Use the pdclose command to close RDAREA1

pdclose -r RDAREA1

(8) Create the control statements file for the pdmod command

A control statements file (/pdmod/init01) is created for the initialize rdarea statement of the pdmod command. The following are the contents of the control statements file:

initialize rdarea RDAREA1                               1
  with reconstruction                                  2
  file name "/rdarea/area02/file01"                    3
     initial 3000 segments;                            4

Explanation

The newly created HiRDB file system area is allocated for RDAREA1.

Specifies the RDAREA (RDAREA1) that is to be reinitialized.

Because the file structure is being changed from what it was before reinitialization, specify with reconstruction.

Specifies the HiRDB file comprising the RDAREA.

Specifies the number of HiRDB file segments.

(9) Use the pdmod command to reinitialize (extend the size of) RDAREA1

pdmod -a /pdmod/init01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (8).

(10) Use the pdopen command to open RDAREA1

pdopen -r RDAREA1

(11) Create the control statements file for the pdrorg command

A control statements file (/pdrorg/reld01) is created for the unload, index, and sort statements of the pdrorg command. The following are the contents of the control statements file:

unload /unld/unldfile                      1
index INDEX1 /unld/index_inf               2
sort /tmp/sortwork/,8192                   3

Explanation

Specifies the name of the unload log file.

Specifies an index identifier (INDEX1) and the name of the index information file (/unld/index_inf).

Specifies the name of the work directory for sorting.

(12) Use the pdrorg command to reload data into TABLE1

pdrorg -k reld -j -t TABLE1 /pdrorg/reld01

Explanation

To also create the index (INDEX1) at the same time, the -i option is omitted and the index is created in the batch mode.

-k: Specifies reld for reloading.

-j: Specifies that one of the following types of tables is to be reloaded:

Table containing a LOB column

Table in which is defined an abstract data type with the LOB attribute

-t: Specifies the name of the table that is to be reloaded.

/pdrorg/reld01: Specifies the name of the control statements file for the pdrorg command created in step (11).

(13) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

(14) Use the pdrels command to release shutdown status of RDAREA1 and RDAREA2

pdrels -r RDAREA1,RDAREA2

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.4.7 Example 6 (abstract data type is defined)

In this example, a user LOB RDAREA (RDAREA2) is reinitialized and, at the same time, the capacity of the RDAREA is increased.

RDAREA1 contains the abstract data type column structure base table of a table (TABLE1). The abstract data type provided by the plug-in (SGMLTEXT type) is defined in TABLE1.

The SGML TEXT data is stored in a user LOB RDAREA (RDAREA2).

The plug-in index is stored in a user LOB RDAREA (RDAREA3).

Procedure

Use the pdfstatfs command to determine if the HiRDB file system area has free space.

Prepare a HiRDB file system area.

Use the pdhold command to shut down RDAREA1 and RDAREA2.

Use the pdcopy command to back up data.

Create a control statements file for the pdrorg command.

Use the pdrorg command to unload the data from TABLE1.

Use the pdclose command to close RDAREA2.

Create a control statements file for the pdmod command.

Use the pdmod command to reinitialize (increase the size of) RDAREA2.

Use the pdopen command to open RDAREA2.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reload data for TABLE1.

Use the pdcopy command to back up data.

Use the pdrels command to release RDAREA1 and RDAREA2 from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

(2) Prepare a HiRDB file system area

(3) Use the pdhold command to shut down RDAREA1 and RDAREA2

(4) Use the pdcopy command to back up data

(5) Create the control statements file for the pdrorg command

(6) Use the pdrorg command to unload data from TABLE1

(7) Use the pdclose command to close RDAREA2

(8) Create the control statements file for the pdmod command

(9) Use the pdmod command to reinitialize (extend the size of) RDAREA2

(10) Use the pdopen command to open RDAREA2

(11) Create the control statements file for the pdrorg command

(12) Use the pdrorg command to reload data into TABLE1

(13) Use the pdcopy command to back up data

(14) Use the pdrels command to release shutdown status of RDAREA1 and RDAREA2

(1) Use the pdfstatfs command to determine if the HiRDB file system area has free space

pdfstatfs /rdarea/area01

(2) Prepare a HiRDB file system area

Assume you determined in step (1) that the HiRDB files system area has no free space. In order to increase the size of the RDAREA when you reinitialize it, you must use one of the following methods to prepare a HiRDB file system area:

Allocate a new HiRDB file system area that is larger than the existing HiRDB file system area.

Allocate a new HiRDB file system area in addition to the existing HiRDB file system area.

Expand the existing HiRDB file system area.

This example uses method 1 to prepare a HiRDB file system area.

pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area02

(3) Use the pdhold command to shut down RDAREA1 and RDAREA2

pdhold -r RDAREA1,RDAREA2

(4) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(5) Create the control statements file for the pdrorg command

A control statements file (/pdrorg/unld01) is created for the unload statement of the pdrorg command. The following are the contents of the control statements file:

unload /unld/unldfile

Explanation

Specifies the name of the unload file.

(6) Use the pdrorg command to unload data from TABLE1

pdrorg -k unld -j -t TABLE1 /pdrorg/unld01

Explanation

-k: Specifies unld for unloading.

-j: Specifies that one of the following types of tables is to be unloaded:

Table containing a LOB column

Table in which an abstract data type with the LOB attribute is defined

-t: Specifies the name of the table that is to be unloaded.

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command created in step (5).

(7) Use the pdclose command to close RDAREA2

pdclose -r RDAREA2

(8) Create the control statements file for the pdmod command

A control statements file (/pdmod/init01) is created for the initialize rdarea statement of the pdmod command. The following are the contents of the control statements file:

initialize rdarea RDAREA2                               1
  with reconstruction                                  2
  file name "/rdarea/area02/file01"                    3
     initial 3000 segments;                            4

Explanation

The newly created HiRDB file system area is allocated for RDAREA2.

Specifies the RDAREA (RDAREA2) that is to be reinitialized.

Because the file structure is being changed from what it was before reinitialization, specify with reconstruction.

Specifies the HiRDB file comprising the RDAREA.

Specifies the number of HiRDB file segments.

(9) Use the pdmod command to reinitialize (extend the size of) RDAREA2

pdmod -a /pdmod/init01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (8).

(10) Use the pdopen command to open RDAREA2

pdopen -r RDAREA2

(11) Create the control statements file for the pdrorg command

A control statements file (/pdrorg/reld01) is created for the unload, index, and sort statements of the pdrorg command. The following are the contents of the control statements file:

unload /unld/unldfile                       1
index INDEX1 /unld/index_inf                2
sort /tmp/sortwork/,8192                    3

Explanation

Specifies the name of the unload log file.

Specifies an index identifier (INDEX1) and the name of the index information file (/unld/index_inf).

Specifies the name of the work directory for sorting.

(12) Use the pdrorg command to reload data into TABLE1

pdrorg -k reld -j -t TABLE1 /pdrorg/unld01

Explanation

-k: Specifies reld for reloading.

-j: Specifies that one of the following types of tables is to be reloaded:

Table containing a LOB column

Table in which an abstract data type with the LOB attribute is defined

-t: Specifies the name of the table that is to be reloaded.

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command created in step (11).

(13) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

(14) Use the pdrels command to release shutdown status of RDAREA1 and RDAREA2

pdrels -r RDAREA1,RDAREA2

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.4.8 Example 7 (using a UAP, all RDAREAs associated with a table are reinitialized, and data is recovered)

In this example, two user RDAREAs (RDAREA1 and RDAREA2) and three user LOB RDAREAs (RDAREA3, RDAREA4, and RDAREA5) are reinitialized and, at the same time, the capacities of the RDAREAs are increased.

A table (TABLE1) with a LOB column structure base table and an abstract data type column structure base table is stored in RDAREA1. A plug-in provided abstract data type (SGMLTEXT type) is defined for TABLE1.

An index (INDEX1) is defined for TABLE1. This index is stored in a user RDAREA (RDAREA2).

LOB data is stored in a user LOB RDAREA (RDAREA3).

SGMLTEXT data is stored in a user LOB RDAREA (RDAREA4).

The plug-in index is stored in a user LOB area (RDAREA5).

Procedure

Use the pdfstatfs command to determine if the HiRDB file system areas have free space.

Prepare the HiRDB file system areas.

Use the pdhold command to shut down RDAREA1 to RDAREA5.

Use the pdcopy command to back up data.

Create a control statements file for the pdrorg command.

Use the pdrorg command to unload the data from TABLE1.

Use the pdclose command to close RDAREA1 to RDAREA5.

Create a control statements file for the pdmod command.

Use the pdmod command to reinitialize RDAREA1 to RDAREA5.

Use the pdopen command to open RDAREA1 to RDAREA5.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reload data for TABLE1.

Use the pdcopy command to back up data.

Use the pdrels command to release RDAREA1 to RDAREA5 from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Use the pdfstatfs command to determine if the HiRDB file system areas have free space

(2) Prepare the HiRDB file system areas

(3) Use the pdhold command to shut down RDAREA1 to RDAREA5

(4) Use the pdcopy command to back up data

(5) Create the control statements file for the pdrorg command

(6) Use the pdrorg command to unload data from TABLE1

(7) Use the pdclose command to close RDAERA1 to RDAREA5

(8) Create the control statements file for the pdmod command

(9) Use the pdmod command to reinitialize RDAREA1 to RDAREA5

(10) Use the pdopen command to open RDAREA1 to RDAREA5

(11) Create the control statements file for the pdrorg command

(12) Use the pdrorg command to reload data into TABLE1

(13) Use the pdcopy command to back up data

(14) Use the pdrels command to release RDAREA1 to RDAREA5 from shutdown status

(1) Use the pdfstatfs command to determine if the HiRDB file system areas have free space

pdfstatfs /rdarea/area01
pdfstatfs /rdarea/area02
pdfstatfs /rdarea/area03
pdfstatfs /rdarea/area04
pdfstatfs /rdarea/area05

Check all the HiRDB files system areas in the RDAREAs to be initialized.

(2) Prepare the HiRDB file system areas

Assume you determined in step (1) that the HiRDB files system areas have no free space. In order to increase the sizes of the RDAREAs when you reinitialize them, you must use one of the following methods to prepare the HiRDB file system areas:

Allocate new HiRDB file system areas that are larger than the existing HiRDB file system areas.

Allocate new HiRDB file system areas in addition to the existing HiRDB file system areas.

Expand the existing HiRDB file system areas.

This example uses method 1 to prepare the HiRDB file system areas.

pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area11
pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area12
pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area13
pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area14
pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area15

(3) Use the pdhold command to shut down RDAREA1 to RDAREA5

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5

(4) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(5) Create the control statements file for the pdrorg command

A control statements file (/pdrorg/unld01) is created for the unload statement of the pdrorg command. The following are the contents of the control statements file:

unload /unld/unldfile

Explanation

Specifies the name of the unload file.

(6) Use the pdrorg command to unload data from TABLE1

pdrorg -k unld -j -t TABLE1 /pdrorg/unld01

Explanation

-k: Specifies unld for unloading.

-j: Specifies that one of the following types of tables is to be unloaded:

Table containing a LOB column

Table in which an abstract data type with the LOB attribute is defined

-t: Specifies the name of the table that is to be unloaded.

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command created in step (5).

(7) Use the pdclose command to close RDAERA1 to RDAREA5

pdclose -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5

(8) Create the control statements file for the pdmod command

A control statements file (/pdmod/init01) is created for the initialize rdarea statement of the pdmod command. The following are the contents of the control statements file:

initialize rdarea RDAREA1                               1
  with reconstruction                                  2
  file name "/rdarea/area11/file01"                    3
     initial 3000 segments;                            4
initialize rdarea RDAREA2
  with reconstruction
  file name "/rdarea/area12/file01"
     initial 3000 segments;
initialize rdarea RDAREA3
  with reconstruction
  file name "/rdarea/area13/file01"
     initial 3000 segments;
initialize rdarea RDAREA4
  with reconstruction
  file name "/rdarea/area14/file01"
      initial 3000 segments;
initialize rdarea RDAREA5
  with reconstruction
  file name "/rdarea/area15/file01"
      initial 3000 segments;

Explanation

The newly created HiRDB file system areas are allocated for the RDAREAs being reinitialized.

Specifies the RDAREAs being initialized.

Because the file structure is being changed from what it was before reinitialization, specify with reconstruction.

Specifies the HiRDB file comprising the RDAREA.

Specifies the number of HiRDB file segments.

(9) Use the pdmod command to reinitialize RDAREA1 to RDAREA5

pdmod -a /pdmod/init01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (8).

Reference note

When RDAREA1 is reinitialized, the KFPX14255-W, KFPX24231-W, and KFPX24242-W messages are issued, warning of an invalid RDAREA. However, because you are reinitializing RDAREA2 through RDAREA5 at the same time, this does not pose a problem. In addition, when RDAREA2, RDAREA4, and RDAREA5 are being reinitialized, the abstract data type with the LOB attribute is denied access to the index, because the index is incomplete. However, reloading the data in step (12) releases these RDAREAs, so this does not pose a problem either.

(10) Use the pdopen command to open RDAREA1 to RDAREA5

pdopen -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5

(11) Create the control statements file for the pdrorg command

A control statements file (/pdrorg/reld01) is created for the unload, index, and sort statements of the pdrorg command. The following are the contents of the control statements file:

unload /unld/unldfile                      1
index INDEX1 /unld/index_inf               2
sort /tmp/sotwork/,8192                    3

Explanation

Specifies the name of the unload log file.

Specifies an index identifier (INDEX1) and the name of the index information file (/unld/index_inf).

Specifies the name of the work directory for sorting.

(12) Use the pdrorg command to reload data into TABLE1

pdrorg -k reld -j -t TABLE1 /pdrorg/reld01

Explanation

-k: Specifies reld for reloading.

-j: Specifies that one of the following types of tables is to be reloaded:

Table containing a LOB column

Table in which an abstract data type with the LOB attribute is defined

-t: Specifies the name of the table that is to be reloaded.

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command created in step (11).

(13) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

(14) Use the pdrels command to release RDAREA1 to RDAREA5 from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.4.9 Example 8 (using a UAP, all RDAREAs associated with a table are reinitialized, and data is recovered)

In this example, two user RDAREAs (RDAREA1 and RDAREA2) and three user LOB RDAREAs (RDAREA3, RDAREA4, and RDAREA5) are reinitialized and, at the same time, the capacities of the RDAREAs are increased.

A table (TABLE1) with a LOB column structure base table and an abstract data type column structure base table is stored in RDAREA1. A plug-in provided abstract data type (SGMLTEXT type) is defined for TABLE1.

An index (INDEX1) is defined for TABLE1. This index is stored in a user RDAREA (RDAREA2).

LOB data is stored in a user LOB RDAREA (RDAREA3).

SGMLTEXT data is stored in a user LOB RDAREA (RDAREA4).

The plug-in index is stored in a user LOB area (RDAREA5).

Procedure

Use the pdfstatfs command to determine if the HiRDB file system areas have free space.

Prepare the HiRDB file system areas.

Use the pdhold command to shut down and close RDAREA1 to RDAREA5.

Use the pdcopy command to back up data.

Create a control statements file for the pdmod command.

Use the pdmod command to reinitialize RDAREA2 to RDAREA5.

Use the pdrels command to release RDAREA2 to RDAREA5 from shutdown status, and to place them in open status.

Create a control statements file for the pdmod command.

Use the pdmod command to reinitialize RDAREA1.

Use the pdrels command to release RDAREA1 from shutdown status, and to place it in open status.

Execute the UAP.

Use the pdcopy command to back up data.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Use the pdfstatfs command to determine if the HiRDB file system areas have free space

(2) Prepare the HiRDB file system areas

(3) Use the pdhold command to shut down and close RDAREA1 to RDAREA5

(4) Use the pdcopy command to back up data

(5) Create the control statements file for the pdmod command

(6) Use the pdmod command to reinitialize RDAREA2 to RDAREA5

(7) Use the pdrels command to release RDAREA2 to RDAREA5 from shutdown status and place them in open status

(8) Create the control statements file for the pdmod command

(9) Use the pdmod command to reinitialize RDAREA1

(10) Use the pdrels command to release RDAREA1 from shutdown status and place it in open status

(11) Execute the UAP

(12) Use the pdcopy command to back up data

(1) Use the pdfstatfs command to determine if the HiRDB file system areas have free space

pdfstatfs /rdarea/area01
pdfstatfs /rdarea/area02
pdfstatfs /rdarea/area03
pdfstatfs /rdarea/area04
pdfstatfs /rdarea/area05

Check all the HiRDB files system areas containing the RDAREAs to be initialized.

(2) Prepare the HiRDB file system areas

Assume you determined in step (1) that the HiRDB files system areas have no free space. In order to increase the sizes of the RDAREAs when you reinitialize them, you must use one of the following methods to prepare the HiRDB file system areas:

Allocate new HiRDB file system areas that are larger than the existing HiRDB file system areas.

Allocate new HiRDB file system areas in addition to the existing HiRDB file system areas.

Expand the existing HiRDB file system areas.

This example uses method 1 to prepare a HiRDB file system areas.

pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area11
pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area12
pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area13
pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area14
pdfmkfs -n 100 -l 10 -k DB -i /rdarea/area15

(3) Use the pdhold command to shut down and close RDAREA1 to RDAREA5

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5 -c

(4) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(5) Create the control statements file for the pdmod command

A control statements file (/pdmod/init01) is created for the initialize rdarea statement of the pdmod command. The following are the contents of the control statements file:

initialize rdarea RDAREA2                               1
  with reconstruction                                  2
  file name "/rdarea/area12/files01"                   3
     initial 3000 segments;                            4
initialize rdarea RDAREA3
  with reconstruction
  file name "/rdarea/area13/files01"
     initial 3000 segments;
initialize rdarea RDAREA4
  with reconstruction
  file name "/rdarea/area14/files01"
      initial 3000 segments;
initialize rdarea RDAREA5
  with reconstruction
  file name "/rdarea/area15/files01"
      initial 3000 segments;

Explanation

The newly created HiRDB file system area is allocated for the RDAREAs being reinitialized.

Specifies the RDAREAs being initialized.

Because the file structure is being changed from what it was before reinitialization, specify with reconstruction.

Specifies the HiRDB file comprising the RDAREA.

Specifies the number of HiRDB file segments.

(6) Use the pdmod command to reinitialize RDAREA2 to RDAREA5

pdmod -a /pdmod/init01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (5).

Reference note

When RDAREA2, RDAREA4, and RDAREA5 are reinitialized, the abstract data type with the LOB attribute is denied access to the index, because the index is incomplete. However, reinitializing RDAREA1 in step (9) releases these RDAREAs, so this does not pose a problem.

(7) Use the pdrels command to release RDAREA2 to RDAREA5 from shutdown status and place them in open status

pdrels -r RDAREA2,RDAREA3,RDAREA4,RDAREA5 -o

(8) Create the control statements file for the pdmod command

A control statements file (/pdmod/init02) is created for the initialize rdarea statement of the pdmod command. The following are the contents of the control statements file:

initialize rdarea RDAREA1                               1
  with reconstruction                                  2
  file name "/rdarea/area11/file01"                    3
     initial 3000 segments;                            4

Explanation

The newly created HiRDB file system area is allocated for RDAREA1.

Specifies the RDAREA (RDAREA2) that is to be reinitialized.

Because the file structure is being changed from what it was before reinitialization, specify with reconstruction.

Specifies the HiRDB file comprising the RDAREA.

Specifies the number of HiRDB file segments.

(9) Use the pdmod command to reinitialize RDAREA1

pdmod -a /pdmod/init02

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (8).

(10) Use the pdrels command to release RDAREA1 from shutdown status and place it in open status

pdrels -r RDAREA1 -o

(11) Execute the UAP

Execute the UAP that inserts data into TABLE1 to recover the data.

(12) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

When an RDAREA is reinitialized, other RDAREAs are also updated as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs as shown in section 6.3. In this example, all RDAREAs are backed up.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.4.10 Example 9 (changing the disk layout for RDAREAs)

In this example, two user RDAREAs (RDAREA1 and RDAREA2) and three user LOB RDAREAs (RDAREA3, RDAREA4, and RDAREA5) are initialized, and the disk layout for the RDAREAs is changed from /rdarea to /rdarea2.

RDAREA1 stores the LOB column structure base table and abstract data type column structure base table of the table TABLE1. An abstract data type (SGMLTEXT type) provided by a plug-in is defined for TABLE1.

An index (INDEX1) is defined for TABLE1. This index is stored in a user RDAREA (RDAREA2).

LOB data is stored in a user LOB RDAREA (RDAREA3).

SGMLTEXT data is stored in a user LOB RDAREA (RDAREA4).

The plug-in index is stored in a user LOB RDAREA (RDAREA5).

Procedure

Prepare a HiRDB file system area.

Use the pdhold command to shut down RDAREA1 through RDAREA5.

Use the pdcopy command to back up data.

Create a control statements file for the pdrorg command.

Use the pdrorg command to unload the data from TABLE1.

Use the pdclose command to close RDAREA1 through RDAREA5.

Create a control statements file for the pdmod command.

Use the pdmod command to reinitialize RDAREA1 through RDAREA5.

Use the pdopen command to open RDAREA1 through RDAREA5.

Create a control statements file for the pdrorg command.

Use the pdrorg command to reload data for TABLE1.

Use the pdcopy command to back up data.

Use the pdrels command to release RDAREA1 through RDAREA5 from shutdown status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Prepare a HiRDB file system area

(2) Use the pdhold command to shut down RDAREA1 through RDAREA5

(3) Use the pdcopy command to back up data

(4) Create a control statements file for the pdrorg command

(5) Use the pdrorg command to unload the data from TABLE1

(6) Use the pdclose command to close RDAREA1 through RDAREA5

(7) Create a control statements file for the pdmod command

(8) Use the pdmod command to reinitialize RDAREA1 through RDAREA5

(9) Use the pdopen command to open RDAREA1 through RDAREA5

(10) Create a control statements file for the pdrorg command

(11) Use the pdrorg command to reload data for TABLE1

(12) Use the pdcopy command to back up data

(13) Use the pdrels command to release RDAREA1 through RDAREA5 from shutdown status

(1) Prepare a HiRDB file system area

Prepare a HiRDB file system area on the disk where the new RDAREAs are to be placed (/rdarea2).

pdfmkfs -n 100 -l 10 -k DB -i /rdarea2/area11
pdfmkfs -n 100 -l 10 -k DB -i /rdarea2/area12
pdfmkfs -n 100 -l 10 -k DB -i /rdarea2/area13
pdfmkfs -n 100 -l 10 -k DB -i /rdarea2/area14
pdfmkfs -n 100 -l 10 -k DB -i /rdarea2/area15

For the -n and -l options, specify a value that is equal to or greater than the value for the HiRDB file system area that was created on the disk (/rdarea) before the change.

(2) Use the pdhold command to shut down RDAREA1 through RDAREA5

pdhold -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5

(3) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is reinitialized, other RDAREAs are also updated, as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs, as shown in Section 6.3. In this example, all RDAREAs are backed up.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(4) Create a control statements file for the pdrorg command

A control statements file containing the pdrorg command's unload statement (/pdrorg/unld01) is created. The following are the contents of the control statements file:

unload /unld/unldfile

Explanation

The name of the unload file is specified.

(5) Use the pdrorg command to unload the data from TABLE1

pdrorg -k unld -j -t TABLE1 /pdrorg/unld01

Explanation

-k: Specifies unld in order to unload.

-j: Specifies that the following tables are to be unloaded:

Table with a LOB column

Table for which an abstract data type with the LOB attribute has been defined

-t: Specifies the name of the table to be unloaded.

/pdrorg/unld01: Specifies the name of the control statements file for the pdrorg command created in step (4).

(6) Use the pdclose command to close RDAREA1 through RDAREA5

pdclose -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5

(7) Create a control statements file for the pdmod command

A control statements file that contains the pdmod command's initialize rdarea statement (/pdmod/init01) is created. The following are the contents of the control statements file:

initialize rdarea RDAREA1                               1
  with reconstruction                                  2
  file name "/rdarea2/area11/file01"                   3
     initial 3000 segments;                            4
initialize rdarea RDAREA2
  with reconstruction
  file name "/rdarea2/area12/file01"
     initial 3000 segments;
initialize rdarea RDAREA3
  with reconstruction
  file name "/rdarea2/area13/file01"
     initial 3000 segments;
initialize rdarea RDAREA4
  with reconstruction
  file name "/rdarea2/area14/file01"
      initial 3000 segments;
initialize rdarea RDAREA5
  with reconstruction
  file name "/rdarea2/area15/file01"
      initial 3000 segments;

Explanation

The newly created HiRDB file system area is allocated for the RDAREAs that are to be reinitialized.

Specifies an RDAREA to be reinitialized.

Because the file structure is being changed from what it was before reinitialization, specify with reconstruction.

Specifies the HiRDB file that is to constitute the RDAREA. This example specifies the new disk on which the RDAREA is to be placed (/rdarea2).

Specifies the number of segments for the HiRDB file. This value must be equal to or greater than the value for the HiRDB file that had been created on the disk before the change (/rdarea).

(8) Use the pdmod command to reinitialize RDAREA1 through RDAREA5

pdmod -a /pdmod/init01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (7).

Reference note

When RDAREA1 is reinitialized, the KFPX14255-W, KFPX24231-W, and KFPX24242-W messages are issued, warning that there is an invalid RDAREA. However, because you are reinitializing RDAREA2 through RDAREA5 at the same time, this does not pose a problem. In addition, when RDAREA2, RDAREA4, and RDAREA5 are being reinitialized, the abstract data type with the LOB attribute is denied access to the index, because the index is incomplete. However, reloading the data in step (11) releases these RDAREAs, so this does not pose a problem either.

(9) Use the pdopen command to open RDAREA1 through RDAREA5

pdopen -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5

(10) Create a control statements file for the pdrorg command

A control statements file (/pdrorg/reld01) is created for the unload, index, and sort statements of the pdrorg command. The following are the contents of the control statements file:

unload /unld/unldfile                      1
index INDEX1 /unld/index_inf               2
sort /tmp/sotwork/,8192                    3

Explanation

Specifies the name of the unload file.

Specifies an index identifier (INDEX1) and the name of the index information file (/unld/index_inf).

Specifies the name of the work directory for sorting.

(11) Use the pdrorg command to reload data for TABLE1

pdrorg -k reld -j -t TABLE1 /pdrorg/reld01

Explanation

-k: Specifies reld in order to reload.

-j: Specifies that the following tables are to be reloaded:

Table with a LOB column

Table for which an abstract data type with the LOB attribute has been defined

-t: Specifies the name of the table to be reloaded.

/pdrorg/reld01: Specifies the name of the control statements file for the pdrorg command created in step (10).

(12) Use the pdcopy command to back up data

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

When an RDAREA is reinitialized, other RDAREAs are also updated, as explained in 6.3 RDAREAs to be backed up together. Therefore, you must also back up other RDAREAs, as shown in Section 6.3. In this example, all RDAREAs are backed up.

(13) Use the pdrels command to release RDAREA1 through RDAREA5 from shutdown status

pdrels -r RDAREA1,RDAREA2,RDAREA3,RDAREA4,RDAREA5

After the command has executed, you should check whether or not the execution results are correct. For details about how to check the command execution results, see the manual HiRDB Version 8 Command Reference.

15.5 Modifying an RDAREA opening trigger attribute (RDAREA modification)

Executor: HiRDB administrator

The RDAREA opening trigger attribute can be changed with the alter rdarea statement of the database structure modification utility (pdmod command).

Organization of this section

15.5.1 Before changing the RDAREA opening trigger attribute

15.5.2 Example

15.5.1 Before changing the RDAREA opening trigger attribute

Organization of this subsection

(1) RDAREA opening trigger attribute

(2) Criteria

(3) RDAREAs whose opening trigger attribute can be changed

(4) Notes

(1) RDAREA opening trigger attribute

The RDAREA opening trigger attribute refers to the time at which RDAREA open processing is executed by HiRDB.

Normally, RDAREA open processing is executed during HiRDB startup. However, as the number of RDAREAs increases, the amount of time required for HiRDB startup processing also increases. Instead, RDAREAs can be opened when they are accessed, rather than being opened during HiRDB startup processing. Thus, the RDAREA opening trigger attribute is changed. There are three triggers for opening an RDAREA, as shown in Table 15-1.

Table 15-1 RDAREA opening trigger attributes

Trigger
Initial status
Opening time
Closing time
Advantages
Disadvantages

INITIAL
Open

During HiRDB startup

During pdopen command execution

During pdclose command execution
High-speed execution from the first SQL
More time is required to start the system.

DEFER
Closed

First time RDAREA is accessed

During pdopen command execution

During pdclose command execution

High-speed system startup

High-speed processing of SQLs after the first access

More time is required to access the RDAREA for the first time.

SCHEDULE
Closed

First time RDAREA is accessed within a transaction

During pdopen command execution

During transaction termination

During pdclose command execution

High-speed system startup

Fewer open files (for DVD-RAM library devices)

More time is required to access the RDAREA for the first time by each transaction.

(2) Criteria

Initially, the RDAREA opening trigger is INITIAL. We recommend you consider changing the RDAREA opening trigger in the following cases:

HiRDB startup processing takes a long time because there is a large number of RDAREAs.

A DVD-RAM library device is being used.

Table 15-2 shows the operating procedure appropriate to each trigger.

Table 15-2 Operating procedure appropriate to each trigger

Trigger
Appropriate operating procedure

INITIAL
HiRDB file system area is opened and the RDAREA information is made resident in memory during system startup. When an RDAREA is accessed for the first time, it is also opened in that process. In this case, the RDAREA information is not re-created; therefore, high-speed operation can be achieved from the first SQL.
The initial status of RDAREAs is to be opened during system startup. This status does not change unless an operation command is entered, except for a status change to error shutdown.
This trigger should be used when no special operating procedure is employed.
When this trigger is used, a closed RDAREA cannot be accessed.

DEFER
HiRDB file system area is opened and the RDAREA information is made resident in memory when an RDAREA is accessed for the first time, not during system start. High-speed operation can be achieved for the subsequent accesses, because no processing is required on the HiRDB file system area other than open processing.
The RDAREAs' initial status during system startup is closed. Each RDAREA is opened when it is accessed for the first time. The status of RDAREAs does not change thereafter unless an operation command is entered, except for a status change to error shutdown.
Specify this attribute when you wish to avoid situations in which many HiRDB file system areas are open concurrently or you wish to reduce the time required for HiRDB startup.
When HiRDB is restarted, any RDAREAs to be recovered are opened during recovery processing.
When this trigger is used, a closed RDAREA can be accessed.

SCHEDULE
HiRDB file system area is opened and the RDAREA information is made resident in memory when an RDAREA is accessed for the first time within a transaction, without opening it during system startup. The HiRDB file system area is closed when the transaction terminates. The transaction processing workload increases because the open processing and all subsequent processing is executed the first time an RDAREA is accessed by each transaction.
The RDAREAs' initial status during system startup is closed. An RDAREA is open only while a transaction that accesses it is being processed. When the transaction terminates, all the RDAREAs opened by it are closed.
When the pdopen command is entered, an RDAREA can be kept in open status until it is placed in shutdown and closed status. Other operation commands can also be used to change the RDAREA status. When an error is detected, the RDAREA is placed in error shutdown status.
Specify this attribute when you wish to avoid situations in which many HiRDB file system areas are open concurrently or you wish to reduce the time required for HiRDB startup when a DVD-RAM library device is being used.
When HiRDB is restarted, any RDAREAs to be recovered are opened during recovery processing, and they are closed when recovery processing finishes.
When this trigger is used, a closed RDAREA can be accessed.

(3) RDAREAs whose opening trigger attribute can be changed

The opening trigger attribute can be changed for the following RDAREAs:

User RDAREAs

User LOB RDAREAs

List RDAREAs

(4) Notes

Before an RDAREA's opening trigger attribute is changed, it must be placed in shutdown and closed status with the pdhold -c command.

Before an RDAREA whose opening trigger attribute has been changed can be used, it must be released from shutdown status and placed in open status by the pdrels -o command.

The same opening trigger attribute should be set for all RDAREAs in a HiRDB file system area.

RDAREAs are not open while the standby system unit to which the rapid system switchover facility switches is in standby status. In addition, because the purpose of this facility is to minimize system switchover time, only those RDAREAs that are needed for recovery when a system is switched over are opened, while the other RDAREAs remain closed. Therefore, the RDAREA opening trigger on a standby system is not the INITIAL attribute. RDAREAs set with the INITIAL attribute are changed to the DEFER attribute.

Because the purpose of the standbyless system switchover facility is to minimize system switchover time, this facility opens only those RDAREAs that are needed for recovery when a system is switched over, while the other RDAREAs remain closed. Therefore, the opening trigger of the RDAREAs on the alternate BES or the alternate portion is as follows:
When system switchover occurs, the opening trigger for RDAREAs in the alternate portion is the SCHEDULE attribute.
When returning the system to the normal BES after having recovered from the error, the opening trigger for RDAREAs set with the INITIAL or DEFER attribute is the DEFER attribute. The opening trigger for RDAREAs set with the SCHEDULE attribute remains unchanged.

Table 15-3 indicates the accessibility of UAP RDAREAs according to the open attribute.

Table 15-3 Accessibility of UAP RDAREAs according to the open attribute

Opening trigger for RDAREA | Status of RDAREA | RDAREA accessible?
INITIAL | Not shutdown | Open | Yes
Closed | No
Command shutdown | Open | No
Closed | No
Reference-possible hold | Open | Some¹
Closed | No
Reference-possible backup hold | Open | Some¹
Updatable backup hold | Open | Yes
Error shutdown | Open | No
Closed | No
No-log hold | Open | Some²
Closed | No
Initialization hold | Open | No³
Closed | No³
Online reorganization hold | Open | Some⁴
Closed | Some⁴
DEFER or SCHEDULE | Not shutdown | Open | Yes
Closed | Yes
Command shutdown | Open | No
Closed | No
Reference-possible hold | Open | Some¹
Closed | Some¹
Reference-possible backup hold | Open | Some¹
Closed | No
Updatable backup hold | Open | No
Closed | Yes
Error shutdown | Open | No
Closed | No
No-log hold | Open | Some²
Closed | Some²
Initialization hold | Open | No³
Closed | No³
Online reorganization hold | Open | Some⁴
Closed | Some⁴

Legend:

Yes: Accessible

Some: Some SQL code accessible

No: Not accessible

¹ Only reference SQL can be accessed.

² Only PURGE TABLE can be executed.

³ Placed in lock-release wait status

⁴ Other than the following, only SQL statements that access a current RDAREA while in the log acquisition mode can be executed:

CREATE TABLE

CREATE INDEX

DROP TABLE

DROP INDEX

DROP SCHEMA

ALTER TABLE

PURGE TABLE

LOCK

15.5.2 Example

This example changes the opening trigger attribute for user RDAREAs (RDAREA1 to RDAREA3) from INITIAL to SCHEDULE; it also changes the opening trigger attribute for all user RDAREAs other than RDAREA1 to RDAREA3 from INITIAL to DEFER. RDAREA1 to RDAREA3 are located in the same HiRDB file system area.

Procedure

Terminate HiRDB normally.

Modify the system common definitions.

Start HiRDB normally.

Use the pdhold command to place the RDAREAs in shutdown and closed status to change their opening trigger attributes.

Create a control statements file for the pdmod command.

Use the pdmod command to change the RDAREAs' opening trigger.

Use the pdrels command to release the shutdown status of RDAREAs whose opening trigger attributes were changed, and then place them in open status.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Terminate HiRDB normally

(2) Modify the system common definition

(3) Start HiRDB normally

(4) Use the pdhold command to place RDAREAs in shutdown and closed status to change their opening trigger attributes

(5) Create the control statements file for the pdmod command

(6) Use the pdmod command to change the RDAREAs' opening trigger

(7) Use the pdrels command to release shutdown status of RDAREAs whose opening trigger attributes were changed, then place them in open status

(1) Terminate HiRDB normally

pdstop

If you were to use the system reconfiguration command (pdchgconf command), you would not need to restart HiRDB normally in this step, because this command enables you to modify HiRDB system definitions while HiRDB is running. Note that HiRDB Advanced High Availability must be installed in order to use this command. For details about modifying HiRDB system definitions while HiRDB is running, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

(2) Modify the system common definition

The following specifications are made in the system common definition:

               :
set pd_rdarea_open_attribute_use = Y                      1
set pd_rdarea_open_attribute = DEFER                      2
               :

Explanation

Specifies that DEFER or SCHEDULE is to be used as the opening trigger attribute for RDAREAs.

Specifies DEFER as the default opening trigger attribute for all RDAREAs.

(3) Start HiRDB normally

pdstart

(4) Use the pdhold command to place RDAREAs in shutdown and closed status to change their opening trigger attributes

pdhold -r RDAREA1,RDAREA2,RDAREA3 -c

(5) Create the control statements file for the pdmod command

A control statements file that contains the pdmod command's alter rdarea statement (/pdmod/alter01) is created. The following are the contents of the control statements file:

alter rdarea RDAREA01 open attribute SCHEDULE;
alter rdarea RDAREA02 open attribute SCHEDULE;
alter rdarea RDAREA03 open attribute SCHEDULE;

Explanation

The opening trigger attributes for RDAREA1 to RDAREA3 are changed from DEFER to SCHEDULE.

(6) Use the pdmod command to change the RDAREAs' opening trigger

pdmod -a /pdmod/alter01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (5).

Reference note

The opening trigger specification does not take effect immediately when RDAREA is added by the database structure modification utility; immediately after adding the RDAREA, the INITIAL attribute takes effect. To enable the opening trigger specification to take effect, you must first terminate HiRDB, and then execute a restart. The opening trigger will then take effect regardless of the startup mode.

(7) Use the pdrels command to release shutdown status of RDAREAs whose opening trigger attributes were changed, then place them in open status

pdrels -r RDAREA1,RDAREA2,RDAREA3 -o

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.6 Deleting an RDAREA

Executor: HiRDB administrator

An RDAREA can be deleted by the remove rdarea statement of the database structure modification utility (pdmod command).

Organization of this section

15.6.1 Before deleting an RDAREA

15.6.2 Example

15.6.1 Before deleting an RDAREA

Organization of this subsection

(1) RDAREAs that can be deleted

(2) When to delete RDAREAs

(3) Notes

(4) Changing global buffer definitions

(1) RDAREAs that can be deleted

The following RDAREAs can be deleted:

User RDAREAs

User LOB RDAREAs

List RDAREAs

(2) When to delete RDAREAs

An RDAREA should be deleted under the following circumstances:

It is an existing RDAREA that is no longer needed.

It is an RDAREA that needs to be re-created.

(3) Notes

If there are any tables or indexes in an RDAREA that is to be deleted, those tables or indexes must be deleted before the RDAREA can be deleted.

Before an RDAREA is deleted, it must be placed in shutdown or error shutdown status by the pdhold command and then in closed status by the pdclose command.

(4) Changing global buffer definitions

Always change the value specified to the pdbuffer operand after you delete an RDAREA. That is, delete the RDAREA from the global buffer definition. If you do not change the value specified in the pdbuffer operand, memory utilization efficiency may deteriorate. Consider the following situations as examples:

If a deleted RDAREA is assigned to a global buffer specified with the -o option of the pdbuffer operand, another RDAREA may be allocated a global buffer that is larger than required.

If only the deleted RDAREA is assigned to the global buffer specified with the -o option of the pdbuffer operand, the unused global buffer remains resident in memory.

15.6.2 Example

This example deletes a user RDAREA named RDAREA1.

Procedure

Delete any table or index from the RDAREA to be deleted.

Use the pdhold command to place the RDAREA to be deleted in shutdown and closed status.

Create a control statements file for the pdmod command.

Use the pdmod command to delete the RDAREA.

Use the pdbufmod command to delete the global buffer.

Update the pdbuffer operand.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Delete any table or index from RDAREA to be deleted

(2) Use the pdhold command to place the RDAREA to be deleted in shutdown and closed status

(3) Create the control statements file for the pdmod command

(4) Use the pdmod command to delete the RDAREA

(5) Use the pdbufmod command to delete the global buffer

(6) Update the pdbuffer operand

(1) Delete any table or index from RDAREA to be deleted

DROP TABLE TABLE1;
DROP INDEX INDEX1;

(2) Use the pdhold command to place the RDAREA to be deleted in shutdown and closed status

pdhold -r RDAREA1 -c

(3) Create the control statements file for the pdmod command

A control statements file that contains the pdmod command's remove rdarea statement (/pdmod/remove01) is created. The following are the contents of the control statements file:

remove rdarea RDAREA1;

Explanation

The RDAREA to be deleted (RDAREA1) is specified.

(4) Use the pdmod command to delete the RDAREA

pdmod -a /pdmod/remove01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (3).

(5) Use the pdbufmod command to delete the global buffer

If you no longer need the global buffer that was allocated for the deleted RDAREA (it is allocated for no other RDAREAs), delete that global buffer.

pdbufmod -k del -a gbuf01

Explanation

-k del: Specifies that a global buffer is to be deleted.

-a: Specifies the name of the global buffer being deleted.

All the following conditions must be satisfied in order to execute the pdbufmod command:

HiRDB Advanced High Availability is installed.

The value Y is specified in the pd_dbbuff_modify operand.

(6) Update the pdbuffer operand

The global buffer deletion information becomes invalid when HiRDB is terminated normally or through planned termination. Therefore, delete the name of the deleted RDAREA from the pdbuffer operand while HiRDB is stopped.

You can use the system reconfiguration command (pdchgconf command to change the pdbuffer operand specification while HiRDB is running. Note that HiRDB Advanced High Availability must be installed in order to execute the system reconfiguration command. For details about modifying HiRDB system definitions while HiRDB is running, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.7 RDAREA automatic extension

Executor: HiRDB administrator

Organization of this section

15.7.1 Automatic extension of an RDAREA

15.7.2 Example

15.7.3 Handling space shortages in HiRDB file system areas

15.7.4 Actions to take when the number of extents reaches the maximum value

15.7.1 Automatic extension of an RDAREA

When a space shortage occurs in an RDAREA, the size of the RDAREA can be expanded by means of automatic addition of segments, provided that there is sufficient free space in the HiRDB file system area. This process is called RDAREA automatic extension. Figure 15-1 illustrates RDAREA automatic extension.

Figure 15-1 RDAREA automatic extension

A contiguous area in a HiRDB file system area is called an extent. The maximum number of extents in a HiRDB file is 24. During automatic extension, if contiguous free space can be allocated following the last allocated extent of the target HiRDB file, the number of extents does not increase. However, if non-contiguous free space is allocated, the number of extents increases. Extent information can be checked with the pdfls command.

When RDAREAs are deleted, reinitialized (allocated size is reduced or with reconstruction is specified), or combined, allocated extents are deleted or their sizes are reduced, as a result creating fragmented free spaces within the HiRDB file system. Note that if RDAREAs are added, expanded, or reinitialized in this state, multiple extents may be allocated to a single HiRDB file even if automatic extension is not executed.

Organization of this subsection

(1) RDAREAs eligible for automatic extension

(2) Setting automatic extension

(3) Notes

(1) RDAREAs eligible for automatic extension

Automatic extension can be applied to the following RDAREAs:

Data dictionary RDAREAs

User RDAREAs

Registry RDAREA

Data dictionary LOB RDAREAs

User LOB RDAREAs

Registry LOB RDAREA

(2) Setting automatic extension

The following is the procedure for setting automatic extension:

Procedure

To set the automatic extension:

When the HiRDB file system area is created with the pdfmkfs command, specify the maximum number of extensions (in the -e option).

When an RDAREA is created, use a utility control statement* to specify use of the automatic extension facility.

* This can be specified in the CREATE RDAREA, EXPAND RDAREA, INITIALIZE RDAREA, or ALTER RDAREA statement of the database initialization utility, database structure modification utility, or registry facility initialization utility.

(3) Notes

Automatic extension cannot be applied to an RDAREA that stores an abstract data type provided by a plug-in. However, in the case of the HiRDB Text Search Plug-in with the SGMLTEXT type, a portion of the index management area can be extended automatically.

If automatic extension is not possible because of a space shortage in the HiRDB file system area, you must either extend the RDAREA or reorganize the tables or indexes in the RDAREA.

If the number of extents exceeds the maximum, which is 24, you must either consolidate the extents in the HiRDB file system area into a single extent or extend the RDAREA. To consolidate extents in a HiRDB file system area, first make a backup of the HiRDB file system area with the pdfbkup command, then initialize the HiRDB file system area with the pdfmkfs command. You can then use the pdfrstr command to restore the HiRDB file system area.

While an RDAREA is in updatable backup hold status or updatable backup hold (WAIT mode) status, RDAREA automatic extension is suppressed. For this reason, you should refrain, while an RDAREA is in either of theses statuses, from executing a job that adds or updates a large volume of data, thus requiring allocation of new pages. To release suppression of RDAREA automatic extension, use the pdrels command to release the RDAREA from the hold.

When the hybrid method is used in Real Time SAN Replication, HiRDB waits for the database to be synchronized with the remote site when RDAREA automatic extension occurs. For this reason, an extension operation my result in a processing overhead of 2 seconds or longer.

15.7.2 Example

This example adds a user RDAREA (RDAREA1) to which the automatic extension facility is applied.

Procedure

Use the pdfmkfs command to create a HiRDB file system area for the RDAREA.

Create a control statements file for the pdmod command.

Use the pdmod command to add the RDAREA.

Use the pdcopy command to back up data.

Use the pdbufmod command to allocate a global buffer.

Update the pdbuffer operand.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this subsection

(1) Use the pdfmkfs command to create a HiRDB file system area for the RDAREA

(2) Create the control statements file for the pdmod command

(3) Use the pdmod command to add the RDAREA

(4) Use the pdcopy command to make a backup

(5) Use the pdbufmod command to allocate a global buffer

(6) Update the pdbuffer operand

(1) Use the pdfmkfs command to create a HiRDB file system area for the RDAREA

pdfmkfs -n 100 -l 10 -e 230 -k DB -i /rdarea/area01

Explanation

Creates a HiRDB file system area (/rdarea/area01) for RDAREAs.

-n: Specifies the size (in megabytes) of the HiRDB file system area.

-l: Specifies the maximum number of HiRDB files that can be created in the HiRDB file system area.

-e: Specifies the maximum number of extensions.

-k: Specifies DB because the HiRDB file system area is to be used for RDAREAs.

-i: Specifies that the HiRDB file system area is to be initialized.

/rdarea/area01: Specifies a name for the HiRDB file system area that is to be created.

(2) Create the control statements file for the pdmod command

A control statements file (/pdmod/create01) is created for the create rdarea statement of the pdmod command. The following are the contents of the control statements file:

create rdarea RDAREA1                              1
  globalbuffer gbuf01                             2
  for user used by PUBLIC                         3
  server name bes1                                4
  page 4096 characters                            5
  storage control segment 10 pages                6
  extension use 500 segments                      7
  file name "/rdarea/area01/file01"               8
     initial 1000 segments;                       9

Explanation

Specifies that an RDAREA named RDAREA1 is to be created.

Specifies the global buffer (gbuf01) to be allocated for RDAREA1. Because a global buffer specified with this operand is not allocated when HiRDB is started subsequently, you must change the value specified in the pdbuffer operand. Note that if you allocate a global buffer in step (5) below, you need not specify this operand.

Specifies that RDAREA1 is to be a public user RDAREA.

In the case of a HiRDB/Parallel Server (only), specifies the name of the server where the RDAREA is to be added.

Specifies the page size.

Specifies the segment size.

Specifies use of the automatic extension facility and the number of segments to be added in each iteration of automatic extension.

Specifies the HiRDB file comprising the RDAREA.
/rdarea/area01 is the HiRDB file system area created in step (1).

Specifies the number of HiRDB file segments.

(3) Use the pdmod command to add the RDAREA

pdmod -a /pdmod/create01

Explanation

-a: Specifies the name of the control statements file for the pdmod command created in step (2).

(4) Use the pdcopy command to make a backup

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. When an RDAREA is added, the contents of the master directory and data dictionary RDAREAs are updated, so all RDAREAs are backed up.

-b: Specifies a name for the backup file.

-p: Specifies the output destination for the pdcopy command's processing results listing.

(5) Use the pdbufmod command to allocate a global buffer

This step adds a new global buffer (gbuf01) and allocates it for RDAREA1.

pdbufmod -k add -a gbuf01 -r RDAREA1 -n 1000

Explanation

-k add: Specifies that a global buffer is to be added.

-a: Specifies the name of the global buffer being added.

-r: Specifies the RDAREA for which the global buffer is being allocated.

-n: Specifies the sector count of the global buffer.

Note, however, that both the following conditions must be satisfied in order to use the pdbufmod command:

HiRDB Advanced High Availability is installed.

The value Y is specified in the pd_dbbuff_modify operand.

(6) Update the pdbuffer operand

The global buffer allocated in this procedure becomes invalid if HiRDB is terminated normally or through a planned termination. Therefore, change the pdbuffer operand specification while HiRDB is stopped. An example of the pdbuffer operand specification follows:

                        :
pdbuffer -a gbuf01 -r RDAREA1,RDAREA2,RDAREA3 -n 1000
                        :

Explanation

The added RDAREA (RDAREA1) is assigned to a global buffer (gbuf01).

You can use the system reconfiguration command (pdchgconf command) to change the pdbuffer operand specification while HiRDB is running. Note that HiRDB Advanced High Availability must be installed in order to use the system reconfiguration command. For details about changing HiRDB system definitions using the system reconfiguration command, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

15.7.3 Handling space shortages in HiRDB file system areas

The following procedure shows how to handle space shortages in HiRDB file system areas that prevent automatic extension from being performed.

Procedure

Use the pdfmkfs command to create a HiRDB file system area.

Use the pdrorg command to unload table data. This is the recommended procedure, although this step is not always required. It does, however, improve performance. For details about unloading data, see the manual HiRDB Version 8 Command Reference.

Use the pdmod command (expand rdarea statement) to expand the RDAREA. Add and allocate the HiRDB file system area created in step 1. For details about expanding RDAREAs, see 15.3 Increasing the size of an RDAREA (RDAREA expansion).

Use the pdrorg command to reload the table data. Reload the data if you unloaded it in step 2. For details about reloading data, see the manual HiRDB Version 8 Command Reference.

Use the pdcopy command to back up data. For details about making backups, see 6. Backup Procedures.

Notes on using the inner replica facility

If you are using the inner replica facility, the number of HiRDB files making up the expanded RDAREA will no longer match the number for the other RDAREAs in the replica group. To copy the contents of an RDAREA to another RDAREA, you can use one of the methods below. If the RDAREA being expanded is an original RDAREA, take the action described in method 1. If the RDAREA being expanded is a replica RDAREA, take the action described in method 2.

Delete all replica RDAREA definitions, and then perform the procedure described above. After finishing, redefine the replica RDAREAs.

Perform the procedure described above. Before copying the data object for use in another RDAREA, use the define copy rdarea statement of the database structure modification utility to copy the RDAREA configuration information from the data object source. For details, see Modifying and copying the configuration information of an RDAREA in an inner replica in the HiRDB Staticizer Option Version 7 Description and User's Guide.

15.7.4 Actions to take when the number of extents reaches the maximum value

If the number of extents reaches the maximum value (24), automatic extension can no longer be performed. If this happens, take one of the following actions:

Consolidate HiRDB file system area extents.

Reinitialize RDAREAs.

Expand RDAREAs as described in section 15.7.3.

Use either method 1 or method 3 if multiple RDAREAs are assigned to a single HiRDB file system area.

Organization of this subsection

(1) Consolidate HiRDB file system area extents

(2) Reinitialize RDAREAs

(1) Consolidate HiRDB file system area extents

The following procedure shows how to consolidate extents (how to merge all extents into one):

Procedure

Use the pdstop command to terminate HiRDB normally.

Use the pdfbkup command to back up the HiRDB file system area.

Use the pdfmkfs command to reinitialize the HiRDB file system area.

Use the pdfrstr command to recover the HiRDB file system area. Recover using the backup made in step 1.

Use the pdstart command to start HiRDB normally.

(2) Reinitialize RDAREAs

Reinitialize the RDAREAs. For details about how to reinitialize RDAREAs, see 15.4 Increasing the size of an RDAREA or modifying its attributes (RDAREA reinitialization). If you specify the initialize rdarea statement of the pdmod command, however, take note of the following cautions:

Specify the with reconstruction operand.

Specify the number of segments required in the initial statement.

If you do not specify these operands, the RDAREAs will be re-created at the same sizes they were when defined originally.

15.8 Moving an RDAREA (RDAREA migration)

Executor: HiRDB administrator

By using the move rdarea statement of the database structure modification utility (pdmod command), you can migrate, or move, RDAREAs to other back-end servers. The functionality that enables RDAREAs to be moved is available only with a HiRDB/Parallel Server.

Organization of this section

15.8.1 Before moving RDAREAs

15.8.2 Example 1 (Moving RDAREAs to the back-end server on a new server machine)

15.8.3 Example 2 (Moving RDAREAs to a back-end server in a different unit)

15.8.4 Example 3 (Moving RDAREAs to a different back-end server in the same unit)

15.8.5 Example 4 (Moving RDAREAs containing a row-partitioned table)

15.8.6 Example 5 (Moving inner replica RDAREAs)

15.8.7 Example 6 (Moving RDAREAs containing an abstract data type)

15.8.1 Before moving RDAREAs

Organization of this subsection

(1) RDAREAs that can be moved

(2) Procedure

(3) Notes

(1) RDAREAs that can be moved

The following RDAREAs can be moved:

User RDAREAs

User LOB RDAREAs

(2) Procedure

The procedure for moving RDAREAs is shown below. Note that the migration procedure described below explains the basic operation; the procedure you use may differ slightly depending on the configuration of your system. For details, see the examples starting in section 15.8.2.

Procedure

Re-estimate the memory requirements for the server machine running the target back-end server.

Use the pdcopy command to make required backups. The RDAREAs to be moved, the master directory RDAREA, and the data dictionary RDAREAs must be backed up.

Use the pdhold command to place the RDAREAs to be moved in shutdown and closed status.

Use the pdmod command to move the RDAREAs.

Use the pdstop command to terminate HiRDB normally. After you have moved the RDAREAs, HiRDB must be stopped. Processing after the RDAREAs have been moved cannot be guaranteed if you do not stop HiRDB at this point.

Transfer the HiRDB files comprising the RDAREAs being moved.*

Use the pdstart command to start HiRDB normally.

Use the pdcopy command to make required backups. The RDAREAs that were moved, the master directory RDAREA, and the data dictionary RDAREAs must be backed up.

Note

Do not execute any UAPs or other utilities from the time you begin moving RDAREAs until the time you start HiRDB (steps 4-7).

* This step is required when you are moving RDAREAs to another server machine. The HiRDB files of the RDAREAs that are being moved must be transferred to the destination server machine. In addition, the path names of these HiRDB files must be the same as their path name on the source server machine. If the same path names cannot be used, create a symbolic link aliasing the original path to the directory on the target server machine that contains the files.

You must also delete the HiRDB files on the source server machine after they have been transferred. For details on how to do this, see the examples starting in section 15.8.2.

(3) Notes

(a) Move all related RDAREAs

If you decide to move an RDAREA, you must move all related RDAREAs, as listed below. If you do not move all related RDAREAs, an error will occur when you execute the database structure modification utility (pdmod command).

Move any RDAREA that contains an index defined for any table stored in an RDAREA that is being moved.

Move any user LOB RDAREA that contains LOB data of any LOB column defined in any table stored in an RDAREA that is being moved.

Move, by partitioning unit, any RDAREA containing any table, index, or LOB column that is in a row-partitioned table stored in an RDAREA that is being moved.

Move all RDAREAs within any replica group RDAREA that is being moved. In this case, you must also pre-register the generation number of the target HiRDB file system area.

(b) If a non-partitioning key index is defined for the table

You cannot move an RDAREA containing a table for which a non-partitioning key index is defined. In such a case, use the procedure explained below to move the RDAREA.

Procedure

Use DROP INDEX to delete the non-partitioning key index.

Move the RDAREA.

Use CREATE INDEX to re-create the non-partitioning key index.

Note that you may not be able to re-create a non-partitioning key index for which UNIQUE is defined. For details about the situations in which you cannot re-create a non-partitioning key index, see the description of CREATE INDEX in the manual HiRDB Version 8 SQL Reference.

(c) If a primary key is defined for a key other than a table partitioning key

You cannot move an RDAREA that contains a table for which a primary key other than a table partitioning key is defined. In such a case, use the procedure explained below to move the RDAREA.

Procedure

Use the pdrorg command to unload the table data.

Use DROP TABLE to delete the table definition.

Move the RDAREA.

Use CREATE TABLE to define a table.

Use the pdrorg command to reload the table data.

(d) If any routines for converting a table to a base table exist

Because any routine that converts a table stored in an RDAREA being moved to a base table becomes invalid when the RDAREA is moved, use ALTER ROUTINE to re-create the routine.

15.8.2 Example 1 (Moving RDAREAs to the back-end server on a new server machine)

In this example, RDAREAs are moved to a back-end server created on a new server machine.

RDAREA1 contains a non-row-partitioned table (TABLE1).

An index (INDEX1) and a LOB column (LOB1) are defined for TABLE1. The index is stored in RDAREA2 and the LOB data is stored in RDAREA3.

The HiRDB files configuring these RDAREAs are as follows:
RDAREA1: /area1/rdarea1
RDAREA2: /area2/rdarea2
RDAREA3: /area3/rdarea3

Organization of this subsection

(1) Add unit 2

(2) Use the pdcopy command to back up the RDAREAs

(3) Use the pdhold command to place the RDAREAs being moved in shutdown and closed status

(4) Create a control statements file for the pdmod command

(5) Use the pdmod command to move the RDAREAs

(6) Use the pdstop command to terminate HiRDB normally

(7) Transfer the HiRDB files comprising the RDAREAs being moved

(8) Use the pdstart command to start HiRDB normally

(9) Use the pdcopy command to back up the RDAREAs

(1) Add unit 2

For details about adding a unit, see 11.1 Adding a unit.

(2) Use the pdcopy command to back up the RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01-p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. Because the master directory RDAREA and the data dictionary RDAREAs are updated when an RDAREA is moved, we recommend that you back up all RDAREAs at this time.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(3) Use the pdhold command to place the RDAREAs being moved in shutdown and closed status

pdhold -r RDAREA1,RDAREA2,RDAREA3 -c

(4) Create a control statements file for the pdmod command

Create a control statements file (/pdmod/move01) containing a move rdarea statement for the pdmod command. The following shows the contents of this control statements file:

move rdarea RDAREA1,RDAREA2,RDAREA3                1
  to bes2;                                        2

Explanation

Specifies the names of the RDAREAs being moved.

Specifies the name of the target server.

(5) Use the pdmod command to move the RDAREAs

pdmod -a /pdmod/move01

Explanation

-a: Specifies the name of the control statements file for the pdmod command.

(6) Use the pdstop command to terminate HiRDB normally

pdstop

(7) Transfer the HiRDB files comprising the RDAREAs being moved

Use one of the following methods to transfer the HiRDB files of the RDAREAs being moved to the new server machine.

(a) Transfer by HiRDB file system area

This method requires the following to be satisfied:

The HiRDB file system area is a regular file.

The HiRDB file system area contains only the HiRDB file being moved.

Use the operating system's rcp or ftp command to transfer the HiRDB file system areas.

rcp /area1 host2:/area1
rcp /area2 host2:/area2
rcp /area3 host2:/area3

Explanation

Transfers the HiRDB file system areas for RDAREA1 through RDAREA3.

(b) Transfer by HiRDB file

If you cannot use the method described in (a), use the procedure described below to move the HiRDB files.

Operations on the source machine

Use the pdfbkup command to back up the HiRDB files to be moved.

Use the rcp or ftp command to move the backups you made of the HiRDB files.

Use the pdfrm command to delete the originals of the HiRDB files that you moved.

Example

pdfbkup /area1/rdarea1 /tmp/bk_rdarea1          1
pdfbkup /area2/rdarea2 /tmp/bk_rdarea2          1
pdfbkup /area3/rdarea3 /tmp/bk_rdarea3          1
rcp /tmp/"bk_*" host2:/tmp/                     2
pdfrm /area1/rdarea1                            3
pdfrm /area2/rdarea2                            3
pdfrm /area3/rdarea3                            3

Explanation

Backs up the HiRDB files of RDAREA1 through RDAREA3.

Moves the backups of the HiRDB files.

Deletes the HiRDB files of RDAREA1 through RDAREA3.

Operations on the target machine

Use the pdfmkfs command to create HiRDB file system areas.

Use the pdfrstr command to restore the HiRDB files that you moved.

Example

pdfmkfs -n 30 -l 10 -k DB /area1               1
pdfmkfs -n 30 -l 10 -k DB /area2               1
pdfmkfs -n 30 -l 10 -k DB /area3               1
pdfrstr /tmp/bk_rdarea1 /area1                 2
pdfrstr /tmp/bk_rdarea2 /area2                 2
pdfrstr /tmp/bk_rdarea3 /area3                 2

Explanation

Creates the HiRDB files system areas for RDAREA1 to RDAREA3. Use the same path name as was used on the source machine. If you cannot use the same path name, create a symbolic link aliasing the original path to the directory on the target machine that contains the files.

Lists the HiRDB files of RDAREA1 to RDAREA3.

(8) Use the pdstart command to start HiRDB normally

pdstart

(9) Use the pdcopy command to back up the RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02-p /pdcopy/list02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. Because the master directory RDAREA and the data dictionary RDAREAs are updated when an RDAREA is moved, we recommend that you back up all RDAREAs at this time.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

15.8.3 Example 2 (Moving RDAREAs to a back-end server in a different unit)

In this example, RDAREAs are moved to a back-end server in a different unit.

RDAREA1 contains a non-row-partitioned table (TABLE1).

An index (INDEX1) and a LOB column (LOB1) are defined for TABLE1. The index is stored in RDAREA2 and the LOB data is stored in RDAREA3.

The HiRDB files configuring these RDAREAs are as follows:
RDAREA1: /area1/rdarea1
RDAREA2: /area2/rdarea2
RDAREA3: /area3/rdarea3

Organization of this subsection

(1) Estimate memory requirements

(1) Estimate memory requirements

Estimate memory requirements for the server machine on which the target unit is running. For details about estimating memory requirements, see the manual HiRDB Version 8 Installation and Design Guide.

The subsequent steps are identical to the steps in section 15.8.2, beginning with 15.8.2(2) Use the pdcopy command to back up the RDAREAs.

15.8.4 Example 3 (Moving RDAREAs to a different back-end server in the same unit)

In this example, RDAREAs are moved to a different back-end server in the same unit.

RDAREA1 contains a non-row-partitioned table (TABLE1).

An index (INDEX1) and a LOB column (LOB1) are defined for TABLE1. The index is stored in RDAREA2 and the LOB data is stored in RDAREA3.

The HiRDB files configuring these RDAREAs are as follows:
RDAREA1: /area1/rdarea1
RDAREA2: /area2/rdarea2
RDAREA3: /area3/rdarea3

Organization of this subsection

(1) Estimate memory requirements

(2) Use the pdcopy command to back up the RDAREAs

(3) Use the pdhold command to place the RDAREAs being moved in shutdown and closed status

(4) Create a control statements file for the pdmod command

(5) Use the pdmod command to move the RDAREAs

(6) Use the pdstop command to terminate HiRDB normally

(7) Use the pdstart command to start HiRDB normally

(8) Use the pdcopy command to back up the RDAREAs

(1) Estimate memory requirements

Estimate memory requirements for the target back-end server. For details about estimating memory requirements, see the manual HiRDB Version 8 Installation and Design Guide.

(2) Use the pdcopy command to back up the RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up.

Because the master directory RDAREA and the data dictionary RDAREAs are updated when an RDAREA is moved, we recommend that you back up all RDAREAs at this time.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(3) Use the pdhold command to place the RDAREAs being moved in shutdown and closed status

pdhold -r RDAREA1,RDAREA2,RDAREA3 -c

(4) Create a control statements file for the pdmod command

Create a control statements file (/pdmod/move01) containing a move rdarea statement for the pdmod command. The following shows the contents of this control statements file:

move rdarea RDAREA1,RDAREA2,RDAREA3                1
  to bes2;                                        2

Explanation

Specifies the names of the RDAREAs being moved.

Specifies the name of the target server.

(5) Use the pdmod command to move the RDAREAs

pdmod -a /pdmod/move01

Explanation

-a: Specifies the name of the control statements file for the pdmod command.

(6) Use the pdstop command to terminate HiRDB normally

pdstop

(7) Use the pdstart command to start HiRDB normally

pdstart

(8) Use the pdcopy command to back up the RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. Because the master directory RDAREA and the data dictionary RDAREAs are updated when an RDAREA is moved, we recommend that you back up all RDAREAs at this time.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

15.8.5 Example 4 (Moving RDAREAs containing a row-partitioned table)

In this example, RDAREAs are moved to a back-end server created on a new server machine. A table that is row-partitioned within a server (TABLE1) is converted to one that is row-partitioned among servers.

RDAREA1 and RDAREA2 contain a row-partitioned table (TABLE1).

A partitioning key index (INDEX1) and a non-partitioning key index (INDEX2) are defined for TABLE1. A LOB column (LOB1) is also defined. INDEX1 is stored in RDAREA3 and RDAREA4, INDEX2 is stored in RDAREA3, and LOB data is stored in RDAREA5 and RDAREA6.

The HiRDB files configuring these RDAREAs are as follows:
RDAREA1: /area1/rdarea1
RDAREA2: /area2/rdarea2
RDAREA3: /area3/rdarea3
RDAREA4: /area4/rdarea4
RDAREA5: /area5/rdarea5
RDAREA6: /area6/rdarea6

Organization of this subsection

(1) Add unit 2

(2) Use the pdcopy command to back up the RDAREAs

(3) Use DROP INDEX to delete the non-partitioning key index

(4) Use the pdhold command to place the RDAREAs being moved in shutdown and closed status

(5) Create a control statements file for the pdmod command

(6) Use the pdmod command to move the RDAREAs

(7) Use the pdstop command to terminate HiRDB normally

(8) Transfer the HiRDB files comprising the RDAREAs being moved

(9) Use the pdstart command to start HiRDB normally

(10) Use CREATE INDEX to re-create the non-partitioning key index

(11) Use the pdcopy command to back up the RDAREAs

(1) Add unit 2

For details about adding a unit, see 11.1 Adding a unit.

(2) Use the pdcopy command to back up the RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. Because the master directory RDAREA and the data dictionary RDAREAs are updated when an RDAREA is moved, we recommend that you back up all RDAREAs at this time.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(3) Use DROP INDEX to delete the non-partitioning key index

DROP INDEX INDEX2;

Because you cannot move an RDAREA that contains a non-partitioning key index, use DROP INDEX to delete INDEX2 (the non-partitioning key index).

(4) Use the pdhold command to place the RDAREAs being moved in shutdown and closed status

pdhold -r RDAREA2,RDAREA4,RDAREA6 -c

(5) Create a control statements file for the pdmod command

Create a control statements file (/pdmod/move01) containing a move rdarea statement for the pdmod command. The following shows the contents of this control statements file:

move rdarea RDAREA2,RDAREA4,RDAREA6                           1
  to bes2;                                                   2

Explanation

Specifies the names of the RDAREAs being moved.

Specifies the name of the target server.

(6) Use the pdmod command to move the RDAREAs

pdmod -a /pdmod/move01

Explanation

-a: Specifies the name of the control statements file for the pdmod command.

(7) Use the pdstop command to terminate HiRDB normally

pdstop

(8) Transfer the HiRDB files comprising the RDAREAs being moved

Use one of the methods explained below to transfer the HiRDB files of the RDAREAs being moved to the new server machine.

(a) Transfer by HiRDB file system area

This method requires that the following be satisfied:

The HiRDB file system area is a regular file.

The HiRDB file system area contains only the HiRDB file being moved.

Use the operating system's rcp or ftp command to transfer the HiRDB file system areas.

rcp /area2 host2:/area2
rcp /area4 host2:/area4
rcp /area6 host2:/area6

Explanation

Transfers the HiRDB file system areas for RDAREA2, RDAREA4, and RDAREA6.

(b) Transfer by HiRDB file

If you cannot use the method described in (a), use the procedure described below to move the HiRDB files.

Operations on the source machine

Use the pdfbkup command to back up the HiRDB files to be moved.

Use the rcp or ftp command to move the backups you made of the HiRDB files.

Use the pdfrm command to delete the originals of the HiRDB files that you moved.

Example

pdfbkup /area2/rdarea2 /tmp/bk_rdarea2          1
pdfbkup /area4/rdarea4 /tmp/bk_rdarea4          1
pdfbkup /area6/rdarea6 /tmp/bk_rdarea6          1
rcp /tmp/"bk_*" host2:/tmp/                     2
pdfrm /area2/rdarea2                            3
pdfrm /area4/rdarea4                            3
pdfrm /area6/rdarea6                            3

Explanation

Backs up the HiRDB files of RDAREA2, RDAREA4, and RDAREA6.

Moves the backups of the HiRDB files.

Deletes the HiRDB files of RDAREA2, RDAREA4, and RDAREA6.

Operations on the target machine

Use the pdfmkfs command to create HiRDB file system areas.

Use the pdfrstr command to restore the HiRDB files that you moved.

Example

pdfmkfs -n 30 -l 10 -k DB /area2               1
pdfmkfs -n 30 -l 10 -k DB /area4               1
pdfmkfs -n 30 -l 10 -k DB /area6               1
pdfrstr /tmp/bk_rdarea2 /area2                 2
pdfrstr /tmp/bk_rdarea4 /area4                 2
pdfrstr /tmp/bk_rdarea6 /area6                 2

Explanation

Creates the HiRDB files system areas RDAREA2, RDAREA4, and RDAREA6. Use the same path name as was used on the source machine. If you cannot use the same path name, create a symbolic link aliasing the original path to the directory on the target machine that contains the files.

Lists the HiRDB files of RDAREA2, RDAREA4, and RDAREA6

(9) Use the pdstart command to start HiRDB normally

pdstart

(10) Use CREATE INDEX to re-create the non-partitioning key index

CREATE INDEX INDEX2 on TABLE1(C2) IN ((RDAREA3),(RDAREA4));

Re-create the non-partitioning key index that you deleted in step (3).

(11) Use the pdcopy command to back up the RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. Because the master directory RDAREA and the data dictionary RDAREAs are updated when an RDAREA is moved, we recommend that you back up all RDAREAs at this time.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

15.8.6 Example 5 (Moving inner replica RDAREAs)

In this example, an inner replica group RDAREA is moved to a back-end server created on a new server machine.

RDAREA1 contains a non-row-partitioned table (TABLE1).

An index (INDEX1) is defined for TABLE1. INDEX1 is stored in RDAREA2.

The replica RDAREA of RDAREA1 is RDAREA1_R1, and the replica RDAREA of RDAREA2 is RDAREA2_R1.

The HiRDB files configuring these RDAREAs are as follows:
RDAREA1: /area1/rdarea1
RDAREA2: /area2/rdarea2
RDAREA1_R1: /area3/rdarea1
RDAREA2_R1: /area4/rdarea2

Organization of this subsection

(1) Add unit 2

(2) Use the pdcopy command to back up the RDAREAs

(3) Create a control statements file for the pdmod command

(4) Use the pdmod command to register the generation number of the replica HiRDB file system areas

(5) Use the pdhold command to place the RDAREAs being moved in shutdown and closed status

(6) Create a control statements file for the pdmod command

(7) Use the pdmod command to move the RDAREAs

(8) Use the pdstop command to terminate HiRDB normally

(9) Transfer the HiRDB files comprising the RDAREAs being moved

(10) Use the pdstart command to start HiRDB normally

(11) Use the pdcopy command to back up the RDAREAs

(1) Add unit 2

For details about adding a unit, see 11.1 Adding a unit.

(2) Use the pdcopy command to back up the RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. Because the master directory RDAREA and the data dictionary RDAREAs are updated when an RDAREA is moved, we recommend that you back up all RDAREAs at this time.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(3) Create a control statements file for the pdmod command

This file is used to register the generation number of the replica HiRDB file system areas on the new back-end server. Create a control statements file (/pdmod/gen01) containing a create generation statement for the pdmod command. The following shows the contents of this control statements file:

create generation for HiRDB file system area
      "/area3"                                       1
      server name bes2                               2
      generation number 1                            3
      reproduce "/area1";                            4
create generation for HiRDB file system area
      "/area4"                                       1
      server name bes2                               2
      generation number 1                            3
      reproduce "/area2";                            4

Explanation

Specifies the names of the replica HiRDB file system areas.
When the pdmod command is executed, the KFPX24251-W message is issued. However, this does not pose a problem because you will create the HiRDB file system areas on the target server machine later in step (11).

Specifies the name of the server to which the replica HiRDB files system areas are being moved.

Specifies the generation number of the replica HiRDB file system areas.

Specifies the original HiRDB file system areas.

(4) Use the pdmod command to register the generation number of the replica HiRDB file system areas

pdmod -a /pdmod/gen01

Explanation

-a: Specifies the name of the control statements file for the pdmod command.

(5) Use the pdhold command to place the RDAREAs being moved in shutdown and closed status

pdhold -r RDAREA1,RDAREA2,RDAREA1_R1,RDAREA2_R1 -c

(6) Create a control statements file for the pdmod command

Create a control statements file (/pdmod/move01) containing a move rdarea statement for the pdmod command. The following shows the contents of this control statements file:

move rdarea RDAREA1,RDAREA2,RDAREA1_R1,RDAREA2_R1            1
  to bes2;                                                  2

Explanation

Specifies the names of the RDAREAs being moved.

Specifies the name of the target server.

(7) Use the pdmod command to move the RDAREAs

pdmod -a /pdmod/move01

Explanation

-a: Specifies the name of the control statements file for the pdmod command.

(8) Use the pdstop command to terminate HiRDB normally

pdstop

(9) Transfer the HiRDB files comprising the RDAREAs being moved

Use one of the following methods to transfer the HiRDB files of the RDAREAs being moved to the new server machine.

(a) Transfer by HiRDB file system area

This method requires that the following be satisfied:

The HiRDB file system area is a regular file.

The HiRDB file system area contains only the HiRDB file being moved.

Use the operating system's rcp or ftp command to transfer the HiRDB file system areas.

rcp /area1 host2:/area1
rcp /area2 host2:/area2
rcp /area3 host2:/area3
rcp /area4 host2:/area4

Explanation

Transfers the HiRDB file system areas for RDAREA1 through RDAREA2, and for RDAREA1_R1 through RDAREA2_R1.

(b) Transfer by HiRDB file

If you cannot use the method described in (a), use the procedure described below to move the HiRDB files.

Operations on the source machine

Use the pdfbkup command to back up the HiRDB files to be moved.

Use the rcp or ftp command to move the backups you made of the HiRDB files.

Use the pdfrm command to delete the originals of the HiRDB files that you moved.

Example

pdfbkup /area1/rdarea1 /tmp/bk_rdarea1             1
pdfbkup /area2/rdarea2 /tmp/bk_rdarea2             1
pdfbkup /area3/rdarea1 /tmp/bk_rdarea1_r1          1
pdfbkup /area4/rdarea2 /tmp/bk_rdarea2_r1          1
rcp /tmp/"bk_*" host2:/tmp/                        2
pdfrm /area1/rdarea1                               3
pdfrm /area2/rdarea2                               3
pdfrm /area3/rdarea1                               3
pdfrm /area4/rdarea2                               3

Explanation

Backs up the HiRDB files of RDAREA1 through RDAREA2, and of RDAREA1_R1 through RDAREA2_R1.

Moves the backups of the HiRDB files.

Deletes the HiRDB files of RDAREA1 to RDAREA2, and of RDAREA1_R1 to RDAREA2_R1

Operations on the target machine

Use the pdfmkfs command to create HiRDB file system areas.

Use the pdfrstr command to restore the HiRDB files that you moved.

Example

pdfmkfs -n 30 -l 10 -k DB /area1               1
pdfmkfs -n 30 -l 10 -k DB /area2               1
pdfmkfs -n 30 -l 10 -k DB /area3               1
pdfmkfs -n 30 -l 10 -k DB /area4               1
pdfrstr /tmp/bk_rdarea1 /area1                 2
pdfrstr /tmp/bk_rdarea2 /area2                 2
pdfrstr /tmp/bk_rdarea1_r1 /area3              2
pdfrstr /tmp/bk_rdarea2_r1 /area4              2

Explanation

Creates the HiRDB files system areas for RDAREA1 to RDAREA2, and for RDAREA1_R1 to RDAREA2_R1. Use the same path name as was used on the source machine. If you cannot use the same path name, create a symbolic link aliasing the original path to the directory on the target machine that contains the files.

Lists the HiRDB files of RDAREA1 to RDAREA2, and of RDAREA1_R1 to RDAREA2_R1

(10) Use the pdstart command to start HiRDB normally

pdstart

(11) Use the pdcopy command to back up the RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. Because the master directory RDAREA and the data dictionary RDAREAs are updated when an RDAREA is moved, we recommend that you back up all RDAREAs at this time.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

15.8.7 Example 6 (Moving RDAREAs containing an abstract data type)

In this example, RDAREAs containing an abstract data type (SGMLTEXT type) are moved to a back-end server created on a new server machine. A table that is row-partitioned within a server (TABLE1) is converted to one that is row-partitioned among servers.

RDAREA1 and RDAREA2 contain a row-partitioned table (TABLE1).

An abstract data type (SGMLTEXT type) and a plug-in index are defined for TABLE1. The SGMLTEXT data is stored in RDAREA3 and RDAREA4, and the plug-in index is stored in RDAREA5 and RDAREA6.

The HiRDB files configuring these RDAREAs are as follows:
RDAREA1: /area1/rdarea1
RDAREA2: /area2/rdarea2
RDAREA3: /area3/rdarea3
RDAREA4: /area4/rdarea4
RDAREA5: /area5/rdarea5
RDAREA6: /area6/rdarea6

Organization of this subsection

(1) Add unit 2

(2) Use the pdcopy command to back up the RDAREAs

(3) Use the pdhold command to place the RDAREAs being moved in shutdown and closed status

(4) Create a control statements file for the pdmod command

(5) Use the pdmod command to move the RDAREAs

(6) Use the pdstop command to terminate HiRDB normally

(7) Transfer the HiRDB files comprising the RDAREAs being moved

(8) Use the pdstart command to start HiRDB normally

(9) Use the pdcopy command to back up the RDAREAs

(1) Add unit 2

For details about adding a unit, see 11.1 Adding a unit.

(2) Use the pdcopy command to back up the RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. Because the master directory RDAREA and the data dictionary RDAREAs are updated when an RDAREA is moved, we recommend that you back up all RDAREAs at this time.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

(3) Use the pdhold command to place the RDAREAs being moved in shutdown and closed status

pdhold -r RDAREA2,RDAREA4,RDAREA6 -c

(4) Create a control statements file for the pdmod command

Create a control statements file (/pdmod/move01) containing a move rdarea statement for the pdmod command. The following shows the contents of this control statements file:

move rdarea RDAREA2,RDAREA4,RDAREA6                    1
  to bes2;                                            2

Explanation

Specifies the names of the RDAREAs being moved.

Specifies the name of the target server.

(5) Use the pdmod command to move the RDAREAs

pdmod -a /pdmod/move01

Explanation

-a: Specifies the name of the control statements file for the pdmod command.

(6) Use the pdstop command to terminate HiRDB normally

pdstop

(7) Transfer the HiRDB files comprising the RDAREAs being moved

Use one of the following methods to transfer the HiRDB files of the RDAREAs being moved to the new server machine.

(a) Transfer by HiRDB file system area

This method requires that the following be satisfied:

The HiRDB file system area is a regular file.

The HiRDB file system area contains only the HiRDB file being moved.

Use the operating system's rcp or ftp command to transfer the HiRDB file system areas.

rcp /area2 host2:/area2
rcp /area4 host2:/area4
rcp /area6 host2:/area6

Explanation

Transfers the HiRDB file system areas for RDAREA2, RDAREA4, and RDAREA6.

(b) Transfer by HiRDB file

If you cannot use the method described in (a), use the procedure described below to move the HiRDB files.

Operations on the source machine

Use the pdfbkup command to back up the HiRDB files to be moved.

Use the rcp or ftp command to move the backups you made of the HiRDB files.

Use the pdfrm command to delete the originals of the HiRDB files that you moved.

Example

pdfbkup /area2/rdarea2 /tmp/bk_rdarea2          1
pdfbkup /area4/rdarea4 /tmp/bk_rdarea4          1
pdfbkup /area6/rdarea6 /tmp/bk_rdarea6          1
rcp /tmp/"bk_*" host2:/tmp/                     2
pdfrm /area2/rdarea2                            3
pdfrm /area4/rdarea4                            3
pdfrm /area6/rdarea6                            3

Explanation

Backs up the HiRDB files of RDAREA2, RDAREA4, and RDAREA6.

Moves the backups of the HiRDB files.

Deletes the HiRDB files of RDAREA2, RDAREA4, and RDAREA6.

Operations on the target machine

Use the pdfmkfs command to create HiRDB file system areas.

Use the pdfrstr command to restore the HiRDB files that you moved.

Example

pdfmkfs -n 30 -l 10 -k DB /area2               1
pdfmkfs -n 30 -l 10 -k DB /area4               1
pdfmkfs -n 30 -l 10 -k DB /area6               1
pdfrstr /tmp/bk_rdarea2 /area2                 2
pdfrstr /tmp/bk_rdarea4 /area4                 2
pdfrstr /tmp/bk_rdarea6 /area6                 2

Explanation

Creates the HiRDB files system areas RDAREA2, RDAREA4, and RDAREA6. Use the same path name as was used on the source machine. If you cannot use the same path name, create a symbolic link aliasing the original path to the directory on the target machine that contains the files.

Lists the HiRDB files of RDAREA2, RDAREA4, and RDAREA6.

(8) Use the pdstart command to start HiRDB normally

pdstart

(9) Use the pdcopy command to back up the RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup02 -p /pdcopy/list02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up. Because the master directory RDAREA and the data dictionary RDAREAs are updated when an RDAREA is moved, we recommend that you back up all RDAREAs at this time.

-b: Specifies the name of the backup file.

-p: Specifies the output destination of the pdcopy command's processing results listing.

15.9 Re-using used free pages and used free segments

You can reuse used free pages in tables and indexes by converting them to unused pages. Similarly, you can reuse used free segments by converting them to unused segments. This section explains how to reuse used free pages and segments. The following topics are explained in this section:

Page and segment status

Reusing used free pages

Reusing used free segments

Organization of this section

15.9.1 Page and segment status

15.9.2 Reusing used free pages

15.9.3 Reusing used free segments

15.9.1 Page and segment status

Before reading about reusing used free pages and used free segments in this section, you must be familiar with page statuses and segment statuses. Table 15-4 lists and describes pages statuses, and Table 15-5 lists and describes segment statuses.

Table 15-4 Page statuses

Page status | Description
Used page | A page in which table or index data is stored. A used page that is completely filled with data such that no more can be added is called a full page, and a used page from which data has been deleted so that it no longer contains data is called a used free page.
Unused page | A page that is not being used.
Free page | A page in which no data is stored. Both used free pages and unused pages are called free pages.

Table 15-5 Segment statuses

Segment status
Description

Used segment*
A segment in which table or index data is stored. A used segment that is completely filled with data such that no more can be added is called a full segment, and a used segment from which data has been deleted so that only free pages remain (used free pages or unused pages) is called a used free segment.

Unused segment
A segment that is not being used. This segment can be used by any table or index in the RDAREA.

Free segment
A segment in which no data is stored. Both used free segments and unused segments are called free segments.

* A used segment can be used only by a table or an index that stored data in it. Other tables or indexes cannot use such a segment.

15.9.2 Reusing used free pages

Organization of this subsection

(1) Releasing used free pages

(2) Benefits of releasing used free pages

(3) Differences from table or index reorganization

(4) Method of operation

(5) Notes

(1) Releasing used free pages

When a large amount of table data is deleted by a batch job or some other operation, some of the pages in which table data is being stored (data pages) may become used free pages. Similarly, when an index is defined, some of the pages in which index key values are being stored (index pages) also become used free pages. By executing the free page release utility (pdreclaim command), you can convert used free pages to unused pages and reuse them. This is called releasing used free pages. Figure 15-2 provides an overview of releasing used free pages.

Figure 15-2 Releasing used free pages

Hint

You cannot release used free pages of data stored in LOB RDAREAs.

You cannot release used free pages of plug-in indexes.

(2) Benefits of releasing used free pages

(a) Benefits of releasing used free pages of tables

Table 15-6 lists and describes the benefits of releasing used free pages of a table.

Table 15-6 Benefits of releasing used free pages of a table

Benefit
Description
Degree of benefit

Ability to increase the table reorganization cycle
The ability to reuse used free pages improves data storage efficiency. In turn, this can increase (improve) the table reorganization time cycle.
Good

Improvement in performance for searching large data sets
Because they are a type of used page, used free pages are searched. However, searching is not performed on unused pages (they are skipped by a search). Thus, converting to unused pages improves search performance in direct proportion to the ratio converted. The benefits are particularly evident when large data sets are searched.
Varies

Improvement in performance when INSERT and UPDATE are used.
If sufficient contiguous free space cannot be allocated when an attempt is made to save data in a used page, HiRDB performs a process called page compaction. In page compaction, data in the affected page is repacked to secure sufficient contiguous free space to enable storage of the new data. When used free pages are released, page compaction is performed at the same time. This eliminates the need to perform page compaction which prolongs INSERT and DELETE processing and improves performance by the corresponding amount. The pages on which page compaction is performed are used pages other than full pages and used free pages.
Varies

Potential reduction in errors when INSERT and UPDATE are performed on branch rows.
If you execute INSERT or UPDATE on a branch row when there are no unused pages, an error occurs (KFPA11756-E message). The increase in unused pages due to the release of used free pages tends to reduce the frequency of this error.
Varies

Legend:

Good: Always beneficial.

Varies: The degree of benefit varies depending on conditions.

Particularly beneficial is application of this facility on tables that satisfy the conditions shown in Table 15-7.

Table 15-7 Tables that benefit from release of used free pages

Condition
Reason

A table that has no updates of variable-length character strings.
Because branch rows do not occur in such tables, the probability of being able to release used free pages increases.
Branch rows are stored on separate pages from their base rows, and base rows of other data are also stored on those pages. This means that, if there are branch rows, even if all rows of a particular value (such as registered duration) are deleted, the number of pages in which data is stored may not be reduced to zero. However, if there are no branch rows, when data inserted during a certain period is deleted, because the space in that contiguous area (page) becomes free, the probability of being able to release used free pages increases.

A table that has no changes in the number of repetition column elements.

A table that has no changes of NULL values to real data or real data to NULL values.

A table that has no cluster key index defined.
Because the storage position of a data item is determined from its key value when a cluster key index is defined, even if used free pages are released, the possibility that those pages will not be used is high, and little benefit will be achieved.

A table that has no LOB data.
This facility cannot be used on data stored in LOB RDAREAs.

A table for which data has already been deleted from the same page.
Because such a page is easy to convert to used free pages, the probability of being able to release used free pages increases.

A table that is a REUSE table (table on which the free space reusage facility has been used).
Free pages released in a REUSE table by the free page release utility can be quickly reused in the free page reuse mode. If the table is not a REUSE table, free pages released by the free page release utility cannot be used until new segments in the RDAREA can no longer be allocated.

Based on the conditions described in Table 15-7, the optimal table on which to apply this facility is a REUSE table with the FIX attribute for which no cluster key index is defined.

(b) Benefits of releasing used free pages of indexes

Table 15-8 lists and describes the benefits of releasing used free pages of an index.

Table 15-8 Benefits of releasing used free pages of an index

Benefit
Description
Degree of benefit

Potential reduction of space shortages in RDAREAs storing indexes
If space runs out even though free pages (used free pages) exist, release the used free pages. Note that this tends to reduce the occurrence of space shortages even for RDAREAs that store indexes with key values that are updated or deleted frequently.
Great

Ability to increase the index reorganization cycle
The ability to reuse used free pages improves data storage efficiency. In turn, this can increase (improve) the index reorganization time cycle.
Good

Improvement in performance when searching large data sets that use indexes
Because they are a type of used page, used free pages are searched. However, searching is not performed on unused pages (they are skipped by a search). Thus, converting to unused pages improves the search performance in direct proportion to the ratio converted. The benefits are particularly evident when large data sets are searched.
Varies

Legend:

Great: Particularly beneficial.

Good: Always beneficial.

Varies: The degree of benefit varies depending on conditions.

Use of this utility is particularly beneficial when deleted key values are not re-registered. Because used free pages are reused when the same key value is added or deleted repeatedly, large numbers of used free pages do not appear. However, for indexes that are defined for rows that increase or decrease by a fixed number (such as date, sequence number, and so on), and if past data is deleted in tandem with increases in data, a large number of used free pages that are not reused appear in the first half of the index pages. Figure 15-3 shows the processing of a used free pages being created for index pages.

Figure 15-3 Processing of used free pages being created for index pages

Note that after the used free pages are released, the key values are stored in the released pages, which improves data storage efficiency.

Reference note

This processing applies only to used free pages; it performs no page compaction on pages whose storage efficiency has deteriorated. Other than for free used pages, no benefit results if applied when there is a large number of pages whose storage efficiency has deteriorated.

(3) Differences from table or index reorganization

From the standpoint of performance and data storage efficiency, reorganizing tables or indexes is superior to releasing used free pages. However, while you are releasing used free pages, you can still access the tables or indexes on which the utility is operating. With reorganization, you cannot access the tables or indexes on which the utility is operating. This means that you do not have to interrupt normal operations in order to release free pages.

Use the execution results of the database condition analysis utility to evaluate whether to reorganize tables and indexes or to release used free pages. The following lists the evaluation criteria:

If there is a large number of used free pages, release the used free pages.

If the page utilization ratio of the used pages differs significantly from the segment free page ratio (value of the PCTFREE operand of CREATE TABLE), perform reorganization.

(4) Method of operation

(a) Estimate the system log file capacity

Because updated logs of the database are obtained when used free pages are released, we recommend that you re-estimate the system log file capacity. For details about estimating system log file capacity, see the manual HiRDB Version 8 Installation and Design Guide.

(b) Check the page status

Use the database condition analysis utility to assess periodically the page storage efficiency, the number of used free pages, and other statuses. A page whose usage ratio is 0% is a used free page. The page usage ratio and the number of used free pages is displayed in Used Page Ratio of Condition analysis (logical analysis) by RDAREA and Condition analysis by table or index.

If the data storage efficiency has deteriorated due to increases in the number of used free pages, consider releasing used free pages.

(c) Execute the free page release utility

You use the free page release utility to release used free pages.

Before releasing used free pages from a table, consider whether or not to perform page compaction. In the following cases, page compaction provides no benefits, so execute the free page release utility without performing page compaction:

If most of the used pages are full pages or used free pages

If all pages are free pages

(d) Check the results

Check the execution results of the free page release utility to determine if used free pages have been released as expected. If there is a large number of used free segments, consider releasing used free segments as well. For details about releasing used free segments, see 15.9.3 Reusing used free segments.

(e) If the free page release utility terminates abnormally

If the free page release utility terminates abnormally, all used free pages being released up to the one immediately prior to the abnormal termination have been released. Although doing nothing more at this time would not create a problem, re-executing the free page release utility will release the remaining pages.

(5) Notes

Execution of the free page release utility on an index does not cause UAPs to wait for a long time while the utility is executing. However, if a UAP accesses an index that is being processed by this utility, completion processing of the UAP transaction may be delayed.

Note that you can specify a maximum wait time in the -w option of the free page release utility. If the wait status is not released within the specified wait time, the KFPH25002-E message is issued and the free page release utility terminates abnormally. If the -w option is omitted, the system continues waiting until the UAP transaction is completed.

15.9.3 Reusing used free segments

Organization of this subsection

(1) Releasing used free segments

(2) Benefits of releasing used free segments

(3) Method of operation

(1) Releasing used free segments

By executing the free page release utility, you can convert used free segments to unused segments and reuse them. This is called releasing used free segments. Figure 15-4 provides an overview of releasing used free segments.

Figure 15-4 Releasing used free segments

(2) Benefits of releasing used free segments

Once segments are allocated, only the table (or index) that is assigned to use a particular segment can use it; no other tables can do so. Releasing used free segments converts used free segments to unused segments, which enables other tables to use those segments.

(3) Method of operation

Whether or not to release used free segments is determined from the execution results of the free page release utility or the database condition analysis utility. Release used free segments if there are a large number of them.

(a) Estimate the system log file capacity

Because updated logs of the database are obtained when used free segments are released, we recommend that you re-estimate the system log file capacity. For details about estimating system log file capacity, see the manual HiRDB Version 8 Installation and Design Guide.

(b) Execute the free page release utility

You use the free page release utility to release used free segments. Check the execution results of the free page release utility to determine if used free segment have been released as expected.

Reference note

A table or index whose used free segments are being released (the free page release utility is executing) cannot be accessed. Because of this, any UAP that attempts to access an RDAREA being processed is placed in wait status. To have the utility return an error without such a UAP being placed in wait status, use the pdhold command to shut down the RDAREA before executing the utility.

(c) If the free page release utility terminates abnormally

If the free page release utility terminates abnormally, the system returns to its status before the utility was executed (before any operation was performed). In such a case, simply re-execute the free page release utility. Although not re-executing the free page release utility does not create a problem, no used free segments are released if you do not re-execute.

16. Handling Stored Procedures and Stored Functions

This chapter explains the procedures for handling stored procedures and stored functions.

Stored procedure is a generic term for SQL stored procedures and Java stored procedures; stored function is a generic term for SQL stored functions and JavaTM stored functions.

This chapter contains the following sections:

Organization of this chapter

16.1 Before creating (registering) stored procedures or stored functions

16.2 Creating (registering) a stored procedure or stored function

16.3 Re-creating an invalidated stored procedure or stored function

16.4 Deleting a stored procedure or stored function

16.5 Creating a definition SQL from an existing stored procedure

16.1 Before creating (registering) stored procedures or stored functions

Executor: HiRDB administrator

Before stored procedures or stored functions are created, the database structure modification utility (pdmod command) must be used to create RDAREAs in which the stored procedures or stored functions will be stored. The following RDAREAs can be created:

Data dictionary LOB RDAREAs

Data dictionary RDAREAs*

* Data dictionary RDAREAs are needed if data dictionary tables for the stored procedures or stored functions are to be stored in RDAREAs other than existing data dictionary RDAREAs.

16.2 Creating (registering) a stored procedure or stored function

Organization of this section

(1) Creating a stored procedure

(2) Creating a stored function

(1) Creating a stored procedure

CREATE PROCEDURE is used to create a stored procedure. For details on how to use CREATE PROCEDURE to create a procedure, see the manual HiRDB Version 8 UAP Development Guide.

(2) Creating a stored function

CREATE FUNCTION is used to create a stored function. For details on how to use CREATE FUNCTION to create a function, see the manual HiRDB Version 8 UAP Development Guide.

(a) When a stored function is created, an existing stored function may be invalidated

When a stored function is created, an existing stored function may become invalid. An existing stored function that satisfies the following condition becomes invalid:

A stored function that calls a stored function that has the same name (authorization identifier and routine identifier) and the same number of parameters as the stored function being created

In this case, use ALTER ROUTINE to re-create the invalidated stored function.

(b) When a stored function is created, an existing stored procedure may be invalidated

When a stored function is created, an existing stored procedure may become invalid. An existing stored procedure that satisfies the following condition becomes invalid:

A stored procedure that calls a stored function that has the same name (authorization identifier and routine identifier) and the same number of parameters as the stored function being created

In this case, use the ALTER PROCEDURE statement or ALTER ROUTINE to re-create the invalidated stored procedure.

(c) When a stored function is created, an existing trigger may be invalidated

When a stored function is created, an existing trigger may become invalid. An existing trigger that satisfies the following condition becomes invalid:

A trigger that calls a stored function that has the same name (authorization identifier and routine identifier) and the same number of parameters as the stored function being created

In this case, use the ALTER TRIGGER statement or ALTER ROUTINE to re-create the invalidated trigger.

(d) A newly created stored function may be invalidated

A stored function created using the following procedure may become invalid:

Procedure

Install a plug-in.

Create a stored function for calling the plug-in function installed in step 1.*

Install a different plug-in from the one installed in step 1.

* If the plug-ins installed in steps 1 and 3 have the same function name and the same number of parameters, the stored function created in step 2 is invalidated when step 3 is executed. In such a case, ALTER ROUTINE can used to re-create the invalidated stored function.

16.3 Re-creating an invalidated stored procedure or stored function

When the definition of a table or index is modified, all the stored procedures and stored functions that use that table or index are invalidated. In such a case, the invalidated stored procedures and stored functions can be re-created, as explained in this section.

ALTER PROCEDURE or ALTER ROUTINE is used to re-create a stored procedure. ALTER ROUTINE is used to re-create a stored function.

16.4 Deleting a stored procedure or stored function

Organization of this section

(1) Deleting a stored procedure

(2) Deleting a stored function

(1) Deleting a stored procedure

DROP PROCEDURE is used to delete a stored procedure.

(2) Deleting a stored function

DROP FUNCTION is used to delete a stored function.

(a) When a stored function is deleted, an existing stored function may be invalidated

When a stored function is deleted, an existing stored function may become invalid. A stored function that satisfies the following condition becomes invalid:

A stored function that calls a stored function that has the same name (authorization identifier and routine identifier) and the same number of parameters as the stored function being deleted

In this case, use ALTER ROUTINE to re-create the invalidated stored function.

(b) When a stored function is deleted, an existing stored procedure may be invalidated

When a stored function is deleted, an existing stored procedure may become invalid. An existing stored procedure that satisfies the following condition becomes invalid:

A stored procedure that calls a stored function that has the same name (authorization identifier and routine identifier) and the same number of parameters as the stored function being deleted

In this case, use the ALTER PROCEDURE statement or ALTER ROUTINE to re-create the invalidated stored procedure.

(c) When a stored function is deleted, an existing trigger may be invalidated

When a stored function is deleted, an existing trigger may become invalid. An existing trigger that satisfies the following condition becomes invalid:

A trigger that calls a stored function that has the same name (authorization identifier and routine identifier) and the same number of parameters as the stored function being deleted

In this case, use the ALTER TRIGGER statement or ALTER ROUTINE to re-create the invalidated trigger.

16.5 Creating a definition SQL from an existing stored procedure

Executor: HiRDB administrator or a user with DBA privilege

The pddefrev command can be used to create a definition SQL from an existing stored procedure. This command is useful for creating a stored procedure that provides a similar function as an existing stored procedure. A definition SQL created with the pddefrev command is used as input information to the database definition utility (pddef command).

17. Using Java Stored Procedures and Java Stored Functions

This chapter explains the environment setup and operating procedures for using Java stored procedures and Java stored functions.

This chapter contains the following sections:

Organization of this chapter

17.1 Overview of Java stored procedures and Java stored functions

17.2 System configuration for using Java stored procedures and Java stored functions

17.3 Environment setup

17.4 JAR file operations

17.1 Overview of Java stored procedures and Java stored functions

This section provides an overview of Java stored procedures and Java stored functions.

Organization of this section

(1) Environments in which Java stored procedures and Java stored functions can be used

(2) Java stored procedures and Java stored functions

(3) Actions of Java stored procedures and Java stored functions

(1) Environments in which Java stored procedures and Java stored functions can be used

Table 17-1 shows the environments in which Java stored procedures and Java stored functions can be used.

Table 17-1 Environments in which Java stored procedures and Java stored functions can be used

OS
Usable
Remarks

HP-UX
Y
Can be used in either of the following environments:

32-bit-mode POSIX library version

HP-UX (IPF) version

Solaris
Y
Can be used in the following environment:

32-bit-mode POSIX library version

AIX 5L
Y

Linux
Y
Can be used in the following environments

32-bit-mode version

Linux (EM64T) version

Legend:

Y: Can be used.

(2) Java stored procedures and Java stored functions

Java stored procedures and Java stored functions are stored procedures and stored functions in which the type of routine control statements that can be described in SQL are instead written in Java. Java stored procedures and Java stored functions use Java methods created externally to HiRDB. Because these methods are registered into HiRDB as routine control statements, it is possible to perform platform-independent processing, development, and debugging.

As with stored procedures and stored functions described in SQL, Java stored procedures and Java stored functions can be called from an SQL (CALL statement or function invocation). Thus, there are no restrictions on the control statement description language.

(3) Actions of Java stored procedures and Java stored functions

Figure 17-1 shows the actions (invocation procedures) of Java stored procedures and Java stored functions.

Figure 17-1 Actions (invocation procedures) of Java stored procedures and Java stored functions

17.2 System configuration for using Java stored procedures and Java stored functions

This section explains the system configuration (positions of Java Virtual Machine, JAR file storage, etc.) for using Java stored procedures and Java stored functions.

Organization of this section

(1) Java Virtual Machine position

(2) JRE (Java Runtime Environment)

(3) System configuration in a HiRDB/Single Server

(4) System configuration in a HiRDB/Parallel Server

(1) Java Virtual Machine position

Figure 17-2 shows the position of a Java Virtual Machine in a HiRDB system.

Figure 17-2 Position of Java Virtual Machine in a HiRDB system

¹ The Java virtual machine is included in a JRE (Java Runtime Environment). For details about JREs, see (2) JRE (Java Runtime Environment).

² HiRDB provides the JDBC driver as a standard.

(2) JRE (Java Runtime Environment)

To use Java stored procedures and Java stored functions, a Java Runtime Environment (JRE) is required at the HiRDB server.

(a) How to obtain a JRE

You should be able to acquire necessary information about JREs and obtain the appropriate JRE by visiting the platform vendor's home page. The JRE version depends on the platform. Table 17-2 lists the JRE version for each platform.

Table 17-2 JRE versions

Platform | Version
HP-UX | Other than below | 1.2.2.04 or later
HP-UX (IPF) | 1.4.2.02 or later
Solaris | 1.3 or later
AIX 5L | 1.3 or later
Linux | Other than below | 1.3 or later
Linux (IPF) | 1.4.2 or later

(b) Handling of the JRE included in HiRDB version 07-02 and earlier

A JRE was included in HiRDB version 07-02 and earlier. This JRE will be deleted from the installation directory and the HiRDB directory at the following times:

When the included JRE is deleted from the installation directory

The JRE is deleted when the following events occur:

The HiRDB version that provided the JRE (07-02 or earlier) is uninstalled.

HiRDB version 07-03 or later is installed by overwriting the existing HiRDB.

When the included JRE is deleted from the HiRDB directory

When the file required for HiRDB execution is deleted in order to delete HiRDB from the OS (when Y is entered as the response to the pdsetup -d command's execution query message).

(c) Notes about upgrading to HiRDB version 07-03 or later

The following notes apply to upgrading to HiRDB version 07-03 or later.

When you upgrade your HiRDB to version 07-03 or later, you must specify the root directory of the Java Runtime Environment (JRE) in the pd_java_runtimepath operand. If necessary, also specify in the pd_java_libpath operand the directory that contains the JRE libraries.

The JRE that was expanded when HiRDB version 07-02 or earlier was installed will be deleted as explained in (b) above. If you want to continue using that JRE, do the following:

Before the JRE is deleted, back it up to a directory other than the installation directory or HiRDB directory.

In the pd_java_runtimepath operand, specify the directory containing the JRE that was backed up.

(3) System configuration in a HiRDB/Single Server

Figure 17-3 shows the system configuration for using Java stored procedures and Java stored functions in a HiRDB/Single Server.

Figure 17-3 System configuration for using Java stored procedures and Java stored functions in a HiRDB/Single Server

(4) System configuration in a HiRDB/Parallel Server

Figure 17-4 shows the system configuration for using Java stored procedures and Java stored functions in a HiRDB/Parallel Server.

Figure 17-4 System configuration for using Java stored procedures and Java stored functions in a HiRDB/Parallel Server

17.3 Environment setup

Executor: Superuser and HiRDB administrator

Figure 17-5 shows the procedure for setting up an environment for using Java stored procedures and Java stored functions. The explanation here assumes that the environment setup for the Java Virtual Machine and JDBC Driver has been completed.

When the environment setup explained here is completed, Java stored procedures and Java stored functions can be created and executed; for details on the creation and execution procedures, see the manual HiRDB Version 8 UAP Development Guide.

Figure 17-5 Environment setup procedure for use of Java stored procedures and Java stored functions

Note

The numbers to the left of the processing boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 3 is explained in paragraph (3) below.

* This step is applicable to the HP-UX, Solaris, and AIX 5L versions only; it is not required for the Linux version. This step is also not required if the POSIX Library version is already being used.

Organization of this section

(1) Create a directory for storing JAR files

(2) Use the pdstop command to terminate HiRDB normally

(3) Specify Java-related HiRDB system definition operands

(4) Use pdsetup command to set up POSIX Library version (applicable to HP-UX, Solaris, and AIX 5L versions only)

(5) Use the pdstart command to start HiRDB normally

(1) Create a directory for storing JAR files

Create a directory for storing the JAR files. The name of the directory created here will be specified in the pd_java_archive_directory operand in step (3).

Hint

Create a special directory in which to store JAR files.

Do not store files other than installed JAR files in the JAR directory.

(2) Use the pdstop command to terminate HiRDB normally

pdstop

If you use the system reconfiguration command (pdchgconf command), you do not need to restart HiRDB normally, because this command enables you to modify HiRDB system definitions while HiRDB is running. Note that HiRDB Advanced High Availability must be installed in order to use this command. For details about modifying HiRDB system definitions while HiRDB is running, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

(3) Specify Java-related HiRDB system definition operands

Specify the following Java-related operands in the HiRDB system definition:

pd_java_option

Specifies the Java option.

pd_java_routine_stack_size

Specifies in bytes the size of the stack to be used by Java routines.

pd_java_archive_directory

Specifies the directory for storing the JAR files.

pd_java_classpath

Specifies a Java class path.

pd_java_runtimepath

Specifies the root directory of the Java Runtime Environment.

pd_java_libpath

Specifies the library directory of the Java Virtual Machine.

pd_java_stdout_file

Specifies the output destination file for the Java Virtual Machine's standard output and standard error output.

(4) Use pdsetup command to set up POSIX Library version (applicable to HP-UX, Solaris, and AIX 5L versions only)

To use a Java stored procedure or Java stored function, the POSIX library version must be used. To use the POSIX library version, specify the -l option in the pdsetup command that is executed at the time of environment setup for HiRDB. The -l option should be specified in the pdsetup command at the time a new HiRDB is installed.

If HiRDB is already running but the POSIX library version is not being used, apply the procedure described below to change HiRDB to the POSIX library version.

Procedure

Use the pdsetup -d command to delete HiRDB from the OS. Choose y in response to the message.
In the case of a HiRDB/Parallel Server, execute the pdsetup -d command at all server machines.

Execute the pdsetup command with POSIX specified in the -l option.
In the case of a HiRDB/Parallel Server, execute the pdsetup -l command at all server machines.

Note

Because it supports POSIX, you do not need to perform the above procedure for the HP-UX (IPF) version of HiRDB.

HiRDB Version 5.0 and older versions do not support the POSIX library version. When HiRDB is being upgraded from Version 5.0 or older, use this procedure to change HiRDB to the POSIX library version.

If the -l option was not specified in the pdsetup command when a new HiRDB was being installed, use this procedure to change the HiRDB to the POSIX library version.

(5) Use the pdstart command to start HiRDB normally

pdstart

17.4 JAR file operations

Executor: HiRDB administrator

The following operations can be performed with the pdjarsync command:

JAR file registration

JAR file re-registration

JAR file deletion

JAR file listing display

Organization of this section

17.4.1 When an error occurs in a JAR file

17.4.2 When the server configuration is modified (HiRDB/Parallel Server only)

17.4.1 When an error occurs in a JAR file

When an error occurs in a JAR file, either each programmer must re-register the JAR file with an INSTALL JAR statement or the HiRDB administrator must re-register the JAR file with the pdjarsync command.

17.4.2 When the server configuration is modified (HiRDB/Parallel Server only)

When the HiRDB server configuration is modified, use the pdjarsync -S command to re-register the JAR files.

18. Error Handling Procedures

This chapter explains the procedures for handling HiRDB errors.

It contains the following sections:

Organization of this chapter

18.1 HiRDB processing and the HiRDB administrator's action in the event of an error

18.2 When a UAP does not execute correctly

18.3 When operation commands do not execute correctly

18.4 When HiRDB does not start

18.5 When HiRDB does not terminate

18.6 Handling of system log file errors

18.7 Handling of synchronization point dump file errors

18.8 Handling of status file errors

18.9 Handling of errors in files other than system files

18.10 When the OS terminates abnormally

18.11 Handling of errors while linked to an OLTP system

18.12 Handling of communication errors, CPU errors, and power failures

18.13 When HiRDB cannot be terminated because a user is still connected

18.14 Actions when there is an undetermined transaction

18.15 Handling of reduced activation (HiRDB/Parallel Server only)

18.16 Handling of disk errors

18.17 When a HiRDB (unit) terminates due to a system log file space shortage

18.18 When a utility terminates abnormally during execution of a reorganization with synchronization points set

18.19 Actions when page destruction in an RDAREA is detected

18.20 Actions to take when an RDAREA I/O error occurs

18.21 Checking the transaction completion type when an error occurs during commit processing (HiRDB/Parallel Server)

18.22 Actions to take when an error occurs while a local buffer is being used to update a shared table (HiRDB/Parallel Server only)

18.23 Actions to take when an error occurs in the system manager unit

18.24 Actions to take when a mismatch occurs between the original and the mirror duplicate

18.25 Recovery of HiRDB directory

18.26 Handling errors in the HiRDB file system areas

18.1 HiRDB processing and the HiRDB administrator's action in the event of an error

This section explains the following aspects of the processing by HiRDB and the actions that should be taken by the HiRDB administrator when an error occurs:

Actions to be taken by the HiRDB administrator when an error occurs

Information collected by HiRDB when an error occurs

HiRDB processing when an error occurs

Handling HiRDB processing errors

Information inherited during HiRDB restart

Facility for changing the process-down message when a transaction is cancelled

Organization of this section

18.1.1 Actions to be taken by the HiRDB administrator when an error occurs

18.1.2 Information collected by HiRDB when an error occurs

18.1.3 HiRDB processing in the event of an error

18.1.4 Handling of HiRDB process errors

18.1.5 Information inherited during a HiRDB restart

18.1.6 Facility for changing the process-down message when a transaction is cancelled

18.1.1 Actions to be taken by the HiRDB administrator when an error occurs

This section explains the actions to be taken by the HiRDB administrator when an error occurs.

Organization of this subsection

(1) Actions to be taken by the HiRDB administrator

(2) Executing the pdgeter command

(3) Deleting unneeded troubleshooting information

(4) Reducing the amount of troubleshooting information that is output

(1) Actions to be taken by the HiRDB administrator

When an error occurs, the HiRDB administrator must take the following actions:

Check the output messages and the manual HiRDB Version 8 Messages to determine the causes of the error.

Use the pdgeter command to make a backup copy of the files under $PDDIR/spool and $PDDIR/tmp to which troubleshooting information has been output

Remarks

Information needed to use problem-solving support and Q&A support services to resolve errors can be found in Appendix C. Information Needed for Troubleshooting. In the event of a problem, we recommend strongly that the HiRDB administrator always refer to Appendix C. Information Needed for Troubleshooting.

Frequently asked questions about the error handling procedures are answered in Q&A format in Section A.4 Errors.

(2) Executing the pdgeter command

When the pdgeter command is executed, a backup copy of the troubleshooting information is created under a directory in the server machine where the pdgeter command was entered. Any directory can be specified in an option of the pdgeter command. The backup copy can also be created at any device, not just in the server machine used to enter the pdgeter command (not supported in the AIX 5L version). The following is the procedure for executing the pdgeter command:

Procedure

Check that the server machine where the pdgeter command is entered has sufficient disk space to store the troubleshooting information.

Create a directory* for storing the troubleshooting information at the server machine where the pdgeter command is entered. This step is not necessary if the troubleshooting information is to be output to a device.

If troubleshooting information for a machine other than the server machine where the pdgeter command is entered is to be output to a device, a work directory is required. In such a case, create a work directory* in the server machine where the pdgeter command is entered.

Copy the pdinit control statement to $PDDIR/conf, using INITCONT as the file name. If all troubleshooting information is to be obtained (by specifying the -a option), copy the information under the file name INITCONT into $PDDIR/conf at the server machine where the pdgeter command is entered.

Copy the pdmod control statement into $PDDIR/conf. In this case, any file name can be used.

If shared memory is to be dumped (by omitting the -m option from the pdgeter command), check that there is a directory for storing a shared memory dump ($PDDIR/spool/pdshmdump) at the server machine subject to collection of troubleshooting information (the server machine with the host name specified in the -x option of the pdgeter command). If there is no such directory, create it.

Execute the pdgeter command. Specify the directories provided in steps 2 and 3 in the pdgeter command's options.

When the troubleshooting information is no longer needed, delete it with the pdcspool command (retaining it may result in a shortage of disk space).

* If this directory already exists, check whether or not it contains any of the directories or files listed below; if it contains these directories or files, the pdgeter command will result in an error.

PDDIR

lib

usr

HiRDB

(3) Deleting unneeded troubleshooting information

When a server process or client is terminated forcibly, HiRDB outputs troubleshooting information to the $PDDIR/spool directory. In addition, whenever the Ctrl + C keys are pressed to terminate a command or a utility while it is executing, the command or utility outputs a temporary work file to the $PDDIR/tmp directory, where it remains resident. If these troubleshooting and temporary work files are left on the disk, they may stress the capacity of the disk on which the HiRDB directory resides. A shortage of free space on the disk containing the HiRDB directory can cause HiRDB to terminate abnormally. To avoid such a problem, HiRDB deletes the following files periodically:

Troubleshooting information files (files in the $PDDIR/spool directory)

Temporary work files (files in the $PDDIR/tmp directory)

Normally, HiRDB deletes these files every 24 hours. You can change this deletion interval in the pd_spool_cleanup_interval operand. You can also specify that only files that were output a specified number of days previous to the current date are to be deleted; you make this specification in the pd_spool_cleanup_interval_level operand.

You can also use the following methods to all delete troubleshooting information (files in the $PDDIR/spool directory):

You can use the pdcspool command to delete troubleshooting information files. You can also use this command to delete temporary work files (files in the $PDDIR/tmp directory).

You can configure HiRDB to delete troubleshooting information files automatically when it starts. You use the pd_spool_cleanup operand to specify whether or not troubleshooting information files are to be deleted automatically. The default value for this operand is that these files are deleted automatically. You can also use the pd_spool_cleanup_level operand to specify that only troubleshooting information files that were output a specified number of days previous to the current date are to be deleted.

Reference note

To select the troubleshooting information that is to be deleted, you can specify a pdcspool command option, or you can specify a value in the pd_spool_cleanup_level or pd_spool_cleanup_interval_level operand.

Note

In some cases, troubleshooting information files that are output by commands or utilities executed by users other than the HiRDB administrator are not deleted. In these cases, a user with the privilege of deleting troubleshooting information files must delete the files with a command such as the OS's rm command.

(4) Reducing the amount of troubleshooting information that is output

You can specify the following operands to reduce the amount of troubleshooting information that is output. Specify these operands as needed.

pd_cancel_dump: Specifies whether or not troubleshooting information is to be output.

pd_client_waittime_over_abort: Specifies whether or not troubleshooting information is to be output when a client that is executing a transaction exceeds its maximum wait time (value specified in the PDCWAITTIME operand of the client environment definitions).

pd_debug_info_netstat: Specifies whether or not network information is to be output in the troubleshooting information collected when a HiRDB process or HiRDB (unit) terminates abnormally.

pd_dump_suppress_watch_time: Specifies a period of time during which re-output of troubleshooting information is to be suppressed.

18.1.2 Information collected by HiRDB when an error occurs

Table 18-1 shows the troubleshooting information that is collected by HiRDB when an error occurs.

Table 18-1 Troubleshooting information collected by HiRDB when an error occurs

Information collected
Explanation

Message log file
($PDDIR/spool/pdlog1, pdlog2)
This file consists of messages output by HiRDB; it can be viewed with the pdcat command. If an error occurs, make a backup of this file.

Standard output and standard error output when executing commands
These screens are output information of the operating command and error messages, which are displayed in the screen that the operating command is input. Save them as redirect if you needed.

Syslogfile
This file contains messages output by HiRDB.This file consists of messages output by HiRDB; it can be referenced using an OS editor. If there are too many accesses to syslogfile at the same time, some messages may not be output.

Save core file*
($PDDIR/spool/save/file-name)
This is HiRDB-related process data and stack information. Because only up to three core files are saved in each server, save core files that need to be saved should be backed up. The file name format is server-name-n, where n is the serial number (1-3) of the save core file. Note that a serial number might not be assigned in some cases.

Abort information file*
($PDDIR/spool/save/file-name)
This is a file of abort information. If this information is output, back it up. The abort codes only can be referenced using an OS editor.The file name format is abcode.server-process-ID.

Snap during an error*
($PDDIR/spool/save/file-name)
This is a file of snap information generated during an error. If this information is output, back it up. The file name format is server-name-n.deb, where n is the serial number (1 to 3) of the save core file. Note that a serial number may not be assigned in some cases.

Shared memory dump file*
($PDDIR/spool/pdshmdump/file-name)
This file consists of data maintained by HiRDB in the shared memory. If this information is output, back it up. The file name format is server-name.rmb.server-process-ID.

Simple dump file*
($PDDIR/spool/server-directory/file-name)
This file consists of data maintained by HiRDB in the shared memory and process private memory. If this information is output, back it up. The file name format is a combination of the date and process ID.

RPC trace file
This is a file of the message sent and received by HiRDB using RPC. If this information is output, back it up. The file name is specified in the pd_rpc_trace_name operand.

Command trace file
($PDDIR/spool/cmdlog1, cmdlog2)
This file consists of statistical information on executed commands (including commands generated internally by HiRDB). Use an OS editor to reference this information.If an error occurs, back up this statistical information.

Error log file
($PDDIR/spool/errlog/errlog1, errlog2)
This is a file of internal information output by HiRDB. If this information is output, back it up.

Connected users data file
($PDDIR/spool/cnctusrinf)
This file contains information on users who were connected when HiRDB terminated. Use an OS-provided text editor to view this information.

Connected users details file
($PDDIR/spool/cnctusrdtl)

Data file for locked resources management table
($PDDIR/spool/pdlckinf/output-date-and-time.mem)
This is a file of user information when deadlock, a lock-release timeout, or an error due to a space shortage in the table for managing locked resources occurs during locking by HiRDB. Use an OS-provided text editor to view this information. If this information is output, back it up.

* This is troubleshooting information that is output when a HiRDB server process terminates abnormally. Abnormal termination of a HiRDB server process can be confirmed when the KFPS01820-E message is output. The server name, process ID, and termination status can be determined from this message. Note, however, that troubleshooting information is not output in the following cases:

Termination status begins with c or d (no troubleshooting information is output)

Termination status is 0009 (the abort information, save core file, and shared memory dump file are not output)

18.1.3 HiRDB processing in the event of an error

This section explains the processing that HiRDB performs when an error occurs.

Organization of this subsection

(1) Range of applicability of an error

(2) System recovery in the event of the abnormal termination of HiRDB

(3) Consecutive occurrences of abnormal termination

(1) Range of applicability of an error

When a hardware or software error occurs in a HiRDB/Parallel Server, HiRDB isolates the affected units and terminates them abnormally, rather than shutting down all the units comprising the HiRDB (although there are some exceptions to this). When an error occurs in a HiRDB/Single Server, HiRDB terminates the unit, which results in complete shutdown of HiRDB, because a HiRDB/Single Server consists of only one unit.

(2) System recovery in the event of the abnormal termination of HiRDB

When HiRDB has terminated abnormally and it is restarted after the cause of the error has been eliminated, HiRDB restores the system to its status immediately before the error occurred.

(3) Consecutive occurrences of abnormal termination

When HiRDB terminates abnormally, the unit will usually restart automatically, depending on the specification of the pd_mode_conf operand in the system common definition. However, if HiRDB terminates abnormally three times* in succession, the unit will not restart again automatically.

In such a case, the HiRDB administrator must eliminate the cause of the error and use the pdstart command to restart HiRDB.

* The pd_term_watch_count operand can be used to specify a maximum number of consecutive abnormal terminations that can occur. For example, if pd_term_watch_count=2 is specified, HiRDB restart will not be attempted again after two consecutive abnormal terminations.

18.1.4 Handling of HiRDB process errors

If an error occurs during an HiRDB process, HiRDB terminates the process abnormally, then rolls back the process for each server by activating a recovery process. There is no need for the HiRDB administrator to take any action, because the corresponding process is restarted automatically.

Depending on the severity of the error, HiRDB may terminate abnormally the unit that is executing the erroneous process. In such a case, the HiRDB administrator must restart the abnormally terminated unit (although the unit may be restarted automatically, depending on the specification of the pd_mode_conf operand).

Described below are the actions to be taken by the HiRDB administrator when a unit terminates abnormally due to abnormal termination of a process.

Organization of this subsection

(1) HiRDB/Single Server

(2) HiRDB/Parallel Server

(1) HiRDB/Single Server

Table 18-2 shows the action to be taken by the HiRDB administrator in the event a HiRDB/Single Server terminates abnormally.

Table 18-2 HiRDB administrator's action in the event of an abnormal termination of a HiRDB/Single Server

HiRDB processing | HiRDB administrator's action
Terminates the HiRDB/Single Server abnormally | Eliminate the cause of the error and restart the HiRDB/Single Server (the HiRDB/Single Server may be restarted automatically, depending on the pd_mode_conf operand specification), then re-execute the previous processing.

(2) HiRDB/Parallel Server

Table 18-3 shows the actions to be taken by the HiRDB administrator in the event a HiRDB/Parallel Server terminates abnormally.

Table 18-3 HiRDB administrator's actions in the event of an abnormal termination of a HiRDB/Parallel Server

Error status
HiRDB processing
HiRDB administrator's action

Process error at unit controller
Terminates abnormally the unit where the corresponding process is located.
Restart the corresponding unit (the unit may be restarted automatically, depending on the pd_mode_conf operand specification).

Process error at system manager
Terminates abnormally the unit where the system manager is located. HiRDB does not accept any operation command or UAP execution request while the system manager is shut down. No message log can be collected during that time.
Eliminate the cause of the error and restart the corresponding unit (the unit may be restarted automatically, depending on the pd_mode_conf operand specification), then re-execute the previous processing.

Process error at front-end server
Terminates abnormally the unit where the front-end server is located. HiRDB does not accept any processing request while the front-end server is shut down. It treats a processing request as a timeout-level communication error.
If a front-end server process terminates abnormally, HiRDB recovers the process. If it is necessary to shut down the unit in such a case, HiRDB terminates abnormally the unit where the corresponding process is located.
Eliminate the cause of the error and restart the corresponding unit (the unit may be restarted automatically, depending on the pd_mode_conf operand specification), then re-execute the previous processing.

Process error at dictionary server
Terminates abnormally the unit where the dictionary server is located.

Process error at back-end server
Terminates abnormally the unit where the back-end server is located.

18.1.5 Information inherited during a HiRDB restart

Table 18-4 shows the information that is inherited during a HiRDB restart.

Table 18-4 Information inherited during a HiRDB restart

Classification
Information that is inherited

System files
System log files
System recovery information

Synchronization point dump files
Table recovery information

Status files

Information used to determine the system startup mode:
Server configuration

Status information about each system server:
Open/close status
Primary/standby (alternate) status
File shutdown status
Service group shutdown status

RDAREA-related information

User data (database)
RDAREAs

Open/close status

Shutdown status*

Operation commands (status changes made by the commands shown at the right are inherited)
Database manipulation commands

pdclose (close RDAREA)

pdopen (open RDAREA)

pdhold (shut down RDAREA)*

pdrels (release RDAREA from shutdown status)

Commands for manipulating system log files or synchronization point dump files

pdlogadpf (allocate file)

pdlogchg (change file status)

pdlogcls (close file)

pdlogopen (open file)

pdlogswap (swap files)

pdlogunld (unload file)

Commands for manipulating status files

pdstscls (close file)

pdstsopen (open file)

pdstsswap (swap files)

Commands for output of audit trails

pdaudbegin command (begin collection of audit trail)

pdaudend command (end collection of audit trail)

Note

The following information is not inherited (these commands must be entered again after HiRDB is restarted):

pdstbegin (start collection of statistical information)

pdstend (terminate collection of statistical information)

* The following hold statuses are not inherited:

Referencing-permitted backup-hold (update WAIT mode)

Updatable backup-hold

Updatable backup-hold (WAIT mode)

18.1.6 Facility for changing the process-down message when a transaction is cancelled

Organization of this subsection

(1) Overview

(2) Function

(1) Overview

If a server process is terminated by a forced termination request due to an interrupt at the client during transaction execution, or if a server process connected to a UAP is terminated by the pdcancel command, HiRDB displays the KFPS01820-E and KFPO00105-E messages that indicate termination of the server process. These messages are also displayed when a server process is terminated due to some abnormality in the server's processing. To determine the cause of such a termination, you must also check other messages, such as KFPS00993-I, that are displayed by HiRDB.

Use of the facility for changing the process-down message when a transaction is cancelled enables you to change the IDs of the KFPS01820-E and KFPO00105-E messages that are displayed in the case of client-related operations and errors. When you do this, you can easily identify a termination of server processing that was caused by a client-related operation or error simply by checking the message IDs (eliminating the need to check other messages).

(2) Function

This facility changes only the message IDs; it does not change the message text or output information (the original message text and output information are still displayed as is even after the message ID has been changed).

(a) Messages subject to change

Table 18-5 lists the messages that can be changed by this facility.

Table 18-5 Messages whose message IDs can be changed

Message ID that can be changed | Description of the message | Message ID after change
KFPS01820-E | Server process was terminated. | KFPS01852-W
KFPO00105-E | Server process was terminated because an error occurred (abort message). | KFPO00115-W

For details about these messages, see the manual HiRDB Version 8 Messages.

(b) Whether or not message IDs are changed

Table 18-6 shows whether or not message IDs are changed, depending on the process-down event.

Table 18-6 Whether or not message IDs are changed depending on the process-down event

No. | Proc-down event | Cause of process-down | Msg ID chgd | Remarks
User op | Env set | Client error | Client comm err | Serv error | S-to-S comm error
1 | Forced termination request due to an interrupt at the client | C | -- | -- | -- | -- | -- | Yes | HiRDB server process was terminated during execution of a transaction due to a forced termination request caused by an interrupt at the client.#1
2 | HiRDB server process killed due to a client process-down | -- | -- | C | C | -- | -- | Yes | For a client process using XA, see No. 11.
3 | HiRDB server process killed because PDCWAITTIME was exceeded | -- | C#2 | -- | C | C | -- | No | HiRDB cannot identify the cause.#3
4 | Process-down (exit) at HiRDB server because PDSWAITTIME was exceeded | -- | C | C | C | -- | -- | Yes | --
5 | Process-down (exit) at HiRDB server because PDSWATCHTIME was exceeded | -- | C | C | C | -- | -- | Yes | --
6 | HiRDB server process killed due to forced termination of unit, unit down, or transaction recovery during system switchover | C | -- | -- | -- | --#4 | --#4 | Yes | Applicable to another unit's branch recovery. This is applicable only to a HiRDB/Parallel Server.
7 | HiRDB server process killed due to forced termination of unit, unit down, or utility branch recovery during system switchover | C | -- | -- | -- | --#4 | --#4 | Yes | Applicable not only to recovery in the local unit but also to another unit's branch recovery.
8 | HiRDB server killed by pdcancel command (including a killed utility) | C | -- | --#4 | -- | --#4 | --#4 | Yes | --
9 | HiRDB server process killed due to forced termination of transaction by pdfgt command (transaction branch recovery) | C | -- | --#4 | -- | --#4 | --#4 | Yes | --
10 | HiRDB server process killed by the facility for monitoring free area for system log file | C#5 | C#6 | -- | -- | -- | -- | Yes | KFPS01160-E message is displayed.
11 | HiRDB server process killed by XA completion instruction issued by the transaction manager in an extension of transaction recovery | C | -- | -- | -- | C | C | No | HiRDB cannot identify the cause.#7
12 | HiRDB server process killed due to recovery when the synchronization skip count exceeded the boundary value | C#8 | C#6 | -- | -- | C | -- | No | HiRDB cannot determine the cause.
13 | Process-down (exit) at HiRDB server due to timeout during communication between HiRDB server processes | -- | -- | -- | -- | C | C | No | --
14 | Communication request processing from a shutdown unit when recovery- unnecessary front-end server is used | -- | -- | -- | -- | C | C | No | --
15 | Process-down (exit) at server due to transaction completion error when recovery- unnecessary front-end server is used | -- | -- | -- | -- | C | C | No | --
16 | Process-down at HiRDB server when automatic log unloading facility was terminated due to a server failure | -- | -- | -- | -- | C | C | No | --
17 | HiRDB server process failure shutdown (such as internal failure, process failure, or transaction start error) | -- | -- | -- | -- | C | C | No | --
18 | HiRDB server process killed during transaction and utility branch recovery due to HiRDB server process failure shutdown | -- | -- | -- | -- | --#4 | --#4 | Yes | Recovery processing caused by No. 17.

Legend:

Proc-down event: Process-down event

User op: User operation

Env set: Environment settings

Client comm err: Client communication error

Serv error: Server error

S-to-S comm error: Server-to-server communication error

Msg ID chgd: Message ID changed

C: Considered to be the cause of the process-down.

--: Not the cause of the process-down.

Yes: Message is changed.

No: Message is not changed.

#1

This is applicable to UAPs that use DBPARTNER or DABroker to access HiRDB, and to UAPs that access HiRDB via ODBC. This also includes cases such as when the applicable UAP is terminated by pressing the Ctrl + C keys on the keyboard.

#2

Applicable when the value is less than the transaction processing time.

#3

This requires user judgment because HiRDB cannot determine whether this is a timeout caused by environment settings or by a server failure. For this reason, message output is required.

#4

Although this is not an error event, it can cause an error event.

#5

Applicable when the volume of transactions exceeds the expected value.

#6

Applicable when a boundary value is invalid.

#7

This is caused by a completion instruction from the transaction manager. If a transaction is cancelled due to a client failure, by the user, or due to a server failure, the transaction manager issues a completion instruction. In this case, HiRDB cannot identify the cause of the completion instruction.

#8

Applicable when the issued SQL statement is invalid.

(c) Unneeded operands

To use this facility, either omit the pd_cancel_down_msgchange operand or specify Y.

If you have specified v6compatible or v7compatible in the pd_sysdef_default_option operand, the default value of the pd_cancel_down_msgchange operand is set to N; therefore, you must specify Y in the pd_cancel_down_msgchange operand.

18.2 When a UAP does not execute correctly

Executor: HiRDB administrator

This section explains the actions to be taken when a UAP does not execute correctly.

Organization of this section

(1) Actions to be taken when a UAP will not execute

(2) Actions to be taken when a UAP does not terminate itself

(3) Actions to be taken when a UAP terminates abnormally

(1) Actions to be taken when a UAP will not execute

Table 18-7 lists the possible reasons for UAP execution errors.

Table 18-7 Causes of UAP execution errors and actions to be taken

Possible cause
Action to be taken

An HiRDB system definition is invalid
A message is displayed indicating the HiRDB system definition that is invalid. Correct the definition on the basis of this message.

Memory is insufficient
A message is issued indicating the memory where the shortage occurred. For shared memory, reevaluate the HiRDB system definitions. For process private memory, terminate any unneeded processes.

Too many users are executing concurrently

Increase the value of the pd_max_users operand.

If the maximum number of server processes for front-end server or single server has been changed with the pdchprc command, increase the maximum value.

An environment variable is invalid in the client environment definition
See the manual HiRDB Version 8 UAP Development Guide and correct the environment variable.

HiRDB has not been started
Start HiRDB.
For a HiRDB/Parallel Server, a specific unit or server may be shut down; in such a case, start the unit or server.

(2) Actions to be taken when a UAP does not terminate itself

Check the UAP's execution status (for the procedure, see 8.2 When a UAP or utility execution takes too long). If necessary, use the pdcancel command to terminate the UAP forcibly.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(3) Actions to be taken when a UAP terminates abnormally

If a UAP terminates abnormally, use the pdls -d prc command to check for any remaining UAP processes. If there are any remaining UAP processes, terminate them with the pdcancel command.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

18.3 When operation commands do not execute correctly

This section explains the actions to be taken when operation commands do not execute correctly.

Organization of this section

18.3.1 Actions to be taken when operation commands will not execute

18.3.2 Actions to be taken when an operation command results in a timeout while waiting for a response

18.3.1 Actions to be taken when operation commands will not execute

Executor: Operation command executor or HiRDB administrator

Table 18-8 lists the possible causes of operation command execution errors.

Table 18-8 Possible causes of operation command execution errors and actions to be taken

Possible cause
Action to be taken

An invalid option or argument was specified in the operation command.
Correct the option or argument and re-execute the operation command.

The user does not have the required privilege to execute the operation command.
Refer to the HiRDB Version 8 Command Reference For details on user execution privileges for operation commands. If the user does not have the required execution privilege, either ask an authorized user to execute the command or obtain the required execution privilege.

A command available only while HiRDB is active was executed while HiRDB was inactive.
Check the HiRDB Version 8 Command Reference for whether or not the command can be executed while HiRDB is inactive. If the command is available only while HiRDB is active, start HiRDB and execute the command.

An operation command execution environment has not been set up.
Check that the following environment setup is correct:

Environment variables

Remote shell execution environment

For details on these environment setup procedures, see the manual HiRDB Version 8 Installation and Design Guide.

An HiRDB system definition is invalid.
See the manual HiRDB Version 8 System Definition and correct the HiRDB system definition.

18.3.2 Actions to be taken when an operation command results in a timeout while waiting for a response

Executor: Operation command executor

An operation command may result in a timeout in the following cases:

Processing was not completed within the response wait time because the OS workload was too high.

An operation command was executed while HiRDB was inactive.

If the OS workload is high, re-execute the operation command. If the response wait timeout recurs, terminate any unneeded processes before re-executing the operation command.

18.4 When HiRDB does not start

This section explains the actions to be taken when HiRDB does not start. The following items are explained:

When HiRDB does not start normally

When HiRDB does not restart

Actions when an error occurs in the master directory RDAREA

Actions when other errors occur

Organization of this section

18.4.1 When HiRDB does not start normally

18.4.2 When HiRDB does not restart

18.4.3 Actions to be taken in the event of an error in the master directory RDAREA

18.4.4 Actions to be taken in the event of other errors

18.4.1 When HiRDB does not start normally

Executor: HiRDB administrator

Table 18-9 lists the possible causes of errors during HiRDB normal startup.

Table 18-9 Possible causes of errors during HiRDB normal startup and actions to be taken

Possible cause
Action to be taken

HiRDB has not been installed or was not set up correctly.
Install HiRDB or set up HiRDB correctly.

An HiRDB system definition is invalid.
A message is displayed indicating the HiRDB system definition that is invalid. Correct the HiRDB system definition on the basis of this message.

An environment variable definition is invalid.
Correct the environment variable. For details on the environment variable setup procedures, see the manual HiRDB Version 8 Installation and Design Guide.

A remote shell execution environment has not been set up.
Set up the remote shell execution environment; for details, see the manual HiRDB Version 8 Installation and Design Guide.

A memory shortage or file space shortage occurred.
A message reporting the memory or file space shortage is displayed. Either terminate any unneeded processes or delete unneeded files. In the case of shared memory, reevaluate the HiRDB system definitions. In the case of process private memory, terminate any unneeded processes.
Also, reevaluate the OS's shared memory-related operating system parameters, as required. For details on the operating system parameters, see the manual HiRDB Version 8 Installation and Design Guide.

A file required for HiRDB startup is missing.
A message is displayed indicating the file required for HiRDB startup that is missing. Create the required file on the basis of this message.

An error occurred in a file required for HiRDB startup.
Check the erroneous file on the basis of the message, then take appropriate action by referencing Sections 18.6 Handling of system log file errors to 18.9 Handling of errors in files other than system files.

The OS configuration is not appropriate to the HiRDB execution environment.
Reconfigure the OS and correct the HiRDB system definitions.

The current system log file cannot be allocated.
Place the system log file waiting to be unloaded in unload completed status with the pdlogunld or pdlogchg command.

An error has occurred in a particular unit (HiRDB/Parallel Server only).
A HiRDB/Parallel Server will not start if any of its units cannot be started. If an error occurs in a unit, HiRDB cannot start until the unit's error is corrected. However, HiRDB can be started using only the normal units if reduced activation is in effect. For details on reduced activation, see 18.15 Handling of reduced activation (HiRDB/Parallel Server only).

A library is not shared correctly (applicable to a multi-HiRDB).
Share the library correctly; for details, see the manual HiRDB Version 8 Installation and Design Guide.

Remarks

Frequently asked questions about errors during HiRDB startup are answered in Q&A format in Section A.6 HiRDB startup.

18.4.2 When HiRDB does not restart

Executor: HiRDB administrator

When a HiRDB restart fails, see the message that is displayed during restart processing. Table 18-10 lists the possible causes.

Table 18-10 Possible causes of HiRDB restart errors and actions to be taken

Possible cause
Action to be taken

HiRDB cannot be restarted due to an error in both versions of the current system log file.
See 18.6.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file.

HiRDB cannot be restarted because there is no system log file in swappable target status.
See 18.17 When a HiRDB (unit) terminates due to a system log file space shortage.

HiRDB cannot be restarted because the system log file corresponding to a synchronization point dump file has been overwritten.
See 18.7(2) Actions to be taken when HiRDB cannot be restarted because the system log file corresponding to a synchronization point dump file has been overwritten.

HiRDB cannot be restarted because there are not enough synchronization point dump files.
See 18.7(3) Actions to be taken when HiRDB cannot be restarted due to an insufficient number of synchronization point dump files.

HiRDB cannot be restarted due to an error on both versions of the current status file.
See 18.6.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file.

An error has occurred in a particular unit (HiRDB/Parallel Server only).
A HiRDB/Parallel Server will not start if any of its units cannot be started. If an error occurs in a unit, HiRDB cannot start until the unit's error is corrected. However, HiRDB can be started using only the normal units if reduced activation is in effect. For details on reduced activation, see 18.15 Handling of reduced activation (HiRDB/Parallel Server only).

HiRDB cannot be restarted due to an error in the master directory RDAREA.
See 18.4.3 Actions to be taken in the event of an error in the master directory RDAREA.

HiRDB cannot be restarted due to some other error.
See 18.4.4 Actions to be taken in the event of other errors.

18.4.3 Actions to be taken in the event of an error in the master directory RDAREA

If an error occurs in the master directory RDAREA, HiRDB cannot be restarted. In such a case, the following procedure must be used to restore the RDAREA:

Procedure

To restore the RDAREA:

Enter the pdstart -r command to start HiRDB.

Use the pdrstr command to restore the master directory RDAREA:
pdrstr -m /rdarea/mast/mast01 -b /pdcopy/backup01
-l /unld/unldlog01,/unld/unldlog02 -w /tmp/sortwork/
-r PDBMAST

Enter the pdstop command to terminate HiRDB.

Enter the pdstart command to start HiRDB.

Use the pdclose command to close the erroneous RDAREA (master directory RDAREA):
pdclose -r rdarea01,rdarea02

Use the database recovery utility (pdrstr command) to restore the RDAREA:
pdrstr -m /rdarea/mast/mast01 -b /pdcopy/backup01
-l /unld/unldlog01,/unld/unldlog02 -w /tmp/sortwork/
-r rdarea01,rdarea02

Use the pdrels -o command to release the restored RDAREA from shutdown status and then open it:
pdrels rdarea01,rdarea02 -o

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

18.4.4 Actions to be taken in the event of other errors

Organization of this subsection

(1) When the HiRDB process registered in the OS is not active

(2) When the HiRDB process registered in the OS is active

(1) When the HiRDB process registered in the OS is not active

The HiRDB process registered with the pdsetup command may not be active for some reason.

The OS attempts to activate the process. If this attempt fails the specified number of times, the process will no longer start and it will not be possible to start HiRDB by entering the pdstart command. The following procedure should be executed in such a case:

Procedure

Use the OS's ps command to check in the HiRDB directory for the process that is being executed.

If the process is not active, enter the pdsetup -d command.

Enter the pdsetup command.

If the server machine is shut down due to a power failure during HiRDB operation, the same event may occur immediately after power is restored and the OS is started due to a disk error in the HiRDB directory. In such a case, the same action should be taken.

(2) When the HiRDB process registered in the OS is active

Procedure

A message is displayed when the pdstart command is entered. Eliminate the cause of the error on the basis of this message.

Use the pdsetup -d command to delete the HiRDB process from the OS.

Enter the pdsetup command.

18.5 When HiRDB does not terminate

Executor: HiRDB administrator

This section explains the actions to be taken when HiRDB will not terminate. Table 18-11 lists the possible causes that prevent HiRDB from terminating.

Table 18-11 Possible causes that prevent HiRDB from terminating and actions to be taken

Possible cause | Actions
A user is still connected. | As long as a user is still connected, HiRDB cannot terminate. For details on the actions to be taken in such a case, see 18.13 When HiRDB cannot be terminated because a user is still connected.
There is an undetermined transaction | If there is an undetermined transaction, HiRDB cannot be terminated. For details on the actions to be taken in such a case, see 18.14 Actions when there is an undetermined transaction.
Communication error occurred | When a utility special unit is used or in the case of a HiRDB/Parallel Server, it may not be possible to terminate HiRDB because of a communication error between servers. For details on the actions to be taken in such a case, see 18.12.1 Handling of communication errors.

18.6 Handling of system log file errors

This section discusses the following topics:

Actions to be taken in the event of an error in the current file

Actions to be taken when HiRDB Datareplicator is being used

Actions to be taken when HiRDB (unit) cannot be restarted due to an error in both versions of the current file

Organization of this section

18.6.1 Actions to be taken in the event of an error in the current file

18.6.2 Actions to be taken when HiRDB Datareplicator is being used

18.6.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file

18.6.1 Actions to be taken in the event of an error in the current file

Organization of this subsection

(1) Error during HiRDB operation

(2) Error during HiRDB restart processing

(3) Placing an erroneous file in swappable target status

(4) Actions to be taken in the event of a disk error

(1) Error during HiRDB operation

Table 18-12 shows the actions to be taken in the event of an error in the current file during HiRDB operation.

Table 18-12 Actions to be taken in the event of an error in the current file during HiRDB operation

Condition at the time of an error
HiRDB processing
HiRDB administrator's action

Write operation
There are files in swappable target status.
Swaps the system log files.
Places the erroneous system log file in reserved status, and places in current status one of the files in swappable target status, then resumes processing.

If application history is required, unload the reserved system log file with the pdlogunld command.

Place the erroneous file in swappable target status with the method shown in (3).

There are no files in swappable target status.
Terminates abnormally the unit containing the erroneous system log file.
See 18.17 When a HiRDB (unit) terminates due to a system log file space shortage.

Create a file that can be placed in swappable target status, then restart HiRDB.

Place the erroneous file in swappable target status with the method shown in (3).

Read operation
Dual system log files are used.
Switches to the normal file version and resumes processing.
Place the erroneous file in swappable target status with the method shown in (3).

Dual system log files are not used.
Places the erroneous system log file in reserved status and cancels processing.

If the erroneous system log file has not been unloaded, unload it with the pdlogunld command.*

Recover the database from a backup copy of the unload log file and the created unload log file using the database recovery utility. For details on the database recovery utility, see 19. Database Recovery Procedures.

Place the erroneous file in swappable target status with the method shown in (3).

* When checking of the unload operation has been released (pd_log_unload_check=N is specified), this action is not required.

(2) Error during HiRDB restart processing

Table 18-13 shows the actions to be taken in the event of an error in the current file during HiRDB restart processing.

Table 18-13 Actions to be taken in the event of an error in the current file during HiRDB restart processing

Condition at the time of an error
HiRDB processing
HiRDB administrator's action

Dual system log files are used
Switches to the normal file version and resumes processing.
After restarting HiRDB, place the erroneous file in swappable target status with the method shown in (3).

Dual system log files are not used
Places the erroneous system log file in reserved status and terminates restart processing of the unit containing the erroneous system log file.

If the erroneous system log file has not been unloaded, unload it with the pdlogunld command, then start the unit forcibly.

Recover the database from a backup copy of the unload log file and created unload log file using the database recovery utility. For details on the database recovery utility, see 19. Database Recovery Procedures.

Place the erroneous system log file in swappable target status with the method shown in (3).

(3) Placing an erroneous file in swappable target status

Procedure

To place an erroneous file in swappable target status:

Use the pdlogls command to determine the system log file that was placed in reserved status due to an error:
pdlogls -d sys -s b001

Use the pdlogrm command to delete the system log files in reserved status:
pdlogrm -d sys -s b001 -f /sysfile/syslog1a
pdlogrm -d sys -s b001 -f /sysfile/syslog1b

Use the pdloginit command to re-create the system log files that were deleted in step 2:
pdloginit -d sys -s b001 -f /sysfile/syslog1a -n 5000
pdloginit -d sys -s b001 -f /sysfile/syslog1b -n 5000

Use the pdlogopen command to place in swappable target status the system log files that were re-created in step 3:
pdlogopen -d sys -s b001 -g syslog01

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(4) Actions to be taken in the event of a disk error

The actions to be taken in the event of a disk error are explained below by way of an example.

Example

An error occurred in one of the current file versions due to a disk error. Because a swappable target file was available, HiRDB swapped the system log files and continued operation.

Action

If online operation is continued as is and there is not enough space in the system log file, the unit may terminate abnormally due to a shortage of space in the system log file. In this case, immediately swap disks and take the action shown in Procedure 1 below.

If disks cannot be swapped immediately, take the action shown in Procedure 2. If neither Procedure 1 nor Procedure 2 can be executed immediately, take the action shown in Procedure 3 below.

Procedure 1: When disks can be swapped immediately

To continue the operation:

Enter the pdstop command to terminate HiRDB normally.

Swap disks and use the pdfmkfs command to create a HiRDB file system area.

Use the pdloginit command to create a system log file.

Enter the pdstart command to start HiRDB normally.

Procedure 2: When disks cannot be swapped immediately

To correct the shortage of disk space:

Enter the pdstop command to terminate HiRDB normally.

Use the pdloginit command to create a system log file in a HiRDB file system area that has sufficient space.

Modify the following server definition operands (i.e., add operands for the system log file that was added):
pdlogadfg
pdlogadpf

Enter the pdstart command to HiRDB start normally.

Procedure 3: Neither Procedure 1 nor Procedure 2 can be executed immediately

To continue the operation temporarily:

Enter the pdstop command to terminate HiRDB normally.

Specify pd_log_singleoperation=Y (to implement the single operation mode for the system log file) in the server definition for the erroneous system log file.

Enter the pdstart command to start HiRDB normally.

Note

If Procedure 3 is used and an error occurs in the system log file during single operation, the database cannot be recovered from the unload log (system log). Therefore, Procedure 1 or Procedure 2 should be used as an immediate measure when possible and Procedure 3 should be used as a temporary measure only.

18.6.2 Actions to be taken when HiRDB Datareplicator is being used

If an input error occurs in the system log file (or in both versions of the system log file when dual system log files are being used) and the system log file is required for data linkage while HiRDB Datareplicator is being used, data linkage becomes unavailable. In such a case, the following action must be taken:

Procedure

To restore data linkage availability:

Enter the pdrplstop command to terminate HiRDB Datareplicator linkage.

To restart HiRDB Datareplicator linkage after correcting the error in the system log file, enter the pdrplstart command. Once HiRDB Datareplicator linkage is cancelled, conformity may be lost between the extracted database and the target database subject to data linkage. Therefore, before entering the pdrplstart command, it is important to re-create the target database on the basis of the extracted database.

18.6.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file

If an error occurs on both versions of the current file, information needed to restart HiRDB (unit) is lost and HiRDB can no longer be restarted. In such a case, the pdstart dbdestroy command must be used to start HiRDB forcibly.

When HiRDB is restarted in this manner, it does not inherit information that was in effect during the previous session. Therefore, the HiRDB administrator must recover the database by executing the database recovery utility using a backup copy and the system log (unload log) as the input information. For details on the database recovery utility, see 19. Database Recovery Procedures.

Before executing forced startup of HiRDB, see 1.6.2 Notes on forced startup of HiRDB (or a unit).

Note

The database should be placed in inaccessible status (by placing the corresponding RDAREAs in command shutdown and closed status with the pdhold -c command) until the database has been recovered.

When HiRDB is started forcibly, all RDAREAs (including system RDAREAs) that were updated during the previous HiRDB session are destroyed. These RDAREAs must be recovered with the database recovery utility. If they are not recovered, subsequent HiRDB operations cannot be guaranteed.

18.7 Handling of synchronization point dump file errors

Table 18-14 shows the actions to be taken in the event of an error in a synchronization point dump file.

Table 18-14 Actions to be taken in the event of an error in a synchronization point dump file

Condition at the time of an error
HiRDB processing
HiRDB administrator's action

Write operation
There are files in overwrite enabled status
Places the erroneous synchronization point dump file in reserved status and resumes processing using one of the files in overwrite-enabled status.
Place the erroneous synchronization point dump file in overwrite enabled status with the procedure shown in (1).

There are no files in overwrite enabled status
Terminates abnormally the unit containing the erroneous synchronization point dump file.

Create a new synchronization point dump file and then restart the unit.

After restarting the unit, place the erroneous synchronization point dump file in overwrite enabled status with the procedure shown in (1).

Read operation
If HiRDB cannot read the file of the most recent generation, it attempts to read the file of the immediately preceding generation. If HiRDB cannot read that file either, it attempts to read the file immediately preceding that one. In this manner, HiRDB continues attempting to read a valid synchronization point dump file by tracking back through the file generations. However, if all of these attempts are unsuccessful (if the number of guaranteed valid generations is exceeded), it may mean that the system is not recoverable because the system logs needed to recover the system have been overwritten.
If dual synchronization point dump files are maintained
If HiRDB cannot read file A, it attempts to read file B. If HiRDB cannot read file B, it attempts to read file A of the immediately preceding generation, and so on.
Place the erroneous synchronization point dump file in overwrite enabled status with the procedure shown in (1).

Organization of this section

(1) Procedure for placing an erroneous file in overwrite enabled status

(2) Actions to be taken when HiRDB cannot be restarted because the system log file corresponding to a synchronization point dump file has been overwritten

(3) Actions to be taken when HiRDB cannot be restarted due to an insufficient number of synchronization point dump files

(1) Procedure for placing an erroneous file in overwrite enabled status

Procedure

To place an erroneous file in overwrite enabled status:

Use the pdlogls command to determine the synchronization point dump file that has been reserved due to an error:
pdlogls -d spd -s b001

If the erroneous file is not reserved, use the pdlogcls command to place it in reserved status:
pdlogcls -d spd -s b001 -g spdfile1

Use the pdlogrm command to delete the reserved synchronization point dump file:
pdlogrm -d spd -s b001 -f /sysfile/sync01

Use the pdloginit command to re-create the synchronization point dump file that was deleted in step 3:
pdloginit -d spd -s b001 -f /sysfile/sync01 -n 5000

Use the pdlogopen command to place the synchronization point dump file re-created in 4 in overwrite enabled status:
pdlogopen -d spd -s b001 -g spdfile1

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(2) Actions to be taken when HiRDB cannot be restarted because the system log file corresponding to a synchronization point dump file has been overwritten

If an error occurs in a synchronization point dump file, HiRDB attempts system recovery using the preceding generation of the synchronization point dump file. If data is written over the system log file corresponding to the synchronization point dump file (the system log file containing the information needed for system recovery), HiRDB cannot be restarted. In such a case, the pdstart dbdestroy command must be used to start HiRDB forcibly.

In such a case, HiRDB does not inherit information that was in effect during the previous HiRDB session. Therefore, the HiRDB administrator must recover the database. To recover the database, the database recovery utility is executed using the backup copy and system log (unload log) as the input information. For details on the database recovery procedure, see 19. Database Recovery Procedures.

Before executing forced startup of HiRDB, see 1.6.2 Notes on forced startup of HiRDB (or a unit).

Note

Until the database has been recovered, the database must be kept inaccessible (place its RDAREAs in command shutdown and closed status with the pdhold -c command).

When HiRDB is started forcibly, all RDAREAs that were updated during the previous HiRDB session (including system RDAREAs) are destroyed. The destroyed RDAREAs must be recovered by the database recovery utility; otherwise, subsequent HiRDB operations cannot be guaranteed.

RDAREAs are recovered from the system log only. See the KFPS01262-I message that was output when the previous pdstart command failed, and use as the input information to the database recovery utility the file group whose name is displayed as the log reading start file group and the subsequent system log.

(3) Actions to be taken when HiRDB cannot be restarted due to an insufficient number of synchronization point dump files

If the number of synchronization point dump files is less than the number of guaranteed valid generations, HiRDB cannot be restarted. In such a case, take one of the following actions and then restart HiRDB:

Re-create the synchronization point dump file resulting in an error.

Specify ONL in the pdlogadfg -d spd operand for all synchronization point dump files (if not specified already).

The length of time HiRDB is shut down can be reduced by specifying the following operands:

pd_spd_reduce_mode=1 or pd_spd_reduce_mode=2

pd_spd_reserved_file_auto_open=Y

18.8 Handling of status file errors

This section explains the actions to be taken when status file errors occur. It discusses the following topics:

Actions to be taken in the event of an error in the current file

Procedures for starting HiRDB (unit) while there is an erroneous status file

Actions to be taken when HiRDB (unit) cannot be restarted due to an error in both versions of the current file

Organization of this section

18.8.1 Actions to be taken in the event of an error in the current file

18.8.2 Procedure for starting a HiRDB (unit) while there is an erroneous status file

18.8.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file

18.8.1 Actions to be taken in the event of an error in the current file

Table 18-15 shows the actions to be taken in the event of an error in the current file.

Table 18-15 Actions to be taken in the event of an error in the current file

Item
Condition at the time of an error
HiRDB processing
HiRDB administrator's action

1
There are spare files.
Swaps the status files. Also issues the KFPS01062-I is output.
Shuts down the erroneous file and resumes processing using one of the spare files as the current file.
Place the shutdown status file in spare status with the procedure shown in (1).

2
There are no spare files.
Single operation of status file specified¹
Resumes processing, placing the status file in single operation mode. Also issues the KFPS01044-I message.
Create a spare file immediately and return the status file operation mode to double operation.
Use the procedure shown in (1) or (2) to create a spare file. Then use the procedure shown in (3) to set a spare file as the current file.

3
Single operation of status file not specified²
Abnormally terminates the unit containing the erroneous status file.
Create a new status file and then restart the unit. For details about restarting the unit, see 18.8.2 Procedure for starting a HiRDB (unit) while there is an erroneous status file.
Then place the shutdown status file in spare status with the procedure shown in (1).

4
Error during single operation or error in both file versions during double operation
Abnormally terminates the unit containing the erroneous status file.
The unit cannot be restarted because needed information has been lost. See 18.8.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file.
If there is no spare status file, create a new status file before starting the unit forcibly.

¹ Applicable when pd_syssts_singleoperation=continue was specified in the unit control information definition or pd_sts_singleoperation=continue was specified in the server definition.

² Applicable when pd_syssts_singleoperation=stop (default value) was specified in the unit control information definition or pd_sts_singleoperation=stop (default value) was specified in the server definition.

Organization of this subsection

(1) Placing shutdown files in spare status

(2) Placing reserved files in spare status

(3) Setting a reserved file as the current file

(1) Placing shutdown files in spare status

Procedure

Use the pdls command to check for status files that have been shut down.
For unit status files:
pdls -d sts -u UNT1
For server status files:
pdls -d sts -s b001

Check if an error has occurred at the disk storing status files that have been shut down. If an error has occurred, correct the error. Also check for a physical error (such as physical damage or a power outage), and for an OS or disk driver error; also check that the disk is enabled.

Use the pdstsrm command to delete the status files in shutdown status.
For unit status files:
pdstsrm -u UNT1 -f /sysfile/usts1a
pdstsrm -u UNT1 -f /sysfile/usts1b
For server status files:
pdstsrm -s b001 -f /sysfile/sstsb1a
pdstsrm -s b001 -f /sysfile/sstsb1b

Use the pdstsinit command to re-create the status files that were deleted in step 3.
For unit status files:
pdstsinit -u UNT1 -f /sysfile/usts1a -l 4096 -c 256
pdstsinit -u UNT1 -f /sysfile/usts1b -l 4096 -c 256
For server status files:
pdstsinit -s b001 -f /sysfile/sstsb1a -l 4096 -c 256
pdstsinit -s b001 -f /sysfile/sstsb1b -l 4096 -c 256

Use the pdstsopen command to place in spare status the status files that were re-created in step 4.
For unit status files:
pdstsopen -u UNT1 -f /sysfile/usts1a
pdstsopen -u UNT1 -f /sysfile/usts1b
For server status files:
pdstsopen -s b001 -f /sysfile/sstsb1a
pdstsopen -s b001 -f /sysfile/sstsb1b

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(2) Placing reserved files in spare status

Procedure

Use the pdls command to check for reserved status files.
For unit status files:
pdls -d sts -u UNT1
For server status files:
pdls -d sts -s b001

Use the pdstsopen command to place the reserved status files in spare status.
For unit status files:
pdstsopen -u UNT1 -n usts1a
For server status files:
pdstsopen -s b001 -n sstsb01

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(3) Setting a reserved file as the current file

Procedure

Use the pdstsswap command to set a reserved file as the current file.
For a unit status file:
pdstsswap -u UNT1
For a server status file:
pdstsswap -s b001

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

18.8.2 Procedure for starting a HiRDB (unit) while there is an erroneous status file

Figure 18-1 shows the procedure for starting a HiRDB (unit) while there is an erroneous status file.

Figure 18-1 Procedure for starting a HiRDB (unit) while there is an erroneous status file

Note

The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 5 is explained in paragraph (5) below.

Figure 18-2 Actions to be taken when an error occurs in a status file

Note

The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 8 is explained in paragraph (8) below.

Organization of this subsection

(1) Checking for a disk error

(2) Correcting a disk error

(3) Checking for a status file error

(4) Restarting HiRDB

(5) Restoring the status file in which the error occurred

(6) Check if single operation is being used

(7) Checking if HiRDB can identify the current file that was in effect during the previous session

(8) Using the current file identification facility

(9) Identifying the current file that was in effect during the previous session

(10) Checking if the identified current file is normal

(11) Specifying the identified current file

(1) Checking for a disk error

Check if a disk error has occurred at the disk that stores the status file in which the error occurred. Check for a physical error (such as physical damage or a power outage), as well as for an OS or disk driver error; also check that the disk is enabled.

Table 18-16 shows how to determine if a physical error has occurred at the disk.

Table 18-16 Determining if a physical error has occurred at the disk (physical error check)

Has a disk error occurred? | Is the physical error recoverable? | Status file data | Determination result
No |  |  | No physical error
Yes | Yes | Data remains.
Data has been lost. | Physical error occurred (no entity)
No |

Legend:

: Not applicable

Note

Regardless of whether or not a disk error has occurred, unless otherwise indicated, do not use the pdstsinit, pdstsrm, or pdfmkfs command until error recovery is completed.

(2) Correcting a disk error

If the check identifies a disk error, correct it. If it is not possible to correct the error, start HiRDB with the remaining normal disks only.

(3) Checking for a status file error

Check for an error in a status file. Table 18-17 shows how to determine if a logical error has occurred.

Table 18-17 Determining if a logical error has occurred (logical error check)

Command execution | Results displayed by the command (compared to the values specified at the time of file creation) | Determination result
Terminated normally | No inconsistency | No logical error
Inconsistency found | Logical error occurred
Terminated abnormally (error message is output) |  | Logical error occurred

Legend:

: Not applicable

Execute the pdcat command for a status file in which no physical error has occurred and check for an error in its contents. The status file is normal if both the following conditions are satisfied:

The record size displayed in the execution results of the pdcat command matches the record size specified when the status file was created.

No error message was output during execution of the pdcat command.

An example of execution of the pdcat command follows:

pdcat -d sts -u UNT1 -f /sysfile/usts1a -v        ...1
pdcat -d sts -s b001 -f /sysfile/sstsb1a -v       ...2

Explanation

Command execution example for a unit status file.

Command execution example for a server status file.

If neither a physical error nor a logical error has occurred, proceed to the next step. If a physical error or a logical error has occurred, take the appropriate actions described in Figure 18-2 Actions to be taken when an error occurs in a status file.

(4) Restarting HiRDB

Use the pdstart command to restart HiRDB. If HiRDB cannot be restarted, take the appropriate actions described in 18.8.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file.

(5) Restoring the status file in which the error occurred

If an error has occurred in one of the current files, the HiRDB administrator must immediately take the appropriate action described in Table 18-15 Actions to be taken in the event of an error in the current file.

If a file has been shut down by an error, place the shutdown file in spare status by following the procedure described in 18.8.1(1) Placing shutdown files in spare status.

After you have restored all status files, terminate HiRDB if necessary, restore the specification values of the following operands to their original values, then start HiRDB:

pd_syssts_initial_error (for a unit status file)

pd_syssts_singleoperation (for a unit status file)

pd_sts_initial_error (for a server status file)

pd_sts_singleoperation (for a server status file)

(6) Check if single operation is being used

Check if single operation is being used for the status file in which the error occurred. If the following operand is specified, as applicable, for the status file in which the error occurred, single operation is being used:

For a unit status file: pd_syssts_singleoperation=continue

For a server status file: pd_sts_singleoperation=continue

(7) Checking if HiRDB can identify the current file that was in effect during the previous session

Based on the results of steps (1) through (3), for each logical file of the status file in which the error occurred, determine whether file versions A and B were in the statuses shown in Table 18-18. If the status file was in any of the statuses shown in Table 18-18, HiRDB cannot identify the current file that was in effect during the previous session.

Table 18-18 Cases in which HiRDB cannot identify the current file that was in effect during the previous session

Status of file version A | Status of file version B
Logical error present | Logical error present
Logical error present | Physical error present (no entity)
Physical error present (no entity) | Logical error present
Physical error present (no entity) | Physical error present (no entity)

(8) Using the current file identification facility

Use HiRDB's current file identification facility. Specify the following operand, as applicable, for the status file:

For a unit status file: pd_syssts_initial_error=excontinue

For a server status file: pd_sts_initial_error=excontinue

(9) Identifying the current file that was in effect during the previous session

Identify the current (most recent) file that was in effect during the previous session. You can identify this file from the messages listed below. Retrieve these messages from the message log file or syslogfile (retrieve the messages for the unit or server for which the current file cannot be identified).

KFPS01001-I (message output when the current file is allocated)

KFPS01044-I (message output when single operation goes into effect)

KFPS01063-I (message output when the current file is swapped by status file swapping)

Check these messages for the one output most recently; the current file is indicated in that message.

(10) Checking if the identified current file is normal

Check that the current file identified in step (9) is normal. You can determine this from the results of steps (1) through (3).

If status file single operation was in effect during the previous session (the last message that was output in step (9) was KFPS01044-I), check whether the status file for the active file system shown in the KFPS01044-I message is normal.

If status file single operation was not in effect during the previous session (the last message that was output in step (9) was KFPS01001-I or KFPS01063-I), check whether either of the status files shown in the KFPS01001-I or KFPS01063-I message is normal.

If the current file is normal (or if one of the files is normal if status file single operation was not in effect), proceed to the next step.

If an error had occurred in the current file, the current file that was in effect during the previous session has been lost, which means that HiRDB cannot be restarted. In such a case, take the actions described in 18.8.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file.

(11) Specifying the identified current file

Specify the identified current file that was in effect during the previous session in the following operands:

When the error occurred in a unit status file

Specify the following operands for the applicable unit:

pd_syssts_initial_error=continue or excontinue

pd_syssts_last_active_file=name-of-current-status-file-that-was-in-effect-during-the-previous-session*

pd_syssts_last_active_side=file-system-that-was-normal-during-the-previous-session*

When the error occurred in a server status file

Specify the following operands for the applicable server:

pd_syssts_initial_error=continue or excontinue

pd_syssts_last_active_file=name-of-current-status-file-that-was-in-effect-during-the-previous-session*

pd_syssts_last_active_side=file-system-that-was-normal-during-the-previous-session*

* Specify the current file name and normal file system identified in steps (9) and (10).

18.8.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file

If an error occurs in both versions of the current status file, HiRDB (unit) cannot be restarted. In this case, use the pdstart dbdestroy command to start HiRDB forcibly.

Note

When HiRDB is started forcibly, it does not inherit information that was in effect during the previous HiRDB session. Therefore, the HiRDB administrator must recover the database. The database is recovered by executing the database recovery utility (pdrstr command) using a backup copy and the system log (unload log) as the input information.

The following is the procedure for starting HiRDB in the event of an error on both versions of the current file:

Procedure

Check for a disk error (physical error check).
Check if a disk error has occurred at the disk that stores the status file. Check for a physical error (such as physical damage or a power outage) as well as for an OS or disk driver error; also check that the disk is enabled.
If the check identifies a disk error, correct it. If it is not possible to correct the error, start HiRDB with the remaining normal disks only. Proceed directly to the next step.
To determine if a physical error has occurred, refer to Table 18-16 Determining if a physical error has occurred at the disk (physical error check).

Check for a status file error (logical error check).
Execute the pdcat -d sts command for a status file in which no physical error has occurred and check for an error in its contents.
For a unit status file:
pdcat -d sts -u UNT1 -f /sysfile/usts1a -v
For a server status file:
pdcat -d sts -s b001 -f /sysfile/sstsb1a -v
The status file is normal if both the following conditions are satisfied:
The record size displayed in the execution results of the pdcat command matches the record size specified when the status file was created.
No error message was output during execution of the pdcat command.

Use the pdstsrm command to delete the erroneous status files.
For unit status files:
pdstsrm -u UNT1 -f /sysfile/usts1a
pdstsrm -u UNT1 -f /sysfile/usts1b
For server status files:
pdstsrm -s b001 -f /sysfile/sstsb1a
pdstsrm -s b001 -f /sysfile/sstsb1b

Use the pdstsinit command to re-create the status files deleted in step 3.
For unit status files:
pdstsinit -u UNT1 -f /sysfile/usts1a -l 4096 -c 256
pdstsinit -u UNT1 -f /sysfile/usts1b -l 4096 -c 256
For server status files:
pdstsinit -s b001 -f /sysfile/sstsb1a -l 4096 -c 256
pdstsinit -s b001 -f /sysfile/sstsb1b -l 4096 -c 256

Use the pdstart dbdestroy command to start HiRDB forcibly.

Use the database recovery utility (pdrstr command) to recover the RDAREAs.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

Note

Starting HiRDB forcibly destroys all RDAREAs that were updated during the previous HiRDB session (including system RDAREAs). The destroyed RDAREAs must be recovered by the database recovery utility; if you fail to do this, subsequent HiRDB operations cannot be guaranteed.

18.9 Handling of errors in files other than system files

This section explains the actions to be taken in the event of a file error, such as an I/O error, in the following types of files:

HiRDB system definitions file

Message log file

Statistics log file

Data linkage file (HiRDB Datareplicator)

Organization of this section

18.9.1 Errors in the HiRDB system definitions file

18.9.2 Errors in the message log file

18.9.3 Errors in the statistics log file

18.9.4 Errors in the data linkage file (HiRDB Datareplicator)

18.9.1 Errors in the HiRDB system definitions file

HiRDB processing

HiRDB does not start.

HiRDB administrator's action

Create a new HiRDB system definition file, specify the HiRDB system definitions, then start HiRDB normally.

18.9.2 Errors in the message log file

HiRDB processing

HiRDB messages are also output to syslogfile. However, some messages may be lost during periods of heavy traffic, because messages from other programs are also output to this log.

HiRDB administrator's action

Take the following action:

Procedure

To correct the message log file error:

Enter the pdstop command to terminate HiRDB.

Eliminate the cause of the message log file error.

Enter the pdstart command to start HiRDB.

18.9.3 Errors in the statistics log file

HiRDB processing

Resumes processing without collecting the statistics log. The KFPS05360-E message is output.

HiRDB administrator's action

Take the following action:

Procedure

To correct the statistics log file error:

Eliminate the cause of the error in the statistics log file.

Use the pdstjswap command to swap the output destination for the statistics log file.

Use the pdstbegin command to resume collection of the statistics log file.

Use the pdls -d stj command to confirm that the statistics log file has been collected.

18.9.4 Errors in the data linkage file (HiRDB Datareplicator)

HiRDB processing

When HiRDB Datareplicator linkage is being used, data linkage is disabled if the data linkage file that is being used to report the extraction status is initialized or if an open error or input/output error occurs in this file. When HiRDB detects an error in the data linkage file, it cancels HiRDB Datareplicator linkage and resumes operation using HiRDB only.

HiRDB administrator's action

Take the following action:

Procedure

To correct the data linkage file error:

Enter the pdls -d rpl command to determine whether or not the HiRDB unit is executing HiRDB Datareplicator linkage.

If the unit is executing HiRDB Datareplicator linkage, enter the pdrplstop command to terminate HiRDB Datareplicator linkage.

Correct the data linkage file.

To restart HiRDB Datareplicator linkage, enter the pdrplstart command.*

* When HiRDB Datareplicator is stopped in this manner, mismatches may arise between the extracted database and the target database being processed over the data linkage. Therefore, before entering the pdrplstart command, you must re-create the target database based on the extracted database. For details about how to re-create a target database, see the manual HiRDB Datareplicator Version 8 Description, User's Guide and Operator's Guide.

18.10 When the OS terminates abnormally

This section describes the HiRDB processing and the HiRDB administrator's action in the event of abnormal termination of the OS.

Organization of this section

(1) HiRDB processing

(2) HiRDB administrator's action

(1) HiRDB processing

If the OS terminates abnormally due to an error, HiRDB causes the unit located at the server machine where the OS terminated abnormally to also terminate abnormally.

(2) HiRDB administrator's action

After rebooting the OS, do the following:

Procedure

To restart HiRDB:

Use the pdgeter command to back up the troubleshooting information that is output under $PDDIR/spool and $PDDIR/tmp.
For details on the pdgeter command execution procedure, see 18.1.1 Actions to be taken by the HiRDB administrator when an error occurs.
For details on the troubleshooting information that is output in the event of an error, see 18.1.2 Information collected by HiRDB when an error occurs.

Enter the pdstart command to restart HiRDB. Depending on the pd_mode_conf operand specification, the unit is restarted automatically after the OS is rebooted.

18.11 Handling of errors while linked to an OLTP system

This section explains the actions to be taken if an error occurs while HiRDB is linked to an OLTP system. It covers the following topics:

Actions to be taken when a communication error occurs while HiRDB is linked to an OLTP system

Actions to be taken when a transaction is placed in FORGETTING status due to an error

Actions to take when transactions remain due to inactivity of a unit with a front-end server

Note that the following discussion applies only to the X/Open XA Interface.

Organization of this section

18.11.1 Actions to be taken when a communication error occurs while HiRDB is linked to an OLTP system

18.11.2 Actions to be taken when a transaction is placed in FORGETTING status due to an error

18.11.3 Actions to be taken when transactions remain resident due to inactivity of a unit with a front-end server

18.11.1 Actions to be taken when a communication error occurs while HiRDB is linked to an OLTP system

If a communication error occurs while HiRDB is linked to an OLTP system, the transaction branch can no longer be committed or rolled back. This section describes the HiRDB processing and the actions to be taken by the HiRDB administrator at this time.

Organization of this subsection

(1) HiRDB processing

(2) HiRDB administrator's action

(3) Recovering a transaction that has reached secure status after an error occurrence

(1) HiRDB processing

HiRDB retains the status of the transaction branch and resumes processing.

(2) HiRDB administrator's action

The OLTP system may not be active; check whether or not OLTP is active (if it is not, start it).

If error recovery is not possible, use the pdcmt or pdrbk command to prepare for transaction determination; for details, see (3) Recovering a transaction that has reached secure status after an error occurrence.

(3) Recovering a transaction that has reached secure status after an error occurrence

When the KFPS00992-E message (transaction cannot be recovered) is output, the pdls -d trn command can be used to display the status of transactions. This section explains how to recover a transaction that has reached the secure status (commit second phase wait status) in which transaction status 1 is READY and transaction status 2 is p.

(a) HiRDB/Single Server

A HiRDB/Single Server reaches secure status only when it is waiting for a commit second phase instruction from the OLTP system. The OLTP system may have terminated abnormally for some reason or the OLTP system cannot communicate with HiRDB. Therefore, take one of the following actions.

When the OLTP system has abnormally terminated
Restart the OLTP system. Once the OLTP system has restarted, the transaction is recovered automatically by establishing synchronization.

In any other case
Check the OLTP system's status, the status of the network between the OLTP system and HiRDB, etc. Once communication between the OLTP system and HiRDB is reestablished, the transaction is recovered by establishing synchronization with the OLTP system.

Use of commands for independent determination
If it is difficult to restart the OLTP system or to restore the network, it is possible to determine the transaction independently without establishing synchronization with the OLTP system. The commands used for this purpose are pdcmt, pdrbk, and pdfgt. For details, see 18.14 Actions when there is an undetermined transaction.
When the transaction is recovered using this method, other resource managers and transaction branches that were being processed by the OLTP system may not be synchronized; check their data contents.

(b) HiRDB/Parallel Server

In the case of a HiRDB/Parallel Server, the actions to be taken depend on the server that has reached secure status.

Front-end server

As is the case above in 1. When the OLTP system has abnormally terminated of (a) HiRDB/Single Server, HiRDB must wait for a commit second phase indication from the OLTP system. Therefore, take the same action as described above in case 1 (a) HiRDB/Single Server.

Back-end server and dictionary server

For details about how transactions are determined, see 18.14 Actions when there is an undetermined transaction.

Note that if pd_trn_rerun_branch_auto_decide = Y is specified (Y is the default), uncompleted transactions are determined automatically.

18.11.2 Actions to be taken when a transaction is placed in FORGETTING status due to an error

Organization of this subsection

(1) Overview of transactions in FORGETTING status

(2) When a transaction in FORGETTING status occurs

(3) Actions to take

(1) Overview of transactions in FORGETTING status

A transaction that is in FORGETTING status, as explained here, is one that satisfies all the following conditions:

The transaction's first status listing under STATUS in the execution results of the pdls -d trn command is FORGETTING (during transaction termination processing).

The transaction's third status listing under STATUS in the execution results of the pdls -d trn command is w (the transaction is being synchronized between the transaction manager and HiRDB).

The following is an example of a FORGETTING transaction:

pdls -d trn

HOSTNAME : host1(153201)
TRNGID           TRNBID           STATUS           PID   SVID   B-SVID
HRD1unt100020b51 HRD1unt100020038​ FORGETTING(r,w)    0   bes1   fes1

(2) When a transaction in FORGETTING status occurs

When an error that satisfies one of the following conditions occurs, the transaction is in FORGETTING status on HiRDB:

The transaction manager is terminating abnormally.

The first SQL (FirstSQL) to access HiRDB after a transaction being managed by the transaction manager starts ends in an error.

The transaction manager is terminated abnormally, and restarting of the transaction manager completes before recovery of the HiRDB transaction completes (Figure 18-3 shows an example of a transaction in FORGETTING status).

Figure 18-3 Example of a transaction in FORGETTING status after restarting the transaction manager is completed

Because a transaction in FORGETTING status uses HiRDB memory resources that are allocated for transactions, an error may occur if too many transactions are placed in FORGETTING status. Such an error may prevent HiRDB from being able to perform concurrent execution of a large number of transactions from connected users.

(3) Actions to take

If a transaction in FORGETTING status occurs, take one of the following actions:

Restart the transaction manager.

Execute the pdfgt command to forcibly terminate the transaction in FORGETTING status.

18.11.3 Actions to be taken when transactions remain resident due to inactivity of a unit with a front-end server

Organization of this subsection

(1) When transactions remain resident

(2) Actions to take

(1) When transactions remain resident

When all the following conditions are present, transactions may remain resident on the active unit:

A HiRDB/Parallel Server consists of multiple units.

A unit with a front-end server is inactive.

There are uncompleted transactions in the active units.

The transaction manager is started after it has terminated abnormally.

Because transactions that remain resident continue to use resources, if too many transactions remain resident, HiRDB may no longer be able to perform concurrent execution of a large number of transactions from connected users.

(2) Actions to take

Use the pdstart -u command to start the unit with the front-end server. If you are unable to start the unit with the front-end server, check the transaction status of the transaction manager's transactions, and use the pdcmt, pdrbk, or pdfgt command to forcibly complete the HiRDB transactions. If you use this method to forcibly complete the transactions, the transaction completion methods recognized in the transaction manager and HiRDB may no longer match.

18.12 Handling of communication errors, CPU errors, and power failures

This section describes the handling of the following types of errors:

Communication errors

CPU errors

Power failure

Organization of this section

18.12.1 Handling of communication errors

18.12.2 Handling of CPU errors

18.12.3 Handling of a power failure

18.12.1 Handling of communication errors

HiRDB processing

Returns control, issuing a message indicating that a communication error occurred in a specified transaction.

HiRDB administrator's action

Check the cause of the communication error, terminate HiRDB, and take appropriate action to correct the error.

It may not be possible to terminate HiRDB normally after a communication error. If this is the case, terminate HiRDB forcibly. If HiRDB still will not terminate, recover each unit if units can be terminated or started individually. Otherwise, shut down the entire system, eliminate the cause of the error, then restart the system.

18.12.2 Handling of CPU errors

HiRDB processing

When a CPU error occurs, the unit at the server machine resulting in the CPU error terminates abnormally.

HiRDB administrator's action

After you have restarted the OS, restart HiRDB. Depending on the specification in the pd_mode_conf operand, HiRDB may restart the unit automatically after you restart the OS.

18.12.3 Handling of a power failure

HiRDB processing

When the power has been restored, the OS has been rebooted, and HiRDB has been restarted, the hardware power backup facility restores the system to its status immediately before the power failure occurred.

HiRDB administrator's action

After you have restarted the OS, restart HiRDB. Depending on the specification in the pd_mode_conf operand, HiRDB may restart the unit automatically after you restart the OS.

18.13 When HiRDB cannot be terminated because a user is still connected

Executor: HiRDB administrator

This section explains the actions to be taken when HiRDB cannot be terminated because a user is still connected.

Organization of this section

18.13.1 Corrective procedure

18.13.2 Connected user data file and connected user details file

18.13.1 Corrective procedure

HiRDB cannot terminate if there is a UAP or utility that has not terminated (i.e., if a user is still connected). If an attempt is made to terminate HiRDB while a user is still connected, HiRDB outputs the KFPS05120-W message, together with the connected user data file and connected user details file. In this case, the HiRDB administrator must follow the procedure described below to disconnect the user and terminate HiRDB.

Procedure

Note

The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 5 is explained in paragraph (5) below.

Organization of this subsection

(1) Check for any user who is still connected

(2) Check for transactions that are still executing

(3) Are there any transactions in READY(p,?) or FORGETTING(?,w) status?

(4) Complete any uncompleted transactions

(5) Are any transactions still executing?

(6) Should the transactions be terminated forcibly?

(7) Use the pdcancel command to terminate forcibly the user (UAP) who is still connected

(8) Wait for approximately 1 minute

(9) Wait for the transaction to terminate

(10) Use the pdcancel command to disconnect the user (UAP) who is still connected

(11) Wait for approximately 1 minute

(12) Has the pdstop command timed out?

(13) Execute the pdstop command

(14) Is the KFPS01840-I message output?

(1) Check for any user who is still connected

(a) Using the pdls -d prc command to check if users are still connected

pdls -d prc

HOSTNAME : k95x620(173420)
STATUS   PID   UID   GID   SVID   TIME      PROGRAM    C-PID   C-GRP

 L      22118 334   300   fes1   173330    uap00      22205   PC

Explanation

Check the UAP identifier listed under PROGRAM. The user who is still connected is uap00.

(b) Checking the connected user data file for users who are still connected

For details about the output contents of the connected user data file, see 18.13.2 Connected user data file and connected user details file.

UNIT ID : UNT1(173420)
UID  PID    GID  SVID  TIME    PROGRAM  C-GRP  C-PID   C-IP
334  22118  300  fes1  173330  uap00    PC     22205   172.17.32.37

Explanation

Check the UAP identifier listed under PROGRAM. The user who is still connected is uap00.

(2) Check for transactions that are still executing

Either execute the pdls -d trn command or use the results in the connected user details file of executing the pdls -d trn command to check for transactions that are still executing.

For details about the output contents of the connected user details file, see 18.13.2 Connected user data file and connected user details file.

(3) Are there any transactions in READY(p,?) or FORGETTING(?,w) status?

Based on the execution results of the pdls -d trn command or the information in the connected user details file, determine whether there are any transactions in READY(p,?) or FORGETTING(?,w) status.

(4) Complete any uncompleted transactions

Complete the uncompleted transactions; for details, see 18.14 Actions when there is an undetermined transaction.

(5) Are any transactions still executing?

Based on the execution results of the pdls -d trn command or the information in the connected user details file, determine whether there are any transactions in READY(p,?) or FORGETTING(?,w) status.

(6) Should the transactions be terminated forcibly?

If there are transactions in READY(p,?) or FORGETTING(?,w) status, decide whether to terminate them forcibly or to wait for them to complete their processing. If the processing time of a transaction that is executing is short, wait for it to terminate; if the processing time is long, terminate it forcibly.

(7) Use the pdcancel command to terminate forcibly the user (UAP) who is still connected

Use the pdcancel command to terminate the transaction forcibly.

HiRDB/Single Server

pdcancel -u UAP00 -i 22118

HiRDB/Parallel Server (execution example 1)

pdcancel -x k95x620 -u UAP00 -i 22118

HiRDB/Parallel Server (execution example 2)

pdcancel -X UNT1 -u UAP00 -i 22118

Explanation

-u: Specifies the identifier of the UAP.

-x: Specifies the name of the host where the front-end server to which the UAP is connected is located. The specified host name is listed under HOSTNAME in the execution results of the pdls -d prc command.

-X: Specifies the unit identifier. The specified unit identifier is listed under UNIT ID in the connected user data file.

-i: Specifies the process ID.

(8) Wait for approximately 1 minute

After executing the pdcancel command, wait for the transaction to be completed by itself.

(9) Wait for the transaction to terminate

If you do not terminate the transaction forcibly, wait for it to terminate.

(10) Use the pdcancel command to disconnect the user (UAP) who is still connected

If there is no transaction for a user who is still connected, use the pdcancel command to disconnect the user.

HiRDB/Single Server

pdcancel -i 22118 -d

HiRDB/Parallel Server (execution example 1)

pdcancel -x k95x620 -i 22118 -d

HiRDB/Parallel Server (execution example 2)

pdcancel -X UNT1 -i 22118 -d

Explanation

-x: Specifies the name of the host where the front-end server to which the UAP is connected is located. The specified host name is listed under HOSTNAME in the execution results of the pdls -d prc command.

-X: Specifies the unit identifier. The specified unit identifier is listed under UNIT ID in the connected user data file.

-i: Specifies the process ID.

-d: Specifies that the HiRDB process is to be terminated forcibly. When the -d option is specified, the core file is output. If the core file is not needed, delete it with the pdcspool command.

(11) Wait for approximately 1 minute

After executing the pdcancel command, wait for the user to be disconnected and HiRDB termination processing to be resumed.

(12) Has the pdstop command timed out?

If the KFPS05047-E message is output, the pdstop command has timed out.

(13) Execute the pdstop command

If the pdstop command has timed out, execute it again.

(14) Is the KFPS01840-I message output?

If the KFPS01840-I message is output, HiRDB termination processing has started.

18.13.2 Connected user data file and connected user details file

If an attempt is made to terminate HiRDB while a user is still connected, HiRDB outputs the KFPS05120-W message, together with the connected user data file ($PDDIR/spool/cnctusrinf) and the connected user details file ($PDDIR/spool/cnctusrdtl). For a HiRDB/Parallel Server, these files are output to the server machine where the system manager is located. The HiRDB administrator can identify the connected users from the information in these files.

Organization of this subsection

(1) Information output in the connected user data file

(2) Information output in the connected user details file

(1) Information output in the connected user data file

Output example

UNIT ID : M350(173420)
UID  PID    GID   SVID  TIME    PROGRAM   C-GRP  C-PID  C-IP
334  22118  300   fes1  173330  uap00     PC     22205  172.17.32.37

UNIT ID : M35b(173427)
UID  PID    GID   SVID  TIME    PROGRAM   C-GRP  C-PID  C-IP
334  17524  300   fes2  173343  uap01     PC     17619  172.17.32.39
334  17533  300   fes2  173333  uap02     PC     22200  172.17.32.37

Explanation

UNIT ID

Displays the connected users data file unit identifier and creation time (hour minute second).

UID

Displays the user ID of each user who is connected to HiRDB.

PID

Displays the process ID of each connected user's HiRDB server process.

GID

Displays the group ID of each user who is connected to HiRDB.

SVID

Displays the server ID of the server to which each connected user is connected.

Blanks may be displayed immediately after HiRDB server process activation.

TIME

Displays the time (hour minute second) at which HiRDB received each service request. 999999 is displayed for a server where no user is connected.

PROGRAM

Displays the value specified in the PDCLTAPNAME operand of the client environment definition.

If this operand is omitted, Unknown is displayed. For details on the PDCLTAPNAME operand, see the manual HiRDB Version 8 UAP Development Guide.

****** is displayed for a utility.

For a UAP that accesses HiRDB using the distributed database facility, RDAUSER - authorization-identifier is displayed.

****** may be displayed immediately after HiRDB server process activation.

C-GRP

Displays the user type (client group type) of each user who is connected to HiRDB.

If the connection frame guarantee facility for a client group is used and a client group selected arbitrarily by the user is defined, the user-defined client group name is displayed.

Displayed character string | User type
XA | User who connected to HiRDB using the X/Open XA interface
DF | User who connected to HiRDB from a distributed client
PC | User who connected to HiRDB from a PC client
WS | User who connected to HiRDB from a WS client
MF | User who connected to HiRDB from a mainframe client (VOS3 client, etc.)

C-PID

Displays the process ID of the client that is connected to HiRDB.

C-IP

Displays the IP address of the client that is connected to HiRDB.

Note

C-GRP, C-PID, and C-IP are not displayed in the following cases:

The UAP or utility was not executed by a client (it was executed by HiRDB).

The version of the client to which the UAP is linked is older than HiRDB Version 4.0 04-00.

(2) Information output in the connected user details file

The execution results of the following commands are output to the connected user details file:

pdls -d act

pdls -d prc

pdls -d trn

For details about the execution results of each command, see the manual HiRDB Version 8 Command Reference.

18.14 Actions when there is an undetermined transaction

This section explains the actions to be taken when there are transactions that have not been determined (undetermined transactions).

Organization of this section

18.14.1 Forcing determination of uncompleted transactions

18.14.2 Performing transaction determination manually on undetermined transactions

18.14.1 Forcing determination of uncompleted transactions

The KFPS00992-E message is output for each undetermined transaction (transaction branch that cannot be determined). When this happens, the HiRDB administrator must force determination of each such transaction that is uncompleted by following the procedure described below.

When pd_trn_rerun_branch_auto_decide = Y (default value) has been specified, determination of uncompleted transactions is performed automatically. If a transaction cannot be determined by this automatic determination facility or if you do not use this facility, you must perform the operation explained below.

Procedure

Notes

The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 5 is explained in paragraph (5) below.

Messages can be checked during the procedure explained below. To do so, reference the messages in syslogfile.

Organization of this subsection

(1) Check for undetermined transactions

(2) Start the client product

(3) Start the servers that have stopped

(4) Perform transaction determination manually on undetermined transactions

(5) Create input files for the pdtrndec command (for the unit where the system manager is located)

(6) Using the input files created in (5), execute the pdtrndec command

(7) Create input files for the pdtrndec command (for each unit where the system manager is not located)

(8) Create input files for the pdtrndec command (for the unit where the system manager is located)

(9) Using the input files created in (7) and (8), execute the pdtrndec command

(10) Check the transaction status

(11) Check for the KFPS02183-I message

(12) Delete unneeded files

(1) Check for undetermined transactions

Check the KFPS00992-E messages to determine if there are undetermined transactions.

KFPS00992-E Unable to determine commit or rollback for transaction branch.
TRNGID=HRD1unt100020b4d, TRNBID=HRD1unt100020034​, server=bes1, service=p_f_sqa_call

KFPS00992-E Unable to determine commit or rollback for transaction branch.
TRNGID=HRD1unt100020b22, TRNBID=HRD1unt100020035​, server=bes1, service=p_f_sqa_call

KFPS00992-E Unable to determine commit or rollback for transaction branch.
TRNGID=HRD1unt100020b5a, TRNBID=HRD1unt100020036​, server=bes1, service=p_f_sqa_call

Explanation

A KFPS00992-E message displays a transaction branch that could not be committed or rolled back. In the case shown above, the transactions indicated by the following transaction identifiers may be undetermined:

TRNGID=HRD1unt100020b4d

TRNGID=HRD1unt100020b22

TRNGID=HRD1unt100020b5a

If there are no undetermined transactions, no further action is necessary.

(2) Start the client product

Check whether the product used as the HiRDB client (OLTP system or HiRDB Datareplicator, for example) is running normally. If not, start it using the procedure appropriate to the particular product.

You should note the following about forcing determination of a transaction while there is a stopped client product:

An undetermined transaction that was generated by a request from a client product that is now stopped may be rolled back forcibly when the steps that follow are performed. If the client product is then started subsequently, it may not be possible to synchronize the transaction between HiRDB and the client product.

To maintain transaction integrity, it is important that you do not execute any new transactions from this point on during this procedure.

(3) Start the servers that have stopped

Use the pdls command to check if all servers (excluding recovery-unnecessary front-end servers) are running. If any server is not running, start it.

You should note the following about forcing determination of a transaction while there is a stopped server:

A transaction that is related to the stopped server may be rolled back forcibly when the operations that follow are performed. If the server is then started subsequently, it may not be possible to synchronize the transaction.

There is no need to start a recovery-unnecessary front-end server that has stopped.

(4) Perform transaction determination manually on undetermined transactions

Perform transaction determination manually on the undetermined transactions. For details about the manual determination procedure, see 18.14.2 Performing transaction determination manually on undetermined transactions.

(5) Create input files for the pdtrndec command (for the unit where the system manager is located)

Use the grep command to create input files for the pdtrndec command. This applies only to the unit where the system manager is located. The files you create with the grep command are for KFPS00990-I messages.

grep "KFPS00990-I" /usr/adm/OLDsyslogfile >/tmp/unit1syslog.copy
grep "KFPS00990-I" /usr/adm/syslogfile >/tmp/unit1syslog2.copy
          1                 2                     3

Explanation

Specifies the KFPS00990-I character string as the pattern for execution of the grep command.

Specifies the absolute path name of a syslogfile to be extracted (syslogfile of the unit where the system manager is located).

Specifies the absolute path name of an input file for the pdtrndec command.

Hint

To avoid adverse impacts on syslogfile from a direct access, extract from syslogfile only the row containing the character string "KFPS00990-I" and save it in a file of your choice. If the extracted contents are processed, the results of the pdtrndec command that will be executed in step (6) cannot be guaranteed. For this reason, you must not perform any processing other than execution of the grep command.

Because syslogfile may have been swapped, all syslogfiles that have been created since the system started normally (time at which the KFPS05210-I message was output after the KFPS01803-I start mode=S message had been output) must be used as input targets. If there is no syslogfile that includes the time at which the system started normally, use all existing syslogfiles as input targets.

The absolute path name of a syslogfile to be input depends on the platform. Specify the absolute path name specified in /etc/syslog.conf.

(6) Using the input files created in (5), execute the pdtrndec command

pdtrndec -i /tmp/unit1syslog.copy,/tmp/unit1syslog2.copy

Explanation

-i: Specifies input of the files created in (5).

Check the items listed under DECISION (transaction determination type) in the command execution results. Then continue the procedure by following the steps in the flowchart.

pdtrndec result                     START TIME:2002/09/05 17:20:08
HOSTNAME    TRNGID           TRNBID           SVID      DECISION    TIME
host1       HRD1unt100020b4d HRD1unt100020034​ bes1      COMMIT      17:20:08
host1       HRD1unt100020b22 HRD1unt100020035​ bes1      ********    --:--:--
host1       HRD1unt100020b51 HRD1unt100020038​ bes1      FORGET      17:20:09
pdtrndec result                     START TIME:2002/09/05 17:36:47
HOSTNAME    TRNGID           TRNBID           SVID      DECISION    TIME
host1       HRD1unt100020b22 HRD1unt100020035​ bes1      ********    --:--:--

Note

If there are still any undetermined transactions after the pdtrndec command has executed, a pdtrnrbk.bat file is created. However, do not execute pdtrnrbk.bat at this point. If you execute it, you may lose transaction synchronization. Also, if the KFPS00982-E message is output when a pdtrnrbk.bat file is created, delete the pdtrnrbk.bat file without using it.

(7) Create input files for the pdtrndec command (for each unit where the system manager is not located)

Use the grep command to create input files for the pdtrndec command. This applies only to each unit where the system manager is not located. The files you create with the grep command are for the KFPS00990-I messages.

grep "KFPS00990-I" /usr/adm/OLDsyslogfile >/tmp/unit2syslog.copy
grep "KFPS00990-I" /usr/adm/syslogfile >/tmp/unit2syslog2.copy
          1               2                     3

Explanation

Specifies the KFPS00990-I character string as the pattern for execution of the grep command.

Specifies the absolute path name of a syslogfile to be extracted (syslogfile of a unit where the system manager is not located).

Specifies the absolute path name of an input file of the pdtrndec command.

Hint

To avoid adverse impacts on syslogfile from a direct access, extract from syslogfile only the row containing the character string "KFPS00990-I" and save it in a file of your choice. If the extracted contents are processed, the results of the pdtrndec command that will be executed in step (8) cannot be guaranteed. For this reason, you must not perform any processing other than execution of the grep command.

Because syslogfile may have been swapped, all syslogfiles that have been created since the system started normally (time at which the KFPS05210-I message was output after the KFPS01803-I start mode=S message had been output) must be used as input targets. If there is no syslogfile that includes the time at which the system started normally, use all existing syslogfiles as input targets.

The absolute path name of a syslogfile to be input depends on the platform. Specify the absolute path name specified in /etc/syslog.conf.

(8) Create input files for the pdtrndec command (for the unit where the system manager is located)

Use the same method as in step (5) to create input files for the pdtrndec command.

(9) Using the input files created in (7) and (8), execute the pdtrndec command

Using the input files created in steps (7) and (8), execute the pdtrndec command to force determination of the transactions. If the return code indicating the final status after the first execution of the pdtrndec command is 4 and ******** is listed under DECISION for a transaction, specify the option shown below and execute the pdtrndec command again.

pdtrndec -i /tmp/unit1syslog.copy,/tmp/unit1syslog2.copy,/tmp/unit2syslog.copy,
/tmp/unit2syslog2.copy -r pdtrnrbk.bat

Explanation

-i: Specifies input of the files created in steps (7) and (8).

-r: Specifies the shell script (pdtrnrbk.bat) file created in step (6).

If the KFPS00982-E message is output when a pdtrnrbk.bat file has been created, delete the pdtrnrbk.bat file without using it.

(10) Check the transaction status

Use the pdls -d trn command to check if all transactions have been determined. If an undetermined transaction remains, check the output message and command execution results, take the necessary corrective action, and then repeat the steps beginning with (7).

pdls -d trn

HOSTNAME : host1(153415)
TRNGID           TRNBID           STATUS        PID   SVID   B-SVID

Explanation

No transaction information is displayed, which means that all transactions have been determined.

(11) Check for the KFPS02183-I message

Once all undetermined transactions have been determined, the KFPS02183-I message is output within 30 seconds. If the KFPS02183-I message is not output after 30 seconds, an undetermined transaction remains. In such a case, repeat the procedure from the start.

(12) Delete unneeded files

Delete the files (such as pdtrndecout and pdtrnrbk.bat) under the output destination directory specified by the pdtrndec command.

18.14.2 Performing transaction determination manually on undetermined transactions

This section explains how to perform transaction determination manually on undetermined transactions.

Procedure

Notes

The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 5 is explained in paragraph (5) below.

Messages can be checked during the procedure explained below. To do so, reference the messages in syslogfile.

Organization of this subsection

(1) Check for KFPS00992-E messages

(2) Is the client product running?

(3) Start the client product

(4) Wait for approximately 1 minute

(5) Was the KFPS00992-E message output during HiRDB termination processing?

(6) Check TRNGID that is output in the KFPS00992-E messages

(7) Use the pdls command to check transaction status

(8) Are there any transactions in READY(p,?) or FORGETTING(?,w) status?

(9) Check the completion type of undetermined transactions

(10) Perform determination of the undetermined transactions

(11) Wait for transaction determination

(12) Check for transaction determination

(13) Have all transactions terminated?

(1) Check for KFPS00992-E messages

Search syslogfile for KFPS00992-E messages.

KFPS00992-E Unable to determine commit or rollback for transaction branch.
TRNGID=HRD1unt100020b4d, TRNBID=HRD1unt100020034​, server=bes1, service=p_f_sqa_call

KFPS00992-E Unable to determine commit or rollback for transaction branch.
TRNGID=HRD1unt100020b22, TRNBID=HRD1unt100020035​, server=bes1, service=p_f_sqa_call

KFPS00992-E Unable to determine commit or rollback for transaction branch.
TRNGID=HRD1unt100020b5a, TRNBID=HRD1unt100020036​, server=bes1, service=p_f_sqa_call

KFPS00992-E Unable to determine commit or rollback for transaction branch.
TRNGID=HRD1unt100020b5f, TRNBID=HRD1unt100020037​, server=bes1, service=p_f_sqa_call

KFPS00992-E Unable to determine commit or rollback for transaction branch.
TRNGID=HRD1unt100020b64, TRNBID=HRD1unt100020038​, server=bes1, service=p_f_sqa_call

Explanation

The KFPS00992-E messages display transaction branches that could not be committed or rolled back. In this example, the transactions with the following transaction identifiers may be undetermined:

TRNGID=HRD1unt100020b4d

TRNGID=HRD1unt100020b22

TRNGID=HRD1unt100020b5a

TRNGID=HRD1unt100020b5f

TRNGID=HRD1unt100020b64

(2) Is the client product running?

Check whether the product used as the HiRDB client is running normally.

(3) Start the client product

If the product used as the HiRDB client is not running normally, start it using the procedure appropriate to the particular product.

Do not forcibly start the client product.

(4) Wait for approximately 1 minute

Wait for approximately 1 minute, because transaction automatic determination may be underway.

(5) Was the KFPS00992-E message output during HiRDB termination processing?

The action to be taken depends on whether the KFPS00992-E message was output during HiRDB termination processing.

(6) Check TRNGID that is output in the KFPS00992-E messages

If the KFPS00992-E message was output during HiRDB termination processing, the pdls -d trn command cannot be executed. Therefore, you must check the TRNGID that is output in each KFPS00992-E message.

(7) Use the pdls command to check transaction status

Use the pdls -d trn command to check the status of transactions.

pdls -d trn

HOSTNAME : host1(153415)
TRNGID           TRNBID           STATUS            PID    SVID    B-SVID
HRD1unt100020b4d HRD1unt100020034​  READY(p,n)       0      bes1    fes1
HRD1unt100020b22 HRD1unt100020035​  READY(p,n)       0      bes1    fes1
HRD1unt100020b5a HRD1unt100020036​  READY(p,n)       0      bes1    fes1
HRD1unt100020b5f HRD1unt100020037​  ROLLBACK(u,n)    29799  bes1    fes1
HRD1unt100020b69 HRD1unt100020039​  FORGETTING(r,w)  0      bes1    fes1

Explanation

Check the information listed in the STATUS column.

The status of the three transactions listed below is READY(p,?).
TRNGID=HRD1unt100020b4d
TRNGID=HRD1unt100020b22
TRNGID=HRD1unt100020b5a

Transaction TRNGID=HRD1unt100020b5f was rolled back by determination processing because a client product was started. This transaction will be determined automatically.

Transaction TRNGID=HRD1unt100020b64 was determined by determination processing because a client product was started. For this reason, this transaction is not listed in the execution results of the pdls -d trn command.

The status of transaction TRNGID=HRD1unt100020b69, which was not output in a KFPS00992-E message, is FORGETTING(?,w).

(8) Are there any transactions in READY(p,?) or FORGETTING(?,w) status?

If the execution results of the pdls -d trn command still show any transactions in READY(p,?) or FORGETTING(?,w) status (in the STATUS column), you must perform determination of those transactions.

If only transactions in statuses other than READY(p,?) or FORGETTING(?,w) remain, wait for those transactions to be determined automatically.

(9) Check the completion type of undetermined transactions

If there are any transactions in READY(p,?) or FORGETTTING(?,w) status, search the KFPS00990-I messages in syslogfile for the TRNGIDs of the transactions to be determined. Each KFPS00990-I message shows the transaction's completion type. Search only the KFPS00990-I messages that have been output since the previous normal startup.

KFPS00990-I Transaction branch recovery complete. TRNGID=HRD1unt100020b5a,
TRNBID=HRD1unt200020015​, server=fes1, service=p_f_sqa_cauxi, completion type=c, c

KFPS00990-I Transaction branch recovery complete. TRNGID=HRD1unt100020b4d,
TRNBID=HRD1unt200020014​, server=fes1, service=p_f_sqa_cauxi, completion type=r, r

Explanation

The search results and the actions to be taken are explained below:

Completion type of transaction TRNGID=HRD1unt100020b5a
Because completion type=c is shown, commit must be used to determine the transaction.

Completion type of transaction TRNGID=HRD1unt100020b4d
Because completion type=r is shown, rollback must be used to determine the transaction.

Transactions that were not found in the search and the actions to be taken are explained below:

Completion type of transaction TRNGID=HRD1unt100020b22
Because there is no KFPS00990-I message for this TRNGID, rollback must be used to determine the transaction.

Completion type of transaction
TRNGID=HRD1unt100020b69
Because the STATUS is FORGETTING(?,w), the transaction must be terminated forcibly.

You need not check the completion types of transactions identified by the following TRNGIDs:

TRNGID=HRD1unt100020b5f

TRNGID=HRD1unt100020b64

(10) Perform determination of the undetermined transactions

Use the following commands to perform determination of undetermined transactions:

Command name | Function and application criteria
pdcmt | Commits a transaction.
pdrbk | Rolls back a transaction.
pdfgt | Terminates a transaction forcibly. This command is executed for a transaction in FORGETTING(?,w) status.

(11) Wait for transaction determination

If the only remaining transactions are in statuses other than READY(p,?) or FORGETTING(?,w), these transactions are being determined. Therefore, wait for determination processing to be completed.

(12) Check for transaction determination

When the KFPS00992-E message was output during HiRDB termination processing, check whether or not the KFPS02183-I message has been output. When all undetermined transactions have been determined, the KFPS02183-I message is output within 30 seconds. If this message is not output within 30 seconds, an undetermined transaction remains.

If the KFPS00992-E message is output during HiRDB restart, or if the execution of the pdls -d trn command while HiRDB is running identifies an undetermined transaction, use the pdls -d trn command to check if the transaction has been determined.

(13) Have all transactions terminated?

If there is any transaction that has not terminated, return to step (5) in the procedure.

18.15 Handling of reduced activation (HiRDB/Parallel Server only)

Executor: HiRDB administrator

Normally, a HiRDB/Parallel Server cannot be started if any of its units will not start. Therefore, if an error occurs at a unit, HiRDB cannot be started until the error is corrected. In such a case, reduced activation enables HiRDB to be started using only the normal units (the units that can be started.

Organization of this section

(1) To use reduced activation

(2) Returning to normal operation mode

(3) When reduced activation is not available

(4) Some tables may not be accessed when reduced activation is used

(5) Use of reduced activation during a restart

(6) Notes on multiple front-end servers

(7) Notes on when HiRDB is linked to HiRDB Datareplicator

(8) When reduced activation is used for subsequent HiRDB startup

(9) Notes about using recovery-unnecessary front-end servers

(1) To use reduced activation

To use reduced activation, 1 must be specified in the pd_start_level operand. HiRDB will start using only the available units if there are units that cannot be started.

When reduced activation takes effect, the KFPS05217-I message is issued. The pdls command can be used to determine the units that could not be started.

Remarks

During startup, HiRDB waits for up to 20 minutes to receive a startup message from all units. Therefore, there is a delay of 20 minutes before reduced activation is executed. The maximum of 20 minutes to wait to receive a startup message can be changed in the pd_reduced_check_time operand of the system common definition.

(2) Returning to normal operation mode

The following procedure shows how to return HiRDB to the normal mode after it has run in reduced activation.

Procedure

To return to normal operation mode:

Use the pdls command to check and eliminate the error in the unit that cannot be started.
pdls -d svr

Use the pdstart -u command to start up a unit that is not active:
pdstart -u unt1
When HiRDB returns to the normal operation mode, the KFPS05218-I message is issued.

(3) When reduced activation is not available

In the following cases, reduced activation is not available; the cause of the error must be eliminated in order to start HiRDB:

The unit to be started does not have either of the following servers:

System manager

Dictionary server

The unit to be started has none of the following servers:

Front-end server

Back-end server

The pdstart -i command is being used to start HiRDB.

HiRDB is being started for the first time after being upgraded.

(4) Some tables may not be accessed when reduced activation is used

If an attempt is made to access a table at an inactive unit, an SQL error results. If a table is row-partitioned, accessing data stored at an inactive unit results in an SQL error.

(5) Use of reduced activation during a restart

If reduced activation is used during a restart, a transaction related to the erroneous unit may be placed in uncompleted status. The transaction will be determined automatically when reduced activation is released and normal operation is started. If there is a transaction in uncompleted status, neither normal termination nor planned termination can be executed on HiRDB. In such a case, the pdstop -f command must be used to terminate HiRDB forcibly.

(6) Notes on multiple front-end servers

Special care is needed when the front-end server to which a client user is to be connected has been determined; i.e., when the following operands have been specified in the client environment definition:

PDFESHOST

PDSERVICEGRP

If the front-end server specified in these operands is not running, no UAPs can be executed. To enable UAPs to execute, either delete these operands or specify a front-end server that is running.

(7) Notes on when HiRDB is linked to HiRDB Datareplicator

(a) HiRDB used at the extracting side

Data extraction processing is not performed on a back-end server in an inactive unit. For such a case, once the unit is running normally again, use the hdestart command of HiRDB Datareplicator to restart data extraction processing. If, however, normal operations resume when HiRDB is restarted after it had been terminated while it was in reduced activation mode, you do not need to enter the hdestart command. Data extraction processing will restart automatically in such a case.

If data extraction processing stops during reduced activation, execute the pdrplstop command. Avoid executing the pdrplstop -f command, if possible. When you execute the pdrplstop command, data execution processing will stop on completion if there are incomplete extraction status system log files in the unit that has been returned to normal operation. However, if you execute the pdrplstop -f command, data extraction processing stops only in conjunction with the entire system, even if there are incomplete extraction status system log files in the unit that has been returned to normal operation.

(b) HiRDB used at the target side

If an attempt is made to reflect data in an inactive unit, an error results and the reflection processing is cancelled. In such a case, data reflection processing must be restarted with HiRDB Datareplicator's hdsstart command after reduced activation is released and normal operation is started.

Re-create the target database based on the database in the unit that is inactive due to reduced activation. In such as case, however, mismatches may arise between the extracted database and the target database.

(8) When reduced activation is used for subsequent HiRDB startup

If reduced activation is to be used for a subsequent HiRDB startup because a unit error cannot be corrected, the name of the unit that cannot be started should be specified in the pd_start_skip_unit operand. Normally during startup, HiRDB waits for up to 20 minutes to receive a startup message from each unit. Therefore, there is a delay of 20 minutes before reduced activation is executed. If the name of a unit that cannot be started is specified in the pd_start_skip_unit operand, HiRDB does not wait for a unit startup message from that unit, which can save a considerable amount of time that HiRDB would otherwise spend waiting for a startup message, thereby reducing the time required for reduced activation.

Example

1 is specified in the pd_start_level operand in the system common definition.

HiRDB executed reduced activation because a unit could not be started due to an error.

When the application terminated, the pdstop command was entered to terminate HiRDB. The error had not been corrected at this point.

The following operand was specified:
pd_start_skip_unit=name-of-unit-that-cannot-be-started

To start the application, the pdstart command was entered to start HiRDB. The HiRDB startup time is reduced as compared to when the pd_start_skip_unit is not specified.

Note

To return to normal operation, delete the pd_start_skip_unit operand. If you do not delete this operand, HiRDB will again be placed in reduced activation mode the next time it is started.

(9) Notes about using recovery-unnecessary front-end servers

Recovery-unnecessary front-end server units start independently in the reduced mode, regardless of the value set in the pd_start_level operand. Even if you specify a unit name in the pd_start_skip_unit operand, that specification is ignored and the recovery-unnecessary front-end server units are started. If any of the recovery-unnecessary front-end server units cannot be started during HiRDB startup, HiRDB is started without those units.

18.16 Handling of disk errors

Executor: HiRDB administrator and superuser

This sections explains the actions to take when a disk error occurs.

Procedure

Initialize the hard disk.

Set partitions.

Initialize the UNIX file system (if regular files are being used).

Change the owner and access privileges of the HiRDB file system area (if character special files are being used).

Create a symbolic link to the file name.

Initialize the HiRDB file system area.

Create system files.

Restore the RDAREAs.

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

Organization of this section

(1) Initialize the hard disk

(2) Set partitions

(3) Initialize the UNIX file system (applicable to regular files)

(4) Change each character special file's owner and access privileges (applicable to character special files)

(5) Link the file names symbolically

(6) Initialize the HiRDB file system area

(7) Create system files

(8) Restore RDAREAs

(1) Initialize the hard disk

Executor: Superuser

Replace the hard disk, and initialize it.

Initialize the hard disk; for the procedure, see the OS manual.

(2) Set partitions

Executor: Superuser

Set partitions on the initialized hard disk; for the procedure, see the OS manual.

(3) Initialize the UNIX file system (applicable to regular files)

Executor: Superuser

If regular files had been used in the HiRDB file system area, initialize the partitions as a UNIX file system; for the procedure, see the OS manual.

If the partitions are already initialized, skip this step.

(4) Change each character special file's owner and access privileges (applicable to character special files)

Executor: Superuser

Set the owner and access privileges for each HiRDB file system area to the previous information. Table 18-19 shows the owner and access privileges to be set for a HiRDB file system area.

Table 18-19 Owner and access privileges to be set for a HiRDB file system area

Owner, access privileges | Information to be set | Command to be executed*
Owner | User ID | HiRDB administrator | chown command
Group ID | HiRDB group | chgrp command
Access privilege | Owner | rw- (read and write operations permitted) | chmod command
Group | rw- (read and write operations permitted)
Other | --- (access denied)

* These are OS commands; for details, see the OS manual.

(5) Link the file names symbolically

Executor: Superuser

If a HiRDB file system area had been linked symbolically to a name, link the same name to the HiRDB file system area; the OS's ln command is used for this purpose (For details on the ln command, see the OS manual).

(6) Initialize the HiRDB file system area

Executor: HiRDB administrator

Initialize each HiRDB file system area on the erroneous disk with the pdfmkfs command.

(a) System files created on the erroneous disk

Use the pdfmkfs command to initialize a HiRDB file system area for system files:

pdfmkfs -n 40 -l 5 -k SYS -i /sysfile_a

Explanation

-n: Specifies the size of the HiRDB file system area. Set the size of the HiRDB file system area to be initialized so that it does not exceed the partition size. If it exceeds the partition size, the partitions physically following the HiRDB file system area may be damaged.

-l: Specifies the maximum number of files that can be created in the HiRDB file system area.

-k SYS: Specifies that this is a HiRDB file system area for system files.

-i: Specifies that the entire HiRDB file system area is to be initialized.

/sysfile_a: Specifies a name for the HiRDB file system area.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(b) RDAREAs created on the erroneous disk

Use the pdfmkfs command to initialize the HiRDB file system area for RDAREAs:

pdfmkfs -n 40 -l 5 -k DB -i /dbarea1

Explanation

-n: Specifies the size of the HiRDB file system area. Set the size of the HiRDB file system area to be initialized so that it does not exceed the partition size. If it exceeds the partition size, the partitions physically following the HiRDB file system area may be damaged.

-l: Specifies the maximum number of files that can be created in the HiRDB file system area.

-k DB: Specifies that this is an HiRDB file system area for RDAREAs.

-i: Specifies that the entire HiRDB file system area is to be initialized.

/dbarea1: Specifies a name for the HiRDB file system area.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

(7) Create system files

Create system files in the HiRDB file system area that was initialized in (6)(a) above.

pdloginit -d sys -f /sysfile_a/log1a -n 2000          1
pdloginit -d sys -f /sysfile_a/log2a -n 2000
pdloginit -d sys -f /sysfile_a/log3a -n 2000
pdloginit -d sys -f /sysfile_a/log4a -n 2000
pdloginit -d spd -f /sysfile_a/sync1 -n 1000          2
pdloginit -d spd -f /sysfile_a/sync3 -n 1000
pdstsinit -u UNT1 -f /sysfile_a/usts1a -c 500         3
pdstsinit -u UNT1 -f /sysfile_a/usts2a -c 500
pdstsinit -s bes1 -f /sysfile_a/b1sts1a -c 500        4
pdstsinit -s bes1 -f /sysfile_a/b1sts2a -c 500

Explanation

Creates system log files.

Creates synchronization point dump files.

Creates unit status files.

Creates server status files.

(8) Restore RDAREAs

Restore the RDAREAs on the erroneous disk with the pdrstr command. For an example of restoring RDAREAs, see 19. Database Recovery Procedures.

Note

If the erroneous disk contains the master directory RDAREAs, start HiRDB with the pdstart -r command and use the pdrstr command to restore the master directory RDAREA. For details on how to handle an error in the master directory RDAREA, see 18.4.3 Actions to be taken in the event of an error in the master directory RDAREA.

18.17 When a HiRDB (unit) terminates due to a system log file space shortage

This section explains the actions to be taken when HiRDB (unit) terminates due to a system log file space shortage.

Organization of this section

18.17.1 Restart procedure

18.17.2 Determining the minimum number of system log files to be added

18.17.3 Creating a file in swappable target status

18.17.4 Creating a HiRDB file system area for system files

18.17.5 Determining the number of system log files to be used as input files during restart

18.17.6 Checking for synchronization point dump validation

18.17.1 Restart procedure

When HiRDB runs out of current system log files due to a shortage of space, it issues the KFPS01220-E message and terminates itself (unit) abnormally. When this happens, abort code Psjnf07 or Psjn381 is output. The HiRDB administrator must restart the job using the procedure shown below:

Procedure

The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 5 is explained in paragraph (5) below.

¹ This step is explained in Section 18.17.2 Determining the minimum number of system log files to be added.

² This step is explained in Section 18.17.3 Creating a file in swappable target status.

Messages can be checked during the procedure explained below. Because messages in the HiRDB message log files ($PDDIR/spool/pdlog1 and pdlog2) may have been overwritten, check the messages in syslogfile.

Organization of this subsection

(1) Determine the server that caused the abnormal termination (for a HiRDB/Parallel Server)

(2) Determine the number of system log files to be used as input information during restart

(3) Use the pdfstatfs command to determine if there is enough space in the HiRDB file system area for system files

(4) Add the pdlogadfg and pdlogadpf operands in the server definition

(5) Use the pdloginit command to add the system log files

(6) Enter the pdstart command to restart the unit

(7) Check that the synchronization point dump has been validated

(8) Use the pdcopy command to back up data (applicable to operation without unloading of the system log)

(9) Use the pdlogls command to determine if there is a system log file in swappable target status

(10) Restart the application

(11) Reevaluate the size of the system log files

(1) Determine the server that caused the abnormal termination (for a HiRDB/Parallel Server)

The server that caused the abnormal termination can be determined from the KFPS01220-E message:

Contents of the syslogfile

KFPS01220-E PRDT untF Request to swap sys(bes1) log file unable to be executed
because there is no standby log file group available.(13830)

In this example, bes1 is the cause of abnormal termination. Assume for this example that this server's system log files are organized as follows:

(2) Determine the number of system log files to be used as input information during restart

The number of system log files to be used as the input information during restart can be determined from the KFPS01229-I message and the pdlogls command.

Reference note

A method other than this method can also be used to determine the number of system log files to be used as input information during restart. For details on the other method, see 18.17.5 Determining the number of system log files to be used as input files during restart.

If pd_mode_conf=AUTO or pd_mode_conf=MANUAL1 is specified, automatic restart processing was executed several times after the unit terminated abnormally, in which case the KFPS01229-I message was output each time. The first KFPS01229-I message that was output during the first abnormal termination (during online operation) is the one that must be used.

Contents of the syslogfile

KFPS01220-E PRDT untF Request to swap sys(bes1) log file unable to be executed
because there is no standby log file group available.(13830)
KFPO00105-E PRDT untF Server _log1s(process ID=13830) killed by
code=Psjnf07(13830)
KFPS01821-E PRDT untF Unable to continue HiRDB unit processing because serious
error occurred; stops HiRDB unit untF (13776)
KFPS01229-I PRDT untF Next bes1 log file restart point,generation number=4,
block number=d. restart end point, generation number=6, blocknumber=11.
last acquired syncpoint dump 1998/11/15 15:54:41 (13776)

Execution results of the pdlogls command:

pdlogls -d sys -s bes1

HOSTNAME : dcm3500(163541)
***** Off-line Information *****
Group    Type Server   Gen No.  Status    Run ID      Block No.
logfg01  sys  bes1     1        cna---u  364a4ac2     1       6
logfg02  sys  bes1     2        cna---u  364a4ac2     7       9
logfg03  sys  bes1     3        cna---u  364a4ac2     a       c
logfg04  sys  bes1     4        cna---u  364a4ac2     d       e
logfg05  sys  bes1     5        cna---u  364a4ac2     f       10
logfg06  sys  bes1     6        cn---cu  364a4ac2     11      0
logfg07  sys  bes1     0        cn-----  00000000​     0       0
logfg08  sys  bes1     0        cn-----  00000000​     0       0

Explanation

The KFPS01229-I message displays information about the system log files that are to be used as the input information during the restart. In this example, the input start generation is 4 and the input end generation is 6 for the system log files to be used during the restart. Files with generation numbers (Gen No) 4 to 6 (logfg04, logfg05, logfg06) are the system log files to be used as the input information during the restart. Therefore, a total of 3 system log files are used as the input information during the restart.

If the number of system log files that can be added equals number-of-system-log-files-used-as-input-during-restart + 1 (3 + 1 = 4), HiRDB can be restarted. Otherwise, determine the minimum number of system log files to be added by referring to 18.17.2 Determining the minimum number of system log files to be added. Then change files in overwrite-enabled status to swappable status and restart HiRDB.

(3) Use the pdfstatfs command to determine if there is enough space in the HiRDB file system area for system files

Use the pdfstatfs command to determine if there is enough space in the HiRDB file system area to add the four system log files determined in step (2).

pdfstatfs /bes1/sysfile_a
pdfstatfs /bes1/sysfile_b

The following procedure is used to determine the size of one system log file:

Procedure

To determine the system log file size:

Use the pdfls command to check the number of records in the existing system log file.

The size of one system log file can be obtained from the following formula, where a is the number of records obtained in step 1:
a 4096 (bytes)

When there is not enough space in the HiRDB file system area

If there is not enough space in the HiRDB file system area to add the four system log files determined in step (2), take one of the following actions:

See 18.17.2 Determining the minimum number of system log files to be added to determine the minimum number of files to be added. Then place overwrite-enabled files in swappable target status.

Create a HiRDB file system area for system files on the hard disk, then add the system log files there. For details on how to create a HiRDB file system area for system files, see 18.17.4 Creating a HiRDB file system area for system files.

System log files cannot be added if there is not enough space on the hard disk (otherwise, the unit cannot be restarted). In such a case, add a new hard disk and create a HiRDB file system area for system files there.

(4) Add the pdlogadfg and pdlogadpf operands in the server definition

pdlogadfg -d sys -g logfg09 ONL
pdlogadpf -d sys -g logfg09 -a /bes1/sysfile_a/log09a\
                           -b /bes1/sysfile_b/log09b
pdlogadfg -d sys -g logfg10 ONL
pdlogadpf -d sys -g logfg10 -a /bes1/sysfile_a/log10a\
                           -b /bes1/sysfile_b/log10b
pdlogadfg -d sys -g logfg11 ONL
pdlogadpf -d sys -g logfg11 -a /bes1/sysfile_a/log11a\
                           -b /bes1/sysfile_b/log11b
pdlogadfg -d sys -g logfg12 ONL
pdlogadpf -d sys -g logfg12 -a /bes1/sysfile_a/log12a\
                           -b /bes1/sysfile_b/log12b

Specify the pdlogadfg and pdlogadpf operands for the system log files to be added. In this example, four files are added to each of versions A and B.

Note

If HiRDB Datareplicator is running, it must be terminated. HiRDB Datareplicator can be started after steps (4) and (5) have been completed.

(5) Use the pdloginit command to add the system log files

pdloginit -d sys -s bes1 -f /bes1/sysfile_a/log09a -n 5000
pdloginit -d sys -s bes1 -f /bes1/sysfile_b/log09b -n 5000
pdloginit -d sys -s bes1 -f /bes1/sysfile_a/log10a -n 5000
pdloginit -d sys -s bes1 -f /bes1/sysfile_b/log10b -n 5000
pdloginit -d sys -s bes1 -f /bes1/sysfile_a/log11a -n 5000
pdloginit -d sys -s bes1 -f /bes1/sysfile_b/log11b -n 5000
pdloginit -d sys -s bes1 -f /bes1/sysfile_a/log12a -n 5000
pdloginit -d sys -s bes1 -f /bes1/sysfile_b/log12b -n 5000

In this example, four files are added to each of versions A and B.

(6) Enter the pdstart command to restart the unit

HiRDB/Single Server

pdstart

HiRDB/Parallel Server

In the case of a HiRDB/Parallel Server, restart the applicable unit.

pdstart -u untF

Although jobs can be accepted immediately after HiRDB (the unit) has been restarted, do not resume jobs yet. Immediately after HiRDB (the unit) is restarted, HiRDB is still recovering the database. If many database-updating jobs are entered at this point, a system log file space shortage may occur again. If that happens, HiRDB (the unit) will terminate abnormally again. Therefore, refrain from resuming jobs until all the steps through (9) have been completed.

(7) Check that the synchronization point dump has been validated

When HiRDB is restarted, a synchronization point dump is validated, in which case the KFPS02183-I message is output. A check should be made that the synchronization point dump has been validated before the next step is executed.

Note that the KFPS02183-I message is output only if Y was specified in the pd_spd_assurance_msg operand or if this operand was omitted. If this condition is not satisfied, check that the synchronization point dump is validated using the procedure explained in Section 18.17.6 Checking for synchronization point dump validation.

(8) Use the pdcopy command to back up data (applicable to operation without unloading of the system log)

pdcopy -m dcm3500:/dbarea/area1/rdmt1 -M x -p /usr/ofile -f /usr/seifile/cfl
-z /usr/bes1/logpoint02

If operation without unloading of the system log was in effect, use the database copy utility (pdcopy command) to back up all RDAREAs in the server before restarting an application. In such a case, specify the -z option to determine the log point information file.

After backing up the RDAREAs, use the pdlogchg -z command to release the system log file and place it in unload completed status:

pdlogchg -z /usr/bes1/logpoint02 [-x host_name]

(9) Use the pdlogls command to determine if there is a system log file in swappable target status

pdlogls -d sys -s bes1

If there is no file in swappable target status, HiRDB may terminate abnormally again. Immediately create a file in swappable target status. For example, if a file can be placed in swappable target status by releasing it from unload wait status, use the pdlogunld command to unload the system log.

(10) Restart the application

Restart the application.

(11) Reevaluate the size of the system log files

Reevaluate the size of the system log files. For details on how to obtain the size of system log files, see the manual HiRDB Version 8 Installation and Design Guide. If any added system log file is not needed, delete it. The procedure for deleting a system log file is shown below.

If operation without unloading of the system log is being used, a system log file cannot be deleted while it is in use as the current system log file. Check that the system log file to be deleted is not the current file, execute step (8) again, then delete the system log file.

Procedure

To delete a system log file:

Enter the pdstop command to terminate HiRDB normally.

Unload the system log file to be deleted, or change its status.

If HiRDB Datareplicator is being used, check that it has finished extracting the system log file that is to be deleted.

If HiRDB Datareplicator is running, terminate it.

Use the pdlogrm command to delete the system log file.

Delete the pdlogadfg and pdlogadpf operands for the deleted system log file.

Enter the pdstart command to start HiRDB normally.

If HiRDB Datareplicator is being used, start HiRDB Datareplicator.

18.17.2 Determining the minimum number of system log files to be added

The following formula is used to obtain the minimum number of system log files to be added:

Formula

Minimum-number-of-system-log-files-to-be-added = L - {N - (M + Z*)}

When the result of this formula is less than 1, there is no need to add system log files.

L: Number of system log files to be used as the input information during restart

This is the value derived as described in 18.17.1(2) Determine the number of system log files to be used as input information during restart.

M: Number of system log files in overwrite disabled status

See (1) below for the procedure for determining the number of system log files in overwrite disabled status.

N: Total number of system log files in the server

Count the number of spare files also. For details about spare files, see 18.17.3(3) Use a spare file.

Z: Number of system log files in overwrite enabled and unload wait status

* Add this value if operation without unloading of the system log is being used.

Organization of this subsection

(1) Determining the number of system log files in overwrite disabled status

(2) Determining the number of system log files in overwrite disabled status (number of valid generations = 2)

(1) Determining the number of system log files in overwrite disabled status

The pdlogls command cannot be used during offline operation to determine whether or not a system log file is in overwrite disabled status. The number of system log files in overwrite disabled status can be determined from messages that are output during restart processing:

Contents of the syslogfile

KFPS01800-I PRDT untF Now starting HiRDB unit untF (19924)
KFPS01262-I PRDT untF Log block reading started. type:sys(bes1),
read start point:logfg04,4,d (19993)
KFPS01182-I PRDT untF Generation file groups changed for further
reading of log blocks. type:sys(bes1), from:logfg04,4, to:logfg05,5,
read direction:f (19993)
KFPS01182-I PRDT untF Generation file groups changed for further
reading of log blocks. type:sys(bes1), from:logfg05,5, to:logfg06,6,
read direction:f (19993)
KFPS01182-I PRDT untF Generation file groups changed for further
reading of log blocks. type:sys(bes1), from:logfg06,6, to:logfg07,7,
read direction:f (19993)
KFPS01263-I PRDT untF Log block reading completed. type:sys(bes1),
read end point:logfg07,7,1e (19993)
KFPS01220-E PRDT untF Request to swap sys(bes1) log file unable to be
executed because there is no standby log file group available. (19993)
KFPO00105-E PRDT untF Server _log1s(process ID=19993) killed by
code=Psjnf07(19993)
KFPS01821-E PRDT untF Unable to continue HiRDB unit processing because
serious error occurred; stops HiRDB unit untF (19979)

Explanation

KFPS01262-I, KFPS01182-I, and KFPS01263-I indicate that system log files logfg04, logfg05, logfg06, and logfg07 are used during the restart. These are the overwrite disabled files, so the number of system log files in overwrite disabled status is 4:

Reference note

If pd_mode_conf=AUTO or pd_mode_conf=MANUAL1 is specified, automatic restart processing was executed several times after the unit terminated abnormally and these messages were output each time. The set of messages that was output during the first abnormal termination are the ones that must be used.

If pd_mode_conf=MANUAL2 is specified and restart processing is not performed (the pdstart command is not entered), the number of system log files used as input information during restart (the value derived as described in 18.17.1(2) Determine the number of system log files to be used as input information during restart) is the number of overwrite-disabled files.

If the number of guaranteed valid generations of synchronization point dump files is 2 (if pd_spd_assurance_count=2 is specified), the number of overwrite-disabled files may increase further. Check by using the method shown below in (2) Determining the number of system log files in overwrite disabled status (number of valid generations = 2).

(2) Determining the number of system log files in overwrite disabled status (number of valid generations = 2)

In (1) above, the system log files in overwrite disabled status that were in existence after the most recent synchronization point dump generation was validated were identified. If the number of synchronization point dump guaranteed valid generations is 2, the files in overwrite disabled status that were in existence up to the point where the previous synchronization point dump generation was validated must also be identified. There are two ways to identify these files:

Using the synchronization point dump validation completion message (KFPS02183-I)

Using the synchronization point dump validation skip message (KFPS02179-I)

(a) Using the synchronization point dump validation completion message (KFPS02183-I)

The files in overwrite disabled status can be identified using the KFPS02183-I message and the pdlogls command:

Contents of the syslogfile

KFPS05210-I PRDT untF HiRDB system initialization process complete(13778)
KFPS01221-I PRDT untF logfg03 assigned as current file group of sys(bes1)
log file. generation number=3, first block number=a (13830)
KFPS02183-I PRDT untF Syncpoint dump for bes1 has been acquired to file
group spdfg03. log file information:logfg03, 3, a. start time=15:53:11,
end time=15:53:11 (13830)    ...1

KFPS02183-I PRDT untF Syncpoint dump for bes1 has been acquired to file
group spdfg04.  log file information:logfg04, 4, d. start time=15:54:40,
end time=15:54:41 (13830)    ...2

KFPS01222-I PRDT untF logfg04 released from sys(bes1) log file. generation
number=4, first block number=d, last block number=e (13830)
KFPS01224-I PRDT untF sys(bes1) log does not have standby file group
available for next swapping. (13830)
KFPS01220-E PRDT untF Request to swap sys(bes1) log file unable to be
executed because there is no standby log file group available.(13830)
KFPO00105-E PRDT untF Server _log1s(process ID=13830) killed by code=
Psjnf07(13830)
KFPS01821-E PRDT untF Unable to continue HiRDB unit processing because
serious error occurred; stops HiRDB unit untF (13776)
KFPS01229-I PRDT untF Next bes1 log file restart point, generation
number=4, block number=d. restart end point, generationnumber=7,
block number=1c. last acquired syncpoint dump 1998/11/15 15:54:41 (13776)

pdlogls command execution results:

pdlogls -d sys -s bes1

HOSTNAME : dcm3500(163541)
***** Off-line Information *****
Group    Type Server   Gen No.  Status    Run ID       Block No.
logfg01  sys  bes1     1        cna---u   364a4ac2     1        6
logfg02  sys  bes1     2        cna---u   364a4ac2     7        9
logfg03  sys  bes1     3       cna---u   364a4ac2     a        c
logfg04  sys  bes1     4       cna---u   364a4ac2     d        e
logfg05  sys  bes1     5        cna---u   364a4ac2     f        10
logfg06  sys  bes1     6        cna---u   364a4ac2     11       11
logfg07  sys  bes1     7        cn---cu   364a4ac2     12       0
logfg08  sys  bes1     0        cn-----   00000000​     0        0

Explanation

This is the message regarding validation of the previous synchronization point dump generation. The indicated system log file is logfg03 (generation number 3).

This is the message regarding the most recent synchronization point dump generation. The indicated system log file is logfg04 (generation number 4).

It is clear from the first message that logfg03 is also in overwrite disabled status. Therefore, logfg03 through logfg07 are all in overwrite disabled status:

(b) Using the synchronization point dump validation skip message (KFPS02179-I)

The files in overwrite disabled status can be identified from the KFPS02179-I message:

Contents of the syslogfile

KFPS01221-I PRDT untF logfg02 assigned as current file group of sys(bes1)
log file. generation number=b, first block number=66 (5075)
KFPS01222-I PRDT untF logfg02 released from sys(bes1) log file. generation
number=b, first block number=66, last block number=66 (5075)
KFPS01221-I PRDT untF logfg03 assigned as current file group of sys(bes1)
log file. generation number=c, first block number=67 (5075)   ...3

KFPS01222-I PRDT untF logfg03 released from sys(bes1) log file.generation
number=c, first block number=67, last block number=68 (5075)
KFPS01221-I PRDT untF logfg04 assigned as current file group of sys(bes1)
log file.generation number=d, first block number=69 (5075)   ...1

KFPS02179-I PRDT untF Syncpoint dump acquisition opportunities for bes1
service were skipped.number of skip=1,log generation number=d factor
code=A01-02 (5054)   ...2

KFPS02179-I PRDT untF Syncpoint dump acquisition opportunities for bes1
service were skipped.number of skip=1,log generation number=d factor
code=A01-02 (5054)
KFPS01222-I PRDT untF logfg04 released from sys(bes1) log file.generation
number=d, first block number=69, last block number=73 (5075)

Explanation

Look for the KFPS01221-I message indicating that logfg04, which is the system log input start point during the restart, was allocated as the current file.

Look for the KFPS02179-I message indicating that the validation skips count was set to 1 while logfg04 was being used as the current file.

If the KFPS02179-I message was output while logfg04's predecessor (logfg03) was used as the current system log file, look for the KFPS02179-I message indicating the validation skips count = 1, and identify the system log file that was being used as the current file when that message was output. Then determine the additional number of overwrite-disabled system log files from the following table:

Condition | Output of KFPS02179-I message while the previous system log file generation was allocated as the current file
Output | Not output
Validation skips count 1 | Validation skips count = 1
Output of KFPS02179-I message while the input start system log file was allocated as the current file at the restart | Output | (Number of files existing up to the point where the message indicating skips count = 1 was output) + 1 | 2 | 2
Not output | 1

Note

The number of files in overwrite disabled status determined in (1) plus the number of overwrite-disabled files determined above cannot exceed the total number of system log files in the corresponding HiRDB server. If the total number of system log files is exceeded, the total number of system log files in the corresponding HiRDB server must be used as the total number of overwrite-disabled system log files.

In this example, the KFPS02179-I message was output while logfg04, which is at the system log input start point during restart, was allocated as the current file. The KFPS02179-I message was not output while its predecessor, logfg03, was allocated as the current file. Therefore, logfg03 and logfg02 are identified as the system log files in overwrite disabled status, and a value of 2 is added to the result of (1).

18.17.3 Creating a file in swappable target status

This section explains the procedures for placing overwrite-enabled files and spare files in swappable target status.

Organization of this subsection

(1) Change the file status from unload wait to unload completed

(2) Wait until the file status changes from extracting status to extraction-completed status

(3) Use a spare file

(1) Change the file status from unload wait to unload completed

Use the pdlogls command to check for files in unload wait status. Use the pdlogunld or pdlogchg command to change their file status from unload wait to unload completed.

Note

This procedure must not be used when operation without unloading system log is being used. In this operation mode, once a system log file in unload wait status is unloaded or its file status is changed, the database recovery method is no longer applicable. If a space shortage occurs in the system log file, add a new system log file and restart the system.

(2) Wait until the file status changes from extracting status to extraction-completed status

During offline operation, the pdlogls command cannot be used to determine whether or not a file is in extraction-completed status. Instead, the pdls -d rpl -j command can be used to determine whether the system log is being extracted by the HiRDB Datareplicator at the extracted side. If it is being extracted, there is a file in extracting status. The following is the procedure for determining whether or not the system log is being extracted:

pdls command execution results

pdls -d rpl -s bes1 -j

SYSTEMID         : PRDT(185014)
Data replication : *
UNITID           : untF(185014)
Data replication : Y
SERVER NAME      : bes1
Extract Database : Y
Extract Status   : C
System Log Extract Point :
Run ID    Group    Gen No.  BLock No.
364a4ac2  logfg01      1       2
System Log Sync Info     :
Run ID    Group    Gen No.  BLock No.
364a4ac2  logfg07      7       1e

Explanation

The generation number of the current system log file is 7, while that of the system log file subject to extraction is 1. This means that there is a file in extracting status. If HiRDB Datareplicator is not active, start it and extract the system log.

pdls command execution results

pdls -d rpl -s bes1 -j

SYSTEMID         : PRDT(185612)
Data replication : *
UNITID           : untF(185612)
Data replication : Y
SERVER NAME      : bes1
Extract Database : Y
Extract Status   : C
System Log Extract Point :
Run ID    Group    Gen No.  BLock No.
364a4ac2  logfg07      7       20
System Log Sync Info     :
Run ID    Group    Gen No.  BLock No.
364a4ac2  logfg07      7       1e

Explanation

The generation number of the current system log file is 7, while that of the system log file subject to extraction is also 7. Therefore, all files are in extraction-completed status.

(3) Use a spare file

If there is a spare file, place it in swappable target status before using it. A spare file is a system log file whose entity has been created but it is not used because ONL is not specified in the pdlogadfg operand in the server definition.

To use a spare file, specify Y in the pd_log_rerun_reserved_file_open operand in the server definition.

Hint

Before executing this procedure, ensure that the spare file is not currently in use. The pdlogls command can be used to determine whether or not a specified spare file is in use.

pdlogls command execution results (spare file not in use)

pdlogls -d sys -s bes1

HOSTNAME : dcm3500(163541)
***** Off-line Information *****
Group    Type Server   Gen No.  Status    Run ID      Block No.
logfg01  sys  bes1     9        cna---u   364a4ac2    101      106
logfg02  sys  bes1     a        cna---u   364a4ac2    107      109
logfg03  sys  bes1     b        cna---u   364a4ac2    10a      10c
logfg04  sys  bes1     c        cna---u   364a4ac2    10d      10e
logfg05  sys  bes1     d        cna---u   364a4ac2    10f      110
logfg06  sys  bes1     e        cn---cu   364a4ac2    111      0
logfg07  sys  bes1     f        cn----u   36491223​    1f0      201
logfg08  sys  bes1     0        cn-----   00000000​    0        0

Explanation

logfg07 has a different Run ID than other system log files. This means that it is a spare file that is currently not in use, although it was previously used.

Because logfg08 has Run ID 0, it is a spare file that has never been used.

pdlogls command execution results (spare file in use)

pdlogls -d sys -s bes1

HOSTNAME : dcm3500(163541)
***** Off-line Information *****
Group    Type Server   Gen No.  Status    Run ID      Block No.
logfg01  sys  bes1     9        cna---u   364a4ac2    101      106
logfg02  sys  bes1     a        cna---u   364a4ac2    107      109
logfg03  sys  bes1     b        cna---u   364a4ac2    10a      10c
logfg04  sys  bes1     c        cna---u   364a4ac2    10d      10e
logfg05  sys  bes1     d        cna---u   364a4ac2    10f      110
logfg06  sys  bes1     e        cn---cu   364a4ac2    111      0
logfg07  sys  bes1     7        cnu---u   364a4ac2    e3       ef
logfg08  sys  bes1     8        cne---u   364a4ac2    f0       100

Explanation

Because both logfg07 and logfg08 have the same Run ID as the other system log files and their generation numbers are consecutive with the other system log files, they are currently in use.

18.17.4 Creating a HiRDB file system area for system files

Figure 18-4 shows the procedure for creating a HiRDB file system area for system files.

Figure 18-4 Procedure for creating a HiRDB file system area for system files

Note

The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 3 is explained in paragraph (3) below.

Organization of this subsection

(1) Initialize the hard disk

(2) Set partitions

(3) Initialize the UNIX file system (applicable to regular files)

(4) Change each character special file's owner and access privileges (applicable to character special files)

(5) Link the file names symbolically

(6) Initialize the HiRDB file system area for system files

(1) Initialize the hard disk

Executor: Superuser

Initialize the hard disk.

Initialize the hard disk; for the procedure, see the OS manual.

(2) Set partitions

Executor: Superuser

Set partitions on the initialized hard disk.

Set partitions on the initialized hard disk; for the procedure, see the OS manual.

(3) Initialize the UNIX file system (applicable to regular files)

Executor: Superuser

If regular files had been used in the HiRDB file system area, initialize the partitions as a UNIX file system; for the procedure, see the OS manual.

If the partitions are already initialized, skip this step.

(4) Change each character special file's owner and access privileges (applicable to character special files)

Executor: Superuser

Change the owner and access privileges of the HiRDB file system area, so it will be protected from unauthorized accesses. Table 18-20 shows the owner and access privileges to be set for the HiRDB file system area.

Table 18-20 Owner and access privileges to be set for HiRDB file system area (HiRDB file system area for system files)

Owner, access privileges | Information to be set | Command to be executed*
Owner | User ID | HiRDB administrator | chown command
Group ID | HiRDB group | chgrp command
Access privilege | Owner | rw- (read and write operations permitted) | chmod command
Group | rw- (read and write operations permitted)
Other | --- (access denied)

* These are OS commands; for details, see the OS manual.

(5) Link the file names symbolically

Executor: Superuser

For a HiRDB file system area, a name linked symbolically to its entity by the ln OS command should be used instead of using the name of its character special file or regular file entity as is. When a symbolically linked name is used, the HiRDB file system area can be restored easily onto another hard disk in the event of a hard disk failure.

For details on the ln command, see the OS manual.

(6) Initialize the HiRDB file system area for system files

Executor: HiRDB administrator

Use the pdfmkfs command to initialize the HiRDB file system area for system files:

pdfmkfs -n 40 -l 5 -k SYS /sysfile_c

Explanation

-n: Specifies the size of the HiRDB file system area. Set the size of the HiRDB file system area to be initialized so that it does not exceed the partition size. If it exceeds the partition size, the partitions physically following the HiRDB file system area may be damaged.

-l: Specifies the maximum number of files that can be created in the HiRDB file system area.

-k SYS: Specifies that this is a HiRDB file system area for system files.

/sysfile_c: Specifies a name for the HiRDB file system area.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

Duplicating the HiRDB file system area using a mirror disk

If the HiRDB file system area is to be duplicated using a mirror disk, do the following:

3050RX group or 3500/3xx
In the pdfmkfs command, specify the name of the character special file on the master disk (/dev/rdsk/rdskxxx) or the name linked to it symbolically.

3500 series (except 3500/3xx)
In the pdfmkfs command, specify the mirror special file name (/dev/mirror/rdskxxx) or the name linked to it symbolically.

18.17.5 Determining the number of system log files to be used as input files during restart

This section shows the procedure for determining the number of system log files to be used as input files during a restart when this information cannot be obtained from the KFPS01229-I message. The procedure is shown below.

Contents of the syslogfile

KFPS01220-E PRDT untF Request to swap sys(bes1) log file unable to
be executed because there is no standby log file group
available.(13830)    ...1

KFPO00105-E PRDT untF Server _log1s(process ID=13830) killed by code=
Psjnf07(13830)
KFPS01821-E PRDT untF Unable to continue HiRDB unit processing because
serious error occurred; stops HiRDB unit untF (13776)
KFPS01800-I PRDT untF Now starting HiRDB unit untF (18534)    ...2

KFPS01262-I PRDT untF Log block reading started. type:sys(bes1), read
start point:logfg04,4,d (18641)     ...3

KFPS01182-I PRDT untF Generation file groups changed for further reading
of log blocks. type:sys(bes1), from:logfg04,4, to:logfg05,5,read
direction:f (18641)
KFPS01182-I PRDT untF Generation file groups changed for further reading
of log blocks. type:sys(bes1), from:logfg05,5, to:logfg06,6,read
direction:f (18641)
KFPS01263-I PRDT untF Log block reading completed. type:sys(bes1),read
end point:logfg06,6,11c (18641)

KFPS01220-E PRDT untF Request to swap sys(bes1) log file unable to
be executed because there is no standby log file group
available.(18641)    ...4

KFPO00105-E PRDT untF Server _log1s(process ID=18641) killed by code=
Psjnf07(18641)

Explanation

This message indicates the first space shortage in the system log file (during online operation).

This message indicates the first restart processing.
If pd_mode_conf=AUTO or pd_mode_conf=MANUAL1 is specified, automatic restart processing was executed several times after the unit terminated abnormally, in which case the messages indicated as 3 were output each time. The messages that were output during the first restart processing are the ones that must be used.

The KFPS01262-I, KFPS01182-I, and KFPS01263-I messages indicate that logfg04, logfg05, and logfg06 are the system log files to be used as the input files during the restart. Therefore, the number of system log files to be used as the input information during the restart is 3.

This message indicates a space shortage in the system log file that occurred during restart processing.

Note

If pd_mode_conf=MANUAL2 is specified, restart HiRDB with the pdstart command in order to output these messages.

18.17.6 Checking for synchronization point dump validation

This section explains the procedure for checking for synchronization point dump validation when the KFPS02183-I message cannot be used for this verification due to a problem with respect to the HiRDB version, etc. This procedure uses the pdlogls command to check for status changes in system log files immediately after restart and after synchronization point dump validation.

pdlogls command execution results (immediately after restart)

pdlogls -d sys -s bes1

HOSTNAME : dcm3500(170302)
Group    Type Server   Gen No.  Status    Run ID       Block No.
logfg01  sys  bes1     11       oc-d--u   365d303d     93      97
logfg02  sys  bes1     b        os----u   365d303d     66      66
logfg03  sys  bes1     c        os----u   365d303d     67      68
logfg04  sys  bes1     d        osud--u   365d303d     69      73
logfg05  sys  bes1     e        osud--u   365d303d     74      7a
logfg06  sys  bes1     f        osud--u   365d303d     7b      82
logfg07  sys  bes1     10       osudb-u   365d303d     83      92
logfg08  sys  bes1     0        cn-----   00000000​     0       0

Explanation

These execution results indicate that the files in overwrite disabled status in existence immediately after the restart are logfg01 and logfg04 to logfg07.

pdlogls command execution results (after synchronization point dump validation)

pdlogls -d sys -s bes1

HOSTNAME : dcm3500(170424)
Group    Type Server   Gen No.  Status     Run ID       Block No.
logfg01  sys  bes1     11       osu---u    365d303d     93       99
logfg02  sys  bes1     12       osu---u    365d303d     9a       a2
logfg03  sys  bes1     13       osu---u    365d303d     a3       a9
logfg04  sys  bes1     d        osu---u    365d303d     69       73
logfg05  sys  bes1     e        osu---u    365d303d     74       7a
logfg06  sys  bes1     f        osu---u    365d303d     7b       82
logfg07  sys  bes1     10       osu---u    365d303d     83       92
logfg08  sys  bes1     14       oc-d--u    365d303d     aa       af

Explanation

These execution results indicate that the file in overwrite disabled status in existence after synchronization point dump validation is logfg08. It is clear that the synchronization point dump was validated because the file in overwrite disabled status followed the system log input start point during restart.

18.18 When a utility terminates abnormally during execution of a reorganization with synchronization points set

This section explains the actions to be taken when a utility terminates abnormally during execution of reorganization with synchronization points set.

Organization of this section

18.18.1 Overview of actions

18.18.2 Example

18.18.3 Actions to be taken when a utility terminates abnormally before unload data files have been consolidated (HiRDB/Parallel Server only)

18.18.4 Notes

18.18.1 Overview of actions

The actions to be taken depend on the timing of the abnormal termination. Figure 18-5 shows the actions to be taken when a utility terminates abnormally during execution of a reorganization with synchronization points set.

Figure 18-5 Actions to be taken when a utility terminates abnormally during execution of a reorganization with synchronization points set

Note: Steps 6 and 7 may be performed in either order.

¹ When the -g option is specified for execution of the database reorganization utility, KFPL00732-I is output.

² When the -g option is specified for execution of the database reorganization utility, KFPL00733-I is output.

Explanation

The total number of data cases is 3 million; the number of synchronization points is 1 million.

If the utility terminates abnormally at point 1, re-execute table reorganization.

If the utility terminates abnormally at a point between 2 and 5, unloading has been completed. Therefore, use the database reorganization utility (-k reld) to execute reloading.

If the utility terminates abnormally at point 6, reloading of table data has been completed. Therefore, create only the plug-in index and the B-tree index. Using the created index information file as the input information, use the database reorganization utility to create the plug-in index and B-tree index in the batch mode (-k ixmk).

If the utility terminates abnormally at point 7, create only the B-tree index. Using the created index information file as the input information, use the database reorganization utility to create the B-tree index in the batch mode (-k ixmk).

18.18.2 Example

The database reorganization utility terminated abnormally during reorganization of a table containing 3 million data cases. The number of synchronization points is 1 million.

Organization of this subsection

(1) Check for messages

(2) Use the pdrorg command to execute reloading

(3) Check for messages

(4) Back up the RDAREAs that were reloaded

(5) Use the pdrels command to release RDAREAs in shutdown status

(1) Check for messages

The following messages have been output:

KFPL00714-I  unload ended, table=USR01.TABLE1, server=sds01, return code=0

KFPL00800-I Loading until 2000000​th row committed

Explanation

Message KFPL00714-I indicates that unloading has been completed.

Message KFPL00800-I indicates that reloading of up to 2 million cases has been completed.

(2) Use the pdrorg command to execute reloading

Use the database reorganization utility to reload the remaining 1 million cases and create the index.

pdrorg -k reld -t TABLE1 /pdrorg/rorg01

Explanation

Change the specification of the -k option only; change it from rorg to reld. The specifications of other options need not be modified.

(3) Check for messages

Determine whether or not the database reorganization utility terminated normally by checking for the KFPL00719-I message.

KFPL00719-I  Pdrorg terminated, return code=0

(4) Back up the RDAREAs that were reloaded

Because you reloaded the RDAREAs in the pre-update log acquisition mode (default), back up the RDAREAs that were reloaded. For details about backing up RDAREAs, see 6.4.6 Example 6 (Backing up RDAREAs).

(5) Use the pdrels command to release RDAREAs in shutdown status

Use the pdrels command to release the table-storage and index-storage RDAREAs that are in shutdown status.

pdrels -r RDAREA1,RDAREA2,RDAREA3

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

18.18.3 Actions to be taken when a utility terminates abnormally before unload data files have been consolidated (HiRDB/Parallel Server only)

When a table is row-partitioned into multiple back-end servers, unload data file consolidation (-g specification for the database reorganization utility) is recommended. If the unload data files are not consolidated, the actions to be taken when the utility terminates abnormally become complicated.

This section explains the actions to be taken when a utility terminates abnormally during reorganization or reloading with synchronization points set before the unload data files have been consolidated.

Organization of this subsection

(1) Overview of actions to be taken

(2) Example

(1) Overview of actions to be taken

If the unload data files have not been consolidated, it is necessary to check whether or not reorganization processing was completed at each server. Figure 18-6 shows the system configuration used for the explanation.

Figure 18-6 Case where the table is row-partitioned into multiple back-end servers

Explanation

If the unload data files are not consolidated, reorganization at BES1 may terminate abnormally during unloading, and reorganization in BES2 may terminate abnormally during reloading. In such a case, it is necessary to modify the specification in the control information file for the utility. The utility must also be re-executed for each server. In this example, the utility must be executed twice.

As explained above, the database reorganization utility must be re-executed individually for each server taking into consideration the timing of abnormal termination.

(2) Example

Reorganization with synchronization points set was executed without consolidating the unload data files. The system configuration is as shown in Figure 18-6. It is assumed that reorganization in BES1 terminated abnormally during unloading and reorganization in BES2 terminated abnormally during reloading.

(a) Specifications for the database reorganization utility when it terminated abnormally

The control information file of the database reorganization utility and the command specification when the utility terminated abnormally are shown below:

Control information file (/pdrorg/rorg01) specification

option job=j01,200
unload BES1:/unload/file01
unload BES2:/unload/file02

pdrorg command specification

pdrorg -k rorg -t TABLE1 /pdrorg/rorg01

(b) Specifications for the database reorganization utility for re-execution

Reorganization must be re-executed for the tables in BES1; reloading must be executed for the tables in BES2. Therefore, the database reorganization utility must be executed individually for BES1 and BES2.

The control information file of the database reorganization utility and the command specification for re-executing the utility are shown below.

Control information file (/pdrorg/rorg01) specification

option job=j01,200
unload BES1:/unload/file01

Control information file (/pdrorg/rorg02) specification

option job=j01,200
unload BES2:/unload/file02

pdrorg command specification

pdrorg -k rorg -t TABLE1 /pdrorg/rorg01
pdrorg -k reld -t TABLE1 /pdrorg/rorg02

18.18.4 Notes

If RDAREA re-initialization or the PURGE TABLE statement is executed before re-execution of the database reorganization utility, the synchronization point information that was set may be lost. In such a case, the re-execution will not be treated as re-execution of reorganization with synchronization points set.

If the utility terminates abnormally during reorganization with synchronization points set for a LOB column structure base table, specify CLR when the utility is re-executed. If CLR is not specified, retrieval efficiency for the LOB column may deteriorate even after reorganization.

If names for the files listed below are not stated clearly, the database reorganization utility will create these files automatically:

Index information file

Error information file

If the database reorganization utility terminates abnormally, these files will remain on the disk. Because the database reorganization utility will create files under new names during re-execution, these files remaining from before the abnormal termination may cause a space shortage on the disk. Therefore, delete these files before re-execution.

18.19 Actions when page destruction in an RDAREA is detected

Executor: HiRDB administrator

This section explains the actions to be taken when RDAREA page destruction has occurred (KFPH00308-E message is output), resulting in an RDAREA error shutdown (KFPH00306-E message is output).

Organization of this section

18.19.1 Causes of page destruction

18.19.2 Actions to be taken

18.19.1 Causes of page destruction

A page may be destroyed in the following cases:

HiRDB was started forcibly after it had terminated abnormally or had been terminated forcibly.

HiRDB was started by initializing the status files after HiRDB had terminated abnormally or had been terminated forcibly.

When RDAREAs were recovered during backup acquisition, not all related RDAREAs were recovered. For example, when a table-storage RDAREA was recovered during backup acquisition, an index-storage RDAREA was missed during recovery processing.

18.19.2 Actions to be taken

The actions to be taken are described below.

Procedure

To recover from an RDAREA shutdown:

Back up the troubleshooting information under $PDDIR/spool.

Back up the contents of the entire syslogfile before the error occurrence.

Use the pdclose command to shut down RDAREAs that are in error shutdown status and their related RDAREAs (related table and index RDAREAs).

Use the pdfbkup command to back up the files comprising the RDAREAs that are in error shutdown status and their related RDAREAs.

After the above operations have been performed, restore the RDAREAs.
There are two methods for restoring RDAREAs, as explained below.

Organization of this subsection

(1) Restoration method 1

(2) Restoration method 2

(1) Restoration method 1

If a backup for the system is available, restore the entire system during backup acquisition.

(2) Restoration method 2

Use the database structure modification utility (pdmod command) to reinitialize the RDAREAs that went into error shutdown status. This method deletes all data in the reinitialized RDAREAs. Restore the data from unload data files, input data files, etc.

The RDAREAs related to the reinitialized RDAREAs must also be restored logically.

Note that if HiRDB has not been restarted, the same error may have occurred in other RDAREAs.

18.20 Actions to take when an RDAREA I/O error occurs

Executor: HiRDB administrator

This section explains the actions to take when an RDAREA I/O error occurs. As discussed here, I/O error means a failure during HiRDB file I/O operations for which HiRDB cannot determine the reason. The error code returned in response to the request to access the HiRDB file system in such a case is -1544.

Organization of this section

(1) HiRDB processing when an RDAREA I/O error occurs

(2) When pd_db_io_error_action=unitdown (HiRDB abnormal termination) is specified

(3) Environment settings

(4) Operating method

(5) Notes

(1) HiRDB processing when an RDAREA I/O error occurs

Table 18-21 describes the processing performed by HiRDB when an RDAREA I/O error occurs.

Table 18-21 HiRDB processing when an RDAREA I/O error occurs

Type of RDAREA | HiRDB processing
pd_db_io_error_action=dbhold (default) | pd_db_io_error_action=unitdown
Master directory RDAREA | HiRDB (unit for a HiRDB/Parallel Server) terminates abnormally.
Other RDAREAs | The RDAREA is placed in error shutdown status | HiRDB (unit for a HiRDB/Parallel Server) terminates abnormally. The RDAREA is not placed in error-shutdown status, unless the I/O error recurs after the abnormal termination.

(2) When pd_db_io_error_action=unitdown (HiRDB abnormal termination) is specified

The following advantages are provided by configuring HiRDB to terminate abnormally when an RDAREA I/O error occurs:

If the error is caused by a path error, operations can be resumed upon system switchover.

The need to recover the RDAREA is eliminated.

(a) If the error is caused by a path error, operations can be resumed upon system switchover

Because HiRDB terminates abnormally when an RDAREA I/O error occurs, the system is switched over. If the cause of the I/O error is a path error, I/O processing can be performed after the system has been switched over, which means operations can resume from that point. As discussed here, path error means that HiRDB cannot access a file because the communication path between HiRDB and the file has been disrupted for some reason.

(b) The need to recover the RDAREA is eliminated

When an RDAREA I/O error occurs, HiRDB terminates abnormally without the RDAREA being placed in error shutdown status. This allows you to eliminate the cause of the I/O error before you restart HiRDB. Once you have eliminated the cause of the error, processing resumes when HiRDB is restarted. The fact that the RDAREA is not placed in error shutdown status in this case eliminates the need for you to recover it, unless, however, the disk needs to be replaced due to a disk error. In such a case, you will need to use the database recover utility to recover the RDAREA.

(3) Environment settings

To configure HiRDB to terminate abnormally when an RDAREA I/O error occurs, you must make the environment settings explained below.

(a) pd_db_io_error_action operand specification

Specify unitdown in the pd_db_io_error_action operand.

(b) If the system switchover facility is being used

If you are using the system switchover facility, see 25.20.2 RDAREA I/O error (path error) has occurred.

(c) pd_mode_conf operand specification (specify only if the system switchover facility is not being used)

To configure HiRDB so that it will not restart automatically after it terminates abnormally, specify MANUAL2 in the pd_mode_conf operand. If you specify any value other than MANUAL2, HiRDB will restart automatically after it terminates abnormally. When you have specified MANUAL2 and an I/O error occurs in the same RDAREA, that RDAREA will be placed in error shutdown status. This means that the pd_db_io_error_action=unitdown specification is ignored.

(d) Relationships with other functions

If you use functionality provided by the OS or the device driver* to specify the time until a physical volume or logical volume I/O error is detected, you must take into account the following operands:

pd_utl_exec_time operand

pd_watch_time operand

exectime operand of the option statement of the pdload, pdrorg, and pdreclaim commands

PDCWAITTIME and PDCWAITTIME operands of the client environment variables

These operands are used for monitoring execution times. If the time specified with an OS or device driver function is longer than the time specified in these operands, the functionality provided by these operands will activate before the I/O error is detected. To avoid such an occurrence, you must increase the monitoring times specified with these operands.

* An example of such a function is the -t option of the pvchange or lvchange command in HP-UX. For details about such functions, see the operating system or device driver documentation.

(4) Operating method

This section explains operations when pd_db_io_error_action=unitdown is specified.

(a) Operations when the system switchover facility is being used

If you are using the system switchover facility, see 25.20.2 RDAREA I/O error (path error) has occurred.

(b) Operations when the system switchover facility is not being used

If HiRDB terminates abnormally because an I/O error occurred, eliminate the error based on the message that is issued. Restart HiRDB after eliminating the error. Note that if the I/O error recurs after HiRDB is restarted, the RDAREA is placed in error shutdown status. In this case, use the database recovery utility to recover the RDAREA.

(c) Actions to take after HiRDB has terminated abnormally (for both (a) and (b))

If HiRDB terminates abnormally because an I/O error occurred, the pd_db_io_error_action=unitdown specification becomes invalid from that point (RDAREAs will be placed in error shutdown status). To re-enable the pd_db_io_error_action=unitdown specification, use one of the following methods:

Start HiRDB normally

Copy the HiRDB system definition files into the $PDDIR/conf/chgconf directory, and then execute the system reconfiguration command (pdchgconf command).

(5) Notes

Because HiRDB terminates abnormally when an I/O error occurs when pd_db_io_error_action=unitdown is specified, if a UAP or a utility is executing in the pre-update log acquisition mode or the no-log mode, the RDAREA being processed may be placed in error shutdown status.

If an I/O error occurs during startup or termination, HiRDB does not terminate abnormally even if pd_db_io_error_action=unitdown is specified.

18.21 Checking the transaction completion type when an error occurs during commit processing (HiRDB/Parallel Server)

Executor: HiRDB administrator

This section explains the method of checking the transaction completion type when an error occurs during commit processing.

When an error occurs during transaction execution, HiRDB performs commit or rollback processing for each server. When this processing is completed, HiRDB sets information about each transaction and the transaction completion type in a KFPS00990-I message that it outputs to the transaction's server. If an error occurred that caused a transaction to roll back on its own, HiRDB sets the transaction information and transaction completion type in a KFPS00973-I message that it outputs to the server in which updating branching occurred.

Figure 18-7 shows how to check the transaction completion type when an error has occurred. You use this procedure also when a commit error is returned for a UAP.

Figure 18-7 Checking the transaction completion type when an error has occurred

¹ Use the pdls command to check if all servers (excluding recovery-unnecessary front-end servers) are running.

² Compare the following information:

Transaction identifiers that are output in the execution results of the pdls -d trn command

Transaction identifiers that are output in the KFPS00973-I or KFPS00990-I messages

Check if any transaction identifier is output to both. If any transaction's identifier is output to both, wait for that transaction to terminate.

³ Compare the following information:

Client process ID, IP address, and UAP identification name output in the execution results of the pdls -d trn command

Process ID, IP address, and UAP identification name of a UAP for which a commit error occurred

Check if there is any transaction to which both of these apply.

When there is a transaction for which there is a match in all three items of information

Wait for that transaction to terminate.

When there is a transaction for which there is a match in only the UAP identification name, and neither the process ID nor the IP address is displayed

Take action by following the procedure below.

Check the transaction identifier of the applicable transaction.

Referring to the execution results of the pdls -d trn -a command, check if the transaction identifier found in step 1 is also displayed elsewhere.

If it is also displayed elsewhere, check if the client process ID and IP address of that transaction are displayed. If no transaction is displayed, wait for transactions to terminate.

Table 18-22 shows the transaction completion types when an error occurs during commit processing. Note that the transaction completion types in the table apply only in cases in which the front-end server or back-end server unit did not terminate abnormally.

Table 18-22 Transaction completion types when an error occurred during commit processing

Item | Error timing | Front-end server | Back-end or dictionary server | Transaction completion type
KFPS00973-I or KPFS00990-I message | Completion type that is output in message | KFPS00973-I or KPFS00990-I message | Completion type that is output in message
1 | During commit processing | Yes | Commit | Yes | Commit | Commit
2 | Rollback | Rollback
3 | No |  | Commit
4 | Rollback | Yes | Commit | Commit
5 | Rollback | Rollback
6 | No |  | Rollback
7 | No |  | Yes | Commit | Commit
8 | Rollback | Rollback
9 | No |  | Commit
10 | Before transaction completion | Yes | Rollback | Yes | Rollback | Rollback
11 | No |  | Rollback
12 | No | Yes | Rollback | Rollback
13 | No |  |

Legend:

: Not applicable

18.22 Actions to take when an error occurs while a local buffer is being used to update a shared table (HiRDB/Parallel Server only)

Executor: HiRDB administrator

You must apply LOCK TABLE to use a local buffer to update a shared table. If the server process terminates abnormally when both of the conditions listed below are applicable, abort code Phb3008 is issued and the unit may terminate abnormally:

A local buffer is being used.

A shared table is being updated without applying LOCK TABLE.

When both of these conditions are applicable and an updated page exists at the time the server process terminates abnormally, recovery processing may not be possible by means of rollback processing. If this happens, recovery processing is performed when the unit is restarted. Table 18-23 shows the HiRDB processing and the actions to take if an error occurs when a local buffer is being used to update a shared table (without the LOCK TABLE specification).

Table 18-23 HiRDB processing and actions to take if an error occurs when a local buffer is being used to update a shared table (without LOCK TABLE specification)

Cause of abnormal termination of server process | HiRDB processing if an updated page exists when the server process terminates abnormally | Action to be taken by the HiRDB administrator
PDSWAITTIME timeout | Abort code Phb3008 is issued, and the unit may terminate abnormally. | Restart the unit if it terminated abnormally.
PDCWAITTIME timeout
pdcancel command executed
Abort | Abort that occurs due to detection of a HiRDB conflict.
Other | Any unexpected error, such as SIGSEGV, SIGBUS, reception of an external signal, exi, etc.

Note

HiRDB does not terminate abnormally when a server process terminates abnormally due to a PDSWATCHTIME timeout, even if an updated page exists.

18.23 Actions to take when an error occurs in the system manager unit

If the system manager unit stops because of an error, users cannot connect to HiRDB servers. If the error in the system manager unit cannot be corrected immediately, you must change the specification of the PDHOST operand in the client environment definition. When the specification of the PDHOST operand is changed as described below, users can connect to the HiRDB servers.

When the PDFESHOST operand in the client environment definition is specified
Specify also in the PDHOST operand the name of the host (FQDN or IP address) specified in the PDFESHOST operand.

When the PDFESHOST operand in the client environment definition is not specified
Specify the PDFESHOST operand and also specify in the PDHOST operand the same host name (FQDN or IP address).

For details about the PDHOST and PDFESHOST operands, see the manual HiRDB Version 8 UAP Development Guide.

18.24 Actions to take when a mismatch occurs between the original and the mirror duplicate

When a database is mirrored using the mirroring facility of LVM or the device driver, the duplicate volume may not match the original volume if an error occurs in the OS or server machine while the database is being copied or if the device driver shuts down input/output during a system switchover. This is called a mismatch between the original and the mirror duplicate. When it occurs, you use one of the following methods to eliminate the mismatch:

Use a facility of LVM or the device driver to eliminate the mismatch between the original and the mirror duplicate

Use the full recovery processing performed by HiRDB during a restart to eliminate the mismatch between the original and the mirror duplicate

Method 1 is usually used. You use method 2 when it is not possible to use the LVM or device driver's facility to eliminate the mismatch, or when the process of matching the original and duplicate volumes takes too long and, as a result, a system requirement, such as system switchover time, cannot be satisfied.

Organization of this section

(1) Using a facility of LVM or the device driver to eliminate the mismatch between the original and the mirror duplicate

(2) Using the full recovery processing performed by HiRDB during a restart to eliminate the mismatch between the original and the mirror duplicate

(3) Configuration example when the rapid system switchover facility is used

(4) Configuration example when the rapid system switchover facility is used (for AIX 5L V5.2 or later)

(1) Using a facility of LVM or the device driver to eliminate the mismatch between the original and the mirror duplicate

Preparation

Either specify N in the pd_redo_allpage_put operand or omit this operand.

Action to take when a mismatch occurs between the original and the mirror duplicate

Before restarting HiRDB, use the facility of LVM or the device driver to make the original and duplicate volumes match. Then restart HiRDB.

(2) Using the full recovery processing performed by HiRDB during a restart to eliminate the mismatch between the original and the mirror duplicate

Preparation

Specify Y in the pd_redo_allpage_put operand. When Y is specified, the full recovery processing performed by HiRDB during a restart writes into the database all pages that were updated at or subsequent to a synchronization point. This processing eliminates the mismatch between the original and the mirror duplicate.

Action to take when a mismatch occurs between the original and the mirror duplicate

There is no need to use the LVM or device driver's facility to make the original and duplicate volumes match. Restart HiRDB immediately. The full recovery processing performed by HiRDB during the restart will make the original and duplicate volumes match.

Note

Use of this method increases the volume of data written into the database during full recovery processing. Consequently, it will take longer to restart HiRDB than when method 1 is used. To reduce the volume of data that must be written into the database, it is recommended that you shorten the synchronization point acquisition interval. Use the pd_log_sdinterval operand to specify the synchronization point acquisition interval.

(3) Configuration example when the rapid system switchover facility is used

Figure 18-8 shows an example of a system configuration when the rapid system switchover facility is used in an environment in which the LVM mirroring facility is used to mirror the database.

In this example, the full recovery processing performed by HiRDB during a restart is used to eliminate a mismatch between the original and the mirror duplicate.

Figure 18-8 Example of a system configuration in which the rapid system switchover facility is used

Explanation

In a system configuration in which the rapid system switchover facility is used, position a Lightning/Thunder device so that it can be accessed from both the primary and secondary systems.

Specify Y in the pd_redo_allpage_put operand.

(4) Configuration example when the rapid system switchover facility is used (for AIX 5L V5.2 or later)

Figure 18-9 shows an example of a system configuration when the rapid system switchover facility is used in an environment in which the mirroring facility of Hitachi Disk Array Driver for AIX is used to mirror the database.

In this example, the full recovery processing performed by HiRDB during a restart is used to eliminate a mismatch between the original and the mirror duplicate.

Figure 18-9 Example of a system configuration in which the rapid system switchover facility is used (for AIX 5L V5.2 or later)

Explanation

In a system configuration in which the rapid system switchover facility is used, position a Lightning/Thunder device so that it can be accessed from both the primary and secondary systems.

Specify Y in the pd_redo_allpage_put operand.

Also use the mirroring facility of Hitachi Disk Array Driver for AIX to mirror the disk in which the HiRDB file system area for RDAREAs is located, as shown in Figure 18-10. Mirror both the primary and secondary systems.

Figure 18-10 Example of a disk configuration in which the system switchover facility is used (for AIX 5L V5.2 or later)

Legend:

HBA: Any of various types of physical adapter cards. A Fibre Channel Adapter is a type of HBA.

CTL: Lightning/Thunder controller.

LU: A Lightning/Thunder device is logically partitioned into LUs, each of which appears as a single physical disk for a host. The number assigned to an LU is called the LUN.

hdiskM: Pseudo device created for mirroring.

hdiskR1, hdiskR2: Real devices corresponding to LUs in Lighnting/Thunder series devices.

If an error occurs in the OS or server machine while the database is being copied or if system switchover occurs, mismatch may occur between the original and the mirror duplicate. However, the full recovery processing performed by HiRDB during a restart will make the original and the mirror duplicate match in terms of RDAREAs. Thus, there is no need to make the original and duplicate volumes match before restarting HiRDB.

18.25 Recovery of HiRDB directory

Executor: Superuser and HiRDB administrator

This section explains the actions to be taken when it is necessary to recover the HiRDB directory because of a disk error, etc. (HiRDB directory recovery procedure).

Organization of this section

18.25.1 When installation directory is available

18.25.2 When installation directory is not available

18.25.3 When a backup is available for the disk on which the HiRDB directory is located

18.25.1 When installation directory is available

If a HiRDB installation directory is available, the HiRDB directory can be recovered from the installation directory. Note that the recovery procedure explained here assumes the following:

The files under $PDDIR/conf have been backed up.

If users have created files under $PDDIR, those files have been backed up.

The database and system files are safe.

In the case of a multi-HiRDB, all the HiRDB versions are identical.

Procedure

Reboot the server machine to clean up the remaining HiRDB processes.

Execute the pdsetup -d command to delete the HiRDB directory information registered in the OS. Respond with Y when prompted. Although the pdsetup -d command will terminate in an error, ignore this error.

Create a HiRDB directory.

Execute the pdsetup command. Executing this command copies the files under the installation directory to the HiRDB directory.

Recover the files under $PDDIR/conf from the backup.

If users created files under $PDDIR, recover those files.

Use the pdstart command to start HiRDB.

18.25.2 When installation directory is not available

If the HiRDB installation directory is not available because the HiRDB directory itself was used as the installation directory, HiRDB must be reinstalled. The recovery procedure explained here assumes the following:

The files under $PDDIR/conf have been backed up.

If users have created files under $PDDIR, those files have been backed up.

The database and system files are safe.

In the case of a multi-HiRDB, all the HiRDB versions are identical.

Procedure

Reboot the server machine to clean up the remaining HiRDB processes.

Execute the pdsetup -d command to delete the HiRDB directory information registered in the OS. Respond with Y when prompted. Although the pdsetup -d command will terminate in an error, ignore this error.

Reinstall HiRDB. For details on how to install HiRDB, see the manual HiRDB Version 8 Installation and Design Guide.

Execute the pdsetup command.

Recover the files under $PDDIR/conf from the backup.

If users created files under $PDDIR, recover those files.

Use the pdstart command to start HiRDB.

18.25.3 When a backup is available for the disk on which the HiRDB directory is located

If HiRDB cannot be reinstalled because neither the installation directory nor the HiRDB provided medium is available, recover the disk contents (including the HiRDB directory) from the disk backup.

For details on how to back up the disk in which the HiRDB directory is located, see the manual HiRDB Version 8 Installation and Design Guide.

Organization of this subsection

(1) When the HiRDB directory is not in the root volume

(2) When the HiRDB directory is in the root volume

(1) When the HiRDB directory is not in the root volume

Procedure

Reboot the server machine to clean up the remaining HiRDB processes.

Set the OS's Run Level (or Run Mode) to 1 (single user mode).

Recover the contents of the disk in which the HiRDB directory is located from the backup.

Return the OS's Run Level (or Run Mode) to the original mode.

If the pdsetup -d command had been executed before the disk was damaged, execute the pdsetup command.

Use the pdstart command to start HiRDB.

(2) When the HiRDB directory is in the root volume

Procedure

Reboot the server machine to clean up the remaining HiRDB processes.

Recover the root volume from the backup.

Execute the pdsetup command.

Use the pdstart command to start HiRDB.

18.26 Handling errors in the HiRDB file system areas

Executor: HiRDB administrator

If HiRDB processing is terminated by the OS's kill command or shutdown occurs while HiRDB file creation, deletion, or extension is underway, updating of the management information in the HiRDB file system areas (HiRDB file system configuration and file management information) is interrupted.

This may create files that cannot be managed and areas that cannot be referenced. Although this does not pose a problem for resuming HiRDB processing, the maximum number of files intended when the HiRDB file system area was created (-l operand value in the pdfmkfs command) or the specified maximum capacity (-n option value in the pdfmkfs command minus the size of the area management section) may no longer be available. In the case of HiRDB version 07-02 or earlier, the area management information may be corrupted.

This section describes how to respond when unmanageable files and unreferenceable areas area created and when area management information is corrupted.

Organization of this section

18.26.1 Unmanageable files and unreferenceable areas

18.26.2 Corruption of the area management information (applicable to HiRDB version 07-02 and earlier)

18.26.1 Unmanageable files and unreferenceable areas

Organization of this subsection

(1) About unmanageable files

(2) About unreferenceable areas

(3) How to check

(4) How to handle

(1) About unmanageable files

HiRDB manages the management information for the HiRDB file system areas in two statuses, Used and Unused, for the maximum number of files that can be created. If file creation or deletion processing is cancelled while management information for the corresponding area is being updated, the file to be processed is not referenced and may become unusable. If this occurs, the number of available files becomes fewer than the defined maximum number of files that can be created. Additionally, the area allocated to the affected file may become unreferenceable, resulting in a reduction of available capacity. If this type of cancellation occurs repeatedly, the available files and file capacity may be reduced considerably.

(2) About unreferenceable areas

Separately from the file management information, HiRDB manages the HiRDB file system areas in two statuses, used area that has been allocated to files, and unused area that has not been allocated. During file extension processing (automatic extension), HiRDB obtains the area required for file extension from the unused area and allocates it as used area. If file extension processing is cancelled while the area management information is being updated, the target area may no longer be referenced as used or unused area, and will not become available thereafter. The following illustrates the concept of unreferenceable area:

This figure shows that the file extension processing was cancelled before the unused area was allocated as used area. The shaded area becomes unreferenceable thereafter, resulting in a reduction of available capacity. If similar processing cancellations occur repeatedly, available capacity may be reduced by a considerable factor.

(3) How to check

The following describes how to check for unmanageable files and unreferenceable areas.

If you execute the pdfls command and the KFPI21586-W message is displayed, there are unmanageable files.

If the available capacity is less than the size specified when the HiRDB file system area was created (-n option value in the pdfmkfs command minus the size of the area management section), there are unreferenceable areas.

Execute the pdffsck -c command to check the processing results.

(4) How to handle

Execute the pdffsck command to repair applicable files and areas.

The pdffsck command with the -c option specified performs only checking and does not perform repair. If you know that there are unmanageable files or unreferenceable areas in the target HiRDB file system area, execute the command without specifying the -c option.

18.26.2 Corruption of the area management information (applicable to HiRDB version 07-02 and earlier)

Organization of this subsection

(1) About corruption of the area management information

(2) How to handle

(1) About corruption of the area management information

In HiRDB version 07-02 and earlier, if file creation, deletion, or extension processing is cancelled, some area may fall into a status that belongs neither to unmanageable files nor to unreferenceable areas. This is the area of corrupted management information and corrupted file caused by operations such as a duplicate allocation of area; this occurence has adverse effects on system operation. The following illustrates the concept of duplicate allocation.

Because the area management information is corrupted, any attempt to recover the corrupted target file results in corruption of other files. If you upgrade the system in this status, the corrupted area will be inherited.

Note

When area management information becomes corrupted, the pdfbkup, pdfrstr, pdcopy, and pdrstr commands cannot recover the information.

The pdffsck command can detect corruption of area management information, but cannot repair it. In such a case, the command displays the KFPI21585-E message and terminates abnormally.

(2) How to handle

Re-create all HiRDB file system areas. Then take the action described below for each HiRDB file system area purpose (-k option value in the pdfmkfs command).

(a) For DB and SDB

Recover the database from its backup. This backup must contain the RDAREAs that were stored in the HiRDB file system area before the area management information was corrupted.

(b) For SYS

Create the system log files, synchronization point dump files, and status files. Note that the system cannot be restarted because the system files required for restart cannot be provided. Perform a normal start.

If the security audit facility is used, create the audit trail file and then restart the HiRDB and security audit facility.

(c) For WORK

No action is needed because work tables are created automatically by HiRDB during SQL execution.

(d) For UTL

Because the backup file for the pdcopy command and the unload data files for the pdrorg command have been lost, re-execute the pdcopy or pdrorg command, if necessary.

19. Database Recovery Procedures

This chapter explains the procedures for recovering a database (RDAREAs) when an error has resulted in damage to the database.

This chapter contains the following sections:

Organization of this chapter

19.1 Overview of database recovery

19.2 Recovering a database to the point at which a backup was made

19.3 Recovering a database to the most recent synchronization point

19.4 Database recovery using the differential backup facility

19.5 Recovery procedure when the backup was not made with the pdcopy command

19.1 Overview of database recovery

Executor: HiRDB administrator

When an error occurs in a database, the HiRDB administrator uses the database recovery utility (pdrstr command) to recover the database. This section explains the basics of database recovery. The following items are explained in this section:

Database recovery point

Relationship to backup acquisition mode

Relationship to log acquisition mode

Notes on recovery of various types of RDAREAs

For users of 64-bit-mode HiRDB

Organization of this section

19.1.1 Database recovery point

19.1.2 Relationship to the backup acquisition mode

19.1.3 Relationship to the log acquisition mode

19.1.4 Notes on recovery of various types of RDAREAs

19.1.5 For users of 64-bit-mode HiRDB

19.1.1 Database recovery point

A database can be recovered to its status at any of the following points:

Backup acquisition point

Most recent synchronization point before the error occurred

Any synchronization point since a backup was made

Reference note

You can use the pdbkupls command to check the backup information collected by the database copy utility. For example, you can check the information listed below (for details about the information you can check, see the manual HiRDB Version 8 Command Reference):

Backup acquisition date and time

Names of RDAREAs that were backed up

Value specified for the backup acquisition mode (-M option)

Organization of this subsection

(1) Recovery to a backup acquisition point

(2) Recovery to most recent synchronization point before the error occurred

(3) Recovery to any synchronization point since a backup was made (recovery with a range specification)

(1) Recovery to a backup acquisition point

To recover a database to the point at which a backup was made, the backup file is the only input information that is required (for input to the database recovery utility). Figure 19-1 provides an overview of database recovery to a backup acquisition point.

Figure 19-1 Overview of database recovery to a backup acquisition point

Note

The following point must be kept in mind when a specific RDAREA is to be recovered to a backup acquisition point:

When only the RDAREA in which the error occurred is recovered, it will lose synchronization with other RDAREAs.

For example, if an error occurs during execution of a definition SQL statement, and then only the user RDAREA in which the error occurred is recovered to a backup acquisition point, the data dictionary RDAREA will be at the most recent synchronization point before the error occurred. Therefore, the RDAREAs described in Table 6-3 must also be recovered from backups made at the same time.

(2) Recovery to most recent synchronization point before the error occurred

(a) Transaction recovery

The point at which a transaction is completed is called a synchronization point. A synchronization point in which updates within a transaction become effective is called a commit, whereas if the updates become ineffective the synchronization point is called a rollback. Database recovery to the synchronization point of the most recently completed transaction at the time of an error is called recovery to the most recent synchronization point before an error occurred. A transaction that is being processed when an error occurs (a transaction that has not yet reached a synchronization point) is ineffective, which means that any update processing by the transaction cannot be recovered. Figure 19-2 shows recovery of a transaction.

Figure 19-2 Transaction recovery (recovery to the most recent synchronization point before an error occurred)

Explanation

Transactions A and B executed to completion and reached synchronization points; the database is recovered to these synchronization points.

Transactions C and D did not reach synchronization points, so their transaction processing is ineffective; these transactions cannot be recovered.

(b) Required input information

To recover a database to the most recent synchronization point before the error occurred, the following input information is required (for input to the database recovery utility):

Backup file

Unload log files*

* The unload log files that are required are those into which system log files subsequent to the backup acquisition point have been unloaded. If operation without unloading system log information is used, all system log files containing system log information subsequent to the backup acquisition point will be required.

Figure 19-3 provides an overview of database recovery to the most recent synchronization point before the error occurred.

Figure 19-3 Overview of database recovery to the most recent synchronization point before the error occurred

(c) Notes (important)

The only RDAREA to be recovered is the one in which the error occurred.

You must back up the RDAREA after it has been completely recovered. Otherwise, it will not be possible to recover the database from this synchronization point if an error occurs in this RDAREA subsequently.

An unload log file to be used as input to the database recovery utility must be a regular file. Therefore, if the unload log files are saved on a medium such as a CMT or DAT, register them on the disk before executing the database recovery utility.

In order to recover the master directory RDAREA using the system logs, HiRDB must be started with the pdstart -r command. If the system logs are used to recover an RDAREA other than the master directory RDAREA, HiRDB must be started with the pdstart command. Therefore, when recovering to the most recent synchronization point, the master directory RDAREA and other RDAREAs cannot be recovered simultaneously. For the procedure for recovering all RDAREAs to the most recent synchronization point, see 19.3.1 Example 1: Recovering all RDAREAs.

(3) Recovery to any synchronization point since a backup was made (recovery with a range specification)

Database recovery to the synchronization point of a completed transaction at a time specified by the HiRDB administrator is called recovery to any synchronization point since a backup was made. It is not possible to recover the updates of a transaction that is being processed at the time specified by the HiRDB administrator (a transaction that has not yet reach a synchronization point). This is called recovery with a range specification. Figure 19-4 shows recovery with a range specification.

Figure 19-4 Recovery with a range specification

Explanation

Specify the recovery synchronization point in the -T option of the database recovery utility.

To recover the database to synchronization point A, specify in the -T option a time after 9:10 but before 9:20 as the recovery end time.

To recover the database to synchronization point B, specify in the -T option a time after 9:20 but before 9:30 as the recovery end time.

To recover the database to synchronization point C (the synchronization point immediately before the error), the -T option need not be specified.

The input information (for input to the database recovery utility) that is required in order to recover the database to any synchronization point since a backup was made is the same as is needed for recovery to the most recent synchronization point before the error occurred.

19.1.2 Relationship to the backup acquisition mode

The point to which the database can be recovered depends on the backup acquisition mode that was specified during backup acquisition (specification of the -M option of the pdcopy command). Table 19-1 shows the points to which the database can be recovered depending on the backup acquisition mode.

Table 19-1 Points to which the database can be recovered depending on the backup acquisition mode

Backup acquisition mode
(-M option specification)
Backup acquisition point
Most recent synchronization point
Recovery with range specification

Referencing/updating-impossible mode (-M x option specification)
R
R
R

Referencing-permitted mode (-M r option specification)
R
R
R

Updatable mode (-M s option specification)*

R
R

R: Database can be recovered to this point.

: Database cannot be recovered to this point.

* If the backup was made with the updatable mode specified, database recovery will require what was the system log current file at the time the backup was made. The corresponding unload log file will be needed as input to the pdrstr command.

The name and generation number of the system log file that will be required for database recovery will be output in the pdcopy command's processing results output file.

19.1.3 Relationship to the log acquisition mode

Organization of this subsection

(1) When a UAP or utility is executed in the pre-update log acquisition mode

(2) When a UAP or utility is executed in the no-log mode

(1) When a UAP or utility is executed in the pre-update log acquisition mode

If an error occurs in the database while executing a UAP or utility in the pre-update log acquisition mode, the database can be recovered only to the backup acquisition point.

(2) When a UAP or utility is executed in the no-log mode

If an error occurs in the database while executing a UAP or utility in the no-log mode, the database can be recovered only to the backup acquisition point. All RDAREAs updated by this UAP are placed in error shutdown status. For the recovery procedure, see 7.3 Procedure for executing a UAP or utility in the no-log mode.

19.1.4 Notes on recovery of various types of RDAREAs

Organization of this subsection

(1) Recovering the master directory RDAREA

(2) Recovering data dictionary LOB RDAREAs

(3) Recovering user LOB RDAREAs

(4) Recovering list RDAREAs

(1) Recovering the master directory RDAREA

If the RDAREAs to be recovered include the master directory RDAREA, it is necessary to start HiRDB with the pdstart -r command and recover the master directory RDAREA with the pdrstr command.

In a recovery to the most recent synchronization point or with range specification, first recover the master directory RDAREA by itself, then recover the other RDAREAs.

(2) Recovering data dictionary LOB RDAREAs

The two data dictionary LOB RDAREAs are classified as follows:

For storage of the sources for stored routines and triggers

For storage of the objects of stored routines and triggers

The recovery timing differs for the two data dictionary LOB RDAREAs.

(a) Recovering the data dictionary LOB RDAREA for storing sources

The data dictionary LOB RDAREA for storing sources can be recovered to the backup acquisition point or to any synchronization point since the backup acquisition point. The backup and system log (unload log) are used as the input to the database recovery utility.

(b) Recovering the data dictionary LOB RDAREA for storing objects

The data dictionary LOB RDAREA for storing objects can be recovered only to the backup acquisition point because a database update log required for rollforward is not collected. Only the backup is used as the input to the database recovery utility.

In the following cases, follow the given procedure to recover the data dictionary LOB RDAREA for storing objects.

You are recovering the data dictionary LOB RDAREA for storing sources to a synchronization point after the backup acquisition point, but the data dictionary LOB RDAREA for storing sources cannot be synchronized with the data dictionary LOB RDAREA for storing objects

The backup was collected by the pdcopy command with the -J option specified, but the data dictionary LOB RDAREA for storing objects was intentionally not backed up

Procedure

To recover the data dictionary LOB RDAREA for storing objects:

Use the pdmod command to reinitialize the data dictionary LOB RDAREA for storing objects:
pdmod -a /pdmod/mod01

Use ALTER ROUTINE to re-create the SQL objects of all stored routines and triggers.
ALTER ROUTINE ALL

(3) Recovering user LOB RDAREAs

When user LOB RDAREAs are recovered, the user RDAREAs for storing the corresponding LOB column structure base tables should also be recovered at the same time.

(4) Recovering list RDAREAs

List RDAREAs do not become the targets of the pdrstr command. Because a list can be re-created if its base table is available, these RDAREAs are not subject to recovery.

If a list RDAREA is placed in error shutdown status, use the following procedure to release the shutdown status:

Procedure

To release the shutdown status for a list RDAREA:

Use the pdclose command to close the RDAREA that has been placed in error shutdown status.

Use the pdmod command to re-initialize the list RDAREA.

Use the pdrels -o command to release the list RDAREA from error shutdown status and open it.

Note

If a list RDAREA is re-initialized, all lists in that RDAREA become unusable. In such a case, you must re-create the lists with the ASSIGN LIST statement.

19.1.5 For users of 64-bit-mode HiRDB

There is no backup compatibility between the 32- and the 64-bit modes. Backups made in 32-bit-mode HiRDB cannot be used in 64-bit-mode HiRDB.

19.2 Recovering a database to the point at which a backup was made

Executor: HiRDB administrator

This section explains by way of examples how to recover a database to the point at which a backup was made. The following examples are provided:

Example 1: Recovering all RDAREAs

Example 2: Recovering specified RDAREAs

Example 3: When JP1/OmniBack II is used for recovery

Organization of this section

19.2.1 Example 1: Recovering all RDAREAs

19.2.2 Example 2: Recovering specified RDAREAs

19.2.3 Example 3: When JP1/OmniBack II is used for recovery

19.2.1 Example 1: Recovering all RDAREAs

This example recovers all RDAREAs, including system RDAREAs, to their status at the backup acquisition point; it is assumed that a backup copy of the entire system (backup of all RDAREAs) is available.

Organization of this subsection

(1) Enter the pdstop command to terminate HiRDB normally

(2) Enter the pdstart -r command to start HiRDB

(3) Use the pdrstr command to restore all RDAREAs

(4) Enter the pdstop command to terminate HiRDB normally

(5) Enter the pdstart command to start HiRDB normally

(6) Use the pdrels command to release and open RDAREAs that are in error shutdown status

(1) Enter the pdstop command to terminate HiRDB normally

pdstop

If HiRDB cannot be terminated normally, take either of the following actions when starting HiRDB in step (5):

Use the pdstart dbdestroy command to start HiRDB forcibly

Start HiRDB after initializing status files

(2) Enter the pdstart -r command to start HiRDB

pdstart -r

(3) Use the pdrstr command to restore all RDAREAs

pdrstr -m /rdarea/mast/mast01 -b /pdcopy/backup01 -a

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-b: Specifies the name of the backup file containing the backup data for all RDAREAs.

-a: Specifies that all RDAREAs are to be recovered.

(4) Enter the pdstop command to terminate HiRDB normally

pdstop

(5) Enter the pdstart command to start HiRDB normally

pdstart

(6) Use the pdrels command to release and open RDAREAs that are in error shutdown status

pdrels -r rdarea01,rdarea02, ... -o

This step is not necessary if you start HiRDB after initializing status files.

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.2.2 Example 2: Recovering specified RDAREAs

This example recovers specified user RDAREAs (rdarea01 and rdarea02) to their status at the backup acquisition point.

Organization of this subsection

(1) Use the pdclose command to close RDAREAs in error shutdown status

(2) Use the pdrstr command to recover the RDAREAs

(3) Use the pdrels command to release the recovered RDAREAs from error shutdown status and open them

(1) Use the pdclose command to close RDAREAs in error shutdown status

pdclose -r rdarea01,rdarea02

(2) Use the pdrstr command to recover the RDAREAs

pdrstr -m /rdarea/mast/mast01 -b /pdcopy/backup01 -r rdarea01,rdarea02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-b: Specifies the name of the backup file containing the backup data for rdarea01 and rdarea02.

-r: Specifies the names of the RDAREAs to be recovered (rdarea01 and rdarea02).

(3) Use the pdrels command to release the recovered RDAREAs from error shutdown status and open them

pdrels -r rdarea01,rdarea02 -o

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.2.3 Example 3: When JP1/OmniBack II is used for recovery

This example recovers all RDAREAs, including the system RDAREAs, to a backup acquisition point; it is assumed that a backup of the entire system (backup of all RDAREAs) is available. Note that JP1/OmniBack II was used to make the backup.

Organization of this subsection

(1) Use pdstop command to terminate HiRDB normally

(2) Use pdstart -r command to start HiRDB

(3) Check for objects to be used for recovery

(4) Use pdrstr command to recover all RDAREAs

(5) Use pdstop command to terminate HiRDB normally

(6) Use pdstart command to start HiRDB normally

(1) Use pdstop command to terminate HiRDB normally

pdstop

(2) Use pdstart -r command to start HiRDB

pdstart -r

(3) Check for objects to be used for recovery

Use the omnidb command of JP1/OmniBack II to check for the objects to be used for recovery. Specify the -stream option in the omnidb command.

(4) Use pdrstr command to recover all RDAREAs

pdrstr -m /rdarea/mast/mast01 -k o -b host01:backup01 -G DLT01 -a

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-k: Specifies the type of backup file. o is specified because a JP1/OmniBack II object is used.

-b: Specifies the name of the backup file that stores the backup of all RDAREAs. Specifies the name of a JP1/OmniBack II object as the backup file name. The specification format is host-name: object-name.

-G: Specifies the name of the barlist file.

-a: Specifies that all RDAREAs are to be backed up.

(5) Use pdstop command to terminate HiRDB normally

pdstop

(6) Use pdstart command to start HiRDB normally

pdstart

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.3 Recovering a database to the most recent synchronization point

Executor: HiRDB administrator

This section explains by way of examples how to recover a database to the most recent synchronization point. The following examples are provided:

Example 1: Recovering all RDAREAs

Example 2: Recovering specified RDAREAs

Example 3: Recovering specified RDAREAs (operation without unloading system log)

Example 4: When JP1/OmniBack II is used for recovery

Organization of this section

19.3.1 Example 1: Recovering all RDAREAs

19.3.2 Example 2: Recovering specified RDAREAs

19.3.3 Example 3: Recovering specified RDAREAs (operation without unloading the system log)

19.3.4 Example 4: When JP1/OmniBack II is used for recovery)

19.3.1 Example 1: Recovering all RDAREAs

This example recovers all RDAREAs, including system RDAREAs, to the most recent synchronization point before the error occurred; it is assumed that a backup of the entire system (backup of all RDAREAs) is available. The system log is unloaded.

Organization of this subsection

(1) Use the pdlogls command to check for the current system log file

(2) Use the pdlogswap command to swap system log files

(3) Use the pdlogunld command to unload what was the current file

(4) Use the pdstop command to terminate HiRDB normally

(5) Use the pdstart -r command to start HiRDB

(6) Use the pdrstr command to recover the master directory RDAREA to the most recent synchronization point

(7) Use the pdrstr command to recover the data directory RDAREA, etc., to the backup acquisition point

(8) Use the pdstop command to terminate HiRDB normally

(9) Use the pdstart command to start HiRDB

(10) Use the pdhold command to close RDAREAs by shutting them down

(11) Use the pdhold command to close the data dictionary RDAREA by shutting it down

(12) Use the pdrstr command to recover RDAREAs other than the master directory RDAREA to the most recent synchronization point

(13) Use the pdrels command to open the data dictionary RDAREA by releasing it from shutdown status

(14) Use the pdrels command to open other RDAREAs by releasing them from shutdown status

(15) Use the pdcopy command to back up all RDAREAs

(16) Use the pdstop command to terminate HiRDB normally

(17) Use the pdstart command to start HiRDB

(18) Recover the data dictionary LOB RDAREA for storing objects

(1) Use the pdlogls command to check for the current system log file

In the case of a HiRDB/Parallel Server, check for the system log file at the dictionary server and back-end server.

pdlogls -d sys

(2) Use the pdlogswap command to swap system log files

To unload the contents of the current file, swap the system log files. In the case of a HiRDB/Parallel Server, swap the system log files at the dictionary server and back-end server.

pdlogswap -d sys -w

(3) Use the pdlogunld command to unload what was the current file

Unload the contents of the current system log file checked in step (1). In the case of a HiRDB/Parallel Server, unload the contents of the current system log file at the dictionary server and back-end server.

pdlogunld -d sys -s bes1 -g log01 -o /unld/unldlog02

When the automatic log unloading facility is used

In this case, this step is not necessary. Use the pdlogatul command to confirm that the automatic log unloading facility is functioning. Also, use the pdlogls command to check if unloading has been completed.

(4) Use the pdstop command to terminate HiRDB normally

If HiRDB cannot be terminated normally, initialize the status files. First, delete the status files with the pdstsrm command, then re-create status files with the pdstsinit command.

pdstop

(5) Use the pdstart -r command to start HiRDB

pdstart -r

(6) Use the pdrstr command to recover the master directory RDAREA to the most recent synchronization point

pdrstr -m /rdarea/mast/mast01 -b /pdcopy/backup01
-l /unld/unldlog01,/unld/unldlog02 -w /tmp/sortwork -r rdmast

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-b: Specifies the name of the backup file that stores the backup of the master directory RDAREA (rdmast).

-l: Specifies the names of the unload log files.

-w: Specifies the name of the work directory for sorting.

-r: Specifies the name of the master directory RDAREA (rdmast).

(7) Use the pdrstr command to recover the data directory RDAREA, etc., to the backup acquisition point

The following RDAREAs are recovered to the backup acquisition point:

Data directory RDAREA

Data dictionary RDAREA

Data dictionary LOB RDAREA (for storing sources)

Registry RDAREA

Registry LOB RDAREA

If HiRDB was started with the pdstart -r command, do not execute multiple pdrstr commands at the same time.

pdrstr -m /rdarea/mast/mast01 -b /pdcopy/backup01
-r rddir,rddic,diclob,regrd,reglob

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-b: Specifies the name of the backup file that stores the backup.

-r: Specifies the names of the RDAREAs that are to be recovered.

(8) Use the pdstop command to terminate HiRDB normally

pdstop

(9) Use the pdstart command to start HiRDB

pdstart

(10) Use the pdhold command to close RDAREAs by shutting them down

Shut down and close all RDAREAs except the master directory RDAREA and data dictionary RDAREA.

pdhold -r rddir,diclob,regrd,reglob,rdarea01,rdarea02,... -c

(11) Use the pdhold command to close the data dictionary RDAREA by shutting it down

The data dictionary RDAREA must be shut down and closed last.

pdhold -r rddic -c

(12) Use the pdrstr command to recover RDAREAs other than the master directory RDAREA to the most recent synchronization point

pdrstr -m /rdarea/mast/mast01 -b /pdcopy/backup01
-l /unld/unldlog01,/unld/unldlog02 -w /tmp/sortwork
-r rddir,rddic,diclob,regrd,reglob,rdarea01,rdarea02,...

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-b: Specifies the name of the backup file.

-l: Specifies the names of the unload log files.

-w: Specifies the name of the work directory for sorting.

-r: Specifies the names of the RDAREAs to be recovered.

(13) Use the pdrels command to open the data dictionary RDAREA by releasing it from shutdown status

The data dictionary RDAREA must be released from shutdown status and opened first.

pdrels -r rddic -o

(14) Use the pdrels command to open other RDAREAs by releasing them from shutdown status

Open all RDAREAs except the master directory RDAREA and data dictionary RDAREA by releasing them from shutdown status.

pdrels -r rddir,diclob,regrd,reglob,rdarea01,rdarea02,... -o

(15) Use the pdcopy command to back up all RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01
-z /pdcopy/logpoint01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the updatable mode as the backup acquisition mode.

-a: Specifies that all RDAREAs are to be backed up.

-b: Specifies a name for the backup file.

-z: Specifies the name of the log point information file. This option is specified when the automatic log unloading facility is used.

-p: Specifies the output destination for the pdcopy command's processing results listing.

(16) Use the pdstop command to terminate HiRDB normally

pdstop

(17) Use the pdstart command to start HiRDB

pdstart

(18) Recover the data dictionary LOB RDAREA for storing objects

The procedure for recovering the data dictionary LOB RDAREA for storing objects is described below.

Procedure

To recover the data dictionary LOB RDAREA:

Use the pdmod command to re-initialize the data dictionary LOB RDAREA for storing objects:
pdmod -a /pdmod/mod01

Use ALTER ROUTINE to re-create the SQL objects of all stored routines and triggers.
ALTER ROUTINE ALL

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.3.2 Example 2: Recovering specified RDAREAs

This example recovers specified user RDAREAs (rdarea01 and rdarea02) to their status at the most recent synchronization point preceding the error. The system log file handling method is system log unloading operation.

Organization of this subsection

(1) Use the pdclose command to close RDAREAs in error shutdown status

(2) Use the pdlogls command to check for the current system log file

(3) Use the pdlogswap command to swap system log files

(4) Use the pdlogunld command to unload the current file

(5) Use the pdrstr command to recover the RDAREAs to the most recent synchronization point

(6) Use the pdcopy command to back up the recovered RDAREAs

(7) Use the pdrels command to release the recovered RDAREAs from error shutdown status and open them

(1) Use the pdclose command to close RDAREAs in error shutdown status

pdclose -r rdarea01,rdarea02

(2) Use the pdlogls command to check for the current system log file

In the case of a HiRDB/Parallel Server, this check is for the system log file in the back-end server that contains rdarea01 and rdarea02.

pdlogls -d sys

(3) Use the pdlogswap command to swap system log files

The system log files are swapped so that the current file can be unloaded. In the case of a HiRDB/Parallel Server, swap the system log files at the back-end servers in which rdarea01 and rdarea02 are located.

pdlogswap -d sys -w

(4) Use the pdlogunld command to unload the current file

Unload the current system log file checked in step (2). In the case of a HiRDB/Parallel Server, unload the current system log files at the back-end servers in which rdarea01 and rdarea02 are located.

pdlogunld -d sys -g log01 -o /unld/unldlog02

When the automatic log unloading facility is used

In this case, this step is not necessary. Use the pdlogatul command to confirm that the automatic log unloading facility is functioning. Also, use the pdlogls command to check if unloading has been completed.

(5) Use the pdrstr command to recover the RDAREAs to the most recent synchronization point

pdrstr -m /rdarea/mast/mast01 -b /pdcopy/backup01
-l /unld/unldlog01,/unld/unldlog02 -w /tmp/sortwork -r rdarea01,rdarea02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-b: Specifies the name of the backup file containing the backup data for rdarea01 and rdarea02.

-l: Specifies the names of the unload log files.

-w: Specifies the name of the work directory for sorting.

-r: Specifies the names of the RDAREAs to be recovered (rdarea01 and rdarea02).

When range-specified recovery is to be executed, the recovery end time is specified in the -T option. If the -T option is omitted, the RDAREAs are recovered to the most recent synchronization point preceding the error.

If there is an unload log file that cannot be read due to an error in a system log file or the unload log file, the most recent unload log file among all the unload log files that were read successfully must be analyzed to narrow the range of data that cannot be recovered. The applicable transactions can then be reexecuted, if necessary.

(6) Use the pdcopy command to back up the recovered RDAREAs

pdcopy -m /rdarea/mast/mast01 -M x -r rdarea01,rdarea02
-b /pdcopy/backup02 -z /pdcopy/logpoint01 -p /pdcopy/list01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing/updating-impossible mode as the backup acquisition mode.

-r: Specifies the RDAREAs that are to be backed up (rdarea01 and rdarea02, the RDAREAs in which the error occurred).

-b: Specifies the name of the backup file.

-z: Specifies the name of the log point information file. This option is specified when the automatic log unloading facility is used.

-p: Specifies the output destination for the pdcopy command's processing results listing.

(7) Use the pdrels command to release the recovered RDAREAs from error shutdown status and open them

pdrels -r rdarea01,rdarea02 -o

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.3.3 Example 3: Recovering specified RDAREAs (operation without unloading the system log)

This example recovers specified user RDAREAs (rdarea01 and rdarea02) to their status at the most recent synchronization point preceding the error. The system log file handling method is operation without unloading the system log.

Organization of this subsection

(1) Use the pdclose command to close RDAREAs in error shutdown status

(2) Use the pdlogswap command to swap system log files

(3) Use the pdrstr command to recover the RDAREAs to the most recent synchronization point

(4) Use the pdcopy command to back up the recovered RDAREAs

(5) Use the pdrels command to release the recovered RDAREAs from error shutdown status and open them

(1) Use the pdclose command to close RDAREAs in error shutdown status

pdclose -r rdarea01,rdarea02

(2) Use the pdlogswap command to swap system log files

The current file cannot be used as is as the input to the database recovery utility, so the system log files are swapped. In the case of a HiRDB/Parallel Server, swap the system log files at the back-end servers in which rdarea01 and rdarea02 are located.

pdlogswap -d sys

(3) Use the pdrstr command to recover the RDAREAs to the most recent synchronization point

pdrstr -m /rdarea/mast/mast01 -b /pdcopy/backup01 -L
-w /tmp/sortwork -r rdarea01,rdarea02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-b: Specifies the name of the backup file containing the backup data for rdarea01 and rdarea02.

-L: Specifies that the system log file is to be used as the input information.

-w: Specifies the name of the work directory for sorting.

-r: Specifies the names of the RDAREAs to be recovered (rdarea01 and rdarea02).

When range-specified recovery is to be executed, the recovery end time is specified in the -T option. If the -T option is omitted, the RDAREAs will be recovered to the most recent synchronization point preceding the error.

(4) Use the pdcopy command to back up the recovered RDAREAs

pdcopy -m /rdarea/mast/mast01 -M x -r rdarea01,rdarea02 -b /pdcopy/backup02
-z /pdcopy/logpoint01

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing/updating-impossible mode as the backup acquisition mode.

-r: Specifies the erroneous RDAREAs (rdarea01 and rdarea02) that are to be backed up.

-b: Specifies the name of the backup file.

-z: Specifies the name of the log point information file.

(5) Use the pdrels command to release the recovered RDAREAs from error shutdown status and open them

pdrels -r rdarea01,rdarea02 -o

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.3.4 Example 4: When JP1/OmniBack II is used for recovery)

This example recovers user RDAREAs (rdarea01 and rdarea02) to the most recent synchronization point before the error occurred; it is assumed that the system log is unloaded.

Note that JP1/OmniBack II is used to make backups.

Organization of this subsection

(1) Use pdclose command to close RDAREAs in error shutdown status

(2) Use pdlogls command to check for current system log file

(3) Use pdlogswap command to swap system log files

(4) Use pdlogunld command to unload what was the current file

(5) Check for objects to be used for recovery

(6) Use pdrstr command to recover RDAREAs to most recent synchronization point

(7) Use pdcopy command to back up recovered RDAREAs

(8) Use pdrels command to release error shutdown status of recovered RDAREAs and open them

(1) Use pdclose command to close RDAREAs in error shutdown status

pdclose -r rdarea01,rdarea02

(2) Use pdlogls command to check for current system log file

In the case of a HiRDB/Parallel Server, check for the system log files at the back-end servers in which rdarea01 and rdarea02 are located.

pdlogls -d sys

(3) Use pdlogswap command to swap system log files

The system log files are swapped so that the current file can be unloaded. In the case of a HiRDB/Parallel Server, swap the system log files at the back-end servers in which rdarea01 and rdarea02 are located.

pdlogswap -d sys

(4) Use pdlogunld command to unload what was the current file

Unload the current file identified in step (2).

pdlogunld -d sys -g log01 -o /unld/unldlog02

(5) Check for objects to be used for recovery

Use the omnidb command of JP1/OmniBack II to check for the objects to be used for recovery. Specify the -stream option in the omnidb command.

(6) Use pdrstr command to recover RDAREAs to most recent synchronization point

pdrstr -m /rdarea/mast/mast01 -k o -b host01:backup01 -G DLT01
-l /unld/unldlog01,/unld/unldlog02 -w /tmp/sortwork -r rdarea01,rdarea02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-k: Specifies the type of backup file. o is specified because a JP1/OmniBack II object is used.

-b: Specifies the name of the backup file that stores the backup of rdarea01 and rdarea02. Specifies the name of a JP1/OmniBack II object as the backup file name. The specification format is host-name: object-name.

-G: Specifies the name of the barlist file.

-l: Specifies the names of the unload log files.

-w: Specifies the name of the work directory for sorting.

-r: Specifies the names of the RDAREAs (rdarea01 and rdarea02) that are to be recovered.

For recovery with a range specification, specify a recovery termination time in the -T option. If this option is not specified, the RDAREAs will be recovered to the most recent synchronization point before the error occurred.

If some unload log files cannot be entered because of an error in the system log file or unload log file, analyze the most recent unload log file that could be entered in order to narrow the range that cannot be recovered. Then, if necessary, re-execute the transaction.

(7) Use pdcopy command to back up recovered RDAREAs

pdcopy -m /rdarea/mast/mast01 -M x -r rdarea01,rdarea02 -k o
-b host01:backup002 -G DLT02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing/updating-impossible mode as the backup acquisition mode.

-r: Specifies the RDAREAs to be backed up (rdarea01 and rdarea02, the RDAREAs in which the error occurred).

-k: Specifies the type of backup file. o is specified because a JP1/OmniBack II object is used.

-b: Specifies the name of a JP1/OmniBack II object as the backup file name. The specification format is host-name: object-name.

-G: Specifies the name of the barlist file.

(8) Use pdrels command to release error shutdown status of recovered RDAREAs and open them

pdrels -r rdarea01,rdarea02 -o

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.4 Database recovery using the differential backup facility

Executor: HiRDB administrator

This section explains the use of the differential backup facility to recover a database to either of the following points:

Most recent differential backup acquisition point

Most recent synchronization point

Organization of this section

19.4.1 Example 1: Recover to the most recent differential backup acquisition point

19.4.2 Example 2: Recover to the most recent synchronization point

19.4.3 Recovery when a differential backup management file is not available

19.4.1 Example 1: Recover to the most recent differential backup acquisition point

This example recovers user RDAREAs (rdarea01 and rdarea02) to a differential backup acquisition point.

Organization of this subsection

(1) Use the pdclose command to close RDAREAs in error shutdown status

(2) Use the pdrstr command to recover RDAREAs

(3) Use the pdrels command to open recovered RDAREAs by releasing their error shutdown status

(1) Use the pdclose command to close RDAREAs in error shutdown status

pdclose -r rdarea01,rdarea02

(2) Use the pdrstr command to recover RDAREAs

pdrstr -m /rdarea/mast/mast01 -g backupg1 -K /pdcopy/admfile -r rdarea01,rdarea02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-g: Specifies the name of a differential backup group.

-K: Specifies the name of the HiRDB file system area for storing the differential backup management file.

-r: Specifies the names of the RDAREAs (rdarea01 and rdarea02) that are to be recovered.

(3) Use the pdrels command to open recovered RDAREAs by releasing their error shutdown status

pdrels -r rdarea01,rdarea02 -o

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.4.2 Example 2: Recover to the most recent synchronization point

This example recovers user RDAREAs (rdarea01 and rdarea02) to the most recent synchronization point before an error occurred; it is assumed that the system log is being unloaded.

Organization of this subsection

(1) Use the pdclose command to close RDAREAs in error shutdown status

(2) Use the pdlogls command to check for the current system log file

(3) Use the pdlogswap command to swap system log files

(4) Use the pdlogunld command to unload what was the current system log file

(5) Use the pdrstr command to recover RDAREAs to the most recent synchronization

(6) Use the pdcopy command to back up recovered RDAREAs

(7) Use the pdrels command to open recovered RDAREAs by releasing their error shutdown status

(1) Use the pdclose command to close RDAREAs in error shutdown status

pdclose -r rdarea01,rdarea02

(2) Use the pdlogls command to check for the current system log file

In the case of a HiRDB/Parallel Server, check the system log files at the back-end servers at which rdarea01 and rdarea02 are located.

pdlogls -d sys

(3) Use the pdlogswap command to swap system log files

In order to unload the contents of the current file, the system log files are swapped. In the case of a HiRDB/Parallel Server, swap the system log files at the back-end servers at which rdarea01 and rdarea02 are located.

pdlogswap -d sys

(4) Use the pdlogunld command to unload what was the current system log file

Unload the contents of the current file identified in step (2). In the case of a HiRDB/Parallel Server, unload the contents of the current system log files at the back-end servers at which rdarea01 and rdarea02 are located.

pdlogunld -d sys -g log01 -o /unld/unldlog02

(5) Use the pdrstr command to recover RDAREAs to the most recent synchronization

pdrstr -m /rdarea/mast/mast01 -g backupg1 -K /pdcopy/admfile
-l /unld/unldlog01 -w /tmp/sortwork -r rdarea01,rdarea02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-g: Specifies the name of a differential backup group.

-K: Specifies the name of a HiRDB file system area for storing the differential backup management file.

-l: Specifies the name of the unload log file.

-w: Specifies the name of the work directory for sorting.

-r: Specifies the names of the RDAREAs (rdarea01 and rdarea02) that are to be recovered.

(6) Use the pdcopy command to back up recovered RDAREAs

pdcopy -m /rdarea/mast/mast01 -M r -r rdarea01,rdarea02,...
-g backupg1(S) -b /pdcopy/backup01 -d a -K /pdcopy/admfile -L 5
-o /pdcopy/rfile

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-M: Specifies the referencing-permitted mode as the backup acquisition mode.

-r: Specifies the RDAREAs that are to be backed up.

The RDAREA group specified here becomes the differential backup group. The RDAREAs to be backed up cannot be changed in the middle.

-g: Specifies the name of the differential backup group.

For a full backup, specify (S) with the differential backup group name. The differential backup group name specified here must be specified when a differential backup is made subsequently.

-b: Specifies a name for the backup file (full backup file name).

-d: Specifies a backup type:

a: Full backup

b: Accumulation-differential backup since the last full backup

c: Accumulation-differential backup since either the last accumulation-differential backup or the last full backup

d: Differential backup

For details on an accumulation-differential backup, see 6.5.4 Creating an accumulation-differential backup.

-K: Specifies the name of the HiRDB file system area for storing the differential backup management file.

-L: Specifies the size (in megabytes) of the differential backup management file.

-o: Specifies the name of the history file for differential backups.

(7) Use the pdrels command to open recovered RDAREAs by releasing their error shutdown status

pdrels -r rdarea01,rdarea02 -o

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.4.3 Recovery when a differential backup management file is not available

If no differential backup management file is available, the database must be recovered by executing the pdrstr command multiple times (once for each backup that was made).

When the recovery method in Example 2 above is executed, the operation at step 19.4.2(5) will be different. This section explains the operation from this step on. It is assumed that differential backups are collected at the following times:

A full backup is collected on Sunday.

A differential backup is collected on Monday and Tuesday.

The database is recovered on Wednesday.

Organization of this subsection

(1) Use the pdrstr command to recover RDAREAs using the full backup as the input information

(2) Use the pdrstr command to recover RDAREAs using a differential backup as the input information

(3) Use the pdrstr command to recover RDAREAs using the differential backup as the input information

(4) Use the pdrstr command to recover RDAREAs using the unload log file as the input information

(1) Use the pdrstr command to recover RDAREAs using the full backup as the input information

pdrstr -m /rdarea/mast/mast01 -g backupg1 -K /pdcopy/admfile
-b /pdcopy/backup01 -r rdarea01,rdarea02

Explanation

-b: Specifies the name of the full backup file.

(2) Use the pdrstr command to recover RDAREAs using a differential backup as the input information

Use the pdrstr command to recover RDAREAs using the differential backup made on Monday as the input information.

pdrstr -m /rdarea/mast/mast01 -g backupg1 -K /pdcopy/admfile
-b /pdcopy/backup02 -r rdarea01,rdarea02

Explanation

-b: Specifies the name of the differential backup file.

(3) Use the pdrstr command to recover RDAREAs using the differential backup as the input information

Use the pdrstr command to recover RDAREAs using the differential backup made on Tuesday as the input information.

pdrstr -m /rdarea/mast/mast01 -g backupg1 -K /pdcopy/admfile
-b /pdcopy/backup03 -r rdarea01,rdarea02

Explanation

-b: Specifies the name of the differential backup file.

(4) Use the pdrstr command to recover RDAREAs using the unload log file as the input information

Use the pdrstr command to recover the RDAREAs beyond the differential backup collected on Tuesday using the unload log file as the input information. If an error occurs at this point, repeat the sequence of operations, beginning with step (1). After RDAREAs have been recovered using the unload log file as the input information, it is important to make a full backup.

pdrstr -m /rdarea/mast/mast01 -l /unld/unldlog01 -w /tmp/sortwork
-r rdarea01,rdarea02

Explanation

-l: Specifies the name of the unload log file.

19.5 Recovery procedure when the backup was not made with the pdcopy command

Executor: HiRDB administrator

This section explains database recovery when a backup was made without using the pdcopy command (i.e., when another product's facility was used). The database recovery procedure is outlined below:

Procedure

To recover the database:

Use the other product's restore facility to recover the database to the backup acquisition point.

Use the pdrstr command to recover the database to the most recent synchronization point.

To recover the database to the backup acquisition point only, perform step 1 only.

If the master directory RDAREA is included in the RDAREAs to be recovered when recovery is to the most recent synchronization point or recovery is with a range specification, first recover the master directory RDAREA only, then recover the remaining RDAREAs.

Organization of this section

19.5.1 Example 1: Recovering all RDAREAs to the point at which a backup was made

19.5.2 Example 2: Recovering specified RDAREAs to the point at which a backup was made

19.5.3 Example 3: Recovering all RDAREAs to the most recent synchronization point

19.5.4 Example 4: Recovering specified RDAREAs

19.5.5 Example 5: Recovering the master directory RDAREA only

19.5.1 Example 1: Recovering all RDAREAs to the point at which a backup was made

This section explains how to recover all RDAREAs, including the system RDAREAs, to the point at which a backup was made; it is assumed that a backup of the entire system (backup of all RDAREAs) is available.

Organization of this subsection

(1) Use the pdstop command to terminate HiRDB normally

(2) Use another product's facility to recover all RDAREAs

(3) Use the pdstart command to start HiRDB normally

(1) Use the pdstop command to terminate HiRDB normally

pdstop

If HiRDB cannot be terminated normally, take either of the following actions when starting HiRDB in step (3):

Use the pdstart dbdestroy command to start HiRDB forcibly.

Start HiRDB after initializing status files.

(2) Use another product's facility to recover all RDAREAs

Use another product's facility to recover all RDAREAs.

(3) Use the pdstart command to start HiRDB normally

pdstart

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.5.2 Example 2: Recovering specified RDAREAs to the point at which a backup was made

This example recovers user RDAREAs (rdarea01 and rdarea02) to the point at which a backup was made.

Organization of this subsection

(1) Use the pdclose command to close RDAREAs in error shutdown status

(2) Use another product's facility to recover all RDAREAs

(3) Use the pdrels command to open recovered RDAREAs by releasing their error shutdown status

(1) Use the pdclose command to close RDAREAs in error shutdown status

pdclose -r rdarea01,rdarea02

(2) Use another product's facility to recover all RDAREAs

Use another product's restore facility to recover the HiRDB file system area that comprises the RDAREAs (rdarea01, rdarea02).

(3) Use the pdrels command to open recovered RDAREAs by releasing their error shutdown status

pdrels -r rdarea01,rdarea02 -o

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.5.3 Example 3: Recovering all RDAREAs to the most recent synchronization point

This example recovers all RDAREAs, including the system RDAREAs, to the most recent synchronization point before an error occurred; it is assumed that a backup of the entire system (backup of all RDAREAs) is available. The system log is being unloaded.

Organization of this subsection

(1) Use the pdlogls command to check for the current system log file

(2) Use the pdlogswap command to swap system log files

(3) Use the pdlogunld command to unload what was the current system log file

(4) Use the pdstop command to terminate HiRDB normally

(5) Recover the master directory RDAREA to the backup acquisition point

(6) Use the pdstart -r command to start HiRDB

(7) Use the pdrstr command to recover the master directory RDAREA to the most recent synchronization point

(8) Recover the data directory RDAREA, etc., to the backup acquisition point

(9) Use the pdstop command to terminate HiRDB normally

(10) Use the pdstart command to start HiRDB

(11) Use the pdhold command to close RDAREAs by shutting them down

(12) Use the pdhold command to close the data dictionary RDAREA by shutting it down

(13) Use the pdrstr command to recover RDAREAs other than the master directory RDAREA to the most recent synchronization point

(14) Use the pdrels command to open the data dictionary RDAREA by releasing it from shutdown status

(15) Use the pdrels command to open other RDAREAs by releasing them from shutdown status

(16) Use the pdstop command to terminate HiRDB normally

(17) Back up all RDAREAs

(18) Use the pdstart command to start HiRDB

(19) Recover the data dictionary LOB RDAREA for storing objects

(1) Use the pdlogls command to check for the current system log file

In the case of a HiRDB/Parallel Server, check for the current system log files at the dictionary and back-end servers.

pdlogls -d sys

(2) Use the pdlogswap command to swap system log files

To unload the current system log file, swap system log files. In the case of a HiRDB/Parallel Server, swap system log files at the dictionary and back-end servers.

pdlogswap -d sys

(3) Use the pdlogunld command to unload what was the current system log file

Unload the current system log file checked in step (1).

In the case of a HiRDB/Parallel Server, unload the current system log files at the dictionary and back-end servers.

pdlogunld -d sys -g log01 -o /unld/unldlog02

(4) Use the pdstop command to terminate HiRDB normally

If HiRDB will not terminate normally, initialize the status files, use the pdstsrm command to delete the status files, then use the pdstsinit command to re-create the status files.

pdstop

(5) Recover the master directory RDAREA to the backup acquisition point

Use another product's facility to recover the master directory RDAREA to a backup acquisition point.

(6) Use the pdstart -r command to start HiRDB

pdstart -r

(7) Use the pdrstr command to recover the master directory RDAREA to the most recent synchronization point

pdrstr -m /rdarea/mast/mast01 -l /unld/unldlog01,/unld/unldlog02
-w /tmp/sortwork -r rdmast

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-l: Specifies the names of the unload log files.

-w: Specifies the name of the work directory for sorting.

-r: Specifies the name of the master directory RDAREA (rdmast).

(8) Recover the data directory RDAREA, etc., to the backup acquisition point

Use another product's facility to recover the following RDAREAs to a backup acquisition point:

Data directory RDAREA

Data dictionary RDAREA

Data dictionary LOB RDAREA (for storing sources)

Registry RDAREA

Registry LOB RDAREA

(9) Use the pdstop command to terminate HiRDB normally

pdstop

(10) Use the pdstart command to start HiRDB

pdstart

(11) Use the pdhold command to close RDAREAs by shutting them down

Shut down and close all RDAREAs except the master directory RDAREA and data dictionary RDAREA.

pdhold -r rddir,diclob,regrd,reglob,rdarea01,rdarea02,... -c

(12) Use the pdhold command to close the data dictionary RDAREA by shutting it down

The data dictionary RDAREA must be shut down and closed last.

pdhold -r rddic -c

(13) Use the pdrstr command to recover RDAREAs other than the master directory RDAREA to the most recent synchronization point

pdrstr -m /rdarea/mast/mast01 -l /unld/unldlog01,/unld/unldlog02
-w /tmp/sortwork -r rddir,rddic,diclob,regrd,reglob,rdarea01,rdarea02,...

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-l: Specifies the names of the unload log files.

-w: Specifies the name of the work directory for sorting.

-r: Specifies the names of the RDAREAs to be recovered.

(14) Use the pdrels command to open the data dictionary RDAREA by releasing it from shutdown status

The data dictionary RDAREA must be released from shutdown status and opened first.

pdrels -r rddic -o

(15) Use the pdrels command to open other RDAREAs by releasing them from shutdown status

Open all RDAREAs except the master directory and data dictionary RDAREAs by releasing their shutdown status.

pdrels -r rddir,diclob,regrd,reglob,rdarea01,rdarea02,... -o

(16) Use the pdstop command to terminate HiRDB normally

pdstop

(17) Back up all RDAREAs

Use another product's backup facility to back up all RDAREAs.

(18) Use the pdstart command to start HiRDB

pdstart

(19) Recover the data dictionary LOB RDAREA for storing objects

The procedure for recovering the data dictionary LOB RDAREA for storing objects is described below.

Procedure

To recover the data dictionary LOB RDAREA:

Use the pdmod command to re-initialize the data dictionary LOB RDAREA for storing objects:
pdmod -a /pdmod/mod01

Use ALTER ROUTINE to re-create the SQL objects of all stored routines and triggers.
ALTER ROUTINE ALL

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.5.4 Example 4: Recovering specified RDAREAs

This example recovers user RDAREAs (rdarea01 and rdarea02) to the most recent synchronization point before an error occurred. The system log is being unloaded.

Organization of this subsection

(1) Use the pdclose command to close RDAREAs in error shutdown status

(2) Use the pdlogls command to check for the current system log file

(3) Use the pdlogswap command to swap system log files

(4) Use the pdlogunld command to unload what was the current system log file

(5) Recover RDAREAs to the backup point

(6) Use pdrstr command to recover RDAREAs to most recent synchronization point

(7) Back up recovered RDAREAs

(8) Use the pdrels command to open recovered RDAREAs by releasing them from error shutdown status

(1) Use the pdclose command to close RDAREAs in error shutdown status

pdclose -r rdarea01,rdarea02

(2) Use the pdlogls command to check for the current system log file

In the case of a HiRDB/Parallel Server, check the system log files at the dictionary and back-end servers.

pdlogls -d sys

(3) Use the pdlogswap command to swap system log files

To unload the current file, swap system log files. In the case of a HiRDB/Parallel Server, swap system log files at the back-end servers where rdarea01 and rdarea02 are located.

pdlogswap -d sys

(4) Use the pdlogunld command to unload what was the current system log file

Unload the current system log file identified in step (2).

pdlogunld -d sys -g log01 -o /unld/unldlog02

(5) Recover RDAREAs to the backup point

Use another product's restore facility to recover rdarea01 and rdarea02 to a backup acquisition point.

(6) Use pdrstr command to recover RDAREAs to most recent synchronization point

pdrstr -m /rdarea/mast/mast01 -l /unld/unldlog01,/unld/unldlog02
-w /tmp/sortwork -r rdarea01,rdarea02

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-l: Specifies the names of the unload log files.

-w: Specifies the name of the work directory for sorting.

-r: Specifies the names of the RDAREAs (rdarea01 and rdarea02) to be recovered.

(7) Back up recovered RDAREAs

Use another product's backup facility to back up rdarea01 and rdarea02.

(8) Use the pdrels command to open recovered RDAREAs by releasing them from error shutdown status

pdrels -r rdarea01,rdarea02 -o

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

19.5.5 Example 5: Recovering the master directory RDAREA only

This example recovers only the master directory RDAREA to the most recent synchronization point before an error occurred. The system log is being unloaded.

Organization of this subsection

(1) Use the pdlogls command to check for the current system log file

(2) Use the pdlogunld command to unload what was the current system log file

(3) Recover the master directory RDAREA to the backup point

(4) Use the pdstart -r command to start HiRDB

(5) Use the pdrstr command to recover the RDAREA to the most recent synchronization point

(6) Use the pdstop command to terminate HiRDB

(7) Back up the master directory RDAREA

(8) Use the pdstart -r command to start HiRDB

(1) Use the pdlogls command to check for the current system log file

In the case of a HiRDB/Parallel Server, check the system log files at all servers.

pdlogls -d sys

(2) Use the pdlogunld command to unload what was the current system log file

Unload the current system log file checked in step (1).

In the case of a HiRDB/Parallel Server, unload the current system log files at all servers.

pdlogunld -d sys -g log01 -o /unld/unldlog02

(3) Recover the master directory RDAREA to the backup point

Use another product's restore facility to recover the master directory RDAREA to a backup acquisition point.

(4) Use the pdstart -r command to start HiRDB

pdstart -r

(5) Use the pdrstr command to recover the RDAREA to the most recent synchronization point

pdrstr -m /rdarea/mast/mast01 -l /unld/unldlog01,/unld/unldlog02
-w /tmp/sortwork -r MAST

Explanation

-m: Specifies the name of the first HiRDB file in the master directory RDAREA.

-l: Specifies the names of the unload log files.

-w: Specifies the name of the work directory for sorting.

-r: Specifies the name of the master directory RDAREA (MAST).

(6) Use the pdstop command to terminate HiRDB

pdstop

(7) Back up the master directory RDAREA

Use another product's backup facility to back up the HiRDB file system area that comprises the master directory RDAREA.

(8) Use the pdstart -r command to start HiRDB

pdstart

It is recommended that after the command has executed you check whether or not the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 8 Command Reference.

20. Obtaining Tuning Information

This chapter explains the procedures for obtaining the tuning information that is required in order to tune the system.

This chapter contains the following sections:

Organization of this chapter

20.1 Collecting tuning information from the statistics log

20.2 Collecting tuning information from the system log

20.3 Using the database condition analysis utility to collect tuning information

20.1 Collecting tuning information from the statistics log

This section explains the procedures for collecting tuning information from the statistics log. The following topics are discussed:

Tuning information that can be collected from the statistics log

Preparing for collecting tuning information

Collecting tuning information

Shell script for creating unload statistics log files at a specified server machine

When linked to an OLTP system

Organization of this section

20.1.1 Tuning information that can be collected from the statistics log

20.1.2 Preparing for collecting tuning information

20.1.3 Collecting tuning information

20.1.4 Shell script for creating unload statistics log files at a specified server machine

20.1.5 When linked to an OLTP system

20.1.1 Tuning information that can be collected from the statistics log

Table 20-1 shows the types of tuning information that can be collected from the statistics log.

Table 20-1 Tuning information that can be collected from the statistics log

Statistics information type | Explanation
System activity statistical information | sys | Outputs activity information related to HiRDB processes, RPC, system logs, etc.
UAP statistical information | uap | Edits by edit time UAP-related information, such as the number of retrieved rows and the number of SQL executions, and outputs this information by UAP or transaction.
SQL statistical information | sql | Outputs by UAP or service information related to SQL issuances, such as the number of retrieved rows, the number of times work tables were created, and the number of back-end servers that issued intra-SQL partitioning commands.
Global buffer pool statistical information¹ | buf | Edits by edit time information related to global buffer accesses, such as the buffer hits rate and the actual I/Os counts, and outputs this information by server or global buffer.
Statistical information on HiRDB files for database manipulation | fil | Edits by edit time information related to HiRDB file accesses, such as the synchronization I/Os counts and I/O error counts, and outputs this information by server, HiRDB file, and RDAREA.
Deferred write processing statistical information | dfw | Edits by edit time information related to deferred write processing, such as the number of deferred write processes, operation factors, and the I/O parallel level, and outputs this information by server.
Index statistical information | idx | Edits by edit time index-related information, such as index key lock information and index split information, based on the statistics logs and system logs, and outputs this information by server and index.
SQL static optimization information | sop | Outputs (to a DAT file only) SQL static optimization information.
SQL dynamic optimization information | dop | Outputs (to a DAT file only) SQL dynamic optimization information.
SQL object execution information | pcd | Outputs (to a DAT file only) SQL object execution optimization information.
SQL statement statistical information² | sqh | Outputs (to a DAT file only) information related to data manipulation SQLs, definition SQLs, LOCK statements, and issued SQLs.
Statistics on SQL object transmission³ | obj | Outputs (to a DAT file only) SQL object transmission information.
Statistical information on the operation of foreign servers³ | fsv | Outputs foreign server operation information. Statistical information is output when transactions are completed. Information is output to a DAT file only.
Statistical information on the usage status of foreign servers 3 | hba | Outputs information on foreign server usage status. Statistical information is output when SQL is executed with respect to a foreign server. Information is output to a DAT file only.

¹ This statistical information is collected at synchronization points. Because it is a compilation of information between synchronization points, no statistical information is collected unless there are at least two synchronization points. To ensure that the statistical information is collected, execute the pdlogsync command immediately before executing the pdstjsync or pdstend command to cause a synchronization point to be set.

² Statistical information related to the history of SQL statements is output when statistical information related to SQL (sql specification) is output.

³ This statistical information is limited to a HiRDB/Parallel Server. It is not output for a HiRDB/Single Server.

20.1.2 Preparing for collecting tuning information

Executor: HiRDB administrator

To collect tuning information, it is necessary to collect the statistical information (statistics log) output by HiRDB. The statistics log is output to a statistics log file. The HiRDB administrator must determine an appropriate size for this file.

Organization of this subsection

(1) Creating the statistics log files

(2) Handling the statistics log file

(1) Creating the statistics log files

There are two statistics log files, named pdstj1 and pdstj2, under the $PDDIR/spool directory. HiRDB creates these statistics log files automatically. The HiRDB administrator must specify the size of the statistics log file in the pd_stj_file_size operand. The following points should be noted about determining this file size:

The total size of the statistics log information to be collected should be specified as the file size. If multiple sets of statistical information are to be collected concurrently, the value specified in the pd_stj_file_size operand must be greater than the sum of the sizes of those statistics logs. For the formula for determining the size of a statistics log, see the manual HiRDB Version 8 System Definition.

Whether or not the various types of statistics log information are collected depends on the type of server, as shown in Table 20-2. The HiRDB administrator must take this into account in determining the file size.

Table 20-2 Servers subject to collection of statistics log information

Type of statistics log | HiRDB/Single Server | HiRDB/Parallel Server
SDS | MGR | FES | DS | BES
System activity statistical information | sys | Y | Y | Y | Y | Y
UAP statistical information | uap | Y |  | Y |  |
SQL statistical information | sql | Y |  | Y |  |
Global buffer pool statistical information | buf | Y |  |  | Y | Y
Statistical information on HiRDB files for database manipulation | fil | Y |  |  | Y | Y
Deferred write processing statistical information | dfw | Y |  |  | Y | Y
Index statistical information* | idx | Y |  |  | Y | Y
SQL static optimization information | sop | Y |  | Y |  |
SQL dynamic optimization information | dop | Y |  | Y |  |
SQL object statistical information | pcd | Y |  | Y | Y | Y
SQL statement statistical information | sqh | Y |  | Y |  |
Statistics on SQL object transfer | obj |  |  |  | Y | Y
Statistical information on the operation of foreign servers | fsv |  |  |  |  | Y
Statistical information on the usage status of foreign servers | hba |  |  |  |  | Y

Y: Statistics log information that is collected

: Statistics log information that is not collected

Note

The CONNECT/DISCONNECT statistical information collected by the pdhibegin operand is output to the system log file, not to the statistics log file; for details, see 20.2 Collecting tuning information from the system log.

In the case of a utility special unit, only system activity statistical information can be collected.

* Information on index page splits is not collected as part of the statistics log. For information on how to collect this information, see 20.2 Collecting tuning information from the system log.

(2) Handling the statistics log file

When a statistics log file becomes full during output of statistics log information, HiRDB switches outputs of the information to the other statistics log file. This is called statistics log file swapping. When statistics log file swapping occurs, new information is written over any existing statistics log information in the swapped-in file. For this reason, as soon as a statistics log file is swapped out, the HiRDB administrator should unload it and create an unload statistics log file. Figure 20-1 shows the procedure for swapping the statistics log files.

Figure 20-1 Swapping of statistics log files

20.1.3 Collecting tuning information

Executor: HiRDB administrator

This section explains the procedure for collecting tuning information (from collection of statistics log information to execution of the statistics analysis utility that uses the collected statistics log as its input information). Figure 20-2 shows the procedure for collecting tuning information (collecting tuning information from the statistics log).

Figure 20-2 Procedure for collecting tuning information (collecting tuning information from the statistics log)

Organization of this subsection

(1) Starting statistics log collection

(2) Outputting statistics logs from the statistics log buffer to a statistics log file

(3) Creating an unload statistics log file

(4) Executing the statistics analysis utility

(1) Starting statistics log collection

Use the pdstbegin command to start statistics log collection. To start collecting statistics logs at the time of HiRDB startup, specify the pdstbegin operand in the system common definition. When the pdstbegin operand is specified, there is no need to execute the pdstbegin command.

Note

The information listed below is not collected unless at least two synchronization points occur during statistics log collection. To ensure that this information is collected, use the pdlogsync command to set a synchronization point immediately after entering the pdstbegin command, and then use the pdlogsync command to set a synchronization point immediately before entering the pdstjsync or pdstend command.

Global buffer pool statistical information

Statistical information on HiRDB files for data manipulation

Deferred write processing statistical information

Index statistical information

Reference note

To end statistics log collection, execute the pdstend command.

(2) Outputting statistics logs from the statistics log buffer to a statistics log file

Use the pdstjsync command to output the statistics logs stored in the statistics log buffer to a statistics log file.

Reference note

The statistics logs stored in the statistics log buffer are output to a statistics log file at the following trigger points:

When the statistics log buffer becomes full

When the pdstjsync command is executed

When the pdstend command is executed

When HiRDB is terminated (normal or planned termination)

(3) Creating an unload statistics log file

One of the following methods must be used to unload a statistics log file and create an unload statistics log file; normally, the OS's cp command is used:

OS's cp command

HiRDB-provided shell script (pdstjacm)

Hint

When statistics log information is being output to multiple server machines (as in the case of a HiRDB/Parallel Server), pdstjacm should be used to create the unload statistics log files. For example, when system activity information is collected by a HiRDB/Parallel Server, the statistics log information is output to multiple server machines. In such a case, pdstjacm must be used to create the unload statistics log files at a specific server machine. For details on pdstjacm, see 20.1.4 Shell script for creating unload statistics log files at a specified server machine.

Note

When a statistics log file is unloaded while HiRDB is active, care must be taken not to delete the statistics log file with the OS's mv or rm command. If it is deleted, statistical information will no longer be output. If the statistics log file is deleted inadvertently, either restart HiRDB or execute the pdstjswap command.

(4) Executing the statistics analysis utility

Using the unload statistics log files created in step (3) as the input information, execute the statistics analysis utility. The HiRDB administrator can then use the execution results to tune HiRDB or UAPs.

Reference note

Because statistics information is collected between the time when the pdstbegin command is entered and the time when the pdstend (or pdstjsync) command is entered, the UAP statistics information may not match the SQL statistics information depending on the command entry timings.

20.1.4 Shell script for creating unload statistics log files at a specified server machine

Executor: HiRDB administrator

In the case of a HiRDB/Parallel Server, a shell script (pdstjacm) can be used to collect all the unload statistics log files acquired at the individual server machines under a specified server machine's directory. This section describes the shell script for creating unload statistics log files at a specific server machine.

Organization of this subsection

(1) Function of pdstjacm

(2) Contents of pdstjacm

(1) Function of pdstjacm

pdstjacm is a HiRDB-provided shell script. Executing pdstjacm collects the statistics log information output from multiple server machines under the directory of a specified server machine. Unload statistics log files appropriate to the user's environment can be created by modifying the contents of pdstjacm. When the contents of pdstjacm are not modified, all the unload statistics log files are collected under $PDDIR/spool/stjfiles at the host used to execute pdstjacm. Figure 20-3 provides an overview of pdstjacm.

Figure 20-3 Overview of pdstjacm

Explanation

The statistics log information from node1, node2, and node3 is collected under the $PDDIR/spool/stjfiles directory.

(2) Contents of pdstjacm

pdstjacm is stored as pdstjacm under $PDDIR/bin. The shell script should be copied before it is modified. In addition to pdstjacm, the OS's rcp command (remote copy) and NFS (network file system) can also be used. The following are the contents of pdstjacm:

#!/bin/sh
# ALL RIGHTS RESERVED,COPYRIGHT (C) 1994,1995,HITACHI,LTD.
# LICENSED MATERIAL OF HITACHI,LTD.
# Name          : pdstjacm
# Function      : Collects statistics log files at host at which command is entered.
# Command Line  : pdstjacm [sysdef filename]
# Command option: sysdef filename - If name of system common definition at local
#                                   host is omitted, $PDCONFPATH/pdsys is assumed.
# Note          : (1) Change the OUTDIR as required.
#                 (2) Statistic log file is collected for each host under a separate
#                     subdirectory of the $OUTDIR directory;
#                     the name of a subdirectory under $OUTDIR is the same as the
#                     corresponding host name.
#                 (3) rcp command is used to transfer statistics log files between
#                     hosts.
#                 (4) A definition of pdstart operand and pdunit operand in definition
#                     files must not be written over several lines. If pdstart operand
#                     or pdunit operand is written over several lines in definition
#                     files, this command("pdstjacm") doesn't work correctly.
#
#                    (Example)
#                      pdstart -t SDS \ |    |
#                       -s sds01 \      | -> | pdstart -t SDS -s sds01 -x host01
#                       -x host01       |    |
#
#                      pdunit -u unt1 \ |    |
#                       -x host01 \     | -> | pdunit -u unt1 -x host01 -d "/HiRDB_S"
#                       -d "/HiRDB_S"   |    |
#
#                 (5) When system switching occurs, this command("pdstjacm") doesn't
#                     work correctly. Change the hostname(s) of the executing system
#                     to the one(s) of the standby system, in order to collect the
#                     statistics log files of the standby system.
#                 (6) Pdstjacm shell is getten HiRDB operational directory name from
#                     system common definition file ($PDCONFPATH/pdsys or specified
#                     first argument). If pdunit operand in definition files is written
#                     over several lines in definition files, pdstjacm shell may be
#                     executed using $PDDIR in .cshrc on several local hosts.
#                 (7) If pdstart operands and/or pdunit operands are specified wrong
#                     in definition files, this command("pdstjacm") doesn't work
#                     correctly.
#
#******************************************************************************
##  Definition for canceling processing when Signal is received
trap "echo processing is canceled.; exit 1" 1 2 15

##  Definition of literals
OUTDIR=$PDDIR/spool/stjfiles      ......................#1
##  OUTDIR is directory under which statistics log files are collected.
##  Modify as required.

##  Checking of number of arguments
if [ $2 ] ; then
        echo  "Usage: $0 [input_file]"
        echo  "$0 processing is canceled."
        exit 1
fi

##  Checking of input definition file
if [ $# -eq 1 ]
then DEFFILE=$1
else DEFFILE=$PDCONFPATH/pdsys
fi
if [ ! -r $DEFFILE ] ; then
        echo "$DEFFILE is not found or cannot be read."
        echo "$0 processing is canceled."
        exit 1
fi

##  Set host name in ${proc_host}.
proc_host=`cat $DEFFILE | sed -n '/^[   ]*pdunit.*[   ]-x/{s/.*[   ]-x//;p;}' \
                        | awk '{print $1}' - | sort | uniq`
set ${proc_host:=no_host_name}

if [ $1 = no_host_name ] ; then
proc_host=`cat $DEFFILE | sed -n '/^[   ]*pdstart.*[   ]-x/{s/.*[   ]-x//;p;}' \
                        | awk '{print $1}' - | sort | uniq`
set ${proc_host:=no_host_name}

##  Validity checking of host name
if [ $1 = no_host_name ] ; then
        echo "No host name to be processed."
        echo "pdstjacm processing terminated."
        exit 1
fi
fi

##  Checking of transfer destination directory
if [ ! -d $OUTDIR ] ; then
        mkdir $OUTDIR
fi

##  Checking of transfer destination directory
if [ ! -d $OUTDIR ] ; then
        mkdir $OUTDIR
fi

##  Copy local host statistics log file   ..........#3
set ${proc_host}          ..........................1
while [ $# -ne 0 ]
do
    if [ ! -d $OUTDIR/$1 ] ; then
             mkdir $OUTDIR/$1
    fi
    proc_dir=`cat $DEFFILE | /bin/grep '[   ]-x[   ]*'$1'[   ]' \
              | sed -n '/^[   ]*pdunit/{s/.*[   ]-d//;p;}' | awk '{print $1}' -`
    if [ -z "$proc_dir" ] ; then
      proc_dir=`cat $DEFFILE | /bin/grep '[   ]-x[   ]*'$1'$' \
             | sed -n '/^[   ]*pdunit/{s/.*[   ]-d//;p;}' | awk '{print $1}' -`
    fi
##  Validity checking of pddir name on pdunit operand
        case ${proc_dir} in
                 /*)
                        rcp $1:$proc_dir/spool/pdstj1 $OUTDIR/$1
                        rcp $1:$proc_dir/spool/pdstj2 $OUTDIR/$1
                ;;
                *)
                        rcp $1:'$'PDDIR/spool/pdstj1 $OUTDIR/$1   ..........#2
                        rcp $1:'$'PDDIR/spool/pdstj2 $OUTDIR/$1
                ;;
        esac
##  rcp command is used to transfer statistics log files between hosts.
##  Environment must be set up so that remote shell can be executed between hosts.
        shift
done      .................2

##  End of processing
echo "pdstjacm : Processing completed."
exit 0

#1: To create unload log files on a specified server machine, the $PDDIR/spool/stjfiles section is modified.

#2: If statistical log files cannot be collected on a specified server machine, compile the '$'PDDIR/spool/pdstj1 and '$'PDDIR/spool/pdstj2 parts.

#3: If control is passed to the standby HiRDB by the system switchover facility and this shell is executed as is, statistics log files will not be collected correctly. In such a case, the shell script from 1 through 2 must be modified as follows:

if[ ! -d $OUTDIR/HOST1 ] ; then
 mkdir $OUTDIR/HOST1
fi          # Copying statistics log file on HOST1
rcp HOST1:HOST1_pddir/spool/pdstj1 $OUTDIR/HOST1
rcp HOST1:HOST1_pddir/spool/pdstj2 $OUTDIR/HOST1

if [ ! -d $OUTDIR/HOST2 ] ; then
 mkdir $OUTDIR/HOST2
fi          # Copying statistics log file on HOST2
rcp HOST2:HOST2_pddir/spool/pdstj1 $OUTDIR/HOST2
rcp HOST2:HOST2_pddir/spool/pdstj2 $OUTDIR/HOST2

Repeat above script as many times as there are units whose statistics log is output. In this case, modify the following literals appropriately:

HOST1, HOST2: Statistics-log-output-host-name

HOST1_pddir, HOST2_pddir: Statistics-log-output-HiRDB-directory

20.1.5 When linked to an OLTP system

Organization of this subsection

(1) When linked to OpenTP1

(2) When linked to TPBroker, TUXEDO or WebLogic Server

(1) When linked to OpenTP1

When HiRDB is linked to OpenTP1, the statistical information collection timing and the statistics analysis utility's editing unit change if the operation mode employed is as discussed in (a) below.

Linkage of HiRDB to OpenTP1 refers to accesses from an application operating under TP1/Server Base or TP1/Message Control (version 03-06 or later).

(a) Operation mode in which a UAP in a client/server environment accesses HiRDB as part of the server UAP's service execution

This includes an application that accesses HiRDB from one of the OpenTP1 services, such as SPP (Service Provider Program) or MHP (Message Handling Program):

In this operation mode, a UAP in OpenTP1 can form multiple services within the same UAP, and each service can access a HiRDB that is appropriate for its purposes. In such a case, the name of the service requested to SPP or MHP (the first service within the transaction accompanying HiRDB access) is added to the statistical information as well as the UAP name of SPP or MHP (value of PDCLTAPNAME specified in the OpenTP1 user server definition for SPP or MHP). This service name is specified when SUP or TP1/Message Control issues a request using RPC; it is the name assigned to the service constituting SPP or MHP.

This service name can be used to determine the service that accessed HiRDB. It can also be used to establish correspondence with OpenTP1's transaction statistical information. Table 20-3 shows the correspondence between statistical information concerning a UAP accessing HiRDB and OpenTP1's statistical information.

Table 20-3 Statistical information for a UAP accessing HiRDB and OpenTP1's statistical information

Type of statistical information
Statistics log output timing
Statistics analysis utility's editing unit
DAT output file analysis

UAP statistical information
Other than OpenTP1's UAP
Each connection
Each UAP name

UAP executions count, average UAP execution time, executions count for each SQL statement, etc.

Total and average values for each item per UAP execution

Information can be analyzed using the transaction or UAP name as the key.

OpenTP1's UAP
With no service name
Normal interface

XA interface
Each transaction

With service name
Normal interface
Each connection

During log output, name of the first service in the connection is added.

Each service name in UAP

Executions count for each SQL statement, etc.

Information can be analyzed using the transaction, UAP, or service name as the key.

XA interface
Each transaction

Name of the first service in the log output period is added.

SQL statistical information
Other than OpenTP1's UAP
Each SQL
Each UAP name

Total and average lengths of SQL objects

Total and average number of object transmissions from front-end server to back-end server

SQL executions count, processing time, number of rows processed

Information can be analyzed using the UAP name as the key.

OpenTP1's UAP
With no service name

With service name
Each SQL

During log output, name of the first service in the transaction is added.

Each service name in UAP

Summary of the above information for each service

Information can be analyzed using the UAP or service name as the key.

SQL optimizing information
Other than OpenTP1's UAP
Each SQL

Information can be analyzed using the UAP name as the key.

OpenTP1's UAP
With no service name

With service name
Each SQL

During log output, name of the first service in the transaction is added

Information can be analyzed using the UAP or service name as the key.

SQL object execution information
Other than OpenTP1's UAP
With no service name
Each SQL

Information can be analyzed using the UAP name as the key.

OpenTP1's UAP
With service name
Each SQL

During log output, name of the first service in the transaction is added.

Information can be analyzed using the UAP or service name as the key.

Legend:

: Not applicable

(b) Operation mode in which HiRDB is accessed directly from the main routine

This includes an application that accesses HiRDB directly from OpenTP1's SUP (Service Utilization Program):

In this operation mode, the statistical information is the same as for a normal application that is not connected to OpenTP1. The UAP name used in the statistical information is the value of PDCLTAPNAME specified in the OpenTP1 user server definition for SUP.

(2) When linked to TPBroker, TUXEDO or WebLogic Server

When HiRDB is linked to TPBroker, TUXEDO or WebLogic Server, the statistical information collection timing and the statistics analysis utility's editing unit change. Table 20-4 shows the statistical information collection timing when HiRDB is linked to TPBroker, TUXEDO or WebLogic Server.

Table 20-4 Statistical information collection timing when HiRDB is linked to TPBroker, TUXEDO or WebLogic Server

Type of statistical information
Statistic log output timing
Statistics analysis utility's editing unit
DAT output file analysis

UAP statistical information
UAP other than TPBroker, TUXEDO or WebLogic Server
Each connection
Each UAP name

UAP executions count, average UAP execution time, executions count for each SQL, etc.

Total and average values for each item per UAP execution

Information can be analyzed using the transaction or UAP name as the key.

TPBroker, TUXEDO or WebLogic Server UAP
Normal interface

XA interface
Each transaction

SQL statistical information
UAP other than TPBroker, TUXEDO or WebLogic Server
Each SQL
Each UAP name

Total and average lengths of SQL objects

Total and average number of object transmissions from front-end server to back-end servers

SQL executions count, processing time, number of rows processed

Information can be analyzed using the UAP name as the key.

TPBroker, TUXEDO or WebLogic Server UAP
Normal interface

XA interface

SQL optimization information
UAP other than TPBroker, TUXEDO or WebLogic Server
Each SQL
Each UAP name

Average executions count and execution time

Information can be analyzed using the UAP name as the key.

TPBroker, TUXEDO or WebLogic Server UAP
Normal interface

XA interface

SQL object execution information
UAP other than TPBroker, TUXEDO or WebLogic Server
Each SQL
Each UAP name

Average executions count and execution time

Information can be analyzed using the UAP name as the key.

TPBroker, TUXEDO or WebLogic Server UAP
Normal interface

XA interface

20.2 Collecting tuning information from the system log

Executor: HiRDB administrator

Organization of this section

(1) Tuning information that can be collected from the system log

(2) Tuning information collection procedure

(1) Tuning information that can be collected from the system log

Table 20-5 shows the tuning information that can be collected from the system log.

Table 20-5 Tuning information that can be collected from the system log

Type of statistical information | Explanation
Index statistical information | idx | Outputs information related to index page splits from within the index statistical information.
CONNECT/DISCONNECT statistical information* | cnc | Outputs (to a DAT file only) statistical information on CONNECTs and DISCONNECTs.

* In the case of a HiRDB/Parallel Server, this statistical information is output to the front-end server's system log file.

(2) Tuning information collection procedure

Figure 20-4 shows the procedure for collecting tuning information (collecting tuning information from the system log).

Figure 20-4 Procedure for collecting tuning information (collecting tuning information from the system log)

Explanation

HiRDB collects system log information in system log files.

Use the pdlogunld command to unload system log files and create unload log files.
When unload log files are output to multiple server machines in a HiRDB/Parallel Server, the OS's rcp command (remote copy) or NFS (network file system) can be used to collect the unload log files.
System log information can also be read directly by the statistics analysis utility. For details on the statistics analysis utility, see the manual HiRDB Version 8 Command Reference.

Execute the statistics analysis utility using the created unload log files as the input information. You can then use the execution results to tune HiRDB or UAPs.

20.3 Using the database condition analysis utility to collect tuning information

This section explains the procedures for using the database condition analysis utility to collect tuning information.

Organization of this section

(1) Preparing for collecting the tuning information

(2) Collecting the tuning information

(1) Preparing for collecting the tuning information

Executor: HiRDB administrator

To use the database condition analysis utility to collect tuning information, the status of RDAREAs must be as shown in Table 20-6. For this reason, the status of RDAREAs should be checked with the pddbls command before the database condition analysis utility is executed.

A user with the DBA privilege only cannot check the status of RDAREAs. In such a case, the HiRDB administrator must be asked whether or not the RDAREAs are in the appropriate status for execution of the database condition analysis utility.

Table 20-6 RDAREA status for collection of tuning information by the database condition analysis utility

Type of RDAREA
Status of RDAREA

Data dictionary RDAREA

Data dictionary LOB RDAREA

Registry RDAREA

Registry LOB RDAREA

List RDAREA

Non-shutdown open status

Reference-enabled shutdown open status

User RDAREA

User LOB RDAREA

RDAREA open attribute: INITIAL

Non-shutdown open status

Reference-enabled shutdown open status

RDAREA open attribute: DEFER or SCHEDULE

Non-shutdown open status

Non-shutdown close status

Reference-enabled shutdown open status

Reference-enabled shutdown close status

(2) Collecting the tuning information

Executor: User with the DBA privilege

This section explains the procedure for collection of tuning information (from entry of operation command to execution of the database condition analysis utility). Figure 20-5 shows the procedure for collecting tuning information (collecting tuning information using the database condition analysis utility).

Figure 20-5 Procedure for collecting tuning information (collecting tuning information using the database condition analysis utility)

* If the RDAREA open attribute is DEFER or SCHEDULE, and the RDAREA is not in reference-possible hold status or shutdown, then it is not necessary to place it in open status.

Explanation

Use the pddbls command to check the status of the RDAREA.

In the case of an error shutdown, use the pdrels command after error recovery to release the shutdown status, then reexecute.

In the case of a command shutdown, use the pdrels command to release the RDAREA from shutdown status.

If in closed status, use the pdopen command to place in open status.

Execute the database condition analysis utility. Perform tuning on the basis of the results of this execution.

If the RDAREA was placed in open status in step 4, use the pdclose command to return to closed status. If command shutdown was used in step 3, use the pdrels command to release the command shutdown.

21. Tuning

This chapter explains how to tune a database.

Databases should be tuned in order to maintain optimum performance. However, the available memory and disk space may not be adequate to achieve the desired level of performance. Therefore, a balance between performance on the one hand and memory and disk space requirements on the other hand must be considered when the system is tuned.

This chapter contains the following sections:

Organization of this chapter

21.1 Tuning global buffer pools

21.2 Tuning deferred write processing

21.3 Tuning the synchronization point processing time when deferred write processing is used

21.4 Tuning the synchronization point dump interval

21.5 Tuning buffer lengths

21.6 Tuning the number of processes

21.7 Tuning indexes

21.8 Tuning the database

21.9 Tuning SQLs

21.10 Tuning the system's internal processing

21.1 Tuning global buffer pools

The specifications for global buffer pools can have a significant effect on a disk's data I/O performance. For this reason, global buffer pools should be specified so that high hits rates are achieved. This section discusses the items to be evaluated in order to improve the buffer hits rates for the global buffer pools.

If the items described here are evaluated in conjunction with HiRDB file information related to database manipulations, performance can be improved most efficiently.

Information to be collected

Global buffer pool statistical information is collected. The following resources are provided for collecting this information:

pdbufls command

Statistics analysis utility

The pditvtrc command can be used to execute this command and utility periodically on a regular basis.

Organization of this section

21.1.1 Using the pdbufls command to collect statistical information

21.1.2 Using the statistics analysis utility to collect statistical information

21.1.1 Using the pdbufls command to collect statistical information

Organization of this subsection

(1) Check the global buffer pool's hits rate (HIT)

(2) Check the update requests hits rate (HIT)

(3) Check the reference requests hits rate (HIT)

(4) Check the update buffer flushes count (UPFLS)

(5) Check the reference buffer flushes count (RFFLS)

(6) Check the real READs count (READ) and real WRITEs count (WRITE)

(7) Check the buffer lock-release waits count (WAITL)

(8) Check the prefetch input pages count (PRRED), prefetch hit pages count (PRHIT), and prefetch hits rate (HIT)

(9) Check the prefetch buffer shortages count (PRINS)

(1) Check the global buffer pool's hits rate (HIT)

Purpose

This information is collected to determine whether or not the number of buffer sectors in a global buffer pool is appropriate. This is the most important item for tuning a global buffer pool.

Evaluating the analysis results

Check to see if the global buffer pool hits rate (HIT) is 80% or higher.

Actions to be taken

Global buffer pool hits rate is below 80%

Increase the value of the pdbuffer operand's -n option (number of global buffers).

Global buffer pool hits rate is 80% or better

There is no problem; however, to improve the hits rate even further, increase the number of global buffer sectors.

RDAREAs storing tables with no buffering effects should be combined into a single RDAREA; otherwise, more memory may be used than is necessary.

(2) Check the update requests hits rate (HIT)

Purpose

This information is collected in order to evaluate the validity of the number of global buffer sectors and the deferred write processing that is executed internally by HiRDB.

When a data insertion, updating, or deletion request is issued for a database, the corresponding data is updated in a global buffer pool. Therefore, the ratio of the number of times requested data was found in a global buffer pool to the total number of update GET requests has an effect on throughput.

Evaluating the analysis results

Evaluate the update requests hits rate with respect to the total number of issued INSERT, UPDATE, and DELETE statements, as reported in the UAP information output by the statistics analysis utility:

Check that the update requests hits rate is not too low

Check that the reference buffer hits rate is not too low even if the update requests hits rate is high.

The update requests hits rate is obtained with the following formula:

Update requests hits rate (%) = (update GET requests hits count update GETs count) 100

Actions to be taken

When the update requests hits rate is low

Increase the value of the pdbuffer operand's -n option (number of global buffers).

Re-evaluate the value specified for the pdbuffer operand. If multiple RDAREAs are allocated to one global buffer, separate the RDAREAs for tables to be updated from the RDAREAs for tables to be referenced, and allocate a global buffer to each type of RDAREA. If one RDAREA is allocated to one global buffer, store indexes and tables in separate RDAREAs and allocate a global buffer dedicated to indexes. Or, row-partition the table.

When performing deferred write processing (when the pd_dbsync_point operand is specified as sync or it is omitted), decrease the value of the pdbuffer operand's -w option (percentage of pages output in deferred write processing).

When the update requests hits rate is high

There is no problem; however, to improve the hits rate even further, increase the number of global buffer sectors.

RDAREAs storing tables with no buffering effects should be combined into a single RDAREA; otherwise, more memory may be used than is necessary.

(3) Check the reference requests hits rate (HIT)

Purpose

This information is collected in order to evaluate the validity of the reference requests hits rate. If needed data is not found in the global buffer, the system retrieves database data from the RDAREA and sets it in the buffer. If the number of times requested data is found in the global buffer pool is small, the number of I/O operations increases, affecting adversely the transaction processing performance.

Evaluating the analysis results

Determine whether the reference requests hits rate is close to 80%. The reference requests hits rate is obtained with the following formula:

Reference requests hits rate (%) = (reference requests hits count reference GETs count) 100

Actions to be taken

When the reference requests hits rate is 80% or lower

Increase the value of the pdbuffer operand's -n option (number of global buffers).

Re-evaluate the value specified for the pdbuffer operand. If multiple RDAREAs are allocated to one global buffer, allocate one global buffer to a frequently accessed table. If one RDAREA is allocated to one global buffer, row-partition the table.

If the reference requests hits rate is too low and the reference page flush count is too high for the update requests hits rate, specify pd_dbbuff_lru_option=MIX.

When performing deferred write processing (when the pd_dbsync_point operand is specified as sync or it is omitted), decrease the value of the pdbuffer operand's -w option (percentage of pages output in deferred write processing).

When the reference requests hits rate is higher than 80%

There is no problem; however, to improve the hits rate even further, increase the number of global buffer sectors. RDAREAs storing tables with no buffering effects should be combined into a single RDAREA; otherwise, more memory may be used than is necessary.

(4) Check the update buffer flushes count (UPFLS)

Purpose

This information is collected in order to evaluate the validity of the update buffer flushes count. If the number of times a free buffer is created to read new pages after writing an updated buffer into a HiRDB file (update buffer flushes count) is high for the number of operations, the number of I/O operations increases, adversely affecting the transaction processing performance.

Evaluating the analysis results

The number of updated global buffer sectors may have increased along with the update buffer flushes count and the buffers count for reloading the same data (reference GETs count) for one of the following reasons:

The number of global buffer pool sectors is small

The ratio of the number of updating processes to the number of operations is high

Determine whether the update buffer flushes count is high or low for the number of operations.

Actions to be taken

When the update buffer flushes count is high

Increase the value of the pdbuffer operand's -n option (number of global buffers).

Re-evaluate the value specified for the pdbuffer operand. If multiple RDAREAs are allocated to one global buffer, separate the RDAREAs for tables to be updated from the RDAREAs for tables to be referenced, and allocate one global buffer to each type of RDAREA. If one RDAREA is allocated to one global buffer, store indexes and tables in separate RDAREAs and allocate a global buffer dedicated to indexes. Or, row-partition the tables.

When performing deferred write processing (when the pd_dbsync_point operand is specified as sync or it is omitted), decrease the value of the pdbuffer operand's -w option (percentage of pages output in deferred write processing).

When performing deferred write processing (when the pd_dbsync_point operand is specified as sync or it is omitted), decrease the value of the deferred write trigger request rate (pd_dbbuff_rate_updpage operand).

When the update buffer flushes count is low

There is no problem; however, to improve the hits rate even further, increase the number of global buffer sectors.

RDAREAs storing tables with no buffering effects should be combined into a single RDAREA; otherwise, more memory may be used than is necessary.

(5) Check the reference buffer flushes count (RFFLS)

Purpose

This information is collected in order to evaluate the validity of the reference buffer flushes count. If the number of times a free buffer is created to read new pages after writing a reference buffer into a HiRDB file (reference buffer flushes count) is high for the number of operations, the number of I/O operations increases, affecting adversely the transaction processing performance.

Evaluating the analysis results

When the reference buffer flushes count is too high for the number of operations

The number of reference buffers may have increased for one of the following reasons:

The number of global buffer pool sectors is small.

The ratio of the number of referencing processes to the number of operations is high.

As a result, buffer invalidation is occurring frequently in memory, or the same data is being fetched frequently in the buffer.

When the reference requests hits rate is low and the reference buffer flushes count is high

The number of update buffers may have increased for one of the following reasons:

The number of global buffer pool sectors is small.

The ratio of the number of update processes to the total number of processes is high (applicable when pd_dbbuff_lru_option=SEPARATE is specified or this operand is omitted).

As the amount of buffer space to be updated increases, the reference requests hits rate decreases. As a result, buffer invalidation occurs frequently in memory, or the same data is fetched frequently in the buffer.

Actions to be taken

When the reference buffer flushes count is high

If the reference requests hits rate is high, there is no problem. If it is low, the following actions can be taken:

Increase the value of the pdbuffer operand's -n option (number of global buffers).

Specify pd_dbbuff_lru_option=MIX.

When the reference buffer flushes count is low

There is no problem.

(6) Check the real READs count (READ) and real WRITEs count (WRITE)

Purpose

This information is collected in order to evaluate the validity of the number of disk I/O operations. If the number of disk I/O operations (HiRDB file I/O operations) is high for the total amount of processing, transaction processing performance and throughput are affected adversely. The number of I/O operations can be reduced efficiently by evaluating this information together with the information for each RDAREA that is provided as the HiRDB file information related to database accesses.

Evaluating the analysis results

When there are many input operations

If many RDAREAs use the same global buffer and each RDAREA is accessed frequently, input operations may occur frequently due to a low buffer hits rate.

If the reference requests hits rate is low, the page input operation may occur frequently due to the following factors:

The number of global buffer pool sectors is small (applicable when pd_dbbuff_lru_option=MIX is specified).

The ratio of the number of updating processes to the total amount of processing is too high for the reference buffer (applicable when pd_dbbuff_lru_option=SEPARATE is specified or this operand is omitted).

When there are many output operations

If greater importance is placed on the update buffer hits rate than on the reference requests hits rate, the corresponding global buffer may be requested for update processing more frequently.

If the update GETs count is greater than the reference GETs count, adverse effects may be caused by update buffer flushing, as described in (4) above.

Actions to be taken

When the reference requests hits rate is low and the number of input operations is high

Increase the value of the pdbuffer operand's -n option (number of global buffers).

Re-evaluate the value specified for the pdbuffer operand. If multiple RDAREAs are allocated to one global buffer, allocate one global buffer to a frequently accessed table. If the same global buffer pool is allocated to an index and table, allocate a global buffer pool dedicated to the index. If one RDAREA is allocated to one global buffer, row-partition the table.

When performing deferred write processing (when the pd_dbsync_point operand is specified as sync or it is omitted), increase the value of the pdbuffer operand's -w option (percentage of pages output in deferred write processing).

Specify pd_dbbuff_lru_option=MIX.

When there are many output operations

pd_dbsync_point=commit specified
There is no problem if the update request hits rate is high. If it is low, increase the value of the pdbuffer operand's -n option (number of global buffers).

pd_dbsync_point=sync specified or this operand omitted

Increase the value of the pdbuffer operand's -n option (number of global buffers).

When performing deferred write processing (when the pd_dbsync_point operand is specified as sync or it is omitted), increase the value of the pdbuffer operand's -w option (percentage of pages output in deferred write processing). Also increase the synchronization point interval.

(7) Check the buffer lock-release waits count (WAITL)

Purpose

This information is collected in order to evaluate the validity of the global buffer pool allocations to RDAREAs. If the number of concurrently executed transactions increases, contention occurs on accesses to the same global buffer pool, resulting in lock-release wait status. When the number of buffer lock-release waits increases, transaction processing time also increases, and the global buffer pool allocations should be reevaluated.

Evaluating the analysis results

If the buffer lock-release waits count is high for the total amount of processing, there may be many users using the same global buffer pool, resulting in high buffer access workload.

If the buffer lock-release waits count is high for the total amount of processing, multiple tables may be defined for the same global buffer pool, resulting in concentration of buffer accesses.

Actions to be taken

If multiple tables are stored in one RDAREA, allocate the storage RDAREA to each of the applicable global buffer pools.

If multiple RDAREAs are allocated to one global buffer pool, reduce the number of RDAREAs allocated to that global buffer pool.

If a table and index are both stored in the same RDAREA, store them in separate RDAREAs, and allocate a global buffer dedicated to the index.

(8) Check the prefetch input pages count (PRRED), prefetch hit pages count (PRHIT), and prefetch hits rate (HIT)

Purpose

This information is collected in order to evaluate the validity of the prefetch facility. In the case of retrieval of all items or retrieval by range, processing time can be reduced by using the prefetch facility. When a large amount of data is to be retrieved, the prefetch facility can influence the processing time.

Evaluating the analysis results

If the prefetch hits rate is 80% or less, the data or index storage pages for the table being retrieval may be fragmented.

Actions to be taken

Reorganize the table being retrieved. If the hits rate is extremely low but the table cannot be reorganized, do not use the prefetch facility (either omit the pdbuffer -m operand or specify 0 in the -m operand).

(9) Check the prefetch buffer shortages count (PRINS)

Purpose

This information is collected in order to evaluate the validity of the prefetch facility. If a shortage occurs in the buffer for prefetch processing, a user who is unable to execute a batch input operation cannot take advantage of prefetch processing.

Evaluating the analysis results

It is no problem if the prefetch buffer shortages count is 0. If it is other than 0, it can be considered that the maximum number of simultaneous prefetches is greater than the value specified in the pdbuffer operand's -m option.

Actions to be taken

Increase the value of the pdbuffer operand's -m option (maximum number of simultaneous prefetches). Also, reevaluate the memory requirements, because if this value is increased, the shared memory for global buffer pools also increases.

21.1.2 Using the statistics analysis utility to collect statistical information

Organization of this subsection

(1) Check the input waits count (WAITR) and output waits count (WAITW)

(2) Check the maximum concurrent request buffer sectors count (MAXB) and the buffer shortages count (BFINS)

(3) Check the number of synchronization point dump pages (SYNCW)

(4) Check the lock-release contention rate (SLEPR) in global buffer lock processing

(5) Check the average value for the sleep processing execution count in buffer lock processing (SLEPA)

(6) Check the buffer pool lock time during synchronization point processing (SYNCL)

(7) Check the take-over count of database write processing by the reference request hit during synchronization point processing (ALTRW)

(1) Check the input waits count (WAITR) and output waits count (WAITW)

Purpose

This information is collected in order to evaluate the validity of global buffer allocations to RDAREAs. If contention results because of multiple requests to access the same page, data I/O operations are placed in wait status for the following reasons:

Requested data must be read from the HiRDB file, because the appropriate page cannot be found in the global buffer pool; this results in an input wait.

Even when the appropriate page is found in the global buffer pool, but contention occurs between a referencing request and an updating request during a HiRDB file output operation, the HiRDB file is placed in output completion wait status.

Evaluating the analysis results

When the input waits count is high

Input waits may occur frequently for the following reasons:

I/O operations concentrate because HiRDB files in one or more RDAREAs are allocated on the same disk.

If multiple tables are stored in one RDAREA, many processing requests are issued for that RDAREA.

When the output waits count is high

Output waits may occur frequently for the following reasons:

Deferred write processing on the appropriate page and HiRDB file output processing result in contention.

The number of update buffers increases in the global buffer pool, because a large amount of global buffer pool space is used for data load processing by the database load utility or for reload processing by the database reorganization utility.

Actions to be taken

If multiple tables are stored in one RDAREA, allocate the RDAREAs to each of the applicable global buffer pools.

If a table contains a large amount of data, consider dividing the table or index into multiple partitions.

Distribute HiRDB files in one or more RDAREAs onto multiple disks.

If a large amount of data is being loaded by the database load utility or is being reloaded by the database reorganization utility, increase the number of batch output pages (-n option). Note that the database reorganization utility is applicable to a table whose data attribute is FIX.

When performing deferred write processing (when the pd_dbsync_point operand is specified as sync or is omitted) while the output waits count is high, decrease the value of the deferred write trigger request rate (pd_dbbuff_rate_updpage operand).

(2) Check the maximum concurrent request buffer sectors count (MAXB) and the buffer shortages count (BFINS)

Purpose

This information is collected in order to evaluate the validity of the number of buffer sectors in a global buffer pool. If the entire global buffer used for reading pages is unavailable, HiRDB cancels a transaction that requests a new page; this has an adverse effect on transaction throughput.

Evaluating the analysis results

If any of the following conditions is true, the number of buffer sectors is too low:

The maximum concurrent request buffer sectors count is close to or equal to the global buffer sectors count, and the buffer shortages count is 0 (this does not apply when the reference or update buffer hits rate is high; maximum performance seems to be achieved when the reference or update buffer hits rate is high).

The maximum concurrent request buffer sectors count is close to or equal to the global buffer sectors count, and the buffer shortages count is high.

The buffer shortages count is not 0.

Actions to be taken

Increase the value of the pdbuffer operand's -n option (number of global buffers).

If I/O operations concentrate on a particular RDAREA, allocate a dedicated global buffer pool instead of sharing the same global buffer pool among multiple RDAREAs.

(3) Check the number of synchronization point dump pages (SYNCW)

Purpose

This information is collected in order to evaluate the validity of the synchronization point dump output interval. Normally, all updated pages are output from a global buffer pool to the database during a synchronization point dump, which has an adverse effect on transaction performance. To prevent this, HiRDB executes internal processing (pre-sync processing and deferred write processing) and reduces the number of pages to be output during synchronization point dumps. Therefore, tuning the global buffer has an effect on the synchronization point dump output interval.

Evaluating the analysis results

Check that the number of pages output during a synchronization point dump is no greater than 50% of the global buffer sectors.

Actions to be taken

Increase the value of the pdbuffer operand's -w option (page rate of output by deferred write processing).

(4) Check the lock-release contention rate (SLEPR) in global buffer lock processing

Purpose

The purpose is to determine how much contention there is for locking of global buffers. If the contention rate is high, this will be one factor in the increased probability of global buffer lock-waiting and the resulting reduced performance.

Evaluating the analysis results

If the lock-release contention rate (SLEPR) in global buffer lock processing is greater than 1, the contention for global buffer lock processing can be considered to be high.

Actions to be taken

Check the value of the pd_dbbuff_lock_release_detect operand, and take one of the following measures:

When pd_dbbuff_lock_release_detect=interval

Do the following to reduce the CPU usage to below 70% and within the allowed operating range:
Increase the value of the pd_dbbuff_lock_spn_count operand.
Decrease the value of the pd_dbbuff_lock_interval operand.

Review the method of allocation of global buffers.
Allocate dedicated global buffers to an RDAREA that stores tables that are accessed frequently. If dedicated global buffers are already allocated, either row partition the tables and allocate dedicated global buffers to each RDAREA or store tables with a high frequency of accesses in different RDAREAs, and allocate dedicated global buffers to those RDAREAs.

When pd_dbbuff_lock_release_detect=pipe (default value)

Specify interval for the pd_dbbuff_lock_release_detect operand. Then execute step 1 above.

Execute step 2 above.

(5) Check the average value for the sleep processing execution count in buffer lock processing (SLEPA)

Purpose

The purpose is to determine whether or not a delay in the global buffer lock processing is causing an extremely long processing time for some jobs during concurrent job execution.

Evaluating the analysis results

If the following conditions are satisfied, it may be possible to reduce the global buffer lock processing time:

The average value for the sleep processing execution count in buffer lock processing (SLEPA) is at least 1 but less than 2.

There is no difference in the global buffer lock processing time between cases in which sleep processing is executed once or more, and cases in which sleep processing is never executed.

Actions to be taken

Check the value of the pd_dbbuff_lock_release_detect operand, and take one of the following measures:

When no transaction stops responding during synchronization point processing

Specify interval in the pd_dbbuff_lock_release_detect operand.

When the CPU usage is below 70% and within the allowed operating range, do the following:
- Specify 10 in the pd_dbbuff_lock_interval operand.
- Specify 100 in the pd_dbbuff_lock_spn_count operand.
If the value of SLPA remains 2 or greater after these settings have been specified, increase the pd_dbbuff_lock_spn_count operand value until the value of SLPA becomes less than 2.

Review the method of allocating global buffers.
Allocate dedicated global buffers to an RDAREA that stores tables that are accessed frequently. If dedicated global buffers are already allocated, either row partition the tables and allocate dedicated global buffers to each RDAREA, or store tables with a high frequency of accesses in different RDAREAs and allocate dedicated global buffers to those RDAREAs.

When transactions stop responding during synchronization point processing

See (6) Check the buffer pool lock time during synchronization point processing (SYNCL).

(6) Check the buffer pool lock time during synchronization point processing (SYNCL)

Purpose

If a transaction stops responding during synchronization point processing, there may be contention for locking the global buffer between search processing in the buffer subject to synchronization point processing, and buffer access by the transaction. If there is contention, buffer access by a transaction is placed on hold during the buffer pool lock time during synchronization point processing (SYNCL).

Evaluating the analysis results

If a transaction stops responding during synchronization point processing, determine whether or not the buffer pool lock time during synchronization point processing (SYNCL) is too long for the lock release wait time.

Actions to be taken

Reduce the pd_dbsync_lck_release_count operand value, so as to adjust the buffer pool lock time during synchronization point processing (SYNCL) to be within the allowable limits of the lock release wait time.

(7) Check the take-over count of database write processing by the reference request hit during synchronization point processing (ALTRW)

Purpose

If a referencing transaction stops responding during synchronization point processing, delayed output processing may be taking place at an extension of transaction at the time of the reference request hit on the buffer that is subject to synchronization point processing.

Evaluating the analysis results

If a referencing transaction stops responding during synchronization point processing, check to see if this is caused by the take-over count of database write processing by the reference request hit during synchronization point processing (ALTRW).

Actions to be taken

By specifying Y in the pd_dbsync_altwrite_skip operand, you can suppress database write processing by the reference request hit during synchronization point processing. However, this increases the synchronization point acquisition processing time. Hitachi recommends that you use the facility for parallel writes in deferred write processing to distribute the write processing workload. For details about the facility for parallel writes in deferred write processing, see the manual HiRDB Version 8 Installation and Design Guide.

21.2 Tuning deferred write processing

When sync is specified in the pd_dbsync_point operand in the system common definition or the pd_dbsync_point operand is omitted, HiRDB executes deferred write processing to reduce the number of disk output operations. Deferred write processing improves performance by processing RDAREAs distributed among multiple disks in units of disks.

Therefore, when character special files are used for a HiRDB file system area in which RDAREAs are allocated and the RDAREAs are allocated on a single disk, the benefits of deferred write processing are not obtained.

Information to be collected

Deferred write processing statistical information is collected by the statistics analysis utility.

Organization of this section

(1) Check the parallel level for each disk volume (MAX ,PMIN)

(2) Check the average value (AVG)

(1) Check the parallel level for each disk volume (MAX ,PMIN)

Purpose

This information is collected in order to evaluate the validity of table and global buffer allocations to RDAREAs on the basis of the level of parallel processing requests for multiple pages in the global buffers. When updated pages are written during deferred write processing, HiRDB executes I/O operations on each disk concurrently in order to improve performance.

Evaluating the analysis results

If multiple RDAREAs use a global buffer, it should be verified that the minimum parallel level value for each disk volume is not 1. If the RDAREAs span multiple disks, only some of the RDAREAs may be updated.

Actions to be taken

If update processing concentrates on a particular RDAREA, allocate a separate global buffer for that RDAREA.

If both index and table are stored in the same RDAREA, store them in separate RDAREAs and allocate separate global buffers to those RDAREAs.

(2) Check the average value (AVG)

Purpose

This information is collected in order to evaluate the validity of the global buffers on the basis of the average updated pages output during the following processing:

Trigger output

When the number of updated pages in the global buffers reaches a given number of buffers, the pages are output to disk.

Note that when the deferred write trigger request rate is enabled, pages are output to disk when the specified value is reached. You specify this value in the pd_dbbuff_rate_updpage operand.

The number of pages output to disk is calculated by HiRDB on the basis of the output page percentage specified in the pdbuffer operand's -w option.

Pre-sync output

A pre-sync point is set internally in order to reduce the number of pages to be output to the disk at a synchronization point. Pre-sync processing involves writing updated pages from global buffer to disk prior to a synchronization point so that fewer pages need to be output during the synchronization point dump.

Synchronization point dump output

All updated pages are output from global buffer to disk at a synchronization point. Pre-sync output can greatly reduce the time required for output processing during a synchronization point dump.

Database synchronization point dump output

The contents of the update buffer are committed to the database at a synchronization point trigger at which a synchronization point dump cannot be enabled.

RDAREA synchronization point dump output

All updated pages corresponding to an RDAREA are output to the disk.

Evaluating the analysis results

When the average number of output pages is too small

Check if the buffer flushes count is greater than the page outputs count during deferred write processing. If so, check the global buffer pool whose data is not updated frequently.

If the update page buffer hits rate is high and the number of pages output during deferred write processing is small, there should be no problem.

If the update page buffer hits rate is low and the number of pages output during deferred write processing is small, the synchronization point dump interval should be reduced.

The following formula can be used to obtain the average number of output pages:

a: Output pages count (OUT PAGE)

b: Number of synchronization point dump pages (SYNCW)

c: Deferred write processing activations count (EXEC)

d: Synchronization points count (SYNC)

n: Number of global buffer pools defined

For a HiRDB/Parallel Server

A specific back-end server may have a high output pages count for one of the following reasons:

A frequently updated table is stored in the back-end server.

Update processing is concentrated on a specific key range of a partitioned table.

Actions to be taken

When write operations are concentrated on a specific global buffer:

If multiple RDAREAs are allocated to the global buffer pool, allocate separate global buffers for the RDAREAs.

If a specific server is used to update multiple tables, each table should be stored in a different back-end server.

When multiple RDAREAs are defined on the same disk

Allocate each RDAREA on a separate disk to improve the I/O parallel level.

21.3 Tuning the synchronization point processing time when deferred write processing is used

When deferred write processing is used, it may take some time to accomplish synchronization point processing. This section describes how to reduce the synchronization point processing time.

Organization of this section

21.3.1 Tuning procedure

21.3.2 How to interpret statistical information about deferred write processing

21.3.3 How to reduce the synchronization point processing time

21.3.1 Tuning procedure

When a large amount of data is updated, the number of update buffers that must be applied to the database during synchronization point processing (number of update pages in the global buffer) increases, resulting in a corresponding increase in the time required for synchronization point processing. If synchronization point processing is skipped two or more times in succession, the number of system log files that cannot be overwritten increases. If there is no swappable file, HiRDB (or the unit in the case of a HiRDB/Parallel Server) terminates abnormally.

To avoid this, it is important to complete synchronization point processing within the amount of time that was estimated at the design stage. If the following conditional expression is satisfied, there is no need to perform tuning:

Synchronization point acquisition interval (time) > synchronization point processing time

If synchronization point processing is skipped due to a delay in deferred write processing, the KFPS02179-I message (factor code = A01-01) is displayed. In such a case, perform tuning according to the procedure described below.

Organization of this subsection

(1) Acquiring the tuning information

(2) Checking the statistical information about the deferred write processing

(3) Checking the average WRITE unit time

(4) Checking the KFPS02179-I message

(5) Evaluating the synchronization point acquisition interval

(6) Tuning the deferred write trigger

(7) Using the facility for parallel writes in deferred write processing

(8) Evaluating a limit on the number of update buffers

(9) Tuning the global buffer

(1) Acquiring the tuning information

Acquire the following tuning information:

Information about CPU and disk I/O operations

Statistical information about the global buffer

Statistical information about the deferred write processing

To acquire 1, use the appropriate OS function. To acquire 2 and 3, use the statistics analysis utility.

(2) Checking the statistical information about the deferred write processing

Check the statistical information about the deferred write processing whose cause (CAUSE) is S (synchronization point processing). If one of the following conditions is satisfied, proceed to (3). If neither of the conditions is satisfied, proceed to (9).

When the facility for parallel writes in deferred write processing is not used
Total WRITE time (DWSUM, DWSUMM) > synchronization point acquisition interval (time)

When the facility for parallel writes in deferred write processing is used
Parallel WRITE time (DWPARA, DWPARAM) > synchronization point acquisition interval (time)

Obtain the synchronization point acquisition interval from the difference between the output times of the following messages:

KFPS02183-I (message displayed when synchronization point processing is completed)

KFPS02179-I (message displayed when synchronization point processing is skipped)

(3) Checking the average WRITE unit time

If the average WRITE unit time for the statistical information about deferred write processing (DWAVG and DWAVGM) is extremely poor compared to the disk write performance, do the following (if these do not apply, proceed to (4)):

Check for a disk failure.

Because a problem such as disk contention may have occurred, use OS functions to acquire tuning information about input/output operations, and perform tuning based on the results. If there is no leeway for tuning, proceed to (4).

(4) Checking the KFPS02179-I message

If synchronization point processing is skipped, the KFPS02179-I message is displayed. If any of the utilities listed below was executing during the period in which this message was displayed, consider changing the operating method (if this does not apply, proceed to (5)):

When the database load utility, database reorganization utility, or rebalancing utility is executing
Use the local buffer by specifying the -n option for the utility's execution. If the local buffer cannot be used, proceed to (5).

When the free page release utility is executing
Specify the -p option for the utility's execution. If the -p option cannot be specified, proceed to (5).

(5) Evaluating the synchronization point acquisition interval

Evaluate whether or not the synchronization point acquisition interval can be made longer. If it cannot be made longer, proceed to (6). You use the pd_log_sdinterval operand to change the synchronization point acquisition interval.

(6) Tuning the deferred write trigger

Perform the tuning described in 21.3.3(1) Reducing the deferred write trigger interval and in 21.3.3(2) Increasing the update page output rate during deferred write trigger. If the problem is not resolved after tuning, proceed to (7).

(7) Using the facility for parallel writes in deferred write processing

If there is enough room in the CPU, perform the tuning described below. If there is not enough room in the CPU, proceed to (8).

When the facility for parallel writes in deferred write processing is not used
Specify the pd_dfw_awt_process operand to use the facility for parallel writes in deferred write processing. If this does not resolve the problem, proceed to (8).

When the facility for parallel writes in deferred write processing is used
Perform the tuning described in 21.3.3(3) Increasing the number of parallel WRITE processes during deferred write processing. If this does not resolve the problem, proceed to (8).

(8) Evaluating a limit on the number of update buffers

Specify the pd_dfw_syncpoint_skip_limit operand to limit the number of update buffers. In this case, note that when the skip count for synchronization point processing reaches the maximum value, the performance of an update transaction decreases because the update buffer is output at the extension of the update transaction.

If the pd_dfw_syncpoint_skip_limit operand cannot be specified, evaluate a disk enhancement.

(9) Tuning the global buffer

If any of the following events has occurred, tune the global buffer:

Buffer lock-release wait (WAITL) occurs frequently.

Output wait (WAITW) occurs frequently.

The lock-release contention rate (SLEPR) in global buffer lock processing is high.

The update buffer flushes count (UPFLS) has increased.

For details about the above information and the tuning of the global buffer, see 21.1 Tuning global buffer pools.

21.3.2 How to interpret statistical information about deferred write processing

Information to be referenced

Use the statistics analysis utility (pdstedit) to acquire DAT-format files that contain statistical information about deferred write processing, and then check the following information:

Execution time (DWTOTAL, DWTOTALM)

Total WRITE time (DWSUM, DWSUMM)

Parallel WRITE time (DWPARA, DWPARAM)

WRITE unit time
Minimum (DWMIN, DWMINM)
Maximum (DWMAX, DWMAXM)
Average (DWAVG, DWAVGM)

WRITE count (DWEXEC)

Organization of this subsection

(1) Execution time (DWTOTAL, DWTOTALM)

(2) Total WRITE time (DWSUM DWSUMM)

(3) Parallel WRITE time (DWPARA DWPARAM)

(4) WRITE unit time minimum (DWMIN DWMINM)

(5) WRITE unit time maximum (DWMAX DWMAXM)

(6) WRITE unit time average (DWAVG DWAVGM)

(7) WRITE count (DWEXEC)

(1) Execution time (DWTOTAL, DWTOTALM)

This is the total time required for deferred write processing. DWTOTAL displays the time in seconds, and DWTOTALM displays only the microseconds portion of the time.

Purpose

This information is collected to determine whether the deferred write processing performance is appropriate.

Evaluating the analysis results

If the deferred write delay message (KFPS02179-I factor code = A01-01) is output, take the following action:

Action to be taken

For details about the action to be taken, see 21.3.1 Tuning procedure.

(2) Total WRITE time (DWSUM DWSUMM)

This is the total time required for writing during deferred write processing. DWSUM displays the time in seconds, and DWSUMM displays only the microseconds portion of the time.

Purpose

This information is collected in order to determine whether tuning the process count when using the facility for parallel writes in deferred write processing had any effect compared to the parallel WRITE time (DWPARA DWPARAM).

Evaluating the analysis results

Check the values of WRITE unit time (maximum) (DWMAX DWMAXM), WRITE unit time (minimum) (DWMIN DWMINM), and WRITE count (DWEXEC).

Action to be taken

Check the values of WRITE unit time (maximum) (DWMAX DWMAXM), WRITE unit time (minimum) (DWMIN DWMINM), and WRITE count (DWEXEC), and take appropriate action.

(3) Parallel WRITE time (DWPARA DWPARAM)

This is the length of time from when a request to process multiple parallel WRITE processes was issued to when completion notifications for all parallel WRITE processes have been received. DWPARA displays the time in seconds, and DWPARAM displays only the microseconds portion of the time. Figure 21-1 shows the concept of parallel WRITE time.

Figure 21-1 Concept of parallel WRITE time

If the facility for parallel writes in deferred write processing is disabled, the parallel WRITE time is 0.

Purpose

This information is collected in order to check the effects of using the facility for parallel writes in deferred write processing.

Evaluating the analysis results

If the following condition is true, use of the facility for parallel writes in deferred write processing is considered to be effective:

Execution time (value of DWTOTAL + DWTOTALM) > parallel WRITE time (value of DWPARA + DWPARA)

For accurate checking, measure the execution time value of DWTOTAL + DWTOTALM) at the following times:

Before and after the facility for parallel writes in deferred write processing is used

Before and after the pd_dfw_awt_process operand value is changed

If the execution time is reduced, use of the facility for parallel writes in deferred write processing is considered to be effective.

Actions to be taken

If use of the facility is effective, perform the tuning described in 21.3.3(3) Increasing the number of parallel WRITE processes during deferred write processing.

If the use of the facility is not effective, do one of the following:

Stop using the facility for parallel writes in deferred write processing.

Restore the pd_dfw_awt_process operand to its original value

(4) WRITE unit time minimum (DWMIN DWMINM)

This is the shortest write time on a page when write operations occur on multiple pages. DWMIN displays the time in seconds, and DWMINM displays only the microseconds portion of the time.

Purpose

This information is collected in order to check the validity of disk performance.

Evaluating the analysis results

Compare with disk performance for evaluation. If you use the facility for parallel writes in deferred write processing or you change the number of parallel WRITE processes, compare disk performance before and after the facility is used, or before and after the change.

Actions to be taken

If the performance is poor compared to the disk performance, use OS functions to acquire input/output-related tuning information, and then perform tuning on the basis of that information. If the disk performance was reduced after the facility for parallel writes in deferred write processing was used or after the number of parallel WRITE processes was changed, check the parallel WRITE time. If the facility is not effective, restore the previous settings that were in use before the facility was applied or the change was made.

One of the causes of poor disk performance is disk contention. Check and, if necessary, revise the configuration of disks, RDAREAs, and tables so that input/output processing is not concentrated on any particular volume. For the design guidelines for disks, RDAREAs, and the table configurations, see the manual HiRDB Version 8 Installation and Design Guide.

(5) WRITE unit time maximum (DWMAX DWMAXM)

This is the maximum write time for a page when write operations occur on multiple pages. DWMAX displays the time in seconds, and DWMAXM displays only the microseconds portion of the time.

Purpose

This information is collected in order to check the validity of disk performance.

Evaluating the analysis results

Compare with the disk performance for evaluation. If you use the facility for parallel writes in deferred write processing or if you change the number of parallel WRITE processes, compare disk performance before and after the facility is used or before and after the change.

Actions to be taken

If the performance is poor compared to disk performance, use OS functions to acquire input/output-related tuning information, and then perform tuning on the basis of that information. If disk performance was reduced after the facility for parallel writes in deferred write processing was used or after the number of parallel WRITE processes was changed, check the parallel WRITE time. If the facility is not effective, restore the previous settings that were in use before the facility was applied or the change was made.

One of the causes of poor disk performance is disk contention. Check and, if necessary, revise the configuration of disks, RDAREAs, and tables so that input/output processing is not concentrated on any particular volume. For the design guidelines for disks, RDAREAs, and the table configurations, see the manual HiRDB Version 8 Installation and Design Guide.

(6) WRITE unit time average (DWAVG DWAVGM)

This is the average write time when write operations occur on multiple pages. DWAVG displays the time in seconds, and DWAVGM displays only the microseconds portion of the time.

Purpose

This information is collected in order to check the validity of disk performance.

Evaluating the analysis results

Compare with the disk performance for evaluation. If you use the facility for parallel writes in deferred write processing or if you change the number of parallel WRITE processes, compare disk performance before and after the facility is used or before and after the change.

Actions to be taken

If the performance is poor compared to the disk performance, use OS functions to acquire input/output-related tuning information and then perform tuning on the basis of that information. If the disk performance was reduced after the facility for parallel writes in deferred write processing was used or after the number of parallel WRITE processes was changed, check the parallel WRITE time. If the facility is not effective, restore the previous settings that were in use before the facility was applied or the change was made.

One of the causes of poor disk performance is disk contention. Check and, if necessary, revise the configuration of disks, RDAREAs, and tables so that input/output processing is not concentrated on any particular volume. For the design guidelines for disks, RDAREAs, and the table configurations, see the manual HiRDB Version 8 Installation and Design Guide.

(7) WRITE count (DWEXEC)

This is the write count for each operational cause (CAUSE).

Purpose

This information is collected to determine whether or not deferred write processing is delayed for the following reason:

The number of update buffers that can be processed is exceeded within the synchronization point collection interval.

Evaluating the analysis results

If the operational cause (CAUSE) is S (synchronization point), check to see if the WRITE count (DWEXEC) is equal to or less than the value obtained from the formula below. If the WRITE count is greater than the value, take appropriate action, as described below.

{synchronization point collection interval average WRITE unit time (DWAVG, DWAVGN)} 0.1

Obtain the synchronization point collection interval from the difference between the output times of the following messages:

KFPS02183-I (message displayed when synchronization point processing is completed)

KFPS02179-I (message displayed when synchronization point processing is skipped)

Actions to be taken

Tune by reducing the number of update buffers during synchronization point processing. For details about the tuning method, see 21.3.3(1) Reducing the deferred write trigger interval and 21.3.3(2) Increasing the update page output rate during deferred write trigger.

If the tuning does not help, specify the pd_dfw_syncpoint_skip_limit operand and limit the number of update buffers. In this case, however, if the skip count for the synchronization point processing reaches the maximum value, the update buffer is output at an extension of the update transaction, thereby adversely affecting the update transaction performance.

21.3.3 How to reduce the synchronization point processing time

There are three ways to reduce the synchronization point processing time:

Reduce the deferred write trigger interval

Increase the update page output rate during the deferred write trigger

Increase the number of parallel WRITE processes during the deferred write processing

Organization of this subsection

(1) Reducing the deferred write trigger interval

(2) Increasing the update page output rate during deferred write trigger

(3) Increasing the number of parallel WRITE processes during deferred write processing

(1) Reducing the deferred write trigger interval

Reduce the deferred write trigger interval and the number of update buffers during synchronization point processing. If the number of update buffers decreases, the time required for applying the updated pages during synchronization point processing can be reduced, thereby reducing the synchronization point processing time.

The following describes how to tune the deferred write trigger interval.

Procedure

Acquire statistical information about the global buffer and the deferred write processing.

From the execution results in the global buffer statistical information, identify the global buffer whose synchronization point output pages count (SYNCW) is high.

Use the following operands to specify the deferred write trigger start conditions:
pd_dbbuff_rate_updpage operand
-y option in the pdbuffer operand
Check the global buffer statistical information and change the operand values in such a manner that the following condition is satisfied:
TRGUP (number of update buffers that become output triggers during deferred write triggers) < SYNCW (number of synchronization point dump pages)/2
If the value of TRGUP is too small, the number of write operations increases and the transaction performance may be adversely affected. If this happens, restore the original operand values.

Check to see if the synchronization point processing time is within 10% of the synchronization point acquisition interval. If it is greater than 10%, repeat steps 1 through 3 until it is within 10%.

To determine the synchronization point processing time, check the execution time (DWTOTAL) in the statistical information about deferred write processing.

Obtain the synchronization point collection interval from the difference between the output times of the following messages:

KFPS02183-I (message displayed when synchronization point processing is completed)

KFPS02179-I (message displayed when synchronization point processing is skipped)

(2) Increasing the update page output rate during deferred write trigger

Increase the update page output rate during deferred write processing (increase the number of update pages to be applied during deferred write trigger processing), and reduce the number of update buffers during synchronization point processing. If the number of update buffers decreases, the time required for applying the updated pages during synchronization point processing can be reduced, thereby reducing the synchronization point processing time.

The following describes how to tune the update page output rate during deferred write trigger.

Procedure

Acquire statistical information about the deferred write processing.

Increase the -w option value in the pdbuffer operand.
If the -w option value is too large, the number of write operations increases and the transaction performance may be affected adversely. If this happens, restore the original operand value.

Check to see if the synchronization point processing time is within 10% of the synchronization point acquisition interval. If it is greater than 10%, repeat steps 1 and 2 until it is within 10%.

Obtain the synchronization point collection interval from the difference between the output times of the following messages:

KFPS02183-I (message displayed when synchronization point processing is completed)

KFPS02179-I (message displayed when synchronization point processing is skipped)

(3) Increasing the number of parallel WRITE processes during deferred write processing

Increase the number of parallel WRITE processes during deferred write processing to reduce the deferred write processing time. The following describes how to tune the number of parallel WRITE processes during deferred write processing.

Procedure

Acquire statistical information about the deferred write processing.

Increase the pd_dfw_awt_process operand value to increase the number of parallel WRITE processes during deferred write processing.
Note that if the pd_dfw_awt_process operand value increases, the number of processes also increases, resulting in an increase in the CPU workload. Therefore, use a facility such as an OS function to monitor the CPU workload.

Check to see if the synchronization point processing time is within 10% of the synchronization point acquisition interval. If it is greater than 10%, repeat steps 1 and 2 until it is within 10%.

To determine the synchronization point processing time, check the execution time (DWTOTAL) in the statistical information about deferred write processing.

Obtain the synchronization point collection interval from the difference between the output times of the following messages:

KFPS02183-I (message displayed when synchronization point processing is completed)

KFPS02179-I (message displayed when synchronization point processing is skipped)

If increasing the number of parallel WRITE processes during deferred write processing does not reduce the parallel WRITE time (DWPARA, DWPARAM), possible causes are as follows:

Disk contention has occurred.
Check and, if necessary, revise the configuration of disks, RDAREAs, and tables so that input/output processing is not concentrated on any particular volume.

Global buffer lock-release-wait has occurred.
You can check the global buffer statistical information referred to as lock-release contention rate (SLEPR) in buffer lock processing to determine the occurrence rate of global buffer lock-release wait status. For details about the tuning method, see 21.1.2(4) Check the lock-release contention rate (SLEPR) in global buffer lock processing .

There are not enough output pages.
The maximum number of parallel WRITE processes that can be executed can be obtained from the following formula:

Total number of output pages (OUT PAGE)/20

Even if a value that is greater than the value obtained from this formula is specified, the value from this formula still takes effect.
To determine the total number of output pages (OUT PAGE), check statistical information about the deferred write processing.

21.4 Tuning the synchronization point dump interval

Typically, the synchronization point dump interval is set taking into account the following considerations:

Considerations

For update processing involving a large amount of data, the transaction processing time is long and there is a large amount of system log information; therefore, recovery at the time of a restart is prolonged.

For update processing involving a small amount of data, the transaction processing time is short and there is a small amount of system log information; therefore, recovery at the time of a restart is brief.

When the synchronization point dump output interval is tuned, it is also advisable to evaluate the global buffer pool statistical information and the deferred write processing statistical information.

Information to be collected

System activity statistical information is collected by the statistics analysis utility.

Information to be referenced

Synchronization point dump interval (SYNC POINT GET INTERVAL)

Synchronization point dump collection time (SYNC POINT GET TIME)

Purpose

In order to evaluate the validity of the synchronization point dump interval, the time required for a restart (time required to collect the system log) and the throughput must be taken into consideration.

The time required for a restart may be shorter than usual, because HiRDB writes updated pages from global buffer to disk during deferred write processing. The performance of synchronization point dumps can be improved if deferred write processing statistical information is also collected and the number of pages written during deferred write processing (OUT PAGE) is evaluated.

Criteria for evaluating the analysis results

If many pages are written to disk during a synchronization point dump, the number of pages written to disk during deferred write processing may be too small.

If the update buffer hits rate is low and the number of pages output at synchronization points is large, consider reducing the value of the pdbuffer operand's -w option (the rate of pages output in deferred write processing).

If the system log file swapping interval is short for the synchronization point dump interval, the size of the system log file may be too small for the number of blocks output at a synchronization point dump interval. This does not apply when the amount of system log file information available for data output is less than the number of blocks to be output at a synchronization point dump. In such a case, a synchronization point dump is collected automatically when the system log file becomes full.

Actions to be taken

Set the time required for restart processing in a range acceptable to the user.

A synchronization point dump cannot become effective until a transaction that is executing has been completed; therefore, a long transaction should not be executed concurrently with other transactions. A long transaction means that the amount of log information output by one user server during execution of the transaction is greater than one-third the size of the log file for the user server (user server refers to the single server in the case of a HiRDB/Single Server and to a front-end server, back-end server, or dictionary server in the case of a HiRDB/Parallel Server).

21.5 Tuning buffer lengths

This section explains tuning of the lengths of the following types of buffers:

Table definition information buffer

View analysis information buffer

User privilege information buffer

SQL object buffer

User-defined type information buffer

Routine definition information buffer

Registry information buffer

Organization of this section

21.5.1 Tuning the buffer length for table definition information

21.5.2 Tuning the buffer length for view analysis information

21.5.3 Tuning the buffer length for user privilege information

21.5.4 Tuning the buffer length for SQL objects

21.5.5 Tuning the buffer length for user-defined type information

21.5.6 Tuning the buffer length for routine definition information

21.5.7 Tuning the buffer length for registry information

21.5.1 Tuning the buffer length for table definition information

This section explains tuning the buffer length for table definition information (pd_table_def_cache_size operand value).

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

Table definition information buffer hits count (#OF TBL-CACHE HIT)

Number of table definition information acquisition requests (#OF TBL-DEF GET REQ)

Tuning procedure

Obtain the table definition information buffer hits rate with the following formula, and make changes to the definitions so that the hits rate becomes greater than 80%:

Table definition information buffer hits rate (%) =

(table definition information buffer hits count number of table definition information acquisition requests) 100

Actions to be taken

Increase the value of the pd_table_def_cache_size operand.

21.5.2 Tuning the buffer length for view analysis information

This section explains tuning of the buffer length for view analysis information (pd_view_def_cache_size operand value).

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

View analysis information buffer hits count (#OF VIEW CACHE HIT)

Number of view analysis information acquisition requests (#OF VIEW DEF GET REQ)

Tuning procedure

Obtain the view analysis information buffer hits rate with the following formula, and make changes to the definitions so that the hits rate becomes greater than 80%:

View analysis information buffer hits rate (%) =

(view analysis information buffer hits count number of view analysis information acquisition requests) 100

Actions to be taken

Increase the value of the pd_view_def_cache_size operand.

21.5.3 Tuning the buffer length for user privilege information

This section explains tuning of the buffer length for user privilege information (pd_auth_cache_size operand value).

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

User privilege information buffer hits count (#OF CON/DBA CACHE HIT)

Number of user privilege information acquisition requests (#OF CON/DBA DEF GET REQ)

Tuning procedure

If the user privilege information buffer hits rate is low for the table definition information buffer hits rate, performance may be affected adversely for the following reason:

The user privilege information buffer hits rate is low because there is too much CONNECT and DBA privilege information.

Obtain the user privilege information buffer hits rate with the following formula:

User privilege information buffer hits rate (%) =

(user privilege information buffer hits count number of user privilege information acquisition requests) 100

Actions to be taken

Increase the value of the pd_auth_cache_size operand.

21.5.4 Tuning the buffer length for SQL objects

This section explains tuning of the buffer length for SQL objects (pd_sql_objet_cache_size operand value). When SQL object buffer tuning is performed, the following must be taken into account:

Relationship between an SQL object and an SQL object buffer

HiRDB analyzes each SQL statement in a UAP and creates an execute-form SQL object when the UAP executes. If the same UAP is executed again by another user and if an SQL object corresponding to a specified SQL statement is found in an SQL object buffer, the time required for creating the SQL object is eliminated, thereby reducing SQL statement processing time.

Once an SQL object is deleted from its buffer, it must be analyzed again to re-create it during execution, resulting in a low SQL object buffer hits rate. Therefore, when an SQL statement whose database accesses count is low is executed, a long processing time is required. Furthermore, if the buffers do not contain the table definition information necessary to analyze an SQL statement, the data dictionary tables must be accessed. If many tables or columns are accessed or data is accessed many times, the amount of locked resources increases, thereby increasing the processing time.

SQL object buffers

In the case of a HiRDB/Parallel Server, multiple SQL objects are created for a single SQL statement. The characteristics of SQL objects in the back-end and front-end servers are discussed below.

Back-end server
SQL objects are created in execute form for each corresponding back-end server (including a floating server). Of all the SQL objects buffered in the front-end server, only those SQL objects for a particular back-end server are buffered in the SQL object buffers of that back-end server; therefore, fewer SQL object buffers are required for a back-end server than for the front-end server.

Front-end server
The SQL object buffers for the front-end server contain all SQL objects for the back-end servers. A large number of SQL object buffers is required in order to take advantage of the buffering effects, because cost-based optimization creates SQL objects for selectable access procedures.
The same applies to stored procedures and stored functions. It should be noted that the size of an SQL object is larger for a stored procedure or a stored function than for a normal SQL.

Performance can be improved efficiently if this information is analyzed together with the following statistical information:

SQL object information
This information is collected in order to analyze the buffer length required for each SQL object.

SQL information
This information is collected in order to determine whether or not the buffer length is too small.

Organization of this subsection

(1) Analysis method (1)

(2) Analysis method (2)

(3) Analysis method (3)

(4) Analysis method (4)

(1) Analysis method (1)

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

SQL object buffer hits count (#OF CACHE HIT (SQLOBJ))

Number of SQL object acquisition requests (#OF SQLOBJ INFO GET)

Number of SQL objects in SQL object buffers (#OF CACHED SQLOBJ)

SQL object buffer hits count for stored procedure objects (#OF CACHED HIT (STRT))

Number of stored procedure object acquisition requests (#OF STRT INFO GET)

Number of stored procedure objects in SQL object buffers (#OF CACHED STRT)

Tuning procedure

If the SQL object buffer hits rate is low and the total length of SQL object information in the buffers is short, the application mode may be preventing a high hits rate from being achieved.

If the SQL object buffer hits rate is low and the total length of SQL object information in the buffers is long, the SQL object buffers may be too small.

Use the following formula to obtain the SQL object buffer hits rate:

SQL object buffer hits rate (%) =

(SQL object buffer hits count number of SQL object acquisition requests) 100

Actions to be taken

If the SQL object buffers are too small, increase the value of the pd_sql_objet_cache_size operand.

(2) Analysis method (2)

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

Number of SQL objects removed from SQL object buffers (#OF SWAP OUT SQLOBJ)

Number of SQL object acquisition requests (#OF SQLOBJ INFO GET)

Number of stored procedure objects removed from SQL object buffers (#OF SWAP OUT STRT)

Number of stored procedure object acquisition requests (#OF STRT INFO GET)

Tuning procedure

Tune in such a manner that the number of SQL objects taken out of the SQL object buffer is small.

If the number of SQL objects removed from SQL object buffers is greater than the number of SQL object acquisition requests, too many SQL objects are having to be re-created, thereby increasing the processing time. This is probably caused by poor utilization of the SQL object buffer pool.

Actions to be taken

Increase the value of the pd_sql_objet_cache_size operand.

(3) Analysis method (3)

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

Length of SQL objects (REQUEST SQLOBJ SIZE)

Length of stored procedure objects (REQUEST STRT SIZE)

Tuning procedure

If the maximum total of the SQL object lengths (REQUEST SQLOBJ SIZE) and stored procedure object lengths (REQUEST STRT SIZE) is greater than the specified buffer length, insufficient memory may have been allocated to execute SQL objects.

Actions to be taken

Increase the value of the pd_sql_objet_cache_size operand.

(4) Analysis method (4)

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

Stored procedure object recompilations count (# OF STRT RECOMPILE)

Tuning procedure

When the CALL statement is used to execute a stored procedure, recompilation usually does not occur. If an index is added to a table used within a stored procedure or an index not in use is deleted, recompilation occurs. Such recompilation occurs each time the stored procedure is executed with the CALL statement, which has an adverse effect on performance.

If recompilation has occurred, one of these changes may have been made to a table used within the stored procedure.

Actions to be taken

Use ALTER PROCEDURE or ALTER ROUTINE to re-create the stored procedure.

21.5.5 Tuning the buffer length for user-defined type information

This section explains tuning of the buffer length for user-defined type information (pd_type_def_cache_size operand value).

Organization of this subsection

(1) Tuning method (1)

(2) Tuning method (2)

(1) Tuning method (1)

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

Type definition cache hits count (# OF TYPE-DEF CACHE HIT)

Number of type definition information acquisition requests (# OF TYPE-DEF GET REQ)

Tuning procedure

Obtain the type definition cache hits rate with the following formula, and tune it so that the hits rate becomes 100%:

Type definition cache hits rate (%) =

(type definition cache hits count number of type definition information acquisition requests) 100

Actions to be taken

Increase the value of the pd_type_def_cache_size operand.

(2) Tuning method (2)

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

Total type definitions cache size (TYPE-DEF CACHE TOTAL SIZE)

Allocated type definition cache size (TYPE-DEF CACHE ALLOC SIZE)

Tuning procedure

Obtain the type definition cache utilization factor with the following formula, and tune it so that the utilization factor becomes 90% or higher:

Type definition cache utilization factor (%) =

(maximum value of total type definitions cache size allocated type definition cache size) 100

Actions to be taken

Reduce the value of the pd_type_def_cache_size operand.

21.5.6 Tuning the buffer length for routine definition information

This section explains tuning of the buffer length for routine definition information (pd_routine_def_cache_size operand value).

Organization of this subsection

(1) Tuning method (1)

(2) Tuning method (2)

(3) Tuning method (3)

(1) Tuning method (1)

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

Routine definition cache hits count (# OF RTN-DEF CACHE HIT)

Number of routine definition information acquisition requests (# OF RTN-DEF GET REQ)

Tuning procedure

Obtain the routine definition cache hits rate with the following formula, and tune it so that the hits rate becomes 100%:

Routine definition cache hits rate (%) =

(routine definition cache hits count number of routine definition information acquisition requests) 100

Actions to be taken

Increase the value of the pd_routine_def_cache_size operand.

(2) Tuning method (2)

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

Total routine definitions cache size (RTN-DEF CACHE TOTAL SIZE)

Allocated routine definition cache size (RTN-DEF CACHE ALLOC SIZE)

Tuning procedure

Obtain the routine definition cache utilization factor with the following formula, and tune it so that the utilization factor becomes 90% or higher:

Routine definition cache utilization factor (%) =

(maximum value of total routine definitions cache size allocated routine definition cache size) 100

Actions to be taken

Reduce the value of the pd_routine_def_cache_size operand.

(3) Tuning method (3)

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

Plug-in routine definition cache hits count (# OF PLG-RTN CACHE HIT)

Number of plug-in routine definition acquisition requests (# OF PLG-RTN GET REQ)

Tuning procedure

Obtain the plug-in routine definition cache hits rate with the following formula, and tune it so that the hits rate becomes 100%:

Plug-in routine definition cache hits rate (%) =

(plug-in routine definition cache hits count number of plug-in routine definition acquisition requests) 100

Actions to be taken

Increase the value of the pd_routine_def_cache_size operand.

21.5.7 Tuning the buffer length for registry information

This section explains tuning of the buffer length for registry information (pd_registry_cache_size operand value).

Information to be referenced

See the following system activity statistical information provided by the statistics analysis utility:

Registry cache hits count (# OF REGISTRY CACHE HIT)

Number of registry information acquisition requests (# OF REGISTRY GET REQ)

Tuning procedure

Determine the registry cache hits rate using the following formula, and adjust the buffer length to achieve a hits rate of 100%.

Registry cache hits rate (%) =

(registry cache hits count registry information collection requests count) 100

Actions to be taken

Increase the value of the pd_registry_cache_size operand.

21.6 Tuning the number of processes

This section explains the procedure for tuning the number of server activation processes, which is part of the system activity statistical information provided by the statistics analysis utility. The purpose is to enable the system to activate server processes in an optimal manner by analyzing the number of active processes that were actually executing services and determining whether or not there were any service requests beyond the maximum number of active processes.

The phrase during service execution in this section refers to the following status in a server:

In the front-end server or single-end server, it is the status in which a HiRDB client is allocated to a process by issuing the CONNECT statement. This status remains until the DISCONNECT statement is issued.

In a back-end server or dictionary server, it is during execution of a transaction. This status remains until the transaction is terminated.

Information to be collected

System activity statistical information is collected by the statistics analysis utility.

Organization of this section

21.6.1 Tuning the maximum number of active processes

21.6.2 Tuning the number of resident processes

21.6.3 Tuning the number of processes in asynchronous READ processing

21.6.1 Tuning the maximum number of active processes

This section explains the procedure for tuning the specifications in the following operands that determine the maximum number of active processes:

pd_max_users

pd_max_bes_process

pd_max_dic_process

Information to be referenced

Reference the following statistical information related to system operations:

Number of service requests exceeding the maximum number of active processes (#OF REQ PROCESS OVER MAX)

Number of service processes under service execution (#OF PROCESS ON SERVICE)

Purpose

To make efficient use of memory resources by adjusting the number of active processes actually executing a service so that it is close to the maximum number of active processes specified in these operands.

To prevent service from being denied by increasing the maximum number of active processes (when it turns out that the estimated value is too small).

Evaluating the analysis results

When the operand value is greater than the number of server processes engaged in service execution

It is likely that the operand value can be reduced.

Reduce each server's maximum number of active processes to a value close to the maximum value for the number of server processes during service execution (#OF PROCESS ON SERVICE). The following should be noted in such a case:

Depending on other servers' status, the value should not be reduced to the maximum value for the number of server processes during service execution (#OF PROCESS ON SERVICE). For example, this is true when service requests from multiple front-end servers may concentrate in a specific back-end server or when a particular front-end server in the unit is handling too much processing.

In tuning pd_max_bes_process or pd_max_dic_process, if the specified value is smaller than the value of pd_max_users, the value of pd_max_users is assumed.

When there are service requests exceeding the maximum number of active processes

The operand value should be increased.

In this case, the operand value should be increased such that no service request is denied. The following should be noted for each server with respect to the tuning procedure:

For the front-end server or single server, if a service request received by the server exceeds the maximum number of active processes, the client retries up to the following number of times:
HiRDB client with HiRDB Version 4.0 03-03 or earlier: 100 times
HiRDB client with HiRDB Version 4.0 04-00 or later: 10 times
The number of service requests exceeding the maximum number of active processes (#OF REQ PROCESS OVER MAX) includes the retries count; this must be taken into account when this parameter is tuned.

For a back-end server or dictionary server, a service request is not retried; therefore, the number of service requests exceeding the maximum number of active processes (#OF REQ PROCESS OVER MAX) can be used for tuning.

If the value of pd_max_users is increased and the resulting value exceeds the value of pd_max_bes_process or pd_max_dic_process, the value of pd_max_bes_process or pd_max_dic_process is also assumed to increase up to the value of pd_max_users.

Actions to be taken

For the front-end server or single server, modify the value of pd_max_users.

For a back-end server, modify the value of pd_max_bes_process.

For a dictionary server, modify the value of pd_max_dic_process.

21.6.2 Tuning the number of resident processes

This section explains the procedure for tuning the number of resident processes specified in the pd_process_count operand.

Information to be referenced

Reference the following statistical information related to system operations:

Number of service processes engaged in service execution (#OF PROCESS ON SERVICE)

Purpose

Each server's process activation time is reduced along with the memory resources by specifying as the number of resident processes a value close to the average number of active processes that were actually executing the service.

Evaluating the analysis results

The process activation time can be reduced by making each server's processes resident beforehand; however, if more processes are made resident than necessary, memory resources will not be used efficiently. A reasonable number of resident processes for a server appears to be the average value of the number of service processes under service execution (#OF PROCESS ON SERVICE).

When improving the server's service execution response

If the value of the pd_process_count operand is less than the average value of the number of service processes during service execution (#OF PROCESS ON SERVICE), increase it up to about the average value. If it is increased further, some resident processes may not receive services, resulting in a waste of memory.

When reducing the memory space used by resident server processes

If the value of the pd_process_count operand is greater than the average value of the number of service processes during service execution (#OF PROCESS ON SERVICE), reduce it down to about the average value. If it is decreased further, more requests may be received than the number of resident processes and service execution response may be delayed as much as the process activation time.

Actions to be taken

Modify the value of the pd_process_count operand.

21.6.3 Tuning the number of processes in asynchronous READ processing

This section explains how to tune the number of processes in asynchronous READ processing specified in the pd_max_ard_process operand. When the asynchronous READ facility is used, if the number of processes in asynchronous READ processing is low and the number of SQL statements to which the asynchronous READ facility is applicable is high, processing time can increase due to completion waiting during I/O processing of asynchronous READ processes.

Information to be referenced

Reference the following information in the UAP statistical report (for details about UAP statistical reports, see the manual HiRDB Version 8 UAP Development Guide):

Accumulated synchronization wait time during asynchronous READ (ARWT, ARWTM)

Accumulated database I/O time (IOTIM, IOTIMM)

Average synchronization wait time during asynchronous READ (ARWTA, ARWTMA)

Average synchronization I/O time during asynchronous READ (ARSTA, ARSTMA)

Purpose

The purpose is to determine the number of appropriate processes for asynchronous READ, when the asynchronous READ facility is not effective.

Evaluating the analysis results

Compare with the following times; if step 2 is longer, consider that the asynchronous wait time may be too long:

Accumulated database I/O time (IOTIM, IOTIMM) when the asynchronous READ facility is not used

Total of the average synchronization wait time during asynchronous READ (ARWTA, ARWTMA) and accumulated database I/O time (IOTIM, IOTIMM) when the asynchronous READ facility is used

Compare the following times; if step 2 is longer, consider that the asynchronous wait time may be too long:

Average synchronization I/O time during asynchronous READ (ARSTA, ARSTMA) when the asynchronous READ facility is used

Average synchronization wait time during asynchronous READ (ARWTA, ARWTMA) when the asynchronous READ facility is used

The number of asynchronous READs (AIO-R) can be understood from the statistical information for HiRDB files related to database operations obtained by the statistics analysis utility.

Actions to be taken

If the accumulated synchronization wait time during asynchronous READ (ARWT, ARWTM) or the average synchronization wait time (ARWTA, ARWTMA) during asynchronous READ is long, increase the value of the pd_max_ard_process operand.

However, if the result of checking the number of asynchronous READs (AIO-R) is that the asynchronous READ requests are concentrated in the same RDAREA, increasing the value of this operand will have no effect. In such a case, have the RDAREA be composed of multiple HiRDB files, and place each HiRDB file on a different disk.

For the maximum effective value of the pd_max_ard_process operand, of the RDAREAs for which the number of asynchronous READ (AIO-R) is specified, specify the number that simultaneously executes the prefetch facility. If the number of processes increases, it is necessary to consider the system resources (shared memory and message queues).

If the accumulated synchronization wait time during asynchronous READ (ARWT, ARWTM) or the average synchronization wait time during asynchronous READ (ARWTA, ARWTMA) is short, the asynchronous READ facility cannot provide greater effectiveness.

21.7 Tuning indexes

When a table is updated, its indexes are also updated to maintain database conformity. When an index has been defined, the following items must be evaluated:

Items to be evaluated

The number of times index update processing is executed increases proportionally to the number of indexes defined for the table, resulting in a commensurate increase in the SQL processing time.

When an index is updated, update information is collected in the system log file. Therefore, if the number of indexes increases, the amount of data to be output to the system log file also increases commensurately.

If a shortage occurs in an index page for storing updated key values, an index page split occurs. When index page split occurs, system log information on the split is collected, thereby increasing the amount of data to be stored in the system log file.

Information to be collected

Index statistical information is collected by the statistics analysis utility.

Organization of this section

(1) Splits count (SP_NM)

(1) Splits count (SP_NM)

Purpose

This information is collected in order to evaluate the validity of indexes. Indexes can affect performance adversely in the following case:

If an appropriate free space ratio (PCTFREE) is not specified in the index definition, index page splitting may occur.

In such a case, the index definition should be modified on the basis of the index splits count.

Evaluating the analysis results

If index page splitting occurs frequently, the index may have been expanded by an application that involves mainly data insertion (INSERT) into the table, resulting in frequent index page splits.

If a table is partitioned and index page splitting occurs frequently in a specific RDAREA, update processing may be concentrated on a specific key range due to poor table partitioning.

Actions to be taken

Take one of the following actions:

Increase the free space ratio (PCTFREE) specified in the index definition. If a large amount of data is to be added, use the database load utility.

Delete any unneeded indexes.

If a table is partitioned, check the key range in which the index page splits are concentrated and determine whether or not to partition further.

21.8 Tuning the database

The condition analysis information for each RDAREA is important for tuning the size and orderliness of a database. The condition of a database is analyzed on the basis of the status of the RDAREAs defined in the HiRDB system and the storage status of the tables and indexes.

Information to be collected

Needed information is collected by the database analysis utility.

Organization of this section

(1) Physical analysis information for each RDAREA

(2) Logical analysis information for an RDAREA

(3) Logical analysis information for a table or index

(4) Storage condition analysis for cluster key and clustering data pages

(1) Physical analysis information for each RDAREA

Purpose

Physical analysis information is collected for each RDAREA in order to evaluate the validity of the utilization efficiency and size of the RDAREA with respect to the defined RDAREA size and segment size.

The validity of the utilization efficiency and size of an RDAREA is evaluated by analyzing the storage status of all segments and pages in the RDAREA without taking into account the tables or indexes.

Evaluating the analysis results

When the ratio of used segments is low

Consider that there are many unused segments, and study the following:

If one RDAREA consists of multiple HiRDB files, check the sizes of the files to determine whether or not they are being used.

Check the amount of data to be added in the future, and the table and index definitions.

When the ratio of used segments is high and the ratio of used pages is low

Consider the following factors, and check that the ratio of free pages in the segments is not too large:

Consider whether the RDAREA is being used efficiently.

A common reason for a large ratio of used segments occurs when the segment size specified during RDAREA definition is larger than the volume of the RDAREA, which reduces the number of segments such that the defined tables and indexes use all of the segments.

When the ratio of used segments is high and the ratio of used pages is high

Possible causes are:

There is not enough free space in the RDAREA.

If the ratio of full pages is high, the size may be insufficient.

Actions to be taken

Check the validity of the segment size specified when the RDAREA was created. Determine the validity by checking the numbers of tables or index and data items stored in the RDAREA. If the ratio of full pages is too high or too low, take the following actions:

If the ratio of full pages is too high, expand the RDAREA with the database structure modification utility. Or, move some of the tables or indexes from this RDAREA to another RDAREA.

If the ratio of full pages is too low, the storage efficiency inside the RDAREA may have declined, resulting in fragmented data placement. In this case, use the database reorganization utility to reorganize the table by RDAREA.

In the case of the data dictionary RDAREA, reorganize it with the database reorganization utility with dir specified in the -C option. When the data dictionary RDAREA is reorganized, reorganization of specified data dictionary tables or reorganization of all data dictionary tables can be selected. When specific data dictionary tables are not specified, the entire data dictionary RDAREA is reorganized.

(2) Logical analysis information for an RDAREA

Purpose

Logical analysis information is collected for each RDAREA in order to evaluate the validity of the following:

Whether the size of each RDAREA matches the estimated size

Whether the database should be reorganized

The storage status of all segments and all pages of the tables or indexes in an RDAREA should be analyzed.

Evaluating the analysis results

Table condition analysis information

When the ratio of used segments is high
If there are no unused segments in the relevant RDAREAs, it can be considered that no more data can be inserted. In this case, consider the availability of free space (PCTFREE) for subsequent data additions and updates.

When the ratio of used segments is high, and the ratio of used pages is low
Consider that the ratio of segment free pages specified in the PCTFREE operand is not appropriate. In this case, consider the availability of free space (PCTFREE) for subsequent data additions and updates.

When there are more used pages than the estimated number of pages
If there are VARCHAR, NVARCHAR, or MVARCHAR columns, consider whether the data length of any of these columns has exceeded 255 bytes, and determine whether or not this was considered in the calculation.

When the ratio of full segments and the ratio of full pages are both high
The RDAREA size is inadequate, or disorder has occurred in the data arrangement because the following operations were performed many times:

Updating of null-value data to numeric or character data

Updating of a VARCHAR, NVARCHAR, or MVARCHAR column resulting in a longer column

Updating of column value to the null value, or updating of a VARCHAR, NVARCHAR, or MVARCHAR column resulting in a shorter column

Index condition analysis information

If the number of used segments and used pages is greater than what was calculated in advance, and if the addition of a large number of key values has caused index splitting to occur, consider that the page usage rate may have increased.

Actions to be taken

Either expand the RDAREA or store some of the tables in different RDAREAs (if multiple tables are stored in the RDAREA).

Reorganize the table with the database reorganization utility.

Reevaluate the ratio of free pages in the segment that was specified in the PCTFREE operand during table definition.

Reevaluate the ratio of unused area in a page that was specified in the PCTFREE operand during table definition.

(3) Logical analysis information for a table or index

Purpose

If a table was row-partitioned, check that the table and any index were partitioned properly. This can be done by comparing the amount of output data (numbers of segments and pages) and the estimated amount of data. Also, whether or not the database should be reorganized can be determined by checking the table or index storage condition.

Evaluating the analysis results

Table condition analysis information

When the ratio of full segments or full pages is 80% or higher
If the ratio of used pages is much higher than expected from the estimated number of segments, consider that the table storage status may have become fragmented.

When a table is row-partitioned
If the number of used segments in a specific RDAREA is large, or if the number of rows stored in a specific RDAREA is large, consider that the tables may not be optimally partitioned. Reconsider the table allocation from the estimated data volume. If hash partitioning is already being used, change the hash function. At this time, check the number of rows stored in each RDAREA, and ensure that the rows are stored uniformly.

When the ratio of total unused pages for a table { (total-number-of-pages - total-number-of-used-pages) total-number-of-pages} is less than the ratio of free pages of segments specified in the table definition
Probably, there are too few unused pages due to repeated addition of data.

When there are not enough free pages to add data
Consider that the ratio of free pages for segments is too large, or that data deletion has caused an increase in the number of used free pages.

Index condition analysis information

When the number of pages that store indexes calculated from the number of rows stored in the tables is less than the total number of used pages in the analysis result
Consider that a large number of rows in a specific range were deleted, which caused the related index key values to also be deleted, resulting in used free pages being created in the index pages.

When the used pages are almost all full pages
If this occurs even after the database reorganization utility has been used to reorganize the indexes, consider that the ratio of segment free pages is not optimal or that data additions have used up the free area in the pages.

Actions to be taken

Table condition analysis information

When the ratio of full segments or full pages is high
If new data is to be added in the future, reorganize the corresponding table.

When there are many free pages (unused pages)
Re-examine the ratio of free pages in the segment.

When data deletions have increased the number of used free pages
Reorganize the tables, reorganize the indexes, or release the used free pages.

When there are few unused segments in an RDAREA
Expand the RDAREA.

Index condition analysis information

When there are many used free pages
Reorganize the tables, reorganize the indexes, or release the used free pages.

When more data is expected to be added in the future
If the column data may occur at random for the defined index, redefine the index and specify an appropriate value in the PCTFREE operand.

When the number of used pages is much greater in a specific RDAREA than in other RDAREAs
Reevaluate the table partitioning method. Partition the table so that the amount of partitioned data is the same in each RDAREA.

When there are many used free pages in specific RDAREAs only
Reorganize the tables and indexes in those RDAREAs, or release the used free pages.

(4) Storage condition analysis for cluster key and clustering data pages

Purpose

If a cluster key is defined, check the storage disorder rate, which indicates the disorder of tables and indexes, and the number of keys stored with a duplicate structure.

Cluster key storage condition analysis

The cluster key is searched in the order of key values to display the storage location changes count where the storage location spans multiple pages or segments and the storage disorders count (rate) where of the storage location changes count, the storage sequence is opposite to the ascending order of pages (segments) in units of pages and segments.

Page splitting increases the storage disorder rate.

Clustering data page storage condition analysis

A data page for a table with a cluster key defined is called a clustering data page.

The row data storage location changes count and the storage disorders count (rate) are displayed in units of pages and segments based on the storage location information for the row data in the cluster key when the row data is searched in the order of cluster key values.

If the storage condition becomes poor due to row addition and update processing, the storage disorder rate or the storage location changes count or both increase.

Evaluating the analysis results

Cluster key storage condition analysis information

When there are too many rows for the number of storage keys in an index
The performance of retrieval processing using the index is affected adversely because the key duplication rate is high.

When some keys are stored with duplicate key structure
The performance of retrieval processing using the index is affected adversely because there are (or there were) keys with a high duplication level.

When the storage disorder rate is high
Retrieval performance is affected adversely because there is some disorder in the data page storage sequence.

Clustering data page storage condition analysis information

When the storage disorder rate is high
The performance of accesses in the order of cluster key values is affected adversely because there is some disorder in the data page storage sequence.

When the storage location changes count is greater than the number of segments or pages used in the condition analysis result for each table minus 1
The performance of accesses in the order of cluster key values is affected adversely because there is some disorder in the data page storage sequence.

Actions to be taken

Cluster key storage condition analysis information

When there are too many rows for the number of storage keys in an index
Reevaluate the column structure in the index definition.

When some keys are stored with duplicate key structure
If there is any key with a high duplication level, redefine the table with the cluster key without using those index structure columns that have a high data duplication level. If in the past there was a key with a high duplication level, the duplicate key structure will be eliminated when the table is reorganized or the index is re-created by the database reorganization utility.

When the storage disorder rate is high
Reorganize the table or re-create the index with the database reorganization utility.

Clustering data page storage condition analysis information

When the storage disorder rate is high
Reorganize the table with the database reorganization utility.

The number of storage unit changes is greater than one less than the number of used segments or pages, based on condition analysis of table units.
Reorganize the table with the database reorganization utility.

21.9 Tuning SQLs

This section explains the method of tuning SQLs that require a long time to execute or that have a large number of input/output processes.

Figure 21-2 shows the flow of SQL tuning.

Figure 21-2 SQL tuning flow

Note

The numbers to the left of the process boxes correspond to the paragraph numbers of the explanations on the following pages. For example, step 5 is explained in paragraph (5) below.

Organization of this section

(1) Determining the tuning goals and warning values for the monitored items

(2) Monitoring the usage rates of hardware resources

(3) Monitoring the global buffer pool hit rate

(4) Monitoring application throughput and SQL execution time

(5) Monitoring the table retrieval rate and storage efficiency

(6) Checking the problem

(7) Identifying the HiRDB file system area

(8) Tuning the buffer sector count of a global buffer pool

(9) Checking if the tuning goal has been reached

(10) Identifying SQLs to be tuned

(11) Checking if lock-release wait is occurring for a tuning-target SQL

(12) Tuning the application (tuning locking)

(13) Checking if lock-release wait has been eliminated

(14) Tuning the SQL

(15) Checking if the SQL tuning goal has been reached

(16) Checking if the tuning goal has been reached

(17) Tuning the database

(18) Checking if the tuning goal has been reached

(19) Tuning hardware resources

(1) Determining the tuning goals and warning values for the monitored items

Determine the tuning goals and warning values for the monitored items. Determine the overall system performance (for example, application processing time and transaction commit count), and then set tuning goals accordingly. Also set warning values for the following monitored items:

Hardware resource usage rate
The items to be monitored are the usage rates of hardware resources, such as a server machine's processor and disk volumes.

Global buffer pool status
The item to be monitored is the global buffer pool hit rate.

Application throughput and SQL execution time
The items to be monitored are the transaction commit count and SQL execution time.

(2) Monitoring the usage rates of hardware resources

When the usage rates of hardware resources, such as a server machine's processor and disks, become high, tuning may be necessary. High hardware resource usage rates may cause system throughput to decline. This is the reason why you should monitor the usage rates of hardware resources.

Using the OS's sar command (vmstat command for Linux), for example, you can identify hardware resources that have high usage rates, such as the server machine's processor and disks.

Reference note

Use of JP1/Performance Management - Agent Option for Platform provides you with a facility for checking hardware resource usage rates. For details about JP1/Performance Management - Agent Option for Platform, see the manual For UNIX Systems: Job Management Partner 1/Performance Management - Agent for Platform.

If you are using a Hitachi disk array device (Lightning/Thunder series), you can use HiCommand Tuning Manager - Agent for RAID to collect performance data for the disk array device. For details about HiCommand Tuning Manager - Agent for RAID, see the manual HiCommand Tuning Manager - Agent for RAID.

(3) Monitoring the global buffer pool hit rate

When the global buffer pool hit rate declines, tuning may be necessary. You can execute the pdbufls command to check the global buffer pool hit rate.

Reference note

You can also use JP1/Performance Management - Agent Option for HiRDB to check the global buffer pool hit rate.

(4) Monitoring application throughput and SQL execution time

When application throughput decline, tuning may be necessary. You can collect statistics on system operations by executing the statistics analysis utility (pdstedit command) and then use this information to check application throughput.

You can also use the SQL runtime warning output facility to monitor SQL execution time. For details about the SQL runtime warning output facility, see 8.9 Output of warning information about the time required for SQL execution (SQL runtime warning output facility).

Reference note

You can also use JP1/Performance Management - Agent Option for HiRDB to check application throughput.

(5) Monitoring the table retrieval rate and storage efficiency

When the arrangement of table data becomes fragmented, tuning may be necessary. The KFPH00212-I or KFPH22017-I message is output when the retrieval rate or storage efficiency declines for a table, so you should watch for these messages.

Reference note

HiRDB provides a facility for predicting reorganization time, which predicts the date when a table will need to be reorganized. For details about the facility for predicting reorganization time, see 13.4 Predicting table reorganization time (facility for predicting reorganization time).

You can also use JP1/Performance Management - Agent Option for HiRDB to collect messages related to tables whose data retrieval rates or storage efficiency have declined.

(6) Checking the problem

You should perform tuning when any of the items monitored in steps (2) through (4) exceeds its warning value. If you use OS or HiRDB commands to collect data on the items being monitored, compare the currently collected data with previously collected data to determine whether warning values have been exceeded.

If a hardware resource whose warning value has been exceeded is a processor, use an OS command to determine whether HiRDB processes are using many processors.

If a warning is issued by the SQL runtime warning output facility, go to step (8) and perform tuning.

If the data arrangement becomes fragmented in a table being monitored in step (5) and a message is issued, go to step (17) and perform tuning.

Reference note

If you use JP1/Performance Management - Agent for Platform, JP1/Performance Management - Agent Option for HiRDB, or HiCommand Tuning Manager - Agent Option for RAID, you can monitor items by specifying warning values for the data in the monitored items. When any of these warning values is exceeded, a warning is issued.

(7) Identifying the HiRDB file system area

When a hardware resource or global buffer pool hit rate exceeds its warning value in step (6), you must identify the HiRDB file system area to which the hardware resource is related. To collect information about the relationship between the hardware resource or global buffer pool that exceeded its warning value and a HiRDB file system area, you need to summarize the information between individual layers.

You can check SQL_PHYSICAL_FILES in the dictionary table to identify the relationship between a disk volume and a HiRDB file system area, the relationship between a HiRDB file system area and HiRDB files, and the relationships between HiRDB files and RDAREAs. If you are using the inner replica facility, check the SQL_IOS_GENERATIONS table.

For a HiRDB file system area for work table files, you can determine the name of the HiRDB file system area by checking the value specified in the pdwork operand. You can also check the SQL_TABLES table or SQL_INDEXES table in the dictionary table to identify the relationships between RDAREAs and tables (or indexes).

Reference note

If you use HiRDB CM, you can collect information about the relationships between disk volumes and tables (or indexes).

If you are using a Hitachi disk array device (Lightning/Thunder Series), you can use HiCommand Tuning Manager - Agent for RAID Map to collect information about the relationships between ports and logical devices in the disk array device. For details about HiCommand Tuning Manager - Agent for RAID Map, see the manual HiCommand Tuning Manager - Agent for RAID Map.

(8) Tuning the buffer sector count of a global buffer pool

If the buffer sector count of a global buffer pool is small, system throughput may have declined or hardware resource usage rates may have increased.

Tune the buffer sector count of the global buffer pool that is related to the HiRDB file system area identified in step (7). If a reduced global buffer pool hit rate necessitated tuning, tune the buffer sector count of the applicable global buffer pool. If application throughput or SQL execution time necessitated tuning, tune the buffer sector counts of all global buffer pools.

For details about the buffer sector count of a global buffer pool, see the manual HiRDB Version 8 Installation and Design Guide. For details about how to tune global buffer pools, see 21.1 Tuning global buffer pools.

(9) Checking if the tuning goal has been reached

If the tuning goal has been reached by the tuning performed in step (8), terminate tuning. If the tuning goal has not been reached, proceed to the next step and continue tuning.

(10) Identifying SQLs to be tuned

Identify SQLs to be tuned. Also establish tuning goals for the SQLs.

Use the pdobils command to collect statistics on an SQL object buffer, and make the SQLs listed below the tuning targets. When you collect statistics on an SQL object buffer, you can check each SQL's execution time, number of executions, and number of inputs/outputs.

Set each SQL's target execution time, target number of executions, and target number of inputs/outputs as the tuning goals.

SQL with the longest execution time

SQL with the largest number of executions

SQL with the largest number of inputs/outputs

SQL with the largest number of real READ counts for data pages, index pages, and directory pages; SQL with the largest number of real READ counts for LOB column data pages; or SQL with the largest number of real READ counts for list pages

SQL with a real WRITE count for data pages, index pages, and directory pages; SQL with a real WRITE count for LOB column data pages; or SQL with a real WRITE count for list pages

SQL with the largest number of updates for data pages, index pages, and directory pages; SQL with the largest number of updates for LOB column data pages; or SQL with the largest number of updates for list pages

SQL with the largest number of READ or WRITE counts for work table files

(11) Checking if lock-release wait is occurring for a tuning-target SQL

Execute the statistics analysis utility (pdstedit command) to collect statistics on system operations and check whether lock-release wait has occurred. If it has, collect the server's lock status regularly, and check whether lock-release wait is occurring. If an applicable SQL is using a resource for which there is a lock-release wait, it is safe to assume that lock-release wait is occurring for that tuning-target SQL.

If there is a lock-release wait, release the lock by performing application tuning (lock tuning) in step (12). If no lock-release wait has occurred, tune the SQL in step (14).

(12) Tuning the application (tuning locking)

If lock-release wait is occurring for a tuning-target SQL, tune the application (tune the locking). For details about application tuning (tuning locking), see Lock in the manual HiRDB Version 8 UAP Development Guide.

(13) Checking if lock-release wait has been eliminated

Check if application tuning has eliminated the lock-release wait that has occurred for the tuning-target SQL. For the checking procedure, see step (11).

If lock-release wait has been eliminated, go to step (16) and check if the tuning goal has been achieved. If lock-release wait has not been eliminated, go to step (14) and tune the SQL.

(14) Tuning the SQL

Table 21-1 shows the methods for tuning an SQL.

Table 21-1 SQL tuning methods

SQL characteristics | Assumed cause | Details | Corrective action
The real READ count for data pages, index pages, and directory pages or the total number of referencing operations is large (the number of inputs/outputs is greater than originally designed, or execution time is longer than originally designed) | Unsuitable access path to the table | Table scan is being executed when the table search range is wide. | See the concept of tuning with the access path display utility in the manual HiRDB Version 8 Command Reference.
Table scan is being executed in a search for which a narrowing condition is specified (an unsuitable index is being used).
Index search range is wide (search is over an unnecessarily wide range).
Index search range has not been narrowed because there is no search condition, or the search condition is invalid.
A search with multiple predicates specified using AND is being performed.
Unsuitable joining method | Index of a join key of an inner table is unsuitable for nest-loop-join.
Index being used for outer join is unsuitable.
BROADCAST or KEY RANGE PARTIAL BROAD CAST transmission is specified as the transmission method for nest-loop-join (for a HiRDB/Parallel Server).
READ or WRITE count exists for work table files (execution time is longer than originally designed) | Unsuitable joining method | Packet partitioning has been executed multiple times because of a large number of hash-joined inner tables or subquery searches. | See the preparations for executing hash join or subquery hash in the HiRDB Version 8 UAP Development Guide.
A large volume of data is sorted in sort-merge join. | See the concept of tuning with the access path display utility in the manual HiRDB Version 8 Command Reference.
Cross-join is executed.
Sorting was executed. | Sorting is executed for ORDER BY processing.

(15) Checking if the SQL tuning goal has been reached

Check if the tuning goal has been reached for the tuning-target SQL. Collect statistics on the SQL object buffer, and check whether the SQL execution time, execution count, and input/output count are within the target ranges. If the goals have not been reached, return to step (14) and tune the SQL again.

(16) Checking if the tuning goal has been reached

Check if the tuning goal has been reached. If it has, terminate tuning. If the tuning goal has not been reached, return to step (10), identify the tuning-target SQL again, and tune it.

If SQL tuning or application tuning has not produced the desired effects, go to step (17) and tune the database.

(17) Tuning the database

If SQL tuning or application tuning does not produce the desired effects, tune the database. Tune the following items:

Buffer sector count of a global buffer pool
For details about the sector count of a global buffer pool, see the manual HiRDB Version 8 Installation and Design Guide. For details about tuning global buffer pools, see 21.1 Tuning global buffer pools.

Work table buffer size
For details about work table buffer size, see the preparations for executing hash join or subquery hash in the manual HiRDB Version 8 UAP Development Guide.

Table row partitioning
For details about table row partitioning, see the HiRDB Version 8 Installation and Design Guide.

Data rearrangement
For details about data rearrangement, see 21.8 Tuning the database.

Deferred write processing
For details about deferred write processing, see 21.2 Tuning deferred write processing.

(18) Checking if the tuning goal has been reached

Check if tuning the database has achieved the tuning goal. If so, terminate tuning. If the tuning goal has not been reached, go to step (10), identify the tuning-target SQL again, and tune it.

If database tuning has not produced the desired effects, go to the next step and tune hardware resources.

(19) Tuning hardware resources

Add or augment hardware resources. Using the OS's sar command (vmstat command for Linux), for example, determine processor usage and disk usage. Add or augment the hardware resource that has the highest usage.

If the hardware resource with the highest usage is a processor, switching to a higher-performance processor may reduce processing time. If the hardware resource with the highest usage is a disk, switching to a higher-performance disk or adding disks (increasing the spindle count) in the case of a disk array device may reduce input/output time.

Reference note

You can also use JP1/Performance Management - Agent Option for Platform to check processor and disk volume usage.

If you are using a Hitachi disk array device (Lightning/Thunder Series), you can use HiCommand Tuning Manager - Agent for RAID to collect performance data for the disk array device.

21.10 Tuning the system's internal processing

In some cases, you can specify an operand to facilitate the system's internal processing.

These operands are described in this section. For details about each operand, see the section on each operand in the manual HiRDB Version 8 System Definition.

Organization of this section

(1) Operands for increasing performance, even if the machine load increases

(2) Operands for specifying performance during concurrent transaction execution

(1) Operands for increasing performance, even if the machine load increases

The operands described here are used to select among methods that use one of the following two general approaches:

An approach that places a high load on the machine, but provides high performance (for a machine capable of high performance). If the machine's performance capacity is low, CPU usage may approach 100%, posing the risk of degraded OS performance.

An approach that places a low workload on the machine, but can ensure standard performance. Stable performance can be achieved with any type of machine.

To minimize risk, the default values for many of these operands are set to use a method that adheres to approach 2.

If your machine's performance capacity is high, you may be able to improve performance (while also increasing the load on the machine) by changing the values specified for these operands. However, if unsuitable values are specified, the CPU usage may approach 100%, posing the risk of degraded OS performance. Thus, you should be careful about changing the specification values for these operands.

Note that these operands are not described in detail here because their specification values are related to the system's complex internal processing. You should refer to the specification guidelines for each operand that are provided in the manual HiRDB Version 8 System Definition.

Table 21-2 lists the operands for tuning the system's internal processing.

Table 21-2 Operands for tuning the system's internal processing

Specification item | Specification condition | Operand
Lock-release detection method | For general UAP execution | pd_lck_release_detect
Lock-release detection interval | pd_lck_release_detect_interval
Processing request queuing method | pd_server_entry_queue
Inter-thread lock sleep method | pd_thdlock_sleep_func
Inter-thread lock sleep time | pd_thdlock_retry_time
Inter-thread spin lock spin count | pd_thdspnlk_spn_count
Global buffer lock-release detection interval | Global buffer lock-release-wait has occurred. | pd_dbbuff_wait_interval
Spin count during global buffer lock release detection | pd_dbbuff_wait_spn_count
Global buffer lock-release detection method | Global buffer is being used. | pd_dbbuff_lock_release_detect
Spin count during global buffer lock-acquisition-wait | pd_dbbuff_lock_spn_count
Interval during global buffer lock-acquisition-wait | pd_dbbuff_lock_interval

(2) Operands for specifying performance during concurrent transaction execution

Table 21-3 shows the operands for specifying performance during concurrent transaction execution.

Table 21-3 Operands for specifying performance during concurrent transaction execution

Specification item | Specification condition | Operand
Inter-thread lock release notification method | When the execution time must be the same for all transactions that are being executed concurrently. | pd_thdlock_wakeup_lock
Inter-thread lock release detection interval | When the execution times may differ to some extent among the transactions that are being executed concurrently. | pd_thdlock_pipe_retry_interval

22. Using the Security Audit Facility

This chapter explains the environmental setup and operating procedures for the security audit facility.

Organization of this chapter

22.1 Overview of the security audit facility

22.2 Information output to an audit trail file

22.3 Audit trail output patterns

22.4 Environment settings

22.5 Operating procedure

22.6 Operation of audit trail files

22.7 Recording data in the audit trail table

22.8 Audit trail table columns

22.9 Narrowing the audit trails

22.10 Audit trail file error handling

22.11 Linkage with other facilities

22.12 Audit trail record items (during privilege checking)

22.13 Audit trail record items (at event termination)

22.14 Audit trail output destination unit during utility execution (HiRDB/Parallel Server only)

22.15 Notes on version upgrading

22.1 Overview of the security audit facility

This section provides an overview of the security audit facility. The following topics are covered:

About the security audit facility

Triggers for collecting audit trails

Examples of audit trail collection

Information collected in an audit trail

Accessing an audit trail

System configuration requirements

Audited events

Organization of this section

22.1.1 About the security audit facility

22.1.2 Triggers for collecting audit trails

22.1.3 Examples of audit trail collection

22.1.4 Information collected in an audit trail

22.1.5 Accessing an audit trail

22.1.6 System configuration requirements

22.1.7 Audited events

22.1.1 About the security audit facility

HiRDB security is protected by privileges. The information that can be referenced, the information that can be updated, and the objects that can be manipulated (tables, indexes, etc.) are restricted by privileges. HiRDB can keep track of various operations on the database in order to make it possible to determine whether or not the privileges are operating appropriately. This facility is called the security audit facility, and the record of actions that is output is called an audit trail. The audit trail that is output can be examined to check for inappropriate accesses. This check can be performed by the user who holds the audit privilege (called the auditor). Figure 22-1 outlines the security audit facility.

Figure 22-1 Outline of the security audit facility

The audit trail collects information on who performed what action on what using what privilege. The auditor can specify the actions that are to be collected in the audit trail using the CREATE AUDIT statement. An audit trail is collected whenever an action is performed for which collection of an audit trail has been specified.

Reference note

The security audit facility is not intended to strengthen security. Its purpose is to output a record of database accesses for checking that privilege operations are functioning appropriately.

22.1.2 Triggers for collecting audit trails

HiRDB collects audit trails at the following triggers:

At the time of privilege checking for executing a command or SQL statement

When an event terminates

HiRDB does not collect an audit trail when an SQL syntax error occurs or when an error occurs as a result of a mistake in entering a command.

Organization of this subsection

(1) Audit trail collection during privilege checking

(2) Audit trail collection at event termination

(1) Audit trail collection during privilege checking

A single audit trail is collected for each privilege check. Sometimes, another SQL is executed as an extension to an executed SQL. In this case, HiRDB also collects an audit trail during privilege checking for the SQL that is executed as an extension to the original SQL. For details, see 22.12 Audit trail record items (during privilege checking).

(2) Audit trail collection at event termination

When an event terminates, HiRDB collects an audit trail for each object that was the target of the event. However, for a consecutive certification failure account lock state that is released because the account lock period has passed, the audit trail is collected not when the account lock period has passed, but when the next event occurs after the passage of the account lock period.

When CONNECT is executed

When DROP CONNECTION SECURITY is executed

When the pdacunlck command is executed

For details about the audit trail output patterns at event termination, see 22.3 Audit trail output patterns.

For details about the audit trails that are output at event termination, see 22.13 Audit trail record items (at event termination).

22.1.3 Examples of audit trail collection

Examples of audit trail collection are shown below.

Example 1: Collect an audit trail of table accesses

When a table is accessed, the table's access privilege (SELECT privilege) is used, and an audit trail is collected.

Table search contents (SQL specification)
Audit trail contents

Executor
Privilege used
Manipulated object
Manipulated object's name
Action

A user (USR1) issues the following SELECT statement:
SELECT C1 FROM USR1.T1
Privilege
USR1
Table access (SELECT privilege)
Table
USR1.T1
Accesses a table (SELECT)

Termination
USR1

Table
USR1.T1
Accesses a table (SELECT)

A user (USR2) issues the following SELECT statement:
SELECT T1.C1,T2.C1
FROM USR1.T1 T1,USR2.T2 T2
WHERE T1.C1=T2.C1
Privilege
USR2
Table access (SELECT privilege)
Table
USR1.T1
Accesses a table (SELECT)

USR2
Table access (SELECT privilege)
Table
USR2.T2
Accesses a table (SELECT)

Termination
USR2

Table
USR1.T1
Accesses a table (SELECT)

USR2

Table
USR2.T2
Accesses a table (SELECT)

Legend:

Privilege: Audit trail collected during privilege checking

Termination: Audit trail collected at event termination

: Not applicable

Example 2: Collect an audit trail of table definitions and deletions

When a table is defined or deleted, schema owner privilege, table owner privilege, and RDAREA usage privilege are used, and an audit trail is collected.

Table search contents (SQL specification)
Audit trail contents

Executor
Privilege used
Manipulated object
Manipulated object's name
Action

A user (USR1) issues the following CREATE TABLE statement:
CREATE TABLE
T1(C1 INT) IN RDAREA1
Privilege
USR1
RDAREA usage privilege
RDAREA
RDAREA1
Creates a definition

USR1
Owner
Schema
USR1
Creates a definition

USR1
Owner
Table
USR1.T1
Creates a definition

Termination
USR1

Table
USR1.T1
Creates a definition

A user (USR2) issues the following DROP TABLE statement:
DROP TABLE T1
Privilege
USR2
Owner
Table
USR2.T1
Deletes a definition

Termination
USR2

Table
USR2.T1
Deletes a definition

Legend:

Privilege: Audit trail collected during privilege checking

Termination: Audit trail collected at event termination

: Not applicable

22.1.4 Information collected in an audit trail

For the information collected in audit trails, see the following sections:

22.2 Information output to an audit trail file

22.8 Audit trail table columns

22.12 Audit trail record items (during privilege checking)

22.13 Audit trail record items (at event termination)

22.1.5 Accessing an audit trail

The audit trail is output to an audit trail file. The data in an audit trail file can be accessed using SQL after the data has been loaded into the audit trail table by the database load utility (pdload command). The auditor can reference an audit trail table (but cannot modify it). A user other than the auditor can access (but cannot modify) an audit trail table if the auditor has granted access privilege to that user. Figure 22-2 shows how to access the audit trail.

Figure 22-2 Accessing the audit trail

Explanation

When audited events are executed, an audit trail is output to an audit trail file. An audit trail file is created in a HiRDB file system area for audit trail files. For details about audited events, see 22.1.7 Audited events.

The audit trail output to an audit trail file becomes the input information to the database load utility (pdload command) for data loading to record the data in the audit trail table. For details, see 22.7 Recording data in the audit trail table.

The auditor uses the audit trail table to inspect the audit. For details about the audit trail table, see 22.8 Audit trail table columns.

Table 22-1 shows the differences between an audit trail table and other tables.

Table 22-1 Differences between an audit trail table and other tables

Action on table | Audit trail table | Other tables
Defining a table | HiRDB administrator uses the pdmod command to define the table. | Each user uses CREATE TABLE to define the table.
Deleting a table | Only the auditor can delete the table. Users with DBA privilege cannot delete the table. | Table owner deletes the table. Users with DBA privilege can also delete the table.
Modifying the table definition | Cannot be done. | Table owner can modify the table.
Granting access privileges to other users | Only the SELECT privilege can be granted. | SELECT, INSERT, UPDATE, and DELETE privileges can all be granted.
Loading data into a table | Can be executed only by the auditor. | Can be executed by the table owner. Can also be executed by other users who are granted access privilege.
Reorganizing a table | Can be executed only by the auditor. | Can be executed by users with DBA privilege. Can also be executed by other users who are granted access privilege.
Usage privilege to RDAREAs for storing the table | Only the auditor has the usage privilege. | Table owner has the usage privilege. Can also be used by other users who are granted the privilege.
Row-partitioning of a table | N | Y
Accessing a table | SELECT | Y | Y
INSERT | N | Y
UPDATE | N | Y
DELETE | Can be performed only by the auditor. | Y
PURGE | Can be performed only by the auditor. | Y

Legend:

Y: Can be executed.

N: Cannot be executed.

22.1.6 System configuration requirements

The following applies to use of the security audit facility:

HiRDB/Single Server
The security audit facility cannot be used with utility special units.

HiRDB/Parallel Server
The security audit facility cannot be used with a unit that does not have a server (including a unit the contains only the system manager). If the security audit facility is to be used in such a situation, provide a front-end server, dictionary server, or back-end server in each unit.

22.1.7 Audited events

Actions that are collected in the audit trail are called audit events. Table 22-2 lists the audit events.

When the security audit facility is enabled, audit trails are output automatically by the system for some events. For other events, the auditor can select whether or not audit trails are to be collected.

Table 22-2 Audit events

Event type
Explanation and audited events
Selectability

System administrator security events

Security events performed by the HiRDB administrator or users with DBA privilege are audited.

Modifications of the setting values of the connection security facility are audited.

Security events performed automatically by the system are audited.

An audit trail is output when the following events occur:

HiRDB startup (pdstart command)¹

HiRDB termination (pdstop command)1,2

Auditor registration (pdmod command)

Audit trail table creation (pdmod command)

Audit trail file deletion (pdaudrm command)³

Audit trail collection startup⁵

Audit trail collection termination⁶

Start of audit trail file overwriting

Transition to consecutive certification failure account lock state

Release of consecutive certification failure account lock state
Applicable in the following cases:
During CONNECT after the account lock period has passed
During execution of DROP CONNECTION SECURITY
During execution of the pdacunlck command

Transition to password-invalid account lock state

Release of password-invalid account lock state

Modification of a setting value of the connection security facility:
Permitted number of consecutive certification failures
Account lock period
Items to be set up for character string restrictions for passwords (including an advance check)

Execution of the pdacnlck command

N (an audit trail is always output).

Auditor security events
These are audits of events performed by the auditor. An audit trail is output when the following events occur:

Data loading into an audit trail table (pdload command)

Swapping of audit trail files (pdaudswap command)

Defining events to be audited (CREATE AUDIT)⁴

Deleting events to be audited (DROP AUDIT)⁴

Changing the auditor password (GRANT AUDIT)⁴

N (an audit trail is always output).

Session security events
These are audits of user authentication by authorization identifier and password.
An audit trail is output when the following events occur:

Connection to HiRDB (CONNECT statement)

User change (SET SESSION AUTHORIZATION statement)

Y

Privilege management events
These are audits of addition or deletion of user privileges. An audit trail is output when the following events occur:

User privilege addition (GRANT statement)

User privilege deletion (REVOKE statement)

Y⁷

Object definition events
These are audits of object definitions, deletions, or modifications. An audit trail is output when the following events occur:

Object definition; this applies to the following SQL statements:
CREATE ALIAS
CREATE FOREIGN INDEX
CREATE FOREIGN TABLE
CREATE FUNCTION
CREATE INDEX
CREATE PROCEDURE
CREATE PUBLIC VIEW
CREATE SCHEMA
CREATE SERVER
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
CREATE USER MAPPING
CREATE VIEW

Object deletion; this applies to the following SQL statements:
DROP ALIAS
DROP DATA TYPE
DROP FOREIGN INDEX
DROP FOREIGN TABLE
DROP FUNCTION
DROP INDEX
DROP PROCEDURE
DROP PUBLIC VIEW
DROP SCHEMA
DROP SERVER
DROP TABLE
DROP TRIGGER
DROP USER MAPPING
DROP VIEW

Object modification; this applies to the following SQL statements:
ALTER PROCEDURE
ALTER ROUTINE
ALTER TABLE
ALTER TRIGGER
COMMENT

Y⁷

Object manipulation events
These are audits of object manipulations. An audit trail is output when the following events occur:

Table reference (SELECT statement)

Table row insertion (INSERT statement)

Table row update (UPDATE statement)

Table row deletion (DELETE statement)

Table deletion of all rows (PURGE TABLE statement)

Stored procedure execution (CALL statement)

Table lock control (LOCK TABLE statement)

List creation (ASSIGN LIST statement)

Y⁷

Utility operation event
Security events related to object operations performed by a utility or command are audited. An audit trail is output when any of the following is executed:

Database load utility (pdload command)
Target object: TABLE

pddefrev command
Target objects: ALIAS, PROCEDURE, TABLE, TRIGGER, and VIEW

Database reorganization utility (pdrorg command)
Target object: TABLE

Dictionary import/export utility (pdexp command)
Target objects: ALIAS, PROCEDURE, TABLE, TRIGGER, and VIEW

Integrity check utility (pdconstck command):
TABLE

Y7, 8

Legend:

Y: Can be selected

N: Cannot be selected

¹ HiRDB/Parallel Server server unit startup and termination are not regarded as audit events.

² Normal termination and planned termination are regarded audit events. Forced termination and abnormal termination are not regarded as audit events. To audit forced termination or abnormal termination, use the messages output by HiRDB or the OS.

The following termination commands are not audited:

pdstop -f

pdstop -f -q

pdstop -f -x host-name

pdstop -f -u unit-identifier

pdstop -f -s server-name

pdstop -f -u unit-identifier -s server-name

pdstop -z

pdstop -z -q

pdstop -z -c

pdstop -z -s server-name

³ Creation of an audit trail file is not regarded as an audit event. To audit creation of audit trail files, use the OS's audit facility.

⁴ An output trail is also output when the database definition utility (pddef command) or the interactive SQL execution utility (pdsql command) is executed.

⁵ An audit trail is output when an audit trail is to be collected because the pdaudbegin command is executed, or when HiRDB is started.

⁶ An audit trail is output when HiRDB is terminated normally or by a planned termination when the pdaudend command is executed or an audit trail is collected.

⁷ If the event-target object in a privilege control event, object definition event, object operation event, or utility operation event is an audit trail table, a view table that uses an audit trail as the base table, or a list that uses an audit trail as the base table, an audit trail is output unconditionally when the event terminates. You can select whether to output an audit trail during privilege checking. However, because the database load utility (pdload command) executed for an audit trail table is included as an auditor security event, the audit trail at event termination and during privilege checking is output unconditionally.

⁸ When the database reorganization utility (pdrorg command) is used to reload a dictionary table, an audit trail is output unconditionally.

22.2 Information output to an audit trail file

Table 22-3 lists the information output to an audit trail file.

Table 22-3 Information output to an audit trail file

Collected information
Explanation

User identifier
Authorization identifier of user who executed the audited event

Event execution date
Date the event was executed

Event execution time
Time the event was executed

Event execution duration
Amount of time required to execute the event (in microseconds)

Event type
Type of event (see Table 22-16 Event types and subtypes)

Event subtype
Event's subtype (see Table 22-16 Event types and subtypes)

Event success or failure
Result of event execution (whether or not privilege checking was successful)

Privilege used
Privilege used when the event was executed

UAP name
UAP name specified in client environment definition's PDCLTAPNAME operand

Service name
Name of the service requested by the UAP that issued the event. If it is an OpenTP1 SUP (service use program), this is the name of the service requested of the SPP (service provider program); if it is TP1/Message Control, this is the name of the service requested of the MHP (message processing program).

IP address
IP address of the client that executed the UAP that issued the event*

Process number
Process ID of the UAP that issued the event*

Thread number
Thread ID of the UAP that issued the event*

Host name
Target host name of the UAP connection that issued the event

Unit identifier
Target unit identifier of the UAP connection that issued the event

Server name
Target front-end server name or single-server name of the UAP connection that issued the event

Connect number
Connect number of the user that issued the event

SQL number
Event SQL number

Object owner name
Owner name of the object that is the target of the event privilege check

Object name
Object name of the object that is the target of the event privilege check

Object type
Object type of the object that is the target of the event privilege check

Added, deleted, or changed privilege
Privilege added, deleted, or changed due to the event

One of the following is acquired:

User identifier of user who granted, deleted, or changed a privilege

User identifier associated with the event target

Identifier of the user whose privilege was granted, deleted, or changed by the event

Authorization identifier that became the event target

Security audit facility operand values
Values of operands related to security audit facility (values applicable at time of HiRDB startup)

Audit trail type
Indicator of privilege checking or event termination

SQL code or termination code
Termination code of the SQL, utility, or command

Audit trail file name at swapping source
Audit trail file name at the swapping source when swapping occurs

Audit trail file name at swapping destination
Audit trail file name at the swapping destination when swapping occurs

Type of setting change for connection security facility
Type of setting change for the connection security facility (the change type is set also when a password is changed)

Operand value related to connection security facility (before change)
Operand value related to the connection security facility before the change

Operand value related to connection security facility (after change)
Operand value related to the connection security facility after the change

Audit trail table option
Flag when the event option target is an audit trail table, a view table that uses an audit trail as the base table, or a list that uses an audit trail

Number of accesses
Number of rows searched, inserted, updated, and deleted in an object (base table, view table, foreign table, table alias, or list) by the event

Note

The information that is collected depends on the event. For a list of the information that is collected for each event, see 22.12 Audit trail record items (during privilege checking) and 22.13 Audit trail record items (at event termination).

* When introducing applications under Open/TP1 or when introducing web servers and other products, information on the application connected to HiRDB is collected, rather than information on the application executed by the end user.

22.3 Audit trail output patterns

This section explains the audit trail output patterns.

Organization of this section

22.3.1 Output patterns during privilege checking

22.3.2 Output patterns at event termination

22.3.3 Relationships among audit trails

22.3.1 Output patterns during privilege checking

A single audit trail is collected during a single privilege check. However, in the exceptional cases shown in Table 22-4, multiple audit trails are collected during a single privilege check.

Table 22-4 Event execution units and audit trail record output units

Events
Execution unit
Target output units
Number of output records

GRANT, REVOKE
User
Users
Number of target users

Group
Groups
Number of target groups

Role
Roles
Number of target roles

CREATE CONNECTION SECURITY,
DROP CONNECTION SECURITY
Setting value of the connection security facility
Setting values of the connection security facility
Number of setting values of the connection security facility

When multiple privilege checks occur in a single event, audit trails are output as follows:

When any one of multiple privileges is required
An audit trail is output during one of the privilege checks.

Example

To unload someone else's table, you must have either DBA privilege or SELECT privilege.

Whether the DBA privilege check or the SELECT privilege check was successful is output in the audit trail.

When all of multiple privileges are required
Audit trails are output during all the privilege checks.

Example

To reorganize someone else's table, you must have the INSERT, DELETE, and SELECT privileges.

If the INSERT, DELETE, and SELECT privilege checks are all successful, audit trails are output for all three checks. If an error occurs in midstream, audit trails are output for the successful privilege checks. Failure trails are output for the unsuccessful privilege checks.

22.3.2 Output patterns at event termination

Multiple audit trails are collected for each event (one audit trail for each event-target object). As a rule, the same contents are output for all items, except for the operation-target object information column of the audit trail table. However, if the result of an event is different for each operation target, such as a utility, different contents are output for each termination code. Examples of audit trail output patterns are described below.

Organization of this subsection

(1) Multiple target objects or target users

(2) SQL that runs internally

(3) Dynamic SQL

(1) Multiple target objects or target users

(a) Multiple target objects

For example, when SELECT * FROM "T1","T2" is executed, two audit trail lines are output, one for object T1 and one for T2, as shown below. In this case, the same termination code is set for both.

... | Event subtype | ... | Object name | ... | Termination code | ...
... | SEL | ... | T1 | ... | XXX | ...
... | SEL | ... | T2 | ... | XXX | ...

An event, such as routine re-creation or the utility for reorganizing a database in units of schemas, may succeed or fail depending on the object. In this case, a different termination code is output for each object. Table 22-5 lists events that sometimes have multiple target objects.

Table 22-5 Events that sometimes have multiple target objects (event execution units and audit trail record output units)

Events
Execution unit
Target output units
Number of output records
SQL code or termination code

GRANT,
REVOKE
User
Users
Number of target users
Same value for all event-target objects

Group
Groups
Number of target groups

Role
Roles
Number of target roles

CREATE CONNECTION SECURITY,
DROP CONNECTION SECURITY
Setting value of the connection security facility
Setting values of the connection security facility
Number of setting values of the connection security facility

Data manipulation SQL
Base table
Base tables
Number of target base tables

View table
View tables
Number of target view tables

Table alias
Table aliases
Number of target table aliases

Foreign table
Foreign tables
Number of target foreign tables

ALTER ROUTINE,
ALTER PROCEDURE,
ALTER TRIGGER
Multiple routines or triggers¹
Procedures, functions, or triggers
One for each target routine
Different value for each event-target object

pdexp,
pddefrev
Base table
Base tables
Number of target base tables

Viewed table
View tables
Number of target view tables

Table alias
Table aliases
Number of target table aliases

Stored procedure
Stored procedures
Number of target stored procedures

Trigger
Triggers
Number of target trigger count

pdrorg
Schema,² base table, or index
Base tables
Number of target base tables

pdaudbegin,
pdaudend
Unit
Units
Number of target units

¹ If routine information cannot be collected, NULL is entered for the object information and only a single audit trail line is output.

² In the case of reorganizing in units of schemas, if the table information in the schema cannot be collected, schema information is entered for the object information, and only a single audit trail line is output.

(b) Subqueries

For example, when UPDATE "T1" SET "C1" = (SELECT "C1" FROM "T2" WHERE CODE = '01') WHERE CODE = '01' is executed, information on the accessed objects is output as in (a) above. In this case, audit trails of the actions performed on the objects are output for the event type and subtypes as shown below. The same value is entered for the SQL code in the audit trail at each event's termination.

... | Event subtype | ... | Object name | ... | Termination code | ...
... | UPD | ... | T1 | ... | XXX | ...
... | SEL | ... | T2 | ... | XXX | ...

(2) SQL that runs internally

In some cases, another SQL is executed as an extension of an executed SQL. If an SQL that is executed as an extension when an event is executed is defined as the audit target, information is collected on the target object of the SQL that is executed as an extension, or on the user. In this case, the event type and subtype of the SQL that is executed as an extension are entered as the event type and subtype of the object or user. Furthermore, for all objects, the same value is entered for the SQL code of each audit trail.

For example, if a table is deleted as an extension of DROP SCHEMA, object information on the table is output as the accessed object, separately from schema information. If the deletion process is terminated by an error, an audit trail is output for each user and each object that has been accessed up to the time of the error.

In procedures and triggers, an SQL is executed automatically as an extension of another SQL. In this case, an event termination audit trail is output for each SQL that is executed as an extension. In the case of a trigger, because the executor switches temporarily to the trigger owner, the trigger owner is entered as the event executor. In the case of a procedure, an event termination audit trail is also output when a CALL statement is terminated. If the procedure is nested, an event termination audit trail is output for each CALL statement. Table 22-6 shows audit trail record output units for trigger and procedure execution.

Table 22-6 Audit trail record output units for trigger and procedure execution

Type | Event executor (authorization identifier value) | Audit trail record output unit
Trigger | User trigger | Trigger owner | SQL units in the trigger
System trigger (internal trigger of a referential constraint, etc.) | Trigger owner | SQL units in the system trigger
Procedure | Procedure executor | SQL units in the procedure + CALL statement

If an error occurs in an SQL in a trigger or procedure, the same SQL record is output as the event results of the SQL at that point in time, the event results of the SQL that became the trigger, and the results of the CALL statement. Table 22-7 shows the error locations in a trigger and the audit trail (SQL code) details. Table 22-8 shows the error locations in a procedure and the audit trail (SQL code) details.

Table 22-7 Error locations in a trigger and audit trail (SQL code) details

BEFORE trigger SQL result
[1]
Trigger SQL result
[2]
AFTER trigger SQL result
[3]
Audit trail (SQL code) details

Audit trail of [1]
Audit trail of [2]
Audit trail of [3]

Error

SQL record of [1]
SQL record of [1]
N

Normal
Error

SQL record of [2]
N

Normal
Error
SQL record of [3]
SQL record of [3]

Normal
0
0
0

Legend:

: Not applicable

N: No audit trail (SQL code) is output.

Table 22-8 Error locations in a procedure and audit trail (SQL code) details

Nesting? | Details of event for which audit trail is to be collected | Audit trail (SQL code) details
[1] | [2] | [3] | [4] | [5] | Audit trail of [1] | Audit trail of [2] | Audit trail of [3] | Audit trail of [4] | Audit trail of [5]
No | E |  |  |  | E | SQL record of [1] | N | N | N | SQL record of [1]
Nrm |  |  |  | E | 0 | N | N | N | SQL record of [5]
Nrm | 0 | N | N | N | 0
Yes | E |  |  |  | E | SQL record of [1] | N | N | N | SQL record of [1]
Nrm | E | E |  | E | 0 | SQL record of [2] | SQL record of [2] | N | SQL record of [2]
Nrm | E |  | E | 0 | 0 | SQL record of [3] | N | SQL record of [3]
Nrm | E | E | 0 | 0 | 0 | SQL record of [4] | SQL record of [4]
Nrm | E | 0 | 0 | 0 | 0 | SQL record of [5]
Nrm | 0 | 0 | 0 | 0 | 0

Legend:

: Not applicable

E: Error

Nrm: Normal

N: No audit trail (SQL code) is output.

[1]: Result of SQL in a procedure before nesting

[2]: Result of SQL in a procedure after nesting

[3]: Result of a nested CALL statement

[4]: Result of SQL in a procedure before nesting

[5]: Result of a CALL statement

(3) Dynamic SQL

In the case of a dynamic SQL, the entire process from PREPARE to execution is treated as a single SQL, and an event termination audit trail is output for that unit. An event termination audit trail during execution is output when OPEN, CLOSE or EXECUTE is completed. Figure 22-3 shows the flow of a dynamic SQL depending on the type of data manipulation SQL.

Figure 22-3 Flow of a dynamic SQL depending on the type of data manipulation SQL

Explanation

The shaded SQLs are triggers for output of an audit trail. Note that the audit trail collection method for PREPARE, CLOSE and OPEN depends on where an error occurs. Table 22-9 shows whether an audit trail is output depending on the success or failure of an event during dynamic SQL execution.

Table 22-9 Audit trail output depending on the success or failure of an event during dynamic SQL execution

SQL result | Collection specification
Upon success | Upon failure | Both
PREPARE successful | OPEN (EXECUTE) successful | CLOSE successful | Output on CLOSE (EXECUTE) | Not output | Output on CLOSE (EXECUTE)
CLOSE failed | Not output | Output on CLOSE (EXECUTE) | Output on CLOSE (EXECUTE)
OPEN (EXECUTE) failed | Not output | Output on OPEN (EXECUTE)
PREPARE failed |  | Not output | Output on PREPARE
EXECUTE IMMEDIATE | Output on EXECUTE IMMEDIATE

Legend:

: Not applicable

Note

An event termination audit trail is output when the cursor is closed by executing the CLOSE statement internally without having to execute it explicitly. For the timing, see the section on the CLOSE statement in the manual HiRDB Version 8 SQL Reference.

22.3.3 Relationships among audit trails

How audit trails that are output during privilege checking are related to audit trails output at event termination and how multiple records are related to events can be checked from the following information:

For an SQL, check the combination of the server name, CONNECT serial number, and SQL serial number that are output in an audit trail.

For a command or utility, check the combination of the process ID and host name that are output in an audit trail.

For details about audit trail output contents, see 22.8 Audit trail table columns.

22.4 Environment settings

The following is the procedure for making the environment settings for the security audit facility.

Procedure

Specify HiRDB system definition operands related to the security audit facility.

Create a HiRDB file system area for the audit trail files.

Register the auditor, create the RDAREA for storing the audit trail table, and create the audit trail table.

Define the audit events.

Steps 1-3 are performed by the HiRDB administrator, and step 4 is performed by the auditor. The procedure step numbers correspond to the section numbers of the explanation that follows. For example, step 3 above is explained in section 22.4.3 below.

Organization of this section

22.4.1 Security audit facility operand specifications

22.4.2 Creation of the HiRDB file system area for the audit trail files

22.4.3 Auditor registration, creation of the RDAREA to store the audit trail table, and creation of the audit trail table

22.4.4 Audit event definition

22.4.1 Security audit facility operand specifications

Executor: HiRDB administrator

Table 22-10 lists the operands that can be specified for using the security audit facility.

Table 22-10 Operands specified for using the security audit facility

Operand
Explanation

pd_audit
Specifies whether or not collection of an audit trail is to start from the time HiRDB starts:
Y: Collect an audit trail from the time of HiRDB startup.
N: Do not start collecting an audit trail at the time HiRDB starts.
Even if N is specified in this operand, an audit trail can be collected by executing the pdaudbegin command.
If Y is specified in the pd_audit operand, or if the pdaudbegin command is executed, audit trails for the following events are collected unconditionally:

System administrator security events

Auditor security events

For other events, use CREATE AUDIT to specify whether an audit trail is to be collected. For details, see 22.4.4 Audit event definition.

pd_aud_file_name
Specifies the HiRDB file system area to be used for the audit trail files. HiRDB creates the audit trail files in this HiRDB file system area. This operand must be specified when the security audit facility is used. If it is not specified, the security audit facility cannot be used.
When this operand is specified, HiRDB will not start if an access error occurs in the HiRDB file system area for the audit trail files during startup of HiRDB (or unit for a HiRDB/Parallel Server).

pd_aud_max_generation_size
Specifies the maximum size of an audit trail file.

pd_aud_max_generation_num*
Specifies the maximum number of audit trail file generations to be created in the HiRDB file system area for audit trail files.

pd_aud_no_standby_file_opr
Specifies the processing when there are no available swappable audit trail files:
down:
When there is one or fewer swappable audit trail files available, HiRDB (or unit for a HiRDB/Parallel Server) is to be terminated forcibly.
forcewrite (default):
When there are no swappable audit trail files available, a data load waiting audit trail file (excluding files in shutdown status) is to be forcibly made the swap target so that audit trail output will continue. For details about the status of audit trail files, see 22.6 Operation of audit trail files.

pd_aud_async_buff_size
Specifies the buffer length to be used when the audit trail is output asynchronously.

pd_aud_async_buff_count
Specifies the number of buffers to be used when the audit trail is output asynchronously.

pd_aud_async_buff_retry_intvl
Specifies the interval at which buffer monitoring is to be retried until an unused buffer is allocated when all the buffers used for asynchronous output of an audit trail are in use.

pd_aud_file_wrn_pnt
Specifies that a warning message is to be output when the number of unswappable audit trail files reaches a warning level. Specify for the warning value a value that is less than the maximum number of audit trail file generations specified in the pd_aud_max_generation_num operand.

* Specify the value of the pd_aud_max_generation_num operand so that it satisfies the following condition:

Value of pd_aud_max_generation_num < value of pdfmkfs command's -l option

The -l option specifies the maximum number of files to be created in the HiRDB file system area used for the audit trail files, which is discussed later. If the value of the operand is specified so that this condition is satisfied, then if swappable files cannot be prepared immediately, you will be able to increase the value of the pd_aud_max_generation_num operand. Figure 22-4 shows the recommended specification.

Figure 22-4 Recommended relationship between the value of pd_aud_max_generation_num and the -l option

22.4.2 Creation of the HiRDB file system area for the audit trail files

Executor: HiRDB administrator

Use the pdfmkfs command to create the HiRDB file system area to be used by HiRDB for creation of the audit trail files. The following should be considered when you create the HiRDB file system area for audit trail files:

Specify the HiRDB file system area name specified in the pd_aud_file_name operand.

Create the HiRDB file system area for the audit trail files as a character special file. Do not create it as a normal file.

For a HiRDB/Parallel Server, create a HiRDB file system area for audit trail files in each unit.

For the -k option (usage), specify SYS or SVR. The recommended value is SYS.

The target for specifying the -n option (HiRDB file system area length) is as follows:
Recommended value: Value of pd_aud_max_generation_size 200 + 20 (megabytes)
Minimum value: Value of pd_aud_max_generation_size value of pd_aud_max_generation_num + 20 (megabytes)

The target for specifying the -l option (maximum number of file generations in the HiRDB file system area) is as follows:
Recommended value: 200 (maximum value of pd_aud_max_generation_num)
Minimum value: Value of pd_aud_max_generation_num

22.4.3 Auditor registration, creation of the RDAREA to store the audit trail table, and creation of the audit trail table

Executor: HiRDB administrator

Execute the database structure modification utility (pdmod command), and perform the following. All of the following tasks can be performed simultaneously with a single issuance of the pdmod command.

Register the auditor

Create the RDAREA that will store the audit trail table

Create the audit trail table

Organization of this subsection

(1) Register the auditor

(2) Create the RDAREA to store the audit trail table

(3) Create the audit trail table

(1) Register the auditor

Register the auditor with the pdmod command's create auditor statement. The auditor can perform the following operations:

Data load the audit trail table

Swap audit trail files

Access, update, and delete the audit trail table

Notes

The registered auditor cannot be deleted and updated at the same time.

Create a user without DBA privilege as the auditor. The HiRDB administrator cannot be the auditor.

Only one person can be registered as the auditor (there cannot be multiple auditors).

The auditor cannot hold the DBA privilege. Table 22-11 lists the user privileges that can be held by the auditor.

Table 22-11 User privileges that can be held by the auditor

Type of user privilege | Yes/No | Remarks
Audit privilege | Yes | These privileges are granted automatically when the auditor is registered.
CONNECT privilege | Yes
Schema definition privilege | Yes
DBA privilege | No | The auditor cannot hold the DBA privilege.
RDAREA usage privilege | Yes | The privilege to use the RDAREA that stores the audit trail table must be granted by a user who has the DBA privilege. This also applies to use of other RDAREAs.
Table access privilege | Yes | The auditor can hold audit trail table access privilege. The privilege to access other tables must be granted by each table's owner.

Legend:

Yes: This privilege can be held.

No: This privilege cannot be held.

Notes when the Directory Server linkage facility is used

Register the auditor's user information with the Directory Server.

The auditor changes the password with the GRANT AUDIT statement. It must be changed to the password registered with the Directory Server.

(2) Create the RDAREA to store the audit trail table

Create the RDAREA where the audit trail table will be stored using the pdmod command's create rdarea statement. The following should be considered when creating the RDAREA for storing the audit trail table:

Make the RDAREA type a user RDAREA.

Grant RDAREA usage privilege only to the auditor. Do not make it a shared RDAREA and do not grant usage to it to other users. Specify the RDAREA usage privilege with the create rdarea statement's for user used by operand.

Allocate global buffers to the added RDAREA.

The audit trail table can be stored in an existing RDAREA, but the audit trail table cannot be stored in a shared RDAREA or in an RDAREA to which users other than the auditor have usage privileges. In such a case, change the RDAREA usage privilege so that only the auditor has it.

Before re-creating or modifying the RDAREA that stores the audit trail table, the auditor must delete the audit trail table.

(3) Create the audit trail table

Create the audit trail table with the pdmod command's create audit table statement. The following should be considered when creating the audit trail table:

Only one audit trail table can be created.

The audit trail table can be deleted and redefined. To delete the audit trail table, the auditor executes the DROP TABLE statement. Users other than the auditor cannot delete the audit trail table. To re-create the audit trail table after it has been deleted, the HiRDB administrator executes the pdmod command's create audit table statement.

The audit trail table cannot be row partitioned.

The table definition of the audit trail table cannot be modified.

22.4.4 Audit event definition

Executor: Auditor

System administrator security events and auditor security events are included in the events to be audited. CREATE AUDIT is used to define whether or not the following are audited:

Session security events

Privilege management events

Object definition events

Object manipulation events

Utility manipulation events

Use DROP AUDIT to remove these audit events from being audited. For details about CREATE AUDIT and DROP AUDIT, see the manual HiRDB Version 8 SQL Reference.

22.5 Operating procedure

This section explains the actions performed by the HiRDB administrator and the tasks performed by the auditor when the security audit facility is used.

Organization of this section

22.5.1 Actions performed by the HiRDB administrator

22.5.2 Actions performed by the auditor

22.5.1 Actions performed by the HiRDB administrator

Organization of this subsection

(1) Collect an audit trail

(2) Delete audit trail files

(3) Manipulate the RDAREA that stores the audit trail table

(4) Create an HiRDB file system area for the audit trail files

(1) Collect an audit trail

The HiRDB administrator uses one of the following methods to collect an audit trail:

Specify Y for the pd_audit operand
In this case, an audit trail will be collected beginning at the time of HiRDB startup.

Execute the pdaudbegin command
In this case, the audit trail will be collected beginning at the time the command is executed.

To stop collection of the audit trail, execute the pdaudend command. Only the HiRDB administrator can execute this command. The auditor cannot use this command.

Reference note

If HiRDB is restarted, the previous operating status is inherited. If an audit trail was being collected, it will be collected after restart; if an audit trail was not being collected, it will not be collected after restart.

If HiRDB undergoes a normal startup, then rather than the previous operating status, the specification of the pd_audit operand takes precedence. Even if an audit trail was being collected, if pd_audit=N is specified, no audit trail will be collected after a normal startup. If an audit trail was not being collected but pd_audit=Y is specified, an audit trail will be collected after the normal startup.

(2) Delete audit trail files

Audit trail files can be deleted with the pdaudrm command. Only the HiRDB administrator can use this command. The auditor cannot use this command.

(3) Manipulate the RDAREA that stores the audit trail table

The HiRDB administrator manipulates the RDAREA that stores the audit trail table. For example, the HiRDB administrator can perform the following actions:

Back up the RDAREA that stores the audit trail table

Recover the RDAREA that stores the audit trail table

Modify the structure of the RDAREA that stores the audit trail table (extend the RDAREA, etc.)

Add or remove usage privileges for the RDAREA that stores the audit trail table*

* This is performed when the RDAREA that stores the audit trail table is modified. For example, the HiRDB administrator can remove usage privileges for the RDAREA before it is modified, and grant an auditor usage privileges for the RDAREA after it is modified.

(4) Create an HiRDB file system area for the audit trail files

The HiRDB administrator manipulates the HiRDB file system area for the audit trail files. For example, the HiRDB administrator performs the following actions:

Delete the audit trail table by deleting the HiRDB file system area (delete with an OS command)*

Back up the HiRDB file system area with the pdfbkup command

Recover the HiRDB file system area with the pdfrstr command

Initialize the HiRDB file system area with the pdfmkfs command

Delete the HiRDB files that store the audit trail table with the pdfrm command

* HiRDB does not output this event as part of the audit trail. Use the OS's audit facility to audit this event.

22.5.2 Actions performed by the auditor

Actions 1 and 2 below are performed periodically, and the remaining actions are performed as needed.

Organization of this subsection

(1) Check the status of the audit trail files

(2) Record data in the audit trail table (data load the audit trail table)

(3) Use the audit trail table

(4) Swap audit trail files

(5) Manipulate the audit trail table

(6) Add and delete audit events

(7) Change the password

(8) Delete the auditor's schema

(1) Check the status of the audit trail files

Check the status of the audit trail files with the pdls -d aud command. Check the following:

Whether or not there are data load waiting audit trail files

Whether or not there are swappable audit trail files

For details about the statuses of audit trail files, see 22.6 Operation of audit trail files.

(2) Record data in the audit trail table (data load the audit trail table)

Record data (the output audit trail) in the audit trail table. Use the database load utility (pdload command) to load the data into the audit trail table from a data load waiting audit trail file. For details about the data load procedure, see 22.7 Recording data in the audit trail table.

(3) Use the audit trail table

Use the audit trail table to perform audits. For details about the columns of the audit table, see 22.8 Audit trail table columns.

(4) Swap audit trail files

Use the pdaudswap command to swap audit trail files. For example, to load the data from the current audit trail file to the audit trail table, swap audit trail files with the pdaudswap command and then perform the data load. The current audit trail file cannot be data loaded.

Note

If either of the following conditions is satisfied, the pdaudswap command cannot be executed:

There are no swappable audit trail files

No audit trail files have been generated

(5) Manipulate the audit trail table

The auditor manipulates the audit trail table. For example, the auditor performs the following actions:

Grant access privileges to the audit trail table
Only the SELECT privilege for the audit trail table and a view table that uses the audit trail table as the base table can be granted to other users. SELECT privilege can also be removed. The INSERT, UPDATE, and DELETE privileges cannot be granted to other users. The auditor adds and removes access privileges to the audit trail table. Access privilege to the audit trail table cannot be granted to anyone other than the auditor.

Define indexes for the audit trail table
Indexes can be defined for the audit trail table. For details about the audit table columns, see 22.8 Audit trail table columns.
The audit trail table cannot be row partitioned, nor can the table definition be modified.

Reorganize the audit trail table
The auditor reorganizes the audit trail table. Users other than the auditor cannot reorganize the audit trail table.

Delete the audit trail table
The audit trail table can be deleted with DROP TABLE. The auditor deletes the audit trail table. Users other than the auditor cannot delete the audit trail table.
To re-create the audit trail table, the HiRDB administrator uses the pdmod command's create audit table statement.

(6) Add and delete audit events

Audit events can be added with CREATE AUDIT. Unnecessary audit events can be deleted with DROP AUDIT.

(7) Change the password

The auditor's password can be changed with GRANT AUDIT. The auditor changes the password.

(8) Delete the auditor's schema

If there is no audit trail table, the auditor's schema can be deleted. The auditor and DBA privilege holders can delete the auditor's schema.

22.6 Operation of audit trail files

This section explains in detail the creation of audit trail files. The following topics are covered:

Creation of audit trail files

Status of audit trail files

Swapping of audit trail files

Organization of this section

22.6.1 Creation of audit trail files

22.6.2 Status of audit trail files

22.6.3 Swapping of audit trail files

22.6.1 Creation of audit trail files

Organization of this subsection

(1) Audit trail file creation convention

(2) Naming of audit trail files

(3) Output to audit trail file

(1) Audit trail file creation convention

HiRDB creates audit trail files automatically in the HiRDB file system area for audit trail files. The first time an audit trail file is created, it becomes the first generation, followed by the second generation, the third generation, and so on. Figure 22-5 shows the procedure for creating audit trail files.

Figure 22-5 Audit trail file creation

The maximum number of audit trail files that can be created in the HiRDB file system area is specified in the pd_aud_max_generation_num operand. However, if the value of the pdfmkfs command's -l option is smaller than the value of the pd_aud_max_generation_num operand, the value of the -l option becomes the maximum. Also, if there becomes insufficient space in the HiRDB file system area, it will not be possible to create as many audit trail files as provided for by the specification of the pd_aud_max_generation_num operand.

(2) Naming of audit trail files

The audit trail files are named according to the following convention:

pdaudunit-identifier001-200.aud

Example: If the unit identifier is UNT1 and pd_aud_max_generation_num=100

1st generation file name: pdaudUNT1001.aud

2nd generation file name: pdaudUNT1002.aud

:

99th generation file name: pdaudUNT1099.aud

100th generation file name: pdaudUNT1100.aud

If files other than audit trail files are created in the HiRDB file system area for audit trail files, they must not be files whose names will be inconsistent with these naming conventions.

(3) Output to audit trail file

Audit trail output format

For the audit trail output format, the pd_aud_async_buff_size operand can be used to select synchronous output or asynchronous output.

Buffer flush opportunities for asynchronous output

If asynchronous output is selected, when an opportunity to output to the audit trail file occurs, the audit trail is stored temporarily in a buffer used for asynchronous output. The audit trail stored in a buffer used for asynchronous output is output to the audit trail file at the following opportunities; these are called asynchronous output buffer flush opportunities:

When the buffer used for asynchronous output becomes full

When the pdaudswap command is executed

When the pdaudend command is executed

When the pdstop command is used for normal termination or planned termination of HiRDB (or unit)

Audit trail output processing

Audit trail output processing to the audit trail file is as follows, depending on the output format:

For synchronous output
If there are no audit trail files, an audit trail file is created at the first audit trail collection opportunity, and the audit trail is output. If there is at least one audit trail file, the audit trail is output to the current file at each output trail collection opportunity.

For asynchronous output
If there are no audit trail files, an audit trail file is created at the first asynchronous output buffer flush opportunity, and the audit trail is output. If there is at least one audit trail file, the audit trail is output to the current file at each asynchronous output buffer flush opportunity.

22.6.2 Status of audit trail files

HiRDB manages audit trail files in several statuses, as shown and explained in Table 22-12 and Figure 22-6. The status of audit trail files can be checked with the pdls -d aud command.

Table 22-12 Audit trail file statuses

File status
Explanation

Current
This is the file to which the audit trail can be output currently. There is always one file in this status. Files other than the current file are considered to be on standby.

Data load completed
This is a file from which data loading to the audit trail table has been completed. Such a file can be used as the swap target when audit trail file swapping occurs.

Data load waiting
This is a file from which data loading to the audit trail table has not been completed. Such a file cannot be used as the swap target when for audit trail file swapping. However, depending on the value of the pd_aud_no_standby_file_opr operand, it may be possible to use a file in this status as the swap target.

Shutdown
This is an audit trail file that cannot be used due to an error during audit trail I/O or with the audit trail file header. Files in this status cannot be used as an audit trail file swap target. Files that are not shut down are called normal files.

Figure 22-6 Audit trail file statuses

22.6.3 Swapping of audit trail files

Changing the audit trail output destination (changing the file that is the current file) is called audit trail file swapping.

Organization of this subsection

(1) When audit trail files are swapped

(2) Audit trail file swap target

(3) HiRDB processing when there are no files available for the swap target

(1) When audit trail files are swapped

Table 22-13 explains the conditions under which audit trail files are swapped.

Table 22-13 Conditions under which audit trail files are swapped

Condition for swapping | Explanation
File is full | When the output audit trail becomes full, the file is swapped. The size of an audit trail file is specified in the pd_aud_max_generation_size operand.
Error in the current file | If an error occurs during I/O processing to the current file, the file is swapped.
pdaudswap command is executed | When the pdaudswap command is executed, the file is swapped.
HiRDB is restarted | When HiRDB (or unit for a HiRDB/Parallel Server) is restarted, the file is swapped. In the case of normal startup or a restart after planned termination, the file is not swapped and the file that was the current file at the time of the previous HiRDB termination continues to be used.

In the following cases, the file that should be swapped in is replaced automatically by another file:

Generation of the audit trail file that was to be the swap target failed

Update to the management information failed

(2) Audit trail file swap target

The processing depends on whether or not the number of audit trail files used has reached the maximum (value of pd_aud_max_generation_num).

If the number of audit trail files has not reached the maximum (value of pd_aud_max_generation_num), another audit trail file is created, and that file becomes the swap target. The smallest unused generation number is allocated as the file generation number.

If the number of audit trail files has reached the maximum number (value of pd_aud_max_generation_num), the data load completed file (excluding files in shut down status) with the oldest update date becomes the swap target.

(3) HiRDB processing when there are no files available for the swap target

If there are no files available for the swap target, HiRDB processing depends on the value of the pd_aud_no_standby_file_opr operand.

If forcewrite (the default) is specified

If there are no swappable files available, a data load waiting audit trail file (excluding files on shutdown status) is forcibly made the swap target. The data load waiting file with the oldest update date becomes the swap target.

If down is specified

If there is one or fewer swappable audit trail files available, HiRDB (or the unit for a HiRDB/Parallel Server) is terminated forcibly. For the procedure at this time, see 22.10(3) When HiRDB is terminated forcibly because there are no swappable target audit trail files.

If the pd_aud_file_wrn_pnt operand is specified, a warning message can be output when the number of unswappable audit trail files reaches a warning level.

22.7 Recording data in the audit trail table

Executor: Auditor

Use the HiRDB supplied audit trail data recording UOC to record data in the audit trail table. This UOC operates by extending the database load utility (pdload command). It provides a facility for load data output to an audit trail file into the audit trail table. Only the auditor can perform data loading to the audit trail table.

Hint

When the pdload command is executed, either the PDUSER environment variable must be used to specify the auditor's authorization identifier and password, or the auditor's authorization identifier must be specified in the pdload command's -u option and the password must be entered when the pdload command executes.

Organization of this section

22.7.1 Example 1: Data loading from specified audit trail files

22.7.2 Example 2: Data loading from all audit trail files in the HiRDB file system area

22.7.3 Procedure when an error occurs during data loading

22.7.1 Example 1: Data loading from specified audit trail files

This example loads two data load waiting files (file names pdaudUNT1001.aud and pdaudUNT1002.aud) into the audit trail table (table name SQL_AUDIT_TRAIL). The following is the specification of the pdload command for this example:

Example pdload command specification

pdload -b -W SQL_AUDIT_TRAIL /pdload/control_file

Explanation

The -b and -W options must be specified.

Specify the audit trail table for the table name.

The following explains the contents of the control information file:

Example of specifying the control information file

source bes1:(uoc)
srcuoc param='dir=/secarea,file=(pdaudUNT1001.aud,pdaudUNT1002.aud)'

Explanation

source bes1:(uoc): Specifies the server name (bes1) for the HiRDB/Parallel Server. You can specify a server name in the unit where the audit trail files are located. You may specify any server name in the unit, but if you specify a back-end server, you can eliminate a communication bottleneck.

dir: Specifies the HiRDB file system area that stores the audit trail files to be data loaded.

file: Specifies the names of the audit trail files to be data loaded.

If indexes have been defined for the audit trail table, use the idxwork statement and the sort statement.

22.7.2 Example 2: Data loading from all audit trail files in the HiRDB file system area

This example loads all data load waiting audit trail files in the HiRDB file system area (/secarea) into the audit trail table (table name SQL_AUDIT_TRAIL). The following is the specification of the pdload command for this example:

Example pdload command specification

pdload -b -W SQL_AUDIT_TRAIL /pdload/control_file

Explanation

The -b and -W options must be specified.

Specify the audit trail table for the table name.

The following explains the contents of the control information file:

Example of specifying the control information file

source bes1:(uoc)
srcuoc param='dir=/secarea,file=all,mode=normal'

Explanation

source bes1:(uoc): Specifies the server name (bes1) for the HiRDB/Parallel Server. You can specify a server name in the unit where the audit trail files are located. You may specify any server name in the unit, but if you specify a back-end server, you can eliminate a communication bottleneck.

dir: Specifies the HiRDB file system area that stores the audit trail files to be data loaded.

file=all: Specifies that all audit trail files in the HiRDB file system area are to be data loaded. However, the current file and files in shutdown status are excluded.

mode=normal: Specifies that data load completed files are not to be data loaded.

Remarks

If mode=force is specified, data load completed files are also data loaded. You would specify force in the situation explained below. Note that when force is specified, the same data may be recorded twice, so care must be taken not to record data that has already been recorded.

If the audit trail table's data was deleted inadvertently and there is no backup, it would be appropriate to data load all audit trail files in order to recover the audit trail table

Table 22-14 shows whether data loading can be executed, depending on the audit trail file status and user specified values.

Table 22-14 Whether or not data is loaded depending on the audit trail file status and user specified values

Audit trail file status | User specified value
Shutdown status | Data load status | mode | file=file-name | file=all
Not shutdown | Data load waiting | normal | Executes data load processing from the audit file.
Data load completed | Skips data load processing from the audit file, and continues processing. | Does not perform data load processing from the audit file.
Shutdown | Data load waiting
Data load completed
Not shutdown | Data load waiting | force | Executes data load processing from the audit file. | This is a user specification error.
Data load completed
Shutdown | Data load waiting | Skips data load processing from the audit file, and continues processing.
Data load completed
| Current |  | Skips data load processing from the audit file, and continues processing. | Does not perform data load processing from the audit file.

Legend:

: Not applicable.

22.7.3 Procedure when an error occurs during data loading

This section explains the procedure when an error occurs during data loading.

Organization of this subsection

(1) When executing in the log acquisition mode or the pre-update log acquisition mode

(2) When executing in the logless mode

(1) When executing in the log acquisition mode or the pre-update log acquisition mode

Procedure

Check the progress of data load processing. Because a commit occurs for each audit trail file during data loading, data loading is completed when the KFPL00800-I message is output for an audit trail file.
Use the pdls -d aud command to check the audit trail file status. Files for which data loading has been completed enter data load completed status.

Check whether or not the KFPL23202-E message has been output. Data loading has been completed for an audit trail file for which the KFPL23202-E message is output, but the file's status failed to change. Therefore, such files remain in data load waiting status, which means that if the pdload command is re-executed the data may be recorded again. For this reason, you should use the pdaudrm command to delete such files before re-executing the pdload command.

Re-execute the pdload command. There is no need to change the option specifications or the control information file specification.

(2) When executing in the logless mode

Procedure

Use the pdrstr command and a backup made before data loading was executed to recover the RDAREA that stores the audit trail table.

Audit trail files for which data loading has been completed enter data load completed status. Therefore, even if the pdload command is re-executed, these files in data load completed status will not be data loaded. In this case, specify mode=force and re-execute the pdload command.

Re-execute the pdload command. If file=all is specified, specify the control information file to be data loaded in the file operand.

22.8 Audit trail table columns

Table 22-15 shows the columns of the audit trail table.

Table 22-15 Audit trail table columns

Column name
Column content
Column data type
NULL value specification

USER_NAME
Authorization identifier of the person who executed the audited event.
For a command or utility executed by the HiRDB administrator or a general OS user, the OS user name is output.
MVARCHAR(30)
No

EXEC_DATE
Date the event was executed.
Event execution date means the date according to the standard time at which the server that issued the audit trail output request requests output of an audit trail to the audit trail buffer.
DATE
No

EXEC_TIME
Time the event was executed.
Event execution time means the time according to the standard time at which the server that issued the audit trail output request requests output of an audit trail to the audit trail buffer.
TIME
No

EXEC_TIME_MICRO
Time the event was executed (microseconds).
Event execution time means the time according to the standard time at which the server that issued the audit trail output request requests output of an audit trail to the audit trail buffer.
INTEGER
No

EVENT_TYPE
Event type. For details about the event types and subtypes, see (1) Event types and subtypes.
CHAR(3)
No

EVENT_SUBTYPE
Event subtype. For details about the event types and subtypes, see (1) Event types and subtypes.
CHAR(3)
No

EVENT_RESULT
Result of event execution; this item flags whether or not privilege checking was successful:
S: Privilege checking or event succeeded.
F: Privilege checking or event failed.
U: Part of the event failed.
CHAR(1)
No

USED_PRIVILEGE
Privilege used when the event executed. When the event is terminated, three consecutive blank symbols () are output.
AUD: Audit privilege
CNT: CONNECT privilege
DBA: DBA privilege
DEL: DELETE privilege
INS: INSERT privilege
OWN: Owner
RDA: RDAREA usage privilege
SCH: Schema definition privilege
SEL: SELECT privilege
SYS: HiRDB administrator
UPD: UPDATE privilege
CHAR(3)
No

UAP_NAME
Name of the UAP that issued the event.¹
If the UAP name is fewer than 30 characters, it is padded with trailing blank symbols ().
In all other cases, the NULL value is output.
VARCHAR(30)
Yes

SERVICE_NAME
Name of the service requested by the UAP that issued the event. If an OpenTP1 UAP, this is the name of the service requested by SPP or MHP.
If not an OpenTP1 UAP, 31 consecutive asterisks (*) are output.
In all other cases, the NULL value is output.
VARCHAR(31)
Yes

IP_ADDRESS
IP address that issued the event. The NULL value is output when the IP address cannot be identified.
VARCHAR(63)
Yes

PROCESS_ID
Process ID that issued the event. The NULL value is output when the process ID cannot be identified.
For a command or utility, the process ID of the executed command is output.
At the start of audit trail overwriting by the system, the process ID of the audit trail daemon is output.
In all other cases, the process ID of the single server or front-end server that connected is output.
INTEGER
Yes

THREAD_ID
Thread ID that issued the event. The NULL value is output when the thread ID cannot be identified.
INTEGER
Yes

HOST_NAME
Name of the host that received the event. The host name specified in the -x option of the pdunit operand is output. If a system switchover facility is used, the host name of the primary system is output.
The NULL value is output when the name of the host that received the event cannot be identified.
VARCHAR(32)
Yes

UNIT_NAME
Unit identifier that received the event. The unit identifier specified in the -u option of the pdunit operand is output.
The NULL value is output when the unit identifier that received the event cannot be identified.
CHAR(4)
Yes

SERVER_NAME
Name of the server that received the event. For a HiRDB/Single Server, this is the name of the single server; for a HiRDB/Parallel Server, this is the name of the front-end server. This is output when the server name can be identified. The server name specified in the -s option of the pdstart operand is output.
The NULL value is output when the name of the server that received the event cannot be identified.
VARCHAR(8)
Yes

CONNECT_NUMBER
Connection number of the event issuer. The NULL value is output when the connection number cannot be identified.
INTEGER
Yes

SQL_NUMBER
Event SQL number. The NULL value is output when the event SQL number cannot be identified.
INTEGER
Yes

OBJECT_SCHEMA
Object information detail²
Owner of the object for which the event privilege is being checked. The NULL value is output when the object owner cannot be identified.
MVARCHAR(30)
Yes

OBJECT_NAME
Name of the object for which the event privilege is being checked. The NULL value is output when the object name cannot be identified.
MVARCHAR(30)
Yes

OBJECT_TYPE
Type of object for which the event privilege is being checked. The NULL value is output when the object type cannot be identified.
ALS: Alias
AUF: Audit trail file
FID: Foreign index
FNC: Function
FSV: Foreign server
FTB: Foreign table
IDX: Index
LST: List
PRC: Procedure
RDA: RDAREA
SCH: Schema
TBL: Table
TRG: Trigger
TYP: Data type
USM: User Mapping
VIW: View table
CHAR(3)
Yes

PRIVILEGE_TYPE
Privilege added, deleted, or modified by the event. The NULL value is output when the privilege cannot be identified.
AUD: Audit privilege
CNT: CONNECT privilege
DBA: DBA privilege
DEL: DELETE privilege
INS: INSERT privilege
RDA: RDAREA usage privilege
SCH: Schema definition privilege
SEL: SELECT privilege
UPD: UPDATE privilege
CHAR(3)
Yes

PRIVILEGE_SCHEMA
User authorization identifier added, deleted, or modified by the event. Or, the authorization identifier of the user who was the target of the event.
The NULL value is output when the authorization identifier cannot be identified.

GRANT or REVOKE: Authorization identifier, group ID, or role name to which a privilege was added, from which a privilege was deleted, or whose privilege was modified.

Transition to or release from consecutive certification failure account lock state: Authorization identifier that was locked or released.

Transition to or release from password-invalid account lock state: Authorization identifier that was locked or released.

MVARCHAR(30)
Yes

SECURITY_OPERAND
Values of the security audit facility operands. These are the operand values at HiRDB startup. For all cases other than startup, the NULL value is output.
For details about the operand values for the security audit facility, see (2) Operand values for the security audit facility.
VARCHAR(256)
Yes

AUDIT_TRAIL_TYPE
Audit trail type. A value is output to differentiate between an audit trail showing an event result and an audit trail showing the result of privilege checking during event execution.
Privilege checking: NULL
Event termination: E
CHAR(1)
Yes

SQL_CODE
SQL code or termination code. When an audited event is terminated, an SQL code or termination code is output for the SQL event or utility (or command). For privilege checking, the NULL value is output.
This code indicates the event success or failure value that is set when the event terminates. For details about each code in the audit record entry and whether or not the event is successful, see (3) SQL code or termination code indicating event success or failure.
INTEGER
Yes

FROM_AUDFILE_NAME
Audit trail file name at the swapping source. The NULL value is output when the audit trail cannot be identified.
MVARCHAR(30)
Yes

TO_AUDFILE_NAME
Audit trail file name at the swapping destination. The NULL value is output when the audit trail cannot be identified.
MVARCHAR(30)
Yes

SECURITY_PARM_TYPE
Modification type related to the connection security facility.³
CHAR(4)
Yes

BEFORE_SECURITY_PARM
Setting value of the connection security facility before change.³
If the setting value is fewer than 10 characters, it is padded for output with trailing blanks (setting value + blanks = 10 characters).
CHAR(10)
Yes

AFTER_SECURITY_PARM
Setting value of the connection security facility after change.³
If the setting value is fewer than 10 characters, it is padded for output with trailing blanks (setting value + blanks = 10 characters).
CHAR(10)
Yes

AUDIT_TABLE_OPTION
Audit trail table option. This item is not output for privilege checking. It is output in the following cases:

The event-target object is an audit trail table.

The event-target object is a view table created using an audit trail table as the base table.

The event-target object is a list created using an audit trail table as the base table.

Y: Manipulation-target object is an audit trail table.
V: Manipulation-target object is a view table created using an audit trail table as the base table.
L: Manipulation-target object is a list created using an audit trail table as the base table.
NULL value: For cases other than those listed above or for privilege checking
For details about whether or not audit trail table options are output, see (5) Whether or not audit trail table options are output.
CHAR(1)
Yes

ACCESS_COUNT
Number of rows searched, inserted, updated, and deleted by the user for an object (base table, view table, foreign table, table alias, or list). The access count that can be acquired is from 0 to 2147483647​. If acquisition of the access count fails, the NULL value is output.
For details about the access count, see (6) Details about the access count.
INTEGER
Yes

Notes

For a column for which the NULL value is specified, NULL is set for the NOT NULL constraint. For a column for which the NULL value is not specified, NOT NULL is set for the NOT NULL constraint.

When version upgrading changes the column structure of an audit trail table and data prior to version upgrading is registered in the audit trail table after version upgrading, the NULL value is set in the newly added columns of the existing rows.

¹ To use a UAP name as a search key, specify CAST to convert the attribute to CHAR(30) and specify the result in the conditional expression.

Example:

  SELECT * FROM SQL_AUDIT_TRAIL
      WHERE UAP_NAME=CAST('UAP11' AS CHAR(30));

² During privilege checking:

The object that is the target of privilege checking is output. However, when the privilege of the executor is checked, nothing is output because there is no object that is checked.

Examples:

Target object when the access privilege to table T1 is checked: Table T1

Target object when whether or not the executor has the DBA privilege is checked: NULL value

At event termination:

The object that is the target of the event is output. If no object is specified as the event target, table is output as the object type.

Example:

Target object when a table is searched: The searched table

³ A modification type is output in the following cases:

When a setting value of the connection security facility is changed

When a password is registered or modified

For details about the information that is recorded, see (4) Information that is recorded when the connection security facility is used.

Organization of this section

(1) Event types and subtypes

(2) Operand values for the security audit facility

(3) SQL code or termination code indicating event success or failure

(4) Information that is recorded when the connection security facility is used

(5) Whether or not audit trail table options are output

(6) Details about the access count

(1) Event types and subtypes

Table 22-16 provides details about the event types and subtypes.

Table 22-16 Event types and subtypes

Audit event | Event type value | Event subtype value | Event
System administrator security events | SYS | STR | HiRDB startup
STP | HiRDB termination
MOD | Auditor registration or audit trail table creation (pdmod command)
ARM | Audit trail file deletion (pdaudrm command)
ABG | Audit trail collection startup (pdaudbegin command, HiRDB startup)
AEN | Audit trail collection termination (pdaudend command, HiRDB termination)
OVW | Start of audit trail file overwriting
CLK | Transition to consecutive certification failure account lock state
CUL | Release of consecutive certification failure account lock state
PLK | Transition to password-invalid account lock state
PUL | Release of password-invalid account lock state
SPR | Modification of an operand related to the connection security facility
ULK | Execution of the pdacnlck command
Auditor security events | AUD | ALD | Data load the audit trail table (pdload command)
ASW | Audit trail file swap (pdaudswap command)
CRT | Audit event definition (CREATE AUDIT)
DRP | Audit event deletion (DROP AUDIT)
GRT | Auditor password change (GRANT AUDIT)
Session security events | SES | CNT | Connection to HiRDB (CONNECT statement)
ATH | User modification (SET SESSION AUTHORIZATION statement)
Privilege management events | PRV | GRT | User privilege addition (GRANT statement)
Password change (adds information indicating a password change to the set modification type for the connection security facility)
RVK | User privilege deletion (REVOKE statement)
Object definition events | DEF | CRT | Object definition (CREATE type SQL)
DRP | Object deletion (DROP type SQL)
ALT | Object modification (ALTER type SQL)
Object manipulation events | ACS | SEL | Table retrieval (SELECT statement)
INS | Table row insertion (INSERT statement)
UPD | Table row modification (UPDATE statement)
DEL | Deletion of a row from a table (DELETE statement)
PRG | Deletion of all rows from a table (PURGE TABLE statement)
CAL | Execution of a stored procedure (CALL statement)
LCK | Table lock control (LOCK TABLE statement)
ASN | List creation (ASSIGN LIST statement)
Utility manipulation event | UTL | LOD | Database load utility (pdload command)
ORG | Database reorganization utility (pdrorg command)
EXP | Dictionary import/export utility (pdexp command)
pddefrev command
CST | Integrity check utility (pdconstck command)

(2) Operand values for the security audit facility

Table 22-17 lists the operand values related to the security audit facility. Figure 22-7 shows the data format used when operand values are recorded.

Table 22-17 Values of security audit facility operands

Operand | Data type | Stored value
pd_audit | CHAR(1) | Y or N
pd_aud_file_name | VARCHAR(167) | Name of HiRDB file system area used for audit trail files
pd_aud_max_generation_size | VARCHAR(4) | 1-5240
pd_aud_max_generation_num | VARCHAR(3) | 2-200
pd_aud_no_standby_file_opr | VARCHAR(10) | down or forcewrite
pd_aud_async_buff_size | VARCHAR(7) | 0, 4096-6553600​
pd_aud_async_buff_count | VARCHAR(4) | 1-6500
pd_aud_file_wrn_pnt | VARCHAR(6) | 0-100 and 0-99

Figure 22-7 Data format for output of security audit facility operand values

(3) SQL code or termination code indicating event success or failure

Table 22-18 provides details about the SQL codes or termination codes that indicate event success or failure.

Table 22-18 SQL code or termination code indicating event success or failure

Event
SQL code or termination code value
Meaning
Event success or failure
Remarks

Various SQLs
0 or greater
Success
S

Negative
Failure
F

pdstart
0
Success
S

4
Success
S

8
Failure
F
An audit trail cannot be collected in the following cases:

Failure occurred before the audit trail daemon started.

Failure of the pdstart command caused the unit to terminate abnormally.

pdstop
0
Success
S
If a failure occurred after the audit trail daemon had terminated, a successful audit trail is output.

4
Success
S

8
Failure
F

pdmod (auditor registration, audit trail creation)
0
Success
S

8
Failure
F

pdaudrm
0
Success
S

8
Failure
F

pdaudbegin
0
Success
S

4
Partial failure
U

8
Failure
F
An audit trail cannot be collected in the following cases:

All generations of audit trail files have been used.

The pdaudbegin command failed because there is no generation of audit trail files that is in unload wait status.

pdaudend
0
Success
S

8
Failure
F

pdacunlck
0
Success
S

8
Failure
F

pdaudswap
0
Success
S
During overwriting of the audit trail file, the names of the audit trail files at the swapping source and swapping destination are output.

8
Failure
F
During overwriting of the audit trail file, the name of the audit trail file at the swapping source is output. The NULL value is output for the audit trail file name at the swapping destination.

pdload
0
Success
S

4
Success
S

8
Failure
F

pddefrev
0
Success
S

4
Success
S

8
Failure
F

12
Failure
F

pdrorg
0
Success
S

4
Success
S

8
Failure
F

pdexp
0
Success
S

4
Success
S

8
Failure
F

12
Failure
F

pdconstck
0
Success
S

4
Success
S
End of warning (there is an integrity violation)

8
Failure
F

Legend:

: Not applicable

(4) Information that is recorded when the connection security facility is used

Table 22-19 provides the information that is recorded when the connection security facility is used.

Table 22-19 Information that is output when the connection security facility is used

Facility | Event type | Event subtype | Modification type | Value that is output after modification
Permitted number of consecutive certification failures | SYS | SPR | ECNT | 1-10 or NULL value
Account lock period | LCKM | 10-44640, UNLIMITED, or NULL value
Minimum number of bytes for a password | MINL | 1-15 or NULL value
Authorization identifier specification prohibition | USID | RESTRICT, UNRESTRICT, or NULL value
Single character-type specification prohibition | SMLN
Password change* | PRV or AUD | GRT | CPWD | NULL value

Note

The NULL value is output in the following cases:

For a value that is to be output before or after a change, no value is found in the corresponding column in the SQL_SYSPARAMS dictionary table (for example, when a new setting is specified).

For a NULL value

When a value cannot be identified.

During an advance check of password character string restrictions, an audit trail is collected for each modification type. However, the NULL value is output for the value that is to be output before or after the change.

*

HiRDB cannot determine from the event type, event subtype, and SQL code only whether the password was actually changed during execution of a GRANT statement. Only when a registered user password is changed during execution of a GRANT statement is CPWD set as the modification type. Table 22-20 shows the modification types that are output when a password is changed.

Table 22-20 Modification types that are output when a password is changed

Does a password exist for the registered user? | GRANT CONNECT, DBA, or AUDIT execution result | Modification type
Password exists. | Password change | CPWD
Password deletion | CPWD
No password change | NULL value
Password does not exist. | Changes to "Password exists." | CPWD
Retains "Password does not exist." | NULL value

Note

Users and passwords referred to here are those managed by HiRDB.

(5) Whether or not audit trail table options are output

Table 22-21 shows whether or not audit trail table options are output.

Table 22-21 Audit trail table option output

Execution result | Failure cause | Is audit trail table option output?
Success |  | Output
Failure* | The target object does not exist. | Not output (NULL value)
An error occurred because the target object is an audit trail table. | Output
Error other than one listed above | Output (not output when information cannot be collected)

Legend:

: Not applicable

* To determine whether a table is an audit trail table when no audit trail table option is output, check the combination of the object owner and object name in the audit record entry, for example.

(6) Details about the access count

Table 22-22 provides the details of the access count.

Table 22-22 Details about the access count

Access method
Access count

SQL
SELECT
Number of rows accessed (fetched until CLOSE was successful or failed) by the user on the result set using the SELECT statement. For block transfer, the number of rows in a block is treated as the access count.
If multiple tables are specified for a query, the same access count is used for all the applicable tables. The access count is set to the NULL value in either of the following cases:

Table is specified in a subquery (for details, see Table 22-23)

Table is specified in the right-hand operand in the EXCEPT [ALL] set operation (for an example, see Figure 22-13)

INSERT
Number of rows inserted

UPDATE
Number of rows updated

DELETE
Number of rows deleted

Utility
pdload
Data load count per table

pdrorg
Unload count per table and reload count per table

pdconstck
Total number of key values resulting in limitation violation

Table 22-23 Access count by subquery

Specified location in table | Access count | Remarks
Scalar subquery | Where a value expression is permitted | NULL value | For an example, see Figure 22-14
Row subquery | Where a row value constructor is permitted | NULL value | For an example, see Figure 22-15
SET clause in UPDATE statement | NULL value | For an example, see Figure 22-16
Table subquery | Right-hand term of IN predicate | NULL value | For an example, see Figure 22-17
Right-hand term of qualified predicate | NULL value | For an example, see Figure 22-18
EXISTS predicate | NULL value | For an example, see Figure 22-19
Derived table in FROM clause | Non-NULL value* | For an example, see Figure 22-20

*

If the result of searching the derived table in the FROM clause is not returned directly to the user, the access count is the NULL value (for an example, see Figure 22-21).

Figures 22-8 through 22-21 show output examples of the access count when the access method is SELECT.

Figure 22-8 Output example of access count (part 1)

Figure 22-9 Output example of access count (part 2)

Figure 22-10 Output example of access count (part 3)

Note: The actual table is the same as in Figure 22-9.

Figure 22-11 Output example of access count (part 4)

Note: The actual table is the same as in Figure 22-9.

Figure 22-12 Output example of access count (part 5)

Figure 22-13 Output example of access count (part 6)

Note: The actual table is the same as in Figure 22-12.

Figure 22-14 Output example of access count (part 7)

Note: The actual table is the same as in Figure 22-12.

Figure 22-15 Output example of access count (part 8)

Note: The actual table is the same as in Figure 22-12.

Figure 22-16 Output example of access count (part 9)

Note: The actual table is the same as in Figure 22-12.

Figure 22-17 Output example of access count (part 10)

Note: The actual table is the same as in Figure 22-12.

Figure 22-18 Output example of access count (part 11)

Note: The actual table is the same as in Figure 22-12.

Figure 22-19 Output example of access count (part 12)

Note: The actual table is the same as in Figure 22-12.

Figure 22-20 Output example of access count (part 13)

Note: The actual table is the same as in Figure 22-12.

Figure 22-21 Output example of access count (part 14)

Note: The actual table is the same as in Figure 22-12.

22.9 Narrowing the audit trails

By narrowing the audit trails, you can acquire only specific audit trails.

You can narrow audit trails by defining a condition in the CREATE AUDIT definition SQL statement, and then use DROP AUDIT as needed to drop audit trails.

Organization of this section

(1) Selection items

(2) Available selections

(3) Combinations of selection items

(4) Security audit information buffer

(5) HiRDB operation in the event of an error in the security audit information buffer

(6) Change of security audit information buffer status

(1) Selection items

Table 22-24 lists and describes the selection items that can be specified as audit trail narrowing conditions.

Table 22-24 Selection items that can be specified as audit trail narrowing conditions

Selection item
Specification
Description
Record items in the corresponding audit trail

Operation type
Required
Narrows the audit trails to be acquired to audit trails of a specified operation type.

Event type

Event subtype

Trail type
Required
Narrows the audit trails to be acquired to audit trails of a specified trail type.

Audit trail type

Event success/failure
Required
Narrows the audit trails to be acquired on the basis of event success or failure.

Event success or failure

Object*
Optional
Acquires audit trails by narrowing the objects that became the target of a specific event.

Object owner

Object name

Object type

*

The following rules apply to object specification:

Definition of an audit event can be specified even for a nonexistent object name (so that the trails can be narrowed down when an object is created by CREATE).

The definition of an audit event cannot be changed even if the object specified in the audit event definition is deleted by another SQL statement, or if one of its attributes (such as its name) is changed. The following are examples:
Example 1: An audit event definition is specified for table T1, but the table is renamed from T1 to T2. The specification of T1 remains unchanged in the audit event definition.
Example 2: An audit event definition is specified for table T1, but table T1 is dropped by DROP TABLE. The audit event definition remains as is.

In the case of privilege checking trails, trails are acquired only when the target object for privilege checking matches the target object for the event. If you acquire audit trails by narrowing down by object, Hitachi recommends that you acquire audit trails at the time of event termination. Table 22-25 shows whether or not there is output from privilege checking when trails are narrowed down by object.

Table 22-25 Whether or not there is output from privilege checking when trails are narrowed by object

Privilege used | Whether or not there are objects | Objects that can be narrowed
DBA | No | None
SCH | No | None
CNT | No | None
RDA | Yes (RDA) | Objects listed at left
SEL | Yes (FTB, LST, TBL, VIW) | Objects listed at left
INS | Yes (FTB, TBL, VIW) | Objects listed at left
DEL | Yes (FTB, TBL, VIW) | Objects listed at left
UPD | Yes (FTB, TBL, VIW) | Objects listed at left
AUD | No | None*
SYS | Yes (AUF, TBL) | --
OWN | Yes (FID, FNC, FSV, FTB, IDX, PRC, SCH, TBL, TRG, TYP, VIW) | Objects listed at left

Legend:

--: If the audit facility is executing, audit trails are always output regardless of the audit event definition.

Note:

For details about the privileges that are used and the symbols for indicating whether or not there is an object, see Table 22-15 Audit trail table column.

*

In the case of an auditor's security event, if the security audit facility is executing, audit trails are always output regardless of the audit event definition.

If you have specified a data dictionary table for the target object, specify the object type, authorization identifier, and table identifier as described in Table 22-26.

Table 22-26 Object type, authorization identifier, and table identifier when a data dictionary table is specified

Operation type | Object type | Authorization identifier | Table identifier
Object operation event | VIEW | MASTER | Table identifiers of the data dictionary tables, excluding the data dictionary tables used by the system
Utility operation event | TABLE | Omitted* | Table identifiers of all data dictionary tables

*

Even when the authorization identifier is omitted, '(Data dictionary)' is stored in the object owner column in the data dictionary table SQL_AUDITS.

(2) Available selections

The following selections are available:

For each CREATE AUDIT, you can combine desired selection items (operation type, trail type, event success/failure, and object) to create a single audit event definition. The AND condition applies to these selection items. Note that specification of an object is optional.

For each CREATE AUDIT, you can specify only one of operation type, trail type, event success/failure, or object. To specify multiple values for each of these items, execute as many CREATE AUDIT statements as there are values. If multiple audit event definitions are created, the OR condition applies to the audit event definitions, in which case an audit trail that satisfies any of the audit event definitions is acquired.

To acquire audit trails when the target of an object operation event is the table "USER1"."T1" and the target of the audit is the termination trail of an object definition event, define as follows:

CREATE AUDIT AUDITTYPE EVENT FOR ACCESS ON TABLE "USER1"."T1"
CREATE AUDIT AUDITTYPE EVENT FOR DEFINITION

The following describes the trails that are acquired and the trails that are not when the above audit event is defined:

Trails that are acquired:

Event termination trail when the table "USER1"."T1" is searched

Event termination trail when the CREATE statement is executed

Trails that are not acquired:

Trail when a table other than "USER1"."T1" is searched

Trail of a connection event

Trail of a utility operation event

(3) Combinations of selection items

Some combinations of selection items serve no purpose. For such a combination of selection items, the executed CREATE AUDIT results in an error.

An example is when the object table "USER1"."T1" is specified in CONNECT for a session security event.

(4) Security audit information buffer

To use the security audit facility, a security audit information buffer is required. Therefore, you must estimate the shared memory requirement for the security audit information buffer.

You can do this by estimating manually the specification value and then specifying the value in the pd_audit_def_buffer_size operand, or by having the system determine the value automatically (omit the pd_audit_def_buffer_size operand). When the system determines the value, a margin is added to the memory size to ensure sufficient space. The memory size required is determined by the number of entries of the object that is the target of the narrowed audit. Thus, to determine the size of memory to allocate, the system both adds the value 100 to the number of entries for the object that has been defined, and also multiplies this number of entries by 1.2. It then applies the higher of the two results as the size of memory to allocate. The following shows the margin value:

Number of entries for an object that has already been defined as the target of a narrowed audit | Condition | Margin value
0 | None | Value for 100 entries for the object that is the target of the narrowed audit
1 or greater | N + 100 > 1.2 | Value for 100 entries for the object that is the target of the narrowed audit
N + 100 N 1.2 | Value for N 0.2 entries

Legend:

N: Number of entries for the object that has already been defined as the target of the narrowed audit

If the required amount of memory cannot be allocated when the security audit information buffer is created, the actions described in Tables 22-27 and 22-28 must be taken.

Note

If the security audit information buffer cannot store definition information for all audit events, processing may slow down because accesses must be made to the data dictionary table.

Table 22-27 HiRDB operation and actions to be taken when security audit information buffer is created (during HiRDB startup)

pd_audit_def_buffer_size operand specification
Allocation of shared memory
HiRDB operation
Action

Specified
Failure
Does not start. In this case, HiRDB displays the KFPD00031-E message.
Take one of the following actions:

Increase the OS's shared memory size.

Provide free space in the OS's shared memory.

Decrease the pd_audit_def_buffer_size operand value.

Success
Starts. If the definition information for all the audit events is not stored in the security audit information buffer, HiRDB displays the KFPD00032-W message.
Because performance may decline, re-estimate the pd_audit_def_buffer_size operand value.

Omitted
Failure
Starts, but does not create the security audit information buffer. In this case, HiRDB displays the KFPD00032-W message.
Because performance may decline, take one of the following actions:

Increase the OS's shared memory size.

Provide free space in the OS's shared memory.

If neither of the above actions can be taken, specify a value in the pd_audit_def_buffer_size operand that is less than the value determined automatically by the system.

Success
Starts.
No action is required.

Table 22-28 HiRDB operation and actions to be taken when security audit information buffer is created (during HiRDB operation)

pd_audit_def_buffer_size operand specification
Overflow of definition information for audit event in security audit information buffer
HiRDB operation
Action

Specified
Yes
Stores as much definition information for audit events as possible in the security audit information buffer and then resumes processing. In this case HiRDB displays the KFPD00032-W message.
Re-estimate the value of the pd_audit_def_buffer_size operand according to the displayed KFPD00032-W message. If no action is taken, performance may decline.

No
Stores the definition information for all the audit events in the security audit information buffer and then resumes processing.
No action is required.

Omitted
Yes
Stores as much definition information for audit events as possible in the security audit information buffer and then resumes processing. In this case HiRDB displays the KFPD00032-W message.
Restart HiRDB. The system re-calculates the size and creates a security audit information buffer. If the KFPD00032-W message is displayed when HiRDB restarts, take one of the following actions:

Increase the OS's shared memory size.

Provide free space in the OS's shared memory.

If neither of the above actions can be taken, specify a value in the pd_audit_def_buffer_size operand that is less than the value determined automatically by the system.

No
Stores the definition information for all the audit events in the security audit information buffer and then resumes processing.
No action is required.

When the pd_audit_def_buffer_size operand is omitted, the specification value is determined automatically by the system. If definitions of audit events increase during HiRDB operation, the size of the security audit information buffer increases the next time HiRDB starts. This means that the size of the security audit information buffer may increase each time HiRDB is started.

(5) HiRDB operation in the event of an error in the security audit information buffer

This subsection describes HiRDB's operation in the event of an error in the security audit information buffer.

(a) At HiRDB startup

The security audit information buffer is created when HiRDB starts. If an error occurs, the HiRDB operation depends on whether the size of the security audit information buffer is being determined automatically by the system or manually by the user.

When the system determines the size automatically
HiRDB displays a message and starts operation with the size of the security audit information buffer set to 0 (security audit information buffer is not created). However, in the case of a dictionary access error (rollback is required), the HiRDB operation is as follows:

For a HiRDB/Single Server:

In the case of an error, such as a disk failure, HiRDB displays a message and immediately terminates abnormally (unit shutdown), because it would most likely be impossible to continue operation when the definition information for audit events cannot be acquired after starting operation.

For a HiRDB/Parallel Server:

HiRDB retries creation of the security audit information buffer a specified number of times, because the dictionary server may have not started. If the error remains after the specified number of retries, HiRDB places the front-end server in SUSPEND status.

When the user determines the size manually
HiRDB displays a message and then resumes processing. However, if the specified shared memory size cannot be allocated for the security audit information buffer, HiRDB displays a message and immediately terminates abnormally (unit shutdown).

Table 22-29 describes the causes of errors during HiRDB startup and the HiRDB operations.

Table 22-29 Causes of errors during HiRDB startup and HiRDB operations

Cause of error | HiRDB operation
pd_audit_def_buffer_size operand is omitted | pd_audit_def_buffer_size operand is specified
Area allocation error | Shared memory for buffer | Starts with size 0 | Cannot start
Process private memory for dictionary search | Starts with size 0 | Allocates shared memory and then resumes processing
Communication error | Starts with size 0 | Allocates shared memory and then resumes processing
Dictionary access error | Rollback is not required | Starts with size 0 | Allocates shared memory and then resumes processing
Rollback is required | Cannot start* | Allocates shared memory and then resumes processing

*

For a HiRDB/Parallel Server, if the error cannot be corrected after the specified number of restart attempts, HiRDB places the front-end server in SUSPEND status.

For a HiRDB/Single Server, HiRDB immediately terminates abnormally.

(b) During HiRDB operation

If an error occurs while HiRDB is checking the definition information for audit events, HiRDB outputs the corresponding audit trail regardless of the definition of audit events.

If an error occurs during SQL execution, HiRDB also outputs audit trails. In this case, an error may also occur when the definition information for an audit event is acquired during output of an audit trail. Table 22-30 describes the combinations of errors, the SQL codes to be set, and whether or not rollback is required. If an error occurs during output of audit trails, HiRDB ignores that error and resumes processing.

Table 22-30 Combinations of errors, SQL codes to be set, and whether or not rollback is required

Status before acquisition of audit event definition | Status during acquisition of audit event definition | SQL code to be set | Whether or not rollback is required
Normal | Normal | 0 | No
Error requiring rollback | SQL code during acquisition of audit event definition | Yes
Error not requiring rollback | SQL code before acquisition of audit event definition | No
Error requiring rollback | Normal | SQL code before acquisition of audit event definition | Yes
Error requiring rollback | SQL code before acquisition of audit event definition | Yes
Error not requiring rollback | SQL code before acquisition of audit event definition | Yes
Error not requiring rollback | Normal | SQL code before acquisition of audit event definition | No
Error requiring rollback | SQL code before acquisition of audit event definition | Yes
Error not requiring rollback | SQL code before acquisition of audit event definition | No

(6) Change of security audit information buffer status

When an event occurs, the status of the security audit information buffer changes, such as from disabled to enabled. The following table shows the changes in the security audit information buffer status when an event occurs.

Event
Status of security audit information buffer

Initial status
(before HiRDB start)
Disabled status
(no information has been set)
Enabled status
(information has been set)
Disabled status
(old information remains)

1
2
3
4

Completion of HiRDB startup processing
2
--
--
--

Access to security audit information buffer
--
3
3
3

Change to audit event definition
(execution of CREATE AUDIT or DROP AUDIT)
--
2
4
4

Legend:

n: When the event occurs, the security audit information buffer is placed in the status indicated by the number n.

--: Not applicable

22.10 Audit trail file error handling

Organization of this section

(1) When an error occurs in an audit trail file

(2) When an error occurs in the HiRDB file system area used for audit trail files (when all audit trail files are in shutdown status)

(3) When HiRDB is terminated forcibly because there are no swappable target audit trail files

(1) When an error occurs in an audit trail file

When an error occurs in an audit trail file, the file is placed in shutdown status. An audit trail file in shutdown status cannot be used except to be deleted. Take action according to the following procedure:

Procedure

Identify the audit trail file in shutdown status from the KFPS05704-E message.
You can use the pdls -d aud command to identify the generation in which the error occurred. If HiRDB is running, the auditor executes the pdls -d aud command.

Use the pdaudrm command to delete the audit trail files in shutdown status. To delete forcibly the files in data load waiting status, specify the -f option.

Files in shutdown status cannot be data loaded. Therefore, if they are not data loaded, the entire audit trail will be lost.

(2) When an error occurs in the HiRDB file system area used for audit trail files (when all audit trail files are in shutdown status)

This explains the procedure when an error has occurred in the HiRDB file system area used for audit trail files, causing all audit trail files to be placed in shutdown status.

The HiRDB processing depends on the value of the pd_aud_no_standby_file_opr operand. If down is specified, HiRDB (or unit for a HiRDB/Parallel Server) is terminated forcibly. If forcewrite (default) is specified, audit trail output stops, but HiRDB continues in operation. The HiRDB administrator uses the procedure explained below.

Procedure

If HiRDB is operating, use the pdstop command to terminate HiRDB normally. If normal termination is not possible, use the pdstop -f command to terminate HiRDB forcibly.

Use the pdfmkfs command to re-create the file system area for audit trail files. If the HiRDB file system area cannot be used due to a fault such as s disk error, create another HiRDB file system area for audit trail files on a different disk.

If you changed the file system area for the audit trail files, also change the specification of the pd_aud_file_name operand.

If there is a backup of the file system area for audit trail files, use the pdfrstr command to recover the HiRDB file system area.

Use the pdstart command to start HiRDB.

(3) When HiRDB is terminated forcibly because there are no swappable target audit trail files

If down is specified in the pd_aud_no_standby_file_opr operand and only one swappable file remains, terminate HiRDB forcibly (for a HiRDB/Parallel Server, terminate the unit). The HiRDB administrator uses the procedure explained below.

(a) For a HiRDB/Single Server

Select one of the following procedures:

Procedure 1: When pd_aud_max_generation_num < 200

Specify 200 for the pd_aud_max_generation_num operand.

Use the pdstart command to start HiRDB.

Use the pdload command to data load the files in data load waiting status.

Procedure 2: When pd_aud_max_generation_num = 200

Specify N in the pd_audit operand.

Use the pdstart command to start HiRDB.

Use the pdload command to data load the files in data load waiting status.

Use the pdaudbegin command to start collection of the audit trail.

(b) For a HiRDB/Parallel Server

Select one of the following procedures:

Procedure 1: When pd_aud_max_generation_num < 200

Use the pdstop -f command to terminate HiRDB forcibly.

Specify 200 for the pd_aud_max_generation_num operand.

Use the pdstart command to start HiRDB.

Use the pdload command to data load the files in data load waiting status.

Procedure 2: When pd_aud_max_generation_num = 200

Use the pdstop -f command to forcibly terminate HiRDB.

Specify N in the pd_audit operand.

Use the pdstart command to start HiRDB.

Use the pdload command to data load the files in data load waiting status.

Use the pdaudbegin command to start collection of the audit trail.

22.11 Linkage with other facilities

This section explains security audit facility linkage with other facilities.

Organization of this section

(1) Linkage with the system switchover facility

(2) Linkage with plug-ins

(3) Linkage with the inner replica facility

(4) Linkage with the HiRDB External Data Access facility

(1) Linkage with the system switchover facility

Whether or not audit trail collection is inherited by the switchover target system is determined from the termination mode of the switching HiRDB. If the switching system is restarted, the status before system switchover is inherited. If the switchover target system terminates normally, it follows the specification of the pd_audit operand.

If the system switchover facility is used in the monitor mode, an audit trail is collected when system switchover occurs and the standby HiRDB system (the standby unit for a HiRDB/Parallel Server) is started. An audit trail is not collected when system switchover occurs in server mode.

If system switchover occurs due to an error, HiRDB does not correctly collect the audit trail before the switchover.

(2) Linkage with plug-ins

If the pdplgrgst command is used to register, delete, or upgrade plug-ins with HiRDB, HiRDB uses the pdplgrgst command extension to issue the following SQL statements:

CREATE statements for functions, abstract data types, or indexes provided by the plug-ins

DELETE statements for the plug-in definition information stored in the dictionary tables

DROP statements for functions, abstract data types, or indexes provided by the plug-ins

If audit events are set for these SQL statements, an audit trail is collected for these SQL statements using the pdplgrgst command extension.

(3) Linkage with the inner replica facility

An audit trail is not collected for pair volumization (disk duplexing). Use the OS's auditing facility to audit pair volumization.

(4) Linkage with the HiRDB External Data Access facility

An audit trail is collected for SQL statements used by the HiRDB External Data Access facility.

22.12 Audit trail record items (during privilege checking)

The audit trail record items during privilege checking are described below.

The record items for User identifier through Process ID are described in Part 1; the record items for Thread ID through SQL code/termination code is described in Part 2, and the record items for Name of swapping source audit trail file and subsequent are described in Part 3.

For details about the event types and subtypes, see Table 22-16 Event types and subtypes. For details about the privileges that were used, see USED_PRIVILEGE in Table 22-15 Audit trail table columns.

Audit trail record items during privilege checking (part 1)

Audit trail record items during privilege checking (part 2)

Legend:

Y: Information is collected.

S: Information is collected sometimes via the XA interface.

: Information is not collected; or, not applicable.

ACS: Number of privileges specified (4 if all is specified).

ATB: Number of audit trail tables created with the pdmod command (1 if audit trail tables were created; 0 if audit trail tables were not created).

AUD: Number of auditors created with the pdmod command (1 if auditors were created; 0 if auditors were not created).

CLS: 1 if FOR CLUSTER KEY clause is specified; 0 if it is not specified.

FNC: Number of functions to be re-created.

IDX: Number of related indexes.

PRC: Number of procedures to be re-created.

PRM: 1 if FOR PRIMARY KEY clause is specified; 0 if it is not specified.

RDA: Number of RDAREAs specified.

RLB: Number of RDAREAs for LOB data.

RID: Number of index RDAREAs.

TBL: Number of tables specified by a SELECT statement, SELECT clause, or LOCK statement, or the number of tables to be processed by a utility.

TRG: Number of triggers to be re-created.

USR: Number of specified users or groups.

VIW: Number of target view tables.

¹ When the SQL type is SELECT, INSERT, UPDATE, or DELETE, usage privilege is also checked during pre-processing by a PREPARE statement and an audit trail is collected. As a result, the number of output records is doubled. The timing for usage privilege checking is described below. The underlined SQL statements check usage privilege and collect an audit trail.

When the SQL type is SELECT

When preprocessing by a PREPARE statement is not performed

 EXEC SQL DECLARE C1 CURSOR FOR SELECT * FROM T1;
 EXEC SQL OPEN C1;

When preprocessing by a PREPARE statement is performed

 EXEC SQL PREPARE S1 FROM 'SELECT * FROM T1';
 EXEC SQL DECLARE C1 CURSOR FOR S1;
 EXEC SQL OPEN C1;

When the SQL type is INSERT (same for UPDATE and DELETE)

When preprocessing by a PREPARE statement is not performed

 EXEC SQL INSERT INTO T1(C1) VALUES(1);

When preprocessing by a PREPARE statement is performed

 EXEC SQL PREPARE S1 FROM 'INSERT
                     INTO T1(C1) VALUES(?)';
 EXEC SQL EXECUTE S1 FOR:data;

² Applies to cases in which a table is not or cannot be recognized as an audit trail table.

³ When the target object is a public view table, PUBLIC is output as the object owner.

⁴ When a base table is a view table or public view table, the record count is increased for each real table or foreign table that is used as the base table.

22.13 Audit trail record items (at event termination)

The audit trail record items at event termination are described below.

The record items for User identifier through Process ID are described in Part 1; the record items for Thread ID through SQL code/termination code is described in Part 2, and the record items for Name of swapping source audit trail file and subsequent are described in Part 3.

For details about the event types and subtypes, see Table 22-16 Event types and subtypes. For details about the privileges that were used, see USED_PRIVILEGE in Table 22-15 Audit trail table columns.

Audit trail record items at event termination (part 1)

Audit trail record items at event termination (part 2)

Legend:

Y: Information is collected.

S: Information is collected sometimes via the XA interface.

: Information is not collected; or, not applicable.

ACS: Number of privileges specified (4 if all is specified).

ALS: Number of target table aliases.

ATB: Number of audit trail tables created with the pdmod command (1 if audit trail tables were created; 0 if audit trail tables were not created).

AUD: Number of auditors created with the pdmod command (1 if auditors were created; 0 if auditors were not created).

CLS: 1 if FOR CLUSTER KEY clause is specified; 0 if it is not specified.

FNC: Number of functions to be re-created.

IDX: Number of related indexes.

PRC: Number of procedures to be re-created.

PRM: 1 if FOR PRIMARY KEY clause is specified; 0 if it is not specified.

RDA: Number of RDAREAs specified.

RLB: Number of RDAREAs for LOB data.

RID: Number of index RDAREAs.

SPR: Number of changed connection security facility settings.

TBL: Number of tables specified by a SELECT statement, SELECT clause, or LOCK statement, or the number of tables to be processed by a utility.

TRG: Number of triggers to be re-created.

USR: Number of specified users or groups.

VIW: Number of target view tables.

¹ When the target object is a public view table, PUBLIC is output as the object owner.

² A foreign server name is output as the user mapping object name. PUBLIC is output as the event target user identifier.

³ If a WITH clause is used, the object type is output as follows:

WITH Q1(C1) AS (SELECT C1 FROM AAA) SELECT C1 FROM BBB

Type | AAA | BBB
Base table | TBL | TBL
Foreign table | FTB | FTB
View table | VIW | VIW
Query name | Not output | Not output

Note

If an error occurs before the type can be determined, TBL is output for all items.

⁴ Applies to cases in which a table is not or cannot be recognized as an audit trail table.

22.14 Audit trail output destination unit during utility execution (HiRDB/Parallel Server only)

This section explains the output destination unit of an audit trail that is output during utility execution. Tables 22-31 and 22-32 show the output destination units of audit trails that are output during utility execution.

Table 22-31 Audit trail output destination unit during utility execution (Part 1)

Condition following utility execution | Audit trail output destination unit
Normal termination | See Table 22-32 for the audit trail output destination unit.
Abnormal termination | After utility server startup
Before utility server startup | Audit trail is output to the unit where the command was entered.

Table 22-32 Audit trail output destination unit during utility execution (Part 2)

Utility
Execution-target object
Output destination unit

At event termination
During privilege checking

pdload
In table units
Base table only
Unit where the input file is located
Unit where the command was entered

Base table + BLOB

BLOB only

In RDAREA units
Base table only

Base table + BLOB

BLOB only

pdrorg
-k rorg
-k unld
-k reld
-g option specified

Unit where the unload file was created
Unit where the command was entered

-g option not specified
Dictionary table reorganization
Unit where the dictionary server is located

User table reorganization
Table reorganization
Unit where the unload file was created

Row- partitioned table
Reorganization in RDAREA units

Reorganization in table units
Unit where the server specified in the first unload or lobunld statement specified is located

-k ixrc

Unit where the command was entered

-k ixor

-k ixmk

pdexp,
pddefrev

Unit where the export file is located
Unit where the export file is located

pdconstck

Unit where the command was entered
Unit where the command was entered

Legend:

: Not applicable

22.15 Notes on version upgrading

This section provides notes about version upgrading when the security audit facility is used. For details about version upgrading, see the manual HiRDB Version 8 Installation and Design Guide.

Organization of this section

(1) When the audit trail format for audit trail files is changed

(2) When the column structure of the audit trail table is changed

(3) When the number of audit trail events increases

(4) Notes on version-upgrading failure

(5) Backing up the RDAREAs that store an audit trail table

(1) When the audit trail format for audit trail files is changed

If version upgrading changes the audit trail format for audit trail files, take the following action before version upgrading:

Use the pdaudswap command to swap audit trail files and use the pdload command to register the content of the file before swapping in the audit trail table.

Reference note

Because there are no triggers for output of an audit trail during HiRDB termination and for swapping audit trail files before HiRDB starts after a version upgrade, an audit trail in the old format collected during HiRDB termination and an audit trail in the new format collected during HiRDB startup will both exist in the same file. For this reason, HiRDB is designed to permit you to load data into the audit trail table even when audit trails in old and new formats coexist in the same file.

(2) When the column structure of the audit trail table is changed

Version upgrading may add columns to the audit trail table. The column structure of the audit trail table can be changed by HiRDB by executing the pdvrup command. If data already exists in the audit trail table, NULL values are set in the added columns.

(3) When the number of audit trail events increases

If version upgrading increases the number of audit trail events, the volume of audit trail output may increase. Therefore, before version upgrading, re-estimate the size required on the disk that stores audit trail files.

This is applicable when audit trails are to be output for all events (CREATE AUDIT FOR ANY is specified). In such a case, if version upgrading increases the number of new events (such as utility manipulation events), audit trails are also collected for the utility manipulation events.

If you do not wish to collect an audit trail for a newly added audited event, do not use CREATE AUDIT FOR ANY when defining audit trail collection. Instead, define individual audit trails (CREATE AUDIT FOR SESSION, CREATE AUDIT FOR PRIVILEGE, ...).

(4) Notes on version-upgrading failure

Execute the pdload command only after version upgrading succeeds. If this command is executed before version upgrading succeeds, the following problems may arise:

Upgrading to version 07-02 or later from a version earlier than 07-02 (but later than version 07-00)
When HiRDB is started after version upgrading, an audit trail in the new format is output to the audit trail file. If the older version is restored from this status, and then the pdload command is used to register an audit trail in the audit trail table, correct operation cannot be guaranteed. In such a case, after the older version has been restored, use the pdfmkfs command to initialize the HiRDB file system area for audit trail files.

Upgrading from version 07-02 or later
In 07-02 or later versions, if the format of the audit trail that is output does not match the format supported by the applicable version, the KFPS05753-W message is output and the audit trail is deleted.

(5) Backing up the RDAREAs that store an audit trail table

Before version upgrading, make a backup of the RDAREAs that store an audit trail table. If version upgrading fails and you need to revert to the older version, restore the RDAREAs that store the audit trail table from the backup.

If no backup was made, use DROP TABLE to delete the audit trail table, then use the pdmod command to re-create the audit trail table. In this case, the data stored in the audit trail table is deleted.

23. Using the Connection Security Facility

This chapter explains how to use the connection security facility, which is designed to enhance the security of HiRDB systems.

Organization of this chapter

23.1 Overview of the connection security facility

23.2 Setting password character string restrictions

23.3 Changing a password character string restriction

23.4 Releasing the password-invalid account lock state

23.5 Checking for users who will be placed in password-invalid account lock state

23.6 Privilege granting or revocation for users in password-invalid account lock state

23.7 Cancelling the password character string restrictions

23.8 Relationships between password character string restrictions and other facilities

23.9 Setting and cancelling the limit on number of consecutive certification failures

23.10 Checking for users in consecutive certification failure account lock state

23.11 Releasing consecutive certification failure account lock state

23.12 Notes on using the connection security facility

23.1 Overview of the connection security facility

This section provides an overview of the connection security facility. The following items are explained.

About the connection security facility

Password character string restrictions

Limit on the number of consecutive certification failures

Organization of this section

23.1.1 About the connection security facility

23.1.2 Password character string restrictions

23.1.3 Limit on the number of consecutive certification failures

23.1.1 About the connection security facility

One of the means of enhancing system security is to use passwords. HiRDB can set up a password for each user. However, if a simple password that can be easily guessed is used (for example, using the person's authorization identifier or birth date as the password), there is a heightened risk that an unauthorized user may be able to guess the password and infiltrate the system. To minimize the possibility of unauthorized use of passwords, Hitachi recommends that you use the connection security facility. Table 23-1 provides an overview of the connection security facility.

Table 23-1 Overview of the connection security facility

Functions
Explanation

Password character string restrictions
You can set up restrictions on the character strings used as passwords. For example, you can prohibit passwords such as AAAAA or zzzzz. Prohibiting simple passwords enhances password security.

Limit on the number of consecutive certification failures
When a user enters an invalid password, certification of that user fails and the user is not connected to HiRDB. If user certification fails more than a certain number of times in succession, HiRDB can be set to deny to that user the right to connect to HiRDB. For this purpose, a limit is set on the number of consecutive failures permitted to achieve user certification, and anytime a user exceeds the limit, the user is barred from connecting to HiRDB.
For example, the limit could be set so that denial of connection rights to HiRDB will be implemented whenever a user enters an invalid password more than three times in a row.

Use of both of these functions makes unauthorized access based on guessing at a password more difficult, resulting in enhanced security.

Note

You cannot use the Directory Server linkage facility and the connection security facility at the same time. If you use the Directory Server linkage facility, you must disable the settings for the connection security facility.

23.1.2 Password character string restrictions

Organization of this subsection

(1) Restrictions that can be set for passwords

(2) Effect on existing users

(3) Effect on new users

(4) Setting method

(1) Restrictions that can be set for passwords

Table 23-2 explains the restrictions that can be set for passwords.

Table 23-2 Restrictions that can be set for passwords

Item | Explanation
Specifiable minimum in bytes | You can specify a minimum number of bytes that must be used for a password.
Prohibition on use of the authorization identifier | You can prohibit use of a person's authorization identifier in his or her password character string.
Prohibition on use of only one type of characters* | You can prohibit the use of only one type of characters in a password, such as only upper-case letters or only lower-case letters.

* The characters that can be specified for passwords can be classified into the following three types:

Uppercase letters (A-Z, #, @, \)

Lowercase letters (a-z)

Numbers (0-9)

Hint

You cannot specify separate password character string restrictions for different users. The specified password character string restrictions will apply uniformly to all HiRDB users (including users with the DBA privilege and the auditor).

Reference note

Whether or not this facility is used, the following specification rule applies to passwords:

A password can consist of alphanumeric characters, but must begin with an alphabetic character.

(2) Effect on existing users

When password character string restrictions are first established, any user whose existing password does not conform to the restrictions is placed in what is called password-invalid account lock state. A user placed in this status can no longer connect to HiRDB.

To release a user from password-invalid account lock state, the user's password must be changed. For details about changing a password, see 23.4.1 Releasing individual users from password-invalid account lock state.

Before establishing password character string restrictions, you can determine how many users will be placed in password-invalid account lock state because of the restrictions. For details about determining the number of such users, see 23.5 Checking for users who will be placed in password-invalid account lock state.

(3) Effect on new users

GRANT DBA, GRANT AUDIT, or GRANT CONNECT is used to set a password for a new user. If that password violates a restriction, execution of the GRANT statement will not be successful.

(4) Setting method

You use CREATE CONNECTION SECURITY to set password character string restrictions. For details about the setting procedure, see 23.2 Setting password character string restrictions.

For details about password character string restrictions, see sections 23.2 through 23.8 and 23.12.

23.1.3 Limit on the number of consecutive certification failures

Organization of this subsection

(1) Limits that can be set

(2) How to count the number of failures

(3) Setting method

(4) Required RDAREA

(1) Limits that can be set

When a user enters an invalid password, certification of that user fails and the user is not connected to HiRDB. If user certification fails more than a certain number of times in succession (permitted number of consecutive certification failures), HiRDB can be set to deny connection rights to HiRDB to that user.

For example, if the permitted number of consecutive certification failures is set to 3, a user who fails user certification four times in a row as a result of entering an invalid password is placed in consecutive certification failure account lock state. A user who is placed in this status no longer has the right to connect to HiRDB.

Reference note

You cannot specify separate limits on the permitted number of consecutive certification failures for different users. The specified limit will apply to all HiRDB users (including users with the DBA privilege and the auditor).

You can also specify the period during which a user is to be kept in consecutive certification failure account lock state; this is called the account lock period. For example, if the account lock period is set to 1 (hour), a consecutive certification failure account lock state remains in effect for a user for one hour. When the hour has passed, the consecutive certification failure account lock state is cancelled and the user is again permitted to attempt to connect to HiRDB.

Reference note

You can also set the account lock period to be permanent (to not expire automatically).

You can cancel a consecutive certification failure account lock state before the account lock period has expired. For details about the cancellation procedure, see 23.11 Releasing consecutive certification failure account lock state.

(2) How to count the number of failures

Only entry of up to 30 bytes of an invalid password is counted as a failure. The following situations do not constitute a failure:

Entry of an invalid authorization identifier (specifying a non-existent authorization identifier).

Entry of more than 30 bytes for a password.

Reference note

The count of consecutive certification failures is not reset to 0 even if the user waits for a while. For example, if a user fails once, then fails again after waiting for an hour, the count of consecutive certification failures increments to 2.

The count of consecutive certification failures is not reset to 0 even when HiRDB terminates.

The count of consecutive certification failures remains valid even if the user attempts to connect from a different client machine. For example, if a user fails once from machine A and then fails from machine B, the count of consecutive certification failures increments to 2.

The count of consecutive certification failures remains valid even if the user tries to connect from a different front-end server. For example, if a user fails once from front-end server A and then fails from front-end server B, the count of consecutive certification failures increments to 2.

Command and utility executions are also counted.

When the consecutive certification failure account lock state is cancelled, the count of consecutive certification failures is reset to 0.

(3) Setting method

You use CREATE CONNECTION SECURITY to set the limit on the number of consecutive certification failures. For details of the setting procedure, see 23.9 Setting and cancelling the limit on number of consecutive certification failures.

For details about applying the limit on number of consecutive certification failures, see sections 23.9 through 23.12.

(4) Required RDAREA

When this facility is used, the system-defined ADD_INTERVAL scalar function is used to check for the consecutive certification failure account lock state. For this reason, a data dictionary LOB RDAREA is required; if no data dictionary LOB RDAREA is available, you must create one.

23.2 Setting password character string restrictions

Executor: DBA privilege holder

This section explains the procedure for initial set-up of password character string restrictions. You must perform the steps in the order they are shown below, beginning with step (1).

Organization of this section

(1) Evaluate the restrictions that can be set for passwords

(2) Check for users who will be in violation of the specified restrictions

(3) Change passwords

(4) Set the password character string restrictions

(5) Check for users in password-invalid account lock state

(1) Evaluate the restrictions that can be set for passwords

You should evaluate the restrictions that can be set for passwords. The items you should consider are shown in Table 23-3.

Table 23-3 Restrictions that can be set for passwords

Restriction
Explanation

Specifiable minimum in bytes
Specify in bytes the minimum number of characters that can be used for a password. The specifiable range of the minimum number of characters for a password is between 6 and 15.

Prohibition on use of the authorization identifier
Specify whether or not inclusion of the person's authorization identifier in the password character string is to be prohibited. If prohibition is specified, the following passwords would be prohibited:

Examples of prohibited passwords when the authorization identifier is K001:

K001, abK001, K00165, GTK001KL

Prohibition on use of only one type of characters
Specify whether or not use of only one type of characters for a password is to be prohibited. If prohibition is specified, the following passwords would be prohibited:

Examples of prohibited passwords:

HUDGTX, jkfgytud, D@MK#B\

(2) Check for users who will be in violation of the specified restrictions

You should check in advance for existing users whose existing password will not conform to the proposed restrictions. Because the nonconforming users will be placed in password-invalid account lock state, they will no longer be permitted to connect to HiRDB. Before establishing restrictions, you should identify the users whose existing password will be in violation of the restrictions. For details about the identification procedure, see 23.5 Checking for users who will be placed in password-invalid account lock state.

Reference note

Setting up password character string restrictions may cause some users to be placed in password-invalid account lock state. You should notify all users in advance about the imminent establishment of password restrictions, and inform them that they may have to change their password before the implementation date. Once the implementation date arrives, check for users who are in violation of the restrictions and contact them.

(3) Change passwords

Use a GRANT statement to change the password of a user whose existing password does not conform to the password restrictions. Examples follow:

Example 1

Change the password of USER01 to f51HD7tc:

GRANT CONNECT TO USER01 IDENTIFIED BY "f51HD7tc"

Reference note

Each user can change his or her own password. Passwords can also be changed by a DBA privilege holder.

Example 2

Change the password of DBA privilege holder ADMIN01 to gd4A@sPL:

GRANT DBA TO ADMIN01 IDENTIFIED BY "gd4A@sPL"

Example 3

Change the auditor's password to a0h7Fc3K:

GRANT AUDIT IDENTIFIED BY "a0h7Fc3K"

(4) Set the password character string restrictions

Use CREATE CONNECTION SECURITY to set the desired password character string restrictions.

Note

If the password of a DBA privilege holder or of the auditor does not conform to the restrictions (even if that is the only person whose password does not conform), execution of CREATE CONNECTION SECURITY will not be successful.

An example of specifying CREATE CONNECTION SECURITY follows:

Example

The following password character string restrictions are to be set:

The minimum number of bytes for a password is to be set to 8.

Inclusion of the authorization identifier in the password is to be prohibited.

Use of only one type of characters in a password is to be prohibited.

CREATE CONNECTION SECURITY
   FOR PASSWORD
     MIN LENGTH 8                  ...1
     USER IDENTIFIER RESTRICT      ...2
     SIMILAR RESTRICT              ...3

Explanation

Sets that each password must be at least 8 bytes in length.

Prohibits inclusion of the user's authorization identifier in his or her password. To prohibit, specify RESTRICT; to not prohibit, specify UNRESTRICT.

Prohibits use of only one type of characters in a password. To prohibit, specify RESTRICT; to not prohibit, specify UNRESTRICT.

(5) Check for users in password-invalid account lock state

Check for users in password-invalid account lock state. For the checking procedure, see 23.4.1(1) Check for users in password-invalid account lock state.

23.3 Changing a password character string restriction

This section explains the procedure for changing a password character string restriction.

Organization of this section

23.3.1 Special notes on changing password character string restrictions

23.3.2 Procedure for changing a password character string restriction

23.3.1 Special notes on changing password character string restrictions

Organization of this subsection

(1) Relaxing a password character string restriction

(2) Strengthening one restriction while relaxing another

(1) Relaxing a password character string restriction

When there are users in password-invalid account lock state, relaxing a password character string restriction may release some users from the password-invalid account lock state. Before changing password character string restriction, make sure it is acceptable to release these users from the password-invalid account lock state.

The following is the procedure for identifying the users who will be released from the password-invalid account lock state:

Procedure

Check for users in the password-invalid account lock state. For the checking procedure, see 23.4.1(1) Check for users in password-invalid account lock state.

Perform an advance check of the restriction that is being considered. For the procedure for checking in advance, see 23.5 Checking for users who will be placed in password-invalid account lock state.

Identify the applicable users based on the differences in the results from steps 1 and 2.

(2) Strengthening one restriction while relaxing another

Care must be exercised in strengthening one restriction while relaxing another restriction. For example, a user may attempt to change a password before the implementation date in order to avoid violation of a new restriction. However, the user may not be able to make the change because it violates the current restriction. In such a case, the password must be changed so that it satisfies both the current and the proposed restrictions.

23.3.2 Procedure for changing a password character string restriction

Executor: DBA privilege holder

This section explains the procedure for changing a password character string restriction. You must perform the steps in order they are shown below, beginning with step (1).

Organization of this subsection

(1) Check the restrictions that are currently in force

(2) Evaluate the restrictions to be set for passwords

(3) Check for users who will be in violation of the specified restrictions

(4) Change passwords

(5) Change the password character string restrictions

(6) Check for users in password-invalid account lock state

(1) Check the restrictions that are currently in force

Information on the password character string restrictions that have been specified is stored in the SQL_SYSPARMS dictionary table. To determine the restrictions that are currently in effect, search SQL_SYSPARMS and check the specification information on password character string restrictions. An example of such a search follows:

Example

Check the password restrictions that are currently in effect:

SELECT FUNCTION_KEY,PARAM_KEY,INT_VALUE,CHAR_VALUE
   FROM MASTER.SQL_SYSPARAMS
     WHERE FUNCTION_KEY='PASSWORD'

Execution results

FUNCTION_KEY   PARAM_KEY        INT_VALUE  CHAR_VALUE
------------------------------------------------
PASSWORD       MIN_LENGTH       8          8
PASSWORD       USER_IDENTIFIER  NULL       RESTRICT
PASSWORD       SIMILAR          NULL       RESTRICT

Explanation

The following settings are in effect:

Minimum length (number of bytes) for a password: 8

Inclusion of the authorization identifier in the password: Prohibited (RESTRICT)

Use of only one type of characters in a password: Prohibited (RESTRICT)

If not prohibited, UNRESTRICT is displayed.

(2) Evaluate the restrictions to be set for passwords

Evaluate the password restrictions you intend to set or change. For details, see Table 23-3 Restrictions that can be set for passwords.

(3) Check for users who will be in violation of the specified restrictions

Check in advance for existing users whose existing password will not conform to the proposed new set of restrictions. Because the nonconforming users will be placed in password-invalid account lock state, they will no longer be permitted to connect to HiRDB. Before establishing a restriction, you should identify the users whose existing password will be in violation of the restriction. For details about the identification procedure, see 23.5 Checking for users who will be placed in password-invalid account lock state.

Reference note

Setting up or changing a password character string restriction may cause some users to be placed in password-invalid account lock state. You should notify all users in advance about the imminent change in password restrictions and inform them that they may have to change their password before the implementation date. Once the implementation date arrives, check for users who are in violation of the new set of restrictions and contact them.

(4) Change passwords

Use a GRANT statement to change the password of a user whose existing password does not conform to the new set of password restrictions. Examples follow:

Example 1

Change the password of USER01 to f51HD7tc:

GRANT CONNECT TO USER01 IDENTIFIED BY "f51HD7tc"

Reference note

Each user can change his or her own password. Passwords can also be changed by a DBA privilege holder.

Example 2

Change the password of DBA privilege holder ADMIN01 to gd4A@sPL:

GRANT DBA TO ADMIN01 IDENTIFIED BY "gd4A@sPL"

Example 3

Change the auditor's password to a0h7Fc3K:

GRANT AUDIT IDENTIFIED BY "a0h7Fc3K"

(5) Change the password character string restrictions

The procedure for changing the password character string restrictions follows:

Procedure

Use DROP CONNECTION SECURITY to cancel the password character string restrictions. For the cancellation procedure, see 23.7 Cancelling the password character string restrictions.

Use CREATE CONNECTION SECURITY to specify the new password character string restrictions.

Reference note

Even if you are not changing all the password character string restrictions (for example, you wish to change only the minimum number of bytes for a password), you must first use DROP CONNECTION SECURITY to cancel all the password character string restrictions, then use CREATE CONNECTION SECURITY to specify the new set of restrictions.

(6) Check for users in password-invalid account lock state

Check for users in password-invalid account lock state. For the checking procedure, see 23.4.1(1) Check for users in password-invalid account lock state.

23.4 Releasing the password-invalid account lock state

This section explains how to release the password-invalid account lock state.

Organization of this section

23.4.1 Releasing individual users from password-invalid account lock state

23.4.2 Releasing all users from password-invalid account lock state

23.4.1 Releasing individual users from password-invalid account lock state

Executor: DBA privilege holder

This section explains the procedure for releasing individual users from password-invalid account lock state. You must perform the steps in order they are shown below, beginning with step (1).

Organization of this subsection

(1) Check for users in password-invalid account lock state

(2) Change passwords

(1) Check for users in password-invalid account lock state

Check for users in password-invalid account lock state. An example follows:

Example

Display the authorization identifiers of users in password-invalid account lock state:

SELECT USER_ID
   FROM MASTER.SQL_USERS
     WHERE PWD_LOCK_TIME IS NOT NULL

Execution results

USER_ID
----------
USER1
USER2

Explanation

USER1 and USER2 are listed as being in password-invalid account lock state.

Reference note

If a user is in password-invalid account lock state, the date and time the user was placed in this status are set in the PWD_LOCK_TIME column of the SQL_USERS dictionary table. If a user is not in password-invalid account lock state, the NULL value is set in the PWD_LOCK_TIME column.

(2) Change passwords

Use a GRANT statement to change the password of a user who is in password-invalid account lock state. Examples follow:

Example

Change the password of user USER01 to f51HD7tc:

GRANT CONNECT TO USER01 IDENTIFIED BY "f51HD7tc"

23.4.2 Releasing all users from password-invalid account lock state

Executor: DBA privilege holder

You use DROP CONNECTION SECURITY to cancel the password character string restrictions. This action releases all users from password-invalid account lock state.

Example

Cancel the password character string restrictions and release all users from password-invalid account lock state:

DROP CONNECTION SECURITY FOR PASSWORD

23.5 Checking for users who will be placed in password-invalid account lock state

Executor: DBA privilege holder

This section explains the procedure for checking in advance for users who will be placed in password-invalid account lock state. You must perform the steps in the order they are shown below, beginning with step (1).

Organization of this section

(1) Execute CREATE CONNECTION SECURITY with the TEST option specified

(2) Search the PASSWORD_TEST column

(1) Execute CREATE CONNECTION SECURITY with the TEST option specified

Execute CREATE CONNECTION SECURITY with the TEST option specified. When the TEST option is specified, a violation type code is set in the PASSWORD_TEST column of the SQL_USERS dictionary table on the line for any user who would be in violation of a proposed restriction specified in the same CREATE CONNECTION SECURITY statement.

Reference note

When the TEST option is specified, only checking of the proposed password character string restrictions is performed. Violators are not placed in password-invalid account lock state.

The following example checks in advance for users who would be placed in password-invalid account lock state by proposed character string restrictions:

Example

Check for violators if the following character string restrictions were set for passwords:

Minimum length (number of bytes) for a password: 8

Inclusion of the authorization identifier in the password: Prohibited

Use of only one type of characters in a password: Prohibited

CREATE CONNECTION SECURITY
   FOR PASSWORD TEST             ...1
     MIN LENGTH 8                ...2
     USER IDENTIFIER RESTRICT    ...3
     SIMILAR RESTRICT            ...4

Explanation

Specifies the TEST option for checking in advance.

The minimum number of bytes permitted for a password would be 8.

Inclusion of the user's authorization identifier in that user's password would be prohibited.

Use of only one type of characters in a password would be prohibited.

When this SQL statement is executed, the passwords of all users who are registered in SQL_USERS are checked, and a violation type code is set in the PASSWORD_TEST column of SQL_USERS for any user whose password would be in violation of any of the specified proposed restrictions.

Hint

If the specification contents of the CREATE CONNECTION SECURITY SQL for an advance check are not the same as the specification contents when the password character string restrictions are actually set, even users who corrected their passwords may be placed in password-invalid account lock state. It is important that the CREATE CONNECTION SECURITY SQL specified for the advance check be the same as the SQL executed for setting the password character string restrictions (other than for the TEST option).

After the advance check is executed, instruct only the users who will be in violation of the new character string restrictions to change their passwords. Also make sure that the password of any new user who is registered complies with the new password restrictions.

(2) Search the PASSWORD_TEST column

Violation type codes are set in the PASSWORD_TEST column of SQL_USERS. Search the PASSWORD_TEST column to identify users whose existing password will cause them to be placed in password-invalid account lock state. Table 23-4 shows the violation type codes that are set. If there is no violation, the NULL value is set.

Table 23-4 Violation type codes set in the PASSWORD_TEST column

Order number | Item | Violation type code set in the PASSWORD_TEST column
1 | Violation of the minimum number of bytes for a password | L
2 | Violation of the prohibition on inclusion of the authorization identifier in the password | U
3 | Violation of the prohibition on use of only one type of characters in a password | S

Note

If a password violates multiple items, only one violation type code is set, depending on the item order numbers. For example, if a password violates the items with order numbers 1 and 2, L (the violation type code for item 1) is set.

Examples of checks for users in password-invalid account lock state are shown below.

Example 1

Obtain a list of users who are in violation of a password character string restriction:

SELECT USER_ID
  FROM MASTER.SQL_USERS
    WHERE PASSWORD_TEST IS NOT NULL

Execution results

USER_ID
-----------
USER1
USER2
USER3

Explanation

USER1, USER2, and USER3 are in violation of a password character string restriction.

Example 2

Obtain a list of DBA privilege holders and auditors who are in violation of a password character string restriction:

SELECT USER_ID
   FROM MASTER.SQL_USERS
     WHERE PASSWORD_TEST IS NOT NULL
       AND (DBA_PRIVILEGE = 'Y' OR AUDIT_PRIVILEGE = 'Y')

Execution results

USER_ID
-----------
AUDITOR1
DBA1
DBA2

Explanation

DBA privilege holders DBA1 and DBA2, as well as the auditor (AUDITOR1), are in violation of a password character string restriction.

23.6 Privilege granting or revocation for users in password-invalid account lock state

Organization of this section

(1) Granting privileges to users in password-invalid account lock state

(2) Deleting privileges from users in password-invalid account lock state

(1) Granting privileges to users in password-invalid account lock state

The DBA privilege cannot be granted to a user (who has the CONNECT privilege) who is in password-invalid account lock status. You must first release the user from password-invalid account lock state, then you can grant the DBA privilege.

(2) Deleting privileges from users in password-invalid account lock state

You use a REVOKE statement to revoke privileges from users in password-invalid account lock state.

23.7 Cancelling the password character string restrictions

Executor: DBA privilege holder

You use DROP CONNECTION SECURITY to cancel the password character string restrictions. This operation returns the system to its status before the password character string restrictions were set.

Example

Cancel the password character string restrictions currently in effect:

DROP CONNECTION SECURITY FOR PASSWORD

Reference note

You cannot delete the restrictions individually (for example, you cannot cancel only the setting for the minimum number of bytes for a password).

Note

Cancelling the password character string restrictions releases the password-invalid account lock state. As a result, any users who had been in this status and who should not be allowed to connect to HiRDB become able to connect. You should first check for the users in password-invalid account lock state.

23.8 Relationships between password character string restrictions and other facilities

This section explains the relationships between password character string restrictions and other facilities.

Organization of this section

23.8.1 Notes on using a Directory Server linkage facility

23.8.2 Notes on using the security audit facility

23.8.1 Notes on using a Directory Server linkage facility

You cannot set up password character string restrictions while you are using a Directory Server linkage facility. If password character string restrictions have already been set up when you begin using a Directory Server linkage facility, the restrictions will no longer be effective.

Before using a Directory Server linkage facility, it is strongly advised that you cancel the password character string restrictions.

Reference note

If you use a Directory Server linkage facility without cancelling the password character string restrictions, and then stop using the Directory Server linkage facility, the following problems may occur:

Users who were in violation of the password character string restrictions will not have been placed in password-invalid account lock state.

Users who are not in violation of the password character string restrictions may be placed in password-invalid account lock state.

DBA privilege holders and the auditor may be placed in password-invalid account lock state.

23.8.2 Notes on using the security audit facility

You should take note of the following when you use the security audit facility:

The password character string restrictions are not checked when the pdmod command is used to register the auditor. After registering the auditor, it is important that you immediately use a GRANT AUDIT statement to change the auditor's password.

You cannot set a user who is in password-invalid account lock state as the auditor.

23.9 Setting and cancelling the limit on number of consecutive certification failures

This section explains how to set and cancel the limit on the number of consecutive certification failures. The following items are explained:

Setting a new limit on the number of consecutive certification failures

Cancelling the limit on the number of consecutive certification failures

Changing the limit on the number of consecutive certification failures

Checking the permitted number of consecutive certification failures and the account lock period

Organization of this section

23.9.1 Setting a new limit on the number of consecutive certification failures

23.9.2 Cancelling the limit on the number of consecutive certification failures

23.9.3 Changing the limit on the number of consecutive certification failures

23.9.4 Checking the permitted number of consecutive certification failures and the account lock period

23.9.1 Setting a new limit on the number of consecutive certification failures

Use CREATE CONNECTION SECURITY to set limits on the number of consecutive certification failures. Examples follow:

Example 1

Set limits on the number for consecutive certification failures as follows:

Permitted number of consecutive certification failures: 3

Account lock period: 30 minutes

CREATE CONNECTION SECURITY
   FOR CONNECT PERMISSION COUNT 3     ...1
               LOCK 30 MINUTE         ...2

Explanation

Specifies the permitted number of consecutive certification failures.

Specifies an account lock period.

Example 2

Set limits on the number of consecutive certification failures as follows:

Permitted number of consecutive certification failures: 5

Account lock period: Permanent

CREATE CONNECTION SECURITY
   FOR CONNECT PERMISSION COUNT 5     ...1
               LOCK UNLIMITED         ...2

Explanation

Specifies the permitted number of consecutive certification failures.

Specifies an account lock period.

23.9.2 Cancelling the limit on the number of consecutive certification failures

Use DROP CONNECTION SECURITY to cancel the limit on the number of consecutive certification failures. An example follows:

Example

Cancel the limit on the number of consecutive certification failures.

DROP CONNECTION SECURITY
   FOR CONNECT

Reference note

Cancelling the limit on the number of consecutive certification failures releases the consecutive certification failure account lock state.

23.9.3 Changing the limit on the number of consecutive certification failures

To change the limit on the number of consecutive certification failures, first use DROP CONNECTION SECURITY to cancel the existing limit, and then use CREATE CONNECTION SECURITY to set a new limit. An example follows:

Example

Change the limit on the number of consecutive certification failures as follows:

Permitted number of consecutive certification failures: 5

Account lock period: 10 hours

DROP CONNECTION SECURITY
   FOR CONNECT                        ...1
CREATE CONNECTION SECURITY
   FOR CONNECT PERMISSION COUNT 5     ...2
               LOCK 10 HOUR           ...3

Explanation

Cancels the existing limit on the number of consecutive certification failures.

Specifies a new permitted number of consecutive certification failures.

Specifies an account lock period.

23.9.4 Checking the permitted number of consecutive certification failures and the account lock period

Executor: DBA privilege holder or auditor

To check the permitted number of consecutive certification failures and the account lock period that have been set, you search the SQL_SYSPARAMS dictionary table. An example follows:

Example

Check the permitted number of consecutive certification failures and the account lock period that have been set:

SELECT * FROM MASTER.SQL_SYSPARAMS
   WHERE PARAM_KEY='PERMISSION_COUNT'
   OR PARAM_KEY='LOCK_MINUTE'

Execution results 1

PARAM_KIND           FUNCTION_KEY   PARAM_KEY        INT_VALUE  CHAR_VALUE
----------------------------------------------------------------------------
CONNECTION_SECURITY  CONNECT        PERMISSION_COUNT 2          2
CONNECTION_SECURITY  CONNECT        LOCK_MINUTE      1440       1440

Explanation

The permitted number of consecutive certification failures is 2, and the account lock period is 1440 minutes.

The account lock period is stored in SQL_SYSPARAMS as a number of minutes.

Execution result 2

PARAM_KIND           FUNCTION_KEY   PARAM_KEY        INT_VALUE  CHAR_VALUE
----------------------------------------------------------------------------
CONNECTION_SECURITY  CONNECT        PERMISSION_COUNT 2          2
CONNECTION_SECURITY  CONNECT        LOCK_MINUTE      NULL       UNLIMITED

Explanation

The permitted number of consecutive certification failures is 2, and the account lock period is permanent (UNLIMITED).

23.10 Checking for users in consecutive certification failure account lock state

Executor: DBA privilege holder or auditor

You search a dictionary table to check for users in consecutive certification failure account lock state. Search examples are provided below.

Because the system-defined ADD_INTERVAL scalar function is used, a data dictionary LOB RDAREA is required. If no data dictionary LOB RDAREA is available, you must create one.

Example 1

Display a list of users in consecutive certification failure account lock state (when the account lock period is not set to permanent):

SELECT USER_ID,CON_LOCK_TIME FROM MASTER.SQL_USERS
 WHERE CAST(CON_LOCK_TIME AS CHAR(19)) >=
 (SELECT MASTER.ADD_INTERVAL(CAST(CURRENT_TIMESTAMP(0) AS CHAR(19)),-INT_VALUE)
   FROM MASTER.SQL_SYSPARAMS
     WHERE PARAM_KEY = 'LOCK_MINUTE_CODE')
     AND CON_LOCK_TIME IS NOT NULL

Execution results

USER_ID CON_LOCK_TIME
---------------------
USER1   2005-01-19 11:37:58
USER2   2005-01-19 12:06:11

Explanation

USER1 and USER2 are in consecutive certification failure account lock state.

Example 2

Display a list of users in consecutive certification failure account lock state (when the account lock period is set to permanent):

SELECT USER_ID,CON_LOCK_TIME FROM MASTER.SQL_USERS
 WHERE CON_LOCK_TIME IS NOT NULL

Execution results

USER_ID CON_LOCK_TIME
---------------------
USER1   2005-01-19 13:17:23
USER2   2005-01-19 13:17:35

Explanation

USER1 and USER2 are in consecutive certification failure account lock state.

Example 3

Display a list of users who are not in consecutive certification failure account lock state (when the account lock period is not set to permanent):

SELECT USER_ID,CON_LOCK_TIME FROM MASTER.SQL_USERS
 WHERE CAST(CON_LOCK_TIME AS CHAR(19)) <
 (SELECT MASTER.ADD_INTERVAL(CAST(CURRENT_TIMESTAMP(0) AS CHAR(19)),-INT_VALUE)
   FROM MASTER.SQL_SYSPARAMS
     WHERE PARAM_KEY = 'LOCK_MINUTE_CODE')
     OR CON_LOCK_TIME IS NULL

Execution results

USER_ID  CON_LOCK_TIME
---------------------
USER1    NULL
AUDITOR1 NULL

Explanation

USER1 and AUDITOR1 are not in consecutive certification failure account lock state.

Example 4

Display a list of users who are not in consecutive certification failure account lock state (when the account lock period is set to permanent):

SELECT USER_ID,CON_LOCK_TIME FROM MASTER.SQL_USERS
 WHERE CON_LOCK_TIME IS NULL

Execution results

USER_ID  CON_LOCK_TIME
---------------------
USER1    NULL
AUDITOR1 NULL

Explanation

USER1 and AUDITOR1 are not in consecutive certification failure account lock state.

Note

If the front-end server and the dictionary server are located in different server machines, you must ensure that the times at the server machines are synchronized. If the times are not synchronized, valid search results may not be obtained.

Reference note

The date/time a user was placed in consecutive certification failure account lock state is stored in the SQL_USERS dictionary table. This date/time information is retained even after the consecutive certification failure account lock state has been released. The date/time information is cleared the first time user certification (CONNECT) is successful.

23.11 Releasing consecutive certification failure account lock state

Executor: HiRDB administrator

You use the pdacunlck command to release the consecutive certification failure account lock state. After checking for users in consecutive certification failure account lock state, you can release those users from consecutive certification failure account lock state. Examples follow:

Example 1

Release user USER01 from consecutive certification failure account lock state:

pdacunlck USER01

Example 2

Release users USER01 and USER02 from consecutive certification failure account lock state:

pdacunlck USER01,USER02

Example 3

Release all users from consecutive certification failure account lock state:

pdacunlck ALL

Reference note

If you use DROP CONNECTION SECURITY to cancel the limit on the number of consecutive certification failures, all users who are currently in consecutive certification failure account lock status are released from that status.

23.12 Notes on using the connection security facility

This section provides notes on using the connection security facility. The following items are explained:

Releasing a double lock

Notes on restoring a dictionary RDAREA

Organization of this section

23.12.1 Releasing a double lock

23.12.2 Notes on restoring a dictionary RDAREA

23.12.1 Releasing a double lock

It is possible for a user to be placed in both password-invalid account lock state and consecutive certification failure account lock state. This state is called a double lock.

To release a double lock, you must release both the password-invalid account lock state and the consecutive certification failure account lock state. The order in which these states are released does not matter.

23.12.2 Notes on restoring a dictionary RDAREA

After a backup of dictionary RDAREAs is made, the password-invalid account lock state or the consecutive certification failure account lock state may change. Therefore, when you restore dictionary RDAREAs, you should use both the backup of the dictionary RDAREAs and the unload log file to restore the dictionary RDAREAs to their most recent status.

24. Using the Directory Server Linkage Facility

This chapter explains the environment setup and operating procedures for the Directory Server linkage facility.

This chapter contains the following sections:

Organization of this chapter

24.1 Overview of the Directory Server linkage facility

24.2 System configuration

24.3 Environment setup

24.4 User privileges setup

24.5 Operating procedures

24.6 Operations in the event of an error

24.7 Creating the HiRDB LDAP Option environment definition file

24.1 Overview of the Directory Server linkage facility

This section provides an overview of the Directory Server linkage facility. This section covers the following topics:

About the Directory Server linkage facility

Directory Servers that can be linked

Capabilities of the Directory Server linkage facility

Organization of this section

24.1.1 About the Directory Server linkage facility

24.1.2 Directory servers that can be linked

24.1.3 Capabilities of the Directory Server linkage facility

24.1.1 About the Directory Server linkage facility

The Directory Server linkage facility makes it possible to use a Directory Server to manage and authenticate HiRDB users. A Directory Server is a program that uses a release type protocol called LDAP to provide service through the Internet or through a distributed system environment such as an intranet. This service, called the Directory Service, uses centralized management to reduce the workload of the system administrator.

Use of a Directory Server makes it possible to centrally manage organizational and user information (such as user IDs, passwords, departments, job titles) that traditionally has been managed separately on a variety of systems such as HiRDB or Groupmax. A Directory Server also makes it possible to reference and update the user information from multiple work sites. Figure 24-1 provides an overview of the Directory Server linkage facility.

Figure 24-1 Overview of the Directory Server linkage facility

* Directory Server performs user authentication for users who wish to access HiRDB. User information (user IDs and passwords) must be registered into Directory Server in advance.

24.1.2 Directory servers that can be linked

HiRDB can link with Sun Java System Directory Server. This is referred to as the Sun Java System Directory Server linkage facility or, simply, as the directory server linkage facility.

Required knowledge

The descriptions in this manual assume that the reader is familiar with the following:

Directory Servers

HiRDB security facility

For details about Directory Servers, see Sun Java System Directory Server. For details about the HiRDB security facility, see 2. Security Definition.

Conditions

The following are the requirements (applicable OSs) for using the directory server linkage facility:
HP-UX
Solaris 8
AIX 5L
The HiRDB must be a POSIX library version that operates in the 32-bit mode. When you set up the HiRDB environment, you use the pdsetup command to select the POSIX library version.

The HiRDB LDAP Option must be installed to use the Sun Java System Directory Server linkage facility.

24.1.3 Capabilities of the Directory Server linkage facility

Organization of this subsection

(1) Centralized management by the Directory Server of users connected to HiRDB

(2) Granting of table access to roles

(1) Centralized management by the Directory Server of users connected to HiRDB

Directory Server provides centralized management of the CONNECT privilege information that was previously managed by HiRDB and performs user authentication whenever a user attempts to connect to HiRDB.

Traditionally, the CONNECT privilege has been granted by the DBA privilege holder to those users who need it. When the Directory Server linkage facility is used, there is no need to grant the CONNECT privilege to users. When user information (user IDs and passwords) is registered into Directory Server, the CONNECT privilege is granted automatically to all the registered users.

HiRDB manages DBA privileges, audit privileges, schema definition privileges, RDAREA usage privileges, and table access privileges. Figures 24-2 provide overviews of user authentication.

Figure 24-2 Overview of user authentication (for the Sun Java System Directory Server linkage facility)

Explanation

When a user attempts to connect to HiRDB, Sun Java System Directory Server performs user authentication. If the user's ID and password have been registered in Sun Java System Directory Server, the user is permitted to connect to HiRDB.

(2) Granting of table access to roles

The Sun Java System Directory Server employs the concept of roles. Groups of people based on job titles or departments are registered in a Directory Server as separate roles. Then, by granting table access privileges to a role, the administrator can grant table access privileges to all users who belong to that role. The administrator can manage separately the table access privileges for the various roles. Figure 24-3 shows the granting of table access privileges to a role.

To provide table access to a role, the administrator must use a role name, which the Sun Java System Directory Server applies as a filter.

Figure 24-3 Granting table access to a role

Explanation

If the owner of a table grants access to a role (for example, to the General Affairs Department), all users in the General Affairs Department will be able to access that table.

24.2 System configuration

Organization of this section

24.2.1 Software configuration

24.2.2 Example system configurations

24.2.1 Software configuration

The conditions of HiRDB LDAP Option determine the operating system and product that are required. The following products are required to run the Sun Java System Directory Server linkage facility:

Sun Java System Directory Server

iPlanet Console (Sun ONE Console) *

HiRDB LDAP Option

* Needed when a graphical user interface is used to register directory information such as user names.

Notes

Hitachi recommends caution when both of the following conditions apply:

Privileges are granted to a role

DABroker (a version earlier than 02-06) is used to acquire table access privilege information

In such a case, users cannot access the table access privilege information granted to their role. If 02-06 or a later version of DABroker is used, users can access the table access privilege information.

24.2.2 Example system configurations

Figure 24-4 shows an example of a system configuration (for a HiRDB/Single Server) when the Sun Java System Directory Server linkage facility is used. You must install HiRDB LDAP Option on the server machine where the HiRDB/Single Server is located.

Figure 24-4 Example system configuration using the Sun Java System Directory Server linkage facility (for a HiRDB/Single Server)

Figure 24-5 shows an example of a system configuration (for a HiRDB/Parallel Server) when the Sun Java System Directory Server linkage facility is used. You must install HiRDB LDAP Option on the server machine where the dictionary server is located.

Figure 24-5 Example system configuration using Sun Java System Directory Server linkage facility (for a HiRDB/Parallel Server)

24.3 Environment setup

This section explains the environment setup for the Directory Server linkage facility.

Organization of this section

24.3.1 Notes on HiRDB environment setup

24.3.2 Procedure for setting up environment for Directory Server linkage facility

24.3.3 Handling upper-case and lower-case letters specified in user IDs, passwords, and roles

24.3.1 Notes on HiRDB environment setup

To use the Directory Server Linkage Facility, the POSIX version must be used. To use the POSIX library version, specify the -l option in the pdsetup command that is executed during environment setup for HiRDB. When HiRDB is first installed, the -l option should be specified in the pdsetup command.

If HiRDB is already running but the POSIX library version is not being used, use the following procedure to change HiRDB to the POSIX library version:

Procedure

Use pdstop command to terminate HiRDB normally.

Use the pdsetup -d command to delete HiRDB from the OS; choose y in response to the message. In the case of a HiRDB/Parallel Server, execute the pdsetup -d command at all server machines.

Execute pdsetup command with POSIX specified in the -l option. In the case of a HiRDB/Parallel Server, execute the pdsetup -l command at all server machines.

Use the pdstart command to start HiRDB normally.

HiRDB Version 5.0 and older versions do not support the POSIX library version. Therefore, when HiRDB is upgraded from Version 5.0 or older, use this procedure to change HiRDB to the POSIX library version.

If the -l option was not specified in the pdsetup command when a new HiRDB was installed, use this procedure to change HiRDB to the POSIX library version.

24.3.2 Procedure for setting up environment for Directory Server linkage facility

This section explains the procedure for setting up an environment for the Directory Server linkage facility. The following assumes that the environment for HiRDB is already set up and HiRDB is ready to be started.

Procedure

Install the Directory Server.

Users and roles must be registered into the Sun Java System Directory Server.

Terminate HiRDB.

Set up the environment for HiRDB LDAP Option.

Specify the pd_directory_server operand.

Grant privileges to users.¹

Delete unneeded CONNECT privileges.²

The procedure step numbers correspond to the paragraph numbers in the explanation that follows. For example, step 3 above is explained in paragraph (3) below.

¹ Perform this step when you install HiRDB at a server for the first time.

² Perform this step when HiRDB is already running.

Organization of this subsection

(1) Install the Directory Server

(2) Register users and roles in the Directory Server

(3) Terminate HiRDB

(4) Set up the environment for HiRDB LDAP Option

(5) Specify the pd_directory_server operand

(6) Grant privileges to the users

(7) Delete unneeded CONNECT privileges

(1) Install the Directory Server

Install the Directory Server. For details about installing the Sun Java System Directory Server, see Sun Java System Directory Server.

(2) Register users and roles in the Directory Server

Register in the Sun Java System Directory Server the users who wish to connect to HiRDB. The HiRDB administrator must also be registered. Defined roles can also be registered. For details about registering users or roles into the Sun Java System Directory Server, see Sun Java System Directory Server.

(a) Notes on registering users

Be sure to specify the users' passwords when you register users in the Directory Server. You can register users without specifying passwords, but such users will not be able to connect to HiRDB.

User IDs must conform to the naming conventions for HiRDB authorization identifiers (i.e., a user ID must consist of up to eight bytes of upper- and/or lower-case alphabetic characters and/or numeric digits).

A user ID that is the same as a HiRDB reserved word cannot be used for connecting to HiRDB (for a list of the reserved words, see the manual HiRDB Version 8 SQL Reference).

All user IDs must be unique.

Note that user and role information is case sensitive. For details, see 24.3.3 Handling upper-case and lower-case letters specified in user IDs, passwords, and roles.

(b) Notes on registering roles

Register roles that use a filter.

Role names must conform to the naming conventions for HiRDB. A role name must consist of up to 30 bytes of upper- and/or lower-case alphabetic characters and/or numeric digits. Double-byte characters are not allowed.

If a role name is the same as a HiRDB reserved word, table access privileges cannot be granted to that group. For a list of reserved words, see the manual HiRDB Version 8 SQL Reference.

Check that no registered role name is the same as an existing role name or user ID in the Sun Java System Directory Server.

All role names must be unique.

Note that user and role information is case sensitive. For details, see 24.3.3 Handling upper-case and lower-case letters specified in user IDs, passwords, and roles.

(c) When HiRDB is already running

The users registered into HiRDB can be identified by referencing the SQL_USERS dictionary table; an example follows:

Example

Display the authorization identifiers of all users registered in HiRDB:

 SELECT USER_ID FROM MASTER.SQL_USERS

(3) Terminate HiRDB

Use the pdstop command to terminate HiRDB normally.

(4) Set up the environment for HiRDB LDAP Option

Install HiRDB LDAP Option and execute the pdopsetup command. For details about installation and executing the pdopsetup command, see the manual HiRDB Version 8 Installation and Design Guide.

After installation is complete, create a HiRDB LDAP Option environment definition file. For details about HiRDB LDAP Option environment definition files, see 24.7 Creating the HiRDB LDAP Option environment definition file.

(5) Specify the pd_directory_server operand

Specify the pd_directory_server operand to use the Directory Server linkage facility. Then, use the pdstart command to start HiRDB normally.

(6) Grant privileges to the users

This task should be performed when HiRDB is installed for the first time. Grant privileges to the users who are registered in Hitachi Directory Server. For the procedure for granting privileges, see 24.4 User privileges setup.

(7) Delete unneeded CONNECT privileges

This task should be performed if HiRDB had been installed and operated previously. Because CONNECT privileges are now managed by Hitachi Directory Server, HiRDB's CONNECT privilege management information is no longer needed. Use the REVOKE statement to delete the CONNECT privilege of all users except for the following:

DBA privilege holders (including the HiRDB administrator)¹

Audit privilege holders¹

Schema definition privilege holders²

The following SQL example retrieves all users who do not have DBA or schema definition privilege (users who have CONNECT privilege only or CONNECT privilege and table access privileges only):

Example

SELECT USER_ID FROM MASTER.SQL_USERS
   WHERE DBA_PRIVILEGE = 'N' AND SCHEMA_PRIVILEGE = 'N'
     AND AUDIT_PRIVILEGE <> 'Y'

¹ CONNECT privileges of DBA privilege holders and audit privilege holders cannot be deleted.

² The CONNECT privilege of a user whose schema exists cannot be revoked. Revoking the CONNECT privilege when there is no schema also revokes the schema definition privilege. If a schema definition privilege is revoked inadvertently, grant the schema definition privilege again. Delete a schema only when it is no longer needed.

Remarks

Although HiRDB can be run without deleting the CONNECT privileges, the CONNECT privilege information will remain in the HiRDB dictionary as unnecessary information that is not used. If unneeded privilege information is left, a different user with the same ID who registers subsequently may manipulate definitions and tables using that privilege. If it is decided not to delete the CONNECT privileges, safeguard against such an occurrence by ensuring that the user information registered in Directory Server matches exactly the privilege information registered in HiRDB.

24.3.3 Handling upper-case and lower-case letters specified in user IDs, passwords, and roles

This section describes the handling of upper-case and lower-case letters specified in user IDs, passwords, and roles.

Organization of this subsection

(1) Differences in handling by HiRDB and the Directory Server

(2) Setting up case sensitivity in a Directory Server

(3) About HiRDB operation

(1) Differences in handling by HiRDB and the Directory Server

HiRDB does not differentiate between upper-case and lower-case letters in user IDs, passwords, and role names. HiRDB handles lower-case letters as upper-case letters. To differentiate between upper-case and lower-case letters, the string must be enclosed in quotation marks ("). For example, USERA, usera, userA, and USerA are all regarded as the character string USERA. In contrast, "USERA", "usera", "userA", and "USerA" are handled as different character strings.

For details with respect to the Sun Java System Directory Server, see Sun Java System Directory Server. Table 24-1 describes typical handling of upper-case and lower-case letters by the Directory Servers.

Table 24-1 Handling of upper-case and lower-case letters by the Directory Servers

Item
Handling by Directory Servers

User IDs
Does not differentiate between upper- and lower-case letters.
Example: USERA, usera, userA, and USerA are all regarded as the same character string.

Passwords
Differentiates between upper- and lower-case letters.
Example: HiRDB, HIRDB, and hirdb are regarded as different passwords.

Role name
Does not differentiate between upper- and lower-case letters.
Example: GROUPA, groupa, GrouPA, and gRoUpA are all regarded as the same character string.

(2) Setting up case sensitivity in a Directory Server

Table 24-2 provides guidelines for setting up case sensitivity in a Directory Server.

Table 24-2 Guidelines for setting up case sensitivity in a Directory Server

Condition | Differentiation between upper- and lower-case letters
When Directory Server is used in HiRDB only | When HiRDB differentiates between upper- and lower-case letters | Set Directory Server to differentiate between upper- and lower-case letters
When HiRDB does not differentiate between upper- and lower-case letters | Set Directory Server to not differentiate between upper- and lower-case letters
When Directory Server is used in multiple products including HiRDB | Decide whether or not Directory Server is to differentiate between upper- and lower-case letters by considering other products as well. Before changing the handling of upper- and lower-case letters for the sake of HiRDB, ensure that other products will not be affected adversely by the change.

Notes on differentiation between upper- and lower-case letters

Suppose that a user called USERA is registered in Directory Server. In this event, either USERA or usera can connect to HiRDB. However, if GRANT SCHEMA TO "usera" is specified when the schema definition privilege is granted, this SQL will be accepted. However, HiRDB will recognize that the schema definition privilege was granted to usera. Consequently, only usera can use the schema definition privilege, and USERA cannot. A similar situation occurs when DBA privilege or an access privilege is granted.

If GRANT SELECT ON T1 TO GROUP "groupa" is specified when access privileges are granted to roles, all users belonging to groupa as well as users belonging to GROUPA will be granted table access privileges.

(3) About HiRDB operation

When specifying user IDs, passwords, or role names in HiRDB, Hitachi recommends specifying in a consistent manner (i.e., using only upper-case letters or enclosing letters in quotation marks).

24.4 User privileges setup

Before setting up user privileges, check that all users have been registered into the Directory Server. Also check that the HiRDB administrator, DBA privilege holders and auditors are also registered. Any users not registered in the Directory Server will not have CONNECT privileges and will not be able to connect to HiRDB.

Organization of this section

24.4.1 DBA privilege setup

24.4.2 Auditor privilege setup

24.4.3 CONNECT privilege setup

24.4.4 Schema definition privilege setup

24.4.5 RDAREA usage privilege setup

24.4.6 Table access privilege setup

24.4.1 DBA privilege setup

A DBA privilege holder uses the GRANT statement to grant DBA privileges to other users. DBA privileges cannot be granted to roles. Specify in the GRANT statement's IDENTIFIED BY operand the passwords that are registered in the Directory Server. Check that a password is specified for every user.

When DBA privilege is granted, that information is registered in SQL_USERS.

Example

Grant DBA privilege to the user whose authorization identifier is USR01 and password is HIR01:

GRANT DBA TO USR01 IDENTIFIED BY HIR01

24.4.2 Auditor privilege setup

Use the pdmod command to register auditors into the Directory Server. Auditors can then use the GRANT AUDIT statement to change their passwords to the passwords registered in the Directory Server.

24.4.3 CONNECT privilege setup

There is no need to grant HiRDB's CONNECT privilege to users. User are not registered in HiRDB's SQL_USERS dictionary table.

Be sure to specify the users' passwords when you registering users in the Directory Server. You can register users without specifying passwords, but such users will not be able to connect to HiRDB.

24.4.4 Schema definition privilege setup

A DBA privilege holder uses the GRANT statement to grant the schema definition privilege to other users. The schema definition privilege cannot be granted to a role. When schema definition privilege is granted, that information is registered in SQL_USERS.

Example

Grant schema definition privilege and RDAREA usage privilege (RDAREA name is RDAREA01) to a user who creates tables (authorization identifier is USR02):

GRANT SCHEMA TO USR02
GRANT RDAREA RDAREA01 TO USR02

24.4.5 RDAREA usage privilege setup

A DBA privilege holder uses the GRANT statement to grant the RDAREA usage privilege to other users. The RDAREA usage privilege cannot be granted to roles.

Example

Grant schema definition privilege and RDAREA usage privilege (RDAREA name is RDAREA01) to a user who creates tables (authorization identifier is USR02):

GRANT SCHEMA TO USR02
GRANT RDAREA RDAREA01 TO USR02

24.4.6 Table access privilege setup

The owner of a table uses the GRANT statement to grant access privileges to other users or roles.

Organization of this subsection

(1) Granting the table access privilege to a user

(2) Granting table access privileges to a role

(3) A user moves to a different role (when granting access privilege for a table to a different role)

(1) Granting the table access privilege to a user

Example

Grant SELECT privilege for a table (authorization-identifier.table-identifier is USR02.T01) to a user (authorization identifieris USR03):

GRANT SELECT ON USR02.T01 TO USR03

Note

If a role name is the same as a user ID and access privileges were granted to both names, it may not be possible to distinguish between the names when acquiring table access privileges information. For details, see 24.5.2 Acquiring table access privileges information.

(2) Granting table access privileges to a role

Table access is granted to roles that use filters.

Example

Grant SELECT privilege for a table (authorization-identifier.table-identifier is USER02.T01) to a role (role name is GRP01):

GRANT SELECT ON USR02.T01 TO GROUP GRP01

Remarks

When the following SQL is executed, the SELECT privilege, INSERT privilege, or UPDATE privilege for a table (T01) is granted to a user (USR01) who belongs to a role (GRP01).

GRANT SELECT ON T01 TO PUBLIC
GRANT INSERT ON T01 TO GROUP GRP01
GRANT UPDATE ON T01 TO USR01

Note

When access privilege for a table is granted to a role, users belonging to that role cannot create a view table for that table.

Access privilege for a table can be granted to a user or role that is not registered in the Directory Server. However, the individual user or a user belonging to the role cannot access the table.

(3) A user moves to a different role (when granting access privilege for a table to a different role)

When a user moves to a different role, it is not necessary to use the GRANT statement or REVOKE statement to change access privilege for a table. For example, when a user (USR01) moves from the Finance Department to General Administration, simply change the department name in the user's user information registered in Directory Server and execute the pdgrprfl command. USR01 will then use the table access privileges granted to the General Administration group and will no longer be able to use the table access privileges granted to the Finance Department group.

If table access privileges have been granted directly to the user, it is necessary to reevaluate those table access privileges (i.e., it may be necessary to revoke some table access privileges).

24.5 Operating procedures

Organization of this section

24.5.1 Adding, modifying, or deleting a user or role

24.5.2 Acquiring table access privileges information

24.5.3 Suspending the Directory Server linkage facility

24.5.1 Adding, modifying, or deleting a user or role

Organization of this subsection

(1) Deleting a user or role

(2) Execute the pdgrprfl command

(3) A user is deleted accidentally

(4) Check to see if user information is registered in Directory Server

(1) Deleting a user or role

When you delete a user who is already registered in the Directory Server, you must also delete the privileges granted to that user. When you delete a role, you must also delete the access privileges for tables that were granted to that role.

(2) Execute the pdgrprfl command

To add, modify, or delete a user or role already registered in the Directory Server, execute the pdgrprfl command. Then, execute the pdgrprfl command to refresh the user and role information stored in HiRDB LDAP Option and HiRDB.

If the pdgrprfl command is not executed after adding, modifying, or deleting a user or role, this user information will not match the user information stored in the Directory Server. If the pdgrprfl command cannot always be executed immediately after updating Directory Server information, you should set the command to execute at a regular interval (such as once every few hours or once a day).

Update the user or role information that is stored in HiRDB LDAP Option, or HiRDB when you start HiRDB (this is the same as executing the pdgrprfl command).

(3) A user is deleted accidentally

If a user is deleted accidentally, the privilege information granted to that user remains in HiRDB. Register that user in the Directory Server again and the user will have access to all privileges previously granted.

(4) Check to see if user information is registered in Directory Server

Execute the pdusrchk command to check for user information in the Directory Server.

24.5.2 Acquiring table access privileges information

Search the SQL_TABLE_PRIVILEGES dictionary table to acquire access privileges information for a table. See the following example.

Example

SELECT TABLE_SCHEMA, TABLE_NAME, GRANTOR, GRANTEE, SELECT_PRIVILEGE,
   INSERT_PRIVILEGE,DELETE_PRIVILEGE, UPDATE_PRIVILEGE, GRANTEE_TYPE
 FROM MASTER.SQL_TABLE_PRIVILEGES
      WHERE TABLE_SCHEMA <> 'HiRDB'
        AND ((GRANTEE_TYPE IS NULL AND GRANTEE IN (USER,'PUBLIC'))
        OR (GRANTEE_TYPE='G' AND
            IS_USER_CONTAINED_IN_HDS_GROUP(GRANTEE) IS TRUE))

Note: IS_USER_CONTAINED_IN_HDS_GROUP is a scalar function.

Reference note

If a role name is the same as a user ID and table access privileges were granted to both names, it may not be possible to distinguish between the names when acquiring table access privileges information. To distinguish between the two names, either execute the SQL such as in the example above or use DABroker (version 02-06 or later) to acquire the table access privileges information.

When you use DABroker (a version earlier than 02-06), table access privileges information granted to user roles cannot be acquired.

24.5.3 Suspending the Directory Server linkage facility

The procedure for suspending the Directory Server linkage facility is explained below.

Procedure

If table access privileges have been granted to roles, revoke the privileges for the roles while using the Directory Server linkage facility.

Use the pdstop command to normally terminate HiRDB.¹

Delete the pd_directory_server operand and suspend usage of the Directory Server linkage facility. Once this operand has been deleted, privileges for roles cannot be revoked.²

Use the pdstart command to start HiRDB. Use HiRDB to check user privileges.

Register in HiRDB all the necessary user privileges.³

Delete HiRDB user information from the Directory Server as necessary.

¹ The system reconfiguration command (pcdhgconf command) makes it possible to modify HiRDB system definitions while HiRDB is operating. In such a case, it is not necessary to terminate HiRDB. Note that HiRDB Advanced High Availability must be installed in order to use this command. For details about modifying HiRDB system definitions while HiRDB is operating, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

² If the pd_directory_server operand is deleted without deleting the privileges for roles, the following problems will occur:

If a role uses the same name as a user ID and access privileges were granted to both names, it may not be possible to distinguish between the names when acquiring table access privileges information. For details, see 24.5.2 Acquiring table access privileges information.

³ User privileges must be registered for the following users:

Users with the DBA privilege (including the HiRDB administrator)
Users have already been registered into HiRDB. Registering users is not necessary unless they were deleted while HiRDB was operating. However, if a user's password was not specified when DBA privileges were granted, that user will not be able to use the granted DBA privilege. If this situation occurs, use the GRANT DBA statement or GRANT CONNECT statement to register the user's password.

Users with the schema definition privilege
Users have already been registered into HiRDB. Registering users is not necessary unless they were deleted while HiRDB was operating. However, if a user who does not have DBA privilege was granted schema definition privilege, no password is registered for that user. If this situation occurs, use the GRANT CONNECT statement to register the user's password.

Users with the audit privilege
Users have already been registered into HiRDB. Registering users is not necessary unless they were deleted while HiRDB was operating.

All other users
If CONNECT privileges was not registered into HiRDB for some users, register this privilege into HiRDB for these users.

Accessing tables
If table access privileges were granted only to the role you belong to, you will not have table access privileges and will not be able to access any tables. If this situation occurs, request the administrator to grant you table access privileges. Also, you will only be able to use privileges information that was granted to your role. Request the administrator to provide the necessary privileges information to you.

Incorrect passwords
If the password registered into HiRDB is incorrect, use the GRANT CONNECT statement to modify the registered password.

24.6 Operations in the event of an error

The operating procedures in the event of an error are explained in this section.

Organization of this section

(1) In the event of a HiRDB error

(2) In the event of a Directory Server error

(1) In the event of a HiRDB error

Even if a HiRDB error occurs, it will not affect the Directory Server. Resolve the HiRDB error.

(2) In the event of a Directory Server error

If a Directory Server error occurs, the Directory Server will no longer perform user authentication and users will not be able to connect to HiRDB. For details about resolving errors, see Sun Java System Directory Server.

(a) Running HiRDB alone until the error is recovered

The procedure for running only HiRDB until an error in Directory Server is recovered is explained below.

Procedure

To run HiRDB alone:

Use pdstop command to terminate HiRDB normally.*

Delete pd_directory_server operand.

Use pdstart command to start HiRDB normally.

Use GRANT statement to grant CONNECT privilege to users who will be accessing HiRDB. Specify in the GRANT statement user IDs and passwords registered in Directory Server.

If table access privileges were granted to a role, use the GRANT statement to grant access privileges to the users belonging to that role.

* The system reconfiguration command (pcdhgconf command) makes it possible to modify the HiRDB system definition while HiRDB is operating. In such a case, it is not necessary to terminate HiRDB. Note that HiRDB Advanced High Availability must be installed in order to use this command. For details about modifying HiRDB system definitions while HiRDB is operating, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

(b) Resuming operation using the Directory Server linkage facility

Explained below is the procedure for resuming operation of the Directory Server linkage facility after recovering from a Directory Server error explained above in (a).

Procedure

To resume operations:

Use pdstop command to terminate HiRDB normally.*

Specify the pd_directory_server operand.

Use pdstart command to start HiRDB normally.

Use REVOKE statement to revoke CONNECT privileges and access privileges granted in procedure (a).

* The system reconfiguration command (pcdhgconf command) makes it possible to modify the HiRDB system definition while HiRDB is operating. In such a case, it is not necessary to terminate HiRDB. Note that HiRDB Advanced High Availability must be installed in order to use this command. For details about modifying HiRDB system definitions while HiRDB is operating, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

24.7 Creating the HiRDB LDAP Option environment definition file

You create the HiRDB LDAP Option environment definition file in the path $PDDIR/hirdb_ldap_sods/conf/pdsodsenv.txt. The operands specified in the HiRDB LDAP Option environment definition file are explained below.

Organization of this section

(1) Operands

(2) Example definition

(3) Notes

(1) Operands

1) LDAPHOST Host name of the Sun Java System Directory Server

~<identifier> <<localhost>>

Specifies the host name of Sun Java System Directory Server. You must specify this operand.

2) LDAPPORT Port number of the Sun Java System Directory Server

~<unsigned-integer> ((1-65535)) <<389>>

Specifies the TCP/IP port number that the Sun Java System Directory Server uses during LDAP communication. You must specify this operand.

3) BINDDN Bind DN for searching roles

~<identifier> <<anonymous>>

Specifies the DN in the management registry used for communicating with a remote server.

4) BINDPASSWORD Password for searching roles

~<identifier> <<anonymous>>

Specifies the password used when searching roles.

5) ROLEBASEDN Base DN for searching roles

~<identifier>

Specifies the base DN to be used for searching roles. You must specify this operand.

6) ROLESCOPE {base|one|sub}

Specifies the scope for searching roles. You must specify this operand.

base: Search only the layer of the search starting point.

one: Search the layer that is directly under the search starting point.

sub: Search the layer of the search starting point and all layers under it.

7) UIDKEY Attribute to use as the key for searching users

~<user-ID> <<uid>>

Specifies the attribute to be used as the key for searching users. You must specify this operand.

8) USERBASEDN Base DN for searching users

~<identifier>

Specifies base DN to be used for searching users. You must specify this operand.

9) USERSCOPE {base|one|sub}

Specifies the scope for searching users. Be sure to specify this operand.

base: Search only the layer of the search starting point.

one: Search the layer that is directly under the search starting point.

sub: Search the layer of the search starting point and all layers under it.

10) NETWORKTIMELIMIT Monitoring time for communication timeout

~<unsigned-integer>((0, 1-65535)) <<120>> (seconds)

Specifies in seconds the communication timeout value for the Sun Java System Directory Server. Specifying 0 in this operand disables timeout monitoring. Specify the value for this operand as follows:

NETWORKTIMELIMIT-value < pd_watch_time-value < PDCWAITTIME-value

NETWORKTIMELIMIT: Time limit for Sun Java System Directory Server communication.

pd_watch_time: Maximum execution time for SQL (specified in the HiRDB system definition).

PDCWAITTIME: Maximum wait time for the HiRDB client (specified in the client environment definition).

11) FILTERPREFIX Search filter prefix

~<identifier> <<(&(objectclass=inetOrgPerson))>>

Specifies a prefix for the search filter. The specified character string is prefixed to the search filter used when the Sun Java System Directory Server searches the DNs of user entries.

12) SERCHSUFFIX Search filter suffix

~<identifier> << ) >>

Specifies a suffix for the search filter. The specified character string is suffixed to the search filter used when the Sun Java System Directory Server searches the DNs of user entries.

13) SERCHTIMELIMIT Time limit for searching DNs of user entries

~<unsigned-integer> ((1-999)) <<60>> (seconds)

Specifies in seconds a maximum amount of time for the Sun Java System Directory Server to search the DNs of user entries.

14) RUNTIMEPATH Storage directory name for Sun ONE Directory Runtime

~<path-name> <<$PDDIR/hirdb_ldap_sods/sodruntime>>

Specifies as an absolute path name the storage directory for Sun ONE Directory Runtime. Use the Sun ONE Directory Runtime that is in the path specified by this operand. If no path name is specified, then the path name of Sun ONE Directory Runtime included with HiRDB LDAP Option is assumed.

If you specify a space for the path, an error may result (because such a file does not exist).

(2) Example definition

The following is an example definition of a HiRDB LDAP Option environment definition file:

LDAPHOST                    host1
LDAPPORT                    389
BINDDN              cn=USERA,ou=soft,o=hitachi
BINDPASSWORD        password
ROLEBASEDN          ou=soft,o=hitachi
ROLESCOPE           sub
UIDKEY              uid
USERBASEDN          ou=soft,o=hitachi
USERSCOPE           sub
NETWORKTIMELIMIT            120
FILTERPREFIX        (&(objectclass=inetOrgPerson)
SERCHSUFFIX         )
SERCHTIMELIMIT      60
RUNTIMEPATH

(3) Notes

Press the Enter key at the end of each line (including the last line).

Enter a space or tab between an operand name and its value.

If the same operand is specified more than once, the most recent specification is effective.

25. Using the System Switchover Facility

This chapter describes the environment setup and operation procedures for the system switchover facility. The explanations in this chapter assume a familiarity with cluster software (HA monitor, MC/ServiceGuard, VERITAS Cluster Server, Sun Cluster, HACMP, or ClusterPerfect).

Organization of this chapter

25.1 Overview of the system switchover facility

25.2 System configuration examples

25.3 IP address configuration examples

25.4 Handling of host names depending on whether or not IP addresses are inherited

25.5 HiRDB preparations

25.6 HA monitor preparations

25.7 MC/ServiceGuard preparations

25.8 VERITAS Cluster Server preparations

25.9 Sun Cluster preparations

25.10 HACMP preparations

25.11 ClusterPerfect preparations

25.12 Hitachi HA Toolkit Extension preparations (server mode only)

25.13 Differences in the HiRDB operating procedures

25.14 Planned system switchover

25.15 Grouped system switchover

25.16 Actions to be taken by the HiRDB administrator when errors occur

25.17 Operating procedures after system switchover

25.18 Reducing system switchover time (user server hot standby, rapid system switchover facility)

25.19 Transaction queuing facility

25.20 System switchover when errors other than server failures occur

25.21 Actions to take when a stopped unit prevents switching of the system manager unit

25.1 Overview of the system switchover facility

The objective of a system switchover facility is to improve the reliability and responsiveness of the system being used. This section explains the HiRDB system switchover facility and covers the following topics:

System switchover facility

Standby-less system switchover facility

Standby-less system switchover (1:1) facility

Standby-less system switchover (effects distributed) facility

Application criteria for system switchover facilities

Cluster software supported by HiRDB

Monitor mode and server mode

Organization of this section

25.1.1 System switchover facility (standby system switchover facility)

25.1.2 Standby-less system switchover facilities

25.1.3 Application criteria for the system switchover facilities

25.1.4 Cluster software supported by HiRDB

25.1.5 Monitor mode and server mode

25.1.1 System switchover facility (standby system switchover facility)

If a standby HiRDB is available in addition to the HiRDB that is currently performing work processing and an error occurs on the server machine or HiRDB performing the work processing, the work processing can be switched automatically to the standby HiRDB. The function that switches the system in this manner is called the system switchover facility (standby system switchover facility). Work processing is suspended when an error occurs but before the processing is switched to the standby HiRDB. The purpose of the system switchover facility is to minimize the system down time after an error occurs.

The system switchover facility is used in a cluster system configuration that uses more than one server machine. A HiRDB/Single Server performs system switchover at the system level (note that a utility special unit cannot perform system switchover). A HiRDB/Parallel Server performs system switchover at the unit level.

The system performing the work processing is called the running system, and the system that is standing by is called the standby system. Each time system switchover is performed, the running system becomes the standby system and the standby system becomes the running system. Also, to differentiate between the two systems during system construction and environment setup, the first system to start as the running system is called the primary system and the system that starts initially as the standby system is called the secondary system. Although the running system and the standby system change designations when system switchover occurs, the primary system and secondary system do not ever change those designations. Figure 25-1 provides an overview of the system switchover facility (standby system switchover facility).

Figure 25-1 Overview of the system switchover facility (standby system switchover facility)

¹ In this manual, a product that executes system switchover is called cluster software. For details about the cluster software supported by HiRDB, see 25.1.4 Cluster software supported by HiRDB.

² For details about shared disk units, see 25.5.2 Preparing a shared disk unit.

Explanation

If an error occurs on the running system, the standby system is notified of the error, the systems are switched, and the standby system takes over the work processing as the running system.

Notes about using ClusterPerfect

This manual refers to the running system of ClusterPerfect as the primary system and the secondary system of ClusterPerfect as the standby system.

25.1.2 Standby-less system switchover facilities

There are two types of system switchover. One is standby system switchover; the standby system switchover facility was discussed above. The other is standby-less system switchover, which consists of two facilities:

Standby-less system switchover (1:1) facility

Standby-less system switchover (effects distributed) facility

A standby-less system switchover facility can be applied only to a HiRDB/Parallel Server's back-end servers; it cannot be applied to a unit that contains servers other than back-end servers.

In contrast to the standby system switchover facility, a standby-less system switchover facility does not require that standby system units be prepared. When an error occurs, instead of switching over to a standby system unit, the system is switched over to another unit on the running system so that the work processing is taken over by an active back-end server. This is the function of the standby-less system switchover facilities.

Organization of this subsection

(1) Standby-less system switchover (1:1) facility

(2) Standby-less system switchover (effects distributed) facility

(1) Standby-less system switchover (1:1) facility

The standby-less system switchover (1:1) facility switches from a unit in which an error has occurred to a pre-designated back-end server unit that assumes the processing; i.e., there is a one-to-one relationship between the original unit and the unit to which processing is switched in the event of an error.

A back-end server that releases a process when an error occurs is called a normal BES, and a back-end server that takes over the process is called an alternate BES. Also, the unit of the normal BESs is called the normal BES unit, and the unit of the alternate BESs is called the alternate BES unit. Figure 25-2 provides an overview of the standby-less system switchover (1:1) facility.

Figure 25-2 Overview of the standby-less system switchover (1:1) facility

Explanation

BES1 and BES2 are both usually performing work processing.

If an error occurs on the normal BES unit (UNT1), the system is switched over and its processing is taken over by the alternate BES. The portion of the processing assumed by the alternate BES is called the alternate portion, and the act of taking over that processing by the alternate portion is called alternating.

After the error is resolved, the normal BES unit is started and the processing that the alternate BES assumed is switched back to the normal BES. In this way, this processing returns to normal status; this resumption of the original processing is called switching the system back.

Hint

The concepts of the primary system in the standby system switchover facility and in the standby-less system switchover (1:1) facility are compared below:

Think of the primary system as the normal BES unit, and think of the secondary system as the alternate BES unit.

During normal operation, think of the normal BES unit as the running system and think of the alternate portion as the standby system. In the alternating unit after alternation, think of the alternate portion as the running system, and think of the normal BES unit as the standby system.

Reference note

Because a unit that is running is used as the target for system switchover, a standby server machine is not needed. Therefore, in the case of standby-less system switchover, IP addresses are not transferred.

(a) Conditions

All the following conditions must be satisfied to use the standby-less system switchover (1:1) facility:

HiRDB Advanced High Availability must be installed.

Hitachi HA Toolkit Extension must be installed (it is not necessary for the HA monitor cluster software to be installed).

The system switchover facility must be operating in the server mode.

(b) Advantages of the standby-less system switchover facility

The standby-less system switchover (1:1) facility provides the following advantages over the standby system switchover facility:

Because it is not necessary to prepare a standby system unit, you use system resources more efficiently. However, when system switchover occurs, the load on the alternate BES increases, which may affect the processing performance of the server.

Because server processes and the system server are started in advance, the amount of time required to perform system switchover is reduced to approximately the same amount of time used by the rapid system switchover facility. For details about the rapid system switchover facility, see 25.18 Reducing system switchover time (user server hot standby, rapid system switchover facility).

Table 25-1 lists the resources that are needed when a standby system unit is standing by and after system switchover is performed.

Table 25-1 Resources needed when a standby unit is standing by and after system switchover is performed

Item | HiRDB system server processes | HiRDB server processes | Shared memory for unit controller | Shared memory for lock pool | Shared memory for global buffer
Standby-less system switchover (1:1) facility | Yes¹ | ²,³ | Yes⁴ | Yes | ⁵
Standby-less system switchover (effects distributed) facility | 6,7 | 3,8 | Yes⁹ | Yes | ¹⁰
Standby system switchover facility | User server host standby | No | Yes | No | No | No
Rapid system switchover facility | Yes | Yes | Yes | Yes | Yes
All others | No | No | No | No | No

Legend:

Yes: Resource is allocated while on standby and is also used after system switchover.

No: Resource is allocated at the time of system switchover, when it becomes the running system.

: Some resources are allocated and used after system switchover, when the standby system becomes the running system.

: Resource is not secured.

¹ Some processes of system server processing generate processes while they are standing by. Because other system servers share system server processes of the alternate BES unit, no resources are needed specifically for the alternate portion.

² The maximum number of back-end server processes is the value for pd_max_bes_process of the alternate BES. This value is the sum of the alternating processes and the non-alternating processes. Therefore, only a limited number of users may be able to connect after a system switchover.

³ If the value of pd_process_count (the number of resident processes) and the number of back-end server processes already activated when system switchover was performed is less than the value of pd_max_bes_process, additional back-end server processes can be activated. Be sure to set the OS's operating system parameters so there will be enough processes, virtual memory, ports, etc., for the operating system after system switchover is performed. Note also that activating additional back-end server processes may cause a temporary drop in performance after system switchover has been performed.

⁴ Shared memory of the alternate portion is secured when the alternate BES unit starts.

⁵ The global buffers used by alternate BESs are shared when alternating processes. Therefore, these buffer are not secured after system switchover occurs. For details about allocation of global buffers during alternating, see 25.5.7 Definition of global buffers (standby-less system switchover (1:1) facility only).

⁶ Because system server processes are shared on a unit-by-unit basis with the accepting units, no resources are required exclusively for the guest areas.

⁷ A system server process for a back-end server generates a process when it becomes the running system.

⁸ The maximum permissible number of HiRDB server (back-end server) processes in a unit after system switchover can normally be defined as the combined total of the number of processes for each back-end server and the number of processes for the guests (pd_ha_max_server_process).

⁹ When an accepting unit is started, shared memory is allocated for the guest areas.

¹⁰ Shared when the global buffer normally used by the back-end server is shared with the accepting unit. Therefore, it is not allocated after system switchover. For details about sharing a global buffer, see 25.5.8 Definition of global buffers (standby-less system switchover (effects distributed) facility only).

For details about a back-end server's resource usage status when the standby-less system switchover (effects distributed) facility is used, see 25.1.2(2) Standby-less system switchover (effects distributed) facility.

(c) Rules for defining normal BES units and alternate BES units

The rules for defining normal BES units and alternate BES units are explained below.

Only a back-end server can be defined for a normal BES unit or alternate BES unit. If another type of server is defined, the standby-less system switchover facility cannot be applied to that unit.

There must be one normal BES unit for every alternate BES unit.

There must be one normal BES for every alternate BES.

You can define more than one normal BES in a normal BES unit. When you do this, be sure to also define the same number alternate BESs in the alternate BES unit.

Figure 25-3 shows examples of valid configurations of a normal BES unit and alternate BES unit. Figure 25-4 shows examples of invalid configurations.

Figure 25-3 Examples of valid configurations of a normal BES unit and an alternate BES unit

An alternate BES is defined with the -c option in the pdstart operand. Example specifications of the pdstart operand are shown in Examples 1 and 2 below.

Example 1

pdstart -t BES -s bes11 -u UNT1 -c bes21
pdstart -t BES -s bes21 -u UNT2

Explanation

-s bes11: Specifies a normal BES.

-c bes21: Specifies an alternate BES.

Example 2

pdstart -t BES -s bes11 -u UNT1 -c bes21
pdstart -t BES -s bes12 -u UNT1 -c bes22
pdstart -t BES -s bes21 -u UNT2
pdstart -t BES -s bes22 -u UNT2

Explanation

-s bes11, -s bes12: Specifies a normal BES.

-c bes21, -c bes22: Specifies an alternate BES.

Figure 25-4 Examples of invalid configurations of a normal BES unit and an alternate BES unit

(2) Standby-less system switchover (effects distributed) facility

(a) Overview

When an error occurs, the standby-less system switchover (effects distributed) facility distributes processing requests intended for the back-end servers in the unit where the error occurred to multiple running units, where these processing requests can be executed. The standby-less system switchover (effects distributed) facility does not require standby server machines or standby units, and thus uses system resources more efficiently. After an error occurs, the processing workload increases at each unit that assumes server processing for the failed node; as a result, transaction-processing performance may be impacted negatively. However, because the processing requests intended for the servers in the failed unit are shared and executed by multiple units, the additional load per unit is kept low and degradation of system performance is minimized.

The standby-less system switchover (effects distributed) facility switches over back-end servers by distributing them, and the switchover destinations can be distributed among multiple units. Moreover, if an error occurs in a unit to which the original unit was switched, switching can be performed again to other running units, where processing can be continued; this is called multi-step system switchover. Multi-step system switchover cannot be performed in a system that uses the standby-less system switchover (1:1) facility; if an error occurs at a unit to which processing was switched in the case of the standby-less system switchover (1:1) facility, processing for the failed unit cannot be assumed and continued elsewhere.

The standby-less system switchover (effects distributed) facility is appropriate for a system whose resources must always be used efficiently and in which performance degradation because of an error must be minimized.

In the standby-less system switchover (effects distributed) facility, a back-end server defined in the original unit is called a host BES, and a back-end server that is accepted by another unit is called a guest BES. The unit where the host BESs are defined is called the regular unit, and the unit where a guest BES is located is called the accepting unit. All accepting units must be defined as an HA group. The back-end server resources that correspond to a guest BES constitute a guest area.

Figure 25-5 provides an overview of the standby-less system switchover (effects distributed) facility (distributed workload transfer and multi-step system switchover).

Figure 25-5 Overview of the standby-less system switchover (effects distributed) facility (distributed workload transfer and multi-step system switchover)

(b) Conditions

All the following conditions must be satisfied to use the standby-less system switchover (effects distributed) facility:

HiRDB Advanced High Availability must be installed.

Hitachi HA Toolkit Extension must be installed (not required if the cluster software is HA monitor).

The system switchover facility must be used in the server mode.

The standby-less system switchover (effects distributed) facility is applicable to back-end server units that consist only of back-end servers.

A unit to which the standby-less system switchover (effects distributed) facility is to be applied must consist of one or more primary system back-end servers. This facility cannot be applied to an accepting-only unit.

(c) Resource usage status

Table 25-2 shows the usage status of back-end server resources when the standby-less system switchover (effects distributed) facility is being applied.

Table 25-2 Usage status of back-end server resources when the standby-less system switchover (effects distributed) facility is applied

Back-end server type | Back-end server status | Resource usage status
Host BES | Accepting status | An area of the size required by the back-end server's definition is created.
Running | An area of the size required by the back-end server's definition is used.
Guest BES | Accepting status | For each resource, a guest area of the largest resource size is created in the guest server.
Running | Within the prepared guest area, an area that matches the size required by the back-end server's definition is used.

(d) Operation of the standby-less system switchover (effects distributed) facility

When the standby-less system switchover (effects distributed) facility is used and an error occurs in a regular unit, that unit's primary BESs are moved automatically to various accepting units where they execute their processing as guest BESs. If a BES at the unit where the error occurs is itself a guest BES, it also is moved automatically to an accepting unit where it continues to execute processing as a guest BES. As is the case with the standby system switchover facility, no intervention is required from the HiRDB administrator.

Table 25-3 lists the various types of errors that can occur and whether or not system switchover occurs when standby-less system switchover (effects distributed) is used.

Table 25-3 System switchover depending on error cause when standby-less system switchover (effects distributed) facility is used

Unit's status
Starting or Stopping
Running

Server's status
Starting or Stopping
Starting or Stopping
Running

Slow-down detected
Not applicable
Unit terminates abnormally.
System switchover occurs.
Unit terminates abnormally.
System switchover occurs.

System log full
Not applicable
Unit terminates abnormally.
System switchover does not occur.
Unit terminates abnormally.
System switchover does not occur.

Database path error
Not applicable
Unit terminates abnormally.
System switchover occurs (only the first time).
Unit terminates abnormally.
System switchover occurs (only the first time).

Back-end server terminated forcibly
Back-end server terminates abnormally.
System switchover does not occur.
Back-end server terminates abnormally.
System switchover does not occur.
Back-end server terminates abnormally.
System switchover does not occur.

System terminated forcibly
Unit terminates abnormally.
System switchover does not occur.
Unit terminates abnormally.
System switchover does not occur.
Unit terminates abnormally.
System switchover does not occur.

System failure
Unit terminates abnormally.
System switchover does not occur.
Unit terminates abnormally.
System switchover does not occur.
Unit terminates abnormally terminated
System switchover occurs.

In the event of system switchover, the host BESs and any guest BESs that are running in the unit are switched over to other units. The back-end servers may be switched to different destinations.

The standby-less system switchover (effects distributed) facility switches systems automatically when various types of errors occur. If an error occurs in an accepting unit after an error had occurred in a regular unit, the back-end servers of the primary system and the guest BESs running in the failed accepting unit move to remaining running units and execute their processing as guest BESs; no intervention is required from the HiRDB administrator. The move destination of each back-end server is determined by the HA monitor definition (cluster software definition when Hitachi HA Toolkit Extension is used).

When a unit runs out of its free guest area, the standby-less system switchover (effects distributed) facility cancels the accepting status of all guest BESs that are not running. The acceptability of a guest area is not affected by the operation of the host BES. Table 25-4 shows automatic cancellation and resetting of acceptability depending on the free space in the guest area.

When acceptability is reset automatically, all servers that are acting as running systems in other units within the HA group enter accepting status. During this process, even those back-end servers whose acceptability was stopped intentionally by entry of a command (monsbystp or pdstop -q -s back-end-server-name) also become accepting. If the number of BESs that can be accepted within an HA group is exceeded, resulting in reduced-mode operation, any server that is stopped is not returned to accepting status.

Table 25-4 Automatic cancellation and resetting of acceptability depending on the free space in the guest area

Unused guest area in the unit | Guest BES acceptability
Guest BESs active in other units | Guest BESs inactive in other units
Disappeared | Cancelled automatically | No change (being cancelled)
Generated | Reset automatically | No change

Note

This table excludes the situation in which the monsbystp command or the pdstop command (pdstop -u accepting-unit-ID -s server-ID) was used to cancel acceptability intentionally.

(e) Examples of system switchover using the standby-less system switchover (effects distributed) facility

Example of system switchover during normal operations

Figure 25-6 shows an example of system switchover during a time of normal operations.

When an error occurs at hostA, BES1 moves to unt2 and executes processing as a guest BES; BES2 moves to unt3 and executes processing as a guest BES.

Figure 25-6 Example of system switchover during normal operations

Example of system switchover at a host that has accepted guest BESs

Figure 25-7 shows an example of system switchover at a host that has accepted guest BESs. In this example, after a server machine has been restored but before it is reactivated, an error occurs in another server machine.

If an error occurs in hostA while BES5 is executing processing at unt1 as a guest BES, the individual back-end servers behave as follows:

BES1 moves to unt2 and executes processing as a guest BES.

BES2 moves to unt3 and executes processing as a guest BES.

BES5 returns to unt3 and executes processing as a host BES.

Figure 25-7 Example of system switchover at a host that has accepted guest BESs

Unbalanced unit loading

Whether the workloads will become unbalanced among the units following system switchover depends on the priorities assigned to the standby systems in the cluster software definition. If the priorities of the standby systems are set appropriately, workloads will be balanced even after multiple units have terminated abnormally in any combination.

However, if system switchover occurs as a result of an error in another unit after a unit has been recovered from an error, the workloads may become unbalanced. For this reason, you should check the allocation of servers after system switchover. You use the pdls -d ha or pdls -d svr command to check the allocation of servers.

If the server allocation is unbalanced, you should use planned system switchover to modify the allocation of the servers.

Additionally, as soon as possible after a unit has been recovered from an error, you should return each BES to the unit where it is defined. This helps prevent server allocation from becoming unbalanced. In the example shown in Figure 25-7, hosts have accepted guest BESs; if BES5 and BES6 are returned to unt3 before the error occurs in host A, the error in hostA will not result in unbalanced server allocation.

System switchover when a series of errors occurs (when all back-end servers are in accepting status)

Figure 25-8 shows an example of system switchover when a series of errors occurs.

Figure 25-8 Example of system switchover when a series of errors occurs

Explanation

An error occurs at hostA, so BES1 is moved to unt2 and BES2 is moved to unt3, where they execute processing as guest BESs. Because the maximum number of BESs that can be accepted by unt2 and unt3 is 4 each, they can now each accept three more servers. In other words, all back-end servers running at all other units can be accepted.

If an error occurs subsequently at hostB, BES1, BES3, and BES4 running in unt2 all move to unt3 and execute processing as guest BESs. No back-end server stops.

System switchover when a series of errors occurs (when the number of BESs that can be accepted is insufficient)

Figure 25-9 shows an example of system switchover when a series of errors occurs but the number of BESs that can be accepted is insufficient.

Figure 25-9 Example of system switchover when a series of errors occurs but the number of BESs that can be accepted is insufficient

Explanation

An error occurs in hostA, so BES1 is moved to unt2 and BES2 is moved to unt3, where they execute processing as guest BESs. Because the maximum number of BESs that can be accepted by unt2 and unt3 is 2 each, they can now each accept only one more server. In other words, not all the back-end servers running at other units can be accepted.

If an error occurs subsequently at hostB, only BES3 running in unt2 moves to unt3 and executes processing as a guest BES; BES1 and BES4 stop.

If it is critical that processing continue at back-end servers even when a series of errors occurs, you must set an appropriately large value for the maximum number of BESs that can be accepted.

System switchover when the number of BESs that can be accepted is insufficient

Whether a back-end server in a unit is switched to another unit or is stopped when an error occurs is determined by the priority for system switchover that is assigned to each back-end server. This order is determined by an action of the cluster software.

In this example, only BES3 was moved. However, depending on the action of the cluster software, BES1 or BES4 might have been moved.

Example of the action to take when an error occurs while the number of BESs that can be accepted is insufficient

Figure 25-10 shows an example of the action to take when an error occurs while the number of BESs that can be accepted is insufficient.

Figure 25-10 Example of the action to take when an error occurs while the number of BESs that can be accepted is insufficient

Explanation

HostB is recovered from an error and unt2 starts. As a result, BES4 starts as the running system in unt2 and BES1 can be accepted.

Next, when the monact command is entered for BES1 in unt2, BES1 begins processing as a guest BES (when Hitachi HA Toolkit Extension is used, an online command of the cluster software is used).

Example of how to avoid a shortage in the number of BESs that can be accepted

If you cannot set a large value for the number of BESs that can be accepted, you must correct errors as soon as possible in order to prevent server stoppage as a result of a shortage in the number of BESs that can be accepted.

Figure 25-11 shows an example of how to avoid a shortage in the number of BESs that can be accepted.

Figure 25-11 Example of how to avoid a shortage in the number of BESs that can be accepted

Explanation

HostA is recovered from an error and unt1 starts. As a result, BES1 and BES2 start as standby systems in unt1, so that BES3, BES4, BES5, BES6 become accepting. Therefore, even if an error occurs in hostB, BES1 and BES4 can continue processing at hostA while BES3 can continue processing at hostC.

System switchover when a series of errors occurs (when no BES can be accepted)

Figure 25-12 shows an example in which system switchover cannot be executed when a series of errors occurs.

Figure 25-12 Example in which system switchover cannot be executed when a series of errors occurs

Explanation

An error occurs in hostA, so BES1 is moved to unt2 and BES2 is moved to unt3, where they execute processing as guest BESs. Because the maximum number of BESs that can be accepted by unt2 and unt3 is 1 each, neither of them can now accept any more servers.

If an error occurs subsequently at hostB, BES1, BES3, and BES4 stop.

If it is critical that processing continue at back-end servers, even when a series of errors occurs, you must set an appropriately large value for the maximum number of BESs that can be accepted. The action to take when no more servers can be accepted and the method of avoiding server stoppage are the same as indicated above for the case where the number of BESs that can be accepted is insufficient.

25.1.3 Application criteria for the system switchover facilities

Organization of this subsection

(1) Application criteria

(2) Usability of each system switchover facility when another system switchover facility is already being used

(1) Application criteria

Table 25-5 shows the application criteria for the system switchover facilities.

Table 25-5 System switchover facility application criteria

Importance
Standby system switchover facility
Standby-less system switchover (1:1) facility
Standby-less system switchover (effects distributed) facility

Transaction performance
Best
Poor
Good

Maintains performance even when an error occurs.

Guarantees the same throughput as during normal operations.

Load from alternate processing when an error occurs may impact processing performance.

Load concentration on certain units reduces system throughput.

Load from alternate processing when an error occurs may impact processing performance.

Load distribution is used to minimize system throughput degradation.

Resource requirement
Poor
Best
Best

Needs standby server machines or system resources for standby units.
Does not need standby server machines or system resources for standby units.
Does not need standby server machines or system resources for standby units.

Handling of a series of errors
Best
Poor
Best

Can handle based on linkage with cluster software (only when IP addresses are inherited, and not when the rapid system switchover facility is used).
Cannot handle because there is only one fixed alternate server.
Can handle based on linkage with cluster software.

(2) Usability of each system switchover facility when another system switchover facility is already being used

Table 25-6 shows when each system switchover facility can be applied to a unit when a different system switchover facility is already being applied to another unit within the same system.

Table 25-6 Usability of each system switchover facility when another system switchover facility is already being used for another unit within the same system

Facility already being used | Usability of the standby system switchover facility | Usability of the standby-less system switchover (1:1) facility | Usability of the standby-less system switchover (effects distributed) facility
Standby system switchover facility | Y | Y | Y
Standby-less system switchover (1:1) facility | Y | Y | N
Standby-less system switchover (effects distributed) facility | Y | N | Y*

Legend:

Y: Can be used.

N: Cannot be used.

* Only one HA group can be used at the switching destination.

25.1.4 Cluster software supported by HiRDB

The cluster software that HiRDB supports is listed in Table 25-7.

Table 25-7 Cluster software supported by HiRDB

Cluster software supported by HiRDB | Operating system
HP-UX | Solaris | AIX 5L | Linux
HA monitor | Yes | No | Yes | Yes
MC/ServiceGuard | Yes | No | No | No
VERITAS Cluster Server | No | Yes | No | No
Sun Cluster | No | Yes | No | No
HACMP | No | No | Yes | No
ClusterPerfect | No | No | No | Yes

Legend:

Yes: Supported

No: Not supported

Note

For details about each type of cluster software, see its manual.

Supported functions differ depending on the type of cluster software used. For details about the functions supported by each type of cluster software, see Table 25-8 Functional differences between the monitor mode and the server mode and Table 25-9 Cluster software that can be operated in the server mode.

25.1.5 Monitor mode and server mode

Organization of this subsection

(1) Functional differences between the monitor mode and the server mode

(2) Cluster software that can be operated in the server mode

(3) Products required for operation in the server mode

(1) Functional differences between the monitor mode and the server mode

The two operation modes for the system switchover facility are the monitor mode and the server mode. When operating in the monitor mode, only system failures are monitored. When operating in the server mode, both system and server failures are monitored. Also, system switchover can be performed more quickly in the server mode. The functional differences between the monitor mode and the server mode are listed in Table 25-8.

Table 25-8 Functional differences between the monitor mode and the server mode

Item or function | Monitor mode | Server mode
Failures that are monitored | System failures¹ | Yes | Yes
Server failures² | No | Yes
Function that reduces system switchover time | User server standby³ | No | Yes
Rapid system switchover facility³ | No | Yes
Standby-less system switchover facility | Standby-less system switchover (1:1) facility | No | Yes
Standby-less system switchover (effects distributed) facility | No | Yes

Legend:

Yes: Is monitored or can be used.

No: Is not monitored or cannot be used.

¹ Errors such as those listed below are assumed to be system failures. However, the conditions for system failures are dependent on the cluster software specifications. For details, check the cluster software documentation or other applicable documentation.

Hardware failures

Operating system failures

Power outages

Cluster software failures

System slowdowns

² Errors such as those listed below are assumed to be server failures.

HiRDB abnormal termination (HiRDB/Parallel Server)

HiRDB slowdown (or unit slowdown in the case of a HiRDB/Parallel Server)

Database path error

³ This is a function that reduces the system switchover time. For details about user server hot standby and the rapid system switchover facility, see 25.18 Reducing system switchover time (user server hot standby, rapid system switchover facility).

(2) Cluster software that can be operated in the server mode

Some cluster software cannot operate in the server mode. Cluster software that can be operated in the server mode is listed in Table 25-9.

Table 25-9 Cluster software that can be operated in the server mode

Cluster software | Monitor mode | Server mode
HA monitor | Yes | Yes
MC/ServiceGuard | Yes | Yes
VERITAS Cluster Server | Yes | Yes
Sun Cluster | Yes | No
HACMP | Yes | No
ClusterPerfect | Yes | No

Legend:

Yes: Can be operated in this mode.

No: Cannot be operated in this mode.

Note

In the Linux (EM64T) version, the system switchover facility in the server mode is not supported.

(3) Products required for operation in the server mode

The products required to operate the system switchover facility in the server mode are listed in Table 25-10.

Table 25-10 Products required for operation in the server mode

Function | HiRDB Advanced High Availability | Hitachi HA Toolkit Extension
Server mode | -- | Required#
User server hot standby | -- | Required#
Rapid system switchover facility | -- | Required#
Standby-less system switchover (1:1) facility | Required | Required#
Standby-less system switchover (effects distributed) facility | Required | Required#

Legend:

Required: This product is required for operation in the server mode.

--: Not required.

# When the cluster software being used is HA monitor, Hitachi HA Toolkit Extension is not required.

25.2 System configuration examples

This section explains system configuration examples for when the system switchover facility is in use.

Organization of this section

25.2.1 System configuration examples of a HiRDB/Single Server (standby system switchover)

25.2.2 System configuration examples of a HiRDB/Parallel Server

25.2.3 System configuration examples of standby-less system switchover (1:1)

25.2.4 System configuration examples of standby-less system switchover (effects distributed)

25.2.1 System configuration examples of a HiRDB/Single Server (standby system switchover)

A HiRDB/Single Server performs system switchover at the system level. System configuration examples of a HiRDB/Single Server are explained below.

Organization of this subsection

(1) Example of a 1-to-1 switchover configuration

(2) Example of a mutual system switchover configuration

(3) Sharing a utility special unit among multiple HiRDB/Single Servers

(4) Setting up a 1:1 correspondence between HiRDB/Single Servers and utility special units

(5) Setting up an m:n correspondence between HiRDB/Single Servers and utility special units

(1) Example of a 1-to-1 switchover configuration

A configuration in which there is a one-to-one correspondence between the running system and the standby system is called a 1-to-1 switchover configuration. This configuration is appropriate when it is important to guarantee response time when system switchover becomes necessary. The drawback of this configuration is that you cannot utilize the resources of the server machine in the standby system (you do not have access to the resources of one of your two server machines). Figure 25-13 shows an example of a 1-to-1 switchover configuration for a HiRDB/Single Server.

Figure 25-13 System configuration example for HiRDB/Single Servers (1-to-1 switchover configuration)

* This product is required in order to operate the system switchover facility in the server mode. However, it is not required when the cluster software in use is HA monitor.

Remarks

Each server machine requires an input/output device for use by utilities.

To execute a utility after system switchover has occurred, you must create on the local server machine the input/output files required to execute that utility.

(2) Example of a mutual system switchover configuration

A system configuration in which the running system has a system on the same server machine that acts as a mutual standby system (standby system for another HiRDB/Single Server) is called a mutual system switchover configuration. This configuration can be applied when multiple HiRDB/Single Servers are being used. This configuration is appropriate for making efficient use of server machine resources. However, response time slows when system switchover occurs.

Figure 25-14 shows an example of a system configuration that includes mutual system switchover for HiRDB/Single Servers. In this example, the mutual system switchover configuration is applied to HiRDB/Single Servers A and B.

Figure 25-14 System configuration example for HiRDB/Single Servers (mutual system switchover)

* This product is required in order to operate the system switchover facility in the server mode. However, it is not required when the cluster software in use is HA monitor.

Remarks

Each server machine requires an input/output device for use by utilities.

To execute a utility after system switchover has occurred, you must create on the local server machine the input/output files required to execute that utility.

In the case of a system switchover configuration, if a host name is specified in a utility control statement, you must change the host name when the systems are switched.

(3) Sharing a utility special unit among multiple HiRDB/Single Servers

Figure 25-15 shows an example of sharing a utility special unit among multiple HiRDB/Single Servers. Note that system switchover cannot be performed on utility special units.

Figure 25-15 Sharing a utility special unit among multiple HiRDB/Single Servers

* This product is required in order to operate the system switchover facility in the server mode. However, it is not required when the cluster software in use is HA monitor.

(4) Setting up a 1:1 correspondence between HiRDB/Single Servers and utility special units

Figure 25-16 shows an example of setting up a 1:1 correspondence between HiRDB/Single Servers and utility special units.

Figure 25-16 Setting up a 1:1 correspondence between HiRDB/Single Servers and utility special units

* This product is required in order to operate the system switchover facility in the server mode. However, it is not required when the cluster software in use is HA monitor.

(5) Setting up an m:n correspondence between HiRDB/Single Servers and utility special units

Figure 25-17 shows an example of setting up an m:n correspondence between HiRDB Single Servers and utility special units.

Figure 25-17 Setting up a m:n correspondence between HiRDB/Single Servers and utility special units

* This product is required in order to operate the system switchover facility in the server mode. However, it is not required when the cluster software in use is HA monitor.

Explanation

The host whose name was specified in executing the utility can select the utility special unit to be used.

Setting up multiple utility special units can increase the reliability of your system.

25.2.2 System configuration examples of a HiRDB/Parallel Server

A HiRDB/Parallel Server performs system switchover at the unit level. System configuration examples for a HiRDB/Parallel Server are explained below.

Organization of this subsection

(1) Example of a 1-to-1 switchover configuration

(2) Example of mutual system switchover configuration

(1) Example of a 1-to-1 switchover configuration

A configuration in which there is a one-to-one correspondence between the running system and the standby system is called a 1-to-1 switchover configuration. This configuration is appropriate when it is important to guarantee response time when system switchover becomes necessary. The drawback of this configuration is that you cannot utilize the resources of the server machine in the standby system (you do not have access to the resources of one of your two server machines). Figure 25-18 shows an example of a 1-to-1 switchover configuration for a HiRDB/Parallel Server.

Figure 25-18 System configuration example for a HiRDB/Parallel Server (1-to-1 switchover configuration)

* This product is required in order to operate the system switchover facility in the server mode. However, it is not required when the cluster software in use is HA monitor.

(2) Example of mutual system switchover configuration

A system configuration in which the running system has a system on the same server machine that acts as its mutual standby system (standby system for another unit) is called a mutual system switchover configuration. In a HiRDB/Parallel Server, systems can be switched over in units. Therefore, whereas a mutual system switchover configuration cannot be applied to a single HiRDB/Single Server, it can be applied to a single HiRDB/Parallel Server. When a mutual system switchover configuration is applied to a HiRDB/Parallel Server, the running unit and the standby unit (standby unit for another unit) can be positioned within the same server machine. This configuration is appropriate for making efficient use of server machine resources. However, response time slows when system switchover occurs.

Figure 25-19 shows an example of a mutual system switchover configuration for a HiRDB/Parallel Server.

Figure 25-19 System configuration example for a HiRDB/Parallel Server (mutual system switchover)

* This product is required in order to operate the system switchover facility in the server mode. However, it is not required when the cluster software in use is HA monitor.

For examples of the HiRDB system definitions for the mutual system switchover configuration, see the manual HiRDB Version 8 System Definition.

Note

If you use the mutual system switchover configuration (or the 2-to-1 switchover configuration), two units may run on a single server machine. Therefore, you must pay attention to the following:

The HiRDB directory names

The port numbers

When running these two units on a single server machine, give each unit a different name and port number. Also, if IP addresses will not be inherited after system switchover, you must also pay attention to the following:

Host names and IP addresses

Provide each unit on the same server machine with a unique host name and IP address.

Figure 25-20 shows an example of correct host name setup; Figure 25-21 shows an example of incorrect host name setup.

Figure 25-20 Example of correct host name setup

The following is an example of correct pdunit operand specifications:

pdunit -x hostA -u UNT1  ...  -c hostAA
pdunit -x hostB -u UNT2  ...  -c hostBB

Furthermore, host names corresponding to different IP addresses must be specified for hostA, hostAA, hostB, and hostBB.

Figure 25-21 Example of incorrect host name setup

The following is an example of incorrect pdunit operand specifications:

pdunit -x hostA -u UNT1  ...  -c hostB
pdunit -x hostB -u UNT2  ...  -c hostA

Explanation

If IP addresses are not to be inherited in a mutual system switchover configuration, the host names specified in the -x and -c options of the pdunit operand must all be different (host names cannot be duplicated).

25.2.3 System configuration examples of standby-less system switchover (1:1)

This section describes typical system configuration examples of standby-less system switchover (1:1).

Organization of this subsection

(1) Mutual alternating configuration

(2) One-way alternating configuration

(3) System configuration example combining standby-less (1:1) and standby system switchover

(1) Mutual alternating configuration

In this configuration, two back-end servers become each other's alternate BESs. Figure 25-22 shows a system configuration example of a mutual alternating configuration.

Figure 25-22 System configuration example of a mutual alternating configuration

* When the cluster software being used is HA monitor, Hitachi HA Toolkit Extension is not required.

Explanation

BES1 is the alternate BES for BES2. When an error occurs in BES2, the alternate portion of BES2 takes over the BES2 processing.

BES2 is the alternate BES for BES1. When an error occurs in BES1, the alternate portion of BES1 takes over the BES1 processing.

(2) One-way alternating configuration

This configuration alternates only in a single direction in 1:1 standby-less system switchover. Figure 25-23 shows a system configuration example of a one-way alternating configuration (2-node configuration).

Figure 25-23 System configuration example of a one-way alternating configuration (2-node configuration)

* When the cluster software being used is HA monitor, Hitachi HA Toolkit Extension is not required.

Explanation

BES2 is the alternate BES for BES1. When an error occurs in BES1, the alternate portion of BES1 takes over the BES1 processing. When an error occurs in BES2, BES1 does not take over the BES2 processing.

(3) System configuration example combining standby-less (1:1) and standby system switchover

Figure 25-24 shows a system configuration example combining standby-less (1:1) and standby system switchover. For example HiRDB system definitions for this system configuration, see the manual HiRDB Version 8 System Definition.

Figure 25-24 System configuration example combining standby-less (1:1) and standby system switchover

* When the cluster software being used is HA monitor, Hitachi HA Toolkit Extension is not required.

Explanation

The standby system switchover facility (mutual system switchover configuration) is applied to the MGR, FES, and DS units. To facilitate operation after system switchover, a configuration that inherits IP addresses is used. Also, user server hot standby is applied.

The standby-less system switchover (1:1) facility (mutual alternate configuration) is applied to BES units.

HiRDB Advanced High Availability must be installed on all server machines. Server machines that do not apply the standby-less system switchover facility and server machines that do not apply the system switchover facility must also run HiRDB Advanced High Availability.

25.2.4 System configuration examples of standby-less system switchover (effects distributed)

Organization of this subsection

(1) System configuration example

(2) Determining the switching destination for each server

(3) Configuration with five units

(1) System configuration example

Figure 25-25 shows a system configuration example of standby-less system switchover (effects distributed). When an error occurs in the regular unit, processing intended for the back-end servers in the primary system where the error occurred is divided in units of back-end servers, assumed by multiple running server machines, and executed.

Figure 25-25 System configuration example of standby-less system switchover (effects distributed)

Explanation

When an error occurs in Unit 1, BES1 executes its processing in Unit 2 as a guest BES, and BES2 executes its processing in Unit 3 as a guest BES.

If an error occurs in Unit 2 while Unit 1 is still in error status, BES1, BES2, BES3, and BES4 all execute their processing in Unit 3 as guest BESs.

(2) Determining the switching destination for each server

When you use the standby-less system switchover (effects distributed) facility, HiRDB takes the following issues into consideration in determining the switching destinations for the individual servers:

Balancing among the units the number of running guest BESs

Balancing among the units the number of servers that share each global buffer

When standby-less system switchover (effects distributed) is used, HiRDB uses the following procedure to determine switching destinations:

Procedure

Determines the switching-destination unit for the server that has the highest priority among all servers. The following are the determination criteria:
Balancing the number of servers to be switched from one unit to other units
Balancing among the units at the switching destination the number of servers that will share a global buffer

From i = 1 to [number-of-units-in-HA-group - 2], steps 3 through 9 are repeated.

Selects a server with priority ranking of i + 1 whose switching destination has not been determined.

If there is an applicable server, the process proceeds to step 5. If there is no applicable server, i = i + 1 is set and the process returns to step 3.

Assumes that switching destinations 1 through i must be determined for the selected servers, and that the unit to which these servers belong is the erroneous unit.

Units other than the erroneous unit are selected as switching destination candidates.

From the servers belonging to the erroneous unit, all servers that have switching destination candidates as defined switching destinations are extracted, and it is assumed that guest BESs for the server in question are allocated to the switching-destination unit with the highest priority.

From the servers belonging to the erroneous unit, all servers that do not have switching destination candidates as defined switching destinations are extracted, and the i +1-th switching-destination unit is determined for each server. The following are the determination criteria:
The unit with the smallest number of guest BESs is selected.
Units in which fewer guest BESs share a global buffer with the server are selected.

Returns to step 3.

(a) Configuration with four units

The standby-less system switchover (effects distributed) facility is applied to the following configuration consisting of four units:

In this case, a global buffer is shared in each of the following groups:

Group A: BES1A, BES2A, BES3A, and BES4A

Group B: BES1B, BES2B, BES3B, and BES4B

Group C: BES1C, BES2C, BES3C, and BES4C

Determining the switching-destination unit with the highest priority
An example is shown that determines the switching-destination unit with the highest priority for BES3B. A switching destination is determined so that it does not coincide with servers that share the same global buffer (BES1B and BES2B) or BES3A. Specifically, unt1 is selected because the switching destination of BES1B (unt3), the switching destination of BES2B (unt4), and the switching destination of BES3A (unt4) cannot be selected.

Server | Host BES | Highest priority | Second priority | Third priority
BES1A | unt1 | unt2 | Allocated | Allocated
BES1B | unt3 | Allocated | Allocated
BES1C | unt4 | Allocated | Allocated
BES2A | unt2 | unt3 | Allocated | Allocated
BES2B | unt4 | Allocated | Allocated
BES2C | unt1 | Allocated | Allocated
BES3A | unt3 | unt4 | Allocated | Allocated
BES3B | unt1 | Allocated | Allocated
BES3C | Allocated | Allocated | Allocated
BES4A | unt4 | Allocated | Allocated | Allocated
BES4B | Allocated | Allocated | Allocated
BES4C | Allocated | Allocated | Allocated

Determining the switching-destination unit with the second or subsequent priority
An example is shown that determines the switching-destination unit with the second priority for BES2B.
First, unt4, which is a defined switching destination of BES2B, and unt2, to which BES2C belongs, are assumed to be erroneous units (step 5), and unt1 and unt3 are selected as switching-destination candidates (step 6). Next, from the servers belonging to the erroneous units (unt2 and unt4), servers (BES2A, BES2C, BES4A, and BES4C) that have the switching destination candidates as defined switching destinations are extracted, and it is assumed that guest servers are allocated as shown below (step 7).
BES2A: unt3; BES2C: unt1; BES4A: unt1; and BES4C: unt3
Next, servers (BES2B and BES4B) that do not contain the switching destination candidates as defined switching destinations are extracted, and the switching-destination unit with the second priority is determined. In this case, the number of guest BESs is the same for unt1 and unt3, and BES2B and BES4B share a global buffer, and therefore, BES2B is switched to unt1 and BES4B is switched to unt3.

Server
Host BES
Highest priority
Second priority
Third priority

BES1A
unt1
Switching-destination candidate unit
unt2
unt4
Allocated

BES1B
unt3
unt2
Allocated

BES1C
unt4
unt2
Allocated

BES2A
unt2
Erroneous unit
unt3
unt1
Allocated

BES2B
unt4
unt1
Allocated

BES2C
unt1
Allocated
Allocated

BES3A
unt3
Switching-destination candidate unit
unt4
Allocated
Allocated

BES3B
unt1
Allocated
Allocated

BES3C
unt2
Allocated
Allocated

BES4A
unt4
Erroneous unit
unt1
Allocated
Allocated

BES4B
unt2
Allocated
Allocated

BES4C
unt3
Allocated
Allocated

Table 25-11 shows an example of switching destination definition in a 4-unit configuration.

Table 25-11 Switching destination definition example in a 4-unit configuration

Server | Host BES | Highest priority | Second priority | Third priority
BES1A | unt1 | unt2 | unt4 | unt3
BES1B | unt3 | unt2 | unt4
BES1C | unt4 | unt2 | unt3
BES2A | unt2 | unt3 | unt1 | unt4
BES2B | unt4 | unt1 | unt3
BES2C | unt1 | unt3 | unt4
BES3A | unt3 | unt4 | unt2 | unt1
BES3B | unt1 | unt4 | unt2
BES3C | unt2 | unt4 | unt1
BES4A | unt4 | unt1 | unt3 | unt2
BES4B | unt2 | unt3 | unt1
BES4C | unt3 | unt1 | unt2

(3) Configuration with five units

The standby-less system switchover (effects distributed) facility is applied to the following configuration consisting of five units:

In this case, a global buffer is shared in each of the following groups:

Group A: BES1A, BES2A, BES3A, BES4A, and BES5A

Group B: BES1B, BES2B, BES3B, BES4B, and BES5B

Group C: BES1C, BES2C, BES3C, BES4C, and BES5C

Group D: BES1D, BES2D, BES3D, BES4D, and BES5D

Table 25-12 shows an example of switching destination definition in a 5-unit configuration.

Table 25-12 Switching destination definition example in a 5-unit configuration

Server | Host BES | Highest priority | Second priority | Third priority | Fourth priority
BES1A | unt1 | unt2 | unt5 | unt3 | unt4
BES1B | unt3 | unt4 | unt2 | unt5
BES1C | unt4 | unt3 | unt5 | unt2
BES1D | unt5 | unt2 | unt4 | unt3
BES2A | unt2 | unt3 | unt1 | unt4 | unt5
BES2B | unt4 | unt5 | unt1 | unt3
BES2C | unt5 | unt4 | unt3 | unt1
BES2D | unt1 | unt3 | unt5 | unt4
BES3A | unt3 | unt4 | unt2 | unt1 | unt5
BES3B | unt5 | unt1 | unt2 | unt4
BES3C | unt1 | unt5 | unt4 | unt2
BES3D | unt2 | unt4 | unt5 | unt1
BES4A | unt4 | unt5 | unt3 | unt1 | unt2
BES4B | unt1 | unt2 | unt3 | unt5
BES4C | unt2 | unt1 | unt5 | unt3
BES4D | unt3 | unt5 | unt2 | unt1
BES5A | unt5 | unt1 | unt4 | unt2 | unt3
BES5B | unt2 | unt3 | unt1 | unt4
BES5C | unt3 | unt2 | unt4 | unt1
BES5D | unt4 | unt1 | unt3 | unt2

25.3 IP address configuration examples

The network configuration and operating procedures depend on whether or not IP addresses are inherited after system switchover. For the applicable procedures, refer to the following sections:

25.4 Handling of host names depending on whether or not IP addresses are inherited

25.17 Operating procedures after system switchover

This section explains the differences between network configurations.

Guidelines

For the standby system switchover facility, Hitachi recommends strongly that you use a system configuration that inherits IP addresses after system switchover. A system configuration that does not inherit IP addresses after system switchover will be more difficult to operate than a system configuration that does inherit IP addresses.

Some cluster software will inherit IP addresses after system switchover and other cluster software will not. For details, see the documentation for each cluster software product.

For units that apply the rapid system switchover facility, use a system configuration that does not inherit IP addresses after system switchover.

Because a host that is already running takes over processing in a standby-less system switchover facility, IP addresses are not inherited.

Use of alias IP addresses is recommended.

When the server mode is used for the Linux version of HiRDB, a system configuration that does not inherit IP addresses is used.

Organization of this section

(1) When IP addresses are inherited

(2) When IP addresses are not inherited

(1) When IP addresses are inherited

The two methods of inheriting IP addresses described below are as follows:

Switching the IP address

Switching LAN adapters

(a) Switching the IP address

You switch the IP address by using an alias IP address (you stop one IP address and start the other). In this way, you use the same IP address and host name for the primary system and the secondary system. Figure 25-26 shows a network configuration example of inheriting IP addresses (switching the IP address).

Figure 25-26 Network configuration example when inheriting IP addresses (switching the IP address)

(b) Switching LAN adapters

You prepare a maintenance LAN adapter in addition to the LAN adapter that HiRDB uses and you switch the LAN adapter that is being used (stop one LAN adapter and start the other one). Then, you use the same IP address and host name for the primary system and the secondary system. Figure 25-27 shows a network configuration example of inheriting IP addresses (switching LAN adapters).

Figure 25-27 Network configuration example when inheriting IP addresses (switching LAN adapters)

(2) When IP addresses are not inherited

Standby-less system switchover (1:1) facility

When IP addresses are not inherited, different IP addresses and host names are used for the primary and secondary systems. This means that the host name for the secondary system must be specified in the pdunit -c operand in the HiRDB system common definition.

Standby-less system switchover (effects distributed) facility

Different IP addresses and host names are used for the regular unit and the accepting unit. Specifying the pdunit -c operand is not necessary.

Figure 25-28 shows an example of a network configuration when IP addresses are not inherited.

Figure 25-28 Example of network configuration when IP addresses are not inherited

Notes (applicable to the standby system switchover facility only)

When you use HiRDB/Single Servers, specify the host name of the primary system and secondary system in the PDHOST operand of the client environment definition.

When a unit in the system manager does not inherit IP addresses after system switchover, specify the host names of the primary system and secondary system in the PDHOST operand of the client environment definition. When a unit in the front-end server does not inherit IP addresses after system switchover, specify the host names of the primary system and secondary system in the PDFESHOST operand of the client environment definition. If you specify the host names in this manner, changing the value specified in the PDHOST or PDFESHOST operand is not necessary even after system switchover occurs.

If the running system switches from the primary system to the secondary system when the host names of the primary system and secondary system are specified in the PDHOST operand, a UAP will attempt to connect to the primary system (standby system). Because such a UAP connects to the secondary system (running system) after the connection could not be established, the UAP processing time increases by the amount of time it takes to establish this new connection. To resolve this problem, set the host name for the client connection to an alias IP address and make sure that IP addresses are inherited. For details about specifying host names in such cases, see 25.4 Handling of host names depending on whether or not IP addresses are inherited.

25.4 Handling of host names depending on whether or not IP addresses are inherited

This section explains the procedures for handling (specifying) host names depending on whether or not IP addresses are inherited.

Organization of this section

25.4.1 HiRDB/Single Server

25.4.2 HiRDB/Parallel Server

25.4.1 HiRDB/Single Server

Organization of this subsection

(1) IP addresses inherited

(2) IP addresses not inherited

(3) IP addresses not inherited (only IP addresses for client connection inherited)

(1) IP addresses inherited

The following explains the procedure for handling (specifying) host names when IP addresses are inherited. The system configuration in this case is a 1-to-1 switchover configuration.

System configuration example (when switching the IP address)

System configuration example (when switching LAN adapters)

Item
Host name to be specified

Host name specified in system common definition
pdunit -x hostA
pdunit -x hostC
pdstart -x hostA

Host name specified in unit control information definition
pd_hostname=host1

Host name specified during rlogin
hostA

Host name specified in operation commands*
For single server
hostA (host name should be omitted)

For utility special unit
hostC

Host name specified in utilities
For single server
hostA (host name should be omitted)

For utility special unit
hostC

Host name displayed in messages
hostA

Host name displayed in statistical information
hostA

Host name specified in PDHOST operand of client environment definition
hostA

* The unit identifier may be specified instead of the host name.

(2) IP addresses not inherited

The following explains the procedure for handling (specifying) host names when IP addresses are not inherited. The system configuration in this case is a 1-to-1 switchover configuration.

System configuration example

Hint

If the default host names are the same (host1 = host2), HiRDB cannot recognize a system switchover. Therefore, use different default host names.

Item
Host name to be specified

Host name specified in system common definition
pdunit -x hostA -c hostB
pdunit -x hostC
pdstart -x hostA

Host name specified in unit control information definition
pd_hostname=host1

Host name specified during rlogin
hostA or hostB (specify the host name of the running system)

Host name specified in operation commands¹
For single server
hostA (host name should be omitted)

For utility special unit
hostC

Host name specified in utilities
For single server
hostA (host name should be omitted)

For utility special unit
hostC

Host name displayed in messages
hostA

Host name displayed in statistical information
hostA

Host name specified in PDHOST operand of client environment definition
hostA and hostB²

¹ The unit identifier may be specified instead of the host name.

² Specify the host names of the primary system and secondary system in the PDHOST operand of the client environment definition. If you specify the host names in this manner, changing the value specified in the PDHOST operand will not be necessary, even after a system switchover. However, when the running system switches from the primary system to the secondary system, a UAP attempts to connect to the primary system (standby system). Because the UAP connects to the secondary system (running system) after the connection could not be established, the UAP processing time increases by the amount of time it takes to establish this new connection. To resolve this problem, set the host name for the client connection to an alias IP address and make sure that IP addresses are inherited. For details about specifying host names in such cases, see (3) IP addresses not inherited (only IP addresses for client connection inherited).

(3) IP addresses not inherited (only IP addresses for client connection inherited)

The following explains the procedure for handling (specifying) host names when the IP addresses HiRDB/Single Servers use are not inherited, but IP addresses for client connections are inherited. The system configuration in this case is a 1-to-1 switchover configuration.

System configuration example

Explanation

hostA and hostB are the host names the HiRDB/Single Server uses. These hosts do not inherit IP addresses.

hostC is the host name (alias IP address) used for client connection. This host inherits IP addresses.

Hint

If the default host names are the same (host1 = host2), HiRDB cannot recognize a system switchover. Therefore, use different default host names.

Item
Host name to be specified

Host name specified in system common definition
pdunit -x hostA -c hostB
pdstart -x hostA

Host name specified in unit control information definition
pd_hostname=host1

Host name specified during rlogin
hostA or hostB (specify the host name of the running system)

Host name specified in operation commands*
hostA (host name should be omitted)

Host name specified in utilities
hostA (host name should be omitted)

Host name displayed in messages
hostA

Host name displayed in statistical information
hostA

Host name specified in PDHOST operand of client environment definition
hostC

* The unit identifier may be specified instead of the host name.

25.4.2 HiRDB/Parallel Server

Organization of this subsection

(1) IP addresses inherited

(2) IP addresses not inherited

(3) IP addresses not inherited (only IP addresses for client connection inherited)

(1) IP addresses inherited

The following explains the procedure for handling (specifying) host names when IP addresses are inherited. The system configuration in this case is a mutual system switchover configuration.

System configuration example

Item
Host names to be specified

Host names specified in system common definition
pdunit -x hostA -u UNT1
pdunit -x hostB -u UNT2
pdunit -x hostC -u UNT3
pdunit -x hostD -u UNT4

Host names specified in the unit control information definition
Unit 1
pd_hostname=host1

Unit 2
pd_hostname=host2

Unit 3
pd_hostname=host3

Unit 4
pd_hostname=host4

Host name specified during rlogin
rlogin in server machine where BES1 is located
hostC

rlogin in server machine where BES2 is located
hostD

Host name specified in operation commands*
Execution of operation commands in BES1
hostC

Execution of operation commands in BES2
hostD

Host name specified in utilities
Execution of utilities in BES1
hostC

Execution of utilities in BES2
hostD

Host name displayed in messages
Messages for BES1
hostC

Messages for BES2
hostD

Host name displayed in statistical information
Statistical information about BES1
hostC

Statistical information about BES2
hostD

Host name specified in the following client environment definitions:

PDHOST

PDFESHOST

hostA

* The unit identifier may be specified instead of the host name.

(2) IP addresses not inherited

The following explains the procedure for handling (specifying) host names when IP addresses are not inherited. The system configuration in this case is a mutual system switchover configuration.

System configuration example

Hint

If the standard host names are the same (host1 = host2, host3 = host4), HiRDB cannot recognize a system switchover. Therefore, use different default host names.

Item
Host names to be specified

Host names specified in system common definition
pdunit -x hostA -u UNT1 -c hostAA
pdunit -x hostB -u UNT2 -c hostBB
pdunit -x hostC -u UNT3 -c hostCC
pdunit -x hostD -u UNT4 -c hostDD

Host names specified in the unit control information definition
Unit 1
pd_hostname=host1

Unit 2
pd_hostname=host2

Unit 3
pd_hostname=host3

Unit 4
pd_hostname=host4

Host name specified during rlogin
rlogin in server machine where BES1 is located
hostC or hostD (specify the host name of the running system)

rlogin in server machine where BES2 is located
hostC or hostD (specify the host name of the running system)

Host name specified in operation commands¹
Execution of operation commands in BES1
hostC

Execution of operation commands in BES2
hostD

Host name specified in utilities
Execution of utilities in BES1
hostC

Execution of utilities in BES2
hostD

Host name displayed in messages
Messages for BES1
hostC

Messages for BES2
hostD

Host name displayed in statistical information
Statistical information about BES1
hostC

Statistical information about BES2
hostD

Host name specified in the following client environment definitions:

PDHOST

PDFESHOST

hostA and hostB²

¹ The unit identifier may be specified instead of the host name.

² When units in the system manager do not inherit IP addresses, specify the host names of the primary system and secondary system in the PDHOST operand of the client environment definition. When units in the front-end server do not inherit IP addresses, specify the host names of the primary system and secondary system in the PDFHESHOST operand of the client environment definition. If you specify the host names in this manner, changing the value specified in the PDHOST or PDFESHOST operand is not necessary even after system switchover occurs. However, if the running system switches from the primary system to the secondary system, a UAP attempts to connect to the primary system (standby system). Because the UAP connects to the secondary system (running system) after the connection could not be established, the UAP processing time increases by the amount of time it takes to establish this new connection. To resolve this problem, set the host name for the client connection to an alias IP address and make sure that IP addresses are inherited. For details about specifying host names in such cases, see (3) IP addresses not inherited (only IP addresses for client connection inherited).

(3) IP addresses not inherited (only IP addresses for client connection inherited)

The following explains the procedure for handling (specifying) host names when IP addresses HiRDB/Parallel Servers use are not inherited, but IP addresses for client connections are inherited. The system configuration in this case is a 1:1 mutual system switchover configuration.

System configuration example

Explanation

hostA is the host name used by Unit 1 (primary system). hostA does not inherit IP addresses. hostAA is the host name used by Unit 1 (secondary system).

hostB is the host name used by Unit 2 (primary system). hostB does not inherit IP addresses. hostBB is the host name used by Unit 2 (secondary system).

hostC is the host name used by Unit 3 (primary system). hostC does not inherit IP addresses. hostCC is the host name used by Unit 3 (secondary system).

hostD is the host name used by Unit 4 (primary system). hostD does not inherit IP addresses. hostDD is the host name used by Unit 4 (secondary system).

hostX to hostZ are the host names (alias IP addresses) used for client connections. These hosts inherit IP addresses.

Hint

If the standard host names are the same (host1 = host2, host3 = host4), HiRDB cannot recognize a system switchover. Therefore, use different default host names.

Item
Host names to be specified

Host names specified in system common definition
pdunit -x hostA -u UNT1 -c hostAA
pdunit -x hostB -u UNT2 -c hostBB
pdunit -x hostC -u UNT3 -c hostCC
pdunit -x hostD -u UNT4 -c hostDD

Host names specified in the unit control information definition
Unit 1
pd_hostname=host1

Unit 2
pd_hostname=host2

Unit 3
pd_hostname=host3

Unit 4
pd_hostname=host4

Host name specified during rlogin
rlogin in server machine where BES1 is located
hostC or hostD (specify the host name of the running system)

rlogin in server machine where BES2 is located
hostC or hostD (specify the host name of the running system)

Host name specified in operation commands*
Execution of operation commands in BES1
hostC

Execution of operation commands in BES2
hostD

Host name specified in utilities
Execution of utilities in BES1
hostC

Execution of utilities in BES2
hostD

Host name displayed in messages
Messages for BES1
hostC

Messages for BES2
hostD

Host name displayed in statistical information
Statistical information about BES1
hostC

Statistical information about BES2
hostD

Host name specified in client environment definition
PDHOST
hostG

PDFESHOST
hostX or hostY (specify the host name of the connected front-end server)

* The unit identifier may be specified instead of the host name.

25.5 HiRDB preparations

Executor: HiRDB administrator

This section explains the procedures for preparing HiRDB. This section covers the following topics:

Conditions and notes

Preparing a shared disk unit

Creating HiRDB system definitions

Client environment definition specification

Specification examples of host names in HiRDB system definitions and client environment definitions

RDAREA creation

Definition of global buffers (standby-less system switchover (1:1) facility only)

Definition of global buffers (standby-less system switchover (effects distributed) facility only)

Using audit trail files

Organization of this section

25.5.1 Conditions and notes

25.5.2 Preparing a shared disk unit

25.5.3 Creating HiRDB system definitions

25.5.4 Client environment definition specification

25.5.5 Specification examples of host names in HiRDB system definitions and client environment definitions

25.5.6 RDAREA creation

25.5.7 Definition of global buffers (standby-less system switchover (1:1) facility only)

25.5.8 Definition of global buffers (standby-less system switchover (effects distributed) facility only)

25.5.9 Using audit trail files

25.5.1 Conditions and notes

Organization of this subsection

(1) Standby system switchover facility

(2) Standby-less system switchover (1:1) facility

(3) Standby-less system switchover (effects distributed) facility

(1) Standby system switchover facility

(a) Information needed in the primary and secondary systems

It is essential to check that the following information is the same in both systems (primary system and secondary system):

Versions of HiRDB and related programs

HiRDB administrator's environment (user ID, group ID, and environment variables)

Absolute path names of the HiRDB directories

HiRDB system definitions

HiRDB file definition formats

Users' execute-form programs

(b) Notes on environment setup

Set up the HiRDB environment in both the primary system and the secondary system. Use the same version of HiRDB in the primary system and the secondary system. Also, when upgrading HiRDB, be sure to upgrade both the primary system and the secondary system.

Do not create the HiRDB directory on a shared disk.

When a DNS server is not used, register a re-allocatable IP address in the hosts file.

To operate a HiRDB/Parallel Server in the server mode, install the following products and set up the environment:

Hitachi HA Toolkit Extension (for the primary and secondary system machines) (not necessary when the cluster software used is HA monitor)

The system switchover facility is not applicable to a recovery-unnecessary front-end server unit.

Notes on using ClusterPerfect

Use the following command to stop the ClusterPerfect daemon before setting up the HiRDB environment; to execute this command, you must have root privileges:

# /etc/rc.d/init.d/dncware_daemon stop

Execute the following command to start the ClusterPerfect daemon:

# /etc/rc.d/init.d/dncware_daemon start

(2) Standby-less system switchover (1:1) facility

Install and set up the environment for the following products:

HiRDB Advanced High Availability (for all server machines)

Hitachi HA Toolkit Extension (for normal BES and alternate BES units) (not necessary when the cluster software used is HA monitor)

Define only back-end servers on the normal BES units and alternate BES units. The standby-less system switchover (1:1) facility cannot be used on units that include servers other than back-end servers.

There is no need to provide a HiRDB directory for an alternate BES.
Because the standby-less system switchover (1:1) facility uses the HiRDB directory of an alternate BES unit, there is no need to provide HiRDB directories specifically for the alternate BESs. That is, the pdsetup command is not necessary for an alternate BES.

Allocate system definition files.
In each unit comprising the group, allocate a back-end server definition file to each back-end server. The parameters to be set in the unit control information definition as the default values for back-end server definition must be defined in the system common definition or a back-end server definition file.

(3) Standby-less system switchover (effects distributed) facility

Install and set up the environment for the following products:

HiRDB Advanced High Availability (for all server machines)

Hitachi HA Toolkit Extension (for the regular units and accepting units) (not necessary when the cluster software used is HA monitor)

Define only back-end servers on regular units and accepting units. Units that include servers other than back-end servers cannot be used with the standby-less system switchover (effects distributed) facility.

There is no need to provide a HiRDB directory for a guest BES.
Because the standby-less system switchover (effects distributed) facility uses the HiRDB directory of an accepting unit, there is no need to provide HiRDB directories specifically for the guest BESs. That is, the pdsetup command is not necessary for a guest BES.

Allocate system definition files.
In each unit comprising the HA group, allocate a back-end server definition file to each back-end server. The parameters to be set in the unit control information definition as the default values for back-end server definitions must be defined in the system common definition or a back-end server definition file.

25.5.2 Preparing a shared disk unit

There must be an external hard disk that can be shared between the primary system and the secondary system (or between the normal BES and the alternate BES in the case of the standby-less system switchover facility). This hard disk is called a shared disk unit.

Organization of this subsection

(1) Shared disk allocation

(2) Shared disk access control

(1) Shared disk allocation

Figure 25-29 shows shared disk allocation.

Figure 25-29 Shared disk allocation

Explanation

When you use the standby system switchover facility or the standby-less system switchover (1:1) facility, allocate a shared disk to each unit because system switchover occurs on a unit-by-unit basis.

When you use the standby-less system switchover (effects distributed) facility, allocate a shared disk to each server because system switchover occurs on a server-by-server basis. You cannot store information from multiple servers in a single shared disk.

The following HiRDB file system areas are created in a shared disk unit:

HiRDB file system area for RDAREAs

HiRDB file system area for system files

HiRDB file system area for backup files

HiRDB file system area for unload log files

Notes

Set up these HiRDB file system areas so that the HiRDBs of both the primary system and the secondary system can reference the shared disk unit using the same path name. When you use the standby-less system switchover (1:1) facility, set up these HiRDB file system areas so that both the normal BES unit and the alternate BES unit can reference the shared disk unit using the same path name. When you use the standby-less system switchover (effects distributed) facility, set up these HiRDB file system areas so that all units within the HA group can reference the shared disk unit using the same path name. However, for the standby-less system switchover (effects distributed) facility, create the unit status file in an independent, non-shared disk that is different from those used for server status files, system log files, and synchronization point dump files.

The shared disk in which HiRDB file system areas for shared RDAREAs are created must be activated in the write mode from all units. For this reason, the disk must not be deactivated or activated in conjunction with system switchover.

Only HiRDB file system areas created in character special files can be shared. HiRDB file system areas in regular files cannot be shared.

Do not use regular files on a shared disk. If system switchover occurs when regular files are in a status that does not apply to shared disks (for example, data remains in the operating system cache even though HiRDB finished writing it to the target files), any updates made to the files may be lost.

(2) Shared disk access control

When the system switchover source and target both attempt to access the shared disk at the same time while the system switchover facility is being used, the database may become corrupted. For this reason, accesses from the system to the shared disk must be controlled. This shared disk access control is performed by either the cluster software or HiRDB.

Normally, the method described in (a) Shared disk access control by the cluster software is used to perform access control on the shared disk. To use the method described in (b) Shared disk access control by HiRDB, HA monitor 01-08 or later is required.

(a) Shared disk access control by the cluster software

The cluster software can perform access control on the shared disk. It exercises controls so that the running system is active and the standby and stopped systems are inactive, which means that only the running system can access the shared disk. Figure 25-30 shows how the cluster software exercises control over shared disk access.

Figure 25-30 Shared disk access control by the cluster software

Explanation

Because an inactive system cannot access the shared disk, only the running system is capable of accessing the shared disk.

For details about the shared disk switching method (between active and inactive), see the cluster software documentation.

If you are using HA monitor, you must specify the disk operand in the HA monitor's servers definition statement.

(b) Shared disk access control by HiRDB

To use HiRDB to perform access control on the shared disk, HA monitor 01-08 or later is required.

HiRDB can perform access control on the shared disk. In such a case, shared disk switching (between active and inactive) is not performed. System switchover takes place in the following sequence:

A failure that results in system switchover occurs.

HiRDB confirms that all processes (HiRDB processes) have terminated in the source system.

System switchover takes place.

The target system starts accessing the shared disk.

Figure 25-31 shows the shared disk access control that is provided by HiRDB.

Figure 25-31 Shared disk access control by HiRDB

Criteria
You should use HiRDB to perform shared disk access control in the following cases:

When the Linux OS in being used
Character special files on LVM are not supported in the Linux version, but LVM is required by a shared disk whose access is to be controlled by the HA monitor. For this reason, the method described in (a) Shared disk access control by the cluster software cannot be used.

When shared RDAREAs are used
When shared RDAREAs are used, the shared disk that contains a shared RDAREA must be made active from all server machines where a back-end server is located. If an updatable back-end server and a reference-only back-end server are both located in the same server machine, the updatable back-end server becomes the target of system switchover. If shared disk switching occurs in such a case, the shared RDAREA can no longer be referenced from the reference-only back-end server. Therefore, the method described in (a) Shared disk access control by the cluster software cannot be used.

When Real Time SAN Replication is used in the log-only synchronous method
When Real Time SAN Replication is used in the log-only synchronous method, TrueCopy is used at the log application site to copy system files from a remote location. When TrueCopy is used, LVM cannot be used, but LVM is required for a shared disk whose access is to be controlled by the HA monitor. For this reason, the method described in (a) Shared disk access control by the cluster software cannot be used.

HiRDB environment settings
You must specify the following operands in the HiRDB system definition:

pd_ha_prc_cleanup_check = Y
When Y is specified in this operand, system switchover takes place only after all processes have terminated in the unit. In the case of the standby-less system switchover (effects distributed) facility, system switchover is executed after all processes have terminated at the back-end servers.

pd_ha_switch_timeout = Y
System switchover may be delayed for a reason such as ongoing disk I/O processing. When Y is specified in this operand, the HA monitor treats it as a server (HiRDB) slowdown and resets the system, so that system switchover can take place.

HA monitor environment settings
The following are the operand specification requirements in the HA monitor's servers definition statement:

pairdown
You must specify use:serv_slow in this operand.
Termination of processes may not be confirmed, such as when a process does not terminate at the source system or when HiRDB slows down. Such an event prevents system switchover from being executed. When this operand is specified, the system is reset to allow execution of system switchover when termination of processes cannot be confirmed for a reason such as a slowdown.

disk
Omit this operand because the HA monitor is not used to perform access control on the shared disk.

25.5.3 Creating HiRDB system definitions

Organization of this subsection

(1) Standby system switchover facility

(2) Standby-less system switchover (1:1) facility

(3) Standby-less system switchover (effects distributed) facility

(4) HiRDB system definition operands related to the system switchover facility

(5) Specifying the switching destination (standby-less system switchover (effects distributed) facility only)

(6) Allocating server processes following system switchover

(1) Standby system switchover facility

Use the same HiRDB system definitions in the primary system and the secondary system. Create the HiRDB system definitions for the primary system, then copy those HiRDB system definitions to the secondary system. Figures 25-32 and 25-33 show configuration examples of the HiRDB system definition files.

Figure 25-32 Configuration example of HiRDB system definition files when using the standby system switchover facility (for a HiRDB/Single Server)

Figure 25-33 Configuration example of HiRDB system definition files when using the standby system switchover facility (for a HiRDB/Parallel Server)

(2) Standby-less system switchover (1:1) facility

Copy the unit control information definition file and back-end server definition file of the normal BES unit to the alternate BES unit. Change the name of the unit control information definition file as shown below:

pdutsys.unit-identifier-of-normal-BES-unit

Of the operands specified in this definition file, those whose settings become effective during alternation are listed below. For all other operands (other than those listed below), the values that are set in the unit control information definition file of the alternate BES unit are effective.

pd_syssts_file_name_1 to 7

pd_syssts_singleoperation

pd_syssts_initial_error

pd_syssts_last_active_file

pd_syssts_last_active_side

pd_audit

pd_aud_file_name

pd_aud_max_generation_size

pd_aud_max_generation_num

pd_aud_async_buff_size

pd_aud_async_buff_count

pd_ha_switch_timeout

pd_rpl_hdepath

Figure 25-34 shows a configuration example of the HiRDB system definition files when using the standby-less system switchover facility (mutual alternating configuration).

Figure 25-34 Configuration example of HiRDB system definition files when using the standby-less system switchover facility (mutual alternating configuration)

Explanation

Copy the unit control information definition file and back-end server definition file of the normal BES unit (BES1) to the alternate BES unit (BES2). Then change the name of the unit control information definition file to pdutsys.UNT1.

Copy the unit control information definition file and back-end server definition file of the normal BES unit (BES2) to the alternate BES unit (BES1). Then change the name of the unit control information definition file to pdutsys.UNT2.

(3) Standby-less system switchover (effects distributed) facility

Table 25-13 shows how system definition files are used when standby-less system switchover (effects distributed) is used.

Table 25-13 Use of system definition files when standby-less system switchover (effects distributed) is used

Definition type
Use of definition files

System common definition
Copy files to all units within the system.
Specify in the system common definition the parameters that are to be set as the default values for back-end server definitions.

Unit control information definition
Specify only the following operands (operands that cannot be specified in the system common definition):

pd_unit_id

pd_hostname

pd_ha_unit

pd_rpl_hdepath

pd_ha_restart_failure

pd_ha_acttype

pd_ha_server_process_standby

pd_ha_agent

pd_ha_max_act_guest_servers

pd_ha_max_server_process

pd_ha_resource_act_wait_time

pd_ha_process_count

pd_syssts_file_name_17

pd_syssts_initial_error

pd_syssts_last_active_file

pd_syssts_last_active_side

pd_syssts_singleoperation

Specify all other operands in the system common definition or in back-end server definitions. If any operand other than those listed above is specified, an error occurs (and the KFPS05618-E message is output).

Server common definition
Copy files to all units within the HA group.

Back-end server definition
Copy files to all units within the HA group.

(4) HiRDB system definition operands related to the system switchover facility

Table 25-14 explains the HiRDB system definition operands that relate to the system switchover facility.

Table 25-14 HiRDB system definition operands related to the system switchover facility

Operand name
Explanation and Notes

pd_ha
Specifies that the system switchover facility is to be used.

pd_ha_ipaddr_inherit
Specifies whether or not IP addresses are to be inherited after a system switchover. Specify N for units using the rapid system switchover facility. Omit this operand for units using the standby-less system switchover facility.
Y: Inherit IP addresses after system switchover.
N: Do not inherit IP addresses after system switchover.

pd_ha_unit
Specify nouse for any unit that is not to use the system switchover facility. You must specify nouse for a recovery-unnecessary front-end server.

pd_ha_acttype
Specifies whether the system switchover facility is to be used in the monitor mode or the server mode. The server mode cannot be used when the system switchover facility uses Sun Cluster, HACMP, or ClusterPerfect.
monitor: Operate the system switchover facility in the monitor mode.
server: Operate the system switchover facility in the server mode.

pd_ha_restart_failure
When operating the system switchover facility in the monitor mode, specifies a command to be executed if the restarting HiRDB fails. This operand has no effect when you use the server mode.

pd_ha_server_process_standby
Specifies whether or not user server hot standby is to be used.
Y: Use user server hot standby.
N: Do not use user server hot standby.

pd_ha_agent
Specifies the system switchover facility to be used:
standbyunit: Rapid system switchover facility
server: Standby-less system switchover (1:1) facility
activeunits: Standby-less system switchover (effects distributed) facility

pd_ha_transaction
pd_ha_trn_queuing_wait_time
pd_ha_trn_restart_retry_time

Specify these operands when you use the transaction queuing facility.

If you specify queuing in the pd_ha_transaction operand and the maximum number of concurrent connections (value of the pd_max_users operand) is exceeded, the HiRDB client will make retries to connect to the HiRDB server for only the amount of time that is equal to pd_ha_trn_queuing_wait_time + pd_ha_trn_restart_retry_time.

pd_ha_switch_timeout
This operand can be specified when the server mode is used. This operand is invalid if it is specified in the monitor mode.
This operand specifies whether or not system switchover is to performed without waiting for HiRDB termination processing when termination processing of HiRDB (or the unit for a HiRDB/Parallel Server) during system switchover exceeds the server failure monitoring time. Server failure monitoring time refers to the time specified in the patrol operand of HA monitor or Hitachi HA Toolkit Extension.
Y: Switch systems without waiting for HiRDB termination processing when HiRDB termination processing during system switchover exceeds the server failure monitoring time.
N: Do not switch systems until HiRDB termination processing during system switchover terminates.

pd_ha_prc_cleanup_check
Specifies whether or not system switchover processing is to be placed on hold until HiRDB processes have terminated. For details, see 25.5.2(2) Shared disk access control.

pd_mode_conf
This operand is related to HiRDB (or unit) startup. Specify this operand as follows:
When the monitor mode is used, specify MANUAL1.
When the server mode is used, specify one of the following:

MANUAL2 if switch is specified in the switchtype operand of the servers definition of Hitachi HA Toolkit Extension.

MANUAL1 if restart or manual is specified in the switchtype operand of the servers definition of Hitachi HA Toolkit Extension.

pd_hostname
Specifies the standard host name of the primary system. When using the standby-less system switchover facility, specifies the unit's standard host name. (This is the same as when not using the system switchover facility.)

pdunit
-x
Specifies the host name of the primary system. When using the standby-less system switchover facility, specifies the unit's host name. (This is the same as when not using the system switchover facility.)

-u
Specifies the unit identifier.

-d
Specifies the HiRDB directory name. When using the standby-less system switchover (1:1) facility, specify the same directory name for the normal BES unit and the alternate BES unit. When using the standby-less system switchover (effects distributed) facility, specify the same directory name for all units within the HA group.

-c
Specifies the host name of the secondary system. Specify this option when not inheriting IP addresses after system switchover. Omit this option when using the standby-less system switchover facility.

-p
Specifies the port number. Specify this option when using a utility special unit or HiRDB/Parallel Server. When using the standby-less system switchover (1:1) facility, specify the same port number for the normal BES unit and the alternate BES unit. When using the standby-less system switchover (effects distributed) facility, specify the same port number for all units within the HA group.

pdstart
-c
Specifies the alternate BES name. Specify this option when using the standby-less system switchover (1:1) facility.

-g
When using the standby-less system switchover (effects distributed) facility, specify the identifier of the HA group that constitutes the set of units that become server switching destinations.

pdbuffer
-c
Specify this option when allocating global buffers that the alternate portion uses when alternating units. Specify this option when using a standby-less system switchover facility. For details when using the standby-less system switchover (1:1) facility, see 25.5.7 Definition of global buffers (standby-less system switchover (1:1) facility only); for details when using the standby-less system switchover (effects distributed) facility, see 25.5.8 Definition of global buffers (standby-less system switchover (effects distributed) facility only).

pdhagroup
-g
To use the standby-less system switchover (effects distributed) facility, you define an HA group that will constitute the set of units that will become server switching destinations. Specify an identifier that will uniquely identify this HA group within the system.

-u
Specifies the unit identifiers of the units that are to comprise the HA group.

pd_ha_max_act_guest_servers
When using the standby-less system switchover (effects distributed) facility, specifies the maximum number of guest BESs that will be permitted to run concurrently in a unit.

pd_ha_max_server_process
When using the standby-less system switchover (effects distributed) facility, specifies the maximum permissible number of active user server processes in a unit.

pd_ha_resource_act_wait_time
When the standby-less system switchover (effects distributed) facility is used, specifies the maximum time to wait until the running server's resources are activated when the unit is started.

pd_service_port
Care must be exercised in specifying this operand in a server machine configuration that includes multiple units (including a mutual system switchover configuration). For such a configuration (including a mutual system switchover configuration), use this operand to specify a separate port number for each unit in its unit control information definition.
If either of the following specifications is made, system switchover to one of the units fails:

The pd_service_port operand of the system common definition is specified (when the pd_service_port operand of the unit control information definition is not specified).

A port number that is specified in the pd_service_port operand of another unit control information definition is specified in the pd_service_port operand of the unit control information definition.

pd_redo_allpage_put
When Y is specified in this operand, all pages that have been updated since a synchronization point are written into the database during full recovery processing that occurs when HiRDB is restarted. This can eliminate inconsistencies between the original and duplicate volumes that occurred during system switchover.
For details about how to handle inconsistencies between the original and duplicate volume, see 18.24 Actions to take when a mismatch occurs between the original and the mirror duplicate.

pd_ha_mgr_rerun
When notwait is specified in this operand, HiRDB does not wait to receive a processing startup completion notice from each unit when switching system manager units (when starting processing at the switching destination). As a result, system manager units can be switched even when some units are stopped.
For details about the operation method, see 25.21 Actions to take when a stopped unit prevents switching of the system manager unit.

(5) Specifying the switching destination (standby-less system switchover (effects distributed) facility only)

When the standby-less system switchover (effects distributed) facility is used, the method of determining the switching destination differs significantly from when the other system switchover facilities are used.

(a) Accepting unit

Because the standby-less system switchover (effects distributed) facility switches systems on a server-by-server basis, a switching destination must be specified for each server. You may specify multiple accepting units for a server. Multiple accepting units are defined as an HA group, you must specify an HA group as the switching destination for each server.

When you use the standby-less system switchover (effects distributed) facility, you can also specify the maximum number of guest BESs that will be permitted to run concurrently in each unit (pd_ha_max_act_guest_servers).

Figure 25-35 shows an example of an HA group configuration.

Figure 25-35 HA group configuration example

pdhagroup -g hag1 -u unt1,unt2,unt3,unt4

pdstart -t BES -s bes1A -u unt1 -g hag1
pdstart -t BES -s bes1B -u unt1 -g hag1
pdstart -t BES -s bes1C -u unt1 -g hag1
pdstart -t BES -s bes2A -u unt2 -g hag1
pdstart -t BES -s bes2B -u unt2 -g hag1
pdstart -t BES -s bes2C -u unt2 -g hag1
pdstart -t BES -s bes2D -u unt2 -g hag1
pdstart -t BES -s bes3A -u unt3 -g hag1
pdstart -t BES -s bes3B -u unt3 -g hag1
pdstart -t BES -s bes3C -u unt3 -g hag1
pdstart -t BES -s bes4A -u unt4 -g hag1
pdstart -t BES -s bes4B -u unt4 -g hag1

(b) HA group definition

You use the HiRDB system definition to define an HA group. Specify a name for the HA group in the -g option of the pdhagroup operand, and specify in the -u option the unit identifiers of the units that will comprise the HA group.

You can specify only one HA group in each system definition.

Example: pdhagroup -g hag1 -u unt1,unt2,unt3,unt4

Defines an HA group named hag1 that consists of unt1, unt2, and unt3.

The following restrictions apply to HA groups:

A maximum of 32 units can be defined in an HA group.

All units in an HA group must be allocated in the same network segment.

The maximum total number of host BESs and guest BES areas (= maximum active guest BESs) that can be defined in a unit within an HA group is 34.

Each unit comprising an HA group must satisfy all the following conditions:

Because a unit that contains no host BES (an accepting-only unit) cannot belong to an HA group, each unit belonging to an HA group must contain at least one host BES.

All servers that comprise a unit belonging to an HA group must be back-end servers; an HA group unit cannot contain any server whose server type is other than BES.

The only type of system switchover that can be used for units belonging to an HA group is standby-less system switchover (effects distributed). This means that for units belonging to an HA group, the only value that can be specified in the pd_ha_agent operand is activeunits.

(c) Specifying an accepting unit

In the HiRDB system definition, you specify in the -g option of the pdstart command the HA group to which an accepting unit belongs.

You must specify the -g option for all servers that belong to a unit to which standby-less system switchover (effects distributed) is applicable.

Example: pdstart -t BES -s bes1A -u unt1 -g hag1

When unt1 or bes1 terminates abnormally, processing for bes1 can be accepted by a unit belonging to the HA group named hag1.

You should note the following about specifying the -g option:

Both the regular unit and the accepting unit must be comprised exclusively of back-end servers.

BES must be specified in the -t option.

Each unit belonging to the HA group specified by the -g option must not contain any server whose server type is not BES.

The number of servers comprising a regular unit need not be the same as the number of servers comprising an accepting unit.

The number of servers in the unit specified by the -u option (regular unit) need not be the same as the number of servers in the unit belonging to the HA group specified by the -g option (accepting unit).

(d) Specifying the maximum number of concurrently running guest BESs

You can specify in the pd_ha_max_act_guest_servers operand of the unit control information definition the maximum number of guest BESs that will be permitted to operate concurrently as running systems in a unit. The purpose of this specification is to reduce the amount of resources required by guest BESs. It can also prevent excessive increases in workload.

Example: pd_ha_max_act_guest_servers = 2

The maximum value that can be specified in the pd_ha_max_act_guest_servers operand is the number obtained by subtracting the number of servers in the local unit from the number of servers in the HA group. If you specify a value greater than this maximum, the maximum value will be set in the pd_ha_max_act_guest_servers operand. The number of host BESs plus the value of the pd_ha_max_act_guest_servers operand cannot exceed 34.

The number of guest BESs that are in accepting status in a unit is not restricted. However, when the number of guest BESs that are operating as running systems in a unit reaches the value specified in the pd_ha_max_act_guest_servers operand, acceptability is cancelled for all the non-active guest BESs.

Once the number of erroneous BESs in an HA group exceeds the combined total number of free guest areas in the running units in the HA group, any subsequent error will cause some servers to stop and their processing will be suspended.

(6) Allocating server processes following system switchover

(a) Standby-less system switchover (1:1)

Once standby-less system switchover (1:1) occurs, the alternate BES unit both executes its own processes and assumes the alternate BES's processes. For this to occur, server processes are allocated to the alternate BES's original processes as well as to the normal BES's processes. The number of server processes executing the alternate BES's original processes and assuming the normal BES's processes varies according to need. However, the maximum number of active alternate BES processes (value of the pd_max_bes_process operand) is also the maximum for the combined total of the number of processes for both BESs. This prevents an excessive increase in workload at the alternate BES after system switchover. On the other hand, however, you need to be aware that the maximum number of service requests that can be processed concurrently after system switchover is limited to one half of the original. For this reason, when you specify the pd_max_bes_process operand for the alternate BES, you should take into consideration both the increase in the unit's workload and the number of service requests that can be processed concurrently.

If a safety margin has been built into the number of resident processes before system switchover (value of the pd_process_count operand), and if processes that are not actually processing service requests are resident, you have these resident processes that are not processing service requests available to assume the normal BES's processing after system switchover. As a result, processing performance after system switchover improves.

Figure 25-36 shows allocation of server processes following standby-less system switchover (1:1) (Part 1).

Figure 25-36 Allocation of server processes following standby-less system switchover (1:1) (Part 1)

Before system switchover occurs, the maximum number of processes that can be processed concurrently equals the value of the pd_max_bes_process operand specified for the alternate BES (bes1). Additionally, as many server processes as the value of the pd_process_count operand for the alternate BES (bes1) can be kept resident.

When system switchover occurs, processing for the normal BES (bes2) begins using available resident processes of the alternate BES (bes1). Therefore, there is no need to start processes for the normal BES (bes2) and the processing of the normal BES (bes2) resumes immediately following system switchover. Moreover, there is no need to start standby processes for the normal BES (bes2) before system switchover.

Once all resident processes are being used, additional processes are started as needed. However, the total number of processes is limited to the value of the pd_max_bes_process operand for the alternate BES (bes1).

Figure 25-37 shows allocation of server processes following standby-less system switchover (1:1) (Part 2).

Figure 25-37 Allocation of server processes following standby-less system switchover (1:1) (Part 2)

After system switchover, while the alternate BES (bes1) is handling the processes of the normal BES (bes2), processes that are started as needed within the value of the pd_max_bes_process operand of the alternate BES are allocated to handle the processes of the alternate BES (bes1) as well as of the normal BES (bes2).

Where there are processing requests only for the alternate BES (bes1), the number of processes up to the value of the pd_max_bes_process operand for the alternate BES (bes1) can be executed concurrently for the alternate BES (bes1).

Where there are processing requests only for the normal BES (bes2), the number of processes up to the value of the pd_max_bes_process operand for the alternate BES (bes1) can be executed concurrently for the alternate BES (bes2).

(b) Standby-less system switchover (effects distributed) facility

Even though standby-less system switchover (effects distributed) has occurred, an accepting unit can continue to accept guest servers until the number of running guest servers reaches the value of the pd_ha_max_act_guest_servers operand.

At an accepting unit, the host BESs and guest BESs individually start server processes up to the maximum number of processes that can be started (value of the pd_max_bes_process operand). However, the total number of server processes in a unit is limited to the value of the pd_ha_max_server_process operand. This prevents an excessive increase in workload at the accepting unit. However, you should be aware that there may be an upper limit to the number of service requests that can be processed concurrently after system switchover. For this reason, when you specify the pd_ha_max_server_process operand, you should take into consideration both the increase in the unit's workload following system switchover and the number of service requests that can be processed concurrently.

If a safety margin has been built into the number of resident processes before system switchover (value of the pd_process_count operand) and if processes that are not actually processing service requests are resident, you have these resident processes that are not processing service requests available to assume the normal BES's processing after system switchover. As a result, processing performance after system switchover improves. On the other hand, when the number of resident processes is set too large, processes that are not processing service requests may cause the number of processes to reach the value of the pd_ha_max_server_process operand. As a result, it may not be possible to process additional service requests even though the number of processes that have been started by other servers has not reached the value of the pd_max_bes_process operand. It is advisable to set the ratio between the total number of resident processes in units and the total of the maximum number of running processes to remain the same before and after guest servers are accepted. In this way, the total number of resident processes in units after guest servers are accepted is restricted by the pd_ha_process_count operand. The actual number of resident processes is either the number obtained by allocating proportionally the value of the pd_ha_process_count operand based on the values of the pd_process_count operands of the servers that are running in the unit, or the actual value of the pd_process_count operand, whichever is smaller.

The meanings of the operands related to number of processes are explained below:

pd_ha_max_act_guest_servers: Number of guest BESs that can be accepted (maximum number in accepting status)

pd_ha_max_server_process: Maximum number of running processes, for both guest BESs and host BESs

pd_ha_process_count: Maximum number of resident processes, for both guest BESs and host BESs

Figure 25-38 shows allocation of server processes following standby-less system switchover (effects distributed) (Part 1)

Figure 25-38 Allocation of server processes following standby-less system switchover (effects distributed) (Part 1)

Before system switchover occurs, each host BES (bes1 and bes2) can execute concurrently as many processes as the value of its pd_max_bes_process operand. For each, as many server processes as the value of its pd_process_count operand can also be made resident.

When system switchover occurs, resident processes in the host BESs (bes1 and bes2) are used to provide processes for the guest BES (bes3). Therefore, there is no need to start processes for the guest BES (bes3) and processing of the guest BES (bes3) can begin immediately following system switchover. Moreover, there is no need to start standby processes for the guest BES (bes3) before system switchover.

Each server starts processes as needed up to the value of its pd_max_bes_process operand, but the combined total number of server processes in the unit is limited by the value of the pd_ha_max_server_process operand.

Also, the number of resident processes in each server is adjusted so that the combined total number of resident processes in the units equals the value of the pd_ha_process_count operand. The value of the pd_ha_process_count operand is allocated among the servers so that the number of resident processes for each server after adjustment maintains the ratio determined by each server's pd_process_count operand value.

Figure 25-39 shows allocation of server processes following standby-less system switchover (effects distributed) (Part 2).

Figure 25-39 Allocation of server processes following standby-less system switchover (effects distributed) (Part 2)

After system switchover and once the guest BES (bes3) has been accepted, the processes of the host BESs (bes1 and bes2) and the processes of the guest BES (bes3) are started, as long as the number of processes in the unit does not exceed the value of the pd_ha_max_server_process operand.

If the number of processing requests to a particular host BES (bes1, for example) is especially large, processes can be executed concurrently up to the value of the pd_max_bes_process operand of that host BES (bes1). However, the number of processing requests that can be handled by other servers (bes3, for example) decreases accordingly.

25.5.4 Client environment definition specification

Pay attention to the following notes about specifying a client environment definition when using the standby system switchover facility.

Organization of this subsection

(1) HiRDB/Single Server

(2) HiRDB/Parallel Server

(1) HiRDB/Single Server

When inheriting IP addresses after a system switchover, specify the host name of the primary system only in the PDHOST operand of the client environment definition. When not inheriting IP addresses, specify the host names of the primary system and the secondary system.

(2) HiRDB/Parallel Server

When a unit in the system manager inherits IP addresses after system switchover, specify the host name of the primary system only (host name of the system manager) in the PDHOST operand of the client environment definition. When not inheriting IP addresses after system switchover, specify the host names of the primary system and the secondary system.

When a unit in the front-end server inherits IP addresses after system switchover, specify the host name of the primary system only (host name in the front-end server) in the PDFESHOST operand. When the unit does not inherit IP addresses after system switchover, specify the host names of the primary system and the secondary system. For details about the PDHOST and PDFESHOST operands, see the manual HiRDB Version 8 UAP Development Guide.

25.5.5 Specification examples of host names in HiRDB system definitions and client environment definitions

Examples of specifying host names when using the standby system switchover facility are explained below.

Organization of this subsection

(1) When inheriting IP addresses

(2) When not inheriting IP addresses

(1) When inheriting IP addresses

Examples of specifying the HiRDB system definition and client environment definition (host names) are shown below.

System common definition

pdunit -x pkghost -u UNT1 -d /hirdb_x             1

Unit control information definition

set pd_hostname = mainhost                        2

Client environment definition

export PDHOST = pkghost                           3

Explanation

Specify the host name* of a re-allocatable IP address in the -x option of the pdunit operand.

Specify the host name of the primary system in the pd_hostname operand.

Specify the host name* of a re-allocatable IP address (the host name of the system manager for a HiRDB/Parallel Server) in the PDHOST operand of the client environment definition.
In the case of multiple front-end servers, specify the host names* of re-allocatable IP addresses (host names of front-end servers) in the PDFESHOST operand.

* In the case of VERITAS Cluster Server or ClusterPerfect, the host name of a logical IP address (the host name of the IP address set in the IP type resource) is specified. In the case of SunCluster, the logical host name registered in SunCluster is specified.

(2) When not inheriting IP addresses

Examples of specifying the HiRDB system definition and client environment definition (host names) are shown below.

System common definition

pdunit -x mainhost -u UNT1 -d /hirdb/pddir_s -c reservedhost      1

Unit control information definition

set pd_hostname = mainhost                                        2

Client environment definition

export PDHOST = mainhost,reservedhost                             3

Explanation

Specify the host name of the primary system in the -x option of the pdunit operand. Specify the host name of the secondary system in the -c option.

Specify the host name of the primary system in the pd_hostname operand.

Specify the host name of the primary system and the secondary system (host name of the system manager for a HiRDB/Parallel Server) in the PDHOST operand of the client environment definition.
In the case of multiple front-end servers, specify the host names of the primary system and secondary system (host names of front-end servers) in the PDFESHOST operand.

25.5.6 RDAREA creation

Define RDAREAs in HiRDB file system areas for RDAREAs. Figures 25-40 and 25-41 show definition examples of creating user RDAREAs and system RDAREAs in different HiRDB file system areas on shared disks. Each system configuration is described following the figure. When you use the standby-less system switchover (effects distributed) facility, you define RDAREAs in HiRDB file system areas created on a different shared disk for each server.

Figure 25-40 HiRDB/Single Server system configuration example

Example of create rdarea statement specification

create rdarea SMAST for masterdirectory                   1
 file name "/sds0111/srd01" initial 10 segments;
create rdarea SDIR for datadirectory                      2
 file name "/sds0112/srd02" initial 5 segments;
create rdarea SDIC for datadictionary                     3
 file name "/sds0113/srd03" initial 20 segments;
create rdarea SUSR01 for user used by PUBLIC              4
 file name "/sds0121/srd04" initial 500 segments;
create rdarea SUSR02 for user used by PUBLIC              5
 file name "/sds0131/srd05" initial 500 segments;

Explanation

Creates the SMAST master directory RDAREA in the HiRDB file system area on shared disk A.

Creates the SDIR data directory RDAREA in the HiRDB file system area on shared disk A.

Creates the SDIC data dictionary RDAREA in the HiRDB file system area on shared disk A.

Creates the SUSR01 user RDAREA in the HiRDB file system area on shared disk B.

Creates the SUSR02 user RDAREA in the HiRDB file system area on shared disk C.

Figure 25-41 HiRDB/Parallel Server system configuration example

Example of create rdarea statement specification

create rdarea PMAST for masterdirectory                      1
   server name DIC file name "/dic0111/prd01"
   initial 10 segments;
create rdarea PDIR for datadirectory                         2
   server name DIC file name "/dic0112/prd02"
   initial 5 segments;
create rdarea PDIC for datadictionary                        3
   server name DIC file name "/dic0113/prd03"
   initial 20 segments;
create rdarea PUSR01 for user used by PUBLIC                 4
   server name BACK01 file name "/back0121/prd04"
   initial 500 segments;
create rdarea PUSR02 for user used by PUBLIC                 5
   server name BACK02 file name "/back0231/prd05"
   initial 500 segments;

Explanation

Creates the PMAST master directory RDAREA in the HiRDB file system area on shared disk A.

Creates the PDIR data directory RDAREA in the HiRDB file system area on shared disk A.

Creates the PDIC data dictionary RDAREA in the HiRDB file system area on shared disk A.

Creates the PUSR01 user RDAREA in the HiRDB file system area on shared disk B.

Creates the PUSR02 user RDAREA in the HiRDB file system area on shared disk C.

25.5.7 Definition of global buffers (standby-less system switchover (1:1) facility only)

When you define global buffers to be used by an RDAREA in the normal BES, specifying the -c option in the pdbuffer operand allows you to also secure global buffers for use by the alternating portion when units are alternated.

If the -c and -o options of the pdbuffer operand are both omitted, the alternate BES unit cannot be started.

Organization of this subsection

(1) Global buffers for data (-r option global buffers)

(2) Global buffers for index (-i option global buffer)

(3) Global buffers for LOB (-b option global buffer)

(4) -o option global buffers

(5) Design guidelines for global buffers

(1) Global buffers for data (-r option global buffers)

The system configuration examples shown below are used to explain how to allocate global buffers for data when alternating units.

System configuration example 1

pdbuffer -a gbuf01 -r RDAREA01,RDAREA02 -n 1000 -c
pdbuffer -a gbuf02 -r RDAREA03,RDAREA04 -n 1000

Explanation

This configuration does not use global buffers with the same names in the normal BES and the alternate BES.

When the -c option is specified, gbuf01 will also be secured in the alternate BES. This global buffer is used when alternating units. However, this global buffer is not used during normal operation.

When estimating shared memory that the global buffers for the alternate BES unit will use, be sure to add enough memory for gbuf01.

The buffer hit rate will not decrease when alternating units.

System configuration example 2

pdbuffer -a gbuf01 -r RDAREA01,RDAREA02,RDAREA03,RDAREA04 -n 1000 -c

Explanation

This configuration uses global buffers with the same names in the normal BES and the alternate BES.

With the -c option specified, gbuf01 of the alternate BES will be used when alternating units.

The buffer hit rate may decrease when alternating units.

The buffer size of gbuf01 in the alternate BES will be the maximum page length of the RDAREAs in the normal BES and alternate BES.

When the -c option is omitted

When the -c option is omitted, global buffers specified by the -o option are used when alternating units.

(2) Global buffers for index (-i option global buffer)

The system configuration examples shown below are used to explain how to allocate global buffers for index when alternating units.

System configuration example

pdbuffer -a gbuf01 -i USER01.INDX01 -n 1000 -c

Explanation

When the -c option is specified for a global buffer that uses row nonpartitioned index INDX01, gbuf01 will also be secured in the alternate BES. This global buffer is used when alternating units. However, this global buffer is not used during normal operation.

When estimating shared memory that the global buffers for the alternate BES unit will use, be sure to add enough memory for gbuf01.

System configuration example

pdbuffer -a gbuf02 -i USER01.INDX02 -n 1000 -c

Explanation

When the -c option is specified for a global buffer that uses row partitioned index INDX02, gbuf02 will also be secured in the alternate BES. This global buffer is used when alternating units, so no access conflict with INDX02 occurs on BES2. However, this global buffer is not used during normal operation.

When estimating shared memory that the global buffers for the alternate BES unit will use, be sure to have twice the size of gbuf02 available.

When the -c option is omitted

When the -c option is omitted, global buffers are used when alternating units according to the priorities explained below.

Allocate a global buffer to the index RDAREA. If the -c option is specified for the global buffer, allocate the global buffer using the procedure explained in (1).

The global buffer specified by the -o option is used.

(3) Global buffers for LOB (-b option global buffer)

The procedure for allocating global buffers for LOB when alternating units is the same as the procedure for allocating global buffers for data. However, if the -c option is omitted, data will be written to or read from the RDAREA directly without using a global buffer.

(4) -o option global buffers

An -o option global buffer in the alternate BES also uses the RDAREA in the normal BES when alternating units. The buffer size of the global buffer is the maximum page length of the RDAREA in the normal BES and alternate BES.

(5) Design guidelines for global buffers

Basically, specify the -c option for global buffers used by RDAREAs, indexes, and LOB RDAREAs in normal BES units.

When the -c option is specified, the global buffer used when an alternating unit is created in the alternate BES. Therefore, be sure there is enough extra shared memory for use by the global buffer in the alternate BES unit. If there is not enough extra shared memory, do not specify the -c option.

When using a global buffer for the alternate BES also in the RDAREA in the normal BES, the buffer size of this global buffer is the maximum page length of the RDAREA in the normal BES and alternate BES. Therefore, be sure to consider the page length of the RDAREAs when specifying the -c option.

25.5.8 Definition of global buffers (standby-less system switchover (effects distributed) facility only)

When you use the standby-less system switchover (effects distributed) facility, you can allocate global buffers on a unit-by-unit basis.

To allocate a global buffer to RDAREAs or indexes located in back-end servers to which the standby-less system switchover (effects distributed) facility is applicable, specify the -c option (sharing option) in the pdbuffer operand. A global buffer allocated by specifying the -c option is called a unit-based global buffer. The unit-based global buffers have the following characteristics:

Unit-based global buffers must be allocated to all units comprising an HA group.

If the RDAREAs and indexes to which the same unit-based global buffer is to be allocated are located in multiple back-end servers, its global buffer resources are divided and used equitably among the multiple back-end servers. If these resources are located in a single back-end server, they are used exclusively by that back-end server. If a global buffer defined with the -o option specified is allocated to RDAREAs located in multiple back-end servers, the global buffer's resources are also divided and used equitably among the multiple back-end servers. Figure 25-42 shows an example in which a unit-based global buffer is shared. In this figure, the same unit-based global buffer is allocated to servers in different units.

Figure 25-42 Sharing of a unit-based global buffer

pdbuffer -a bp01 -a bp01 -r RD11,RD12 -n 60 -c

Organization of this subsection

(1) Design concepts for a unit-based global buffer

(2) Allocating global buffers for RDAREAs and LOB global buffers (-r or -b option specified)

(3) Allocating a global buffer to an index (-i option specified)

(4) Allocating a global buffer for OTHER (-o option specified)

(5) Allocating a global buffer during a configuration change (database reorganization utility)

(1) Design concepts for a unit-based global buffer

First, select whether or not the global buffer is to be shared. You can design a global buffer for reduced operation after system switchover occurs based on either of the following concepts:

Sharing design
During reduced operation, memory is used efficiently by means of sharing the accepting unit's global buffer. This is called a sharing design; it has the following characteristics:

Advantage: Because the accepting unit's global buffer is shared during reduced operation, memory usage efficiency is high.

Disadvantage: During reduced operation, the buffer hit rate is reduced proportionately to the number of servers that share the global buffer.

Non-sharing design
Global buffer resources to be used only during reduced operation are allocated to each accepting unit and go into service when system switchover occurs. This is called a non-sharing design. It has the following characteristics:

Advantage: Because the same amount of buffer resources is available for use before and during reduced operation, the hit rate can be maintained.

Disadvantage: Because global buffer resources to be used only during reduced operation are allocated to an accepting unit, memory usage efficiency is low.

Because the objective of the standby-less system switchover (effects distributed) facility is to share resources and distribute the workload, it is more advantageous to use the sharing design (1 above); the reason for this is that memory is used more efficiently.

In the case of non-sharing design, global buffers dedicated to servers are allocated to all accepting units. Therefore, for an entire HA group, you can estimate the required amount of shared memory for global buffers by multiplying the estimated amount of shared memory for normal global buffers by the number of units comprising the HA group. If the amount of shared memory available satisfies the estimate, performance can be maintained even during reduced operation, enabling you to use non-sharing design (2 above).

(a) Procedure for sharing design

This section explains how to create a sharing design in which a global buffer is shared.

Determining the RDAREAs that share the same buffer pool

Sharing among RDAREAs of the same type
Use the -r option of the pdbuffer operand to specify RDAREAs of the same type, such as RDAREAs for data, index RDAREAs, or LOB RDAREAs, so that they cam share a global buffer. When a global buffer is shared by RDAREAs of the same size or same access frequency, memory efficiency is high.

Sharing among RDAREAs for row-partitioned tables or indexes
Use the -r option of the pdbuffer operand to specify RDAREAs for row-partitioned tables or RDAREAs for row-partitioned indexes so that they share a global buffer. If the row-partitioned tables and indexes are stored in the same RDAREA, specify the -i option of the pdbuffer operand to allocate a buffer exclusively for indexes.

Also, depending on the server and unit allocation of the RDAREAs that share a global buffer, the characteristics described below can be obtained. Use these characteristics for reference when selecting the RDAREAs that will share a global buffer.

When sharing of RDAREAs of servers located in different units occurs:
Because global buffers can be used exclusively before reduced operation occurs, allocation can be made that places more importance on performance before reduced operation occurs. However, global buffer resource allocation during reduced operation becomes unbalanced among units.

When sharing occurs between RDAREAs of servers located within the same unit with an RDAREA of a server located in a different unit:
Buffer allocation during reduced operation can be kept balanced among units.

Determining the buffer sector count of a global buffer to be shared
The number of buffer sectors specified with the -n option are divided equally and used among the sharing serves within the HA group. For this reason, you must specify a buffer sector count that is appropriate to the number of sharing servers so that a shortage will not occur. Use the following formula for estimating an appropriate buffer sector count:

number-of-sectors-needed-by-each-server (number-of-host-BESs + number-of-BESs-that-can-be-accepted)

If there is an RDAREA that requires the same level of performance before and during reduced operation, allocate to that RDAREA alone a server-specific global buffer; for details, see (b) Procedure for non-sharing design.

(b) Procedure for non-sharing design

This section explains how to create a non-sharing design that does not share global buffers.

You can allocate a server-specific global buffer either for a single RDAREA or for multiple RDAREAs belonging to the same server.

Allocating exclusively to a single RDAREA
Specify the RDAREA in the -r option of the pdbuffer operand. Because there is no competition from other RDAREAs, a global buffer can be allocated to maximize performance. You can also allocate an index-specific buffer by specifying a non-partitioning index in the -i option of the pdbuffer operand.

Allocating to multiple RDAREAs belonging to the same server
Specify in the -r option of the pdbuffer operand multiple RDAREAs belonging to the same server. Specify RDAREAs of the same type, such as RDAREAs for data, index RDAREAs, or LOB RDAREAs.

(2) Allocating global buffers for RDAREAs and LOB global buffers (-r or -b option specified)

Allocation of global buffers for RDAREAs and LOB global buffers on a unit-by-unit basis can be classified into four types depending on the combination of the specified RDAREAs. Table 25-15 shows the recommended conditions for global buffer sharing modes (specification of the -r or -b option).

Table 25-15 Recommended conditions for global buffer sharing modes (-r or -b option specified)

Specification method (combination of RDAREAs specified with -r or -b)
Buffer sharing mode
Benefit
Recommended condition

RDAREAs in different servers
RDAREAs in the same unit
RDAREAs in different units

None
None
None
Non-shared
Because global buffers are not shared with other servers, normal buffer performance can be maintained even when multiple errors occur.
Because buffers are allocated to all accepting units, this mode is recommended for RDAREAs for which buffer performance should be maintained before and during reduced operation in an environment with ample memory capacity.

Yes
Yes
None
Sharing by servers within a unit
Normal buffer performance can be maintained even when multiple errors occur.
As with the non-shared mode, this mode can maintain buffer performance before and during reduced operation. However, because memory usage efficiency is low when switching first occurs, the non-shared mode is recommended.

Yes
None
Yes
Sharing by servers in different units

Back-end servers of the primary system can use all of the specified buffer sectors.

During reduced operation, the accepting unit's resources are shared, resulting in high memory efficiency.

This mode is recommended when performance during normal operation is important and buffer resources should be shared during reduced operation.

Yes
Yes
Yes
Sharing by servers within a unit and in different units

During reduced operation, the accepting unit's resources are shared, resulting in high memory usage efficiency.

Because the number of sharing servers can be balanced, workload during reduced operation can be balanced.

This mode is recommended when buffer resources should be shared and the workload should be balanced during reduced operation.

Select the appropriate sharing mode by considering the buffer design guidelines for the -r or -b specification explained below. Because the objective of the standby-less system switchover (effects distributed) facility is to share resources and distribute the workload, it is preferable to use Sharing by servers in different units or Sharing by servers within a unit and in different units, both of which involve sharing between units. If it is important to maintain performance even during reduced operation, select Non-shared or Sharing by servers within a unit.

Buffer design guideline for -r or -b specification

For an RDAREA for which the buffer hit rate should be maintained even during reduced operation in an environment with ample memory: Select Non-shared or Sharing by servers within a unit.

To have a particular server use the buffer resources exclusively during normal operation and allow sharing with other servers during reduced operation: Select Sharing by servers in different units.

Cases other than 1 or 2: Select Sharing by servers within a unit and in different units.

(a) Allocating non-shared global buffers

Specify only RDAREAs belonging to a single back-end server in the -r or -b option of each pdbuffer operand. A system configuration example follows:

System configuration example

Global buffer definitions

pdbuffer -a gbuf01 -r RDAREA11,RDAREA12 -n 2000 -c
pdbuffer -a gbuf02 -r RDAREA21 -n 1000 -c
pdbuffer -a gbuf03 -r RDAREA31 -n 1000 -c

Explanation

Only RDAREAs belonging to a single back-end server are specified in the -r or -b option of each pdbuffer operand.

Non-shared buffers gbuf01, gbuf02, and gbuf03 are allocated to BES11, BES21, and BES31, respectively.

Even after system switchover, gbuf01 is used exclusively by BES11 and thus the buffer hit rate does not decline. However, because a buffer to be used after system switchover must be allocated to each accepting unit, a large amount of memory is used.

Notes

The same global buffer is created for all accepting units. This global buffer is not used until system switchover occurs.

To improve memory efficiency, specify RDAREAs of the same page size.

(b) Allocating global buffers to be shared by servers within a unit

Specify this option if you wish to maintain the same buffer performance even when multi-point errors occur during reduced operation in an environment with ample memory. Specify RDAREAs allocated to back-end servers within the same unit in the -r or -b option of each pdbuffer operand.

System configuration example

Global buffer definitions

pdbuffer -a gbuf01 -r RDAREA11,RDAREA12 -n 1000 -c
pdbuffer -a gbuf02 -r RDAREA21,RDAREA22 -n 1000 -c
pdbuffer -a gbuf03 -r RDAREA31,RDAREA32 -n 1000 -c

Explanation

RDAREAs allocated to back-end servers within the same unit are specified in the -r or -b option of each pdbuffer operand.

Global buffers gbuf01, gbuf02, and gbuf03 that are to be shared by servers within each unit are allocated.

Because gbuf01 is used even after system switchover, the buffer hit rate does not decline. However, because a buffer to be used after system switchover must be allocated to each accepting unit, a large amount of memory is used.

Notes

The same global buffer is created for all accepting units. This global buffer is not used until system switchover occurs.

A global buffer with this specification is shared among multiple servers.

The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified RDAREAs.

(c) Allocating global buffers to be shared by servers in multiple units

Rather than specifying RDAREAs allocated to servers within the same unit, you may specify RDAREAs allocated to servers in different units in the -r or -b option of the pdbuffer operand.

System configuration example

Global buffer definition

pdbuffer -a gbuf01 -r RDAREA11,RDAREA21,RDAREA31 -n 1000 -c

Explanation

RDAREAs allocated to servers located in different units are specified.

A global buffer is not shared exclusively among RDAREAs allocated to servers within the same unit. Instead, a global buffer can be shared by RDAREAs allocated to servers located in different units.

Before reduced operation, the resource (buffer) can be used exclusively by BES11. During reduced operation, because the resource must be shared between BES21 and BES11, the amount of the resource (buffer) that can be used by each back-end server is halved.

Notes

Because the switching destination is a single unit, the workload on the global buffer of that unit alone becomes high. Therefore, define multiple buffers to be shared by servers at multiple units so that the workload among individual units is balanced.

The same global buffer is created for all accepting units.

A global buffer with this specification is used exclusively by a single server during normal operation and is shared among multiple servers during reduced operation.

The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified RDAREAs.

(d) Allocating global buffers to be shared by servers within a unit and in different units

You can specify RDAREAs to be shared by servers within a unit and in different units in the -r or -b option of the pdbuffer operand.

System configuration example

Global buffer definition

pdbuffer -a gbuf01 -r RDAREA11,RDAREA12,RDAREA21,RDAREA22,RDAREA31,RDAREA32 -n 1000 -c

Explanation

The RDAREAs to be shared by servers within the unit and in different units are specified in the -r or -b option of the pdbuffer operand.

Because the global buffer is shared among RDAREAs that are shared by servers in different units, this method of buffer allocation results in a balanced workload during reduced operation. During normal operation, the back-end servers in each unit share that unit's gbuf01, and the amount of each buffer's resources allocated to each back-end server is one half of the total. During reduced operation, the three back-end servers share gbuf01, so the amount of buffer resources allocated to the back-end servers in each unit is one-third of the total.

Notes

Design the configuration so that the number of servers to be supported during reduced operation is equalized among the individual accepting units.

The same global buffer is created for all accepting units.

A global buffer with this specification is shared by multiple servers.

The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified RDAREAs.

(3) Allocating a global buffer to an index (-i option specified)

To buffer the index pages of a particular index, allocate a global buffer for the index. If an index RDAREA contains only an index, you can also achieve the same effect by allocating a global buffer for an RDAREA (-r option specified) to that RDAREA. Allocation of global buffers to indexes on a unit-by-unit basis can be classified into four types depending on the allocation of the index RDAREA for the specified index. Table 25-16 shows the recommended conditions for global buffer sharing modes (specification of the -i option).

Table 25-16 Recommended conditions for global buffer sharing modes (-i option specified)

Specification method (index RDAREA specified by the -i option)
Index partitioning mode
Buffer sharing mode
Benefit
Recom- mended condition

RDAREAs in different servers
RDAREAs in the same unit
RDAREAs in different units

None
None
None
Non- partitioning and partitioning within the same server
Non-shared
Because global buffers are not shared with other servers, normal buffer performance can be maintained even when multiple errors occur.
Because buffers are allocated to all accepting units, this mode is recommended for indexes for which buffer performance should be maintained before and during reduced operation in an environment with ample memory capacity.

Yes
Yes
None
Partitioning within the same unit
Sharing by servers within a unit
Normal buffer performance can be maintained even when multiple errors occur.
Because buffers are allocated to all accepting units, this mode is recommended for indexes for which buffer performance should be maintained before and during reduced operation in an environment with ample memory capacity.

Yes
None
Yes
Partitioning between units but not within each unit
Sharing by servers in different units

Back-end servers of the primary system can use all the specified buffer sectors.

During reduced operation, the accepting unit's resources are shared, resulting in high memory efficiency.

This mode is recommended when performance during normal operation is important and the buffer resources should be shared during reduced operation.

Yes
Yes
Yes
Partitioning between units and within each unit
Sharing by servers within a unit and in different units

During reduced operation, the accepting unit's resources are shared, resulting in high memory efficiency.

Because the number of sharing servers can be balanced, workload during reduced operation can be balanced.

This mode is recommended when the buffer resources should be shared and the workload should be balanced during reduced operation.

You should determine whether or not to allocate buffers dedicated to indexes by considering the buffer design guidelines for the -i specification explained below.

Buffer design guidelines for -i option specification

For a non-partitioning index, partitioning index within the same server, or partitioning index within the same unit: Define a dedicated buffer if each unit within the HA group has sufficient memory capacity to allocate a global buffer.

Cases other than 1: Define a global buffer for index. Allocate a number of buffer sectors that is appropriate for the sharing servers.

(a) Allocating a global buffer to a non-partitioning index

Specify a non-partitioning index in the -i option of the pdbuffer operand.

System configuration example

Global buffer definition

pdbuffer -a gbuf01 -i USER01.INDEX01 -n 200 -c

Explanation

Non-partitioning index USER01.INDEX01 is specified.

This example allocates a shared global buffer to a non-partitioning index. The global buffer is used exclusively and is not shared with other servers. Even after system switchover, gbuf01 is used exclusively by BES11 and thus the buffer hit rate does not decline. However, because a buffer to be used after system switchover must be allocated to each accepting unit, a large amount of memory is used.

Note

The same global buffer is created for all accepting units. This global buffer is not used until system switchover occurs.

(b) Allocating a global buffer to a partitioning index within the same server

Specify an index that is partitioned within the same server in the -i option of the pdbuffer operand.

System configuration example

Global buffer definition

pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c

Explanation

USER01.INDEX01, an index with row partitioning within a server, is specified.

This example allocates a shared global buffer to an index partitioned within the same server. The global buffer is used exclusively and is not shared with other servers. Even after system switchover, gbuf01 is used exclusively by BES11 and thus the buffer hit rate does not decline. However, because a buffer to be used after system switchover must be allocated to each accepting unit, a large amount of memory is used.

Notes

The same global buffer is created for all accepting units. This global buffer is not used until system switchover occurs.

To improve memory efficiency, specify index RDAREAs of the same page size.

(c) Allocating a global buffer to a partitioning index within the same unit

Specify an index that is partitioned within the same unit in the -i option of the pdbuffer operand.

System configuration example

Global buffer definition

pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c

Explanation

This example allocates a shared global buffer to an index partitioned within the same unit. Even after system switchover, gbuf01 is used and thus the buffer hit rate does not decline. However, because a global buffer to be used after system switchover must be allocated to each accepting unit, a large amount of memory is used.

Notes

The same global buffer is created for all accepting units. This global buffer is not used until system switchover occurs.

A global buffer with this specification is shared by multiple servers.

To improve memory efficiency, specify index RDAREAs of the same page size.

The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified index RDAREAs.

(d) Allocating a global buffer to an index partitioned between units but not within each unit

Specify an index that is partitioned between units but not within each unit in the -i option of the pdbuffer operand.

System configuration example

Global buffer definition

pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c

Explanation

USER01.INDEX01, an index that is row partitioning between different units, is specified.

This example allocates a global buffer to an index partitioned between units but not within each unit. Before reduced operation, the gbuf01 resource (buffer) is used exclusively by BES11. During reduced operation, because the resource is shared between BES21 and BES11, the amount of the resource (buffer) that can be used by each back-end server is halved.

Notes

Because the switching destination is a single unit, the workload on the global buffer of that unit alone becomes high. Therefore, you should define multiple buffers to be shared by servers at multiple units so that the workload among individual units is balanced.

The same global buffer is created for all accepting units.

A global buffer with this specification is used exclusively by a single server during normal operation and is shared among multiple servers during reduced operation.

To improve memory efficiency, specify index RDAREAs of the same page size.

The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified index RDAREAs.

(e) Allocating a global buffer to an index partitioned between units and within each unit

Specify an index that is partitioned between units and within each unit in the -i option of the pdbuffer operand.

System configuration example

Global buffer definition

pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c

Explanation

USER01.INDEX01, an index with row partitioning within each unit and between servers, is specified.

This example allocates a shared global buffer to an index partitioned between units and within each unit. During normal operation, back-end servers in the units share each gbuf01, and the amount of the buffer resources allocated to each back-end server is one half of the total. During reduced operation, the three back-end servers share gbuf01, so the amount of the buffer resources allocated to the back-end servers in each unit is one-third of the total.

Notes

Design the configuration so that the number of servers to be supported during reduced operation is equalized among the individual accepting units.

The same global buffer is created for all accepting units.

A global buffer with this specification is shared by multiple servers.

To improve memory efficiency, specify index RDAREAs of the same page size.

The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified index RDAREAs.

(4) Allocating a global buffer for OTHER (-o option specified)

One global buffer for OTHER can be allocated to all units to which the standby-less system switchover (effects distributed) facility is applied. The allocation method is explained below:

Within a system, you can define only one buffer for OTHER with the -c option of the pdbuffer operand. If you use the -c option to define multiple buffers for OTHER, the first one defined in the system common definition is valid.

Out of the RDAREAs allocated to the host BESs and guest BESs that run in the units to which the standby-less system switchover (effects distributed) facility is applied, the buffer for OTHER is allocated to those RDAREAs to which no global buffer has been allocated with the -r option.

When a buffer size is omitted in the -l option of the pdbuffer operand, if there are RDAREAs to which no global buffer has been allocated with the -c or -r option within the same HA group, the maximum page size of these RDAREAs is used as the buffer size for the buffer for OTHER. If global buffers have been allocated to all RDAREAs within the HA group with the -c or -r option specified, the maximum page size of the specified RDAREAs in the HA group is used.

You can simultaneously define a global buffer for OTHER with the -c option of the pdbuffer operand specified and another without the -c option specified. Table 25-17 shows the relationship between global buffers for OTHER that are specified in duplicate.

Table 25-17 Relationship between global buffers for OTHER that are specified in duplicate

Definition of a global buffer for OTHER with -c option specified | Definition of a global buffer for OTHER without -c option specified | Units to which the standby-less system switchover (effects distributed) facility is applied | Units to which the standby-less system switchover (effects distributed) facility is not applied
Yes | Yes | Allocates the buffer defined with the -c option specified. | Allocates the buffer defined without the -c option specified.
Yes | No | Allocates the buffer defined with the -c option specified. | Allocates the buffer defined with the -c option specified.
No | Yes | Does not allocate a buffer for OTHER. | Allocates the buffer defined without the -c option specified.
No | No | Does not allocate a buffer for OTHER. | Does not allocate a buffer for OTHER.

(a) Recommended conditions for a global buffer for OTHER

System in which RDAREAs are added on an online basis

RDAREAs with a low access frequency

RDAREAs with a small number of accessed pages

RDAREAs storing an extremely large number of pages (RDAREAs for which buffer hits are not expected)

(b) Notes about a global buffer for OTHER

The resources of a global buffer for OTHER allocated to units are divided and used equitably among these units. Therefore, specify in the -n option of the pdbuffer operand a buffer sectors count that is appropriate to the number of servers used.

In a system in which RDAREAs are added on an online basis, specify a buffer size in the -l option of the pdbuffer operand by taking into consideration the page sizes of the RDAREAs that will be added in the future.

(c) Allocation example of a global buffer for OTHER

Specify the -o option of the pdbuffer operand.

System configuration example

Global buffer definitions

pdbuffer -a gbuf01 -r RDAREA11 -n 500 -c
pdbuffer -a gbuf02 -o -n 1000 -c

Explanation

The -o and -c options of the pdbuffer operand are specified.

A dedicated buffer is allocated to RDAREA11 and a global buffer for OTHER is allocated to all other RDAREAs. The global buffer for OTHER is created for all units to which the standby-less system switchover (effects distributed) facility is applicable.

(5) Allocating a global buffer during a configuration change (database reorganization utility)

Specify the name of an existing global buffer in the globalbuffer operand of the control statement of the database reorganization utility. You can use the pdbufls command to check the existing global buffers.

System configuration example

Configuration changed definition

create rdarea RDAREA13 globalbuffer gbuf01 server name BES11
               :

Explanation

Shared global buffer gbuf01 is allocated to an added RDAREA. The added RDAREA uses gbuf01 even after system switchover.

Design guidelines

During both system switchover and system reactivation, allocate the global buffer specified with the globalbuffer operand.

You cannot allocate an index global buffer or a LOB global buffer.

The size of the global buffer to be specified must be greater than the page size of any RDAREA to be added. You can use the pdbufls command to check the global buffer size.

The global buffer allocation specified here becomes invalid when the server terminates normally (normal or planned termination of the HiRDB system, normal termination of the unit, or normal termination of a server itself). Therefore, before the server starts normally the next time, you must use the pdbuffer operand in the system common definition to allocate global buffers. However, if a global buffer with the -o option specification has been allocated, that global buffer is allocated again, and therefore there is no need to modify the system common definition.

When HiRDB fails to allocate a global buffer, no RDAREAs can be added.

25.5.9 Using audit trail files

Executor: HiRDB administrator or auditor

When using the standby system switchover facility or the standby-less system switchover (1:1) facility:

The HiRDB administrator creates audit trail files on a shared disk. The HiRDB administrator and the auditor can use the audit trail files on the shared disk.

When using the standby-less system switchover (effects distributed) facility:

The HiRDB administrator creates audit trail files on a shared disk of the regular unit. During this process, the HiRDB administrator must select a destination disk that is different from the individual servers' shared disks (disks that store individual servers' system log files, synchronization point dump files, and server status files).

At the system switchover destination, the audit trail files of the accepting unit are shared.

The HiRDB administrator and the auditor can use the audit trail files of both the regular unit and the accepting unit.

Organization of this subsection

(1) Creating audit trail files

(2) Using audit trail files

(3) Collecting audit trails

(4) Executing the pdload command

(1) Creating audit trail files

(a) When using the standby system switchover facility or standby-less system switchover (1:1) facility

The HiRDB administrator creates audit trail files on a shared disk.

(b) When using the standby-less system switchover (effects distributed) facility

The HiRDB administrator creates audit trail files on a shared disk of the regular unit. During this process, the HiRDB administrator must select a destination disk that is different from the individual servers' shared disks (disks that store individual servers' system log files, synchronization point dump files, and server status files).

If audit trail files are created on a shared disk that corresponds to individual servers, the disk's host is switched when system switchover occurs. Consequently, other running servers within the unit can no longer output audit trails. At the system switchover destination, the audit trail files of the accepting unit are shared.

(2) Using audit trail files

(a) When using the standby system switchover facility or standby-less system switchover (1:1) facility

When system switchover occurs, HiRDB records monitored events in an audit trail file on the shared disk. For details about using audit trail files related to recording of monitored events, see 22.6 Operation of audit trail files.

(b) When using the standby-less system switchover (effects distributed) facility

When system switchover occurs, HiRDB records monitored events in the audit trail file being used by the accepting unit at the switching destination. In this case, operation of audit trail files related to monitored event records is managed centrally by the accepting unit.

For a system that uses the standby-less system switchover (effects distributed) facility, audit trails must be collected at all units.

(3) Collecting audit trails

(a) When using the standby system switchover facility or standby-less system switchover (1:1) facility

When system switchover occurs, how the audit trail collection status is inherited depends on whether or not the switched unit stops. If the system at the switching destination is restarted, the status before system switchover occurred is inherited. If the system at the switching destination is started normally, the specification in the pd_audit operand is used.

(b) When using the standby-less system switchover (effects distributed) facility

When system switchover occurs, whether an audit trail is collected depends on the accepting unit's status. Table 25-18 shows whether an audit trail is collected when the standby-less system switchover (effects distributed) facility is used.

Table 25-18 Collection of audit trails when the standby-less system switchover (effects distributed) facility is used

Unit type | Unit status | Accepting unit
Collecting | Not collecting
Regular unit | Collecting | Collects | Does not collect
Not collecting | Collects | Does not collect

Figure 25-43 shows an example of audit trail collection when the standby-less system switchover (effects distributed) facility is used.

Figure 25-43 Audit trail collection example when the standby-less system switchover (effects distributed) facility is used

(4) Executing the pdload command

(a) When using the standby system switchover facility or standby-less system switchover (1:1) facility

The auditor executes the pdload command using an audit trail file as the input information. However, if a factor such as an error caused system switchover, HiRDB will not have correctly collected the audited events that occurred immediately before the system switchover. For this reason, even if the pdload command is executed, it may not be possible to collect the data that existed immediately before system switchover.

(b) When using the standby-less system switchover (effects distributed) facility

The auditor executes the pdload command using the audit trail files of the regular unit and the accepting unit as the input information. The audit trails of a server that has been switched are processed as server information belonging to the accepting unit.

When a factor such as an error caused system switchover, HiRDB will not have correctly collected the audited events that occurred immediately before the system switchover. For this reason, even if the pdload command is executed, it may not be possible to collect the data that existed immediately before system switchover.

Operation during an error: When an error occurs, load the audit log as follows:

At the running host, manually activate the disk storing the audit trail files collected before system switchover.

Using the audit trail files of the regular unit and the accepting unit as the input information, execute the pdload command.

Operation after error recovery: Load the audit log using the same method as used before the error occurred.

25.6 HA monitor preparations

You should read this section when you use HA monitor in the cluster software. This section provides guidelines for the values to be specified in operands of the following HA monitor definition statements that relate to HiRDB:

sysdef definition statement

server definition statement

Reference note

Note that the path names of the files storing the sysdef and server definition statements depend on the operating system.

When you use the standby system switchover facility or standby-less system switchover (1:1) facility, you must set up an operating environment for each unit; when you use the standby-less system switchover (effects distributed) facility, you must set up an operating environment for each server.

When using the monitor mode

When you use the monitor mode, you must set up the environment by referring to the explanation in this section.

When using the server mode

When you use the server mode, you must set up the environment by referencing the following:

Explanation in this section

Explanation in 25.12 Hitachi HA Toolkit Extension preparations (server mode only)

Organization of this section

25.6.1 sysdef definition statement

25.6.2 server definition statement

25.6.1 sysdef definition statement

Organization of this subsection

(1) servmax operand

(2) multistandby operand

(1) servmax operand

You can specify this operand when the version of HA monitor is 01-08 or later.

For the servers to be switched using HA monitor, specify 16 or 64 as the maximum number of servers that can be started concurrently as running servers or standby servers on a single server machine.

16: Sets 16 as the maximum number of servers that can be started concurrently.

64: Sets 64 as the maximum number of servers that can be started concurrently.

Specify 64 when the number of servers, which are the units for switching on a single server machine, exceeds 16.

The number of servers to be switched using HA monitor also includes products other than HiRDB that are to be switched. HiRDB computes the number of servers to be switched as follows:

Total number of running units and standby units that are operating on a single server machine and that are subject to standby system switchover

Total number of normal BES units and alternate BES units that are running on a single server machine and that are subject to standby-less system switchover (1:1)

Total number of host BESs and guest BESs that are running on a single server machine and that are subject to standby-less system switchover (effects distributed)

(2) multistandby operand

You can specify this operand when the version of HA monitor is 01-08 or later.

This operand specifies whether the multi-standby function, which defines multiple standby systems for a single running system, is to be used:

use: Use the multi-standby function

nouse: Do not use the multi-standby function

Table 25-19 provides specification guidelines for the multistandby operand.

Table 25-19 Specification guidelines for the multistandby operand

Environment of system switchover facility | multistandby operand specification
Standby system switchover facility | When IP addresses are not inherited. | Can be omitted.
When IP addresses are inherited. | Specify use if multiple standby systems are defined.
Standby-less system switchover facility | Standby-less system switchover (1:1) facility | Can be omitted.
Standby-less system switchover (effects distributed) facility | Specify use if the number of units belonging to the HA group is 3 or more.

Note

When use is specified, you must use the standbypri operand of the servers definition statement to specify priorities for the standby systems.

25.6.2 server definition statement

Organization of this subsection

(1) acttype operand

(2) switchtype operand (applicable to the server mode only)

(3) name operand

(4) termcommand operand (applicable to the monitor mode only)

(5) alias operand

(6) disk operand

(7) lan_updown operand

(8) group operand

(9) initial operand

(10) standbypri operand

(11) Example of specifying the server definition statements

(1) acttype operand

To operate the system switchover facility in the server mode, specify server in this operand. To operate in the monitor mode, specify monitor in this operand.

(2) switchtype operand (applicable to the server mode only)

Consider specifying this operand when operating the system switchover facility in the server mode. You cannot specify this operand when operating in the monitor mode. Specify in this operand the processing to be performed when a server failure is detected.

switch:

When HiRDB (or unit for a HiRDB/Parallel Server) terminates abnormally, system switchover is to be performed and HiRDB is to restart on the switchover destination system.

For the standby-less system switchover (1:1) facility, it is recommended that you specify switch in the server definition statement for the alternate portion created in the alternate BES unit. When switch is specified, the system is switched from the alternate portion to the normal BES unit, if an error occurs in the alternate BES unit while alternating units; as a result, the load on the alternate BES unit can be reduced after it restarts.

For the standby-less system switchover (effects distributed) facility, it is advisable to specify switch in the server definition statement for the guest BES. When switch is specified, the guest BES switches to another unit if an error occurs in the unit in which the guest BES is running; as a result, the load on the unit can be distributed after it restarts.

restart:

HiRDB (or unit for a HiRDB/Parallel Server) is to be restarted on the system resulting in an error. Only if HiRDB cannot be restarted on the system resulting in the error is system switchover to occur and HiRDB to be restarted on the switchover destination system (system switchover is reported by output of the KFPS00715-E message).

For the standby-less system switchover (1:1) facility, it is not recommended that you not specify restart in the server definition statement for the alternate portion created in the alternate BES unit. When restart is specified, the alternate BES unit continues to assume the alternate processes of the normal BES unit when an error occurs in the alternate BES unit while alternating units; as a result, the load on the alternate BES unit is not reduced after it restarts.

For the standby-less system switchover (effects distributed) facility, it is not recommended that you specify restart in the server definition statement for the guest BES. When restart is specified, the guest BES continues processing, if an error occurs in the unit in which the guest BES is running after the unit restarts; as a result, the load on the unit cannot be distributed after it restarts.

manual:

The systems are not to be switched automatically even if HiRDB (or unit for a HiRDB/Parallel Server) cannot be restarted.

Hint

When you use the standby-less system switchover (1:1) facility with a mutual alternating configuration, specify the same value in the switchtype operand of the alternate BES unit and the alternate portion.

When you use the standby-less system switchover (effects distributed) facility, specify the same value in the switchtype operand of all servers in the HA group.

(3) name operand

Server mode

In the case of the standby system switchover facility, specify the HiRDB directory name using an absolute path name. In the case of a HiRDB/Parallel Server, specify the HiRDB directory name of the applicable unit using an absolute path name.

In the case of the standby-less system switchover (1:1) facility, specify a HiRDB identifier (value specified in the pd_system_id operand) and unit identifier (value specified in the pd_unit_id operand) of a normal BES unit, separated by a slash (/). Specify as shown below if the HiRDB identifier is DB01 and the unit identifier of the normal BES unit is UNT1:
"DB01/UNT1"

In the case of the standby-less system switchover (effects distributed) facility, specify a HiRDB identifier and server identifier, separated by a slash (/). Specify as shown below if the HiRDB identifier is DB01 and the server identifier is BES1:
"DB01/BES1"

Monitor mode

Specify a command (shell) for starting HiRDB (or unit for a HiRDB/Parallel Server) using an absolute path name. If the environment variables inherited from HA monitor are not appropriate for use by the HiRDB start command, HiRDB will not function properly. Use a user command (shell) to change the execution environment, then issue the following commands:

$PDDIR/bin/pdstart (for a HiRDB/Single Server)

$PDDIR/bin/pdstart -q* (for a HiRDB/Parallel Server)

* This command starts a unit in the HiRDB/Parallel Server when using the system switchover facility.

The following example shows how to create a user command (shell) when using a HiRDB/Single Server.

Example:

PDDIR=/HiRDB_S
PATH=/bin:/usr/bin:/usr/bin/ucb:/$PDDIR/bin
PDCONFPATH=$PDDIR/conf
SHLIB_PATH=$PDDIR/lib
export PATH PDDIR PDCONFPATH SHLIB_PATH
$PDDIR/bin/pdstart

(4) termcommand operand (applicable to the monitor mode only)

Consider specifying this operand when operating the system switchover facility in the monitor mode. You cannot specify this operand when operating in the server mode. In the following cases, specify a command (shell) for terminating HiRDB (or unit for a HiRDB/Parallel Server) using an absolute path name:

When performing grouped system switchover

When terminating* HiRDB by issuing only the monend command of HA monitor or performing a planned system switchover of HiRDB by issuing only the monswap command

* This applies when forcible termination is used. For normal termination, use the pdstop command to terminate HiRDB and then execute the monend command.

If the environment variables inherited from HA monitor are not appropriate for use by the HiRDB termination command, HiRDB will not function properly. Use a user command (shell) to change the execution environment, then issue the following commands:

$PDDIR/bin/pdstop or $PDDIR/bin/pdstop -f -q: For a HiRDB/Single Server

$PDDIR/bin/pdstop -z -q: For a HiRDB/Parallel Server

When this command is executed, RDAREAs on a shared disk may go into error shutdown. If this occurs, recover the RDAREAs on the shared disk by executing the database recovery utility (pdcopy command).

The following example shows how to create a user command (shell) when using a HiRDB/Single Server:

Example:

PDDIR=/HiRDB_S
PATH=/bin:/usr/bin:/usr/ucb:/$PDDIR/bin
PDCONFPATH=$PDDIR/conf
SHLIB_PATH=$PDDIR/lib
export PATH PDDIR PDCONFPATH SHLIB_PATH
$PDDIR/bin/pdstop

Reference note

If this operand is specified and HA monitor's monswap command is entered during HiRDB termination processing, the pdstop command results in an error (pdstop was entered while HiRDB was stopping). No error message is output at this time, but this is an actual error.

Even if you define a command (in the pd_ha_restart_failure operand) that is to execute when restart fails, the pdstop command results in an error similar to the above case.

(5) alias operand

Specify an identifying name that is unique within the system to which HA monitor is applied. You must specify the same identifying name in the primary and secondary systems.

For the standby-less system switchover facility, it is recommended that the unit identifier be specified. For the standby-less system switchover (1:1) facility, it is recommended that the unit identifier of the normal BES unit be specified. For the standby-less system switchover (effects distributed) facility, it is recommended that the server identifier of the server subject to system switchover be specified.

(6) disk operand

Specify the name of the disk area (volume group and partition) in which a HiRDB file system area was created.

(7) lan_updown operand

When inheriting IP addresses:

To turn the power to the network on or off, you can specify the IP address to be inherited in the .up file or the server identifier's .down file as the alias operand value. To do this, you must also specify use in the lan_updown operand.

When not inheriting IP addresses:

Before starting the running system and standby system HiRDB (or unit), you can activate the IP addresses specified in the -x and -c options of the pdunit operand. Do not specify an IP address specified in the -x or -c option of the pdunit operand in the alias operand value's .up or .down file for HA monitor. If IP addresses for client connection are to be inherited, specify these IP addresses. If there are no IP addresses to be inherited, such as IP addresses for client connection, specify nouse in the lan_updown operand of the server definition statement of HA monitor, or delete the alias operand value's .up and .down files.

Standby-less system switchover facility

For the standby-less system switchover (1:1) facility, activate the IP addresses specified in the -x and -c options of the pdunit operand before starting the normal BES unit and the alternate BES unit. For the standby-less system switchover (effects distributed) facility, activate the IP addresses specified in the -x and -c options of the pdunit operand before starting the unit with the HA group name.

Do not specify an IP address specified in the -x or -c option of the pdunit operand in the alias operand value's .up or .down file for HA monitor. If IP addresses for client connection are to be inherited, specify these IP addresses. If there are no IP addresses to be inherited, such as IP addresses for client connection, specify nouse in the lan_updown operand of the server definition statement of HA monitor, or delete the alias operand value's .up and .down files.

(8) group operand

Specify this operand in order to perform grouped system switchover. Specifying this operand is not necessary if the only server to be switched is HiRDB. You specify a server group name in this operand. The examples below provide guidelines for specifying server group names:

When performing OpenTP1 and grouped system switchover, specify the same value as the definition file that set up the environment for the specified server in Open TP1 of the same system.

When using HiRDB Datareplicator and performing grouped system switchover, specify the same value as the definition file that set up the environment for the specified server in HiRDB Datareplicator.

(9) initial operand

When you use the standby system switchover facility, specify online for the primary system and standby for the secondary system.

When you use the standby-less system switchover (1:1) facility, specify online for the normal BES unit and standby for the alternate BES unit.

When you use the standby-less system switchover (effects distributed) facility, specify online for the host BES and standby for the guest BES.

(10) standbypri operand

Specification of this operand is applicable when the version of HA monitor is 01-08 or later.

You use this operand to specify priorities when you use the multi-standby function of HA monitor (use must be specified in the multistandby operand of the sysdef definition statement).

(11) Example of specifying the server definition statements

For this example, the standby-less system switchover (effects distributed) facility is applied to the following 3-unit configuration:

Also, each of the following groups shares a global buffer:

Group A: BES1A, BES2A, and BES3A

Group B: BES1B, BES2B, and BES3B

The following table shows the priorities assigned to each unit:

Server
online
Highest priority
Second priority

BES1A
unt1
[1]
[4]
unt2
[2]
unt3
[3]

BES1B
unt3
[5]
unt2
[6]

BES2A
unt2
[7]
[10]
unt3
[8]
unt1
[9]

BES2B
unt1
[11]
unt3
[12]

BES3A
unt3
[13]
[16]
unt2
[14]
unt1
[15]

BES3B
unt1
[17]
unt2
[18]

A specification example of the server definition statements follows:

Server definition statements for server machine 1

server  name     PDB1/bes1A,
       alias    bes1A,
       patrol   10,
       disk     /dev/vg01,
       initial  online;       ....[1]
server  name     PDB1/bes1B,
       alias    bes1B,
       patrol   10,
       disk     /dev/vg02,
       initial  online;       ....[4]
server  name     PDB1/bes2A,
       alias    bes2A,
       patrol   10,
       disk     /dev/vg03,
       initial  standby,
       standbypri 2;           ...[9]
server  name     PDB1/bes2B,
       alias    bes2B,
       patrol   10,
       disk     /dev/vg04,
       initial  standby,
       standbypri 1;           ...[11]
server  name     PDB1/bes3A,
       alias    bes3A,
       patrol   10,
       disk     /dev/vg05,
       initial   standby,
       standbypri 2;           ...[15]
server  name     PDB1/bes3B,
       alias    bes3B,
       patrol   10,
       disk     /dev/vg06,
       initial  standby,
       standbypri 1;           ...[17]

Server definition statements for server machine 2

server  name     PDB1/bes1A,
       alias    bes1A,
       patrol   10,
       disk     /dev/vg01,
       initial  standby,
       standbypri 1;          ....[2]
server  name     PDB1/bes1B,
       alias    bes1B,
       patrol   10,
       disk     /dev/vg02,
       initial  standby,
       standbypri 2;           ...[6]
server  name     PDB1/bes2A,
       alias    bes2A,
       patrol   10,
       disk     /dev/vg03,
       initial  online;        ...[7]
server  name     PDB1/bes2B,
       alias    bes2B,
       patrol   10,
       disk     /dev/vg04,
       initial  online;        ...[10]
server  name     PDB1/bes3A,
       alias    bes3A,
       patrol   10,
       disk     /dev/vg05,
       initial  standby,
       standbypri 1;           ...[14]
server  name     PDB1/bes3B,
       alias    bes3B,
       patrol   10,
       disk     /dev/vg06,
       initial  standby,
       standbypri 2;           ...[18]

Server definition statements for server machine 3

server  name     PDB1/bes1A,
       alias    bes1A,
       patrol   10,
       disk     /dev/vg01,
       initial  standby,
       standbypri 2;           ...[3]
server  name     PDB1/bes1B,
       alias    bes1B,
       patrol   10,
       disk     /dev/vg02,
       initial  standby,
       standbypri 1;           ...[5]
server  name     PDB1/bes2A,
       alias    bes2A,
       patrol   10,
       disk     /dev/vg03,
       initial  standby,
       standbypri 1;           ...[8]
server  name     PDB1/bes2B,
       alias    bes2B,
       patrol   10,
       disk     /dev/vg04,
       initial  standby,
       standbypri 2;           ...[12]
server  name     PDB1/bes3A,
       alias    bes3A,
       patrol   10,
       disk     /dev/vg05,
       initial  online;        ...[13]
server  name     PDB1/bes3B,
       alias    bes3B,
       patrol   10,
       disk     /dev/vg06,
       initial  online;        ...[16]

25.7 MC/ServiceGuard preparations

Read this section when using MC/ServiceGuard in the cluster software. This section covers the following topics:

Package

Shell script for starting HiRDB

Shell script for terminating HiRDB

Shell script for generating a dummy process

Package IP address

Example of grouped MC/ServiceGuard and HiRDB configuration

When using the monitor mode:

When you use the monitor mode, set up the environment by referencing the explanation in this section and the MC/ServiceGuard documentation. For details about setting up the environment for MC/ServiceGuard, see the MC/ServiceGuard documentation.

When using the server mode:

When you use the server mode, set up the environment by referencing the following:

Explanation in 25.12 Hitachi HA Toolkit Extension preparations (server mode only)

MC/ServiceGuard documentation

For details about setting up the environment for MC/ServiceGuard, see the MC/ServiceGuard documentation.

Organization of this section

25.7.1 Package

25.7.2 Shell script for starting HiRDB

25.7.3 Shell script for terminating HiRDB

25.7.4 Shell script for generating a dummy process (services monitored by MC/ServiceGuard) (monitor mode only)

25.7.5 Package IP address

25.7.6 Example of grouped MC/ServiceGuard and HiRDB configuration

25.7.1 Package

The unit MC/ServiceGuard uses for switching systems is called a package. A package refers to a set of the following resources necessary for applications to run:

Volume group

Network address

Service (application)

Operation for startup or stop (script)

Products that group MC/ServiceGuard with HiRDB are usually handled as a single package, which MC/ServiceGuard uses for switching systems. Figure 25-44 provides an overview of packaging. Figure 25-45 shows the flow of package processing by MC/ServiceGuard.

Figure 25-44 Package overview

Figure 25-45 Flow of package processing by MC/ServiceGuard

25.7.2 Shell script for starting HiRDB

Create a shell script for starting HiRDB (execute $PDDIR/bin/pdstart). Be sure to execute that shell script when you start the package (during package startup preprocessing). Set up the shell script for starting HiRDB so that the package control script for MC/ServiceGuard executes this shell script. Figure 25-46 shows the flow of HiRDB startup processing.

Figure 25-46 HiRDB startup processing flow (MC/ServiceGuard)

Organization of this subsection

(1) Examples of a shell script for starting HiRDB

(2) When the pdstart command fails and HiRDB cannot be started

(3) Note

(1) Examples of a shell script for starting HiRDB

Examples of a shell script for starting HiRDB are shown below.

HiRDB/Single Server

#!/bin/sh
PDDIR=/HiRDB_S
PDCONFPATH=${PDDIR}/conf
SHLIB_PATH=${PDDIR}/lib
PATH=${PATH}:${PDDIR}/bin
export PDDIR PDCONFPATH SHLIB_PATH PATH
${PDDIR}/bin/pdstart>/dev/null 2>&1

HiRDB/Parallel Server

#!/bin/sh
PDDIR=/HiRDB_P
PDCONFPATH=${PDDIR}/conf
SHLIB_PATH=${PDDIR}/lib
PATH=${PATH}:${PDDIR}/bin
export PDDIR PDCONFPATH SHLIB_PATH PATH
${PDDIR}/bin/pdstart -q>/dev/null 2>&1

Note

Modify the PDDIR directory on the second line as appropriate for the environment.

The pdstart -q command starts the units in a HiRDB/Parallel Server when the system switchover facility is used.

(2) When the pdstart command fails and HiRDB cannot be started

The following are possible causes of a pdstart command failure:

HiRDB is being started

HiRDB is running

HiRDB is being terminated normally or planned termination is underway

HiRDB is terminating abnormally

HiRDB's environment setup is incorrect

Items 1-4 can occur if the package is started before HiRDB has stopped. There is no means to accurately determine this timing. In such a case, the pdstart command error may be ignored, because it does not affect any other operations.

In the case of item 5, HiRDB cannot be started because the HiRDB environment setup is incorrect; correct the environment setup.

(3) Note

If no system RDAREAs have been created, an instruction to create system RDAREAs (execute the pdinit command) will be displayed during HiRDB startup (during execution of the pdstart command). The pdstart command started from MC/ServiceGuard is executed in the background, so it cannot respond to this instruction. Therefore, before starting operation of MC/ServiceGuard, execute the pdstart command and ensure that system RDAREAs have been created.

25.7.3 Shell script for terminating HiRDB

Create a shell script for terminating HiRDB (executing $PDDIR/bin/pdstop) and start this shell script when the package stops. To do this, set a shell script that terminates HiRDB inside the package control script of MC/ServiceGuard. Figure 25-47 shows the HiRDB termination processing flow.

Figure 25-47 HiRDB termination processing flow (MC/ServiceGuard)

Organization of this subsection

(1) Examples of a shell script for terminating HiRDB

(2) Notes

(1) Examples of a shell script for terminating HiRDB

Examples of a shell script for terminating HiRDB are shown below.

HiRDB/Single Server

#!/bin/sh
PDDIR=/HiRDB_S
PDCONFPATH=${PDDIR}/conf
SHLIB_PATH=${PDDIR}/lib
PATH=${PATH}:${PDDIR}/bin
export PDDIR PDCONFPATH SHLIB_PATH PATH
${PDDIR}/bin/pdstop -f -q>/dev/null 2>&1

Note

Specify the pdstop -f -q command to terminate HiRDB forcibly.

Executing this command may cause an error shutdown in the RDAREAs on the shared disk. If this happens, use the database recovery utility to recover the RDAREAs on the shared disk.

HiRDB/Parallel Server

#!/bin/sh
PDDIR=/HiRDB_P
PDCONFPATH=${PDDIR}/conf
SHLIB_PATH=${PDDIR}/lib
PATH=${PATH}:${PDDIR}/bin
export PDDIR PDCONFPATH SHLIB_PATH PATH
${PDDIR}/bin/pdstop -z -q>/dev/null 2>&1

Note

Specify the pdstop -z -q command to terminate HiRDB forcibly.

Executing this command may cause an error shutdown in the RDAREAs on the shared disk. If this happens, use the database recovery utility to recover the RDAREAs on the shared disk.

(2) Notes

The package is also stopped when system switchover is being performed erroneously. In such a case, HiRDB is terminated forcibly so that the systems can be switched immediately and the standby system can restart HiRDB in order to resume operations.

A termination mode, such as normal termination or planned termination, cannot be specified in a shell script.

To terminate HiRDB normally, first use the pdstop command to terminate HiRDB, and then deactivate the package.

25.7.4 Shell script for generating a dummy process (services monitored by MC/ServiceGuard) (monitor mode only)

MC/ServiceGuard monitors services (applications). It executes a service as a sub-process, and when it detects service termination, it determines that a package error has occurred. The only interface between HiRDB and MC/ServiceGuard, except for HiRDB startup and termination processing, is service termination (exit). All HiRDB processes are monitored by pdprcd and are restarted by HiRDB facilities after an abnormal termination. Therefore, there is no need to have MC/ServiceGuard monitor HiRDB processes. Figure 25-48 shows the relationship between process startup and monitoring.

Figure 25-48 Relationship between process startup and monitoring (MC/ServiceGuard)

To maintain the status in which HiRDB is running as a package, a dummy service (dummy process) is necessary. This dummy process must satisfy all the following conditions:

Conditions

The process must be resident.

Because MC/ServiceGuard issues SIGTERM when it issues an instruction to terminate the package, the process must be terminated when SIGTERM is received.

There is no need to notify MC/ServiceGuard of HiRDB abnormal termination.

The following is an example of a shell script for generating a dummy process:

#!/bin/sh
trap exit SIGTERM
while true
do
   sleep 5
done
exit

Explanation

This example is coded in the Bourne shell. sleep is executed in an infinite loop until SIGTERM (=15) is received. Other implementation methods are also possible.

Specify this shell script in SERVICE_CMD in the package control script. To start a resident process, infinite startup should be used by specifying SERVICE RESTART ="-R" in the package control script. Otherwise, unexpected termination will be treated as abnormal termination of the HiRDB server.

25.7.5 Package IP address

Specify the package's IP address (repositionable IP address) in the package control script.

IP[0] = Package-IP-address (repositionable-IP-address)

25.7.6 Example of grouped MC/ServiceGuard and HiRDB configuration

This section provides and explains an example of a grouped MC/ServiceGuard and HiRDB configuration. Figure 25-49 shows the system configuration. In this case, HiRDB uses a HiRDB/Single Server.

Figure 25-49 Example of grouped MC/ServiceGuard and HiRDB configuration

Organization of this subsection

(1) Package control script

(2) Shell script

(3) HiRDB system definitions

(1) Package control script

Definitions related to system configuration

VGCHANGE="vgchange -a e"
VG[0]=vg10
LV[0]=/dev/vg10/lvol11; FS[0]=/hirdb
IP[0]=192.168.30.51
SUBNET[0]=192.168.30.0

MC/ServiceGuard service registration (definitions for monitoring HiRDB startup and termination)

SERVICE_NAME[0]=hirdb

#Service = specifies the process to be monitored [required]
#MC/ServiceGuard starts and monitors for process termination.
SERVICE_CMD[0]=/etc/cmcluster/hirdb_pkg/monitor.sh         1
SERVICE_RESTART[0]="-R"

#Service startup preprocessing: Start HiRDB here.
function customer_defined_run_cmds
{
/etc/cmcluster/hirdb_pkg/run.sh                            2
test_return 51
}

#Service stop preprocessing: Stop HiRDB here.
function customer_defined_halt_cmds
{
/etc/cmcluster/hirdb_pkg/halt.sh                           3
test_return 52
}

Explanation

Specifies the shell script for generating a dummy script.

Specifies the shell script for starting HiRDB.

Specifies the shell script for terminating HiRDB.

(2) Shell script

Shell script for generating a dummy script (monitor.sh)

!/bin/ksh
trap exit SIGTERM
while true
do
  sleep 5
done
exit

Shell script for starting HiRDB (run.sh)

#!/bin/sh
PDDIR=/home/test
PDCONFPATH=${PDDIR}/conf
SHLIB_PATH=${PDDIR}/lib
PATH=${PATH}:${PDDIR}/bin
export PDDIR PDCONFPATH SHLIB_PATH PATH
/home/test/bin/pdstart > /dev/null 2>&1

Shell script for terminating HiRDB (halt.sh)

#!/bin/sh
export PDDIR=/home/test
export PDCONFPATH=${PDDIR}/conf
export SHLIB_PATH=${PDDIR}/lib
export PATH=${PATH}:${PDDIR}/bin
/home/test/bin/pdstop -f -q> /dev/null 2>&1

(3) HiRDB system definitions

System common definitions

set pd_mode_conf = MANUAL1
set pd_ha_ipaddr_inherit = Y
set pd_ha   = use
pdunit -x pkghost -u puid -d /home/test
pdstart -t SDS -s sds -x pkghost

Note

Specify the host name that corresponds to the repositionable IP address for accessing the package.

Unit information definition

set pd_hostname = vr2001

25.8 VERITAS Cluster Server preparations

Read this section when using VERITAS Cluster Server in the cluster software. This section covers the following topics:

Groups and resources

HiRDB resource type definition

Agent definition pre-preparation

Agent definition

Environment setup file creation

When using the monitor mode:

When you use the monitor mode, set up the environment by referencing the explanation in this section and the VERITAS Cluster Server documentation. For details about setting up the environment for VERITAS Cluster Server, see the VERITAS Cluster Server documentation.

When using the server mode:

When you use the server mode, set up the environment by referencing the following:

Explanation in 25.8.1 Groups and resources

Explanation in 25.12 Hitachi HA Toolkit Extension preparations (server mode only)

VERITAS Cluster Server documentation

For details about setting up the environment for VERITAS Cluster Server, see the VERITAS Cluster Server documentation.

Organization of this section

25.8.1 Groups and resources

25.8.2 HiRDB resource type definition

25.8.3 Agent definition pre-preparation

25.8.4 Agent definition

25.8.5 Environment setup file creation

25.8.1 Groups and resources

The unit VERITAS Cluster Server uses for switching systems between nodes is called a group. The applications comprising a group operate using what are referred to as resources. The following types of resources are available:

Disk group (shared disk)

Network address (logical IP address)

Network interface card (NIC)

Service (application)

Organization of this subsection

(1) Setting up groups and resources

(2) Defining the parent-child relationships of resources

(3) Dummy file (applicable to the monitor mode only)

(4) Notes

(1) Setting up groups and resources

Provide NICs, logical IP addresses, and a shared disk, and set them up as VERITAS Cluster Server resources to form a group. In the explanation in this manual, VERITAS Volume Manager is used for setting up a shared disk. When these resources are set up, resource types that have already been defined (such as NIC type, IP type, and DiskGroup) can be used.

It is also necessary to set up HiRDB as a resource within the group so that it can be managed by VERITAS Cluster Server. For this purpose, a new resource type is defined for HiRDB. For details on how to define a resource type, see 25.8.2 HiRDB resource type definition.

The resource type name is HiRDB_S in the case of a HiRDB/Single Server and HiRDB_P in the case of a HiRDB/Parallel Server. This manual uses the generic notation HiRDB_x for resource type names; substitute HiRDB_S or HiRDB_P as appropriate.

(2) Defining the parent-child relationships of resources

Parent-child relationships are defined for the resources defined within a group. For HiRDB to run, logical IP addresses (when IP addresses are inherited) and the shared disk must be enabled. Therefore, HiRDB_x type resources must be defined as parent resources to the IP type and DiskGroup type resources. Figure 25-50 shows a group configuration.

Figure 25-50 Group configuration

(3) Dummy file (applicable to the monitor mode only)

If HiRDB terminates abnormally when operating the system switchover facility in the monitor mode, HiRDB will restart. For this reason, it is not necessary to monitor the operating status of HiRDB. However, you must create a dummy file for notifying VERITAS Cluster Server that HiRDB is currently active as a resource. This dummy file must satisfy all the conditions listed below.

Conditions

Dummy file is created when HiRDB is started by VERITAS Cluster Server.

Dummy file is deleted when HiRDB is terminated by VERITAS Cluster Server.

While dummy file is in existence, the HiRDB resource is considered to be running.

Hint

If the dummy file is deleted inadvertently, VERITAS Cluster Server assumes that an error has occurred in the resource and switches systems. To prevent this, specify Critical=0 as the resource attribute value for the HiRDB_x type resource. Also, to prevent the dummy file from being deleted inadvertently, create it using the name $PDDIR/.pdveritas.

(4) Notes

The standard output messages of HiRDB commands executed from the agent script of a HiRDB_x type resource are output to VERITAS Cluster Server's log file (/var/VRTSvcs/log/engine.log_A).

Do not delete the dummy file for the HiRDB_x type resource. Otherwise, system monitoring cannot be performed correctly.

25.8.2 HiRDB resource type definition

To set up HiRDB as a resource, resource type HiRDB_x for HiRDB must be defined. When a new resource type is created, an agent for monitoring the resource must also be defined. Agent definition is explained in Section 25.8.3 Agent definition pre-preparation.

Organization of this subsection

(1) HiRDB/Single Server

(2) HiRDB/Parallel Server

(1) HiRDB/Single Server

The following is an example of a resource type definition for a HiRDB/Single Server:

type HiRDB_S (
    static str ArgList[] = { PdDir, PdConfPath, Ld_Library_Path, DummyFilePath }
    str PdDir
    str PdConfPath
    str Ld_Library_Path
    str DummyFilePath
)

Create a file with this contents under the name /etc/VRTSvcs/conf/config/HiRDB_STypes.cf.

(2) HiRDB/Parallel Server

The following is an example of a resource type definition for a HiRDB/Parallel Server:

type HiRDB_P (
    static str ArgList[] = { PdDir, PdConfPath, Ld_Library_Path, DummyFilePath }
    str PdDir
    str PdConfPath
    str Ld_Library_Path
    str DummyFilePath
)

Create a file with this contents under the name /etc/VRTSvcs/conf/config/HiRDB_PTypes.cf.

25.8.3 Agent definition pre-preparation

Define an agent for the newly-created resource type HiRDB_x. This section explains how to define an agent using a shell script. Before defining an agent, take the pre-preparation steps described below.

HiRDB/Single Server
Copy /opt/VRTSvcs/bin/ScriptAgent under the name /opt/VRTSvcs/bin/HiRDB_S/HiRDB-SAgent.

HiRDB/Parallel Server
Copy /opt/VRTSvcs/bin/ScriptAgent under the name /opt/VRTSvcs/bin/HiRDB_P/HiRDB-PAgent.

25.8.4 Agent definition

Define the action details of the agents shown in Table 25-20.

Table 25-20 Agent action definition items and file names

Agent action | HiRDB type | Script file name
Bringing a resource online | HiRDB/Single Server | /opt/VRTSvcs/bin/HiRDB_S/online
HiRDB/Parallel Server | /opt/VRTSvcs/bin/HiRDB_P/online
Taking a resource offline | HiRDB/Single Server | /opt/VRTSvcs/bin/HiRDB_S/offline
HiRDB/Parallel Server | /opt/VRTSvcs/bin/HiRDB_P/offline
Monitoring a resource | HiRDB/Single Server | /opt/VRTSvcs/bin/HiRDB_S/monitor
HiRDB/Parallel Server | /opt/VRTSvcs/bin/HiRDB_P/monitor

Organization of this subsection

(1) Online script

(2) Offline script

(3) Monitor script

(1) Online script

An online script explains the details of the processing to be performed when an agent brings a resource online. The following processing is required:

Setting of the environment variables necessary for executing $PDDIR/bin/pdstart

HiRDB startup

Dummy file creation

Dummy file mode change

(a) HiRDB/Single Server

The following is an example of an online script for a HiRDB/Single Server:

#!/bin/sh
PATH=/sbin:/usr/bin:/usr/sbin:/etc:/bin:/opt/VRTSvcs/bin:"$2"/bin
export PATH
PDDIR="$2"
PDCONFPATH="$3"
LD_LIBRARY_PATH="$4"
export PDDIR PDCONFPATH LD_LIBRARY_PATH
$PDDIR/bin/pdstart
/bin/touch "$5"
/bin/chmod 0400 "$5"

(b) HiRDB/Parallel Server

The following is an example of an online script for a HiRDB/Parallel Server:

#!/bin/sh
PATH=/sbin:/usr/bin:/usr/sbin:/etc:/bin:/opt/VRTSvcs/bin:"$2"/bin
export PATH
PDDIR="$2"
PDCONFPATH="$3"
LD_LIBRARY_PATH="$4"
export PDDIR PDCONFPATH LD_LIBRARY_PATH
$PDDIR/bin/pdstart -q
/bin/touch "$5"
/bin/chmod 0400 "$5"

Note

The pdstart -q command starts the units in a HiRDB/Parallel Server during use of the system switchover facility.

(2) Offline script

An offline script explains the details of the processing to be performed when an agent takes a resource offline. The following processing is required:

Setting of the environment variables necessary for executing $PDDIR/bin/pdstop

HiRDB termination

Dummy file deletion

(a) HiRDB/Single Server

Following is an example of an offline script for a HiRDB/Single Server:

#!/bin/sh
PATH=/sbin:/usr/bin:/usr/sbin:/etc:/bin:/opt/VRTSvcs/bin:"$2"/bin
export PATH
PDDIR="$2"
PDCONFPATH="$3"
LD_LIBRARY_PATH="$4"
export PDDIR PDCONFPATH LD_LIBRARY_PATH
$PDDIR/bin/pdstop -f -q
/bin/rm -f "$5"

Note

Specify the pdstop -f -q command to terminate HiRDB forcibly. Executing this command may cause an error shutdown in the RDAREAs on the shared disk. If this happens, use the database recovery utility to recover the RDAREAs on the shared disk.

The offline script is executed during system switchover. At such a time, HiRDB is terminated forcibly so that the systems can be switched immediately and the standby system can restart HiRDB in order to resume operations.

(b) HiRDB/Parallel Server

The following is an example of an offline script for a HiRDB/Parallel Server follows.

#!/bin/sh
PATH=/sbin:/usr/bin:/usr/sbin:/etc:/bin:/opt/VRTSvcs/bin:"$2"/bin
export PATH
PDDIR="$2"
PDCONFPATH="$3"
LD_LIBRARY_PATH="$4"
export PDDIR PDCONFPATH LD_LIBRARY_PATH
$PDDIR/bin/pdstop -z -q
/bin/rm -f "$5"

Note

Specify the pdstop -z -q command to terminate HiRDB forcibly. Executing this command may cause an error shutdown in the RDAREAs on the shared disk. If this happens, use the database recovery utility to recover the RDAREAs on the shared disk.

The offline script is executed during system switchover. At such a time, HiRDB is terminated forcibly so that the systems can be switched immediately and the standby system can restart HiRDB in order to resume operations.

(3) Monitor script

A monitor script explains the details of the processing to be performed when an agent monitors a resource (for checking whether or not a resource is online). The following processing is required:

Check of whether or not a dummy file exists

Return value setting

The following is an example of a monitor script:

#!/bin/sh
if /bin/test -f "$5"
then
   exit 110
else
   exit 100
fi

The values of the environment variables and dummy file path names, which will be needed in each script, can be transferred during script execution. For the arguments and return values to be transferred to each script, see the VERITAS Cluster Server manual.

25.8.5 Environment setup file creation

Create the environment setup file for VERITAS Cluster Server (/etc/VRTSvcs/conf/config/main.cf) and set up groups and resources.

Organization of this subsection

(1) Resource attribute setting value

(2) Environment setup file example (IP addresses inherited)

(3) Environment setup file example (IP addresses not inherited)

(1) Resource attribute setting value

Table 25-21 shows the values to be specified for resource attributes. For details on the individual items, see the VERITAS Cluster Server manual.

Table 25-21 Values to be specified for resource attributes

Resource | Attribute | Value to be specified
HiRDB_x type resource | Critical | Specify 0.
PdDir | Specify the HiRDB directory name ($PDDIR).
PdConfPath | Specify the name of the directory storing the HiRDB system definition file ($PDCONFPATH).
Ld_Library_Path | Specify the name of the directory storing the HiRDB library ($LD_LIBRARY_PATH = $PDDIR/lib).
DummyFilePath | Specify the dummy file name ($PDDIR/.pdveritas).
DiskGroup type resource | DiskGroup | Specify the name of the VERITAS Volume Manager's disk group to be used as a shared disk by HiRDB (monitor mode only).
IP type resource | Device | Specify the name of the NIC device related to the logical IP address to be used by HiRDB.
Address | Specify the logical IP address to be used by HiRDB.
NIC type resource | Device | Specify the device name of the NIC connected to the network to be used by HiRDB.
NetworkHosts | Specify the IP address of the host on the network, to be used by HiRDB. This attribute is not required.

(2) Environment setup file example (IP addresses inherited)

include "types.cf"
include "HiRDB_STypes.cf"

cluster vcs (
     UserNames = { vcsadm = cDi1yyJLOgPWY }
     CounterInterval = 5
     Factor = { runque = 5, memory = 1, disk = 10, cpu = 25, network = 5 }
     MaxFactor = { runque = 100, memory = 10, disk = 100, cpu = 100, network = 100 }
     )

system mainhost

system reservedhost

snmp vcs (
       TrapList = { 1 = "A new system has joined the VCS Cluster",
                2 = "An existing system has changed its state",
                3 = "A service group has changed its state",
                4 = "One or more heartbeat links has gone down",
                5 = "An HA service has done a manual restart",
                6 = "An HA service has been manually idled",
                7 = "An HA service has been successfully started" }
       )

group gr1 (
       SystemList = { mainhost, reservedhost }
       AutoStartList = { mainhost }
       )

       HiRDB_S gr1_HiRDB_S_UNT1 (
               Critical = 0
               PdDir = "/hirdb/pddir_s"
               PdConfPath = "/hirdb/pddir_s/conf"
               Ld_Library_Path = "/hirdb/pddir_s/lib"
               DummyFilePath = "/hirdb/pddir_s/.pdveritas"
               )

       DiskGroup gr1_DiskGroup_sharedg1 (
               DiskGroup = sharedg1
               )

       IP gr1_IP_logicalhost (
               Device = hme0
               Address = "172.16.161.177"
               )

       NIC gr1_NIC_hme0 (
               Device = hme0
               NetworkHosts = { "172.16.161.1" }
               )

       gr1_HiRDB_S_UNT1 requires gr1_DiskGroup_sharedg1
       gr1_DiskGroup_sharedg1 requires gr1_IP_logicalhost
       gr1_IP_logicalhost requires gr1_NIC_hme0

(3) Environment setup file example (IP addresses not inherited)

include "types.cf"
include "HiRDB_STypes.cf"

cluster vcs (
     UserNames = { vcsadm = cDi1yyJLOgPWY }
     CounterInterval = 5
     Factor = { runque = 5, memory = 1, disk = 10, cpu = 25, network = 5 }
     MaxFactor = { runque = 100, memory = 10, disk = 100, cpu = 100, network = 100 }
     )

system mainhost

system reservedhost

snmp vcs (
       TrapList = { 1 = "A new system has joined the VCS Cluster",
                2 = "An existing system has changed its state",
                3 = "A service group has changed its state",
                4 = "One or more heartbeat links has gone down",
                5 = "An HA service has done a manual restart",
                6 = "An HA service has been manually idled",
                7 = "An HA service has been successfully started" }
       )

group gr1 (
       SystemList = { mainhost, reservedhost }
       AutoStartList = { mainhost }
       )

       HiRDB_S gr1_HiRDB_S_UNT1 (
               Critical = 0
               PdDir = "/hirdb/pddir_s"
               PdConfPath = "/hirdb/pddir_s/conf"
               Ld_Library_Path = "/hirdb/pddir_s/lib"
               DummyFilePath = "/hirdb/pddir_s/.pdveritas"
               )

       DiskGroup gr1_DiskGroup_sharedg1 (
               DiskGroup = sharedg1
               )

       NIC gr1_NIC_hme0 (
               Device = hme0
               NetworkHosts = { "172.16.161.1" }
               )

       gr1_HiRDB_S_UNT1 requires gr1_DiskGroup_sharedg1
       gr1_DiskGroup_sharedg1 requires gr1_NIC_hme0

25.9 Sun Cluster preparations

Read this section when using Sun Cluster in the cluster software. This section covers the following topics:

Cluster startup

Shared disk setup (disk group creation)

Network setup (PNM setup)

Logical host creation

Service creation and registration

For details about setting up the environment for Sun Cluster, see the Sun Cluster manual.

Organization of this section

25.9.1 Cluster startup

25.9.2 Shared disk setup (disk group creation)

25.9.3 Network setup (PNM setup)

25.9.4 Logical host creation

25.9.5 Service creation and registration

25.9.1 Cluster startup

This section explains how to start Sun Cluster, based on the system configuration described below.

Configuration example

Cluster name: sun_cluster

Configuration node: sc-node0sc-node1

Sun Cluster does not have a command for starting the entire cluster. The cluster at the first node is started, then other nodes are added to that cluster. First, scadmin(1M) is used to start the cluster of the master node.

[sc-node0] # scadmin startcluster  sc-node0  sun_cluster
Node specified is sc-node0
Cluster specified is sun_cluster
=========================== WARNING =================================
=                     Creating a new cluster                        =
=====================================================================
You are attempting to start up the cluster node 'sc-node0' as the
only node in a new cluster. It is important that no other cluster
nodes be active at this time. If this node hears from other cluster
nodes, this node will abort. Other nodes may only join after this
command has completed successfully. Data corruption may occur if
more than one cluster is active.

Do you want to continue [y,n,?]   y

Next, confirm that the master node has started, then add other nodes to the cluster.

[sc-node1] # scadmin startnode

When all nodes have been started, use hastat(1M) to check the status of the entire cluster.

[sc-node1] # hastat
Getting Information from all the nodes ......
             HIGH AVAILABILITY CONFIGURATION AND STATUS
             -------------------------------------------

LIST OF NODES CONFIGURED IN <sun_cluster> CLUSTER
     sc-node0 sc-node1

CURRENT MEMBERS OF THE CLUSTER
    sc-node0 is a cluster member        <-- Node has started.
    sc-node1 not a cluster member       <-- Node has not started.

If startup fails, use /var/adm/messages and /var/opt/SUNWcluster/scadmin.log to check for errors.

25.9.2 Shared disk setup (disk group creation)

Create a disk group that is to be used as a shared disk. Area setup and formatting for the created disk group are specified when the HiRDB environment for the master node is set. The explanation in this section uses Sun Enterprise Volume Manager.

25.9.3 Network setup (PNM setup)

The network interface to be used by the logical host must be set to PNM. If a dual network interface is used, it must be set in a NAFO group.

25.9.4 Logical host creation

Once the shared disk and network have been set up, create a logical host. The following configuration is assumed here:

Configuration of logical host to be created:

Logical host name: sc-lnode0 (IP address is 172.16.170.100)

Default master node: sc-node0

Default network interface: qfe1 (qfe1 and qfe2 have been set up in the NAFO group)

Disk group: dg0

File system name: /shdsk/node0

Organization of this subsection

(1) Registering the host name of the logical host

(2) Creating a logical host

(3) Creating the logical host's management file system

(4) Confirming logical host startup

(1) Registering the host name of the logical host

When a DNS server is not used, register the host name of the logical host in the hosts file. This must be set up in both nodes in the cluster.

172.16.170.100  sc-lnode0               # Sun Cluster  logical host 0

(2) Creating a logical host

After confirming that the cluster has been started, create a logical host. This is performed in one node within the cluster.

[sc-node0] # hastat                                     <-- Cluster status check
[sc-node0] # scconf sun_cluster  -L sc-lnode0   \       <-- Logical host name
>               -n  sc-node0, sc-node1          \       <-- Node
>               -g  dg0                         \       <-- Disk group
>               -i  qfe1, qfe1,  sc-lnode0      \       <-- Network
>               -m                                      <-- Automatic changeback disabled
/etc/opt/SUNWcluster/conf/sun_cluster.cdb
Checking node status...
[sc-node0] #

Explanation

-L: Specifies the logical host name.

-n: Specifies the nodes comprising the logical host (separated by commas).

The order in which these nodes are specified corresponds to their priority order. The host specified first becomes the master node. In Sun Cluster, when a high-priority node starts in a logical host without the -m specification, changeback occurs automatically.

-g: Specifies the disk group to be used by the logical host.

The shared disk specified here is imported and mounted automatically when the logical host starts.

/etc/opt/SUNWcluster/conf/hanfs/vfstab.logical-host-name must be set up.

-i: Specifies the network interfaces to be used by the logical host.

Specify network interfaces for the nodes specified in -n in the order specified, and specify the host name of the logical host at the end. If a NAFO group is set up, specify the primary interface.

-m: Specifies that automatic changeback is to be disabled.

If -m is not specified, changeback occurs automatically when a higher-priority node, as specified in -n, starts.

(3) Creating the logical host's management file system

Use scconf -F to create a management file system for storing the configuration information of the logical host. A management file system must be created for all nodes that use the logical host.

[sc-node0] # scconf sun_cluster -F sc-lnode0
/etc/opt/SUNWcluster/conf/sun_cluster.cdb
Checking node status...
[sc-node0] #

When scconf -F terminates normally, the logical host starts in the master node (the first node specified in -n), and the shared disk and logical IP addresses are allocated.

Use vxprint to confirm that a management file system has been created. The logical volume indicated by disk-group-name-stat is the management file system.

[sc-node0] # vxprint

Disk group: dg0

Y NAME          ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg dg0          dg0          -        -        -        -        -       -
dm dg001        c2t0d0s2     -        17678493​ -        -        -       -
v  dg0-stat     fsgen        ENABLED  4096     -        ACTIVE   -       -
pl dg0-stat-01  dg0-stat     ENABLED  7182     -        ACTIVE   -       -
sd dg001-01     dg0-stat-01  ENABLED  7182     0        -        -       -

(4) Confirming logical host startup

The steps taken so far should enable the logical host to start. Start the logical host at each node and confirm its operation.

[sc-node0] # haswitch  -m sc-lnode0                <-- Stops once.
[sc-node0] # haswitch  sc-node0  sc-lnode0         <-- Starts the logical host.
[sc-node0] # netstat -in                           <-- Verifies logical IP address.
Name   Mtu  Net/Dest      Address        Ipkts  Ierrs Opkts  Oerrs Collis Queue
Qfe1:1 1500 172.16.170.0  172.16.170.100 0      0     0      0     0      0

Check these items at all nodes.

[sc-node1] # haswitch  sc-node1  sc-lnode0         <-- Starts the logical host.
[sc-node1] # netstat -in                           <-- Verifies logical IP address.

If the shared disk and logical IP addresses have been assigned correctly, the logical host has been constructed normally.

25.9.5 Service creation and registration

This section provides an overview of Sun Cluster's service control and explains how to register HiRDB as a data service in the Sun Cluster environment using a Sun Cluster control script.

Organization of this subsection

(1) Sun Cluster's service control specification

(2) Methods

(3) HiRDB data service control script (Sun Cluster control script)

(4) HiRDB data service registration

(1) Sun Cluster's service control specification

Use HA-API to register HiRDB as a data service in the Sun Cluster environment. Available APIs include data service registration (hareg), cluster status check (haget), etc. For details, see the Sun Cluster documentation.

(2) Methods

A method refers to a call-out to a data service that occurs in each step during reconfiguration. The following methods are available:

Start (START, START_NET)

Stop (STOP, STOP_NET)

Abnormal termination (ABORT, ABORT_NET)

Monitoring control (FM_INIT, FM_START, FM_STOP, FM_CHECK)

For the HiRDB data service, register the control scripts that will be called when the Start (START, START_NET) and Stop (STOP, STOP_NET) methods occur.

(3) HiRDB data service control script (Sun Cluster control script)

To set up the HiRDB environment as a data service in the Sun Cluster environment, execution control using Sun Cluster HA-API must be carried out. This section explains an example of creating Sun Cluster control scripts for controlling the calling of methods from Sun Cluster. The following names are used for the Sun Cluster control scripts to be created:

Name of script file to be executed by START_NET method: hirdb00-start_net.sh

Name of script file to be executed by STOP_NET method: hirdb00-stop_net.sh

Script to be executed by START_NET

#!/bin/sh
## *********************************************************************
##  HiRDB START_NET Control Script (for Sun Cluster)
## *********************************************************************
PATH=/sbin:/usr/bin:/usr/sbin:/etc:/bin:/opt/SUNWcluster/bin:/HiRDB_S1/bin
export PATH
PDDIR=/HiRDB_S1
PDCONFPATH=/HiRDB_S1/conf
LD_LIBRARY_PATH=/HiRDB_S1/lib
export PDDIR PDCONFPATH LD_LIBRARY_PATH

if [ "$1" != "sc-lnode0" ]
then
  exit 0
fi

$PDDIR/bin/pdstart

Script to be executed by STOP_NET

#!/bin/sh
## *********************************************************************
##  HiRDB STOP_NET Control Script (for Sun Cluster)
## *********************************************************************
PATH=/sbin:/usr/bin:/usr/sbin:/etc:/bin:/opt/SUNWcluster/bin:/HiRDB_S1/bin
export PATH
PDDIR=/HiRDB_S1
PDCONFPATH=/HiRDB_S1/conf
LD_LIBRARY_PATH=/HiRDB_S1/lib

export PDDIR PDCONFPATH LD_LIBRARY_PATH

if [ "$2" != "sc-lnode0" ]
then
  exit 0
fi

MASTER_HOST=`haget -f master -h sc-lnode0`
if [ $MASTER_HOST != `hostname` ]
then
   exit 0
fi

$PDDIR/bin/pdstop -f -q*

Note

The control scripts created above must be stored in the same directory as the HiRDB system definition files ($PDDIR/conf). For nodes other than the master node as well, the same files must be stored in the same directory.

* Executing this command may cause an error shutdown in the RDAREAs on the shared disk. If this happens, use the database recovery utility to recover the RDAREAs on the shared disk.

(4) HiRDB data service registration

Use Sun Cluster's hareg command to register the HiRDB data service hirdb00 into the logical host.

hareg -r hirdb00 -b "/HiRDB_S1/conf"
 -m START_NET="hirdb00-start_net.sh" -t START_NET=1800
 -m STOP_NET="hirdb00-stop_net.sh"   -t STOP_NET=300
 -h sc-lnode0 -a 1

Explanation

-r: Specifies the data service name; this name must be unique within the cluster.

-b: Specifies the directory for storing the control script file.

-m: Specifies START_NET="HiRDB-startup-control-script-file-name".

-t:START_NET=1800

Specifies in seconds the amount of time for terminating the action of the HiRDB startup control script. Specify at least 1800 seconds.

-m: Specifies STOP_NET="HiRDB-stop-control-script-file-name".

-t: STOP_NET=300

Specifies in seconds the amount of time for terminating the action of the HiRDB stop control script. Specify around 300 seconds.

-h: Specifies the name of the logical host.

-a: Specifies the HA-API version (specify 1).

A data service must be registered or deleted while the logical host is stopped. Sun Cluster can control independently startup and stop of the logical host and startup and stop of data services. Therefore, another service can be added while a service is running in the logical host.

However, if the configuration is changed while a service is running, a problem due to cluster configuration change or a problem caused by the added service, etc., might cause a fail over. Therefore, to ensure stable service operations, do not add a service while another service is running.

25.10 HACMP preparations

For details about setting up the environment for HACMP, see the HACMP documentation.

25.11 ClusterPerfect preparations

Read this section when using ClusterPerfect in the cluster software. This section covers the following topics:

System configurations unable to perform system switchover

Network configuration examples

Scenario preparations

Shells used when setting HiRDB scenarios

For details about setting up the environment for ClusterPerfect, see the ClusterPerfect manual.

Organization of this section

25.11.1 System configurations unable to perform system switchover

25.11.2 Network configuration examples

25.11.3 Scenario preparations

25.11.4 Shells used when setting HiRDB scenarios

25.11.1 System configurations unable to perform system switchover

The conditions for the system switchover facility when ClusterPerfect is used are listed below:

There must be at least two connectable fiber optic cables for the shared disk unit (CR80).

Only a 1-to-1 switchover configuration can be used; a mutual system switchover configuration cannot be used.

Organization of this subsection

(1) System configuration able to perform system switchover

(2) System configurations unable to perform system switchover

(1) System configuration able to perform system switchover

Figure 25-51 shows a system configuration that can perform system switchover.

Figure 25-51 System configuration able to perform system switchover

Explanation

The fiber optic cable of each server machine is connected to the two fiber optic cables that connect to the shared disk unit (CR80). Locks operate correctly with this system configuration.

(2) System configurations unable to perform system switchover

Figures 25-52 and 25-53 show system configurations that cannot perform system switchover.

Figure 25-52 System configuration unable to perform system switchover (1)

Explanation

If an optical HUB is placed between CR80 and the server machines, even if server machine 1 is in reserved status, its reserved status is released when server machine 2 restarts. This occurs because server machine 2 generates a LIP that affects server machine 1.

Figure 25-53 System configuration unable to perform system switchover (2)

Explanation

Because a HUB is being used, the LIP that is generated when the system restarts releases the lock and does not operate properly.

In the case of SWITCH, LIP is performed independently on each server so it operates properly.

When using a Fiber-HUB, LIP causes an error in the lock.

Note

LIP is valid on all devices that are connected to the loop. Therefore, the lock may not be performed properly when two CR80 units are connected or multiple server machines and one CR80 unit are connected via a HUB.

25.11.2 Network configuration examples

Organization of this subsection

(1) When inheriting IP addresses

(2) When not inheriting IP addresses

(1) When inheriting IP addresses

When inheriting IP addresses, set a logical IP address and host name that correspond to the logical IP address (host name of the IP address that is set in the IP type resource). Also, set up this logical IP address so it can be replaced on multiple server machines using the system switchover facility. Figure 25-54 shows a network configuration example for when inheriting IP addresses.

Figure 25-54 Network configuration example when inheriting IP addresses (using ClusterPerfect)

Explanation

Set a logical IP address (Service IP: 192.168.1.1) and the host name (logicalhost) that correspond to this logical IP address.

HiRDB is installed on both server machine 1 and server machine 2.

ClusterPerfect, which monitors server machine 1 and server machine 2, is installed on the MMC machine.

/mirror1 is the mount point.

Create HiRDB system files on the shared disk unit (/mirror1).

(2) When not inheriting IP addresses

When not inheriting IP addresses, set a different IP address and host name in the primary system and secondary system. Therefore, you must specify the host name of the secondary system in the pdunit -c operand of the HiRDB system common definition. Figure 25-55 shows a network configuration example for when IP addresses are not inherited.

Figure 25-55 Network configuration example when not inheriting IP addresses (using ClusterPerfect)

Explanation

HiRDB is installed in server machine 1 and server machine 2.

ClusterPerfect, which monitors server machine 1 and server machine 2, is installed on the MMC machine.

/mirror1 is the mount point.

Create HiRDB system files on the shared disk unit (/mirror1).

25.11.3 Scenario preparations

Use the DNCWARE design support system in ClusterPerfect to create and register abnormal termination, startup, termination, and takeover scenarios. For details about creating and registering scenarios, see the ClusterPerfrect manual. The content of each scenario is described below.

Organization of this subsection

(1) Abnormal termination scenario

(2) Startup scenario

(3) Termination scenario

(4) Takeover scenario

(1) Abnormal termination scenario

The contents of the abnormal termination scenario are outlined below:

1: Asynchronous calling of process 4 (enddb)
2: Disconnecting of disk 1 (CR80)
3: Disconnecting of service IP1 (serviceIP)

(2) Startup scenario

The contents of the startup scenario are outlined below:

1: Embedding of service IP1 (serviceIP)
2: Embedding of disk 1 (CR80)
3: Asynchronous calling of process 3 (startdb)

(3) Termination scenario

The contents of the termination scenario are outlined below:

1: Asynchronous calling of process 4 (enddb)
2: Disconnecting of disk 1 (CR80)
3: Disconnecting of service IP1 (serviceIP)

(4) Takeover scenario

The contents of the takeover scenario are outlined below:

1: Embedding of service IP1 (serviceIP)
2: Asynchronous calling of process 10 (mount1)
3: Asynchronous calling of process 3 (startdb)

25.11.4 Shells used when setting HiRDB scenarios

This section explains examples of shells used to set up HiRDB scenarios.

Organization of this subsection

(1) HiRDB/Single Server

(2) HiRDB/Parallel Server

(1) HiRDB/Single Server

The following examples show shells used to set up HiRDB/Single Server scenarios:

Start

#!bin/sh
PDDIR=/hirdb_x
PATH=:/bin:/usr/bin:/usr/bin/ucb:/$PDDIR/bin
PDCONFPATH=$PDDIR/conf
SHLIB_PATH=$PDDIR/lib
LD_LIBRARY_PATH=$PDDIR/lib
export PATH PDDIR PDCONFPATH SHLIB_PATH LD_LIBRARY_PATH
# single
$PDDIR/bin/pdstart
exit 0

Terminate

#!bin/sh
PDDIR=/hirdb_x
PATH=:/bin:/usr/bin:/usr/bin/ucb:/$PDDIR/bin
PDCONFPATH=$PDDIR/conf
SHLIB_PATH=$PDDIR/lib
LD_LIBRARY_PATH=$PDDIR/lib
export PATH PDDIR PDCONFPATH SHLIB_PATH LD_LIBRARY_PATH
# single
$PDDIR/bin/pdstop -f
exit 0

Mount the shared disk

#!/bin/sh
/usr/local/DNCWARE/bin/genresv /dev/sdb
sleep 10
/usr/local/DNCWARE/bin/hadkresv /dev/sdb
mount /mirror1

(2) HiRDB/Parallel Server

The following examples show shells used to set up HiRDB/Parallel Server scenarios:

Start

#!bin/sh
PDDIR=/hirdb_x
PATH=:/bin:/usr/bin:/usr/bin/ucb:/$PDDIR/bin
PDCONFPATH=$PDDIR/conf
SHLIB_PATH=$PDDIR/lib
LD_LIBRARY_PATH=$PDDIR/lib
export PATH PDDIR PDCONFPATH SHLIB_PATH LD_LIBRARY_PATH
# parallel
$PDDIR/bin/pdstart -q
exit 0

Terminate

#!bin/sh
PDDIR=/hirdb_x
PATH=:/bin:/usr/bin:/usr/bin/ucb:/$PDDIR/bin
PDCONFPATH=$PDDIR/conf
SHLIB_PATH=$PDDIR/lib
LD_LIBRARY_PATH=$PDDIR/lib
export PATH PDDIR PDCONFPATH SHLIB_PATH LD_LIBRARY_PATH
# parallel
$PDDIR/bin/pdstop -z
exit 0

Mount the shared disk

#!/bin/sh
/usr/local/DNCWARE/bin/genresv /dev/sdb
sleep 10
/usr/local/DNCWARE/bin/hadkresv /dev/sdb
mount /mirror1

25.12 Hitachi HA Toolkit Extension preparations (server mode only)

You should read this section when you use Hitachi HA Toolkit Extension. This section provides guidelines for the values to be specified in operands of Hitachi HA Toolkit Extension's sysdef and server definition statements that relate to HiRDB.

When you use the standby system switchover facility or the standby-less system switchover (1:1) facility, you must set up an operating environment for each unit. When you use the standby-less system switchover (effects distributed) facility, you must set up an operating environment for each server.

Organization of this section

25.12.1 sysdef definition statement

25.12.2 server definition statement

25.12.1 sysdef definition statement

Organization of this subsection

(1) servmax operand

(1) servmax operand

You can specify this operand when the version of Hitachi HA Toolkit Extension is 01-04 or later.

For the servers to be switched using Hitachi HA Toolkit Extension, specify 16 or 64 as the maximum number of servers that can be started concurrently as running servers or standby servers on a single server machine.

16: Sets 16 as the maximum number of servers that can be started concurrently.

64: Sets 64 as the maximum number of servers that can be started concurrently.

Specify 64 when the number of servers, which are the units for switching on a single server machine, exceeds 16.

The number of servers to be switched using Hitachi HA Toolkit Extension also includes products other than HiRDB that are to be switched. HiRDB computes the number of servers to be switched as follows:

Total number of running units and standby units that are running on a single server machine and that are subject to standby system switchover

Total number of normal BES units and alternate BES units that are running on a single server machine and that are subject to standby-less system switchover (1:1)

Total number of host BESs and guest BESs that are running on a single server machine and that are subject to standby-less system switchover (effects distributed)

25.12.2 server definition statement

Organization of this subsection

(1) switchtype operand

(2) actcommand operand

(3) termcommand operand

(1) switchtype operand

Specify the processing to be performed when a server failure is detected.

switch:

When HiRDB (or unit for a HiRDB/Parallel Server) terminates abnormally, system switchover is to be performed and HiRDB is to restart on the switchover destination system.

For the standby-less system switchover (1:1) facility, it is recommended that you specify switch in the server definition statement for the alternate portion created in the alternate BES unit. When switch is specified, the system is switched from the alternate portion to the normal BES unit if an error occurs in the alternate BES unit while alternating units; as a result, the load on the alternate BES unit can be reduced after it restarts.

For the standby-less system switchover (effects distributed) facility, it is recommended that you specify switch in the server definition statement for the guest BES. When switch is specified, the guest BES switches to another unit if an error occurs in the unit in which the guest BES is running; as a result, the load on the unit can be distributed after it restarts.

restart:

HiRDB (or unit for a HiRDB/Parallel Server) is to be restarted on the system on which the error occurred. Only if HiRDB cannot be restarted on the system on which the error occurred is system switchover to occur and HiRDB to be restarted on the switchover destination system (system switchover is reported by output of the KFPS00715-E message).

For the standby-less system switchover (1:1) facility, it is not recommended that you specify restart in the server definition statement for the alternate portion created in the alternate BES unit. When restart is specified, the alternate BES unit continues to assume the alternate processes of the normal BES unit when an error occurs in the alternate BES unit while alternating units; as a result, the load on the alternate BES unit is not reduced after it restarts.

For the standby-less system switchover (effects distributed) facility, it is not recommended that you specify restart in the server definition statement for the guest BES. When restart is specified, the guest BES continues processing if an error occurs in the unit in which the guest BES is running after the unit restarts; as a result, the load on the unit cannot be distributed after it restarts.

manual:

The systems are not to be switched automatically even if HiRDB (or unit for a HiRDB/Parallel Server) cannot be restarted.

Hint

When you use the standby-less system switchover (1:1) facility with a mutual alternating configuration, specify the same value in the switchtype operand of the alternate BES unit and the alternate portion.

When you use the standby-less system switchover (effects distributed) facility, specify the same value in the switchtype operand of all servers in the HA group.

(2) actcommand operand

Specify a command to be executed at the time of package startup or failover. Hitachi recommends that you not specify this operand in the server mode, because this is an extension issued by system switchover and the command must be issued to the standby system unit.

When a unit in the system manager is subject to system switchover, specifying the pdstart command (pdstart -q for a HiRDB/Parallel Server) in the actcommand operand makes it possible to group this command with the package startup command and start HiRDB. However, because the actcommand operand is also executed during system switchover, the pdstart command is issued to the standby system HiRDB that is already performing the startup processing and an error is output.

For the standby-less system switchover (1:1) facility, specify the pdstart -q -c command in the startup batch file if the actcommand operand must be specified for the standby system (alternate portion).

For the standby-less system switchover (effects distributed) facility, you cannot specify the actcommand operand.

(3) termcommand operand

Hitachi recommends specifying the pdstop -f -q command (pdstop -z -q command for a HiRDB/Parallel Server) for two reasons. First, specifying the forced termination option is guaranteed to stop the unit. Second, during planned system switchover, the standby system must inherit IP addresses when it restarts. Also, if planned system switchover is performed when the running system unit has not started, the pdstop command specified in the termcommand operand will result in an error. If the termcommand operand is not specified, the pdstop command must be used to terminate forcibly the running unit before system switchover occurs. If a planned system switchover is performed while the running system unit is still active, there will be two running units. If an error occurs, both systems may stop.

For the standby-less system switchover (1:1) facility, specify the pdstop -z -c command in the termcommand operand of the alternate portion.

For the standby-less system switchover (effects distributed) facility, specify the pdstop -z -s command in the termcommand operand of all servers within the HA group.

25.13 Differences in the HiRDB operating procedures

The operating procedures for the items listed below depend on whether or not you are using the system switchover facility. The differences in each procedure are described in this section.

Starting HiRDB (in the server mode)

Starting HiRDB (in the monitor mode)

Terminating HiRDB (in the server mode)

Terminating HiRDB (in the monitor mode)

Checking status

Handling of statistics log files

Notes on operations

Notes on using the standby-less system switchover facility

Organization of this section

25.13.1 Starting HiRDB (in the server mode)

25.13.2 Starting HiRDB (in the monitor mode)

25.13.3 Terminating HiRDB (in the server mode)

25.13.4 Terminating HiRDB (in the monitor mode)

25.13.5 Monitoring statuses

25.13.6 Handling of statistics log files

25.13.7 Notes on operations

25.13.8 Notes on using the standby-less system switchover facility

25.13.1 Starting HiRDB (in the server mode)

Organization of this subsection

(1) HiRDB/Single Server

(2) HiRDB/Parallel Server (in the case of the standby system switchover facility)

(3) Standby-less system switchover (1:1) facility

(4) Standby-less system switchover (effects distributed) facility

(5) Notes

(1) HiRDB/Single Server

The procedure for starting a HiRDB/Single Server when using the system switchover facility is explained below.

Procedure:

Use the pdstart command to start HiRDB on the running system.

Use the pdstart command to start HiRDB on the standby system.

(2) HiRDB/Parallel Server (in the case of the standby system switchover facility)

Use the pdstart command to start HiRDB on the running system and the standby system.

Inheriting IP addresses

Starting HiRDB on the running system
When starting HiRDB on the running system without allocating the IP address in advance, directly log onto the server machine of each unit and execute the pdstart -q command.
If you allocate an IP address for each server machine and execute the pdstart command, you can start all units on the running system. When using HiRDB on the running system to start one unit at a time, be sure to allocate the IP address of the unit you will start first.

Starting HiRDB on the standby system
Directly log onto a server machine that has standby system units and execute the pdstart -q command.

Not inheriting IP addresses

Starting HiRDB on the running system
Directly log onto a server machine that has running system units and execute the pdstart -q command. Another method is to execute the pdstart command to start all units on the running system.

Starting HiRDB on the standby system
Directly log onto a server machine that has standby system units and execute the pdstart -q command.

(3) Standby-less system switchover (1:1) facility

Table 25-22 lists the methods of starting the normal BES unit and alternate BES unit.

Table 25-22 HiRDB startup methods when using the standby-less system switchover (1:1) facility

Objective | Command to execute | Remarks
Starting the normal BES unit | pdstart -q | If this command is executed when a normal BES unit has stopped when alternating units, the normal BES unit is placed in waiting status.¹
Starting the alternate BES unit | pdstart -q | The alternate portion in the alternate BES unit is also started. The alternate portion is placed in waiting status² if it was in normal status.
Starting the alternate portion | pdstart -q -c | Not necessary because HiRDB starts automatically. The command needs to be executed only when the alternate portion is stopped or is to be reactivated.

Note: Startup cannot be performed at the server level.

¹ The system will only be switched back to the normal BES unit if the normal BES unit is in waiting status (that is, it will not be switched back to normal status from alternating status). If the normal BES unit is in waiting status, the system status is displayed as SBY in the execution results of the pdls -d ha command.

² System switching only occurs when the alternating portion is in waiting status. If the alternate BES unit is in waiting status, the system status is displayed as SBY in the execution results of the pdls -d ha command.

(4) Standby-less system switchover (effects distributed) facility

Table 25-23 shows how to start the regular unit and a guest BES unit.

Table 25-23 HiRDB startup methods when using the standby-less system switchover (effects distributed) facility

Objective
Command to execute
Remarks

Starting the regular unit
pdstart -q
Started when the regular unit is stopped.

Starting the accepting unit
pdstart -q
Guest BESs in the accepting unit are also started at the same time.

Starting the host BES or starting the guest BES
pdstart -u -s
If a guest BES is stopped, it is placed in accepting status.
In general, it is not necessary to use this command because HiRDB starts automatically; this command is needed only when a back-end server or its standby server was stopped explicitly.

(a) Starting the entire system

Table 25-24 shows how to start the entire system.

Table 25-24 Startup method for the entire system

Input location | Command | Operation
Unit where the system manager is defined | pdstart | Starts the entire system.

The process of starting the entire system is explained below.

Server startup: Execute server startup for all host BESs and guest BESs of each unit.

Figure 25-56 shows an example of starting the entire system when the standby-less system switchover (effects distributed) facility is used.

To start the entire system, enter the pdstart command from the unit where the system manager is defined, as is the case when standby system switchover is used. The guest BESs in each unit are placed in accepting status automatically.

Figure 25-56 Example of starting the entire system when the standby-less system switchover (effects distributed) facility is used

Table 25-25 shows the system startup operations. When system startup is completed, the KFPS05210-I message is output.

Table 25-25 System startup operations

Start type
If standby-less system switchover (effects distributed) facility is applicable to the unit

No
Yes

System startup
Starts all units
(All servers start).
Starts all servers
(Not all units start).

Solo-startup of the unit where the system manager is defined
(after abnormal termination of the unit where the system manager is defined)
Starts one front-end server, one dictionary server, and one back-end server.
Starts one front-end server, one dictionary server, and one back-end server.

Solo-startup of a unit in an HA group

Solo-startup of other units

Legend:

: Not applicable

(b) Starting a unit

Table 25-26 shows how to start a unit.

Table 25-26 Unit startup method

Input location | Command | Option | Operation
-q | -u
Unit where the system manager is defined | pdstart | No | Yes | Starts the target unit.
Yes | No
Target unit | pdstart | Yes | No

Startup modes for units

Table 25-27 shows the unit startup modes. Whether a unit is to be started normally or restarted is determined exclusively by the unit's previous termination mode; it is not affected by the presence or absence of a host BES or guest BES that starts, or by normal start or restart of the server that starts.

Table 25-27 Unit startup modes

Unit's previous termination mode | Host BES or guest BES | Unit startup mode
Startup of start server | Startup of restart server during startup of start server
Normal stop | No | No | Normal start
Yes | No
Yes | Yes
Planned stop, forced termination, or abnormal termination | No | No | Restart
Yes | No
Yes | Yes

When the standby-less system switchover (effects distributed) facility is used, determination and processing of restart or normal start is executed for each user server. Therefore, the unit can start normally even when another server within the unit has been terminated forcibly or abnormally or is running on another unit in the HA group.

Also when the standby-less system switchover (effects distributed) facility is used, a unit is restarted after it has been terminated forcibly or abnormally. Because restart processing is executed for each user server, there is no resource (database) to be restored for the unit itself. However, as usual, the operations during unit restart are different from those during a normal start, as shown in Table 25-28.

Table 25-28 Significance of unit restart

Item
Content

Configuration modification check
Checks for definition modifications that increase system resources (such as shared memory) to eliminate the risk of a restart failure (the number of guest BESs that can be accepted can be changed).

System startup completion check
If there is one front-end server, one dictionary server, and one back-end server available during the restart of the unit where the system manager is defined, system startup is considered complete and service begins. During normal startup of the unit where the system manager is defined, the system waits for all servers to be completely started. However, during a restart of the unit where the system manager is defined, the number of servers to wait for is reduced, resulting in an earlier resumption of service acceptance.

Unit run ID inheritance
Unit run ID is inherited before the unit stops. It is used as the reference for output of the KFPS01826-I message during unit startup and for regular and automatic execution of pdcspool.

Unit startup example

Figure 25-57 shows an example of unit start when the standby-less system switchover (effects distributed) facility is used. Start the unit as follows:

Enter the pdstart -u command from the unit where the system manager is defined.

Log onto the host where the unit is located and enter the pdstart -q command.

As the unit starts, the system changes the status of the following guest BESs:

Cancels the accepting status for guest BESs in the unit (Automatic status change 1 in the figure)

Guest BESs corresponding to host BESs in the unit (Automatic status change 2 in the figure)

Figure 25-57 Unit startup example when the standby-less system switchover (effects distributed) facility is used

Unit startup example when there is no running system back-end server

Figure 25-58 shows an example of starting a unit that has no running system back-end server when the standby-less system switchover (effects distributed) facility is used.

The following methods are available for starting the unit:

Entering the pdstart -u command from the unit where the system manager is defined

Logging onto the host where the unit is located and entering the pdstart -q command

As the unit starts, the system changes the status of the guest BESs in the unit (Automatic status change 1 in the figure).

Figure 25-58 Example of starting a unit that has no running system back-end server when the standby-less system switchover (effects distributed) facility is used

You can determine unit startup completion based on the output of the KFPS05110-I message:

For a unit that does not use the standby-less system switchover (effects distributed) facility, the message is output when startup of all servers in the unit has been completed.

For a unit that uses the standby-less system switchover (effects distributed) facility, the message is output when startup of all running system servers in the unit has been completed.

(c) Starting a server

Table 25-29 shows how to start a server.

Table 25-29 Startup method for a server

Input location | Command | Option | Operation
-q | -u | -s
Unit where the system manager is defined | pdstart | No | No | Yes | Starts the target servers in all active units in an HA group¹
Yes | No | Yes | Starts the host BES (-u may be omitted)²

¹ The back-end servers in one of the units that are active in the HA group become the running servers and the other units are placed in accepting status.

² When the target back-end servers are started successfully as running servers, the active units in the HA group are placed in accepting status automatically.

Table 25-30 shows the processing results during server startup depending on the cluster software used.

Table 25-30 Processing results during server startup

Cluster software | Server type | Other units while the applicable server is active | Activation on the applicable host³ | Server startup result
HA monitor | Host BES | No |  | Active
Yes |  | Accepting
Guest BES | No |  | Waits for running system to start¹
Yes |  | Accepting
Hitachi HA Toolkit Extension |  | No | Yes | Active²
No | Accepting
Yes | Yes |
No | Accepting

Legend:

: Not applicable

¹ HA monitor does not include the concepts of the running server and the standby server once a server has stopped. When the server starts again, the running system and the standby system are determined anew. In such a case, a secondary system (standby system in the default mode) waits for the running system to start when there is no running system. Therefore, if an active guest BES is stopped and then restarted at the same unit, it waits for the running system to start and does not return to active status until the monact command is executed.

² Even after it stops a server, Hitachi HA Toolkit Extension makes the server appear to the cluster software to remain active. Therefore, when active servers, including guest BESs, are stopped and started on the same unit, they are placed on active status again.

³ This is equivalent to package activation in MC/ServiceGuard or group start in VERITAS Cluster Server.

Server startup example

Figure 25-59 shows an example of starting a running system server when the standby-less system switchover (effects distributed) facility is used.

The following method is available for starting the running system server:

Entering the pdstart -s command from the unit where the system manager is defined

As the server starts, the system changes the status of the guest BESs corresponding to the server (Automatic status change in the figure).

To check whether the server is the running system, use the pdls -d ha command.

Figure 25-59 Example of starting a running system server when the standby-less system switchover (effects distributed) facility is used

Figure 25-60 shows an example of starting a standby system server when the standby-less system switchover (effects distributed) facility is used.

The following method is available for starting a standby system server:

Entering the pdstart -u -s command from the unit where the system manager is defined

The specified host BES is placed in accepting status. To check whether the server is the running system, use the pdls -d ha command.

Figure 25-60 Example of starting a standby system server when the standby-less system switchover (effects distributed) facility is used

Figure 25-61 shows an example of a guest server status change when the standby-less system switchover (effects distributed) facility is used.

The following method is available to make a guest BES in a unit accepting:

Entering the pdstart -u -s command from the unit where the system manager is defined

The specified guest BES is placed in accepting status.

Figure 25-61 Status change example of a guest server when the standby-less system switchover (effects distributed) facility is used

(5) Notes

Common notes

When executing the pdstart -q command, you must start all units within 20 minutes from the time the first unit starts. If all units cannot be started within 20 minutes, HiRDB startup processing terminates. Note that this value of 20 minutes for the startup time limit can be modified with the pd_reduced_check_time operand. The value of 20 minutes is the default for this operand.

The -i option, -r option, and dbdestroy option cannot be specified when HiRDB on a standby system executes the pdstart command.

Execute the pdstart -r command after HiRDB on the running system and standby system terminates. When the pdstart -r command is used to start HiRDB, HiRDB is not subject to system switchover. After a process such as database recovery processing terminates, terminate HiRDB then start it on the running system and standby system.

Notes on using the rapid system switchover facility

The notes explained here apply only when you are using Hitachi HA Toolkit Extension.

After startup processing for the running system unit is finished, start the standby system unit that uses the rapid system switchover facility. If the standby system unit is started before the running system unit has started, the standby system unit waits for startup of the running system unit to finish. If the running system unit does not start up within the waiting time limit, the standby system unit outputs abort code Phi1012 and terminates abnormally.

Notes on using the standby-less system switchover (1:1) facility

The notes explained here apply only when you are using Hitachi HA Toolkit Extension.

After starting either the normal BES unit or the alternate BES unit, start the other idle unit within 20 minutes. If the standby system unit is started before the running system unit has started, the standby system unit waits for startup of the running system unit to finish. If the running system unit does not start within the waiting time limit, the standby system unit outputs abort code Phi1012 and terminates abnormally.

During normal operation, the normal BES unit becomes the running system and the alternate portion becomes the standby system. When alternating units, the alternate portion becomes the running system and the normal BES unit becomes the standby system.

Notes on using MC/ServiceGuard

When starting HiRDB, the MC/ServiceGuard package must start normally on the running system. Therefore, before starting HiRDB, confirm that the package has started. Use MC/ServiceGuard commands to confirm that the package has started or to start a package.

When the running system unit has stopped (including when the unit terminates abnormally), MC/ServiceGuard may recognize that node as one that cannot be switched during a system switchover. In such a case, that node cannot be switched even if HiRDB is waiting. Use an MC/ServiceGuard command to place that node in system switchable status.

Notes on using Hitachi HA Toolkit Extension

If HiRDB is started without activating service processing for Hitachi HA Toolkit Extension, both systems will start as standby systems. In such a case, follow the applicable procedure explained in Table 25-31.

service processing for Hitachi HA Toolkit Extension

Table 25-31 Procedures to perform when HiRDB is started without activating service processing for Hitachi HA Toolkit Extension

Condition
Procedure

User server hot standby is applied to the unit
Message KFPS01872-I, which indicates that both systems started as standby systems, is output. This message is output to both systems. The procedure for resolving this problem is explained below.
Procedure

Use the terminate waiting system command of Hitachi HA Toolkit Extension to terminate both systems.

Activate the cluster software on the running system.

Start the running system unit.

Confirm* that startup processing of the running system unit is finished, then start the standby system unit.

Rapid system switchover facility is applied to the unit
Message KFPS01854-E is output and the primary system unit terminates abnormally (abort code: Psadhfe). The secondary system unit waits for the primary system unit to start as the running system unit. The procedures for resolving this problem are explained below.
Starting the primary system as the running system

Activate the cluster software on the primary system.

Start the primary system unit as the running system unit.

Because the waiting time is elapsing, if the secondary system (standby system) unit terminates abnormally, confirm* that the startup process of the running unit is complete, and then start the standby system unit.

Starting the secondary system as the running system

Use the pdstop -z (pdstop -f for a HiRDB/Single Server) command to terminate the secondary unit forcibly.

Activate service processing for Hitachi HA Toolkit Extension on the secondary system.

Start the secondary system unit as the running system unit.

Confirm* that the startup process of the running unit is complete, and then start the standby system unit.

Unit for which the standby-less system switchover (1:1) facility is applicable
Message KFPS01854-E is output and the normal BES unit terminates abnormally (abort code: Psdahfe). The alternate portion waits for the normal BES unit to start. The procedure for resolving this problem is explained below.
Procedure

Activate service processing for Hitachi HA Toolkit Extension on the normal BES unit.

Start the normal BES unit.

Because the waiting time is elapsing, if the waiting status of the alternate portion is released, confirm* that the startup process of the normal BES unit is complete, and then place the alternate portion in waiting status.

Unit for which the standby-less system switchover (effects distributed) facility is applicable
Servers in both the running system and the standby system are placed in standby status and can be operated by the user. Neither system is terminated abnormally.
In this case, you can activate the cluster software on the host on which the server becomes the running system and complete the startup process (start the service process of Hitachi HA Toolkit Extension).

* You can use the following to confirm that unit startup processing is complete:

STATUS in the execution results of the pdls command displays ACTIVE.

The KFPS05210-I or KFPS05110-I message is output.

Notes about using the HA monitor

Before you start the running unit, use HA monitor's monshow command to make sure that the standby unit has stopped. The monshow command does not display any inactive system. If the command displays the status of the standby system, the standby status has not stopped.

An attempt to start the running unit immediately after its termination may result in output of the KFPS01878-I and KFPS00715-E messages, because the standby unit is still engaged in termination processing. If an attempt to start the running unit has failed, follow the procedure below to start the unit:

Use HA monitor's monshow command to make sure that the standby unit has stopped.

Execute the pdrpause command to restart HiRDB's process service.

Use the pdstart command to start the running unit.

25.13.2 Starting HiRDB (in the monitor mode)

Use a command in the cluster software (monbegin command in the case of HA monitor) to start HiRDB on the running system and standby system. If HiRDB cannot be started for either of the following reasons, correct the problem and then use the pdstart (pdstart -q for a HiRDB/Parallel Server) command to start HiRDB:

An error occurred that requires setup to be performed again with pdsetup.

Restart failed when no user command was specified during a restart attempt.

Notes

Execute the pdstart -r command after HiRDB on the running system and standby system terminates. When the pdstart -r command is used to start HiRDB, HiRDB is not subject to system switchover. After a process such as database recovery processing terminates, terminate HiRDB, then start it on the running system and standby system.

For a HiRDB/Parallel Server, units not subject to system switchover (units specified by pd_ha_unit=nouse) cannot be started by a cluster software command. In such a case, log on directly to the server machine on the applicable unit and execute the pdstart -q command.

Note on using MC/ServiceGuard

When HiRDB termination terminates abnormally, the status of the MC/ServiceGuard package is up or running. In such a case, use the pdstart command to separately restart HiRDB.

Procedure for starting HiRDB when using ClusterPerfect

To start HiRDB when using ClusterPerfect:

Check to see if the dncware_daemon on the primary system and secondary system is set to start automatically. You must have root privileges to perform this check.
# chkconfig -list
dncware_daemon 0:off 1:off 2:off 3:off 4:off 5:off 6:off

If the dncware_daemon is off, make the specification to turn it on.
# chkconfig dncware_daemon on
dncware_daemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off

Restart the server machines for the primary system and the secondary system.

Activate the DNCWARE operation support system for MMC.

Activate the ClusterPerfect system information window. This window displays the status of the primary system and secondary system.

Activate Resource 1 and Resource 2. Start the server (HiRDB) from this window.

For details about activation and the window status, see the ClusterPerfect manual.

25.13.3 Terminating HiRDB (in the server mode)

Organization of this subsection

(1) Standby system switchover facility

(2) Standby-less system switchover (1:1) facility

(3) Standby-less system switchover (effects distributed) facility (terminating both the running system and the standby system)

(4) Standby-less system switchover (effects distributed) facility (terminating only the standby system)

(1) Standby system switchover facility

Table 25-32 lists the methods of terminating HiRDB when using the standby system switchover facility.

Table 25-32 Terminating HiRDB when using the standby system switchover facility

Condition
Termination method

Cluster software used is HA monitor
Terminating both the running system and the standby system
Use the pdstop command to terminate the running system HiRDB. The standby system HiRDB will terminate together with the running system. This situation also applies during planned termination or forced termination.
To terminate at the unit level, use the pdstop -u command to terminate the running system unit. The standby system unit will terminate together with the running system unit. This situation also applies when the pdstop -z command is executed.

Terminating only the standby system
Use the HA monitor monsbystp command to terminate only the standby system.

Cluster software other than HA monitor is used
Terminating both the running system and the standby system*
Use the pdstop command to terminate the running system HiRDB, then use the hatesbystp command in Hitachi HA Toolkit Extension to terminate HiRDB. Executing the pdstop command does not terminate the standby system HiRDB. This situation also applies to planned termination or forced termination.
To terminate at the unit level, use the pdstop -u command to terminate the running system unit, then use the hatesbystp command in Hitachi HA Toolkit Extension to terminate the standby unit. Executing the pdstop -u command does not terminate the standby system unit. This situation also applies when the pdstop -z command is executed.

Terminating only the standby system
Use the hatesbystp command in Hitachi HA Toolkit Extension to terminate the standby system HiRDB.

*

When terminating the running system HiRDB (or unit), be sure to terminate the standby system HiRDB also.

Be sure to terminate the standby system HiRDB before restarting the running system HiRDB (or unit).

(2) Standby-less system switchover (1:1) facility

Table 25-33 lists the methods of terminating HiRDB when you use the standby-less system switchover (1:1) facility.

Table 25-33 Terminating HiRDB when using the standby-less system switchover (1:1) facility

Objective
Command to execute
Remarks (effect on other unit or alternate portion)

Terminating HiRDB
pdstop
No specific operation needs to be performed on the alternate BES. Operation does not change even when alternating units.

Terminating the normal BES unit
pdstop -u
Waiting status¹ of the alternate portion is released.

Terminating the alternate BES unit
Normal operation
pdstop -u
Waiting status of the alternate portion in the alternate BES unit is released.

Alternating
The alternate portion in the alternate BES unit also stops.
Also, when the normal BES unit is in waiting status,² the waiting status of the alternate BES unit is released.

Terminating the alternate portion when alternating units
pdstop -u
Specify for the unit identifier the unit identifier of the normal BES unit.

Releasing waiting status of the alternate portion
hatesbystp³
None

Releasing waiting status of the normal BES unit
hatesbystp⁴

Note: Termination at the server level is not possible.

¹ The system is switched to the alternate BES unit only if the alternate portion is in waiting status. If the alternate portion is in waiting status, the system status is displayed as SBY in the execution results of the pdls -d ha command.

² The system will be switched back to the normal BES unit only if the normal BES unit is in waiting status (that is, it will not be switched back to normal status from alternating status). If the normal BES unit is in waiting status, the system status is displayed as SBY in the execution results of the pdls -d ha command.

³ Use the monsbystp command of HA monitor or the hatesbystp command of Hitachi HA Toolkit Extension to release the waiting status of the alternate portion. Specify in the hatesbystp command the alias of the normal BES unit that corresponds to the alternate portion to be released from standby status.

⁴ Use the monsbystp command of HA monitor or the hatesbystp command of Hitachi HA Toolkit Extension to release the waiting status of the normal BES unit. Specify in the hatesbystp command the unit identifier of the normal BES unit that releases the waiting status.

Examples of terminating an alternate BES unit or normal BES unit are provided below.

Example 1: Terminating a normal BES unit (normal operation, one-way alternating configuration)

To start the normal BES unit (UNT1) that has stopped:

Use the pdstart -q command to start the normal BES unit (UNT1).

Use the pdstart -q -c command to place the alternate portion of BES1 in waiting status.

Example 2: Terminating an alternate BES unit (normal operation, one-way alternating configuration)

To start the alternate BES unit (UNT2) that has stopped:

Use the pdstart -q command to start the alternate BES unit (UNT2). The alternate portion of BES1 is also placed in waiting status.

Example 3: Terminating a unit (normal operation, mutual alternating configuration)

To start a unit (UNT1) that has stopped:

Use the pdstart -q command to start the unit (UNT1). The alternate portion of BES2 is also placed in waiting status.

Use the pdstart -q -c command to place the alternate portion of BES1 in waiting status.

Example 4: Terminating a unit (alternating, one-way alternating configuration)

To return to normal status:

Reactivate the package for BES1. This step is necessary only when using Hitachi HA Toolkit Extension.

Use the pdstart -q command to start the alternate BES unit (UNT2).

Use the pdstart -q command to start the normal BES unit (UNT1).

Example 5: Terminating a unit (alternating, mutual alternating configuration)

* The alternate portion of BES2 is inactive.

To return to normal status:

Reactivate the package for BES1. This step is necessary only when using Hitachi HA Toolkit Extension.

Use the pdstart -q command to start the unit (UNT2).

Use the pdstart -q command to start the unit (UNT1).

Example 6: Terminating the alternate portion (alternating, one-way alternating configuration)

To return to normal status:

Reactivate the package for BES1. This step is necessary only when using Hitachi HA Toolkit Extension.

Use the pdstart -q command to start the unit (UNT1).

Example 7: Releasing the waiting status of the alternate portion (normal operation, mutual alternating configuration)

To place the alternate portion of BES2, which has stopped, in waiting status:

Use the pdstart -q -c command to place the alternate portion of BES2 in waiting status.

Example 8: Stopping a unit in waiting status (alternating, mutual alternating configuration)

* The alternate portion of BES2 is inactive.

To place a stopped unit (UNT1) in waiting status:

Use the pdstart -q command to place the unit (UNT1) in waiting status.

(3) Standby-less system switchover (effects distributed) facility (terminating both the running system and the standby system)

This section explains how to terminate both the running system and the standby system.

(a) Stopping the entire system

Table 25-34 shows how the entire system is stopped when the standby-less system switchover (effects distributed) facility is used.

Table 25-34 Stopping the entire system when the standby-less system switchover (effects distributed) facility is used

Input location | Command | Option | Condition | Operation
-f | Forcibly/abnormally terminated server?
Unit where system manager is defined | pdstop | No | Yes¹ | Error (a new message, such as KFPS05063-E or its equivalent, is output)
No | No² | Stops the system.
Yes | Yes | Stops the system forcibly (some units are already stopped).
Yes | No | Stops the system forcibly.

¹ Even if a server has been terminated forcibly or abnormally, it is considered that there is no forcibly/abnormally terminated server if this server is in one of the following statuses:

Restarted at another unit and currently running.

Restarted at another unit and has already been stopped normally.

² No under Forcibly/abnormally terminated server? means one of the following:

There are no servers in the system that have been terminated forcibly or abnormally.

There is a server in the system that was terminated forcibly or abnormally, but it has since been restarted at another unit and is currently running.

There is a server in the system that was terminated forcibly or abnormally, but it has since been restarted at another unit and has already been stopped normally.

Table 25-35 shows the processing that occurs during system termination.

Table 25-35 Processing that occurs during system termination

Target | Processing detail
Unit | While the system is being stopped, the system manager stops all units (by executing pdstop -u UID (-f) or its equivalent).
Server | When a unit is stopped while the system is being stopped, the system stops all host BESs and guest BESs at that unit (by executing pdstop -q -s server-name (-f) or its equivalent).

When the system is stopped, the accepting status for guest BESs at an accepting unit is cancelled automatically regardless of whether the system is being terminated normally terminated or forcibly. This cancellation occurs even if a guest BES is active. For this reason, you need not take any action with regard to guest BESs.

Table 25-36 shows the processing that occurs for the various back-end servers during system termination when the standby-less system switchover (effects distributed) facility is used.

Table 25-36 Processing that occurs for the various back-end servers during system termination when the standby-less system switchover (effects distributed) facility is used

Back-end server's status | Processing
Host BES | Running | Stops.
Accepting status | Cancels the accepting status automatically.
Guest BES | Running | Stops automatically.
Accepting status | Cancels the accepting status automatically.

Figure 25-62 shows an example of system termination. In this example, the following servers are stopped when the system is stopped:

Host BESs

Guest BES that is running (Automatic stop 1 in the figure)

Additionally, the accepting status for the following servers is cancelled:

Guest BESs that are in accepting status (Automatic status change 1 in the figure)

Figure 25-62 System termination example

(b) Stopping a unit

Table 25-37 shows how a unit is stopped when the standby-less system switchover (effects distributed) facility is used.

Table 25-37 Stopping a unit when the standby-less system switchover (effects distributed) facility is used

Input location | Command | Option | Operation
-z | -u | -f
Unit where system manager is defined | pdstop | No | Yes | No | Stops the target unit normally.
Yes | Stops the target unit forcibly.
Target unit | pdstop | Yes | No | No | Stops the target unit forcibly.

To stop a unit, stop all host BESs and guest BESs at the unit (by executing pdstop -q -s server-name (-f) or its equivalent).

Table 25-38 shows whether a unit can be stopped normally depending on the status of servers in the unit. When the standby-less system switchover (effects distributed) facility is used, a unit can be stopped normally regardless of whether any of its servers, host BESs or guest BESs, have stopped abnormally by themselves or have been stopped forcibly.

Table 25-38 Whether a unit can be stopped normally depending on the status of servers in the unit

Server status (both BESs and guest BESs) | Can the unit be stopped normally?
Starting/stopping¹ | On standby² | Stopped³ | Standby-less system switchover (effects distributed) facility
No | No | No | Yes
Yes | Yes
Yes | No | Yes
Yes | Yes
Yes | No | No | No
Yes | No
Yes | No | No
Yes | No

¹ Includes starting normally, restarting, stopping normally, stopping according to plan, being stopped forcibly, or being stopped abnormally.

² Being blocked by mon_standby() or mon_connect().

³ Includes stopped normally, stopped according to plan, stopped forcibly, stopped abnormally, or guest area that has become unallocated after guest BES was stopped.

Table 25-39 shows the processing for the various back-end servers during unit termination when the standby-less system switchover (effects distributed) facility is used.

Table 25-39 Processing that occurs for the various back-end servers during unit termination when the standby-less system switchover (effects distributed) facility is used

Running location | Back-end server state | Processing
Unit being stopped | Running | Stops.
Accepting status | Cancels the accepting status.
Other unit | Running | No change.
Accepting status | Cancels the accepting status automatically.

Example 1: Stopping a unit during normal operation

Figure 25-63 shows an example of stopping a unit during normal operation.

Figure 25-63 Example of stopping a unit during normal operation

When a unit that has not accepted any guest BES is stopped, the following servers are also stopped:

Host BESs in the unit

In addition, the accepting status is cancelled for the following servers:

Guest BESs in the unit that are in accepting status (cancellation of accepting status)

Guest BESs in another unit that corresponds to the host BES in the unit being stopped (automatic cancellation of accepting status)

Example 2: Stopping a unit that has accepted a guest BES

Figure 25-64 shows an example of stopping a unit that has accepted a guest BES.

Figure 25-64 Example of stopping a unit that has accepted a guest BES

When a unit that has accepted a guest BES is stopped, the following servers are also stopped:

Host BES in the unit

Guest BES that is running in the unit (Automatic stop 1)

Host BES in another unit that corresponds to the guest BES that is running in the unit that is being stopped (Automatic stop 2)

In addition, the accepting status is cancelled for the following servers:

Guest BESs in the unit that are in accepting status (cancellation of the accepting status)

Guest BES in another unit that corresponds to the host BES in the unit being stopped (automatic cancellation of accepting status)

Guest BES in another unit that corresponds to the guest BES that is running in the unit being stopped (automatic cancellation of accepting status)

Example 3: Stopping a unit that has only a guest BES

Figure 25-65 shows an example of stopping a unit that has only a guest BES.

Figure 25-65 Example of stopping a unit that has only a guest BES

When a unit in which only a guest BES is running is stopped, the following servers are also stopped:

Host BES in the unit

Guest BES in the unit that is running (Automatic stop 1)

Host BES in another unit that corresponds to the guest BES that is running in the unit that is being stopped (Automatic stop 2)

In addition, the accepting status is cancelled for the following servers:

Guest BESs in the unit that are in accepting status (cancellation of accepting status)

Guest BES in another unit that corresponds to the guest BES that is running in the unit being stopped (automatic cancellation of accepting status)

(c) Stopping a server

Table 25-40 shows how a server is stopped when the standby-less system switchover (effects distributed) facility is used.

Table 25-40 Stopping a server when the standby-less system switchover (effects distributed) facility is used

Input location | Command | Option | Operation
-z | -u | -s | -f
Unit where system manager is defined | pdstop | No | No | Yes | No | Stops the target server²
Yes | Terminates forcibly the target servers in all active units in the HA group¹.
Yes | Yes | No | Stops the target server2, 3.
Yes | Stops the target server forcibly².
Target unit | pdstop | Yes | No | Yes | No | Stops the target server (host BES) forcibly⁴.

¹ Of all the active units in the HA group, servers in the running units only are stopped; the accepting status is cancelled for other units.

² If pdstop -s(f) is used to stop a running server, the accepting status is cancelled automatically for all active units in the HA group. For Hitachi HA Toolkit Extension, ndm and rdm jointly release the standby system (accepting status). For HA monitor, HiRDB and HA monitor both cancel the accepting status.

³ Table 25-41 shows the results of server termination depending on the server status.

⁴ For Hitachi HA Toolkit Extension, even when pdstop -z -s is used to stop the running server, the accepting status for the server is not cancelled automatically at other units in the HA group. To cancel the accepting status, enter Hitachi HA Toolkit Extension's standby stop command (hatesbystp) at all units in the HA group.

Table 25-41 Server termination results depending on the server status

Server status | Start result
Waiting for the running system to start | Cancels the wait for the running system to start.
Accepting status | Cancels the accepting status.
Active | Stops the server.

Table 25-42 shows the processing for the various back-end servers during server termination when the standby-less system switchover (effects distributed) facility is used.

Table 25-42 Processing that occurs for the various back-end servers during server termination when the standby-less system switchover (effects distributed) facility is used

Running location | Back-end server status | Processing
Active unit | Operation target | Stops
Other units | Accepting status | Cancels the accepting status.

Example 1: Stopping a host BES

Figure 25-66 shows an example of stopping a host BES.

Figure 25-66 Example of stopping a host BES

When a host BES is stopped, the following server is also stopped:

Host BES

In addition, the accepting status is cancelled for the following servers:

Guest BES in another unit that corresponds to the host BES in the unit being stopped (cancellation of accepting status)

Example 2: Stopping a guest BES

Figure 25-67 shows an example of stopping a guest BES.

Figure 25-67 Example of stopping a guest BES

When a guest BES is stopped, the following servers are also stopped:

Running guest BES

Host BES in another unit that corresponds to the running guest BES that is being stopped (automatic stop)

In addition, the accepting status is cancelled for the following servers:

Guest BES in another unit that corresponds to the running guest BES that is being stopped (cancellation of accepting status)

(4) Standby-less system switchover (effects distributed) facility (terminating only the standby system)

This section explains how to stop only the standby system.

As when using the standby system switchover facility or standby-less system switchover (1:1) facility, the monsbystp command of HA monitor can be used to stop the standby system. When the standby-less system switchover (effects distributed) facility is used, you can also perform the operation from the unit where the system manager is defined.

Table 25-43 shows how to terminate the standby system when the standby-less system switchover (effects distributed) facility is used.

Table 25-43 Terminating the standby system when the standby-less system switchover (effects distributed) facility is used

Input location | Command | Operation target | Operation
Host where the operation-target server is located | monsbystp* | Back-end server in accepting status | Cancels the accepting status for a guest BES
Unit where system manager is defined | pdstop -u -s

* When you use Hitachi HA Toolkit Extension, use the hatesbystp command.

Example 1: Example of cancelling the accepting status for a guest BES

Figure 25-68 shows an example of cancelling the accepting status for a guest BES.

Figure 25-68 Example of cancelling the accepting status for a guest BES

To cancel the accepting status for a guest BES, enter HA monitor's monsbystp command. When you use Hitachi HA Toolkit Extension, enter the hatesbystp command.

Example 2: Example of stopping a host BES of the standby system

Figure 25-69 shows an example of stopping a host BES of the standby system.

Figure 25-69 Example of stopping a host BES of the standby system

To stop a host BES of the standby system, enter HA monitor's monsbystp command. When you use Hitachi HA Toolkit Extension, enter the hatesbystp command.

25.13.4 Terminating HiRDB (in the monitor mode)

Table 25-44 lists the methods of terminating HiRDB (when in the monitor mode).

Table 25-44 Terminating HiRDB (in the monitor mode)

Condition
Termination method

Terminating both the running system and the standby system

Use the pdstop command to terminate the running system HiRDB.

Use a cluster software command (monend command in the case of HA monitor) to terminate both the running system and the standby system.

Terminating only the standby system
Use a cluster software command (monsbystp command in the case of HA monitor) to terminate the standby system.

Notes on using MC/ServiceGuard

If an MC/ServiceGuard command is used to terminate the package without using the pdstop command to terminate HiRDB, HiRDB will be terminated forcibly. Be sure to restart HiRDB the next time the package is started. Note that when HiRDB has been terminated forcibly, database integrity cannot be guaranteed. Therefore, when terminating the package, be sure to use the pdstop command to terminate HiRDB (normal termination or planned termination) before terminating the package.

Notes on using VERITAS Cluster Server

When it is not necessary to stop the system immediately, first use the pdstop command to terminate HiRDB normally. Then use a VERITAS Cluster Server command to terminate the system. Each resource will disconnect from its parent resource in order and VERITAS Cluster Server will stop. The execution results of the pdstop command in the offline script will show an error. This is not a problem because HiRDB has already terminated.

If a VERITAS Cluster Server command is used to terminate the system without first terminating HiRDB normally, the HiRDB termination mode will be force termination because the pdstop command in the offline script terminates HiRDB. When HiRDB has been terminated forcibly, database integrity cannot be guaranteed. Therefore, be sure to terminate HiRDB normally before using a VERITAS Cluster Server command.

Terminating HiRDB when using ClusterPerfect

Terminate the server (HiRDB) from the Resource 1 or Resource 2 window.

25.13.5 Monitoring statuses

Organization of this subsection

(1) Unit and server operating statuses

(2) Checking the system status

(3) Checking whether or not a command or utility can be executed

(1) Unit and server operating statuses

Table 25-45 shows how to check the operating status of units and servers when a system switchover facility is used.

Table 25-45 Checking the operating status of units and servers when a system switchover facility is used

Command
System switchover facility
Output information

pdls -d svr
Standby system switchover facility

Host name (the primary system host name is displayed after system switchover)

Unit operating status

Server operating status

Standby-less system switchover (1:1) facility

Host name (the primary system host name (host name of the normal BES) is displayed after system switchover)

Unit operating status (the unit identifier of the normal BES is displayed after system switchover)

Server operating status

Standby-less system switchover (effects distributed) facility

Host name (the host name of the accepting unit is displayed after system switchover)

Unit operating status (the unit identifier of the accepting unit is displayed after system switchover)

Server operating status (displayed as a server belonging to the accepting unit after system switchover)

(2) Checking the system status

Table 25-46 shows how to check the system status when a system switchover facility is used.

Table 25-46 Checking the system status when a system switchover facility is used

Command
System switchover facility
Output information

pdls -d ha
Standby system switchover facility

Host name and system status of the primary system (running/standby/stopped)

Host name and system status of the standby system (running/standby/stopped)

This command can check the host name and status of the standby system only when IP addresses are not inherited.¹

Standby-less system switchover (1:1) facility

Host name and status of the normal BES unit (running/standby/stopped)

Host name and status of the alternate BES unit (running/standby/stopped)

Standby-less system switchover (effects distributed) facility

Name and status of the unit where the back-end server is located (running/standby/stopped/running system in wait status) and defined destination unit name
Detailed status of the back-end server is displayed only when the detailed display option (-a) is specified.

monshow (only when HA monitor is used)
Standby system switchover facility

Local system's host name and status²

Other system's host name and status³

Standby-less system switchover (1:1) facility

Standby-less system switchover (effects distributed) facility

hateshow (only when Hitachi HA Toolkit Extension is used)
Standby system switchover facility

Status of the local system⁴

Standby-less system switchover (1:1) facility

Standby-less system switchover (effects distributed) facility

¹ When IP addresses are inherited, use a command of the cluster software to check the system status. For details about the information displayed, see the documentation for the cluster software.

² Statuses are displayed for the following categories:

Executing, on standby, starting as a running server, starting as a standby server, stopped as the running server, stopped as a standby server, waiting for restart as the running server, waiting for restart as a standby server, waiting for server system switchover, waiting for linked server system switchover

³ Statuses are displayed for the following categories:

Executing, on standby, starting as a running server, starting as a standby server, stopped as the running server, stopped as a standby server, waiting for restart as the running server

⁴ Statuses are displayed for the following categories:

Startup completed for the running server, startup completed for a standby server, running server starting, a standby server starting, the running server being stopped, a standby server being stopped, the running server waiting to be restarted, server not yet started

(3) Checking whether or not a command or utility can be executed

Execute the pdls -d svr command on the system manager unit of the primary system.

When the termination status of the pdls -d svr command executed on the primary system is 0:
Because the primary system is the running system, execute the command or utility on the primary system.

When the termination status of the pdls -d svr command executed on the primary system is 8 or when the pdls -d svr command cannot be executed (for example, remote shell cannot be executed and logon is not possible):
The secondary system may be the running system. Execute the pdls -d svr command on the system manager unit of the secondary system to check whether or not the secondary system is the running system.

When the termination status of the pdls -d svr command executed on the primary system or secondary system is 4:
Some units may be stopped or HiRDB is being started or terminated.
If units are stopped, start them. If units are stopped because of an error, check the message that was output to the event log, correct the error, and then start the stopped units.
If HiRDB is being started or terminated, execute the pdls -d svr command repeatedly at intervals of approximately 5 seconds until the termination status is no longer 4. Execute the pdls -d svr command repeatedly based on the time specified in the pd_system_complete_wait_time operand as a guideline.

25.13.6 Handling of statistics log files

When the standby system switchover facility is used, the statistics log files consist of the two files pdstj1 and pdstj2. These files are created automatically for both the primary system and the secondary system, so the HiRDB administrator must prepare a total of four files. Statistics log files cannot be shared between the primary system and the secondary system.

When the standby-less system switchover (1:1) facility or the standby-less system switchover (effects distributed) facility is used, the statistics log files consist of the two files pdstj1 and pdstj2. These files are created as a set for the primary HiRDB system. Because the accepting unit's statistics log files are shared at the switching destination, no files are created for the secondary system. The HiRDB administrator must prepare files for the regular unit and for the accepting unit.

Organization of this subsection

(1) Creating unload statistics log files

(2) Process for collecting statistical information after a system switchover

(3) Executing the statistics analysis utility

(1) Creating unload statistics log files

(a) When using the standby system switchover facility

Because statistics log files are distributed to each server machine when system switchover occurs, create unload statistics log files on a specific server machine. Hitachi recommends creating unload statistics log files in the following cases:

When HiRDB starts

When statistics log files are swapped

When system switchover occurs

Figure 25-70 shows examples of unload statistics log files created when a system switchover facility is used.

Figure 25-70 Examples of unload statistics log files created when a system switchover facility is used (Part 1)

Hint

Each server machine has a statistics log file with the same name. Be sure to create your unload statistics log file with a different name. Even when using the shell script provided by HiRDB (pdstjacm), modify the shell script so each unload statistics log file has a different name.

(b) Standby-less system switchover (1:1) facility or standby-less system switchover (effects distributed) facility

When system switchover occurs, the statistics log files to be used by the switching-destination host are the files being used by the accepting unit at the switching destination. Because statistics log output destination files are distributed to each host, unload statistics log files must be created on a specific server machine.

You should create unload statistics log files at the following times:

When statistics log files are swapped

When system switchover occurs

Figure 25-71 shows examples of unload statistics log files created when a system switchover facility is used.

Figure 25-71 Examples of unload statistics log files created when a system switchover facility is used (Part 2)

Hint

Because statistics log files have identical names on all server machines, do not use the same names when you create the unload statistics log files. Also, when using a shell script (pdstjacm) provided by HiRDB, change the shell script so that the same name is not used.

When system switchover occurs, statistics log files are handled by the switching-destination host.

(2) Process for collecting statistical information after a system switchover

(a) Standby system switchover facility

After system switchover occurs, the following operands specify whether or not statistical information is to be collected by the HiRDB on the switchover destination system:

pd_statistics

pdstbegin

If Y is specified in the pd_statistics operand or the pdstbegin operand is specified, statistical information is collected immediately after system switchover occurs.

If system switchover occurs when the pdstbegin command is being used to start collecting statistical information, HiRDB on the switchover destination system cannot collect statistical information. To collect statistical information in this situation, you must use HiRDB on the switchover destination system to execute the pdstbegin command.

Also, HiRDB on the switchover destination system determines whether the pdstj1 or the pdstj2 statistics log file will be used. The procedure for determining which statistics log file will be used is the same as when the system switchover facility is not used.

(b) Standby-less system switchover (1:1) facility

The process for collecting statistical information when in alternating status is explained below. The collection status of statistical information on the alternate BES unit determines whether or not collection of statistical information is necessary on a normal BES unit in alternating status. The same types of statistical information are collected on the normal BES unit and on the alternate BES unit. Figure 25-72 shows the process of collecting statistical information in the alternating status.

Figure 25-72 Process of collecting statistical information in alternating status

Explanation

The process of collecting statistical information for BES1 and BES2 when in alternating status is explained below:

BES1: Collects the same buf and dfw as the alternate BES unit (BES3).

BES2: Collects the same sys as the alternate BES unit (BES4).

The process for BES3 and BES4 is the same.

In addition to the statistical information for BES3 and BES4, the statistical information for BES1 and BES2 is output to the statistics log file in the alternate BES unit (UNT2).

Remarks

The collection status of statistical information for a normal BES unit and an alternate BES unit in alternating status and the types of statistical information collected are the same. Figure 25-73 is used as an example in the following explanations.

When the pdstend command stops collection of statistical information for BES3, the statistical information for BES1 can no longer be collected. Similarly, when the pdstend command stops collection of statistical information for BES1, the statistical information for BES3 can no longer be collected.

When the pdstbegin or pdstend command changes the types of statistical information collected for BES3, the types of statistical information for BES1 are also changed. Similarly, when the pdstbegin or pdstend command changes the types of statistical information collected for BES3, the types of collected information acquired for BES3 are also changed.

When switching a system back

When switching a system back (returning from alternating status to normal status), the operands listed below specify whether or not statistical information of the normal BES unit is to be collected and the types of statistical information to collect:

pd_statistics

pdstbegin

Therefore, you must execute the pdstbegin command again when changing whether or not to acquire statistical information or when changing the types of information to be collected.

(c) Standby-less system switchover (effects distributed) facility

When system switchover occurs, the statistics log collection status that existed immediately before system switchover is inherited. That is, if statistics logs were being collected before the system switchover, statistics logs will continue to be collected at the switched server after system switchover, regardless of the value specified in the pd_statistics operand of the system common definition. In this case, the statistics log files are shared with the accepting unit at the switching destination. If statistics logs were not being collected immediately before system switchover, no statistics logs will be collected after system switchover; you can begin collecting statistics logs by entering the pdstbegin command after switchover.

Table 25-47 shows when statistics logs are collected when the standby-less system switchover (effects distributed) facility is used.

Table 25-47 Statistics log collection when the standby-less system switchover (effects distributed) facility is used

Unit type | Being collected | Accepting unit
Regular unit | Was being collected. | Collects.
Was not being collected. | Does not collect.

Figure 25-73 shows an example of statistics log collection after system switchover when the standby-less system switchover (effects distributed) facility is used.

Figure 25-73 Example of statistics log collection after system switchover when the standby-less system switchover (effects distributed) facility is used

(3) Executing the statistics analysis utility

(a) Standby system switchover facility

The statistics analysis utility is executed using the created unload statistics log files as the input information. If system switchover occurs due to an error, the statistics log information immediately prior to system switchover is not acquired correctly in the file. For this reason, the execution results of the statistics analysis utility may not be accurate when used for tuning, etc.

(b) Standby-less system switchover (1:1) facility or standby-less system switchover (effects distributed) facility

The statistics analysis utility is executed using the unload statistics log files created at the regular unit and the accepting unit as the input information. To manually copy the files that existed prior to system switchover you must use, for example, an OS command. The statistics information on the server that has been switched is processed as information on a server belonging to the accepting unit.

If system switchover occurs because of an error, the statistics log information immediately prior to system switchover is not acquired correctly in the file. For this reason, the execution results of the statistics analysis utility may not be accurate when used for tuning, etc.

25.13.7 Notes on operations

Organization of this subsection

(1) Limitations on execution of operation commands

(2) Limitations on execution of operation commands when using the standby-less system switchover (effects distributed) facility

(3) Changing a HiRDB system definition or the HiRDB configuration

(4) When HiRDB files created on a shared disk cannot be accessed

(5) Notes on executing the pdsetup command (applicable to the server mode only)

(6) Note on using Hitachi HA Toolkit Extension

(7) Notes on using HA monitor

(1) Limitations on execution of operation commands

To execute an operation command during HiRDB termination processing, the HiRDBs on both systems must be engaged in termination processing (however, this requirement does not apply to the pdstart command).

While HiRDB is running, no operation commands can be executed by the HiRDB on the standby system.

(2) Limitations on execution of operation commands when using the standby-less system switchover (effects distributed) facility

When the situation described below occurs in an environment in which a global buffer for OTHER is defined, you must not attempt to terminate the unit alone by executing the pdstop -u command from the unit where the system manager is defined. First, either execute the pdstop command from the unit where the system manager is defined to terminate HiRDB or use the system reconfiguration command (pdchgconf command) to allocate a global buffer to the RDAREA to be added, and then terminate the unit. For details about global buffers for OTHER, see 25.5.8 Definition of global buffers (standby-less system switchover (effects distributed) facility only).

In a unit to which the standby-less system switchover (effects distributed) facility is applicable, the globalbuffer operand was omitted from the create rdarea statement of the database structure modification utility (pdmod) and an RDAREA with a page size larger than the size of the global buffer for OTHER has been added.

(3) Changing a HiRDB system definition or the HiRDB configuration

If you change a HiRDB system definition or the HiRDB configuration, do not use a cluster software command to terminate HiRDB. Instead, use the pdstop command to terminate HiRDB only normally, then change the HiRDB system definition or reconfigure HiRDB. When you are done, you can use the pdstart command to start HiRDB only.

(4) When HiRDB files created on a shared disk cannot be accessed

If HiRDB is stopped by the cluster software, it may not be possible to manipulate HiRDB files on the shared disk from either system. In this case, you must use an OS command to activate the shared disk.

(5) Notes on executing the pdsetup command (applicable to the server mode only)

You must be careful about executing the pdsetup -d command while terminating HiRDB forcibly or abnormally. Do not enter Y at the command's prompt; if you do enter Y, it may become impossible to start HiRDB subsequently.

(6) Note on using Hitachi HA Toolkit Extension

When using Hitachi HA Toolkit Extension, the standby system unit will not wait for the running system unit to start. If a command is issued to the running system unit before the standby system unit has started, an error may occur and the standby system unit may abort (Phi1012). Therefore, wait for startup of the running system unit to finish before starting the standby system unit. If the standby system unit is started without waiting for startup of the running system to finish, the standby system unit may abort (Phi1012).

(7) Notes on using HA monitor

The following points about using HA monitor should be noted:

During startup of a server,¹ if all systems, including the primary system (system for which online is specified in the init operand of HA monitor's servers definition), wait for the running system server to start,² start the primary system³ as the running system by executing HA monitor's monact command.

If a server is being activated in a unit to which the standby-less system switchover (effects distributed) facility is applicable, do not terminate that unit forcibly. If it is terminated forcibly, the next time a server is started on the primary system, this server may wait for the running system server to start.² In this case, start the primary system³ as the running system by executing HA monitor's monact command.

¹ For a unit to which the standby-less system switchover (1:1) facility is applicable, replace server with unit when you read this sentence.

² Status in which *SBY* is displayed when the HA monitor's monshow command is executed.

³ If the secondary system (system for which standby is specified in the init operand of HA monitor's servers definition) server is started by the monact command as the running system, the messages listed below may be output repeatedly on the primary system until startup of the running system is completed. These messages cease to be output once startup of the running system is completed.

KFPS05608-I

KAMN305-E

KAMN222-I

The KAMN305-E and KAMN222-I messages are output by HA monitor.

25.13.8 Notes on using the standby-less system switchover facility

Organization of this subsection

(1) Operations requiring a restart of the alternate BES unit or alternate portion (standby-less system switchover (1:1) facility only)

(2) RDAREA opening trigger attributes

(1) Operations requiring a restart of the alternate BES unit or alternate portion (standby-less system switchover (1:1) facility only)

When any of the operations listed below occurs, you must restart the alternate portion. If you do not restart the alternate portion, it will terminate abnormally when system switchover occurs. You must also restart the alternate BES unit after operation 1 or 3 below occurs.

The database structure modification utility (pdmod command) was executed.

A process is performed that updates the master directory RDAREA (for example, executing the database structure modification utility, executing a definition SQL, or executing the pddbchg command), and then the server (front-end server, dictionary server, or back-end server) is independently terminated normally and then started normally.

The pdbuffer operand is modified, and then the server is independently terminated normally and then started up normally.

The pd_max_rdarea_no, pd_max_file_no, pd_inner_replica_control, or pd_index_assurance_no operand is modified, and then the server is independently terminated normally and then started normally.

A foreign server or user mapping is defined, and then the server is independently terminated normally and then started normally.

If the alternate portion terminates abnormally, use the pdstart -q -c command to start it.

When performing the operations listed above, terminate the normal BES unit then restart it. If you do not restart the normal BES unit, it will terminate abnormally when system switchover (or system switchback) occurs. If the normal BES unit terminates abnormally, use the pdstart -q command or pdstart -u command to start the normal BES unit.

(2) RDAREA opening trigger attributes

(a) Standby-less system switchover (1:1) facility

To minimize the time required for system switchover, the standby-less system switchover (1:1) facility opens only the RDAREAs needed for full recovery when system switchover occurs; it does not open other RDAREAs. The RDAREA opening trigger attributes in the normal BES unit are listed below:

When system switchover occurs, the system can be reactivated only after all processes in the alternate portion have terminated; therefore, the RDAREA opening trigger attribute of the alternate portion is the SCHEDULE attribute.

After recovering from an error and switching the system back to the normal BES unit, the RDAREA opening trigger attribute of the INITIAL or DEFER attribute on the normal BES unit is the DEFER attribute. RDAREAs with the SCHEDULE attribute remain unchanged.

For details about RDAREA opening trigger attributes, see 15.5 Modifying an RDAREA opening trigger attribute (RDAREA modification).

(b) Standby-less system switchover (effects distributed) facility

To minimize the time required for system switchover, the standby-less system switchover (effects distributed) facility opens only the RDAREAs needed for full recovery when system switchover occurs; it does not open other RDAREAs. The RDAREA opening trigger attributes are listed below:

Even if N is specified in the pd_rdarea_open_attribute_use operand, Y is assumed.

When system switchover occurs, even if the RDAREA opening trigger attribute is INITIAL, DEFER is assumed.

For the RDAREA opening trigger attributes when you use the standby-less system switchover (effects distributed) facility, see the explanations for the pd_rdarea_open_attribute_use and pd_rdarea_open_attribute operands in the manual HiRDB Version 8 System Definition.

25.14 Planned system switchover

This section explains the procedures for performing planned system switchover.

Organization of this section

(1) Standby system switchover facility

(2) Standby-less system switchover (1:1) facility

(3) Standby-less system switchover (effects distributed) facility

(1) Standby system switchover facility

To perform a planned system switchover:

Server mode

Use the pdstop command to terminate the running system HiRDB (unit or server). Perform this step only when a product other than HA monitor is used in the cluster software.
Also, if you specify the pdstop command in the termcommand operand of Hitachi HA Toolkit Extension, you do not have to execute the pdstop command at this time, because Hitachi HA Toolkit Extension executes it as an extension of the command in step 2.

Use a cluster software command (monswap command in the case of HA monitor) to perform a planned system switchover. For details about planned system switchovers, see the documentation for the cluster software product.

The HiRDB (or unit) that became the standby system must be placed in waiting status. Execute the pdstart command (pdstart -q command in the case of a HiRDB/Parallel Server) on the standby system HiRDB.

Monitor mode

Use the pdstop command to terminate the running system HiRDB (or unit).

Use a cluster software command (monswap command in the case of HA monitor) to perform a planned system switchover. For details about planned system switchovers, see the documentation for the cluster software product.

When the cluster software product used is HA monitor and you specify HiRDB termination in the shell you start with the termcommand operand in the server definition statement, you can perform a planned system switchover by simply executing the monswap command. For examples of shell creation, see 25.6.2(4) termcommand operand (applicable to the monitor mode only).

To perform a system switchover manually when the cluster software product used is ClusterPerfect, stop the running system then start the standby system. When system switchover occurs, the color of ClusterPerfect's ClusterPerfect system information window changes.

(2) Standby-less system switchover (1:1) facility

When performing a planned system switchover to the alternate BES unit, the alternate portion must be in waiting status. When switching the system back to the normal BES unit, the normal BES unit must be in waiting status. The procedure for performing a planned system switchover is explained below:

Procedure: Switching the system to the alternate BES unit

Use the pdstop -z command to terminate the normal BES unit. Perform this step only when a product other than HA monitor is used in the cluster software.
Also, when specifying the pdstop command in the termcommand operand of Hitachi HA Toolkit Extension, you do not have to execute the pdstop command at this point, because Hitachi HA Toolkit Extension executes the pdstop command as an extension of the command in step 2.

Use a cluster software command (monswap command in the case of HA monitor) to perform a planned system switchover. For details about planned system switchovers, see the documentation for the cluster software product.

When you use the above procedure to perform a planned system switchover, the alternate BES unit performs normal BES unit processing. The normal BES unit becomes inactive. To switch the system back to the normal BES unit, use the following procedure to perform a planned system switchover again:

Procedure: Switching system back to the normal BES unit

Use the pdstart -q command to place the normal BES unit in waiting status.

Use a cluster software command (the monswap command in the case of HA Monitor) to perform a planned system switchover. The waiting status of the alternate portion is released.

Use the pdstart -q command to place the alternate portion in waiting status.

(3) Standby-less system switchover (effects distributed) facility

For a planned system switchover, execute HA monitor's monswap command.

When this command executes, the back-end server at the switching-source unit is placed automatically on standby status.

If you are using Hitachi HA Toolkit Extension, enter the cluster software's planned system switchover command instead of the monswap command.

Table 25-48 shows the planned system switchover operation when you use the standby-less system switchover (effects distributed) facility.

Table 25-48 Planned system switchover operation when the standby-less system switchover (effects distributed) facility is used

Back-end server type | Operation | Move destination
Host BES | Moves to the switching destination with the highest priority; if there is no free space in the guest area, moves to the switching destination with the next highest priority. | Guest BES
Guest BES | Host BES

(a) Planned system switchover for a host BES

Figure 25-74 shows an example of planned system switchover for a host BES. In this example, a server machine (hostA) must be stopped for hardware maintenance of the host.

Figure 25-74 Example of planned system switchover for a host BES

In this example, planned system switchover is executed for the current BES on unt1. The procedure is as follows:

In hostA, the monswap command is entered for BES1 and BES1 is switched to hostB.

In hostA, the monswap command is entered for BES2 and BES2 is switched to hostC.

If you are using Hitachi HA Toolkit Extension, enter the cluster software's planned system switchover command.

(b) Planned system switchover for guest BESs (system reactivation)

Figure 25-75 shows an example of planned system switchover for guest BESs (system reactivation). In this example, a unit recovers from an error.

Figure 25-75 Example of planned system switchover for guest BESs (system reactivation)

In this example, BES5 and BES6, which had moved from unt3, are reactivated through planned system switchover. The procedure is as follows:

In hostA, the monswap command is entered for BES5 and BES5 is switched to hostC.

In hostB, the monswap command is entered for BES6 and BES6 is switched to hostC.

If you are using Hitachi HA Toolkit Extension, enter the cluster software's planned system switchover command.

25.15 Grouped system switchover

This section describes the methods of performing grouped system switchover when using HA monitor in the cluster software. To perform grouped system switchover while using cluster software other than HA monitor, see the documentation for the cluster software product.

Organization of this section

(1) Server mode

(2) Monitor mode

(3) Grouped system switchover with HiRDB Datareplicator

(4) Relationship to planned system switchover

(1) Server mode

The following explanation assumes use of grouped system switchover with HiRDB and OpenTP1.

To perform grouped system switchover, you must use the group operand of HA monitor to define grouped system switchover. The following explanation assumes that exchange is specified in the group operand. For details about defining grouped system switchover. Table 25-49 lists the system processing when performing grouped system switchover (in the server mode).

Table 25-49 System processing when performing grouped system switchover (in the server mode)

Error description | System processing
An error occurred that prevents hardware from restarting, or an error occurred when restarting the operating system or HA monitor (a system failure occurred). | Performs system switchover. Also switches over OpenTP1 and HiRDB.
An error occurred in OpenTP1 and OpenTP1 terminated abnormally. | switchtype=restart | Restarts OpenTP1 on the running system. Performs system switchover if OpenTP1 cannot be restarted. When system switchover is performed on OpenTP1, grouped system switchover is also performed on HiRDB.
switchtype=switch | Performs system switchover. When system switchover is performed on OpenTP1, grouped system switchover is also performed on HiRDB.
switchtype=manual | Performs system switchover. Restarts OpenTP1 on the running system.
An error occurred in HiRDB and HiRDB terminated abnormally. | switchtype=restart | Restarts HiRDB on the running system. Switches systems if HiRDB cannot be restarted. When system switchover is performed on HiRDB, grouped system switchover is also performed on OpenTP1.
switchtype=switch | Performs system switchover. When system switchover is performed on HiRDB, grouped system switchover is also performed on OpenTP1.
switchtype=manual | Does not perform system switchover. Restarts HiRDB on the running system.

(2) Monitor mode

The following explanation assumes the use of grouped system switchover with HiRDB and OpenTP1.

To perform grouped system switchover, you must use the group operand and termcommand operand of HA monitor to define grouped system switchover. The following explanation assumes that exchange is specified in the group operand. For details about defining grouped system switchover, see the manual. Table 25-50 lists the system processing when performing grouped system switchover (in the monitor mode).

Table 25-50 System processing when performing grouped system switchover (in the monitor mode)

Error description | System processing
An error occurred that prevents hardware from restarting, or an error occurred when restarting the operating system or HA monitor (a system failure occurred). | Performs system switchover. Also performs switchover for OpenTP1 and HiRDB.
An error occurred in OpenTP1 and OpenTP1 terminated abnormally. | Performs system switchover. When system switchover is performed on OpenTP1, grouped system switchover is also performed on HiRDB.
An error occurred in HiRDB and HiRDB terminated abnormally. | Does not perform system switchover. Restarts HiRDB on the running system.

(3) Grouped system switchover with HiRDB Datareplicator

When you use HiRDB Datareplicator, you must perform grouped system switchover with both HiRDB and HiRDB Datareplicator. In such a case, use the group operand of HA monitor to define HiRDB and HiRDB Datareplicator in the same server group. For details about defining grouped system switchover. For details about performing system switchover when using HiRDB Datareplicator, see the manual HiRDB Datareplicator Version 8 Description, User's Guide and Operator's Guide.

Conditions

Perform grouped system switchover with HiRDB Datareplicator in the monitor mode.

You must describe in the termcommand operand of HA monitor a command or shell that terminates HiRDB Datareplicator forcibly.

Automatic system switchover

When an error occurs on the running system, the system switches automatically to the standby system. No action needs to be taken by the HiRDB administrator or HiRDB Datareplicator administrator.

Planned system switchover

You can use the HA monitor's monswap command to perform a planned system switchover on HiRDB and HiRDB Datareplicator.

When HiRDB system is switched over

When an error occurs and the HiRDB system is switched over, terminate the running system HiRDB Datareplicator forcibly and switch the HiRDB Datareplicator system.

When an error occurs in HiRDB Datareplicator

When HiRDB Datareplicator independently terminates abnormally, system switchover is not performed because HiRDB Datareplicator is restarted on the running system. When HiRDB Datareplicator is independently terminated abnormally, grouped system switchover cannot be performed on HiRDB and HiRDB Datareplicator.

(4) Relationship to planned system switchover

If you define grouped system switchover in advance, you can use the planned system switchover functionality of HA monitor's monswap command to perform grouped system switchovers.

25.16 Actions to be taken by the HiRDB administrator when errors occur

Organization of this section

(1) System processing and actions taken by the HiRDB administrator when errors occur

(2) Notes on using VERITAS Cluster Server

(3) When the standby-less system switchover (1:1) facility is used

(4) When the standby-less system switchover (effects distributed) facility is used

(1) System processing and actions taken by the HiRDB administrator when errors occur

Table 25-51 lists the system processing and the actions to be taken by the HiRDB administrator when errors occur.

Table 25-51 System processing and the HiRDB administrator's actions in the event of an error (using the system switchover facility)

Error
System processing
HiRDB administrator's action

A server failure occurred (only HiRDB terminated abnormally).
Server mode
As specified in the switchtype operand¹ of HA monitor or Hitachi HA Toolkit Extension.
Check the cause of the error on the basis of the output message. Refer to 18. Error Handling Procedures,and take appropriate action.

Monitor mode
Does not perform system switchover. Restarts HiRDB on the system resulting in the error.

A system failure occurred.
Performs system switchover and restarts HiRDB on the switchover destination system. However, depending on the type of system failure, system switchover may not be performed. A cluster software specification determines whether or not system switchover will be performed; for details, see the cluster software documentation.
Check the cause of the error on the basis of the output message. Refer to 18. Error Handling Procedures or the applicable manual, and take appropriate action.

HiRDB restart failed
Server mode
As specified in the switchtype operand¹ of HA monitor or Hitachi HA Toolkit Extension.

Monitor mode
As specified in the pd_ha_restart_failure operand.²

System switchover failed
Terminates the system.

Note

The information inherited after system switchover is the same as when HiRDB is restarted. For details on the information that is inherited after a HiRDB restart, see 18.1.5 Information inherited during a HiRDB restart.

¹ Processing depends on the specification of the switchtype operand. For details about HA monitor's switchtype operand, see 25.6 HA monitor preparations; for details about the switchtype operand of Hitachi HA Toolkit Extension, see 25.12 Hitachi HA Toolkit Extension preparations (server mode only).

² If you register a command for switching the cluster software system in this operand, the system will be switched over automatically when restart processing fails. The system stops operating if this operand is omitted. In such a case, you must enter a command for switching the cluster software system and then perform system switchover.

(2) Notes on using VERITAS Cluster Server

(a) Actions to take when system switchover occurs

When system switchover occurs, VERITAS Cluster Server takes all resources on the running system offline, starting with the parent resource, and then places the resources on the standby system online starting with the child resources. If an unexpected system switchover occurs, take the following actions as necessary to return the running system to its original server machine:

When a process on the running system server machine cannot be continued
Investigate the reason the server machine process cannot continue and eliminate the error. Activate VERITAS Cluster Server.

When an error occurs in a resource
Investigate the cause of the resource error and eliminate the error. Use a VERITAS Cluster Server command to release the resource's error status.

(b) Actions to take when HiRDB terminates abnormally

When HiRDB terminates abnormally, restart HiRDB on the running system. Also, when a dummy file for a HiRDB_x type resource is deleted, the resource is placed in error status and HiRDB terminates forcibly. Actions to take are described below:

Procedure

Use a VERITAS Cluster Server command to release the error status of the resource.

Use a VERITAS Cluster Server command to bring the resource online; HiRDB restarts.

(3) When the standby-less system switchover (1:1) facility is used

After resolving the error, use a planned system switchover to switch the system back to the normal BES unit (return to normal status from alternating status). For details about planned system switchover, see 25.14(2) Standby-less system switchover (1:1) facility.

(4) When the standby-less system switchover (effects distributed) facility is used

After resolving the error, use a the planned system switchover to switch the system back to the regular unit (return to normal status from standby status). For details about planned system switchover, see 25.14(3) Standby-less system switchover (effects distributed) facility.

25.17 Operating procedures after system switchover

When inheriting IP addresses, no action is required after system switchover, because the primary system and the secondary system have the same host name. When not inheriting IP addresses, you must perform the following procedures, because the primary system and the secondary system have different host names.

The following operations are also required when you use the standby-less system switchover (1:1) facility. Note that IP addresses are not inherited when the standby-less system switchover (effects distributed) facility is used. Because the switching destination differs for each server, the host name of the switching destination is used after system switchover; this is why the operations described below are required.

Organization of this section

(1) Operation commands and utilities

(2) Messages

(3) Acquisition of statistical information

(4) Client environment definition (applicable to the standby system switchover facility only)

(1) Operation commands and utilities

(a) Standby system switchover facility or standby-less system switchover (1:1) facility

Even after a system switchover, there is no need to change the host name or unit identifier specified in an operation command or utility. The -x option of the pdunit operand specifies the host name, which is the host name of the primary system (or normal BES unit).

Specify a unit identifier as often as possible, and you will not have to be concerned with host names.

For a HiRDB/Single Server, Hitachi recommends omitting host names to avoid problems that may occur during operation. Only specify host names when manipulating a utility special unit.

The host name of the primary system is displayed in the processing results of operation commands. For the standby-less system switchover (1:1) facility, the host name of the alternate BES unit is displayed.

(b) Standby system switchover facility or standby-less system switchover (1:1) facility

If system switchover occurs while a server is active, each server defined in the erroneous unit must be operated as a server belonging to the accepting unit. Because the switching destination differs for each server, servers cannot be operated grouped as a regular unit after system switchover occurs.

For this reason, you must specify the values shown in Table 25-52 when you issue operation commands.

Table 25-52 Specification values for operation commands when the standby-less system switchover (effects distributed) facility is used

Type of command | Specification value
Before switching | After switching
Host name specification command | Host name of the regular unit | Host name specification command
Unit identifier specification command | Unit identifier of the regular unit | Unit identifier specification command
Server name specification command | Operation target server name | Server name specification command

In operations in which a host name or unit identifier is specified, the processing target differs before and after system switchover. Therefore, when the standby-less system switchover (effects distributed) facility is used, it is advisable to use operations that provide for server name specification.

When a host name is displayed in the processing results of an operation command, it is the host name of the accepting unit that is displayed.

Table 25-53 shows the standby-less system switchover (effects distributed) facility the execution targets when operation command options are specified. Be aware that the execution targets of the pdstart and pdstop commands are different from those shown in the table; for details about the pdstart and pdstop commands, see 25.13 Differences in the HiRDB operating procedures.

Table 25-53 Execution targets when operation command options are specified (for the standby-less system switchover (effects distributed) facility)

Option | Condition | Command operation mode* | Command's execution target
-u | -s | Unit where system manager is defined | Target server
No | No |  |  |  | System (or all running back-end servers in the system)
Yes | Offline |  | Offline | Specified server that is a back-end server of the primary system in the regular unit
Online | Offline | Offline | Specified server that is a back-end server of the primary system in the regular unit
Online | Online | Specified server that is a running back-end server of the running unit
Yes | No |  |  |  | Specified unit (or all running back-end servers in the specified unit)
Host | Offline |  | Offline | Specified unit that is a host BES in the specified regular unit
Online | Offline | Offline | Specified unit that is a host BES in the specified regular unit
Online | Online | Specified server that is a running BES in the running unit (-u specification is ignored)
Guest | Offline |  | Offline | Specified server that is a guest BES in the specified accepting unit
Online | Offline | Offline | Specified server that is a guest BES in the specified accepting unit
Online | Online | Specified server that is a running back-end server in the running unit (-u specification is ignored)

Legend:

: Not applicable

* Mode for determining the running system when entering a subcommand on a unit where the system manager is not defined.

(2) Messages

For the standby system switchover facility, the primary system's host name is displayed in messages.

For the standby-less system switchover (1:1) facility, the host name or unit identifier of the normal BES unit is displayed in messages for normal BES unit processing.

For the standby-less system switchover (effects distributed) facility, the host name of the accepting unit is displayed in messages.

(3) Acquisition of statistical information

For details about collecting statistical information after system switchover, see 25.13.6 (2) Process for collecting statistical information after a system switchover.

(4) Client environment definition (applicable to the standby system switchover facility only)

(a) HiRDB/Single Server

When only the host name of the primary system is specified in the PDHOST operand, you must perform the following procedure. This procedure is not necessary when the host names of the primary system and secondary system are both specified in the PDHOST operand.

Because the host name of the HiRDB to be connected is specified in the PDHOST operand, you must specify in the PDHOST operand after system switchover the host name of the running system. Therefore, after system switchover, the HiRDB administrator must notify all client users that the host name of HiRDB has changed. Client users must change the host name specified in the PDHOST operand to this new host name, then re-execute UAPs. Note that you will not be able to execute UAPs if you do not first change the host name specified in the PDHOST operand. For details about the PDHOST operand, see the manual HiRDB Version 8 UAP Development Guide.

(b) HiRDB/Parallel Server

When only the host name of the primary system is specified in the operands listed below, you must perform the following procedure. This procedure is not necessary when the host names of the primary system and secondary system are both specified in these operands.

PDHOST

PDFESHOST (applicable when multiple front-end servers are being used)

Because the host name of the HiRDB to be connected is specified in one of these operands, the host name of the running system must be specified after system switchover in the applicable one of these operands. (the host name of the system manager is specified in the PDHOST operand and the host name of a front-end server is specified in the PDFESHOST operand). Therefore, after system switchover, the HiRDB administrator must notify all client users that the host name of HiRDB has changed. Client users must change the host name specified in the applicable operand to this new host name, then re-execute UAPs. Note that you will not be able to execute UAPs if you do not first change the host name specified in the applicable operand. For details about the PDHOST operand and the PDFESHOST operand, see the manual HiRDB Version 8 UAP Development Guide.

Remarks

The host name specified in the PDHOST operand needs to be changed only when system switchover occurs on the system manager unit.

The host name specified in the PDFESHOST operand needs to be changed when only system switchover occurs on a front-end server unit.

There is no need to change the PDHOST or PDFESHOST operand specification when system switchover occurs for a unit where no system manager or front-end server is defined.

25.18 Reducing system switchover time (user server hot standby, rapid system switchover facility)

The following functions reduce the amount of time used to perform system switchover; the system switchover facility must be operating in the server mode to use these functions:

User server hot standby

Rapid system switchover facility

Organization of this section

25.18.1 User server hot standby

25.18.2 Rapid system switchover facility

25.18.3 System configuration examples when using the rapid system switchover facility

25.18.4 Checking procedure when activation of standby system takes much time

25.18.5 Notes on using the rapid system switchover facility

25.18.1 User server hot standby

When system switchover occurs, the following processes are performed to start HiRDB on the standby system.

System server activation process

System file inherit process

Server process activation process

Rollforward process

The time required for activating these server processes accounts for a large part of the system switchover time. Because the time required for activating a server process is proportional to the number of resident server processes, the system switchover time increases as the number of resident processes increases. Therefore, server processes of the standby system HiRDB can be activated in advance so that no time is required during switchover for their startup processing. The time required for system switchover is reduced by the amount of time that would have been required for their activation processing. This function is called user server host hot standby. For example, activating one server process on a server machine operating at about 100 MIPS requires approximately 1 second. Therefore, eliminating this activation process should reduce system switchover time by approximately 1 second.

To use the user server hot standby function, specify Y in the pd_ha_server_process_standby operand.

25.18.2 Rapid system switchover facility

Server processes or system servers for HiRDB on the standby system can be activated in advance, not during system switchover. This function is called the rapid system switchover facility. The time required for system switchover is reduced by the amount of time that would have been required for the activation processing of the server processes or system servers during system switchover.

The rapid system switchover facility is more effective in reducing the time required for system switchover than user server hot standby (the rapid system switchover facility includes the functionality of user server hot standby). Figure 25-76 compares the system switchover times of the two system switchover facilities.

Figure 25-76 Comparison of system switchover times

Explanation

Because the processes indicated by shading execute while waiting, these processes are not executed during system switchover. The time required for system switchover is reduced by the amount of time required for these processes.

Organization of this subsection

(1) Conditions for IP addresses

(2) Operands specified when using the rapid system switchover facility

(1) Conditions for IP addresses

(a) HiRDB/Single Server

The unit that uses the rapid system switchover facility cannot inherit IP addresses. Therefore, in the case of a HiRDB/Single Server, configure the unit so it does not inherit IP addresses.

(b) HiRDB/Parallel Server

Configure the unit that uses the rapid system switchover facility so it does not inherit IP addresses. Specify N in the pd_ha_ipaddr_inherit operand in the unit control information definition for the applicable unit. Units that do not use the rapid system switchover facility can be configured to inherit IP addresses.

Hitachi recommends allowing use of the rapid system switchover facility on a back-end server unit and not allowing its use on a unit for the system manager or a front-end server. If a unit for the system manager or a front-end server is configured to not inherit IP addresses, operation after system switchover is more difficult than on a unit configured to inherit IP addresses. For system configuration examples, see 25.18.3 System configuration examples when using the rapid system switchover facility.

(c) When using HA monitor in the cluster software

Before activating the running system and standby system HiRDB (or unit), start the IP addresses specified in the -x and -c options of the pdunit operand. Do not specify an IP address specified in the -x or -c option of the pdunit operand in the alias operand value's .up or .down file for HA monitor. If IP addresses for client connection are to be inherited, specify these IP addresses. If there are no IP addresses to be inherited, such as IP addresses for client connection, either specify nouse in the lan_updown operand of HA monitor's server definition statement or delete the alias operand value's .up and .down files.

(2) Operands specified when using the rapid system switchover facility

To use the rapid system switchover facility, specify standbyunit in the pd_ha_agent operand.

In the case of a HiRDB/Parallel Server, consider whether or not to use the transaction queuing facility. When the transaction queuing facility is used, fewer transaction errors will occur during system switchover. For details about the transaction queuing facility, see 25.19 Transaction queuing facility.

25.18.3 System configuration examples when using the rapid system switchover facility

Figure 25-77 shows a system configuration example when using the rapid system switchover facility.

Figure 25-77 System configuration example when using the rapid system switchover facility

Explanation

Because the unit for the system manager and front-end server (unit 1) is configured to inherit IP addresses, it cannot use the rapid system control facility. This unit has a 1-to-1 switchover configuration configuration that uses the user server hot standby function.

The back-end server units (unit 2 and unit 3) have a mutual system switchover configuration that uses the rapid system switchover facility.

The following examples show the specification of operands in the HiRDB system definition. These definition examples explain only operands related to the system common definition and unit control information definition.

System common definition

set pd_ha = use
set pd_name_port = 20000

pdunit -x hostAA -u unt1 -d "/hirdb1" -p 20000                       1
pdunit -x hostB -u unt2 -d "/hirdb2" -c hostBB -p 20001              2
pdunit -x hostC -u unt3 -d "/hirdb3" -c hostCC -p 20002              3

pdstart -t MGR -u unt1
pdstart -t DIC -u unt1 -s DIC
pdstart -t FES -u unt1 -s FES
pdstart -t BES -u unt2 -s BES1
pdstart -t BES -u unt3 -s BES2

Explanation

This is the definition for unit 1. Because this unit inherits IP addresses after system switchover, the -c option is not specified.

This is the definition for unit 2. Because this unit does not inherit IP addresses after system switchover, the host name of the secondary system is specified in the -c option.

This is the definition for unit 3. Because this unit does not inherit IP addresses after system switchover, the host name of the secondary system is specified in the -c option.

Unit control information definition (unit 1)

set pd_hostaname = host1                            1
set pd_ha_acttype = server                          2
set pd_ha_server_process_standby = Y                3

Explanation

Specifies the standard host name of the primary system.

Executes the system switchover facility in the server mode. The server mode requires that the unit use the user server hot standby function.

The user server hot standby function is used on this unit.

Unit control information definition (unit 2)

set pd_hostname = hostB                            1
set pd_ha_acttype = server                         2
set pd_ha_ipaddr_inherit = N                       3
set pd_ha_agent = standbyunit                      4

Explanation

Specifies the host name of the primary system.

Executes the system switchover facility in the server mode. The server mode requires that the unit use the user server hot standby function.

Specifies that IP addresses are not to be inherited after system switchover. Units using the rapid system switchover facility cannot inherit IP addresses.

The rapid system switchover facility is used on this unit.

Unit control information definition (unit 3)

set pd_hostname = hostC                           1
set pd_ha_acttype = server                        2
set pd_ha_ipaddr_inherit = N                      3
set pd_ha_agent = standbyunit                     4

Explanation

Specifies the host name of the primary system.

Executes the system switchover facility in the server mode. The server mode requires that the unit use the rapid system switchover facility.

Specifies that IP addresses are not to be inherited after system switchovers. Units using the rapid system switchover facility cannot inherit IP addresses.

The rapid system switchover facility is used on this unit.

25.18.4 Checking procedure when activation of standby system takes much time

The process for activating the standby system waits for the running system to be activated. When activation of a unit in the standby system using the rapid system switchover facility takes too much time, perform the following checking procedure.

Check to see if the running system was activated. Activate the running system if it was not activated.

Use the pdls -d prc -a command to check to see if the pdenvcp command that is issued internally by the HiRDB in the standby system has responded. If the pdenvcp command did not respond, check to see if the _pd0envc command process remains on the running system. If this command process does remain, terminate it, then reactivate the standby system.

Use the pdls -d rpc command to see if RPC or a file input/output process stopped the pdenvcp command that HiRDB in the running system issues internally. Eliminate the cause of the network or OS error, and then reactivate the standby system.

If the process of activating the standby system during system switchover times out, redefine the value of the pd_system_complete_wait_time operand (completion wait time for the pdstart command). Set a value that takes into account the activation time of the standby system then reactivate the standby system. If the process for activating the standby system times out, use the pdls -d prc -a command to see if the _pd0envc command process remains on the running system. If this command process does remain, terminate the process, and then reactivate the standby system.

When using a large number of lists, the list initialization process may increase the time required for system switchover. In such a case, consider changing the list initialization time with the pd_list_initialize_timing operand. For details about changing the list initialization time, see 13.21(9) Changes when initializing (deleted) lists.

25.18.5 Notes on using the rapid system switchover facility

Organization of this subsection

(1) Actions requiring restarting HiRDB (or unit) in the standby system

(2) RDAREA opening trigger attributes

(3) Linking with OLTP products

(1) Actions requiring restarting HiRDB (or unit) in the standby system

After taking one of the actions listed below, terminate then restart HiRDB on the standby system (unit in the standby system in the case of a HiRDB/Parallel Server). If HiRDB on the standby system is not restarted, it will terminate abnormally when a system switchover occurs.

HiRDB in the running system executed the database structure modification utility (pdmod command)

After a process was performed that updates the master directory RDAREA (for example, executing the database structure modification utility, executing a definition SQL, executing the pddbchg command), the server in the running system (front-end server, dictionary server, or back-end server) independently terminated normally and then was started normally.

After the pdbuffer, pd_max_rdarea_no, pd_max_file_no, pd_inner_replica_control, or pd_index_assurance_no operand was modified, the server in the running system independently terminated normally and then was started normally.

After a foreign server or user mapping was defined, the server in the running system independently terminated normally and then was started normally.

If HiRDB in the standby system terminated abnormally, use the pdstart command (pdstart -u or pdstart -q for HiRDB in the standby system) to start HiRDB in the standby system.

(2) RDAREA opening trigger attributes

Units in the standby system that are subject to the rapid system switchover facility do not open any RDAREAs when in waiting status. To minimize the time required for system switchover, the rapid system switchover facility opens only the RDAREAs needed for full recovery when a system switchover occurs. Therefore, the RDAREA opening trigger attribute of the standby system does not become INITIAL. The RDAREAs with the INITIAL attribute change to DEFER.

For details about RDAREA open attributes, see 15.5 Modifying an RDAREA opening trigger attribute (RDAREA modification).

(3) Linking with OLTP products

Caution is urged when all of the conditions listed below are present:

The rapid system switchover facility is being used (in the case of a HiRDB/Parallel Server, units in the system manager are subject to the rapid system switchover facility)

Products using X/Open-compliant API are linked with OLTP products (such as OpenTP1 or TPBroker)

The HiRDB client is version 06-02-/A or earlier

HiRDB_PDHOST is specified in the client environment variables of the OLTP products

The primary system is in waiting completed status as the standby system

In such a case, if the OLTP products perform recovery processing on an undetermined transaction, the X/Open-compliant API may return an error and not be able to recover the transaction. If this problem occurs, upgrade the HiRDB client to version 06-02-/B or later. If you cannot immediately upgrade the HiRDB client because, for example, you do not wish to stop the current job task, switch the HiRDB (unit) in the primary system from the standby system to the running system. However, this is only a temporary measure. Be sure to upgrade the HiRDB client after the current job task has been completed.

25.19 Transaction queuing facility

You can use the transaction queuing facility while using the rapid system switchover facility or the standby-less system switchover facility on a HiRDB/Parallel Server.

Organization of this section

(1) About the transaction queuing facility

(2) Setting up the environment

(3) Transactions that are subject to queuing

(4) Notes

(1) About the transaction queuing facility

When system switchover occurs in a unit for a back-end server or dictionary server, the back-end server or dictionary server cannot accept any transactions until system switchover is completed. This means that any transaction to be processed by the back-end server or dictionary server while the system switchover is in progress results in an error.

The function called the transactions queuing facility queues transactions on the front-end server until system switchover is complete without causing errors for these transactions. This makes it possible to reduce the number of transaction errors occurring during system switchover. Figure 25-78 provides an overview of the transaction queuing facility.

Figure 25-78 Overview of the transaction queuing facility

* In the case of standby-less system switchover:

During normal operation, the normal BES unit becomes the running system and the alternate portion becomes the standby system.

When in alternating status, the alternate portion becomes the running system and the normal BES unit becomes the standby system.

Explanation

An error has occurred in the unit for a back-end server and system switchover has occurred. Transactions are queued until the unit in the standby system has been activated, then transaction processing resumes.

Remarks

Transactions for execution by a unit that was not switched (did not cause an error) are not queued. These transactions are executed as usual.

Using multiple front-end servers makes it possible to reduce transaction errors when system switchover occurs for units for front-end servers. In such a case, only the transaction in progress when an error occurs results in an error.

(2) Setting up the environment

Use of the rapid system switchover facility on a HiRDB/Parallel Server is assumed. The operands explained in Table 25-54 are specified to use the transaction queuing facility.

Table 25-54 Operands specified to use the transaction queuing facility

Operand
Description

pd_ha_transaction
Specifies that the transaction queuing facility is to be used.
When NO is specified in the PDHATRNQUEUING operand in the client environment definition, the UAP executed by the HiRDB client is not subject to the transaction queuing facility. For details about the PDHATRNQUEUING operand, see the manual HiRDB Version 8 UAP Development Guide.

pd_ha_trn_queuing_wait_time
Specifies the queuing wait time for transactions. If the unit in the standby system is not activated before the wait time specified in this operand expires, transactions currently being queued result in an error. Any subsequent transactions result in an error and are not queued.

pd_ha_trn_restart_retry_time
If system switchover occurs while the transaction queuing facility is being used, transactions are queued on the front-end server. However, the front-end server cannot detect system switchover until the unit in the standby system restarts. During the time from when system switchover occurs until the time the unit in the standby system restarts, the front-end server continues to request that the unit in the running system start transactions. However, such transaction startup requests result in errors because the unit in the running system has already terminated abnormally. The front-end server retries the transaction startup requests continuously.
A maximum retry time value is specified in this operand. If the unit in the standby system has not restarted by the time the value specified in this operand is reached, transactions currently being retried result in an error. All subsequent transactions result in an error also and are not retried. Figure 25-79 shows the relationship between the pd_ha_trn_queuing_wait_time operand and the pd_ha_trn_restart_retry_time operand.

Figure 25-79 Relationship between the pd_ha_trn_queuing_wait_time operand and the pd_ha_trn_restart_retry_time operand

* For standby-less system switchover:

During normal operation, the normal BES unit becomes the running system and the alternate portion becomes the standby system

When in alternating status, the alternate portion becomes the running system and the normal BES unit becomes the standby system.

Explanation

Intervals A and D:

Transactions can be started (normal status).

Interval B:

The back-end server unit is performing system switchover but the front-end server cannot detect that system switchover is in progress. A transaction startup request is retried until the amount of time specified in the pd_ha_trn_restart_retry_time operand is reached. When the front-end server detects system switchover, the transaction is queued. If system switchover is not detected before the specified amount of time is reached, the transaction results in an error.

Interval C:

The back-end server unit is performing system switchover but the front-end server cannot detect that system switchover is in progress. The transaction is queued until the amount of time specified in the pd_ha_trn_queuing_wait_time operand is reached. If the transaction cannot be started before this amount of time is reached, the transaction results in an error.

(3) Transactions that are subject to queuing

Transactions generated by an SQL extension are subject to queuing. However, transactions generated by definition SQL and transactions using the holdable cursor facility are not subject to queuing. The following transactions not subject to queuing:

Transactions that issue definition SQL

Transactions with connections that open holdable cursors

Transactions that issue the ASSIGN LIST statement

Transactions generated by operation commands or utilities

However, depending on the timing, some of these transactions may be queued.

(4) Notes

(a) Interval monitoring operands

The transaction queuing time is the maximum value that is equal to the sum of the value of the pd_ha_trn_queuing_wait_time operand (default: 180 seconds) and the value of the pd_ha_trn_restart_retry_time operand (default: 60 seconds). Therefore, be sure to take careful note of the values for the following operands.

PDCWAITTIME operand of the client environment definition
Because PDCWAITTIME is also monitored during system switchover, be sure to include the time required for system switchover when determining the value of this operand.

pd_lck_wait_timeout operand
Because a lock may be secured on a unit that has been queued and has not caused an error, be sure to include the time required for system switchover when determining the value of this operand.

The time required for system switchover is determined by calculating the difference between the time the cluster software outputs the system switchover startup message to syslogfile and the time it outputs the system switchover completion message to syslogfile. One of the messages listed below is output when system switchover starts:

KAMN200-I message (output when a command for switching the cluster software system is entered)

KAMN300-E message (output when HiRDB in the running system terminates abnormally)

KAMN301-E message (output when HiRDB in the running system slows down)

The KAMN311-I message is output when system switchover is completed.

(b) Notes on using lists

Caution is urged if system switchover occurs while a search using a list is underway. A list created by a unit before system switchover occurred is deleted when system switchover occurs on a back-end server or a dictionary server. Therefore, a search that uses a list (queued transactions) will result in an error after system switchover occurs. In such a case, either delete or re-create the list.

(c) Maximum number of concurrent connections (value of the pd_max_users operand)

Because a larger number of users than usual is waiting to perform processing while transactions are being queued, the maximum number of concurrent connections (value of the pd_max_users operand) may be exceeded. If this occurs, no additional users will be able to connect to the front-end server, and processes for connecting to the front-end server will be retried. These processes will be retried only for the amount of time equal to the sum of the values specified in the pd_ha_trn_queuing_wait_time and pd_ha_trn_restart_retry_time operands.

(d) UAPs that cannot connect to HiRDB during system switchover

UAPs cannot connect to HiRDB during system switchover in the situations listed below:

Front-end server allocation cannot be performed if the unit for the system manager is currently being switched. Therefore, a UAP that has not specified a front-end server to connect to (has not specified one in the PDFESHOST operand) cannot connect to HiRDB.

If the unit for the front-end server specified in the PDFESHOST operand is currently being switched, the UAP cannot connect to HiRDB.

In these cases, the UAP uses the automatic reconnect facility to retry connecting to HiRDB. If system switchover is completed during the retry interval, the UAP will connect successfully to HiRDB. For details about the automatic reconnect facility, see the manual HiRDB Version 8 UAP Development Guide.

(e) When the BES connection holding facility is used

For notes on using the BES connection holding facility, see E.1(3)(c) Setting the maximum client wait time.

25.20 System switchover when errors other than server failures occur

This section explains the procedures for performing system switchover when the following errors occur:

A large number of server processes has terminated abnormally

An RDAREA I/O error (path error) has occurred

Organization of this section

25.20.1 A large number of server processes has terminated abnormally

25.20.2 RDAREA I/O error (path error) has occurred

25.20.1 A large number of server processes has terminated abnormally

If a large number of server processes has terminated abnormally, new services may not be accepted. HiRDB does not terminate abnormally because a server process has terminated abnormally, but HiRDB is essentially in online stopped status. Also, because HiRDB will not have terminated abnormally, system switchover will not be performed. The procedure for performing system switchover when HiRDB is in online stopped status is explained below.

Organization of this subsection

(1) System switchover preparations

(2) Mutual system switchover configuration

(3) Reducing system switchover time

(1) System switchover preparations

(a) Specify the pd_down_watch_proc operand

HiRDB (or applicable unit for a HiRDB/Parallel Server) can be terminated abnormally when the number of server processes terminating abnormally exceeds the value set in the pd_down_watch_proc operand during a specified period of time. The facility that terminates HiRDB abnormally in such circumstances is called the process abnormal termination monitoring facility. This facility is used to terminate HiRDB abnormally and perform system switchover when HiRDB is in online stopped status. For details about the process abnormal termination monitoring facility, see 8.13 Monitoring the number of times server processes terminate abnormally (abnormal termination monitoring facility).

(b) Check the value specified in the pd_mode_conf operand

If system switchover is to be performed when the process abnormal termination monitoring facility terminate HiRDB abnormally, specify pd_mode_conf=MANUAL2. If system switchover is not to be performed (if HiRDB is to be restarted on the abnormally terminated system), specify pd_mode_conf=MANUAL1.

(c) Specify the switchtype operand for HA monitor or Hitachi HA Toolkit Extension (applicable to the server mode only)

Specify switch in the switchtype operand for HA monitor or Hitachi HA Toolkit Extension. When switch is specified, system switchover will be performed when HiRDB terminates abnormally.

(d) Monitoring of the system switchover time period (applicable to the monitor mode only)

In this case, a system cannot be switched automatically even if a large number of server processes terminate abnormally and HiRDB terminates abnormally. Systems can be switched only by a user operation (such as by executing a system switchover shell script). Example system switchover operations are explained below.

When HiRDB terminates abnormally, the KFPS01821-E message is output to syslogfile. Use JP1 or a monitor shell script to monitor this message and perform system switchover when this message is output. In the case of a HiRDB/Parallel Server, this message is output to syslogfile on either the server machine running the system manager or on the server machine with the unit that terminated abnormally.

Execute the UAP regularly and see if the database can be accessed. If the UAP cannot access the database, perform a system switchover.

(2) Mutual system switchover configuration

Performing a system switchover may not be effective and may actually cause traffic to increase because more than one HiRDB is running on the same server machine. When using the process abnormal termination monitoring facility in a mutual system switchover configuration, Hitachi recommends that you not perform system switchover when HiRDB terminates abnormally. Instead, restart HiRDB in the system where it terminated abnormally by specifying pd_mode_conf=MANUAL1.

When running in the server mode, specify either restart or manual in the switchtype operand of HA monitor or Hitachi HA Toolkit Extension. When restart is specified, HiRDB on the system resulting in an error restarts. When HiRDB cannot be restarted on the system resulting in an error, perform a system switchover and restart HiRDB on the system that was the switchover destination. When manual is specified, system switchover will not be performed automatically even if HiRDB cannot be restarted.

(3) Reducing system switchover time

When a large number of server processes terminates abnormally, a large amount of troubleshooting information may be output, requiring much time to perform a system switchover. Specifying the operands listed below suppresses output of troubleshooting information and makes it possible to reduce the system switchover time when many server processes have terminated abnormally:

pd_dump_suppress_watch_time

pd_cancel_dump = noput

pd_client_waittime_over_abort = N

Also, specifying Y in the pd_ha_switch_timeout operand makes it possible to perform system switchover without waiting for HiRDB termination processing in the running system if that termination processing (normal BES unit for the standby-less system switchover facility) exceeds the server failure monitoring time when system switchover occurs. Note that this operand can be specified only when operating in the server mode.

Table 25-55 lists the errors that affect the system switchover time.

Table 25-55 Errors that affect the system switchover time

Error type (cause of system switchover)
Effects?

Monitor mode
Server mode

Abnormal termination of HiRDB
Abnormal termination of pdprcd
No
No

Abnormal termination of system server
Yes
No

Abnormal termination of user server
Critical
May
No

Non- critical¹
PDCWAITTIME exceeded
pd_client_waittime_
over_abort=Y (default)
May
No

pd_client_waittime_
over_abort=N
No
No

Internal forced termination²
May
No

Abort
May
No

Rollback occurred in UAP connected to XA
May
No

Other than the above
May
No

Slowdown of HiRDB
No response from pdprcd
Yes
No

System failure
No
No

Planned system switchover
No
No

Legend:

No: Has no effects on the system switchover time.

However, depending on when the error occurred, the system switchover time may be affected.

May: May have effects on the system switchover time.

Specifying the operands listed below makes it possible to minimize the effects these errors have on the system switchover time:

pd_cancel_dump=noput

pd_dump_suppress_watch_time

Yes: Does often have effects on the system switchover time.

¹ In the case of this error, HiRDB does not usually terminate abnormally. However, when the pd_down_watch_proc operand is specified, the number of server processes terminating abnormally is monitored and HiRDB is terminated abnormally if this number exceeds a specified value.

² HiRDB issues SIGKILL internally and terminates processing. Forced termination resulting when PDCWAITTIME is exceeded or the pdcancel command is issued is not included.

25.20.2 RDAREA I/O error (path error) has occurred

This section explains the procedure for performing system switchover when an RDAREA input/output error (path error) has occurred. For this purpose, an I/O error means an error that occurs when HiRDB manipulates a file, when HiRDB can no longer distinguish a file, when file manipulation fails. The error code returned from the request for access to the HiRDB file system is -1544.

Organization of this subsection

(1) System switchover preparations

(2) Operation

(1) System switchover preparations

(a) Specify the pd_db_io_error_action operand

If unitdown is specified in the pd_db_io_error_action operand, HiRDB (or unit in the case of a HiRDB/Parallel Server) terminates abnormally when an RDAREA I/O error occurs and system switchover is performed. When the cause of the I/O error is a path error, job tasks can continue because I/O processing can be performed after system switchover is performed. For this purpose, a path error means a status in which files cannot be accessed because the path of communication between HiRDB and the files was interrupted.

For details about specifying unitdown in the pd_db_io_error_action operand, see 18.20 Actions to take when an RDAREA I/O error occurs.

(b) Check the value specified in the pd_mode_conf operand

If system switchover is to be performed when HiRDB terminates abnormally, specify pd_mode_conf=MANUAL2. If system switchover is not to be performed (if HiRDB is to restarted on the abnormally terminated system), specify pd_mode_conf=MANUAL1.

(c) Specify the switchtype operand for HA monitor or Hitachi HA Toolkit Extension (applicable to the server mode only)

Specify switch in the switchtype operand for HA monitor or Hitachi HA Toolkit Extension. When switch is specified, system switchover will be performed when HiRDB terminates abnormally.

(d) Monitoring of the system switchover time period (applicable to the monitor mode only)

When in the monitor mode, a system cannot be switched automatically even if HiRDB terminates abnormally. Systems can be switched only by a user operation (such as by executing a system switchover shell script). Example system switchover operations are explained below.

When HiRDB terminates abnormally, the KFPS01821-E message is output to the syslogfile. Use JP1 or a monitor shell script to monitor this message and perform system switchover when this message is output. In the case of a HiRDB/Parallel Server, this message is output to syslogfile on either the server machine running the system manager or on the server machine with the unit that terminated abnormally.

Execute the UAP regularly and see if the database can be accessed. If the UAP cannot access the database, perform a system switchover.

(2) Operation

When an I/O error occurs and HiRDB terminates abnormally, perform a system switchover and continue the processing in progress when the error occurred. Also, read the output messages and resolve the error. Then, either perform another system switchover or terminate and restart HiRDB, as appropriate. If the I/O error recurs after the system switchover, the RDAREA is shut down. In such a case, use the database recovery utility (pdrstr command) to recover the RDAREA.

25.21 Actions to take when a stopped unit prevents switching of the system manager unit

When system switchover for the system manager unit occurs while there is a stopped unit, it will not be possible to start the system manager unit at the switching destination. As a result, system switchover for the system manager unit fails.

However, if you take either of the following actions, you can execute system switchover for the system manager unit even when there is a stopped unit:

Specify reduced activation

Specify the pd_ha_mgr_rerun operand

The required conditions and operation timing restrictions depend on which of these methods you use. The method you choose should be appropriate for your system.

Organization of this section

25.21.1 Using reduced activation

25.21.2 Specifying the pd_ha_mgr_rerun operand

25.21.1 Using reduced activation

When there is a stopped unit, you can execute system switchover for the system manager unit by specifying the following operands:

pd_start_level = 1

pd_start_skip_unit = unit-identifier-of-stopped-unit

pd_reduced_check_time = startup-time-limit

Table 25-56 shows how to specify these operands and the actions HiRDB takes during system switchover.

Table 25-56 Operands related to reduced activation and actions HiRDB takes during system switchover

Condition
Actions HiRDB takes when system switchover occurs for the system manager unit

pd_start_level specification value
pd_start_skip_unit specification

0
(default value)

If there is a stopped unit, system switchover for the system manager unit fails.

1
Not specified
Even if there is a stopped unit, system switchover for the system manager unit executes. However, a wait occurs for receipt of a startup processing completion notice from each unit. The startup time limit is specified in the pd_reduced_check_time operand (default value is 20 minutes).

Specified
Even if there is a stopped unit, system switchover for the system manager unit executes. No checking wait time occurs.

Reference note

When system switchover for the system manager unit occurs, a check is made for whether or not front-end servers and back-end servers are active at the system manager unit at the switching destination. This is why a wait occurs for receipt of a startup processing completion notice from each unit. If system switchover occurs while there are units that are stopped, the operating status of such units cannot be determined; as a result, system switchover may fail or take a long time to be completed.

If any of the following conditions is not satisfied, system switchover for the system manager unit fails:
A front-end server is active
A back-end server is active
A dictionary server is active

When you specify the pd_start_skip_unit operand, you must terminate HiRDB. Therefore, you should consider the other method if your system must remain active around the clock.

25.21.2 Specifying the pd_ha_mgr_rerun operand

Organization of this subsection

(1) Processing difference depending on the operand specification

(2) Required system configuration

(3) Environment setting

(4) Notes about system switchover for the system manager unit

(1) Processing difference depending on the operand specification

When notwait is specified in the pd_ha_mgr_rerun operand, HiRDB does not wait to receive a startup processing completion notice from each unit during system switchover for the system manager unit (at the time of startup processing at the switching destination). Table 25-57 shows the processing by HiRDB depending on the value specified in the pd_ha_mgr_rerun operand.

Table 25-57 Processing by HiRDB depending on the value specified in the pd_ha_mgr_rerun operand

Item
pd_ha_mgr_rerun value

wait (default value)
notwait

Whether system switchover for the system manager unit can be executed when there is a stopped unit.
System switchover cannot be executed (system switchover fails).
System switchover can be executed.

Processing that occurs during system switchover for the system manager unit.

Checks each unit's version.¹

Checks the system configuration.²

Does not perform the processing described at the left.³

¹ Checks whether the version of the system manager in the standby system is the same as the version of other units.

² Checks the following:

Is any front-end server active?

Is any back-end server active?

Is a dictionary server active?

³ When system switchover for the system manager unit is complete, the KFPS05210-I message (system startup completion message) is output, even if the HiRDB operating environment is not complete (for example, no front-end server is active).

Reference note

When notwait is specified in the pd_ha_mgr_rerun operand, HiRDB does not perform version checking of the units or the system configuration check. Therefore, the time required for system switchover of the system manager unit is reduced.

(2) Required system configuration

When notwait is specified in the pd_ha_mgr_rerun operand, the system must be configured so that all the following conditions are satisfied:

The rapid system switchover facility is used for the system manager unit.

Only the rapid system switchover facility is used for units subject to system switchover (the user server hot standby function or a standby-less system switchover facility cannot also be used).

The system manager and the dictionary server are defined in the same unit.

A HiRDB/Parallel Server consists of at least two units.

HiRDB Datareplicator is not be used.

(3) Environment setting

The procedure for setting the environment is as follows:

Procedure

Use the pdadmvr command to check that all units in the primary and standby system are of the same version.

Specify notwait in the pd_ha_mgr_rerun operand.

Reference note

When notwait is specified in the pd_ha_mgr_rerun operand, HiRDB does not perform unit version checking when system switchover for the system manager unit occurs. Because correct HiRDB operation cannot be guaranteed if there is a version mismatch between units, you must implement step 1 to ensure all units are of the same version.

(4) Notes about system switchover for the system manager unit

(a) When jobs cannot be executed after system switchover for the system manager unit

When system switchover for the system manager unit is completed, the KFPS05210-I message (system startup completion message) is output, even if the HiRDB operating environment is not complete (for example, no front-end server is active). Consequently, if jobs cannot be executed after completion of system switchover for the system manager unit, a UAP could terminate in an error. For this reason, you should use the pdls command to check the operating status of each server.

(b) When system switchover for the system manager unit occurs while HiRDB is starting or terminating

If system switchover for the system manager unit occurs while HiRDB is starting (or terminating), the system manager unit starts (or terminates) regardless of the operating status of other units. Therefore, units other than the system manager unit may not be able to start (or terminate). In this case, you must terminate HiRDB forcibly.

You can avoid this situation by taking the following actions when starting or terminating HiRDB:

When starting HiRDB
Make sure HiRDB has started completely, then start the system manager unit of the standby system.

When stopping the HiRDB system
First terminate the system manager unit of the standby system; then terminate HiRDB.

(c) About the status of the stopped unit

After system switchover, you can execute the pdls -d svr command for a unit that was stopped at the time of system switchover for the system manager unit. STOP(N), indicating normal termination status following execution of the pdstop command) will be displayed as long as the unit remains stopped.

If a network error causes the unit to remain in STOP(N) status even though it has actually started, first resolve the network error, terminate the unit, and then restart it.

26. Using the Facility for Monitoring MIB Performance Information

This chapter explains the use of the facility for monitoring MIB performance information; this facility uses MIB to collect HiRDB operation information.

Organization of this chapter

26.1 Overview of the facility for monitoring MIB performance information

26.2 System configuration

26.3 Environment setup

26.4 MIB definition file

26.5 Server status table (hirServerStatusTable)

26.6 Work table HiRDB file system area table (hirFileSystemTable)

26.7 RDAREA table (hirRdareaStatusTable)

26.8 RDAREA details table (hirRdareaDetStatusTable)

26.9 Global buffer table (hirBufferStatusTable)

26.10 HiRDB file system area (RDAREAs) table (hirRdareaFileTable)

26.11 SYS statistics table (hirStatisInfSysTable)

26.12 Disk usage

26.1 Overview of the facility for monitoring MIB performance information

This section provides an overview of the facility for monitoring MIB performance information.

Organization of this section

26.1.1 About the facility for monitoring MIB performance information

26.1.2 Objectives of the facility for monitoring MIB performance information

26.1.3 MIB definition file

26.1.4 MIB environment definition file

26.1.1 About the facility for monitoring MIB performance information

SNMP is a protocol for managing management-target objects (such as routers, printers, and databases) on a network. By using SNMP, HiRDB operating information (performance information) can be collected at regular intervals using an SNMP agent and MIB. The collected operating information is sent to a Management Framework where it is managed. This is called the facility for monitoring MIB performance information.

The Management Framework provides a facility for converting the collected operating information into graphs, enabling the HiRDB operating information to be evaluated over a period of time. You can also set events, such as issuance of a warning when the value of an operating information item that is being monitored exceeds a specified value. In this way, changes in HiRDB's operating status can be monitored and the network administrator can take appropriate action before an incipient change results in an error.

MIB records the HiRDB operating information provided by HiRDB. MIB also prescribes the method of collecting the HiRDB operating information and executes HiRDB commands, such as pdbufls, or utilities in response to requests from the Management Framework for the purpose of collecting the HiRDB operating information.

Reference note

A Management Framework performs management of the collected HiRDB operating information, user notification, and creation of documentation for investigating operating problems.

Figure 26-1 provides an overview of the facility for monitoring MIB performance information.

Figure 26-1 Overview of the facility for monitoring MIB performance information

Explanation

JP1/ESA, which is an SNMP agent, uses MIB commands to collect HiRDB operating information at specified intervals. This operating information is managed by the Management Framework.

MIB:

Variables that represent information that can be accessed using SNMP are described in a text file coded in ASN.1.

MIB commands:

Commands used to collect HiRDB operating information. These commands are executed by JP1/ESA on HiRDB. A HiRDB command or utility is executed as an extension of an MIB command and returns its execution results to JP1/ESA.

SNMP:

A protocol for monitoring and controlling management-target objects (such as routers, printers, and databases) on a network via the network.

SNMP agent:

A program that transfers HiRDB operating information to the Management Framework or that collects HiRDB operating information in response to requests from the Management Framework. The following product is used as the SNMP agent:

JP1/Cm2/Extensible SNMP Agent

Management Framework:

An SNMP-compatible management program. The following are recommended for use as the Management Framework:

JP1/Cm2/Network Node Manager, JP1/Performance Management/SNMP System Observer, and JP1/Performance Management/SNMP System Observer for Database Server

Management Frameworks of other companies

Reference note

In addition to the method that uses MIB, JP1/PFM-Agent for HiRDB can also be used to monitor performance information. You must select either the facility for monitoring MIB performance information or JP1/PFM-Agent for HiRDB, whichever is appropriate for your system environment.

26.1.2 Objectives of the facility for monitoring MIB performance information

The facility for monitoring MIB performance information can be used to achieve the following objectives:

Continuous analysis of the HiRDB operating status
Because you collect and summarize on a regular basis such operating information as RDAREA usage rate and number of server processes, you can quickly and easily analyze the HiRDB operating status from the monitored HiRDB itself and display operating trends and history as graphs.

Early detection of system problems and creation of documents for investigation of problems
When performance begins to decline in the monitored HiRDB, such as the global buffer hit rate starts to fall, the HiRDB administrator can be alerted to the incipient problem by means of an e-mail. This enables corrective action to be implemented early. Moreover, because information about the problem can be displayed as a graph, documents for investigating and resolving the problem can be prepared easily and expeditiously.

26.1.3 MIB definition file

The MIB definition file stores the following types of information, which can be accessed via SNMP:

Variable name

Variable's object ID

Variable's data type

Variable's access restriction

26.1.4 MIB environment definition file

You specify the HiRDB to be monitored in the MIB environment definition file. You also specify the information (such as a user name) that will be required to execute HiRDB commands and utilities as extensions of MIB commands.

26.2 System configuration

This section provides examples of system configurations for using the facility for monitoring MIB performance information.

Organization of this section

(1) HiRDB/Single Server

(2) HiRDB/Parallel Server

(3) Multi-HiRDB

(4) Using a system switchover facility

(1) HiRDB/Single Server

Figure 26-2 shows a system configuration for applying the facility for monitoring MIB performance information to a HiRDB/Single Server.

Figure 26-2 System configuration for a HiRDB/Single Server

Explanation

JP1/ESA is installed in the server machine where the monitored HiRDB is located.

(2) HiRDB/Parallel Server

Figure 26-3 shows a system configuration for applying the facility for monitoring MIB performance information to a HiRDB/Parallel Server.

Figure 26-3 System configuration for a HiRDB/Parallel Server

Explanation

JP1/ESA is installed in the server machine where the system manager is defined, because that is the server machine where performance information is collected; there is no need to install JP1/ESA in other server machines.

MIB commands are executed at the server machine where the system manager is defined.

(3) Multi-HiRDB

Figure 26-4 shows a system configuration for applying the facility for monitoring MIB performance information to a multi-HiRDB configuration of HiRDB/Single Servers.

Figure 26-4 System configuration for a multi-HiRDB configuration of HiRDB/Single Servers

Explanation

In the case of a multi-HiRDB configuration, a single MIB command can be used to monitor multiple HiRDBs. You must specify in the MIB environment definition file all the HiRDBs that are to be monitored. Note that there is no requirement that you monitor all the HiRDBs; it is possible to monitor only selected HiRDBs.

(4) Using a system switchover facility

Figure 26-5 shows a system configuration for applying the facility for monitoring MIB performance information to a 1-to-1 switchover configuration.

Figure 26-5 System configuration for a 1-to-1 switchover configuration

Explanation

If you are using a system switchover facility, you must also set up the server machine in the standby system for performance monitoring. That way, if system switchover should occur, monitoring will be continued for the server machine at the switching destination. However, as is shown in Figure 26-6, the collected performance information is not continuous. After switchover, it will appear as though a different HiRDB were being monitored.

Figure 26-6 Performance information when the facility for monitoring MIB performance information is applied to a 1-to-1 switchover configuration

26.3 Environment setup

This section explains the HiRDB environment setup when you use the facility for monitoring MIB performance information. You must perform all the tasks described in the subsections below.

Organization of this section

(1) Creating the common MIB environment definition file (pdmibtgt)

(2) Creating an individual MIB environment definition file (pdmibenv)

(3) Registering the MIB definition file

(4) Setting up the remote shell execution environment (HiRDB/Parallel Server only)

(5) Setting up environment variables

(6) Selecting the performance information to be collected

(1) Creating the common MIB environment definition file (pdmibtgt)

You must create a common MIB environment definition file (pdmibtgt). Specify in this file the HiRDB identifier of the HiRDB to be monitored and the HiRDB directory name. A specification example follows:

pdmib -a HiRDB-system-identifier -d HiRDB-directory-name

Explanation

Create the common MIB environment definition file in the HiRDB installation directory: /sample/pdmibtgt.

In the case of a HiRDB/Parallel Server, create the common MIB environment definition file in the server machine where the system manager is defined.

To monitor multiple HiRDBs in a multi-HiRDB environment, specify multiple lines. A specification example follows:

  pdmib -a HRD1 -d /hirdb_x1
  pdmib -a HRD2 -d /hirdb_x2

(2) Creating an individual MIB environment definition file (pdmibenv)

You must create an individual MIB environment definition file (pdmibenv). Specify in this file the environment for executing HiRDB commands and utilities. A specification example follows:

putenv PDHOST host-name-of-HiRDB-server-to-be-connected
putenv PDDIR HiRDB-directory-name-of-HiRDB-server-to-be-connected
putenv PDNAMEPORT port-number-of-HiRDB-server-to-be-connected
putenv PDUSER authorization-identifier-and-password
putenv LANG character-code-classification

Explanation

The specification of each operand is the same as in the client environment definition. For details about the client environment definition, see the manual HiRDB Version 8 UAP Development Guide.

Create the individual MIB environment definition file in $PDDIR/conf/pdmibenv ($PDDIR is the HiRDB directory name specified in (1)).

Note

If you use the pdchgconf command to modify PDNAMEPORT while HiRDB is running, you must also modify the pdmibenv file.

(3) Registering the MIB definition file

Register into JP1/ESA the MIB definition file provided by HiRDB. In the case of a HiRDB/Parallel Server, register it in the server machine where the system manager is defined. For details about registering into JP1/ESA, see the manual Job Management Partner 1/Consolidated Management 2/Extensible SNMP Agent.

The path name for the MIB definition file is as follows:

/opt/HiRDB_S/sample/hirdbMIB (HiRDB/Single Server)

/opt/HiRDB_P/sample/hirdbMIB (HiRDB/Parallel Server)

Notes about a multi-HiRDB

Register the MIB definition file of the HiRDB in whose directory the pdmibtgt file was created.

If the HiRDB whose MIB definition file was registered is uninstalled, you will have to re-register the MIB definition file of a HiRDB that has not been uninstalled.

(4) Setting up the remote shell execution environment (HiRDB/Parallel Server only)

Because MIB commands are executed with the superuser privilege, a superuser must set up the remote shell execution environment. Settings that permit mutual logon between any server comprising the HiRDB/Parallel Server and the server machine where the system manager is defined must be specified in /etc/hosts.equiv or /.rhosts.

(5) Setting up environment variables

Add the installation directory /lib to the superuser's SHLIB_PATH environment variable. For the Solaris or Linux version, add the installation directory /lib to the superuser's LD_LIBRARY_PATH environment variable. For the AIX 5L version, add the installation directory /lib to the superuser's LIBPATH environment variable.

(6) Selecting the performance information to be collected

(a) Using JP1/SSO for Database

Use JP1/SSO for Database to select the performance information that you wish to collect. For details about the selection method, see the manual Job Management Partner 1/Performance Management/SNMP System Observer for Extended Resource Management.

Note

Depending on the environment applicable to the history to be monitored and the MIB for which information is to be collected, an SNMP timeout error may occur. In such a case, adjust appropriately the SNMP timeout value for JP1/NNM or JP1/ESA.

(b) Using another company's Management Framework

See the relevant manuals for other company's Management Framework.

26.4 MIB definition file

This section explains the conventions for the MIB definition file and the MIB tables that are stored in the MIB definition file.

Organization of this section

(1) Conventions for the MIB definition file provided by HiRDB

(2) MIB tables provided by HiRDB

(1) Conventions for the MIB definition file provided by HiRDB

Table 26-1 explains the conventions for the MIB definition file provided by HiRDB.

Table 26-1 Conventions for the MIB definition file provided by HiRDB

Item
Conventions

File name
File name is hirdbMIB.

Object ID
HiRDB's object ID is .iso.org.dod.internet.private.enterprises.hitachi.systemExMib.hirdbMibs.HiRDB. In numeric format, it is 1.3.6.1.4.1.116.5.24.2. Objects containing HiRDB performance information are located under this object ID.

Comment (DESCRIPTION)
A comment for the object ID can be specified on the first line, followed on the second and subsequent lines by JP1/ESA commands.

Index (INDEX)
Indexes identify an MIB object. For example, to identify information on a particular RDAREA, the following two indexes are required:

HiRDB system index

RDAREA index

Access restriction (ACCESS)
Access restriction for the object. In HiRDB, all objects except tables and entries are read-only. GetRequest or GetNextRequest is allowed, but SetRequest is not. Tables and entries are set to not-access and cannot be accessed.

Object type (SYNTAX)
DisplayString (ASCII) is used for characters, and INTEGER (-(2³¹-1) to 2³¹-1) or Gauge (0 to 2³²-1) is used for numbers. SEQUENCE is used for tables.

(2) MIB tables provided by HiRDB

Table 26-2 lists the MIB tables provided by HiRDB.

Table 26-2 List of MIB tables provided by HiRDB

Table name | Explanation
Server status table (hirServerStatusTable) | Stores a snapshot of performance information on a server's operating status at a given point in time. For details, see 26.5 Server status table (hirServerStatusTable).
Work table HiRDB file system area table (hirFileSystemTable) | Stores performance information collected over a given time period on a HiRDB file system area for work table files. For details, see 26.6 Work table HiRDB file system area table (hirFileSystemTable).
RDAREA table (hirRdareaStatusTable) | Stores performance information collected over a given time period on RDAREAs. For details, see 26.7 RDAREA table (hirRdareaStatusTable).
RDAREA details table (hirRdareaDetStatusTable) | Stores performance information collected over a given time period on RDAREAs. For details, see 26.8 RDAREA details table (hirRdareaDetStatusTable).
Global buffer table (hirBufferStatusTable) | Stores performance information collected over a given time period on global buffers. For details, see 26.9 Global buffer table (hirBufferStatusTable).
HiRDB file system area (RDAREAs) table (hirRdareaFileTable) | Stores performance information collected over a given time period on a HiRDB file system area for RDAREAs. For details, see 26.10 HiRDB file system area (RDAREAs) table (hirRdareaFileTable).
SYS statistics table (hirStatisInfSysTable) | Collects statistical information related to system operations for servers. For details, see 26.11 SYS statistics table (hirStatisInfSysTable).

26.5 Server status table (hirServerStatusTable)

The server status table stores a snapshot of performance information on a server's operating status at a given point in time. An instance is created for each unit or server.

Notes on collecting performance information

Set the performance information collection interval to no less than 60 seconds so that HiRDB performance is not affected adversely.

Table 26-3 shows the configuration of the server status table.

Table 26-3 Configuration of the server status table

ID
Object
Explanation
Type
Privilege
Data source

1.
hirServerStatusTable
Server status table
SEQUENCE
not-access

1.1
hirServerStatusEntry
Server operating status entry
SEQUENCE
not-access

1.1.1
hirServerStatusSysIndex
HiRDB system identifier index
INTEGER
read-only
MIB command

1.1.2
hirServerStatusHostIndex
HiRDB host identifier index
INTEGER
read-only
MIB command

1.1.3
hirServerStatusUnitIndex
HiRDB unit identifier index
INTEGER
read-only
MIB command

1.1.4
hirServerStatusServerIndex
HiRDB server identifier index
INTEGER
read-only
MIB command

1.1.5
hirServerStatusInstance
Instance name
HiRDB-identifier:host-name:unit-identifier:server-name
Display
String
read-only
MIB command

1.1.6
hirServerStatusHirID
HiRDB identifier
Display
String
read-only
MIB command

1.1.7
hirServerStatusHost
Host name
Display
String
read-only
pdls -d svr

1.1.8
hirServerStatusServerName
Server name
******** is displayed for a unit.
Display
String
read-only
pdls -d svr

1.1.9
hirServerStatusStartTime
Start time of server or unit
999999 is displayed if the server or unit is stopped.
Display
String
read-only
pdls -d svr

1.1.10
hirServerStatusStatus
Server or unit status
One of the following:
1: ACTIVE
2: STOP
3: STOP (N)
4: STOP (F)
5: STOP (A)
6: START (I)
7: SUSPEND
8: STARTING
9: STOPPING
10:TRNPAUSE
INTEGER
read-only
pdls -d svr

1.1.11
hirServerStatusUnitID
Unit identifier
Display
String
read-only
pdls -d svr

1.1.12
hirServerStatusDummy
Cannot be referenced.
INTEGER
read-only
MIB command

Legend:

: Not applicable

26.6 Work table HiRDB file system area table (hirFileSystemTable)

The work table HiRDB file system area table stores performance information collected over a given time period on a HiRDB file system area for work table files.

Notes on collecting performance information

Set the performance information collection interval to no less than 600 seconds so that HiRDB performance is not affected adversely.

Table 26-4 shows the configuration of the work table HiRDB file system area table.

Table 26-4 Configuration of the work table HiRDB file system area table

ID
Object
Explanation
Type
Privilege
Data source

3.
hirFileSystemTable
Work table HiRDB file system area table
SEQUENCE
not-access

3.1
hirFileSystemEntry
Work table HiRDB file system area entry
SEQUENCE
not-access

3.1.1
hirFileSystemSysIndex
HiRDB system identifier index
INTEGER
read-only
MIB command

3.1.2
hirFileSystemFileIndex
HiRDB file system identifier index
INTEGER
read-only
MIB command

3.1.3
hirFileSystemInstance
Instance name
HiRDB-identifier:host-name:HiRDB-file-system-area-name
Display
String
read-only
MIB command

3.1.4
hirFileSystemHirID
HiRDB identifier
Display
String
read-only
MIB command

3.1.5
hirFileSystemAvailableExpandCount
Maximum number of HiRDB file system area extensions
INTEGER
read-only
pdfstatfs -d -b

3.1.6
hirFileSystemAvailableFileSize
Maximum size of each file that can be allocated in the HiRDB file system area (KB)
INTEGER
read-only
pdfstatfs -d -b

3.1.7
hirFileSystemCurrentExpandCount
Total number of HiRDB file system area extensions
INTEGER
read-only
pdfstatfs -d -b

3.1.8
hirFileSystemCurrentFileCount
Number of HiRDB files created
INTEGER
read-only
pdfstatfs -d -b

3.1.9
hirFileSystemFreeAreaCount
Total number of non-contiguous free areas
INTEGER
read-only
pdfstatfs -d -b

3.1.10
hirFileSystemHiRDBFileSystemAreaName
HiRDB file system area name
Display
String
read-only
pdfstatfs -d -b

3.1.11
hirFileSystemPeakCapacity
Largest space* used by the user since the maximum value allocated in the HiRDB file system area was reset to 0 (KB)
INTEGER
read-only
pdfstatfs -d -b

3.1.12
hirFileSystemRemainingFileCount
Number of HiRDB files that can still be created (max-number-of-files-that-can-be-created number-of-created-files)
INTEGER
read-only
pdfstatfs -d -b

3.1.13
hirFileSystemRemainingUserArea
Size of unused area in the area allocated to the user (area not allocated as HiRDB files)(KB)
INTEGER
read-only
pdfstatfs -d -b

3.1.14
hirFileSystemSectorSize
HiRDB file system area sector size (KB)
Sector size specified in -s option of pdfmkfs command (default is 1024)
INTEGER
read-only
pdfstatfs -d -b

3.1.15
hirFileSystemHost
Host name
Display
String
read-only
pdfstatfs -d -b

3.1.16
hirFileSystemUserAreacapacity
Size of the HiRDB file system area in the user area (KB)
INTEGER
read-only
pdfstatfs -d -b

3.1.17
hirFileSystemDummy
Cannot be referenced.
INTEGER
read-only
MIB command

Legend:

: Not applicable

* Because the PEAK_CAPACITY value is not cleared until the pdfstatfs -c command is executed on the applicable HiRDB file system area, this field's value does not decrease.

26.7 RDAREA table (hirRdareaStatusTable)

The RDAREA table stores performance information collected over a given time period on RDAREAs. One line is created for each RDAREA.

Notes on collecting performance information

Set the performance information collection interval to not less than 600 seconds so that HiRDB performance is not affected adversely.

For a shared RDAREA, performance information of updatable back-end servers only is collected.

Table 26-5 shows the configuration of the RDAREA table.

Table 26-5 Configuration of the RDAREA table

ID
Object
Explanation
Type
Privilege
Data source

4.
hirRdareaStatusTable
RDAREA table
SEQUENCE
not-access

4.1
hirRdareaStatusEntry
RDAREA entry
SEQUENCE
not-access

4.1.1
hirRdareaStatusSysIndex
HiRDB system identifier index
INTEGER
read-only
MIB command

4.1.2
hirRdareaStatusRdareaIndex
RDAREA identifier index
INTEGER
read-only
MIB command

4.1.3
hirRdareaStatusInstance
Instance name
HiRDB-identifier:server-name:RDAREA-name
Display
String
read-only
MIB command

4.1.4
hirRdareaStatusHirID
HiRDB identifier
Display
String
read-only
MIB command

4.1.5
hirRdareaStatusBufferName
Global buffer name
Display
String
read-only
pdbufls -k def-s SERVR_NAME

4.1.6
hirRdareaStatusExtensionSegmentSize
Number of segment extensions
0 if RDAREA extension is not specified.
INTEGER
read-only
Dictionary table*

4.1.7
hirRdareaStatusFileCount
Number of HiRDB files
INTEGER
read-only
Dictionary table*

4.1.8
hirRdareaStatusIndexCount
Number of stored indexes (number defined)
INTEGER
read-only
Dictionary table*

4.1.9
hirRdareaStatusPageSize
Page size (bytes)
INTEGER
read-only
Dictionary table*

4.1.10
hirRdareaStatusRDAREAName
RDAREA name
Display
String
read-only
pddbls -r ALL -a

4.1.11
hirRdareaStatusRDAREAStatus
RDAREA status
One of the following:
CLOSE, CLOSE HOLD, CLOSE HOLD (INQ), CLOSE HOLD (CMD), CLOSE HOLD (BU), CLOSE HOLD (BU I), CLOSE HOLD (BU W), CLOSE HOLD (BU IW), CLOSE HOLD (SYNC), CLOSE HOLD (ORG), CLOSE ACCEPT-HOLD, HOLD, HOLD (INQ), HOLD (CMD), HOLD (BU), HOLD (BU I), HOLD (BU W), HOLD (BU IW), HOLD (SYNC), HOLD (ORG), ACCEPT-HOLD, OPEN
Display
String
read-only
pddbls -r ALL -a

4.1.12
hirRdareaStatusRDAREAType
RDAREA type
One of the following:
MAST, DDIR, DDIC, DLOB, USER, ULOB, LIST, RGST, RLOB
Display
String
read-only
pddbls -r ALL -a

4.1.13
hirRdareaStatusSegmentSize
Segment size (pages)
INTEGER
read-only
Dictionary table*

4.1.14
hirRdareaStatusServerName
Server name
Display
String
read-only
pddbls -r ALL -a

4.1.15
hirRdareaStatusTableCount
Number of stored tables (number defined)
INTEGER
read-only
Dictionary table*

4.1.16
hirRdareaStatusTotalRDAREASegments
Total number of segments in the RDAREA
INTEGER
read-only
pddbls -r ALL -a

4.1.17
hirRdareaStatusUnusedRDAREASegments
Number of unused segments in theRDAREA
INTEGER
read-only
pddbls -r ALL -a

4.1.18
hirRdareaStatusDummy
Cannot be referenced.
INTEGER
read-only
MIB command

Legend:

: Not applicable

* Result of the following SQL statement:

SELECT PAGE_SIZE,SEGMENT_SIZE,FILE_COUNT,N_TABLE,N_INDEX,EXTENSION_SEGMENT_SIZE
     FROM "MASTER".SQL_RDAREAS

26.8 RDAREA details table (hirRdareaDetStatusTable)

The RDAREA details table stores performance information collected over a given time period on RDAREAs. One line is created for each RDAREA.

Notes on collecting performance information

Set the performance information collection interval to not less than 3600 seconds so that HiRDB performance is not affected adversely.

For a shared RDAREA, the performance information of updatable back-end servers only is collected.

If the pddbst command cannot be executed, 0 (for a numeric value field) or a blank (for a character string field) is set in any field that acquires data from the pddbst command.
The pddbst command can be executed when both the following conditions are satisfied:
The target RDAREA is a data dictionary RDAREA, user RDAREA, LOB RDAREA, registry RDAREA, or registry LOB RDAREA.
The target RDAREA is open without shutdown or referencing-possible hold in effect.

Table 26-6 shows the configuration of the RDAREA details table.

Table 26-6 Configuration of the RDAREA details table

ID
Object
Explanation
Type
Privilege
Data source

5.
hirRdareaDetStatusTable
RDAREA details table
SEQUENCE
not-access

5.1
hirRdareaDetStatusEntry
RDAREA details entry
SEQUENCE
not-access

5.1.1
hirRdareaDetStatusSysIndex
HiRDB system identifier index
INTEGER
read-only
MIB command

5.1.2
hirRdareaDetStatusRdareaIndex
RDAREA identifier index
INTEGER
read-only
MIB command

5.1.3
hirRdareaDetStatusInstance
Instance name
HiRDB-identifier:server-name:RDAREA-name
Display
String
read-only
MIB command

5.1.4
hirRdareaDetStatusHirID
HiRDB identifier
Display
String
read-only
MIB command

5.1.5
hirRdareaDetStatusAutoExtendErrorCode
Error code when automatic extension cannot be executed
INTEGER
read-only
pddbst -k phys -f

5.1.6
hirRdareaDetStatusAutoExtendStatus
Automatic extension facility's status:
SUP: Suppressed
NOSUP: Not suppressed
Display
String
read-only
pddbst -k phys -f

5.1.7
hirRdareaDetStatusAutoExtendUse
Automatic extension facility's use status:
USE: Being used
NOUSE: Not being used
Display
String
read-only
pddbst -k phys -f

5.1.8
hirRdareaDetStatusBufferName
Global buffer name
Display
String
read-only
pdbufls -k def-s SERVR_NAME

5.1.9
hirRdareaDetStatusExtensionSegmentSize
Number of segment extensions
0 if RDAREA extension is not specified.
INTEGER
read-only
Dictionary table¹

5.1.10
hirRdareaDetStatusFileCount
Number of HiRDB files
INTEGER
read-only
Dictionary table¹

5.1.11
hirRdareaDetStatusFreezeSpecified
Whether or not RDAREA updating is frozen
Display
String
read-only
pddbst -k phys -f²

5.1.12
hirRdareaDetStatusFullUsedPage
Ratio of full pages (%)
INTEGER
read-only
pddbst -k phys -f⁹

5.1.13
hirRdareaDetStatusFullUsedPages
Number of full pages
INTEGER
read-only
pddbst -k phys -f⁹

5.1.14
hirRdareaDetStatusGenNumber
Generation number of the RDAREA
INTEGER
read-only
pddbst -k phys -f⁴

5.1.15
hirRdareaDetStatusHoldCode1
Hold cause code for the RDAREA
INTEGER
read-only
pddbst -k phys -f

5.1.16
hirRdareaDetStatusHoldCode2
Hold cause code immediately prior to Hold Status 1
INTEGER
read-only
pddbst -k phys -f

5.1.17
hirRdareaDetStatusHoldStatus1
Hold type of the RDAREA:
1: Error shutdown (shut down by an error)
2: Command shutdown (command shutdown based on error detection by HiRDB)
3: Value output by pddbst (value other than FLT or CMD)
4: Blank (other cases)
Display
String
read-only
pddbst -k phys -f

5.1.18
hirRdareaDetStatusHoldStatus2
Hold status immediately prior to Hold Status 1
Display
String
read-only
pddbst -k phys -f

5.1.19
hirRdareaDetStatusHoldTime1
Hold time of the RDAREA
Display
String
read-only
pddbst -k phys -f

5.1.20
hirRdareaDetStatusHoldTime2
Hold time immediately prior to Hold Status 1
Display
String
read-only
pddbst -k phys -f

5.1.21
hirRdareaDetStatusIndexCount
Number of stored indexes (number defined)
INTEGER
read-only
Dictionary table¹

5.1.22
hirRdareaDetStatusLastSegment
Position information indicating the last segment being used
Always indicates the last segment if Segment Over is Y.
INTEGER
read-only
pddbst -k phys -f⁶

5.1.23
hirRdareaDetStatusLobmapOver
Whether or not all LOB management entries are being used:
Y: All are being used
N: Some entries are unused
Display
String
read-only
pddbst -k phys -f⁵

5.1.24
hirRdareaDetStatusOriginal
RDAREAName
Original RDAREA name
Display
String
read-only
pddbst -k phys -f³

5.1.25
hirRdareaDetStatusPageSize
Page size (bytes)
INTEGER
read-only
Dictionary table¹

5.1.26
hirRdareaDetStatusRDAREAName
RDAREA name
Display
String
read-only
pddbls -r ALL -a

5.1.27
hirRdareaDetStatusRDAREAStatus
RDAREA status
One of the following:
CLOSE, CLOSE HOLD, CLOSE HOLD (INQ), CLOSE HOLD (CMD), CLOSE HOLD (BU), CLOSE HOLD (BU I), CLOSE HOLD (BU W), CLOSE HOLD (BU IW), CLOSE HOLD (SYNC), CLOSE HOLD (ORG), CLOSE ACCEPT-HOLD, HOLD, HOLD (INQ), HOLD (CMD), HOLD (BU), HOLD (BU I), HOLD (BU W), HOLD (BU IW), HOLD (SYNC), HOLD (ORG), ACCEPT-HOLD, OPEN
Display
String
read-only
pddbls -r ALL -a

5.1.28
hirRdareaDetStatusRDAREAType
RDAREA type
One of the following:
MAST, DDIR, DDIC, DLOB, USER, ULOB, LIST, RGST, RLOB
Display
String
read-only
pddbls -r ALL -a

5.1.29
hirRdareaDetStatusReplicaRDAREAs
Number of replica RDAREAs
INTEGER
read-only
pddbst -k phys -f⁴

5.1.30
hirRdareaDetStatusSegmentOver
Whether or not LOB RDAREA storage is disorganized:
Y: Disorganized
N: Organized
Display
String
read-only
pddbst -k phys -f⁵

5.1.31
hirRdareaDetStatusSegmentSize
Segment size
INTEGER
read-only
Dictionary table¹

5.1.32
hirRdareaDetStatusServerName
Server name
Display
String
read-only
pddbls -r ALL -a

5.1.33
hirRdareaDetStatusTableCount
Number of stored tables (number defined)
INTEGER
read-only
Dictionary table¹

5.1.34
hirRdareaDetStatusTotalPages
Total number of pages in segments in the RDAREA (number-of-used-pages + number-of-unused-pages)
INTEGER
read-only
pddbst -k phys -f¹⁰

5.1.35
hirRdareaDetStatusTotalRDAREASegments
Total number of segments in the RDAREA
INTEGER
read-only
pddbls -r ALL -a

5.1.36
hirRdareaDetStatusUnusedRDAREASegments
Number of unused segments in the RDAREA
INTEGER
read-only
pddbls -r ALL -a

5.1.37
hirRdareaDetStatusUsed
Rate of used segments
INTEGER
read-only
Fixed to 0

5.1.38
hirRdareaDetStatusUsedPage
Percentage of used pages (%)
INTEGER
read-only
pddbst -k phys -f⁸

5.1.39
hirRdareaDetStatusUsedPages
Number of used pages
INTEGER
read-only
pddbst -k phys -f⁷

5.1.40
hirRdareaDetStatusDummy
Cannot be referenced.
INTEGER
read-only
MIB command

Legend:

: Not applicable

¹ Result of the following SQL statement:

SELECT PAGE_SIZE,SEGMENT_SIZE,FILE_COUNT,N_TABLE,N_INDEX,EXTENSION_SEGMENT_SIZE FROM "MASTER".SQL_RDAREAS

² Left blank except in the case of a LOB RDAREA.

³ Left blank if HiRDB Staticizer Option is not installed.

⁴ 0 if HiRDB Staticizer Option is not installed.

⁵ Left blank except in the case of a LOB RDAREA.

⁶ 0 except in the case of a LOB RDAREA.

⁷ Value of USED_AREA_SEG in the case of a LOB RDAREA.

⁸ Value of PERCENT_USED in the case of a LOB RDAREA.

⁹ 0 in the case of a LOB RDAREA.

¹⁰ Value of TOTAL_AREA_SEG in the case of a LOB RDAREA.

26.9 Global buffer table (hirBufferStatusTable)

The global buffer table stores performance information collected over a given time period on global buffers. One line is created for each global buffer.

Notes on collecting performance information

Set the performance information collection interval to no less than 60 seconds so that HiRDB performance is not affected adversely.

Table 26-7 shows the configuration of the global buffer table.

Table 26-7 Configuration of the global buffer table

ID
Object
Explanation
Type
Privilege
Data source

6.
hirBufferStatusTable
Global buffer table
SEQUENCE
not-access

6.1
hirBufferStatusEntry
Global buffer entry
SEQUENCE
not-access

6.1.1
hirBufferStatusSysIndex
HiRDB system identifier index
INTEGER
read-only
MIB command

6.1.2
hirBufferStatusBufferIndex
Global buffer identifier index
INTEGER
read-only
MIB command

6.1.3
hirBufferStatusInstance
Instance name
HiRDB-identifier:server-name:global-buffer-name
Display
String
read-only
MIB command

6.1.4
hirBufferStatusHirID
HiRDB identifier
Display
String
read-only
MIB command

6.1.5
hirBufferStatusBufferName
Global buffer name
Display
String
read-only
pdbufls -k sts -d

6.1.6
hirBufferStatusBufferPoolHitRate
Global buffer pool hit rate (%)
INTEGER
read-only
pdbufls -k sts -d

6.1.7
hirBufferStatusCurrentReferenceBuffers
Current number of reference buffers
INTEGER
read-only
pdbufls -k sts -d

6.1.8
hirBufferStatusCurrentUpdateBuffers
Current number of update buffers
INTEGER
read-only
pdbufls -k sts -d

6.1.9
hirBufferStatusDBSyncs
Number of synchronization points that have occurred
Gauge
read-only
pdbufls -k sts -d

6.1.10
hirBufferStatusLOBBufferInputPages
Number of LOB buffer batch input pages
Gauge
read-only
pdbufls -k sts -d

6.1.11
hirBufferStatusLOBBufferOutputPages
Number of LOB buffer batch output pages
Gauge
read-only
pdbufls -k sts -d

6.1.12
hirBufferStatusLOBBufferReadRequests
Number of LOB buffer read requests
Gauge
read-only
pdbufls -k sts -d

6.1.13
hirBufferStatusLOBBufferWriteRequests
Number of LOB buffer write requests
Gauge
read-only
pdbufls -k sts -d

6.1.14
hirBufferStatusOutOfBuffer
Number of times buffer shortage occurred
Gauge
read-only
pdbufls -k sts -d

6.1.15
hirBufferStatusPrefetchBufferShortages
Number of times prefetch buffer shortage occurred
Gauge
read-only
pdbufls -k sts -d

6.1.16
hirBufferStatusPrefetchHitRate
Prefetch hit rate (%)
INTEGER
read-only
pdbufls -k sts -d

6.1.17
hirBufferStatusPrefetchInputPages
Number of prefetch input pages
Gauge
read-only
pdbufls -k sts -d

6.1.18
hirBufferStatusPrefetchReadRequests
Number of prefetch read requests
Gauge
read-only
pdbufls -k sts -d

6.1.19
hirBufferStatusReads
Number of real read requests from disk
Gauge
read-only
pdbufls -k sts -d

6.1.20
hirBufferStatusReferenceBufferFlushes
Number of reference buffer flushes
Gauge
read-only
pdbufls -k sts -d

6.1.21
hirBufferStatusReferenceGets
Number of reference GETs
Gauge
read-only
pdbufls -k sts -d

6.1.22
hirBufferStatusReferenceHitRate
Reference request hit rate
INTEGER
read-only
pdbufls -k sts -d

6.1.23
hirBufferStatusServerName
Server name
Display
String
read-only
pdbufls -k sts -d

6.1.24
hirBufferStatusUpdateBufferFlushes
Number of update buffer flushes
Gauge
read-only
pdbufls -k sts -d

6.1.25
hirBufferStatusUpdateGets
Number of update GETs
Gauge
read-only
pdbufls -k sts -d

6.1.26
hirBufferStatusUpdateHitRate
Update request hit rate (%)
INTEGER
read-only
pdbufls -k sts -d

6.1.27
hirBufferStatusUpdatedBufferTrigger
Number of update buffers that become output triggers during deferred write triggers
INTEGER
read-only
pdbufls -k sts -d

6.1.28
hirBufferStatusWaits
Number of times buffer lock-release wait occurred
Gauge
read-only
pdbufls -k sts -d

6.1.29
hirBufferStatusWrites
Number of real write operations to disk
Gauge
read-only
pdbufls -k sts -d

6.1.30
hirBufferStatusDummy
Cannot be referenced.
INTEGER
read-only
MIB command

Legend:

: Not applicable

26.10 HiRDB file system area (RDAREAs) table (hirRdareaFileTable)

The HiRDB file system area (RDAREAs) table stores performance information collected over a given time period on a HiRDB file system area for RDAREAs. One line is created for each combination of a HiRDB file system area and an RDAREA.

Notes on collecting performance information

Performance information is collected while HiRDB statistical information is being collected.
Trigger for starting statistical information collection
When the pdstbegin command is executed with fil specified for the statistical information type (-k option) while HiRDB is running
When HiRDB is started by the pdstbegin operand with fil specified for the statistical information type (-k option)
Trigger for terminating statistical information collection
When the pdstend command is executed while HiRDB is running
When HiRDB is terminated

For a shared RDAREA, performance information is collected for each server on a separate line.

Performance information cannot be collected on a unit that is stopped.

Table 26-8 shows the configuration of the HiRDB file system area (RDAREAs) table.

Table 26-8 Configuration of the HiRDB file system area (RDAREAs) table

ID
Object
Explanation
Type
Privilege
Data source

9.
hirRdareaFileTable
HiRDB file system area (RDAREAs) table
SEQUENCE
not-access

9.1
hirRdareaFileEntry
HiRDB file system area entry
SEQUENCE
not-access

9.1.1
hirRdareaFileSysIndex
HiRDB system identifier index
INTEGER
read-only
MIB command

9.1.2
hirRdareaFileServerIndex
Server identifier index
INTEGER
read-only
MIB command

9.1.3
hirRdareaFileFileIndex
HiRDB file identifier index
INTEGER
read-only
MIB command

9.1.4
hirRdareaFileRdareaIndex
RDAREA identifier index
INTEGER
read-only
MIB command

9.1.5
hirRdareaFileInstance
Instance name
HiRDB-identifier:server-name:HiRDB-file-system-area-name:RDAREA
Display
String
read-only
MIB command

9.1.6
hirRdareaFileHirID
HiRDB identifier
Display
String
read-only
MIB command

9.1.7
hirRdareaFileAIORead
System-specific information (AIO READ)
INTEGER
read-only
pdstedit (fil)¹

9.1.8
hirRdareaFileAIOWrite
System-specific information (AIO WRITE)
INTEGER
read-only
pdstedit (fil)¹

9.1.9
hirRdareaFileClose
Number of closing operations that occurred (CLOSE)
INTEGER
read-only
pdstedit (fil)¹

9.1.10
hirRdareaFileFreeMBytes
Size of unused area in the user area (area not allocated as HiRDB files)(KB)
INTEGER
read-only
pdfstatfs FS_NAME

9.1.11
hirRdareaFileHiRDBFileSystemAreaName
HiRDB file system area name (full path) (FS NAME)
Display
String
read-only
pdstedit (fil)²

9.1.12
hirRdareaFileHiRDBFileSystemAreaType
HiRDB file system area type (DB, DB(NOLOB), SVR)
Display
String
read-only
pdfstatfs FS_NAME

9.1.13
hirRdareaFileHost
Host name (HOST)
Display
String
read-only
pdstedit (fil)

9.1.14
hirRdareaFileIOError
Number of input/output errors (IO ERROR)
INTEGER
read-only
pdstedit (fil)¹

9.1.15
hirRdareaFileListIO
System-specific information (LIST IO)
INTEGER
read-only
pdstedit (fil)¹

9.1.16
hirRdareaFileMbytes
Total size of user areas in the HiRDB file system area (MB)
INTEGER
read-only
pdfstatfs FS_NAME

9.1.17
hirRdareaFileOpen
Number of opening operations that occurred (OPEN)
INTEGER
read-only
pdstedit (fil)¹

9.1.18
hirRdareaFileRDAREAName
RDAREA name (RDAREA NAME)
Display
String
read-only
pdstedit (fil)

9.1.19
hirRdareaFileServerName
Server name (SERVER NAME)
Display
String
read-only
pdstedit (fil)

9.1.20
hirRdareaFileSyncRead
Number of synchronous read operations that occurred (SYNC READ)
INTEGER
read-only
pdstedit (fil)¹

9.1.21
hirRdareaFileSyncWrite
Number of synchronous write operations that occurred (SYNC WRITE)
INTEGER
read-only
pdstedit (fil)¹

9.1.22
hirRdareaFileDummy
Cannot be referenced.
INTEGER
read-only
MIB command

Legend:

: Not applicable

Note: Information in parentheses following pdstedit is the edit item in the statistics analysis utility.

¹ Operations are separated into groups based on the combination of RDAREA NAME and HiRDB file system area name obtained by removing the HiRDB file name from HOST, SERVER, and FILE NAME in fil_DAT in order to compute the total of the numeric value data in the fields. Overflow is indicated when ********** is output instead of numeric data, and 0 is set.

² Created by removing the HiRDB file name from the full-path HiRDB file name. For example, /users/hirdb_s/area/rdsys04 is obtained from /users/hirdb_s/area/rdsys04/rddata01.

26.11 SYS statistics table (hirStatisInfSysTable)

The SYS statistics table collects statistical information related to system operations for servers. One line is created for each server.

Notes on collecting performance information

Performance information is collected while HiRDB statistical information is being collected.
Trigger for starting statistical information collection
When the pdstbegin command is executed with sys specified for the statistical information type (-k option) while HiRDB is running
When HiRDB is started by the pdstbegin operand with sys specified for the statistical information type (-k option)
Trigger for terminating statistical information collection
When the pdstend command is executed while HiRDB is running
When HiRDB is terminated

Performance information cannot be collected on a unit that is stopped.

Set the collection interval to be the same as the interval specified in the -m option of the pdstbegin command or the pdstbegin operand.

Table 26-9 shows the configuration of the SYS statistics table.

Table 26-9 Configuration of the SYS statistics table

ID
Object
Explanation
Type
Privilege
Data source

11.
hirStatisInfSysTable
SYS statistics table
SEQUENCE
not-access

11.1
hirStatisInfSysEntry
SYS statistical information entry
SEQUENCE
not-access

11.1.1
hirStatisInfSysSysIndex
HiRDB system identifier index
INTEGER
read-only
MIB command

11.1.2
hirStatisInfSysHostIndex
HiRDB host identifier index
INTEGER
read-only
MIB command

11.1.3
hirStatisInfSysUnitIndex
HiRDB unit identifier index
INTEGER
read-only
MIB command

11.1.4
hirStatisInfSysServerIndex
HiRDB server identifier index
INTEGER
read-only
MIB command

11.1.5
hirStatisInfSysInstance
Instance name
HiRDB-identifier:host-name:server-name
Display
String
read-only
MIB command

11.1.6
hirStatisInfSysHirID
HiRDB identifier
Display
String
read-only
MIB command

11.1.7
hirStatisInfSysHost
Host name (HOST)
Display
String
read-only
pdstedit (sys)

11.1.8
hirStatisInfSysServerName
Server name (SERVER_NAME)
Display
String
read-only
pdstedit (sys)

11.1.9
hirStatisInfSysScheduleQueueLenFreq
Number of scheduling queues that occurred
(SCHEDULE_QUEUE_LEN_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.10
hirStatisInfSysScheduleQueueLenMax
Maximum scheduling queue size (SCHEDULE_QUEUE_LEN_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.11
hirStatisInfSysScheduleQueueLenMin
Minimum scheduling queue size (SCHEDULE_QUEUE_LEN_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.12
hirStatisInfSysScheduleQueueLenAvg
Average scheduling queue size (SCHEDULE_QUEUE_LEN_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.13
hirStatisInfSysMessageLenFreq
Number of schedule messages issued (MESSAGE_LEN_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.14
hirStatisInfSysMessageLenMax
Maximum schedule message size (MESSAGE_LEN_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.15
hirStatisInfSysMessageLenMin
Minimum schedule message size (MESSAGE_LEN_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.16
hirStatisInfSysMessageLenAvg
Average schedule message size (MESSAGE_LEN_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.17
hirStatisInfSysServerAbort
Number of times servers terminated abnormally (SERVER_ABORT)³
INTEGER
read-only
pdstedit (sys)

11.1.18
hirStatisInfSysSystemServerAbort
Number of times internal servers used by HiRDB terminated abnormally (SYSTEM_SERVER_ABORT)³
INTEGER
read-only
pdstedit (sys)

11.1.19
hirStatisInfSysProcessCountMax
Maximum number of processes generated (PROCESS_COUNT_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.20
hirStatisInfSysProcessCountMin
Minimum number of processes generated (PROCESS_COUNT_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.21
hirStatisInfSysProcessCountAvg
Average number of processes generated (PROCESS_COUNT_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.22
hirStatisInfSysCommit
Number of commits (COMMIT)³
INTEGER
read-only
pdstedit (sys)

11.1.23
hirStatisInfSysRollback
Number of rollbacks (ROLLBACK)³
INTEGER
read-only
pdstedit (sys)

11.1.24
hirStatisInfSysLockWaitTimeFreq
Number of lock-release waits that occurred (LOCK_WAIT_TIME_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.25
hirStatisInfSysLockWaitTimeMax
Maximum lock-release wait time (LOCK_WAIT_TIME_MAX)¹ (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.26
hirStatisInfSysLockWaitTimeMin
Minimum lock-release wait time (LOCK_WAIT_TIME_MIN)² (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.27
hirStatisInfSysLockWaitTimeAvg
Average lock-release wait time (LOCK_WAIT_TIME_AVG)³ (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.28
hirStatisInfSysLockQueueLenFreq
Number of users who had to wait for lock release (LOCK_QUEUE_LEN_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.29
hirStatisInfSysLockQueueLenMax
Maximum number of users who had to wait for lock release (LOCK_QUEUE_LEN_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.30
hirStatisInfSysLockQueueLenMin
Minimum number of users who had to wait for lock release (LOCK_QUEUE_LEN_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.31
hirStatisInfSysLockQueueLenAvg
Average number of users who had to wait for lock release (LOCK_QUEUE_LEN_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.32
hirStatisInfSysDeadlock
Number of deadlocks (DEADLOCK)³
INTEGER
read-only
pdstedit (sys)

11.1.33
hirStatisInfSysUseLockTableFreq
Number of phenomena that increased the usage rate of the table for managing locked resources by at least 5% (USE_LOCK_TABLE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.34
hirStatisInfSysUseLockTableMax
Maximum usage rate of the table for managing locked resources (USE_LOCK_TABLE_MAX)¹ (%)
INTEGER
read-only
pdstedit (sys)

11.1.35
hirStatisInfSysUseLockTableMin
Minimum usage rate of the table for managing locked resources (USE_LOCK_TABLE_MIN)² (%)
INTEGER
read-only
pdstedit (sys)

11.1.36
hirStatisInfSysUseLockTableAvg
Average usage rate of the table for managing locked resources (USE_LOCK_TABLE_AVG)³ (%)
INTEGER
read-only
pdstedit (sys)

11.1.37
hirStatisInfSysSegmentSizeAvg
Average size of shared memory allocated to servers and internal servers used by HiRDB (SEGMENT_SIZE_AVG)³ (KB)
INTEGER
read-only
pdstedit (sys)

11.1.38
hirStatisInfSysStaticSizeAvg
Average size of the allocated static shared memory (STATIC_SIZE_AVG)³ (KB)
INTEGER
read-only
pdstedit (sys)

11.1.39
hirStatisInfSysDyanamicSizeAvg
Average size of the allocated dynamic shared memory (DYNAMIC_SIZE_AVG)³ (KB)
INTEGER
read-only
pdstedit (sys)

11.1.40
hirStatisInfSysSizeForBufferAvg
Average size of the allocated shared memory for global buffers (SIZE_FOR_BUFFER_AVG)³ (KB)
INTEGER
read-only
pdstedit (sys)

11.1.41
hirStatisInfSysSyncGetIntervalTimeFreq
Number of synchronization point dumps collected (SYNC_GET_INTERVAL_TIME_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.42
hirStatisInfSysSyncGetIntervalTimeMax
Maximum interval for collecting a synchronization point dump (SYNC_GET_INTERVAL_TIME_MAX)¹ (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.43
hirStatisInfSysSyncGetIntervalTimeMin
Minimum interval for collecting a synchronization point dump (SYNC_GET_INTERVAL_TIME_MIN)² (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.44
hirStatisInfSysSyncGetIntervalTimeAvg
Average interval for collecting a synchronization point dump (SYNC_GET_INTERVAL_TIME_AVG)³ (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.45
hirStatisInfSysSyncGetTimeFreq
Number of synchronization point dumps collected (SYNC_GET_TIME_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.46
hirStatisInfSysSyncGetTimeMax
Maximum time required for collecting a synchronization point dump (SYNC_GET_TIME_MAX)¹ (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.47
hirStatisInfSysSyncGetTimeMin
Minimum time required for collecting a synchronization point dump (SYNC_GET_TIME_MIN)² (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.48
hirStatisInfSysSyncGetTimeAvg
Average time required for collecting a synchronization point dump (SYNC_GET_TIME_AVG)³ (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.49
hirStatisInfSysLogBufferFull
Number of times the log buffer was full (LOG_BUFFER_FULL)³
INTEGER
read-only
pdstedit (sys)

11.1.50
hirStatisInfSysLogWaitThread
Number of times log input/output had to wait because no current buffer was available (LOG_WAIT_THREAD)³
INTEGER
read-only
pdstedit (sys)

11.1.51
hirStatisInfSysLogOutputBlockLenFreq
Number of times log block was output (LOG_OUTPUT_BLOCK_LEN_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.52
hirStatisInfSysLogOutputBlockLenMax
Maximum log output block size (LOG_OUTPUT_BLOCK_LEN_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.53
hirStatisInfSysLogOutputBlockLenMin
Management log output block size (LOG_OUTPUT_BLOCK_LEN_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.54
hirStatisInfSysLogOutputBlockLenAvg
Average log output block size (LOG_OUTPUT_BLOCK_LEN_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.55
hirStatisInfSysLogNotBusLenFreq
Number of times log was output in non-bus area (LOG_NOT_BUS_LEN_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.56
hirStatisInfSysLogNotBusLenMax
Maximum log block size in non-bus area (LOG_NOT_BUS_LEN_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.57
hirStatisInfSysLogNotBusLenMin
Minimum log block size in non-bus area (LOG_NOT_BUS_LEN_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.58
hirStatisInfSysLogNotBusLenAvg
Average log block size in non-bus area (LOG_NOT_BUS_LEN_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.59
hirStatisInfSysLogWaitBufferForIOFreq
Number of cases in which the system had to wait for log input/output completion (LOG_WAIT_BUFFER_FOR_IO_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.60
hirStatisInfSysLogWaitBufferForIOMax
Maximum number of buffer sectors waiting for log input/output (LOG_WAIT_BUFFER_FOR_IO_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.61
hirStatisInfSysLogWaitBufferForIOMin
Minimum number of buffer sectors waiting for log input/output (LOG_WAIT_BUFFER_FOR_IO_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.62
hirStatisInfSysLogWaitBufferForIOAvg
Average number of buffer sectors waiting for log input/output (LOG_WAIT_BUFFER_FOR_IO_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.63
hirStatisInfSysLogWriteToFile
Number of times data was written into system log file (LOG_WRITE_TO_FILE)³
INTEGER
read-only
pdstedit (sys)

11.1.64
hirStatisInfSysLogWriteError
Number of log write errors (LOG_WRITE_ERROR)³
INTEGER
read-only
pdstedit (sys)

11.1.65
hirStatisInfSysLogFileSwapTimeFreq
Number of times log files were swapped (LOG_FILE_SWAP_TIME_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.66
hirStatisInfSysLogFileSwapTimeMax
Maximum time for log file swapping (LOG_FILE_SWAP_TIME_MAX)¹ (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.67
hirStatisInfSysLogFileSwapTimeMin
Minimum time for log file swapping (LOG_FILE_SWAP_TIME_MIN)² (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.68
hirStatisInfSysLogFileSwapTimeAvg
Average time for log file swapping (LOG_FILE_SWAP_TIME_AVG)³ (milliseconds)
INTEGER
read-only
pdstedit (sys)

11.1.69
hirStatisInfSysLogInputDataFreq
Number of logs that were input during rollback (LOG_INPUT_DATA_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.70
hirStatisInfSysLogInputDataMax
Maximum size of log input data during rollback (LOG_INPUT_DATA_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.71
hirStatisInfSysLogInputDataMin
Minimum size of log input data during rollback (LOG_INPUT_DATA_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.72
hirStatisInfSysLogInputDataAvg
Average size of log input data during rollback (LOG_INPUT_DATA_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.73
hirStatisInfSysLogReadFromFile
Number of times logs were read during rollback (LOG_READ_FROM_FILE)³
INTEGER
read-only
pdstedit (sys)

11.1.74
hirStatisInfSysLogReadError
Number of log read errors (LOG_READ_ERROR)³
INTEGER
read-only
pdstedit (sys)

11.1.75
hirStatisInfSysDicTblDEFGetReq
Number of requests for collecting table definition information (DIC_TBL-DEF_GET_REQ)³
INTEGER
read-only
pdstedit (sys)

11.1.76
hirStatisInfSysDicTableCacheHit
Number of hits for the buffer for table definition information (DIC_TABLE_CACHE_HIT)³
INTEGER
read-only
pdstedit (sys)

11.1.77
hirStatisInfSysDicCachedTblDEFFreq
Number of definition information items in the buffer for table definition information (DIC_CACHED_TBL-DEF_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.78
hirStatisInfSysDicCachedTblDEFMax
Maximum number of definition information items in the buffer for table definition (DIC_CACHED_TBL-DEF_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.79
hirStatisInfSysDicCachedTblDEFMin
Minimum number of definition information items in the buffer for table definition (DIC_CACHED_TBL-DEF_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.80
hirStatisInfSysDicCachedTblDEFAvg
Average number of definition information items in the buffer for table definition (DIC_CACHED_TBL-DEF_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.81
hirStatisInfSysDicUseTblDEFSizeFreq
Number of definition information items collected in the buffer for table definition information (DIC_USE_TBL-DEF_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.82
hirStatisInfSysDicUseTblDEFSizeMax
Maximum size of the area used in the buffer for table definition information per item of table definition information collected in the buffer for table definition information (DIC_USE_TBL-DEF_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.83
hirStatisInfSysDicUseTblDEFSizeMin
Minimum size of the area used in the buffer for table definition information per item of table definition information collected in the buffer for table definition information (DIC_USE_TBL-DEF_SIZE_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.84
hirStatisInfSysDicUseTblDEFSizeAvg
Average size of the area used in the buffer for table definition information per item of table definition information collected in the buffer for table definition information (DIC_USE_TBL-DEF_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.85
hirStatisInfSysDicCacheTblDEFSizeFreq
Number of table definition information items in the buffer for table definition information (DIC_CACHED_TBL-DEF_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.86
hirStatisInfSysDicCacheTblDEFSizeMax
Maximum size of the area used in the buffer for table definition information (DIC_CACHED_TBL-DEF_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.87
hirStatisInfSysDicCacheTblDEFSizeMin
Minimum size of the area used in the buffer for table definition information (DIC_CACHED_TBL-DEF_SIZE_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.88
hirStatisInfSysDicCacheTblDEFSizeAvg
Average size of the area used in the buffer for table definition information (DIC_CACHED_TBL-DEF_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.89
hirStatisInfSysDicAccessPrivCheck
Number of times table access privilege information was collected (DIC_ACCESS_PRIV_CHECK)³
INTEGER
read-only
pdstedit (sys)

11.1.90
hirStatisInfSysDicAccessCacheHit
Number of hits for the buffer for table access privilege information (DIC_ACCESS_CACHE_HIT)³
INTEGER
read-only
pdstedit (sys)

11.1.91
hirStatisInfSysDicConDbaDefGetReq
Number of requests for collecting user privilege information (DIC_CON/DBA_DEF_GET_REQ)³
INTEGER
read-only
pdstedit (sys)

11.1.92
hirStatisInfSysDicConDbaCacheHit
Number of hits for the buffer for user privilege information (DIC_CON/DBA_CACHE_HIT)³
INTEGER
read-only
pdstedit (sys)

11.1.93
hirStatisInfSysDicConDbaCachedUserFreq
Number of users using the buffer for user privilege information (DIC_CON/DBA_CACHED_USER_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.94
hirStatisInfSysDicConDbaCachedUserMax
Maximum number of users using the buffer for user privilege information (DIC_CON/DBA_CACHED_USER_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.95
hirStatisInfSysDicConDbaCachedUserMin
Minimum number of users using the buffer for user privilege information (DIC_CON/DBA_CACHED_USER_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.96
hirStatisInfSysDicConDbaCachedUserAvg
Average number of users using the buffer for user privilege information (DIC_CON/DBA_CACHED_USER_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.97
hirStatisInfSysDicTransDataLenFreq
Number of requests for collecting table definition information (DIC_TRANS_DATA_LEN_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.98
hirStatisInfSysDicTransDataLenMax
Maximum size of communications with the dictionary server (DIC_TRANS_DATA_LEN_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.99
hirStatisInfSysDicTransDataLenMin
Minimum size of communications with the dictionary server (DIC_TRANS_DATA_LEN_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.100
hirStatisInfSysDicTransDataLenAvg
Average size of communications with the dictionary server (DIC_TRANS_DATA_LEN_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.101
hirStatisInfSysDicTrans
Number of times communication occurred with the dictionary server (DIC_TRANS)³
INTEGER
read-only
pdstedit (sys)

11.1.102
hirStatisInfSysDicViewDefGetReq
Number of requests for collecting view analysis information (DIC_VIEW_DEF_GET_REQ)³
INTEGER
read-only
pdstedit (sys)

11.1.103
hirStatisInfSysDicViewDefCacheHit
Number of hits for the buffer for view analysis information (DIC_VIEW_DEF_CACHE_HIT)³
INTEGER
read-only
pdstedit (sys)

11.1.104
hirStatisInfSysDicViewCachedDef
Number of analysis information items in the buffer for view analysis information (DIC_VIEW_CACHED_DEF)³
INTEGER
read-only
pdstedit (sys)

11.1.105
hirStatisInfSysDicUsedViewSizeFreq
Number of analysis information items collected in the buffer for view analysis information (DIC_USED_VIEW_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.106
hirStatisInfSysDicUsedViewSizeMax
Maximum size of the area used in the buffer for view analysis information per view collected in the buffer for view analysis information (DIC_USED_VIEW_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.107
hirStatisInfSysDicUsedViewSizeMin
Minimum size of the area used in the buffer for view analysis information per view collected in the buffer for view analysis information (DIC_USED_VIEW_SIZE_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.108
hirStatisInfSysDicUsedViewSizeAvg
Average size of the area used in the buffer for view analysis information per view collected in the buffer for view analysis information (DIC_USED_VIEW_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.109
hirStatisInfSysDicViewCacheSizeFreq
Number of view analysis information items in the buffer for view analysis information (DIC_VIEW_CACHE_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.110
hirStatisInfSysDicViewCacheSizeMax
Maximum size of the buffer for view analysis information used (DIC_VIEW_CACHE_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.111
hirStatisInfSysDicViewCacheSizeMin
Minimum size of the buffer for view analysis information used (DIC_VIEW_CACHE_SIZE_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.112
hirStatisInfSysDicViewCacheSizeAvg
Average size of the buffer for view analysis information used (DIC_VIEW_CACHE_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.113
hirStatisInfSysDicCacheMissViewSizeFreq
Number of times the buffer for view analysis information was missed (DIC_CACHE_MISS_VIEW_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.114
hirStatisInfSysDicCacheMissViewSizeMax
Maximum size of the view analysis information that caused a buffer miss (DIC_CACHE_MISS_VIEW_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.115
hirStatisInfSysDicCacheMissViewSizeMin
Minimum size of the view analysis information that caused a buffer miss (DIC_CACHE_MISS_VIEW_SIZE_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.116
hirStatisInfSysDicCacheMissViewSizeAvg
Average size of the view analysis information that caused a buffer miss (DIC_CACHE_MISS_VIEW_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.117
hirStatisInfSysSQLOBJGetReq
Number of requests for collecting SQL objects (SQLOBJ_GET_REQ)³
INTEGER
read-only
pdstedit (sys)

11.1.118
hirStatisInfSysSQLOBJCacheHit
Number of hits for the SQL object buffer (SQLOBJ_CACHE_HIT)³
INTEGER
read-only
pdstedit (sys)

11.1.119
hirStatisInfSysCachedSQLOBJFreq
Number of SQL objects in the SQL object buffer (CACHED_SQLOBJ_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.120
hirStatisInfSysCachedSQLOBJMax
Maximum number of SQL objects in the SQL object buffer (CACHED_SQLOBJ_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.121
hirStatisInfSysCachedSQLOBJMin
Minimum number of SQL objects in the SQL object buffer (CACHED_SQLOBJ_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.122
hirStatisInfSysCachedSQLOBJAvg
Average number of SQL objects in the SQL object buffer (CACHED_SQLOBJ_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.123
hirStatisInfSysCachedSQLOBJSizeFreq
Number of SQL objects in the SQL object buffer (CACHED_SQLOBJ_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.124
hirStatisInfSysCachedSQLOBJSizeMax
Maximum value of the combined total size of objects in the SQL object buffer (CACHED_SQLOBJ_SIZE_MAX)¹ (KB)
INTEGER
read-only
pdstedit (sys)

11.1.125
hirStatisInfSysCachedSQLOBJSizeMin
Minimum value of the combined total size of objects in the SQL object buffer (CACHED_SQLOBJ_SIZE_MIN)² (KB)
INTEGER
read-only
pdstedit (sys)

11.1.126
hirStatisInfSysCachedSQLOBJSizeAvg
Average value of the combined total size of objects in the SQL object buffer (CACHED_SQLOBJ_SIZE_AVG)³ (KB)
INTEGER
read-only
pdstedit (sys)

11.1.127
hirStatisInfSysSwapOutSQLOBJ
Number of SQL objects taken out of the SQL object buffer (SWAP_OUT_SQLOBJ)³
INTEGER
read-only
pdstedit (sys)

11.1.128
hirStatisInfSysSQLOBJLenFreq
Number of SQL objects in the SQL object buffer (SQLOBJ_LEN_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.129
hirStatisInfSysSQLOBJLenMax
Maximum size of SQL objects in the SQL object buffer (SQLOBJ_LEN_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.130
hirStatisInfSysSQLOBJLenMin
Minimum size of SQL objects in the SQL object buffer (SQLOBJ_LEN_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.131
hirStatisInfSysSQLOBJLenAvg
Average size of SQL objects in the SQL object buffer (SQLOBJ_LEN_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.132
hirStatisInfSysSTROBJGetReq
Number of requests to collect stored procedure objects (STROBJ_GET_REQ)³
INTEGER
read-only
pdstedit (sys)

11.1.133
hirStatisInfSysSTROBJCacheHit
Number of SQL object buffer hits by stored procedure objects (STROBJ_CACHE_HIT)³
INTEGER
read-only
pdstedit (sys)

11.1.134
hirStatisInfSysCachedSTROBJFreq
Number of stored procedure objects in the SQL object buffer (CACHED_STROBJ_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.135
hirStatisInfSysCachedSTROBJMax
Maximum number of stored procedure objects in the SQL object buffer (CACHED_STROBJ_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.136
hirStatisInfSysCachedSTROBJMin
Minimum number of stored procedure objects in the SQL object buffer (CACHED_STROBJ_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.137
hirStatisInfSysCachedSTROBJAvg
Average number of stored procedure objects in the SQL object buffer (CACHED_STROBJ_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.138
hirStatisInfSysCachedSTROBJSizeFreq
Number of stored procedure objects in the SQL object buffer (CACHED_STROBJ_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.139
hirStatisInfSysCachedSTROBJSizeMax
Maximum value of the combined total size of stored procedure objects in the SQL object buffer (CACHED_STROBJ_SIZE_MAX)¹ (KB)
INTEGER
read-only
pdstedit (sys)

11.1.140
hirStatisInfSysCachedSTROBJSizeMin
Minimum value of the combined total size of stored procedure objects in the SQL object buffer (CACHED_STROBJ_SIZE_MIN)² (KB)
INTEGER
read-only
pdstedit (sys)

11.1.141
hirStatisInfSysCachedSTROBJSizeAvg
Average value of the combined total size of stored procedure objects in the SQL object buffer (CACHED_STROBJ_SIZE_AVG)³ (KB)
INTEGER
read-only
pdstedit (sys)

11.1.142
hirStatisInfSysSwapOutSTROBJ
Number of stored procedure objects taken out of the SQL object buffer (SWAP_OUT_STROBJ)³
INTEGER
read-only
pdstedit (sys)

11.1.143
hirStatisInfSysSTROBJLenFreq
Number of stored procedure objects in the SQL object buffer (STROBJ_LEN_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.144
hirStatisInfSysSTROBJLenMax
Maximum size of stored procedure objects in the SQL object buffer (STROBJ_LEN_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.145
hirStatisInfSysSTROBJLenMin
Minimum size of stored procedure objects in the SQL object buffer (STROBJ_LEN_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.146
hirStatisInfSysSTROBJLenAvg
Average size of stored procedure objects in the SQL object buffer (STROBJ_LEN_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.147
hirStatisInfSysSTROBJRecompile
Number of times stored procedure objects were recompiled (STROBJ_RECOMPILE)³
INTEGER
read-only
pdstedit (sys)

11.1.148
hirStatisInfSysProcessServiceCountMax
Maximum number of server processes that are executing service (PROCESS_SERVICE_COUNT_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.149
hirStatisInfSysProcessServiceCountMin
Minimum number of server processes that are executing service (PROCESS_SERVICE_COUNT_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.150
hirStatisInfSysProcessServiceCountAvg
Average number of server processes that are executing service (PROCESS_SERVICE_COUNT_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.151
hirStatisInfSysProcessRequestOver
Number of service requests exceeding the maximum number of processes that can be activated (PROCESS_REQUEST_OVER)³
INTEGER
read-only
pdstedit (sys)

11.1.152
hirStatisInfSysResponseOnOwnUnitFreq
Number of service responses to the local unit server (RESPONSE_ON_OWN_UNIT_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.153
hirStatisInfSysResponseOnOwnUnitMax
Maximum service response time to the local unit server (RESPONSE_ON_OWN_UNIT_MAX)¹ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.154
hirStatisInfSysResponseOnOwnUnitMin
Minimum service response time to the local unit server (RESPONSE_ON_OWN_UNIT_MIN)² (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.155
hirStatisInfSysResponseOnOwnUnitAvg
Average service response time to the local unit server (RESPONSE_ON_OWN_UNIT_AVG)³ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.156
hirStatisInfSysResponseToOtherUnitFreq
Number of service responses to other unit servers (RESPONSE_TO_OTHER_UNIT_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.157
hirStatisInfSysResponseToOtherUnitMax
Maximum service response time to other unit servers (RESPONSE_TO_OTHER_UNIT_MAX)¹ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.158
hirStatisInfSysResponseToOtherUnitMin
Minimum service response time to other unit servers (RESPONSE_TO_OTHER_UNIT_MIN)² (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.159
hirStatisInfSysResponseToOtherUnitAvg
Average service response time to other unit servers (RESPONSE_TO_OTHER_UNIT_AVG)³ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.160
hirStatisInfSysExecTimeOnOwnUnitFreq
Number of executions per service from the local unit server (EXEC_TIME_ON_OWN_UNIT_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.161
hirStatisInfSysExecTimeOnOwnUnitMax
Maximum execution time per service from the local unit server (EXEC_TIME_ON_OWN_UNIT_MAX)¹ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.162
hirStatisInfSysExecTimeOnOwnUnitMin
Minimum execution time per service from the local unit server (EXEC_TIME_ON_OWN_UNIT_MIN)² (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.163
hirStatisInfSysExecTimeOnOwnUnitAvg
Average execution time per service from the local unit server (EXEC_TIME_ON_OWN_UNIT_AVG)³ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.164
hirStatisInfSysExecTimeFromOtherUnitFreq
Number of executions per service from other unit servers (EXEC_TIME_FROM_OTHER_UNIT_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.165
hirStatisInfSysExecTimeFromOtherUnitMax
Maximum execution time per service from other unit servers (EXEC_TIME_FROM_OTHER_UNIT_MAX)¹ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.166
hirStatisInfSysExecTimeFromOtherUnitMin
Minimum execution time per service from other unit servers (EXEC_TIME_FROM_OTHER_UNIT_MIN)² (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.167
hirStatisInfSysExecTimeFromOtherUnitAvg
Average execution time per service from other unit servers (EXEC_TIME_FROM_OTHER_UNIT_AVG)³ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.168
hirStatisInfSysSendToOwnProcs
Number of send operations to the local process (SEND_TO_OWN_PRCS)³
INTEGER
read-only
pdstedit (sys)

11.1.169
hirStatisInfSysSendToOtherPrcs
Number of send operations to other processes within the local unit (SEND_TO_OTHER_PRCS)³
INTEGER
read-only
pdstedit (sys)

11.1.170
hirStatisInfSysSendToOtherUnit
Number of send operations to other units (SEND_TO_OTHER_UNIT)³
INTEGER
read-only
pdstedit (sys)

11.1.171
hirStatisInfSysReceiveFromOwnPrcs
Number of receive operations from the local process (RECEIVE_FROM_OWN_PRCS)³
INTEGER
read-only
pdstedit (sys)

11.1.172
hirStatisInfSysReceiveFromOtherPrcs
Number of receive operations from other processes within the local unit (RECEIVE_FROM_OTHER_PRCS)³
INTEGER
read-only
pdstedit (sys)

11.1.173
hirStatisInfSysReceiveFromOtherUnit
Number of receive operations from other units (RECEIVE_FROM_OTHER_UNIT)³
INTEGER
read-only
pdstedit (sys)

11.1.174
hirStatisInfSysTypeDEFGetReq
Number of requests for collecting type information (TYPE-DEF_GET_REQ)³
INTEGER
read-only
pdstedit (sys)

11.1.175
hirStatisInfSysTypeDEFCacheHit
Number of hits for the user-defined type information buffer (TYPE-DEF_CACHE_HIT)³
INTEGER
read-only
pdstedit (sys)

11.1.176
hirStatisInfSysCachedTypeDEFFreq
Number of type definition information items in the user-defined type information buffer (CACHED_TYPE-DEF_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.177
hirStatisInfSysCachedTypeDEFMax
Maximum number of type definition information items in the user-defined type information buffer (CACHED_TYPE-DEF_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.178
hirStatisInfSysCachedTypeDEFMin
Minimum number of type definition information items in the user-defined type information buffer (CACHED_TYPE-DEF_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.179
hirStatisInfSysCachedTypeDEFAvg
Average number of type definition information items in the user-defined type information buffer (CACHED_TYPE-DEF_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.180
hirStatisInfSysTypeDEFCacheSizeFreq
Number of type definition information items in the user-defined type information buffer (TYPE-DEF_CACHE_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.181
hirStatisInfSysTypeDEFCacheSizeMax
Maximum size of the buffer area used for one type definition information item collected in the user-defined type information buffer (TYPE-DEF_CACHE_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.182
hirStatisInfSysTypeDEFCacheSizeMin
Minimum size of the buffer area used for one type definition information item collected in the user-defined type information buffer (TYPE-DEF_CACHE_SIZE_MIN)²
(bytes)
INTEGER
read-only
pdstedit (sys)

11.1.183
hirStatisInfSysTypeDEFCacheSizeAvg
Average size of the buffer area used for one type definition information item collected in the user-defined type information buffer (TYPE-DEF_CACHE_SIZE_AVG)³
(bytes)
INTEGER
read-only
pdstedit (sys)

11.1.184
hirStatisInfSysTypeDEFCacheTotalSizeFreq
Number of user-defined type information items collected (TYPE-DEF_CACHE_TOTAL_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.185
hirStatisInfSysTypeDEFCacheTotalSizeMax
Maximum size of the total area used for user-defined type information buffers (TYPE-DEF_CACHE_TOTAL_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.186
hirStatisInfSysTypeDEFCacheTotalSizeMin
Minimum size of the total area used for user-defined type information buffers (TYPE-DEF_CACHE_TOTAL_SIZE_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.187
hirStatisInfSysTypeDEFCacheTotalSizeAvg
Average size of the total area used for user-defined type information buffers (TYPE-DEF_CACHE_TOTAL_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.188
hirStatisInfSysTypeDEFCacheAllocSizeFreq
Number of user-defined type information buffers allocated (TYPE-DEF_CACHE_ALLOC_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.189
hirStatisInfSysTypeDEFCacheAllocSizeMax
Maximum size of the user-defined type information buffers allocated (TYPE-DEF_CACHE_ALLOC_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.190
hirStatisInfSysTypeDEFCacheAllocSizeMin
Minimum size of the user-defined type information buffers allocated (TYPE-DEF_CACHE_ALLOC_SIZE_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.191
hirStatisInfSysTypeDEFCacheAllocSizeAvg
Average size of the user-defined type information buffers allocated (TYPE-DEF_CACHE_ALLOC_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.192
hirStatisInfSysRtnDEFGetReq
Number of requests for collecting routine definition information (RTN-DEF_GET_REQ)³
INTEGER
read-only
pdstedit (sys)

11.1.193
hirStatisInfSysRtnDEFCacheHit
Number of hits for the routine definition information buffer (RTN-DEF_CACHE_HIT)³
INTEGER
read-only
pdstedit (sys)

11.1.194
hirStatisInfSysCachedRtnDEFFreq
Number of routine definition information items in the routine definition information buffer (CACHED_RTN-DEF_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.195
hirStatisInfSysCachedRtnDEFMax
Maximum number of routine definition information items in the routine definition information buffer (CACHED_RTN-DEF_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.196
hirStatisInfSysCachedRtnDEFMin
Minimum number of routine definition information items in the routine definition information buffer (CACHED_RTN-DEF_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.197
hirStatisInfSysCachedRtnDEFAvg
Average number of routine definition information items in the routine definition information buffer (CACHED_RTN-DEF_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.198
hirStatisInfSysRtnDEFCacheSizeFreq
Number of routine definition information items in the routine definition information buffer (RTN-DEF_CACHE_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.199
hirStatisInfSysRtnDEFCacheSizeMax
Maximum size of the buffer area used for one routine definition information item collected in the routine definition information buffer (RTN-DEF_CACHE_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.200
hirStatisInfSysRtnDEFCacheSizeMin
Minimum size of the buffer area used for one routine definition information item collected in the routine definition information buffer (RTN-DEF_CACHE_SIZE_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.201
hirStatisInfSysRtnDEFCacheSizeAvg
Average size of the buffer area used for one routine definition information item collected in the routine definition information buffer (RTN-DEF_CACHE_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.202
hirStatisInfSysRtnDEFCacheTotalSizeFreq
Number of routine definition information items in the routine definition information buffer (RTN-DEF_CACHE_TOTAL_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.203
hirStatisInfSysRtnDEFCacheTotalSizeMax
Maximum size of the total area used for routine definition information buffers (RTN-DEF_CACHE_TOTAL_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.204
hirStatisInfSysRtnDEFCacheTotalSizeMin
Minimum size of the total area used for routine definition information buffers (RTN-DEF_CACHE_TOTAL_SIZE_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.205
hirStatisInfSysRtnDEFCacheTotalSizeAvg
Average size of the total area used for routine definition information buffers (RTN-DEF_CACHE_TOTAL_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.206
hirStatisInfSysRtnDEFCacheAllocSizeFreq
Number of routine definition information buffers allocated (RTN-DEF_CACHE_ALLOC_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.207
hirStatisInfSysRtnDEFCacheAllocSizeMax
Maximum size of the routine definition information buffers allocated (RTN-DEF_CACHE_ALLOC_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.208
hirStatisInfSysRtnDEFCacheAllocSizeMin
Minimum size of the routine definition information buffers allocated (RTN-DEF_CACHE_ALLOC_SIZE_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.209
hirStatisInfSysRtnDEFCacheAllocSizeAvg
Average size of the routine definition information buffers allocated (RTN-DEF_CACHE_ALLOC_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.210
hirStatisInfSysPlgRTNGetReq
Number of requests for collecting routine definitions of functions provided by plug-ins (PLG-RTN_GET_REQ)³
INTEGER
read-only
pdstedit (sys)

11.1.211
hirStatisInfSysPlgRTNCacheHit
Number of hits for the buffer for routine definition information of functions provided by plug-ins (PLG-RTN_CACHE_HIT)³
INTEGER
read-only
pdstedit (sys)

11.1.212
hirStatisInfSysRegistryGetReq
Number of requests for collecting registry information (REGISTRY_GET_REQ)³
INTEGER
read-only
pdstedit (sys)

11.1.213
hirStatisInfSysRegistryCacheHit
Number of hits for the registry information buffer (REGISTRY_CACHE_HIT)³
INTEGER
read-only
pdstedit (sys)

11.1.214
hirStatisInfSysCachedRegistryDEFFreq
Number of registry information items in the registry information buffer (CACHED_REGISTRY-DEF_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.215
hirStatisInfSysCachedRegistryDEFMax
Maximum number of registry information items in the registry information buffer (CACHED_REGISTRY-DEF_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.216
hirStatisInfSysCachedRegistryDEFMin
Minimum number of registry information items in the registry information buffer (CACHED_REGISTRY-DEF_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.217
hirStatisInfSysCachedRegistryDEFAvg
Average number of registry information items in the registry information buffer (CACHED_REGISTRY-DEF_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.218
hirStatisInfSysRegistryCacheSizeFreq
Number of registry information items in the registry information buffer (REGISTRY_CACHE_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.219
hirStatisInfSysRegistryCacheSizeMax
Maximum size of the registry information buffer per registry information item (REGISTRY_CACHE_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.220
hirStatisInfSysRegistryCacheSizeMin
Minimum size of the registry information buffer per registry information item (REGISTRY_CACHE_SIZE_MIN)² (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.221
hirStatisInfSysRegistryCacheSizeAvg
Average size of the registry information buffer per registry information item (REGISTRY_CACHE_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.222
hirStatisInfSysRegistryCacheTotalSizeFreq
Number of registry information items in the registry information buffer (REGISTRY_CACHE_TOTAL_SIZE_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.223
hirStatisInfSysRegistryCacheTotalSizeMax
Maximum size of the total area used for the registry information buffer (REGISTRY_CACHE_TOTAL_SIZE_MAX)¹ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.224
hirStatisInfSysRegistryCacheTotalSizeMin
Minimum size of the total area used for the registry information buffer (REGISTRY_CACHE_TOTAL_SIZE_MIN)²
(bytes)
INTEGER
read-only
pdstedit (sys)

11.1.225
hirStatisInfSysRegistryCacheTotalSizeAvg
Average size of the total area used for the registry information buffer (REGISTRY_CACHE_TOTAL_SIZE_AVG)³ (bytes)
INTEGER
read-only
pdstedit (sys)

11.1.226
hirStatisInfSysRegisterdPortsFreq
Number of HiRDB reserved ports used (REGISTERED_PORTS_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.227
hirStatisInfSysRegisterdPortsMax
Maximum number of HiRDB reserved ports used (REGISTERED_PORTS_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.228
hirStatisInfSysRegisterdPortsMin
Minimum number of HiRDB reserved ports used (REGISTERED_PORTS_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.229
hirStatisInfSysRegisterdPortsAvg
Average number of HiRDB reserved ports used (REGISTERED_PORTS_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.230
hirStatisInfSysAssignedPortsFreq
Number of ports allocated automatically by the OS when the number of HiRDB reserved ports was insufficient (ASSIGNED_PORTS_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.231
hirStatisInfSysAssignedPortsMax
Maximum number of ports allocated automatically by the OS when the number of HiRDB reserved ports was insufficient (ASSIGNED_PORTS_MAX)¹
INTEGER
read-only
pdstedit (sys)

11.1.232
hirStatisInfSysAssignedPortsMin
Minimum number of ports allocated automatically by the OS when the number of HiRDB reserved ports was insufficient (ASSIGNED_PORTS_MIN)²
INTEGER
read-only
pdstedit (sys)

11.1.233
hirStatisInfSysAssignedPortsAvg
Average number of ports allocated automatically by the OS when the number of HiRDB reserved ports was insufficient (ASSIGNED_PORTS_AVG)³
INTEGER
read-only
pdstedit (sys)

11.1.234
hirStatisInfSysDirectoryUserCheckTimeFreq
Number of requests for authenticating directory-registered users (DIRECTORY_USER_CHECK_TIME_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.235
hirStatisInfSysDirectoryUserCheckTimeMax
Maximum time for authenticating directory-registered users (DIRECTORY_USER_CHECK_TIME_MAX)¹ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.236
hirStatisInfSysDirectoryUserCheckTimeMin
Minimum time for authenticating directory-registered users (DIRECTORY_USER_CHECK_TIME_MIN)² (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.237
hirStatisInfSysDirectoryUserCheckTimeAvg
Average time for authenticating directory-registered users (DIRECTORY_USER_CHECK_TIME_AVG)³ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.238
hirStatisInfSysGroupCheckTimeFreq
Number of requests for checking groups (GROUP_CHECK_TIME_FREQ)³
INTEGER
read-only
pdstedit (sys)

11.1.239
hirStatisInfSysGroupCheckTimeMax
Maximum time for checking a group (GROUP_CHECK_TIME_MAX)¹ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.240
hirStatisInfSysGroupCheckTimeMin
Minimum time for checking a group (GROUP_CHECK_TIME_MIN)² (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.241
hirStatisInfSysGroupCheckTimeAvg
Average time for checking a group (GROUP_CHECK_TIME_AVG)³ (microseconds)
INTEGER
read-only
pdstedit (sys)

11.1.242
hirStatisInfSysDummy
Cannot be referenced.
INTEGER
read-only
MIB command

Legend:

: Not applicable

Note

Information in parentheses following pdstedit is the edit item in the statistics analysis utility.

¹ If multiple items of statistical information are collected for a server, the maximum value is used.

² If multiple items of statistical information are collected for a server, the minimum value is used.

³ If multiple items of statistical information are collected for a server, the average value is used.

26.12 Disk usage

This section explains disk usage when the facility for monitoring MIB performance information is used. Table 26-10 shows the disk usage for MIB tables. These areas are used for returning results to JP1/ESA. Table 26-11 shows the disk usage in other areas.

Table 26-10 Disk usage for MIB tables (bytes)

Purpose | Directory/file name | Size
Server status table | /opt/HiRDB_S/sample/snmptmp or /opt/HiRDB_P/sample/snmptmp | 178 (unit-count + server-count)
Work table HiRDB file system area table | /opt/HiRDB_S/sample/snmptmp3 or /opt/HiRDB_P/sample/snmptmp3 | 2212 number-of-HiRDB-file-system-areas-for-work-tables
RDAREA table | /opt/HiRDB_S/sample/snmptmp4 or /opt/HiRDB_P/sample/snmptmp4 | 215 RDAREA-count
RDAREA details table | /opt/HiRDB_S/sample/snmptmp5 or /opt/HiRDB_P/sample/snmptmp5 | 502 RDAREA-count
Global buffer table | /opt/HiRDB_S/sample/snmptmp6 or /opt/HiRDB_P/sample/snmptmp6 | 351 global-buffer-count
HiRDB file system area (RDAREAs) table | /opt/HiRDB_S/sample/snmptmp9 or /opt/HiRDB_P/sample/snmptmp9 | 345 RDAREA-count
SYS statistics table | /opt/HiRDB_S/sample/snmptmp11 or /opt/HiRDB_P/sample/snmptmp11 | 2719 server-count

Note

The maximum sizes are indicated.

Table 26-11 Disk usage for other areas (bytes)

Directory/file name
Purpose
Size

$PDDIR/spool/pdmibwork directory
pdmibwork/sys_DAT
pdmibwork/fil_DAT
pdstedit execution result¹
See File size when executing the statistics analysis utility (pdstedit) in the manual HiRDB Installation and Design Guide.

pdmibwork/new_parameter
Final log information¹
32

pdmibwork/log/stlog01
pdmibwork/log/stlog02
Statistics log output facility command log
Maximum of 1 MB each for stlog01 and stlog02

pdmibwork/stjtmp/pdstj_tmp
Statistics log temporary file¹
Combined total of the maximum sizes of pdstj1 and pdstj2

Manager host's pdmibwork/sys_DAT_copy
pdmibwork/fil_DAT_copy
pdstedit execution result for remote copy 2
See File size when executing the statistics analysis utility (pdstedit) in the manual HiRDB Installation and Design Guide.

Manager host's pdmibwork/new_parameter_copy
Final log information for remote copy²
32

pdmibwork/pdmibstm_sys.dat
pdmibwork/pdmibstm_fil.dat
Statistical information management data
1 KB + (32 unit-count)

pdmibwork/mibstrerr
Final standard error output of the statistical information output facility
Maximum of 1 KB

pdmibwork/pdmibidx
Index value management data
Maximum: 47 host-count + 19 unit-count + 23 server-count + 45 RDAREA-count + 31 global-buffer-count + 46 HiRDB-file-system-area-count

¹ Deleted after information is collected by executing the pdstedit command.

² Deleted after remote copy.

27. Using a Distributed Database (applicable to HP-UX and AIX 5L only)

This chapter explains the environment setup and operating procedures for a distributed database. The Distributed Database System DF/UX program product is required in order to use the distributed database facility.

This chapter assumes that the reader is familiar with the Distributed Database System DF/UX.

This chapter contains the following sections:

Organization of this chapter

27.1 Overview of a distributed database

27.2 Environment setup for a distributed database

27.3 Distributed database security

27.4 Information output when a communication error occurs (Distributed Server facility only)

27.1 Overview of a distributed database

This section explains a distributed database implemented under HiRDB. The following items are explained here:

Scope of distributed database

Remote database access facility

Character codes environment

Handling of authorization identifiers

Handling of passwords

Notes on establishing connection with another node's HiRDB

Organization of this section

27.1.1 Scope of distributed database

27.1.2 Remote database access facility

27.1.3 Character codes environment

27.1.4 Handling of authorization identifiers

27.1.5 Handling of passwords

27.1.6 Notes on establishing connection with another node's HiRDB

27.1.1 Scope of distributed database

Table 27-1 shows the scope of a distributed database implemented under HiRDB.

Table 27-1 Scope of distributed database

Distributed client
Distributed server type

HiRDB
XDM/RD
ORACLE
(HI-UX/
WE2 Version)
RDB1 E2
SQL/K

HiRDB
Y¹
Y
Y²
Y²
Y²

XDM/RD
Y

ORACLE
(HI-UX/WE2 Version)
Y³

RDB1 E2
N

SQL/K
N

Y: Distributed database can be implemented.

N: Distributed database cannot be implemented.

: Not applicable.

Notes

The distributed database facility is limited to HP-UX and AIX 5L (excluding the 64-bit-mode HiRDB and POSIX library version of HiRDB). However, versions earlier than 07-02 support the HI-UX/WE2 version of HiRDB. The distributed database facility is supported by this HI-UX/WE2 version of HiRDB.

OSI-RDA is used as the protocol.

XDM/RD and XDM/RD E2 are referred to collectively as XDM/RD.

¹ The distributed database facility can be used between different platforms. For example, a distributed database can be constructed for HP-UX HiRDB and AIX 5L HiRDB.

² The distributed clients of a distributed database configuration are limited to HP-UX HiRDB.

³ The distributed clients of a distributed database configuration are limited to HP-UX HiRDB.

27.1.2 Remote database access facility

A distributed database can be implemented under HiRDB by using the remote database access facility of DF/UX (Distributing Facility/for UNIX). The remote database access facility consists of two facilities, the distributed client facility and the distributed server facility.

Organization of this subsection

(1) Distributed client facility

(2) Distributed server facility

(1) Distributed client facility

When HiRDB at the local node is used as a distributed client, it is possible to access a database at a remote distributed server (a UAP of the HiRDB at the local node can access a remote database at another node's DBMS). This capability is implemented using the distributed client facility of DF/UX.

When the UAP is created, you write the HiRDB SQL statements in the same way as for a UAP used for local access to the HiRDB database at the local node. You specify in the SQL statements the distributed server's table name, a name indicating the location of the database, etc. It must be noted that there are restrictions on UAP creation; for details on these restrictions, see the manual HiRDB Version 8 UAP Development Guide.

Figure 27-1 provides an overview of the distributed client facility.

Figure 27-1 Distributed client facility overview

(2) Distributed server facility

When HiRDB at the local node is used as a distributed server, it is possible for a database at a remote distributed client at a remote node to access this distributed server (the DBMS of a remote node can access the HiRDB database at the local node). This capability is implemented using the distributed server facility of DF/UX. Figure 27-2 provides an overview of the distributed server facility.

Figure 27-2 Distributed server facility overview

27.1.3 Character codes environment

An appropriate character codes environment must be set up for the system with which connection is to be established.

Organization of this subsection

(1) Connection with HiRDB

(2) Connection with Oracle

(3) Connection with XDM/RD

(4) Connection with RDB1 E2

(5) Connection with SQL/K

(1) Connection with HiRDB

When the connection is with a HiRDB, the distributed client and the distributed server must both use the same character code set; HiRDB supports the following character code sets:

Shift JIS Kanji encoding (SJIS)

EUC Chinese Kanji encoding (EUC/GB)

(2) Connection with Oracle

When the connection is with Oracle, the distributed client and the distributed server must both use the same character code set; HiRDB supports the following character code set:

Shift JIS Kanji encoding (SJIS)

(3) Connection with XDM/RD

When the connection is with XDM/RD, HiRDB supports the following character code set:

Shift JIS Kanji encoding (SJIS)

To use Shift JIS Kanji encoding, XDM/RD must be using EBCDIK/KEIS character codes.

(4) Connection with RDB1 E2

When the connection is with RDB1 E2, HiRDB supports the following character code set:

Shift JIS Kanji encoding (SJIS)

In this case, RDB1 E2 must be using EBCDIK/KEIS character codes.

(5) Connection with SQL/K

When the connection is with SQL/K, HiRDB supports the following character code set:

Shift JIS Kanji encoding (SJIS)

In this case, SQL/K must be using EBCDIK/KEIS character codes.

27.1.4 Handling of authorization identifiers

The length of the authorization identifier and the permitted characters depend on the system with which connection is established. Table 27-2 shows the permitted authorization identifier length, and Table 27-3 shows the permitted characters that can be used in an authorization identifier.

Table 27-2 Permitted authorization identifier length

System to be connected | Permitted authorization identifier length
HiRDB | Maximum 8 characters
ORACLE | Maximum 8 characters*
XDM/RD | Maximum 7 characters
RDB1 E2 | Maximum 8 characters
SQL/K | Maximum 7 characters

* When Oracle is the distributed client, a maximum of 7 characters is permitted for the authorization identifier used to establish connection with HiRDB.

Table 27-3 Characters permitted in an authorization identifier

System to be connected | Characters permitted in authorization identifier
A-Z | a-z | 0-9 | # | @, \ | Other
HiRDB | Y | Y | Y | Y | Y | N
ORACLE | Y | Y | Y | Y | N | N
XDM/RD | Y | N | Y | Y | Y | N
RDB1 E2 | Y | N | Y | Y | Y | N
SQL/K | Y | N | Y | Y | Y | N

Y: Permitted.

N: Not permitted.

27.1.5 Handling of passwords

The length of the password and the permitted characters depend on the system with which connection is established. Table 27-4 shows the permitted password length, and Table 27-5 shows the permitted characters that can be used in a password.

Table 27-4 Permitted password length

System to be connected | Permitted password length
HiRDB | Maximum 30 characters¹
ORACLE | Maximum 30 characters²
XDM/RD | Maximum 30 characters³
RDB1 E2 | Maximum 8 characters
SQL/K | Maximum 30 characters⁴

¹ Can also be omitted.

² When Oracle is the distributed client, a maximum of 8 characters is permitted for the password used to establish connection with HiRDB.

³ When TRUST E2 is used with the XDM/RD system, a maximum of 8 characters is permitted.

⁴ SQL/K does not check passwords. The password specified at the HiRDB side is ignored by SQL/K.

Table 27-5 Characters permitted in a password

System to be connected | Characters permitted in password
A-Z | a-z | 0-9 | # | @, \ | Other
HiRDB | Y | Y | Y | Y | Y | N
ORACLE | Y | Y | Y | Y | N | N
XDM/RD | Y | N | Y | Y | Y | N
RDB1 E2 | Y | N | Y | Y | Y | N
SQL/K | Y | Y | Y | Y | Y | N

Y: Permitted.

N: Not permitted.

27.1.6 Notes on establishing connection with another node's HiRDB

When connection is established with a HiRDB at another node, the HiRDB version should be checked. The following points must be taken into consideration when the two HiRDB versions are different:

Only facilities supported by the earlier version of HiRDB are available.

Only data types supported by the earlier version of HiRDB are available.

If the return code from the distributed server is not listed in the current manual, see the appropriate manual for the distributed server's version.

27.2 Environment setup for a distributed database

This section explains the environment setup for a distributed database. The following items are explained:

HiRDB environment setup

DF/UX environment setup

DF/UX Extension environment setup

Organization of this section

27.2.1 HiRDB environment setup

27.2.2 DF/UX environment setup

27.2.3 DF/UX Extension environment setup

27.2.1 HiRDB environment setup

Executor: HiRDB administrator

Organization of this subsection

(1) HiRDB system definitions

(2) Client environment definition (for distributed client facility only)

(1) HiRDB system definitions

In the case of a HiRDB/Single Server, specify the name of the local RD node in the pd_node_name operand of the single server definition. In the case of a HiRDB/Parallel Server, specify the name of the local RD node in the pd_node_name operand of the front-end server definition.

(2) Client environment definition (for distributed client facility only)

When the distributed client facility is to be used, specify whether or not batch retrieval is to be performed. Specify in the PDRDABLKF operand the number of rows that are to be subject to batch retrieval. Batch retrieval means transferring from the distributed server to the HiRDB system multiple rows of retrieval results in the batch mode. Specifying the PDRDABLKF operand reduces the number of data transfer operations, thereby reducing communications overhead and retrieval time. For details on the PDRDABLKF operand, see the manual HiRDB Version 8 UAP Development Guide.

When batch retrieval is used, more data is received than is customary during retrieval processing. Therefore, if batch retrieval is not possible due to limitations with respect to the DF/UX transfer buffer, a FETCH statement may result in an error. For details on the error handling procedures and the maximum amount of receive data, see the manual Distributed Database System DF/UX.

If the distributed server DBMS does not support batch retrieval, regular retrieval (single-row retrieval) is executed.

27.2.2 DF/UX environment setup

Executor: Superuser and DF/UX system administrator

Organization of this subsection

(1) DF/UX installation

(2) DF/UX environment definition

(3) DF/UX distribution definition

(4) Creating a server facility executable file (for distributed server facility only)

(5) Environment variable setup (for distributed server facility only)

(1) DF/UX installation

HiRDB/Single Server
Install DF/UX on the server machine where the single server is defined.

HiRDB/Parallel Server
Install DF/UX on the server machine where the front-end server is defined.

(2) DF/UX environment definition

HiRDB-related operands in the DF/UX environment definition are explained below. For details on DF/UX environment definition, see the manual Distributed Database System DF/UX.

(a) Related operands (for distributed client facility only)

The following table shows the operands that are related to use of the distributed client facility:

Operand | Specification
sql_environment_name | Specifies the RD node name of the distributed server. Specify the name specified in the rd_node_name operand of the SQL environment definition in DF/UX.
context_name | Specifies RDA#SQL#BASIC#OSAS.
block_fetch_count | Becomes the default value of the PDRDABLKF operand.

(b) Invalid operands (for distributed client facility only)

When the distributed client facility is being used, the following operands are ignored even if specified:

maximum_SQL_length

maximum_parameters

maximum_statements

block_fetch_limit

(c) Specification of maximum_client_users and maximum_server_users operands

The maximum_client_users and maximum_server_users operands must be specified so that the following condition is satisfied:

Formula

Value of pd_process_count (in single server definition*)

value of maximum_client_users + value of maximum_server_users

* In the case of a HiRDB/Parallel Server, use the value in the front-end server definition.

(3) DF/UX distribution definition

The operand shown below must be specified in the DF/UX distribution definition. For details on the DF/UX distribution definition, see the manual Distributed Database System DF/UX.

Operand | Specification
context_name | Specifies RDA#SQL#BASIC#OSAS.

(4) Creating a server facility executable file (for distributed server facility only)

Use the dfsvplink command of DF/UX to create a server facility executable file. Specify the options listed below in this command. For details on the dfsvplink command, see the manual Distributed Database System DF/UX.

dfsvplink command option
Specification

-x
Specifies p_rdb_df_xa_switch as the name of the xa_switch_t structure.

-l
Specifies the following as the libraries of the distributed server's DBMS:

$PDDIR/lib/libdfc.sl*

$PDDIR/client/lib/libzcltx.sl*

* The library suffix depends on the platform; for AIX 5L, it is .a.

(5) Environment variable setup (for distributed server facility only)

As in the case of a local-access UAP, communication between DF/UX and HiRDB uses the HiRDB client's library. Therefore, client environment definitions must be specified in environment variables of the startup command (dfstart command) of DF/UX. To start DF/UX automatically, specify the client environment definitions before the dfstart command in localrc in the /etc/rc file. For details on automatic startup of DF/UX (details of specifying localrc in the /etc/rc file), see the manual Distributed Database System DF/UX.

The following are the client environment definitions that must be specified (for details, see the manual HiRDB Version 8 UAP Development Guide):

PDCLTPATH¹

PDHOST

PDNAMEPORT

PDSWAITTIME²

¹ Specifies $PDDIR/spool/dfc as the error log output destination. The HiRDB administrator must create $PDDIR/spool/dfc. Because error logs are output under the ID of the DF/UX system manager, the privilege to write into the directory must be granted to the DF/UX system manager.

² Specifies a value that is greater than the value of the limit_access_interval operand of DF/UX. To safeguard against errors in distributed clients, access time is monitored based on the value specified in the limit_access_interval operand. If an error occurs in DF/UX, access time is monitored based on the value specified in the PDSWAITTIME operand.

27.2.3 DF/UX Extension environment setup

Executor: Superuser and DF/UX system administrator

Organization of this subsection

(1) DF/UX Extension installation

(2) DF/UX Extension environment definition

(3) DF/UX Extension distribution definition

(4) Package creation

(1) DF/UX Extension installation

In the case of a HiRDB/Single Server, install DF/UX Extension at the server machine where the single server is defined.

In the case of a HiRDB/Parallel Server, install DF/UX Extension at the server machine where the front-end server is defined.

(2) DF/UX Extension environment definition

The HiRDB-related operand for the DF/UX Extension environment definition is explained below.

maximum_client_users must be set so that the following condition is satisfied:

Formula

Value of pd_process_count (single server definition*)

value of maximum_client_users (DF/UX environment definition)

+ value of maximum_server_users (DF/UX environment definition)

+ value of maximum_client_users (DF/UX Extension environment definition)

* In the case of a HiRDB/Parallel Server, use the value in the front-end server definition.

(3) DF/UX Extension distribution definition

The following operand must be specified in the DF/UX Extension distribution definition:

Operand | Specification
rdb_name | Must be the same RD node name specified in the SQL statements.

(4) Package creation

DF/UX Extension's package handling utility is used to create a package used by DF/UX Extension. The following points should be noted.

When DF/UX Extension's package handling utility creates cursor declarations in the package, it uses C00001-C00100 as the cursor names. However, any cursor names can be used in cursor declarations in a UAP. HiRDB converts the cursor names in the UAP to the cursor names in the package.

27.3 Distributed database security

Organization of this section

(1) Security when distributed client facility is used

(2) Security when distributed server facility is used

(1) Security when distributed client facility is used

Required privileges must be registered in the distributed server for the authorization identifier of a UAP that accesses a remote database.

(2) Security when distributed server facility is used

Executor: User with DBA privilege and table owner

The following user privileges must be granted to the authorization identifier of a UAP that accesses a remote database:

CONNECT privilege

Access privilege

For details on how to grant user privileges, see 2.2 Setting user privileges.

27.4 Information output when a communication error occurs (Distributed Server facility only)

If an error occurs during communication between DF/UX and HiRDB, error information (error log) is output to an error log file.

File name

$PDCLTPATH/pderrxxxxx-1.trc (where xxxxx is the DF/UX server process ID)

$PDCLTPATH/pderrxxxxx-2.trc

File size

4096 bytes

For details on the error log files, see the manual HiRDB Version 8 UAP Development Guide.

Appendixes

Organization of the appendixes

A. Q&A

B. Operations When Using a DVD-RAM Library Device

C. Information Needed for Troubleshooting

D. Notes on Running HiRDB Around the Clock

E. Using Performance Improvement Facilities

Appendix A. Q&A

Frequently asked questions about HiRDB operations are answered in this appendix in Q&A format. The following topics are covered:

This appendix contains the following sections:

A.1 System log files

A.2 Synchronization point dump files

A.3 Status files

A.4 Errors

A.5 Tables and indexes

A.6 HiRDB startup

A.7 HiRDB termination

A.8 Performance

A.9 Backup

A.10 RDAREA recovery

A.11 Other

Organization of this section

A.1 System log files

A.2 Synchronization point dump files

A.3 Status files

A.4 Errors

A.5 Tables and indexes

A.6 HiRDB startup

A.7 HiRDB termination

A.8 Performance

A.9 Backup

A.10 RDAREA recovery

A.11 Other

Appendix A.1 System log files

Organization of this subsection

(1) The KFPS01224-I warning message was displayed indicating that there are no system log files in swappable target status

(2) The KFPS01251-E message was displayed indicating that a system log file was invalid

(3) Addition of a system log file and restart of HiRDB were repeated several times

(1) The KFPS01224-I warning message was displayed indicating that there are no system log files in swappable target status

Question

When HiRDB starts normally, doesn't it continue to use the system log file that was being used during the previous HiRDB session ?

Phenomenon 1

I executed normal startup or forced normal startup of HiRDB, but the KFPS01224-I message was displayed indicating that there was no system log file available for swapping. When this problem occurred, the system log files were in the following status:

There was adequate free space remaining in the system log file that was being used during the previous HiRDB session.

There was an available system log file that could be swapped in.

Phenomenon 2

I executed normal startup or forced normal startup of HiRDB, but the KFPS01256-E message was displayed indicating that there was no available system log file, and then HiRDB (or unit for a HiRDB/Parallel Server) terminated abnormally with abort code Psjnf07. When this problem occurred, the system log files were in the following status:

There was adequate free space remaining in the system log file that was being used during the previous HiRDB session.

There was no available system log file that could be swapped in.

Answer

When HiRDB starts normally, it does not continue to use the system log file that was being used during the previous HiRDB session. Because HiRDB swaps system log files during a normal startup (including a forced normal startup), the current file is swapped. The KFPS01256-E warning message was displayed because the last system log file available to be swapped in was allocated, and now there are no more system log files available for future swapping.

On the other hand, when HiRDB is restarted, the system log files are used as if the previous session was being resumed (system log files are not swapped).

If the same system log files were used after a normal startup, the system log from the previous session and the system log for the current session would be stored in a single system log file. In this case, performing file management tasks (such as unloading into unload log files) would be complicated. Therefore, HiRDB swaps system log files during normal startup so that a system log file containing only the new information following the normal startup is compiled.

When pd_log_rerun_swap=Y is specified, the system log files are also swapped during a restart. If a shortage of space occurs in the system log file, the restart fails; therefore, the number of system log files available to be swapped in (in swappable target status) should be increased.

(2) The KFPS01251-E message was displayed indicating that a system log file was invalid

Question

I executed forced normal startup of HiRDB (or a unit) after forced termination occurred (or the HiRDB unit terminated abnormally due to a software or hardware error), but the KFPS01251-E message was displayed indicating an invalid system log file. As a result, the system log file could no longer be used as a swappable target. What is the cause of this and what action should be taken?

Answer

Cause:

The file is an incomplete file because the primary file was not closed normally when HiRDB (or the unit) terminated abnormally. The same file will continue to be used because such situations occur during a restart. However, this file will be checked when a restart is executed.

Action:

Use the pdlogunld command to unload the system log in this system log file. If this system log information is not needed, the pdlogchg command can be used to simply change the file's status.

(3) Addition of a system log file and restart of HiRDB were repeated several times

Question

HiRDB terminated abnormally immediately after a restart because there was no system log file available to be swapped in (in swappable target status). So I allocated a new system log file and restarted HiRDB. HiRDB terminated abnormally again due to a shortage of system log files. I repeated the process of adding a system log file and restarting HiRDB, but the problem could not be resolved. Why did HiRDB keep terminating abnormally?

Answer

Possible reasons:

pd_log_rerun_swap=Y is specified.
When Y is specified in this operand, the current system log files are swapped even during a restart, thus reducing the number of swappable files by one. Therefore, this phenomenon cannot be eliminated by adding only one system log file. Add at least two system log files and restart HiRDB.

There is not enough space in the overwrite-enabled system log file.
During a HiRDB restart, system log information is collected even for rollback. Therefore, repeating the restart increases the number of system log files that are output, thereby increasing the range of the overwrite-disabled system log files. Because a new synchronization point dump is collected upon completion of all rollbacks after a restart, if the unit terminates abnormally after this synchronization point, the range of the overwrite-disabled system log files will not increase.
At least two system log files should be added at the same time, rather than adding one at a time. The total size of the files to be added should be at least 1.5 times the system log input range at the first restart when this event occurred for the first time (from the location indicated in the KFPS01262-I message to the location indicated in the KFPS01263-I message).

Remarks

This problem can be prevented by providing multiple reserved file groups and specifying pd_log_rerun_reserved_file_open=Y.

Appendix A.2 Synchronization point dump files

Organization of this subsection

(1) The KFPS02179-I message is issued repeatedly

(2) Number of guaranteed valid generations

(1) The KFPS02179-I message is issued repeatedly

Question

Why is the KFPS02179-I message being issued repeatedly (this message says that the time for collecting a synchronization point dump has been reached, but collection of the dump was skipped because the previous synchronization point dump processing had not been completed)?

Answer

This message is issued when HiRDB is waiting for commitment of an updating transaction that was being executed when a synchronization point dump was collected (i.e., HiRDB is waiting for completion of validation). There should be no problem if there is a sufficient number of system log files with sufficient space in them. However, if the unit terminates abnormally in such status, the restart time for HiRDB or the unit may be prolonged.

If there are enough generations and there is enough space in the system log file, HiRDB or the unit may terminate abnormally due to a shortage of overwrite-enabled system log files (the KFPS01256-E message is issued). To avoid such problems, reevaluate the following:

When it takes a long time for the transaction to commit after updating a database or data dictionary

Evaluate the following items:

Would it be possible to issue the commit statement during the processing?

If the transaction retrieves a large amount of data after updating, would it be possible to reduce the time from the first update processing in the transaction to the commit point by changing the sequence of the update processing and the retrieval processing?

When there is insufficient space in the system log file or too few generations

Evaluate the following items:

It is recommended that you provide the amount of file space necessary to store system logs that will be output during operation of HiRDB. If this is not feasible, try to allocate at least the size recommended in the HiRDB Version 8 Installation and Design Guide.

Do not collect a database update log for a transaction that updates a large amount of data. Whether or not a database update log is to be collected is specified in the PDDBLOG operand in the client environment definition. If a database update log is not collected and an error occurs during UAP execution, the database can be restored only to the point where its backup was made.

(2) Number of guaranteed valid generations

Question

What is meant by the number of guaranteed valid generations of the synchronization point dump file?

Answer

Information such as a read operation's starting point in the system log file is acquired in the synchronization point dump file; this information is useful in the event a restart of HiRDB becomes necessary. Thus, the portion of the system log file beginning at the location indicated in the synchronization point dump file is write-protected because it might be needed for a restart.

The number of guaranteed valid generations is the number of generations of synchronization point dump files that are used to write-protect the system log file. In other words, if the number of guaranteed valid generations is 1, only the system log file corresponding to the most recent synchronization point dump file is write-protected. If the number of guaranteed valid generations is 2, the system log file corresponding to the most recent synchronization point dump file and the one immediately preceding it are write-protected. Therefore, if the number of guaranteed valid generations is 2, the number of system log files that are write-protected may increase.

The number of synchronization point dump file guaranteed valid generations is specified in the pd_spd_assurance_count operand.

Appendix A.3 Status files

Organization of this subsection

(1) When are status files swapped?

(2) Does swapping occur even though an error occurs in only one of the status file versions?

(3) Handling of status file errors

(1) When are status files swapped?

Question

Are status files swapped only when a disk error occurs?

Answer

No. Status files are swapped at the following times:

When an error occurs in a status file

When a current status file becomes full

When there is no more usable space in a current status file due to fragmentation

When the pdstsswap command is executed

(2) Does swapping occur even though an error occurs in only one of the status file versions?

Question

Are status files swapped when an error occurs in only one of the file versions?

Does there have to be an error in both file versions before swapping occurs?

Answer

Swapping of status files occurs when an error occurs in either of the file versions. Below is the procedure HiRDB follows from the time an error is detected until swapping is completed:

Searches for normal spare files for both versions A and B.

The contents of the normal system are copied into versions A and B of other status files (the file space is also defragmented).

The status files at the copy destination are used as the current status files.

(3) Handling of status file errors

Question

The following operands are used to specify the HiRDB processing when no more normal status files are available for either file version A or file version B (in the event of an error in file version A or B):

pd_syssts_singleoperation=stop |continue (applicable to unit status files)

pd_sts_singleoperation=stop |continue (applicable to server status files)

Should I specify stop or continue for these operands?

Answer

Specifying stop terminates HiRDB or the unit abnormally. When continue is specified, operation with a single set of status files occurs (this is called single operation).

Status files are important because they contain information needed for full recovery processing. When continue is specified and an error occurs in the status file during single operation, HiRDB or the unit is terminated abnormally because the error is in both file versions. In this case, full recovery processing cannot be executed because neither file version that was used as the current file can be accessed. Following are guidelines for specifying these operands:

When providing for full recovery is more important than preventing abnormal termination of HiRDB, stop should be specified.

When you do not want to stop HiRDB (when you give up on full recovery processing, recover the database up to the point of the most recent backup, and reload data), continue should be specified.

Appendix A.4 Errors

Organization of this subsection

(1) What information do I need in the event of an error?

(2) After restarting HiRDB, SPP terminated abnormally due to a DB lock-release wait timeout

(1) What information do I need in the event of an error?

Question

Which information should I collect for purposes of investigation in the event of an error?

Answer

In general, save the following information onto a medium such as DAT:

All files under $PDDIR/spool

The following shared libraries:
/lib/libM.sl
/lib/libc.sl
/usr/lib/libdld.sl
/usr/lib/librsort.sl

syslog file

For an error associated with database conformity, collect the following information:
Contents of the user RDAREAs storing the corresponding table
Contents of the past log files up to that point
Contents of the master directory RDAREA
Contents of the data directory RDAREA
Contents of data dictionary RDAREAs

Remarks

HiRDB provides the pdgeter command for collecting all the above error information except No. 4.

(2) After restarting HiRDB, SPP terminated abnormally due to a DB lock-release wait timeout

Question

After restarting HiRDB, SPP terminated abnormally due to an RDAREA lock-release wait timeout:

The database seems to still be locked. What is the cause of this?

After SPP's abnormal termination, the status during rollback cannot be restored. What is the cause of this?

An attempt to terminate OpenTP1 normally with the dcstop command (OpenTP1 command) failed because there is an SPP engaged in rollback processing. What is the cause of this?

Answer

The following specifications may be missing in OpenTP1's transaction service definition (trn):
trnstring -n HiRDB_DB_SERVER -d*
set trn_tran_optimum_processing=N
These operands suppress OpenTP1's commit optimization and prepare optimization and normally are used when HiRDB is linked with OpenTP1 via the XA interface.
* Supported by TP1/Server Base 03-03 or later.

A HiRDB client environment variable may be missing or an invalid value may have been specified in OpenTP1's transaction service definition (trn). Check the following client environment variables:
PDHOST
PDNAMEPORT
At the same time, check OpenTP1's user service default definition (usrrc).

Same as 2 above.

Note

When this event occurs, terminate OpenTP1 forcibly, correct the HiRDB system definitions, then restart OpenTP1.

Reference note

The environment variables common to trn and usrrc should be specified in env. When they are specified in env, the environment variables are different from those in trn or usrrc; check the HiRDB Version 8 UAP Development Guide for the correct ones.

Appendix A.5 Tables and indexes

Organization of this subsection

(1) How can I obtain an existing index's definition?

(2) How can I add columns to an existing FIX table?

(1) How can I obtain an existing index's definition?

Question

Is it possible to use SQL to find out if an index has been defined?

Answer

It is possible by searching data dictionary tables; see the examples below.

The definition SQL generation facility of the dictionary import/export utility (pdexp command) can also be used for this purpose.

Example 1

Search for tables that have indexes:

SELECT TABLE_SCHEMA,TABLE_NAME,TABLE_ID
   FROM MASTER.SQL_TABLES WHERE N_INDEX >= 1

Example 2

Display the index names and columns names for a defined table:

SELECT TABLE_SCHEMA,TABLE_NAME,INDEX_NAME,INDEX_ID,COLUMN_NAME
   FROM MASTER.SQL_INDEX_COLINF
       WHERE TABLE_SCHEMA = USER

Example 3

Display the table name, table ID, index name, index ID, and column names for a table that has an index:

SELECT X.TABLE_SCHEMA,X.TABLE_NAME,X.TABLE_ID,
 INDEX_ID,COLUMN_NAME
   FROM MASTER.SQL_TABLES X,MASTER.SQL_INDEX_COLINF Y
       WHERE X.TABLE_SCHEMA = Y.TABLE_SCHEMA
            AND X.TABLE_SCHEMA = USER
            AND X.TABLE_NAME = Y.TABLE_NAME
            AND N_INDEX >= 1

(2) How can I add columns to an existing FIX table?

Question

Is there a way to add columns to a FIX table that already contains data?

Answer

Yes, there is. For details about adding columns, see 13.6 Adding a column.

Appendix A.6 HiRDB startup

Organization of this subsection

(1) HiRDB startup is slow

(2) The pdstart command resulted in an error (reason code=TIMEOUT)

(3) The pdstart command resulted in an error (RETURN_CODE=28)

(4) The pdstart command resulted in an error (reason code=SETUP)

(5) The pdstart command was invalidated

(6) A unit cannot be started with the pdstart command

(7) There is no response from the pdstart command

(8) HiRDB/Parallel Server will not start

(9) A unit other than the system manager unit will not start

(10) The front-end server is in SUSPEND status

(11) Is it possible to start HiRDB automatically?

(12) The pdstart command was specified in /etc/localrc, but it resulted in an error

(13) When I closed the window used to enter the pdstart command, HiRDB terminated abnormally

(1) HiRDB startup is slow

Question

Why does it take so much time (1-2 hours) for all units to start?

When the pdstart command was executed, the KFPS05078-I message was issued.

Answer

Check the following:

If the KFPS00608-W message (-314) is output more than once, check that the same host name is specified in the pdunit and pdstart operands for all units and that the specified host name is correct (name of the existing host).

Check that all hosts used by HiRDB and the network have started.

(2) The pdstart command resulted in an error (reason code=TIMEOUT)

Question

The pdstart command resulted in an error with the KFPS01861-E message (reason code=TIMEOUT). Why has this happened?

Answer

Cause

Following are possible reasons:

It took more time to start up a unit than expected.

There is an error in the server common definition or an individual server definition.

Action

Take the following actions:

Increase the value specified in the pd_start_time_out operand, then re-enter the pdstart command.

Check the messages HiRDB has output to syslogfile and correct any incorrect definitions that were detected. Then use the pdsetup -d command (enter y at the KFPS00036-Q prompt message) to delete HiRDB from the operating system and re-execute the pdsetup command.

(3) The pdstart command resulted in an error (RETURN_CODE=28)

Question

The pdstart command resulted in an error, setting RETURN_CODE=28 for a semaphore-related function such as semctl and semop. What causes this error?

Answer

The problem was caused by a resource shortage. Change the OS's operating system parameter to the value required by HiRDB. Note that the default value of the operating system parameter is smaller than the value required by HiRDB.

If the pdstart command terminates in a timeout error, a semaphore or shared memory shortage may be the cause. For details about the operating system value required by HiRDB, see the manual HiRDB Version 8 Installation and Design Guide.

If the operating system parameter value is appropriate, increase the value of the pd_start_time_out operand, and then re-execute the pdstart command.

(4) The pdstart command resulted in an error (reason code=SETUP)

Question

The pdstart command resulted in an error and the KFPS01801-E message was issued (reason code=SETUP). Why?

Answer

Cause

Following are possible reasons:

The HiRDB directory specified in the PDDIR environment variable was not registered into the OS with the pdsetup command.

The process server daemon cannot be started because of a kernel semaphore shortage.

Action

Take the following actions:

Use the pdsetup command to register the HiRDB directory into the OS.

Increase the number of semaphores used, which is defined by the system. Note that you must reboot the OS in order for the new value to take effect.

Reference note

This event may also occur immediately after OS booting or when another program registered in inittab is placed in response wait status.

(5) The pdstart command was invalidated

Question

The pdstart command had no effect. Why?

Answer

The HiRDB server daemon may have been unable to start up because of an error.

Investigate the cause of the error by checking the message log ($PDDIR/spool/pdlog1 or pdlog2) and take appropriate action. If the cause of the error cannot be determined from the message log, check the details in the HiRDB message output to syslogfile, and take appropriate action.

(6) A unit cannot be started with the pdstart command

Question

When I executed pdstart, the KFPS01815-E message (errno=11,13,22) was displayed indicating that semaphore manipulation (semop, semctl) failed. What happened?

Answer

Cause

Following are possible reasons:

HiRDB has not been installed on that machine.

HiRDB was not registered in the OS with the pdsetup command.

The installation directory is linked to a shared disk.

Action

Take the following actions:

Reboot the server machine, then execute the pdsetup -d command to delete HiRDB from the OS. Then re-execute the pdsetup command.

If HiRDB is installed on the server machine, execute the pdsetup command.

Create the installation directory on the local server machine's local disk.

(7) There is no response from the pdstart command

Question

Why is there no response from the pdstart command?

Answer

Is the front-end server in SUSPEND status?
If it is not in SUSPEND status, check for another cause. If it is in SUSPEND status, execute ps -ef or grep fesact at the host where the front-end server is started. for multiple front-end servers, execute it at all those hosts.

Is there more than one fesact process?
If not, check for another cause. If there is, an error may have occurred in the network. Terminate HiRDB forcibly with the pdstop -f command.
Contact the network administrator for error recovery.

(8) HiRDB/Parallel Server will not start

Question

The system manager unit terminated abnormally, and only that unit was restarted. Now, HiRDB startup cannot be completed.

Answer

Abnormal termination of the system manager unit may have caused abnormal termination of another unit. Use the pdls command to determine the units that are not active.

(9) A unit other than the system manager unit will not start

Question

The pdstart command was entered, but a unit other than the system manager unit will not start. Why?

When ps -ef was checked on the unit other than the system manager unit, there was only pdprcd. HiRDB's other daemons have not been started.

Answer

Check the system common definition for the unit that would not start. The value specified for the pdunit or pdstart operand may not match the information in the system common definition for the server machine where the system manager is located.

Correct the system common definition for the unit resulting in the startup error, then start the unit again with pdstart -u.

(10) The front-end server is in SUSPEND status

Question

When the front-end server unit or the front-end server was started independently, the front-end server was placed in SUSPEND status. How can I place it in ACTIVE status?

Answer

If the front-end server unit or the front-end server is started while the dictionary server is shut down, the status is set to SUSPEND. In such a case, start the dictionary server, then execute pdstart -a -s front-end-server-identifier.

(11) Is it possible to start HiRDB automatically?

Question

Is it possible for HiRDB to be started and terminated automatically when the OS is started and terminated?

pdstart was specified in /etc/localrc in order to start HiRDB when the OS was started, but this did not work. Why?

pdstop was specified in /etc/localshutrc in the same manner. Why didn't this work?

Answer

To start HiRDB when the OS starts, specify AUTO in the pd_mode_conf operand.

Currently, there is no way to terminate HiRDB automatically when the OS terminates. Execute the pdstop command and check that HiRDB has terminated normally, then terminate the OS.

Neither the pdstart nor the pdstop command can be specified in the OS's /etc/localrc or /etc/localshutrc environment file. During OS startup, /etc/localrc is activated at the /etc/rc phase, but pdstart cannot be accepted at this point because the HiRDB process server daemon (_prc) has not been started yet. If the pdstart command is specified in /etc/localrc, the command terminates abnormally. To start HiRDB when the OS is started, specify AUTO in the pd_mode_conf operand. On the other hand, /etc/localshutrc is activated as an extension of the shutdown command when the OS execution level is 0, at which point the HiRDB process server daemon has already been terminated. If the pdstop command is specified in /etc/localshutrc, the command results in an error and HiRDB has to be restarted.

(12) The pdstart command was specified in /etc/localrc, but it resulted in an error

Question

The pdstart command was specified in /etc/localrc, but it resulted in an error.

The pdstart command was executed using the HA monitor's interface, but it resulted in an error.

The pdstart command resulted in an error when it was executed after OS bootup followed by remote login.

Answer

HiRDB operation becomes available near the end of OS bootup processing. Therefore, HiRDB cannot be started by specifying the pdstart command in /etc/localrc, etc. The pdstart command can be executed only after HiRDB's pdprcd daemon has started.

Action 1

Do not execute the pdstart command immediately after OS bootup. For example, use the following procedure to execute the pdstart command:

Procedure:

Ensure that pdprcd is active:
ps -ef | grep $PDDIR/lib/servers/pdprcd

Wait a few seconds (until startup of the pdprcd daemon is completed).

Execute the pdstart command.

Action 2

Automatic startup of HiRDB should be employed. To start HiRDB automatically, specify pd_mode_conf=AUTO. When this is specified, HiRDB starts automatically at the completion of OS bootup (there is no need to enter the pdstart command).

(13) When I closed the window used to enter the pdstart command, HiRDB terminated abnormally

Question

I entered the pdstart command but there was no response from the command. Therefore, I closed the window used to enter the pdstart command. HiRDB terminated abnormally immediately after this. Why?

Answer

If the pdstart command is stopped forcibly, conformity cannot be maintained in the shared resources, resulting in abnormal termination of HiRDB. Similarly, if the window is closed while waiting for a response from the pdstart command, HiRDB terminates abnormally.

Do not close the window used to enter the pdstart command until the command has terminated. This also applies to all other operation commands and utilities; do not close the corresponding window during execution or while waiting for a response.

Appendix A.7 HiRDB termination

Organization of this subsection

(1) When the pdstop -f command was entered, the unit terminated abnormally

(2) HiRDB will not terminate normally

(3) When HiRDB terminated normally, the system server terminated abnormally

(4) When I closed the window used to enter the pdstop command, HiRDB terminated abnormally

(1) When the pdstop -f command was entered, the unit terminated abnormally

Question

When I entered the pdstop -f command, why did HiRDB or the unit terminate abnormally with abort code Polkcrt?

Answer

A process in critical status was terminated during forced termination processing. Ignore this event because there is no problem in terms of operations.

The pdstop -f command terminates forcibly all processes, even processes in critical status. Therefore, although this event can occur, there is no problem because HiRDB is restarted by the next pdstart command (the database is restored from the system log).

(2) HiRDB will not terminate normally

Question

Why won't HiRDB terminate normally?

Answer

HiRDB cannot terminate normally while there is a transaction in uncompleted status or a connected user. Use the following commands to check the status of connected users and transactions before attempting to terminate HiRDB normally:

pdls -d prc command to check for connected users

pdls -d trn command to check transaction status

For the actions to be taken, see 18.13 When HiRDB cannot be terminated because a user is still connected or 18.14 Actions when there is an undetermined transaction.

(3) When HiRDB terminated normally, the system server terminated abnormally

Question

I executed the pdstop and shutdown commands consecutively in this order using a shell script, then the system server terminated abnormally. Why?

Answer

The system server does not terminate the moment the pdstop command is entered. If the shutdown command is executed while the system server is still engaged in termination processing, the system server terminates abnormally.

Do not execute the shutdown command immediately after entering the pdstop command. For example, execute the following commands in the sequence shown:

pdstop

sleep 60

shutdown

(4) When I closed the window used to enter the pdstop command, HiRDB terminated abnormally

Question

I entered the pdstop command, but there was no response from the command. Therefore, I closed the window used to enter the pdstop command. HiRDB terminated abnormally immediately after this. Why?

Answer

If the pdstart command is stopped forcibly, conformity cannot be maintained in the shared resources, resulting in abnormal termination of HiRDB. Similarly, if the window is closed while waiting for a response from the pdstop command, HiRDB terminates abnormally.

Do not close the window used to enter the pdstop command until the command has terminated. This also applies to all other operation commands and utilities; do not close the corresponding window during execution or while waiting for a response.

Appendix A.8 Performance

Organization of this subsection

(1) The expected retrieval performance cannot be obtained

(2) Is it possible to check the buffer utilization status and the number of read/write operations?

(1) The expected retrieval performance cannot be obtained

Question

I defined an index for a table in order to use the index to achieve high-speed retrieval, but the expected retrieval performance was not obtained. Is it possible that the index was not used?

Answer

An index may not be used for retrieval if the optimizing information collection utility (pdgetcst command) has not been used in the database's most recent status. For details about whether or not execution of the optimizing information collection utility is required, see the manual HiRDB Version 8 Command Reference.

If any of the events listed below occurs with respect to a table that has been optimized based on cost using the optimizing information collection utility (pdgetcst command), the pdgetcst command must be executed again to obtain the most recent optimization information:

A large amount of data has been added, updated, or deleted

The database load utility (pdload command) or the database reorganization utility (pdrorg command) has been executed

Table definition has been modified, or an index has been added or deleted

Remarks

The access path display utility (pdvwopt command) can be used to determine whether or not an index is being used for retrieval.

(2) Is it possible to check the buffer utilization status and the number of read/write operations?

Question

How can I check a buffer's utilization status (such as the hits rate) and the number of read/write operations in order to tune the buffer?

Answer

A buffer's hits rate and the real READ/WRITE counts can be obtained by editing the global buffer statistical information with the statistics analysis utility (pdstedit command). Start collecting statistical information by executing the statistics information output start command (pdstbegin command) with buf specified as the statistical information type. Note that this is the differential information between synchronization point dumps; therefore, the information will not be edited or output until two synchronization point dumps have been validated. If necessary, use the following commands to forcibly swap the system log files and validate synchronization point dumps:

pdststart -k buf: Starts collection of statistical information

pdlogsync: Validates synchronization point dumps

Range of statistical information collection:

pdlogsync: Validates synchronization point dumps

pdstedit: Edits and outputs the statistical information

Remarks

The same information as obtained by the statistics analysis utility can be displayed easily by entering the pdbufls command. In this case, the differential information between two pdbufls command entries is displayed; therefore, execute the pdbufls command twice, once at the beginning and once at the end of the desired range of statistical information collection.

Appendix A.9 Backup

Organization of this subsection

(1) Backup acquisition unit

(2) Difference between the pdfbkup and pdcopy commands

(3) Backing up the master directory RDAREA

(4) Even though there is available space on the disk, a disk space shortage occurs during execution of the pdcopy command

(1) Backup acquisition unit

Question 1

Can you make a backup of just a table?

Answer

No, you cannot. However, you can achieve this with one of the following methods:

Store one table in one RDAREA and make a backup of the RDAREA.

Use the database reorganization utility (pdrorg command) to unload each table.

Question 2

Can you make a backup that consists of only the changes made since the previous backup?

Answer

Yes, you can. HiRDB supports the differential backup facility. This facility backs up only the information that has changed (differential information) since the previous backup was made. This facility can reduce the amount of time spent making backups. The differential backup facility should be used when the database is large but the volume of updating is small. For details of the differential backup facility, see 6.5 Acquiring a differential backup.

Question 3

If an error occurs in a particular RDAREA after all RDAREAs have been backed up with the -a option specified in the pdcopy command, can you recover only that RDAREA from the backup copy of all RDAREAs?

Answer

Yes, you can. A particular RDAREA can be recovered by specifying its name in the pdrstr command.

(2) Difference between the pdfbkup and pdcopy commands

Question 1

Can I use a backup (backup of a HiRDB file system area) acquired with the pdfbkup command as the input file for the pdrstr command?

Answer

No, a backup acquired with the pdfbkup command can be used only with the pdfrstr command.

Question 2

Can I make a backup with the pdfbkup command while HiRDB is running?

Answer

No, you cannot. Use the pdcopy command to make a backup while HiRDB is running.

(3) Backing up the master directory RDAREA

Question 1

Can I back up RDAREAs while HiRDB is running?

Answer

Yes, you can. However, if the master directory RDAREA is included, one of the following backup acquisition modes must be used:

Referencing-permitted mode (-M r specified)

Updatable mode (-M s specified)

Question 2

If the -a option (back up all RDAREAs) is specified in the pdcopy command, will the master directory RDAREA be included? If so, do I need to start HiRDB with the pdstart -r command?

Answer

The master directory RDAREA will be included.

HiRDB must be started with the pdstart -r command, not just when the master directory RDAREA is backed up, but when both the following conditions are satisfied:

The master directory RDAREA is included in the backup

The referencing/updating-impossible mode (-M x specified) is specified as the backup acquisition mode

(4) Even though there is available space on the disk, a disk space shortage occurs during execution of the pdcopy command

Question

Why does a disk space shortage occur during execution of the pdcopy command, even though there is available space on the disk?

Answer

Following are possible reasons:

Use of large files is not permitted (pd_large_file_use = Y is not specified).

The permitted maximum size for the kernel parameter has been exceeded.

In this case, either use large files or change the kernel parameter. You can also solve the problem by specifying multiple backup files. However, if the OS does not support large files, you must set the disk partition size to 2 GB or less to handle multiple files.

Appendix A.10 RDAREA recovery

Organization of this subsection

(1) Specification of the pdrstr command

(2) Master directory RDAREA recovery

(1) Specification of the pdrstr command

Question 1

Because errors occurred in the master directory RDAREA and in a particular user RDAREA, all RDAREAs were recovered with -a (recovery of all RDAREAs) or -c (recovery of all RDAREAs in a backup) specified in the pdrstr command. In this case, has the information in normal RDAREAs also been replaced?

Does recovery processing first delete the information internally and then import it?

Answer

The information is replaced. The pdrstr command first deletes the HiRDB files comprising the RDAREAs to be recovered by the pdrstr command and then restores the contents of the backup files. Therefore, the RDAREAs specified as recovery targets during execution of the pdrstr command (including normal RDAREAs) are all replaced.

Question 2

When an initialized RDAREA is recovered with the pdrstr -a command (recovery of all RDAREAs), is table definition information also recovered?

If not, when should I execute CREATE TABLE?

Answer

The table information is recovered. Because the table definition information is stored in a dictionary, it is recovered correctly if the initialized RDAREA is synchronized with the dictionary, data directory, and master directory.

(2) Master directory RDAREA recovery

Question

How should I recover the master directory RDAREA?

Answer

To recover the master directory RDAREA, you must start HiRDB with the pdstart -r command. For details of the recovery procedure, see 19. Database Recovery Procedures.

Appendix A.11 Other

Organization of this subsection

(1) Increasing the number of executing users

(2) No UAP is connected, but user identification information is displayed

(3) Can the system time be changed?

(4) Authorization identifiers and passwords are not being recognized correctly

(1) Increasing the number of executing users

Question

What are the effects of increasing the value of the pd_max_users operand in order to accommodate more users?

Answer

For details about the effects of increasing the value of the pd_max_users operand, see 9.5 Handling an increase in the number of users.

(2) No UAP is connected, but user identification information is displayed

Question

No UAP is connected, so why is user identification information displayed when the pdls -d act command is executed?

Answer

If transaction rollback was not completed after a server process was aborted or rerun, the user identification information is retained. This user identification information will be deleted once transaction rollback is completed.

(3) Can the system time be changed?

Question

I want to change the system time to do some tests. Is it possible to change the system time?

What would be the effects of forcibly advancing or rolling back the system date or time?

Answer

Although you can advance the system date or time, it is not recommended that you do so.

HiRDB stores date and time information in the system log files, status files, and dictionaries for use during HiRDB restart, etc. Date and time information is also stored in the work files of various utilities for use in several types of checking.

Advancing the date and time

There is no serious problem in advancing the time, but statistical information may not be displayed correctly, or for some period the time may not be updated in messages. If the date and time are changed during HiRDB startup processing, the results cannot be guaranteed. There may also be OS consequences.

Rolling back the date and time

The results cannot be guaranteed because various problems may result, such as restart errors, database recovery errors, invalid system waits, etc. For these reasons, forcibly rolling back the date or time is not advisable. If the date and time are rolled back for testing purposes, the system and databases will have to be rebuilt from the beginning.

(4) Authorization identifiers and passwords are not being recognized correctly

Question

Why are authorization identifiers and passwords not being recognized correctly?

Answer

It is possible that upper- and lower-case letters are not being recognized correctly. If lower-case letters are included, the character strings must be enclosed in quotation marks ("). Otherwise, the lower-case letters will be regarded as upper-case letters.

Example

SELECT * FROM "user05".TABLE05;

Appendix B. Operations When Using a DVD-RAM Library Device

This appendix explains the procedures for using a DVD-RAM library device as a storage device.

Organization of this section

(1) Setting system common definitions

(2) Creating HiRDB file system areas

(3) RDAREA opening trigger attribute

(1) Setting system common definitions

To use a DVD-RAM library device, you must take steps to avoid detection of false timeouts caused by the fact that the physical mounting operation (staging) takes a long time. Therefore, specify a value in the operands listed below that adds the time required for the mounting operation to the previous estimate:

pd_watch_time (maximum response wait time)

pd_lck_wait_timeout (lock-release wait time)

(2) Creating HiRDB file system areas

You create a HiRDB file system area in a normal file or character special file in a DVD-RAM library device.

Creating a HiRDB file system area in a normal file

A HiRDB file system area created in a DVD-RAM library device can be manipulated in the same manner as a HiRDB file system area created on a magnetic disk. However, when considering performance and availability, Hitachi does not recommend using such file system areas for system files (SYS), work files, or list RDAREAs (WORK).

Creating a HiRDB file system area in a character special file

If you create a HiRDB file system area in a character special file in a DVD-RAM library device, you must take into consideration the sector length of the DVD-RAM library device. When the sector length is 512 or 1024 bytes, the HiRDB file system area can be manipulated in the same manner as a HiRDB file system area created in a character special file on a magnetic disk. However, when considering performance and reliability, Hitachi does not recommend using such file system areas for system files (SYS), work files, or list RDAREAs (WORK).

Notes

You should note following when the sector length is 2048 or 4096 bytes:

Only the files listed below can be created in a HiRDB file system area created using this procedure:

HiRDB files comprising RDAREAs (excluding list RDAREAs)

Backup files

Unload log files

Unload data files

Execute the pdfmkfs command, then use the -s option to specify the sector length. You cannot use the -k option to specify SYS, WORK, or SVR.

When you use the database initialization utility (pdinit command) to define an RDAREA, specify in the page operand (page length) in the utility control statement a value that is a multiple of the sector length.

When you use the database structure modification utility (pdmod command) to add, extend, or reinitialize an RDAREA, specify in the page operand (page length) in the utility control statement a value that is a multiple of the sector length.
Hitachi cautions against omitting the page operand during reinitialization of an RDAREA. If the page length of the RDAREA before reinitialization is not a multiple of the sector length, the RDAREA cannot be reinitialized.

When you use the pdfrstr command to restore a HiRDB file, the record length of the HiRDB file to be restored must be a multiple of the sector length of the HiRDB file system area into which the file will be restored. The record length of a HiRDB file can be checked with the pdfls command.

When you use the database recovery utility (pdrstr command) to recover an RDAREA, the page length of the RDAREA to be recovered must be a multiple of the sector length of the HiRDB file system area. If the page length is not a multiple of the sector length, the RDAREA cannot be recovered. For example, if the medium that a HiRDB file system area is created on is being replaced because of a physical failure, check that the sector length of the HiRDB file system area on the new medium is the same as on the medium being replaced.

(3) RDAREA opening trigger attribute

When you define an RDAREA on a DVD-RAM library device, use SCHEDULE as the RDAREA opening trigger attribute. If you use INITIAL (the default), all HiRDB files will be opened when HiRDB is restarted because RDAREA information resides in memory. When opening processes accumulate on a DVD-RAM library device, disk swapping may occur often and result in the HiRDB startup process timing out. By using the DEFER attribute, you can avoid accumulation of opening processes when HiRDB starts, but they will accumulate when HiRDB terminates normally.

Also, when you use a normal file with the INITIAL or DEFER attribute, reactivation will not be performed smoothly because fsck will be executed on all media HiRDB opens during the next OS startup if a power outage or restart occurred while HiRDB was still active.

RDAREA opening trigger attributes are not suitable for operations with DVD-RAM library devices, because the RDAREA opening trigger attribute is fixed to INITIAL for the master directory RDAREA, data directory RDAREA, data dictionary RDAREAs, data dictionary LOB RDAREAs, and registry RDAREA. You should create these RDAREAs on a magnetic disk.

To change the opening trigger attribute of RDAREAs to SCHEDULE, specify pd_rdarea_open_attribute_use=Y and take one of the following actions depending on the number of RDAREAs to be assigned the SCHEDULE attribute:

When changing many RDAREAs to the SCHEDULE attribute

Specify pd_rdarea_open_attribute=SCHEDULE. This specification makes all RDAREAs in the entire system valid except for the master directory RDAREAs, data directory RDAREAs, data dictionary RDAREAs, data dictionary LOB RDAREAs, and the registry RDAREA.

When changing a small number of RDAREAs to the SCHEDULE attribute

Define each such RDAREA by specifying it in a control statement of one of the following utilities:

Specify SCHEDULE in the open attribute operand of the database initialization utility (pdinit command)

Specify SCHEDULE in the open attribute operand of the database structure modification utility (the pdmod command)

Such a specification is valid only for the specified RDAREA. Also, when used in conjunction with specification of the pd_rdarea_open_attribute operand, the specification for the utility has the higher priority.

Reference note

Specification of an opening trigger attribute in this manner does not take effect immediately after the database structure modification utility is used to add an RDAREA because the opening trigger attribute starts out as INITIAL. To activate specification of the opening trigger attribute, you must restart HiRDB. The specified opening trigger becomes effective regardless of the startup mode.

Appendix C. Information Needed for Troubleshooting

The information needed for troubleshooting can be divided broadly into operating system information and HiRDB information. Operating system information is collected using operating system commands. HiRDB information is collected using HiRDB commands.

If you use problem-solving support or Q&A support services, the information explained in Table C-1 may be needed. Table C-1 explains the information needed for troubleshooting. The priority for collecting information is divided into three categories: a performance problem, a no-response, and abnormal termination. There are seven priority levels, with 1 being the highest priority and 7 being the lowest.

Table C-1 Information needed for troubleshooting

No.
Category
Collected information
Collection method
Prf.
NR
AT

1
OS
syslogfile
Use an operating system function (command).
1
1
1

2
CPU utilization and device status
Use the OS's sar command. For details about this command, see the documentation for the operating system.
3
4
3

3
CPU activity or memory status for the process
Use the OS's top command. For details about this command, see the documentation for the operating system.
3
4
3

4
Virtual memory information
Use the OS's vmstat command. For details about this command, see the documentation for the operating system.
3
4
3

5
Network status information
Use the OS's netstat command. For details about this command, see the documentation for the operating system.
3
4
3

6
HiRDB
HiRDB error information
Use the pdgeter command. Save the output information onto a medium such as a DAT.
2
2
2

7
Error log files
Error log files are output to the directory $PDDIR/spool/errlog.
2
2
2

8
Command log file
Command log files are output to the directory $PDDIR/spool/cmdlog.
2
2
2

9
HiRDB system definition information
Save files in the directory $PDDIR/conf on a medium such as a DAT.
4
5
4

10
Table and index definition information
Save files describing definition SQL used when defining tables or indexes on a medium such as a DAT.
4

11
Statistical information
Use the statistical information output start and end commands (pdstbegin and pdstend) to collect the information listed below:

Statistical information on system operations (sys)
Recommended interval: 1 hour

Statistical information on the global buffer pool (buf)

Statistical information for HiRDB files on database manipulation (fil)

This information is output to the directories $PDDIR/spool/pdstj1 and pdstj2.
After collecting the statistical information, use the statistics analysis utility (pdstedit command) to edit the statistical information.
6

12
Server communication control information
Use the pdls -d rpc -a command. Execute this command at 60-second intervals and output to the target file using an appending redirect (>>). Save this file on a medium such as a DAT.

Recommended collection interval: 60 seconds

Disk space needed to collect information one time: approximately 62 KB.

5
4
4

13
Information on the status of server transactions
Use the pdls -d tm -a command. Execute this command at 60-second intervals and output to the target file using an appending redirect (>>). Save this file on a medium such as a DAT.

Recommended collection interval: 60 seconds

Disk space needed to collect information one time: approximately 30 KB

5
6
5

14
Information on the status of server processes
Use the pdls -d prc -a command. Execute this command at 60-second intervals and output to the target file using an appending redirect (>>). Save this file on a medium such as a DAT.

Recommended collection interval: 60 seconds

Disk space needed to collect information one time: approximately 28 KB

5
6
5

15
Information on server lock
Use the pdls -d lck -a command. Execute this command at 60-second intervals and output to the target file using an appending redirect (>>). Save this file on a medium such as a DAT.

Recommended collection interval: 60 seconds

Disk space needed to collect information one time: approximately 62 KB

5

16
Information on the global buffer usage status
Use the pdbufls command. Execute this command at 60-second intervals and output to the target file using an appending redirect (>>). Save this file on a medium such as a DAT.

Recommended collection interval: 60 seconds

Disk space needed to collect information one time: approximately 3 KB

5

17
SQL trace files and error log files
SQL trace files and error log files are output to the directory specified by the PDCLTPATH operand of the client environment definition. When the PDCLTPATH operand is omitted, these files are output to the directory in which the AP is currently running.
Save the output files on a medium such as a DAT. File names start with pderr or pdsql.

6
5

18
System log files
Use pdlogunld to unload the system log. Save the unload log files on a medium such as a DAT.
6
7
6

19
Core files
If a utility stops responding, use the following procedure to collect the core files:
Procedure

Use the pdls -d prc command to check the server process ID of the utility.

Use the pdcancel -d command to cancel the process checked in step 1.

3

Legend:

Prf.: Performance problem

NR: No-response

AT: Abnormal termination

: Collection of this information is not necessary.

Notes

The necessary disk space is a reference value. The actual value will depend on the system configuration.

Available disk space is suppressed because files that can be added to by redirecting output information increase in size incrementally. Therefore, create a general-purpose shell script that swaps files and reuses them in a specific generation.

Appendix D. Notes on Running HiRDB Around the Clock

This appendix explains the procedures for and provides notes about running HiRDB continuously around the clock. These procedures and notes are listed below.

System reconfiguration command (pdchgconf command)

Specifying HiRDB system definitions

Making backups

Reorganizing databases

Reusing used free pages and free space within pages

Expanding RDAREAs

Dynamic updating of global buffers

Deleting troubleshooting information

System switchover facility

Program maintenance facility (upgrade to update version)

Recovery-unnecessary front-end server (HiRDB/Parallel Server only)

Organization of this section

D.1 System reconfiguration command (pdchgconf command)

D.2 Specifying HiRDB system definitions

D.3 Making backups

D.4 Reorganizing databases

D.5 Reusing used free pages and free space within pages

D.6 Expanding RDAREAs

D.7 Dynamic updating of global buffers

D.8 Deleting troubleshooting information

D.9 System switchover facility

D.10 Program maintenance facility (upgrade to update version)

D.11 Recovery-unnecessary front-end server (HiRDB/Parallel Server only)

Appendix D.1 System reconfiguration command (pdchgconf command)

It is usually necessary to terminate HiRDB in order to modify a HiRDB system definition (other than a UAP environment definition). However, by using the system reconfiguration command, you can modify HiRDB system definitions while HiRDB is still active. The actions listed below can be executed while HiRDB is active:

Adding, removing, or moving units

Adding, removing, or moving servers

Adding system files

Adding, removing, or modifying global buffers

The system reconfiguration command is very convenient in the case of a system that runs around the clock without interruption. For details about using this command, see the references below.

For details about using the system reconfiguration command about modifying HiRDB system definitions, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

For details about adding, removing, or moving units or servers, see 11. Modifying the System Configuration.

For details about adding system files, see 3.5.8 Adding a new system log file, 4.3.5 Adding a new synchronization point dump file, or 5.2.6 Adding a new status file.

For details about adding, removing, or modifying a global buffer, see 15.2 Creating an RDAREA (RDAREA addition).

Note that HiRDB Advanced High Availability must be installed in order to use the system reconfiguration command.

Appendix D.2 Specifying HiRDB system definitions

To modify an operand in a HiRDB system definition, HiRDB must be terminated. When you wish to modify any of the operands explained in Table D-1, you should determine in advance the new values to be specified. Care is required in specifying values for the operands described in Table D-1 in the case of a HiRDB that operates around the clock.

When HiRDB Advanced High Availability is installed, HiRDB system definitions can be modified while HiRDB remains active because the system reconfiguration command becomes available for use.

Table D-1 Operands requiring caution when specifying new values while HiRDB is running around the clock

Operand
Caution

pd_max_users
pd_max_server_process
pd_max_bes_process
pd_max_dic_process
When the number of concurrently connected clients is expected to increase, specify values for these operands that provide a sufficient margin. Also, reducing the value of the pd_process_count operand makes it possible to minimize the number of unnecessary (unconnected) processes.
When the pd_max_server_process operand is omitted, HiRDB calculates a value for it automatically.

pd_stj_file_size
The file size depends on the statistical information acquired, but Hitachi recommends specifying a value greater than the default (which is 1024 kilobytes).

pd_spd_syncpoint_skip_limit
When specifying this operand, be aware of the amount of data handled by batch jobs to be executed.

pd_lck_pool_size
When the job mode changes and the number of resources to be locked might increase until the resources are committed, take that potential increase into account when determining the value of this operand.

pd_lck_until_disconnect_cnt
When the job mode might change, take that into account when determining the value of this operand.

pd_sds_shmpool_size
pd_dic_shmpool_size
pd_bes_shmpool_size
The values specified in these operands are calculated from the values of other operands in this list. Therefore, when you change the value specified in any of those other operands, you must re-calculate the values to be specified in these operands. For details about which other operands affect these operands, see Formula for calculating the shared memory used by single servers or Formula for calculating the shared memory used by each server in the manual HiRDB Version 8 Installation and Design Guide.
When these operands are omitted, HiRDB calculates values for them automatically.

pdlogadfg -d sys
pdlogadpf -d sys
Be sure to provide sufficient extra overall space for system log files. Use these operands to define reserved files, and you can add content to system log files as necessary.

pd_svr_castoff_size
Specifying this operand while processes reside in the system increases the amount of memory used. Therefore, confirm that specifying this operand is necessary.

pd_log_sdinterval
Do not specify 0 as the elapsed time.

Appendix D.3 Making backups

Hitachi recommends using the inner replica facility because you can reference and update the database while making a backup. Figure D-1 shows how a backup is made using the inner replica facility.

Figure D-1 Making a backup using the inner replica facility

Explanation

A backup is made from a replica database, which means that the master database can continue to be referenced and updated while the backup is being made.

When an error occurs in the master database, the backup of the replica database can be used to recover the master database.

For details about the inner replica facility, see the manual HiRDB Staticizer Option Version 7 Description and User's Guide.

When the inner replica facility is not used

When the inner replica facility is not used, Hitachi recommends using the updatable mode for making backups (specifying -M s). In such a case, you should make note of the following items:

The pdcopy command may timeout waiting for a lock-release from an update transaction while a backup is being made. To avoid this situation, either increase the lock-release wait time of the pdcopy command (-j option) or execute the pdcopy command when no update transactions have been issued.

The database cannot be recovered from the backup alone. The database must be recovered from a synchronization point subsequent to when the backup was made. Therefore, the backup and the system log from the most recent synchronization point subsequent to when the backup was made are required in order to recover the database. When a database is recovered to the most recent synchronization point, the run ID and generation number of the system log file needed for recovering the target RDAREAs is output to the process results output file for the database copy utility. You must manage all subsequent system log files.
When you recover a database up to the first synchronization point after the backup was made, you must manage the system log files from the last synchronization point before the backup was made to the first synchronization point after the backup was made.

Appendix D.4 Reorganizing databases

Hitachi recommends using the inner replica facility because you can reference and update the database while reorganizing it. This is called updatable online reorganization. If the inner replica facility is not used, the database cannot be referenced or updated while it is being reorganized. Using the inner replica facility minimizes the impact on online job tasks because job processing uses the replica database while the master database is being reorganized. Figure D-2 shows how a database is reorganized using the inner replica facility.

Figure D-2 Database reorganization using the inner replica facility

Explanation

The database reorganization utility (prdorg command) is used to reorganize the master database, and the replica database is used for the online job tasks.

Before reorganizing the current database, another database is committed and the current database is switched to that database. The current database cannot be referenced or updated during this time. After the current database is switched, the master database is reorganized and the replica database is used for performing online job tasks. After reorganization is complete, the system log for the replica database becomes input information and the update processes performed during the reorganization are applied to the master database. This is called reflection processing.

For details about the inner replica facility, see the manual HiRDB Staticizer Option Version 7 Description and User's Guide.

When the inner replica facility is not used

When the inner replica facility is not used, Hitachi recommends using the pdhold command to place RDAREAs storing a reorganization table in hold status so UAPs do not wait for lock-release. This is because EX (the update mode) locks the table during reorganization. UAPs that were accessing in the reorganization table are terminated immediately without waiting for lock-release because RDAREAs in hold status cannot be accessed. Set in the reorganization table the amount of time RDAREAs will not be accessible, and. reorganize the table within that amount of time.

Appendix D.5 Reusing used free pages and free space within pages

Job tasks that repeatedly insert or delete rows in a table reduce the storage efficiency of tables or indexes and become a factor in reducing performance. Therefore, you must regularly use the database reorganization utility to reorganize tables or indexes. However, you must stop job tasks that access the table to be reorganized because that table or index cannot be accessed by other UAPs or by utilities while the database reorganization utility is executing. If job tasks cannot be stopped or indexes cannot be reorganized, you can use the following facilities:

Release used free pages

Free space reusage facility

Releasing used free pages makes it possible to reuse used free pages. Using the free space reusage facility makes it possible to reuse the free space in a page. Combining these facilities makes it possible to increase the time between reorganizations of tables and indexes because data storage efficiency in increased and performance degradation is minimized.

Organization of this subsection

(1) Release used free pages

(2) Free space reusage facility

(1) Release used free pages

When you delete a large amount of table data, such as with a batch job for example, there are cases where some of the pages (data pages) storing that table data become used free pages. Also, if you have defined an index, some of the pages (index pages) storing the index key values become used free pages. Executing the free page release utility (pdreclaim command) makes it possible to change these used free pages into unused pages which can then be reused. This is called releasing used free pages.

For details about releasing used free pages, see 15.9 Re-using used free pages and used free segments.

(2) Free space reusage facility

When the INSERT process cannot store data in a segment, data is stored in a free area in a used segment (a free area on a page) without allocating a new unused segment. This is called the free space reusage facility. Using this facility makes it possible to reuse free areas that became unavailable when data was deleted.

To use the free space reusage facility, specify SEGMENT REUSE when you execute CREATE TABLE. For details about the free space reusage facility, see the manual HiRDB Version 8 Installation and Design Guide.

Appendix D.6 Expanding RDAREAs

Adding data may cause a space shortage in an RDAREA. The methods for ensuring a space shortage does not occur are explained below.

Organization of this subsection

(1) RDAREA automatic extension

(2) RDAREA expansion

(3) RDAREA reinitialization

(1) RDAREA automatic extension

When a space shortage occurs in an RDAREA, segments can be added automatically to increase the size of the RDAREA, provided that space is available in the HiRDB file system area. This is called RDAREA automatic extension. For details about the RDAREA automatic extension, see 15.7 RDAREA automatic extension.

To automatically extend RDAREAs, there must be free space in the HiRDB file system area. Therefore, include sufficient extra space when estimating the HiRDB file system area size.

Note that stopping job tasks is not necessary for extending RDAREAs automatically.

(2) RDAREA expansion

There is a limit to the number of times RDAREA automatic extension explained in (1) above can be performed. When automatic extension is no longer possible, you can expand the RDAREA manually. For details about RDAREA expansion, see 15.3 Increasing the size of an RDAREA (RDAREA expansion).

A maximum of 16 HiRDB files comprise an RDAREA, so no more than 16 HiRDB files can be added to an RDAREA.

Stopping job tasks is not necessary in order to expand an RDAREA.

(3) RDAREA reinitialization

There is a limit to the number of times RDAREA expansion explained in (2) above can be performed. When expansion is no longer possible, you can reinitialize the RDAREA and increase its size. For details about RDAREA reinitialization, see 15.4 Increasing the size of an RDAREA or modifying its attributes (RDAREA reinitialization).

Note that an RDAREA that is being reinitialized cannot be accessed. Therefore, you should us method (1) or (2) above whenever possible.

Appendix D.7 Dynamic updating of global buffers

Hitachi recommends that you install HiRDB Advanced High Availability and specifying Y in the pd_dbbuff_modify operand. This makes it possible to add, modify, and delete global buffers while HiRDB is active. This capability is called dynamic updating of global buffers. You should use dynamic updating of global buffers in the following situations:

For allocating global buffers to an added RDAREA

For modifying a global buffer to be allocated to an RDAREA

For modifying the tuning results or definition of a global buffer

Once HiRDB has terminated, you must change the value specified in the pdbuffer operand, because dynamically modified global buffer information becomes invalid when normal termination or planned termination occurs. However, if you use the system reconfiguration command (pdchgconf command), you can change the value specified in the pdbuffer operand while HiRDB is running.

For details about dynamic updating of global buffers, see 9.3 Adding, modifying, and deleting global buffers while HiRDB is running (dynamic updating of global buffers). For details about using the system reconfiguration command, see 9.2 Modifying HiRDB system definitions while HiRDB is running (system reconfiguration command).

Appendix D.8 Deleting troubleshooting information

When a server process or a client is terminated forcibly, HiRDB outputs troubleshooting information to the $PDDIR/spool directory. Also, when you terminate a command or utility while it is executing by pressing Ctrl-C, for example, temporary work files generated by the command or utility remain in the $PDDIR/tmp directory. If these troubleshooting information and temporary work files are not deleted, they may eventually cause a space shortage on the disk containing the HiRDB directory. To prevent a space shortage from occurring on the disk containing the HiRDB directory and causing HiRDB abnormal termination, HiRDB regularly deletes the files listed below:

Troubleshooting information files (files in the $PDDIR/spool directory)

Temporary work files (work files in the ($PDDIR/tmp directory)

These files are normally deleted every 24 hours. This deletion interval can be changed with the pd_spool_cleanup_interval operand. In addition, files that were output a specific number of days in the past can be deleted by specifying an appropriate value in the pd_spool_cleanup_interval_level operand.

You can also delete troubleshooting information files and temporary work files (files in the $PDDIR/tmp directory) with the pdcspool command.

You select the troubleshooting information to be deleted by specifying it in the pdcspool command option or the pd_spool_cleanup_interval_level operand.

Note

There are situations in which troubleshooting information files output by a command or utility that a user other than the HiRDB administrator executed cannot be deleted. In such cases, a user who has troubleshooting information file deletion privileges uses the OS's rm or other command to delete the files.

If a HiRDB operation command or utility is aborted when the TMPDIR environment variable is specified, there are situations in which HiRDB creates files beginning with the letters pdcmd or plcmd in the directory specified in TMPDIR. If these files are not deleted even after the HiRDB operation command or utility has terminated, the OS's rm or other command can be used to delete them.

Appendix D.9 System switchover facility

If you use the system switchover facility, Hitachi recommends that you include the facilities listed below. Using these facilities minimizes job task downtime by reducing the amount of time required to implement system switchover.

Rapid system switchover facility

Standby-less system switchover facility

Transaction queuing facility (HiRDB/Parallel Server)

Organization of this subsection

(1) Rapid system switchover facility

(2) Standby-less system switchover facility

(3) Transaction queuing facility (HiRDB/Parallel Server only)

(1) Rapid system switchover facility

The rapid system switchover facility activates server processes and system servers in the HiRDB standby system in advance, instead of having to wait for them to be activated during system switchover. This facility reduces the system switchover time by the amount of time that is saved by not having to activate server processes and system servers during system switchover. For details about the rapid system switchover facility, see 25.18.2 Rapid system switchover facility.

(2) Standby-less system switchover facility

In contrast to the standby system switchover facility that prepares an HiRDB standby system, it is not necessary to have a standby system when you use the standby-less system switchover facility. This facility transfers processing to another active unit instead of switching to a HiRDB standby system when an error occurs. This facility reduce the system switchover time by using an active unit.

(3) Transaction queuing facility (HiRDB/Parallel Server only)

When system switchover occurs in a unit with a back-end server or dictionary server, the back-end server or dictionary server cannot accept transactions until switchover is completed. This means that transactions processed by a back-end server or dictionary server that is involved in switchover result in an error.

The transaction queuing facility queues such transactions on the front-end server until system switchover is completed so that errors are not generated. This facility reduces transaction errors during system switchover. For details about the transaction queuing facility, see 25.19 Transaction queuing facility.

Appendix D.10 Program maintenance facility (upgrade to update version)

When you upgrade to the update level (called upgrading to the update HiRDB version), it is not necessary to terminate HiRDB normally. Bu using the program maintenance facility, the version is upgraded to the update level while HiRDB is still active.

The update level version here refers to the underlined part of the revision number, as in 07-00-/A. For example, when upgrading from 07-00-/A to 07-00-/B, it is not necessary to terminate HiRDB normally. This makes it possible to upgrade to the update level without stopping job tasks. For details about the program maintenance facility, see the manual HiRDB Version 8 Installation and Design Guide.

Appendix D.11 Recovery-unnecessary front-end server (HiRDB/Parallel Server only)

When a front-end server unit terminates abnormally, any transaction that was being executed from this front-end server may end up in uncompleted status. A transaction that is thrown into uncompleted status may still be maintaining a lock on the database, thus preventing other transactions from referencing or updating the database. Ordinarily, a transaction in uncompleted status must be completed from the front-end server, so you must first recover the front-end server unit from the error and then restart the unit.

When a recovery-unnecessary front-end server is used, a transaction in uncompleted status is completed automatically when the front-end server unit terminates abnormally (the transaction is completed without waiting for the front-end server to restart). You can install a front-end server unit in an application server that does not use system switchover, and use reduced operation for the front-end server unit.

Whereas normally the pdrplstart and pdrplstop commands can be executed only when all units and servers are running, use of a recovery-unnecessary front-end server means that these commands will execute even though a recovery-unnecessary front-end server or recovery-unnecessary unit is stopped.

For details about recovery-unnecessary front-end servers, see the manual HiRDB Version 8 Installation and Design Guide.

To use a recovery-unnecessary front-end server, HiRDB Non Recover FES must be installed.

Appendix E. Using Performance Improvement Facilities

This Appendix describes facilities designed to improved system performance and explains their use.

Organization of this section

E.1 BES connection holding facility (HiRDB/Parallel Server only)

Appendix E.1 BES connection holding facility (HiRDB/Parallel Server only)

Organization of this subsection

(1) About the BES connection holding facility

(2) Application criteria

(3) Environment setting

(4) Notes

(1) About the BES connection holding facility

When a HiRDB/Parallel Server is used, the front-end server must be connected to a back-end server to start a transaction. Consequently, in a system with a high volume of traffic that requires high throughput, this connection process can become a performance bottleneck. When the BES connection holding facility is used, the connection between the front-end server and a back-end server is not terminated when a transaction terminates. This means that if a subsequent transaction will use the same back-end server, no connection processing is needed between the front-end server and the back-end server. In other words, the BES connection holding facility eliminates a performance bottleneck by eliminated the need for connection processing between the front-end server and a back-end server. Figure E-1 shows the transaction flow when the BES connection holding facility is used.

Figure E-1 Transaction flow when the BES connection holding facility is used

Reference note

Although the BES connection holding facility also reduces the number of processes for disconnecting the front-end server from a back-end server, this does not have much effect on system performance.

The BES connection holding facility cannot hold the connection between the front-end server and the dictionary server. When a transaction involving the dictionary server is terminated, the connection between the front-end server and the dictionary server is terminated.

(2) Application criteria

Because the time required for connecting the front-end server to a back-end server is normally between several milliseconds and dozens of milliseconds, use of the BES connection holding facility is appropriate in systems in which transaction execution time is relatively short (between a few dozen milliseconds and 2 seconds). Using the BES connection holding facility in systems in which transactions take a long time to execute cannot be expected to improve performance.

If HiRDB is always connected in systems described below, the connection between the front-end server and a back-end server may be held even though the back-end server is not being used. Consequently, a shortage may occur in resources such as memory, sockets, and communication ports (a high load level is maintained for each type of resource). Therefore, care must be exercised when using the BES connection holding facility in such an environment.

Systems with a low transaction load

Systems in which specific back-end servers are more used heavily than others (do not use the BES connection holding facility with a back-end server that is used infrequently).

When the HiRDB XA library is used, one connection may equal one transaction depending on the transaction manager used. In such a case, using the BES connection holding facility results in no benefit. For the list of XA libraries that can be used, see the list of libraries used by each transaction manager in the manual HiRDB Version 8 UAP Development Guide.

(3) Environment setting

You must set up the following environment to use the BES connection holding facility:

Set the BES connection holding facility

Set a BES connection holding period

Set a maximum client wait time

Set the number of back-end server processes

(a) Setting the BES connection holding facility

To use the BES connection holding facility, you must specify either (or both) of the following operands:

pd_bes_connection_hold operand

PDBESCONHOLD operand in a client environment definition

When the pd_bes_connection_hold operand is specified, the BES connection holding facility is applied to all UAPs. When the PDBESCONHOLD operand of a client environment definition is specified, the BES connection holding facility is applied only to UAPs executed from the client for which the PDBESCONHOLD operand was specified. The PDBESCONHOLD operand has higher priority than the pd_bes_connection_hold operand. Operand combinations are explained below.

When pd_bes_connection_hold = Y is specified
The BES connection holding facility is applied to all UAPs.

When PDBESCONHOLD = YES is specified
The BES connection holding facility is applied only to UAPs executed from the client for which the operand is specified.

When pd_bes_connection_hold = Y and PDBESCONHOLD = NO are both specified
The BES connection holding facility is applied to all UAPs except for UAPs executed from a client for which PDBESCONHOLD = NO is specified.

(b) Setting the BES connection holding period

Specify how long the BES connection is to be held open after a transaction terminates. When the specified BES connection hold time expires, the connection between the front-end server and the back-end server will be terminated when the next transaction that is executed terminates.

How the BES connection holding period is measured

Measurement of the BES connection holding period starts and ends as explained below:

Measurement starting point: When transaction processing terminates

Measurement ending point: When the next transaction's processing starts

Figure E-2 shows how the BES connection holding is measured and the processing performed by HiRDB.

Figure E-2 Measurement of the BES connection holding period and processing by HiRDB

Explanation

Because interval [1] is within the BES connection holding period, the connection between the FES and BES1 remains open.

Because interval [2] exceeds the BES connection holding period, the connection between the FES and BES2 will be terminated when the next transaction (transaction 3) terminates. When the next transaction to be executed after that (transaction 4) starts, the FES and BES2 must be connected anew.

Notes

Note that the connection between the front-end server and a back-end server does not terminate as soon as the BES connection holding period expires. The following summarizes the processing performed by HiRDB in the event the BES connection holding period expires:

At the point when the BES connection holding period expires
HiRDB does not take any action.

When a transaction starts
Because the connection between the front-end server and the back-end server is still being held, no processing is required to connect the front-end server to the back-end server.

When this transaction terminates
Terminates the connection between the front-end server and the back-end server.

When the next transaction starts
Connects the front-end server to the back-end server.

Specification guidelines for the BES connection holding period

For a system in which the UAP connection period is brief, set the BES connection holding period to 0.

For a system that is always connected or in which the UAP connection period is prolonged, do not specify the BES connect hold period; instead, use the default value (1 second).

Operation when 0 is specified as the BES connection holding period

When 0 is specified as the BES connection holding period, time is not monitored and the connection between the front-end server and the back-end server is held open indefinitely. However, such a connection will be terminated in the cases explained in (4)(b) Cases in which a connection hold is cancelled.

Specifying the BES connection holding period

To specify the BES connection holding period, you specify either (or both) of the following operands:

pd_bes_conn_hold_trn_interval operand

PDBESCONHTI operand in a client environment definition

The BES connection holding period specified with the pd_bes_conn_hold_trn_interval operand is applied to all UAPs. In contrast, the BES connection holding period specified with the PDBESCONHTI operand in a client environment definition is applied only to UAPs executed from the client for which the PDBESCONHTI operand was specified. The PDBESCONHTI operand has higher priority than the pd_bes_conn_hold_trn_interval operand. Operand combinations are explained below.

When pd_bes_conn_hold_trn_interval = 10 is specified

The BES connection holding period is 10 seconds for all UAPs.

When PDBESCONHTI = 10 is specified

The BES connection holding period is 10 seconds for UAPs executed from the client for which this operand is specified.

When pd_bes_conn_hold_trn_interval = 10 and PDBESCONHTI = 20 are specified

The BES connection holding period is 20 seconds for UAPs executed from the client for which the PDBESCONHTI operand is specified and 10 seconds for all other UAPs.

(c) Setting the maximum client wait time

If a back-end server unit being held in connected status terminates abnormally, the next transaction to be executed by the back-end server may enter no-response status. Also, when the transaction queuing facility is used, the retry processing specified by the pd_ha_trn_restart_retry_time operand may not occur, resulting in a no-response (a no-response may also occur during planned system switchover). For this reason, you should use the PDCWAITTIME operand in the client environment definition to specify a maximum client wait time so that situations in which transactions stop responding can be handled. If there is no response from a transaction within the time specified by the PDCWAITTIME operand, the transaction is cancelled.

(d) Setting the number of back-end server processes

To use the BES connection holding facility, you should set the number of individual back-end servers to be greater than the total number of front-end servers in the system. To do so, specify values for the system definition operands so that the following condition is satisfied:

value-of-pd_max_bes_process-operand

value-of-pd_max_users-operand number-of-front-end-servers

If this condition is not satisfied, a shortage may occur in the number of available back-end server processes, and, as a result, the message queue monitoring facility may cause HiRDB (or unit for a HiRDB/Parallel Server) to terminate abnormally or an SQL error may occur.

To execute utilities while UAPs are running, the number of back-end server processes you specify must also include the number needed by the utilities.

(4) Notes

(a) Do not use for definition SQLs

Do not use the BES connection holding facility for a UAP that executes a definition SQL. If the facility is used for such a UAP, connection between the front-end server and back-end server may occur simultaneously with connection between the dictionary server and the back-end server, and, as a result, a shortage may occur in the number of available back-end server processes, causing an SQL error. You can prevent this situation from occurring by specifying NO in the PDBESCONHOLD operand in the client environment definition of any UAP that executes a definition SQL.

(b) Cases in which a connection hold is cancelled

Even when the BES connection holding facility is used, the connection between the front-end server and a back-end server is terminated unconditionally in the following cases:

Connection between the front-end server and the client is terminated by a DISCONNECT statement (or xa_close when HiRDB XA library is used) or because the time specified by the PDCWAITTIME operand expires.

Rollback (including internal rollback) occurs.

The facility for monitoring the memory size of server processes determines that the memory usage upper limit has been exceeded.

A large amount of memory is used internally.

The pdpfresh command (without the -f option specified) is executed.

The cursor of a holdable cursor is closed.

(c) Connection may not be terminated even when the BES connection holding period has expired

In the following cases, the connection between the front-end server and back-end server is not terminated even though the BES connection holding period has expired:

A holdable cursor is used

A local buffer specified in the UAP environment definition is used

Index

[Symbols]
[Numbers]
[A][B][C][D][E][F][G][H][I][J][K][L][M][N][O][P][R][S][T][U][V][W]

(Symbols)

-c option

-M option (pdcopy command)

(Numbers)

1-to-1 switchover configuration

example of (HiRDB/Parallel Server)

example of (HiRDB/Single Server)

(A)

abnormal termination

notes on

of OS

abort code (Polkcrt)

abstract data type

deleting

subtypes of, deleting

table reorganization

accepting unit

starting

access control, shared disk

access privilege

access privilege

granting

granting (group)

granting (role)

revoking

setup (Directory Server linkage facility)

to audit trail table

account lock period

checking

accumulated condition analysis results, resetting

accumulation-differential backup

creating

examples of making

actcommand operand (Hitachi HA Toolkit Extension)

active processes, tuning maximum number of

acttype operand (HA monitor)

agent

definition

definition pre-preparation

alias IP address

alias operand (HA monitor)

allocated routine definition cache size

allocated type definition cache size

alter HiRDB mode to parallel statement

ALTER PROCEDURE

alter rdarea statement

ALTER ROUTINE

ALTER TABLE

adding column

deleting column

modifying table's definition

alternate BES

alternate BES unit

starting

switching system to

terminating

alternate portion

releasing waiting status of

starting

terminating

alternating

ASSIGN LIST statement

audit event

adding

definition of

deleting

audit event types

auditor security event

object definition event

object manipulation event

privilege management event

session security event

system administrator security event

utility operation event

audit privilege

audit trail

collecting

narrowing

audit trail data recording UOC

audit trail file

checking status of

creating

creating HiRDB file system area for

current

data load completed

data load waiting

deleting

error handling for

information output to

manipulating HiRDB file system area for

naming of

operation of

shutdown

standby

status of

swapping

swapping

using

audit trail record items

at event termination

during privilege checking

audit trail table

access privilege

columns of

creating

creating RDAREA to store

defining index for

deleting

manipulating

manipulating RDAREA storing

recording data in

recording data in

reorganizing

using

auditor

changing password

changing password

deleting schema of

privilege setup (Directory Server linkage facility)

registering

automatic extension

automatic log unloading facility

error handling

using

automatic reconnect facility

automatic startup

average value

(B)

B-tree index

back-end server

for load balancing, migrating

load balancing performed by user

backup

acquisition (JP1/OmniBack II)

acquisition with use of frozen update command

examples of

HiRDB file system area

making (24-hour continuous operation)

procedure for

questions about

timing

unit

without using pdcopy command

backup acquisition mode

backup acquisition mode

referencing/updating-impossible mode

referencing-permitted mode

updatable mode

backup acquisition time, reduced (user LOB RDAREAs)

backup file

checking contents of

creating (character special file)

size of

backup-hold

backup-hold

deadlock during

lock-release timeout during

reference-possible

reference-possible (update WAIT mode)

updatable

updatable (WAIT mode)

barlist file

batch retrieval

BES connection holding facility

BES connection holding period

BINDDN

BINDPASSWORD

buffer length

for registry information, tuning

for routine definition information, tuning

for SQL object, tuning

for table definition information, tuning

for user privilege information, tuning

for user-defined type information, tuning

for view analysis information, tuning

tuning

buffer lock-release waits count

buffer pool lock time during synchronization point processing

buffer sectors count, maximum concurrent request

buffer shortages count

buffer utilization status

(C)

character special file, creating unload data file in

client environment definition specification (system switchover facility)

client group

connection frame guarantee facility for

type of

client maximum wait time

cluster key

storage condition analysis

storage condition analysis

storage efficiency of

cluster software

cluster system

clustering data page

storage condition analysis

storage condition analysis

storage efficiency

ClusterPerfect, preparation

column

adding

adding (abstract data type column)

adding (LOB column)

adding (to table with FIX attribute)

adding (to table with FIX attribute)

adding (to table with FIX attribute)

adding (to table without FIX attribute)

changing data size of

changing name of

deleting

column structure information files, specification examples of

combine facility

command, deadlock priority value for

commit

commit second phase wait status

communication error

condition analysis

by index

by RDAREA

by table

CONNECT privilege

granting

granting

revoking

setup (Directory Server linkage facility)

connected user data file

connected user data file

connected user details file

connected user details file

connection security facility, using

consecutive certification failure account lock state

checking for users in

releasing

consecutive certification failures

cancelling limit on number of

changing limit on number of

checking permitted number of

limit on number of

permitted number of

setting new limit on number of

conventions

diagrams

fonts and symbols

KB, MB, GB and TB

version numbers

CPU error

CREATE AUDIT

create audit table statement

create auditor statement

CREATE CONNECTION SECURITY

CREATE CONNECTION SECURITY

CREATE FUNCTION

CREATE PROCEDURE

create rdarea statement

current file

changing (status file)

changing file used as

error in (status file)

error in (system log file)

error in (system log file)

error in both versions of (status file)

unloading

(D)

d_reduced_check_time operand

data dictionary LOB RDAREA

for storing objects

for storing sources

data dictionary table, referencing privilege for

data retrieval efficiency

data storage efficiency

in RDAREAs

data, migrating to another table

database

committing

reorganization utility (table reorganization)

reorganizing (24-hour continuous operation)

tuning

update log acquisition mode of

database management table

data dictionary RDAREA for storing

database recovery

overview of

procedures for

utility

database state analyzed table

data dictionary RDAREA for storing

database structure modification utility

deleting HiRDB file

migrating to HiRDB/Parallel Server

RDAREA addition

RDAREA deletion

RDAREA expansion

RDAREA migration

RDAREA modification

RDAREA reinitialization

database update log acquisition mode

database update log acquisition mode

operational difference depending on

selecting (table reorganization)

database write processing by reference request hit during synchronization point processing, take-over count of

DBA privilege

granting

revoking

setup (Directory Server linkage facility)

DCWAITTIME timeout

deadlock

in event of

priority value

priority value

deadlock information

output

using

deadlock priority

change value of

value for command

decimal signed normalized number, facility for conversion to

decimal type, converting sign portion of

deferred write processing

increasing number of parallel WRITE processes during

interpreting statistical information about

tuning

deferred write trigger

increasing update page output rate during

reducing interval

definition SQL

creating

creating

from table

delayed batch creation

DELETE privilege

DELETE statement

deletion prevented duration

device driver

DF/UX

distribution definition of

environment definition of

environment setup for

installation of

DF/UX Extension

distribution definition of

environment definition of

environment setup for

installation of

package creation for

dfsvplink command

diagram conventions

dictionary import/export utility

migrating stored procedure

migrating table definition information

differential backup

acquiring

group

history file for

differential backup facility

differential backup facility

for database recovery

differential backup management file

restoring

differential index facility

directory for unload log files

creation of

Directory Server linkage facility

environment setup for

handling lower-case letters

handling upper-case letters

using

Directory Service

disk agent

disk error, handling of

disk group creation

disk operand (HA monitor)

disk space shortage

database reorganization utility

during backup

disk volume, parallel level for each

distributed client facility

distributed database

character codes environment

environment setup for

environment variable setup for

establishing connection with another node's HiRDB

handling of authorization identifier

handling of password

information output for communication error

scope of

security

using

distributed server facility

double lock, releasing

DROP AUDIT

DROP CONNECTION SECURITY

DROP DATA TYPE

DROP FUNCTION

DROP INDEX

DROP PROCEDURE

dummy file

DVD-RAM library device, operations using

(E)

ECOVERY operand

EMPTY option

environment setup file

creating

example of

example of

error

actions taken by HiRDB administrator for

handling procedures for

in both versions of current file (status file)

in current file (status file)

in data linkage file

in files (other than system file)

in HiRDB system definitions file

in master directory RDAREA

in message log file

in statistics log file

information needed for

of status file

questions about

synchronization point dump file of

while linked to OLTP system

while local buffer is being used

error log file

error shutdown

handling of

event subtype

event type

execution mode

exclusive mode

rebalancing utility

shared mode

execution time

expand rdarea statement

extent

(F)

falsification prevented table

falsification prevention facility

falsification prevention option

file name, linking symbolically

file status, changing

file status, changing

FILTERPREFIX

FIX hash partitioning (changing hash function)

FIX table, adding column to

flexible hash partitioning (changing hash function)

font conventions

free area for system log file, percentage of

free page release utility

free space

reusage facility of

within page, reusing

frozen update command

frozen update command

backup acquisition with use of

frozen update status

releasing

full backup

(G)

GB, meaning of

global buffer

adding

adding

allocating (RDAREA addition)

changing

changing definition of

deleting

deleting

dynamic updating of

dynamic updating of (24-hour continuous operation)

for data when alternating unit, allocating

maximum number of

maximum number of shared memory segments used for

modification

global buffer pool

hits rate

tuning

global buffer table

globalbuffer operand (create rdarea statement)

GRANT AUDIT

GRANT statement

group

deleting

granting table access to

registering

group ID

group operand (HA monitor)

grouped system switchover

with HiRDB Datareplicator

guaranteed valid generations

increasing number of

number of

number of

guest area

guest BES

starting

(H)

HA group

HA monitor, preparation

HACMP, preparation

hareg command

hash facility for hash row partitioning

hash function, changing

hash group

HiRDB

24-hour continuous operation

abnormal termination of

actions taken at restart failure of, due to error in both versions of current file

automatic startup of

changing computer name

data service control script

data service registration

forced startup of

forced termination due to no swappable target audit trail file

forced termination of

information inherited during restarting

manual startup of

normal startup failure of

normal startup of

normal termination of

planned termination of

reduced activation (HiRDB/Parallel Server)

reducing startup processing time of

restart after planned termination of

restart failure of

restarting

special startup procedure

starting

starting

starting while there is erroneous status file

startup failure of

startup modes

startup of

startup of

startup of (system switchover facility)

startup procedure used in event of error in master directory RDAREA

startup procedure used to reinitialize database

startup processing errors of (HiRDB/Parallel Server)

terminating

terminating

terminating during OS shutdown

termination failure of

termination failure of (due to connected user)

termination modes

termination of

termination of

termination of (system switchover facility)

upgrading to update version

when startup processing takes too long

when termination processing takes too long

HiRDB administrator

actions taken by, when errors occur

actions taken by, when errors occur

system log file

HiRDB Advanced High Availability

HiRDB Advanced High Availability

HiRDB Advanced Partitioning Option

HiRDB CM

HiRDB Datareplicator

at extracted side

modifying HiRDB system definition

system reconfiguration command

HiRDB directory, recovery of

HiRDB file system area

backing up

creating

creating for audit trail file

deleting

handling error in

information about

owner for

restoring

HiRDB file system area (RDAREAs) table

HiRDB LDAP Option

HiRDB LDAP Option environment definition file, creating

HiRDB Non Recover FES

HiRDB process

not active

HiRDB system definition

creating

modifying

modifying (system reconfiguration command)

modifying, partly available

specifying (24-hour continuous operation)

HiRDB Text Search Plug-in

HiRDB/Parallel Server

HiRDB startup processing errors

HiRDB, reduced activation

migrating to

server startup procedure

server termination procedure

unit startup procedures

unit termination procedures

history file for differential backups

Hitachi Disk Array Driver for AIX

Hitachi HA Toolkit Extension

preparation

service processing for

host BES

starting

host name

changing

handling of

(I)

I/O error, handling of

index

batch creation of

creating definition SQL from

defining for table

deleting

handling

questions about

re-creation

storage efficiency of

storage efficiency of

tuning

unfinished

index information files (batch creation of plug-in index)

index page splitting

index reorganization

when error occurs during

initial operand (HA monitor)

initialize rdarea statement

inner replica facility

index information file name

using list

input waits count

INSERT privilege

interval analysis

IP address

configuration examples of

inherited

inherited

inherited

not inherited

not inherited

not inherited

switching

iPlanet Console

(J)

JAR file

directory for storing

operations of

when error occurs in

Java class path

Java option

Java Runtime Environment, root directory of

Java stored function

environment setup procedure for use of

supported environment

Java stored procedure

environment setup procedure for use of

supported environment

Java Virtual Machine

library directory of

output destination file for standard error output of

output destination file for standard output of

position

jobnet

JP1/AJS2

JP1/AJS2-SO

JP1/OmniBack II

backup acquisition using

registering user into

JP1/VERITAS NetBackup Agent for HiRDB License

(K)

KB, meaning of

KFPA20009-W

KFPS00888-W

KFPS00889-E

KFPS00992-E

KFPS01861-E

KFPS01910-I

KFPS02179-I

KFPS04665-W

KFPS05120-W

(L)

LAN adapter, switching

lan_updown operand (HA monitor)

LDAP

LDAPHOST

LDAPPORT

list

changes when initializing

command for checking information

managing

STANDBY specification

list RDAREA

backup

space shortage in

load balancing, migrating back-end servers for

LOB column structure base table (table reorganization)

local access

lock (backup-hold)

lock mode

lock mode

lock mode

lock mode

lock mode

lock mode

lock mode

lock mode

lock occurrence time

lock occurrence time

lock-release contention rate in global buffer lock processing

locked resource information

locked resource information

locked resource information

locked resource information

locked resource type

locked resource type

locked resource type

locked resource type

locked resources management table

data file name of

information of

shortage of

log acquisition mode

log acquisition mode

log acquisition mode

update

log point concept

log point information file

logical analysis information

for RDAREA

logical device, creating

logical host

confirming startup of

creating

creating management file system of

registering host name of

logless hold

logless hold

lower case letter, handling (Directory Server linkage facility)

LVM

LVM

LVM

(M)

Management Framework

master directory RDAREA, error in

MB, meaning of

MC/ServiceGuard

grouped configuration, with HiRDB

preparation

service monitored by

media agent

merge analysis

message log

output destination of

output dispersion of

output method for

referencing

message log file

changing size of

swapping

message queue monitoring facility

message queue monitoring time

message queue stagnation

causes of

corrective measures for

method

MIB

MIB command

MIB definition file

MIB definition file

registering

MIB environment definition file

creating

MIB performance information, using facility for monitoring

migrating back-end servers (load balancing)

mirror disk

mirroring facility

mismatch between original and mirror duplicate, actions to take in case of

monitor mode

monitor script

monitoring facility

abnormal termination

free area for system log file

skipped effective synchronization point dump

mount prompt, setting automatic processing of

move rdarea statement

multi-step system switchover

multiple front-end server

multi-standby function

multistandby operand (HA monitor)

mutual alternating configuration

mutual system switchover configuration

example of (HiRDB/Parallel Server)

example of (HiRDB/Single Server)

(N)

name operand (HA monitor)

narrowed search

NetBackup linkage facility

network setup (Sun Cluster)

NETWORKTIMELIMIT

no-log mode

no-log mode

nonresponding program, reducing effect of

normal BES

normal BES unit

releasing waiting status of

starting

switching system back to

terminating

normal operation mode, returning to

normalization

(O)

occupied resource information

occupied resource information

occupied resource information

occupied resource information

occupied resource type

occupied resource type

occupied resource type

occupied resource type

offline script

one-way alternating configuration

online reorganization

overwriting denied status for

overwriting permitted status for

updatable

online script

opening trigger attribute

operand

for specifying maximum number of active processes

for specifying number of resident processes

operation

in event of error (Directory Server linkage facility)

no-log mode

pre-update log acquisition mode

without acquiring database update log

without acquiring database update log, notes on backup

without unloading system log

without unloading system log

without unloading system log information

operation command

execution error of

in timeout while waiting for response

output waits count

overwrite enabled file, unavailable

(P)

package

IP address of (MC/ServiceGuard)

package control script

page compaction

page destruction, handling of

page splits, number of

page statuses

free page

full page

unused page

used free page

used page

parallel WRITE time

partitioning definition, changing

partitioning storage condition

for table, changing

for table, changing

for table, prerequisites

purpose of changing

password character string restriction

cancelling

changing

setting

password restriction

prohibition on use of authorization identifier

prohibition on use of only one type of characters

Specifiable minimum in bytes

password, changing

password, changing

PASSWORD_TEST column

password-invalid account lock state

checking for users to be placed in

deleting privilege from user in

granting privileges to users in

releasing

path error

path error

PCTFREE operand (CREATE INDEX)

pd_aud_async_buff_count operand

pd_aud_async_buff_retry_intvl operand

pd_aud_async_buff_size operand

pd_aud_file_name operand

pd_aud_file_wrn_pnt operand

pd_aud_max_generation_num operand

pd_aud_max_generation_size operand

pd_aud_no_standby_file_opr operand

pd_audit operand

pd_audit operand

pd_bes_conn_hold_trn_interval operand

pd_bes_connection_hold operand

pd_command_deadlock_priority operand

pd_db_io_error_action operand

pd_dbbuff_modify operand

pd_dbsync_point operand

pd_deadlock_priority_use operand

pd_dec_sign_normalize operand

pd_directory_server operand

pd_down_watch_proc operand

pd_ha operand

pd_ha_acttype operand

pd_ha_agent operand

pd_ha_agent operand

pd_ha_ipaddr_inherit operand

pd_ha_max_act_guest_servers operand

pd_ha_max_server_process operand

pd_ha_mgr_rerun operand

pd_ha_mgr_rerun operand

pd_ha_mgr_rerun operand

pd_ha_prc_cleanup_check

pd_ha_resource_act_wait_time

pd_ha_restart_failure operand

pd_ha_server_process_standby operand

pd_ha_server_process_standby operand

pd_ha_switch_timeout operand

pd_ha_transaction operand

pd_ha_trn_queuing_wait_time operand

pd_ha_trn_restart_retry_time operand

pd_ha_unit operand

pd_java_archive_directory operand

pd_lck_deadlock_info operand

pd_lck_wait_timeout operand

pd_list_initialize_timing operand

pd_log_auto_unload_path operand

pd_log_remain_space_check operand

pd_log_sdinterval operand

pd_log_unload_check operand

pd_log_unload_check operand

pd_log_unload_check operand

pd_max_ard_process operand

pd_max_bes_process operand

pd_max_dic_process operand

pd_max_users operand

pd_mlg_file_size operand

pd_mlg_msg_log_unit operand

pd_mode_conf operand

pd_mode_conf operand

pd_plugin_ixmk_dir operand

pd_process_count operand

pd_process_count operand

pd_process_count operand

pd_queue_watch_time operand

pd_queue_watch_timeover_action operand

pd_redo_allpage_put operand

pd_redo_allpage_put operand

pd_registered_port operand

pd_registry_cache_size operand

pd_rorg_predict operand

pd_routine_def_cache_size operand

pd_service_port operand

pd_space_level operand

pd_spd_syncpoint_skip_limit operand

pd_spool_cleanup operand

pd_spool_cleanup_interval operand

pd_spool_cleanup_interval_level operand

pd_spool_cleanup_level operand

pd_sql_objet_cache_size operand

pd_start_level operand

pd_start_skip_unit operand

pd_stj_file_size operand

pd_svr_castoff_size operand

pd_table_def_cache_size operand

pd_trn_rerun_branch_auto_decide operand

pd_type_def_cache_size operand

pd_view_def_cache_size operand

pdacunlck command

pdaudbegin command

pdaudend command

pdaudrm command

pdaudswap command

PDBESCONHOLD operand

PDBESCONHTI operand

pdbkupls command

pdbuffer operand (-c option)

pdbufmod command

pdcancel command

pdcat command

pdchgconf command

PDCLTAPNAME operand

PDCLTGRP operand

pdcltgrp operand

pdcspool command

PDCWAITTIME operand

PDCWAITTIME operand

pddbfrz command

pddbfrz command

PDDBLOG operand

pddbls command

pddbls command

pddefrev command

pddefrev command

pddefrev command

pdexp command

migrating stored procedure

migrating table definition information

pdf_utl_exec_time operand

pdfbkup command

pdfls command

pdfmkfs command

pdfrm command

pdfrstr command

pdfstatfs command

pdgeter command

pdgrprfl command

pdhagroup operand

pdjarsync -S command

pdjarsync command

pdlistls command

pdlogatul command

pdlogchg -z command

pdlogunld command

pdls -d aud command

pdls -d mem command

pdls -d prc command

pdls -d svr command

pdmlgput operand

pdmod command

deleting HiRDB file

migrating to HiRDB/Parallel Server

RDAREA addition

RDAREA deletion

RDAREA expansion

RDAREA migration

RDAREA modification

RDAREA reinitialization

PDPLGIXMK operand

pdrbal command

pdreclaim command

pdrorg command (table reorganization)

pdrstr command

PDSPACELVL operand

pdstart -a command

pdstart -i command

pdstart -r command

pdstart command

server machine where pdstart command is executed

pdstbegin command

pdstjacm command, function of

pdstjsync command

pdstop command

server machine where pdstop command is executed

pdusrchk command

performance, questions about

permit update status

physical analysis information for each RDAREA

planned system switchover

plug-in index

delayed batch creation of

reorganization of

PNM setup

Polkcrt (abort code)

port

port numbers, specifying range of

POSIX library

POSIX library

power failure

pre-update log acquisition mode

pre-update log acquisition mode

pre-update log acquisition mode

prefetch buffer shortages count

prefetch hit pages count

prefetch hits rate

prefetch input pages count

primary system

private RDAREA

private RDAREA

process abnormal termination monitoring facility (system switchover facility)

process ID

process ID

process ID

process ID

process ID

process ID

process startup and monitoring, relationship between (MC/ServiceGuard)

process-down message when transaction is cancelled, facility for changing

processes

in asynchronous READ processing, tuning number of

tuning number of

program maintenance facility

public RDAREA

public RDAREA

PURGE TABLE statement

(R)

range specification, recovery with

rapid system switchover facility

system configuration example, using

RD node name

RDAREA

actions taken for page destruction in

actions taken for I/O error of

addition of

automatic extension of

automatic extension of

backing up of

backing up of

creating, to store audit trail table

deleting

example in which non-partitioning key index is not created during reorganization by

expanding (24-hour continuous operation)

expansion of

holding

I/O error of (system switchover facility)

migration of

modification of

moving

opening trigger attribute of

opening trigger attribute of, modifying

questions about recovery of

reinitialization of

reinitialization of (registry LOB RDAREA)

reinitialization of (registry RDAREA)

reorganization by

space shortage in

space shortage in

space shortage in

status of

to be backed up together

unused space in

with OTHERS specified

with OTHERS specified

RDAREA details table

RDAREA table

RDAREA usage privilege

granting

revoking

setup (Directory Server linkage facility)

read/write operations, checking number of

real READs count

real WRITEs count

rebalancing facility

rebalancing table

defining

increasing number of row partitions in

rebalancing utility

execution mode

using

when table rebalancing takes time

recovery

of all RDAREAs

of all RDAREAs

of all RDAREAs to backup point

of all RDAREAs to most recent synchronization point

of database to most recent synchronization point

of database to point at which backup was made

of master directory RDAREA only

of specified RDAREAs

of specified RDAREAs

of specified RDAREAs

of specified RDAREAs

of specified RDAREAs to backup point

using JP1/OmniBack II for

using JP1/OmniBack II for

when backup was not made with pdcopy command

when differential backup management file is not available

with range specification

recovery-unnecessary front-end server

HiRDB/Parallel Server only

system reconfiguration command

reduced activation

reduced activation

handling of

reference buffer flushes count

reference privilege for data dictionary table

reference privilege for data dictionary table

reference requests hits rate

reflection processing

regular unit

starting

remote database access facility

remove rdarea statement

reorganization

by RDAREA

by schema

by table

examples of

with large quantity of data

with synchronization points set

with synchronization points set (abnormal termination of utility)

reorganization time

customizing prediction for

facility for predicting

predicting

stopping prediction for

reorganization time prediction data

analysis of

collection of

collection of

resident process, tuning number of

resource

attribute setting value

defining parent-child relationships of

information

interpreting information

migrating between systems

monitoring utilization factor of

types of

utilization factor of

resource type definition

restoring, HiRDB file system area

retrieval performance

REVOKE statement

role

deleting

registering

ROLEBASEDN

ROLESCOPE

rollback

rollback

rollback

rollforward

routine definition cache hits count

routine definition information acquisition requests, number of

row partition, increasing number of

running system

RUNTIMEPATH

(S)

scenario

abnormal termination

back-end server load balancing

preparation

setting HiRDB scenario

startup

takeover

template

termination

variable value

scheduled database maintenance date

schema

deleting

deleting (auditor)

migrating tables of

reorganization by

when schema cannot be deleted

schema definition privilege

granting

revoking

setup (Directory Server linkage facility)

secondary system

secure status

security

distributed database

security audit facility

environment setting for

operand

using

version upgrading

security facility (Directory Server linkage facility)

segment statuses

free segment

full segment

unused segment

used free segment

used segment

SELECT privilege

semaphore

semaphore identifier

SERCHSUFFIX

SERCHTIMELIMIT

server

monitoring operating statuses

moving

removing

startup procedure (HiRDB/Parallel Server)

startup procedure for

termination procedure (HiRDB/Parallel Server)

termination procedure for

server configuration modification, not available

server definition statement

HA monitor

Hitachi HA Toolkit Extension

server facility executable file, creating

server failure

server failure monitoring time

server ID

server mode

server processes

abnormal termination of (system switchover facility)

abnormal termination, monitoring number of times

changing number of

changing number of

engaged in service execution, number of

facility for monitoring memory size of

monitoring status of

reducing number of

that are down, monitoring for

under service execution, number of

server status table

service creation (Sun Cluster)

service processing (Hitachi HA Toolkit Extension)

service registration (Sun Cluster)

service request exceeding maximum number of active processes, number of

servmax operand

HA monitor

Hitachi HA Toolkit Extension

shared disk

access control

access control by cluster software

access control by HiRDB

setup (Sun Cluster)

shared disk unit, preparing

shared memory utilization status, obtaining

shell for backing up, example of

shell script

for generating dummy process (MC/ServiceGuard)

for starting HiRDB (MC/ServiceGuard)

for terminating HiRDB (MC/ServiceGuard)

MC/ServiceGuard

sign portion, converting

signed packed format

sleep processing execution count, average value in buffer lock processing

SNMP

SNMP agent

space conversion facility

space conversion levels

special startup procedure for HiRDB

split facility

splits count

SQL

output format of runtime warning information

runtime warning information file

runtime warning output facility

tuning

SQL object buffer hits count

for stored procedure object

SQL objects

acquisition requests, number of

acquisition requests, number of

in SQL object buffers, number of

length of

removed from SQL object buffers, number of

standard value

customizing

standard value definition file

STANDBY specification (using list)

standby system

standby system switchover facility

standby-less system switchover (1:1) facility

definition of global buffers

standby-less system switchover (effects distributed) facility

definition of global buffers

specifying switching destination

standby-less system switchover (effects distributed), system configuration examples of

standby-less system switchover facility

standbypri operand (HA monitor)

START_NET, script executed by

startup modes

forced startup

HiRDB

normal startup

restart

statistical information

when linked to OLTP system

when linked to OpenTP1

when linked to TPBroker

when linked to TUXEDO

when linked to WebLogic Server

statistics information types

CONNECT/DISCONNECT statistical information

deferred write processing statistical information

global buffer pool statistical information

index statistical information

index statistical information

SQL dynamic optimization information

SQL object execution information

SQL statement statistical information

SQL static optimization information

SQL statistical information

statistical information on HiRDB files for database manipulation

statistical information on operation of foreign servers

statistical information on usage status of foreign servers

statistics on SQL object transmission

system activity statistical information

UAP statistical information

statistics log file

creating

handling

handling of (system switchover facility)

swapping

statistics log information, servers subject to collection of

status file

adding new

changing status of

checking information in

commands used to manipulate

current

deleting

deleting

entity of

error in both versions of current file

error in current file

errors of

increasing size of

initializing

modifying

procedure for manipulating

questions about

record utilization factor

reducing size of

reserved

shutdown

spare

starting HiRDB while there is erroneous

status changes of

status of

swapping

status file swapping

status information file for system log file

STOP_NET, script executed by

stored function

creating

deleting

stored procedure

creating

deleting

length of object

object acquisition requests, number of

object acquisition requests, number of

object recompilations count

objects in SQL object buffers, number of

objects removed from SQL object buffers, number of

procedure for migrating

procedure for migrating

Sun Cluster

cluster startup

control script

preparation

service control specification of

Sun Java System Directory Server linkage facility

Sun ONE Console

SUSPEND status

SUSPEND status

front-end server from

swappable target status

checking for files in

when there is no file in

switchtype operand

HA monitor

Hitachi HA Toolkit Extension

symbol conventions

synchronization point

about

synchronization point dump

interval

validated

validated

synchronization point dump file

adding

adding new

commands used to manipulate

deleting

deleting

errors of

increasing number of guaranteed valid generations of

increasing size of

initializing

manipulating

modifying

overwrite disabled

overwrite enabled

questions about

reducing size of

reserved

status changes of

status changes of

status of

system log file corresponding to

writing

synchronization point dump interval, tuning

synchronization point dump pages, number of

synchronization point lines count

synchronization point processing time

reducing

tuning

syntax conventions

SYS statistics table

sysdef definition statement

HA monitor

Hitachi HA Toolkit Extension

syslogfile, suppressing message out to

system configuration

example (system switchover facility)

modifying

system configuration command

limitation at execution

restriction at execution

system failure

system file, deleting

system log file

adding new

changing record length of

commands used to manipulate

current

current, swapping

deleting

deleting

disk error

error during restart processing

error in

error in

error in both versions of current file

error in current file

error of

error, using HiRDB Datareplicator

extracting status

extraction completed state

handling method for

HiRDB administrator

increasing size of

manipulating

modifying

monitoring free area for

overwrite disabled state

overwrite enabled

percentage of free area for

questions about

record length

reducing size of

releasing

releasing

releasing

releasing checking of unload status of

reserved

space shortage of

standby

status changes of

status information file for

status of

swappable

swapped

unload completed

unload wait state

unloading

unswappable

system log information, unloading

system log, unloading

system log, unloading

system manager unit

actions to take when error occurs in

actions to take when stopped unit prevents switching of

system operating environment

obtaining

system reconfiguration command

24-hour continuous operation

environment in which system reconfiguration command cannot be executed

HiRDB status after execution of

if error occurs at execution of

system status, monitoring

system switchover facility

24-hour continuous operation

application criteria for

system configuration example

system reconfiguration command

using

system switchover time

comparing

reducing

system switchover, operating procedure after

system time, changing

system, switching back

system's internal processing, tuning

(T)

table

base

before reorganizing

changing name of

changing partitioning definition

checking storage efficiency of

containing large quantity of data, reorganizing

defining index for

deleting

deleting data from

handling

migrating (schema)

migrating (to different schema)

modifying definition of

questions about

reorganization by

reorganizing

table access privilege

group

role

table data

migrating

reloading

unloading

table definition information

acquisition requests, number of

buffer hits count

procedure for migrating

table reorganization

table reorganization

before

dictionary table

example: reorganizing data dictionary tables

example: reorganizing in no-log mode

example: reorganizing RDAREA

example: reorganizing schema

example: reorganizing table (HiRDB/Parallel Server)

example: reorganizing table (HiRDB/Single Server)

example: reorganizing table in which abstract data type is defined

example: reorganizing table in which LOB column is defined

examples of

execution units for

HiRDB Datareplicator

in unit

with large quantity of data

table reorganization time, predicting

table row partitions

increasing number of

increasing number of (using hash facility for hash row partitioning)

TB, meaning of

termcommand operand

HA monitor

Hitachi HA Toolkit Extension

termination modes

abnormal termination

forced termination

HiRDB

normal termination

planned termination

TEST option

time series list, creating (unload log file)

TIMEOUT

timeout

in event of

timeout detection date and time

timeout information

output

using

total routine definitions cache size

total type definitions cache size

total WRITE time

transaction

actions taken when there is an undetermined transaction

actions taken when transactions remain resident

in FORGETTING status

recovering

transaction completion type

checking

checking, when error occurs during commit processing

transaction identifier

transaction identifier

transaction identifier

transaction identifier

transaction queuing facility

transaction status 1

transaction status 2

troubleshooting information

troubleshooting information

abort information file

collected by HiRDB when error occurs

command trace file

connected users data file

connected users details file

data file for locked resources management table

deleting

deleting (24-hour continuous operation)

error log file

message log file

reducing outputted amount of

RPC trace file

save core file

shared memory dump file

simple dump file

snap during error

troubleshooting, information needed for

tuning

buffer length

buffer length for registry information

buffer length for routine definition information

buffer length for SQL object

buffer length for table definition information

buffer length for user privilege information

buffer length for user-defined type information

buffer length for view analysis information

database

deferred write processing

global buffer pool

index

maximum number of active processes

number of processes

number of processes in asynchronous READ processing

number of resident processes

SQL

synchronization point dump interval

synchronization point processing time

system's internal processing

tuning information

collecting

collecting

collecting

collecting from statistics log

collecting from system log

obtaining

starting collection of

using database condition analysis utility to collect

type definition cache hits count

type definition information acquisition requests, number of

(U)

UAP

abnormal termination of

execution error of

monitoring execution time of

monitoring status of

termination error of

when execution takes too long

UAP identification information

UAP identification information

UAP identification information

UAP identification information

UIDKEY

unbalanced index split

UNBALANCED SPLIT

CREATE INDEX

CREATE TABLE

unit

adding

monitoring operating statuses

moving

removing

startup procedures for

startup procedures for (HiRDB/Parallel Server)

termination procedures for

termination procedures for (HiRDB/Parallel Server)

unload log file

creating time series list of

unload statistics log file

creating

unload status, releasing check of

unloading file in unload completed status

unused segments, number of

update buffer flushes count

UPDATE privilege

update requests hits rate

upper-case letter, handling (Directory Server linkage facility)

used free page

being created, processing of

releasing

releasing (24-hour continuous operation)

reusing

reusing

used free segments

releasing

reusing

used page, ratio of

used segment, ratio of

user

authorized

handling increase in number of

identification information of

registering (Directory Server linkage facility)

user authentication

user ID

user identifier

user identifier

user privilege

procedure for setting

revoking

setup (Directory Server linkage facility)

user privilege information

acquisition requests, number of

buffer hits count

user server hot standby

USERBASEDN

USERSCOPE

utility

monitoring execution time of

when execution takes too long

(V)

VERITAS Cluster Server

dummy file

group

preparation

resource

version number conventions

version upgrading (security audit facility)

view analysis information

acquisition requests, number of

buffer hits count

view table, deleted from

violation type code

(W)

WAIT status, procedure for determining user who is causing

warning value

work table HiRDB file system area table

WRITE count

WRITE time

parallel

total

WRITE unit time

average

maximum

minimum

Trademarks

ActiveX is a trademark of Microsoft Corp. in the U.S. and other countries.
AIX is a registered trademark of the International Business Machines Corp. in the U.S.
CORBA is a registered trademark of Object Management Group, Inc. in the United States.
DataStage, MetaBroker, MetaStage and QualityStage are trademarks of International Business Machines Corporation in the United States, other countries, or both.
DB2 is a registered trademark of the International Business Machines Corp. in the U.S.
HACMP/6000 is a trademark of the International Business Machines Corp. in the U.S.
HP-UX is a product name of Hewlett-Packard Company.
IBM is a registered trademark of the International Business Machines Corp. in the U.S.
Itanium is a registered trademark of Intel Corporation or its subsidiaries in the United States and other countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
JBuilder is a trademark of Borland Software Corporation in the United States and other countries.
Linux is a registered trademark of Linus Torvalds.
Lotus, 1-2-3 are registered trademarks of International Business Machines Corporation in the United States, other countries, or both.
Microsoft Access is a registered trademark of Microsoft Corporation in the U.S. and other countries.
Microsoft Excel is a product name of Microsoft Corp.
Microsoft is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Motif is a registered trademark of the Open Software Foundation, Inc.
MS-DOS is a registered trademark of Microsoft Corp. in the U.S. and other countries.
ODBC is Microsoft's strategic interface for accessing databases.
OLE is the name of a software product developed by Microsoft Corporation and the acronym for Object Linking and Embedding.
ORACLE is a registered trademark of Oracle Corporation.
Oracle8i is a trademark of ORACLE Corporation.
Oracle9i is a trademark of ORACLE Corporation.
Oracle 10g is a trademark of ORACLE Corporation.
OS/390 is a trademark of the International Business Machines Corp. in the U.S.
POSIX stands for Portable Operating System Interface for Computer Environment, which is a set of standard specifications published by the Institute of Electrical and Electronics Engineers, Inc.
RISC System/6000 is a registered trademark of the International Business Machines Corp. in the U.S.
Solaris is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.
Sun is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.
Sun Microsystems is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.
The right to use the trademark DCE in Japan is sub-licensed from OSF.
UNIFY2000 is a product name of Unify Corp.
UNIX is a registered trademark of The Open Group in the United States and other countries.
VERITAS is a trademark or registered trademark of Symantec Corporation in the U.S. and other countries.
Visual Basic is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Visual C++ is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Visual Studio is a registered trademark of Microsoft Corp. in the U.S. and other countries.
WebLogic is a registered trademark of BEA Systems, Inc.
Windows is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Windows NT is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Windows Server is a registered trademark of Microsoft Corp. in the U.S. and other countries.
X/Open is a registered trademark of X/Open Company Limited in the U.K. and other countries.
X Window System is a trademark of X Consortium, Inc.
The following program products include material copyrighted by Sun Microsystems, Inc.: P-9D62-1182, P-9D62-1382, P-9D62-1582, P-9D62-1782, P-9D62-1B82, P-9D62-1C82, P-9D62-1D82, P-9D62-1E82, P-F9D62-11823, P-F9D62-11825, P-F9D62-11826, and P-F9D62-11827.
The following program products include material copyrighted by UNIX System Laboratories, Inc.: P-9D62-1182, P-9D62-1382, P-9D62-1582, P-9D62-1782, P-9D62-1B82, P-9D62-1C82, P-9D62-1D82, P-9D62-1E82, P-F9D62-11823, P-F9D62-11825, P-F9D62-11826, and P-F9D62-11827.
Other product and company names mentioned in this document may be the trademarks of their respective owners. Throughout this document Hitachi has attempted to distinguish trademarks from descriptive terms by writing the name with the capitalization used by the manufacturer, or by writing the name with initial capital letters. Hitachi cannot attest to the accuracy of this information. Use of a trademark in this document should not be regarded as affecting the validity of the trademark.