【求助・疑问】RAC环境下Node间的数据同步和共享

成贵在坚持

你好，
针对第一个问题：
3.3 发送的数据时，是带着修改内容发送的《发送的数据时，是带着修改内容发送的》是什莫意思？？？
回答：《发送的数据时，是带着修改内容发送的》这是说：Cache fusion的传送过程是跨事务边界的，也就是说不用等到实例3上面的事务完成，就可以发送这个PI数据块；

针对你的第二个问题：

2.实例2检查GRD，发现实例4拥有current version，向实例4发出通知；（如果实例4还没有ＣＯＭＭＩＴ的情况下，current version还是在实例3 ？？）
回答：事务commit只是会触发讲log buffer中的redo log写入磁盘中，此时实例4即使没有commit，但是讲数据块写入DISK的时候，同事在log中记录一条BWR，所以不用清空log buffer；

针对你的第三个问题：
我想简要介绍一点背景知识，我尽量简捷一些：
Oracle cluster发展历史分为两个阶段，最初是oracle 并行服务器(oracle parallel Server,OPS),第二阶段是从oracle 9i开始的oracle真正应用集群，就是我们说的RAC；
两个阶段中DLM（Distributed Lock Management）称呼是不一样的，OPS叫做PCM，RAC的叫做Cache fusion；
相应的：在DLM中把资源也分成了两类，在OPS时代叫做PCM Resource 和Non－PCM Resource ，在9i的RAC中还是沿用了这个叫法；在10g以后的RAC中就叫做Cache fusion 资源和
Non－Cache fusion 资源；
Cache fusion 资源包括：regular data block;index data block;segment header,undo block;
Non-Cache fusion 资源:data file;control file;data dictionary view;Library Cache;Row Cache等；
所以在RAC数据库中有4种lock：1.PCM LOCK  2.Non-PCM 3.Lock  4.Lock Latch;

而且非常重要的概念：GRD(Gloabl Resource Directory)
可以把GRD看作一个inner数据库，它记录这数据块在各node之间的分布情况，GRD位于每个节点的SGA中，但是每个实例SGA都是部分的GRD，所有节点的GRD合在一起才是真正完整的GRD；
RAC 会从各个节点中选择一个节点作为MASTER node，它来维护所有节点的GRD；
PCM的属性包涵：Mode;Role;PI
GRD的数据结构为：
DBA :Location: Mode: Role: scn: PI
说明如下：
DBA： data block address;
Mode:PCM的属性，有X,S,NULL三种值；
Role:有Local 和Global role；（具体用法和转换，我就不详细描述了，不过原理很重要），PCM的属性；
PI：PCM的属性，它代表中实例SGA中是否拥有和DISK内容不一致的版本，以及版本顺序，并不是代表每个节点是否修改过这个数据块，past Image能够加速Crash Recovery的恢复；
可以看到GRD包涵PCM的消息；

我们必须明白的是：Cache fusion是RAC的核心，它的服务由三架马车构成：GRD,GCS,GES
GCS：负责维护全局的SCN号；
GES：维护数据块的访问顺序，负责Lock的管理；

希望能够解答你的困惑。

powpeo

学习了

ccsnmoracle

针对你的第二个问题：

2.实例2检查GRD，发现实例4拥有current version，向实例4发出通知；（如果实例4还没有ＣＯＭＭＩＴ的情况下，current version还是在实例3 ？？）
回答：事务commit只是会触发讲log buffer中的redo log写入磁盘中，此时实例4即使没有commit，但是讲数据块写入DISK的时候，同事在log中记录一条BWR，所以不用清空log buffer；

在RAC环境下，所有的针对Block的操作，都要通过ResourceMaster的调度。。。

看这样的一个例子

1 NODE1进行UPDATE操作，将BlockA中的row1给修改了，但没有COMMIT。
2 NODE2进行SELECT操作，由于NODE1没有COMMIT操作，NODE2是看不到NODE1所做的更新。
3 NODE1进行COMMIT
4 NODE2再进行SELECT操作，NODE2就可以看到NODE1所做的修改了。

在RAC环境下NODE2是怎么样知道NODE1进行了COMMIT操作？
当进行commit操作时，一般情况下都是要进行快速提交。所以，Node1在做Commit时，一定要对Block进行写操作。
是否在commit时，NODE1会获得X锁，对block进行修改？？
对block修改完成之后，NODE2就可以看到NODE1所做的修改了？？？

