1、對于閂（Latches）的概覽
Latches是為了保護SGA中的共享數據結構而創建的簡單的底層的序列化機制，是輕量級的鎖。server或后臺進程為了操作或是查看共享數據結構必 須先申請Latches，當操作結束，需要釋放Latches。Latches的爭用是不用tuning的，它是不合理使用SGA資源的征兆，需要 tuning內部的爭用。僅僅是觀察v$LATCH是不足的，但可以將其看做是診斷工具，查找SGA資源爭用的位置。
1）Latches的目的：
* 控制序列化訪問：保護SGA中的數據結構；保護共享內存的分配。
* 序列化執行某些操作：避免同時執行某些關鍵的臨界code；避免corruptions。
2）等待Latch
盡管latch的實現根據不同的OS和平臺而不同，但是其都是內存中的一塊地址空間，當latch空閑時是0，已經被申請了時為非0值。
在單cpu中，當進程p1申請的latch被占用，p1將釋放cpu，sleep一小段時間，等待latch被釋放。
在多cpu中，如果進程p1申請的latch被p2占用，很可能p2在其他的cpu上，則p1不會釋放cpu，而是spin計數，重試，spin計數，重試，直到重試次數達到設置數，仍未成功，才會釋放cpu，但這種可能比較小。
3）Latch的請求類型：
latch的請求方式有兩類：willing-to-wait和immediate。
willing-to-wait：當進程申請一個latch時，如果當前latch已經被占用，該進程會等待片刻再重試，等待-重試，直到獲得latch，這是一般普遍的latch申請方式。
immediate：如果進程申請的latch不能獲得，該進程會繼續執行后續的指令。
4）latch 沖突：latch的申請釋放都是Oracle自動實現的，所以速度比較快。latch的資源是有限的。
在診斷latch時，可利用視圖v$latch，該視圖中主要columns的意義：
• gets: Number of successful willing-to-wait requests for a latch
• misses: Number of times an initial willing-to-wait request was unsuccessful
• sleeps: Number of times a process waited after an initial willing-to-wait request
• wait_time: Number of milliseconds waited after willing-to-wait request
• cwait_time: A measure of the cumulative wait time including the time spent spinning and sleeping, the overhead of context switches due to OS time slicing and page faults and interrupts
• spin_gets: Gets that missed first try but succeeded after spinning
• immediate_gets: Number of successful immediate requests for each latch.
• immediate_misses: Number of unsuccessful immediate requests for each latch.
在使用statspack是，可先查看其report的top 5 wait events部分，是否有latch free事件，如果有再進行后續的分析。
2、降低Latches的沖突
一般，DBA不應該調節latches的數目，自9i以來，Oracle已經可以自己進行latches數量的調節了，這主要是根據DB在建立時設置的初始參數和OS的環境。
latches的沖突是性能問題的表現。最好的解決latches沖突問題的方法是修改application行為。此外，如果觀察到是buffer或shared poolsize的問題，也需要進行適當的修改。
3、對DBA而言，幾個重要的latches
1）shared pool latch和library cache latch：如果沖突出現在這兩類latch上，則表示sql或是pl/sql命令沒有被有效重用，可能是沒有有效的使用綁定變量，或是cursor cache不足。如果是Oracle Shared server模式，如果沒有設置large pool，也可能導致Shared pool Latch的沖突，則需要考慮設置large pool。
2）cache buffer lru chain latch：當dirty blocks被寫入disk或server進程查找blocks用于寫入操作時會request此latch。如果它存在較大沖突，則表示buffer cache任務繁重，可能存在較多的cache-based sorts、低效的SQL（使用了不正確的迭代索引）或是較多的全表掃描。此外，也可能是由于DBWn的寫速度跟不上data blocks的變化速度。使得訪問進程不得不為了找到buffer中的free blocks等待。對這個latch的沖突，應該從buffer cache或DBWn的調節入手。
3）cache buffers chains latch：當user進程試圖分配buffer cache中的data blocks時，需要申請此latch。它的沖突反映了某些熱塊被重復訪問的情況。
4、共享池和library cache latch沖突：如上所述，此類沖突的一個主要原因是不必要的解析。其調節方法已經在之前介紹過了。
1）辨識因為拼寫方式而造成的多次解析：
select sql_text from v$sqlarea where executions=1 order by upper(sql_text);
2）查看是否有不必要的重復解析。
select sql_text, parse_calls, executions from v$sqlarea order by parse_calls;