ITPUB论坛-中国最专业的IT技术社区

 
 注册
热搜:
查看: 17168|回复: 27

[精华] 请问library cache pin和library cache lock是latch吗

[复制链接]
论坛徽章:
0
跳转到指定楼层
1#
发表于 2008-6-20 20:09 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
请问library cache pin和library cache lock是latch吗?对这个问题一直很模糊!
论坛徽章:
38
2010新春纪念徽章
日期:2010-01-04 08:33:082012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25版主2段
日期:2012-05-15 15:24:11优秀写手
日期:2013-12-18 09:29:08马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14
2#
发表于 2008-6-20 21:27 | 只看该作者
不是,Library cache pin是Oracle内部针对共享池的内存块的一种锁。
一些内存块合在一起存贮了一种对象。比如游标,一般需要两个两个内存块,一个存贮一般信息,另一个存贮执行执行计划。需要有一个总的内存块来管理这些分散的内存块,一般称这个总的内存块为句柄。Library cache lock是针对这个句柄块的锁。

使用道具 举报

回复
论坛徽章:
0
3#
 楼主| 发表于 2008-6-21 10:04 | 只看该作者
感谢晶晶的回答,这个我知道,但是这些都是内存锁,难道latch不是锁内存的吗?

使用道具 举报

回复
论坛徽章:
38
2010新春纪念徽章
日期:2010-01-04 08:33:082012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25版主2段
日期:2012-05-15 15:24:11优秀写手
日期:2013-12-18 09:29:08马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14
4#
发表于 2008-6-21 12:30 | 只看该作者
Library cache Lock/Pin和Latch都是锁,只不过它们的实现方式不一样。相比之下,大多数的Latch只是内存中的一些字节,通过在这些字节中设置某个值,代表Latch所保护的对象是否被占用,大部分闩没有等待者队列、占用者队列等队列,等等吧。Latch的工作方式和Library cache Lock/Pin不太一样。它们都是锁,只不过有些是暗锁,有些是明锁,就是这样吧,实现方式不同,因此就说锁的类型不同。

[ 本帖最后由 晶晶小妹 于 2008-6-21 12:32 编辑 ]

使用道具 举报

回复
论坛徽章:
47
蒙奇·D·路飞
日期:2017-03-27 08:04:23马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11一汽
日期:2013-09-01 20:46:27复活蛋
日期:2013-03-13 07:55:232013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:322012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20
5#
发表于 2008-6-22 03:18 | 只看该作者
chandler_1983's question can also be looked at this way: What do the latches "library cache pin" and "library
cache lock" do and what's the difference between "latch free" wait event where the latches are these two
types and the "library cache pin" or "library cache lock" waits themselves? Do the numbers
v$latch.gets for library cache lock/pin or the numbers v$system_event.total_waits for them tell us
the actual number of library cache locks/pins we've had in the database since instance startup?

If you check v$latch for these two latches and compare with the same name wait events in
v$system_event, you'll see the two latches are get'ed much more frequently. I think the numbers
for the two latches in v$latch accurately reflect the actual pins/locks we've had. There's no
statistic in v$sysstat or v$sesstat for latch gets, probably because v$latch.gets serves the
purpose already. If the database is not too busy causing waits on them, the numbers in
v$system_event (or other wait related views) will not increment. In fact, v$latch.sleeps should be
equal to these latches' "latch free" waits because latch waits are the same as latch sleeps. You
can test on a quiet single-user database, with no jobs or scheduler jobs, and very quickly type
select name, gets, misses, sleeps, immediate_gets from v$latch where name in ('library cache pin',
'library cache lock'). You'll see the pin gets keep going up (by 2 in my 10.2.0.1 database) while
lock gets stay the same. The 2 pins must be due to this SQL itself. Values in v$system_event stay
the same.

Yong Huang

[ 本帖最后由 Yong Huang 于 2008-6-23 06:07 编辑 ]

使用道具 举报

