查pl/sql依赖首选dba_dependencies视图，但必须加where status='valid'过滤失效对象、and owner not in ('sys','system','public')排除系统模式、and dependency_type='hard'确保强依赖，并注意name为当前对象、referenced_name为所依赖对象。
查 PL/SQL 存储过程依赖，直接查 DBA_DEPENDENCIES 视图最可靠，但必须加过滤条件，否则结果里混着大量系统包和失效对象，根本没法用。
为什么不能直接 SELECT * FROM DBA_DEPENDENCIES WHERE NAME = 'XXX'？
常见错误现象：SELECT * 返回几百上千行，其中大量 REFERENCED_OWNER 是 SYS 或 PUBLIC，比如 DBMS_OUTPUT、UTL_HTTP —— 这些是 Oracle 内置包的隐式引用，不是业务逻辑依赖，会干扰判断。
- 只保留有效对象：必须加
WHERE STATUS = 'VALID'，失效对象（STATUS = 'INVALID'）的依赖信息不全或已过期 - 排除系统模式：加
AND OWNER NOT IN ('SYS', 'SYSTEM', 'PUBLIC')，避免把基础平台调用当业务依赖 - 注意
DEPENDENCY_TYPE：值为'HARD'才表示真实强依赖；'SOFT'多来自动态 SQL 或同义词，不可信
NAME 和 REFERENCED_NAME 到底谁是谁？顺序搞反就全错了
NAME 是当前存储过程名，REFERENCED_NAME 是它调用的对象名。比如过程 CALC_SALARY 调用了函数 GET_TAX_RATE，那这一行里 NAME = 'CALC_SALARY'，REFERENCED_NAME = 'GET_TAX_RATE'。
- 跨 schema 调用必须显式写全名，如
HR.GET_TAX_RATE；否则 Oracle 默认找当前用户下的同名对象，依赖记录里REFERENCED_OWNER就会错 -
REFERENCED_NAME不带 schema，当多个用户有同名对象时，必须结合REFERENCED_OWNER才能定位真实目标 - 同义词（
SYNONYM）在依赖中显示的是原对象名，不是同义词名；查之前先确认REFERENCED_TYPE = 'SYNONYM'的行是否已解析到底层
递归查调用链时 CONNECT BY 容易报 ORA-01436
想查「A → B → C」这种链路，硬套 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')，它们常引发非业务相关分支
包体（PACKAGE BODY）的依赖容易被误读
包体本身不直接声明对外接口，它的依赖关系实际指向包规范（PACKAGE）里的函数/过程声明，而不是包体自身代码。所以查 TYPE = 'PACKAGE BODY' 的行时，REFERENCED_TYPE 很可能是 'PACKAGE'，而不是另一个包体。
- 不要按
TYPE = 'PACKAGE BODY'去查它“依赖了哪些包体”，这逻辑不成立 - 真正要查的是：这个包体实现的某个过程，最终调用了哪些外部对象 —— 得从包规范出发，再顺藤摸瓜
- 如果包规范里声明了
FUNCTION GET_DATA RETURN SYS_REFCURSOR，而包体里实际调用了HR.EMPLOYEE_VIEW，那依赖记录里REFERENCED_NAME = 'EMPLOYEE_VIEW'，REFERENCED_OWNER = 'HR'
依赖分析最麻烦的不是查不到，而是查到太多无关项。关键在过滤粒度：每一步都得明确是在解决什么问题——是定位故障源头？评估重构影响？还是清理废弃对象？目标不同，过滤条件就得跟着变，不能一套 SQL 打天下。
