Instance Memory Structures

The Oracle instance contains several memory structures located in the System Global Area, or SGA. This shared memory area holds both data and control information for the instance, and is referenced by virtually all of the background processes covered in the previous lesson. The benefit of this shared memory model is straightforward: information gets shared efficiently between the various system processes instead of each one keeping its own private, duplicated copy. The major, classic components of the SGA are shown in the diagram below.

The diagram above is the classic four-box SGA picture, and it is still an accurate core: the large pool, database buffer cache, redo log buffer, and shared pool remain exactly where you would expect them in Oracle AI Database 26ai. What has changed is what sits around them. 26ai adds a dedicated Vector Pool to the SGA, an area reserved for the in-memory indexes that power native vector search, elastic in how it is managed and autonomously sized on Autonomous AI Database deployments. Alongside the SGA, 26ai also introduces the Managed Global Area (MGA), a semi-shared memory framework that lets a defined set of trusted Oracle processes share memory without everything being visible to every process the way the SGA is; on Linux it is backed by /dev/shm, and its usage is tracked against the PGA aggregate limit rather than the SGA. And for sizing all of this, 26ai continues to support unified memory management, where a single MEMORY_SIZE parameter lets the instance dynamically divide memory across the SGA, PGA, MGA, and UGA, rather than requiring separate manual targets for each.
It is worth being clear about one more distinction while we are on the subject, since the SGA gets most of the attention: not everything an Oracle process touches is shared. Each process, whether a background process or a session's server process, has its own private Program Global Area (PGA), holding things like sort work areas and cursor state that have no business being visible to other sessions. Session-specific state itself, the User Global Area (UGA), normally lives inside that private PGA under the default dedicated-server connection model. The large pool section below explains the one important exception to that rule. The previous lesson covered the process side of the instance in depth; this lesson stays on the memory side, starting with the component that the legacy documentation for this page has always centered on: the large pool.

The large pool was introduced back in Oracle 8, and its job has not fundamentally changed since: it holds large memory allocations that would otherwise crowd out smaller, more frequently reused items in the shared pool. Recovery Manager benefits directly from this. When you back up or restore a database, RMAN moves large chunks of data at once, and having dedicated large-pool buffers for that I/O keeps those operations from competing with ordinary SQL parsing for shared pool space. Parallel query benefits the same way: large sorts, hash joins, and other parallel execution operations can use large pool memory for their message buffers and temporary storage rather than spilling extra I/O to disk.
The large pool also plays a specific role in distributed transactions that use the XA protocol^[1]. An XA transaction has to maintain context information across every session involved: a transaction ID, the list of participating resources, and the current state of the transaction. That context lives in the User Global Area (UGA) for each session, and here is the detail worth remembering: in dedicated server mode the UGA sits in that session's private PGA, but in shared server mode, which is exactly where XA-coordinated sessions typically run, the UGA is allocated from the large pool instead. That is the whole reason the large pool matters for XA work: it is where the session state for those coordinated, shared-server sessions actually lives.
None of this happens automatically. You have to tell the instance you want a large pool by setting the LARGE_POOL_SIZE parameter. If you never configure one, Oracle does not simply skip large-pool-dependent operations; it falls back to allocating that memory from the shared pool instead, which is workable in a pinch but defeats the purpose of keeping large, bursty allocations away from your shared SQL and dictionary cache. If you are running RMAN backups regularly, using shared servers, or working with distributed XA transactions, sizing an explicit large pool is worth the extra configuration step.

A database, in the physical sense, is a collection of files stored on disk. The primary logical unit organizing those files is the tablespace: a logical container made up of one or more physical data files. The relationship runs in one direction only. A tablespace is the logical construct; a data file is the physical file underneath it. Multiple data files can belong to a single tablespace, letting you spread that tablespace's storage across several disks for performance reasons or simply to grow it over time, but a single data file can only ever belong to one tablespace. This separation is what makes storage genuinely manageable at scale: you can allocate specific files to specific storage devices based on performance needs, grow a tablespace by adding more files rather than resizing one enormous file, and perform backup and recovery operations at the tablespace level rather than juggling individual files by hand.
One tablespace deserves particular attention here: the SYSTEM tablespace. It must be available at all times for the database to function normally, since it contains the data dictionary, the metadata Oracle itself relies on to know what your database even contains. The data dictionary stays relatively stable in size; it does not grow the way user data does, so SYSTEM does not need the same kind of aggressive space planning a busy application tablespace does. What has genuinely changed for this tablespace in Oracle AI Database 26ai is more structural than a free-space percentage: starting with 26ai, the SYSTEM, SYSAUX, and USER tablespaces are created as bigfile tablespaces by default, meaning each is backed by one very large data file rather than a growable collection of smaller ones. A DBA should still limit unnecessary access to SYSTEM and keep an eye on its growth, but the operative discipline now is understanding that single-bigfile model, not chasing a specific free-space percentage.
You will refer to various data dictionary views throughout this course. The V$SGA view reports the size of the shared pool, log buffer, data buffer cache, and fixed memory areas; V$INSTANCE returns information about the running instance itself, including its name, startup time, and host name. Both are worth becoming comfortable querying early, since you will lean on them again once this course reaches performance and recovery diagnostics.

Oracle AI Database offers a solid set of tools for managing both data files and tablespaces day to day.
Managing data files. The two features worth knowing here are Oracle Managed Files (OMF), which automates the naming, creation, and extension of data files so you are not manually tracking file paths, and transparent data file encryption through Oracle Advanced Security, which helps meet compliance requirements without changing how applications read or write data. Oracle also continues to support very large individual data files for demanding storage needs, including hybrid on-premises and cloud deployments.
Adding a data file to an existing tablespace looks like this:

