In some cases, data might be lost if sessions are aborted by:
- The Gateway Control Utility DISCONNECT SESSION command
- The Performance Monitor ABORT SESSION command
- BTEQ not initiating the reconnection of sessions that have been idle for more than 20 minutes after a Teradata Database restart.
After a Teradata Database restart, BTEQ sends a request or fetch on the active session, then CLI starts the reconnect procedure. If a session is idle, it does not send a request or fetch, and CLI cannot perform the reconnect.The 20-minute period is the default value of a gateway configuration specification. The period might be different for local systems.
In these cases, the Teradata Database returns error code 8018 (Session id is illegal) or 8055 (The session has been forced off) to BTEQ. This means that the Teradata SQL response has been discarded, and the request and the transaction in which it was embedded have been aborted and backed out.
- For mainframe-attached systems, BTEQ does not resubmit the request after a session has been aborted, and associated data might be lost.
- For workstation-attached systems, if multiple sessions are running, BTEQ resubmits the request through the next available session. However, if only one session is logged on, and that session is forced off, the transaction is aborted and its associated data is lost. BTEQ is terminated at this point.
The severity of this condition depends on the nature of the transactions that were running when the session was aborted:
- If an insert request was running, the row data might be lost. In this case, the maximum number of rows lost is equivalent to the number of sessions that received the 8018 error.
- If an update or delete request was running, the integrity of the table might be compromised.
In either case, the aborted request must be manually resubmitted.