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).
4. For one server, creation of system log files must meet the following condition:
   

   100 (unit: megabytes) (200 - number of system log file groups assigned to server) total system log file capacity allocated to the server 3

   Multiplying by three is necessary to restart a HiRDB system that has terminated abnormally due to insufficient space for the system log files. Depending on usage and whether there is enough space for system log files, you might need to take action by creating system log files of three times the capacity allocated to the server, and then adding them to the 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) (a + 368) c zueng005.tif c zueng005.tif b zueng005.tif 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) 3 zueng005.tif a zueng005.tif (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-6 Effects on operations of the number of generations of system log files

Comparison item	System log file configuration
	Small number of generations	Large number of generations
Size of each generation of system log files	Becomes larger.	Becomes smaller.
Swap interval	Because 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 frequency	Because 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.

(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:

• pd_log_dual=Y
• -b option in the pdlogadpf operand (to specify the name of the B version of system log file)

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

(a) Facility for monitoring the free space remaining for system log files

When system log files need to be swapped, if no swappable target system log files exist, HiRDB (the unit) terminates abnormally. To prevent this, HiRDB has a facility for monitoring the free space remaining for system log files. 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:

When the available space in the system log file falls below the warning level, the KFPS01162-W warning message is output.

Level 2:

When the available space in the system log file falls below the warning level, scheduling of new transactions is suppressed, and all transactions inside the server are forcibly terminated. At this time, message KFPS01160-E is output. This controls the output volume of the system logs.

If level 2 is selected, all transactions on the server are terminated forcibly when there is insufficient free space in the system log files. Therefore, the design of system log files requires more accuracy.

For details about this facility, see the HiRDB Version 9 System Operation Guide.

(b) System log file automatic extension facility

The HiRDB system (or unit) terminates abnormally when it runs out of free space for system log files. To prevent this, HiRDB provides a facility to automatically expand the space for system log files (the system log file automatic extension facility). By using this facility, you can reduce the frequency of abnormal termination of the HiRDB system (or unit) due to lack of free space for system log files.

For details about the system log file automatic extension facility, see the HiRDB Version 9 System Operation Guide.

(c) Skipped effective synchronization point dump monitoring facility

If a UAP continues to update the database in an infinite loop, it cannot enable the synchronization point, and the number of system log files that cannot be overwritten increases. If the point is reached where none of the system log files can be overwritten, HiRDB terminates abnormally.

If HiRDB is forcibly terminated or terminates abnormally when the number of system log files that cannot be overwritten reaches one-half or more of all system log files, a shortage of system log files occurs during rollback processing when HiRDB restarts. In this case, HiRDB cannot be restarted unless new system log files are added. Any such restart processing will take longer than usual.

To prevent this, HiRDB has established a skipped effective synchronization point dump monitoring facility.

For details about this facility, see the HiRDB Version 9 System Operation Guide.

When the system log file is duplexed, using the facility for parallel output of system logs allows log output to the two systems to be executed in parallel, so less time is required. To use the facility for parallel output of system logs, you will need an aio library (for AIX, the Asynchronous I/O Subsystem; for Linux, libaio). For details about the Asynchronous I/O Subsystem or libaio, see the OS documentation.

Note that when you use the facility for parallel output of system logs on the Linux version, it is assumed that the platform you are using is one of the following:

• Red Hat Enterprise Linux ES 4(AMD64 & Intel EM64T) or later
• Red Hat Enterprise Linux AS 4(AMD64 & Intel EM64T) or later

(a) Recommended usage

Although you can define for each server whether the facility for parallel output of system logs is to be used, we recommend that you apply this facility to all servers. We also recommend that you place the primary and secondary files on separate devices in order to further reduce the time required for output of log information.

(b) Environment settings (setting system definitions)

In the server definition, specify pd_log_dual_write_method=parallel. In the following cases, the facility for parallel output of system logs is not applied, regardless of the specified value:

• Dual system log files are not used (the value of the pd_log_dual operand is not Y).
• The system log files are not placed in character special files.

(c) Environment settings (setting the aio library)

Install the aio library on all server machines that will use the facility for parallel output of system logs, and perform the required settings. See the OS documentation for details about how to install and set up the aio library.

If the aio library installation and settings are not performed correctly using the environment settings described in (b), HiRDB cannot start.

Using AIX 5L

Asynchronous I/O Subsystem must be enabled prior to starting HiRDB. Otherwise, HiRDB will not start. On AIX 5L V5.2 and later, Asynchronous I/O Subsystem comes in a legacy version and a POSIX version. HiRDB uses the legacy version, so enable the legacy Asynchronous I/O Subsystem.

Once you have installed Asynchronous I/O Subsystem, set the following parameters.

Parameter	Recommended value
STATE to be configured at system restart	available
STATE of FastPath	enable#

#: This is the default, so no change is needed. If the setting is changed, performance might decline.

Other parameters do not require tuning.

(d) Notes

1. If Asynchronous I/O Subsystem is not enabled on HiRDB for AIX 5L, HiRDB cannot start and will terminate abnormally. Either enable the Asynchronous I/O Subsystem, omit the pd_log_dual_write_method operand, or specify serial, and then restart HiRDB. If the Asynchronous I/O Subsystem parameter is set to STATE to be configured at system restart = available, HiRDB starts automatically.
2. The facility for parallel output of system logs is not applicable to system log files placed in regular files. If you add system log files, place them in character special files.
3. The facility for parallel output of system logs is applied only when both primary and secondary current files are placed in character special files and system log information can be output to those current files (they are not in closed, reserved, or error status). Parallel output of system logs does not take place, regardless of the system definition, if the current file satisfies either of the following conditions:
   
   • The primary or secondary current file is placed in a regular file.
   • The primary or secondary current file is in a status such that no log information can be output to it.
4. If the server that uses the facility for parallel output of system logs is running on multiple server machines, as when the system switchover facility is used, startup of the standby unit or system switchover might fail if the aio library is not enabled on any of the server machines. Enable the aio library on all server machines.

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.

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