DELETE视图根本不执行，因视图非物理对象、不占表空间；所谓“释放”无从谈起，其仅是数据字典中一条SELECT定义，DROP VIEW仅删除少量元数据，不影响磁盘空间。
DELETE 视图根本不会执行，因为视图不是物理对象
视图在 Oracle 中不占表空间，所以「删除视图不释放表空间」这个说法本身就有逻辑错误——你删的不是一个占用空间的东西，自然谈不上「释放」。视图只是数据字典里一条 SELECT 语句的定义（存于 DBA_VIEWS.TEXT），背后没数据块、没段（segment）、没 extent，DBA_SEGMENTS 里压根查不到它。
常见错误现象包括：误以为 DROP VIEW v_emp 后磁盘空间变大了，或反过来怀疑「删了视图怎么表空间没变化」；其实执行前后 DBA_DATA_FILES.BYTES 和 DBA_FREE_SPACE.BYTES 完全不变，这是正常且唯一可能的结果。
真正占空间的是基表，而 DELETE 基表才触发 HWM 滞留问题
如果你删的是视图所依赖的基表里的数据（比如 DELETE FROM emp WHERE deptno = 10），那问题就转到基表身上了：Oracle 只标记行删除，不降高水位线（HWM），DBA_TABLES.BLOCKS 不变，全表扫描仍扫到老位置。
-
DELETE后立刻查SELECT blocks, num_rows FROM user_tables WHERE table_name = 'EMP'，会发现blocks毫不动，num_rows变小 —— 这就是 HWM 虚高 - 想确认实际使用块数？用
DBMS_SPACE.SPACE_USAGE：返回的USED_BLOCKS才反映真实数据密度 - 别指望
ANALYZE TABLE，优先用DBMS_STATS.GATHER_TABLE_STATS，统计更准、兼容性更好
SHRINK SPACE 或 TRUNCATE 是针对基表的操作，和视图无关
收缩空间必须作用于基表，且有明确前提：
-
ALTER TABLE emp ENABLE ROW MOVEMENT是SHRINK SPACE的硬性前置，否则报ORA-10636 -
SHRINK SPACE COMPACT只整理块内碎片，加 RX 锁，DML 可并发；SHRINK SPACE才动 HWM，第二阶段需短暂 X 锁，所有 DML 阻塞 -
TRUNCATE TABLE emp重置 HWM + 释放 extents，但不可回滚、不能有外键引用、会冲突 Flashback Data Archive - 无论 SHRINK 还是 TRUNCATE，做完后数据文件（.dbf）大小仍不变，必须手动
ALTER DATABASE DATAFILE ... RESIZE
视图被 DROP 后，唯一「释放」的是数据字典里几行元数据
DROP VIEW v_emp 实际只删掉三样东西：DBA_VIEWS 里一行定义、DBA_OBJECTS 里一个对象记录、以及依赖它的授权信息（如 DBA_TAB_PRIVS）。这些元数据加起来通常不到 1KB，操作系统层面完全不可见。
容易被忽略的一点：如果视图用了 WITH READ ONLY 或 WITH CHECK OPTION，DROP 时不会影响基表约束或触发器；但如果视图上建了物化视图（MV），那 DROP VIEW 会失败——因为 MV 依赖它，得先删 MV。
