Purpose and Function of the Oracle Process Monitor (PMON)

The Process Monitor (PMON) is a vital background process in Oracle databases, acting as a "cleanup crew" to maintain the system's health and stability. Let me break down its key responsibilities for clarity:

1. Process Recovery: PMON cleans up after terminated user processes. If a user session ends abnormally (e.g., due to a crash or network failure), PMON rolls back uncommitted transactions, releases locks, and frees up resources tied to that session.
2. Memory Management: It reclaims memory allocated to failed processes, ensuring that the database doesn't run out of resources due to dangling or "zombie" processes.
3. Listener Registration: PMON dynamically registers database services with the Oracle Net Listener, facilitating client connections to the database instance. This ensures that the listener always has up-to-date information about available services.
4. Instance Recovery: In a Real Application Clusters (RAC) environment or after a database crash, PMON assists in coordinating recovery by releasing resources held by failed instances.

Essentially, PMON keeps the database environment tidy and responsive by handling the aftermath of disruptions and maintaining connectivity. Without it, you'd see resource leaks, locked objects, and connection issues pile up fast.

The Process Monitor (PMON) process does the same sort of thing for user processes that SMON does for the instance, it takes care of various cleanup operations. Whenever a user process is abnormally terminated, PMON does the following:

1. Releases any locks that may have been held by the user process
2. Removes the process ID from the list of active processes
3. Rolls back any open transactions for the process

If the multi-threaded server option is being used, PMON will also periodically check to be sure that the neccessary dispatcher processes are running.
The process monitor (PMON) performs process recovery when a user process fails. PMON is responsible for

1. cleaning up the database buffer cache and
2. freeing resources that the user process was using.

For example, it resets the status of the active transaction table, releases locks, and removes the process ID from the list of active processes. PMON periodically checks the status of dispatcher and server processes, and restarts any that have stopped running (but not any that Oracle has terminated intentionally). PMON also registers information about the instance and dispatcher processes with the network listener.
If a user process terminates abnormally, PMON is responsible for cleaning up any of the resources left behind (such as memory) and for releasing any locks held by the failed process.
Like SMON, PMON checks regularly to see whether it is needed and can be called if another process detects the need for it.

In an Oracle Real Application Clusters (RAC) environment, the Process Monitor (PMON) takes on an expanded role to ensure the stability and coordination of the clustered database system. RAC allows multiple instances (running on separate nodes) to access a single shared database, and PMON plays a critical part in maintaining consistency and resource management across these nodes. Here’s how PMON functions in RAC:

1. Instance Failure Detection and Recovery:
   • PMON helps detect when an instance in the RAC cluster fails. It works in conjunction with the clusterware (e.g., Oracle Clusterware) and other processes like the Global Cache Service (GCS) to identify node or instance crashes.
   • Upon detecting a failure, PMON participates in instance recovery by cleaning up resources locked or held by the failed instance. This includes rolling back uncommitted transactions from the failed node and releasing any associated locks.
2. Global Resource Cleanup:
   • In RAC, resources like data blocks and locks are shared across instances via the Global Resource Directory (GRD), managed by processes like the Global Enqueue Service (GES) and GCS. If an instance fails, PMON ensures that locally held resources (e.g., enqueues or buffers) are released, allowing surviving instances to take over without conflicts.
   • This cleanup prevents deadlocks or resource contention that could otherwise stall the cluster.
3. Dynamic Service Registration:
   • PMON continues its role of registering services with the Oracle Net Listener, but in RAC, this extends to the cluster-wide listener infrastructure (e.g., SCAN listeners). It ensures that client connections are directed to surviving instances after a failure, supporting load balancing and failover.
4. Coordination with Cluster Synchronization Services (CSS):
   • PMON interacts with the Cluster Synchronization Services to maintain cluster health. For example, if a node is evicted from the cluster (due to network issues or timeouts), PMON on the surviving nodes helps reconfigure the cluster by updating resource ownership and session states.
5. Support for Failover and Load Balancing:
   • When an instance fails, PMON on the remaining nodes assists in redistributing the workload. It ensures that sessions connected to the failed instance can failover to another instance (if configured with Transparent Application Failover, or TAF) by releasing resources and updating service availability.

Example Scenario
Imagine a three-node RAC setup. If Node 2 crashes, PMON on Nodes 1 and 3 detects the failure (via clusterware alerts) and:

• Rolls back any uncommitted transactions from Node 2’s sessions.
• Releases locks on data blocks held by Node 2, allowing Nodes 1 and 3 to access them.
• Updates the listener configuration so new connections are routed to the surviving nodes.

Key Difference from Single Instance: In a single-instance database, PMON’s recovery duties are limited to local process cleanup. In RAC, its scope expands to cluster-wide coordination, making it essential for high availability and scalability.

Click the Quiz link below to take a short quiz and review what you have learned about PMON, SMON, and the SGA.
Pmon Smon Sga -Quiz