buffer busy waits與rac cluster wait之間的聯絡

之前遇到的buffer busy waits的問題在所做的一些變動後，情況下降許多，但問題依然存在。[@more@]因為我們的環境中遇到的buffer busy waits為data block型別，識別碼為220，讓人直接想到的就是，高併發的DML是導致這個環境buffer busy waits的主因。(額外附註一下：當塊被讀到sga後，若有session想讀取或者修改它，必先獲取cache buffers chains鎖存器以遍歷該緩衝區鏈而找到所必需的緩衝區頭，然後，根據session所請求的類別來以共享模式或者獨佔模式來pin住該緩衝區頭，然後才可以進行讀取或者修改,pin住後然後釋放cache buffer chains鎖存器)。

至於出現的global null to x 和global cr request之類的cluster wait，跟我們的應用較為相關，頻繁的相同的DML動作分佈在三個不同的節點(RAC環境為4節點)，當修改其中一個節點SGA裡的一個塊後，其他節點同樣有這個動作，9i的cache fusion會根據其他請求節點的GCS請求生成pi塊到對應請求節點，因為session的pin動作是1:1的(pin:物件塊)，且9i預設pi塊是6個，所以，這是目前環境中造成cluster wait的主要原因，再深入分析一下，這也跟block_size有較大原因，若一個塊中含有的行不多，就算有此類buffer busy waits 220識別碼的等待，也不會是非常突出的。不行的是，這個db環境的db_block_size不知是誰設的，大小為16K。

解決方法：
1、減少塊中的行數(可增加pctfree，若塊大小較大，應該收效甚微)
2、將client連線節點的操作進行分類，比如將那些造成併發update的應用都連線至同一個節點，當然，這樣對rac的failover挑戰又提高到新的一個層面，比如若這個節點crash掉，整個業務的流程基本也被破壞掉。