latch free等待事件

 

latch free 

latch是一種輕量級的鎖。一般來說，latch由三種記憶體元素組成：pid（程式id），記憶體地址和記憶體長度。Latch保證對共享資料結構的排它性訪問，以此來保證記憶體結構的完整性不受到損壞。在多個會話同時修改或者檢視(inspect)sga中同一個記憶體結構時，必須序列化訪問以保證sga中資料結構的完整性。 

Latch只是用來保護sga中的記憶體結構。對資料庫中的物件的保護，使用的lock而不是latch。Oracle sga中有許多latch，用來保護sga中各種記憶體結構不會因為併發訪問而損壞。常見的Latch Free等待事件是由於熱塊 (buffer cache中的latch爭用) 及未使用繫結變數(shared pool中的latch爭用) 導致的。

最常見的Latch集中於Buffer Cache的競爭和Shared Pool的競爭。和Buffer Cache相關的主要Latch競爭有cache buffers chains和cache buffers lru chain，和Shared Pool相關的主要Latch競爭有Shared Pool Latch和Library Cache Latch等。  Buffer Cache的Latch競爭經常是由於熱點塊競爭引起；Shared Pool的Latch競爭通常是由於SQL的硬解析引起。

在oracle9i（包括9i）之前，latch free等待事件包括了所有的latch等待，但從oracle10g起，latch被分成不同的種類，並且某些latch表現為獨立的等待事件。

如果我們在v$session_wait中發現有latch free等待事件，就意味著，程式在請求一個willing_to_wait模式的latch，在重試了_spin_count次 (預設為2000) 後還是沒有獲得latch，然後轉入睡眠狀態了。如果latch爭用嚴重，將會由於不斷的spin導致cpu資源緊張，從而增加系統響應時間。

V$system_event檢視的total_waits列記錄了程式獲取willing-to-wait模式latch失敗的次數。V$latch的sleeps列記錄了程式由於等待某個latch而進入睡眠狀態的次數。由於一個程式在_spin_count次嘗試請求latch失敗後會轉入睡眠狀態，total_waits列應該等於sleeps列的值的和，如以下sql所示。但是，某些時候，total_waits會比sleeps的和要大，這是因為，只有在程式獲得latch後才會更新total_waits的值，而不是每次請求latch失敗就更新。

 

Latch的獲取   

如果請求latch時，該latch不可用，程式就會在cpu中等待一小段時間(spin)然後重新請求latch。如果latch一直不可用，該過程(spin一段時間然後重新請求)會一直重複。重複的次數由隱含引數_spin_count決定，預設值2000。如果在請求_spin_count次之內獲得了latch，就對spin_gets和misses列各加一，否則，程式在v$session_wait中記錄latch free等待事件，然後釋放cpu，轉入睡眠狀態。睡眠一定時間後，程式被喚醒並重覆上面的過程，一直到獲得latch。在成功獲得latch後，才會更行sleep列得統計資訊。

 

由於程式只有在獲得latch後才會停止對latch得請求，如果某個持有latch的程式發生異常，其他請求該latch的程式該怎麼辦？豈不是要一直等待下去？不會的。當一個程式請求latch失敗一定次數後，它會請求pmon程式檢視該latch的持有者，如果持有程式異常，pmon就會清理該程式，釋放latch。 

 

Latch 爭用 

程式在spin的過程中，會一直持有CPU，spin的機制是假設Latch可以被快速釋放（正常情況下，Latch的持有時間是微秒級，相對spin機制如果直接採用Sleep方式引起的上下文切換會相當昂貴，所以Oracle針對Latch引入了spin演算法），如果其他CPU上的其他程式釋放了Latch，SPIN程式就可以立即獲得這個Latch。如果系統只有單CPU，那就談不上SPIN了。另一方面也可以看到，Latch競爭是非常昂貴的，可能導致嚴重的CPU耗用，所以Latch競爭在任何時候都應該引起充分的重視。經過spin後成功獲得Latch的次數被記錄在v$latch.spin_gets欄位。透過下圖來說明一下Latch競爭的情況。