SGA--Database Buffer Cache

Overview of the System Global Area

    The SGA is a read/write memory area that, along with the Oracle background processes, make up 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.

    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. 

    SGA是read/write memory area，它与Oracle后台进程组成数据库实例。用户执行的server processes都能够读取实例SGA中的信息。一些进程还可以向SGA中写内容。每个数据库实例都有自己的SGA，Oracle会在实例启停时自动分配和释放SGA占用的内存。

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组件，除了redo log buffer，都是以粒组为分配和释放单位的。粒组大小与平台相关。

The most important SGA components are the following:

Database Buffer Cache

Redo Log Buffer

Shared Pool

Large Pool

Java Pool

Streams Pool

Fixed SGA

上面介绍了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.

database buffer cache小名buffer cache，它存储从数据文件中读取到的数据块的copies。Buffer是内存中的一个地址，buffer manager会临时的把currently or recently used数据块cache到那里（注意buffer与cache的区别）。同时连接到数据库实例的所有用户都能够访问buffer cache。

Oracle Database uses the buffer cache to achieve the following goals:

--使用buffer cache有两个目的：

Optimize physical I/O

--优化物理 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 disk but does not immediately write data blocks to disk. Instead, database writer (DBWn) performs lazy writes in the background.

数据库在cache中更新数据块，并且在redo log buffer中存储改动的元数据。在COMMIT后，数据库把redo buffer写到disk，但是不立即把数据库写到disk。相反，这个工作由DBWn进行再后台执行lazy写。

Keep frequently accessed blocks in the buffer cache and write infrequently accessed blocks to disk

--把经常访问的块保留在buffer cache中，把不经常访问的块写到磁盘上。

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 a flash disk device, which is a solid state storage device that uses flash memory. The database can improve performance by caching buffers in flash memory instead of reading from magnetic disk.

要是Smart Flash Cache开启的话，buffer cache的一部分就会存在于flash cache中。这个buffer cache extension存储在一个闪盘设备上，它是一个固态存储设备，使用闪存。数据库可以通过把buffers cache到闪存而不是从磁盘读取来提高性能。

Buffer States

buffer有三种状态，并且互相排斥。数据库使用内部的算法来管理cache中的buffers（buffers in the cache）。

Unused

这种类型的buffer对于数据库来说是最容易使用的。The buffer is available for use because it has never been used or is currently used.

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.

这种buffer之前使用过，现在包含某一时点的read-consistent version的块（就是说，它是一致性的块）。这个块含有数据，但它是clean的（也就是read-consistent），所以不需要对它进行checkpoint。数据库能够pin the block and reuse it。

Dirty

The buffer contain modified data that has not yet been written to disk. The database must checkpoint the block before reusing it.

这种buffer包含被修改的数据，并且这个数据没有被写到磁盘。此时，在重用它之前，就必须进行checkpoint the block。

--以上的三种状态如果没太明白，可以多读几遍。

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.

The database uses a sophisticated algorithm to make buffer access efficient. Pointers to dirty and nondirty buffers exist on the same least recently used (LRU) list, which has a hot end and cold end. A cold buffer is one that has not been recently used. A hot buffer is frequently accessed and has been recently used.

每一个buffer都有种access mode：pinned（钉住）or free（未钉住）。Pinned到cache中的buffer不会age out of memory。多个会话不能同时修改a pinned buffer。

数据库使用一种复杂的算法来使buffer的访问高效。指向dirty和nondirty buffers的指针存在于LRU列表上，LRU有热端和冷端。冷端buffer就是最近没被使用。热端buffer就是经常使用，最近也使用。

Buffer Modes

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.

--发现这术语就不能翻译，别扭

Current mode get也叫db block get。块在buffer cache中啥样，就获取到啥样的。比如，一个没提交的事务更新了一个块的两行内容，那么current mode get就会获取被更改但是尚未提交的块的行。Db block get会经常在modification语句过程中使用，因为它们需要更新当前的版本的块。（什么意思呢？就是说比方你执行update操作修改了scott的emp表，但是你还没提交，然后你要看看你update是否正确，然后执行select，这个select查出的内容就是你更改的但是没有提交的内容，也就是block的current version。）

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.

要注意理解consistent mode与current mode区别。Consistent read get是获取block的read-consistent version，而非current version。此时就要用到undo data。比方说一个没提交的事务更新了一个块的两行，然后一个独立的会话要查询这个被更新的块，这是数据库就会使用undo data来创建一个read-consistent（读一致性）的块，也叫consistent read clone，这种块就不包含未提交的被更改的数据。查询一般都要获取读一致性的块。

Buffer I/O

Logical I/O也叫buffer I/O，指的是从buffer cache中读写buffers。当在内存中没有找到请求的buffer时，数据库就要执行物理I/O，把buffer从flash cache or disk中copy到内存，然后逻辑I/O再去读这个被cached buffer.

Buffer Writes

The database writer (DBWn) process 这个进程会定期的把冷的，脏的buffer写到磁盘。DBWn在下面的情况会写buffers。

服务进程找不到干净的buffers来把新的块读到数据库的buffer cache中。随着buffers变脏，free buffers的数量就开始减少。如果数量低于内部的一个阀值，并且有会话在请求clean buffers，那么服务进程就会给DBWn发写的信号。

