有關執行計畫，空間釋放的另一些

最近負責起了dba的部分工作，於是有一天在對錶空間的清理中發現了一張表，這個表有27g那麼大，是乙個分割槽表，按天分割槽。我檢視了過程，每天刪除35天以前的資料，但是用的方法是delete，那麼我就可以很明確的推斷出，這個表占用了大量本應該釋放的空間。

我第乙個使用的方法是move：

alter table table_name move partition part_1;

這樣做很快，但是今天我在看一本書的時候，上面記載這種方法會更改rowid，會讓原來的索引失效。不過和我的有一點小出入：

這個表上沒有索引，所以我這樣做了也無所謂，但是系統中存在著很多這樣的表，我需要試驗一下在分割槽表上move操作會不會導致索引失效。事實上我不需要建立索引實驗，我只需要知道move之後rowid變了沒有就好了。

建一張分割槽表：

上圖是資料。下面只查詢一下part_1裡的資料：

然後在執行move語句，看看這樣之後的結果：

仔細看，rowid確實變了，根據上面書中的記載，這樣是要導致索引失效的。後來經過實際測試，確實失效（我在day_id列上建立的local索引）。失效之後rebuild索引的時候不能使用這個語句：

alter index idx_name rebuild;

而要乙個分割槽乙個分割槽的重建：

繼續上面第一段的內容說，這個表被我從27g弄到了3.7g，省了快20g的空間出來，對我們這種沒什麼空間的系統很寶貴了。

首先建立這個表：

create table test as select * from dba_objects; --收集統計資訊 analyze table test compute statistics;

執行計畫是這樣子的：

如上如紅色框處所示，在查詢得到的結果相同的情況下，cost要大了很多，我推測這是掃瞄了那些本來應該釋放掉的資料塊所致。

move之後情況就會變得不一樣：

我聽說很多技術很正規的公司不允許寫select *。我覺得這個是對的，select你需要的字段，就會大大降低很多壓力：