背景

在上文中：http://blog.itpub.net/9240380/viewspace-1820418/，我們學習oracle 11g latch開了個頭，本文繼續瞭解latch相關的知識，
主要基於v$latch進行測試，以小見大，為求真義。

結論

1,latch分為樂意等待和不樂意等待，共計2種型別
2,v$latch會包含所有的latch,即其中包含了當前ORACLE沒有使用的latch
3,當前ORACLE沒有使用的LATCH的v$latch相關列全為0
4,樂意等待latch
v$latch.gets及misses為非0，且immediate_gets及immediate_misses為0

不樂意等待latch
與上述相反

5，當前ORACLE未使用的LATCH其 v$latch.gets及misses且immediate_gets及immediate_misses全為0

6，v$latch還有一個重要的列wait_time,表明用於等待獲取latch消耗的時間，單位為微妙 (1微妙=百萬分之1秒)，所以當你分析latch相關的問題時，可以從gets,misses,immediate_gets,immediate_misses
以及wait_time進行分析，也就是說你只要關注gets高，且miss也很高，且wait_time也很高的latch,當然這個wait_time是所有等待latch的累積值，其實大家最主要是參考gets,miss以及immediate gets和
immediate misses的佔比，基於這些嚴重的latch進行進一步的分析即可，這就是價值所在

7,獲取資料庫最引發效能問題的LATCH 的SQL如下：

select addr,latch#,level#,name,hash,gets,misses,immediate_gets,immediate_misses,spin_gets,wait_time
from v$latch
order by gets desc,misses desc,immediate_gets desc,immediate_misses desc

8，v$latch.wait_time表明等待獲取LATCH的時間，單位為微妙 (1微妙=百萬分之1秒)

測試

1,資料庫版本
SQL> select * from v$version where rownum=1;

BANNER
----------------------------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

2,獲取latch資訊，基於pool相關的latch進行測試

SQL> select latch#,name,hash from v$latchname where lower(name) like '%pool%';

LATCH# NAME HASH
---------- ---------------------------------------------------------------------- ----------
33 SGA IO buffer pool latch 2719726273
47 channel handle pool latch 2325739900
49 message pool operations parent latch 2459008016
66 segmented array pool 4087078798
97 KJC message pool free list 1098645424
146 buffer pool 510014793
229 io pool granule metadata list 583120770
230 io pool granule list 3227857269
251 sort extent pool 986781538
264 File State Object Pool Parent Latch 4105835930
265 Write State Object Pool Parent Latch 3443296917
269 Locator state objects pool parent latch 1756373275
293 shared pool 2276811941
309 shared pool simulator 1958856927
310 shared pool sim alloc 287267747
331 SGA pool creation lock 1589099373
332 SGA pool locks 822732615
356 cp pool array latch 3981471796
361 cp pool latch 4172867191
403 STREAMS Pool Advisor 1282588990
414 connection pool sga data lock 1957382980
451 XDB unused session pool 894085995
452 XDB used session pool 3437339883

23 rows selected.

3,以shared pool latch進行測試
--spin_gets表明首次請求沒有獲取到，但在其後的spinning中獲取到了latch的請求次數，也就是在多少次請求後，獲取到了latch
SQL> select addr,latch#,level#,name,hash,gets,misses,immediate_gets,immediate_misses,spin_gets from v$latch where latch#=293;

ADDR LATCH# LEVEL# NAME HASH GETS MISSES IMMEDIATE_GETS IMMEDIATE_MISSES SPIN_GETS
---------------- ---------- ---------- -------------------- ---------- ---------- ---------- -------------- ---------------- ----------
0000000060033B08 293 7 shared pool 2276811941 2520762 3161 0 0 4

由上可見shared pool它是屬於樂意等待latch,判斷依據為其immediate_gets,immediate_misses全為0
可進一步引申出gets,misses與immediate_gets,immediate_misses為互斥列，即只能二選一
且gets,misses為非0時，且列spin_gets也為非值，因為此列與樂意等待latch有關，請見官方手冊

4，為了驗證這一點，我們找一個不樂意等待latch,對比一看即知,但從實驗結果可知，latch並非簡單的可以分為樂意等待和不樂意等待，從下可知，有些latch
是混合型的，即有樂意等待，也有不樂意等待

SQL> select addr,latch#,level#,name,hash,gets,misses,immediate_gets,immediate_misses,spin_gets from v$latch where gets >0 and immediate_gets>0 and rownum<=10;

