B
的具体步骤:
1
。
offline
存在丢失或损坏的数据文件的回滚段表空间中的所有回滚段。
ALTER ROLLBACK SEGMENT <rollback_segment> OFFLINE;
2
。检测当然回滚段的状态。
SELECT SEGMENT_NAME, STATUS FROM DBA_ROLLBACK_SEGS
WHERE TABLESPACE_NAME = '<TABLESPACE_NAME>';
3
。删除所有
offline
的回滚段
DROP ROLLBACK SEGMENT <rollback_segment>;
4
。处理那些
online
状态的回滚段。
重新执行第二步的查询
如果你已经执行过
offline
操作的回滚段状态仍然是
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".
接着查看
ACTIVE_TX
列,如果值为
0
,则表明此回滚段中已经没有未处理的事务了,很快就会被
offline
的,然后等它
offline
后重新执行
2
,
3
步后跳至第六步。如果值大于
0
,则继续到第五步。
5
。强制那些包含活动事务的回滚段
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;
最好能直接联系到那些
user
让他们自己去回滚或者提交事务,如果不能做到的话,那就只能强制性的杀掉进程了。
ALTER SYSTEM KILL SESSION '<SID>, <SERIAL#>';
杀掉进程后再过一段时间后回滚段会自动清除那些事务,然后就可以回到第二步继续查询了。
6
。删除回滚段。
DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS;
7
。重建回滚段并
online
它们
说明:
1
、数据库如果是
open
状态,就可以直接在
open
状态下解决问题,没有必要停下数据库,增加
down
机时间
2
、不管上上面那种恢复方法都是正常性的恢复,不会引起数据的不一致或错误。
5.3.2数据库关闭,但是数据文件中没有活动事务
这种情况下最简单的方法就是
offline drop
掉这个坏了的或者丢失的数据文件,然后以
restricted
模式打开数据库然后删除并且重建包含损坏文件的回滚段表空间。
具体步骤如下:
1
。确定数据库是正常的关闭的。方法是可以去查看
alert
文件,到最后看是否有如下信息:
"alter database dismount
Completed: alter database dismount"
如果有的话,就证明数据库是正常关闭的,否则就不能用这个方法去恢复。
2
。修改
init
参数文件,移去
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, and ORA-1110
的错误信息,继续第
6
步。
6
。正常的关闭数据库,然后在
init
文件中注释掉
ROLLBACK_SEGMENTS
,并加入隐含参数
_corrupted_rollback_segments = ( <rollback1>,...., <rollbackN> )
然后以
restricted
模式打开数据库
STARTUP RESTRICT
7
。删除掉那个包含损坏文件的回滚段表空间。
DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS;
8
。重建回滚段表空间,记得创建后要把回滚段都
online
。
9
。重新使数据库对所有用户可用。
ALTER SYSTEM DISABLE RESTRICTED SESSION;
10
。然后正常关闭数据库,修改
init
文件,如果开始只是注释掉了
ROLLBACK_SEGMENTS
的,就去掉注释即可,如果加了隐含参数的,注释掉它,并在
ROLLBACK_SEGMENTS
加入所有的回滚段。
11
。正常启动数据库。
Startup
说明:
1
、这种方法的前提条件是数据库是正常关闭(不是
abort
)可用
2
、这种方法是正常方法,不会引起数据错误
5.3.3 数据库关闭,数据文件中有活动事务,没有可用备份
一般造成这种原因的情况是采用了
shutdown abort
或其它原因异常关机(如断电)导致的。
1
、开启一个事务
SQL> set transaction use rollback segment rbs0;
Transaction set.
SQL> insert into test (a) values (1);
1 row created.
2
、异常关闭
SQL> shutdown abort;
ORACLE instance shut down.
3
、删除
rbs
的一个数据文件
C:>del D:Oracleoradatachenrbs01.
4
、修改
INIT<sid>.ora
rollback_segments=(system)
添加
_corrupted_rollback_segments=(rbs0,rbs1,rbs2
……
)
5
、
SQL>Startup mount
6
、
SQL>alter database datafile ’d:oracleoradatat8irbs01.dbf’ offline drop;
数据库已更改。
7
、
SQL>recover database
;
完成介质恢复。
8
、
SQL>alter database open ;
数据库已更改。
9
、
SQL>select * from v$rollname;
USN NAME
----------------- ---------------------
0 SYSTEM
10
、
SQL>select segment_name,tablespace_name,status from dba_rollback_segs;
SEGMENT_NAME TABLESPACE_NAME STATUS
------------------------------ ------ ------------------------------------
SYSTEM SYSTEM ONLINE
RBS0 RBS NEEDS RECOVERY
RBS1 RBS NEEDS RECOVERY
RBS2 RBS NEEDS RECOVERY
11
、
SQL>drop rollback segment rbs0;
重算段已丢弃。
SQL>drop rollback segment rbs1;
重算段已丢弃。
SQL>drop rollback segment rbs2;
重算段已丢弃。
12
、
SQL>select segment_name,tablespace_name,status from dba_rollback_segs;
SEGMENT_NAME TABLESPACE_NAME STATUS
------------------------------ ------ ------------------------------------
SYSTEM SYSTEM ONLINE
13
、
SQL>drop tablespace rbs including contents;
表空间已丢弃。
14
、重建新的回滚表空间及回滚段,并联机。
15
、
SQL>shutdown abort
16
、再修改
INIT<sid>.ora
rollback_segments=(rbs0,rbs1,rbs2)
将
_corrupted_rollback_segments=(rbs0,rbs1,rbs2)
去掉。
17
、
SQL>startup
1
、这种办法是万不得以的时候使用的方法,如果有备份,都建议从备份上进行恢复
2
、这种方法恢复的数据库,可能会引起数据库的数据错误
3
、恢复成功以后,建议
exp/imp
数据,并重新分析检查数据库
5.3.4 数据库关闭,数据文件中有活动事务,从备份恢复
1
。从一个有效的备份中恢复损坏的数据文件。
2
。
mount
数据库。
3
。执行以下查询
SELECT FILE#, NAME, STATUS FROM V$DATAFILE;
如果发现要恢复的文件是
offline
状态的话,要先
online
它
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# ;
这个将列出
redlog
文件所代表的
sequence
和
first change numbers
。
5
。如果数据库是非归档情况下,执行以下查询:
SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;
如果
CHANGE#
大于最小的
redolog
文件的
FIRST_CHANGE#
,则数据文件可以被恢复,记得在应用日志的时候要把所有
redolog
文件全部应用一遍。
如果
CHANGE#
小于最小的
redolog
文件的
FIRST_CHANGE#
,则数据文件就不可以被恢复了,这时候你要从一个有效的全备份中去恢复数据库了,如果没有全备份的话,那你就只能把数据库强制打开到一个不一致的状态去
exp
出数据,然后重新建库导入数据,因为这种方式的恢复
oracle
是不推荐用户自己做的,所以这里我就不详细说明了。
6
。恢复数据文件
RECOVER DATAFILE '<full_path_file_name>'
7
。确信你应用了所有的
redolog
文件,直至出现提示信息
"Media recovery complete"
。
8
。打开数据库。
说明:
1
、这种方法要求在归档有备份的方式下进行,而且是建议方式
2
、这种方法不会导致数据库的错误
5.4 损坏临时数据文件的恢复方法
临时数据文件的恢复是比较简单的,因为临时文件中不涉及到其它的有用的数据,所以可以删除后重建
1
、关闭数据库
SQL>shutdown immediate
2
、删除临时数据文件,模拟媒体失败
3
、启动数据库,检测到文件错误
4
、脱机该数据文件
SQL>alter database datafile ‘
文件名全名
’ offline drop;
5
、打开数据库
SQL>alter database open
6
、删除该临时表空间
SQL>drop tablespace temp(
或其它临时表空间名称
);
7
、重新创建该表空间,并重新分配给用户
说明:
1
、临时数据文件是非重要文件,不保存永久数据,可以随时删除重建,不影响数据库的数据安全
2
、如果重新建立以后,别忘了重新分配给用户。
第六章. 常见恢复误区
1
、可以不需要备份,只有归档就能进行数据库的向前的恢复
答:这个在
ORACLE 9i
以前起码是不可能的,在别的数据库我也没有听说过,不完全恢复的主要思路是利用不完全点之前的备份,加上归档日志,恢复到不完全恢复点,
9i
中出现了一个
flashback
的特性,这个特性的使用,也是有很多局限的。
2
、进行不完全恢复只需要拷贝一个需要恢复的备份数据文件
答:不完全恢复需要拷贝所有的数据文件,最好包括临时数据文件在内,否则需要另外的处理,如果有一个数据文件的
SCN
大于不完全恢复点,那么这个恢复都将是失败的。
3
、使用
RMAN
目录与目标数据库在同一数据库能很好进行数据库的恢复
答:使用恢复目录与目标数据库在同一个数据库中,将存在很大的恢复局限,如该数据库的系统数据文件的损害,数据库根本不能
open
,那么
RMAN
也就无法连接恢复目录,也就不存在恢复了。
第七章. 小结
这里我们反复演示了多种情况下的恢复方案,通过这些演示,我们应该掌握了如下内容:
1
、利用
OS
与
RMAN
进行各种常规备份与恢复。
2
、熟悉没有备份或简单的非常规备份与恢复的方法。