2.Oracle体系结构-内存结构

Program code #程序代码
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 #缓存数据。例如我们常见的：数据块、redo 记录

Basic Memory Structures

Oracle Database includes several memory areas, each of which contains multiple subcomponents. #oracle分配的内存包含多个内存区域，每一个内存区域又包含多个子区域

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. #SGA是一组共享内存结构（所以这就是需要用到操作系统的共享内存的根因）。所有服务进程和后台进程可以共享SGA
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. #PGA是一块非共享的内存区域（所以根本用不到操作系统的共享内存因此计算kernel.shmall和kernel.shmmax值的时候计算SGA的值即可，不需要将PGA的值计算入内）。当oracle 进程（进程包括每一个服务进程和每一个后台进程）启动的时候就会创建一个PGA，而且每一个进程是独占的使用这个PGA

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. #系统为每一个服务进程和每一个后台进程而创建一个PGA，每一个PGA的总和即是整个实例的PGA。init参数文件中设置的PGA参数值是整个实例的参数不是单个 PGA的值。
User global area (UGA)

The UGA is memory associated with a user session. #UGA为用户会话而分配
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. #软件代码区域通常存放正在运行或者可运行的代码，Oracle Database 代码被存储在不同于用户程序区域的位置-位置被更严格独占和保护

内存结构如图：

2.3 内存管理

Oracle Database Memory Management

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.

就是使用ASMM或者AMM 或者两者都不使用。没什么好说的

2.4 User Global Area（UGA）

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. #UGA属于会话内存，分配用于存放变量信息，例如：登录信息和其他会话需要请求的信息，同时有会话的状态信息

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. #如果会话将PL/SQL包加载到内存中，则UGA包含包状态，它是在特定时间存储在所有包变量中的一组值。当程序包子程序更改变量时，程序包状态会发生变化。默认情况下，包变量是唯一的，并在会话的整个生命周期中保持不变

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. #OLAP页面池也存储在UGA中。此池管理OLAP数据页，这些数据页相当于数据块。页面池在OLAP会话开始时分配，在会话结束时释放。每当用户查询多维数据集等维度对象时，OLAP会话就会自动打开

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 #UGA必须在会话的整个生命周期内可用于数据库会话。因为这个原因。当使用共享服务器连接时，UGA不能存储在PGA中，因为PGA是被单个进程独占使用，所以UGA是存放在SGA中当使用共享服务器连接时，允许所有共享服务进程访问这个UGA。当使用独占服务器连接的时候UGA存放在PGA中

2.5 Program Global Area (PGA)

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. #PGA是指定用于操作进程或者线程，在系统上不被其他的进程或者线程共享。因为PGA是进程特定的且不会被分配到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. #PGA是一个内存堆，包含专用或共享服务器进程所需的会话相关变量。服务器进程在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. #下图展示了非共享服务器连接的整个实例PGA情况。你可以init中设置PGA的最大值，理论单个PGA可以增长到参数设定的值目标值，但是这个目标值是针对整个实例的，所以单个的PGA 不可能扩展到目标值，会被其他的PGA分摊。从图中可以看出每一个服务进程或者后台进程独占一个PGA,一个个的PGA 总和就是一个实例的PGA。

Note:Background processes also allocate their own PGAs. This discussion focuses on server process PGAs only. #后台进程也分配自己的PGA 但是这里重点讨论服务进程的PGA而已

Contents of the PGA

The PGA is subdivided into different areas, each with a different purpose. #PGA被分成不同的区域，每个区域有不同的作用

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. #下图展示了独占服务器连接的PGA。注意：并非所有的PGA区域都会在任何情况下存在

Private SQL Area

A private SQL area holds information about a parsed SQL statement and other session-specific information for processing.#私有SQL区域保存有关已解析SQL语句的信息以及其他会话特定信息以供处理。

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 #当服务器进程执行SQL或PL/SQL代码时，该进程使用专用SQL区域来存储绑定变量值、查询执行状态信息和查询执行工作区域。.

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. #不要将PGA中的私有SQL区域与存储SGA中执行计划的共享SQL区域混淆。相同或不同会话中的多个私有SQL区域可以指向SGA中的单个执行计划。例如，在一个会话中执行20次SELECT*FROM销售和在不同会话中执行10次相同查询可以共享同一计划。每次执行的专用SQL区域不共享，可能包含不同的值和数据

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. #游标是特定私有SQL区域的名称或句柄。如下图所示，您可以将游标视为客户端的指针和服务器端的状态。由于游标与私有SQL区域密切相关，因此这些术语有时可以互换使用

A private SQL area is divided into the following areas:#专有SQL区域又可以分为以下区域

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 #Oracle数据库创建运行时区域作为执行请求的第一步。对于DML语句，当SQL语句关闭时，将释放运行时区域.
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. #此区域包含绑定变量值。在执行SQL语句时，会在运行时将绑定变量值提供给该语句。只有当游标关闭时，持久区域才会被释放

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 OPEN_CURSORS. #客户端进程负责管理私有SQL区域。私有SQL区域的分配和解除分配在很大程度上取决于应用程序，尽管客户端进程可以分配的私有SQL区域数量受到初始化参数OPEN_CURSORS的限制

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. #尽管大多数用户依赖于数据库实用程序的自动游标处理，但Oracle数据库编程接口为开发人员提供了对游标的更多控制。一般来说，应用程序应该关闭所有打开的游标，这些游标将不再使用，以释放持久区域并最大限度地减少应用程序用户所需的内存

SQL Work Areas

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 #例如，排序操作使用排序区域对一组行进行排序。类似地，hash 连接操作使用hash 区域去创建hash 表；位图合并使用位图合并区域合并从多个位图索引扫描来的数据。

The following example shows a join of employees and departments with its query plan:

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.#在前面的示例中，运行时区域跟踪 full table scan 的进度。会话在哈希区域中执行哈希联接，以匹配两个表中的行。ORDER BY排序出现在排序区域中。

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. #如果处理的数据量不适合一个工作区域，那么Oracle数据库会将输入数据划分为更小的部分。通过这种方式，数据库处理内存中的一些数据，同时将其余数据写入临时磁盘（即临时表空间）以供稍后处理。

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. #启用自动PGA内存管理时，数据库会自动调整工作区大小。也可以手动控制和调整工作区域的大小

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. #通常，较大的工作区域可以以较高的内存消耗为代价显著提高操作的性能。最理想的情况是，工作区的大小足以容纳输入的数据及其相关SQL操作分配的辅助内存结构。否则，响应时间会增加，因为部分输入数据必须缓存在磁盘上。在极端情况下，如果工作区域的大小与输入数据的大小相比太小，则数据库必须对数据段执行多次传递，从而大大增加响应时间

PGA Usage in Dedicated and Shared Server Modes

PGA memory allocation depends on whether the database uses dedicated or shared server connections. #PGA内存分配取决于数据库使用专用服务器连接还是共享服务器连接。

The following table shows the differences.

