PickedLamportschemetogenerateSCNs

故障现象： 数据库节点1由于卡死重启后，数据库实例无法open,警告日志没有错误只有一条记录：Picked Lamport scheme to generate SCNs，节点2正常，应用可以正常使用。 分析处理： 1 检查数据库系统的警告日志包括节点1：alert_szm21.log，节点2：alert_szm2

故障现象：

数据库节点1由于卡死重启后，数据库实例无法open,警告日志没有错误只有一条记录：Picked Lamport scheme to generate SCNs，节点2正常，应用可以正常使用。

分析处理：

1 检查数据库系统的警告日志包括节点1：alert_szm21.log，节点2：alert_szm22.log，没有报错现象。

2 节点1数据库实例： oradubug dump systemstate 10 oradebug analyze 3，ass109.awk分析没有等待和死锁现象。

3 metlink上对Picked Lamport scheme to generate SCNs的理解分析发现

Lamport 10.1 前：

Commit Broadcas 10.2后：

系统有如下问题的时候应该scn 推荐Commit：（文档 ID 259454.1

However, if any of the following conditions exist, there may be a need to

deviate from the default and explicitly set max_commit_propagation_delay=0.

- The data consistency between the different instances must be guaranteed and

immediate i.e. if commits must be seen instantaneously on remote instances.

- When rapid inserts (or updates) and immediate queries of the same dataset are

done from different instances.

- If middle-tier connection pools are being used in tandem with connection load

balancing to the RAC instances, and the application is arbitrarily selecting a

connection (and hence an instance) for each SQL operation.

- Some packaged applications (e.g. SAP) might recommend setting this parameter

to a specific value (mostly 0), in which case you should follow the

application vendor’s recommendations.

SCN算法上10.1前的版本与10.2的版本有明显不同，老版本算法存在不足的地方，

通过以上三条分析：决定对节点1进行重新启动，或许重现问题或许解决问题：重新启动节点1后，实例可以正常启动。

总结：对与该类问题，通过各种手段没有发现错误信息，而且存在版本差异，重启一般可以解决问题，

有其他思路请留言！！