Use the Restore Process to select data from one or more Archive Files and restore the data to the original or to a different database.
Specifications for a Restore Process are stored as a Restore Request. Use the Restore Request Editor to define parameters for a Restore Process, including the source of the archived data and the destination to which it is restored, and designating whether a Load Process or an Insert Process is used to restore the data.
There are two steps to a Restore Process. First, the Archive File that contains the desired data is located and the desired data selected. Once the data is located, it is restored. The Restore Request Editor has two work areas to accommodate these steps: the top area is used to locate and select the desired data and the bottom area is used to manage restore processing – including whether to use an Insert Process (in other words, dynamically constructed SQL) or a Load Process (in other words, the DBMS Load Utility) to restore the selected data.
A Restore Process can be run from the graphical user interface (by clicking on the Restore Request Editor) or from the command line. The approach used depends upon how your organization manages its archiving environment. You can also schedule the request to run at a later time (by clicking ), but this is done infrequently.
For unplanned restorations, a member of the IT group will typically use the Restore Request Editor to define and run the Restore Process from the graphical user interface. However, many organizations can anticipate and plan restorations. These organizations can use the Restore Request Editor to define the two parts of the Restore Request in advance. The Restore Process is then run in an automated fashion, using the command line interface. When defining a Restore Request in advance, the top portion of the editor lists one or more representative Archive Files (templates for files that may be found when searching for data to be restored) and the bottom portion provides the information needed to Insert or Load data from similar files. In this automated process, Archive Files to be restored are substituted at run-time for the template files listed in the pre-defined Restore Request.
This automated approach accommodates changes in data model by allowing you to list “template” Archive Files in the Restore Request that mirror the data model for an application. The rules for restoring data from each template are typically straightforward and you can create an Insert or Load Request to match each template Archive File. As the application and data model evolve over time, the Insert or Load Request for an early Archive File can be updated, creating a new Insert or Load Request to accommodate files that reflect the more recent data model.
Using the command line interface, all Archive Files for the application are searched and the names of matching Archive Files are used as overrides for files listed in the Restore Request. The Insert or Load Request (referenced in the Restore Request) that matches the Archive File is then used to restore the selected data.
As an example of this approach, assume that when archiving is implemented, the data model of the production database matches that of the Archive Files. Therefore, the Restore Request lists a single Insert (or Load) Request that references, as its Source File, an Archive File with this data model. At some point in the future, a new version of the application is released and the data model changes. At that time, a second Insert Request, which references an Archive File with the new data model as its Source File, is added to the Restore Request. In addition, the Table Map and any Column Maps for the original Insert Request can be edited to accommodate the new data model. This process is repeated each time the data model is updated.
Suppose that the data model of your production database is based on version 1 of your order-entry application. From July 2000 to November 2000, you archive old orders monthly. To restore data, you need only one Restore Request. This Restore Request lists a single Insert Request that references an Archive File (say, from August 2000) as its Source File. The data model of this Source File matches all Archive Files created during that time.
In December 2000, your
company implements version 2 of the application, and the data model
of the production database changes. You continue to archive orders
monthly. To restore data successfully, however, you must alter the
Restore Request. First, to restore data from files archived from July
2000 to November 2000, you must modify the original Insert Request
by editing the Table and/or Column Maps to reflect the new data model.
Second, you must add a new Insert Request to the Restore Request,
which references the new data model as its Source File. These changes
ensure that you can restore data from the Archive Files using one
Restore Request, and that you have accommodated changes to the data
model.
In this example, each Archive File is processed by the first Insert or Load Request for which the data model of the Source File matches that of the Archive File.