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