Oracle Instance Structures

The diagram below illustrates the processes and memory structures that make up an Oracle instance. The square boxes represent processes; the circle in the center represents the shared area of memory, the System Global Area (SGA), that all of them read from and write to. Boxes drawn in bold are processes that are mandatory, meaning they are always running whenever a database is open. The remaining processes are optional, and whether any particular one exists on your system depends on which Oracle features you have enabled.
This same structure holds true in Oracle AI Database 26ai, with two changes worth knowing up front. First, several of the classic process names from older Oracle material have changed, and this lesson corrects them so you are not troubleshooting against terminology that no longer matches what you will see in an alert log or in V$PROCESS. Second, 26ai adds a few genuinely new pieces to the picture, most notably a dedicated memory area for AI vector search, which we will cover alongside the classic components rather than as a separate topic.

The SGA in the diagram above is really a collection of smaller, purpose-built memory areas, not one undifferentiated block. The shared pool caches parsed SQL and PL/SQL, the library cache, and the data dictionary cache, which is why a well-sized shared pool cuts down on repeated hard parsing. The database buffer cache holds copies of data blocks recently read from disk, so a session reading the same rows twice usually finds them in memory the second time. The redo log buffer is a small, fast, circular buffer that holds redo entries just before LGWR writes them out to the online redo logs. The large pool handles bigger allocations that would otherwise crowd the shared pool, including RMAN backup and restore buffers and shared-server session memory. Smaller special-purpose pools, such as the Java pool, exist for their respective features.
Oracle AI Database 26ai adds a Vector Pool to this list, a dedicated area of the SGA that stores the in-memory indexes used for native vector search (HNSW indexes, specifically), along with their supporting metadata. It is elastic by design and, on Autonomous AI Database deployments, is managed automatically rather than requiring manual sizing. The exact sizing parameters and limits are still evolving as the feature matures, so if you are configuring this on your own infrastructure rather than an Autonomous deployment, check the current Oracle AI Vector Search documentation for the specific parameter names and defaults rather than relying on any single number here.
Separate from the SGA, each Oracle process, whether a background process or a server process handling a user session, gets its own private Program Global Area (PGA). The PGA is never allocated inside the SGA; it holds things like sort areas, hash join work areas, and private SQL cursor state. In dedicated-server connections, session state itself (the User Global Area, or UGA) also lives in the PGA; in shared-server configurations, the UGA moves into the SGA instead, typically into the large pool.
A newer addition to this picture is the Managed Global Area (MGA). Unlike the SGA, which every server and background process can see, the MGA is a semi-shared memory framework that a small set of trusted Oracle processes attach to on demand. It is configurable, elastic, and reused rather than statically allocated at startup the way the SGA is, and on Linux it is implemented using /dev/shm. Its memory usage counts against the PGA aggregate limit rather than the SGA, which is a useful detail if you are ever trying to reconcile total instance memory against what PGA_AGGREGATE_LIMIT reports.
Finally, 26ai continues to support (and increasingly favors) unified memory management, where a single parameter, MEMORY_SIZE, lets the instance dynamically split memory across the SGA, PGA, MGA, and UGA as workload demands shift, rather than requiring you to separately tune SGA_TARGET and PGA_AGGREGATE_TARGET by hand. You will still find both approaches in production environments; unified memory management is simpler to administer, while manually tuned targets give an experienced DBA more granular control.
Two more pieces round out the full memory picture, even though they rarely come up by name in day-to-day administration. Software code areas are portions of memory, typically shared among processes when the operating system supports it, that store the Oracle executable code itself, the actual compiled programs the instance runs, as distinct from the data those programs operate on. And within the shared pool specifically, a portion is set aside as a reserved pool, held back for unusually large memory allocations so that a single big request does not force the shared pool to age out a large number of smaller, still-useful cached items all at once.

A handful of background processes are always running in any open Oracle AI Database instance, and understanding what each one actually does removes a lot of the mystery from reading an alert log.
The PMON group handles process and session cleanup. It is not a single process but a small team: PMON itself detects when a server or dispatcher process has terminated abnormally, the Cleanup Main Process (CLMN) takes over the actual cleanup work once PMON has flagged the failure, and one or more Cleanup Helper Processes (CLnn) assist CLMN when there is enough work to distribute. Together this group releases locks, resets the status of the active transaction table, and removes terminated processes from the list of active processes, so that one failed connection never leaves the instance holding resources it can no longer use.
PMAN, the Process Manager, oversees a related but distinct set of restartable, feature-driven processes: shared servers and their dispatchers, pooled servers used for Database Resident Connection Pooling, and job queue processes. If one of these needs to be spawned, monitored, or stopped, PMAN is the process responsible.
LREG, the Listener Registration process, registers the instance and its available services with the Oracle Net listener. This is what lets a listener route an incoming connection request to the correct instance without you manually maintaining that mapping.
SMON, the System Monitor, performs instance recovery after a crash, replaying and then rolling back redo as needed, and also handles housekeeping tasks like coalescing free space and cleaning up temporary segments. DBW (sometimes written DBWn, since Oracle can run several numbered database writer processes on a busy system) writes modified, or "dirty," buffers from the database buffer cache back out to the data files. LGWR, the Log Writer, is the process that actually makes a commit durable: it flushes the redo log buffer's contents to the online redo log files, and a transaction is not considered committed until that write succeeds. CKPT, the Checkpoint process, periodically updates the control file and data file headers with checkpoint information, which shortens how much redo SMON has to replay after a future crash.
Rounding out the mandatory core, MMON and MMNL handle Automatic Workload Repository snapshots and related performance metric gathering, and RECO, the Recoverer, automatically resolves in-doubt distributed transactions once communication is reestablished after a network or system failure between databases involved in a two-phase commit.

