Troubleshooting 'library cache: mutex X' Waits.

What is a ‘library cache: mutex X‘ wait?

The mutex feature is a mechanism to control access to in memory structures. It is used in a number of areas including the library cache.

The library cache is a memory area that holds parsed cursor structures needed to execute SQL.

Waits for ‘library cache: mutex X‘ are similar to a library cache waits in earlier versions.  ‘library cache: mutex X‘ may be caused by many issues (including application issues, lack of sharing resulting in high version counts etc.) but essentially something is holding the mutex for "too long" such that other session have to wait for the resource.  If there is contention on the latches/mutexes that protect the library cache structures this means that there is stress on the parsing system. Parsing of SQL takes longer because it cannot get the resources they need. This delays other operations and generally slows the system.

Because of the varied causes, it is important to find the correct cause; so that the right solution can be implemented.

What causes ‘library cache: mutex X‘ wait?

    • Frequent Hard Parses - If the frequency of Hard Parsing is extremely high, then contention can occur on this pin.
    • High Version Counts - When Version counts become excessive, a long chain of versions needs to be examined and this can lead to contention on this event
    • Invalidations - An invalidation is a measure of the number of times a cached cursor is deleted from the cache because it is no longer valid. A cursor is invalidated because something has changed such that the copy of the cursor in memory is not valid any more. For example, regathering the statistics on an object or modifying a table definition is enough to invalidate a cursor for a query that is based on that object. When a cursor is invalidated, any sessions wanting to use the cursor need to wait for a valid version to be loaded. If there is excessive or unnecessary invalidation then significant waits for ‘library cache: mutex X‘ can be seen.
    • Reloads - Reload is a count of the number of times a cursor that previously existed in the cache, was searched for, found to not be there (because it had aged out etc) and then had to be re-compiled and re-loaded in to the library cache. High reloads are a bad thing because they indicate that you are doing work that you would not have had to do if your cache was setup appropriately so as not to remove the cursor in the first place. If a cursor is being reloaded then it cannot be grabbed for work by a session and this can lead to waits for ‘library cache: mutex X‘.
    • Known Bugs

Troubleshooting 'library cache: mutex X' Waits.

时间: 2024-10-21 20:05:49

Troubleshooting 'library cache: mutex X' Waits.的相关文章

Troubleshooting 'library cache: mutex X' waits. (文档 ID 1357946.1)

In this Document   Purpose   Troubleshooting Steps   What is a 'library cache: mutex X' wait?   What causes 'library cache: mutex X' wait?   How to diagnose the cause.   How to Examine the Diagnostics.   Potential Solutions   References APPLIES TO: O

WAITEVENT: "library cache: mutex X" (文档 ID 727400.1)

WAITEVENT: "library cache: mutex X" (文档 ID 727400.1) 2014-01-19 09:56 2367人阅读 评论(0) 收藏 举报  分类: 网络资源_ORACLE_调优(108)  目录(?)[-] APPLIES TO PURPOSE SCOPE DETAILS Definition Individual Waits Systemwide Waits Wait Time Reducing Waits Wait times Known

Oracle数据库大量library cache: mutex X及latch: shared pool问题排查一例

业务系统数据库夯住,数据库内大量的library cache: mutex X及latch: shared pool等待,alert日志信息如下 Tue Sep 26 22:10:04 2017 WARNING: inbound connection timed out (ORA-3136) Tue Sep 26 22:10:04 2017 WARNING: inbound connection timed out (ORA-3136) Tue Sep 26 22:10:04 2017 WARN

Oracle Library Cache深入解析

Oracle Library Cache深入解析 每一个进入库缓存的对象,在库缓存中都被按照本身内容分割成多块进行存贮.Oracle这样做的目的是为了更灵活的内存管理,因为在内存寻找大块连续的内存,总比寻找小块连续内存更慢一些.如果一个库缓存对象(如一条SQL语句的执行计划),它所占的内存被切割成4个小块,它们分别被存放在库缓存的各处,并且互不相连.为了将这4个小块组合起来,Oracle另外这个库缓存对象分配一小块内存,这块内存中存有其他4个小块内存的地址,并且,还有一些有关此库缓存对象的基本信

遇到Library cache load lock 等待事件

遇到Library cache load lock 等待事件: 在Troubleshooting Library Cache: Lock, Pin and Load Lock (Doc ID 444560.1)这篇文章中,详细解释了该等待事件: If an object is not in memory, then a library cache lock cannot be acquired on it. The object has to be loaded into the memory

关于cursor: pin S wait on X 和 library cache pin 及其他等待事件

cursor: pin S wait on X 也好,library cache pin 也罢,这都是shared pool 的等待事件,关于此类的等待事件,阅读的书有:<<oracle 内核技术揭秘>>,<<高级owi与oracle性能调整>> 其中,<<oracle 内核技术揭秘>> 是吕海波大师所著,吕大师也是我的OCM培训老师,在此向吕大师致敬. <<高级owi与oracle性能调整>> 是Oracle

如何简单阅读library cache dump

源起于对实例的systemdump分析,现把library cache dump的部分单拿出来,做个简单的猜想. [email protected] SQL>col KGLNAOBJ for a40 [email protected] SQL>set line 123 [email protected] SQL>select * from scott.dept;       DEPTNODNAME          LOC ---------- -------------- ------

[转载】&mdash;&mdash;故障排除:Shared Pool优化和Library Cache Latch冲突优化 (文档 ID 1523934.1)

原文链接:https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=181268979889050&id=62143.1&displayIndex=5&_afrWindowMode=0&_adf.ctrl-state=177vgme69e_105#aref_section212用途   提出问题,得到帮助并分享您的心得   排错步骤   什么是shared pool?   专用术语   Literal S

Library cache lock/pin详解

Library cache lock/pin 一.概述 ---本文是网络资料加metalink 等整理得来一个实例中的library cache包括了不同类型对象的描述,如:游标,索引,表,视图,过程,等等. 这些对象不能在他们被使用的时候改变,他们在被使用的时候会被一种library locks and pins的机制锁住. 一个会话中,需要使用一个对象,会在该对象上先得到一个library lock(null, shared or exclusive模式的)这是为了,防止其他会话也访问这个对