Oracle Memory, Processes, and Files: Module Summary

This module opened with a single question: in Oracle terms, when is an instance a database? The answer, as the first lesson argued, is never. An instance and a database are two genuinely different things that happen to cooperate so closely that people talk about them as one. Everything since that first lesson has been an exercise in pulling those two halves apart on purpose: the instance's memory structures and background processes on one side, the database's physical files on the other. This closing lesson pulls the two halves back together and points at where the course goes next.

A database is a set of files on disk: data files, control files, and online redo logs, that store user data whether or not anything is currently running against them. An instance is a named set of memory structures and background processes that manage those files on your behalf. In Oracle AI Database 26ai specifically, every database is a multitenant container database (CDB) holding one or more pluggable databases (PDBs); the old non-container architecture stopped being an option starting with Oracle Database 21c, so this is not a stylistic preference, it is the only supported shape a 26ai database can take.

The library analogy from Lesson 1 is worth keeping: the database is the books on the shelves, present whether the library is open or not; the instance is the staff, the catalog system, and the open reading rooms, which exist only while the library is running. Close the instance and the files remain exactly where they were. That distinction is what makes an instance cheap and disposable (start another one, mount the same database, and you are back in business) while the database itself is the one truly irreplaceable asset in the whole architecture. Real Application Clusters makes the split undeniable: several separate instances, each with its own memory and processes, can mount and operate against one shared set of database files at the same time.

The System Global Area (SGA) is the shared memory every background process and server process can see. Its classic pieces are the shared pool (parsed SQL and PL/SQL, the data dictionary cache), the database buffer cache (recently read data blocks), the redo log buffer (a short-term holding area for redo before LGWR writes it out), and the large pool, which keeps large, bursty allocations like RMAN backup and restore buffers from crowding out smaller, more frequently reused items in the shared pool. Oracle AI Database 26ai adds a Vector Pool to this list, a dedicated area supporting native vector search through HNSW indexes, elastic in how it is managed and automatically sized on Autonomous AI Database deployments.

Not everything is shared, though. Each process, background or server, gets its own private Program Global Area (PGA) for sort areas and cursor state that have no business being visible to other sessions. Under the default dedicated-server model, session state itself, the User Global Area (UGA), lives inside that private PGA; under shared servers it moves into the large pool instead, which is exactly why the large pool matters for XA-coordinated distributed transactions specifically. 26ai also introduces the Managed Global Area (MGA), a semi-shared framework a defined set of trusted processes attach to on demand rather than a statically allocated block like the SGA; its usage counts against the PGA aggregate limit, not the SGA. For sizing all of this, unified memory management lets a single MEMORY_SIZE parameter dynamically divide memory across the SGA, PGA, MGA, and UGA as workload shifts, an alternative to manually tuning SGA_TARGET and PGA_AGGREGATE_TARGET by hand.

An instance's background processes split into a mandatory core, always running whenever a database is open, and an optional set that only appears when a corresponding feature is in use. The mandatory core includes the PMON group (PMON itself, plus the Cleanup Main Process and Cleanup Helper Processes that do the actual work of releasing locks and resources after a failed connection), PMAN (which manages shared servers, pooled servers, and job queue processes), LREG (which registers the instance's services with the listener), SMON (crash recovery and space housekeeping), DBW (writing dirty buffers from the buffer cache to the data files), LGWR (flushing redo to the online redo logs, the one write a commit actually waits on), CKPT (updating the control file and data file headers with checkpoint information), and MMON/MMNL and RECO rounding out the group with AWR snapshots and distributed transaction resolution respectively.

The optional set is feature-driven: ARCn archives filled redo logs when ARCHIVELOG mode is on, CJQ0 and its Jnnn children run scheduled jobs, RVWR and FBDA support Flashback Database and the Flashback Data Archive, SMCO handles automatic space management, QMNn supports Advanced Queueing, and LCKn handles inter-instance locking in RAC. One naming note worth repeating here since it comes up constantly in older material: current Oracle documentation uses DBW/DBWn and ARCn, not the older DBWR and ARCH spellings that still circulate in legacy references. It is a small detail, but precision matters when you are troubleshooting an actual alert log rather than a textbook diagram.