ccsnmoracle

原帖由 wei-xh 于 2010-5-16 22:56 发表
NodeA做了一次update操作，NodeA是否立刻通过CacheFusion将更新后的数据，发送给NodeB，以保持数据同步？？？

---------------------------------------------------
解答这个问题前，首先你要知道几点。
RAC是运行在多台计算机上的，对于单机而言，一条记录能否被修改，只要没有其他进程并行修改就行。可是对于RAC而言，怎么才能感知这种并发存在呢，传统的方式已经不行了，因为传统的方式感受不到另一节点对此资源的使用情况。那么势必需要引入一个‘第三者’来当‘裁判’，这就是DLM，分布式锁管理器，他主要记录着数据块在节点间的使用分布情况。
你还需要知道什么是grd，它记录着数据块在集群间的分布情况，他位于SGA中，而且每个节点都只有部分数据块的GRD，所有节点合起来才是完整的GRD。
每个数据块都有他的master node，master node记录着此数据块在所有节点间的分布情况，对应着有shadow node他只记录数据块在此节点的分布。每次数据请求都会计算数据块的master node，通过查看master node的grd,来获知数据块在实例间的使用分布情况。
做完UPDATE操作后，NODE A并不会立刻传递数据块，除非有条件去触发，才会去传递。
假如此数据块的master node是节点A，你在节点A更新了此数据块，接着节点B的一个查询使用到了此数据块，master node会判断出NODE A拥有数据块的当前版本，会命令节点A传递数据块，并同时更新GRD中的信息。注意一个问题，在节点A传递这个数据块的时候，传递的一定是当前版本，也就是说不管UPDATE操作后，这个事务由没有提交，ORACLE都会传递这个当前版本的数据块，而不会去构造一个一致性读的块去传递。

当节点A传递这个数据块之后（这个块应该是CR！！？），节点A执行了COMMIT.
这之后的操作该如何进行？？

比如
快速提交由哪一个节点来做？？由节点B??

再者，节点A传递的内容里，应该有能够保证数据一致性的内容吧。？？？？
我的意思是说，节点A传递CR内容里，存在类似于UNDO的内容。

Yong Huang

wei-xh wrote:

> 假如此数据块的master node是节点A，你在节点A更新了此数据块，接着节点B的一个查询使用到了此数据块，...，
> 在节点A传递这个数据块的时候，传递的一定是当前版本，也就是说不管UPDATE操作后，这个事务由没有提交，
> ORACLE都会传递这个当前版本的数据块，而不会去构造一个一致性读的块去传递。

That's not correct. If you have access to K Gopalakrishnan's "Oracle Database 10g Real Application Clusters Handbook", refer to pp.257-258, example 8 "Select the Rows from Instance A". In your case, if B wants to *read* the block (节点B查询), A will construct a *CR* block and ship this CR block to B.

But of course if B needs to *update* the block, A will ship the current or dirty block as you said. See example 4 of the book (p.255)

成贵在坚持 wrote:

> 第五种情形：
> 1.实例1 想读数据块，向实例2发出请求；
> 2.实例2 检查GRD，发现实例4 持有current version，向实例4发出请求；
> 3.实例4 发送数据块，PCM 将为 shared mode ，global role

You didn't say clearly, but it sounds like instance 4 will ship the current instead of CR version of the block to instance 1. Then I don't agree. See the reference I quoted above, example 8 of the book.

Yong Huang

ccsnmoracle

Yong Huang Sir


我的看法是。。。

Commit操作主要的任务有两个，第一是将REDO BUFFER的内容写入REDO文件.
                                             第二是释放相应的锁资源。

在RAC环境下，GES负责管理锁资源。

NODE1在没有提交的情况下，将block传送给了NODE2.
之后，NODE1进行了Commit操作。NODE2的GES会释放NODE1所使用的锁资源比如说快速提交，
从而node1上的transaction也就正常完结了。

opsc

原帖由 Yong Huang 于 2010-5-25 03:43 发表
wei-xh wrote:


You didn't say clearly, but it sounds like instance 4 will ship the current instead of CR version of the block to instance 1. Then I don't agree. See the reference I quoted above, example 8 of the book.

Yong Huang

juliandyke "RACInternals.ppt", it explains this behavior clearly, first build the consistent block, then ship to another instance.

Also for the block mastering, here is a super good link by Riyaj Shamsudeen:
http://orainternals.wordpress.co ... ynamic-remastering/