Testing Network Connectivity and Server Connection Type in Oracle AI Database 26ai

This lesson covers two layers of connectivity that sit on either side of the Oracle Net testing already covered in Lesson 8. First, the layer beneath Oracle Net entirely: raw network reachability, which has nothing to do with Oracle software and everything to do with whether your machines can talk to each other at all. Second, the layer above a successful connection: once you're actually connected, confirming what kind of server process is actually handling your session — dedicated or shared.

If your underlying protocol is TCP/IP, testing basic connectivity to the database server is straightforward: use the ping^[1] utility.

C:\>ping prodsvr
Pinging prodsvr [10.11.49.239] with 32 bytes of data:
Reply from 10.11.49.239: bytes=32 time=1ms TTL=128
Reply from 10.11.49.239: bytes=32 time<10ms TTL=128
Reply from 10.11.49.239: bytes=32 time=1ms TTL=128
Reply from 10.11.49.239: bytes=32 time=1ms TTL=128
Ping statistics for 10.11.49.239:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  1ms, Average =  0ms

The ping command works identically from Windows and Unix/Linux command prompts. Pass your database server's hostname as the argument. The example above succeeded — you know this because you received replies back from the server. Had it failed, you'd see "request timed out" messages instead. If you get timeouts or no replies at all, check two things first: the hostname you're pinging, and whether that hostname actually resolves to the IP address you expect. If the hostname is correct and pinging still fails, you're looking at a genuine network problem — worth confirming your own network cable or connection is physically active before escalating to whoever manages your network infrastructure.

ping deliberately knows nothing about Oracle — it only confirms the two machines can exchange packets at all. That's exactly why it's the right first step: it rules out an entire category of problems before you ever touch Oracle Net. Once ping succeeds, the next layer up is Oracle Net connectivity specifically — testing whether the listener on that reachable host is actually responding. Lesson 8 covers that testing in detail, including tnsping, the distinction between a name-resolution failure and a listener-not-running failure, and the TRCROUTE utility for tracing a connection's path when the picture is less clear-cut. If ping succeeds but your Oracle connection still fails, that's where to go next — this lesson won't re-cover that ground.

One scenario worth knowing about specifically, since it doesn't come up in Lesson 8's coverage: if you're running multiple releases of Oracle client software on the same PC, you may end up with several separate tnsnames.ora^[2] files — one per client installation, each in its own Oracle home's network/admin directory.

This becomes a problem when you're not careful about keeping them in sync. Add a new service entry to one file but forget the others, and connecting through a different client release than the one you just edited produces a "failed to resolve service name" error — not because anything is actually broken, but because the client you're using is reading a different, unedited copy of the file. It's an easy problem to fix once you know it exists, but confusing the first time you hit it, since everything about your configuration looks correct from where you're standing.

Adopting a predictable naming and distribution strategy for your tnsnames.ora files — rather than editing whichever one happens to be nearest — is the real fix here, and worth doing deliberately rather than discovering the problem by accident. See creating and maintaining tnsnames.ora for a fuller treatment of that strategy.

Once you're successfully connected, there's a further question worth answering: is your session running through a dedicated server process, or a shared server? This matters because the two behave differently under load, and because — as covered below — shared server configuration has its own container-scope rules worth understanding if you're working in a CDB.

Server-side configuration is controlled by two initialization parameters:

• SHARED_SERVERS — the number of shared server processes created at instance startup. The default is 0, meaning shared server is off entirely; setting it above zero enables the feature.
• DISPATCHERS — configures the dispatcher processes that handle network communication for shared server connections. If SHARED_SERVERS is set above zero, DISPATCHERS defaults to a nonzero value automatically.

To check what a specific session is actually using, query v$session:

SELECT sid, serial#, username, server, program
FROM v$session
WHERE username = 'YOUR_USERNAME'; -- replace with the connected user

The SERVER column tells you directly — SHARED means the session is using a shared server, DEDICATED means it isn't. The PROGRAM column is a useful secondary clue about which client tool actually established the connection.

One important caveat: enabling shared servers doesn't guarantee every connection actually uses one. Client tools and connection string configuration both influence whether a given session ends up shared or dedicated — a working shared server setup and a session that happens to be dedicated anyway are not a contradiction.

Two more ways to check, beyond querying v$session directly:

• lsnrctl services — the Listener Control command introduced in Lessons 4 through 6 — displays a summary of dispatched and connected shared server processes, giving you the listener's perspective on the same information.
• OS-level tools — ps on Linux/Unix, Task Manager on Windows — let you view the actual server processes running on the database host directly, useful when you want to see process-level detail beyond what the database's own views expose.

Here's a container-scope wrinkle worth understanding, in the same family as the "which container does this apply to?" question that's come up repeatedly across this course. SHARED_SERVERS can be set inside a PDB — but not in the same way most parameters work at the PDB level. Within a PDB, you don't get to choose a specific server count; you only get an on/off switch. A DBA working inside a PDB can either:

• Set SHARED_SERVERS to 0 within that PDB, disabling shared server use for that PDB specifically, or
• Run ALTER SYSTEM RESET SHARED_SERVERS within that PDB, re-enabling shared servers using whatever configuration the CDB root has established.

The actual configuration — how many shared servers, how many dispatchers — can only be set in the CDB root. A PDB gets a toggle, not a dial.

A worked example. Suppose your COIN CDB's root has shared servers configured with SHARED_SERVERS=4, and you want a specific PDB — say, a reporting workload that should always use dedicated connections for predictable performance — to opt out of shared servers entirely, without touching the root's configuration for every other PDB:

-- Connected to the specific PDB, not the CDB root
ALTER SYSTEM SET SHARED_SERVERS = 0;

Every other PDB in the CDB continues using the root's shared server configuration unaffected. If you later want that PDB back on shared servers, using the root's settings again:

ALTER SYSTEM RESET SHARED_SERVERS;

What you can't do from inside a PDB is set SHARED_SERVERS = 8 to give that one PDB a different server count than the root — that level of configuration is root-only. This is a narrower kind of container-scope control than the realm/factor examples covered in Lesson 9 of Module 7's coverage — not "this only works in the root" or "this only works in a PDB," but "the PDB gets a switch, the root gets the dial."

One related setting worth being aware of even though it lives in a different file: connection-level timeout behavior — how long Oracle Net waits before giving up on a hung connection attempt — is controlled through sqlnet.ora, not through the shared server parameters covered here. Sane outbound, inbound, send, and receive timeout values matter for both dedicated and shared connections, and are worth setting deliberately rather than leaving at their defaults; see setting TNS timeout values for that topic specifically.

[1]ping: A utility used to verify basic TCP/IP connectivity between two nodes on a network, independent of any Oracle-specific software.

[2]tnsnames.ora: An Oracle Net configuration file mapping network service names to connect descriptors, as covered in Lesson 7.