Wednesday, January 7, 2026

Interview Question 9 : Dedicated Server vs Shared Server user connectivity

 

1️⃣ Dedicated Server vs Shared Server (DBA Deep Dive)

Dedicated Server

What It Is

  • One client session → one server process
  • Server process handles only that session
Client ─── Dedicated Server Process ─── Instance

Characteristics

  • Fast response time
  • Simple architecture
  • High memory consumption (PGA per session)

When DBAs Use It

✅ OLTP systems
✅ Low–medium number of concurrent users
✅ High‑performance workloads

Pros / Cons

ProsCons
FastHigh memory usage
Easy to manageLimited scalability
Predictable performanceMore OS processes

Shared Server

What It Is

  • Multiple client sessions share a pool of server processes
  • Uses dispatcher processes
Clients
  ↓
Dispatchers
  ↓
Shared Server Processes
  ↓
Instance

Key Components

  • Dispatchers (network-facing)
  • Shared server processes
  • Large pool (SGA usage increases, PGA decreases)

When DBAs Use It

✅ Thousands of users
✅ Call centers
✅ Chatty applications

Pros / Cons

ProsCons
Scales wellSlight overhead
Lower memoryMore complexity
Fewer processesNot ideal for large batch jobs

DBA Rule of Thumb

Dedicated = performance
Shared = scalability


2️⃣ Listener vs Local Listener vs SCAN (Very Important)

Listener (Single Instance)

  • Network gateway into Oracle
  • Listens on port 1521
  • Hands off connection → server process
Client → Listener → Server Process → Instance

✅ Listener does NOT run SQL
✅ Not involved after connection


Local Listener (RAC)

  • Node‑specific listener
  • Bound to node VIP
  • Accepts redirected connections from SCAN

One per node.


SCAN Listener (RAC)

What Is SCAN?

Single Client Access Name

  • Cluster‑level hostname
  • Resolves to 3 IPs
  • Never changes

Why SCAN Exists

  • HA
  • Load balancing
  • Zero client reconfiguration
Client
  ↓
SCAN Listener
  ↓ (redirect)
Local Listener (Node)
  ↓
Instance

Clients never connect directly to nodes in RAC


Comparison Table

ComponentSingle InstanceRAC
ListenerYesYes
Local ListenerNoYes
SCAN ListenerNoYes
Client visibilityHostSCAN only

3️⃣ What Happens During COMMIT in Oracle RAC (GCS / GES)

This is senior DBA / architect‑level knowledge.


Key RAC Components

GES (Global Enqueue Service)

  • Manages locks across instances
  • Ensures consistency

GCS (Global Cache Service)

  • Manages data blocks in memory across instances
  • Prevents corruption

COMMIT Flow in RAC

Step‑by‑Step

  1. User issues COMMIT
  2. Redo entries written to redo log buffer
  3. LGWR writes redo to disk
  4. GES confirms global locks
  5. GCS ensures all instances see consistent block state
  6. Commit acknowledged to user

Why RAC COMMIT Is Slower Than Single Instance

Reason
Global lock coordination
Inter‑instance messaging
Cache fusion traffic

✅ Still extremely fast — but architecturally more complex


Important DBA Insight

COMMIT works at cluster level in RAC, not just instance level.


4️⃣ Session vs Process vs Thread (Top Interview Confusion)

Session

  • Logical
  • Represents user context
  • Stored in SGA
  • Contains:
    • User
    • Privileges
    • SQL state

✅ Session exists after login


Process

  • OS‑level entity
  • Executes SQL
  • Exists for work execution

Types:

  • Server process
  • Background process

✅ Can exist without session (background)


Thread

  • Lightweight execution unit inside a process
  • Common in Windows / multithreaded systems
  • Rarely visible to Oracle admins

Mapping Table

ConceptNatureExists Where
SessionLogicalSGA
ProcessPhysicalOS
ThreadExecution unitInside process

Relationship (Dedicated Server)

1 Session ↔ 1 Server Process

Relationship (Shared Server)

Many Sessions ↔ Few Server Processes

5️⃣ Interview Q&A: Oracle Connectivity

Q1: Do users connect to the database or instance?

Instance


Q2: Does listener execute SQL?

❌ No
✅ Only hand‑off


Q3: What happens if listener goes down?

✅ Existing sessions continue
❌ New connections fail


Q4: What does a service represent?

✅ Logical workload boundary
✅ Not tied to a specific instance


Q5: Can one database have multiple services?

✅ Yes (OLTP, Reporting, Batch)


Q6: Can one instance serve multiple services?

✅ Yes


One‑Line Interview Killers

  • “Users connect to services, not instances.”
  • “Listener is not in the data path after connection.”
  • “Session is logical, process is physical.”
  • “RAC commits involve cluster‑wide coordination.”
  • “SCAN gives HA without client changes.”