Memory Area	Dedicated Server	Shared Server
Nature of session memory #会话内存属性	Private	Shared
Location of the persistent area #永久区域所在位置	PGA	SGA
Location of the run-time area for DML and DDL statements # 为DDL\DML服务的运行时区域的所在位置	PGA	PGA

Memory Area

Dedicated Server

Shared Server

Nature of session memory #会话内存属性

Private

Shared

Location of the persistent area #永久区域所在位置

PGA

SGA

Location of the run-time area for DML and DDL statements

# 为DDL\DML服务的运行时区域的所在位置

PGA

2.6 System Global Area (SGA)

The SGA is a read/write memory area that, along with the Oracle background processes, form a database instance #SGA是一个读/写内存区域，与Oracle后台进程一起形成数据库实例。.

Note: The server and background processes do not reside within the SGA, but exist in a separate memory space #注意：服务器和后台进程不位于SGA中，而是存在于单独的内存空间中。.

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 #所有服务器进程都可以读取实例SGA中的信息。在数据库操作期间，有几个进程写入SGA。.

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: #每个数据库实例都有自己的SGA。Oracle数据库在实例启动时自动为SGA分配内存，并在实例关闭时回收内存。使用SQL*Plus或Oracle Enterprise Manager启动实例时，SGA的大小如下例所示：

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 #SGA由几个内存组件组成，这些组件是用于满足特定类型内存分配请求的内存池。除了重做日志缓冲区之外，所有SGA组件都以称为细粒的连续内存为单位分配和释放内存空间。细粒的尺寸由特定平台和总的SGA尺寸所决定。

You can query the V$SGASTAT view for information about SGA components. #可以通过V$SGASTAT 视图获取SGA的组件信息

The most important SGA components are the following:

Database Buffer Cache #数据库缓冲区
In-Memory Area #内存空间
Redo Log Buffer #重做日志缓冲区
Shared Pool #共享池
Large Pool #大池
Java Pool #JAVA池
Fixed SGA #固定SGA
Optional Performance-Related SGA Subareas #可选性能相关的SGA子区

Database Buffer Cache

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. #缓冲区缓存当前或最近使用的数据块。同时连接到数据库实例的所有用户共享访问缓冲区。

Purpose of the Database Buffer Cache

Oracle Database uses the buffer cache to achieve multiple goals. #ORACLE使用数据库缓冲区实现多个目的

The goals include #目的包括如下:

Optimize physical I/O #优化物理IO

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. #数据库更新缓存中的数据块，并将有关更改的元数据存储在重做日志缓冲区中。COMMIT之后，数据库将重做缓冲区写入在线重做日志，但不会立即将数据块写入数据文件。相反，数据库写入（DBW）在后台执行延迟写入
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 devices. The database can improve performance by caching buffers in flash memory instead of reading from magnetic disk #启用数据库智能闪存（闪存）时，部分缓冲区缓存可以位于闪存中。此缓冲区缓存扩展存储在一个或多个闪存设备上。数据库可以通过在闪存中缓存缓冲区而不是从磁盘读取来提高性能。.

Use the DB_FLASH_CACHE_FILE and DB_FLASH_CACHE_SIZE initialization parameters to configure multiple flash devices. The buffer cache tracks each device and distributes buffers to the devices uniformly. #使用DB_FLASH_CACHE_FILE和DB_FLASH-CACHE_SIZE初始化参数配置多个闪存设备。缓冲高速缓存跟踪每个设备，并将缓冲区均匀地分配给这些设备。

Note:Database Smart Flash Cache is available only in Solaris and Oracle Linux #db 闪存只可以在Solaris and Oracle Linux 中生效 .

Manage buffer headers that point to data files in Oracle Persistent Memory Filestore (PMEM Filestore) #管理指向Oracle持久内存文件库（PMEM Filestore）中数据文件的缓冲区标头

If you enable PMEM Filestore, then database files are mapped for direct read-only access. Queries can bypass the traditional buffer cache mechanism, avoiding unnecessary I/O. In this case, buffer headers must store metadata corresponding to the PMEM blocks. The database can still use the traditional (DRAM) buffer cache for modifications, read consistency, and faster access for "hot" data blocks. #如果启用PMEM Filestore，则会映射数据库文件以进行直接只读访问。查询可以绕过传统的缓冲区缓存机制，避免不必要的I/O。在这种情况下，缓冲区头必须存储与PMEM块相对应的元数据。数据库仍然可以使用传统的（DRAM）缓冲缓存进行修改、读取一致性和更快地访问“热”数据块

Buffer States

The database uses internal algorithms to manage buffers in the cache. #ORACLE使用内部算法来管理缓存

A buffer can be in any of the following mutually exclusive states: #缓冲区可以处于以下任何互斥状态：

Unused #未使用

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. #此状态的缓冲区可供使用，因为它从未使用过或当前未使用。这种类型的缓冲区对数据库来说是最容易使用的。
Clean #清理的

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. #此缓冲区以前使用过，现在包含截至某个时间点的块的读取一致性版本。该块包含数据，但是“干净的”，因此不需要进行检查点操作。数据库可以pin并重用它
Dirty #脏

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. #每个缓冲区都有一种访问模式：固定(pin)或取消固定(unpin)。缓冲区被“固定(pin)”在缓存中，这样当用户会话访问缓冲区时，缓冲区就不会耗尽内存。多个会话不能同时修改固定(pin)的缓冲区

Buffer Modes

When a client requests data, Oracle Database retrieves buffers from the database buffer cache in either current mode or consistent mode. #当客户端请求数据时，Oracle数据库会以当前模式或一致模式从数据库缓冲区缓存中检索数据

The modes differ as follows:

Current mode #当前模式

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 #当前模式get，也称为db块get，是对当前出现在缓冲区缓存中的块的检索。例如，如果一个未提交的事务更新了一个块中的两行，那么当前模式get将检索具有这些未提交行的块。数据库在修改语句期间最频繁地使用db块get，修改语句必须且仅能更新当前版本的块.
Consistent mode #一致模式

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. #一致读取获取是对块的读取一致版本的检索。此检索可能使用撤消数据。例如，如果未提交的事务已更新了块中的两行，并且单独会话中的查询请求了该块，则数据库将使用撤消数据创建该块的读取一致性版本（称为一致读取克隆），该版本不包括未提交的更新。通常，查询以一致模式检索块

Buffer I/O

A logical I/O, also known as a buffer I/O, refers to reads and writes of buffers in the buffer cache.#逻辑I/O，也称为缓冲区I/O，是指缓冲区的读取和写入。

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. #当在内存中找不到请求的缓冲区时，数据库会执行物理I/O，将缓冲区从闪存或磁盘复制到内存中。然后，数据库执行逻辑I/O以读取缓存的缓冲区。

Buffer Replacement Algorithms

To make buffer access efficient, the database must decide which buffers to cache in memory, and which to access from disk. #为了提高缓冲区访问效率，oracle必须决定哪些数据块缓存在内存中，哪些数据块是从磁盘中访问

