这几天我有一个客户的数据库出现了这样的情况，在一个3节点的RAC上，其中一个节点上修改的数据，马上在另外一个节点上查，发现有千分之5左右的数据没有更新，要过一会才能查到正确的结果。这造成了应用软件的业务逻辑错误。

通过分析，发现是SCN的传播机制导致。由于Oracle 9i缺省的传播模式是lamport算法，SCN在实例间传递是通过GCS MESSAGE来传递的，因此就会造成一定的延时。LAMPORT算法可以减少实例间同步SCN所造成的性能问题，但是在变更十分频繁的系统中，可能出现上述的问题。因此在这种情况下，客户首先把这个应用全部部署在一个节点上，以避免业务逻辑的问题。如果无法通过应用调整来解决，那么就必须调整MAX_COMMIT_PROPAGATION_DELAY来改变传播算法了。一般来说这个参数在9i和10.1的缺省值是700（TRU64除外）也就是7秒钟，实际上这是一个上限了，因为lck每隔3秒钟会有一个例行的信息包交换，一般情况下，3秒钟肯定会完成一次scn传播。这个参数，如果设置为0-99，那么数据库会选择Broadcast-On-Commit算法，由LGWR来传播SCN。一般来说我们可以设置为0-99或者保留原有的值不懂，没有十分可靠的分析证据的情况下，建议不要设置100-700之间的值。

10.2开始，lgwr传播SCN的算法有了很大的改进，因此10.2缺省使用Broadcast-On-Commit，这个参数的缺省值也变为0.