Lesson 1

If you have reached this point in your Oracle training, you have almost certainly heard the terms instance and database used as though they were interchangeable. So here is the question this module is built around: in Oracle land, when is an instance a database?
The answer is never. An instance and a database are two genuinely different things that happen to work so closely together that people talk about them as one. In this module we will separate the two apart deliberately, reviewing the components of the instance (memory structures and background processes) and the components of the database (the files stored on disk), because that split is the conceptual foundation for the rest of this backup and recovery course.
As users and as DBAs, we talk to the instance, not the database directly. An Oracle database is not readable unless there is an instance running to interpret it on our behalf. The database ORCL will always and forever be ORCL; its identity does not change. The instance you use to access that database, however, can change from moment to moment. Our job as Oracle DBAs is to make sure the database remains available to our user community, and we care about the instance mainly to the extent that we use it to back up and recover that database. If an instance dies, we start another one and move on. If the database dies, that is an entirely different, much more serious story, one we will spend the rest of this course preparing for.
By the end of this module you will be comfortable with the following topics:

1. The Oracle instance
2. Oracle memory structures
3. Oracle background processes
4. How PMON, DBW, LGWR, CKPT, and ARCn work together
5. Oracle database file structures

This module will not cover every subtlety of these topics; entire Oracle certification tracks are built around instance internals alone. Our goal here is a high level, working understanding, sufficient to formulate a sound backup and recovery plan later in the course. Once you know what actually lives in memory versus what actually lives on disk, concepts like archivelog mode, RMAN backups, flashback, and Data Guard will make far more sense, because each of them is really just a different strategy for protecting the database files while working around the instance's temporary, restartable nature. So let's get into our investigation of Oracle memory, processes, and files.

Oracle documentation is unusually strict about this vocabulary, and it is worth being just as strict here.
A database is a set of files, located on disk, that store user data. Those data files, control files, and online redo log files can exist on disk whether or not anything is currently running against them. In Oracle AI Database 26ai specifically, "database" refers to the data files belonging to a multitenant container database (CDB), a pluggable database (PDB) inside that CDB, or an application container. That last point is not a minor footnote: starting with Oracle Database 21c, the multitenant architecture is the only supported architecture. Every Oracle AI Database 26ai database is a CDB containing one or more PDBs; the old-style non-container database that many of us learned on no longer exists as an option going forward.
A database instance, usually shortened to just "instance," is a named set of memory structures that manage those database files. Concretely, an instance consists of a shared memory area called the System Global Area (SGA) plus a set of background processes that read from and write to the database files on the instance's behalf. Here is the detail that trips people up: an instance can exist independently of any database files at all. You can start an instance in NOMOUNT mode before it has attached itself to a single control file, and that instance, while technically running, is almost useless until it mounts a database.
A simple picture helps here. Think of the database as a library's books, physically sitting on shelves whether or not the library is open. The instance is the staff, the catalog system, and the reading rooms, all of which exist only while the library is open for business. Close the library and the books remain exactly where they were; the staff and the open reading rooms disappear until someone reopens the doors. Oracle AI Database 26ai's newer AI-native capabilities (Select AI, native vector search, and a dedicated Vector Pool inside the SGA) run inside that same instance, against that same database; they do not change this underlying architecture at all.

The table below summarizes the split we just walked through.

	Instance	Database
What it is	Memory (SGA/PGA) plus background processes	Files on disk (a CDB and its PDBs)
Lifetime	Starts and stops with the running server	Persists across restarts and shutdowns
Purpose	Cache data, execute SQL, recover from crashes, serve user connections	Store the actual, permanent data
Can it exist alone?	Yes, in NOMOUNT state, though not usefully for long	Yes; the files remain even with the instance shut down
Multiple instances?	In Real Application Clusters (RAC), several instances on different hosts	Share one single database

Notice the last row. RAC is the clearest possible proof that instance and database are not the same thing: several completely separate instances, each with its own SGA and its own set of background processes running on its own host, can all mount and operate against one shared set of database files at the same time.

An Oracle instance has exactly two kinds of ingredients: memory structures and background processes. Everything genuinely internal to the instance falls into one of those two buckets.
Memory structures. The System Global Area (SGA) is a large, shared pool of memory allocated when the instance starts, and it is where most of the interesting caching happens. Its major pieces include the shared pool (parsed SQL and PL/SQL, the data dictionary cache), the database buffer cache (copies of data blocks recently read from disk), the redo log buffer (a short-term holding area for redo entries before they are written to disk), the large pool (used for RMAN backup and restore operations, among other things), and smaller special-purpose pools such as the Java pool and the Streams pool. Oracle AI Database 26ai adds a Vector Pool to this list, a dedicated SGA component supporting the platform's native vector search and AI features; the fundamentals of memory management around it work the same way as the rest of the SGA. Separate from the SGA, each server process connecting to the database gets its own private Program Global Area (PGA), memory that is not shared with other sessions and that holds things like sort areas and session-specific cursor state.
Background processes. These are the processes that quietly do the instance's real work in the background, and they are exactly the ones this module's objectives call out by name. PMON, the Process Monitor, cleans up after failed user processes, releasing locks and rolling back incomplete transactions so a single dropped connection does not leave the database in a bad state. DBW (you may also see it written DBWn, since Oracle can run multiple numbered database writer processes on a busy system) writes modified data blocks from the database buffer cache back out to the data files, typically at checkpoints or when the cache needs room. LGWR, the Log Writer, is the one process guaranteed to write to disk before a transaction is considered committed; it flushes redo entries from the redo log buffer out to the online redo log files. CKPT, the Checkpoint process, updates the control file and the data file headers to record the most recent successful checkpoint, which shortens the work required for crash recovery. ARCn, the Archiver process, copies filled online redo log files out to archived redo logs before they get reused, but only when the database is running in ARCHIVELOG mode, a setting you will get to know intimately later in this course.
If that last sentence about legacy naming sounds oddly specific, it is because it matters here: older Oracle material, including some material this course has carried forward from earlier revisions, sometimes labels the database writer DBWR and the archiver ARCH. Those exact spellings do not appear in current Oracle documentation. The correct current forms are DBW/DBWn and ARCn respectively. It is a small naming detail, but precision matters when you are troubleshooting an actual alert log at two in the morning.
Notice how directly this connects to backup and recovery already. LGWR and the online redo logs are what make crash recovery automatic and near-instant. ARCn and archived redo logs are what make media recovery, restoring from a backup and rolling forward, possible at all. CKPT and DBW together determine how much redo an instance actually needs to replay after a crash. None of this is background trivia; it is the machinery every RMAN command you will learn later actually depends on.

