truncate分区表的操作，会导致全局索引失效？

拼搏现实的明天。 2023-05-21 15:28 34阅读 0赞

今天看到《[删除分区如何不让全局索引失效？][Link 1]》这篇文章有朋友提了个问题，

![format_png][]

truncate是删除数据操作，但他是DDL语句，不是delete这种DML语句，不会写redo和undo，不能rollback。

官方文档，已经明确指出，除非使用update indexes，否则用truncate分区表，就会导致全局索引失效，必须重建，

> Unless you specify UPDATE INDEXES, any global indexes are marked UNUSABLE and must be rebuilt. (You cannot use UPDATE INDEXES for index-organized tables. Use UPDATE GLOBAL INDEXES instead.)

在alter table分区表的操作中带着update indexes，就会让Oracle在执行DDL语句的同时，更新索引，当然这会让alter table执行的时间更长。这就是所谓“甘蔗没有两头甜”。

扩展一下，对堆表来说，alter table不带update indexes，则涉及的局部索引会失效，涉及的全局索引会标记为失效，需要重建，对索引组织表，局部索引的效果和堆表相同，但是全局索引仍可用，

![format_png 1][]

分区表执行drop、truncate、exchange这些DDL操作，不再是快速操作，他的时间就需要衡量了，因为会导致全局索引的失效，需要重建索引，

> The DROP, TRUNCATE, and EXCHANGE operations are no longer fast operations. Again, you must compare the time it takes to do the DDL and then rebuild all indexes.

最简单的方式，当然就是测试，实践是检验真理的唯一标准。

创建测试表、测试数据，

SQL> CREATE TABLE interval_sale
      2      ( prod_id        NUMBER(6)
      3      , cust_id        NUMBER
      4      , time_id        DATE
      5      )
      6      PARTITION BY RANGE (time_id)
      7      INTERVAL(NUMTOYMINTERVAL(1, 'YEAR'))
      8        ( PARTITION p0 VALUES LESS THAN (TO_DATE('1-1-2003', 'DD-MM-YYYY')),
      9          PARTITION p1 VALUES LESS THAN (TO_DATE('1-1-2004', 'DD-MM-YYYY')),
     10         PARTITION p2 VALUES LESS THAN (TO_DATE('1-1-2005', 'DD-MM-YYYY')),
     11         PARTITION p3 VALUES LESS THAN (TO_DATE('1-1-2006', 'DD-MM-YYYY')));
    Table created.
    
    
    SQL> insert into interval_sale values(1, 1, to_date('2002-01-01','yyyy-mm-dd'));
    1 row created.
    
    
    SQL> insert into interval_sale values(2, 2, to_date('2003-01-01','yyyy-mm-dd'));
    1 row created.
    
    
    SQL> insert into interval_sale values(3, 3, to_date('2004-01-01','yyyy-mm-dd'));
    1 row created.
    
    
    SQL> insert into interval_sale values(4, 4, to_date('2005-01-01','yyyy-mm-dd'));
    1 row created.
    
    
    SQL> commit;
    Commit complete.

创建全局索引，

SQL> create index idx_01 on interval_sale(cust_id);
    
    
    Index created.
    
    
    SQL> select table_name, index_name, partitioned, status from user_indexes where table_name='INTERVAL_SALE';
    
    
    TABLE_NAME       INDEX_NAME     PAR  STATUS
    --------------- --------------- --- --------
    INTERVAL_SALE      IDX_01       NO    VALID

执行truncate，不带update indexes，

SQL> alter table interval_sale truncate partition p1;
    Table truncated.

此时索引状态，UNUSABLE，

SQL> select table_name, index_name, partitioned, status from user_indexes where table_name='INTERVAL_SALE';
    TABLE_NAME       INDEX_NAME   PAR  STATUS
    --------------- ------------- --- --------
    INTERVAL_SALE    IDX_01       NO  UNUSABLE

如果用了update indexes，全局索引状态，仍是VALID，

SQL> alter table interval_sale truncate partition p3 update indexes;
    Table truncated.
    
    
    SQL> select table_name, index_name, partitioned, status from user_indexes where table_name='INTERVAL_SALE';
    TABLE_NAME        INDEX_NAME   PAR  STATUS
    ---------------- ------------- --- --------
    INTERVAL_SALE       IDX_01     NO   VALID

当然，按照《[删除分区如何不让全局索引失效？][Link 1]》逻辑，执行delete，再执行truncate，

SQL> delete from interval_sale partition (p0);
    2 rows deleted
    
    
    SQL> alter table interval_sale truncate partition p0;                    
    Table truncated.

此时全局索引状态还是VALID，但是这种操作，没什么实际意义，

SQL> select table_name, index_name, partitioned, status from user_indexes where table_name='INTERVAL_SALE';
    TABLE_NAME       INDEX_NAME   PAR  STATUS
    --------------- ------------- --- --------
    INTERVAL_SALE      IDX_01     NO   VALID

**近期热文：**

《[NUMBER长度的误解][NUMBER]》

《[《decode函数的妙用》网友的两个问题解答][decode]》

《[decode函数的妙用][decode 1]》

《[虚拟内存详解][Link 2]》

《[7号球衣的故事：重要的不是号码，而是穿着它的人][7]》

《[插入"&"特殊字符的几种思考][Link 3]》

《[connect by超乎你想象][connect by]》

《[TOEIC科普一下][TOEIC]》

[Link 1]: https://blog.csdn.net/bisal/article/details/103856220
[format_png]: /images/20230521/f07d9216a115402d93e37e72c62285d2.png
[format_png 1]: /images/20230521/66c506b2b11044479fd0a7a33dc3396c.png
[NUMBER]: https://blog.csdn.net/bisal/article/details/105548618
[decode]: https://blog.csdn.net/bisal/article/details/105445417
[decode 1]: https://blog.csdn.net/bisal/article/details/105424100
[Link 2]: http://mp.weixin.qq.com/s?__biz=MzI2NzM1OTM4OA%3D%3D&chksm=ea815efdddf6d7eb584de7d482ed5dfb230a0867eabba143f6821a3d9201f6ba9e1ec97db410&idx=1&mid=2247490318&scene=21&sn=d8d2178a7f06ed7cebbb11d4718f3885#wechat_redirect
[7]: https://blog.csdn.net/bisal/article/details/105283168
[Link 3]: http://mp.weixin.qq.com/s?__biz=MzI2NzM1OTM4OA%3D%3D&chksm=ea815f05ddf6d613a8fd4f4454278476e27e37675d810d3aa4e74a8e0c8d06b6e168ea9c8ecb&idx=1&mid=2247490294&scene=21&sn=46ac00aeef5cae9c81dcd234c9766853#wechat_redirect
[connect by]: https://blog.csdn.net/bisal/article/details/105236326
[TOEIC]: https://blog.csdn.net/bisal/article/details/105383559