同义词本身不直接导致解析等待，但其指向的对象权限缺失、不存在或DB Link解析失败会触发硬解析及递归SQL，引发library cache lock或row cache lock等待；需通过ASH中in_hard_parse='Y'定位会话并检查SQL文本是否引用同义词，再验证同义词定义、目标对象存在性及用户权限。
同义词本身不直接导致解析等待，但当它指向的对象权限缺失、对象不存在或跨数据库链接（DB Link）解析失败时，会强制触发硬解析甚至递归SQL，进而堆积 library cache lock 或 row cache lock 等等待。ASH 能抓到这些“被拖住”的会话，但关键在识别背后是同义词路径引发的解析链。
查 in_hard_parse = 'Y' 且关联同义词访问的会话
同义词问题往往藏在解析阶段，而非执行阶段。先锁定正在硬解析的会话，再反查其 SQL 是否引用了同义词：
- 用
in_hard_parse = 'Y'过滤v$active_session_history，避免被普通执行干扰 - 必须关联
sql_id到dba_hist_sqltext或v$sql，看原始语句里是否含SELECT * FROM my_syn这类写法 - 注意：
current_obj#在解析阶段可能为 0 或无效值，不能靠它定位同义词对象——要查的是 SQL 文本本身 - 示例查询：
SELECT sql_id, sample_time, event, p1text, p1 FROM v$active_session_history WHERE in_hard_parse = 'Y' AND sample_time > SYSDATE - 1/1440 AND sql_id IN ( SELECT sql_id FROM v$sql WHERE sql_text LIKE '%my_syn%' );
验证同义词定义与目标对象状态
即使 SQL 用了同义词，真正卡住的常是解析目标对象不可用。需人工确认三层关系：
- 执行
SELECT * FROM dba_synonyms WHERE synonym_name = 'MY_SYN'，确认table_owner和table_name正确，且db_link（如有）存在且可连通 - 检查目标对象是否存在：
SELECT owner, object_type FROM dba_objects WHERE owner = 'TARGET_OWNER' AND object_name = 'TARGET_TABLE'；若返回空，说明同义词指向了不存在的对象，每次访问都会触发硬解析+字典查询失败 - 验证当前用户对目标对象是否有权限：
SELECT * FROM dba_tab_privs WHERE table_name = 'TARGET_TABLE' AND grantee = 'CURRENT_USER'；缺少 SELECT 权限时，Oracle 会在解析时反复检查数据字典，引发row cache lock
区分同义词 vs 普通对象解析瓶颈
同义词引发的解析问题有典型特征，和普通 SQL 绑定变量缺失不同：
- 等待事件集中于
row cache lock（尤其dc_users、dc_objects）或library cache lock，而不是latch: library cache -
v$active_session_history中同一sql_id的current_obj#值频繁变化或为 0，说明 Oracle 还没确定最终对象 - 若同义词指向 DB Link，
event可能出现SQL*Net message to dblink长等待，且sql_id对应的原始语句中带@符号 - 性能影响是“偶发性卡顿”，不是持续高 CPU——因为只在首次解析或对象元数据变更后才触发
最易忽略的一点：同义词解析失败不会报 ORA-00942（表或视图不存在），而是静默降级为硬解析+重试，直到超时或锁争用爆发。所以不能只盯错误日志，得从 ASH 里捞出那些 in_hard_parse = 'Y' 且 event 是字典相关锁的会话，再倒查 SQL 文本。
