Thursday, January 8, 2026

Bequeath protocol usage in the 26ai for applications

Oracle 26ai Support for the Bequeath Protocol


Starting from Oracle AI Database Release 26ai, the JDBC thin driver supports the Bequeath protocol (BEQ) for applications running on Linux platforms, this protocol let applications, connect to Oracle database without Listener, however, other non-administrative users too can use this protocol.

To connect to the Database using the Bequeath Protocol, you must set the value of the ORACLE_HOME variable, so that the driver can locate the Oracle server process executable. 


Typically, the ORACLE_HOME variable points to the database installation location, that is,

 /var/lib/oracle/dbhome. 

You can reset the location in the following two ways:

  • In the connection URL
  • In the environment of the current application

The second mandatory variable, which you must enable, is the ORACLE_SID. Similar to setting the ORACLE_HOME variable, you can set the ORACLE_SID in the connection URL or in the current application environment. To establish a bequeath connection, the BEQ protocol must be enabled, which is the default setting in the authentication services property.

The following example shows how you can set the ORACLE_HOME variable and the ORACLE_SID in the connection URL:


jdbc:oracle:thin:@(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))

(ENVS=ORACLE_HOME=/var/lib/oracle/dbhome,ORACLE_SID=oraclesid))


JDBC OCI Driver or Type 2 Client Driver

You must use the JDBC OCI driver in your client-side Java applications only if your applications use any of the following features that are dependent on the platform-specific OCI libraries:

  • Bequeath protocol:This procol lets you use the local connections without going through the listener, which is typically used by the Database Administrators to perform various administrative operations; however, other non-administrative users too can use this protocol.
  • OS Authentication: The JDBC OCI driver supports OS Authentication on Linux when the client and the server are on the same computer. On Window domains, it supports OS Authentication even across multiple computers.
  • Transparent Application Failover (TAF): that supports failover of read transactions.


Requirements for enabling BEQ protocol for Clients and Applications:


--Adding BEQ to oracle configuration files:

Update the Oracle sqlnet.ora configuration file


authentication_services = (BEQ, TCPS, NONE)


Note: BEQ requires a local OS user.


• The BEQ protocol bypasses listener/TCP and directly spawns a database server process ($ORACLE_HOME/bin/oracle) on the same host.


• This means the JDBC application must run on the same Linux machine as the database instance.

• The OS user running the application must have permission to execute the Oracle binary (oracle) inside $ORACLE_HOME/bin. That’s why Oracle recommends setting restrictive permissions like chmod 750 $ORACLE_HOME/bin/oracle.

• No remote network user is involved — it’s strictly local process spawning.


Ensure $ORACLE_HOME/bin/oracle is executable by the local application user.

Example:

chmod 750 $ORACLE_HOME/bin/oracle


Connection String sample:


 jdbc:oracle:thin:@(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))

(ENVS=ORACLE_HOME=/var/lib/oracle/dbhome,ORACLE_SID=oraclesid))


Default BEQ Enablement:

BEQ is enabled by default in Oracle 26ai unless explicitly restricted.

• If security policies require disabling BEQ, you can:

• Remove BEQ from authentication_services.

• Add a logon trigger to block BEQ sessions for non-SYS/SYSTEM users.


Use this Trigger to preventing BEQ connections:


CREATE OR REPLACE TRIGGER block_beq_logon

AFTER LOGON ON DATABASE

BEGIN

  IF SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') = 'beq'

     AND SYS_CONTEXT('USERENV','SESSION_USER') NOT IN ('SYS','SYSTEM') THEN

    RAISE_APPLICATION_ERROR(-20001, 'BEQ connections are not allowed');

  END IF;

END;

/


Benefits of the Bequeath Protocol Solution


•Improved Performance of Local Connections

The primary benefit of using the Bequeath protocol is enhanced performance for applications running on the same machine as the Oracle database. By bypassing the network listener and network stack, the connection is established more directly and efficiently. 


