ORACLE备份&恢复案例之四（精品）

 

5.2 损坏控制文件的恢复方法

5.2.1 损坏单个控制文件

损坏单个控制文件是比较容易恢复的，因为一般的数据库系统，控制文件都不是一个，而且所有的控制文件都互为镜相，只要拷贝一个好的控制文件替换坏的控制文件就可以了。

1 、控制文件损坏，最典型的就是启动数据库出错，不能 mount 数据库

SQL>startup

ORA-00205: error in identifying controlfile, check alert log for more info

查看报警日志文件，有如下信息

alter database mount

Mon May 26 11:59:52 2003

ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl'

ORA-27041: unable to open file

OSD-04002: unable to open file

O/S-Error: (OS 2) 系统找不到指定的文件。

2 、停止数据库

SQL>shutdown immediate

3 、拷贝一个好的控制文件替换坏的控制文件或修改 init.ora 中的控制文件参数，取消这个坏的控制文件。

4 、重新启动数据

SQL>startup

说明：

1 、损失单个控制文件是比较简单的，因为数据库中所有的控制文件都是镜相的，只需要简单的拷贝一个好的就可以了

2 、建议镜相控制文件在不同的磁盘上

3 、建议多做控制文件的备份，长期保留一份由 alter database backup control file to trace 产生的控制文件的文本备份

5.2.2 损坏全部控制文件

损坏多个控制文件，或者人为的删除了所有的控制文件，通过控制文件的复制已经不能解决问题，这个时候需要重新建立控制文件。

同时注意， alter database backup control file to trace 可以产生一个控制文件的文本备份。

以下是详细重新创建控制文件的步骤

1 、关闭数据库

SQL>shutdown immediate;

2 、删除所有控制文件，模拟控制文件的丢失

3 、启动数据库，出现错误，并不能启动到 mount 下

SQL>startup

ORA-00205: error in identifying controlfile, check alert log for more info

查看报警日志文件，有如下信息

alter database mount

Mon May 26 11:53:15 2003

ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl'

ORA-27041: unable to open file

OSD-04002: unable to open file

O/S-Error: (OS 2) 系统找不到指定的文件。

4 、关闭数据库

SQL>shutdown immediate;

5 、在 internal 或 sys 下运行如下创建控制文件的脚本，注意完整列出联机日志或数据文件的路径，或修改由 alter database backup control file to trace 备份控制文件时产生的脚本，去掉多余的注释即可。

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE "TEST" NORESETLOGS NOARCHIVELOG

MAXLOGFILES 32

MAXLOGMEMBERS 2

MAXDATAFILES 254

MAXINSTANCES 1

MAXLOGHISTORY 226

LOGFILE

GROUP 1 'D:ORACLEORADATATESTREDO01.LOG' SIZE 1M,

GROUP 2 'D:ORACLEORADATATESTREDO02.LOG' SIZE 1M,

GROUP 3 'D:ORACLEORADATATESTREDO03.LOG' SIZE 1M

DATAFILE

'D:ORACLEORADATATESTSYSTEM01.DBF',

'D:ORACLEORADATATESTRBS01.DBF',

'D:ORACLEORADATATESTUSERS01.DBF',

'D:ORACLEORADATATESTTEMP01.DBF',

'D:ORACLEORADATATESTTOOLS01.DBF',

'D:ORACLEORADATATESTINDX01.DBF'

CHARACTER SET ZHS16GBK;

-- Recovery is required if any of the datafiles are restored backups,

-- or if the last shutdown was not normal or immediate.

RECOVER DATABASE

--if the last shutdown was not normal or immediate

--noarchive

-- RECOVER DATABASE UNTIL CANCELUSING BACKUP CONTROLFILE

--archive

-- RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL

-- Database can now be opened normally.

ALTER DATABASE OPEN;

--if recover database until cancel

--ALTER DATABASE OPEN RESETLOGS;

6 、如果没有错误，数据库将启动到 open 状态下。

说明：

1 、重建控制文件用于恢复全部数据文件的损坏，需要注意其书写的正确性，保证包含了所有的数据文件与联机日志

2 、经常有这样一种情况，因为一个磁盘损坏，我们不能再恢复 (store) 数据文件到这个磁盘，因此在 store 到另外一个盘的时候，我们就必须重新创建控制文件，用于识别这个新的数据文件，这里也可以用这种方法用于恢复

5.3 损坏回滚数据文件的恢复方法

回滚段表空间中的一个数据文件丢失或者损坏导致数据库无法识别它，在启动数据库的时候会出现 ORA-1157, ORA-1110 的错误，或者操作系统级别的错误，例如 ORA-7360 。在关闭数据库的时候 (normal 或者 immediate) 会出现 ORA-1116, ORA-1110 的错误，或者操作系统级别的错误，例如 ORA-7368 。

感谢 coolyl 的辛勤工作，关于回滚段的大部分内容都是摘自他在 itpub 的文章。

5.3.1 损坏数据文件，但数据库处于Open状态

如果你发现有回滚段的数据文件丢失或者损坏了，而此时的数据库是处于打开的状态下并且在运行，就千万不要关闭数据库了，因为在大多数的情况下打开的时候比关闭的时候好解决问题一些。

一般也是存在有两种情况：

A 。是 offline 丢失或损坏的数据文件，然后从一个备份中恢复，执行介质恢复以保持一致性。但是这种情况要求数据库是归档方式下才可以采用的。

B 。是 offline 那个存在丢失或损坏的数据文件所在的整个回滚段表空间，然后删除整个回滚段表空间并重建，但是你必须要杀掉那些在回滚段中已经激活的用户进程才可以 offline 的。

通常第一种情况就比较简单实现，但是更多的用户事务将会出错并且回滚。

A 的具体步骤：

1 。 offline 丢失或损坏的数据文件

ALTER DATABASE DATAFILE '<full_path_file_name>' OFFLINE;

2 。从一个有效的备份中恢复。

3 。执行以下查询

SELECT V1.GROUP#, MEMBER, SEQUENCE#

FROM V$LOG V1, V$LOGFILE V2

WHERE V1.GROUP# = V2.GROUP# ;

这个将列出你的所有 redolog 文件以及它们所代表的 sequence numbers 。

4 。恢复数据文件。

RECOVER DATAFILE '<full_path_file_name>'

5 。确信你应用了所有的 redolog 文件，直至出现提示信息 "Media recovery complete" 。

6 。 online 那个数据文件。

ALTER DATABASE DATAFILE '<full_path_file_name>' ONLINE;

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 、熟悉没有备份或简单的非常规备份与恢复的方法。