This chapter discusses the memory architecture of a database instance.
This chapter contains the following sections:
Oracle Database Administrator’s Guide for instructions for configuring and managing memory
When an instance is started, Oracle Database allocates a memory area and starts background processes.
The memory area stores information such as the following:
Information about each connected session, even if it is not currently active
Information needed during program execution, for example, the current state of a query from which rows are being fetched
Information such as lock data that is shared and communicated among processes
Cached data, such as data blocks and redo records, that also exists on disk
Oracle Database includes several memory areas, each of which contains multiple subcomponents.
The basic memory structures associated with Oracle Database include:
System global area (SGA)
The SGA is a group of shared memory structures, known as SGA components, that contain data and control information for one Oracle Database instance. All server and background processes share the SGA. Examples of data stored in the SGA include cached data blocks and shared SQL areas.
Program global area (PGA)
A PGA is a nonshared memory region that contains data and control information exclusively for use by an Oracle process. Oracle Database creates the PGA when an Oracle process starts.
One PGA exists for each server process and background process. The collection of individual PGAs is the total instance PGA, or instance PGA. Database initialization parameters set the size of the instance PGA, not individual PGAs.
User global area (UGA)
The UGA is memory associated with a user session.
Software code areas
Software code areas are portions of memory used to store code that is being run or can be run. Oracle Database code is stored in a software area that is typically at a different location from user programs—a more exclusive or protected location.
The following figure illustrates the relationships among these memory structures.
Figure 14-1 Oracle Database Memory Structures
Memory management involves maintaining optimal sizes for the Oracle instance memory structures as demands on the database change. Oracle Database manages memory based on the settings of memory-related initialization parameters.
The basic options for memory management are as follows:
Automatic memory management
You specify the target size for the database instance memory. The instance automatically tunes to the target memory size, redistributing memory as needed between the SGA and the instance PGA.
Automatic shared memory management
This management mode is partially automated. You set a target size for the SGA and then have the option of setting an aggregate target size for the PGA or managing PGA work areas individually.
Manual memory management
Instead of setting the total memory size, you set many initialization parameters to manage components of the SGA and instance PGA individually.
If you create a database with Database Configuration Assistant (DBCA) and choose the basic installation option, then automatic memory management is the default.
The UGA is session memory, which is memory allocated for session variables, such as logon information, and other information required by a database session. Essentially, the UGA stores the session state.
The following figure depicts the UGA.
Figure 14-2 User Global Area (UGA)
If a session loads a PL/SQL package into memory, then the UGA contains the package state, which is the set of values stored in all the package variables at a specific time. The package state changes when a package subprogram changes the variables. By default, the package variables are unique to and persist for the life of the session.
The OLAP page pool is also stored in the UGA. This pool manages OLAP data pages, which are equivalent to data blocks. The page pool is allocated at the start of an OLAP session and released at the end of the session. An OLAP session opens automatically whenever a user queries a dimensional object such as a cube.
The UGA must be available to a database session for the life of the session. For this reason, the UGA cannot be stored in the PGA when using a shared server connection because the PGA is specific to a single process. Therefore, the UGA is stored in the SGA when using shared server connections, enabling any shared server process access to it. When using a dedicated server connection, the UGA is stored in the PGA.
Oracle Database Net Services Administrator's Guide to learn about shared server connections
Oracle OLAP User’s Guide for an overview of Oracle OLAP
The PGA is memory specific to an operating process or thread that is not shared by other processes or threads on the system. Because the PGA is process-specific, it is never allocated in the SGA.
The PGA is a memory heap that contains session-dependent variables required by a dedicated or shared server process. The server process allocates memory structures that it requires in the PGA.
An analogy for a PGA is a temporary countertop workspace used by a file clerk. In this analogy, the file clerk is the server process doing work on behalf of the customer (client process). The clerk clears a section of the countertop, uses the workspace to store details about the customer request and to sort the folders requested by the customer, and then gives up the space when the work is done.
The following figure shows an instance PGA (collection of all PGAs) for an instance that is not configured for shared servers. You can use an initialization parameter to set a target maximum size of the instance PGA. Individual PGAs can grow as needed up to this target size.
Figure 14-3 Instance PGA
Background processes also allocate their own PGAs. This discussion focuses on server process PGAs only.
The PGA is subdivided into different areas, each with a different purpose.
The following figure shows the possible contents of the PGA for a dedicated server session. Not all of the PGA areas will exist in every case.
Figure 14-4 PGA Contents
A private SQL area holds information about a parsed SQL statement and other session-specific information for processing.
When a server process executes SQL or PL/SQL code, the process uses the private SQL area to store bind variable values, query execution state information, and query execution work areas.
Do not confuse a private SQL area, which is in the PGA, with the shared SQL area, which stores execution plans in the SGA. Multiple private SQL areas in the same or different sessions can point to a single execution plan in the SGA. For example, 20 executions of
SELECT * FROM sales in one session and 10 executions of the same query in a different session can share the same plan. The private SQL areas for each execution are not shared and may contain different values and data.
A cursor is a name or handle to a specific private SQL area. As shown in the following graphic, you can think of a cursor as a pointer on the client side and as a state on the server side. Because cursors are closely associated with private SQL areas, the terms are sometimes used interchangeably.
Figure 14-5 Cursor
A private SQL area is divided into the following areas:
The run-time area
This area contains query execution state information. For example, the run-time area tracks the number of rows retrieved so far in a full table scan.
Oracle Database creates the run-time area as the first step of an execute request. For DML statements, the run-time area is freed when the SQL statement is closed.
The persistent area
This area contains bind variable values. A bind variable value is supplied to a SQL statement at run time when the statement is executed. The persistent area is freed only when the cursor is closed.
The client process is responsible for managing private SQL areas. The allocation and deallocation of private SQL areas depends largely on the application, although the number of private SQL areas that a client process can allocate is limited by the initialization parameter
Although most users rely on the automatic cursor handling of database utilities, the Oracle Database programmatic interfaces offer developers more control over cursors. In general, applications should close all open cursors that will not be used again to free the persistent area and to minimize the memory required for application users.
A work area is a private allocation of PGA memory used for memory-intensive operations.
For example, a sort operator uses the sort area to sort a set of rows. Similarly, a hash join operator uses a hash area to build a hash table from its left input, whereas a bitmap merge uses the bitmap merge area to merge data retrieved from scans of multiple bitmap indexes.
SQL> SELECT * 2 FROM employees e JOIN departments d 3 ON e.department_id=d.department_id 4 ORDER BY last_name; . . . -------------------------------------------------------------------------------- | Id| Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 106 | 9328 | 7 (29)| 00:00:01 | | 1 | SORT ORDER BY | | 106 | 9328 | 7 (29)| 00:00:01 | |*2 | HASH JOIN | | 106 | 9328 | 6 (17)| 00:00:01 | | 3 | TABLE ACCESS FULL| DEPARTMENTS | 27 | 540 | 2 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| EMPLOYEES | 107 | 7276 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------
In the preceding example, the run-time area tracks the progress of the full table scans. The session performs a hash join in the hash area to match rows from the two tables. The
ORDER BY sort occurs in the sort area.
If the amount of data to be processed by the operators does not fit into a work area, then Oracle Database divides the input data into smaller pieces. In this way, the database processes some data pieces in memory while writing the rest to temporary disk storage for processing later.
The database automatically tunes work area sizes when automatic PGA memory management is enabled. You can also manually control and tune the size of a work area. See "Memory Management" for more information.
Generally, larger work areas can significantly improve performance of an operator at the cost of higher memory consumption. Optimally, the size of a work area is sufficient to accommodate the input data and auxiliary memory structures allocated by its associated SQL operator. If not, response time increases because part of the input data must be cached on disk. In the extreme case, if the size of a work area is too small compared to input data size, then the database must perform multiple passes over the data pieces, dramatically increasing response time.
PGA memory allocation depends on whether the database uses dedicated or shared server connections.
The following table shows the differences.
Table 14-1 Differences in Memory Allocation Between Dedicated and Shared Servers
|Memory Area||Dedicated Server||Shared Server|
Nature of session memory
Location of the persistent area
Location of the run-time area for DML and DDL statements
Oracle Database Administrator’s Guide to learn how to configure a database for shared server
The SGA is a read/write memory area that, along with the Oracle background processes, form a database instance. All server processes that execute on behalf of users can read information in the instance SGA. Several processes write to the SGA during database operation.
The server and background processes do not reside within the SGA, but exist in a separate memory space.
Each database instance has its own SGA. Oracle Database automatically allocates memory for an SGA at instance startup and reclaims the memory at instance shutdown. When you start an instance with SQL*Plus or Oracle Enterprise Manager, the size of the SGA is shown as in the following example:
SQL> STARTUP ORACLE instance started. Total System Global Area 368283648 bytes Fixed Size 1300440 bytes Variable Size 343935016 bytes Database Buffers 16777216 bytes Redo Buffers 6270976 bytes Database mounted. Database opened.
As shown in Figure 14-1, the SGA consists of several memory components, which are pools of memory used to satisfy a particular class of memory allocation requests. All SGA components except the redo log buffer allocate and deallocate space in units of contiguous memory called granules. Granule size is platform-specific and is determined by total SGA size.
You can query the
V$SGASTAT view for information about SGA components.
The most important SGA components are the following:
The database buffer cache, also called the buffer cache, is the memory area that stores copies of data blocks read from data files.
A buffer is a main memory address in which the buffer manager temporarily caches a currently or recently used data block. All users concurrently connected to a database instance share access to the buffer cache.
Oracle Database uses the buffer cache to achieve multiple goals.
The goals include:
Optimize physical I/O
The database updates data blocks in the cache and stores metadata about the changes in the redo log buffer. After a
COMMIT, the database writes the redo buffers to the online redo log but does not immediately write data blocks to the data files. Instead, database writer (DBW) performs lazy writes in the background.
Keep frequently accessed blocks in the buffer cache and write infrequently accessed blocks to disk
When Database Smart Flash Cache (flash cache) is enabled, part of the buffer cache can reside in the flash cache. This buffer cache extension is stored on one or more flash disk devices, which are solid state storage devices that uses flash memory. The database can improve performance by caching buffers in flash memory instead of reading from magnetic disk.
DB_FLASH_CACHE_SIZE initialization parameters to configure multiple flash devices. The buffer cache tracks each device and distributes buffers to the devices uniformly.
Database Smart Flash Cache is available only in Solaris and Oracle Linux.
Oracle Database Reference to learn about the
DB_FLASH_CACHE_FILE initialization parameter
The database uses internal algorithms to manage buffers in the cache.
A buffer can be in any of the following mutually exclusive states:
The buffer is available for use because it has never been used or is currently unused. This type of buffer is the easiest for the database to use.
This buffer was used earlier and now contains a read-consistent version of a block as of a point in time. The block contains data but is "clean" so it does not need to be checkpointed. The database can pin the block and reuse it.
The buffer contain modified data that has not yet been written to disk. The database must checkpoint the block before reusing it.
Every buffer has an access mode: pinned or free (unpinned). A buffer is "pinned" in the cache so that it does not age out of memory while a user session accesses it. Multiple sessions cannot modify a pinned buffer at the same time.
When a client requests data, Oracle Database retrieves buffers from the database buffer cache in either current mode or consistent mode.
The modes differ as follows:
A current mode get, also called a db block get, is a retrieval of a block as it currently appears in the buffer cache. For example, if an uncommitted transaction has updated two rows in a block, then a current mode get retrieves the block with these uncommitted rows. The database uses db block gets most frequently during modification statements, which must update only the current version of the block.
A consistent read get is a retrieval of a read-consistent version of a block. This retrieval may use undo data. For example, if an uncommitted transaction has updated two rows in a block, and if a query in a separate session requests the block, then the database uses undo data to create a read-consistent version of this block (called a consistent read clone) that does not include the uncommitted updates. Typically, a query retrieves blocks in consistent mode.
A logical I/O, also known as a buffer I/O, refers to reads and writes of buffers in the buffer cache.
When a requested buffer is not found in memory, the database performs a physical I/O to copy the buffer from either the flash cache or disk into memory. The database then performs a logical I/O to read the cached buffer.
To make buffer access efficient, the database must decide which buffers to cache in memory, and which to access from disk.
The database uses the following algorithms:
LRU-based, block-level replacement algorithm
This sophisticated algorithm, which is the default, uses a least recently used (LRU) list that contains pointers to dirty and non-dirty buffers. The LRU list has a hot end and cold end. A cold buffer is a buffer that has not been recently used. A hot buffer is frequently accessed and has been recently used. Conceptually, there is only one LRU, but for data concurrency the database actually uses several LRUs.
Temperature-based, object-level replacement algorithm
Starting in Oracle Database 12c Release 1 (188.8.131.52), the automatic big table caching feature enables table scans to use a different algorithm in the following scenarios:
In single-instance and Oracle Real Applications Cluster (Oracle RAC) databases, parallel queries can use the big table cache when the
DB_BIG_TABLE_CACHE_PERCENT_TARGET initialization parameter is set to a nonzero value, and
PARALLEL_DEGREE_POLICY is set to
In a single-instance configuration only, serial queries can use the big table cache when the
DB_BIG_TABLE_CACHE_PERCENT_TARGET initialization parameter is set to a nonzero value.
When a table does not fit in memory, the database decides which buffers to cache based on access patterns. For example, if only 95% of a popular table fits in memory, then the database may choose to leave 5% of the blocks on disk rather than cyclically reading blocks into memory and writing blocks to disk—a phenomenon known as thrashing. When caching multiple large objects, the database considers more popular tables hotter and less popular tables cooler, which influences which blocks are cached. The
DB_BIG_TABLE_CACHE_PERCENT_TARGET initialization parameter sets the percentage of the buffer cache that uses this algorithm.
This document explains the LRU-based, block level replacement algorithm. To learn more about the temperature-based algorithm, see Oracle Database VLDB and Partitioning Guide.
The database writer (DBW) process periodically writes cold, dirty buffers to disk.
DBW writes buffers in the following circumstances:
A server process cannot find clean buffers for reading new blocks into the database buffer cache.
As buffers are dirtied, the number of free buffers decreases. If the number drops below an internal threshold, and if clean buffers are required, then server processes signal DBW to write.
The database uses the LRU to determine which dirty buffers to write. When dirty buffers reach the cold end of the LRU, the database moves them off the LRU to a write queue. DBW writes buffers in the queue to disk, using multiblock writes if possible. This mechanism prevents the end of the LRU from becoming clogged with dirty buffers and allows clean buffers to be found for reuse.
Tablespaces are changed to read-only status or taken offline.
When the number of unused buffers is low, the database must remove buffers from the buffer cache.
The algorithm depends on whether the flash cache is enabled:
Flash cache disabled
The database re-uses each clean buffer as needed, overwriting it. If the overwritten buffer is needed later, then the database must read it from magnetic disk.
Flash cache enabled
DBW can write the body of a clean buffer to the flash cache, enabling reuse of its in-memory buffer. The database keeps the buffer header in an LRU list in main memory to track the state and location of the buffer body in the flash cache. If this buffer is needed later, then the database can read it from the flash cache instead of from magnetic disk.
When a client process requests a buffer, the server process searches the buffer cache for the buffer. A cache hit occurs if the database finds the buffer in memory. The search order is as follows:
The server process searches for the whole buffer in the buffer cache.
If the process finds the whole buffer, then the database performs a logical read of this buffer.
The server process searches for the buffer header in the flash cache LRU list.
If the process finds the buffer header, then the database performs an optimized physical read of the buffer body from the flash cache into the in-memory cache.
If the process does not find the buffer in memory (a cache miss), then the server process performs the following steps:
Copies the block from a data file on disk into memory (a physical read)
Performs a logical read of the buffer that was read into memory
Figure 14-6 illustrates the buffer search order. The extended buffer cache includes both the in-memory buffer cache, which contains whole buffers, and the flash cache, which contains buffer bodies. In the figure, the database searches for a buffer in the buffer cache and, not finding the buffer, reads it into memory from magnetic disk.
Figure 14-6 Buffer Search
In general, accessing data through a cache hit is faster than through a cache miss. The buffer cache hit ratio measures how often the database found a requested block in the buffer cache without needing to read it from disk.
The database can perform physical reads from either a data file or a temp file. Reads from a data file are followed by logical I/Os. Reads from a temp file occur when insufficient memory forces the database write data to a temporary table and read it back later. These physical reads bypass the buffer cache and do not incur a logical I/O.
Oracle Database Performance Tuning Guide to learn how to calculate the buffer cache hit ratio
The database measures the frequency of access of buffers on the LRU list using a touch count. This mechanism enables the database to increment a counter when a buffer is pinned instead of constantly shuffling buffers on the LRU list.
The database does not physically move blocks in memory. The movement is the change in location of a pointer on a list.
When a buffer is pinned, the database determines when its touch count was last incremented. If the count was incremented over three seconds ago, then the count is incremented; otherwise, the count stays the same. The three-second rule prevents a burst of pins on a buffer counting as many touches. For example, a session may insert several rows in a data block, but the database considers these inserts as one touch.
If a buffer is on the cold end of the LRU, but its touch count is high, then the buffer moves to the hot end. If the touch count is low, then the buffer ages out of the cache.
A buffer pool is a collection of buffers.
The database buffer cache is divided into one or more buffer pools, which manage blocks in mostly the same way. The pools do not have radically different algorithms for aging or caching blocks.
You can manually configure separate buffer pools that either keep data in the buffer cache or make the buffers available for new data immediately after using the data blocks. You can then assign specific schema objects to the appropriate buffer pool to control how blocks age out of the cache. For example, you can segregate segments into hot, warm, and cold buffer pools.
The possible buffer pools are as follows:
This pool is the location where blocks are normally cached. Unless you manually configure separate pools, the default pool is the only buffer pool. The optional configuration of the other pools has no effect on the default pool.
Starting in Oracle Database 12c Release 1 (184.108.40.206), the big table cache is an optional section of the default pool that uses a temperature-based, object-level replacement algorithm. In single-instance and Oracle RAC databases, parallel queries can use the big table cache when the
DB_BIG_TABLE_CACHE_PERCENT_TARGET initialization parameter is set to a nonzero value, and
PARALLEL_DEGREE_POLICY is set to
adaptive. In single-instance configurations only, serial queries can use the big table cache when
DB_BIG_TABLE_CACHE_PERCENT_TARGET is set.
This pool is intended for blocks that were accessed frequently, but which aged out of the default pool because of lack of space. The purpose of the keep buffer pool is to retain objects in memory, thus avoiding I/O operations.
The keep pool manages buffers in the same way as the other pools: it does not use a special algorithm to pin buffers. The word "keep" is a naming convention. You can place tables that you want to keep in the larger keep pool, and place tables that you do not want to keep in the smaller recycle pool.
This pool is intended for blocks that are used infrequently. A recycle pool prevent objects from consuming unnecessary space in the cache.
A database has a standard block size. You can create a tablespace with a block size that differs from the standard size. Each nondefault block size has its own pool. Oracle Database manages the blocks in these pools in the same way as in the default pool.
Figure 14-7 shows the structure of the buffer cache when multiple pools are used. The cache contains default, keep, and recycle pools. The default block size is 8 KB. The cache contains separate pools for tablespaces that use the nonstandard block sizes of 2 KB, 4 KB, and 16 KB.
Figure 14-7 Database Buffer Cache
The database uses a complicated algorithm to manage table scans. By default, when buffers must be read from disk, the database inserts the buffers into the middle of the LRU list. In this way, hot blocks can remain in the cache so that they do not need to be read from disk again.
A problem is posed by a full table scan, which sequentially reads all rows under the table high water mark (HWM). Suppose that the total size of the blocks in a table segment is greater than the size of the buffer cache. A full scan of this table could clean out the buffer cache, preventing the database from maintaining a cache of frequently accessed blocks.
By default, the database takes a conservative approach to full table scans, loading a small table into memory only when the table size is a small percentage of the buffer cache.
To determine whether medium sized tables should be cached, the database uses an algorithm that incorporates the interval between the last table scan, the aging timestamp of the buffer cache, and the space remaining in the buffer cache.
For very large tables, the database typically uses a direct path read, which loads blocks directly into the PGA and bypasses the SGA altogether, to avoid populating the buffer cache. For medium size tables, the database may use a direct read or a cache read. If it decides to use a cache read, then the database places the blocks at the end of the LRU list to prevent the scan from effectively cleaning out the buffer cache.
Starting in Oracle Database 12c Release 1 (220.127.116.11), the buffer cache of a database instance automatically performs an internal calculation to determine whether memory is sufficient for the database to be fully cached in the instance SGA, and if caching tables on access would be beneficial for performance. If the whole database can fully fit in memory, and if various other internal criteria are met, then Oracle Database treats all tables in the database as small tables, and considers them eligible for caching. However, the database does not cache LOBs marked with the
When performing a full table scan, the database can sometimes improve response time by using multiple parallel execution servers.
In some cases, as when the database has a large amount of memory, the database can cache parallel query data in the system global area (SGA) instead of using direct path reads into the program global area (PGA). Typically, parallel queries occur in low-concurrency data warehouses because of the potential resource usage.
In the rare case where the default caching behavior is not desired, you can use
ALTER TABLE ... CACHE to change how blocks from large tables are read into the database buffer cache.
For tables with the
CACHE attribute set, the database does not force or pin the blocks in the buffer cache. Instead, the database ages the blocks out of the cache in the same way as any other table block. Use care when exercising this option because a full scan of a large table may clean most of the other blocks out of the cache.
ALTER TABLE ... CACHE does not cause a table to be cached.
For large tables, you can use
ALTER TABLE ... STORAGE BUFFER_POOL KEEP to cause scans to load blocks for these tables into the keep pool.
Placing a table into the keep pool changes the part of the buffer cache where the blocks are stored. Instead of caching blocks in the default buffer pool, the database caches them in the keep buffer pool. No separate algorithm controls keep pool caching.
To improve performance in some situations, you can explicitly execute the
ALTER DATABASE ... FORCE FULL DATABASE CACHING statement to enable the force full database caching mode.
In contrast to the default mode, which is automatic, the force full database caching mode considers the entire database, including
NOCACHE LOBs, as eligible for caching in the buffer cache. This mode is available starting in Oracle Database 12c Release 1 (18.104.22.168).
Enabling force full database caching mode does not force the database into memory. Rather, the entire database is eligible to be completely cached in the buffer cache. Oracle Database caches the tables only when they are accessed.
Oracle recommends that you enable force full database caching mode only when the buffer cache size of each individual instance is greater than the database size. This guideline applies to both single-instance and Oracle RAC databases. However, when Oracle RAC applications are well partitioned, you can enable force full database caching mode when the combined buffer cache of all instances, with extra space to handle duplicate cached blocks between instances, is greater than the database size.
Starting in Oracle Database 12c Release 1 (22.214.171.124), the In-Memory Column Store (IM column store) is an optional, static SGA pool that stores copies of tables and partitions in a special columnar format optimized for rapid scans.
The IM column store does not replace the buffer cache, but acts as a supplement so that both memory areas can store the same data in different formats. By default, only objects specified as
INMEMORY using DDL are candidates to be populated in the IM column store.
It is not necessary for objects populated in the IM column store to be loaded into the database buffer cache.
The columnar format exists only in memory. The following figure shows three tables from the
sh schema stored in the IM column store:
sales. The IM column store stores the data by column rather than row. The database keeps the columnar data transactionally consistent with the buffer cache.
Figure 14-8 Columnar Format
This section contains the following topics:
The IM column store enables the database to perform scans, joins, and aggregates much faster than when it uses the on-disk format exclusively.
In particular, the IM column store is useful for:
Performing fast full scans of large tables
Evaluating predicate filters that use operators such as
Querying a subset of columns in a table, for example, selecting 5 of 100 columns
Accelerating joins by converting predicates on small dimension tables into filters on a large fact table
Business applications, ad-hoc analytic queries, and data warehouse workloads benefit most. Pure OLTP databases that perform short transactions using index lookups benefit less.
The IM column store also provides the following advantages:
All existing database features are supported, including High Availability features (see "Overview of High Availability").
No application changes are required.
The optimizer automatically takes advantage of the columnar format.
Configuration is simple.
INMEMORY_SIZE initialization parameter specifies the amount of memory reserved for use by the IM column store. DDL statements specify the tablespaces, tables, partitions, or columns to be read into the IM column store.
Compression is optimized for query performance.
These compression techniques increase the effective memory bandwidth by enabling sessions to read more data into memory.
Fewer indexes, materialized views, and OLAP cubes are required.
The reduction in the number of pre-built objects results in reduced storage space and significantly less processing overhead.
When fetching data, Oracle Database can read either the IM column store or the database buffer cache, or both within the same query.
The database transparently sends OLTP queries (such as primary key lookups) to the buffer cache, and analytic and reporting queries to the IM column store. Thus, dual memory formats provide the best of both worlds.
In the execution plan, the operation
TABLE ACCESS IN MEMORY FULL indicates use of the IM column store.
The following figure shows a sample IM column store. The
sh.sales table is stored on disk in traditional row format. The SGA stores the data in columnar format in the IM column store, and in row format in the database buffer cache.
Figure 14-9 IM Column Store
Every on-disk data format for permanent, heap-organized tables is supported by the IM column store. The columnar format does not affect the format of data stored in data files or in the buffer cache, nor does it affect undo, online redo logging, and so on.
The database processes DML modifications in the same way regardless of whether the IM column store is in use: by updating the buffer cache, online redo log, undo tablespace, and so on. However, the database uses an internal mechanism to track changes and ensure that the IM column store is consistent with the rest of the database. For example, if the
sales table resides in the IM column store, and if a row in
sales is updated, then the database automatically ensures the copy of the
sales table in the IM column store is kept transactionally consistent. A query that accesses the IM column store always returns the same results for a query that accesses the buffer cache.
During population, the database reads data from disk in its row format, pivots the rows to create columns, and then compresses the data into In-Memory Compression Units (IMCUs).
Worker processes (Wnnn) populate the data in the IM column store. Each worker process operates on a subset of database blocks from the object. Population is a streaming mechanism, simultaneously compressing the data and converting it into columnar format.
INMEMORY_MAX_POPULATE_SERVERS initialization parameter specifies the maximum number of worker processes to use for IM column store population. By default, the setting is one half of
CPU_COUNT. Set this parameter to an appropriate value for your environment. More worker processes result in faster population, but they use more CPU resources. Fewer worker processes result in slower population, which reduces CPU overhead.
INMEMORY_MAX_POPULATE_SERVERS is set to
0, then population is disabled.
Oracle Database Reference for more information about the
INMEMORY_MAX_POPULATE_SERVERS initialization parameter
The database must reconstruct the entire in-memory columnar representation from the on-disk representation every time the database instance restarts. This reconstruction is necessary because the IM column store resides only in memory.
INMEMORY attribute on an object means that this object is a candidate for population in the IM column store, not that the database immediately populates the object in memory.
By default (
INMEMORY PRIORITY is set to
NONE), the database delays population of a table in the IM column store until the database considers it useful. When the
INMEMORY attribute is set for an object, the database may choose not to materialize all columns when the database determines that the memory is better used elsewhere. Also, the IM column store may populate a subset of columns from a table.
Example 14-1 Population of an Object in the IM Column Store
Assume that you connect to the database as administrator. To determine whether data from the
sh.customers table has been populated in the IM column store, you execute the following query :
SQL> SELECT SEGMENT_NAME, POPULATE_STATUS FROM V$IM_SEGMENTS WHERE SEGMENT_NAME = 'CUSTOMERS'; no rows selected
In this case, no segments are populated in the IM column store because
sh.customers has not yet been accessed. You query
sh.customers, and then query
SQL> SELECT cust_id, cust_last_name, cust_first_name 2 FROM sh.customers WHERE cust_city = 'Hyderabad' 3 AND cust_income_level LIKE 'C%' AND cust_year_of_birth > 1960; CUST_ID CUST_LAST_NAME CUST_FIRST ---------- --------------- ---------- 6284 Hummer Liane 12515 Oppy Linette 39514 Ready Theodric 33292 Weston Theodric 33284 Grigsby Thatcher 27062 Patterson Thatcher 6 rows selected. SQL> COL SEGMENT_NAME FORMAT a20 SQL> SELECT SEGMENT_NAME, POPULATE_STATUS FROM V$IM_SEGMENTS WHERE SEGMENT_NAME = 'CUSTOMERS'; SEGMENT_NAME POPULATE_STAT -------------------- ------------- CUSTOMERS COMPLETED
The following query confirms that the database used the IM column store to retrieve the results:
SQL> COL NAME FORMAT a25 SQL> SELECT ul.NAME, ul.DETECTED_USAGES FROM DBA_FEATURE_USAGE_STATISTICS ul 2 WHERE ul.VERSION=(SELECT MAX(u2.VERSION) FROM DBA_FEATURE_USAGE_STATISTICS u2 3 WHERE u2.NAME = ul.NAME AND ul.NAME LIKE '%Column Store%'); NAME DETECTED_USAGES ------------------------- --------------- In-Memory Column Store 1
Each node in an Oracle Real Application Clusters (Oracle RAC) environment has its own IM column store.
By default, each in-memory object is distributed among the Oracle RAC instances, effectively employing a share-nothing architecture for the IM column store. When
INMEMORY is specified, the
DUPLICATE keywords control the distribution of objects.
0 for a specific node disables the IM column store for the node.
The IM column store uses special compression formats optimized for access speed rather than storage reduction.
The database increases speed in the following ways:
The compression formats enable the database to decrease the amount of memory processed for each column. SQL executes directly on the compressed columns.
The database uses SIMD vector (array) instructions to process an array of column values in a single CPU clock cycle. The database can store many values in a vector, which maximizes the performance benefits with SIMD vector processing.
You can use the
MEMCOMPRESS subclause of
ALTER to select different compression options for each table, partition, or column. For example, you might optimize some columns in a table for scan speed, and others for storage.
The default compression option is
MEMCOMPRESS FOR QUERY LOW. This option provides the fastest read times because the database does not need to decompress the data. The other compression options, such as
FOR QUERY HIGH and
FOR CAPACITY, use layers of compression, some of which require decompression. Before storing a table in the IM column store, you can use
DBMS_COMPRESSION.GET_COMPRESSION_RATIO to report the compression ratio, and thus estimate how much space is required.
The in-memory columnar compression is closely related to Hybrid Columnar Compression. Both technologies involve processing sets of column vectors. The primary difference is that the column vectors for the IM column store are optimized for memory storage, whereas the column vectors for Hybrid Columnar Compression are optimized for disk storage.
Oracle Database Administrator’s Guide for a summary of compression options
Oracle Database SQL Language Reference for
ALTER TABLE syntax and semantics
Oracle Database PL/SQL Packages and Types Reference to learn about
The columnar format enables queries to scan only necessary columns.
For example, suppose a user executes the following ad hoc query:
SELECT cust_id, time_id, channel_id FROM sales WHERE prod_id > 14 AND prod_id < 29
When using the buffer cache, the database would typically scan an index to find the product IDs, use the rowids to fetch the rows from disk into the buffer cache, and then discard the unwanted column values. Scanning data in row format in the buffer cache requires many CPU instructions, and can result in poor CPU efficiency.
When using the IM column store, the database can scan only the requested
sales columns, avoiding expensive disk I/O altogether. Scanning data in columnar format pipelines only necessary columns to the CPU, increasing efficiency. Each CPU core scans local in-memory columns using SIMD vector instructions.
The redo log buffer is a circular buffer in the SGA that stores redo entries describing changes made to the database.
A redo record is a data structure that contains the information necessary to reconstruct, or redo, changes made to the database by DML or DDL operations. Database recovery applies redo entries to data files to reconstruct lost changes.
The database processes copy redo entries from the user memory space to the redo log buffer in the SGA. The redo entries take up continuous, sequential space in the buffer. The background process log writer process (LGWR) writes the redo log buffer to the active online redo log group on disk. Figure 14-10 shows this redo buffer activity.
Figure 14-10 Redo Log Buffer
LGWR writes redo sequentially to disk while DBW performs scattered writes of data blocks to disk. Scattered writes tend to be much slower than sequential writes. Because LGWR enable users to avoid waiting for DBW to complete its slow writes, the database delivers better performance.
LOG_BUFFER initialization parameter specifies the amount of memory that Oracle Database uses when buffering redo entries. Unlike other SGA components, the redo log buffer and fixed SGA buffer do not divide memory into granules.
The shared pool caches various types of program data.
For example, the shared pool stores parsed SQL, PL/SQL code, system parameters, and data dictionary information. The shared pool is involved in almost every operation that occurs in the database. For example, if a user executes a SQL statement, then Oracle Database accesses the shared pool.
The shared pool is divided into several subcomponents, the most important of which are shown in Figure 14-11.
Figure 14-11 Shared Pool
This section includes the following topics:
The library cache is a shared pool memory structure that stores executable SQL and PL/SQL code.
This cache contains the shared SQL and PL/SQL areas and control structures such as locks and library cache handles. In a shared server architecture, the library cache also contains private SQL areas.
When a SQL statement is executed, the database attempts to reuse previously executed code. If a parsed representation of a SQL statement exists in the library cache and can be shared, then the database reuses the code, known as a soft parse or a library cache hit. Otherwise, the database must build a new executable version of the application code, known as a hard parse or a library cache miss.
The database represents each SQL statement that it runs in the shared SQL area and private SQL area.
The database uses the shared SQL area to process the first occurrence of a SQL statement. This area is accessible to all users and contains the statement parse tree and execution plan. Only one shared SQL area exists for a unique statement. Each session issuing a SQL statement has a private SQL area in its PGA. Each user that submits the same statement has a private SQL area pointing to the same shared SQL area. Thus, many private SQL areas in separate PGAs can be associated with the same shared SQL area.
The database automatically determines when applications submit similar SQL statements. The database considers both SQL statements issued directly by users and applications and recursive SQL statements issued internally by other statements.
The database performs the following steps:
Checks the shared pool to see if a shared SQL area exists for a syntactically and semantically identical statement:
If an identical statement exists, then the database uses the shared SQL area for the execution of the subsequent new instances of the statement, thereby reducing memory consumption.
If an identical statement does not exist, then the database allocates a new shared SQL area in the shared pool. A statement with the same syntax but different semantics uses a child cursor.
In either case, the private SQL area for the user points to the shared SQL area that contains the statement and execution plan.
Allocates a private SQL area on behalf of the session
The location of the private SQL area depends on the connection established for the session. If a session is connected through a shared server, then part of the private SQL area is kept in the SGA.
Figure 14-12 shows a dedicated server architecture in which two sessions keep a copy of the same SQL statement in their own PGAs. In a shared server, this copy is in the UGA, which is in the large pool or in the shared pool when no large pool exists.
Figure 14-12 Private SQL Areas and Shared SQL Area
The library cache holds executable forms of PL/SQL programs and Java classes. These items are collectively referred to as program units.
The database processes program units similarly to SQL statements. For example, the database allocates a shared area to hold the parsed, compiled form of a PL/SQL program. The database allocates a private area to hold values specific to the session that runs the program, including local, global, and package variables, and buffers for executing SQL. If multiple users run the same program, then each user maintains a separate copy of his or her private SQL area, which holds session-specific values, and accesses a single shared SQL area.
The database processes individual SQL statements within a PL/SQL program unit as previously described. Despite their origins within a PL/SQL program unit, these SQL statements use a shared area to hold their parsed representations and a private area for each session that runs the statement.
The database allocates shared pool memory when a new SQL statement is parsed. The memory size depends on the complexity of the statement.
In general, an item in the shared pool stays until it is removed according to a least recently used (LRU) algorithm. The database allows shared pool items used by many sessions to remain in memory as long as they are useful, even if the process that created the item terminates. This mechanism minimizes the overhead and processing of SQL statements.
If space is needed for new items, then the database frees memory for infrequently used items. A shared SQL area can be removed from the shared pool even if the shared SQL area corresponds to an open cursor that has not been used for some time. If the open cursor is subsequently used to run its statement, then Oracle Database reparses the statement and allocates a new shared SQL area.
The database also removes a shared SQL area from the shared pool in the following circumstances:
If the database gathers statistics for a table, table cluster, or index, then by default the database gradually removes all shared SQL areas that contain statements referencing the analyzed object after a period. The next time a removed statement is run, the database parses it in a new shared SQL area to reflect the new statistics for the schema object.
If a schema object is referenced in a SQL statement, and if this object is later modified by a DDL statement, then the database invalidates the shared SQL area. The optimizer must reparse the statement the next time it is run.
If you change the global database name, then the database removes all information from the shared pool.
To assess the performance that can be expected after a database instance restart, use the
ALTER SYSTEM FLUSH SHARED_POOL statement to manually remove all information in the shared pool.
The data dictionary is a collection of database tables and views containing reference information about the database, its structures, and its users.
Oracle Database accesses the data dictionary frequently during SQL statement parsing. The data dictionary is accessed so often by Oracle Database that the following special memory locations are designated to hold dictionary data:
Data dictionary cache
This cache holds information about database objects. The cache is also known as the row cache because it holds data as rows instead of buffers.
All server processes share these caches for access to data dictionary information.
The server result cache is a memory pool within the shared pool. Unlike the buffer pools, the server result cache holds result sets and not data blocks.
A client result cache differs from the server result cache. A client cache is configured at the application level and is located in client memory, not in database memory.
Oracle Database Administrator’s Guide for information about sizing the result cache
Oracle Database PL/SQL Packages and Types Reference for information about the
Oracle Database Performance Tuning Guide for more information about the client result cache
The SQL query result cache is a subset of the server result cache that stores the results of queries and query fragments.
Most applications benefit from this performance improvement. Consider an application that runs the same
SELECT statement repeatedly. If the results are cached, then the database returns them immediately. In this way, the database avoids the expensive operation of rereading blocks and recomputing results.
When a query executes, the database searches memory to determine whether the result exists in the result cache. If the result exists, then the database retrieves the result from memory instead of executing the query. If the result is not cached, then the database executes the query, returns the result as output, and then stores the result in the result cache. The database automatically invalidates a cached result whenever a transaction modifies the data or metadata of database objects used to construct that cached result.
Users can annotate a query or query fragment with a
RESULT_CACHE hint to indicate that the database should store results in the SQL query result cache. The
RESULT_CACHE_MODE initialization parameter determines whether the SQL query result cache is used for all queries (when possible) or only for annotated queries.
The PL/SQL function result cache is a subset of the server result cache that stores function result sets.
Without caching, 1000 calls of a function at 1 second per call would take 1000 seconds. With caching, 1000 function calls with the same inputs could take 1 second total. Good candidates for result caching are frequently invoked functions that depend on relatively static data.
PL/SQL function code can include a request to cache its results. Upon invocation of this function, the system checks the cache. If the cache contains the result from a previous function call with the same parameter values, then the system returns the cached result to the invoker and does not reexecute the function body. If the cache does not contain the result, then the system executes the function body and adds the result (for these parameter values) to the cache before returning control to the invoker.
You can specify the database objects that Oracle Database uses to compute a cached result, so that if any of them are updated, the cached result becomes invalid and must be recomputed.
The cache can accumulate many results—one result for every unique combination of parameter values with which each result-cached function was invoked. If the database needs more memory, then it ages out one or more cached results.
The reserved pool is a memory area in the shared pool that Oracle Database can use to allocate large contiguous chunks of memory.
The database allocates memory from the shared pool in chunks. Chunking allows large objects (over 5 KB) to be loaded into the cache without requiring a single contiguous area. In this way, the database reduces the possibility of running out of contiguous memory because of fragmentation.
Infrequently, Java, PL/SQL, or SQL cursors may make allocations out of the shared pool that are larger than 5 KB. To allow these allocations to occur most efficiently, the database segregates a small amount of the shared pool for the reserved pool.
Oracle Database Performance Tuning Guide to learn how to configure the reserved pool
The large pool is an optional memory area intended for memory allocations that are larger than is appropriate for the shared pool.
The large pool can provide large memory allocations for the following:
UGA for the shared server and the Oracle XA interface (used where transactions interact with multiple databases)
Message buffers used in the parallel execution of statements
Buffers for Recovery Manager (RMAN) I/O slaves
By allocating session memory from the large pool, the database avoids the memory fragmentation that can occur when the database allocates memory from the shared pool. When the database allocates large pool memory to a session, this memory is not eligible to be released unless the session releases it. In contrast, the database manages memory in the shared pool in an LRU fashion, which means that portions of memory can age out.
Figure 14-13 is a graphical depiction of the large pool.
Figure 14-13 Large Pool
The large pool is different from reserved space in the shared pool, which uses the same LRU list as other memory allocated from the shared pool. The large pool does not have an LRU list. Pieces of memory are allocated and cannot be freed until they are done being used. As soon as a chunk of memory is freed, other processes can use it.
"Dispatcher Request and Response Queues" to learn about allocating session memory for shared server
Oracle Database Development Guide to learn about Oracle XA
Oracle Database Performance Tuning Guide for more information about the large pool
"Query Coordinator" for information about allocating memory for parallel execution
The Java pool is an area of memory that stores all session-specific Java code and data within the Java Virtual Machine (JVM). This memory includes Java objects that are migrated to the Java session space at end-of-call.
For dedicated server connections, the Java pool includes the shared part of each Java class, including methods and read-only memory such as code vectors, but not the per-session Java state of each session. For shared server, the pool includes the shared part of each class and some UGA used for the state of each session. Each UGA grows and shrinks as necessary, but the total UGA size must fit in the Java pool space.
The Java Pool Advisor statistics provide information about library cache memory used for Java and predict how changes in the size of the Java pool can affect the parse rate. The Java Pool Advisor is internally turned on when
statistics_level is set to
TYPICAL or higher. These statistics reset when the advisor is turned off.
The Streams pool stores buffered queue messages and provides memory for Oracle Streams capture processes and apply processes. The Streams pool is used exclusively by Oracle Streams.
Unless you specifically configure it, the size of the Streams pool starts at zero. The pool size grows dynamically as required by Oracle Streams.
The fixed SGA is an internal housekeeping area.
For example, the fixed SGA contains:
General information about the state of the database and the instance, which the background processes need to access
Information communicated between processes, such as information about locks
The size of the fixed SGA is set by Oracle Database and cannot be altered manually. The fixed SGA size can change from release to release.
A software code area is a portion of memory that stores code that is being run or can be run. Oracle Database code is stored in a software area that is typically more exclusive and protected than the location of user programs.
Software areas are usually static in size, changing only when software is updated or reinstalled. The required size of these areas varies by operating system.
Software areas are read-only and can be installed shared or nonshared. Some database tools and utilities, such as Oracle Forms and SQL*Plus, can be installed shared, but some cannot. When possible, database code is shared so that all users can access it without having multiple copies in memory, resulting in reduced main memory and overall improvement in performance. Multiple instances of a database can use the same database code area with different databases if running on the same computer.
The option of installing software shared is not available for all operating systems, for example, on PCs operating Microsoft Windows. See your operating system-specific documentation for more information.