转载

oracle 11g latch之v$latch系列二

背景

  在上文中: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/

正文到此结束
Loading...