Final Mental Model (Everything Together)

Client
 ↓
Service
 ↓
Listener / SCAN
 ↓
Server Process
 ↓
Session
 ↓
Instance
 ↓
Database



1️⃣ Oracle Memory Model in Connectivity (SGA vs PGA)

Understanding who uses what memory and when is critical for DBAs.


SGA (System Global Area)

Shared memory used by all sessions connected to the instance.

Key Connectivity‑Related Components

🔹 Shared Pool

  • Stores:
    • Parsed SQL
    • Execution plans
    • Data dictionary cache
  • Shared across all sessions

✅ High shared pool efficiency = faster logins & SQL reuse


🔹 Database Buffer Cache

  • Stores data blocks read from disk
  • Impacted heavily by:
    • Number of users
    • Access patterns
    • LRU behavior

✅ Connectivity + workload decides cache pressure


PGA (Process Global Area)

Private memory for each server process.

Usage Depends on Server Mode

ModePGA Usage
Dedicated ServerHigh (1 PGA per session)
Shared ServerLower (shared execution)

PGA Stores:

  • Sort areas
  • Session variables
  • Cursor state

✅ Too many dedicated sessions → PGA exhaustion


DBA Insight

Connection strategy directly determines memory scalability.


2️⃣ Oracle Cache Fusion (RAC Internals – Must‑Know)

Cache Fusion is why RAC works safely.


What Is Cache Fusion?

Cache Fusion allows instances to share data blocks directly from memory instead of writing to disk.


Scenario Without Cache Fusion (Old Clusters)

Instance 1 → Disk → Instance 2 (slow)

With Cache Fusion

Instance 1 → Interconnect → Instance 2 (fast)

How It Works

  1. Instance A modifies a block
  2. Instance B requests the same block
  3. GCS coordinates ownership
  4. Block transferred over cluster interconnect
  5. No disk I/O required

✅ Faster
✅ ACID‑compliant
✅ No data corruption


RAC Performance Reality

Good InterconnectPoor Interconnect
RAC is fastRAC is slow
Low gc waitsHigh gc waits
PredictableUnstable

DBA Key Metrics

  • gc cr block receive time
  • gc current block busy
  • Interconnect latency

3️⃣ Real‑World RAC & Connectivity Troubleshooting


Problem 1: Users Can’t Connect, Database Is UP

Possible Causes

  • Listener down
  • Service not registered
  • SCAN misconfigured

DBA Checks

lsnrctl status
srvctl status service

✅ Instance UP ≠ Database Accessible


Problem 2: Connections Are Slow

Root Causes

  • Shared pool contention
  • DNS / SCAN latency
  • Excessive session creation

DBA Fixes

  • Connection pooling
  • Increase shared pool
  • Fix DNS resolution

Problem 3: Sudden RAC Performance Drop

Common Reasons

  • Cross‑instance block pinging
  • Hot table accessed from many nodes
  • Poor service affinity

✅ Bind services to workload patterns


4️⃣ Session Leaks & Connection Pool Issues (Very Common)


What Is a Session Leak?

  • Application opens sessions
  • Does not close them
  • Instance memory grows
  • Eventually hits process/session limits

Symptoms

  • Thousands of inactive sessions
  • Memory pressure
  • ORA‑00020 (processes exceeded)

DBA Solution

  • Enforce connection pooling
  • Idle timeouts
  • Proper app close logic

✅ DBAs fix symptoms
✅ Developers fix root cause


5️⃣ Full Interview Mock Q&A (Senior DBA / Architect)


Q1: Do users connect to database files?

❌ No
✅ To the instance via a server process


Q2: What breaks existing sessions if listener crashes?

❌ Nothing
✅ Listener is not in the data path


Q3: Why doesn’t RAC cause data corruption?

✅ Cache Fusion + GCS + GES


Q4: Which memory grows with users?

✅ PGA (especially dedicated server)


Q5: When would you avoid shared server?

✅ Long‑running queries
✅ Batch jobs
✅ High PGA workloads


Q6: Can one service run on multiple instances?

✅ Yes (normal RAC design)


Interview Killer One‑Liners

  • “Listener is only for connection establishment.”
  • “Users connect to services, not instances.”
  • “Session is logical, process is physical.”
  • “Cache Fusion eliminates disk I/O in RAC block transfers.”
  • “Dedicated server consumes PGA per session.”

6️⃣ Mental Model: End‑to‑End Oracle Connectivity

Client
 ↓
DNS / SCAN
 ↓
Listener
 ↓
Server Process
 ↓
Session
 ↓
SGA + PGA
 ↓
Instance
 ↓
Database

7️⃣ Architect‑Level Takeaway

