Library Cache Load Lock
The session tries to find the load lock for the database object so that it can load the object.
The load lock is always obtained in Exclusive mode. Thus, other process can load the same object. 能还是不能？应该时不能同时
The session will wait on this event until the lock becomes available if the load lock is busy.
Tuning the Library Cache Load Lock
Library cache load lock is due to objects not being in the memory. This may be due to undersized shared pool, sqls not being
shared, or lot of hard parsing. For further information on how to tune library cache load lock, review following note under
how can library cache load lock be reduced:
Library Cache Load Lock
Generally, the Library cache lock is held up during parsing of the sql and the lock is held up on the object（sql还是其中的表？） in shared mode and released after the parse. This is the expected behaviour.
Mostly, The Library cache lock would not be held up in the execution phase.
Example: A query with joins going for merge join cartesian taking long time in execution would not block others with Library cache lock. Because Library cache lock would have been released after the parse.
This is the behaviour of Library cache lock.
从这个BUG 可以看出lock 和pin是可能死锁的
Related To:
- Excessive CPU Usage
- Deadlock
- Hang (Process Hang)
- Mutex Contention
- Waits for "cursor: pin S wait on X"
- Waits for "library cache lock"
(None Specified)
Details
A deadlock may be seen involving library cache locks on dictionary objects and other resources. eg: SYS.USER$ Rediscovery Notes If you encounter a deadlock that involves library cache objects on SYS dictionary objects, you may be hitting this problem. A wait chain is likely to show a cyclic wait (deadlock) involving 'cursor: pin S wait on X' and 'library cache lock' waits Workaround None
---并行导致
Database hangs periodically with many sessions being blocked by each other, deadlocks can be seen as well, with different waits such as 'cursor: pin S wait on X', 'row cache lock' and 'library cache load lock'.
'Row cache lock' can be on different dictionary cache areas. In this case, they were ondc_objects and dc_histogram_defs.（管理dictionary cache 的表 因为ibrary cache 需要lock时要查看依赖对象的信息**）**
问题确认：
- 等待"库缓存加载锁定"是整体数据库时间的重要组成部分
- 整体性能问题可能会被发现
- 高CPU和"库缓存负载锁定"可能很重要
- "库缓存针PIN"等待也可能与"库缓存加载锁"一起出现
库缓存加载锁定
会话尝试获取数据库对象的库缓存加载锁，以便将其加载到库缓存中。当一个会话经历这种锁定时，另一个会话对同一**对象（这个对象是table 还是sql cursor之类的运行程序呢？）**进行了负载锁定。没有其他进程能将相同对象加载到库缓存中，因为加载锁总是在独占模式下实现。---是不是少了同时
减少等待时间
如果对象不在内存中，Oracle 需要将其加载到内存中。检查一下 SQL 是否共享，并且大量硬解析法的数量有限。此外，参数session_cached_cursors可以提高，以防止光标从共享池中被清除。如需更多可能的决心，请查看以下注释：
KB142997 - 库缓存故障排除：锁定、引脚和加载锁定
如果有多个进程想要同一个对象，它们需要等待。确保共享池足够大，可以加载内存中的对象。所以尽量在一天中较少的时间段进行物品维护，比如更改、授予和撤销权限。更多信息可见以下说明：
115656.1 - 关于库缓存引脚和库缓存加载锁的等待场景
衡量成功
在你应用了这些更改来解决你发现的问题后，将最新的AWR与引导你来到这里的AWR进行比较（该AWR成为你的基线）。查看该事件总等待时间减少的百分比。如果仍有问题，重新评估并根据具体症状进行处理。
已知问题
KI4832 - 进程可能在"库缓存加载锁定"时卡住，但没有持有
者 KI5284 - 进程可能会在等待"库缓存加载锁"时卡住，且没有持有者
Summary
Disclaimer: This note is written in the context that the Performance Guided Resolution tool was used and recommended this article. It may not make as much sense if read standalone or by other audiences.
Solution
Brief Definition:
This note covers issues where the Guided Resolution Tool indicates contention where performance issue is noticed due to library cache load lock.
Problem Confirmation:
- Waits for 'library cache load lock' are a significant component of the overall database time
- Overall performance issue may be seen
- High CPU along with 'library cache load lock' may be significant
- 'Library cache pin' wait may also appear along with 'library cache load lock'
Library Cache Load Lock
A session tries to obtain a library cache load lock for a database object so that it can load it into the library cache. When a session is experiencing this form of lock, there is another session that has the load lock for the same object. No other process can load the same object into the library cache, as the load lock is always obtained in exclusive mode.
Reducing Waits
If the object is not in memory, Oracle will need to load it in memory. Check to see if sqls are shared and high number of hard parses are limited. Furthermore, parameter session_cached_cursors can be increased to keeping cursors from being flushed from the shared pool. For more possible resolutions, review following note:
KB142997 - Troubleshooting Library Cache: Lock, Pin and Load Lock
If there are multiple processes wanting the same object, they will need to wait. Make sure the shared pool is large enough to load the object in memory. So try to do object maintenance such as altering, granting, and revoking privileges during the slow time of the day. Further information can be found in following note:
115656.1 - WAIT SCENARIOS REGARDING LIBRARY CACHE PIN AND LIBRARY CACHE LOAD LOCK
Measuring Success
Once you have applied the changes to resolve the issues you have found, compare the latest AWR to the AWR that led you here via Guided Resolution (that AWR becomes your baseline). Look at the percentage decrease total wait time for this event. If there are still issues, re- evaluate those and address them according to the specific symptom.
Known Issues
KI4832 - Process may hang waiting for "library cache load lock" with no holder
KI5284 - Process may hang waiting for "library cache load lock" with no holder
Library Cache Load Lock
The session tries to find the load lock for the database object so that it can load the object.
The load lock is always obtained in Exclusive mode. Thus, other process can load the same object. 能还是不能？应该时不能同时
The session will wait on this event until the lock becomes available if the load lock is busy.
Tuning the Library Cache Load Lock
Library cache load lock is due to objects not being in the memory. This may be due to undersized shared pool, sqls not being
shared, or lot of hard parsing. For further information on how to tune library cache load lock, review following note under
how can library cache load lock be reduced:
Library Cache Load Lock
Generally, the Library cache lock is held up during parsing of the sql and the lock is held up on the object（sql还是其中的表？） in shared mode and released after the parse. This is the expected behaviour.
Mostly, The Library cache lock would not be held up in the execution phase.
Example: A query with joins going for merge join cartesian taking long time in execution would not block others with Library cache lock. Because Library cache lock would have been released after the parse.
This is the behaviour of Library cache lock.
Solution
Brief Definition:
This note covers issues where the Guided Resolution Tool indicates contention as a result "library cache pins" or "Cursor Pin S wait on X".
In 10g and later, library cache pins are replaced by mutexes. So library cache pins and Pin S wait on X are similar waits but different names for different versions.
Problem Confirmation:
- Library cache pin for pre 10g may be significant
- Cursor: Pin S wait on X may be significant on 10g and later
- High CPU with per above waits
Library Cache Pin
Library cache pin deals with concurrent wait for library cache. When a pin is acquired, it causes the object's (这里ojbect 代表sql 之类吧)heap to be loaded into memory if it is not already there. A wait for a "library cache pin" implies some other session holds that PIN in an incompatible mode. For example, if an object structure（这里是表之类） is changed such as dropping a column, it will cause library cache pin wait and implies it is held in exclusive mode.
（pin表示我要在memory改动对象了，帮我把对象先pin住再load进内存， lock就是你要pin住，那我先看看相关的对象在不在使用，如果发现了对象在parse或者运行，就要尝试lock住。
从下文可知，pin是shared 而lock 是exclusived）
So be careful when changing the structure of an object and try to do it during slow time of the day. For more information on scenarios of library cache pin, review the following note:
<Note:115656.1> WAIT SCENARIOS REGARDING LIBRARY CACHE PIN AND LIBRARY CACHE LOAD LOCK
Cursor Pin S wait on X
Mutex wait is similar to library cache pin wait but was introduced for 11g. A session waits for "cursor: pin S wait on X" when it wants a mutex in S (share) mode on a specific cursor（这里不说object） but some other session holds that same mutex in X (exclusive) mode. 也就是说pin是需要shared
Hence the current session has to wait for the X mode holder to release the mutex.
Improving Performance of Library cache pin or Pin S wait on X
The library cache pin wait often happens when you are compiling or parsing a PL/SQL object（不带pl/sql 是不是就是普通对象，类似表 ） or a view.
Recompilation may be due to invalidations. Invalidations are usually due to ddls. 有没有例外
So check for ddls at the time of the issue. For further information, review following note:
<Note:444560.1> Troubleshooting Library Cache: Load,Lock, and Pin Lock
Pin S wait on X is usually due to high parses（这个意思是ibrary cache pin只要有就会存在，但是pin s wait x是hard parse太多导致的）. So check for high parsing sqls （这个说明sql是shared的，但是因为对象改动导致的）or tune application to share cursors（这个说明是sql不同，尝试修改成变量）
----如果sql 不同，那肯定就是sql hash value不一样，这时还需要pin，说明pin的是其SQL内包含的object
. For further diagnosis, please review following note:
<Note:1349387.1> Troubleshooting 'Cursor: Pin S wait on X' wait
--------------------例子
Summary
-
The DB is experiencing performance issue with high library cache locks from AWR report:Top 10 Foreground Events by Total Wait Time
Event Waits Total Wait Time (sec) Wait Avg(ms) % DB time Wait Class
library cache lock 1,320,245 15.4K 11.68 61.0 Concurrency
cursor: pin S wait on X 1,209,204 3547.2 2.93 14.0 Concurrency
library cache: mutex X 1,160,748 2572.2 2.22 10.2 Concurrency -
The following recursive sql is taking high parse time:a6r5q9yqaqabs select obj#, name, stab#, sobj#, sobjd#, ttab#, tobj#, tobjd#, mflags from rmtab$ where (stab# = :1 or ttab# = :1) order by obj#
SQL ordered by Parse Calls
Total Parse Calls: 113,613
Captured SQL account for 38.0% of TotalParse Calls Executions % Total Parses SQL Id SQL Module PDB Name SQL Text
42,63042,630 37.52 a6r5q9yqaqabs PDB_PRODHIM select obj#, name, stab#, sobj... <<<<<<<<<<< High No of executions
--------------------------
Measuring Success
Once you have applied the changes to resolve the issues you have found, compare the latest AWR to the AWR that led you here via Guided Resolution (that AWR becomes your baseline). Look at the percentage decrease total wait time for this event. If there are still issues, re- evaluate those and address them according to the specific symptom.
-----------pin /lock 的--ojbect ---------------------------------
Summary
This Document discusses library cache locks and pins and how to analyze locking problems in this area.
Solution
Why does ORA-4021 error occur?
Oracle instance contains a cache that holds the definitions of each different type of objects e.g. cursors, indexes, tables, views, procedures, etc. This cache is called the library cache and contains a 'library' of object definitions. While these objects are in use, these definitions cannot be changed. They are protected by a series of locks and pins called library cache locks and pins.
A session that needs to use an object will first attempt to acquire a library lock in a certain mode on the object (null, shared or exclusive). If it gets the library cache lock, this will prevent other sessions from modifying it (e.g. an exclusive lock will be taken when recompiling a package or view). If the lock is not available, it will wait until it can get it (i.e. when another session has stopped using it). Locking an object is the first step and is essentially the task of locating the object in the library cache and then lock it in a certain mode. If the session wants to modify or examine the object, it must also acquire a pin in a certain mode (again null, shared or exclusive) after the lock has been taken.
Each SQL statement that wants to use/modify objects that are already locked or pinned (and whose lock/pin mode is incompatible with the requested mode), will wait on events like 'library cache pin' or 'library cache lock' until it is freed, and it can get the lock. If it waits longer than a pre-defined threshold, a timeout occurs. This is done to free up resources in the waiting session that might be blocking other sessions rather than having a series of sessions that cannot move.
If it times out, then a ORA-4021 error is raised:
ORA-04021 timeout occurred while waiting to lock object %s%s%s%s%s.
Cause: While trying to lock a library object, a time-out occurred.
Action: Retry the operation later.
The timeout normally occurs after 5 minutes.
It is also possible for a library cache deadlock to occur. This is a similar situation to the above except that in this case the holder is also waiting for the waiter. In most cases this is automatically detected and a ORA-4020 is returned (in the same way as an ORA-00060 error is raised fro an application deadlock):
ORA-04020 deadlock detected while trying to lock object %s%s%s%s%s
Cause: While trying to lock a library object, a deadlock is detected.
Action: Retry the operation later.
For more about library cache deadlocks, see the following Document
KB111877 - ORA-04020 Deadlocks Most Common Causes
Which views can be used to detect library locking problems?
There are a number of different views that are useful for the detection of pins/locks:
DBA_KGLLOCK : one row for each lock or pin of the instance
-KGLLKUSE session address
-KGLLKHDL Pin/Lock handle
-KGLLKMOD/KGLLKREQ Holding/requested mode
0 no lock/pin held
1 null mode
2 share mode
3 exclusive mode
-KGLLKTYPE Pin/Lock
(created via the $ORACLE_HOME/rdbms/admin/catblock.sql)
V$ACCESS : one row for each object locked by any user
-SID session sid
-OWNER username
-OBJECT object name
-TYPE object type
V$DB_OBJECT_CACHE : one row for each object in the library cache
-OWNER object owner
-NAME object name or cursor text
-TYPE object type
-LOCKS number of locks on this object
-PINS number of pins on this object
DBA_DDL_LOCKS : one row for each object that is locked (exception made of the cursors)
-SESSION_ID
-OWNER
-NAME
-TYPE
-MODE_HELD
-MODE_REQUESTED
V$SESSION_WAIT : each session waiting on a library cache pin or lock is blocked by some other session
-p1 = object address
-p2 = lock/pin address
How to find out why an ORA-4021 occurs?
If possible and reproducible to execute a statement that generates a ORA-4021 error, you can find out more information as to the reason for the blocking situation by running the query below in the 5 minute wait period before the error appears (i.e. when it is waiting):
NOTE: You need to run the script called "catblock.sql" first. This script can be found in: $ORACLE_HOME/rdbms/admin/catblock.sql
select /*+ ordered */ w1.sid waiting_session,
h1.sid holding_session,
w.kgllktype lock_or_pin,
w.kgllkhdl address,
decode(h.kgllkmod, 0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
'Unknown') mode_held,
decode(w.kgllkreq, 0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
'Unknown') mode_requested
from dba_kgllock w, dba_kgllock h, v$session w1, v$session h1
where
(((h.kgllkmod != 0) and (h.kgllkmod != 1)
and ((h.kgllkreq = 0) or (h.kgllkreq = 1)))
and
(((w.kgllkmod = 0) or (w.kgllkmod= 1))
and ((w.kgllkreq != 0) and (w.kgllkreq != 1))))
and w.kgllktype = h.kgllktype
and w.kgllkhdl = h.kgllkhdl
and w.kgllkuse = w1.saddr
and h.kgllkuse = h1.saddr
/The results will be similar to the following:
WAITING_SESSION HOLDING_SESSION LOCK ADDRESS MODE_HELD MODE_REQU
--------------- --------------- ---- -------- --------- ---------
16 12 Pin 03FA2270 Share ExclusiveThe object that is locked can be found with a query against v$object_dependency and should be the same object as mentioned in the ORA-4021 error message.
e.g.
select to_name from v$object_dependency where to_address = '03FA2270';
for a query returning:
ORA-04021 timeout occurred while waiting to lock object DBMS_PIPE
should give:
TO_NAME
DBMS_PIPE
You can find which library objects are used by each session by running the following queries, e.g.
-
for the blocked session (waiter):
select distinct kglnaobj from x$kgllk where
kgllkuse in (select saddr from v$session where sid = 16);
-
for the blocking session (holder
select distinct kglnaobj from x$kgllk where
kgllkuse in (select saddr from v$session where sid = 12);
One of the objects will be the cursor or statement that each session is executing/trying to execute.
You can also use the $ORACLE_HOME/rdbms/admin/utldtree.sql utility to find out what the dependency tree looks like and which objects are dependent on which other objects. One of those objects will be the sql statement of the holding session. A variant on utldtree.sql can be found in the following document and provides the objects tha a particular object depends on:
KB118825 - Script To List Recursive Dependency Between Objects
What type of objects can be locked in a library cache?
Following list give all objects that can be locked in the library cache:
-
CURSOR
-
INDEX
-
TABLE
-
CLUSTER
-
VIEW
-
SYNONYM
-
SEQUENCE
-
PROCEDURE
-
FUNCTION
-
PACKAGE
-
PACKAGE BODY
-
TRIGGER
-
TYPE
-
TYPE BODY
-
OBJECT
-
USER
-
DBLINK
-
PIPE
-
TABLE PARTITION
-
INDEX PARTITION
-
LOB
-
LIBRARY
-
DIRECTORY
-
QUEUE
-
INDEX-ORGANIZED TABLE
-
REPLICATION OBJECT GROUP
-
REPLICATION PROPAGATOR
Which lock/pin mode is required for which type of action?
- All DDL operations (For example, when a package is recompiled, when a grant is given on an object, a truncate on a table, etc.) require a exclusive lock and pin on the object that needs to be processed. The DDL cursors themselves require a null lock (localization job in library cache) and an exclusive pin when executing.
- All operations that use an objects (e.g. when a view is used, when a procedure is executed, etc.) require a null lock and shared pin on those objects. This is also applicable for all dependent objects (e.g. view based on another view, package using another package or view).
- Query and DML cursors requires a null lock and shared pin when executing.
The locks/pins are held for the duration of the SQL statement, and released at the end of it.
Common ora-4021 and ora-4020 situations
If using DBMS_SQL for DDL or 'execute immediate' operations, be sure the DDL does not affect objects that currently have other operations running against them or that the operation is directly dependent on. For example, if you grant a privilege on a procedure that is being executed, then this will result in a ORA-4020 deadlock because the grant session needs to lock and pin the objects. But it cannot due to the conflicting locks that exist for the duration of the execution (assuming that the execution does not complete in the mean time). Another example is when dropping a user. Most likely a user has locked that object. Try the operation again or kill the session holding that object.
Known issues:
KB114108 - While Dropping a User, receive: Ora-04021: Timeout Occurred While Waiting To Lock Object SYS.DBMS_PIPE
KI52920 - Bug 9278979 - Instance hang / ORA-4021 with OPTIMIZER_USE_PENDING_STATISTICS = true