AMP Usage - Parallel Transporter

AMP Usage

Down AMPs

The impact of down AMPs on the Update operator depends on the following:

The number of AMPs that are down, either logically or physically, in a cluster

The operational phase of the Update tasks when the down AMP condition occurs

Whether the target tables are fallback or nonfallback

Table 40 describes the impact of down AMPs on Update operator tasks on fallback and nonfallback tables.

Table 40: AMP Usage 

Condition 1	Condition 2	Result
All of the target tables are fallback	Not more than one AMP is down	Update operator tasks continues to run as long as there is not more than one AMP down, either logically or physically, in a cluster. The down AMP does not participate in the application phase if: The AMP goes down before the Update operator tasks enter the application phase, and the AmpCheck attribute is set to 'None' Certain I/O errors occur during the application phase
	Two or more AMPs are down	Update operator tasks do not run, or terminate if two or more AMPs are down, either logically or physically, in a cluster. Note: In the application phase, if AMPs are down to the extent that data on the DSU is corrupted, then you must restore the affected tables.
One or more of the target tables is nonfallback	One or more AMPs are down	Update operator tasks terminate and you cannot restart until all of the AMPs are back up. Note: The Update operator also terminates if I/O errors corrupt the target tables in the application phase.

Nonparticipant AMPs

An AMP can become nonparticipant for an Update operator task one of the following ways:

When any AMP is down at the end of the acquisition phase/beginning of the application phase, the associated AMP becomes a nonparticipant if the AmpCheck 'None' option is specified. Because the Update operator does not run after the acquisition phase if an AMP is down and the target table is nonfallback, an AMP can become a nonparticipant only if the target table is defined as having fallback protection. The AmpCheck 'Apply' and 'All' options prevent the occurrence of nonparticipant AMPs in this situation.

When I/O errors occur in certain Update operator tables during the application phase, the associated AMP becomes a nonparticipant if the I/O recovery operation stops the Update operator task.

When a head/disk assembly (HDA) fails during the application phase, the associated AMP becomes a nonparticipant but it returns after the disk is replaced and the Disk Copy and Table Rebuild utilities are run.

In effect, the Update operator treats a nonparticipant AMP as if it were a down AMP. Thus, the Update operator does not run if a cluster has any combination of more than one AMP that is:

Down

Offline

Nonparticipant

And, if more than one AMP in a cluster becomes a nonparticipant during the application phase, the Update operator tasks cannot continue. The target tables are considered unusable, and must be recovered from archives.

One-AMP Systems

The Update operator cannot run on a one-AMP Teradata Database system, or on a multi-AMP system configured with one-AMP clusters. Any attempt to run Update in this environment triggers the Teradata Database to immediately reject the request, abort the job, and issue a diagnostic message stating that a one-AMP system is not supported.