Older descriptions of "instance components" tend to blur in a few things that are closely associated with an instance but are not, strictly speaking, part of it. It is worth being precise about the boundary, since the whole point of this module is learning to draw it correctly.
The listener is a separate process that runs outside the instance and routes incoming client connection requests to the appropriate instance. Its job is connectivity, not memory management or data access, so it does not belong on a list of instance internals. The underlying network protocol has also moved on: what older material calls "SQL*Net" is the historical name for what is now Oracle Net Services, and modern client connectivity increasingly uses Easy Connect Plus and OCI-native connection methods rather than the classic tnsnames.ora-based setup. If you want the fuller picture of how that connectivity layer has evolved, see Oracle Service Connection Methods in the Network Topology course.
Oracle Data Pump and the Oracle Scheduler are both genuinely useful, but they are utilities and features that run using the instance's existing processes and memory rather than components of the instance in their own right. Data Pump moves data between databases and schemas using ordinary server processes; the Scheduler automates jobs like backups and maintenance tasks using background processes the instance already provides. Calling them "instance components" muddies exactly the distinction this lesson exists to make clear.

Turn now to the other half of the split: the database itself, meaning the actual files on disk that survive whether or not an instance is currently running against them.
At the physical level, every Oracle AI Database 26ai database (remember, always a CDB with one or more PDBs) consists of three core file types. Data files hold the actual table and index data, organized into tablespaces; the CDB has its own set of data files, and each PDB has its own separate set nested within the overall CDB storage. Control files are small but critical files that track the physical structure of the whole CDB, including the locations of every data file and redo log; PDBs do not maintain their own separate control files, since the control file is a CDB-root-level structure. Online redo log files record every change made to data within the CDB and are shared across the CDB in the same way; individual PDBs do not have their own private online redo logs either.
It is this small set of physical files, plus the archived redo logs generated once ARCHIVELOG mode is enabled, that a backup and recovery strategy actually protects. Everything you will learn about RMAN backup sets, image copies, and recovery windows later in this course is ultimately about safeguarding these files, and about giving an instance enough information (through the control file and the redo stream) to put a damaged or restored copy of them back into a consistent state.

It is worth being explicit about why a course on backup and recovery opens with a lesson on instance and memory architecture rather than jumping straight to RMAN commands.
Oracle actually distinguishes between two very different kinds of recovery, and the instance/database split is exactly what makes that distinction meaningful. Instance recovery happens automatically after an instance crashes while the underlying database files are still intact; a new instance starts, reads the online redo logs, and rolls forward and then back to bring the data files to a consistent state, all without any DBA intervention or any backup at all. Media recovery is a different animal entirely: it is required when the database files themselves are lost, corrupted, or otherwise damaged, and it depends on having a genuine backup to restore from plus the archived redo logs to roll forward afterward. One of these failure modes the instance quietly fixes on its own; the other is exactly what this entire course, and tools like RMAN, Data Guard, and Flashback, exist to prepare you for.
This is also where the earlier mention of NOMOUNT stops being a technicality and starts being a real recovery tool. Every restore and recovery scenario you will practice with RMAN moves an instance through the same three states in order: NOMOUNT, where the instance exists in memory but has not yet located a control file; MOUNT, where the instance has read the control file and knows the layout of the database but has not yet opened the data files for normal use; and OPEN, where the database is fully available to users. Lose a control file and you restore it while the instance sits in NOMOUNT. Lose a data file and you restore and recover it while the instance sits in MOUNT, before ever reaching OPEN. None of that sequence makes sense until you have internalized that the instance and the database files it is reading are two separate things that come together in stages, not all at once.
Keeping instance and database mentally separate also clarifies why "the instance died" is a Tuesday-afternoon inconvenience and "the database died" is a career-defining incident. An instance is cheap and disposable: start another one, mount the same database, and you are back in business within minutes. The database is the one truly irreplaceable asset in this whole architecture, which is exactly why the rest of this module, and the rest of this course, focuses so heavily on protecting it.

The next lesson goes deeper into Oracle instance structures, building directly on the memory and process concepts introduced here.