Nonstop Database, HiRDB Version 9 System Operation Guide

[Contents][Index][Back][Next]

3.3.2 HiRDB parallel server configuration

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
We recommend that you make a backup 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. Set the backup acquisition interval so that the system will never run out of files in swappable target status.

Number of system log files
We recommend that the total number of system log files 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, provide at least four system log files 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, specify pd_log_unload_check=N 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 21. Database Recovery Procedures.

Example
The following figure shows the procedure for operation without unloading the system log in a HiRDB parallel server configuration.

Figure 3-5 Procedure for operation without unloading the system log (HiRDB parallel server configuration)

[Figure]

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
 

[Figure]

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. For details about making backups, see 6. Backup Procedures.

 
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
 

[Figure]

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.