现在有这样的环境
一台web Server一个是纯JAVA APP 程序
数据库两台做成RAC的形式 web Server与APP 程序都通过oci(rac)的方式连接
数据库
出了这样的怪问题webServer更新或是插图入一条数据后面紧跟着的在APP中就查询不到等到用工具查询就没有问题
初步怀疑
RAC方式下面的数据库两个instance的同步没做好？
查询相关资料发现在与MAX_COMMIT_PROPAGATION_DELAY有关
最大提交传播时延（MAX_COMMIT_PROPAGATION_DELAY简称MCPD）在ORACLE RAC(或OPS)环境中才使用表示在RAC系统中一个instance系统提交产生的最新系统改变码（SCN）能够以多快的速度反应到另一个instance中
举例说明RAC系统有AB两个实例（instance）AB本地系统改变码为SCNA更新数据DATA提交 LGWR操作完成后A本地系统改变码为SCN经过不大于MAX_COMMIT_PROPAGATION_DELAY时间后B系统本地改变码才变为SCN
Global Cache Services 将刷新RAC中的SCN不管SCN是否及时刷新后续的数据查询都不会因此产生数据库错误但在此时间内有可能查询结果不是最新数据产生读一致性（read consistency）问题
RAC环境中的所有实例此参数值必须相同
ORACLEi后建议常用的两个值是和（默认）其他数值皆不建议其实这两个数值就代表了RAC环境中两种SCN 产生机制
Lamport Scheme和 Broadcast on Commit scheme
设置为默认值表示采用Lamport SchemeSCN改变不会完全同步同步将在 秒钟内完成而不是总等待秒钟后才完成如果系统比较空闲同步可能在秒（甚至更短时间）内完成不管系统多繁忙同步时间也不可能超过秒不难理解采用此模式整个RAC系统的运行效率较高
设置为表示采用Broadcast on Commit schemeSCN改变完全同步每当commit时（即LGWR 写redo log时）
－ LGWR发送消息更新全局SCN（global SCN）
－ LGWR 发送消息给每个活动的实例更新其本地SCN（local SCN）
有资料说只要MCPD < 系统将采用Broadcast on Commit scheme
Lamport Scheme能够适应绝大部分应用的要求只有个别实时性特别高的业务才需要Broadcast on Commit scheme通过分析不难理解Broadcast on Commit scheme将需要更多的系统资源