The database uses the following algorithms:

LRU-based, block-level replacement algorithm #基于LRU（least recently used）的块级替换算法

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. #默认情况下，这种复杂的算法使用最近、最少使用（LRU least recently used ）列表，该列表包含指向脏缓冲区和非脏缓冲区的指针。LRU列表有热端和冷端。冷缓冲区是指最近没有使用过的缓冲区。热缓冲区指经常被访问，最近也被使用过。从概念上讲，只有一个LRU，但对于数据并发，数据库实际上使用了几个LRU
Temperature-based, object-level replacement algorithm #基于温度（即是否经常被访问）的对象级替换算法

Starting in Oracle Database 12c Release 1 (12.1.0.2), the automatic big table caching feature enables table scans to use a different algorithm in the following scenarios: #从Oracle Database 12c Release 1（12.1.0.2）开始，自动大表缓存功能使表扫描能够在以下场景中使用不同的算法：
- Parallel queries #并行查询
  
  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 auto or adaptive. #在单实例和Oracle Real Applications Cluster（Oracle RAC）数据库中，当DB_big_table_cache_PERCENT_TARGET初始化参数设置为非零值，并且parallel_DEGREE_POLICY设置为自动或自适应时，并行查询可以使用大表缓存
- Serial queries #串行查询
  
  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. #仅在单实例配置中，当DB_big_table_cache_PERCENT_TARGET初始化参数设置为非零值时，串行查询可以使用大表缓存。
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 #当表大小不适合内存时，数据库会根据访问模式决定缓存哪些缓冲区。例如，如果一个流行的表中只有95%适合内存，那么数据库可能会选择将5%的块留在磁盘上，而不是循环地将块读取到内存中并将块写入磁盘——这种现象被称为抖动。当缓存多个大型对象时，数据库会认为更流行的表更热，而不太流行的表则更冷，这会影响缓存哪些块。DB_BIG_TABLE_CACHE_PERCENT_TARGET初始化参数设置使用此算法的缓冲区缓存的百分比.

Buffer Writes

The database writer (DBW) process periodically writes cold, dirty buffers to disk #数据库写入程序（DBW）进程定期将冷的、脏的缓冲区写入磁盘。

DBW writes buffers in the following circumstances: #DBW在以下情况下写入缓冲区

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. #当缓冲区被弄脏时，可用缓冲区的数量就会减少。如果这个数字降到内部阈值以下，并且有干净缓冲区的请求，则服务器处理信号DBW进行写入。

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 #数据库使用LRU来确定要写入哪些脏缓冲区。当脏缓冲区到达LRU的冷端时，数据库将它们从LRU移到写入队列。DBW将队列中的缓冲区写入磁盘，如果可能的话，使用多块写入。该机制可防止LRU的末端被脏缓冲器堵塞，并允许找到干净的缓冲器进行重复使用.
The database must advance the checkpoint, which is the position in the redo thread from which instance recovery must begin. #数据库必须执行检查点，实例恢复时必须得从重做线程中的检查点位置开始
Tablespaces are changed to read-only status or taken offline. #表空间更改为只读状态或脱机。

Buffer Reads

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 #DBW可以将干净缓冲区的主体写入闪存缓存，从而实现其内存缓冲区的重用。数据库将缓冲区头保存在主存储器的LRU列表中，以跟踪闪存中缓冲区主体的状态和位置。如果以后需要这个缓冲区，那么数据库可以从闪存中读取，而不是从磁盘中读取。.

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. #服务器进程在闪存LRU列表中搜索缓冲区头部。

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: #如果进程在内存中找不到缓冲区（即在缓存区检索不到数据块）（缓存未命中），则服务器进程将执行以下步骤：
1. Copies the block from a data file on disk into memory (a physical read) #将块从磁盘上的数据文件复制到内存中（物理读取）
2. Performs a logical read of the buffer that was read into memory #对已读入内存的缓冲区数据块执行逻辑读取

下图显示了检索buffer 中数据块的顺序：

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. #数据库可以从数据文件或临时文件执行物理读取。从数据文件读取之后是逻辑I/O。当内存不足迫使数据库将数据写入临时表并在以后读回时，就会发生从临时文件中读取数据的情况。这些物理读取绕过缓冲区缓存，不会产生逻辑I/O。

Buffer Touch Counts

#缓冲区接触计数

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. #数据库使用触摸计数来计算LRU列表上的缓冲区的访问频率。这种机制使数据库能够在pin缓冲区时增加计数，而不是不断地统计LRU列表上的缓冲区。

Note:The database does not physically move blocks in memory. The movement is the change in location of a pointer on a list.#注意：数据库不会在内存中物理移动块。移动是指针在LRU列表上的位置变化。

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. #当缓冲区被pin（固定）时候，数据库会确定其触摸次数上次增加的时间。如果计数在三秒前递增，则计数递增；否则，计数保持不变。三秒规则可以防止缓冲区上的一连串的pin 次数与触摸数一样多。例如，会话可以在数据块中插入几行，但数据库将这些插入视为一次触摸

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. #如果一个缓冲区位于LRU的冷端，但其触摸次数较高，则该缓冲区移动到热端。如果触摸次数较低，则缓冲区会从缓存中老化（即从缓冲区中删掉或者被重用）。

Buffer Pools

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:#可能的缓冲池如下：

Default pool #默认池

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. #此池是块通常缓存的位置。除非手动配置单独的池，否则默认池是唯一的缓冲池。其他池的可选配置对默认池没有影响

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 auto or adaptive. In single-instance configurations only, serial queries can use the big table cache when DB_BIG_TABLE_CACHE_PERCENT_TARGET is set. #大表缓存是默认池的一个可选部分，它使用基于温度的对象级替换算法。在单实例和Oracle RAC数据库中，当DB_big_table_cache_PERCENT_TARGET初始化参数设置为非零值，并且parallel_DEGREE_POLICY设置为自动或自适应时，并行查询可以使用大表缓存。仅在单实例配置中，当设置了DB_big_table_cache_PERCENT_TARGET时，串行查询可以使用大表缓存
Keep pool #保留池

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. #此池适用于频繁访问但由于空间不足而在默认池之外老化的块。keep缓冲池的目的是将对象保留在内存中，从而避免I/O操作

Note: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. #注意：keep池管理缓冲区的方式与其他池相同：它不使用特殊的算法来固定缓冲区。单词“keep”是一种命名约定。可以将要保留的表放在较大的保留池中，也可以将不想保留的表放置在较小的回收池中

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. #数据库具有标准块大小。您可以创建一个块大小不同于标准大小的表空间。每个非默认块大小都有自己的池。Oracle数据库以与默认池相同的方式管理这些池中的块。

The following figure 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. #下图显示了使用多个池时缓冲区缓存的结构。缓存包含默认池、保留池和回收池。默认块大小为8 KB。缓存包含表空间的独立池，这些表空间使用2 KB、4 KB和16 KB的非标准块大小。

