4 Ways To Protect Your Data In Teradata

Roland Wenzlofsky

November 4, 2014

minutes reading time

Teradata has many features to protect you against potential data loss. Each feature protects your data differently and on a different level of granularity. Some features are activated by default; others must be turned on explicitly.

1. The Teradata Transient Journal – Transaction Failure Protection

All transaction changes are recorded in the so-called transaction log or Teradata transient journal.

While most Teradata tables are distributed across all AMPs by the Primary Index values, the transient journal is not. Each AMP keeps its transient journal.

A copy of the original row is stored in the transient journal, ensuring data integrity when a row changes during a transaction. It enables the system to roll back the table to the initial state, for example, in the case of error.
The rows are only temporarily stored in the transient journal and deleted once successfully committed. The parsing engine ensures that all AMPs successfully finish their work before committing any transaction.

2. Teradata Fallback – AMP Failure Protection

The transient journal protects your data only against transaction failures. In the case of an AMP failure, it is possible that your data is not accessible anymore until the AMP comes back online. The fallback protection strategy was implemented to ensure data accessibility in such cases,

Fallback protection means that each row is stored twice. A second hash map determines each row an AMP, saving a copy of the row. Fallback-protected tables require twice as much space.

The advantage of fallback protection is that your data may be accessible in case of an AMP failure, as the auxiliary AMP will take over its tasks until the failed AMP comes back online.

Only in the unlikely event that the backup AMP fails will your table become inaccessible.

To achieve maximum protection, AMPs are grouped in clusters. Primary AMP and fallback AMP always belong to the same cluster and protect each other.

Furthermore, the primary AMP and the fallback AMP are never stored together physically at the same node, a prudent design choice for hardware failures. Even if a complete node fails, the fallback protection allows us to access the data!

3. Raid 1 – Disk Failure Protection

Fallback protection helps in case of the failure of the Unix processes (VPROC, AMP) belonging to the Teradata System.

Teradata uses the public RAID 1 protection (mirroring) to protect the data against disk failures. Although each AMP has exactly one virtual disk assigned (VDISK), several physical disks make up this VDISK. Half of the discs keep the mirrored data.

As in the case of fallback protection, the cost is the usage of twice as much disk space.

The RAID 1 configuration ensures enhanced data accessibility and security. If a single disk fails, data will serve from the mirror disk. If both the primary disk and the mirror disk fail, and no fallback protection is enabled, the data would be lost.

4. The Teradata Clique – Node Failure Protection

This protection mechanism adds another level of security to the Teradata System. Clique configuration protects against complete node failures. Cliques are grouping nodes together like clusters group the AMPs together.

The AMPs of the failed node will be migrated to another node belonging to the same clique and stays fully functional. The node taking over the AMPs will have more work to do, negatively impacting the performance.

Nevertheless, to overcome this restriction, Teradata offers hot standby nodes to take over the AMPs of a failed node. As these AMPs are not engaged in routine operations in the ordinary course of business, no performance degradation occurs.

Remember that before the AMP migration occurs, a system restart is required, followed by another restart as soon as the failed node goes online again.

  • Hi Roland,

    Thanks for the awesome post.

    Is it right that a permanent journal too protects the data and can make up for the 5th way for protecting data?
    Why it does not make the cut?

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    You might also like