SCN的Broadcast-On-Commit和Lamport算法

这几天我有一个客户的数据库出现了这样的情况，在一个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.

以上源自老白的blog

Setting MAX_COMMIT_PROPAGATION_DELAY to zero or to any value below 100 will have the same effect, that is to use the broadcast on commit System Change Number (SCN) generation scheme. By default, the system uses a scheme called the Lamport scheme and a MAX_COMMIT_PROPAGATION_DELAY value of 700 hundredths of a second, or seven seconds. You can see this in the alert.log file ("Picked xxx scheme to generate SCNs"). The only exception is Tru-64: on that platform, setting MAX_COMMIT_PROPAGATION_DELAY to zero is not recommended because it causes excessive system CPU consumption. Unfortunately, zero is the default on Tru-64, so this value must be changed for this platform. Setting the parameter to anything between 1 and 99 will have the desired broadcast on commit behavior, although it will not be reported as such in the alert.log file (instead it will say "Picked Lamport Server scheme to generate SCNs"). The bottom line is that if you want to set this parameter to a value that guarantees broadcast on commit for all platforms, select a value between 1 and 99. The fact that the parameter is a number in hundredths of a second is misleading, as anything between 1 and 99 works exactly the same way.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16158219/viewspace-580632/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16158219/viewspace-580632/