Buffers and Full Table Scans

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. #数据库使用复杂的算法来管理表扫描。默认情况下，当必须从磁盘读取到缓冲区时，数据库会将缓冲区插入LRU列表的中间。通过这种方式，热块可以保留在缓存中，这样就不需要再次从磁盘读取它们

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. #全表扫描带来了一个问题，它按顺序读取表高水位线（HWM）下的所有行。假设表段中块的总大小大于缓冲区缓存的大小。对该表全扫描可以清除缓冲区缓存，从而防止数据库维护频繁访问的块的缓存

Default Mode for Full Table Scans

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. #对于非常大的表，数据库通常使用直接路径读取（将块直接加载到PGA中），并完全绕过SGA，以避免填充缓冲缓存。对于中等大小的表，数据库可以使用直接读取或高速缓存读取。如果决定使用缓存读取，则数据库将块放置在LRU列表的末尾，以防止扫描有效地清除缓冲区缓存

Starting in Oracle Database 12c Release 1 (12.1.0.2), 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 NOCACHE attribute. #从Oracle Database 12c Release 1（12.1.0.2）开始，数据库实例的缓冲区缓存会自动执行内部计算，以确定内存是否足以使数据库完全缓存在实例SGA中，以及在访问时缓存表是否有利于性能。如果整个数据库能够完全容纳在内存中，并且满足其他各种内部条件，那么Oracle数据库会将数据库中的所有表视为小表，并认为它们有资格进行缓存。但是，数据库不会缓存标有NOCACHE属性的LOB

Parallel Query Execution

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. #在某些情况下，当数据库具有大量内存时，数据库可以将并行查询数据缓存在系统全局区域（SGA）中，而不是使用直接路径读取到程序全局区域（PGA）中。通常，由于潜在的资源使用，并行查询发生在低并发数据仓库中

CACHE Attribute

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. #可以使用ALTER TABLE。。。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. #对于设置了CACHE属性的表，数据库不会强制或固定（pin）缓冲区缓存中的块。相反，数据库以与任何其他表块相同的方式将块从缓存中老化。使用此选项时要小心，因为对大表进行完全扫描可能会清除缓存中的大部分其他块

KEEP Attribute

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. #对于大型表，可以使用ALTER TABLE。。。STORAGE BUFFER_POOL KEEP使扫描将这些表的块加载到保留池中

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. #将表放入保留池会更改存储块的缓冲区缓存部分。数据库不将块缓存在默认缓冲池中，而是将它们缓存在保留缓冲池中。没有单独的算法控制来保留池缓存

Force Full Database Caching Mode

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. #为了在某些情况下提高性能，可以显式执行ALTER DATABASE。。。FORCE FULL DATABASE CACHING语句，以启用强制完全数据库缓存模式

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 database buffer cache. This mode is available starting in Oracle Database 12c Release 1 (12.1.0.2). #与自动的默认模式不同，强制完整数据库缓存模式将整个数据库（包括NOCACHE LOB）视为有资格在数据库缓冲区缓存中进行缓存。此模式可从Oracle Database 12c Release 1（12.1.0.2）开始使用

Note:Enabling force full database caching mode does not force the database into memory. Rather, the entire database is eligible to be cached in the buffer cache. Oracle Database caches tables only when they are accessed. #注意：启用强制完全数据库缓存模式不会强制数据库进入内存。相反，整个数据库都有资格缓存在缓冲区缓存中。Oracle数据库仅在访问表时缓存表

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. #Oracle建议，只有当每个实例的缓冲区缓存大小大于数据库大小时，才启用强制完全数据库缓存模式。适用于单实例数据库和Oracle RAC数据库。但是，当Oracle RAC应用程序分区良好时，当所有实例的组合缓冲区缓存（以及用于处理实例之间重复缓存块的额外空间）大于数据库大小时，可以启用强制完全数据库缓存模式。

DRAM and PMEM Buffers

#该方式目前生产很少见使用

Standard (DRAM) database buffers differ from PMEM buffers, but they share characteristics.

When Oracle Persistent Memory Filestore (PMEM Filestore) is configured, every data block is directly mapped to the buffer cache in DRAM. Unlike DRAM buffers, PMEM buffers do not copy the contents of data blocks. Rather, PMEM buffer headers point to data blocks stored in PMEM Filestore. For most reads, the database only caches the block metadata, not the contents. PMEM buffers use a special type of granule whose structure is different from standard buffer cache granules. #当配置Oracle持久内存文件存储（PMEM Filestore）时，每个数据块都会直接映射到DRAM中的缓冲区缓存。与DRAM缓冲区不同，PMEM缓冲区不复制数据块的内容。相反，PMEM缓冲区头指向存储在PMEM Filestore中的数据块。对于大多数读取，数据库只缓存块元数据，而不缓存内容。PMEM缓冲区使用一种特殊类型的颗粒，其结构不同于标准缓冲区缓存颗粒。。

Note:The initialization parameter DB_CACHE_SIZE specifies the minimum size of the DRAM cache. PMEM metadata overhead is not included in this allocation.

PMEM buffers can be in any of the following states:

Current

This is the current version of a PMEM buffer. It can be directly accessed from the filestore.

Oracle Database keeps the PMEM current version separate from the standard DRAM buffer current version. This separation helps to reduce code complexity during PMEM block pinning, cleanup, and migrate to DRAM.
Consistent

This is the consistent read version of a PMEM buffer. It is created after the database creates a clone in DRAM. The PMEM buffer can be directly accessed from the filestore.
Free

This is a free PMEM buffer. It can be reused by a PMEM block. After instance startup, all PMEM buffers are in a free state.

PMEM has higher latency than DRAM. Oracle Database uses an internal, workload-based algorithm to decide which blocks to migrate from PMEM to DRAM.

Redo Log Buffer

The redo log buffer is a circular buffer in the SGA that stores redo entries describing changes made to the database. #重做日志缓冲区是SGA中的一个循环缓冲区，用于存储描述对数据库所做更改的重做条目

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. #重做记录是一种数据结构，包含重建或重做DML或DDL操作对数据库所做更改所需的信息。数据库恢复将重做项应用于数据文件，以重建丢失的更改

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 16-8 shows this redo buffer activity. #重做条目占用缓冲区中连续的、连续的空间。后台进程日志写入进程（LGWR）将重做日志缓冲区写入磁盘上的活动联机重做日志组。

下图显示了这个重做缓冲区活动

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. #LGWR将重做条目顺序写入磁盘，而DBW将数据块分散写入磁盘。分散写入往往比顺序写入慢得多。因为LGWR使用户能够避免等待DBW完成其缓慢的写入，所以数据库提供了更好的性能

The 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. #LOG_BUFFER初始化参数指定Oracle数据库在缓冲重做项时使用的内存量。与其他SGA组件不同，重做日志缓冲区和固定SGA缓冲区不将内存划分为颗粒

