一次归档日志被删除导致offline的datafile 无法访问的问题
一次归档日志被删除导致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 ---这一点比较有迷惑性。