Nonstop Database, HiRDB Version 9 System Operation Guide
![[Contents]](FIGURE/CONTENT.GIF)
![[Index]](FIGURE/INDEX.GIF)
![[Back]](FIGURE/FRONT.GIF)
![[Next]](FIGURE/AFTER.GIF)
21.1.5 Same log reuse check
When you use the database recovery utility to recover a database, and you use only unload log files and do not specify a backup file at the same time, you cannot use the same log more than once. If you recover a database using as input to the database recovery utility a log that has already been used, the database might be damaged or data integrity might be compromised.
To prevent such problems, HiRDB checks the log to be used for database recovery. This is called a same log reuse check. If the check detects a log that was previously used for recovery or a log older than that, HiRDB stops recovery processing of the applicable server and the database recovery utility terminates abnormally. During this step, recovery processing for RDAREAs of servers other than the applicable server continues. Note that if the pdrstr command is executed with the -b or -g option specified, HiRDB does not perform a same log reuse check.
- Organization of this subsection
- (1) When recovery processing is interrupted
If a same log reuse check interrupts recovery processing, message KFPR26288-E is issued. This message shows at which server the recovery processing was interrupted; re-execute the RDAREA recovery for that server. However, in the following case, re-execution is not needed because the database has not been updated:
- The pdrstr command on the same command line or in the same control statement file was executed more than once by mistake, resulting in a check error.
The procedure for re-executing RDAREA recovery is described below.
- Procedure
- Use the pdrstr command or the recovery facility of another product to recover from a backup the RDAREA of the server indicated by the message KFPR26288-E.
- Specify an unload log file that is more recent than the backup file used in step 1, and use the pdrstr command to recover the target RDAREA.
- Reference note
- Why recovery using the same log might compromise data integrity
- The example below explains how a recovery operation is processed when you recover a database using an unload log file only, and you use the same log more than once.
- In this example, it is assumed that a backup has been acquired using the backup facility of another product.
![[Figure]](FIGURE/ZU200150.GIF)
- After the first error occurred
- Backup file 1, acquired using another product, was used to recover the database to a backup acquisition point. Then, the pdrstr command was executed with unload log files 1 and 2 specified to recover the database to the state in which it had been just before the error occurred.
![[Figure]](FIGURE/ZU200151.GIF)
- In this process, the database is recovered to the most recent state using rollforward, and is rolled back using the log for uncompleted transactions.
- After the second error occurred
- Backup file 2, acquired using another product, was used to recover the database to the second backup acquisition point. Afterwards, the pdrstr command was executed with unload log files 1 through 4 specified to recover the database to the state in which it had been just before the error occurred.
![[Figure]](FIGURE/ZU200152.GIF)
- In this process, the database is recovered to the most recent state using rollforward. However, because the database was rolled forward using unload log file 2 during the first recovery operation, processing up to that point is skipped. Afterwards, the database is rolled back using the log for uncompleted transactions. However, because unload log file 2 also contains a log for uncompleted transactions, the transactions in unload log file 2 also roll back (rollback is not skipped), thereby compromising data integrity.
All Rights Reserved. Copyright (C) 2011, 2015, Hitachi, Ltd.