Picked Lamport scheme to generate SCNs，lamportscns

Picked Lamport scheme to generate SCNs，lamportscns

故障現象：

 資料庫節點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後，執行個體可以正常啟動。

 

總結：對與該類問題，通過各種手段沒有發現錯誤資訊，而且存在版本差異，重啟一般可以解決問題，

             有其他思路請留言！！