Knowing what a process does is different from knowing when it is struggling, and this module spent real time on that second question because it matters directly for recovery planning. DBW falling behind shows up as free buffer waits, a server process unable to find a clean buffer to use; the usual causes are slow I/O, a buffer cache sized wrong in either direction, or DBW contending with some other resource. ARCn falling behind produces the "archiver stuck" condition: LGWR cannot reuse a redo log group until ARCn has archived it, so if archiving cannot keep pace, the database eventually stalls on the next log switch. Oracle actually names two distinct wait events for that stall, log file switch (archiving needed) pointing at ARCn and log file switch (checkpoint incomplete) pointing at DBW, and knowing which one you are looking at tells you which process to go investigate.

LGWR itself writes redo on commit, on a log switch, when the buffer gets one-third full or hits a megabyte of buffered data, on a roughly three-second timeout, and whenever DBW needs to write a block whose protecting redo has not hit disk yet; that last rule, write-ahead logging, is the whole reason crash recovery works at all. The two wait events worth knowing for LGWR are log file sync (a session waiting on its own commit to flush, usually fixed by batching commits or giving redo logs dedicated, uncontended disks) and log buffer space (server processes waiting for room in the buffer itself, fixed either by enlarging the buffer or by addressing the same disk contention that causes log file sync waits). Redo log sizing affects all three processes at once: undersized logs force more frequent checkpoints and log switches, which pushes both DBW and ARCn harder, while LGWR's own write performance depends on disk speed, not log file size.

CKPT is a coordinator, not a writer: it updates the control file and data file headers with checkpoint information and signals DBW to write the corresponding buffers, but it never touches a data block or a redo entry itself. Checkpoints happen in three distinct categories: thread checkpoints (a consistent shutdown, an explicit ALTER SYSTEM CHECKPOINT, a log switch, or ALTER DATABASE BEGIN BACKUP), tablespace and data file checkpoints (making a tablespace read-only or offline, shrinking a data file, or ALTER TABLESPACE BEGIN BACKUP), and incremental checkpoints, the ongoing background mechanism where DBW checks for work at least every three seconds and advances the checkpoint position a little at a time rather than writing everything in one large batch.

Incremental checkpointing is tuned with FAST_START_MTTR_TARGET, a target mean time to recover in seconds; the older static parameters FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL, and LOG_CHECKPOINT_TIMEOUT predate it and should be disabled once it is in use. One correction from this module is worth restating because it is easy to get backwards: a manual checkpoint issued right before SHUTDOWN ABORT reduces how much redo needs replaying afterward, but it cannot remove the need for instance recovery, since ABORT never checkpoints the open data files regardless of what happened beforehand. The checkpoint SCN also decides whether an RMAN backup is consistent or not: every file sharing the same checkpoint SCN means no recovery is needed after restore, while an online, inconsistent backup depends entirely on ARCHIVELOG mode and archived redo to become usable again.

Not every physical file this module covered is strictly mandatory. A database needs at least one control file to mount, at least one data file and two online redo log groups to open, and a parameter file (PFILE or SPFILE) just to start the instance in NOMOUNT. Everything else, archived redo logs, RMAN backup pieces, the password file, temp files, either supports recovery specifically or can be recreated rather than protected. Backup and recovery material has its own dedicated home, the Fast Recovery Area, set through DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE; it centralizes backup pieces, archived logs, and flashback logs, and 26ai now lets you move flashback logs to a separate, faster location instead of leaving them stuck inside the Fast Recovery Area if write-heavy workloads need it.

Every process and file covered in this module maps directly onto one of two recovery scenarios, and that mapping is the real point of the module. Instance recovery happens automatically after a crash while the database files are still intact: a new instance starts, reads the online redo logs, and rolls the data files forward and then back to a consistent state, no DBA intervention and no backup required. Media recovery is the other case entirely, needed when the files themselves are lost or damaged, and it depends on having an actual backup plus the archived redo logs to roll forward afterward. LGWR and the online redo logs are what make the first kind automatic; ARCn and archived redo logs are what make the second kind possible at all.

The NOMOUNT, MOUNT, and OPEN states this module introduced are not academic either: every RMAN restore and recovery scenario moves through them in order, restoring a lost control file while the instance sits in NOMOUNT, restoring and recovering a lost data file while it sits in MOUNT, before ever reaching OPEN. Keeping the instance and the database mentally separate is what makes that sequence make sense at all, and it is exactly the foundation the rest of this course, RMAN backup sets and recovery windows, Data Guard standby databases, Flashback, and ARCHIVELOG mode itself, is built on.

The next module moves from this architectural foundation into ARCHIVELOG mode and the mechanics of archiving redo for real, the first concrete step toward the RMAN backup and recovery work this entire module has been quietly pointing toward.

Click the Quiz link below to review concepts covered in this module.
Memory Process Files - Quiz