Rollback Processing | Transaction Processing | Teradata Vantage - Rollback Processing - Analytics Database - Teradata Vantage

SQL Request and Transaction Processing

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
VMware
Product
Analytics Database
Teradata Vantage
Release Number
17.20
Published
June 2022
Language
English (United States)
Last Update
2024-10-04
dita:mapPath
zfm1628111633230.ditamap
dita:ditavalPath
qkf1628213546010.ditaval
dita:id
evd1472255317510
lifecycle
latest
Product Category
Teradata Vantage™

This section describes rollback (abort) processing for Teradata and ANSI session modes.

See Teradata Vantage™ - SQL Data Manipulation Language, B035-1146 for details about the ABORT and ROLLBACK statements.

Rollback Processing in ANSI Session Mode

ANSI only recognizes termination of a transaction by the performance of a COMMIT [WORK] or ABORT/ROLLBACK [WORK] request performed by the application. The system terminates a transaction only to preserve the integrity of the database.

If a request errs, only the current request is rolled back, and not other requests previously performed in the transaction, which means that a request in which this happens is not atomic (for more information, see ACID Properties of Transactions). The Lock Manager does not release locks placed for a rolled back request.

The entire transaction is rolled back when the current request is in one of the following states:
  • ABORT or ROLLBACK
  • Deadlocked.
  • An aborted DDL statement.

    Either state listed here is necessary before the locks held by the transaction can be released.

  • Rejected because the request was blocked and had specified a LOCKING NOWAIT option.

Rollback Processing in Teradata Session Mode

For a transaction, either all submitted requests are performed, or none are. Another way of stating this is to say that all transactions in Teradata session mode are atomic (for more information, see ACID Properties of Transactions).

If, for any reason, a transaction cannot be completed successfully, or times out, the entire transaction ends and rollback processing is performed.

Rollback processing performs the following actions in Teradata session mode:
  1. Rolls back all changes made to the database as a result of the transaction.
  2. Releases any locks applied as a result of requests in the transaction.
  3. Erases any partially accumulated results (spools).

The rollback process constitutes transaction recovery.

If the amount of work performed by a transaction is not properly controlled, the following things may occur.
  • Locks applied on behalf of the transaction may block other sessions.
  • The transaction may fail due to the accumulation of locks.
  • If a failure, time out, ABORT/ROLLBACK, logoff, or system restart occurs, rollback of the work already performed by the transaction may delay releasing locks and the availability of the locked objects.
  • If the system must restart during the transaction, rollback of the work already performed by the transaction may delay post-restart system availability.

Application-Initiated Asynchronous Aborts

An application-initiated asynchronous end causes full transaction rollback in both ANSI and Teradata session modes. The term application in this case refers to a component of the database management system, whether client-based or server-based, and not to user-written applications.

This can occur in multiple ways, for example, by means of a CLIv2 ABORT request, or by the TDP when the application terminates without proper session cleanup, or by using a Teradata tool such as Teradata Studio™.