Dispatcher | SQL Request and Transaction Processing | Teradata Vantage - Dispatcher - Advanced SQL Engine - Teradata Database

SQL Request and Transaction Processing

Product
Advanced SQL Engine
Teradata Database
Release Number
17.05
17.00
Published
June 2020
Language
English (United States)
Last Update
2021-01-24
dita:mapPath
ykx1561500561173.ditamap
dita:ditavalPath
lze1555437562152.ditaval
dita:id
B035-1142
lifecycle
previous
Product Category
Teradata Vantage™

The Dispatcher

The Dispatcher exercises execution and response control for requests and dynamic plan fragments, and manages transaction and request aborts and the queue table cache.

The Dispatcher has the following primary functions:
  • Apply TASM rules and classify into workload.
  • Route AMP steps to the appropriate AMPs.
  • Return result or statistics feedback to the optimizer so it can generate the next plan fragment when executing a dynamic plan.
  • Return the results of a request to the user application that submitted that request.
  • Notify client applications and Teradata platform processors of aborted transactions and requests.

Execution Control

Execution control is the term applied to Dispatcher handling of concrete steps.

The Dispatcher routes the concrete steps in the plan for a request to the appropriate AMPs for processing. Once a concrete step has been placed on the BYNET, it is referred to as an AMP step.

Part of the routing function of the Dispatcher is the sequencing of step execution. A new step is never dispatched until the previous step has completed its work, which is signalled by a completion response from the affected AMPs.

Teradata Database can dispatch a parallel step if the previous step has finished acquiring its task locks, but has not yet completed its work. This is signalled by a response from the affected AMPs, and the Dispatcher determines that it can send another parallel step.

Depending on the nature of the request, an AMP step might be sent to one, several, or all AMPs (termed point-to-point, multicast, and broadcast, respectively).

Execution control also monitors the status reports of individual AMPs as they process the steps the Dispatcher has sent to them and forwards the results to the response control function once the AMPs complete processing each step.

Response Control

Response control is the term applied to Dispatcher handling of results. The second most important function of the Dispatcher is to return the (possibly converted) results of a request to the requesting application.

Transaction and Request Abort Management

The Dispatcher monitors transactions for deadlocks. When a deadlock occurs, the Dispatcher resolves it by managing the locked resources consistently and resolving the deadlock in the most optimal manner available. This often means that one of a pair of deadlocked transactions must be aborted.

The Dispatcher process request and transaction aborts by notifying both the client application and all affected Teradata platform virtual processors.

Transactions and requests can abort for several reasons, both normal and abnormal. Typical normal aborts are caused by the following actions:
  • TDP logoff command
  • Client application terminates normally
Typical abnormal aborts are caused by the following actions:
  • Syntax and semantic errors in a request
  • Internal Parser errors such as memory overflow
  • Internal AMP errors such as primary index conflicts
  • Transaction deadlocks

Queue Table FIFO Cache Management

The Dispatcher maintains a cache that holds row information for a number of non-consumed rows for each queue table. The system creates this queue table cache during system startup. There can be a queue table cache task on each PE in your system.

The queue table FIFO cache row entries on a given PE are shared by all queue tables that hash to that PE. Each queue table row entry is a pair of QITS and rowID values for each row to be consumed from the queue, sorted in QITS value order.

During startup, the system allocates 64KB to the queue table cache on each PE and increases its size dynamically in 64KB increments to a maximum of 1MB per PE as required. The system initializes all the fields in the cache during startup and allocates space for 100 table entries. As queue tables are activated, they populate these slots beginning with the lowest numbered slot and proceeding upward from there. When the maximum cache size is reached, the system flushes it, either partially or entirely, depending on the number of bytes that must be inserted into the cache.

See “CREATE TABLE (Queue Table Form)” in Teradata Vantage™ - SQL Data Definition Language Syntax and Examples, B035-1144 for more information about the queue table FIFO cache and its operation.