Lesson 10

This module worked through Oracle Connection Manager from the ground up: what CMAN actually is, the internal processes that make it run, the features that make it worth deploying, the configuration file that governs all of it, and the specific tasks of multiplexing sessions, controlling access, and administering an instance day to day. Across nine lessons, the module also repeatedly separated what CMAN still does in Oracle AI Database 26ai from what older course material and older Oracle documentation once claimed it did, correcting retired terminology, desupported authentication methods, and a few claims that were never accurate to begin with.

CMAN's Role and Internal Architecture

The first lesson introduced Oracle Connection Manager as a proxy that sits between clients and the database, adding an access control layer a plain Oracle Net listener cannot provide on its own, and multiplexing many client sessions over a smaller number of physical connections to the database. Three recurring deployment scenarios came up repeatedly through the rest of the module: perimeter protection in a DMZ, connection consolidation at scale for large web tiers, and the protocol flexibility covered in depth in the ninth lesson.

The second lesson went inside that proxy and separated it into its four working parts. The listener screens incoming requests against CMAN's access control rules first. CMGW, the gateway process, relays and multiplexes the sessions the listener allows through. CMADMIN monitors and restarts the listener and every gateway, registering each one's load so new connections go to the least busy gateway. CMCTL is the command line tool administrators use to control the other three. Keeping these four pieces separate is what lets CMADMIN restart a failed gateway without interrupting the listener, and what lets an administrator run CMCTL commands without touching the processes carrying live traffic.

This lesson also walked through a real CMADMIN log capture to make that registration chain concrete: a gateway process registering with CMADMIN, CMADMIN in turn registering with the listener, and a parameter list entry recorded at startup. The sample log happened to be old enough to show the retired password authentication model in its event stream, a detail the lesson flagged explicitly as historical rather than something to replicate, while the log format itself is still representative of what a current CMADMIN instance produces.

The Feature Set

With the architecture established, the third lesson surveyed everything CMAN actually offers: rule based access control, session multiplexing, TLS secured connections, compression, bandwidth control per service, Traffic Director Mode for proxy based connection pooling, and administration through CMCTL, now including a REST interface. This lesson also drew the clearest line in the module between CMAN's current scope and its Net8 era reputation, correcting the old claim that CMAN was ever intended to replace the Oracle Net listener rather than work in front of it.

The cman.ora Configuration File

Every feature introduced in the third lesson is ultimately configured through one file, and the fourth lesson covered its structure directly: a listening address section, a rule list, and a parameter list, all wrapped under a top level CMAN= identifier. This lesson also covered where cman.ora lives by default, how Oracle Net searches multiple candidate locations in a fixed order, and how CMAN's diagnostic data is captured, through the Automatic Diagnostic Repository by default rather than the older manually sized and numbered trace files, which still work but have to be turned on deliberately with DIAG_ADR_ENABLED=off. Two smaller but practical refinements to the listening address syntax rounded out the lesson: tagging an address with (ADMIN=YES) to keep CMCTL administration reachable even if the regular client facing endpoints are closed off, and configuring the PROXY protocol with an EXPECTED_PROXIES list so CMAN can see a client's real IP address when a load balancer sits in front of it rather than logging and filtering on the load balancer's own address.

Putting Session Multiplexing to Work

The fifth lesson turned the session multiplexing feature introduced earlier in the module into a working deployment, in three concrete steps: enabling multiplexing at the database's dispatcher with the MULTIPLEX attribute of the DISPATCHERS parameter, registering the database with CMAN through tnsnames.ora and CMAN's node checking rules, and routing client connect descriptors at CMAN's address instead of the database's. This lesson also retired two more pieces of older terminology along the way: MTS became shared server back in Oracle 9i, and MTS_DISPATCHERS has been DISPATCHERS with a MULTIPLEX attribute for just as long. It also drew a distinction worth keeping straight: Database Resident Connection Pooling, requested with a :POOLED connect string, pools database server processes directly and needs no CMAN involvement at all, which is a genuinely different mechanism from CMAN's own session multiplexing at the network layer, even though both get described loosely as connection pooling.

Network Access Control

The sixth lesson went deep on the RULE_LIST mechanism that sits behind CMAN's perimeter protection use case: the four fields that make up a RULE, CMAN's default deny behavior when no rule matches, the first match evaluation order that makes rule placement matter as much as rule content, and the per-rule ACTION_LIST overrides that let a single sensitive service carry its own connect time and idle timeout limits. This lesson also introduced IP rate limiting, a newer, separate layer that throttles connections by how fast a single address opens them rather than by who that address is or what it is asking for.

Administering CMAN with CMCTL

The seventh lesson covered CMCTL itself in full: its command and batch modes, selecting an instance with ADMINISTER, reconfiguring a running instance without a restart through RELOAD, and the full family of SHOW and SET commands used to monitor and adjust an instance live. It also established the administrative model that runs through the rest of the module: Oracle AI Database 26ai has desupported password based CMAN administration entirely, in favor of Local Operating System Authentication, so whoever is allowed to administer an instance is determined by which operating system account is running CMCTL, not by a separate credential.

Starting and Stopping an Instance

