Cache Fusion (1)

鄂昌胤

2023-12-01

这两天学习了RAC的Cache Fusion，整理一下，年前最后的笔记。

RAC环境下，每个实例都有其本地buffer cache，与单实例DB中一样完成其工作。但是会存在实例A需要某个数据块而这个数据块正在被实例B操作，这种情况下，需要通过互联(Interconnect)机制访问，就是Cache Fusion。

Cache Fusion通过共享缓存(Cache)解决并发问题。在Cache Fusion算法中，当一个实例请求修改数据块时候，当前正在修改该数据块的实例不需要写入磁盘，减少了磁盘写操作I/O开销。Cache Fusion的并发控制极大的改善了数据库性能，减少了RAC环境中的更多的管理。

先来介绍几个定义吧：

GCS (Global Cache Service) 全局缓存服务：是在多个缓存中维持缓存一致性(cache coherency)的主要机制，它是Cache Fusion的核心概念，当一个实例需要访问某一数据块时候，会向GCS发起请求。后台进程LMS

Tracking：跟踪数据块；跟踪队列机制中的所有状态

Accepting：接受数据块请求；

Informing：通知持有资源的实例释放数据块上的锁或者发送CR image；通知实例持有或者情况PI

Coordinating：通过interconnect 协调数据块在不同实例之间转发

GES (Global Enqueue Service) 全局队列服务，通过管理字典缓存锁，Library Cache锁和事务来实现被多个实例使用的资源的并发，包括：

事务锁(Transaction locks) – 排它模式，事务提交或者回滚后才会释放。

Library Cache locks - 解析和编译SQL,DML, DDL,PL/SQL, Java语句时引用数据库对象(表，视图，过程，函数，包，包体，触发器，索引，簇，同义词) 需要该锁。

字典缓存锁(Dictionary Cache Locks) - RAC中，oracle会在整个集群中同步所有的字典缓存，使用的是latches。

表级锁(Table locks) – null (N), row share (RS), row exclusive (RX), share lock (S), share row exclusive (SRX), or exclusive (X).

GRD (Global Resource Dictionary) 全局资源目录，由GCS和GES共同维护(可以看做一个内存数据库)，保存当前缓存中的块信息(数据块地址，最新版本所在实例，Mode，Role，SCN，PI)。

GRD记录了最新的数据库所在位置，块模式(Mode)和角色(Role)，cache fusion 中所有资源请求和转发都保存在GRD中。GRD是分布式资源，存储在SGA中，每个实例中都包含一部分GRD资源。

模式(Mode)和角色(Role)信息有GCS在GRD中维护。

GRD资源的Mode有三种：Null (N) Mode，Shared (S) Mode，Exclusive (X) Mode

Null (N) Mode

Shared (S) Mode：共享模式表明当前实例会话对数据块读而没有修改

Exclusive (X) Mode：独占模式表明不可以被其他实例修改，当前实例会话独占该数据块，该数据库可以被一致读。

GRD资源的Role有三种：Local，Global

Local：数据库首次被读入内存，只有一个该数据块的镜像。

Global：脏缓冲在持有资源的实例(holding instance)上(PI)，发送到新请求的实例(requesting instance)中，这时候需要Global角色。

综上，可以用SL0表示Shared mode, Local role, 0 PI

PI (Past Image) 陈像，是数据块写入磁盘之前的保存在buffer cache中的数据块镜像，出现在写-写并发中。

实例A读取数据块D1入A的buffer cache，实例B也想读取数据块D1，cache fusion 中，实例A将把D1传送到B，此时，在A的buffer cache中的D1就成为一个“陈像”。之所以称之为“陈像”，是因为当前最后请求访问的是实例B，B可能对D1做修改，而一旦修改了，在A中的D1的PI就不再是最新版本，也就是一个“陈像”(脏缓冲块)了。

Cache fusion优势在于多实例并发访问同一数据块时候，不需要等待当前实例完成磁盘写入就可以把该数据块连带被该实例修改但尚未写入磁盘的内容一并直接从buffer cache中copy到另一个实例，这样多个实例并发就会在多个实例上存在不同版本的PI了。

这些不同版本的PI可以在某个实例宕掉的时候做恢复使用。

当数据块修改被写入磁盘时候，所有实例上的所有PI就会被清理掉，redo log里与该PI相关的log也可以被覆盖掉了。

CR Image 一致读镜像，出现在读-写并发中。

PI是保存在持有资源的实例(holding instance)的buffer cache里的，而CR image需要发送到新请求的实例(requesting instance)中。

先来了解一下一致性读(Consistent Read)

事务T1正在修改D1，事务T2想要读取D1；如果T1还没有commit，T2就需要一个CR块。CR块是根据SCN从undo segment/buffer中读取的脏数据块。

在RAC中，由于需要访问不同实例上的undo segment，创建CR image会产生额外的I/O开销。

整理这些就用了一下午，看了好多文档，blog，依靠强大的网络学到了知识，所以也希望多少贡献一点点，希望能有用。

其实，看的越多，发现懂得越少了。。

明天不忙的话把Cache fusion的使用场景列一下。

发现了一本好书，打个广告吧，O(∩_∩)O~，五百多，怎么说也有点贵呀。