Journals are kept on the system to provide data availability in the event of a component or process failure in the system:
Recovery Journal
The Teradata Database uses Recovery Journals to automatically maintain data integrity in the case of:
*An interrupted transaction (Transient Journal)
*An AMP failure (Down-AMP Recovery Journal)
Recovery Journals are created, maintained, and purged by the system automatically, so no DBA intervention is required. Recovery Journals are tables stored on disk arrays like user data is, so they take up disk space on the system.
Transient Journal
A Transient Journal maintains data integrity when in-flight transactions are interrupted (due to aborted transactions, system restarts, and so on). Data is returned to its original state after transaction failure.
A Transient Journal is used during normal system operation to keep "before images" of changed rows so the data can be restored to its previous state if the transaction is not completed. This happens on each AMP as changes occur. When a transaction is started, the system automatically stores a copy of all the rows affected by the transaction in the Transient Journal until the transaction is committed (completed). Once the transaction is complete, the "before images" are purged. In the event of a transaction failure, the "before images" are reapplied to the affected tables and deleted from the journal, and the "rollback" operation is completed.
Down-AMP Recovery Journal
The Down-AMP Recovery Journal allows continued system operation while an AMP is down (for example, when two disk drives fail in a rank or mirrored pair). A Down-AMP Recovery Journal is used with Fallback-protected tables to maintain a record of write transactions (updates, creates, inserts, deletes, etc.) on the failed AMP while it is unavailable.
The Down-AMP Recovery Journal starts automatically after the loss of an AMP in a cluster, Any changes to the data on the failed AMP are logged into the Down-AMP Recovery Journal by the other AMPs in the cluster. When the failed AMP is brought back online, the restart process includes applying the changes in the Down-AMP Recovery Journal to the recovered AMP. The journal is discarded once the process is complete, and the AMP is brought online, fully recovered.
Permanent Journals
Permanent Journals are an optional feature used to provide an additional level of data protection. You specify the use of Permanent Journals at the table level. It provides full-table recovery to a specific point in time. It can also reduce the need for costly and time-consuming full-table backups.
Permanent Journals are tables stored on disk arrays like user data is, so they take up additional disk space on the system. The Database Administrator maintains the Permanent Journal entries (deleting, archiving, and so on.)
How Permanent Journals Work
A Database (object) can have one Permanent Journal.
When you create a table with Permanent Journaling, you must specify whether the Permanent Journal will capture:
*Before images -- for rollback to "undo" a set of changes to a previous state.
*After images -- for rollforward to "redo" to a specific state.
You can also specify that the system keep both before images and after images. In addition, you can choose that the system captures:
*Single images (the default) -- this means that the Permanent Journal table is not Fallback protected.
*Dual images -- this means that the Permanent Journal table is Fallback protected.
The Permanent Journal captures images concurrently with standard table maintenance and query activity. The additional disk space required may be calculated in advance to ensure adequate resources. Periodically, the Database Administrator must dump the Permanent Journal to external media, thus reducing the need for full-table backups since only changes are backed up rather than the entire database.
- Recovery Journals
- Permanent Journals
Recovery Journal
The Teradata Database uses Recovery Journals to automatically maintain data integrity in the case of:
*An interrupted transaction (Transient Journal)
*An AMP failure (Down-AMP Recovery Journal)
Recovery Journals are created, maintained, and purged by the system automatically, so no DBA intervention is required. Recovery Journals are tables stored on disk arrays like user data is, so they take up disk space on the system.
Transient Journal
A Transient Journal maintains data integrity when in-flight transactions are interrupted (due to aborted transactions, system restarts, and so on). Data is returned to its original state after transaction failure.
A Transient Journal is used during normal system operation to keep "before images" of changed rows so the data can be restored to its previous state if the transaction is not completed. This happens on each AMP as changes occur. When a transaction is started, the system automatically stores a copy of all the rows affected by the transaction in the Transient Journal until the transaction is committed (completed). Once the transaction is complete, the "before images" are purged. In the event of a transaction failure, the "before images" are reapplied to the affected tables and deleted from the journal, and the "rollback" operation is completed.
Down-AMP Recovery Journal
The Down-AMP Recovery Journal allows continued system operation while an AMP is down (for example, when two disk drives fail in a rank or mirrored pair). A Down-AMP Recovery Journal is used with Fallback-protected tables to maintain a record of write transactions (updates, creates, inserts, deletes, etc.) on the failed AMP while it is unavailable.
The Down-AMP Recovery Journal starts automatically after the loss of an AMP in a cluster, Any changes to the data on the failed AMP are logged into the Down-AMP Recovery Journal by the other AMPs in the cluster. When the failed AMP is brought back online, the restart process includes applying the changes in the Down-AMP Recovery Journal to the recovered AMP. The journal is discarded once the process is complete, and the AMP is brought online, fully recovered.
Permanent Journals
Permanent Journals are an optional feature used to provide an additional level of data protection. You specify the use of Permanent Journals at the table level. It provides full-table recovery to a specific point in time. It can also reduce the need for costly and time-consuming full-table backups.
Permanent Journals are tables stored on disk arrays like user data is, so they take up additional disk space on the system. The Database Administrator maintains the Permanent Journal entries (deleting, archiving, and so on.)
How Permanent Journals Work
A Database (object) can have one Permanent Journal.
When you create a table with Permanent Journaling, you must specify whether the Permanent Journal will capture:
*Before images -- for rollback to "undo" a set of changes to a previous state.
*After images -- for rollforward to "redo" to a specific state.
You can also specify that the system keep both before images and after images. In addition, you can choose that the system captures:
*Single images (the default) -- this means that the Permanent Journal table is not Fallback protected.
*Dual images -- this means that the Permanent Journal table is Fallback protected.
The Permanent Journal captures images concurrently with standard table maintenance and query activity. The additional disk space required may be calculated in advance to ensure adequate resources. Periodically, the Database Administrator must dump the Permanent Journal to external media, thus reducing the need for full-table backups since only changes are backed up rather than the entire database.
