9.3.1 Designing system log files

When system log files need to be swapped, HiRDB (the unit) will terminate abnormally if there are no swappable target system log files. To prevent this, HiRDB has a facility for monitoring the free space remaining for system log files (monitoring free area for system log files facility). This facility operates when the percentage of available free area for the system log files reaches a warning value. Select one of the following two levels.

Level 1:
Output the KFPS01162-W warning message when the percentage of free area for the system log files reaches the warning level.
Level 2:
When the percentage of free area for the system log files reaches the warning level, suppress all further scheduling of new transactions, terminate forcibly all transactions in the server, and output the KFPS01160-E message. This controls the output volume of the system logs.

If level 2 is selected, all transactions in the server are terminated forcibly when there becomes insufficient free space in the system log files. Because of the severity of this action, the system log files should be designed quite carefully.

The following explains some of the design considerations for system log files.

Organization of this subsection
(1) Design considerations
(2) Design for improved reliability
(3) Record length of a system log file
(4) Defining the system log files

(1) Design considerations

  1. System log files are required for each server, except for the system manager.
  2. Specify the same record length and number of records for all system log files on the same server.
  3. The number of system log files that can be created for each server is 2 to 200 groups (we recommend creating at least six groups).
    If HiRDB is restarting after an abnormal termination due to insufficient space for the system log files, the number of system log files to be added must be the same as the number that were already created. For example, if 50 groups of 50 system log files had been created, each of the maximum size (100 gigabyte), then 50 groups of 50 system log files of the maximum size should now be added. Therefore, it is recommended that system log files always be created in units of 100 groups.
  4. The maximum total size of the system log files is 20 terabytes per server.
  5. To reduce the number of unload operations, it is advisable to create many large system log files.
  6. If the system switching facility is used, a file that is involved in many input/output operations (such as a log unload file) should not be created on the same disk that contains $PDDIR%PDDIR%.
  7. The amount of space required for one system log file must satisfy the condition shown following:
    Size of one system log file (bytes) [Figure][Figure](a + 368) [Figure] c[Figure] x c x b x d
    a: Value of pd_log_max_data_size operand
    b: Value of pd_log_sdinterval operand
    c: Value of pd_log_rec_leng operand
    d: Value of pd_spd_assurance_count operand
  8. The total size of the system log files (if duplexed, only their size in one of the systems) must meet the following two conditions.
Condition 1
The size must be at least the value calculated according to the formula in 17.1.1(1) How to obtain the total size of system log files.
Condition 2
After the start of the large object transaction, system log files cannot be overwritten until the large object transaction finishes. Moreover, the current generation of system log files and system log files corresponding to the number of guaranteed-valid generations of the synchronization point dump file cannot be overwritten either. For this reason, make sure that there is at least enough system log file capacity to accommodate this amount of data. Use the following equation to estimate the required capacity.
System log file total size (bytes) [Figure] 3 x a x (b + 1)
a:
Size of system log information that may be output at the corresponding server while executing the database updating transaction with the longest execution time.
For details about the formula for estimating the size of system log information, see 17.1 Determining the size of system log files.
b: Value of pd_spd_assurance_count operand
Number of guaranteed-valid generations for synchronization point dump files.
(a) Effects on operations of the number of generations of system log files

If the total size of the system log files is unchanged, the size of each generation will depend on how many generations of system log files are being maintained. The following table describes the effect on operations of the number of generations of system log files. The total size of the system log files is unchanged.

Table 9-5 Effects on operations of the number of generations of system log files

Comparison itemSystem log file configuration
Small number of generationsLarge number of generations
Size of each generation of system log filesBecomes larger.Becomes smaller.
Swap intervalBecause the size of each generation of system log files becomes larger, the swap interval becomes longer.Because the size of each generation of system log files becomes smaller, the swap interval becomes shorter.
Unload frequencyBecause the swap interval becomes longer, the unload frequency becomes lower.Because the swap interval becomes shorter, the unload frequency becomes higher.
Effects on the system log size when something such as a disk failure makes several generations of system log files unusable
  • Because the size of each generation of system log files becomes larger, the log volume used for database recovery in the event of a disk failure increases, and the time required for database recovery increases.
  • If the decrease in the system log volume is large, the effects of the decrease in system log volume will have increasing effects on HiRDB operations.
  • Because the size of each generation of system log files becomes smaller, the log volume used for database recovery in the event of a disk failure decreases, and the time required for database recovery decreases.
  • If the decrease in the system log volume is small, the effects of the decrease in system log volume will have decreasing effects on HiRDB operations.

In normal operations, the lower the number of generations of system log files, the more advantageous the swapping interval and the unload frequency will become. However, if there is a failure, the effects on operations will be reduced with a larger number of log file generations.

(2) Design for improved reliability

(a) System log file duplexing

When system log file duplexing is used, HiRDB acquires the same system log information in both versions. In the event of an error on one of the versions, the system log can be read from the other version, thereby improving system reliability. When dual system log files are used, they must be used under the management of HiRDB rather than using a mirror disk. When using dual system log files, create the files for each system on a separate hard disk.

To use dual system log files, specify the following operands in the server definition:

(b) Single operation of system log files

Single operation of system log files is employed when dual system log files are used.

In the event of an error in a system log file, processing can continue using the normal version of the system log file without having to terminate the HiRDB unit abnormally even if neither system has a usable system log file. This is called single operation of system log files. To perform single operation of system log files, specify pd_log_singleoperation=Y in the server definition.

As opposed to single operation of system log files, continuing processing using both versions of system log files (normal processing mode) is called double operation of system log files

(c) Automatic opening of system log files

If there is no overwrite-enabled system log file at the time of a HiRDB restart, but a reserved file is available, then HiRDB continues processing by opening the reserved file and placing it in overwrite-enabled status. This is called automatic opening of system log files.

To perform automatic opening of system log files, specify pd_log_rerun_reserved_file_open=Y in the server definition.

(3) Record length of a system log file

Use the pdloginit command's -l option to specify the record length of a system log file. You can select 1,024, 2,048, or 4,096 as the record length.

(a) When constructing a new HiRDB

When you are constructing a new HiRDB, we recommend that you select 1,024 as the record length, because this will improve system log storage efficiency. To do this, specify a value of 1024 in the pd_log_rec_leng operand in the server definition.

If the record length is small, the number of file input/output operations increases for large-sized data. However, file utilization efficiency improves because empty areas created by rounding up to a multiple of the record length are small.

If the record length is large, the number of file input/output operations decreases for large-sized data. However, file utilization efficiency becomes poor because empty areas created by rounding up to a multiple of the record length are large.

(b) When already running a HiRDB

If the record length is not 1,024, we recommend that you change it to 1,024 to improve system log storage efficiency.

For details about how to change the system log file record size, see the HiRDB Version 9 System Operation Guide.

Notes about changing the record length:

(4) Defining the system log files

The pdlogadfg and pdlogadpf operands are used to define the correspondence between file groups and the created system log files.