一次歸檔日誌被刪除導致offline的datafile 無法訪問的問題，offlinedatafile

一次歸檔日誌被刪除導致offline的datafile 無法訪問的問題，offlinedatafile

一次歸檔日誌被刪除導致offline的datafile 無法訪問的問題

其實，該標題改為“rebuid online 索引 遇到control file sequential read 等待事件的問題 ”比較合適

版本：10.2.0.5, asm 方式的2個節點rac，rhel5.5

其實該問題的解決思路，應該說是搶救資料出來。
該datafile是索引資料表空間的非第一個資料檔案。app的開發工程師說該資料表空間內只有index，沒有table

使用如下語句查詢出該datafile內含有的object:

select distinct owner, segment_name, segment_type, partition_name  from dba_extents where relative_fno IN (select relative_fno                          from dba_data_files                         where tablespace_name = 'XXX'                           and file_name = 'YYYY');

--注意：該語句寫的不夠完善，請提出寶貴意見。

從以上的查詢結果中，可以看到，不包括table，僅僅是index 以及index 的partition

根據這個實際情況，工程師決定使用rebuild online的方式來重構索引，具體語句為：

alter index index_owner.index_name rebuild partition partition_name online tablespace XXX parallel 20;

--注釋：也就是說，還是將索引放在原來的XXX資料表空間。

以上語句的執行時間超過6小時，不斷的執行v$session的查詢，以確定20個並行session在v$session中的等待事件為(v$session.event列)：
絕大多數並行session在絕大多數的執行次數中，都是 control file sequential read 等待事件，還有零星的 enq: RO - fast object reuse等待事件

這個等待感覺極不正常。以”control file sequential read“在mos上搜尋，沒有找到有價值的資訊。

事後截取了6小時其中1小時的awr，control file sequential read 等待事件是相當突出：

 

後來去查詢XXX資料表空間的使用率，發現資料表空間使用率的指令碼（見下）的輸出居然沒有該XXX資料表空間：

--這一般意味著該資料表空間中的dba_data_files.bytes已經全部使用了。（這句話等於：在不考慮datafile 自動擴充的情況下，資料表空間滿了。）

SQL> select f.tablespace_name tablespace_name,round((d.sumbytes/1024/1024/1024),2) total_g,  2  round(f.sumbytes/1024/1024/1024,2) free_g,  3  round((d.sumbytes-f.sumbytes)/1024/1024/1024,2) used_g,  4  round((d.sumbytes-f.sumbytes)*100/d.sumbytes,2) used_percent  5  from (select tablespace_name,sum(bytes) sumbytes from dba_free_space group by tablespace_name) f,  6  (select tablespace_name,sum(bytes) sumbytes from dba_data_files group by tablespace_name) d  7  where f.tablespace_name= d.tablespace_name  8  order by  used_percent desc;  

後來繼續檢查該datafile的資訊，發現該XXX資料表空間一共4個datafile,除了那個offline掉的datafile，剩餘還有3個，每個datafile的bytes 大概6G左右，而這些datafile的maxbytes為32GB
於是工程師決定resize datafile：

alter database datafile 'datafile全部路徑\idx_tool3.dbf' resize 20000M;--該datafile為online的datafile，不是offline的datafile

該datafile 被resize完畢後， 下面的的語句：

alter index index_owner.index_name rebuild partition partition_name online tablespace XXX parallel 20;

也立即執行完畢了。

 

因此，也就推斷出一件事情：
索引rebuild online 的過程中，只會去使用該資料表空間內各個datafile的dba_data_files.bytes大小的容量，不會去使用(dba_data_files.maxbytes - dba_data_files.bytes)大小的容量。
若是rebuild 開始前，該資料表空間已經用完（“不考慮datafile的自動擴充屬性，只考慮dba_data_files.bytes”上的用完），那麼開始rebuild後，在索引rebuild online 的過程中，不會報ora-錯誤，等待事件大多是control file sequential read ---這一點比較有迷惑性。