1、對(duì)于閂（Latches）的概覽
Latches是為了保護(hù)SGA中的共享數(shù)據(jù)結(jié)構(gòu)而創(chuàng)建的簡(jiǎn)單的底層的序列化機(jī)制，是輕量級(jí)的鎖。server或后臺(tái)進(jìn)程為了操作或是查看共享數(shù)據(jù)結(jié)構(gòu)必 須先申請(qǐng)Latches，當(dāng)操作結(jié)束，需要釋放Latches。Latches的爭(zhēng)用是不用tuning的，它是不合理使用SGA資源的征兆，需要 tuning內(nèi)部的爭(zhēng)用。僅僅是觀察v$LATCH是不足的，但可以將其看做是診斷工具，查找SGA資源爭(zhēng)用的位置。
1）Latches的目的：
* 控制序列化訪問(wèn)：保護(hù)SGA中的數(shù)據(jù)結(jié)構(gòu)；保護(hù)共享內(nèi)存的分配。
* 序列化執(zhí)行某些操作：避免同時(shí)執(zhí)行某些關(guān)鍵的臨界code；避免corruptions。
2）等待Latch
盡管latch的實(shí)現(xiàn)根據(jù)不同的OS和平臺(tái)而不同，但是其都是內(nèi)存中的一塊地址空間，當(dāng)latch空閑時(shí)是0，已經(jīng)被申請(qǐng)了時(shí)為非0值。
在單cpu中，當(dāng)進(jìn)程p1申請(qǐng)的latch被占用，p1將釋放cpu，sleep一小段時(shí)間，等待latch被釋放。
在多cpu中，如果進(jìn)程p1申請(qǐng)的latch被p2占用，很可能p2在其他的cpu上，則p1不會(huì)釋放cpu，而是spin計(jì)數(shù)，重試，spin計(jì)數(shù)，重試，直到重試次數(shù)達(dá)到設(shè)置數(shù)，仍未成功，才會(huì)釋放cpu，但這種可能比較小。
3）Latch的請(qǐng)求類型：
latch的請(qǐng)求方式有兩類：willing-to-wait和immediate。
willing-to-wait：當(dāng)進(jìn)程申請(qǐng)一個(gè)latch時(shí)，如果當(dāng)前latch已經(jīng)被占用，該進(jìn)程會(huì)等待片刻再重試，等待-重試，直到獲得latch，這是一般普遍的latch申請(qǐng)方式。
immediate：如果進(jìn)程申請(qǐng)的latch不能獲得，該進(jìn)程會(huì)繼續(xù)執(zhí)行后續(xù)的指令。
4）latch 沖突：latch的申請(qǐng)釋放都是Oracle自動(dòng)實(shí)現(xiàn)的，所以速度比較快。latch的資源是有限的。
在診斷latch時(shí)，可利用視圖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事件，如果有再進(jìn)行后續(xù)的分析。
2、降低Latches的沖突
一般，DBA不應(yīng)該調(diào)節(jié)latches的數(shù)目，自9i以來(lái)，Oracle已經(jīng)可以自己進(jìn)行latches數(shù)量的調(diào)節(jié)了，這主要是根據(jù)DB在建立時(shí)設(shè)置的初始參數(shù)和OS的環(huán)境。
latches的沖突是性能問(wèn)題的表現(xiàn)。最好的解決latches沖突問(wèn)題的方法是修改application行為。此外，如果觀察到是buffer或shared poolsize的問(wèn)題，也需要進(jìn)行適當(dāng)?shù)男薷摹?/p>
3、對(duì)DBA而言，幾個(gè)重要的latches
1）shared pool latch和library cache latch：如果沖突出現(xiàn)在這兩類latch上，則表示sql或是pl/sql命令沒(méi)有被有效重用，可能是沒(méi)有有效的使用綁定變量，或是cursor cache不足。如果是Oracle Shared server模式，如果沒(méi)有設(shè)置large pool，也可能導(dǎo)致Shared pool Latch的沖突，則需要考慮設(shè)置large pool。
2）cache buffer lru chain latch：當(dāng)dirty blocks被寫入disk或server進(jìn)程查找blocks用于寫入操作時(shí)會(huì)request此latch。如果它存在較大沖突，則表示buffer cache任務(wù)繁重，可能存在較多的cache-based sorts、低效的SQL（使用了不正確的迭代索引）或是較多的全表掃描。此外，也可能是由于DBWn的寫速度跟不上data blocks的變化速度。使得訪問(wèn)進(jìn)程不得不為了找到buffer中的free blocks等待。對(duì)這個(gè)latch的沖突，應(yīng)該從buffer cache或DBWn的調(diào)節(jié)入手。
3）cache buffers chains latch：當(dāng)user進(jìn)程試圖分配buffer cache中的data blocks時(shí)，需要申請(qǐng)此latch。它的沖突反映了某些熱塊被重復(fù)訪問(wèn)的情況。
4、共享池和library cache latch沖突：如上所述，此類沖突的一個(gè)主要原因是不必要的解析。其調(diào)節(jié)方法已經(jīng)在之前介紹過(guò)了。
1）辨識(shí)因?yàn)槠磳懛绞蕉斐傻亩啻谓馕觯?span lang="EN-US">
select sql_text from v$sqlarea where executions=1 order by upper(sql_text);
2）查看是否有不必要的重復(fù)解析。
select sql_text, parse_calls, executions from v$sqlarea order by parse_calls;