latch:library cache

一：硬解析造成的shared pool latch 争用:

每一个sql被执行之前，先要到library cache中根据hash_value查找parent cursor,这就需要先获得library cache latch；

也就是说硬解析和软解析都有可能造成latch 争用

查看这些非常相似的语句:

select orguser0_.ID as ID359_, orguser0_.NAME as NAME359_, orguser0_.EMAIL as EMAIL359_, orguser0_.TEL as TEL359_, orguser0_.MOBILE as MOBILE359_, orguser0_.ATTR1 as ATTR6_359_, orguser0_.ATTR2 as ATTR7_359_, orguser0_.ATTR3 as ATTR8_359_, orguser0_.ATTR4 as ATTR9_359_, orguser0_.ATTR5 as ATTR10_359_, orguser0_.PASSWORD as PASSWORD359_, orguser0_.SECURITY_LEVEL as SECURITY12_359_ from ORG_USER orguser0_, ORG_GROUPUSER orggroupus1_ where (orguser0_.ID=orggroupus1_.USERID )and(orguser0_.ATTR2='0' )and((orguser0_.ATTR4 is null )or(orguser0_.ATTR4!='1' ))and(orggroupus1_.GROUPTYPEID='dept' )and(orggroupus1_.GROUPID in('300' , '300017' , '300010' , '300001' , '300013' , '300002' , '300014' , '300003' , '300012' , '300020')) order by orggroupus1_.GROUPID asc , orggroupus1_.SORTINDEX asc   select orguser0_.ID as ID359_, orguser0_.NAME as NAME359_, orguser0_.EMAIL as EMAIL359_, orguser0_.TEL as TEL359_, orguser0_.MOBILE as MOBILE359_, orguser0_.ATTR1 as ATTR6_359_, orguser0_.ATTR2 as ATTR7_359_, orguser0_.ATTR3 as ATTR8_359_, orguser0_.ATTR4 as ATTR9_359_, orguser0_.ATTR5 as ATTR10_359_, orguser0_.PASSWORD as PASSWORD359_, orguser0_.SECURITY_LEVEL as SECURITY12_359_ from ORG_USER orguser0_, ORG_GROUPUSER orggroupus1_ where (orguser0_.ID=orggroupus1_.USERID )and(orguser0_.ATTR2='0' )and((orguser0_.ATTR4 is null )or(orguser0_.ATTR4!='1' ))and(orggroupus1_.GROUPTYPEID='dept' )and(orggroupus1_.GROUPID in('300300017' , '300300013' , '300300015' , '300300045' , '300300021' , '300300022' , '300300046' , '300300023' , '300300024' , '300300025')) order by orggroupus1_.GROUPID asc , orggroupus1_.SORTINDEX asc

只要In的地方不一样,其他的地方都一样,这就是硬解析造成的Latch 争用

这种情况是属于没有使用绑定变量的情况。

转载于:https://www.cnblogs.com/zhaoyangjian724/p/3797902.html