故障现象： 数据库节点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后，实例可以正常启动。
总结：对与该类问题，通过各种手段没有发现错误信息，而且存在版本差异，重启一般可以解决问题，
有其他思路请留言！！
