Oracle FAST_START_PARALLEL_ROLLBACK: Understanding and Tuning Parallel Rollback

In Oracle Database, the FAST_START_PARALLEL_ROLLBACK initialization parameter controls the degree of parallelism used during transaction rollback. It helps Oracle accelerate the rollback of terminated or interrupted transactions, particularly after an instance crash or failure.

When an instance recovers, Oracle may need to roll back large transactions that were not committed before the failure. Depending on the amount of undo data involved, this process can take a considerable amount of time. By enabling parallel rollback, Oracle can distribute the workload across multiple processes, potentially reducing recovery time.

However, parallel rollback also consumes CPU and I/O resources. Choosing the appropriate parameter value is therefore important for balancing rollback performance and overall system resource utilization.

Parameter Values

The FAST_START_PARALLEL_ROLLBACK parameter supports three values:

Value	Description
LOW	The default setting. Limits the degree of parallelism to a maximum of 2 * CPU_COUNT.
HIGH	Allows a higher degree of parallelism, up to 4 * CPU_COUNT.
FALSE	Disables parallel rollback and forces rollback processing to run serially.

The actual rollback performance depends on several factors, including the volume of undo data, CPU availability, storage performance, and the number of transactions that need to be rolled back.

How to Change the Parameter

You can change the parameter dynamically using the ALTER SYSTEM command.

Enable a higher degree of parallelism:

ALTER SYSTEM SET fast_start_parallel_rollback = HIGH;

Use the default, lower degree of parallelism:

ALTER SYSTEM SET fast_start_parallel_rollback = LOW;

Disable parallel rollback:

ALTER SYSTEM SET fast_start_parallel_rollback = FALSE;

These commands change the parameter at the system level. In an Oracle RAC environment, consider the instance scope and the desired behavior across all instances when applying the change.

When Should You Use Each Setting?

1. When to Use LOW or HIGH

Consider using LOW or HIGH when the database needs to roll back large, uncommitted transactions following an instance failure or crash.

For example, a system may have been executing large parallel DML operations when the instance failed. During instance recovery, Oracle must undo the changes made by transactions that did not commit.

Parallel rollback can help accelerate this process, provided sufficient CPU and I/O capacity is available.

• Use LOW as the default choice when parallel rollback is beneficial but resource consumption should remain relatively controlled.
• Consider HIGH when rollback is taking too long, the volume of undo data is substantial, and sufficient CPU and storage I/O capacity is available.

Increasing the degree of parallelism does not always improve performance. If the system is already constrained by CPU utilization or storage throughput, using HIGH may increase contention instead of reducing recovery time.

2. When to Use FALSE

Setting the parameter to FALSE disables parallel rollback and makes Oracle perform rollback processing serially.

This setting may be worth evaluating when parallel rollback processes cause excessive resource contention, particularly under heavy CPU or storage I/O pressure.

Potential symptoms include:

• High CPU utilization caused by rollback workers.
• Storage I/O saturation during rollback processing.
• Increased resource contention between rollback workers and other database activities.
• Poor overall system responsiveness while rollback is in progress.

Disabling parallel rollback can reduce the resource pressure associated with multiple rollback workers. However, it can also significantly increase the time required to complete rollback, especially when a large amount of undo data must be processed.

Important: Setting the parameter to FALSE is not a general solution for every database hang or performance problem. Before changing it, identify the dominant bottleneck and verify that parallel rollback is contributing to the issue.

Monitoring Rollback Progress

Oracle provides the GV$FAST_START_TRANSACTIONS dynamic performance view to monitor transactions involved in fast-start parallel rollback.

You can query it as follows:

SELECT * FROM GV$FAST_START_TRANSACTIONS;

In Oracle RAC, the GV$ view provides information across instances, making it useful for monitoring rollback activity throughout the cluster.

Review the returned information to assess rollback progress and identify transactions that may require significant recovery work.

For more detailed troubleshooting, correlate this information with CPU utilization, storage I/O metrics, transaction activity, and relevant wait events.

Understanding Wait Events During Parallel Rollback

During parallel rollback, Oracle may encounter wait events such as Wait for a undo record or Wait for stopper event, depending on the Oracle version and the specific rollback activity.

These waits may occur when rollback workers need to coordinate their work or wait for the undo information and processing dependencies required to proceed.

Their presence does not automatically indicate a problem. The important factors are the frequency and duration of the waits, the amount of rollback work remaining, and the overall resource utilization of the database.

What if CPU Utilization Becomes Excessive?

When a large volume of undo data must be processed, parallel rollback can generate substantial CPU demand. If CPU contention becomes the primary bottleneck, reducing the degree of parallelism may improve overall system responsiveness.

One option is to change the parameter to:

ALTER SYSTEM SET fast_start_parallel_rollback = FALSE;

This disables parallel rollback and may reduce CPU contention associated with concurrent rollback workers.

However, the trade-off is that rollback processing may take considerably longer because the work is performed serially.

Before making this change, verify that CPU pressure is actually related to parallel rollback rather than other database workloads. Also, monitor the impact on recovery progress after applying the change.

Best Practices

When tuning FAST_START_PARALLEL_ROLLBACK, consider the following recommendations:

1. Start with LOW. It is the default setting and provides a reasonable starting point for most environments.
2. Use HIGH selectively. Increase parallelism when rollback duration is a concern and the server has sufficient CPU and I/O capacity.
3. Identify the bottleneck before changing the parameter. Distinguish CPU saturation from storage I/O limitations and rollback coordination waits.
4. Monitor rollback progress. Use GV$FAST_START_TRANSACTIONS alongside operating system and database performance metrics.
5. Evaluate the trade-off before disabling parallelism. Setting the parameter to FALSE may reduce resource contention but can substantially extend rollback duration.
6. Validate changes in the actual workload. The optimal setting depends on transaction size, undo volume, available resources, and database activity.