The remaining processes in the diagram only appear when you are using the corresponding Oracle feature.
ARCn, the Archiver, copies filled online redo log files out to archived redo logs before those online logs get reused, but only when the database is running in ARCHIVELOG mode. This is the single most important process for this course specifically: without archived redo logs, media recovery from a backup is not possible, and you will spend real time with ARCHIVELOG mode once we reach the RMAN portion of the syllabus.
CJQ0, the job queue coordinator, and its child processes Jnnn run scheduled jobs, including automated maintenance tasks and materialized view refreshes. If you have seen older Oracle material refer to a "Snapshot" process, or SNPn, that is the same job the CJQ0/Jnnn pair now performs; SNPn is Oracle 7/8-era terminology that current documentation does not use.
RVWR, the Recovery Writer, writes flashback logs when Flashback Database is enabled, letting you rewind an entire database to a prior point in time without a full restore. FBDA manages the Flashback Data Archive, automatically maintaining historical versions of tracked table data for compliance and auditing use cases. SMCO coordinates automatic space management tasks in the background.
A couple of remaining processes are long-standing, well-known parts of Oracle's architecture even though they did not come up for detailed re-verification in this pass: QMNn, the Queue Monitor, supports Oracle Advanced Queueing, and LCKn handles inter-instance locking in a Real Application Clusters (RAC) environment, where multiple instances share one database. If your environment uses AQ or RAC, you will encounter these by name in your own alert logs.
The Dispatcher (Dnnn) and the Shared Server Process both belong to the shared-server connection model, an alternative to the default dedicated-server model where one server process serves exactly one client session. Under shared servers, dispatchers hand incoming requests off to a smaller pool of shared server processes; note that the shared server process itself is not considered part of the mandatory instance, since dedicated-server connections do not use it at all.

Every Oracle instance reads a parameter file at startup, and it is worth being precise about what that file actually is today.
The classic INIT.ORA file, more formally a text initialization parameter file (sometimes called a PFILE), is still fully supported. It is not deprecated. What has changed is which mechanism Oracle recommends for day-to-day administration. The current, recommended option is the server parameter file, or SPFILE: a binary file that only Oracle itself reads and writes, with exactly one SPFILE per database, stored on the database host. The practical advantage of an SPFILE is that ALTER SYSTEM commands can write parameter changes directly into it, so a change you make while the instance is running can persist automatically across the next restart, without you manually editing a text file yourself. A text init.ora PFILE still works exactly as it always has; it is simply less convenient for ongoing administration, since persisting a change means editing the file by hand rather than letting ALTER SYSTEM do it for you. For a closer look at how SPFILE and PFILE parameters are actually managed day to day, see Additional Database Parameters later in the course.
Either file, SPFILE or PFILE, contains the same kind of content: a list of initialization parameters that control the instance's basic operation, things like the database name, the location of the control files, the database block size, and the size of major memory structures such as the shared pool and the redo log buffer. Changes to most of these parameters only take effect after the instance restarts, though some can be modified dynamically while the instance is running; which category a given parameter falls into is itself documented for every parameter, and is worth checking before you assume a change has taken effect. As you can see, an Oracle instance really is the sum of these memory structures and background processes working in concert. The next lesson explores Oracle instance memory structures in more depth, building directly on the SGA components introduced here.

It is worth drawing the line explicitly from what you just learned to where this course is headed. LGWR and the online redo logs are what make instance recovery automatic after a crash; ARCn and the archived redo logs it produces are what make media recovery from an actual backup possible at all, and only when ARCHIVELOG mode is enabled. CKPT's updates to the control file determine how much redo SMON has to replay, which is part of why a well-tuned checkpoint interval matters for recovery time. Even RECO's narrower job, resolving in-doubt distributed transactions, matters once you start working with Data Guard standby databases later in this course, where keeping multiple databases transactionally consistent is the whole point. None of these processes exist in isolation; they are the same machinery this entire module keeps coming back to, just viewed now from the process side rather than the file side.