欢迎进入oracle社区论坛，与200万技术人员互动交流 >>进入
现在有这样的环境：
一台web server,一个是纯java app 程序
数据库两台做成rac的形式。 web server与app 程序都通过oci(rac)的方式连接
数据库。
出了这样的怪问题，webserver更新或是插图入一条数据，后面紧跟着的在app中就查询不到，等到用工具查询就没有问题.
初步怀疑
1. rac方式下面的数据库两个instance的同步没做好？
查询相关资料发现在与max_commit_propagation_delay有关.
最大提交传播时延（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 lamport scheme能够适应绝大部分应用的要求，只有个别实时性特别高的业务，才需要broadcast on commit scheme。通过分析，不难理解，broadcast on commit scheme将需要更多的系统资源