RollbackPriority - Teradata Database

RollbackPriority

Because rollbacks can involve millions or billions of rows, competing for CPU and other system resources, rollbacks can impact system performance. Rollbacks can keep locks on affected tables for hours or days until the rollback is complete. During a rollback, a trade-off occurs between overall system performance and table availability.

How RollbackPriority affects performance is not always straightforward, and is related to the Priority Scheduler configuration, job mix, and other processing dynamics. The RollbackPriority setting should only be changed after full consideration of the performance consequences:

When RollbackPriority is set to FALSE, rollbacks are performed at system priority, a special priority higher than any user-assigned priority, that is reserved for critical internal work. As a result, faster rollbacks occur at the expense of other online performance.

The default setting of FALSE is especially appropriate when rollbacks are large, occurring to critical tables that are accessed by many users. It is better to complete these rollbacks as quickly as possible to maximize table availability.

When RollbackPriority is set to TRUE, rollbacks are executed within the aborted job's Performance Group or workload. This isolates the rollback processing to the aborted job's priority, and minimizes the effect on the performance of the rest of the system. However, if the rollback places locks on tables that other users are waiting for, this causes a greater performance impact for those users, especially if the rollback is running at a low priority.

A setting of TRUE is appropriate when rollbacks are typically smaller, occurring to smaller tables that are less critical, and less extensively used.

Regardless of the RollbackPriority setting, rollbacks are never subject to CPU limits:

When RollbackPriority is FALSE, rollbacks run in the system performance group where jobs use as much CPU as they require.

When RollbackPriority is TRUE, rollbacks are not constrained by CPU limits at the system, Resource Partition, or Allocation Group level.