Features of the Connection Manager

Oracle Connection Manager is a session level proxy available as part of Oracle Enterprise Edition, and it remains a current, supported component of Oracle Net Services in Oracle AI Database 26ai. It screens client connection requests and forwards the ones it allows on to a database or to another Connection Manager, building on the listener, CMGW, and CMADMIN roles covered in the previous lesson.

The features that make that screening and forwarding useful in a production network are, at a glance:

• Access control, through rule based filtering in cman.ora
• Session multiplexing, which funnels many client sessions through fewer physical database connections
• TLS support, so clients can reach the database over an encrypted connection
• Compression, to reduce the amount of data moving across the network
• Bandwidth control, to cap throughput per service
• Traffic Director Mode, for proxy based connection pooling
• Administration through CMCTL, now including a REST interface

Each of these is worth examining on its own.

Access Control

Access control rules live in the cman.ora file's RULE_LIST, where each RULE filters connections by source host (SRC), destination host (DST), and service name (SRV), resolving to accept, reject, or drop. A rule list looks like this:

(RULE_LIST=
  (RULE=
    (SRC=client1-pc)
    (DST=sales-server)
    (SRV=sales.us.example.com)
    (ACT=reject))
  (RULE=
    (SRC=192.0.2.45)
    (DST=192.0.2.200)
    (SRV=db1)
    (ACT=accept)))

If no rules are specified at all, every connection is rejected by default, and the rule list needs at least one rule covering client connections and one covering CMCTL connections or all connections of the omitted type are rejected.

Rules can also be organized with the GROUP parameter inside a RULE_GROUP section, which lets you attach a separate rule list to each service name rather than maintaining one long flat list:

(RULE_GROUP=
  (GROUP=
    (DESCRIPTION=(NAME=sales.us.example.com))
    (RULE_LIST=
      (RULE=(SRC=client1-pc)(DST=sales-server)(SRV=*)(ACT=reject))))
  (GROUP=
    (DESCRIPTION=(NAME=hr.us.example.com))
    (RULE_LIST=
      (RULE=(SRC=192.0.2.45)(DST=192.0.2.200)(SRV=*)(ACT=accept)))))

A related, separate control governs which databases are allowed to register themselves with CMAN in the first place: VALID_NODE_CHECKING_REGISTRATION, which defaults to on. With the default setting, only local IP addresses may register their services with CMAN unless you explicitly add remote nodes to REGISTRATION_INVITED_NODES, or block specific nodes with REGISTRATION_EXCLUDED_NODES. A third setting, subnet, extends the default behavior to every machine on the local subnet rather than just the local host. This is a different checkpoint than the RULE_LIST access control rules: RULE_LIST governs which clients can connect through CMAN, while valid node checking registration governs which databases can register with CMAN at all.

Session Multiplexing

CMGW funnels many client sessions through a single existing transport connection to a server rather than opening a new physical connection for every client, which is what cuts the number of connections the database server has to maintain. By running multiple Connection Managers, it becomes possible for thousands of concurrent users to connect to a server without a proportional increase in the connections the database itself has to track.

Older course material and older Oracle documentation called this capability "connection concentration," a term that was retired after the Net8 and Oracle 8i era, as covered in the first lesson of this module. This lesson uses session multiplexing throughout for that reason, and the architecture diagram below, which previously illustrated this section under that older name, illustrates the same request path under its current terminology.

TLS and Secure Connections

Clients can reach the database through CMAN over TCPS, Oracle Net's TLS secured transport. CMAN can listen on multiple protocol addresses at once, which in practice means it can offer a TCPS endpoint to internet facing clients while connecting onward to the database over plain TCP, keeping internal servers off the public network entirely. If CMAN already has a TCPS connection open to the destination a client is requesting, it multiplexes the new connection request onto that existing one rather than opening a second one.

One change is worth flagging for anyone securing a CMAN deployment on Oracle AI Database 26ai specifically: TLS protocol versions 1.0 and 1.1 are desupported, and the older SSLv3 protocol is no longer supported for database server to client connections at all. TLS 1.3 is the newly introduced, most secure option, and in most environments the client and server simply negotiate the strongest protocol available without any configuration change required. If a CMAN configuration still specifies TLS 1.0 or 1.1 explicitly, that setting needs to be removed or replaced with TLS 1.2, TLS 1.3, or both.

Compression and Larger Packets

CMAN can compress network traffic to improve throughput, controlled by three parameters: COMPRESSION turns it on or off, COMPRESSION_LEVELS chooses between a low CPU, low ratio setting and a high CPU, high ratio setting, and COMPRESSION_THRESHOLD sets the minimum data size, 1024 bytes by default, below which compression is skipped entirely since it would not be worth the overhead.