回复
论坛徽章:
23
授权会员
日期:2007-10-05 10:04:39生肖徽章2007版:猪
日期:2009-03-10 21:17:25生肖徽章2007版:猪
日期:2009-03-10 21:24:49生肖徽章2007版:蛇
日期:2009-03-10 21:28:28生肖徽章2007版:蛇
日期:2009-03-10 21:34:30祖国60周年纪念徽章
日期:2009-10-09 08:28:00ITPUB元老
日期:2009-12-20 10:42:092010年世界杯参赛球队:巴西
日期:2010-06-15 20:33:58ITPUB十周年纪念徽章
日期:2011-11-01 16:23:26雪佛兰
日期:2013-11-02 12:32:45
6#
发表于 2008-6-23 15:36 | 只看该作者
恩,学习一下

使用道具 举报

回复
论坛徽章:
38
2010新春纪念徽章
日期:2010-01-04 08:33:082012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25版主2段
日期:2012-05-15 15:24:11优秀写手
日期:2013-12-18 09:29:08马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14
7#
发表于 2008-6-23 17:21 | 只看该作者
library cache pin latch和library cache lock latch好像在文档上看过,因为Library cache Lock/Pin都不是原子操作,因此为了不使在加或释放Library cache Lock/Pin时,有其他操作对它们进行打扰,因为使用Library cache Lock/Pin latch对加、释放Lock/Pin的过程加以保护。

使用道具 举报

回复
论坛徽章:
86
ITPUB元老
日期:2005-02-28 12:57:002012新春纪念徽章
日期:2012-01-04 11:49:542012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20咸鸭蛋
日期:2012-05-08 10:27:19版主8段
日期:2012-05-15 15:24:112013年新春福章
日期:2013-02-25 14:51:24
8#
发表于 2008-6-23 19:21 | 只看该作者
获得一个library cache lock,表示获得到一个 handle,可以是  null、share,exclusive 三种模式。 根据这个handle可以获得到object。

pin 则是表示拥有handle情况下,要真正地使用这些object,必须把这些object 钉在内存中,这也分了 null、share、exclusive三种模式。

所以tom曾经简单描述过:  lock, get a handle,是一个寻找的结果; pin,excute ,使用寻找到的结果


结合sql的执行,编译,ddl的发生等情况可以理解三种模式的可能意义。

至于yong huang的例子中 pin增加  lock不增加,可以看作是 执行次数增加,但是由于session已经获得handle 不需要重新去寻找获得(session已经 cached这个 cursor ,表示已经获得handle)


这时我的理解,有什么不对欢迎讨论。

使用道具 举报

回复
论坛徽章:
47
蒙奇·D·路飞
日期:2017-03-27 08:04:23马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11一汽
日期:2013-09-01 20:46:27复活蛋
日期:2013-03-13 07:55:232013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:322012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20
9#
发表于 2008-6-23 20:12 | 只看该作者
I modified my text and specially added these words:

"the numbers [i.e. gets]
for the two latches in v$latch accurately reflect the actual pins/locks we've had. There's no
statistic in v$sysstat or v$sesstat for latch gets, probably because v$latch.gets serves the
purpose already. If the database is not too busy causing waits on them, the numbers in
v$system_event (or other wait related views) will not increment. In fact, v$latch.sleeps should be
equal to these latches' "latch free" waits because latch waits are the same as latch sleeps."

Yong Huang

使用道具 举报

回复
论坛徽章:
47
蒙奇·D·路飞
日期:2017-03-27 08:04:23马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11一汽
日期:2013-09-01 20:46:27复活蛋
日期:2013-03-13 07:55:232013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:322012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20
10#
发表于 2008-6-23 20:17 | 只看该作者
原帖由 biti_rainy 于 2008-6-23 05:21 发表
至于yong huang的例子中 pin增加  lock不增加,可以看作是 执行次数增加,但是由于session已经获得handle 不需要重新去寻找获得(session已经 cached这个 cursor ,表示已经获得handle)


Exactly! Can we guess what the 2 pins are for each execution? I type
select name, gets, misses, sleeps, immediate_gets from v$latch where name in ('library cache pin',
'library cache lock')
in quick succession and v$latch.gets for library cache pin goes up by 2. Why 2? One for x$kslld and one for x$ksllt, the two base table under v$latch?

Yong Huang

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 |
  | | |
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表