Because database update log information is not collected, the processing time is reduced, thereby reducing the UAP or utility execution time.
(a) Executing the database reorganization utility in the no-log mode
For details about using the database reorganization utility in the no-log 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.
(b) Executing a UAP in the no-log mode
The following is the procedure for executing a UAP in the no-log mode.
- Procedure
- Use the pdlogswap -d sys -w command to swap the system log files.
- Use the pdcopy command to back up the RDAREAs to be updated. For details about how to back up RDAREAs, see 6.4.8 Example 8 (backing up specified RDAREAs).
- Execute a UAP in the no-log mode.
- Use the pdlogswap -d sys -w command to swap the system log files.
- Use the pdcopy command to back up the RDAREAs to be updated. For details about how to back up RDAREAs, see 6.4.8 Example 8 (backing up specified RDAREAs).
- 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 2. 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 21.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 21.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
- Use the PURGE TABLE statement to delete all table row data that was updated by the UAP.#
- Use the pdrels command to release the RDAREA from error shutdown status.
- Use the database load utility (pdload command) to store the initial data in the table again.
- #
- If a temporary table RDAREA shuts down due to an error, you cannot execute the PURGE TABLE statement on the temporary table. Therefore, to recover the temporary table RDAREA, use the pdmod command to reinitialize it.
(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
- Use the pdclose command to close the RDAREA to be recovered.
- Use the pdmod command to re-initialize the RDAREA.
- Use the pdopen command to open the RDAREA.
- Use the pdload command to reload the initial data into the table.
- Use the pdrels command to release the RDAREA from error shutdown status.
All Rights Reserved. Copyright (C) 2011, 2015, Hitachi, Ltd.