Shared Pool

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. #例如，共享池存储解析的SQL、PL/SQL代码、系统参数和数据字典信息。共享池几乎涉及数据库中发生的每一个操作。例如，如果用户执行SQL语句，那么Oracle数据库将访问共享池。

The shared pool is divided into several subcomponents, the most important of which are shown in #共享池分为几个子组件，其中最重要的如图下图：

This section includes the following topics: #本节包括以下主题：

Library Cache #库缓存
Data Dictionary Cache # 数据字典缓存
Server Result Cache #服务器结果缓存
Reserved Pool #保留池

Library Cache

The library cache is a shared pool memory structure that stores executable SQL and PL/SQL code. #库缓存是一种共享池内存结构，用于存储可执行SQL和PL/SQL代码。

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.#该缓存包含共享的SQL和PL/SQL区域以及控制结构，如锁和库缓存句柄。在共享服务器体系结构中，库缓存还包含专用SQL区域。

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. #执行SQL语句时，数据库会尝试重用以前执行的代码。如果SQL语句的解析表示存在于库缓存中并且可以共享，那么数据库将重用该代码，称为软解析或库缓存命中。否则，数据库必须构建应用程序代码的新可执行版本，称为硬解析或库缓存未命中。

Shared SQL Areas

The database represents each SQL statement that it runs in the shared SQL area and private SQL area. #数据库表示它在共享SQL区域和专用SQL区域中运行的每个SQL语句。

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. #数据库使用共享SQL区域来处理（即提供内存区域）首次执行的SQL。所有用户都可以访问此区域，其中包含语句解析树和执行计划。对于一个唯一的语句，只会存在一个共享SQL区域。每个发出SQL语句的会话在其PGA中都有一个专用SQL区域。每个提交同一语句的用户都有指向同一共享SQL区域的专用SQL区域。因此，单独的PGA中的许多私有SQL区域可以与同一共享SQL区域相关联

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. #数据库会自动确定应用程序何时提交类似的SQL语句。数据库既考虑用户和应用程序直接发布的SQL语句，也考虑其他语句内部发布的递归SQL语句

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: 检查共享池以查看是否存在语法和语义相同的语句的共享SQL区域：
- 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. #如果存在相同的语句，那么数据库将使用共享SQL区域来执行该语句，从而减少内存消耗
- 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. #如果不存在相同的语句，则数据库会在共享池中分配一个新的共享SQL区域。语法相同但语义不同的语句使用子游标
In either case, the private SQL area for the user points to the shared SQL area that contains the statement and execution plan. #在任何一种情况下，用户的专用SQL区域都指向包含语句和执行计划的共享SQL区域。！！重点
Allocates a private SQL area on behalf of the session #会话分配专用SQL区域

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. #专用SQL区域的位置取决于为会话建立的连接。如果会话是通过共享服务器连接的，那么部分专用SQL区域将保留在SGA中

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. #下图显示了一种专用的服务器体系结构，其中两个会话将同一SQL语句的副本保存在各自的PGA中。在共享服务器中，此副本位于UGA中，UGA位于大池中，或者在不存在大池时位于共享池中。

Program Units and the Library Cache

The library cache holds executable forms of PL/SQL programs and Java classes. These items are collectively referred to as program units. #库缓存保存了可执行的PL/SQL程序和Java类。这些项目统称为程序单元。

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. #数据库处理程序单元的方式类似于SQL语句。例如，数据库分配一个共享区域来保存PL/SQL程序的解析、编译形式。数据库分配一个专用区域来保存运行程序的会话特定的值，包括本地、全局和包变量，以及用于执行SQL的缓冲区。如果多个用户运行同一个程序，那么每个用户都会维护其专用SQL区域的一个单独副本，该副本包含特定于会话的值，并访问单个共享SQL区域

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. #如前所述，数据库在PL/SQL程序单元中处理单个SQL语句。尽管这些SQL语句起源于PL/SQL程序单元，但它们使用一个共享区域来保存解析后的计划，并为运行该语句的每个会话使用一个专用区域（通俗的讲就是：会将PL/SQL拆分执行，单独分内存）

Allocation and Reuse of Memory in the Shared Pool

#共享池中内存的分配和重用

The database allocates shared pool memory when a new SQL statement is parsed, unless the statement is DDL, which is not considered sharable. The size of memory allocated depends on the complexity of the statement. #当解析新的SQL语句时，数据库会分配共享池内存，除非该语句是DDL，这是不可共享的。分配的内存大小取决于语句的复杂性。

In general, an item in the shared pool stays until the database removes it 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 database 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 consumed by infrequently used items. #通常，共享池中的项目会一直保留，直到数据库根据最近最少使用（LRU）算法将其删除。数据库允许许多会话使用的共享池项目保留在内存中，只要它们有用，即使创建该项目的数据库进程终止。这种机制最大限度地减少了SQL语句的开销和处理。如果新项目需要空间，那么数据库会释放不常用项目所消耗的内存

The ALTER SYSTEM FLUSH SHARED_POOL statement removes all information in the shared pool, as does changing the global database name. #ALTER SYSTEM FLUSH SHARED_POOL语句删除共享池中的所有信息，更改全局数据库名称也是如此

Data Dictionary Cache

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: #Oracle数据库在SQL语句解析过程中频繁访问数据字典。Oracle数据库经常访问数据字典，因此指定了以下特殊内存位置来保存字典数据

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. #此缓存保存有关数据库对象的信息。缓存也称为行缓存，因为它将数据保存为行而不是缓冲区
Library cache #库缓存

All server processes share these caches for access to data dictionary information. #所有服务器进程共享这些缓存以访问数据字典信息。

Server Result Cache

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. #服务器结果缓存是共享池中的内存池。与缓冲池不同，服务器结果缓存保存的是结果集，而不是数据块

Note: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. #注意：客户端结果缓存与服务器结果缓存不同。客户端缓存是在应用程序级别配置的，位于客户端内存中，而不是数据库内存中

SQL Query Result Cache

The SQL query result cache is a subset of the server result cache that stores the results of queries and query fragments. You can enable or disable result caching at the database or statement level. #SQL查询结果缓存是存储查询结果和查询片段的服务器结果缓存的子集。可以在数据库或语句级别启用或禁用结果缓存

When a query executes, the database determines whether the result exists in the query result cache. If the result is not cached, and if caching is enabled for the query, then the database runs the query, returns the result, and then caches it. If the result exists, however, then the database retrieves it from the cache instead of executing the query. #当执行查询时，数据库会确定查询结果缓存中是否存在该结果。如果未缓存结果，并且为查询启用了缓存，则数据库运行查询，返回结果，然后缓存它。但是，如果结果存在，则数据库从缓存中检索结果，而不是执行查询

The database automatically invalidates a cached result whenever a transaction modifies the data or metadata of database objects used to construct the result. The next query cannot use the cached result, so the database automatically computes a new result, and then caches it for use by subsequent queries. The cache refresh process is transparent to the application. #每当事务修改用于构造结果的数据库对象的数据或元数据时（就是DDL），数据库就会自动使缓存的结果无效。下一个查询无法使用缓存的结果，因此数据库会自动计算一个新结果，然后将其缓存以供后续查询使用。缓存刷新过程对应用程序是透明的

