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

環境：

[sql]

[oracle@localhost ~]$ uname -r

2.6.18-308.el5xen

[oracle@localhost ~]$ 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;

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