Simplified Configuration: Since the Bequeath protocol does not require a network listener for local connections, the configuration is simplified. This can be particularly advantageous in development and testing environments. 


Resource Efficiency: By avoiding the network layer, the Bequeath protocol can lead to more efficient use of system resources for local database connections.


Why Oracle Introduced Bequeath Protocol Support in the JDBC Thin Driver

Oracle’s introduction of Bequeath protocol support in the JDBC thin driver for Release 26ai is a strategic move to enhance the capabilities and performance of Java applications running on the same host as the database. Here’s why this is a significant development:


•Alignment with Modern Application Architectures

Many modern application architectures, including microservices and containerized applications, often involve components running on the same host. Providing a high-performance, low-latency connection method for these scenarios is crucial.


•Completing the JDBC Thin Driver’s Capabilities: The JDBC thin driver is a pure Java, platform-independent driver that is widely used. Adding Bequeath protocol support makes it a more comprehensive solution, allowing it to handle both local and remote connections efficiently without requiring a different driver. 

•Deprecation of the JDBC OCI Driver: 

Oracle has deprecated the JDBC OCI (Type 2) driver in Oracle AI Database Release 26ai. The OCI driver was another way to achieve high-performance local connections. 

By incorporating Bequeath support into the thin driver, Oracle is providing a modern and preferred alternative for the functionality that will be lost with the OCI driver’s deprecation. 


Deprecated Features in 26ai


Deprecation of the JDBC OCI Driver

The JDBC OCI Driver or Type 2 Client Driver, is deprecated in Oracle AI Database Release 26ai. Most Java applications that use Open Database Connectivity (ODBC) with Oracle JDBC drivers use the Thin driver. To enable Oracle to allocate resources to better address customer requirements, Oracle is deprecating the JDBC-OCI driver.

Deprecation of Blob, Clob, and BFile Methods

Oracle is deprecating the methods open(), close(), and isClosed() in the interfaces oracle.jdbc.OracleBlob, oracle.jdbc.OracleClob, and oracle.jdbc.OracleBfile.


These methods are replaced with the openLob(), closeLob() and isClosedLob() methods. The method close() conflicts with the type java.lang.AutoCloseable. Removing the proprietary method close() makes it possible for OracleBlob, OracleClob, and OracleBfileinterfaces to extend the AutoCloseable interface at some future time. The open() and isClosed()methods will be removed and replaced to maintain rational names for these methods.


Same Machine Requirement and OS User needs 


Same Machine Requirement: Oracle database and the application using the Bequeath protocol must be on the same machine. The protocol is specifically designed for local inter-process communication and does not work over a network. 


•OS User dependency: The introduction of the Bequeath protocol support in the JDBC thin driver does not eliminate the need for an operating system user. The connection process still operates within the security context of the OS. In fact, to use the Bequeath protocol, you must set the `ORACLE_HOME` environment variable so that the driver can locate the Oracle server process executable, which underscores the reliance on the underlying OS and its user environment.


#############################

Friday, January 2, 2026

Oracle Listener Protocols

 Oracle Listener Protocols : 

BEQUEATH, IPC, TCP, TCPS, SDP and what changed in Oracle 26ai


When we talk about Oracle connectivity, we usually reduce everything to “the listener” and “port 1521”. But Oracle actually supports multiple connection protocols, each optimized for a different use case, performance, security, locality, or scale.


Understanding these protocols helps you design systems that are faster, safer, and easier to operate.


🔹 BEQUEATH (BEQ) — direct local attach

BEQUEATH is a local-only protocol that allows a client process to attach directly to a database server process without using the listener or the network.


Typical use:

• Local SQL*Plus

• Local RMAN

• DBA maintenance


• New in Oracle 26ai: JDBC Thin on Linux for local apps (wait for next post about this feature)


Characteristics:

• No listener

• No network

• Very fast

• Very secure

• Same host only


In Oracle 26ai, BEQ became available for JDBC Thin ; allowing Java applications running on the database host to avoid TCP and connect locally.


🔹 IPC — local communication through the listener

IPC is also local-only, but it still goes through the listener. It uses OS shared memory or pipes instead of the network.


Used for:

• Local scripts

• RMAN via listener

• External procedures (extproc)


Characteristics:

• Listener involved

• Local only

• Fast

• Isolated from network


🔹 TCP — standard network connectivity

TCP is the default protocol for remote access and distributed systems.


Used for:

• Application servers

• JDBC / ODP.NET

• Microservices

• RAC and Data Guard


Characteristics:

• Network based

• Flexible and universal

• Slightly higher latency

• Firewall-controlled


🔹 TCPS — encrypted TCP

TCPS is TCP with SSL/TLS encryption.


Used for:

• Regulated environments

• Zero-trust networks

• Internet-facing systems


🔹 SDP — ultra-low latency networking

Oracle Net Services provides support for the Sockets Direct Protocol (SDP) for InfiniBand high-speed networks.  

SDP is a standard communication protocol for clustered server environments. SDP is an interface between a network interface card and the application. By using SDP, applications place most of the messaging burden upon the network interface card, freeing the CPU for other tasks. As a result, SDP decreases network latency and CPU utilization. 

SDP is designed specifically for System Area Networks (SANs). A SAN is characterized by short-distance, high-performance communications between multiple server systems, such as Oracle WebLogic Server or any other third-party middle-tier client and database servers clustered on one switch.


When used over an InfiniBand network, SDP reduces TCP/IP overhead by eliminating intermediate replication of data and transferring most of the messaging burden away from the CPU and onto the network hardware.

SDP is used in high-performance environments using RDMA / InfiniBand.


Used for:

• HPC clusters

• Trading platforms

• Ultra-low latency systems



Another method to connection:

🔹Named Pipes Protocol

The Named Pipes protocol is a high-level interface providing interprocess communications between clients and database servers using distributed applications.

Named Pipes is specifically designed for Microsoft Windows LAN environments. 

One server-side process creates a named pipe, and the client-side process opens it by name. What one side writes, the other can read. 

If a remote Oracle database is running on a host system that supports network communication using Named Pipes, then Oracle Net enables applications on a client to communicate with the Oracle database using Named Pipes.


🔹Exadirect Protocol

The Exadirect protocol is an innovative protocol for low overhead database access. Use the new transport to improve latency and throughput by leveraging Remote Direct Memory Access (RDMA) in an InfiniBand environment.

Exadirect protocol uses TCP for control communication and IB RC transport for data.

The Exadirect protocol adapter is supported only on Oracle Linux in this release.


🔹Websocket Protocol

The Database client connection supports secure websocket protocol. The secure web socket connection establishment is designed to work over HTTPS, to support HTTPS proxies and intermediary proxies.

This protocol offers a native connection to the database with minimum protocol overhead. Secure websocket protocol is used to negotiate SQL*Net protocol during connection establishment between the database server and the client. The secure websocket protocol uses TLS and requires wallet for operation.

The Web server should support web socket tunneling. Web server proxy module (in case of Apache or Oracle HTTP Server (OHS), mod_proxy_wstunnel)) proxies the secure web socket database connection data between the client and the backend database server. The Database client connects using secure websocket protocol to Web server and the Web server connects to the database using websocket protocol.


🔹 Summary



Sqlnet :

authentication_services = (BEQ, TCPS, NONE)


🔹 Why this matters


Choosing the right protocol:

• Reduces attack surface

• Improves performance

• Simplifies networking

• Improves operational reliability


Small architectural decisions at the connectivity layer can have large operational impact at scale.


Bequeath protocol usage in the 26ai for applications

Oracle 26ai Support for the Bequeath Protocol Starting from Oracle AI Database Release  26ai , the JDBC thin driver supports the Bequeath pr...