The eighth lesson focused specifically on the STARTUP and SHUTDOWN commands introduced in the previous lesson: what each one actually does, the difference between a graceful shutdown, an immediate ABORT, and a client-warning NOTIFY, and how to verify a start or stop actually took effect with SHOW STATUS rather than trusting command output alone. This lesson also reinforced a theme that runs through the whole module: RELOAD handles most day to day configuration changes without dropping a single connection, and a full restart is reserved for the smaller set of changes that genuinely require one. On Windows specifically, CMAN's components are also registered as standard Windows services, which can be started and stopped through the Services console with the same effect as the equivalent CMCTL command, a convenient option in an environment already managing other Oracle services that way.

What's Left of Multi-Protocol Functionality

The ninth lesson closed out the feature coverage by addressing a capability that has changed more than almost anything else in this module since the Net8 era. CMAN no longer converts between arbitrary network transports; its listener always listens on TCP/IP. What survives under the multi-protocol name today is narrower: mixing plain TCP and TCP with TLS within a single deployment, including a TLS leg on one side of a connection and a plain TCP leg on the other, and bridging IPv4 and IPv6 when a CMAN instance runs on a dual-stack host. Both remaining capabilities solve specific, current migration problems, phased TLS adoption and phased IPv6 adoption, rather than the open-ended cross-protocol claims the original Net8-era material made. A dual-stack CMAN instance can combine both roles at once, letting an IPv4-only application tier keep connecting the way it always has while CMAN itself holds the IPv6 reachability a newer database segment requires and the TCPS leg a trusted-to-untrusted network boundary requires, so neither migration has to ripple out to every client at once.

Oracle Connection Manager in Oracle AI Database 26ai: A Running List

Rather than treating "what's new in 26ai" as a single topic, this module surfaced it piece by piece as each relevant feature came up. Gathered together, the full list of 26ai-specific changes covered across the module is:

• Password based CMCTL administration is desupported, replaced by Local Operating System Authentication (LOSA), covered in the second and seventh lessons
• CMCTL administration is also available through a REST interface over TCPS, configured with the REST_ADDRESS parameter, covered in the third lesson
• TLS protocol versions 1.0 and 1.1, along with SSLv3, are desupported for CMAN connections; TLS 1.3 is the newest supported option, covered in the third lesson
• Implicit connection pooling for CMAN-TDM through Proxy Resident Connection Pooling (PRCP), and per-PDB PRCP pool sizing on Autonomous AI Database via the TDM_PERPDB_PRCP_CONNFACTOR parameter, covered in the first lesson
• IP rate limiting, through IP_RATE_COUNT, IP_RATE_INTERVAL, and IP_RATE_BLOCK, covered in the sixth lesson
• Expanded diagnostics and logging for database service registration, viewable through CMCTL and the CMAN and listener log files, covered in the first lesson

Several of these changes point in the same direction: CMAN administration has moved away from anything a shared secret could compromise, toward identity the operating system itself already vouches for, and CMAN's operational visibility, through logging, diagnostics, and now a REST interface, has expanded considerably from what the Net8 era original course material described.

Terminology Retired Across This Module

Two pieces of Net8-era and Oracle 8i-era terminology came up repeatedly enough across this module to be worth restating together here, rather than leaving the correction scattered across individual lessons. "Connection concentration" was the standard term for CMAN's session multiplexing capability only through the Oracle 8i era; it does not appear anywhere in Oracle's documentation afterward, which is why every lesson in this module used session multiplexing instead, even where a page's own URL or an older figure caption still carries the retired name. Oracle Names, the centralized naming directory this course's older material sometimes assumed was still available, was desupported starting with Oracle Database 10g; Oracle Database clients today resolve connect strings through local naming, directory naming using LDAP, the centralized configuration provider method, or Easy Connect instead. For a fuller look at how Oracle connectivity has moved since the Net8 and SQL*Net era generally, see our guide to modern Oracle connection methods.

Learning Objectives Revisited

The first lesson of this module set out four objectives for the module as a whole. Looking back across all nine lessons, each one was covered directly: the purpose and function of Oracle Connection Manager, including its roles as proxy, access control filter, and session multiplexer, in the first three lessons; configuring CMAN through cman.ora, including listening endpoints, access control rules, and operational parameters, in the fourth and sixth lessons; starting, stopping, and monitoring CMAN through CMCTL, in the seventh and eighth lessons; and explaining how CMAN supports session multiplexing and multiple network protocols, along with what is new for CMAN in Oracle AI Database 26ai, in the fifth and ninth lessons and in the 26ai roundup above.

That covers Oracle Connection Manager from its internal architecture through to day to day administration in Oracle AI Database 26ai: what it is, the four processes that make it run, the full feature set, the cman.ora file that configures all of it, and the specific tasks of multiplexing sessions, controlling access, and starting, stopping, and monitoring a running instance. The cman.ora structure, access control patterns, and CMCTL commands covered across these nine lessons apply directly to any CMAN instance you deploy going forward, whether that instance is doing perimeter protection in a DMZ, consolidating connections for a large application tier, or bridging a TLS or IP version boundary the way the ninth lesson described.

Before moving on to the next module, click the Quiz link below to check your knowledge of the Connection Manager.
Configuring Connection Manager - Quiz