新系统改造，对于分区表上的索引都改成local类型的分区索引，便以为高枕无忧，自此任由他人对表进行DDL操作，也无需担心索引失效的情况了。
然而，天有不测风云。
在巡检系统运行情况时候，发现一条sql语句平均执行时间到达0.2秒，然而该语句正常情况下应该几毫秒结束战斗。查看执行计划，竟然是全表扫描，查看索引情况，创建了相关索引，并且是本地分区索引。
于是，怀疑是统计信息出现问题了，但右击属性，看到num_rows也正常，未出现0的情况。
不明索引，甚至开始怀疑是不是踩了优化器方面的bug，毕竟自从用了12.1.0.2这个版本，bug方面就没消停过。
后来我新建了一个索引，执行计划变过来了，走了该索引，不明所以，我也以为此事到此为止了。
结果，今天过来一看，这条语句又出现全表扫描的情况了。感觉不对，看了下alert日志，发现竟然有失效索引的情况。
有点楞，一直以为只要建成本地分区索引，oracle便会自动维护，无需我等介入。
查了点资料，发现存在一种情况：当对最大分区拆分分区时候，若是拆分出来的分区没有涉及到数据移动，那么oracle可以自动维护本地分区索引，但是若是存在数据被拆分到新的分区里面，那么就需要我们闪亮登场了。
当然，也可以在拆分语句后面加上update indexes来解决该问题：
alter table test split partition PEVER at ('20180511') into (partition KAPB_TZNRMX_P20180510 tablespace cbmain_index,
partition pever tablespace cbmain_index) update indexes;
----------------------------------------------------------------------
重建这个失效本地分区索引的语法，还略有不同：
alter index idx_local rebuild partition idx_20180202 online;
----------------------------------------------------------------------
总结：错误的认识当成了真理，以为local分区索引是高枕无忧，导致最开始出现问题的时候没有及时想到索引失效的情况。
有时候，还是要敢于怀疑那些约定俗成的认知。
毕竟，有很多人，很多事，再后来人看来，都是错的！