ALTER TABLESPACE users ADD DATAFILE '/u01/oracle/users02.dbf' SIZE 50M AUTOEXTEND ON;

With OMF enabled, Oracle can manage the file name and location for you:

ALTER TABLESPACE users ADD DATAFILE SIZE 50M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED;

You can resize an existing data file manually:

ALTER DATABASE DATAFILE '/u01/oracle/datafile1.dbf' RESIZE 100M;

Or enable auto-extension so it grows on its own as needed:

ALTER DATABASE DATAFILE '/u01/oracle/datafile1.dbf' AUTOEXTEND ON NEXT 10M MAXSIZE 500M;

You cannot drop a data file directly; you drop the tablespace that contains it. To monitor data file usage, query the DBA_DATA_FILES view:

SELECT FILE_NAME, TABLESPACE_NAME, BYTES, AUTOEXTENSIBLE FROM DBA_DATA_FILES;

Managing tablespaces. Tablespace-level features include read-only tablespaces for data that no longer changes, improved temporary tablespace management for sort operations, bigfile tablespaces for very large single data files, and ongoing improvements to undo tablespace performance and visibility. The standard tablespace types are SYSTEM and SYSAUX, required for basic database operation; PERMANENT, storing user data and indexes; TEMPORARY, used for sort and other temporary operations; and UNDO, managing undo data for transactions.
Create a standard tablespace:

CREATE TABLESPACE users
DATAFILE '/u01/oracle/users01.dbf' SIZE 50M AUTOEXTEND ON NEXT 10M MAXSIZE 500M;

Or a bigfile tablespace, backed by a single large data file:

CREATE BIGFILE TABLESPACE big_users
DATAFILE '/u01/oracle/big_users01.dbf' SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE UNLIMITED;

Mark a tablespace read-only once its data is finalized:

ALTER TABLESPACE users READ ONLY;

Drop a tablespace along with its underlying data files:

DROP TABLESPACE users INCLUDING CONTENTS AND DATAFILES;

Monitor tablespaces with DBA_TABLESPACES:

SELECT TABLESPACE_NAME, STATUS, CONTENTS, BIGFILE FROM DBA_TABLESPACES;

Create a temporary tablespace and assign it as the default:

CREATE TEMPORARY TABLESPACE temp1
TEMPFILE '/u01/oracle/temp01.dbf' SIZE 50M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED;

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp1;

Create and assign an undo tablespace:

CREATE UNDO TABLESPACE undo_tbs
DATAFILE '/u01/oracle/undo01.dbf' SIZE 200M AUTOEXTEND ON;

ALTER SYSTEM SET UNDO_TABLESPACE = undo_tbs;

A few additional capabilities are worth knowing by name even if you will not use them in every environment. Heat Map tracking identifies frequently and infrequently accessed blocks so storage can be placed accordingly; Automatic Data Optimization (ADO) can act on that heat map data to move data between storage tiers automatically; tablespace cloning allows quick duplication of a tablespace for test or backup purposes; and hybrid partitioned tables let a single table span both internally stored partitions and externally referenced ones, useful when you want to keep actively queried data inside the database while leaving colder data in place elsewhere.

Two views come up constantly once you start working with an instance's memory and general status: V$SGA and V$INSTANCE. A basic instance status query looks like this:

SELECT instance_number, instance_name, version, status, host_name, startup_time
FROM v$instance;

That gives you the instance number, its name, the running version, its current status, the host it is running on, and when it was last started, everything you need for a quick sanity check that you are connected to the instance you think you are. V$SGA works the same way for memory:

SELECT * FROM v$sga;

which returns the size of the fixed SGA, the variable size, the database buffer cache, and the redo buffers. Both views are stable, long-standing parts of Oracle's data dictionary; get comfortable with them now, because this course will come back to them repeatedly once we start diagnosing recovery scenarios later in the module.
Why memory structures matter for backup and recovery. It is easy to treat this lesson as pure architecture trivia, so it is worth connecting it back to where this course is headed. The redo log buffer you saw in the four-box diagram is the staging area LGWR flushes to the online redo logs on every commit; nothing about instance or media recovery works without it. The database buffer cache is what DBW eventually writes back to data files, and it is exactly the set of dirty blocks that determines how much recovery work is needed after a crash. Even the shared pool plays a role indirectly: the SQL and PL/SQL that RMAN itself runs gets parsed and cached there like any other statement. And the bigfile-by-default change to SYSTEM and SYSAUX in 26ai is not just a storage detail either; it changes how you think about backing up those tablespaces, since you are now protecting one very large file per tablespace rather than coordinating backups across several smaller ones. None of the memory structures in this lesson exist in isolation from the recovery concepts the rest of this course builds toward.
The next lesson explores Oracle background processes.

Click the Exercise link below to complete a brief matching exercise on instance memory structures.
Oracle Memory Structures - Exercise

[1] XA Protocol: XA Protocol is a standard that defines how a database, like an Oracle instance, participates in distributed transactions managed by an external transaction manager. This ensures data integrity across multiple resources, even if they reside in different databases or systems. Within the Oracle instance memory, XA Protocol interacts with the System Global Area (SGA), specifically the shared pool and buffer cache, to manage transaction states and data consistency during the two-phase commit process.