Lesson 1

Oracle Connection Manager, known as CMAN, is a networking component available with Oracle Enterprise Edition. It sits between a client and an Oracle database, acting as a router that forwards a connection request either directly to the database or on to its next hop. CMAN is part of the same family of components as the Oracle Net listener and Oracle Net Manager, collectively referred to as Oracle Net Services, and it fills a gap that a plain listener cannot close on its own.
A listener by itself accepts connections from any client that knows its host address, port number, and database name. It has no built-in way to say "yes" to some clients and "no" to others. CMAN sits in front of that listener and adds an access control layer: you define rules specifying which client hosts, which remote databases, and which services are permitted to make a connection at all. CMAN also multiplexes sessions, meaning many client sessions can share a single transport-protocol connection to their destination, so the database server needs far fewer physical connection endpoints to service the same number of users. Throughout this lesson, we describe that multiplexing capability in modern terms, as session multiplexing, rather than by the retired term "connection concentration" discussed later in this lesson.

Why Deploy Oracle Connection Manager

Most small deployments never need CMAN. A single application server talking directly to a single database instance can connect through the listener with no intermediary. CMAN earns its place when the network topology gets more complicated, and a few recurring scenarios show up again and again in production environments.

The most common scenario is perimeter protection. Organizations frequently place CMAN in a demilitarized zone, between an external network and an internal database tier, so that no client ever opens a direct socket to the database host itself. Every connection request is screened by CMAN first, and only the requests that match an access control rule are forwarded inward. This keeps the database server's address out of reach of anything that has not already passed CMAN's filter.

Picture that DMZ deployment in a bit more detail. An external client opens a connection to CMAN's listening address, not to the database host, because the database host address is never exposed outside the internal network at all. CMAN evaluates that request against its access control rule list, and only a request matching an allowed client, service, or destination is forwarded inward to the real listener on the database tier. A request that does not match any rule is rejected or dropped before it ever reaches the database, which means a misconfigured or malicious client cannot even discover that the database exists, let alone attempt to log in to it.

A second scenario is connection consolidation at scale. Environments with large numbers of short lived client sessions, such as web application tiers that open and close database connections constantly, can overwhelm a listener's capacity to track individual endpoints. By multiplexing those sessions over a smaller number of transport connections, CMAN reduces the resource burden on the database host considerably. Without CMAN, each client session typically needs its own dedicated connection endpoint on the database server; with CMAN in place, many of those sessions can share a much smaller set of physical connections to the database, which is precisely the resource saving that session multiplexing is designed to deliver.

A third scenario is multi-protocol bridging, where CMAN translates between network protocols so that clients and databases configured for different transport mechanisms can still reach each other. This matters most in environments that have grown organically over many years, where not every client and not every database server ends up standardized on the same underlying protocol stack.

Oracle Connection Manager: Purpose and Function

Oracle Connection Manager is a software component that typically runs on its own host, separate from both the client machine and the Oracle database server. Functionally, it does three things at once: it proxies connection requests on the database's behalf, it screens those requests against configured access rules, and it multiplexes sessions across a shared transport connection.

Think of CMAN as a receptionist standing between a lobby full of visitors and a set of private offices. Instead of every visitor walking straight to an office door, each one checks in with the receptionist first. The receptionist checks a list, decides who is allowed through, and in CMAN's case also groups several visitors onto a single elevator trip rather than sending each one up individually. That grouping is the session multiplexing behavior: many client sessions funneled through one transport protocol connection to a particular destination, which reduces the number of connection endpoints the Oracle Database server has to maintain for a given volume of traffic. Acting as an access control filter, CMAN is the point at which connections to Oracle databases are allowed through or turned away.

It is worth being precise about what CMAN is not. It is not a replacement for the Oracle Net listener, which still performs the actual database-side connection handling once a request has been forwarded. It is also not a general-purpose network load balancer or firewall appliance, even though it shares some characteristics with both. CMAN is purpose-built for Oracle Net traffic specifically, which is why it understands Oracle service names, Oracle session semantics, and Oracle connect strings in a way a generic network appliance does not.

Purpose and Function of the cman.ora File

CMAN's behavior is governed entirely by a configuration file named cman.ora, which plays the same role for Connection Manager that sqlnet.ora plays for general Oracle Net client and server configuration. The two files are configured independently, but they are conceptually siblings: both are plain text parameter files that Oracle Net components read at startup. cman.ora is essential to CMAN's operation. If the file is missing or contains invalid syntax, CMAN will not start at all.

At a high level, cman.ora stores the addresses CMAN listens on, the access control rules that determine which connections are accepted or rejected, and a set of operational parameters covering connection pooling, logging, tracing, resource limits, and security settings.

Key Components of cman.ora

The listening endpoints section specifies the protocol addresses and ports on which CMAN listens for incoming connections, using the same address syntax found throughout Oracle Net Services. A typical entry looks like this:

ADDRESS = (PROTOCOL=TCP)(HOST=192.168.1.100)(PORT=1630)

The access control rule list is where CMAN's filtering behavior is defined. Rules can be scoped by client IP address, by service name, or by other connection attributes, and each rule resolves to one of three outcomes: the connection is accepted, rejected outright, or silently dropped. This rule list is what makes CMAN useful as a perimeter control point rather than just a pass-through proxy.

