15.00 - RollbackPriority - Teradata Database

Teradata Database Utilities

Teradata Database
Release Number
Content Type
Publication ID
English (United States)
Last Update


Note: This setting affects all users on the system.


Determines the priority given to rollback operations.

Field Group


Valid Settings





Rollbacks are executed within the aborted job's Performance Group or workload.


Rollback is at system priority, a super-high priority, greater than any user-assigned priority, which is reserved for critical internal work.



This value should be changed only after careful consideration of the consequences to system performance, based on the information here and in Database Administration.

Changes Take Effect

After the next Teradata Database restart.

Usage Notes  

RollbackPriority affects only individual rollbacks resulting from aborted sessions. It does not affect rollbacks resulting from a Teradata Database restart. The priority of a rollback resulting from a restart is determined by a setting in the Recovery Manager (rcvmanager) utility. This setting can be changed at any time, even if there is no system rollback underway. If a system rollback is underway when the setting is changed, the tasks working on the rollback will have their priorities changed immediately.

Performance Implications

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.
  • Related Topics


    For more information on…


    rollbacks, rollback priority, and their affect on performance

    Database Administration.

    Performance Groups, Allocation Groups, and the Priority Scheduler utility

    Priority Scheduler (schmon).

    the Recovery Manager utility

    Recovery Manager (rcvmanager).