Oracle DISCONNECT vs EXIT: What Really Happens

In SQL*Plus, the two commands people confuse most are:

• DISCONNECT - ends your current database session but keeps the SQL*Plus program open at the prompt.
• EXIT - ends your database session (if connected) and closes SQL*Plus.

Neither command “switches” you out of Shared Server. Whether a session uses Shared or Dedicated servers is determined by the database/service configuration (e.g., service-level dispatchers, SHARED_SERVERS, DISPATCHERS) when you connect. Ending a session simply returns server-side resources to the pool.

When to use each command

• Use DISCONNECT if you want to end the current session, then connect again (perhaps as a different user or to a different service) without closing SQL*Plus.
• Use EXIT when you are done with SQL*Plus entirely (scripts completed, cleanup finished).

Typical workflows

1) Connect, do work, then DISCONNECT (stay in SQL*Plus)

-- Local admin (OS authentication)
sqlplus / AS SYSDBA

\-- or user/service with Easy Connect Plus:
sqlplus scott@//dbhost.example.com:1521/finance.example.com

\-- ...run statements...
DISCONNECT

\-- You are now at the SQL> prompt without an active session
\-- You can CONNECT again, or EXIT to close SQL\*Plus. 

2) Connect, do work, then EXIT (close SQL*Plus)

sqlplus scott@//dbhost.example.com:1521/finance.example.com
-- ...run statements...
EXIT

How to tell if your session used Shared Server

Shared vs. Dedicated is a property of the session you established. To inspect from the server side:

-- As a DBA, check your own session:
SELECT s.sid, s.serial#, s.server
FROM   v$session s
WHERE  s.audsid = USERENV('SESSIONID');

\-- Result: SERVER column shows DEDICATED or SHARED 

Quick checks and clean shutdown of a session

Before disconnecting, it’s good practice to finish any spooling or long operations:

-- Optional: capture output
SPOOL /tmp/session_log.txt

\-- Your work here...
\-- SELECT ... ; DDL; etc.

SPOOL OFF
DISCONNECT
\-- or EXIT 

Common myths (debunked)

• Myth: “You must use DISCONNECT to leave Shared Server.”
  Fact: You don’t “leave” Shared Server with a client command. You end a session (DISCONNECT or EXIT) and, if you reconnect to a service configured for dedicated servers, you’ll get a dedicated session next time.
• Myth: “EXIT is not allowed with Shared Server.”
  Fact: EXIT is allowed; it terminates the session and closes SQL*Plus.

Optional: lightweight reconnection pattern

Use DISCONNECT to swap identities/services without relaunching SQL*Plus:

-- Stay in SQL*Plus; flip between services or users
DISCONNECT
CONNECT app_user@//dbhost:1521/reporting.example.com
-- work ...
DISCONNECT
CONNECT / AS SYSDBA
-- finish admin steps ...
EXIT

Environment startup snippets (shell)

Keep them minimal and per-shell; avoid outdated per-OS lists. Example (bash/ksh):

# ~/.profile (or ~/.bash_profile)
export ORACLE_SID=FIN01
export ORACLE_HOME=$(/usr/bin/awk -F: -v s="$ORACLE_SID" '$1==s{print $2}' /etc/oratab)
export PATH="$ORACLE_HOME/bin:$PATH"

Suggested <title>: Oracle SQL*Plus DISCONNECT vs EXIT - Correct Usage with Shared Server

Suggested meta description: Learn the real difference between DISCONNECT and EXIT in SQL*Plus, how they release resources with Shared Server, and simple checks to see your session mode. Includes safe snippets and reconnection patterns.