Fast-Start Parallel Rollback in Oracle 26ai

Place parallel rollback in the recovery sequence

Instance recovery applies redo during cache recovery, then undoes uncommitted work during transaction recovery. Database opening and completion of all background undo are different milestones. On-demand recovery can address blocks needed by foreground work while other transaction recovery continues. Oracle explains this sequence in its instance recovery tuning documentation.

Keep three mechanisms distinct. Incremental checkpointing influences the amount of redo needed after an instance failure. Parallel transaction recovery concerns undo work. RMAN restore and media recovery address damaged or missing files using backups and redo. Increasing RMAN channel parallelism does not configure the parameter discussed here, and an RMAN RECOVER command is not a prerequisite for automatic instance recovery after an ordinary crash.

That distinction helps you investigate the right phase. If most downtime occurs before the database opens, first establish what startup and redo processing are doing. If the database has opened but a transaction-heavy application encounters delays, investigate the affected work and background recovery. A single elapsed-time total hides those different causes and can lead to an irrelevant configuration change.

Understand the worker limit

Parallel work does not guarantee a speedup

Parallel rollback can distribute recoverable work across workers, including suitable work within a large transaction. Oracle's parallel execution guide discusses parallel transaction recovery after failures and distinguishes it from rollback initiated by a user during parallel DML. These paths should not be treated as interchangeable experiments.

A useful planning exercise is to compare two recovery workloads. One has many modest transactions spread across data. Another has one large transaction with substantial undo. Even if their total changed-row counts match, their work distribution and storage demands can differ. Measure both if they represent your application. Avoid choosing a setting from a synthetic test whose transaction pattern never occurs in production.

More workers also share resources with returning applications. Monitor processor use, storage response, and foreground latency alongside recovery progress. Treat a faster background completion as only one result. If users experience slower requests during that interval, the change has a cost that belongs in the decision. Begin with the default as a baseline and justify a different value with comparable measurements.

Replace the legacy script with an inspection-first workflow

SHOW CON_NAME
SHOW PARAMETER spfile

SELECT name, value, issys_modifiable, ispdb_modifiable
FROM v$parameter
WHERE name IN ('cpu_count', 'fast_start_parallel_rollback')
ORDER BY name;

Choose temporary or persistent configuration deliberately

Oracle's ALTER SYSTEM reference describes privileges, container context, and parameter scope. For a temporary evaluation in the intended container, use:

ALTER SYSTEM SET FAST_START_PARALLEL_ROLLBACK = LOW
  SCOPE=MEMORY;

SCOPE=MEMORY changes the running configuration. In an SPFILE-based setup, SCOPE=BOTH applies and persists a change, while SCOPE=SPFILE changes the persisted setting for subsequent startup. With a PFILE, maintain the approved initialization file separately for persistence. A dynamic change does not inherently require a shutdown just to take effect.

For an approved persistent configuration in an appropriate SPFILE-based context, the focused example is:

ALTER SYSTEM SET FAST_START_PARALLEL_ROLLBACK = LOW
  SCOPE=BOTH;

These examples are alternatives. Select one after inspecting the environment, rather than executing both automatically. Confirm the effective value afterward using the inspection query. If your procedure requires instance-specific RAC settings or a particular PDB inheritance policy, resolve those details before applying the example. A short script cannot determine the intended administrative scope for you.

Persistence deserves its own check. A successful runtime change and a successful future startup configuration are separate outcomes. Put both in the review record when the change is meant to survive restart. Conversely, label an evaluation explicitly as temporary so another administrator does not mistake the live value for the long-term configuration.

Observe recovery workers

V$FAST_START_SERVERS reports workers performing parallel transaction recovery. The documented states are IDLE and RECOVERING. This query preserves container identity and presents the transaction identifier as readable hexadecimal text:

SELECT con_id, pid, state,
       RAWTOHEX(xid) AS transaction_id,
       undoblocksdone
FROM v$fast_start_servers
ORDER BY con_id, pid;

The worker's process ID and undo-block count provide context for successive samples. An idle row is not an error. Avoid adding the same cumulative counter from several snapshots as if each snapshot represented new work. Store a timestamp with each observation and compare changes over a clearly defined interval.

Use a consistent observation process during a test. Capture the configuration before the workload starts, the failure and restart milestones from the controlled test procedure, and recovery samples afterward. This sequence gives each measurement a place in the timeline. Without timestamps, a worker list copied into a ticket cannot explain whether it describes early recovery, a quiet interval, or completion.

Observe parallel transaction progress

V$FAST_START_TRANSACTIONS reports transactions recovered in parallel, excluding serial recovery progress. It includes transaction state, completed and total undo blocks, and container identity. Query those documented columns directly:

