Configuring Client Connection Routing in Oracle 23ai

Client connection routing is the process of determining how an Oracle client reaches a database service and how Oracle Net directs that request toward the correct destination. In older Oracle environments, administrators often learned this topic through GUI-oriented tools and simplified diagrams. In Oracle 23ai, especially when the database runs on Oracle Cloud Infrastructure (OCI), routing is better understood as a combination of Oracle Net configuration, service selection, client-side connect descriptors, and OCI network controls.

That means this lesson is not only about whether a session uses a dedicated server process or a shared server process. It is also about how the client reaches the correct service, how load balancing and failover can be expressed, how routing changes between self-managed and Autonomous Database environments, and when Oracle Connection Manager (CMAN) is the correct Oracle-supported tool.

The most important modern distinction is this: Autonomous Database and self-managed Oracle Database 23ai do not use exactly the same routing model. In Autonomous Database, Oracle manages much of the listener and internal service routing for you. In self-managed OCI environments, you still control more of the routing behavior through Oracle Net configuration, connect descriptors, service names, and intermediary tools such as CMAN.

What Client Connection Routing Means

When a client tries to connect, Oracle Net must answer several questions before the session reaches a database process:

1. Which host or endpoint should receive the request?
2. Which listener port should the client use?
3. Which service name should be requested?
4. Should multiple addresses be tried for load balancing or failover?
5. Is the connection routed directly, through an OCI-managed service path, or through an intermediary such as Oracle Connection Manager?

In Oracle 23ai, routing is therefore broader than a single parameter in sqlnet.ora. The route is shaped by the client connect string or descriptor, the selected service, the naming method, and the OCI network environment in which the database is deployed.

Two Different OCI Routing Models

1. Oracle Autonomous Database on OCI

With Autonomous Database, Oracle manages the listener layer and much of the underlying connection distribution internally. The administrator usually does not configure traditional database-side routing by editing listener.ora. Instead, the client typically connects through a wallet, Oracle-provided service names, or a modern TCPS connection string. In this model, Oracle already handles much of the internal routing, service placement, and failover behavior.

2. Self-Managed Oracle Database 23ai on OCI

With a self-managed database on OCI, such as a VM DB system or another administrator-controlled deployment, you retain more direct control over how client requests are routed. You can define multi-address connect descriptors, client-side load balancing and failover, service-based routing behavior, and in more advanced cases deploy Oracle Connection Manager as a proxy or traffic intermediary. OCI networking still matters, but Oracle does not abstract as much of the routing layer away from you.

Routing in Oracle Autonomous Database

For most Autonomous Database deployments, the starting point is the wallet downloaded from the OCI Console. The wallet contains the secure connection information, including service aliases such as _high, _medium, _low, _tp, and _tpurgent. These service names are important because they do more than identify the database. They represent workload-oriented routing choices that Oracle manages internally.

A typical Autonomous Database client workflow looks like this:

1. Download the wallet from OCI.
2. Extract the wallet to a secure local directory.
3. Set TNS_ADMIN to the wallet directory if needed.
4. Use one of the provided service names based on the workload profile.

In this model, routing is influenced less by hand-built listener configuration and more by the service alias the client chooses. OCI and Oracle-managed infrastructure handle much of the internal request placement. This is why a lesson on routing in Oracle 23ai should not imply that every environment starts with manual editing of listener.ora or server-side Oracle Net files.

Autonomous Database routing is also tied to OCI security and connectivity features such as private endpoints, access control lists, network security groups, and secure TCPS/TLS access. The client may appear to use a simple alias, but the effective route is shaped by both Oracle-managed service logic and OCI network policy.

Easy Connect and Easy Connect Plus

Easy Connect and Easy Connect Plus provide a simpler client-side routing model because they allow the route information to be expressed directly in the connection string. For some environments, especially scripts, modern tools, and lightweight deployments, this reduces the need for local alias files.

sqlplus username/password@//dbhost.example.com:1521/service_name

Easy Connect Plus extends this approach with more advanced options such as retry behavior and additional connection parameters. In practice, this means that routing information can sometimes live directly in the client connect syntax rather than in a separate file. That makes it useful when you want fewer moving parts on the client side.

However, Easy Connect is not the answer to every routing problem. It is excellent for straightforward direct connectivity, but larger environments may still benefit from centralized descriptors, service alias strategies, or intermediary routing controls.

Client-Side Routing with Connect Descriptors

In self-managed Oracle 23ai environments, one of the most important routing mechanisms remains the client-side connect descriptor. This is usually defined in tnsnames.ora or provided centrally through another supported configuration path. A descriptor can define multiple addresses, failover behavior, and load balancing rules.

MYDB =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (LOAD_BALANCE = on)
      (FAILOVER = on)
      (ADDRESS = (PROTOCOL = tcps)(HOST = dbhost1.example.com)(PORT = 1521))
      (ADDRESS = (PROTOCOL = tcps)(HOST = dbhost2.example.com)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = appsvc)
    )
    (SECURITY =
      (SSL_SERVER_DN_MATCH = yes)
    )
  )

