1. Library Cache Mutex等待
库缓存是共享池的一部分，在共享池里有SQL的缓存定义、PL/SQL和JAVA类。对库缓存的修改收到library cache mutex的保护。在Oracle 10gR2之前，它们被library cache latch保护。
用独占模式获取一个library cache mutex最常见的原因是向缓存中添加一个新条目。比如，在我们分析一个新的SQL语句时这将发生。Oracle在缓存中查找一个匹配的条目且没有发现（未命中）时，它获得相关的互斥并且插入一个新的条目。最常见的未命中类型是针对新的SQL语句，尽管也可能涉及PL/SQL块。
在大部分的案例中，library cache mutex之所以争用是因为应用程序没有使用绑定变量因而产生过度的硬解析。
当应用程序使用字面变量而不是绑定变量时，几乎每条SQL语句的执行都会要求一次新的SQL解析。因此，每个SQL的执行都要求得到一个互斥，互斥争用几乎无法避免。这通常表现为library cache: mutex事件上的高等待。
2. Library cache pin
library cache pin严格来说不是一个闩锁或互斥，但是经常在相似的场合出现。只要库缓存中的对象被解析或者重新解析，都需要获得
library cache pin。比如，一个SQL语句的执行计划需要被改变或者一个PL/SQL包被修改或重新编译，library cache pin将会发生。
想要修改对象的会话将试图以独占模式得到library cache pin，执行对象的会话将持有一个共享的library cache pin。
Library cache pin等待经常是由于会话试图修改或者编译一个PL/SQL程序，而这个程序同时正被另外一个会话执行导致的。
3. Shared Pool Latch
Shared pool latch的主要目的是控制对共享池内存映射的的访问。在共享池中，为新的SQL语句或PL/SQL包寻找空闲空间的会话需要得到shared pool latch，
而且许多Oracle内部操作（例如重设共享池大小）也需要获得这些闩锁。
过度的硬解析（library cache mutex争用的主要原因）通常也会导致shared pool latch争用，因为一次性的SQL语句的持续分配会导致共享池的碎片和对老的SQL
语句持续回收。
Shared pool latch争用经常是高的硬解析速率产生的负面影响，并且也指示使用绑定变量或者调整CURSOR_SHARING参数的必要性。
共享池碎片有其他的副作用，包括ORA-04031错误和过度的共享池内存消耗。多年来，我们已经看到了减轻碎片使用的各种各样的技巧。
a. 一些站点定期使用alter system flush shared pool命令刷新共享池。
b. 使用自动SGA内存管理可能会加重碎片问题，因为内存管理算法不能总是预测或度量产生的碎片程度。转换到手动内存管理可以缓解这个问题。
c. 通过阻止大对象换进和换出内存，使用DBMS_SHARED_POOL在共享池中钉住大的但不频繁地执行的PL/SQL包可能帮助减少碎片。
4. Cache Buffers Chains Latch
当会话需要从缓冲区告诉访问一个块时，它必须获得控制缓冲的缓冲链上的cache buffers闩锁。链是散列到一个共同值的少量的块。每个cache buffers chains闩锁
保护许多链。
访问内存中的一个块所消耗的时间数量是很小的，而且有大量的cache buffers chains闩锁。不过，在具有高的逻辑读的系统上，cache buffers chains闩锁
争用可能会很多，特别是当逻辑读集中在少量的块上时。
具有讽刺意味的是，在所有其他地方几乎完美优化的系统上，cache buffers chains闩锁争用也经常发生。为了得到必要的高的逻辑读速率而诱发了cache buffers chains争用，
通常系统需要最小化其他形式的争用和等待，如IO、解析和锁等。
然而，高的逻辑读速率和由此产生的cache buffers chains闩锁争用可能是未调优SQL的结果。例如，一个使用没有选择性的索引的嵌套循环联结多次重复的
扫描内部表上的相同数据块集。然后这些块变为热点，并且成了闩锁争用的对象。通过创建一个更高选择性的索引来调优SQL将减少多余的逻辑读并降低闩锁争用，
以及提高涉及的SQL的性能。
Cache buffers chains闩锁争用与高的逻辑读速率有关，逻辑读集中在相对少的几个块上。通过调优SQL来减少逻辑读速率是减少闩锁争用的一个明智的第一步。
为了减少cache buffers chains闩锁争用，尝试改变索引的选项、把涉及的对象分区或者通过调优针对对象的SQL来减少针对热点对象的逻辑读。
摘自：《Oracle性能优化求生指南》
库缓存是共享池的一部分，在共享池里有SQL的缓存定义、PL/SQL和JAVA类。对库缓存的修改收到library cache mutex的保护。在Oracle 10gR2之前，它们被library cache latch保护。
用独占模式获取一个library cache mutex最常见的原因是向缓存中添加一个新条目。比如，在我们分析一个新的SQL语句时这将发生。Oracle在缓存中查找一个匹配的条目且没有发现（未命中）时，它获得相关的互斥并且插入一个新的条目。最常见的未命中类型是针对新的SQL语句，尽管也可能涉及PL/SQL块。
在大部分的案例中，library cache mutex之所以争用是因为应用程序没有使用绑定变量因而产生过度的硬解析。
当应用程序使用字面变量而不是绑定变量时，几乎每条SQL语句的执行都会要求一次新的SQL解析。因此，每个SQL的执行都要求得到一个互斥，互斥争用几乎无法避免。这通常表现为library cache: mutex事件上的高等待。
2. Library cache pin
library cache pin严格来说不是一个闩锁或互斥，但是经常在相似的场合出现。只要库缓存中的对象被解析或者重新解析，都需要获得
library cache pin。比如，一个SQL语句的执行计划需要被改变或者一个PL/SQL包被修改或重新编译，library cache pin将会发生。
想要修改对象的会话将试图以独占模式得到library cache pin，执行对象的会话将持有一个共享的library cache pin。
Library cache pin等待经常是由于会话试图修改或者编译一个PL/SQL程序，而这个程序同时正被另外一个会话执行导致的。
3. Shared Pool Latch
Shared pool latch的主要目的是控制对共享池内存映射的的访问。在共享池中，为新的SQL语句或PL/SQL包寻找空闲空间的会话需要得到shared pool latch，
而且许多Oracle内部操作（例如重设共享池大小）也需要获得这些闩锁。
过度的硬解析（library cache mutex争用的主要原因）通常也会导致shared pool latch争用，因为一次性的SQL语句的持续分配会导致共享池的碎片和对老的SQL
语句持续回收。
Shared pool latch争用经常是高的硬解析速率产生的负面影响，并且也指示使用绑定变量或者调整CURSOR_SHARING参数的必要性。
共享池碎片有其他的副作用，包括ORA-04031错误和过度的共享池内存消耗。多年来，我们已经看到了减轻碎片使用的各种各样的技巧。
a. 一些站点定期使用alter system flush shared pool命令刷新共享池。
b. 使用自动SGA内存管理可能会加重碎片问题，因为内存管理算法不能总是预测或度量产生的碎片程度。转换到手动内存管理可以缓解这个问题。
c. 通过阻止大对象换进和换出内存，使用DBMS_SHARED_POOL在共享池中钉住大的但不频繁地执行的PL/SQL包可能帮助减少碎片。
4. Cache Buffers Chains Latch
当会话需要从缓冲区告诉访问一个块时，它必须获得控制缓冲的缓冲链上的cache buffers闩锁。链是散列到一个共同值的少量的块。每个cache buffers chains闩锁
保护许多链。
访问内存中的一个块所消耗的时间数量是很小的，而且有大量的cache buffers chains闩锁。不过，在具有高的逻辑读的系统上，cache buffers chains闩锁
争用可能会很多，特别是当逻辑读集中在少量的块上时。
具有讽刺意味的是，在所有其他地方几乎完美优化的系统上，cache buffers chains闩锁争用也经常发生。为了得到必要的高的逻辑读速率而诱发了cache buffers chains争用，
通常系统需要最小化其他形式的争用和等待，如IO、解析和锁等。
然而，高的逻辑读速率和由此产生的cache buffers chains闩锁争用可能是未调优SQL的结果。例如，一个使用没有选择性的索引的嵌套循环联结多次重复的
扫描内部表上的相同数据块集。然后这些块变为热点，并且成了闩锁争用的对象。通过创建一个更高选择性的索引来调优SQL将减少多余的逻辑读并降低闩锁争用，
以及提高涉及的SQL的性能。
Cache buffers chains闩锁争用与高的逻辑读速率有关，逻辑读集中在相对少的几个块上。通过调优SQL来减少逻辑读速率是减少闩锁争用的一个明智的第一步。
为了减少cache buffers chains闩锁争用，尝试改变索引的选项、把涉及的对象分区或者通过调优针对对象的SQL来减少针对热点对象的逻辑读。
摘自：《Oracle性能优化求生指南》
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8520577/viewspace-1662269/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/8520577/viewspace-1662269/
510
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
