查DBA_DEPENDENCIES需DBA或SELECT_CATALOG_ROLE权限，否则应使用ALL_DEPENDENCIES并注意OWNER和NAME大小写；删表前重点查REFERENCED_TYPE为VIEW等的依赖，而非双向关系；动态SQL、JOB、APEX等隐式引用不会被捕获。
查 DBA_DEPENDENCIES 之前先确认权限和对象范围
没有 select_catalog_role 或 dba 权限，dba_dependencies 查不到其他用户的依赖；用 all_dependencies 只能看到你有权限访问的对象。如果目标表在 scott 下，而你登录的是普通用户且没被授权，查询结果为空不是 bug，是权限拦的。
实操建议：
- 先执行
SELECT * FROM SESSION_ROLES;确认是否含SELECT_CATALOG_ROLE - 不确定时直接用
SELECT * FROM ALL_DEPENDENCIES WHERE NAME = 'YOUR_TABLE' AND OWNER = 'OWNER_NAME';，避免跨 schema 权限问题 - 注意
OWNER和NAME区分大小写，未加双引号的表名默认大写，'my_table'查不到，得用'MY_TABLE'
过滤 TYPE = 'TABLE' 但 REFERENCED_TYPE = 'VIEW' 才是关键路径
删表前最该盯的是“谁依赖我”，不是“我依赖谁”。DBA_DEPENDENCIES 默认返回双向关系，容易误读。比如一条记录 NAME='EMP'、TYPE='TABLE'、REFERENCED_OWNER='HR'、REFERENCED_NAME='DEPT'、REFERENCED_TYPE='TABLE'，说明 EMP 表引用了 DEPT 表——删 DEPT 会影响 EMP，但你要删的是 EMP，这行无关。
实操建议：
- 删表
EMP前，查：SELECT REFERENCED_OWNER, REFERENCED_NAME, REFERENCED_TYPE FROM DBA_DEPENDENCIES WHERE OWNER = 'SCOTT' AND NAME = 'EMP' AND REFERENCED_TYPE IN ('VIEW', 'MATERIALIZED VIEW', 'FUNCTION', 'PROCEDURE', 'PACKAGE BODY'); - 特别注意
REFERENCED_TYPE = 'VIEW'的记录，这些视图会因表结构变更或删除直接失效（ORA-04063: view "X.Y" has errors） -
DEPENDENCY_TYPE字段值为'HARD'才真正影响编译态，'SOFT'一般可忽略
注意物化视图和函数体内的隐式依赖漏报
DBA_DEPENDENCIES 不捕获动态 SQL 里的对象引用，比如函数里写了 EXECUTE IMMEDIATE 'SELECT * FROM ' || v_table_name;，哪怕 v_table_name 实际是你要删的表，也不会出现在依赖结果中。物化视图若基于复杂查询或含子查询因子（WITH），也可能只显示顶层引用，漏掉中间层表。
实操建议：
- 对疑似含动态 SQL 的
FUNCTION/PROCEDURE，手动 grep 源码：SELECT TEXT FROM ALL_SOURCE WHERE NAME = 'XXX' AND TYPE = 'FUNCTION' ORDER BY LINE; - 查物化视图基表：先从
ALL_MVIEWS找到MVIEW_NAME，再用DBMS_METADATA.GET_DDL('MATERIALIZED_VIEW', ...)看完整定义 - 别全信
STATUS = 'VALID'，删表后视图可能仍显示 VALID，但首次查询就报错——依赖校验是 lazy 的
删表前用 DROP TABLE ... CASCADE CONSTRAINTS 要小心外键反向依赖
CASCADE CONSTRAINTS 会自动删掉引用本表的外键约束，但它不会删视图、函数或物化视图。更危险的是：如果另一张表 ORDER_ITEMS 的外键指向你正要删的 PRODUCTS，CASCADE CONSTRAINTS 会删掉那个外键，但 ORDER_ITEMS 表本身还在——这时如果还有视图基于 ORDER_ITEMS JOIN PRODUCTS，删完 PRODUCTS 后视图照样失效，而你误以为“CASCADE 已兜底”。
实操建议：
- 执行
CASCADE CONSTRAINTS前，先查反向外键：SELECT OWNER, CONSTRAINT_NAME, TABLE_NAME FROM ALL_CONSTRAINTS WHERE R_OWNER = 'SCOTT' AND R_CONSTRAINT_NAME IN (SELECT CONSTRAINT_NAME FROM ALL_CONSTRAINTS WHERE OWNER = 'SCOTT' AND TABLE_NAME = 'PRODUCTS' AND CONSTRAINT_TYPE = 'P'); - 删表命令不加
CASCADE CONSTRAINTS更安全，先手动处理外键，再统一评估上层对象 - 生产环境删表前，务必在测试库跑一遍
SELECT COUNT(*) FROM YOUR_VIEW;，比看依赖列表更直接
依赖分析真正的难点不在 SQL 写多长，而在“哪些地方根本不会进 DBA_DEPENDENCIES”——比如 JOB 调用的匿名块、外部应用直连查询、甚至 APEX 页面里写的 SQL。只要没经过 PL/SQL 编译器解析，就不会留痕。