ADDR LATCH# LEVEL# NAME HASH GETS MISSES IMMEDIATE_GETS IMMEDIATE_MISSES SPIN_GETS
---------------- ---------- ---------- -------------------------------------------------- ---------- ---------- ---------- -------------- ---------------- ----------
0000000060009720 2 8 post/wait queue 823771719 119871 13 129158 13 0
0000000060009F38 9 7 process allocation 2600548697 4690 0 1625 0 0
000000006000A9E0 16 8 longop free list parent 853437045 445 0 50 0 0
000000006000CF38 28 4 enqueue hash chains 1456202064 1363385 4404 1888 0 94
000000006000D3A0 33 6 SGA IO buffer pool latch 2719726273 1 0 1 0 0
00000000600101C8 70 0 active service list 4226341592 222878 185 1799 0 43
00000000600178B0 137 7 Memory Management Latch 1808980316 25 0 1112 0 0
00000000600188A8 145 2 cache buffers lru chain 3559635447 186779 248 170794 436 0
0000000060019E38 149 5 checkpoint queue latch 4259362863 50678 3 13881 16 0
000000006001A620 150 1 cache buffers chains 3563305585 35875686 9320 422474 391 3876

10 rows selected.

5,我們先暫且放下由4引出的問題，先繼續測試不樂意等待latch

可見不樂意等待latch只有1個latch
SQL> select addr,latch#,level#,name,hash,gets,misses,immediate_gets,immediate_misses,spin_gets from v$latch where gets=0 and immediate_gets>0;

ADDR LATCH# LEVEL# NAME HASH GETS MISSES IMMEDIATE_GETS IMMEDIATE_MISSES SPIN_GETS
---------------- ---------- ---------- -------------------------------------------------- ---------- ---------- ---------- -------------- ---------------- ----------
0000000060036B68 355 6 kmcpvec latch 4081087589 0 0 1 0 0

6,突然想到我們對比看下總的latch個數，以及樂意等待latch個數，不樂意等待latch個數，還有混合型latch個數，我的目的，就是看看ORACLE這些不同型別latch的資料分佈情況

總LATCH個數
SQL> select count(*) from v$latch;

COUNT(*)
----------
535

SQL> select count(*) from v$latchname;

COUNT(*)
----------
535

樂意等待的LATCH個數
SQL> select count(*) from v$latch where gets>0 and IMMEDIATE_GETS=0;

COUNT(*)
----------
232

不樂意等待的LATCH個數
SQL> select count(*) from v$latch where gets=0 and IMMEDIATE_GETS>0;

COUNT(*)
----------
1

混合型的LATCH個數
SQL> select count(*) from v$latch where gets>0 and IMMEDIATE_GETS>0;

COUNT(*)
----------
26

從這些資料來看，可見不樂意等待LATCH佔比最小，其次是混合等待LATCH，佔比最大是樂意等待LATCH

大家注意到沒有，出現一個問題，還有將近300個LATCH沒有出來，那麼這些LATCH在V$LATCH中的資料是如何表示的呢

SQL> select count(*) from v$latch where latch# not in (select latch# from v$latch where gets>0 and IMMEDIATE_GETS=0) and
2 latch# not in (select latch# from v$latch where gets=0 and IMMEDIATE_GETS>0) and latch# not in (select latch# from v$latch where gets>0 and IMMEDIATE_GETS>0);

COUNT(*)
----------
276

哈哈，我忽略了一點，oracle是設計了很多latch,但並不一定在ORACLE會用到，所以下面的資料全是0，再引申一點，透過gets及immediate_gets的值，可以對比分析ORACLE不同時間獲取latch的資訊
select addr,latch#,level#,name,hash,gets,misses,immediate_gets,immediate_misses,spin_gets
from v$latch
where latch# not in (select latch# from v$latch where gets>0 and IMMEDIATE_GETS=0) and
latch# not in (select latch# from v$latch where gets=0 and IMMEDIATE_GETS>0) and
5 latch# not in (select latch# from v$latch where gets>0 and IMMEDIATE_GETS>0);

