Introduction to Blocker Resolver in Oracle 26ai

Introduction to Blocker Resolver in Oracle 26ai

Blocker Resolver is an Oracle Real Application Clusters (Oracle RAC) environment feature that autonomously resolves delays and keeps the resources available.

Enabled by default, Blocker Resolver:

• Reliably detects database delays and deadlocks
• Autonomously resolves database delays and deadlocks
• Logs all detections and resolutions
• Provides SQL interface to configure sensitivity (Normal/High) and trace file sizes

A database delays when a session blocks a chain of one or more sessions. The blocking session holds a resource such as a lock or latch that prevents the blocked sessions from progressing. The chain of sessions has a root or a final blocker session, which blocks all the other sessions in the chain. 

Blocker Resolver resolves these issues autonomously by detecting and resolving the delays.

• Blocker Resolver Architecture
  Blocker Resolver autonomously runs as a DIA0 task within the database.
• Optional Configuration for Blocker Resolver
  You can adjust the sensitivity, and control the size and number of the log files used by Blocker Resolver.
• Blocker Resolver Diagnostics and Logging
  Blocker Resolver autonomously resolves delays and continuously logs the resolutions in the database alert logs and the diagnostics in the trace files.

Blocker Resolver Architecture

Blocker Resolver autonomously runs as a DIA0 task within the database.

Blocker Resolver works in the following three phases:

• Detect: In this phase, Blocker Resolver collects the data on all the nodes and detects the sessions that are waiting for the resources held by another session. 
• Analyze: In this phase, Blocker Resolver analyzes the sessions detected in the Detect phase to determine if the sessions are part of a potential delay. If the sessions are suspected as delayed, Blocker Resolver then waits for a certain threshold time period to ensure that the sessions are delayed.
• Verify: In this phase, after the threshold time period is up, Blocker Resolver verifies that the sessions are delayed and selects a session that's causing the delay.

After selecting the session that's causing the delay, Blocker Resolver applies resolution methods on that session. 

If the chain of sessions or the delay resolves automatically, then Blocker Resolver does not apply delay resolution methods. 

However, if the delay does not resolve by itself, then Blocker Resolver resolves the delay by terminating the session that's causing the delay. If terminating the session fails, then Blocker Resolver terminates the process of the session. This entire process is autonomous and does not block resources for a long period and does not affect the performance.

For example, if a high rank session is included in the chain of delayed sessions, then Blocker Resolver expedites the termination of the session that's causing the delay. 

Termination of the session that's causing the delay prevents the high rank session from waiting too long and helps to maintain performance objective of the high rank session.

Optional Configuration for Blocker Resolver

You can adjust the sensitivity, and control the size and number of the log files used by Blocker Resolver.

Note:

The DBMS_HANG_MANAGER package is deprecated in Oracle AI Database 26ai. Use DBMS_BLOCKER_RESOLVER instead. The DBMS_HANG_MANAGER package provides a method of changing some configuration parameters and constraints to address session issues. 

This package is being replaced with DBMS_BLOCKER_RESOLVER.DBMS_HANG_MANAGER can be removed in a future release.

Sensitivity:

If Blocker Resolver detects a delay, then Blocker Resolver waits for a certain threshold time period to ensure that the sessions are delayed. Change threshold time period by using DBMS_BLOCKER_RESOLVER to set thesensitivity parameter to either Normal or High. If the sensitivity parameter is set to Normal, then Blocker Resolver waits for the default time period. However, if the sensitivity is set to High, then the time period is reduced by 50%.

By default, the sensitivity parameter is set toNormal. To set Blocker Resolver sensitivity, run the following commands in SQL*Plus as SYS user:

• To set the sensitivity parameter toNormal:
  
  exec dbms_blocker_resolver.set(dbms_blocker_resolver.sensitivity, dbms_blocker_resolver.sensitivity_normal);
  
  
• To set the sensitivity parameter toHigh:
  
  exec dbms_blocker_resolver.set(dbms_blocker_resolver.sensitivity, dbms_blocker_resolver.sensitivity_high);
  
  

