Logical Restore

Enterprise Edition Home | Express Edition Home | Previous Page | Next Page Other Data Restore Utilities > Restoring Table-level Data > Restoring Data >

Logical Restore

Following the physical restore, logical recovery can further restore tables to a user-specified point in time. To do this, the archecker utility reads backed-up logical logs, converts them to SQL statements, and then replays these statements to restore data. The archecker utility cannot replay transactions from the current log. Before performing a logical recovery, ensure that all transactions you want to restore are contained in backed-up logical logs.

When performing a logical restore, archecker uses two processes that run simultaneously:

Stager: assembles the logical logs and saves them in tables.
Applier: converts the log records to SQL statements and executes the statements.

The Stager

To collect the pertinent logical log records, the stager performs the following steps:

Scans only the backed-up logical logs.
The stager reads the backed-up logical log files and assembles complete log records.
Tests the logical log records
Any log record that is not applicable to the tables being restored is rejected.
Inserts the logical log information into a table
If the logical log record is not rejected, it is inserted into a stage table.

The Applier

The applier reads data from the control table created by the stager. It begins processing the required transaction and updates the control table to show that this transaction is in process. Next, it operates on each successive log record, row by row, until the transaction commits.

All updates to the control table occur in the same transaction as the log record modification. This allows all work to be completed or undone as a single unit, maintaining integrity at all times. If an error occurs, the transaction is rolled back and the error is recorded in the control table entry for this transaction.

Note:

When data is being restored and the DBA has elected to include a logical restore, two additional work columns and an index are added to the destination table. These columns contain the original rowid and original part number. These columns provide a unique key which identifies the location of the row on the original source archive. To control the storage of the index, use the SET WORKSPACE command (see The SET Statement). Otherwise, the index is stored in the same space as the table.

After the applier has finished and the restore is complete, these columns, and any indexes created on them, are dropped from the destination table.

Considerations

Consider the following issues when performing a logical restore:

The table or table fragments being recovered must exist in the level-0 archive. The table or fragment cannot be created or added during the logical recovery. Tables created or fragments added during the logical recovery are ignored.
Because a detached fragment is no longer part of the original table, the applier does not process the detached fragment log record or any other log records for this fragment from this point forward. A message in the archecker message log file indicates a detach occurred.
If a table is altered, dropped, or truncated during a logical restore, the restore terminates for that table. Termination occurs at the point that the alter was performed. A message in the archecker message log file records that an alter operation occurred.
During a level-0 archive, there cannot be any open transactions that would change the schema of the table.
You cannot perform a logical restore on an external table.