There are three different database update log acquisition modes:

• Log acquisition mode
  This mode acquires the database update log required for rollback and rollforward. Use this mode when there are relatively few data items.
  
• Pre-update log acquisition mode
  This mode acquires only the database update log required for rollback. Use this mode when there are many data items.
  
• No-log mode
  This mode does not acquire a database update log. Therefore, the data load processing time is the shortest of the three modes. Use this mode when there is only one table per RDAREA (if the table is partitioned, only one row-partitioned table per RDAREA) and any related index is also placed in one RDAREA.
  

For details about the functionality of these modes, see the manual HiRDB Version 8 System Operation Guide.

If you are storing data in a user LOB RDAREA, use the CREATE TABLE's RECOVERY operand to specify the database update log acquisition mode.

The database update log acquisition mode for user LOB RDAREAs (RECOVERY operand of CREATE TABLE) may depend on the -l option value in pdload, as shown in Table 6-1.

Table 6-1 Database update log acquisition mode for user LOB RDAREAs depending on the -l option value in pdload

Value specified for -l option in pdload	RECOVERY operand value in CREATE TABLE
	ALL	PARTIAL	NO
a (equivalent to ALL)	ALL	PARTIAL	NO
p (equivalent to PARTIAL)	PARTIAL*	PARTIAL*	NO
n (equivalent to NO)	NO	NO	NO

ALL: Log acquisition mode

PARTIAL: Pre-update log acquisition mode

NO: No-log mode

For example, if PARTIAL is specified in the RECOVERY operand of CREATE TABLE and the log acquisition method is NO in pdload, then NO (no-log mode) is set for the user LOB RDAREAs.

^* For the log that is output by plug-ins, ALL (log-acquisition mode) is assumed.

In general, the pre-update log acquisition mode, which is the default mode, should be selected. However, selection of another mode should be considered under the following conditions:

Condition	Mode to be selected
For initial storage, only the target table (or index) for data storage is stored in the RDAREA.	No-log mode
There is large volume of input data, and data storage will take a long time.
There is only a small amount of input data.	Log acquisition mode

Depending on the mode that is selected, there are differences in the operating procedure during data storage, as shown in Figure 6-2.

Figure 6-2 Differences in operating procedure based on the database update log acquisition mode (data storage)

Note 1

This operation is required when the no-log mode is selected. If the pdload command should terminate abnormally during operation in the no-log mode, you would use this backup to recover the RDAREA. Note that it is not necessary to make a backup if the conditions described in (5) When it is not necessary to make a backup prior to data storage are satisfied.

However, regardless of the update log acquisition mode, a backup should be made when additional data storage is performed in the batch index creation mode on a table for which a plug-in index has been defined. The reason is that in order to perform database recovery after the pdload command has terminated abnormally, all the plug-in indexes, including the data portions, must be re-created, which would require a long time for database recovery.

Note 2

This operation is required when the pre-update log acquisition mode or the no-log mode is selected. If a backup is not made at this point, it will not be possible to recover the RDAREA to a subsequent status if it becomes necessary to recover the RDAREA with the pdrstr command (target processing after data storage execution cannot be recovered); the RDAREA can be recovered only to its status before data storage was executed.

Supplemental note

If the pre-update log acquisition mode or the no-log mode is selected, the target data storage RDAREA must remain on shutdown status during the steps 1-4 shown in the figure. If the contents of the RDAREA are modified before the backup at step 4 has been made, and if it becomes necessary to recover the RDAREA with the pdrstr command, the modified contents will not be recovered; it will be possible to recover the RDAREA only to its status before data storage was executed. If the pdrstr command is used to recover the RDAREA, an error will occur during execution of the pdrstr command if the system log in the input information contains a log collected in the pre-update log acquisition mode or the no-log mode.

If data storage is executed in the no-log mode, a backup must have been made prior to execution of data storage. However, if either condition 1 or 2 in the following table is satisfied, it becomes unnecessary to make a backup, because the RDAREA can be returned to its status before execution of data storage even if the pdload command terminated abnormally:

No.	Condition		RDAREA recovery method in the event of an error
1	Initial storage	When only the targeted data storage table and indexes of that table are stored in the target data storage RDAREA	If the target data storage RDAREA is reinitialized with the database reconfiguration utility (pdmod command), then once data storage is re-executed the RDAREA can be recovered.
	Data storage executed in the creation mode
2	There exists in the RDAREA targeted for data storage at least one table (index) other than the table (index) targeted for data storage.	When the RDAREA can be recovered to its status before data storage by using a backup and the system log	The RDAREA can be recovered if you use the pdclose command to close the target data storage RDAREA, use the pdlogswap command to swap system log files, and then use the current system log file as input to the database recovery utility (pdrstr command).
	Data storage executed in the addition mode

Note

With respect to the condition in No. 2, the recovery operation on the RDAREA is easier if a backup has been made, so in general it is recommended that a backup be made. In particular, if pdload has terminated abnormally while in the batch index creation mode, indexes cannot be recovered by a rollback even in the log acquisition mode or the in pre-update log acquisition mode. If it is necessary to be able to recover quickly to the status before data storage was attempted in the event of abnormal termination of pdload, you should definitely make a backup.