Size of the Trace Log File:

The Blocker Resolver logs detailed diagnostics of the delays in the trace files with _base_ in the file name. Change the size of the trace files in bytes with the base_file_size_limit parameter. Run the following command in SQL*Plus, for example, to set the trace file size limit to 100 MB:

exec dbms_blocker_resolver.set(dbms_blocker_resolver.base_file_size_limit, 104857600);

Number of Trace Log Files

The base Blocker Resolver trace files are part of a trace file set. Change the number of trace files in trace file set with the base_file_set_count  parameter. Run the following command in SQL*Plus, for example, to set the number of trace files in trace file set to 6:

exec dbms_blocker_resolver.set(dbms_blocker_resolver.base_file_set_count,6);

By default, base_file_set_count parameter is set to 5.

Blocker Resolver Diagnostics and Logging

Blocker Resolver autonomously resolves delays and continuously logs the resolutions in the database alert logs and the diagnostics in the trace files.

Blocker Resolver logs the resolutions in the database alert logs as Automatic Diagnostic Repository (ADR) incidents with incident code ORA–32701. 

You also get detailed diagnostics about the delay detection in the trace files. 

Trace files and alert logs have file names starting with database instance_dia0_.

• The trace files are stored in the $ ADR_BASE/diag/rdbms/database name/database instance/incident/incdir_xxxxxxdirectory
• The alert logs are stored in the $ ADR_BASE/diag/rdbms/database name/database instance/tracedirectory

Example: Blocker Resolver Trace File for a Local Instance

This example shows an example of the output you see for Blocker Resolver for the local database instance

Trace Log File .../oracle/log/diag/rdbms/hm1/hm11/incident/incdir_111/hm11_dia0_11111_i111.trc

Oracle Database 19c Enterprise 64bit 

...

*** 2025-05-16T12:39:02.715475-07:00

HM: Hang Statistics - only statistics with non-zero values are listed

current number of active sessions 3

current number of hung sessions 1

instance health (in terms of hung sessions) 66.67%

number of cluster-wide active sessions 9

number of cluster-wide hung sessions 5

cluster health (in terms of hung sessions) 44.45%

*** 2025-05-16T12:39:02.715681-07:00

Resolvable Hangs in the System

 Root       Chain Total      Hang Hang Hang          Inst Root  #hung #hung  Hang   Hang  Resolution

ID Type Status   Num  Sess   Sess  Sess  Conf   Span  Action

  ----- ---- -------- ---- ----- ----- ----- ------ ------ --------

1 HANG RSLNPEND    3    44     3     5   HIGH GLOBAL Terminate Process

Hang Resolution Reason: Although hangs of this root type are typically

 self-resolving, the previously ignored hang was automatically resolved.

Example: Error Message in the Alert Log Indicating a Delayed Session

This example shows an example of a Blocker Resolver alert log on the primary instance

2025-07-16T12:39:02.616573-07:00

Errors in file .../oracle/log/diag/rdbms/hm1/hm1/trace/hm1_dia0_i1111.trc  (incident=1111):

ORA-32701: Possible hangs up to hang ID=1 detected

Incident details in: .../oracle/log/diag/rdbms/hm1/hm1/incident/incdir_1111/hm1_dia0_11111_i1111.trc

2025-07-16T12:39:02.674061-07:00

DIA0 requesting termination of session sid:44 with serial # 23456 (ospid:34569) on instance 3

due to a GLOBAL, HIGH confidence hang with ID=1.

Hang Resolution Reason: Although hangs of this root type are typically self-resolving, the previously ignored hang was automatically resolved.

DIA0: Examine the alert log on instance 3 for session termination status of hang with ID=1.

Example: Error Message in the Alert Log Showing a Session Delay Resolved by Blocker Resolver

This example shows an example of a Blocker Resolver alert log on the local instance for resolved delays

2025-07-16T12:39:02.707822-07:00

Errors in file .../oracle/log/diag/rdbms/hm1/hm11/trace/hm11_dia0_11111.trc  (incident=169):

ORA-32701: Possible hangs up to hang ID=1 detected