This type of descriptor lets the client participate directly in routing decisions. Instead of always trying one fixed address, the client can work through an address list with explicit load-balancing and failover behavior. This is still highly relevant in Oracle 23ai for self-managed systems, because it gives administrators fine-grained control over how requests are distributed.

It is also important to separate this from the question of dedicated versus shared server. Routing decides how the client reaches a service and which address path is attempted. Server process model determines how Oracle services the session after connection establishment. They are related topics, but they are not identical.

Centralized Configuration Provider Naming

Oracle 23ai introduces a more modern option for managing connection metadata centrally: centralized configuration provider naming. In OCI-oriented environments, this can place connect descriptors in OCI Object Storage and allow clients to retrieve the routing definition from a shared managed source rather than relying only on local configuration files.

This approach is useful when many clients should follow the same routing policy. Instead of manually distributing revised tnsnames.ora files to many systems, administrators can centralize the descriptor logic and update it in one place. That is especially valuable when routing rules change over time or when a cloud-managed deployment wants a cleaner operational model.

Conceptually, this is one of the clearest examples of how Oracle 23ai moves beyond older file-only Oracle Net administration. The route still depends on Oracle Net descriptors and service names, but the storage and distribution model becomes more cloud-native.

Oracle Connection Manager (CMAN)

For self-managed Oracle Database 23ai on OCI, Oracle Connection Manager is the main Oracle-supported intermediary when you need advanced routing control. CMAN acts as a proxy layer between clients and the database. Rather than allowing every client to connect directly to the listener, you can route requests through CMAN and apply additional control over how connections are handled.

CMAN is useful in scenarios such as:

• IP-based allow or deny rules
• routing through a transit or proxy host
• hiding direct database addresses from clients
• connection concentration and network-layer mediation
• environments where direct database exposure is undesirable

In OCI, CMAN would typically be placed on a separate compute instance in the appropriate subnet layout. Clients then connect to CMAN, and CMAN forwards approved requests toward the database. That gives administrators more rule-based control than a simple direct connect string. It also makes CMAN much more relevant to self-managed environments than to Autonomous Database, where Oracle already manages more of the connection path.

OCI Network Controls That Influence Routing

Even when Oracle Net descriptors define the logical connection path, OCI still determines whether that route is actually reachable. That is why client connection routing in Oracle 23ai on OCI must be understood at two layers:

1. Oracle Net routing layer — connect strings, aliases, service names, load balancing, failover, CMAN, and centralized configuration
2. OCI network layer — VCNs, subnets, route tables, security lists, network security groups, private endpoints, service gateways, VPN, or Direct Connect

For example, a connect descriptor may be syntactically correct, but if a private endpoint is required and the client is outside the allowed path, the request will never reach the service. Likewise, an Autonomous Database service alias may be valid, but network access controls may still decide whether the route is permitted. In modern OCI deployments, routing and access control are tightly related.

Dedicated and Shared Server: Related but Separate

Older presentations of this topic sometimes blur connection routing with the choice between dedicated and shared server processing. Oracle 23ai still supports those execution models, and they matter operationally, but they are not the main definition of client connection routing.

If you force a dedicated server path, you are influencing how Oracle services the session after connection establishment. If you define an address list, Easy Connect Plus string, wallet-based service alias, or CMAN proxy path, you are influencing how the request is routed before the session is established. A modern lesson should keep those ideas distinct so the reader does not confuse process model with network routing model.

Choosing the Right Routing Model

The right routing model depends on the deployment context and the level of control required:

• Use Autonomous Database wallet-based service routing when Oracle manages the infrastructure and the service aliases already express workload intent.
• Use Easy Connect or Easy Connect Plus when you want simple modern direct connectivity with minimal local configuration.
• Use client-side descriptors with load balancing and failover when you need explicit Oracle Net routing logic in a self-managed deployment.
• Use centralized configuration provider naming when many clients should consume a common cloud-managed routing definition.
• Use Oracle Connection Manager when advanced rule-based or proxy-style routing is needed in a self-managed OCI environment.

That choice should be driven by architecture, not habit. Oracle 23ai gives you multiple valid routing patterns, and OCI adds another layer of network design that shapes which one is best.

Conclusion

Configuring client connection routing in Oracle 23ai means understanding how Oracle Net and OCI work together to direct client requests toward the correct database service. In Autonomous Database, routing is largely managed by Oracle through wallet-based secure service aliases and OCI-aware service design. In self-managed Oracle Database 23ai environments, administrators retain more direct control through connect descriptors, load balancing, failover settings, Easy Connect Plus, and Oracle Connection Manager.

The lesson objective is best satisfied when routing is treated as a deployment-context problem, not merely as an old listener setting. Once you understand how service names, connect descriptors, centralized configuration, CMAN, and OCI network controls fit together, you can design a routing model that is both modern and operationally sound.