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

HiRDB manages system log files according to their status, as described in the following table.

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.

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 configuration) terminates abnormally.

HiRDB provides the following facilities:

• Facility for monitoring the amount of free space available for system log files (facility for monitoring the free space remaining for system log files)
  For details about this facility, see 3.9 Monitoring the free area for system log files.
  
• Facility for automatically extending the size of system log files (system log file automatic extension facility)
  For details about this facility, see 3.10 Using the system log file automatic extension facility.
  

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 Version 9 Staticizer Option 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; that is, the 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 is not validated until the transaction has terminated. Because the transactions listed below take a long time to execute, the synchronization point dump is not validated until these transactions have terminated. Therefore, avoid executing the following transactions concurrently with others:

• Transactions that take a long time to commit after an update SQL statement is executed, such as insertion of a row into a table (INSERT), data updating (UPDATE), and row deletion (DELETE)
• Transactions that involve a large amount of data and that execute the database load utility (pdload), database reorganization utility (pdrorg), or free page release utility (pdreclaim)
• Transactions that execute the CREATE INDEX statement on a table that stores a large amount of data

(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 a system log stored in a file that is in unload wait status is unloaded, that file's status changes from unload wait status to unload completed status. 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.

There are different methods for handling system log files, as shown in the following table. 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.

For details on how to handle errors in system log files, see 20.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.

The following table 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.