在 Oracle 共享池（Shared Pool）中，Library Cache 是 SQL、PL/SQL、對象元數據等最核心的組件之一。當系統出現明顯的 library cache lock 等待 時，通常意味著：

共享池中的對象訪問、解析、失效或并發控制已經成為系統瓶頸。

本文從 內部原理 → 常見成因 → 定位方法 → 對應解決方案 → 風險評估 的角度，對 library cache lock 等待進行一次完整拆解。

一、Shared Pool 與 Library Cache Lock 的作用機制

共享池主要包含以下內容：

• Library Cache
• Data Dictionary Cache
• SQL Query Result Cache
• PL/SQL Function Result Cache
• Buffers for parallel execution messages
• Control structures

1. Library Cache Lock 的本質

library cache lock 用于控制多個客戶端（Session）對同一對象的并發訪問，它是：

• 在 對象句柄（object handle） 上獲取的鎖
• 用于保證：
  1. 某一時刻只有合法的訪問者可以操作對象
  2. 對象在被依賴期間不被修改

其獲取過程包括：

1. 獲取 library cache 子鎖，掃描對象句柄列表
2. 找到目標對象后，在句柄上放置 library cache lock

2. 它意味著什么？

• 一個 Session 正在：
  • 解析 SQL
  • 編譯對象
  • 執行依賴對象的 PL/SQL
• 另一個 Session 想：
  • 使用同一對象
  • 修改 / 失效該對象

此時就會產生 library cache lock 等待。

二、如何在報告中識別

library cache lock

1. TKProf

• Overall wait event summary
  • non-recursive / recursive statements
  • library cache lock 等待時間顯著

2. AWR / Statspack

• Top Wait Events 中出現：
  • library cache lock
• Library Cache Statistics 異常

三、常見成因一：SQL 因文字值無法共享（硬解析）

問題描述

SQL 本可使用綁定變量，卻使用了字面量（literal），導致：

• SQL 無法共享
• 每次執行都觸發 硬解析
• 頻繁獲取 library cache lock

定位方法

TKProf：

• 按 parse time 排序
• 檢查：
  • Misses in library cache ≈ Parse count
• 查找 SQL 中是否存在大量文字值

解決方案

重寫 SQL，使用綁定變量

優點：

• 顯著提升 SQL 共享率
• 降低硬解析與 library cache 爭用

代價與風險：

• 費勁程度：中 / 高
• 風險：中
  • 可能影響執行計劃
  • 必須充分測試

驗證方式

• 實施后重新分析：
  • AWR
  • TKProf
• 若無改善：
  • 重新確認是否為主要原因

四、常見成因二：共享池過小，已共享 SQL 被刷出

問題描述

• Shared Pool 太小
• 可共享 SQL 被頻繁老化
• 再次執行 → 硬解析 → library cache lock

定位方法

AWR / Statspack：

• Library Cache Statistics：
  • Reloads 很高（每小時幾千）
  • Invalidations 很少
• % SQL with executions > 1 > 60%

解決方案一：增大 Shared Pool

• 費勁程度：低
• 風險：低
  • 除非物理內存不足

解決方案二（10g+）：啟用 ASMM

• 設置：
  • SGA_TARGET
  • SGA_MAX_SIZE
• 自動調節共享池大小

解決方案三：Pin 關鍵對象

• 使用：

DBMS_SHARED_POOL.KEEP()

• 保留：
  • 大型
  • 高頻使用
  • PL/SQL / Cursor

風險：

• 中度風險
• 過度 pin 可能引發 ORA-4031

五、常見成因三：Library Cache 對象失效（DDL / 統計信息）

1. DDL 導致失效

• CREATE / ALTER / DROP
• 級聯失效依賴游標
• 引發大量硬解析

解決方案：

• 避免在繁忙期執行 DDL
• 安排到維護窗口

2. 收集優化器統計信息

• ANALYZE
• DBMS_STATS

影響：

• 對象失效
• 大量硬解析

解決方案：

• 避開高峰期
• 使用 no_invalidate（10g+）

3. TRUNCATE 操作

• 本質是 DDL
• 同樣會引發對象失效

解決方案：

• 延后到低負載時段

六、常見成因四：跨 Session 編譯對象

問題描述

• 一個 Session 編譯對象（PL/SQL）
• 另一個 Session 正在執行 / 解析該對象
• 出現 library cache pin / lock 等待

定位方法

TKProf：

• library cache pin waits
• 伴隨對象編譯行為

解決方案

• 避免并發編譯
• 避免高峰期編譯
• 使用 HangAnalyze 定位阻塞鏈

七、常見成因五：開啟審計（尤其 RAC）

問題描述

• 審計會增加 library cache lock 獲取頻率
• RAC 中影響更明顯（全局資源）

定位方法

• AWR / Statspack：
  • library cache lock waits
• 參數：
  • audit_trail != none

解決方案

• 評估審計必要性
• 非強制合規場景可關閉

風險：

• 低風險
• 但需考慮合規要求

八、常見成因六：RAC 環境中的非共享 SQL

典型特征

• 單實例：表現為 latch 爭用
• RAC：表現為 library cache lock

定位方法

• TKProf：
  • 大量硬解析
• AWR：
  • % SQL with executions > 1 < 60%
  • Soft Parse Ratio < 80%

解決方案一：綁定變量

（同原因一）

解決方案二：CURSOR_SHARING 參數

• EXACT（默認）
• FORCE
• SIMILAR

建議：

• 優先 Session 級設置
• 避免 Instance 級 FORCE

風險：

• 中度風險
• 可能導致執行計劃劣化

九、常見成因七：大量使用行級觸發器

問題描述

• 行級觸發器頻繁觸發
• 每次觸發：
  • 檢查 mutating table
  • 獲取 library cache lock

關鍵點：

觸發頻率比觸發器數量更重要

定位方法

• TKProf：
  • 硬解析多
  • recursive SQL
  • trigger 相關痕跡

解決方案

• 評估是否必須使用行級觸發器
• 設計替代方案

風險：

• 中度風險
• 需充分測試

十、常見成因八：過多的子游標（Version Count）

問題描述

• 單條 SQL 生成大量子游標
• 多 Session 并發創建 → 爭用加劇

定位方法

• AWR：
  • SQL ordered by Version Count
• V$SQLAREA.version_count > 500
• V$SQL_SHARED_CURSOR

常見誘因

• CURSOR_SHARING = SIMILAR
• 范圍謂詞（>、<）導致計劃差異

解決方案選擇

• 重寫 SQL 使用綁定（最佳）
• 或改用 CURSOR_SHARING = FORCE（有風險）

十一、總結：排查

library cache lock

的正確姿勢

一句話原則：

先判斷是不是“非共享 SQL”，再判斷是不是“對象失效或并發編譯”，最后才考慮參數和內存。

實戰順序建議：

1. TKProf 看解析
2. AWR 看共享率 / Reload
3. 排查 DDL / Stats / Compile
4. 再談參數調整

參考文檔

• ‘library cache lock’ Waits: Causes and Solutions

  Doc ID 1952395.1