In effect, the query result cache functions as a "just-in-time" materialized view that the database creates and maintains as needed. The cache enables the database to avoid the expensive operation of rereading data blocks and recomputing results. Most applications benefit from this performance improvement. #实际上，查询结果缓存充当数据库根据需要创建和维护的“即时”物化视图。缓存使数据库能够避免重新读取数据块和重新计算结果的昂贵操作。大多数应用程序都受益于这种性能改进

PL/SQL Function Result Cache

The PL/SQL function result cache is a subset of the server result cache that stores function result sets. #PL/SQL函数结果缓存是存储函数结果集的服务器结果缓存的子集。

Without caching, 1000 calls of a PL/SQL 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. #如果没有缓存，以每秒1秒的速度对PL/SQL函数进行1000次调用将花费1000秒。有了缓存，1000个具有相同输入的函数调用总共可能需要1秒的时间。结果缓存的好候选者是依赖于相对静态数据的频繁调用的函数

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 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. #PL/SQL函数代码可以包括缓存其结果的请求。调用此函数后，系统会检查缓存。如果缓存包含具有相同参数值的上一个函数调用的结果，则系统将结果返回给调用程序，而不重新执行函数体。如果缓存不包含结果，则系统执行函数体并将结果（对于这些参数值）添加到缓存中，然后将控制权返回给调用程序。

Note:You can specify the database objects used to compute a cached result, so that if any of them are updated, the cached result becomes invalid and must be recomputed #可以指定用于计算缓存结果的数据库对象，这样，如果其中任何对象被更新，则缓存结果将无效，必须重新计算.

A function that is invoked frequently with different arguments may generate results that are rarely reused, leading to performance degradation. Oracle Database tracks recently used PL/SQL functions that have the RESULT_CACHE hint. Using this history, the database only caches a PL/SQL function and argument pair if it has seen it x times in recent history, where x is set by an internal threshold. If the database needs more memory because too many results are cached, then one or more cached results are aged out. #使用不同参数频繁调用的函数可能会生成很少重复使用的结果，从而导致性能下降。Oracle数据库跟踪最近使用的带有RESULT_CACHE提示的PL/SQL函数。使用此历史记录，如果数据库在最近的历史记录中见过PL/SQL函数和参数对x次，则仅缓存该函数和参数，其中x由内部阈值设置。如果数据库因为缓存了太多结果而需要更多内存，那么一个或多个缓存的结果就会过期

RESULT_CACHE_EXECUTION_THRESHOLD specifies the number of times a function and a particular set of arguments must be seen until it is cached. Note that functions are considered unique if they have different arguments, for example, MYFUNC(1,2) and MYFUNC(1,3). You can only set this parameter at the system level, not the session level. #RESULT_CACHE_EXECION_THRESHOLD指定在缓存函数和一组特定参数之前必须查看的次数。请注意，如果函数具有不同的自变量，例如，MYFUNC（1,2）和MYFUNC（1,3），则它们被认为是唯一的。只能在系统级别而不能在会话级别设置此参数

Server Result Cache Infrastructure

#服务器结果缓存基础结构

The query result cache and PL/SQL function result cache share the same infrastructure. #查询结果缓存和PL/SQL函数结果缓存共享相同的基础结构。

Object Types: Result, Dependency, and Temp #对象类型：结果、依赖项和临时

Within the server result cache, a result object is a data structure that stores the rows returned by a query or PL/SQL function. A dependency object stores the metadata for objects referred to by queries stored as result objects. #在服务器结果缓存中，结果对象是存储查询或PL/SQL函数返回的行的数据结构。依赖对象存储作为结果对象存储的查询所引用的对象的元数据

A typical query result is small, expensive to compute, reused often, and based on non-volatile tables. However, results can sometimes be large. If a query result passes the size limit, then the database stores part of the result as a temp object and part as a standard result object. A temp object is a collection of result cache metadata that points to a temporary tablespace segment that holds the actual query result. #典型的查询结果很小，计算成本很高，经常重复使用，并且基于非易失性表。然而，结果有时可能很大。如果查询结果超过了大小限制，那么数据库将部分结果存储为临时对象，另一部分存储为标准结果对象。临时对象是结果缓存元数据的集合，指向保存实际查询结果的临时表空间段

Result Subcaches #结果子缓存

Depending on the workload, the database may create result subcaches to support higher concurrency during read/write access. Oracle Database uses an internal algorithm to decide whether to create subcaches, and if so, how many to create . #根据工作负载的不同，数据库可能会创建结果子缓存，以在读/写访问期间支持更高的并发性。Oracle数据库使用内部算法来决定是否创建子缓存，如果是，则创建多少子缓存。

Server Result Cache User Interface

#服务器结果缓存用户接口

The RESULT_CACHE_MODE initialization parameter determines whether the SQL query result cache is used for all possible queries or only for hinted queries. #RESULT_CACHE_MODE初始化参数确定SQL查询结果缓存是用于所有可能的查询，还是仅用于提示查询

The RESULT_CACHE_MAX_TEMP_SIZE initialization parameter controls the maximum amount of temporary tablespace memory that the result cache can consume in the PDB. RESULT_CACHE_MAX_TEMP_RESULT controls the maximum amount of temporary tablespace memory that one cached query can consume. #RESULT_CACHE_MAX_TEMP_SIZE初始化参数控制结果缓存可以在PDB中消耗的最大临时表空间内存量。RESULT_CACHE_MAX_TEMP_RESULT控制一个缓存查询可以消耗的最大临时表空间内存量

To override the RESULT_CACHE_MODE parameter setting, you can annotate a query or query fragment with a RESULT_CACHE hint. Starting in Oracle Database 21c, the hint accepts the option TEMP={TRUE|FALSE}, which controls whether the results can be stored in a temporary tablespace. #要覆盖RESULT_CACHE_MODE参数设置，可以使用RESULT_CACHE提示注释查询或查询片段。从Oracle数据库21c开始，提示接受选项TEMP＝｛TRUE|FALSE｝，该选项控制结果是否可以存储在临时表空间中

The DBMS_RESULT_CACHE package enables you to administer that part of the shared pool that is used by the SQL result cache and the PL/SQL function result cache. You can invalidate objects, blacklist queries and objects, and perform related operations. #DBMS_RESULT_CACHE包使您能够管理SQL结果缓存和PL/SQL函数结果缓存所使用的共享池的那部分。您可以使对象失效，将查询和对象列入黑名单，并执行相关操作。

The V$RESULT_CACHE_OBJECTS.TYPE column indicates the type of objects in the cache. If query results are stored in temporary tablespace, then TYPE shows two objects: Result and Temp. Subcache metadata is accessible using V$RESULT_SUBCACHE_STATISTICS and related views. #V$RESULT_CACHE_OBJECTS。TYPE列表示缓存中对象的类型。如果查询结果存储在临时表空间中，则TYPE显示两个对象：Result和Temp。可以使用V$Result_Subcache_STATISTICS和相关视图访问子缓存元数据。

