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 does not terminate a transaction unless it needs 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.
- ABORT or ROLLBACK
- Deadlocked.
- An aborted DDL statement.
Either of the above situations 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 if it times out, the entire transaction aborts and rollback processing is performed.
Rollback processing, also called abort processing, performs the following actions in Teradata session mode.
- Rolls back all changes made to the database as a result of the transaction.
- Releases any locks applied as a result of requests in the transaction.
- Erases any partially accumulated results (spools).
The rollback process constitutes transaction recovery.
- Locks applied on behalf of the transaction might block other sessions.
- The transaction may fail due to the accumulation of too many 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 might delay post-restart system availability.
Application-Initiated Asynchronous Aborts
An application-initiated asynchronous abort 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 several 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™ .