Lesson 4	Fast-Start on-demand rollback
Objective	Explain how automatic Fast-Start on-demand rollback improves data availability during transaction recovery, and how to observe its effects.

Automatic Fast-Start On-Demand Rollback in Oracle 26ai

Oracle AI Database 26ai performs Fast-Start on-demand rollback automatically. There is no separate command or parameter that an administrator must use to enable it. Its purpose is to recover needed blocks from terminated transactions without making a requesting transaction wait for the entire unfinished transaction to be recovered first.

This distinction changes the administrative task. Instead of following an activation checklist, understand when on-demand recovery applies, distinguish it from ordinary lock contention, and observe whether the application can resume useful work. Background recovery can continue after the database opens, so opening the database and completing all transaction cleanup are different milestones.

On-demand rollback preserves transaction consistency. It does not make unfinished changes permanent, remove all waits, or replace restore and recovery procedures after media loss. The benefit is earlier availability of the data that new work needs, subject to the recovery processing and resources required for that access.

Why Transaction Recovery Is Necessary

A transaction groups changes into a unit that is committed or rolled back. Oracle records undo information so it can reverse unfinished changes and supply consistent data to readers. Modified database blocks may reach datafiles before their transaction commits; committed changes may also remain in memory while the necessary redo is already durable. Recovery must therefore consider transaction state rather than simply which blocks reached disk first.

After an instance failure, cache recovery applies the required redo to reconstruct affected blocks. This can reconstruct both committed and uncommitted changes. Transaction recovery then applies undo to remove changes that were not committed when the failure occurred. The database can open after cache recovery while transaction recovery continues.

A terminated transaction may have modified many blocks and left unfinished work affecting data that an application now needs. Background recovery processes that work. Access-triggered recovery provides another way to address the relevant blocks sooner. The system still has to establish a consistent result before allowing conflicting new work to proceed.

The historical term dead transaction refers here to a terminated transaction requiring recovery. It does not mean every transaction that existed before a failure, nor every live session that has been idle for a while. Committed transactions must retain their committed outcomes. A live transaction holding a lock requires a different diagnosis from recovery of a terminated transaction.

How On-Demand Rollback Helps New Work

Oracle's 26ai VLDB guide describes Fast-Start on-demand rollback as recovery of terminated transactions one block at a time. When new work needs data affected by unfinished recovery, Oracle can perform the necessary recovery for the block being accessed while the remainder of the terminated transaction is recovered in the background.

Imagine an inventory adjustment that modified thousands of rows but did not commit before an instance failed. After recovery opens the database, a new order needs one affected product row. Making that request wait for every unrelated product adjustment to be undone would delay useful business work. On-demand recovery addresses the needed block so the request can proceed once the required recovery and other access conditions are satisfied.

The unit of recovery in this explanation is a database block, not a business label such as a critical order or a premium customer. Oracle is not reading an application priority list and deciding which entire transaction matters most. The new request creates demand for the relevant data; recovery processing addresses that demand within the database's consistency rules.

Access still has a cost. Required blocks and undo may need to be read, and recovery competes for system resources with the workload already running. A statement can also encounter other waits. Describe the feature as reducing dependency on complete background cleanup, rather than promising that an affected row becomes accessible immediately or that every request finishes without waiting.

Separate the Related Recovery Mechanisms

Recovery responsibilities and administrative controls
Mechanism	Purpose	Relationship to on-demand rollback
Cache recovery	Applies required redo to reconstruct blocks.	Precedes transaction cleanup during instance recovery.
Background transaction recovery	Undoes unfinished changes.	Continues processing work beyond the immediately requested blocks.
On-demand rollback	Recovers affected blocks needed by new access.	Automatic behavior; no separate enablement command.
Parallel rollback	Uses multiple workers for eligible transaction recovery.	A separate concurrency mechanism with a documented parameter.
Fast-Start checkpointing	Limits outstanding crash-recovery work through incremental writes.	Its recovery target is not an on-demand activation switch.
Media recovery	Recovers damaged or restored database files.	On-demand rollback cannot replace missing files or backups.

What the Administrator Actually Does

The useful operational steps are observation and validation, not enabling a dormant feature. First establish the failure and recovery context. Determine whether the database experienced an instance failure, whether recovery has opened it, and whether the application is encountering unfinished transaction recovery or another source of contention.

Next identify the service and operations affected. A successful query against an unrelated table proves little about an update that needs a block changed by the terminated transaction. Record what users are trying to do, which data they access, and the timing of their requests relative to startup and background recovery.

Then inspect available recovery and session evidence with its limitations in mind. A parallel recovery view describes eligible parallel work; session waits describe observed access conditions. Neither independently proves that every block is available or that all unfinished transactions have been recovered.

Finally, verify the intended application outcome. Check representative operations and committed results, preserve relevant diagnostic records, and document any remaining recovery activity. A useful incident record distinguishes database open time, first successful affected operation, and completion of background work instead of reporting a single ambiguous recovery time.

Remove the Legacy Enablement Checklist

FAST_START_MTTR_TARGET controls checkpoint-related crash-recovery targeting. A positive value is not a prerequisite for automatic on-demand rollback. Changing it addresses a different recovery-performance question and can alter normal write activity. Keep checkpoint policy and transaction recovery behavior distinct when reviewing a configuration.

Undo administration is also a separate responsibility. Appropriate undo storage supports transaction processing, rollback, and consistent reads, but changing UNDO_MANAGEMENT or UNDO_TABLESPACE is not an on-demand activation procedure. Likewise, UNDO_RETENTION concerns retention of undo history; it does not establish the business recovery point objective or replace backups and redo protection.

There is no row-locking enablement step for this feature, and the old suggestion to adjust a small-table caching threshold is unrelated to enabling on-demand transaction recovery. Avoid changing unrelated settings because an older article presented them in a numbered list.

