RollbackPriority - Advanced SQL Engine - Teradata Database

Purpose

Determines the priority given to rollback operations.

Field Group

General

Valid Settings

Default

FALSE

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

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.

RollbackPriority 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. It is related to the TASM/Viewpoint Ruleset, 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 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.

Rollbacks can be affected by Workload Management Capacity On Demand (WM COD) and Hard Limits, depending on their running context:

• When RollbackPriority is FALSE, the rollback runs under the system priority, which is subject to WM COD throttling.
• When RollbackPriority is TRUE, the rollback runs under the current user workload, which is also subject to WM COD throttling. The current workload may be further throttled if it is running under a Virtual Partition with a fixed limit, or a SLG Tier Workload Management Method with a hard limit.

Related Topics