19c中ddl操作常伴library cache lock等待，是因ddl本身需独占锁，而19c采样机制对高频等待动态提频，并非锁变多；p3=127表明mode=3+namespace=127，多为pl/sql编译卡住，sql_id为空属正常，需结合v$session查sql_text确认。
为什么19c的ASH里DDL操作总带着library cache lock等待
因为19c没改锁机制，只是采样更“勤”——DDL执行本身就要先抢library cache lock（独占模式），而19c对高频等待事件（比如这个）会动态提高采样率。你看到的“大量”，不是锁变多了，是它被ASH捕获得更全了。
常见表现：sql_opname为CREATE、ALTER或DROP的记录，event字段稳定显示library cache lock，且p1text = 'handle address'、p2text = 'lock address'；p3值若为127（即0x7F），说明是mode=3（独占）+ namespace=127（PL/SQL对象），基本锁定是包/过程编译卡住了。
- 别只查
blocking_session非空的行——持锁会话可能state = ON CPU但长时间不动，sql_text里有CREATE OR REPLACE PACKAGE就大概率是它 -
sql_id为空？正常。DDL在parse阶段尚未生成完整sql_id，必须用session_id去v$session查sql_text - RAC环境下必须用
GV$ACTIVE_SESSION_HISTORY，单查V$视图会漏掉其他节点的持锁会话
为什么enq: TX - row lock contention在19c ASH中更容易被捕捉到
不是TX锁变多了，是19c MMNL内部加了“热度感知”逻辑：当某类等待（如enq: TX - row lock contention）在连续5秒内高频出现，后续采样会倾向保留更多该事件样本。这对瞬时锁争用特别敏感——尤其当你只查最近60秒的ASH时，19c的结果比12c更“稠密”，更容易定位到那个正在update同一行的会话。
但要注意：V$ACTIVE_SESSION_HISTORY本身字段没变，SQL写法完全兼容12c，你不需要改任何查询语句。
- 别只盯着
blocking_session——如果它为空，或对应会话在v$session里已是INACTIVE，说明持锁者可能已提交/回滚/崩溃，根本没被采样到 -
SQL*Net message from client持续出现？那不是锁问题，是应用端没发commit，事务空挂着，得看应用日志 - 结合
v$transaction查used_ublk和start_date，确认事务是否真在跑、跑了多久
19c中library cache: mutex X和library cache lock能混着查吗
不能。这是两类完全不同的机制：library cache lock管的是对象定义的并发访问（比如DDL期间不让别人动包），library cache: mutex X管的是共享池中内存结构（比如SQL游标解析时的heap访问）。两者p1/p2/p3含义不同，混查会误导定位。
查library cache: mutex X得看p1text = 'idn'（mutex identifier），不是handle address；它的p2是持有者PID，p3是请求模式，跟lock的参数体系不兼容。
- 用
v$event_name确认参数含义：SELECT parameter1,parameter2,parameter3 FROM v$event_name WHERE name = 'library cache: mutex X' - 如果ASH里同时出现这两个事件，优先排查
library cache lock——它往往是源头，mutex争用常是其副作用 -
library cache pin一般不会单独成等待事件，它依附于lock存在，查lock时顺带看pin状态即可
查完ASH后，怎么快速验证是不是DDL卡住导致的连锁等待
直接查v$db_object_cache里对应对象的locks字段是否>0，比反复扫ASH更快。比如怀疑PKG_TEST被卡住：
SELECT name, type, locks, pins FROM v$db_object_cache
WHERE name = 'PKG_TEST' AND type IN ('PACKAGE', 'PACKAGE BODY');
如果locks > 0且pins = 0，基本就是它在持锁未释放；如果pins > 0但locks = 0，说明锁已释放但pin还在，可能是硬解析卡在heap加载阶段。
- 别依赖
v$session.sql_text——长DDL可能被截断，用v$sqltext.sql_text拼接完整 - 业务高峰期间避免
CREATE OR REPLACE PACKAGE，它不是原子操作：先删旧再建新，中间任何延迟都会挂住lock - 如果必须执行，提前用
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12'抓parse路径，看卡在哪一步
最麻烦的其实是锁持有时间远短于ASH采样周期（1秒）的情况——它可能一闪而过，既不在当前v$session里，也没被ASH捞到。这种时候，dba_hist_active_sess_history里的历史快照反而更可靠，但得确认AWR快照间隔和保留策略是否覆盖问题时段。
