1. 程式人生 > >分割槽表或分割槽索引的BLOCK_ID很大導致DATAFILE無法RESIZE的解決方法

分割槽表或分割槽索引的BLOCK_ID很大導致DATAFILE無法RESIZE的解決方法

一 前言

最近發現磁碟空間有3T的效能機器出現了磁碟空間不足的現象,該機器主要部署ORACLE資料庫,所以,猜測很可能是表空間資料檔案變更導致的。接下來,就需要一步步的排查問題了,最終確認是ORACLE BLOCK_ID惹的禍。


二 定位磁碟空間佔用情況

首先需要確定是哪些檔案佔用空間,使用du -sh * ,果不其然,有個表空間增加了20個數據檔案,而且每個資料檔案設定30G,Word天,誰這麼狠,居然找不到元凶,好吧,那我就任意處置了,不能影響後面的效能測試。


三 刪除資料檔案

既然發現這麼多資料檔案,當然想直接drop掉,於是,不以為然的執行alter tablespace TEST drop datafile '/oradata/dat20.dbf';先把最後一個幹掉,結果執行報錯“ORA-03262: THE FILE IS NON-EMPTY”,呵,居然有資料,直接刪不掉。於是,就想查詢這個表空間的表,把資料TRUNCATE掉,但又考慮到該表空間TABLE就有上千張,而且不能確定哪張表可刪,不能太魯莽,事實證明,真和資料無關。


四 退而求其次-RESIZE 資料檔案釋放空間

既然不能drop 資料檔案,那就resize它,就不信拿不回空間。於是,先查下可以釋放多少空間出來,先執行如下命令:

select d.file_name,d.file_id,d.bytes/1024/1024 as d_byte,sum(f.bytes/1024/1024) as free_byte 

from dba_data_files d,dba_free_space f 

where d.file_id=f.file_id and d.file_id=67 

group by d.file_name,d.file_id,d.bytes/1024/1024;

輸出顯示67號資料檔案可用空間29.9G,看到這裡,心裡暗罵,是誰這麼不靠譜,亂加亂設資料檔案。不過,都是小問題,resize成1G就行了。於是,又興沖沖的趕緊執行ALTER DATABASE DATAFILE '/oradata/hisdat20.dbf' RESIZE 1G; 居然又報錯了,

“ORA-03297:file contains used data beyond requested RESIZE value”,看到這個報錯,開始意識到可能問題沒有這麼簡單。


五 shrink space降低高水位

既然實際資料很少,resize卻不能成功,就表明是某些資料塊位於資料檔案的末端,那就先降降HWM高水位,對錶空間的表進行操作,主要命令如下:

alter table test_table enable row movement;

alter table test_table shrink space; ---降低高水位,釋放空間

alter table test_table disable row movement;


當然,這樣一個個的執行不顯示,需要批量執行,命令如下:

SELECT DISTINCT 'alter table ' || segment_name || ' enable row movement;'||

                'alter table ' || segment_name || ' shrink space;'||

                'alter table ' || segment_name || ' disable row movement;'

 FROM dba_extents

 WHERE tablespace_name = 'TEST'

 AND segment_type = 'TABLE'


降低HWM後,再次執行RESIZE操作,報錯依舊,好吧,既然這樣都沒搞定,需要認真研究下了。


六 找到真凶和解決方法

通過上述嘗試,發現數據檔案可用空間充足,但對ORACLE而言,資料檔案使用了30G,所以RESIZE到1G會報錯失敗,儘快進行了降高水位或TRUNCATE操作都無濟於事。於是,排查和解決思路是這樣的:

1)查詢資料檔案的最大BLOCK_ID

select max(block_id) from dba_extents where file_id=67;


2)確定該BLOCK_ID與哪個表或索引有關

SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME FROM DBA_EXTENTS A WHERE FILE_ID = 67 AND block_id = 3839929;

查詢後,發現最大的BLOCK_ID都是與分割槽表或分割槽索引有關的。


3)針對最大BLOCK_ID出現在分割槽表的處理方法

對分割槽表出現最大BLOCK_ID的情況,採用先降分割槽表高水位,然後MOVE表空間,命令如下:

alter table TEST_TABLE MODIFY PARTITION P101101 shrink space;---注意降低高水位並不能降低資料檔案中block_id大小

alter table TEST_TABLE move partition P101101 tablespace TEST;---move操作資料移動表空間最前面的空閒block,注意需要重建索引


4)針對最大BLOCK_ID出現在索引分割槽的處理方法

對索引分割槽出現最大BLOCK_ID的情況,重建分割槽索引即可,命令如下:

ALTER INDEX IDX_TEST_TABLE REBUILD PARTITION P201201


5)處理完後,再次執行RESIZE操作,資料檔案大小修改成功。


最後,因為同個檔案號上可能出現多個分割槽表,分割槽索引需要處理的情況,建議像第五步寫成批量執行,提高效率。


關於shrink space降低高水位,可以參考博文Oracle delete操作隱藏著你可能不知道的祕密