Fast-Start Parallel Rollback

While "Fast-Start" is a key part of Oracle's parallel rollback process, it's not a feature you directly "implement" yourself. Oracle automatically uses Fast-Start when necessary during instance recovery to expedite rollback of uncommitted transactions. Here's a breakdown of parallel rollback and the role of Fast-Start:
Parallel Rollback in Oracle:

• Purpose: When an Oracle instance recovers from a crash, it needs to undo uncommitted transactions. Parallel rollback speeds up this process by using multiple server processes to concurrently roll back transactions.
• Mechanism: The SMON background process acts as the coordinator, identifying uncommitted transactions and assigning them to available server processes. Each server process then rolls back its assigned transactions in parallel.

Fast-Start Feature:

• Role in Rollback: Fast-Start enables efficient identification of uncommitted transactions. Instead of scanning the entire undo segment sequentially, it uses dedicated data structures for faster transaction identification, significantly reducing the initial overhead of parallel rollback.
• Automatic Activation: You don't need to specifically configure Fast-Start. It's enabled by default in Oracle 19c and automatically invoked during instance recovery when parallel rollback is triggered.

Key Points:

• You don't directly "implement" Fast-Start, it's an internal mechanism used by Oracle for parallel rollback.
• Parallel rollback automatically activates when necessary during instance recovery.
• You can monitor and adjust parallel rollback settings like the degree of parallelism (number of server processes) using database parameters.

While you can't directly use Fast-Start independently, understanding its role in parallel rollback can help you optimize your instance recovery process by adjusting relevant parameters like the degree of parallelism.

More processes mean better performance. This is the main theme behind "Fast-Start parallel rollback". Oracle background processes coordinate and roll back a set of transactions by using multiple server processes. Whenever a large number of transactions (like INSERT, UPDATE, and DELETE statements) have not been committed, Fast-Start parallel rollback becomes very important.
When the System Monitor process realizes that a large number of transactions must be rolled back, and it is faster to roll back in parallel than serially, the System Monitor starts multiple server processes, rolling back the transactions. Each server process handles one transaction and the performance is improved.

• One Transaction divided among several Processes
  Fast-start parallel rollback has a special feature called intra-transaction recovery^[1], whereby a single transaction is divided among several processes. This happens when one transaction is large, meaning it takes longer for one process to roll this transaction back than for the other processes to roll back their transactions. Oracle automatically begins intra-transaction recovery by dispersing the large transaction among the processes. Setting the parameter FAST_START_PARALLEL_ROLLBACK to one of the following three values controls the number of processes involved in transaction recovery:
  1. FALSE: Turns off Fast-Start parallel rollback
  2. LOW: Specifies that the number of recovery servers may not exceed twice the value of the CPU_COUNT parameter
  3. HIGH: Specifies that the number of recovery servers may not exceed four times the value of the CPU_COUNT: parameter
  
  An instance is recovered using RMAN, by issuing the RECOVER command. This is called “Fast-Start-parallel rollback,” and you must define the degree of parallelism while issuing the command.

Here is a modernized version of the script updated for compatibility with Oracle 11g and Oracle 19c. The changes include:

1. Deprecations: Parameters like log_checkpoint_interval, db_block_buffers, and sort_area_size are deprecated in newer versions of Oracle. They have been replaced or removed.
2. Updated compatible parameter: Set to 11.2.0 or 19.0.0 for Oracle 11g or 19c, respectively.
3. New Parameters: Adjusted some parameters to reflect modern recommendations (e.g., pga_aggregate_target and sga_target instead of manual memory allocation).
4. File path adjustments: Used consistent path separators (/) as modern Oracle typically uses Unix-like paths, even on Windows.

Modernized Script

db_name = pets
instance_name = pets
service_names = pets
db_files = 1024
control_files = ('D:/Oracle/oradata/pets/control01.ctl')
db_file_multiblock_read_count = 16
memory_target = 1G
memory_max_target = 2G
processes = 150
parallel_max_servers = 16
log_buffer = 10485760
global_names = true
background_dump_dest = D:/Oracle/admin/pets/bdump
user_dump_dest = D:/Oracle/admin/pets/udump
core_dump_dest = D:/Oracle/admin/pets/cdump
audit_file_dest = D:/Oracle/admin/pets/adump
db_block_size = 8192
remote_login_passwordfile = exclusive
job_queue_processes = 4
open_links = 10
distributed_transactions = 16
dispatchers = '(PROTOCOL=TCP)(SERVICE=petsXDB)'
compatible = 19.0.0
log_archive_dest_1 = 'LOCATION=D:/Oracle/oradata/pets/archive'
log_archive_dest_2 = 'SERVICE=stby REOPEN=10'
log_archive_format = 'pets_%t_%s_%r.arc'
pga_aggregate_target = 500M
sga_target = 1G
undo_tablespace = UNDO_TBS
undo_retention = 900
recyclebin = ON
audit_trail = DB
FAST_START_PARALLEL_ROLLBACK = LOW

Explanation of Changes

1. memory_target and memory_max_target:
   • Simplifies memory management by using Automatic Memory Management (AMM).
   • You can remove these and configure pga_aggregate_target and sga_target individually if AMM is not required.
2. compatible:
   • Updated to 19.0.0 for Oracle 19c or 11.2.0 for Oracle 11g.
3. pga_aggregate_target and sga_target:
   • Modern memory management parameters replacing manual configurations like sort_area_size.
4. log_checkpoint_interval:
   • Removed because it is deprecated; log_checkpoint_timeout is sufficient.
5. dispatchers:
   • Updated syntax for shared server configuration.
6. undo_tablespace and undo_retention:
   • Added for undo management, which is required in modern versions of Oracle.
7. Audit parameters:
   • Added audit_file_dest and audit_trail for compliance with modern auditing standards.
8. recyclebin:
   • Enabled to use Oracle's recycling bin for dropped objects.

The following illustration is an example of an initialization parameter file (INIT.ORA). Based on this information you will need to determine the parameter setting for Fast-Start-parallel rollback: false, low, or high. Click the View Image button to see the illustration.
The value assigned is LOW. By using this value, the number of processes created to perform parallel rollback will be twice the number of CPU’s within the host machine containing the database. If there are 4 CPU's within the host machine, the number of processes that will be created is 8.
Afer adding the parameter within INIT.ORA, shut down and restart the database for the parameters to take effect. Implementing this parameter within the database instance ensures faster recovery of non-committed transactions.
FAST_START_PARALLEL_ROLLBACK

Property	Description
Parameter type	String
Syntax	FAST_START_PARALLEL_ROLLBACK = { HI | LO | FALSE }
Default value	LOW
Modifiable	ALTER SYSTEM
Basic	No

FAST_START_PARALLEL_ROLLBACK specifies the degree of parallelism used when recovering terminated transactions. Terminated transactions are transactions that are active before a system failure. If a system fails when there are uncommitted parallel
DML or DDL transactions, then you can speed up transaction recovery during startup by using this parameter. Values:

1. FALSE- Parallel rollback is disabled
2. LOW- Limits the maximum degree of parallelism to 2 * CPU_COUNT
3. HIGH - Limits the maximum degree of parallelism to 4 * CPU_COUNT

If you change the value of this parameter, then transaction recovery will be stopped and restarted with the new implied degree of parallelisme.
The next lesson explains how to set up an automated standby database.

[1]intra-transaction recovery: Intra-transaction recovery is a feature of Oracle backups that allows you to recover a database to a consistent point in time, even if a transaction was in progress when the backup was started. This is done by using a combination of redo logs and database snapshots.