Oracle DBA Lesson 33A — Follow a Client Into the Right PDB

A successful remote connection passes through naming, the listener, and the requested service before creating a database session. Follow that path to understand what the connect identifier requests and how to prove the resulting session reached the intended PDB.

Oracle DBA Lesson 33A — Follow a Client Into the Right PDB

Environment and prerequisites

Use Oracle Database 19c, a Linux SQL*Plus client, and a single-instance CDB/PDB. The instructor supplies the actual host, port, intended service, and PDB. dbhost, port 1521, service LABPDB, and container LABPDB are example values. The service name may differ from the PDB name or include a domain. Use the exact expected service. The model assumes configured dedicated servers, with no proxy, connection manager, shared-server dispatchers, or DRCP. The connect string shown alone does not force that server model. See Oracle Net architecture.

Use an instructor-designated disposable lab. COURSE_READER is local to the target PDB and needs CREATE SESSION there. The own-session SYS_CONTEXT query needs no dictionary role. Ordinary login assumes the PDB permits this access. Displayed values are examples. Record the actual session results in the lab.

The optional local administrator comparison requires separate designated OSDBA authorization on the database host. The ordinary COURSE_READER exercise grants no SYSDBA authorization. Typical local bequeath assumes the intended ORACLE_HOME and ORACLE_SID, no TWO_TASK or LOCAL network redirection, and no ORACLE_PDB_SID selecting another container. If access is unavailable, interpret instructor-provided local output instead.

Connection and interpretation

At the Linux client, replace the example endpoint with the approved lab values:

sqlplus -L COURSE_READER@"//dbhost:1521/LABPDB"

SQL*Plus prompts for the password. -L suppresses repeated initial username and password prompts after an unsuccessful logon. Enter secrets only through the approved prompt or wallet.

Easy Connect constructs a descriptor from host, port, and requested service. A short net-service alias instead uses the configured naming method to obtain that descriptor. Separately, hostname resolution supplies the network address. TCP reaches the listener, which uses registered service and handler information for the dedicated handoff. The service maps the request to its intended PDB. An SID identifies an instance. After authentication and session creation, SQL and results use the established client/server path. The listener continues accepting new requests. Under this ordinary model, stopping the listener normally leaves established dedicated sessions running. No listener stop is part of this lab. See naming methods and database access and handoff.

Inside the connected session:

SHOW USER
SHOW CON_NAME
SELECT SYS_CONTEXT('USERENV','SERVICE_NAME') AS service_name,
       SYS_CONTEXT('USERENV','CON_NAME') AS container_name
FROM dual;

SHOW is a SQL*Plus client command. SELECT runs inside the database. SERVICE_NAME gives the effective session service. CON_NAME gives its current container. Example expected values are LABPDB and LABPDB. Compare the actual returned identity, service, and container with the intended account and destination. Service and container equality is an example convention, not a rule. Preserve the actual output in the lab record. See starting SQL*Plus and SYS_CONTEXT.

Independent read-only practical

1. Record the approved lab version and release update, the SQL*Plus client home, and the exact expected host, port, service, PDB, and account. Draw the client, hostname lookup, listener endpoint, requested service, registered dedicated handler, server, and session.
2. Run the remote service login above using the actual provided values and the password prompt. Capture the sanitized identifier, time, observed logon result, and the three own-session checks. If the account or destination differs, stop this exercise and preserve the evidence for investigation.
3. Explain how the identifier was interpreted, how the hostname supplied the address, which listener endpoint was reached, which service was requested, and how the returned service and container match the intended destination. Trace a later SELECT and its result along the established dedicated path.
4. On the designated database host only, an authorized administrator may compare sqlplus / as sysdba with the service login. Record its actual connected user and container using SHOW USER, SHOW CON_NAME, and the same SYS_CONTEXT query. Explain the local OS-authenticated bequeath path under the stated environment. Learners without administrative access use provided evidence. Do not grant privileges or change environment, network, or database settings to complete this comparison.
5. Close each read-only test session with EXIT. Record that the sessions closed and that no database or configuration changes were made.

Success: correctly draw and explain both paths, identify which one tests the application's remote service route, and show actual remote session evidence matching the intended account, service, and container. Cleanup is closing test sessions. No listener restart, firewall edit, password reset, PDB-mode change, or object creation is required.

Recap

Interpret the identifier, trace the listener and service handoff, and verify the connected account, service, and container. Test the actual remote route independently of a local administrative login.

Quiz

1. In //dbhost:1521/LABPDB, what does LABPDB identify?

The operating-system SID variable The requested database service The listener process name A mandatory name for every PDB

2. What should be checked after an ordinary login succeeds?

Only whether a prompt appeared Only the password length Only the filename of SQL*Plus The connected account, session service and current container

3. Does a successful usual local sqlplus / as sysdba prove the remote PDB service works?

No; test the remote service route and its session destination separately Yes; every local login uses that remote service Yes; OS authentication tests the client's naming file No; a local login can never reach any database

4. After the ordinary dedicated handoff, which path carries later SQL and results?

A fresh connection through the listener for every query Only the hostname lookup service The established client/server connection The listener.ora file

5. Which own-session query reports the effective service?

SELECT * FROM every PDB's DBA_USERS SYS_CONTEXT('USERENV','SERVICE_NAME') SHOW PARAMETER control_files REPORT SCHEMA

Names, paths, marker values, and expected results are teaching examples. Perform the practice in the designated Oracle Database 19c lab, confirm the exact release and update level, and record actual observations against the stated success criteria.

AIOps Pro

https://www.apps-dba.com/ https://x.com/AIOpsPro https://www.youtube.com/@AIOpsPro