ADDR LATCH# LEVEL# NAME HASH GETS MISSES IMMEDIATE_GETS IMMEDIATE_MISSES SPIN_GETS
---------------- ---------- ---------- -------------------------------------------------- ---------- ---------- ---------- -------------- ---------------- ----------
00000000600426B0 450 0 qm_init_sga 1799516562 0 0 0 0 0
0000000060017810 136 7 KMG resize request state object freelist 1416635829 0 0 0 0 0
0000000060014148 104 2 KJCT receiver queue access 838120754 0 0 0 0 0
00000000600213E8 184 8 readredo stats and histogram 2574800526 0 0 0 0 0
00000000600410D0 429 6 kwqbsgn:msghdr 4071600641 0 0 0 0 0
000000006003E628 398 0 datapump job fixed tables latch 3169101808 0 0 0 0 0
000000006001CE60 172 1 SGA kcrrgap latch 2883851438 0 0 0 0 0
000000006003E428 397 6 pass worker exception to master 2904702169 0 0 0 0 0
0000000060013D50 99 2 KJC snd proxy ctx free list 3826497631 0 0 0 0 0
00000000600272D8 221 6 Minimum flashback SCN latch 3060729071 0 0 0 0 0

所以說oracle的latch還是分為樂意等待和不樂意等待的，呵呵。

7,v$latch還有一個重要的列wait_time,表明用於等待獲取latch消耗的時間，單位為微妙 (1微妙=百萬分之1秒)，所以當你分析latch相關的問題時，可以從gets,misses,immediate_gets,immediate_misses
以及wait_time進行分析，也就是說你只要關注gets高，且miss也很高，且wait_time也很高的latch,當然這個wait_time是所有等待latch的累積值，其實大家最主要是參考gets,miss以及immediate gets和
immediate misses的佔比，基於這些嚴重的latch進行進一步的分析即可，這就是價值所在
SQL> select addr,latch#,level#,name,hash,gets,misses,immediate_gets,immediate_misses,spin_gets,wait_time from v$latch order by wait_time desc;

ADDR LATCH# LEVEL# NAME HASH GETS MISSES IMMEDIATE_GETS IMMEDIATE_MISSES SPIN_GETS WAIT_TIME
---------------- ---------- ---------- -------------------------------------------------- ---------- ---------- ---------- -------------- ---------------- ---------- ----------
000000006004B2C8 528 1 JS slv state obj latch 1133594188 472751 9394 0 0 0 1.0229E+10
000000006001A620 150 1 cache buffers chains 3563305585 51831818 11566 424902 409 5465 1316150119
00000000600306F0 270 4 row cache objects 2412510220 35491496 5163 149 2 4 1169799490
000000006002A770 243 0 In memory undo latch 4131189770 1055428 4579 209200 870 14 1100035765
000000006000CF38 28 4 enqueue hash chains 1456202064 1985359 4821 1891 0 95 647337885
0000000060033B08 293 7 shared pool 2276811941 4627433 3426 0 0 4 302077467
000000006000CE98 27 5 enqueues 3020999359 711879 1577 0 0 1 164373577
0000000060009FD8 10 5 call allocation 2417017526 217168 773 0 0 0 108367630

8,也就是說你在分析時，可採用的SQL如下
select addr,latch#,level#,name,hash,gets,misses,immediate_gets,immediate_misses,spin_gets,wait_time from v$latch order by gets desc,misses desc,immediate_gets desc,immediate_misses desc

個人簡介：

8年oracle從業經驗，具備豐富的oracle技能，目前在國內北京某專業oracle服務公司從事高階技術顧問。

服務過的客戶：

中國電信

中國移動

中國聯通

中國電通

國家電網

四川達州商業銀行

湖南老百姓大藥房

山西省公安廳

中國郵政

北京302醫院

河北廊坊新奧集團公司

專案經驗:

中國電信3G專案AAA系統資料庫部署及最佳化

中國聯通CRM資料庫效能最佳化

中國移動10086電商平臺資料庫部署及最佳化

湖南老百姓大藥房ERR資料庫sql最佳化專案

四川達州商業銀行TCBS核心業務系統資料庫模型設計和RAC部署及最佳化

四川達州商業銀行TCBS核心業務系統後端批處理儲存過程功能模組編寫及最佳化

北京高鐵訊號監控系統RAC資料庫部署及最佳化

河南宇通客車資料庫效能最佳化

中國電信電商平臺核心採購模組表模型設計及最佳化

中國郵政儲蓄系統資料庫效能最佳化及sql最佳化

北京302醫院資料庫遷移實施

河北廊坊新奧data guard部署及最佳化

山西公安廳身份證審計資料庫系統故障評估

聯絡方式：

手機：18201115468

qq : 305076427

qq微博: wisdomone1

新浪微博：wisdomone9

qq群：275813900

itpub部落格名稱：wisdomone1 http://blog.itpub.net/9240380/

oracle 11g latch之v$latch系列二

背景

結論

測試

個人簡介：

相關文章