Oracle Process Monitor (PMON): Responsibilities, RAC Notes, and Troubleshooting

PMON (Process MONitor) is an Oracle background process that keeps the instance tidy and available. It cleans up after failed sessions, releases resources, and keeps the listener informed about services so clients can connect reliably. PMON starts with the instance and runs until shutdown.

What PMON actually does

• Process cleanup (process recovery) - When a user/server process dies unexpectedly, PMON:
  • Rolls back its uncommitted work (via the transaction/undo tables).
  • Releases row/table locks and other enqueues held by the dead process.
  • Removes the process from the instance’s active structures.
• Listener/service registration - PMON dynamically registers the instance and its services with the Oracle Net listener(s) (service names, instance name, dispatcher endpoints, etc.) so new clients can connect without static listener.ora entries.
• Shared Server health checks - In Shared Server (MTS), PMON periodically checks that dispatchers and shared servers are available and can restart them if they’ve failed (not if Oracle terminated them intentionally).

Common misconceptions (what PMON does not do)

• Instance recovery - That’s SMON, which rolls forward/rolls back during instance startup (and in RAC, a surviving instance’s SMON may recover a failed instance).
• Buffer cache management - DBWn, LGWR, CKPT, and server processes govern cache/redo I/O; PMON does not “tune” the cache.
• Distributed TXN resolution - The RECO process resolves in-doubt distributed transactions, not PMON.
• Deadlock detection - The lock manager detects and resolves deadlocks during statement execution; PMON is not involved.

PMON in Oracle RAC

In RAC, PMON’s core duties remain the same (local process cleanup and dynamic registration). Cluster membership, global locks, and instance failover are handled by Clusterware and GES/GCS. Ensure correct service registration across SCAN listeners so connections load-balance and fail over cleanly.

Service registration checklist

• Set SERVICE_NAMES appropriately (may be multiple, e.g., OLTP/REPORTING).
• For single-instance: set LOCAL_LISTENER (host:port or a TNS alias).
• For RAC: set REMOTE_LISTENER to your SCAN (e.g., scan-cluster:1521 or a TNS alias).

-- Inspect current values
SHOW PARAMETER service_names
SHOW PARAMETER local_listener
SHOW PARAMETER remote_listener

-- Example: use a TNS alias for LOCAL_LISTENER (single-instance)
ALTER SYSTEM SET local_listener = 'LISTENER_DB1' SCOPE=BOTH;

-- Example: RAC uses SCAN for REMOTE_LISTENER
ALTER SYSTEM SET remote_listener = 'SCAN_LISTENERS' SCOPE=BOTH;

-- After changes, PMON will re-register; or prompt it:
ALTER SYSTEM REGISTER;

Troubleshooting playbook

• Clients can’t connect / service missing in lsnrctl status: verify SERVICE_NAMES, LOCAL_LISTENER/REMOTE_LISTENER; run ALTER SYSTEM REGISTER.
• Orphaned locks after session crash: PMON usually releases them quickly; confirm with V$LOCK/DBA_BLOCKERS/DBA_WAITERS.
• Shared Server endpoints not advertising: check dispatcher count and status; PMON restarts failed ones when appropriate.

-- Show PMON background process (naming varies by platform)
SELECT p.pid, p.spid, p.pname

FROM   v$bgprocess b
JOIN   v$process   p ON b.paddr = p.addr
WHERE  b.name = 'PMON';

-- Sessions recently killed or dead (investigate lingering locks/resources)
SELECT sid, serial#, status, username, program
FROM   v$session
WHERE  status IN ('KILLED','SNIPED')
ORDER BY status;

-- Locks held/waited (high-level view)
SELECT s.sid, s.serial#, l.type, l.mode_held, l.mode_requested, l.block
FROM   v$lock l
JOIN   v$session s ON s.sid = l.sid
ORDER BY l.block DESC, s.sid;

-- Dispatcher and Shared Server health (Shared Server only)
SELECT name, paddr, status, (busy/(busy+idle)) AS busy_ratio
FROM   v$dispatcher;

SELECT name, status, requests
FROM   v$shared_server;

Operational guidance

1. Keep dynamic registration healthy; prefer TNS aliases for listener params so you can change endpoints centrally.
2. Use Shared Server only when it matches the workload profile; else dedicated servers are simpler and predictable.
3. When diagnosing “connection flaps,” check alert log timestamps against listener logs and PMON re-registration events.
4. In RAC, validate service goals (TPC/TAF/FAN) and that services are offered on the intended instances.

Key takeaway: PMON is your automatic janitor and service herald-cleaning up failed sessions and keeping listeners in sync-while SMON handles instance recovery and RECO resolves distributed transactions.

PMON SMON SGA - Quiz