Incident details in: .../oracle/log/diag/rdbms/hm1/hm11/incident/incdir_169/hm11_dia0_30676_i169.trc

2025-07-16T12:39:05.086593-07:00

DIA0 terminating blocker (ospid: 30872 sid: 44 ser#: 23456) of hang with ID = 1

requested by master DIA0 process on instance 1

Hang Resolution Reason: Although hangs of this root type are typically

self-resolving, the previously ignored hang was automatically resolved.

by terminating session sid:44 with serial # 23456 (ospid:34569)

...

DIA0 successfully terminated session sid:44 with serial # 23456 (ospid:34569) with status 0.

---------------------

Alireza Kamrani 

RDBMS Solution Architect

A strong technical review on Oracle Bigfile Tablespace

 A strong technical review on Oracle Bigfile Tablespace
and exploring the challenges & Concerns for DBAs

Bigfile Tablespaces in Oracle:

Oracle Database enables the creation of bigfile tablespaces.

A bigfile tablespace consists of a single data or temporary file which can be up to 128 TB. The use of bigfile tablespaces can significantly reduce the number of data files for your database. Oracle Database supports parallel RMAN backup and restore on single data files.

Consequently, there is no disadvantage to using bigfile tablespaces and you may choose to use bigfile tablespaces to significantly reduce the number of data and temporary files.

v  File allocation is a serial process. If you use automatic allocation for your tables and automatically extensible data files, then a large data load can be impacted by the amount of time it takes to extend the file, regardless of whether you use bigfile tablespaces. However, if you preallocate data files and you use multiple data files, then multiple processes are spawned to add data files concurrently.

An Oracle Bigfile tablespace is a special tablespace that contains only one extremely large datafile (up to 128 TB), offering benefits like significantly increased storage capacity, simplified management by reducing the number of datafiles, and datafile transparency where operations can be performed on the tablespace rather than individual datafiles. Bigfile tablespaces are ideal for large databases and work best with technologies like Oracle ASM or other logical volume managers that support dynamic volume resizing.

Benefits of Bigfile Tablespaces

• Increased Storage Capacity:

By using a single, very large datafile instead of many smaller ones, bigfile tablespaces can dramatically increase the maximum storage capacity of an Oracle Database. 

• Simplified Management:

With only one file to manage per tablespace, database administration becomes simpler, especially for ultra-large databases. 

• Datafile Transparency:

You can perform operations like backup, restore, and resize on the entire tablespace, rather than having to manage individual datafiles. 

·         Reduced Control File and SGA Overhead:

Bigfile tablespaces reduce the amount of information the database needs to track for datafiles, decreasing the size of the control file and the space required in the System Global Area (SGA). 

• Parallel RMAN Backup and Restore:

Oracle supports parallel operations for RMAN (Recovery Manager) backup and restore on the single, large datafile of a bigfile tablespace. 

Considerations

• Compatibility with Logical Volume Managers:

Bigfile tablespaces are designed to be used with systems like Oracle ASM or other logical volume managers that can provide dynamically extensible logical volumes, striping, and RAID capabilities. 

• Multisection Backups:

For very large bigfile tablespaces, the ability to create multisection backups using multiple channels to read sections of the single large datafile can improve performance. 

• Default Behavior in Recent Versions:

In recent Oracle versions (such as Oracle 23ai), bigfile tablespaces are often the default for newly created tablespaces, simplifying management of large databases. 

In essence, bigfile tablespaces are a key feature for handling very large amounts of data efficiently by reducing the complexity of file management and increasing the potential scale of Oracle databases. 

 

Oracle Bigfile VS Small file Tablespace

As an Oracle DBA, usually you select which model in Production env? 

Do you have concerns about the Bigfile model?

In Oracle, Bigfile Tablespace (BFTS) vs Smallfile Tablespace (SFTS) is mostly a management and architecture decision, not a raw performance feature.

Let’s break it down:

Advantages of Bigfile Tablespace

• Fewer Datafiles → Easier management in databases with thousands of tablespaces (no need to manage hundreds of small files).
• Supports very large databases → One datafile can go up to 128TB (depending on block size and OS).
• ASM / OMF integration → Works best with Automatic Storage Management (ASM) or Oracle Managed Files, where the file system limits (e.g., max files per volume) might be a concern.
• Online resize → You can resize a single file easily instead of managing multiple small ones.

 

 Potential Disadvantages / Challenges:

1. Backup & Recovery

• With RMAN, a single very large file means if corruption hits the file header or file gets damaged, you deal with the entire multi-terabyte file, not just a 10–50 GB chunk although Section Size parameter in RMAN can be used.
• Incremental backups mitigate this (RMAN tracks block changes), but initial backups and restores are still heavy.

2. I/O Performance Concerns

• Oracle accesses blocks, not files → so in theory, no performance penalty.
• But in practice, on some storage subsystems, very large files may lead to:
• OS-level limits (metadata, extent maps).
• Suboptimal striping on some legacy filesystems.
• Modern ASM / SAN / Exadata generally eliminates this concern.

3. Tablespace Operations

• If you need to move a bigfile tablespace (e.g., to another storage system), you have to move a huge file in one piece. With smallfiles, you can parallelize movement of multiple files.

 

4. Compatibility / Administration

• Some 3rd-party tools (older backup agents, monitoring, etc.) don’t handle multi-terabyte single files well.
• DBA "comfort level" → many DBAs prefer multiple files for granularity and flexibility.

5. Flashback / Recovery Time

• During recovery, handling one huge file may be slower than parallel recovery of multiple smaller datafiles.
• If corruption affects one portion of a BFTS, you may be forced to recover the entire file.

 Practical Considerations:

• On Exadata / ASM / OMF → Bigfile is safe and often recommended, since the storage layer takes care of striping, balancing, and performance.
• On traditional file systems or non-ASM storage → many DBAs stick with Smallfiles for backup/recovery granularity and manageability.
• Hybrid approach → use BFTS for large objects (e.g., data warehouse fact tables, staging) and SFTS for OLTP / critical smaller workloads.

Rule of Thumb:

• OLTP systems with mixed workloads → Smallfile may still be better for more granular backup and restore, but the performance impact such as I/O is almost the same in both.
• DW / DWH / Exadata / ASM-managed databases → Bigfile is fine (and often preferred).
• If unsure → default to Smallfile unless you have a strong storage/management reason to choose Bigfile.

 

Are you have any other concerns about using Bigfile tablespace:

Oracle Database does not treat Bigfile Tablespaces differently from Smallfile Tablespaces in terms of I/O performance.

• Oracle reads and writes at the block level, not at the file level.

·         Whether those blocks live in fileA.dbf (100 GB smallfile) or in fileB.dbf (5 TB bigfile) makes no difference to the optimizer, buffer cache, or physical I/O operations.

• The extent and segment management inside the tablespace is identical — same bitmap, same freelists, same algorithms.

When There Is No Performance Issue

• Oracle kernel I/O path → No penalty. The database engine issues I/O requests per block/extent.
• ASM / Exadata / modern SAN → These automatically stripe data across disks, so even one bigfile gets spread evenly.
• RMAN incremental backups → Only changed blocks are backed up, regardless of file size.

Where Performance Problems Might Appear:

Not because of Oracle, but because of the underlying OS / storage:

• Legacy filesystems → Some OSs have inefficient file extent maps when file size is multi-TB. This can slow metadata operations (open, extend, checkpoint scanning).
• Backup / restore throughput → Copying or recovering one 5 TB file might be slower than handling 50×100 GB files in parallel.
• Corruption recovery granularity → With smallfiles, you might restore only one 100 GB file; with a bigfile, you must restore the entire multi-TB file, even if only a tiny portion was affected.

Bottom line for DBAs:

• I/O performance is the same → Oracle does not penalize Bigfile vs Smallfile.
• The concern is not I/O speed but operational flexibility (backup, recovery, corruption handling, file movement).
• That’s why many DBAs feel safer with Smallfiles, even though the engine performs equally well.

 Datafile Limits with Smallfile Tablespaces

• Each Smallfile Tablespace (SFTS) can have up to 1,022 datafiles (on most platforms).
• Each datafile can be up to 32 GB × block size (so with 8K block size → ~32 TB per tablespace).
• If your database grows very large, you may end up with thousands of datafiles across all tablespaces.

This stresses:

• Control file size (Oracle must track all file headers).
• SPFILE/PFILE parameters (e.g., DB_FILES), which sets the upper limit of total datafiles the DB can open.
• Startup overhead (Oracle must scan all file headers).
• Backup/restore catalog size (RMAN has to track each file individually).

 

Bigfile Tablespaces Avoid This

• A Bigfile Tablespace has only one datafile.
• That file can grow up to 128 TB (8K block size with 32-bit file header) or more with 64-bit headers.
• DB_FILES limit becomes less relevant, since you need only a handful of very large files instead of thousands of small ones.

 

 Trade-off:

• Smallfiles → more granularity in recovery, but risk of hitting DB_FILES and control file bloat.
• Bigfiles → reduce file count dramatically, but one file can be “too big to fail” (restore/repair impact).

 

• If using ASM or Exadata → BFTS is often preferred, since storage spreads I/O automatically but backup recovery and Recovery time objective (RTO) can lead to use Smallfile.
• If using traditional file systems → be mindful of OS file size limits; sometimes many smallfiles are safer.
• For very large databases (VLDBs) → Bigfile is a practical solution to avoid DB_FILES hitting the ceiling.
• DB_FILES parameter → you can increase it (up to 65,533 depending on platform), but this increases controlfile size and memory usage.
• From Oracle database 26ai onward we can use the DBMS_SPACE package to shrink a bigfile tablespace to reclaim unused space.

 

Alireza Kamrani

Oracle Solutions Advisor, ACE Pro

Configuring RMAN to Make Backups to Recovery Appliance

Configuring RMAN to Make Backups to Recovery Appliance in Oracle AI

RMAN commands can be used to back up target databases to Zero Data Loss Recovery Appliance.

This section describes the configuration steps required to backup a target database to Recovery Appliance using RMAN.
• Prerequisites for Using Recovery Appliance
• Setting Up the Recovery Appliance Backup Module
• Configuring SBT Channel for RMAN Backups to Recovery Appliance

Prerequisites for Using Recovery Appliance
Review the prerequisites to backup a target database to Zero Data Loss Recovery Appliance(ZDLR).

• Set up the Recovery Appliance backup module on the target database server.
The backup module setup file (ra_installer.zip) is located in the ORACLE_HOME/lib directory of the target database.


The Recovery Appliance backup module creates the Oracle wallet containing credentials used to authenticate the target database with Recovery Appliance.

• RMAN requires the system backup to tape (SBT) channel to perform cloud backup and recovery operations. Use the CONFIGURE command to create an automatic SBT channel. Use the SBT_LIBRARY parameter to specify the media library that enables RMAN to communicate with the Recovery Appliance backup module.

Note:
An automatic SBT channel creates a persistent default SBT device setting that applies to all backup and recovery operations. Alternatively, you can use the ALLOCATE CHANNEL  command to manually allocate a one-time SBT channel before each backup or restore operation.

🧣 Starting in Oracle Database 19c Release Update version 27 (19.27), Oracle provides native SBT libraries for RMAN backup and recovery operations with Recovery Appliance.

• On UNIX/Linux systems, the Recovery Appliance SBT library libra.so is located in the $ORACLE_HOME/lib directory.
• On Windows systems, the Recovery Appliance SBT library orara.dll is located in the %ORACLE_HOME%\bin directory.

🎩 Starting in Oracle Database 19c Release Update version 28 (19.28), oracle.zdlra is the alias name for the Recovery Appliance native SBT library.

When you configure the RMAN SBT channel for backups to Recovery Appliance, specify the SBT_LIBRARY alias oracle.zdlra (recommended), or provide the absolute path to the SBT_LIBRARY file: $ORACLE_HOME/lib/libra.so on UNIX/Linux systems or %ORACLE_HOME%\bin\orara.dll on Windows systems.

Run the backup module installer to set up the authentication required for RMAN to access Recovery Appliance. You must use the SBT library included with the patch instead of downloading the library while running the installer.

Setting Up the Recovery Appliance Backup Module
The Recovery Appliance backup module is an Oracle-supplied media management library that enables RMAN to perform backup and restores with Recovery Appliance.


Starting with Oracle Database 19c Release Update version 27 (19.27), the Recovery Appliance backup module setup file (ra_installer.zip) is located in the $ORACLE_HOME/lib directory of the target database.


Note:
For Oracle Database 19c Release Update version 26 (19.26) and earlier versions, download the operating system-specific Recovery Appliance backup module from My Oracle Support Patch Number 37855779.

Run the backup module installer to set up the authentication required for RMAN to access Recovery Appliance. You must use the SBT library included with the patch instead of downloading the library while running the installer.

• Extract the ra_installer.zip file to a subdirectory of your choice. In this example, you extract the setup files to the ramodule subdirectory.

$ mkdir -p $ORACLE_HOME/lib/ramodule
$ cd $ORACLE_HOME/lib/ramodule
unzip -q $ORACLE_HOME/lib/ra_installer.zip

• On the target database server, go to the directory where you have extracted the Recovery Appliance backup module setup files.
In this example, you navigate to the ramodule subdirectory which contains the ra_install.jar file and the README file ra_readme.txt.

$ cd $ORACLE_HOME/lib/ramodule

• Run this command to preview the parameters required to run the Recovery Appliance backup module.

$ java -jar ra_install.jar

Compile the values for the parameters.

• Run the ra_install.jar file by specifying the parameters and values.

Configuring SBT Channel for RMAN Backups to Recovery Appliance
Configure an automatic SBT channel so that RMAN can directly send backups to Recovery Appliance.
When you configure the SBT channel, you must specify the native SBT library that corresponds to Recovery Appliance, and specify the location of the client configuration file stored on the protected database.

The configuration file contains the configuration settings that are used by the Recovery Appliance backup module to communicate with the Recovery Appliance. This configuration file is created when you set up the Recovery Appliance backup module.

• Start RMAN and connect to the target database.
• Use the CONFIGURE command to preconfigure an automatic SBT channel. Use the SBT_LIBRARY parameter to specify the library alias oracle.zdlra. You can optionally specify the native SBT library path instead of the library alias.
• Use the ENV parameter (UNIX and Linux) or the SBT_PARMS parameter (Windows) to directly specify the client configuration parameters for Recovery Appliance.

The client configuration file must contain the location of the Oracle wallet that stores the credentials required to authenticate the target database with Recovery Appliance. Other optional settings may be included.

Note:
On Windows platforms, Oracle recommends that you use the SBT_PARMS parameter to specify the environment variables, instead of the ENV parameter.

Example: Specifying Recovery Appliance Client Configuration Settings

The following command (suggested on LINUX and UNIX platforms) specifies the Recovery Appliance client configuration settings directly as part of the CONFIGURE CHANNEL command:

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARAMS 'SBT_LIBRARY= oracle.zdlra, ENV=(BA_WALLET=location=file:/home/oracle/product/19.28.0/dbhome_1/wallet credential_alias=ra-scan:1521/zdlra5:dedicated)';


The following command (suggested on Windows platforms) specifies the Recovery Appliance client configuration settings directly as part of the CONFIGURE CHANNEL command:

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARAMS 'SBT_LIBRARY= oracle.zdlra, SBT_PARMS=(BA_WALLET=location=file:/home/oracle/product/19.28.0/dbhome_1/wallet credential_alias=ra-scan:1521/zdlra5:dedicated)';

In this example, oracle.zdlra is the native SBT library that corresponds to the Recovery Appliance backup module. ra-scan is the SCAN of the Recovery Appliance and zdlra5 is the service name of the Recovery Appliance metadata database.


Alireza Kamrani

Oracle Technical Solutions Advisor
ACE Pro