Reserved Pool

The reserved pool is a memory area in the shared pool that Oracle Database can use to allocate large contiguous chunks of memory. #保留池是共享池中的一个内存区域，Oracle数据库可以使用它来分配大的连续chunks。

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. #数据库以chunks的形式从共享池中分配内存。chunks允许将大型对象（超过5KB）加载到缓存中，而不需要单个连续区域。通过这种方式，数据库减少了由于碎片而耗尽连续内存的可能性

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. #Java、PL/SQL或SQL游标很少会从大于5 KB的共享池中进行分配。为了使这些分配能够最有效地进行，数据库将少量共享池隔离为保留池

Large 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) #用于共享服务器和Oracle XA接口的UGA（用于事务与多个数据库交互的地方）
Message buffers used in parallel execution #并行执行中使用的消息缓冲区
Buffers for Recovery Manager (RMAN) I/O slaves #RMAN I/O slaves的缓冲区
Buffers for deferred inserts (inserts with the MEMOPTIMIZE_WRITE hint) #延迟插入的缓冲区（带有MEMOPTIMIZE_WRITE提示的插入）

The following figure depicts the large pool. #下图展示了大池结构

Large Pool Memory Management

#大池内存管理

The large pool manages memory differently from the shared pool, which uses an LRU list so that portions of memory can age out. #大池管理内存的方式与共享池不同，共享池使用LRU列表，因此部分内存可能会老化

The large pool does not have an LRU list. When the database allocates large pool memory to a database session, this memory is not eligible to be released unless the session releases it. As soon as a portion of memory is freed, other processes can use it. By allocating session memory from the large pool, the database avoids the fragmentation that can occur in the shared pool. #大型池没有LRU列表。当数据库将大池内存分配给数据库会话时，除非会话释放内存，否则无法释放此内存。一旦释放了一部分内存，其他进程就可以使用它。通过从大池中分配会话内存，数据库可以避免共享池中可能出现的碎片

Large Pool Buffers for Deferred Inserts

For a special type of insert known as a deferred insert, the database allocates buffers from the large pool. #对于特殊类型的延迟插入，数据库会从大池中分配缓冲区。

For rapid “fire and forget” inserts from Internet of Things (IoT) applications, the database infrastructure creates performance overhead. For example, the code path includes buffer cache navigation, buffer pins, and concurrency protections. Array inserts minimize these costs, but the array must be built on the client side, which is not typical for Internet of Things applications. To address this issue, an Oracle application can use a hint to insert rows into a table specified as MEMOPTIMIZE FOR WRITE. #对于来自物联网（IoT）应用程序的快速“即用即忘”插入，数据库基础设施会产生性能开销。例如，代码路径包括缓冲区缓存导航、缓冲区引脚和并发保护。阵列插入将这些成本降至最低，但阵列必须在客户端构建，这对于物联网应用程序来说并不常见。为了解决这个问题，Oracle应用程序可以使用提示将行插入到指定为MEMOPTIMIZE FOR WRITE的表中

The inserts are deferred because they are buffered in the large pool, and then later written to disk asynchronously by background processes. The database processes deferred inserts as follows: #插入被推迟，因为它们被缓冲在大池中，然后由后台进程异步写入磁盘。数据库按如下方式处理延迟插入

The application sends MEMOPTIMIZE_WRITE inserts to a middle tier, which can aggregate the data. While an IoT application will almost always send inserts to the middle tier, it is also possible to send inserts directly to the database. For example, using SQL*Plus sends the inserts directly to the database. #应用程序向中间层发送MEMOPTIMIZE_WRITE插入，中间层可以聚合数据。虽然物联网应用程序几乎总是向中间层发送插入，但也可以直接向数据库发送插入。例如，使用SQL*Plus将插入直接发送到数据库
The middle tier writes the aggregation of inserts to the database server. #中间层将插入的聚合写入数据库服务器。
Optionally, the middle tier client retains a local copy of the data that it wrote in the previous step. #可选地，中间层客户端保留其在前一步骤中写入的数据的本地副本。
A server process writes data to a buffer or buffers in the large pool. #服务器进程将数据写入大池中的一个或多个缓冲区。

To avoid contention, each buffer has its own internal locking mechanism. This locking mechanism is separate from the locking mechanism that the database buffer cache uses for its buffers. The basic write process is as follows: #为了避免争用，每个缓冲区都有自己的内部锁定机制。这种锁定机制与数据库缓冲区缓存用于其缓冲区的锁定机制是分开的。基本的写入过程如下：
1. After instance startup, the first MEMOPTIMIZE_WRITE insert allocates the buffers from the large pool. #实例启动后，第一个MEMOPTIMIZE_WRITE插入会从大池中分配缓冲区。
2. The writer chooses a buffer from the list of available buffers #编写器从可用缓冲区列表中选择一个缓冲区。
3. If the chosen buffer is not locked, and if this buffer has free space, then the client writes to the buffer, stamping each buffer write with a session-specific sequence number. If not, then the writer returns to the preceding step, and continues in this way until either a buffer is found or sufficient space has been freed in the large pool. #如果所选的缓冲区没有锁定，并且该缓冲区有可用空间，则客户端向缓冲区写入，并在每个缓冲区写入时标记一个特定于会话的序列号。如果没有，那么编写器返回到前面的步骤，并以这种方式继续，直到找到缓冲区或在大池中释放了足够的空间。
The database creates a server-side array from the buffered data. #数据库根据缓冲的数据创建服务器端数组。
The Space Management Coordinator (SMCO) and its helper processes (Wnnn) write the array to disk asynchronously using the standard data block format. #空间管理协调器（SMCO）及其辅助进程（Wnnn）使用标准数据块格式将阵列异步写入磁盘。

Unlike standard inserts, deferred inserts are automatically committed and cannot be rolled back. The database commits the inserts to a given object in the order in which they appear within a session. There is no guarantee of ordering between objects or sessions. #与标准插入不同，延迟插入是自动提交的，不能回滚。数据库按照插入在会话中出现的顺序将插入提交给给定的对象。无法保证在对象或会话之间进行排序。

The database supports constraints and index maintenance just as for regular inserts. However, the database performs evaluations during the write to disk, not the write to the large pool. #数据库支持约束和索引维护，就像支持常规插入一样。但是，数据库在写入磁盘期间执行评估，而不是在写入大型池期间执行评估。

Note:For best performance, Oracle recommends disabling constraints. #注意：为了获得最佳性能，Oracle建议禁用约束。

The following figure depicts the workflow for deferred inserts. #下图显示了延迟插入的工作流程。

