Share pool由library cache、data dictionary cache、result cache、enqueues、latches等組成;
其中：
library cache：
An area of memory in the shared pool. This cache includes the shared SQL areas, private SQL areas (in a shared server configuration), PL/SQL procedures and packages, and control structures such as locks and library cache handles.
用於保存最近解析過的SQL語句、PL/SQL過程等。
Oracle在執行一條SQL語句、一段PL/SQL過程前首先在library cache中搜索，如果搜索到完全匹配的，就利用library cache中的解析結果和執行計劃來執行，而不必重新對它們進行解析。
data dictionary cache:
A memory area in the shared pool that holds data dictionary information. The data dictionary cache is also known as the row cache because it holds data as rows instead of buffers, which hold entire data blocks.
用於存儲經常使用的數據字典信息。比如（表的定義、用戶名、口令、權限、數據庫的結構等）。
Oracle運行過程中經常訪問該緩存以便解析SQL語句，確定操作的對象是否存在，是否具有權限等。如果不在數據字典緩存中，服務器進程就從保存數據字典信息的數據文件中將其讀入到數據字典緩存中。
區別於其他buffer(比如db buffer)，data dictionary cache是按行緩存而不是緩存整個data block
常見的等待事件中，
涉及到library cache的有library cache pin、library cache lock
涉及到data dictionary cache的有row cache lock
下面我們就主要說一下row cache lock
關於V$ROWCACHE
row cache lock等待事件是一個共享池相關的等待事件，是由於對字典緩衝的訪問造成的。每一個行緩衝隊列鎖都對應一個特定的數據字典對象，這被叫做隊列鎖類型，並可以在V$ROWCACHE視圖中找到。在AWR中需要查看Dictionary Cache Stats部分用以確定問題。
For each enqueue type, there are a limited number of operations that require each enqueue. The enqueue type therefore may give an indication as the type of operation that may be causing the issue. As such some common reasons are outlined below:
DC_TABLESPACES
Probably the most likely cause is the allocation of new extents. If extent sizes are set low then the application may constantly be requesting new extents and causing contention. Do you have objects with small extent sizes that are rapidly growing? (You may be able to spot these by looking for objects with large numbers of extents). Check the trace for insert/update activity, check the objects inserted into for number of extents.
DC_SEQUENCES
Check for appropriate caching of sequences for the application requirements.
DC_USERS
Deadlock and resulting “WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!” can occur if a session issues a GRANT to a user, and that user is in the process of logging on to the database.
DC_SEGMENTS
This is likely to be down to segment allocation. Identify what the session holding the enqueue is doing and use errorstacks to diagnose.
DB_ROLLBACK_SEGMENTS
This is due to rollback segment allocation. Just like dc_segments,identify what is holding the enqueue and also generate errorstacks. Remember that on a multi-node system (RAC) the holder may be on another node and so multiple systemstates from each node will be required.
DC_AWR_CONTROL
This enqueue is related to control of the Automatic Workload Repository. As such any operation manipulating the repository may hold this so look for processes blocking these.
遇到該等待事件的排查思路：
1.確定p1、p2、p3的值
SQL> select p1text,p1,p2text,p2,p3text,p3 from v$session where event='row cache lock';
(也可以通過其他路徑獲取到p1、p2、p3的值比如v$active_session_history)
2.確定隊列鎖類型
SQL> select parameter,count,gets,getmisses,modifications from v$rowcache where cache#=:p1;
3.參考隊列鎖類型、隊列鎖結合AWR分析問題的原因
It is important to determine which cache is being waited for. The V$ROWCACHE view gives an overview of which caches are being used most, but the waits may not necessarily be on the most used cache. The V$ACTIVE_SESSION_HISTORY view can be used to get an idea of which cache ids (P1) are involved in waits.
- If the issue is general across various caches (different cache ids) then the shared pool may need increasing in size to allow more dictionary information to be cached
- If the issue is focused on a specific cache id then options typically depend on the cache involved
這篇文章大家可以參考一下(http://blog.itpub.net/26736162/viewspace-2139754/)