Connectivity design is not a networking topic — it directly impacts memory, performance, scalability, and RAC stability.


Interview Question 8 : How User Connectivity Works in Oracle RAC ?

Oracle RAC (Real Application Clusters) allows multiple instances to access one single database. User connectivity in RAC is designed for high availability, scalability, and load balancing.


1. RAC Connectivity at a High Level

In a RAC environment:

  • One database
  • Multiple instances
  • Multiple nodes (servers)
  • Users connect to a service, not a specific instance
Client
  ↓
SCAN Listener
  ↓
Local Listener (Node-level)
  ↓
Instance (Node 1 / Node 2 / Node N)
  ↓
Single RAC Database

2. Key Components Involved in RAC Connectivity

1️⃣ SCAN (Single Client Access Name)

  • A cluster-level virtual hostname
  • Resolves to multiple IP addresses
  • Acts as the initial entry point for all clients

Example:

scan.prod.example.com

✅ Clients always connect using SCAN, not node hostnames.


2️⃣ SCAN Listener

  • Runs on multiple cluster nodes
  • Listens on default port 1521
  • Redirects connections to the appropriate node

Purpose:

  • Load balancing
  • HA during node failures

3️⃣ Local Listener

  • Runs on each RAC node
  • Bound to the node’s VIP
  • Accepts redirected connections from SCAN listener

Each instance registers its services with:

  • SCAN listener
  • Local listener (via PMON)

4️⃣ Services (Very Important)

In RAC:

  • Services, not instances, define workload behavior
  • A service can run on:
    • One instance
    • Multiple instances

Examples:

  • oltp_service
  • reporting_service

Services support:

  • Load balancing
  • Failover
  • Workload isolation

3. Step‑by‑Step RAC Connection Flow

Step 1: Client Initiates Connection

sqlplus user/password@scan.prod.example.com:1521/prod_service

Client only knows:

  • SCAN name
  • Port
  • Service name

Step 2: DNS Resolves SCAN Name

SCAN resolves to multiple IPs:

scan → IP1, IP2, IP3

Client randomly picks one.

✅ This provides client‑side load balancing.


Step 3: SCAN Listener Receives Request

SCAN listener:

  • Knows which instances are available
  • Knows which services run where
  • Chooses the best node based on load

Step 4: Connection Redirect to Local Listener

SCAN listener redirects the client to:

  • Specific node
  • Node’s local listener
  • Node VIP

Listener hand‑off completes here.


Step 5: Server Process Is Created

On the chosen node:

  • Dedicated or shared server process is created
  • Session is established in the local instance

✅ From now on:

  • Client talks directly to that instance
  • SCAN listener is no longer involved

4. What Happens During Node or Instance Failure?

Instance Failure

✅ Existing sessions on failed instance:

  • Disconnected
  • Rolled back

✅ New connections:

  • Automatically routed to surviving instances

Service‑Aware Failover (TAF / FAN / ONS)

Oracle supports:

  • TAF (Transparent Application Failover)
  • FAN (Fast Application Notification)

These allow:

  • Faster reconnect
  • Smarter connection pool behavior

5. Dedicated vs Shared Server in RAC

Same concepts apply, but multiplied:

TypeRAC Impact
Dedicated ServerHigher memory, simpler
Shared ServerBetter scalability for thousands of users

6. Why SCAN Is Critical (DBA Perspective)

Without SCAN:

  • Client configs change during node add/remove
  • Poor HA

With SCAN:

  • Client config never changes
  • Nodes can be added or removed dynamically

SCAN = zero‑touch client configuration


7. Comparison: Single Instance vs RAC Connectivity

AspectSingle InstanceRAC
Entry pointListenerSCAN Listener
InstancesOneMultiple
ServicesOptionalMandatory
Load balancingLimitedBuilt‑in
HALowHigh

8. Common RAC Connectivity Errors (DBA View)

ErrorMeaning
ORA‑12514Service not registered
ORA‑12541Listener not reachable
ORA‑12170Timeout
Sessions stuckFAN not configured

9. Interview‑Ready RAC Answer (2–3 Lines)

In Oracle RAC, clients connect using a SCAN address and service name. The SCAN listener routes the connection to the least‑loaded instance via the node’s local listener, where a server process creates a user session against the shared RAC database.


10. One‑Line DBA Golden Rule

🔥 Clients connect to services via SCAN—not to instances or nodes in RAC.

Interview Question 7 : Explain how user connectivity happens in oracle database ?

Below is a DBA‑oriented, step‑by‑step explanation of how user connectivity happens in an Oracle Database, from the moment a user runs a client tool until a database session is established.


How User Connectivity Happens in Oracle Database

High‑Level Overview