Beyond addressing and access control, cman.ora carries a broader parameter list that tunes CMAN's day to day operation: how aggressively it pools and reuses connections, what gets written to its log files, whether tracing is enabled for troubleshooting, limits on the resources a single connection or client can consume, and security settings such as TLS configuration for encrypted client traffic.

Logging and tracing deserve a word of their own, since they are usually the first place an administrator looks when a connection through CMAN behaves unexpectedly. Logging records the events CMAN handles over time, such as connections accepted or rejected, while tracing captures a much more granular record of CMAN's internal processing, useful for diagnosing a specific problem rather than for ongoing monitoring. Because tracing is more resource intensive than logging, it is typically enabled only while troubleshooting and turned back off once the issue is resolved.

By default, cman.ora lives in $ORACLE_HOME/network/admin on UNIX-like systems, or %ORACLE_HOME%\network\admin on Windows, the same default directory used for sqlnet.ora and tnsnames.ora. It can also be placed in a directory specified by the TNS_ADMIN environment variable, or in a platform-specific global configuration location such as /var/opt/oracle on Solaris. Administrators commonly manage these settings through Oracle Net Manager rather than editing the file by hand, though direct editing remains fully supported.

CMAN is typically deployed in large-scale or high-security environments to centralize connection management, improve scalability, enhance security, and simplify network configuration. It is not a mandatory component of every Oracle deployment, and plenty of smaller environments run without it.

What's New for CMAN in Oracle AI Database 26ai

Connection Manager is not a frozen, legacy component. It continues to receive meaningful engineering investment, and Oracle AI Database 26ai shipped several enhancements specific to CMAN running in Traffic Director Mode, commonly abbreviated CMAN-TDM.

The first is implicit connection pooling for CMAN-TDM. Client applications that do not implement their own application-level connection pool can now take advantage of CMAN-TDM's Proxy Resident Connection Pooling, or PRCP, automatically and without any code changes. PRCP servers are assigned to and released from a connection at runtime as the application starts and finishes database operations, even when the application never explicitly closes the connection itself. For applications that were never built with Oracle Session Pooling or Universal Connection Pooling in mind, this closes a real efficiency gap.

The second enhancement targets Autonomous AI Database specifically: per-PDB PRCP pool configuration. CMAN-TDM can now consolidate and share connection pools across services that belong to the same pluggable database, and the maximum pool size can scale dynamically based on a new cman.ora parameter, TDM_PERPDB_PRCP_CONNFACTOR, combined with the OCPU allocation assigned to that PDB. The practical effect is fewer pools to manage per CMAN-TDM gateway and less manual re-tuning as workloads shift.

CMAN also picked up two operational improvements worth knowing about. The first is IP rate limiting: CMAN can now cap the number of new connections it accepts from a given IP address within a specified time window. Malicious clients that flood a server with connection requests can exhaust CMAN's capacity to handle new connections, producing a denial-of-service condition for everyone else, and the rate limit feature lets administrators detect and reject that kind of traffic before it does damage.

The second is a set of diagnostics and logging enhancements. Using CMAN's command-line interface, administrators can now monitor statistics for every database service registration operation the CMAN listener performs, including registrations, updates, and unregistrations, and view additional diagnostic detail in the CMAN and listener log files. That visibility makes it considerably easier to evaluate traffic patterns and diagnose registration problems at both the global and per-instance level.

Retired Terminology and the Desupport of Oracle Names

Two pieces of Oracle networking history are worth clearing up here, because older documentation and older versions of this course still reference both.

First, the Oracle Names Control Utility has been desupported since Oracle Database 10g, along with every related control utility command. Oracle Database clients cannot use an Oracle Names server to resolve connect strings. Applications still relying on Oracle Names should migrate to Oracle Internet Directory with LDAP based directory naming, which this course covers in an earlier module. For a broader look at where Oracle connectivity has moved since the Net8 era, including Easy Connect Plus and OCI-native connection methods, see our guide to modern Oracle connection methods.

Second, a terminology note on the phrase "connection concentration." That phrase was the standard term for CMAN's session multiplexing capability only during the Net8 and Oracle 8i era. You will not find it anywhere in Oracle's documentation after Oracle 8i, which is exactly why this lesson has described the capability as session multiplexing throughout, rather than reviving a term Oracle itself retired more than two decades ago. The underlying functionality did not go away. Only the name did.

Learning Objectives

With the terminology and the current feature set established, here is what you should be able to do by the end of this module.

1. Describe the purpose and function of Oracle Connection Manager, including its roles as proxy, access control filter, and session multiplexer
2. Configure Oracle Connection Manager using the cman.ora file, including listening endpoints, access control rules, and operational parameters
3. Start, stop, and monitor Oracle Connection Manager using the Oracle Connection Manager Control Utility
4. Explain how Oracle Connection Manager supports session multiplexing and multiple network protocols, and identify what is new for CMAN in Oracle AI Database 26ai

In the next lesson, you will examine the function of CMAN's three server programs in detail, including how they work together to handle the proxy, access control, and multiplexing roles described above.