truncate
上午有同事让我帮他删除数据，因为他用DELETE删除时很慢，就把删除语句发给我了：
DELETE FROM cjcl.cj_cj_tbjd where bgq = ‘201309MM’
我一看，这条语句所删除的内容正是某个分区的数据：
SELECT COUNT(0) FROM cjcl.cj_cj_tbjd where bgq = ‘201308MM’; –RWID_601_BGQ_201309MM
SELECT COUNT(0) FROM cjcl.cj_cj_tbjd SUBPARTITION (RWID_601_BGQ_201308MM)
执行上面两条命令，所得的结果都一样，可以肯定要删除的数据全在这个分区上，于是就用下面的命令来删除数据：
ALTER TABLE cjcl.cj_cj_tbjd TRUNCATE SUBPARTITION RWID_601_BGQ_201309MM
删除是很快的，可没过多长时间，应用那边的人就找麻烦了，发来了一条错误消息：
DELETE FROM CJCL.CJ_CJ_SJXGJL WHERE REPORTID = ‘5EB74170’ AND BGQ = ‘201301YY’ AND DCDXXTM = ‘0316344’]; sql state [null]; ERROR code [17081]; 批处理中出现错误: ORA-01502: 索引 ‘CJCL.PK_CJ_CJ_TBJD’ 或这类索引的分区处于不可用状态
错误消息主要是后面”ORA-01502: 索引 ‘CJCL.PK_CJ_CJ_TBJD’ 或这类索引的分区处于不可用状态”，查询了一下这个索引，原来是被删除数据的那张表的主键全局索引，这下可好了，由于刚才执行的TRUNCATE（DDL）命令，使这张表的主键全局分区索引失效，再对这张表进行更新或插入操作的时候，就直接报上面的错误了，这张表很大，有1亿100万行数据，现在也没办法了，只能把这张表的这个索引REbuild一下，于是后来执行了下面的命令对这个索引进行REBUILD：
ALTER INDEX PK_CJ_CJ_TBJD REBUILD parallel 10; // 一 刚开始没有使用并行，非常慢，跑了3个小时也没有跑出来，于是终止了，并加了并行。
当这个主键全局分区索引执行完成后，一切才慢慢才恢复正常，过程从下午4点折腾到晚上9点才结束。
总结：如果一张表是分区表，并且这张表上有全局分区索引，则千万不要用TRUNCATE 及类似的DDL来操作这张表，这样会导致全局分区索引失效，从而使应用挂住，无法在这张表上进行DML操作，就如同上面的删除操作，如果用DELETE来删除数据，这个问题就不会发生了。
相关阅读
delete 逐条删除表“内容”，truncate 先摧毁表再重建。(由于delete使用频繁，Oracle对delete优化后delete快于truncate) delete 是D