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.

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

This operating environment is used principally for referencing-based databases.

For example, we recommend that you employ this operating environment 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 re-executing the UAPs or utilities.

HiRDB parallel server configuration

• 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, we recommend that you always use this operating environment for a front-end server.

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

1. 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).
   
2. HiRDB must not be started while the pdlogunld or pdlogchg command is executing; otherwise, the pdlogunld or pdlogchg command might terminate with an error. An unload log file might be created even though the pdlogunld command has terminated with an error; however, such an unload log file cannot be used for database recovery.

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 configuration, this operand is specified in the single server definition; in the case of a HiRDB parallel server configuration, 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

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.

1. Use the pdlogswap command to swap the system log files:
   pdlogswap -d sys -s b001
   
2. Use the pdcopy command (database copy utility) to back up the RDAREAs. For details about making backups, see 6. Backup Procedures.
   pdcopy -m /rdarea/mast/mast01 -M r -a -b /pdcopy/backup01
   
3. 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 re-executed.

We recommend that after the command has executed you check whether the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 9 Command Reference.

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