In most cases, select the default mode, which is the pre-update log acquisition mode. Consider using another mode only under the following conditions:

Condition	Mode to select
There is a large amount of data to be reorganized, and it will take a long time.	No-log mode
There is very little table data to be reorganized.	Log acquisition mode

The manner in which database reorganization is performed depends on the mode that is selected, as the following figure shows.

Figure 13-6 Differences in how tables are reorganized depending on the database update log acquisition mode

#1: This step is required when the no-log mode is selected. The backup that is obtained is used to recover the RDAREA in the event the pdrorg command terminates abnormally while the no-log mode is in effect. However, you need not make this backup if the conditions described in (3) Conditions under which a backup is not needed before reorganizing are satisfied.

#2: This step is required when the pre-update log acquisition mode or the no-log mode is selected. If you do not make a backup at this point, the RDAREAs cannot be recovered to their most recent status with the pdrstr command in the event the need to recover them arises (they cannot be recovered to include the updates implemented by the pdrorg command). The RDAREAs can be recovered only to their status at the time the pdrorg command is executed.

Tip

When the pre-update log acquisition mode or the no-log mode is selected, keep the RDAREAs to be reorganized in shutdown status from steps 1 through 4 (in Figure 13-6). Otherwise, if the need arises to recover the RDAREAs with the pdrstr command, any updates to the RDAREAs that were performed before the backup is made in step 4 will not be recovered. You will only be able to recover the RDAREAs to the point at which the pdrorg command is executed. This is because if the system log files that the pdrstr command uses as input contain logs collected in the pre-update log acquisition mode or the no-log mode, the pdrstr command that is used to recover the RDAREAs will terminate in an error.

Normally in the no-log mode, a backup must be made before the pdrorg command is executed. However, if either of the conditions described in 1 and 2 below is satisfied, it is not necessary to make the backup because the RDAREAs can be recovered to their status at the time the pdrorg command executed even if the command terminates abnormally. We do recommend, however, that in general you make a backup, because recovering RDAREAs is simpler if a backup is available.

No.	Condition		How to recover the RDAREAs if an error occurs
1	Unload data can be used to recover the RDAREAs to their status at the time the pdrorg command was executed.	If the RDAREAs contain only the table to be reorganized and its indexes.	Recover with the database reorganization utility (pdmod command) in order to re-initialize the RDAREAs that are being reorganized, and then reload the data.
		If all of the following conditions are satisfied: The table being reorganized contains LOB data. The RDAREAs contain only a LOB column structure base table being reorganized. The unload data was obtained by specifying the -j option.	Recover with the database reorganization utility (pdmod command) in order to re-initialize the RDAREAs that are being reorganized, and then specify the -j option.
2	The backup and the system logs can be used to recover the RDAREAs to their status at the time the pdrorg command was executed.		Recover with the pdclose command in order to close the RDAREAs that are being reorganized, the pdlogswap command to swap the system log files, and then the database recovery utility (pdrstr command) to input the system logs output up to this point.