A recovery session is the set of actions to be taken as a result of the Teradata Database system restart for all transactions that were in progress at the time the Teradata Database system restarted.
All of the online AMPs at the time of the restart work together to determine which transactions were complete, and which ones were not completed. Completed transactions are ignored and incomplete ones are backed out.
If new work or transactions are allowed in during recovery, and another restart occurs, an additional recovery session is created. Then there will be two recovery sessions:
- The first one that was created for the previous restart
- The new one that was created for the current work
Since there is a sequential relationship between these two recovery sets and they are inherently mutually exclusive, they are kept as separate operations.
Therefore, if a system crash or user abort occurs and the amount of work to be done in each recovery session is large, then three, four or more recovery sessions may be created. Each session exists until all the incomplete transactions of the session are rolled back.
The issue of multiple recovery sessions may be avoided by having all the restarts be COLDWAIT, since the WAIT means to wait for recovery to complete before allowing the Teradata Database system to accept new work from the hosts. Although the recovery proceeds faster, since it is not competing with any other new work for computing resources, the Teradata Database system remains totally unavailable to the database users.