数据库使用LRU来决定到底写哪些dirty buffers。当dirty buffers到达LRU的冷端时，数据库就会把它们从LRU移动到write queue（写队列），DBWn会把队列上的buffers写到磁盘。这种机制阻止了LRU末端被dirty buffers阻塞，并且能够发现干净的buffers，然后重用它们。

The database must advance the checkpoint, which is the position in the redo thread from which instance recovery must begin.

--这句话不好翻译。意思是说，数据库必须先执行一个检查点，这是redo线程中的一个位置，这个位置是实例恢复时候的起始点。这里面主要是涉及到进程协作等内容，所以如果不理解，可以暂时略过，以后会明白的。

Tablespaces are changed to read-only status or taken offline.

这是最后一种情况，当表空间改变成只读状态或者离线的时候，也要进行buffer write。

Buffer Reads

当clean or unused buffers数量低的时候，数据库就会从buffer cache中移出buffers。这个事情要靠算法解决，而算法要分两种，flash cache是否开启。

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

DBWn 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.

这个方法就是多了个flash cache在memory与disk之间。DBWn把clean buffer的body写到flash cache中，然后把buffer的header留在LRU列表中，用header记录buffer的状态和buffer body在flash cache中的位置。如果buffer后来要被使用的话，那么数据库就从flash cache中读出来，而不是再从磁盘上读。这样效率高嘛。

当客户进程请求一个buffer，服务进程就会到buffer cache中去找对应的buffer。如果找到了，就叫做cache hit。服务进程会遵循下面的顺序去查找。

1.The server process searches for the whole buffer in the buffer cache。注意这里的单词whole buffer，它的意思其实是指whole buffer=buffer header + buffer body。If the process finds the whole buffer, then the database performs a logical read of this buffer.也就是说，如果服务进程在buffer cache中直接找到了whole buffer（包括header和body），那么就是进行的逻辑读。

2.服务进程从flash cache的LRU列表查找buffer header。如果它查找buffer header，那么数据库就会执行optimized physical read，把buffer body从flash cache中读到内存中。

3.如果服务进程在内存中没找到对应的buffer，这叫做cache miss，那么它就会执行下列步骤：

A.把块从数据文件中复制到内存（physical read）

B.对这个读入到内存的块执行logical read

下图描述了查找顺序。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.

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.

有一点需要说明，数据库能够从data file 或者 temp file进行物理读。但是，当从数据文件物理读后，会紧跟着逻辑读。而从temp file则不然。因为当内存不足时，数据库会强制把数据写到一个临时表中，然后再读回来。这样物理读就会略过buffer cache这一部分，从而不发生逻辑I/O。

Buffer Touch Counts

数据库通过touch counts来计算访问LRU列表的buffer的频率。当buffer被pinned，而不是被从LRU列表shuffle掉的时候，数据库就会增加一个计数。注意，数据库并不是真的在内存中去移动block，而是列表上指针指向的位置。

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.

--当buffer被pinned时，数据库还要测算它的touch count上一次增加时什么时候，如果超过三秒，就加一，反之则保持原状。

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.

--这里就说明了touch count是如何来决定buffer被移动到哪一端的（hot or cold or age out of the cache）。

Buffers and Full Table Scans

当数据库必须从disk读取buffers时候，数据库就会把读取来的buffers插入到LRU列表的中间，这样热块还能留在cache中，不会在需要它们的时候再重新从disk读取了。

全表扫描会带来问题，当你把高水位线下的所有行都顺序读到buffer cache中，如果表段中的块比buffer cache大，它们就会把经常访问的块清空，取而代之。

但是别担心，全表扫描或者是从一个大表中读取到buffer cache中的块会采用不同于其他方式读取的块的对待方法。The blocks are immediately available for reuse to prevent the scan from effectively cleaning out the buffer cache.

In the rare case where the default behavior is not desired, you can change the CACHE attribute of the table. In this case, the database does not force or pin the blocks in the buffer cache, but ages them out of the cache in the same way as any other 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属性就行了。

Buffer Pools

Buffer pool就是buffers的集合。数据库的buffer cache被分成了一个或多个buffer pool。可以手动配置这些分开的池子，使其在buffer cache中保存数据，或者在用过之后能够立刻给新的数据块使用。（or make the buffers available for new data immediately after using the data blocks。还可以把特定的schema对象分配到恰当测池子，以便控制块如何age out of cache。

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.

--这个是默认的池子，一般都会cache到这里。如果没手动配置其他池子，这个就是唯一的buffer pool

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 goal of the keep buffer pool is to retain objects in memory, thus avoiding I/O operations.

--这个池子就用来cache那些经常访问，但是会由于内存不足而被置换出的blocks，目的是避免不必要的I/O操作。

Recycle pool

This pool is intended for blocks that are used infrequently. A recycle pool prevent objects from consuming unnecessary space in the cache.

--用来cache那些不经常用的blocks，阻止消耗不必要的内存空间。

数据库有一个标准大小的块尺寸，当你创建了非标准大小的，它们就会拥有自己的池子，管理方法与default pool一样。

The below 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.