Oracle Background Processes

In an earlier lesson we presented a diagram identifying various components of the Oracle instance. Among the processes in that diagram were the six that keep a typical read and write instance running:

1. PMON
2. SMON
3. DBW
4. LGWR
5. CKPT
6. ARCn

All six reside inside the instance itself. There are also two groups of processes that live outside the instance and exist to carry user requests to it and back.
The first group is the set of client or user processes: the applications, SQL*Plus sessions, or JDBC connections that actually request information. The second group is the set of server processes that carry those requests to the instance and return results. A restaurant makes a decent analogy. Customers arriving for lunch are the client processes. A server takes the order and passes it along to the kitchen, which is the instance itself doing the actual work; once the order is ready, the server brings the food back to the table. The client process asks, the instance does the work, and a server process carries the answer back.
Of the six background processes above, PMON, SMON, DBW, LGWR, and CKPT are created automatically whenever an instance starts. ARCn is the one optional process in the group: it only runs when the database is in ARCHIVELOG mode with automatic archiving enabled. The rest of this lesson walks through what each of these six actually does, then closes with a simple query against V$PROCESS, the view that lets you actually see these processes running on your own system.

DBW (you will also see it written DBWn, since a system can run more than one) writes modified, or "dirty," buffers from the database buffer cache out to the data files. One detail trips up almost everyone learning this for the first time: DBW does not write on every commit. A commit only requires the redo describing that change to be durable, which is LGWR's job, not DBW's. DBW writes later, for efficiency, when a server process can't find a clean reusable buffer after scanning far enough into the cache, or periodically to advance the checkpoint position, the point in the redo stream from which instance recovery would need to begin.
One DBW0 process is enough for most systems, but on a heavily-written system you can configure additional writers via DB_WRITER_PROCESSES: DBW1 through DBW9, then DBWa through DBWz, and beyond that BW36 through BW99. These additional writers only help on genuinely multi-processor, heavily-modified systems; they won't do anything useful on a small or lightly-loaded instance. If DBW can't keep up with the rate of dirty buffers accumulating, you'll typically see free buffer waits and longer checkpoint activity as symptoms, both signs worth recognizing if you ever find yourself troubleshooting a sluggish instance later in your career. In practice, most of DBW's writes are scattered across disk rather than sequential, since dirty buffers rarely correspond to physically adjacent blocks on disk; DBW does perform multiblock writes where the operating system allows it, which helps offset that scattered access pattern somewhat.

LGWR writes redo entries from the redo log buffer out to the online redo log files, and this is the process that actually makes a commit durable, the "D" in ACID. LGWR flushes everything copied into the buffer since its last write whenever any of the following happens: a user commits a transaction, an online redo log switch occurs, three seconds have passed since LGWR last wrote, the redo log buffer becomes one-third full or accumulates 1 MB of buffered data, or DBW needs to write a dirty buffer whose protecting redo hasn't been written yet. That last condition is the write-ahead logging rule in action: Oracle will not let a modified data block reach disk before the redo describing that modification does. It's worth contrasting LGWR's write pattern with DBW's directly: LGWR writes sequentially to the redo log, which is inherently faster than DBW's scattered writes across data files, and that speed difference is exactly why Oracle separates the two jobs into different processes in the first place rather than having one process handle both.
If your redo logs are multiplexed, meaning each log group has multiple identical members, LGWR writes the same redo synchronously to every member of the active group, which is exactly what protects you if one copy becomes inaccessible. LGWR is mandatory; if it fails, the instance aborts, because there is no way to guarantee committed data is safe without it.

SMON handles instance-level cleanup and recovery. Its main duties are performing instance recovery after a crash, replaying redo from the last checkpoint forward and then rolling back anything left uncommitted; cleaning up temporary segments left behind by failed or aborted operations, for instance when an index creation fails partway through; and coalescing contiguous free extents within dictionary-managed tablespaces, a legacy tablespace type that's uncommon today but still supported and still something SMON handles when it exists. In a Real Application Clusters environment, one instance's SMON can also step in to help recover a different instance that has failed. SMON is mandatory; without it, an instance generally cannot stay up.

PMON watches for failed processes and cleans up after them, though it isn't really a single process so much as a small team. PMON itself detects when a server or dispatcher process has died abnormally; the Cleanup Main Process (CLMN) does the actual cleanup work once PMON has flagged the failure; and one or more Cleanup Helper Processes (CLnn) assist CLMN when there's enough work to split up. Together this group releases locks the dead session was holding, rolls back whatever work was left uncommitted, frees buffer cache pins and other resources, and removes the dead process from the instance's list of active processes. This matters more than it might sound like at first: without that cleanup, a single application that crashed mid-transaction could leave rows locked indefinitely, blocking every other session that needed to touch that data, long after the original session itself was gone. PMON is mandatory: without it, a single dropped connection could leave locks and resources hanging indefinitely, and the instance would gradually accumulate orphaned state until something intervened.

