The logical recovery process starts with an audit table design similar to the designs previously described. The key to this logical recovery process is the ability to control application recovery activation. This typically can be enabled via a DB2 table called the Logical Recovery Table (LRT), which will almost always be empty and will always be read by any application program reading the main tables. If the application ever reads the LRT and it returns data, then the application will switch into logical recovery mode and read the “as of ” images. The LRT contains nothing more than a timestamp column, and will have no rows unless a recovery is needed. At that time, one row will be inserted with a timestamp representing the desired recovery time. Figure 8 shows the application activation process.
Once logical recovery has been activated in the application, it reads a set of views rather than the main tables. Other than reading views, virtually all other application code remains the same. The views then hold the key to the recovery process, and the purpose of the views is to return the “as of” image of the data depending on the value of the timestamp in the LRT. These views look very similar to the previous “as of” examples in this article with the exception that they’re also reading the LRT. Figure 9 shows an example of a “logical recovery view” that returns the “as of” image represented by the logical recovery timestamp.
With the application in logical recovery mode, a background process can use the value of the logical recovery timestamp to clean up any changes made to data after that point in time. If your applications are reading WITH UR and aren’t updating, then these data corrections can be made while all readers continue reading the “as of ” data images. Once the clean-up process completes, the timestamp can be deleted from the LRT, and normal processing can begin.
IBM DB2 Futures
You may see an “as of” capability built into an upcoming release of DB2. Consideration is being given to providing a snapshot query capability to see what data looked like at a particular time. While this sounds like an exciting feature, it’s a ways out in the future. If you currently have requirements to provide that capability, for now it must come from creative table and code design.
While time travel is still impossible, it isn’t for your data. You have the capability to see your data at a point in time, see ranges of data as it changes over time, and go back in time to see your data as it was before it became corrupted while backing out the corruption. Those are three attractive ways to take a trip to the past using a few DB2 tables and some imaginative code.