Because database update log information is not collected, the processing time is reduced, thereby reducing the UAP or utility execution time.

1. When a UAP that adds, updates, or deletes a large amount of data is to be executed
2. When a large amount of data is loaded
3. When table data involving a large number of tables is reorganized (reloaded)
4. When RDAREAs that are subject to UAP update processing in the no-log mode can be placed in exclusive use status

1. When PDDBLOG=NO is specified in the client environment definition, a table that is updated by a UAP running in the no-log mode is placed in lock mode (EX). Such a table must not be updated concurrently by another UAP.
2. When PDDBLOG=NO is specified (or specification is omitted) in the client environment definition and an RDAREA contains a user LOB RDAREA that is to be updated by a UAP running in the no-log mode, the user LOB RDAREA must not be updated concurrently by another UAP if NO is specified in the RECOVERY operand in the table definition. If it is updated by another UAP and the UAP in the no-log mode terminates abnormally, the update by the other UAP is invalidated.
3. If a UAP or utility that is running in the no-log mode terminates abnormally, any RDAREA storing a table updated by the UAP or utility is placed in error shutdown status (logless hold). HiRDB will not restore such an RDAREA; it must be restored by the HiRDB administrator. Therefore, any RDAREA placed in error shutdown status by a no-log mode UAP or utility that terminated abnormally cannot be accessed by other UAPs or utilities until the HiRDB administrator has restored it. In addition, the RDAREA can be restored only to its status at the time a backup was made.
4. Synchronization point dumps are not collected while a UAP or utility is executing in the no-log mode. If a system failure occurs while a UAP or utility is executing in the no-log mode concurrently with another UAP or utility, more time is required for system restart. Therefore, while a UAP or utility is being executed in the no-log mode, it is best that no other UAP or utility be executing.

1. When CREATE INDEX is executed by the database definition utility and the table for which the index is to be created contains row data, the index is created in the batch mode during execution of CREATE INDEX. If PDDBLOG=NO is specified in the client environment definition in such a case, the index will be created in the batch mode without database update log information being collected. The HiRDB administrator must therefore apply the operating procedures for the no-log mode.
2. An RDAREA's error shutdown status is inherited at the next normal startup of HiRDB. Its open or closed status is also inherited.

For details about using the database reorganization utility in the no-log acquisition mode, see 13.2.3 Selecting an update log acquisition mode for a database and 13.3.7 Example 7: Reorganizing in no-log mode.

The following is the operating procedure for executing a UAP in the no-log mode:

Procedure

1. Use the pdcopy command to back up the RDAREA to be updated.
2. Execute the UAP in the no-log mode.
3. Use the pdlogswap command to swap system log files.
4. Use the pdcopy command to back up the updated RDAREA.

Note

If there are backup and system log files that can be used to restore the RDAREA to its status before the UAP was executed, you do not need to make the backup described in step 1. An exception to this is that you must always back up any user LOB RDAREA for which a plug-in index has been created in the batch mode.

When a UAP or utility terminates abnormally, any RDAREA that the abnormally terminated UAP or utility has updated is placed in error shutdown status (logless hold). The HiRDB administrator must recover RDAREAs that are in error shutdown status. For details about recovering RDAREAs, see 19.2 Recovering a database to the point at which a backup was made.

(a) Identifying RDAREAs placed in error shutdown status

The pddbls command can be used to identify RDAREAs that have been placed in error shutdown status.

(b) When data was not backed up before a UAP or utility was executed

When the data was not backed up before a UAP or utility was executed, a range specification must be used to recover the applicable RDAREAs; For details on recovery using a range specification, see 19.3 Recovering a database to the most recent synchronization point.

• The input information for such recovery is the most recent backup copy of the RDAREAs that are in error shutdown status and the unload log file containing the information collected subsequently to the backup (system log file).
• The UAP's execution start time is specified as the recovery end time in the -T option of the database copy utility.
• After the database has been recovered by this procedure, the UAP or utility can be re-executed.

(c) Restoring an RDAREA from its initial data (in the event of abnormal termination of a UAP)

The following is the procedure for recovering an RDAREA from its initial data without using the database recovery utility. However, if the program that terminated abnormally is a utility, this procedure cannot be used to recover an affected RDAREA.

Procedure

1. Use the PURGE TABLE statement to delete all table row data that was updated by the UAP.
2. Use the pdrels command to release the RDAREA from error shutdown status.
3. Use the database load utility (pdload command) to store the initial data in the table again.

(d) Restoring an RDAREA from its initial data (in the event of abnormal termination of a utility)

The following is the procedure for recovering an RDAREA from its initial data without using the database recovery utility when the program that terminated abnormally is a utility.

Procedure

1. Use the pdclose command to close the RDAREA to be recovered.
2. Use the pdmod command to re-initialize the RDAREA.
3. Use the pdopen command to open the RDAREA.
4. Use the pdload command to reload the initial data into the table.
5. Use the pdrels command to release the RDAREA from error shutdown status.