CKPT coordinates checkpoints, but it's worth being precise about what that actually means: CKPT does not write data blocks itself. At a checkpoint, CKPT signals DBW to flush dirty buffers, then updates the control file and every data file header with checkpoint information, including the checkpoint position, SCN, and the location in the online redo log where recovery should begin if needed. That update is what shortens instance recovery time, since SMON only has to replay redo generated after the most recently recorded checkpoint rather than the entire redo history. Think of CKPT purely as the coordinator and DBW as the worker actually moving blocks to disk. You can trigger a checkpoint manually with ALTER SYSTEM CHECKPOINT, which is occasionally useful before certain maintenance operations.

ARCn is the one process in this group that's optional, and it exists specifically to support this course's central subject: recovery. When the database runs in ARCHIVELOG mode with automatic archiving enabled, ARCn copies each filled online redo log group to an archive destination, on disk or on external storage, once a log switch has moved on to the next group. In NOARCHIVELOG mode, by contrast, redo logs simply get overwritten once full, and ARCn never runs at all.
Archived redo logs are what make several things possible that online redo logs alone cannot do. They enable media recovery: restoring a damaged or lost data file from backup and then rolling forward using the archived logs to bring it back to a consistent, current state. They enable point-in-time recovery, restoring a database to a specific moment before some unwanted change occurred. And they are exactly what gets shipped to a standby database in a Data Guard configuration, which is how the standby stays synchronized with the primary. If your archive destination ever fills up, be aware that the database can actually hang on the next log switch, since Oracle won't overwrite an unarchived log; monitoring archive destination space is a real, practical concern, not just theory.
A handful of parameters control this process: LOG_ARCHIVE_DEST_n (the modern, numbered form; you may see the older unnumbered LOG_ARCHIVE_DEST in legacy material, but the numbered form is what supports multiple destinations) specifies where archived logs go, LOG_ARCHIVE_FORMAT controls how those archived files get named, LOG_ARCHIVE_MAX_PROCESSES controls how many archiver processes can run concurrently, and ARCHIVE_LAG_TARGET sets a target interval for how often archiving happens, useful for keeping a standby database from falling too far behind. Multiple archiver processes can run simultaneously if a single one can't keep up with archiving demand on a busy system.

It helps to walk through the full sequence once, start to finish. A user makes a change; that change lands in the database buffer cache, and the redo describing it lands in the redo log buffer. On commit, LGWR makes that redo durable by writing it to the online redo logs. Sometime later, DBW writes the actual dirty data block out to its data file, and CKPT periodically records that those writes have reached a consistent checkpoint SCN in the control file and data file headers. If ARCHIVELOG mode is enabled, ARCn preserves each filled redo log group before it gets reused. If an individual session dies, PMON cleans up after it. If the entire instance crashes, SMON recovers it, replaying redo starting from the last checkpoint that CKPT recorded.
It's worth saying plainly that the AI-focused capabilities Oracle AI Database 26ai adds, native vector search, Select AI, autonomous agents, and so on, all sit on top of this same process model. They don't replace PMON, SMON, DBW, LGWR, CKPT, or ARCn; they run as ordinary work inside the same instance these six processes have always managed.
Tie this back to where this course is headed and the relevance becomes concrete rather than abstract. Every RMAN backup you will run later in this module depends on ARCn having faithfully archived redo logs beforehand; a backup strategy without ARCHIVELOG mode enabled simply cannot support point-in-time recovery, no matter how good your RMAN configuration otherwise is. Every instance recovery you will ever witness, intentionally in a lab exercise or unintentionally after a real crash, is SMON replaying redo from the checkpoint CKPT most recently recorded. And every media recovery scenario later in this course, restoring a lost data file and rolling it forward, is really just archived redo logs (ARCn's output) being applied in sequence. None of the backup and recovery tooling ahead of you in this course works around these six processes; it works through them.

You can see these processes directly by querying V$PROCESS, the dynamic performance view that exposes information about every process, background and server alike, currently associated with the instance. A simple starting query looks like this:

SELECT pid, program, background FROM v$process;

This returns each process's internal process ID, the program name associated with it (which is how you'll spot DBW0, LGWR, PMON, and the rest by name), and a flag indicating whether that row is a background process or an ordinary server process. In a multitenant environment you'll also find a CON_ID column identifying which container a given process is associated with. V$PROCESS has grown a great deal over the years, and current versions carry considerably more columns than older Oracle releases did, including detailed PGA memory statistics per process, so it's worth simply querying the view directly in your own environment rather than relying on any fixed column list, this one included.
The next lesson turns to Oracle's database file structures, the physical files these six processes exist to protect.

Before you move on to the next lesson, click the Quiz link below to answer some questions about instances.
Oracle Memory Structures - Quiz