In situations where you need to drop a database or perform a point-in-time rollforward recovery, it is possible to lose log files that might be required for future recovery operations. In these cases, it is important to make copies of all the logs in the current database log path directory.
Consider the following scenarios:
If you plan to drop a database before a restore operation, you need to save the log files in the active log path before issuing the DROP DATABASE command. After the database is restored, these log files might be required for rollforward recovery because some of them might not have been archived before the database was dropped. Normally, you are not required to drop a database before issuing the RESTORE command. However, you might have to drop the database (or drop the database on one database partition by specifying the AT DBPARTITIONNUM parameter of the DROP DATABASE command), because it was damaged to the extent that the RESTORE command fails. You might also decide to drop a database before the restore operation to give yourself a fresh start.
If you are rolling a database forward to a specific point in time, log data after the time stamp you specify is overwritten. If, after you complete the point-in-time rollforward operation and reconnect to the database, you determine that you actually need to roll the database forward to a later point in time, you are not able to because the logs are already overwritten. It is possible that the original set of log files might have been archived; however, DB2® might be calling a user exit program to automatically archive the newly generated log files. Depending on how the user exit program is written, this might cause the original set of log files in the archive log directory to be overwritten. Even if both the original and new set of log files exist in the archive log directory (as different versions of the same files), you might have to determine which set of logs should be used for future recovery operations.