Oracle RAC Cache Fusion 系列十三：PCM资源访问

前面的章节我们介绍了Oracle为实现Cache Fusion引入的各种改变和新的概念。本节我们从RAC环境中可能发生的场景对Oracle Cache Fusion的实现进行更近一步的探讨。

| 从磁盘中读一个块
实例C希望读取块，这时需要通过主实例D（块的master）获得共享模式锁。 1.实例C的FG（Foreground Process）进程通过向实例D的LMS进程发送数据块（需要共享锁）请求来获得块的访问权限。 2.实例D发现块从未被读取到集群中的任何实例的缓冲区缓存中，并且也未被锁定。实例D的LMS进程将PR（x$kjbl的kjblgrant列显示KJUSERPR。）锁授予实例C，授予的锁为sl0（Shared-Local-noPI）。 3.实例C将块从共享磁盘读取到它的缓冲区缓存中（buffer cache），假设这个时候块的SCN为1000。 4.实例C在共享模式下有块，最后锁管理器更新资源目录（GRD）。 注：这时如果用10046跟踪会话那么你会发现等待事件如下： WAIT #19446741324875049632: nam='gc cr grant 2-way' ela= 49 p1=7 p2=6867 p3=1 obj#=3214    tim=4597940025

WAIT #19446741324875049632: nam='db file sequential read' ela= 56 file#=7 block#=6867 blocks=1 obj#=3214 tim=4597941129

| 从内存中读一个块 继续第一个场景，实例B希望读取缓存在实例C缓冲区中的数据块块。 1.实例B的FG进程向主实例D的LMS进程发送数据块请求 2.实例D的LMS进程知道该块在实例C上以共享模式持有，实例D的LMS进程紧接着向实例C的LMS进程转发这个请求。（ gc cr grant 3-way ） 3. 实例C的LMS进程通过私网将块发送到实例B的FG，同时实例C通知实例B采用与实例C一样的锁定模式和角色，而实例C保留块的副本（CR Block）。

4.实例B向实例D发送一条消息，表明它现在持有了该块的SL锁。因为这条消息对于锁管理器来说不是必要信息，所以这条消息可以异步发送。

| 获取缓存块进行更新 继续上面的场景，实例A想要修改已经缓存在实例B和C中的同一块。 1.实例A向块的master实例D发送独占锁请求。 2.实例D知道块在实例B内存中以scur模式持有和在实例C中以cr模式持有。这时lock master实例D向共享锁持有者实力B发送ping消息。 3.实例B通过私网将块发送给实例A，并且释放它持有的共享锁。块仍在实例B的缓冲区中以CR形式存在，只是所持有的锁都被释放了。 4.实例A现在在该块上持有独占锁，并向实例D发送一条消息，表明它现在持有了该块的XL0（exclusive-LOCAL-noPI）锁。

5.实例A修改缓冲区缓存中的块，但是未提交更改，因此块未写入磁盘，因此SCN保持在1000。

| 获取缓存中已经被修改的块以进行更新和提交 继续上面的场景，实例C现在想要修改相同块的不同行。 1.实例C向lock master实例D发送独占锁请求。 2. 实例D知道实例A持有请求块的独占锁，因此向实例D向实例A发送ping消息。 3.实例A通过私网将脏块发送到实例C，并且实例A将锁从xcr降级为空。但是它会保留块的PI版本。在发送块之前，实例A必须创建一个PI镜像并刷入块更改的任何操作条目到redo日志中，实例A上的块模式现在是NG1（null-GLobal-1PI）

4.实例C向实例D发送一条消息，表明它持有的块处于独占模式。如果需要将块写入磁盘，它必须与具有该块的过去镜像（PI）的其他实例进行协调。实例C修改块并发出提交，SCN现在是1001。

| 提交修改块的操作 继续上面的场景操作，实例A现在发出commit，以释放它持有的行级锁，并将重做日志信息刷入到redo log。 1.实例A想要提交更改，这时提交操作不需要对块进行任何同步的操作（只需日志持久化即可）。 2.块的锁定状态与以前的状态没有变化，提交的更改向量将写入redo log。
| 由于增量检查点的发生，需将脏缓冲区写入磁盘 继续上面的场景，实例B由于增量检查点的更新需要从缓冲区缓存中将脏块写入。 1.实例B向块的master实例D发送写块请求。 2.实例D知道实例C上有块的最新副本，因此实例D会向实例C发送一条消息，请求刷脏块。 3.实例C启动磁盘写入并将对应的BWR写入redolog文件中。 4.LGWR通知实例C日志写入操作完成。 5.实例C通知master实例D，脏块的写入操作已完成。 6.在收到通知后，实例D通知所有PI持有者它们所持有的PI块。

7.以前修改过此块的所有实例同样也需写BWR。实例C的写请求已经全部完成，实例B最后向磁盘中写入其增量检查点。

| 主实例崩溃 继续上面的场景 1.主实例D崩溃 2.全局资源目录GRD冻结，主实例D所持有的资源将平均分布在幸存的节点中，也称为remaster。
| 从实例A中查询一行数据 从上面的示例继续，现在实例A查询该表中的行以获取最新的数据。 1.实例A向新的主实例C发送请求共享锁操作。 2.根据GRD信息实例C知道块的最新副本在实例C中，并要求持有实例C将CR块发送给实例A。 3.实例C通过私网将CR块发送给实例A。 可能上面的实例读起来有点绕，我们通过下面的表格可以更加容易的阅读每个场景。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28218939/viewspace-2654391/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28218939/viewspace-2654391/