ORA-14006错误主因是尝试删除分区表中最后一个或关键边界分区，Oracle强制要求表至少保留一个分区；正确做法是先TRUNCATE TABLE清空数据，再通过ADD+DROP调整分区结构。
直接执行 DROP PARTITION 会报 ORA-14006 错误
Oracle 不允许用 DROP PARTITION 删除最后一个分区——哪怕表是范围/列表分区且还有其他分区存在，只要目标分区是「当前仅存的分区」或「被依赖的边界分区」，就会触发 ORA-14006: invalid partition name。这不是语法写错，而是 Oracle 的分区结构保护机制：它要求表至少保留一个分区（不能变为空分区表），且某些分区（如 MAXVALUE 或 DEFAULT）不可删。
删除所有分区的正确路径是先清空再删表
想真正“清空所有分区数据并释放空间”，DROP PARTITION 本身不是为批量清空设计的。可行做法分两步：
- 用
TRUNCATE TABLE ... DROP STORAGE清空全部分区数据并回收段空间（比逐个TRUNCATE PARTITION快得多，且不走回滚段） - 如果连分区定义也要清除，直接
DROP TABLE；若需保留表结构，就重建分区方案（例如改用非分区表，或重定义为单一分区） - 注意：
TRUNCATE TABLE在分区表上默认作用于全表，无需指定分区名，也绕过DROP PARTITION的校验逻辑
逐个 DROP PARTITION 的适用场景和风险
只有在明确要保留部分分区、且目标分区非系统关键分区时，才用 DROP PARTITION。常见错误包括：
- 对哈希分区表执行
DROP PARTITION—— Oracle 12c 及以后才支持，旧版本直接报错 - 未检查分区键值依赖：比如删掉
P1后，新插入数据可能因范围定义缺失而报ORA-14400: inserted partition key does not map to any partition - 忽略全局索引失效：删分区后，若未加
UPDATE GLOBAL INDEXES，全局索引会进入UNUSABLE状态，后续查询可能失败
快速清空 + 重建分区的最小安全操作示例
假设表 Sales 是按时间范围分区，你只想留结构、清所有数据并重置分区布局：
-- 1. 清空全部数据（秒级完成）
TRUNCATE TABLE Sales DROP STORAGE;
<p>-- 2. 删除所有现有分区（需先 add 一个新分区占位，否则 DROP PARTITION 会卡住）
ALTER TABLE Sales ADD PARTITION p_future VALUES LESS THAN (MAXVALUE);</p><p>-- 3. 逐个 DROP 原有分区（除刚加的 p_future）
ALTER TABLE Sales DROP PARTITION p_2022;
ALTER TABLE Sales DROP PARTITION p_2023;</p><p>-- 4. 最后删掉占位分区，再重建所需分区结构
ALTER TABLE Sales DROP PARTITION p_future;
ALTER TABLE Sales ADD PARTITION p_2024 VALUES LESS THAN (TO_DATE('2025-01-01','YYYY-MM-DD'));</p>
真正的难点不在语法，而在确认分区键分布、全局索引状态、以及应用层是否缓存了分区名——这些漏掉一个，上线后就容易查不到数据。
