oracle 11g latch之v$latch系列二

时间：2015-11-04 02:21:00 阅读：352 评论：0 收藏：0 [点我收藏+]

背景

在上文中：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系列二

原文：http://blog.itpub.net/9240380/viewspace-1820457/

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年09月23日 (328)
2021年09月24日 (313)
2021年09月17日 (191)
2021年09月15日 (369)
2021年09月16日 (411)
2021年09月13日 (439)
2021年09月11日 (398)
2021年09月12日 (393)
2021年09月10日 (160)
2021年09月08日 (222)