Before Teradata changes a data row (update, insert or delete statement), it takes a backup copy of the entire row.

Each AMP manages its local transient journal. Backup rows are always kept together with the base table row on the same AMP.

The decision about which row belongs to each AMP is built on the hashing algorithm Teradata used to distribute rows evenly.

The only task of the transient journal is to allow Teradata to roll back failed transactions. In a rollback case, the base table row can be quickly replaced with the backup row from the transient journal.

The transient journal cannot be turned off manually.

This is reasonable because database integrity has to be ensured. But sometimes we want to avoid the usage of it for performance reasons.

Especially when doing many changes on a table (such as updating billions of rows), the transient journal can become huge. Because it’s stored in the DBC database, we could run out of space. Running out of space would have significant implications on the existing workload (failing sessions, etc.)

Another nasty side effect of the transient journal shows up when updating many rows in an enormous and skewed table. The rollback usually consumes many resources and might hurt the overall system performance.

Remember, the transient journal is AMP-local: For any rollback executed on a skewed table, the AMPs holding most of the rows will have to do most of the work. Of course, the above-described issues also apply to DELETE statements.

Luckily, there are several techniques to avoid using the transient journal in such a situation described above.