DROP PARTITION本身不触发全表锁，仅持短暂元数据锁；加UPDATE GLOBAL INDEXES才会因全局索引排他锁导致等效全表阻塞，验证需查v$session和v$sql中含该子句的执行语句。
Drop Partition本身不触发全表锁，但UPDATE GLOBAL INDEXES会
Oracle执行ALTER TABLE ... DROP PARTITION默认只持有一个短暂的元数据锁（DDL lock），不影响常规DML；所谓“全表锁”其实是误判——真正导致长时间阻塞的是加了UPDATE GLOBAL INDEXES子句后的同步索引维护行为。
UPDATE GLOBAL INDEXES为什么等价于全表锁
该子句要求Oracle在删分区的同时，扫描所有被删数据在全局索引中的对应条目，并逐个修正B-tree叶节点指针。这个过程：
- 必须对整张表的全局索引段加排他锁（
Xmode），期间所有DML（INSERT/UPDATE/DELETE）都会等待 - 若分区含千万级以上数据，或存在多个全局索引，耗时可达数十分钟
- 锁范围不是“表”，而是“每个全局索引的全部segment”，但效果上与全表不可写无异
如何验证当前是不是被UPDATE GLOBAL INDEXES卡住
查v$session和v$lock，重点关注LOCKED_MODE为6（X锁）且BLOCKING_SESSION非空的会话；再结合v$sql看其SQL_TEXT是否含UPDATE GLOBAL INDEXES。更直接的是查：
SELECT sql_id, sql_text FROM v$sql WHERE sql_text LIKE '%DROP%PARTITION%UPDATE%GLOBAL%INDEXES%';
只要这条语句还在执行中，就说明正处在索引同步阶段，不是元数据操作卡住，而是索引重建卡住。
Drop Partition后全局索引变UNUSABLE，反而是低风险选择
不加UPDATE GLOBAL INDEXES时，DROP PARTITION秒级完成，仅全局索引状态变为UNUSABLE，本地索引不受影响。后续可用两步法修复：
-
ALTER INDEX idx_name UNUSABLE;（毫秒级，几乎不阻塞） -
ALTER INDEX idx_name REBUILD PARALLEL 4;（可在线、可指定表空间、可加LOGGING）
这比硬扛UPDATE GLOBAL INDEXES的锁表风险更可控——尤其在1.8TB级大表上，重建索引可调度到业务低峰，而同步更新根本没法中断或降级。