Oracle follows a client–server architecture.
A user never connects directly to database files—they connect to an Oracle instance via a listener, which then creates a server process and a session.

User / Application
        ↓
Oracle Client
        ↓
Oracle Listener
        ↓
Server Process
        ↓
Oracle Instance
        ↓
Database (Datafiles)

1. User Initiates a Connection (Client Side)

The process starts when a user runs a database client, such as:

  • SQL*Plus
  • SQL Developer
  • JDBC application
  • Python / OCI / ODBC program

Example Connection Request

sqlplus scott/tiger@prod_db

From the client side, the following information is supplied:

  • Username
  • Password
  • Connect identifier (service name / TNS alias)
  • Database host and port

2. Client Resolves Connect Identifier

Oracle must translate the connect identifier to network details.

Resolution Methods (in order)

  1. tnsnames.ora
  2. LDAP directory
  3. Easy Connect (host:port/service_name)

Example (tnsnames.ora)

PROD_DB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL=TCP)(HOST=dbserver)(PORT=1521))
(CONNECT_DATA =
(SERVICE_NAME=prod)
)
)

✅ At this point, the client knows where the database listener is located.


3. Client Sends Connection Request to Oracle Listener

The client sends a connection request to:

  • Oracle Net Listener
  • Running on the database server
  • Listening on a specific port (default 1521)

Listener Responsibilities

  • Accept incoming client requests
  • Identify the requested service
  • Hand off the request to the database instance

✅ The listener does NOT process queries.


4. Listener Identifies the Requested Service

Oracle databases expose services, not instances.

Service Mapping

  • A service is registered with the listener
  • Can be:
    • Static (listener.ora)
    • Dynamic (PMON registration)

Listener checks:

  • Is the service available?
  • Is the instance accepting connections?

If valid → listener proceeds.


5. Server Process Is Spawned or Assigned

Once the listener accepts the connection, it:

  • Creates or assigns a server process
  • Then hands off communication to that process
  • Listener is no longer involved

Server Process Types

TypeDescription
Dedicated ServerOne process per user session
Shared ServerMultiple sessions share processes

✅ From a DBA view, this choice impacts scalability and memory usage.


6. Session Is Created Inside the Instance

Once the server process is assigned:

  1. Server process connects to the Oracle instance
  2. User credentials are validated
  3. A session is created in memory (SGA)

Key Internal Structures Used

  • Shared Pool (SQL, metadata)
  • PGA (session-specific data)
  • Data Dictionary cache

📌 Session ≠ Process

  • Session = logical
  • Server process = physical

7. Authentication Happens

Oracle validates credentials via:

  • Database authentication (username/password)
  • OS authentication
  • External services (Kerberos, LDAP)

If authentication fails:

  • Connection is rejected
  • No session created

8. User Is Connected (Session Established)

At this stage:

  • User is connected to the instance
  • SQL statements can be executed
  • Transactions can begin
User → Client → Server Process → Session → Instance → Database

9. Request Processing (After Connection)

For every SQL command:

  1. Statement sent to server process
  2. Parsed in shared pool
  3. Data blocks accessed in buffer cache
  4. Results returned to client

The listener is not involved anymore.


10. Disconnection Flow

When the user:

  • Exits the client
  • Closes the application
  • Session times out

Then:

  • Session is destroyed
  • Server process is released
  • PGA memory is freed

Key Oracle Connectivity Components Summary

ComponentRole
ClientInitiates connection
Oracle NetNetwork communication
ListenerAccepts and routes connections
ServiceLogical database access point
Server ProcessExecutes SQL
SessionLogical user context
InstanceProcesses data
DatabaseStores data

Dedicated vs Shared Server (Connectivity Impact)

Dedicated Server

  • Fast
  • High memory usage
  • Common for OLTP

Shared Server

  • Efficient resource usage
  • Slight overhead
  • Good for thousands of users

✅ DBAs choose based on workload.


One‑Line DBA Summary (Interview‑Perfect)

In Oracle, user connectivity occurs when a client connects to a listener, which assigns a server process that creates a session within the database instance, enabling the user to execute SQL against the database.


Common DBA Troubleshooting Points

IssueLayer
ORA‑12514 / ORA‑12541Listener
ORA‑01017Authentication
Too many processesInstance
Connection slownessNetwork / server processes
Session leaksApplication side

Final Conceptual Analogy

📞 Call Center Analogy

  • Client = Phone
  • Listener = Receptionist
  • Server Process = Agent
  • Session = Active call
  • Instance = Call center system
  • Database = Records archive

what is catcon.pl (Catalog Container Script) and why very useful for Oracle Multitenant Database ?

  catcon.pl (Catalog Container Script) is an Oracle utility introduced with the Multitenant Architecture (CDB/PDB) to execute SQL scripts ...