Java Pool

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. #Java池是存储Java虚拟机（JVM）中所有特定于会话的Java代码和数据的内存区域。这个内存包括在调用结束时迁移到Java会话空间的Java对象

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. #对于专用服务器连接，Java池包括每个Java类的共享部分，包括方法和只读内存（如代码向量），但不包括每个会话的每个会话Java状态。对于共享服务器，池包括每个类的共享部分和用于每个会话状态的一些UGA。每个UGA都会根据需要进行增长和收缩，但UGA的总大小必须适合Java池空间

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. #Java Pool Advisor统计信息提供有关用于Java的库缓存的信息，并预测Java池大小的变化如何影响解析率。当statistics_level设置为TYPERAL或更高时，Java Pool Advisor会在内部打开。当顾问关闭时，这些统计信息会重置

Fixed SGA

The fixed SGA is an internal housekeeping area.#固定SGA是一个内部管理区域

For example, the fixed SGA contains:#例如，固定SGA包含

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. #固定SGA的大小由Oracle数据库设置，不能手动更改。固定的SGA大小可以随版本的不同而变化。

Optional Performance-Related SGA Subareas

#可选性能相关SGA子区域

Some SGA subareas are only enabled for specific performance features. #某些SGA子区域仅针对特定性能功能启用。

This section contains the following topics: #本节包含以下主题：

In-Memory Area

The In-Memory Area is an optional SGA component that contains the In-Memory Column Store (IM column store). #内存中区域是一个可选的SGA组件，包含内存中列存储（IM列存储）。

The IM column store contains copies of tables, partitions, and materialized views in a columnar format optimized for rapid scans. The IM column store supplements the database buffer cache, which stores data in traditional row format. #IM列存储包含为快速扫描优化的列格式的表、分区和物化视图的副本。IM列存储补充了数据库缓冲区缓存，后者以传统的行格式存储数据。

Note:To enable an IM column store, you must have the Oracle Database In-Memory option. #注意：要启用IM列存储，必须具有Oracle Database In Memory选项。

Memoptimize Pool

The memoptimize pool stores buffers and related structures for heap-organized tables specified as MEMOPTIMIZE FOR READ. #内存优化池存储指定为 memoptimize for READ的堆组织表的缓冲区和相关结构。

This structure provides high performance and scalability for key-based queries such as SELECT * FROM cust WHERE cid = 10. To reduce end-to-end response time, clients pull requested buffers directly from the SGA over the network, avoiding CPU and operating system overhead. Applications can benefit from the memoptimize pool without requiring code changes. #这种结构为基于键的查询（如SELECT*FROM cust WHERE cid=10）提供了高性能和可扩展性。为了减少端到端响应时间，客户端通过网络直接从SGA提取请求的缓冲区，从而避免CPU和操作系统开销。应用程序可以从内存优化池中获益，而无需更改代码

The memoptimize pool contains two parts:

Memoptimize buffer area

To avoid disk I/O, the database permanently locks buffers for MEMOPTIMIZE FOR READ tables in the memoptimize pool, until the table is marked NO MEMOPTIMIZE FOR READ. The memoptimize buffers use the same structure as buffers in the database buffer cache. However, the buffers in the memoptimize pool are completely separate from the database buffer cache and do not count toward its size. The memoptimize buffer area occupies 75% of the memoptimize pool. #为了避免磁盘I/O，数据库将永久锁定内存优化池中MEMOPTIMIZE for READ表的缓冲区，直到该表标记为NO MEMOPTIMIZE for READ。内存优化缓冲区使用与数据库缓冲区缓存中的缓冲区相同的结构。但是，内存优化池中的缓冲区与数据库缓冲区缓存完全分离，并且不计入其大小。内存优化缓冲区占内存优化池的75%。
Hash index

A hash index is a non-persistent, segment data structure. The database allocates the hash index as multiple, noncontiguous memory units. Each unit contains a number of hash buckets. A separate map structure correlates a memory unit with a primary key. The hash index occupies 25% of the memoptimize pool. #哈希索引是一种非持久的分段数据结构。数据库将哈希索引分配为多个不连续的内存单元。每个单元包含多个散列桶。单独的映射结构将存储器单元与主键相关联。哈希索引占据了内存优化池的25%。

To enable the memoptimize pool, set the MEMOPTIMIZE_POOL_SIZE initialization parameter to an integer value (the pool is disabled by default). The value specifies the amount of SGA to allocate to the pool. The MEMOPTIMIZE_POOL_SIZE value does count toward SGA_TARGET, but the database does not grow and shrink the memoptimize pool automatically. For example, if SGA_TARGET is 10 GB, and if MEMOPTIMIZE_POOL_SIZE is 1 GB, then a total of 9 GB is available for SGA memory other than the memoptimize pool. #要启用内存优化池，请将memoptimize_pool_SIZE初始化参数设置为整数值（默认情况下禁用该池）。该值指定要分配给池的SGA数量。MEMOPTIMIZE_POOL_SIZE值确实计入SGA_TARGET，但数据库不会自动增长和收缩内存优化池。例如，如果SGA_TARGET为10 GB，并且MEMOPTIMIZE_POOL_SIZE为1 GB，则除内存优化池外，总共有9 GB可用于SGA内存

To change the size of the memoptimize pool, you must set MEMOPTIMIZE_POOL_SIZE manually and restart the database instance. You cannot change the pool size dynamically using ALTER SYSTEM. #要更改内存优化池的大小，必须手动设置memoptimize_pool_size，然后重新启动数据库实例。不能使用ALTER SYSTEM动态更改池大小。

The DBMS_MEMOPTIMIZE package enables you to explicitly populate a table into the memoptimize pool. #DBMS_MEMOPTIMIZE包使您能够将表显式填充到内存优化池中

2.7 Software Code Areas

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. #软件代码区是存储正在运行或可以运行的代码的存储器的一部分。Oracle数据库代码存储在一个软件区域，该区域通常比用户程序的位置更具排他性和保护性。

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. #软件区域是只读的，可以共享或非共享安装。一些数据库工具和实用程序，如Oracle Forms和SQL*Plus，可以共享安装，但有些则不能。在可能的情况下，数据库代码是共享的，这样所有用户都可以访问它，而无需在内存中有多个副本，从而减少了主内存并总体提高了性能。如果在同一台计算机上运行，一个数据库的多个实例可以将同一数据库代码区与不同的数据库一起使用

Note: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. #注意：并非所有操作系统都可以选择安装共享软件，例如在运行Microsoft Windows的电脑上。有关详细信息，请参阅特定于操作系统的文档

小小年纪净学坏

关注

8
点赞
踩
6

收藏

觉得还不错? 一键收藏
1
评论
2.Oracle体系结构-内存结构

目录目录2.1 文章概述2.2 内存结构概述Basic Memory Structures2.1 文章概述文章为记录学习oracle体系结构内存部分笔记。文章为根据官网同时根据实际经验翻译、理解生成广大网友有缘看到，具体内容还请自己甄别。文中黄色部分为官网原文供网友解读、绿色部分为个人记录或翻译,翻译也只是翻译主要内容。2.2 内存结构概述When an instance is started, Oracle Database allocates a memory
复制链接

扫一扫