Recovering Data with Rollforward - Teradata Database

Teradata Database Administration

Teradata Database
Release Number
English (United States)
Last Update
Product Category

Recovering Data with Rollforward

The ROLLFORWARD command helps you recover from a hardware error. It changes existing rows in data tables by replacing them with after-change images stored in a permanent journal. The after-change images must reside in either the restored or current subtables of a permanent journal.

When you use the restored subtable for rollforward procedures, you need to verify that it contains the desired journal table.

If it does not, submit the RESTORE JOURNAL TABLE command with the appropriate portable storage media. This ensures that you restore the correct subtable.

Also, before you can rollforward, you must have a backup copy of the table rows and AFTER Image journal rows since the last backup.

The following table lists descriptions of some of the options.





During a rollforward operation, this option instructs the software to ignore secondary index and fallback row updates.

A BUILD operation rebuilds the invalidated fallback copy and indexes.

TO checkpointname,

Checkpoint names need to match existing names used with a previous CHECKPOINT statement.

An event number is the software-supplied event number of a previous checkpoint. You can supply either one or both of these.

To find the checkpoint names or event numbers, select information about the checkpoint from the DBC.EventsV view.

If there are duplicate checkpoint names in the journal and an event number is not supplied, rollback stops when it encounters with a matching name.

The following illustrates a rollforward procedure:

1 Submit the RESTORE DATA TABLE command.

2 Submit the RESTORE JOURNAL TABLE command to load the appropriate archive files into the restored permanent journal subtable.

3 Submit the ROLLFORWARD RESTORED JOURNAL command to replace existing data table rows with their after-image rows stored in the restored journal.

4 Submit the ROLLFORWARD CURRENT JOURNAL statement to rollforward any changes made since the journal table was archived. This statement rolled forward the saved subtable first followed by the active subtable.


This option replaces only primary row images during the rollforward process. It ignores secondary index.

If you use this option with a rollforward operation, you can reduce the amount of I/O. It also improves the rollforward performance when recovering a specific AMP from disk failure.

Unique indexes are not valid when recovering a specific AMP. Always submit a BUILD statement when the rollforward command includes the PRIMARY DATA option.

Therefore, the PRIMARY DATA Option:

  • Ignores secondary index rows
  • Reduces amount of I/O
  • Improves performance when recovering single-AMP
  • ROLLFORWARD Restrictions

    The following table illustrates important restrictions on using the ROLLFORWARD statement.


    ROLLFORWARD Restriction


    AMP-specific Restore

    If you perform a restore operation on a specific AMP rather than on all AMPs, the ROLLFORWARD command does not permit you to use the TO CHECKPOINT NAME option.

    Following an AMP-specific restore, the system permits a rollforward only to the end of the journal.

    You must follow up the restore process with a rollforward of the entire journal table.

    All-AMP Restore

    When you perform an all-AMP restore, you choose whether to submit the ROLLFORWARD command with the TO CHECKPOINT NAME option, or to the end of the journal.

    The PRIMARY DATA option of the ROLLFORWARD statement indicates that the operation should ignore secondary index and fallback rows that will reduce the amount of I/O during rollforward.

    If you use this option, follow up with the BUILD statement.

    Use the DBC.EventsV view to determine event numbers and checkpoint names.

    For example:

    SELECT EventNum FROM DBC.EventsV WHERE CreateDate = 940819;
    SELECT CheckPointName FROM DBC.EventsV
    WHERE CreateDate = 940819;