RAC方式下有没有可能出现数据不同步的现象？

显示全部楼层 · 2005-2-28 12:57:00

现在有这样的环境：
APServer两台，IBM Websphere5.1 做成cluster的形式，
数据库两台做成RAC的形式。 APServer通过oci(rac)的方式连接
数据库。
出了这样的怪问题，前一个ejb transaction更新了一条数据，后面紧跟着的一个ejb读的数据不是最新的，再去读的时候就好了。
现在怀疑两个方面的问题。
1. RAC方式下面的数据库两个instance的同步没做好？
2. Websphere的transaction commit自己做了cache管理？
大家有没有遇到这样的问题呢？ RAC方式下面的数据库
有没有这样的设定？另外在已经建好的RAC数据库下面
修改每个instance的 memeory size是不是直接修改init.org
就可以了？

千问 · 2005-2-28 12:57:00

前面的 EJD 确信是已经提交了的话，这两个EJB是不是可能连接了不同的 instance ?

千问 · 2005-2-28 12:57:00

对，是可能连接了不同的instance。
但是即使这样，它们之间应该是保持数据同步的吧。
是不是有什么cache设置呢？

千问 · 2005-2-28 12:57:00

可能和这个参数有关
但还没有去证实过
max_commit_propagation_delay integer 700

千问 · 2005-2-28 12:57:00

看来就是这个问题了，星期一去公司试试，非常感谢。
从网上找到如下解释：

最大提交传播时延（MAX_COMMIT_PROPAGATION_DELAY，简称MCPD），在ORACLE RAC(或OPS)环境中才使用，表示在RAC系统中，一个instance系统提交产生的最新系统改变码（SCN），能够以多快的速度反应到另一个instance中。
举例说明，RAC系统，有A,B两个实例（instance），A、B本地系统改变码为SCN1，A更新数据DATA1提交， LGWR操作完成后，A本地系统改变码为SCN2，经过不大于MAX_COMMIT_PROPAGATION_DELAY时间后，B系统本地改变码才变为SCN2。
Global Cache Services 将刷新RAC中的SCN。不管SCN是否及时刷新，后续的数据查询都不会因此产生数据库错误。但，在此时间内，有可能查询结果不是最新数据，产生读一致性（read consistency）问题。
RAC环境中的所有实例，此参数值必须相同。
ORACLE8i后，建议常用的两个值是0和700（默认），其他数值皆不建议。其实，这两个数值就代表了RAC环境中，两种SCN 产生机制：
Lamport Scheme和 Broadcast on Commit scheme。
设置为默认值700，表示采用Lamport Scheme，SCN改变不会完全同步，同步将在 7秒钟内完成，而不是总等待7秒钟后才完成。如果系统比较空闲，同步可能在0.5秒（甚至更短时间）内完成；不管系统多繁忙，同步时间也不可能超过7秒。不难理解，采用此模式，整个RAC系统的运行效率较高。
设置为0，表示采用Broadcast on Commit scheme，SCN改变完全同步。每当commit时（即LGWR 写redo log时）：
－ LGWR发送消息更新全局SCN（global SCN），
－ LGWR 发送消息给每个活动的实例更新其本地SCN（local SCN）。
有资料说，只要MCPD < 700，系统将采用Broadcast on Commit scheme。
Lamport Scheme能够适应绝大部分应用的要求，只有个别实时性特别高的业务，才需要Broadcast on Commit scheme。通过分析，不难理解，Broadcast on Commit scheme将需要更多的系统资源