The VLDB documentation retains a historical compatibility threshold when explaining this recovery capability. It should not become an instruction to change COMPATIBLE on an Oracle 26ai system. Compatibility management has its own release and upgrade requirements. This lesson also does not prescribe a Recovery Advisor wizard for enabling or tuning on-demand rollback.

Parallel Rollback Is a Separate Feature

FAST_START_PARALLEL_ROLLBACK governs the maximum parallelism used for eligible terminated transaction recovery. Oracle documents FALSE, LOW, and HIGH, with LOW as the default. These settings concern parallel recovery, rather than switching automatic on-demand behavior on or off.

Parallel workers can help recover eligible workloads, particularly substantial unfinished parallel work. Additional concurrency is not a guarantee of proportional speedup. Storage throughput, available CPU, and the recovery workload determine whether more workers improve elapsed time or increase contention with the application.

Do not change the parallel rollback parameter merely because a request is waiting. Establish which recovery activity exists and which resource limits apply. The next lesson addresses parallel rollback configuration and monitoring in detail. This lesson focuses on the availability of accessed blocks while transaction recovery proceeds.

Monitor Parallel Recovery with the Correct Scope

The following is an illustrative read-only query for an administrator with access to the dynamic performance view. Run monitoring in the correct container and instance context; these examples are not results from a recovery performed for this lesson.

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

V$FAST_START_TRANSACTIONS shows transactions recovered in parallel. It does not display serial transaction recovery. The undo segment, slot, and sequence identify the transaction; state and undo-block counts describe reported progress. Do not treat the view as a complete ledger of every on-demand block recovery request.

An empty result means no rows were reported by this view in that observation. It does not prove all recovery has completed. Similarly, a recovered transaction row does not establish that every application operation has succeeded. Correlate monitoring with diagnostic records and affected application behavior.

Progress counts can support comparisons over time, but they do not establish a guaranteed finishing time. Recovery work and resource availability can vary during observation. If reporting a completion percentage, explain what it measures and avoid turning a block ratio into a precise outage forecast.

Distinguish Recovery from Ordinary Session Blocking

A blocked update is not automatically evidence of a dead transaction. A healthy application session may still hold a row lock because its transaction is active. In that case, treating the owner as terminated recovery work would be an incorrect diagnosis. The operational response must follow the actual session and transaction state.

SELECT sid, serial#, state, event,
       blocking_session_status,
       blocking_instance, blocking_session
FROM v$session
WHERE type = 'USER'
  AND state = 'WAITING';

EVENT describes a current or most recent wait, rather than identifying a SQL command named ROLLBACK. Interpret it together with STATE. Blocking-session identifiers are meaningful when BLOCKING_SESSION_STATUS is VALID; other status values require their documented interpretation. Missing or unknown blocker information is not proof that a transaction has finished.

A wait observation is a starting point for diagnosis. Establish whether the owner is live, what operation is waiting, and whether recovery evidence matches the incident timeline. Do not kill a session, change undo configuration, or restart an instance solely because a monitoring query returns a wait.

In RAC, retain instance identity and use appropriate global observations when the question spans instances. In a multitenant environment, retain container context as well. Session numbers without their associated context can lead an administrator to investigate the wrong workload.

Validate Availability in a Controlled Environment

A meaningful exercise tests application access rather than simply checking that a parameter has a value. Use a designated non-production environment and an approved failure procedure. Define the initial data, expected committed results, unfinished workload, and the operations that will access affected and unaffected blocks afterward.

For the inventory example, separate a committed adjustment from an unfinished batch adjustment. Record which product data each changes and the expected final values. After the planned recovery, check that committed work remains, unfinished changes are removed, and new work can obtain the data it needs under the documented consistency rules.

Record several milestones: recovery opening the database, first successful operation on affected data, observations of remaining parallel recovery where available, and completion of the representative business task. An unaffected query succeeding early cannot substitute for validation of the blocked application path.

Repeat observations under comparable conditions rather than assuming one run is a universal performance result. Different data placement, storage cache state, transaction size, and application concurrency can change the amount of work needed for a request. Label any measurements with their actual test conditions and preserve the records that support them.

The exercise should also include an ordinary live blocking transaction as a separate comparison. Its owner can still commit or roll back normally; automatic recovery of a terminated transaction is a different situation. Recognizing that difference prevents an availability feature from being used as an explanation for every lock wait.

Interpret the Business Result Carefully

Database availability and successful business processing are related but distinct. A connection can be established while some operations still need recovery processing. An application may also need to resolve the outcome of a request interrupted by the original failure. On-demand rollback handles unfinished database changes; it does not decide whether a client should repeat an uncertain business transaction.

For an order service, verify the order outcome before blindly resubmitting work after a disconnect. A transaction that committed before the failure must remain committed even if its acknowledgement did not reach the client. Application retry design and supported continuity mechanisms belong to the broader availability plan.

When communicating an incident, state which service operations are working, what remains affected, and what evidence supports those observations. Avoid claiming that background rollback is complete merely because the database is open or that the feature failed merely because one request waited.

Retain a concise validation record containing workload identity, instance and container context, recovery timeline, monitoring snapshots, application results, and unresolved conditions. This gives another administrator enough information to distinguish demonstrated behavior from assumptions and to compare a later incident fairly.

Apply the Lesson

The key administrative skill is recognizing automatic on-demand recovery and its limits. Explain why a requesting operation can benefit before complete transaction cleanup, why unrelated parameter changes are unnecessary, and why parallel recovery observations cannot prove the absence of serial recovery.

Continue with Fast-Start parallel rollback to examine the separate configuration choices that govern eligible parallel transaction recovery.

Oracle 26ai References