如何分析PLSQL依赖_DBA_DEPENDENCIES视图查询对象关系-Oracle-PHP中文网

首选DBA_DEPENDENCIES因其是Oracle官方维护的实时编译依赖视图，但仅记录编译成功对象的依赖；需过滤STATUS='VALID'及非系统模式，并注意NAME为当前对象、REFERENCED_NAME为所依赖对象，结合REFERENCED_OWNER判别跨schema调用。

查 PL/SQL 对象依赖为什么首选 `DBA_DEPENDENCIES`

因为它是 oracle 官方维护的、实时反映编译时依赖关系的视图，比手工解析源码或查 all_source 更可靠。但要注意：它只记录「编译成功后」的依赖，如果对象失效（status = 'invalid'），依赖可能不全或滞后。

常见错误现象：SELECT * 查出大量 REFERENCED_OWNER 为 SYS 或 PUBLIC 的行，误以为是业务依赖；其实很多是系统包（如 DBMS_OUTPUT）的隐式引用，和实际逻辑无关。

只查有效对象：加 WHERE STATUS = 'VALID' 过滤掉失效依赖
排除系统模式：加 AND OWNER NOT IN ('SYS', 'SYSTEM', 'PUBLIC')
注意 DEPENDENCY_TYPE 字段：值为 'HARD' 才表示强依赖（比如调用函数），'SOFT' 多是动态 SQL 或同义词间接引用，不可靠

`DBA_DEPENDENCIES` 中 `NAME` 和 `REFERENCED_NAME` 到底指什么

NAME 是「当前对象名」，REFERENCED_NAME 是它「依赖的对象名」——顺序不能反。比如一个存储过程 PAY_PROC 调用了函数 GET_TAX_RATE，那这行里 NAME = 'PAY_PROC'，REFERENCED_NAME = 'GET_TAX_RATE'。

容易踩的坑：REFERENCED_NAME 不带 schema，当多个用户有同名对象时，得结合 REFERENCED_OWNER 判断真实目标；而 OWNER 和 NAME 组合才是当前对象的唯一标识。

跨 schema 调用必须显式写 schema.package_name，否则 Oracle 默认找当前用户下的同名对象
同义词（SYNONYM）在依赖中显示的是原对象名，不是同义词名；查依赖前先确认 REFERENCED_TYPE = 'SYNONYM' 的行是否已解析到底层
包体（PACKAGE BODY）依赖的是包规范（PACKAGE）里的声明，不是包体自身，所以 TYPE = 'PACKAGE BODY' 的行里 REFERENCED_TYPE 很可能是 'PACKAGE'

递归查完整调用链：别直接用 CONNECT BY 硬套

想查「A → B → C → D」这种链路，CONNECT BY 看起来方便，但 Oracle 的 DBA_DEPENDENCIES 不保证依赖方向完全可逆，且存在循环引用（比如 A 调 B，B 又调 A）时会报 ORA-01436: CONNECT BY loop in user data。

更稳妥的做法是分步 + 过滤：

先限定起点：比如 WHERE OWNER = 'HR' AND NAME = 'CALC_SALARY'
加层级限制：LEVEL 防止无限递归
用 NOCYCLE 关键字容错（Oracle 10g+），并检查 CONNECT_BY_ISCYCLE 字段标记循环点
避免查到 TYPE IN ('TRIGGER', 'VIEW') 这类间接依赖——它们常引发意外分支，业务上通常不关心

示例片段：

SELECT LEVEL, OWNER, NAME, REFERENCED_OWNER, REFERENCED_NAME
FROM DBA_DEPENDENCIES
WHERE REFERENCED_OWNER NOT IN ('SYS','SYSTEM')
START WITH OWNER = 'HR' AND NAME = 'CALC_SALARY'
CONNECT BY NOCYCLE PRIOR REFERENCED_OWNER = OWNER
  AND PRIOR REFERENCED_NAME = NAME
  AND LEVEL 

<h3>依赖没更新？先确认对象是否真的重新编译过</h3>
<p><code>DBA_DEPENDENCIES</code> 不是实时监听器，它只在对象被 <code>CREATE</code> / <code>ALTER</code> / <code>REPLACE</code> 并**成功编译**后刷新。如果改了包体但忘记执行 <code>ALTER PACKAGE xxx COMPILE BODY</code>，或者编译失败（<code>SHOW ERRORS</code> 有报错），依赖关系就不会变。</p>
<p>典型场景：开发改完 <code>pkg_util</code> 包体，测试发现调用它的过程 <code>proc_main</code> 没生效——很可能 <code>proc_main</code> 还依赖旧版 <code>pkg_util</code>，因为没重新编译它自己。</p>