TRUNCATE PARTITION更安全高效，保留分区结构和索引有效性，适合ADG环境；DROP PARTITION物理删除分区但使全局索引失效，需加UPDATE GLOBAL INDEXES。
直接删分区比drop table安全得多，但选drop partition还是truncate partition，得看你要不要保留分区结构、索引状态和后续扩展能力。
区分DROP PARTITION和TRUNCATE PARTITION的实际影响
两者都删数据，但底层行为完全不同：
-
DROP PARTITION：物理删除分区段（segment），释放空间，分区定义从数据字典中移除；全局索引会变UNUSABLE（除非加UPDATE GLOBAL INDEXES）；本地索引随分区一起消失。 -
TRUNCATE PARTITION：清空数据但保留分区结构，段头重置，高水位线（HWM）归零；全局索引默认保持VALID，但会产生ORPHANED_ENTRIES（需后续清理）；本地索引自动维护有效。 - 性能上，
TRUNCATE PARTITION通常更快、生成Redo更少，尤其适合ADG环境——它不修改数据字典元数据，备库应用压力小得多。 - 如果表有
INTERVAL分区或未来要按相同逻辑新增分区，TRUNCATE PARTITION更稳妥，避免因分区定义缺失导致自动分区失败。
在Oracle 19c ADG环境中执行必须加的参数
主库执行分区操作时，备库同步效率直接受影响。以下参数不是“可选”，而是生产环境强制建议：
- 对
TRUNCATE PARTITION，加UPDATE GLOBAL INDEXES没意义（语法不支持），但必须关注ORPHANED_ENTRIES——它会在凌晨自动触发PMO_DEFERRED_GIDX_MAINT_JOB，但该JOB会产大量Redo；建议业务低峰期手动运行：exec DBMS_PART.CLEANUP_GIDX('SCHEMA','TABLE_NAME'); - 对
DROP PARTITION，强烈要求加上UPDATE GLOBAL INDEXES，否则全局索引失效后所有走该索引的查询都会报错ORA-01502；但注意：这个子句本身会显著延长执行时间并增加Redo量。 - 无论哪种操作，提前将对应索引设为
NOLOGGING可大幅降低Redo（仅限允许丢失该索引重做的场景）：ALTER INDEX idx_name NOLOGGING;，操作完记得切回LOGGING。
执行前必须验证的三件事
跳过这步，大概率在半夜收到告警：
- 查分区名是否真实存在且未被锁定：
SELECT partition_name, high_value FROM dba_tab_partitions WHERE table_name = 'ABC' AND table_owner = 'YOUR_SCHEMA'; - 确认当前没有长事务或DDL正在访问该表：
SELECT sid, serial#, sql_id, event FROM v$session WHERE blocking_session IS NOT NULL OR sql_id IN (SELECT sql_id FROM v$sql WHERE sql_text LIKE '%abc%'); - 检查表空间剩余空间——
TRUNCATE PARTITION不释放空间，DROP PARTITION才释放；但如果后续要重建索引或清理全局索引，临时空间可能吃紧。
为什么不能用DELETE FROM ... PARTITION (...)
看起来直观，实际是灾难性选择：
- 逐行删除，生成海量Undo和Redo，ADG环境下极易拖垮备库应用进程（MRP）；
- 锁粒度是行级+事务级，可能阻塞其他DML长达数小时；
- 执行期间无法中断，一旦OOM或超时，残留事务清理极麻烦；
- 即使加了
PARTITION限定，Oracle仍可能做全表扫描过滤（尤其无合适分区键谓词时），性能不可控。
真正需要“删部分数据而非整个分区”时，应先EXCHANGE PARTITION到临时表，再DELETE，最后TRUNCATE临时表——但这已超出单纯分区清理范畴。
