offline和online的初步研究

前几天碰到这样一件事情：一个生产库上DATA表空间，其中有20几个文件，但是有一个文件是处于offline drop状态，这个文件在物理上早就被删除了。

将这个表空间offline temporary下来后，就再也无法online起来了，从而业务也无法运行。这个表空间有60个G左右，重新导入数据的话，时间太长了。。。

环境：

oracle 8.1.6.3 32bit

os:aix 4.3.3

数据库大小为170G左右，非归档。

当是为了将这个表空间online，我们试了多种方法，将该数据文件创建回去，offline drop,重建控制文件等，均不成功。最后不得不采用bbed和dul修改该文件的scn号，使的在online时，oracle不恢复该数据文件。这种方法最后是成功了。

事后我想到另外一个思路就是手工修改数据字典，于是就开始了表空间online和offline的研究。。。

通过10046事件跟踪，可以得知oracle在offline过程中做了以下事情：

1.首先oracle会在system表空间中产生一个defered回滚段。

2.将该回滚段的信息插入到seg$基表中。其type为3即临时段。

3.更新ts$基表，将表空间变为offline,且写入defered回滚段的信息（即ts$表中的undofile#和undoblock#字段)。

4.将defered回滚段的类型由type变为save undo类型。

从trace文件中，只能得出上面几件事情，但是从后面的研究可以得知，在这些过程，oracle还有一个内部触发器，修改了x$ktfbhc基表，将ktfbhccval字段改为1，这意味着该数据文件是不可用的。这个字段在alter database datafile online和alter tablespace offline时会被修改。

接着对online做跟踪，可以发现oracle做了以下的事情：

1.更新ts$基表的scnwrp和scnbas字段

2.更新ts$基表的online$字段为1，scnwrp和scnbas字段为0。online$字段为1，表示为online，为2表示offline,为3表示invalid。

3.更新seg$基表，将对应的defered回滚段更新为临时段，即type#改为3

4.更新ts$基表，将undofile#和undoblock#字段更新为0

5.drop defered回滚段

delete from seg$ where ts#=:1 and file#=:2 and block#=:3

根据 这些步骤，我手工做了一个测试：

首先创建一个test表空间：

create tablespace test datafile 'e:1.dbf' size 10M;

alter tablespace test add datafile 'e:2.dbf' size 10M;

然后将e:2.dbf offline drop掉：

alter database datafile 'e:2.dbf' offline drop;

在test表空间中创建一个表test:

create table test tablespace test as select *from dba_tables;

然后做几次切换，将所有的日志都冲掉，以防recover datafile成功。

alter system switch logfile;

然后将表空间test offline temporary:

alter tablespace test offline temporary;

接着试着将test表空间online：

alter tablespace test online;

此时会报出数据文件'e:2.dbf'需要recover，因为没有相应的日志，recover datafile显然不成功。

然后将数据文件'e:1.dbf' online起来：

alter database datafile 'e:1.dbf' online;

然后手工修改数据字典ts$和seg$。再重起数据库，发现test表空间是online状态,数据文件e:1.dbf也是online状态，但是从v$datafile的enabled字段中可以看出

该数据文件是disabled的，从dba_data_files视图中可以发现e:1.dbf和e:2.dbf的字节数均为0.该表空间虽然是online的，但是select * from test;就会报出错误，说数据文件e:1.dbf此时不可读取。

由于v$datafile和dbA_data_files主要是从x$ktfbhc中获取信息的。查询x$ktfbhc表，发现e:1.dbf和e:2.dbf文件的ktfbhccval字段为1。也就是说在表空间offline下来后，即使alter database datafile online也不会修改此字段。如果是数据文件offline下来的话，将数据文件online起来是会修改的。

由于x$ktfbhc表是无法直接update的，研究至此，就下不去了。。。

from：http://blog.itpub.net/post/3185/25925