latch:shared pool
shared pool 锁存器一般在整个实例上只存在一个(9i之前).
hard parsing严重时,经常发生分割chunk的现象,因此在空闲列上出现许多较小空闲的chunk的现象.这种现象称为共享池的碎片化,延长查询空闲列 的时间.共享池碎片化是引发shared pool锁存器争用的根本原因.ora-4031错误也是由碎片化引发的.
最好的解决方法就是为避免发生hard parsing,恰当使用bind变量.但不容易对动态的应用程序进行修正.
oracle提供了几个解决问题的方法:
(1)oracle 9i以上版本起,共享池分为多个副池,最多由7个副池分别进行管理.
(2)hard parsing引发shared pool锁存器争用时,另外的解决方法是减少共享池大小.但这时发生ora-4031的错误概率高.可以利用dbms_shared_pool.keep ,应用将经常使用的sql cursor,程序包,procedure等永久置于共享池的方法.
(3)提供cursor sharing方法.
latch:library cache
为了执行sql,通过library cache锁存器,保护检索并管理库高速缓冲区的所有工作.library cache锁存器拥有与比cpu count值
大的最小质数值相同数量的子锁存器.
library cahce争用主要在哪下情况下发生:
(1)hard parsing 或soft parsing过多时
(2)version count 高时
(3)sga区域发生pageout时
library cache锁存器争用的最重要原因也是hard parsing.因为检索库高速缓冲区的次数增加,相应地拥有library cache锁存器
的时间和次数会增加;hard parsing时,不仅需要对库高速缓冲区的查询,还需要进行额外的chunk分配,因此相应地延长了拥有library
cache锁存器的时间.
对于soft parsing引发的library cache锁存器争用,大致有两种解决方案:
(1)减少parsing次数,最好的方法是一次parsing后执行数次.
(2)利用session_cached_cursors参数.
各种OS在oracle中,防止sga的page out的方法如下:
hp_ux,aix:将lock_sga参数值修改为true(默认值是false)
sunos:确认_use_ism参数值是否是true(默认值是false)
library cache lock,library cache pin
library cache lock:访问或修改库高速缓冲区的对象时,对库高速缓冲区句柄获得的锁.在获得library cache lock的过程中,如果发生争用,则等待library cache lock事件.
library cache pin:对库高速缓冲区对象访问或修改时,对library cache object(LCO)获得锁.library cache pin是在获得library cache lock后,需要对库高速缓冲区对象进行追加工作时获取.
(1)library cache lock和library cache pin等待引起的性能下降现象,大部份是因不适当的ddl引发的.
(2)hard parsing频繁的系统上,也可能出现library cache pin等待.最好的解决方法是恰当地使用bind变量,也可以考虑cursor sharing等方法.
row cache lock
oracle将数据字典信息存于sga内的行高速缓冲区.想要修改数据字典内容的进程,应对其相应的row cache object获得row cache
lock.其中最具代表性的是sequence.
除了sequence之外,几科没有如此频繁地修改行高速缓冲区信息的.因此,出现row cache等待时,需要确认sequence上是否赋予了nocache属性.
enq:sq-contention,dfs lock handle(sv)
row cache lock:在调用sequence.nextval过程中,将数据字典信息进行物理修改时获取.赋予了nocache属性的sequence上发生.sq 锁:在内存上缓存的范围内,调用sequence.nextval期间拥有此锁.赋予了cache属性的sequence上发生.sv锁:rac上节点之 间顺序得到保障的情况下,调用sequence.nextval期间拥有.赋予了cache+order属性的sequence上发生.
创建sequence赋予的cache值较小时,有enq:sq-contention等待增加的趋势.
shared pool 锁存器一般在整个实例上只存在一个(9i之前).
hard parsing严重时,经常发生分割chunk的现象,因此在空闲列上出现许多较小空闲的chunk的现象.这种现象称为共享池的碎片化,延长查询空闲列 的时间.共享池碎片化是引发shared pool锁存器争用的根本原因.ora-4031错误也是由碎片化引发的.
最好的解决方法就是为避免发生hard parsing,恰当使用bind变量.但不容易对动态的应用程序进行修正.
oracle提供了几个解决问题的方法:
(1)oracle 9i以上版本起,共享池分为多个副池,最多由7个副池分别进行管理.
(2)hard parsing引发shared pool锁存器争用时,另外的解决方法是减少共享池大小.但这时发生ora-4031的错误概率高.可以利用dbms_shared_pool.keep ,应用将经常使用的sql cursor,程序包,procedure等永久置于共享池的方法.
(3)提供cursor sharing方法.
latch:library cache
为了执行sql,通过library cache锁存器,保护检索并管理库高速缓冲区的所有工作.library cache锁存器拥有与比cpu count值
大的最小质数值相同数量的子锁存器.
library cahce争用主要在哪下情况下发生:
(1)hard parsing 或soft parsing过多时
(2)version count 高时
(3)sga区域发生pageout时
library cache锁存器争用的最重要原因也是hard parsing.因为检索库高速缓冲区的次数增加,相应地拥有library cache锁存器
的时间和次数会增加;hard parsing时,不仅需要对库高速缓冲区的查询,还需要进行额外的chunk分配,因此相应地延长了拥有library
cache锁存器的时间.
对于soft parsing引发的library cache锁存器争用,大致有两种解决方案:
(1)减少parsing次数,最好的方法是一次parsing后执行数次.
(2)利用session_cached_cursors参数.
各种OS在oracle中,防止sga的page out的方法如下:
hp_ux,aix:将lock_sga参数值修改为true(默认值是false)
sunos:确认_use_ism参数值是否是true(默认值是false)
library cache lock,library cache pin
library cache lock:访问或修改库高速缓冲区的对象时,对库高速缓冲区句柄获得的锁.在获得library cache lock的过程中,如果发生争用,则等待library cache lock事件.
library cache pin:对库高速缓冲区对象访问或修改时,对library cache object(LCO)获得锁.library cache pin是在获得library cache lock后,需要对库高速缓冲区对象进行追加工作时获取.
(1)library cache lock和library cache pin等待引起的性能下降现象,大部份是因不适当的ddl引发的.
(2)hard parsing频繁的系统上,也可能出现library cache pin等待.最好的解决方法是恰当地使用bind变量,也可以考虑cursor sharing等方法.
row cache lock
oracle将数据字典信息存于sga内的行高速缓冲区.想要修改数据字典内容的进程,应对其相应的row cache object获得row cache
lock.其中最具代表性的是sequence.
除了sequence之外,几科没有如此频繁地修改行高速缓冲区信息的.因此,出现row cache等待时,需要确认sequence上是否赋予了nocache属性.
enq:sq-contention,dfs lock handle(sv)
row cache lock:在调用sequence.nextval过程中,将数据字典信息进行物理修改时获取.赋予了nocache属性的sequence上发生.sq 锁:在内存上缓存的范围内,调用sequence.nextval期间拥有此锁.赋予了cache属性的sequence上发生.sv锁:rac上节点之 间顺序得到保障的情况下,调用sequence.nextval期间拥有.赋予了cache+order属性的sequence上发生.
创建sequence赋予的cache值较小时,有enq:sq-contention等待增加的趋势.
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/28539951/viewspace-1264949/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/28539951/viewspace-1264949/