Oracle体系结构之Database Buffer Cache

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,又称the buffer cache，是用来保存从数据文件中读取的数据块的一片内存区域，保存正在或者最近被使用的data block。sga的一部分

Oracle Database uses the buffer cache to achieve the following goals:
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 disk but does not immediately write data blocks to disk. Instead, database writer (DBW) performs lazy writes in the background.
DML时，database 在 db buffer cache中更改数据并把数据改变写入到redo log buffer中(应该是先写log)，接收到commit指令后，database把redo log buffer里的信息写到disk上(redo log file),但是数据的修改并不是立刻刷新到disk上的，DBW在后台进行lazy writes(也有可能数据已经有部分写入到磁盘上了)，让commit与data的实际落盘相互独立，避免在commit时过分等待physical I/O(commit时写log这部分还是要physical I/O的，相关等待事件：log file sync、log file parallel write)

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 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.
(Note:  Database Smart Flash Cache is available only in Solaris and Oracle Enterprise Linux.)
我接触的环境好像都么有Flash Cache

Buffer States:
The database uses internal algorithms to manage buffers in the cache. 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.
■ Dirty
The buffer contain modified data that has not yet been written to disk. The database must checkpoint the block before reusing it.
buffer块的三种状态；Unused 未使用，Clean 之前用过 现在存着老版本的数据 可以直接被拿过来reuse，Dirty 里面存着还没被写入diks的数据 reuse之前必须checkpoint 一下

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.
(Note:  Conceptually, there is only one LRU, but for concurrency the database actually uses several LRUs.)
有个LRU链表 上面存着指向 dirty and nondirty buffers 的指针，list 有 hot end and cold end，hot部分存的是最近使用和经常访问的，cold部分存最近没有使用的，具体怎么划分的是通过算法控制

Buffer Modes
When a client requests data, Oracle Database retrieves buffers from the database buffer cache in either of the following 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.
■ 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中的数据，Oracle 提供两种模式：Current mode和Consistent mode，我理解是  同一个事务中的修改并读取是Current mode，不同事务间的是Consistent mode，Consistent mode是读取不到buffer中的正在修改的数据的，而是去undo里读

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. 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, and then a logical I/O to read the cached buffer.
logical I/O-----读内存(读 db buffer)，a physical I/O -----读flash cache or disk 

Buffer Writes 
The database writer (DBW) process periodically writes cold, dirty buffers to disk. DBWn 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 DBWn 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. DBWn 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.
■ 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.

DBWn写dirty buffers的条件：
1.free buffers不足了 2.checkpoint 3.表空间变成只读or offline

下面是从网上找到 总结的比较详细：
checkpoint会触发dbwr写脏块时是根据checkpoint queue来的，而LRU-W是负责dbwr的其他写出条件的触发。
DBWR作为一个后台进程，只有在某些条件满足了才会触发。这些条件包括：
1.当进程在辅助LRU链表和主LRU链表上扫描以查找可以覆盖的buffer header时，如果已经扫描的buffer header的数量到达一定的限度（由隐藏参数：_db_block_max_scan_pct决定）时，触发DBWR进程。_db_block_max_scan_pct表示已经扫描的buffer header的个数占整个LRU链表上buffer header总数的百分比。这时，搜索可用buffer header的进程挂起，在v$session_wait中表现为等待“free buffer wait”事件，同时增加v$sysstat中的“dirty buffers inspected”的值。
2.当DBWR在主LRUW链表上查找已经更新完而正在等待被写入数据文件的buffer header时，如果找到的buffer header的数量超过一定限度（由隐藏参数：_db_writer_scan_depth_pct决定）时，DBWR就不再继续往下扫描了，而转到辅助LRUW链表上将其上的脏数据块写入数据文件。_db_writer_scan_depth_pct表示已经扫描的脏数据块的个数占整个主LRUW链表上buffer header总数的百分比。
3.如果主LRUW链表和辅助LRUW链表上的脏数据块的总数超过一定限度，也将触发DBWR进程。该限度由隐藏参数：_db_large_dirty_queue决定。
4.发生增量检查点（incremental checkpoint）或完全检查点（complete checkpoint）时触发DBWR。
5.每隔三秒钟启动一次DBWR。
6.将表空间设置为离线（offline）状态时触发DBWR。
7.发出命令：alter tablespace … begin backup，从而将表空间设置为热备份状态时触发DBWR。
8.将表空间设置为只读状态时，触发DBWR。
(原文：https://blog.csdn.net/louisjh/article/details/80413274) 

Buffer Reads 
When the number of clean or 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
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.

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:
1. 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.
2.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.
3. If the process does not find the buffer in memory (a cache miss), then the server process performs the following steps:
a. Copies the block from a data file into memory (a physical read)
b. Performs a logical read of the buffer that was read into memory

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

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

Buffers and Full Table Scans
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.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.
从这可以看出 大表的全表扫表有多恐怖

Blocks read into the database cache as the result of a full scan of a large table are treated differently from other types of reads. 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.

Buffer Pools：
A buffer pool is a collection of buffers. The database buffer cache is divided into one or more buffer pools.
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.
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.
■ 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.
■ 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.