Teradata Data Protection

Teradata has many features to protect against potential data loss. Each of these features protects the data differently and on a different level of granularity. Some processes for protection are automatic, and some of them are optional.

Here are some features available for data protection in Teradata.

1. RAID
2. Fallback
3. Cliques
4. Journals
5. Hot Standby Nodes

RAID

RAID mechanism is used to protect data from Disk Failures. Disk Array consists of a set of disks that are grouped as a logical unit. This unit looks like a single unit to the user, but it can be spread across several disks.

RAID 1 is commonly used in Teradata. In RAID 1, each disk is associated with a mirror disk. Any changes to the data in the primary disk are reflected in mirror copy as well. If the primary disk fails, then the data from the mirror disk can be accessed.

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 as disk space.

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

Fallback

Fallback protects the table data by storing the second copy of rows of a table on another AMP called as Fallback AMP. If one AMP fails, then the fallback rows are accessed. With this, even if one AMP fails, data is still available through fallback AMP. The fallback option can be used at table creation or after table creation.

Fallback ensures that the second copy of the table's rows is always stored in another AMP to protect the data from AMP failure. However, fallback occupies twice the storage and input for Insert, Delete, or Update.

The advantage of fallback protection is that the 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 as well, your table ultimately will become inaccessible.

The following diagram shows how a fallback copy of the rows is stored in another AMP.

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

The main AMP and the fallback AMP are never stored together physically at the same node, a prudent design choice on the nature of hardware failures. Even if a complete node fails, the fallback protection still allows us to access the data!

Cliques

Clique is a mechanism used by Teradata to protect data from Node failures. A clique is nothing but a set of Teradata nodes that share a common set of Disk Arrays. When a node fails, the AMPs of the failed node will be migrated to another node belonging to the same clique and stays fully functional and continue to access their disk arrays.

This protection mechanism adds another level of security to the Teradata System.

To remove 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. Before the AMP migration occurs, a system restart is required, followed by another restart as soon as the failed node goes online again.

Journals

Journals are kept on the system to provide data availability in the event of a component or process failure. Journals are the following types in the Teradata:

1. Recovery Journal: The Teradata Database uses Recovery Journals to maintain data integrity in the case of automatically

• An interrupted transaction.
• An AMP failure.

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.

2. Down-AMP Recovery Journal: The Down-AMP Recovery Journal allows continued system operationwhile an AMP is down.

A Down-AMP Recovery Journal is used with Fallback-protected tables to maintain a record of writing transactions (updates, creates, inserts, deletes, etc.) on the failed AMP while unavailable.

The Down-AMP Recovery Journal starts after the loss of an AMP in a cluster automatically. Any changes to the data on the failed AMP are logged into the Down-AMP Recovery Journal by the other AMPs in the group.

When the failed AMP is online again, the restart process includes applying the changes in the Down-AMP Recovery Journal to the recovered AMP. The journal is discarded when the process is complete, and the AMP is brought online and fully recovered.

3. Transient Journal: A Transient Journal maintains data integrity when in-flight transactions are interrupted. Data is returned to its original stateafter transaction failure.

A Transient Journal is used during regular 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 stores a copy of all the rows automatically affected by the transaction in the Transient Journal until the transaction is completed.

Once the transaction is complete, the "before images" are purged. In the event of a transaction failure, "before images" are reapplied to affected tables, deleted from the journal, and the "rollback" operation is completed.

4. Permanent Journal: Permanent Journals are an optional feature used to provide an additional level of data protection. We can specify the use of Permanent Journals at the table level. It offers full-table recovery for 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 such as user data, so they take up additional disk space. The Database Administrator maintains the Permanent Journal entries such as deleting, archiving, etc.

The additional disk space required may be calculated in advance to ensure adequate resources. The Database Administrator must leave 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.

Hot Standby Node

Hot Standby Node is a node that does not participate in the production environment.

Teradata Database can use spare nodes to improve availability and maintain performance levels in node failure. If a node fails, then the vprocs from the failed nodes will migrate to the hot standby node.

Once the failed node is recovered, it becomes the hot standby node. Hot Standby nodes are used to maintain the performance in case of node failures.

When the failed node is recovered and restarted, it becomes the new hot standby node. The second restart of Teradata is not needed.

Hot standby node has the following characteristics:

• A node that is a member of a clique.
• Hot Standby Node does not regularly participate in the trusted parallel application (TPA).
• It can be brought into the configuration when a node fails in the clique.
• It helps with unplanned outages.
• It also eliminates the need for a restart to bring a failed node back into service.