ORACLE回滚段表空间数据文件丢失或损坏处理方法

问题描述：
这是一个回滚段表空间数据文件丢失或损坏的情景，这时oracle不能识别相应的数据文件。当你试图startup数据文件时会报ORA-1157，ORA-1110，并且可能会伴随着标识操作系统级别的错误，比如ORA-7360。当你试图以shutdown normal或shutdown immediate模式关闭数据库时会导至ORA-1116,ORA-1110,并可能伴随标识操作系统级别的错误，比如ORA-7368，有时以正常方式shutdown数据库根本shutdown不下来。

警告：
文章中所提及的步骤是供oracle的全球技术支持使用的。特别是步骤6中的_corrupted_rollback_segments参数，使用后需要重建数据库，在使用这个参前请观察一下所有其它的选项。

解决方法解释：

如下的解决方法取于检测问题出现时数据库所处于状态:

I. 数据库是处于关闭状态的。
试图打开数据库时报ORA-1157和ORA-1110错误，这时的解决方法取于数据库是否是正常shutdown的(使用normal或immediate选项。

I.A.数据库是正常shutdown的

如果数据数据库是正常shutdown的，最简单的解决方法是以offline drop选项删除丢失或损坏的数据文件，以restriceted模式打个数据库，删除并重建这个数据文件所属的那个回滚表空间。如果数据库是以shutdown abort或自己崩溃掉的则不要遵循这个过程。

步骤如下：

1、确认数据库是正常shutdown的。可以检查alter.log这个文件，定位到最后几行看是否可以看到如下的信息：
"alter database dismount
Completed: alter database dismount"

这当然也包括以正常方式shutdown,接然试图启动数据库确失败的状况。如果最近一次你是以shutdown abort方式关闭数据库的或数据库是自己crashed掉的，你应用使用下面的I.B的方法。

2、在init<sid>.ora中把属于丢失数据文件的回滚段从ROLLBACK_SEGMENTS参数中去掉。如果你不能确信是哪个回滚段，可以简单的把ROLLBACK_SEGMENTS这个参数注释掉。

3、以restricted模式mount数据库
STARTUP RESTRICT MOUNT;

4、Offline drop丢失或损坏的那个数据文件。
ALTER DATABASE DATAFILE '<full_path_file_name>' OFFLINE DROP;

5、打开数据库
ALTER DATABASE OPEN；
如果返回"Statement processed"这条信息，转到第7步.
如果得到ORA-604,ORA-376,和ORA-1110错误，转到第6步。

6、因为打开数据库失败，shutdown掉数据库并且编辑int<SID>.ora这个文件。注释掉ROLLBACK_SEGMENTS这个参数，并且在init<SID>.ora文件中加入如下一行：
_corrupted_rollback_segments = (<rollback1>,...,<rollbackN>)
这个参数应当包含ROLLBACK_SEGMENTS中所有的回滚段。

需要注意的是这个参数只能在指定的情况下或在oracle的全球持术支持的指导下才应使用，然后以restricted模式打开数据库：

STARTUP RESTRICT

7、删除掉那个文件所属的回滚段表空间。
DROP TABLESPACE <tablespace name> INCLUDING CONTENTS;

8、重建回滚段表空间及回滚段，创建完后使它们online.

9、使数据库所有用户都可用。
ALTER SYSTEM DISABLE RESTRICTED SESSION;

10、在init<SID>.ora中把你重新创建的回滚段再一次包括进来，如果你使用了第6步则移除掉CORRUPTED_ROLLBACK_SEGMENTS这个参数。

I.B.数据库不是正常shutdown的

这种情况，数据库最近一次是用shutdown abort或crashed掉关闭，回滚段中几乎一定包含着活动的事务。因此，坏的那个数据文件不能脱机(offline)或是drop掉，你必需从备份恢复这个文件。如果数据为是处于非归档模式的，只有最近的一些事务日志还没有被重写掉的情况你才能成功恢复这个文件。如果这个文件的备份也是无效的，联系一下oracle的技术支持吧。

步骤如下：

1、从备份中恢复丢失的那个数据文件.

2、mount 上数据库

3、执行如下的查询：
SELECT FILE#,NAME,STATUS FROM V$DATAFILE;
如果数据文件的状态是offline的，你必需先把它联机了：
ALTER DATABASE DATAFILE '<full_path_file_name>' ONLINE;

4、执行如下的查询：

SELECT V1.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP# ;

这将列出所有的联机的重做日志和他们的序号及首次改变号(first change numbers).

5、如果这个数据库是非归档模式的，执行如下的查询：
SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;
如果其中的CHANG#比4中的最小的那个FIRST_CHANGE#大的话，用联机日志就可以完成恢复。

6、如果CHANG#比4中的最小的那个FIRST_CHANGE#小，则数据库是不能恢复的，可以联系一下oracle的技术支持。

译者插入：如果你真是非归档方式且这个文件的备份也是无效的，如果你认为可以丢失回滚段中的那事务，你可以用I.A中从第6步的方法，这时可以打开数据库，应立即做一个备份，因为库中的数据有些不一致。

RECOVER DATAFILE '<full_path_file_name>'

7、确认所有的日志都被恢复，只到你收到"Media recovery complete"信息。

8、打开数据库

II. 数据库是启动着的

如果你检测到丢失或损坏了回滚段表空间的数据文件，并且数据库是运行着的，不要把它down掉。在很多情况下，数据库是启着的比关闭着解决问题更容易些。

这种情况的两种可能的解决方法:

A)使丢失的那个数据文件offline,并从备份中恢复它，这种情况适用于数据库是处于归档方式的。