Compression is negotiated between any two adjacent nodes in the chain, and when more than two consecutive nodes all support it, an intermediate node simply relays the already compressed data to the next node without decompressing and recompressing it. Notably, compression between CMAN and the database server works even when the client itself predates Oracle Database 12c and cannot support compression on its own leg of the connection. CMAN also supports a session data unit, or SDU, of up to 2 MB, letting client and server negotiate a larger SDU than they could without CMAN in the path; when the client, server, and CMAN are configured with different SDU values, the smallest of the three is what actually gets used.

Bandwidth Control

CMAN can cap the throughput of all connections to a given service using the BANDWIDTH parameter, specified in bytes per second, for example BANDWIDTH=524288 to cap a service at 512 KB per second. This parameter requires the companion MAX_BANDWIDTH_GROUP parameter to be set as well, which specifies the maximum number of services the bandwidth feature can be configured for and must be sized with some headroom if services are created and destroyed frequently in the environment.

Traffic Director Mode

With the cman.ora parameter TDM set to TRUE, CMAN runs in Traffic Director Mode, acting as a database proxy that performs connection pooling through Proxy Resident Connection Pooling, or PRCP, covered in the first lesson of this module for its Oracle AI Database 26ai enhancements such as per-PDB pool sizing. Traffic Director Mode relies on Oracle's existing proxy authentication mechanism rather than any new scheme invented specifically for CMAN: a database user grants a proxy user the right to connect on their behalf with a statement such as ALTER USER appuser GRANT CONNECT THROUGH tdm_proxy, and the application then authenticates through that proxy user when connecting via CMAN-TDM.

Administration

CMCTL remains the primary interface for starting, stopping, and inspecting CMAN, as covered in the previous lesson, including the move to Local Operating System Authentication, or LOSA, in place of password access in Oracle AI Database 26ai. CMAN administration is no longer limited to the command line either: the REST_ADDRESS parameter configures a REST endpoint hostname and port, so the same status, rule, and gateway information CMCTL exposes at the command line can also be retrieved through a REST API over TCPS.

Multiple Protocol Support

Oracle Connection Manager lets a client and a server configured for different underlying network protocols communicate with each other, a capability that traces back to the Multi-Protocol Interchange feature of SQL*Net version 2. That lineage is worth knowing, but the terminology around it has moved on considerably since then; for a current look at Oracle connectivity methods beyond the Net8 and SQL*Net era, see our guide to modern Oracle connection methods.

One historical claim from earlier course material is worth correcting explicitly rather than quietly dropping: CMAN was once described as "a new product within Oracle8" that was "intended to eventually replace the Net8 listener." That never happened and was never the actual design intent. CMAN was built to sit in front of the Oracle Net listener and work with it, forwarding screened requests to it, not to replace it, and every lesson in this module has described that same relationship between CMAN and the listener it depends on.

Oracle Net Services in Cloud Environments

Oracle Net Services is still the foundational networking technology for Oracle databases, including Oracle AI Database 26ai, in both on-premises and cloud deployments. Within Oracle Cloud Infrastructure (OCI)^[1] and Oracle Autonomous Database, that foundation is paired with cloud native networking: Virtual Cloud Networks (VCNs)^[2] to define network topology, FastConnect or VPN services to connect on-premises environments to the cloud, private endpoints^[3] to avoid exposing a database to the public internet, and network security groups (NSGs)^[4] to control traffic at the resource level.

Oracle Net Services, including Transparent Network Substrate (TNS) configuration, continues to operate underneath these cloud native layers rather than being replaced by them. In essence, Oracle Net Services is still relevant in cloud enabled databases, it is simply integrated with the broader cloud networking infrastructure around it.

In the next lesson, you will find out how to configure the CMAN parameter file.

[1] Oracle Cloud Infrastructure (OCI): Oracle Cloud Infrastructure (OCI) is a comprehensive suite of cloud services offered by Oracle that provides on-demand access to compute, storage, networking, and various platform services. It enables businesses to build, deploy, and manage applications and workloads in a scalable, secure, and high-performance cloud environment.

[2] Virtual Cloud Networks (VCNs): Virtual Cloud Networks (VCNs) are software-defined networks that provide isolated and customizable network environments within a cloud provider's infrastructure. They allow you to segment and control your cloud resources, much like you would in a traditional on-premises data center.

[3] Private endpoints: Private endpoints are network interfaces that allow you to privately and securely connect to a service, effectively bringing that service into your own virtual network. This eliminates the need to expose your data to the public internet, enhancing security and control over your network traffic.

[4] Network security groups: Network security groups (NSGs) are a fundamental cloud network security feature that controls traffic flow to resources in a virtual network. They act like a virtual firewall, using rules to allow or deny inbound and outbound network traffic based on source, destination, port, and protocol.