|
|
|
The Recover dialog is used to create one of two types of "undo scripts"—an internal script that is run immediately or an external script that can be saved and run later.
To recover transactions, follow these steps:
Initially, the row changes that you selected in the Journal Analyzer are displayed in the lower portion of the Recover dialog.
|
|
|
If you chose whole transactions in the Journal Analyzer, the Whole Transaction(s) option is selected automatically in the Recover dialog.
If you selected individual row changes that make up only part of a transaction (in the lower portion of the dialog), the Individual Rows option is selected. In this case, you are prompted for confirmation as to whether you want to recover only parts of transactions, and lose transaction integrity. Although the recovery of individual rows is not recommended, it can be useful, for example, if a table has Ingres rules associated with it.
|
|
|
If a table has Ingres rules associated with it that results in additional row changes within the same transaction, do not generate undo operations for such dependent changes because it leads to undesirable results. Also, the rules can change between the time of the initial transaction and the time when you want to undo that transaction. Instead, undo only the change in the base table, and let the rules generate the dependent changes.
Journal Analyzer detects the rules, constraints, and integrities that exist in the tables involved in the transaction(s) and displays them on the tabbed pages in the Recover dialog. From this display, you can determine whether some changes in a transaction resulted from rules and if certain constraints cannot be fulfilled. This information helps you determine if you want to use the No Rules option, and possibly disable certain rows within the transaction. You can view the properties for a particular rule, constraint, or integrity by double clicking it. Examine these entities to determine their impact on a restore.
Note: Integrity constraints that are violated are not specifically reported: updates and inserts that violate any integrity constraints are simply not performed.
|
|
|
The Scan Journals to the End option provides a warning if the tables have been altered since the time of the initial transaction, in which case the rules for these tables have changed.
If there are rules on a table, you have two choices:
|
|
|
The order of the undoing of transactions is reverse of the order at commit time of these transactions and cannot be changed. If for some reason you need the order to be different than the usual order, the only way to do this is to recover each transaction separately (by launching the Recover dialog for each transaction individually) in the desired order.
In each transaction to be recovered, the order of the individual statements can be changed, using the Up and Down buttons in the Recover dialog.
|
|
|
Before proposing to reverse row changes resulting from a transaction, you must take into account the fact that some of these rows have changed after the transaction. The possible cases are as follows:
Or:
There is an "advanced" exception, in the case where a given row (the same or another one) has the exact same content afterwards as the after image of the initial change: in this case, it is the user's responsibility to make a decision about taking additional actions.
For this reason, the following features are available:
|
|
|
By default, Journal Analyzer proposes to recover transactions by executing reverse transactions under the currently connected user. However, the Impersonate User of Initial Transaction option allows you to impersonate the user under which each transaction had initially been executed.
Note: This option requires that the connected user is the database administrator or has appropriate privileges.
The Impersonate User of Initial Transaction option affects the way the reverse transactions are executed: that is, normally Journal Analyzer recovers multiple transactions by executing the recover statements of all transactions to be undone in a single, global "recover" transaction. This allows, in case of failure at any point in the recover operation, to cancel the whole operation.
However, given that it is not possible to execute in the same transaction different statements under different users, if this option is used, and the initial transactions had not all be executed under the same user, Journal Analyzer must commit (and change the user) before each reverse statement to be executed under a different user than the previous one.
A possible problem in this case is when a reverse statement fails, once other recover statements have already been committed. In this situation, Journal Analyzer proposes to "undo the undo" of the transactions previously undone. However in case of failure of this last operation, you need to manually "repair" this situation (typically by using Journal Analyzer) by completing or canceling the uncompleted operation.
|
|
|
Journal Analyzer-generated reverse statements for insert and update statements are delete and update statements, with a "where" clause on all columns that can be accepted in a where clause (column types such as "long varchar" cannot).
If you need two identical rows in which all columns can be part of a where clause (SQL does not normally distinguished such rows), the Recover dialog has an option (selected by default) called "Don't Recover if >1 Row is Affected by an Individual Statement". Only when this option is explicitly disabled does the recover process work even if more than one row is affected by an individual recover statement.
In the case where no row is affected by an individual "recover" statement, Journal Analyzer provides an error anyway, and the recover operation fails. If the Scan Journals to End option has not been disabled, Journal Analyzer normally warns you that rows involved already have changed since the initial transaction (different warnings appear if journaling has been disabled after the initial transaction or in similar situations).
|
|
|
If you want to view the script that is run based on your Recover dialog selections, click the View Recover Script Now button. The following dialog appears:
This dialog allows you to see the SQL statements that are executed if you click the Recover Now button. The script only works when executed within Journal Analyzer and must not be used externally. If desired, you can also save the script by clicking Save.
If you want to generate an external undo SQL script that you can run at another time (possibly on another database), you can do so after you have made your selections in the Recover dialog. By clicking the Generate External Script button, the following dialog appears:
You can make any necessary changes to the script by selecting the Edit Script option. To save or run the script, clicking the corresponding button.
Although external scripts can be very useful, you should be aware of some issues:
For this reason, the Generate External Script options must be restricted for the Recover and Redo features to when absolutely necessary (that is, typically when executing the scripts on another node and database). In this case: