When an application is running and either a Teradata Database crash or AP reset occurs,
the following steps occur:
The Teradata session ids are preserved and can continue to be used.
If a restart is detected during logoff processing, CLIv2 reconnects the session and
resubmits the logoff request.
Affected Teradata transactions are aborted and all of the databases involved are rolled
back to the state they would have been in if the transactions had not begun.
Affected requests that have not completed are aborted, and any work they have performed
is rolled back.
Affected spool files on the Teradata Database, including those that the Teradata Database
has kept for completed requests, are discarded.
Applications already waiting for a response before the event occurs will be notified.
(For when and how, see “What the Application Does” on page 375.)
Applications submitting a request during the crash and recovery process may be notified.
See “What the Application Does” on page 375.
Applications later using the abort, fetch, rewind, or end request function for a Teradata
SQL request aborted by the event, or submitting a new request in a transaction that
was in progress when the event occurred and thus was aborted in the recovery process,
will be notified. See “What the Application Does” on page 375.