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


问题描述:
这是一个回滚段表空间数据文件丢失或损坏的情景,这时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

 1<sid>.ora中把属于丢失数据文件的回滚段从ROLLBACK_SEGMENTS参数中去掉。如果你不能确信是哪个回滚段,可以简单的把ROLLBACK_SEGMENTS这个参数注释掉。   
 2  
 33、以restricted模式mount数据库   
 4STARTUP RESTRICT MOUNT;   
 5  
 64、Offline drop丢失或损坏的那个数据文件。   
 7ALTER DATABASE DATAFILE '<full_path_file_name>' OFFLINE DROP;   
 8  
 95、打开数据库   
10ALTER DATABASE OPEN;   
11如果返回"Statement processed"这条信息,转到第7步.   
12如果得到ORA-604,ORA-376,和ORA-1110错误,转到第6步。   
13  
146、因为打开数据库失败,shutdown掉数据库并且编辑int<sid>.ora这个文件。注释掉ROLLBACK_SEGMENTS这个参数,并且在init<sid>.ora文件中加入如下一行:   
15_corrupted_rollback_segments = (<rollback1>,...,<rollbackn>)   
16这个参数应当包含ROLLBACK_SEGMENTS中所有的回滚段。   
17  
18需要注意的是这个参数只能在指定的情况下或在oracle的全球持术支持的指导下才应使用,然后以restricted模式打开数据库:   
19  
20  
21STARTUP RESTRICT   
22  
237、删除掉那个文件所属的回滚段表空间。   
24DROP TABLESPACE <tablespace name=""> INCLUDING CONTENTS;   
25  
268、重建回滚段表空间及回滚段,创建完后使它们online.   
27  
289、使数据库所有用户都可用。   
29ALTER SYSTEM DISABLE RESTRICTED SESSION;   
30  
3110、在init<sid>.ora中把你重新创建的回滚段再一次包括进来,如果你使用了第6步则移除掉CORRUPTED_ROLLBACK_SEGMENTS这个参数。   
32  
33  
34I.B.数据库不是正常shutdown的   
35  
36这种情况,数据库最近一次是用shutdown abort或crashed掉关闭,回滚段中几乎一定包含着活动的事务。因此,坏的那个数据文件不能脱机(offline)或是drop掉,你必需从备份恢复这个文件。如果数据为是处于非归档模式的,只有最近的一些事务日志还没有被重写掉的情况你才能成功恢复这个文件。如果这个文件的备份也是无效的,联系一下oracle的技术支持吧。   
37  
38步骤如下:   
39  
401、从备份中恢复丢失的那个数据文件.   
41  
422、mount 上数据库   
43  
443、执行如下的查询:   
45SELECT FILE#,NAME,STATUS FROM V$DATAFILE;   
46如果数据文件的状态是offline的,你必需先把它联机了:   
47ALTER DATABASE DATAFILE '<full_path_file_name>' ONLINE;   
48  
494、执行如下的查询:   
50  
51SELECT V1.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE#   
52FROM V$LOG V1, V$LOGFILE V2   
53WHERE V1.GROUP# = V2.GROUP# ;   
54  
55这将列出所有的联机的重做日志和他们的序号及首次改变号(first change numbers).   
56  
575、如果这个数据库是非归档模式的,执行如下的查询:   
58SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;   
59如果其中的CHANG#比4中的最小的那个FIRST_CHANGE#大的话,用联机日志就可以完成恢复。   
60  
616、如果CHANG#比4中的最小的那个FIRST_CHANGE#小,则数据库是不能恢复的,可以联系一下oracle的技术支持。   
62  
63译者插入:如果你真是非归档方式且这个文件的备份也是无效的,如果你认为可以丢失回滚段中的那事务,你可以用I.A中从第6步的方法,这时可以打开数据库,应立即做一个备份,因为库中的数据有些不一致。   
64  
65RECOVER DATAFILE '<full_path_file_name>'   
66  
677、确认所有的日志都被恢复,只到你收到"Media recovery complete"信息。   
68  
698、打开数据库   
70  
71  
72待续</full_path_file_name></full_path_file_name></sid></tablespace></rollbackn></rollback1></sid></sid></full_path_file_name></sid>
Published At
Categories with 数据库类
Tagged with
comments powered by Disqus