SELECT con_id, usn, slt, seq, state,
       undoblocksdone, undoblockstotal
FROM v$fast_start_transactions
ORDER BY con_id, usn, slt, seq;

Use the identifying columns together to follow a transaction across samples. Empty results establish only that this view returned no parallel-recovery transactions visible to the session. They do not prove that every form of rollback has finished. Check the connection context and the application outcome before declaring recovery complete.

Undo-block counts are progress indicators, not a precise remaining-time forecast. Resist converting one early rate into a promised completion time. A better operational report says when the sample was taken, which transactions were visible, how their counts changed, and whether the service-level checks passed. Keep estimates separate from directly observed facts.

For authorized RAC-wide observation, Oracle's global dynamic performance views provide instance identity through INST_ID. Use the corresponding GV$ views where appropriate and retain both instance and container identifiers. Do not merge rows from different instances into a single transaction narrative without checking their context.

Build a representative comparison

Plan recovery experiments on an isolated test database with a repeatable workload and a separate failure procedure. This lesson deliberately supplies no crash command. The useful experiment is a controlled comparison with known data and verified recovery outcomes, rather than an unexpected interruption of a service that other people depend on.

1. Record the baseline. Save the original runtime and persisted configuration, container, instance, CPU count, dataset, and workload definition.
2. Define success. Choose measurable milestones such as database opening, a representative application transaction succeeding, and completion of observable parallel recovery.
3. Run the baseline test. Capture timestamps and resource observations using a consistent sampling interval.
4. Change one setting. Evaluate a different rollback value only when the baseline and available capacity justify the comparison.
5. Repeat comparable work. Restore the test conditions and compare both recovery progress and foreground response.
6. Validate the data. Confirm expected committed results and the absence of the test transaction's uncommitted effects.

For a practical measurement sheet, use separate columns for elapsed recovery milestones, application latency, CPU utilization, and storage observations. Include a notes column for deviations such as another job running during one trial. A faster result accompanied by a workload change is a reason to repeat the comparison, not a sufficient basis for deployment.

Specify the application check precisely. “The database opened” is an infrastructure observation. “The order-entry transaction committed and its result was verified” is an application observation. Choose checks that exercise the data and operations affected by the recovery workload. A connection test alone may miss the delay you are trying to reduce.

Turn the observations into a decision

Consider a hypothetical batch-processing test with two recovery runs. In the first run, the application becomes usable after three minutes and background recovery finishes after twelve minutes. In the second, background recovery finishes after eight minutes, but the application becomes usable after four minutes. Those invented numbers describe a tradeoff, not a universal improvement. A service with a strict availability objective may prefer the first result even though its background work takes longer.

Before accepting either result, examine comparability. Were the transactions the same size? Did both runs begin with the same dataset? Did another maintenance task use the storage during one run? Record answers rather than explaining away inconvenient measurements. If the conditions differ substantially, repeat the experiment with controlled conditions and label the earlier results as exploratory.

Also specify what will trigger a review after deployment. Examples include a change in batch volume, a new application sharing the database, or a revised availability requirement. A setting selected for one workload is a recorded operational decision, not a permanent claim that its value is best for every workload. Keeping the original observations makes later reviews more concrete.

Finally, separate configuration verification from performance verification in the ticket. The first confirms the intended value and scope. The second explains the measured benefit and its cost. A successful statement proves that Oracle accepted a change; it does not prove that the application recovered faster.

Restore the original configuration and review the evidence

A rollback plan should restore the original setting, not automatically restore the default. If the baseline was FALSE or HIGH, changing to LOW is another configuration change. Use the recorded original value and the same intended container and persistence policy. Verify runtime and persisted outcomes independently when both were changed.

Retain the comparison even when the proposed change is rejected. The measurements can explain why the current setting is appropriate and prevent the same inconclusive experiment from being repeated. Record what the test covered and what remains uncertain, such as a larger batch size or a different service mix. Keep those limits visible when applying a result to another database.

During an actual incident, avoid repeatedly toggling the parameter while watching a small number of samples. Decide what evidence would justify a change and who owns that decision. Record the time of any alteration so later observations can be interpreted against the configuration that produced them. A controlled sequence is easier to diagnose than several undocumented adjustments.

Check your understanding

If CPU_COUNT is 8, the calculated ceiling for LOW is 16 and for HIGH is 32. Those calculations do not predict the observed worker count. If the transaction view is empty, you still need contextual and application checks. If a runtime change was temporary, it should not be described as a verified persistent configuration.

The completed administration task therefore has four pieces of evidence: the original configuration, the chosen setting and scope, measured recovery observations, and the verified application outcome. Together they explain why the decision is appropriate. The next lesson moves from recovery within this database to an automated standby database and its role in a wider availability strategy.