B)另一个方法是offline掉所有的那个文件所属表空间的回滚段，drop那个表空间,然后得建它们。你可能不得不杀掉那些使用着回滚段的进程，以便使它offline.

方法II.A:从备份恢复那个数据文件

这个方法只有你的库是在归档方式下才能使用。

1、脱机(offline)那个丢失的数据文件。
ALTER DATABASE DATAFILE '<full_path_file_name>' OFFLINE;

提示：其于目前数据库的事务量，你可能需要建一个临时的回滚表空间和一些临时的回滚段以备正常业务运行。

2、从备份中恢复(restore)那个数据文件。

3、执行如下命令

SELECT V1.GROUP#, MEMBER, SEQUENCE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP# ;
这将列出所有的联机的重做日志和他们的序号及首次改变号(first change numbers).

4、得用联机日志及归档日志恢复那个文件
RECOVER DATAFILE '<full_path_file_name>'

5、确认所有的日志都被恢复，只到你收到"Media recovery complete"信息。

6、使这个数据文件online
ALTER DATABASE DATAFILE '<full_path_file_name>' ONLINE;

方法II.B:重建回滚表空间

这种方法不必考虑数据库是否是归档模式的。

步骤如下：

1、试图脱机所有的丢失或损坏数据文件所在回滚表空间中所包含的回滚段。
ALTER ROLLBACK SEGMENT <rollback_segment> OFFLINE;
重复执行这个命令直到所包含的回滚段都脱机.

2、检查回滚段的状态。
在drop掉它们之前它们必需是offline状态的。
SELECT SEGMENT_NAME, STATUS FROM DBA_ROLLBACK_SEGS
WHERE TABLESPACE_NAME = '<TABLESPACE_NAME>';

3、删除掉所有脱机的c。
DROP ROLLBACK SEGMENT <rollback_segment>;

4、处理那些保持online状态的回滚段
重复执行2一下的命令，如果回滚段在执行1中命令仍保扭亏为盈"ONLINE"状态，意味着它之中有活动的事务，你可以用如下的查询来确认一下：
SELECT SEGMENT_NAME, XACTS ACTIVE_TX, V.STATUS
FROM V$ROLLSTAT V, DBA_ROLLBACK_SEGS
WHERE TABLESPACE_NAME = '<TABLESPACE_NAME>' AND SEGMENT_ID = USN;
如果这个查询没有结果返回，意味着没有事务在这些回滚段中了。哪果有结果返回，那些不能offline的回滚段的状态应为"PENDING OFFLINE"。可以用5中的方法把这些事务杀掉。

5、强制使有活动事务的回滚段脱机
执行如下查询，看这些"PENDING OFFLINE"的回滚段包含哪些事务。
SELECT S.SID, S.SERIAL#, S.USERNAME, R.NAME "ROLLBACK"
FROM V$SESSION S, V$TRANSACTION T, V$ROLLNAME R
WHERE R.NAME IN ('<PENDING_ROLLBACK_1>', ... , '<PENDING_ROLLBACK_N>')
AND S.TADDR = T.ADDR AND T.XIDUSN = R.USN;

用ALTER SYSTEM KILL SESSION '<SID>, <SERIAL#>';语句杀掉这些事务，重复执行上面的查询，直到没有事务存在，这时运行一下2中的查询，确认这些回滚段己经处于offline状态,并用3中的语句把它们drop掉。

6、删除这个回滚表空间。
DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS;
如果语句执行失败，请与oracle技术支持联系，否则转向7

7、重建回滚段表空间。

8、重建回滚段，并使它们联机(online)。

译者按：

回滚段表空间的数据文件丢失或损坏在实际中是比较棘手和常见的，产生这种问题 的原回很多的，比如介质的损坏、人为的误操作、机器的突然的断电等等。

建议没实践过这种操作的oracle的爱好者可以模拟一下这种故障，实际实测一下，注意一定要在测试库，我模拟的方法如下：

1、单独建了一个rbs表空间，并在这个表空间建了一个回滚段rbs_test。

2、指定一个transaction 用这个回滚段

sql>set transaction userollback segment rbs_test;

sql>insert into test values ('2');

sql>insert into test values('3');

3、另开一个telnet窗口telnet至主机，执行如下命令:

sqlplus /nolog

sql>conn / as sysdba

sql>shutdown abort

4、把新加的那个回滚段表空间的数据文件更个名。