[z]分區truncate操作的介紹及對全局索引和空間釋放影響的案例解析

[z]https://www.2cto.com/database/201301/181226.html

環境：

[sql]

[[email protected] ~]$ uname -r

2.6.18-308.el5xen

[[email protected] ~]$ sqlplus -v

SQL*Plus: Release 10.2.0.1.0 - Production

㈠ 文法   www.2cto.com  

例如：

① 馬上回收空間：

  alter table table_name truncate partition partition_name drop storage;

② 同時維護全局索引：

  alter table table_name drop partition partition_name update global indexes;

㈡ 對全局索引的作用

大分區表truncate partition後,需要對全局索引進行維護,否則，global index會變成unusable

問題介紹：

① 在drop partition時，為了維護global索引，要加update indexes或是update global indexes條件

  請問，大家研究過這兩個條件的差別嗎？

  答： UPDATE GLOBAL INDEXES隻維護全局索引

UPDATE INDEXES同時維護全局和本地索引

對于DROP/TRUNCATE PARTITION而言 ，二者沒有太大的差別

對于MERGE和SPLIT PARTITION，你就可以看到二者的差別了

雖然index是變得valid了，但是index的空間沒有釋放

因為該操作不等于REBUILD，隻是在進行DDL的時候，同步維護索引資訊而已

  www.2cto.com  

工業環境的案例介紹：

② 我今天對分區表的一個分區做了TRUNCATE,這個分區有一個普通唯一索引和本地索引,

  TRUNCATRE的時候沒有用UPDATE GLOBAL INDEXES 那個指令,結果導緻報：

  ORA-01502: index 'BILL.IDX_CHARGE_D_591_0712_SID' or partition of such index is in unusable state

  這是因為，truncate partition不加update global indexes，會導緻全局索引失效（unusable）.

  然後，我隻好：

  alter index bill.IDX_CHARGE_D_591_0712_SID parallel 10 nologging rebuild  來整個的重建,13億記錄的大表

  後來接着晚上有人繼續插入這個表的時候，告訴我慢的要命,本來一個小時至少可以跑完400萬條記錄，現在3個小時了才跑130萬

  我馬上想到會不會是本地索引問題，因為我聽說雖然分區交換或者TRUNCATE對局部索引沒影響,

  但是實際上是有問題的，還是重建的好：

  alter index bill.UNQ_RRATING_CHARGE_D_591_0712 rebuild partition PART_20

  把這個剛才我TRUNCATE的分區的涉及到的局部索引重建立了一下

  結果立馬見效果了，10分鐘跑了200萬條記錄，600萬條記錄在20分鐘全部跑好!比以前同期跑的還快一點

  半夜被叫起來幹活了

  奇怪，如下寫法怎麼半天都執行不好

  alter table bill.recur_rating_charge_d_591_0712 truncate partition PART_21  update global indexes  ;

  select count(*) from bill.recur_rating_charge_d_591_0712 partition(PART_21)

  資料始終不變

  但是我看v$session_longops看到這個SID很快就做好事了，

  而我看表分區記錄始終在

  我暈,隻好采用老辦法,殺掉會話後，

  alter table bill.RECUR_RATING_CHARGE_d_591_0712 truncate partition PART_20不加update global indexes

  然後分别維護了普通索引和局部索引，這次加NOLOGGING和PARALLEL 8 ,也很快,3億的大表，維護普通索引隻花了200秒

  alter index bill.IDX_CHARGE_D_591_0712_SID rebuild  parallel 8 nologging ;

  alter index bill.UNQ_RRATING_CHARGE_D_591_0712 rebuild partition PART_21 parallel 8 nologging;

  猜測原因：

  truncate partition PART_20後，這個分區的和這個分區上的本地索引的統計資訊是不會更新也不會丢失

  當我往這個分區插入資料的時候，執行計劃是根據錯誤的統計資訊生成的，是以會很慢

  當我rebuild index partition PART_20 後，會導緻這個索引的統計資訊丢失，

  而我的執行計劃就有可能改變了，是以我的插入變快了

  總結：    www.2cto.com  

  當你truncate後應該立即對這個分區做分析cascade => true（增加對索引的統計資訊），

  同時rebuild global index 并分析global index才對

㈢ 空間釋放問題

其實空間等都已經釋放了，但資料字典沒有被更新，

例如你查dba_segments視圖，發現這個分區的bytes其實還為原來的大小

我們可執行alter table **** allocate extent即可更新資料字典為正常狀态

例如針對範圍分區如下操作：

alter table *** modify partition PART_*** allocate extent;

轉載于:https://www.cnblogs.com/jjj250/p/9528808.html