ORA-01922或ORA-02429报错源于残留对象：回收站未清表、跨Schema外键/同义词/物化视图等依赖未解除；DROP USER CASCADE不释放磁盘空间，需手动删表空间；清理须覆盖触发器、调度任务等隐式依赖对象。
ORA-01922 或 ORA-02429 报错时，其实是残留对象在作祟
执行 DROP USER xxx CASCADE 后仍报错，常见于两类残留：一是回收站（RECYCLEBIN）里没清的表，二是其他用户创建、但依赖已删用户的对象（比如外键指向原用户表、同义词指向原用户对象）。Oracle 不会自动清理这些跨 Schema 依赖，报错信息却常误导人——例如 ORA-01922: CASCADE constraint does not exist 实际是因依赖未断，不是约束真不存在。
- 先查回收站：
SELECT * FROM RECYCLEBIN WHERE OWNER = 'XXX';，若有结果，用PURGE TABLE "BIN$xxx";或直接PURGE USER_RECYCLEBIN; - 再查外键依赖：
SELECT owner, constraint_name, table_name FROM dba_constraints WHERE r_owner = 'XXX' AND constraint_type = 'R';，这些外键必须由目标 Schema 所有者手动删掉或禁用 - 同义词和视图不会被级联删除，只置为
INVALID；若需彻底清理，得在其他用户下运行DROP SYNONYM xxx;或DROP VIEW xxx;
drop user cascade 后，其他用户里的物化视图还能用吗
不能刷新，但也不会自动删。Oracle 明确不删除其他 Schema 中基于已删用户表的 MATERIALIZED VIEW，因为物化视图本身属于调用方 Schema。只要基表没了，下次 REFRESH 就会失败，报 ORA-12008: error in materialized view refresh path 或 ORA-00942: table or view does not exist。这类对象得人工识别并处理：
- 查依赖：
SELECT mview_name, owner FROM dba_mviews WHERE query LIKE '%XXX.%';（把XXX换成被删用户名） - 确认是否还用得上：如果只是历史快照且无业务依赖，直接
DROP MATERIALIZED VIEW owner.mview_name; - 如果还要保留结构，可改写查询语句绕过已删表（前提是有替代数据源）
为什么磁盘空间没释放，即使 drop user cascade 成功了
DROP USER ... CASCADE 只删数据字典元数据，完全不碰物理文件。哪怕用户独占一个表空间，那个表空间及其数据文件（如 /u01/oradata/ORCL/tq_tables01.dbf）依然躺在磁盘上，df -h 看不到变化。
- 必须单独删表空间：
DROP TABLESPACE tq_tables INCLUDING CONTENTS AND DATAFILES; - 加
CASCADE CONSTRAINTS是防外键拦路，尤其当其他表空间的表有外键引用该表空间里的主键时 - 删表空间前务必确认：没有用户还在用它做默认表空间（查
DBA_USERS.DEFAULT_TABLESPACE），否则后续新建用户可能失败
用脚本批量清理残留对象比手工一条条删更可靠
手工删容易漏——比如忘了触发器、调度任务（DBA_SCHEDULER_JOBS）、函数包体（DBA_SOURCE 里藏的 PL/SQL）、甚至细粒度审计策略。一套按类型分拆的 PL/SQL 脚本能覆盖更全：
- 删表前先清外键：
FOR c IN (SELECT 'ALTER TABLE ' || table_name || ' DROP CONSTRAINT ' || constraint_name FROM user_constraints WHERE constraint_type = 'R') LOOP EXECUTE IMMEDIATE c.text; END LOOP; - 删所有非系统对象通用模板：
EXECUTE IMMEDIATE 'DROP ' || object_type || ' ' || object_name;，遍历USER_OBJECTS过滤OBJECT_TYPE NOT IN ('INDEX', 'LOB', 'TABLE PARTITION')等需特殊处理的类型 - 真正麻烦的是
DBA_REGISTRY或DBA_APPLY这类高级功能对象，它们不在常规对象列表里，得单独查、单独删
复杂点在于对象间的隐式依赖：删一个包可能让另一个用户的视图失效，而这个视图又被第三个用户的存储过程调用。清理前最好停业务或切到维护窗口，别信“只删自己用户的东西就安全”。
