一次归档日志被删除导致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 ---这一点比较有迷惑性。