Latch free等待事件.doc
50墨值下载
Latch free
等待事件
Latch free
等待事件的三个参数：
p1
－
latch
的地址；
p2
－
latch
编号；
p3
－请求次数。
从
oracle10g
起，
latch free
不再包含所有的
latch
等待，有些
latch
等待可能表现为单独的
等待事件，这个后面有提到一些这样的等待事件，一般情况下我们还是统称为
latch free
等
待事件。在处理
latch free
等待事件时，需要注意以下几点：
Latch
只是用来保护
sga
中的内存结构。对数据库中的对象的保护，使用的
lock
而不
是
latch
。
Oracle sga
中有许多
latch
，用来保护
sga
中各种内存结构不会因为并发访
问而损坏。
等待
latch
的是
oracle
会话。不同的
latch
类型会导致会话采取不同的策略。
在
oracle9i
（包括
9i
）之前，
latch free
等待事件包 括了所有的
latch
等待，但 从
oracle10g
起，
latch
被分成不同的种类，并且某些
latch
表现为独立的等待事件。
什么是
latch
Latch
是一种锁机制。你应该已经熟悉
latch
的概念和用法，虽然可能你自己并没有意
识到。在日常的工作和交流中，
latch
都经常出现，比如你锁门时，需要获得一个
latch
；或
者你坐到车里，系上安全带，你就把自己放在一个
latch
的保护中了。
在
oracle
中，
latch
是一种轻量级的锁。一般来说，
latch
由三种内存元素组成：
pid
（进
程
id
），内存地址和内存长度。
Latch
保证对共享数据结构的排它性访问，以此来保证内存
结构的完整性不受到损坏。在多个会话同时修改或者检视
(inspect)sga
中同一个内存结构时，
必须串行化访问以保证
sga
中数据结构的完整性。
Latch
和
lock
的异同
Latch
和
lock
有许多不同之处。下表列出了
latch
和
lock
之间的比较结果。
Latch Lock
目的 只有一个目的：保证对内存结构的排他性
访问（从
oracle9i
开始，
cache buffers chain
latch
可以允许只读共享访问）
两个目的：如果锁模式是兼容的，允
许多个进程共享相同的资源；如果锁
模型是不兼容的，保证对共享资源的
排它性访问。
适用场景 只能应用于
sga
中的数据结构，保护内存对
象。
Latch
只影响单次操作，而和事务无
关。
保护数据库对象，诸如表，数据块和
状态对象等。由应用程序驱动，控制
对 数 据 库 中 数 据 和 元 数 据 的 访
问。
Lock
是事务性的。
获取方式 两种模式：
willing-to-wait
和
no-wait
六 种 模 式 ：
null, row share, row
exclusive, share, share row exclusive
和
exclusive
范围 信息都保存在内存中，并且只在本实例可
见――
latch
是实例级别的
信息保存在数据库中，并且该数据库
的所有实例都可见――
lock
是数据库
级的
复杂度 使 用 简 单 机 器 指 令 比 如 ：
test-and-set,
compare-and-swap
或其他简单的
cpu
指令实
现。由于
cpu
指令平台相关，所以
latch
在
不同的平台的具体实现不一样。轻量级
的。
需要上下文切换（
context siwtch
），
使用一系列指令实现。
重量级的。
持续事件 非常短暂（通常是微妙级的） 通常在整个事务中都持有。
排队机制 当一个进程获取
latch
失败，转入睡眠状态
时，他的请求不需要按顺序排队（一个例
外情况：
latch wait list latch
需要排队）。
当一个进程获取
lock
失败，它的请求
会进入一个队列，除非指定
nowait
。
死锁
Latch
的实现方式不会产生死锁（不排队）
Lock
的排队机制可能导致死锁。死
锁发生时会产生相应的跟踪文件。
Latch
家族
Latch
有三种：父
latch
，子
latch
和独立
latch
。父
latch
和独立
latch
在
oracle
的内核代
码中固化，子
latch
则在实例启动时创造。
V$latch_parent
和
v$latch_children
视图分别包含
父
latch
和子
latch
的统计信息。而
v$latch
则包含独立
latch
，父
latch
及其相应子
latch
的聚
合统计信息。
Latch
的获取
进程获取
latch
有两种模式：
willing-to-wait
和
no_wait
。
No-wait
模式只在少数
latch
中
使用。通过
no-wait
模式获取
latch
的统计信息记录在
immediate_gets
和
immediate_misses
列
中，这些列在
v$latch
，
v$latch_parent
，
v$latch_children
视图中都存在。一般来说，
no-wait
模式在第一次获取一些有很多子
latch
的
latch
比如
redo copy
时使用。如果一个进程第一次
获取这些子
latch
中的任何一个失败，它会立即使用
no-wait
模式询问下一个。只有当采用
no-wait
模式试图获取所有的子
latch
都失败以后，才会转而采用
willing-to-wait
模式。
通过
willing-to-wait
模式获取
latch
的统计信息存放在
gets
和
misses
列中。每当一个进
程用
willing-to-wait
模式去获取一个
latch
时，
gets
都会增加。
如果进程在第一次请求
latch
时，
latch
可用，就会直接获得该
latch
。在修改任何受到
保护的数据结构之前，进程会将一些恢复信息写入到
latch
恢复区，这样当获得
latch
的进
程发生异常时，
pmon
进程才能够清理该进程持有的
latch
。
如果请求
latch
时，该
latch
不可用，进程就会在
cpu
中等待一小段时间
(spin)
然后重新
请求
latch
。如果
latch
一直不可用，该过程
(spin
一段时间然后重新请求
)
会一直重复。重复
的次数由隐含参数
_spin_count
决定，默认值
2000
。如果在请求
_spin_count
次之内获得了
latch
，就对
spin_gets
和
misses
列各加一，否则，进程在
v$session_wait
中记录
latch free
等
待事件，然后释放
cpu
，转入睡眠状态。睡眠一定时间后，进程被唤醒并重复上面的过程，
一直到获得
latch
。在成功获得
latch
后，才会更行
sleep
列得统计信息。
由于进程只有在获得
latch
后才会停止对
latch
得请求，如果某个持有
latch
的进程发生
异常，其他请求该
latch
的进程该怎么办？岂不是要一直等待下去？不会的。当一个进程请
求
latch
失败一定次数后，它会请求
pmon
进程查看该
latch
的持有者，如果持有进程异常，
pmon
就会清理该进程，释放
latch
。
每个
latch
都有一个从
0
到
13
的优先级编号。父
latch
和独立
latch
的优先级编号是在
oracle
内核代码中固定的。子
latch
是在实例启动时创建，其优先级编号从其父
latch
继承。
使用优先级可以避免死锁。
当一个进程请求
no-wait
模式的
latch
时，该
latch
的优先级编号必须和它当前已经持有
的
latch
的优先级编号相同。
当一个进程请求
willing-to-wait
模式的
latch
时，该
latch
的优先级编号必须比它当前已
经持有的
latch
的优先级编号要大。
短等待
latch
与长等待
latch
大多数
latch
都是短等待
latch
，所以，进程请求
latch
时不会等待太长的时间。
Oracle
进程请求
latch
失败而导致进入睡眠状态，每次睡眠时间按双指数队列增长，比如睡眠时间
of 19
50墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论