ORACLE热备份恢复手册收藏

概要
1.1. 本文的目的

为了模拟测试oracle热备份的各种恢复情况，同时给以后工程人员一些实施借鉴，特地整理了本文档，在其中记录各种恢复的情况，以方便恢复时使用。
1.2. 系统概况

系统环境：hp unix11 oracle 9201

数据情况：一个系统文件、3个联机日志、一个回滚段表空、一个undo表空间、其他的数据文件，数据库当前使用undo。

备份方式：热备份

备份文件：数据文件、归档日志、控制文件、初始化文件。
2.   恢复情况介绍
2.1. 模拟回滚表空间损坏丢失

当初设计时系统就同时并存了两种回滚段管理模式，目的就是当其中的一个出现问题的话，就可以立刻恢复。Undo与8i时回滚段比，它的优势是自动管理回滚段，简化了管理工作。

下面介绍回滚表空间数据文件损坏时的恢复方式：

假设在undo表空间数据文件损坏时拥有所有的备份，系统存在回滚段表空间。

在数据库运行状态下删除undo表空间数据文件。

此时如果向数据库中写入数据，会出现如下错误：

SQL> exec sp_insert_del;
BEGIN sp_insert_del; END;

*
ERROR at line 1:
ORA-01116: error in opening database file 4
ORA-01110: data file 4: '/opt/oradata/openview/RBS2_1.dbf'
ORA-27041: unable to open file
HP-UX Error: 2: No such file or directory
Additional information: 3
ORA-06512: at "DBBACKUP.SP_INSERT_DEL", line 9
ORA-06512: at line 1

此时需要作的是修改数据库初始化参数，将他修改成为使用rollback_segment,同时将数据库加载，

SQL>startup mount pfile='/opt/oracle/admin/openview/initopenview.ora'

然后删除回滚表空间的数据文件

SQL>alter database defile 4 offline off;

SQL>alter database open;

但是数据库启动后，察看如下信息，发现有大量属于回滚表空间的回滚段

SQL>select * from dba_rollback_segs;

此时如果想恢复原来的回滚表空间，需要修改初始化文件，在其中加入隐含参数_CORRUPTED_ROLLBACK_SEGMENTS，在其中加入回滚表空间的回滚段后，重新启动数据库，然后删除回滚表空间

SQL>drop tablespace undo2 INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS;

重新创建回滚表空间后，修改初始化参数后，然后重新启动数据库即可。

总结：当回滚表空间发生损坏时，需要将系统重新启动，这是必须的，对于24小时系统来说，这无疑是极为不利的一种情况，在这种情况下，需要的是双机热备的系统来保证系统24小时不间断运行。当出现系统崩溃的情况时，毫无疑问，需要备份机立即切换来保证系统运行，然后及时恢复生产系统。
2.2. 模拟非系统数据文件丢失

当非系统数据文件损坏时，有三种恢复方式，一种是拥有数据文件备份、归档日志备份以及其他的相关文件，此时可以做到的是完全的恢复；一种是有数据文件备份，但是归档日志不全；一种是没有数据文件备份，此时就需要将系统down下，然后恢复。

下面介绍第一种情况的恢复：

在数据库运行状态下删除数据文件，如果此时系统没有down机，那么采用以下方式恢复

SQL> alter database datafile '/opt/oradata/openview/ts_iptool_1.dbf' offline;

Database altered.

将备份文件拷贝回来，将数据文件online,提示需要恢复数据文件。

SQL> alter database datafile '/opt/oradata/openview/ts_iptool_1.dbf' online;
alter database datafile '/opt/oradata/openview/ts_iptool_1.dbf' online
*
ERROR at line 1:
ORA-01113: file 19 needs media recovery
ORA-01110: data file 19: '/opt/oradata/openview/ts_iptool_1.dbf'

执行媒体恢复，可以将数据文件online，由于有所有的归档日志和联机日志都存在，因此没有数据丢失。

SQL> recover datafile '/opt/oradata/openview/ts_iptool_1.dbf';
Media recovery complete.
SQL> alter database datafile '/opt/oradata/openview/ts_iptool_1.dbf' online;

Database altered.

总结：在数据库运行状态下，如果有数据文件损坏不能读取时，数据库不至于down下，此时如果发现的话，在拥有所有备份和归档日志、联机日志的情况下，可以及时恢复。

当数据库已经宕下时，需要在数据加载时恢复，将数据文件拷贝到正确的位置后，恢复步骤如下：

SQL> startup mount

SQL> recover database;

SQL>alter database open;

总结：在这种情况下，对于24小时系统来说是一个损失，为了保证系统的正确运行，需要双机备份来保证系统的高可用性。

仅仅拥有数据文件和部分归档日志的恢复：

如果数据库处于打开状态时，先将数据文件offline

SQL> alter database datafile '/opt/oradata/openview/ts_iptool_1.dbf' offline;

Database altered.

将备份文件拷贝回来，执行媒体恢复

SQL> recover datafile '/opt/oradata/openview/ts_iptool_1.dbf' until cancel;

选择auto，尽量多的实施归档日志。

然后再次执行以下语句，选择cancel，然后将数据文件online

SQL> recover datafile '/opt/oradata/openview/ts_iptool_1.dbf' until cancel;

Media recovery complete.
SQL> alter database datafile '/opt/oradata/openview/ts_iptool_1.dbf' online;

Database altered.

当数据库crash时，将

没有任何备份的恢复：备份文件拷贝回来，执行媒体恢复，

SQL> recover datafile '/opt/oradata/openview/ts_iptool_1.dbf' until cancel;

选择auto，尽量多的实施归档日志。

然后再次执行以下语句，选择cancel

SQL> recover datafile '/opt/oradata/openview/ts_iptool_1.dbf' until cancel;

Media recovery complete.
    总结：将数据库打开后，最好作一个数据库全备份。

当系统没有备份时发生数据文件损坏的情况时，不可避免的会丢失数据，它的恢复比较简单，但是必须要将系统down下，将数据库启动到mount时，进行恢复。

SQL> startup mount

SQL> alter database datafile 6 offline drop;

SQL>alter database open;

此时在系统中还保留有丢失数据文件的字典信息，系统处于不一致状态。如果数据文件表空间的表remove到其他表空，可以将表空间删除重建，并将表再次move回来。

总结：这种情况下不可避免的会丢失数据，可能会丢失重要的数据文件，如果拥有备份，最多只能恢复到备份那一时刻的数据。
2.3. 模拟系统数据文件丢失

在数据库运行状态下删除系统数据文件，系统崩溃了，当拥有所有的备份时，系统是可以恢复的，恢复得步骤和2.2的第一种情况一样。
2.4. 模拟非当前联机日志文件丢失

如果丢失的联机日志不是当前的文件，那么他的恢复比较简单，只需要将日志清除即可。有两种情况，如果当联机日志已经归档，在数据库打开状态下删除不活动的联机日志时，可以用以下方式恢复。

SQL> alter database clear logfile group groupnumber;

或者在数据库加载时运行以上sql，系统会自动生成一个日志文件。

下面是一个恢复的例子：

SQL> select GROUP#, SEQUENCE#, ARCHIVED,STATUS  from v$log;



    GROUP#      SEQUENCE#        ARCHIVED STATUS

----------  ---------- ---------- --- ----------------

         4          209715200         YES INACTIVE

         5          209715200         YES INACTIVE

         6          209715200         NO  CURRENT

SQL> !

$ mv log4.log log.log

$ exit

SQL> alter system switch logfile;

alter system switch logfile

*

ERROR at line 1:

ORA-03113: end-of-file on communication channel

当删除一个非当前的日志文件后系统切换到此文件时，不能读取次文件时，系统crash.将系统重新启动，发现系统不能打开。此时数据库处于mount状态

SQL> startup

ORACLE instance started.



Total System Global Area  267479512 bytes

Fixed Size                   735704 bytes

Variable Size             184549376 bytes

Database Buffers           81920000 bytes

Redo Buffers                 274432 bytes

Database mounted.

ORA-00313: open failed for members of log group 4 of thread 1

ORA-00312: online log 4 thread 1: '/opt/oradata/openview/log4.log'

修改数据库，清除归档的日志，然后将数据库打开。

SQL> alter database clear logfile group 4;

Database altered.

SQL> alter database open;

Database altered.

察看联机日志文件

SQL> !

$ ls *.log

log4.log  log5.log  log6.log

察看日志文件，发现日志组4 已经可以使用。

SQL> select GROUP#, SEQUENCE#, ARCHIVED,STATUS  from v$log;

    GROUP#     SEQUENCE#      ARCHIVED STATUS

----------  ---------- ----------   ----------------

         4         209715200       NO  CURRENT

         5         209715200       YES INACTIVE

         6         209715200       YES INACTIVE

假如在丢失已归档的联机日志时能够及时发现，那么就可以在数据库打开状态下清除日志，自动生成一个日志文件，保证数据库正常运行。

$ rm log6.log

$ exit

SQL> alter database clear logfile group 6;

Database altered.

$ ls log*.*

log4.log  log5.log  log6.log

总结：在恢复完成后，由于有一个日志文件没有归档，因此需要立即进行数据库全备份。
2.5. 模拟当前联机日志文件丢失

如果丢失的联机日志是当前的日志文件，如果数据库以及crash，那么需要在mount下进行恢复，恢复步骤也比较复杂。可以通过以下命令来恢复.

SQL>recover database until cancel;

恢复完成后还需要重新设置log来打开数据库.

如果数据库还处于打开状态，那么恢复比较简单，只要执行以下语句就可以恢复

SQL> alter database clear unarchived logfile group groupnumber;

以下举例说明在数据打开状态下，恢复需要执行的步骤。

SQL> !

$ ls log*.log

log4.log  log5.log  log6.log

$ mv log4.log log.log

$ exit

SQL> create table iptpa_test1 (n1 date) tablespace ts_iptool;

Table created.

SQL> insert into iptpa_test1 select sysdate from dual;

1 row created.

SQL> commit;

Commit complete.

SQL> alter system switch logfile;

从数据字典中可以看出日志4处于未归档状态，但是此时它已经被删除了。

SQL> select GROUP#, SEQUENCE#, ARCHIVED,STATUS  from v$log;

    GROUP#     SEQUENCE#      ARCHIVED STATUS

----------  ---------- ----------   ----------------

         4          209715200     NO  ACTIVE

         5          209715200     YES INACTIVE

         6          209715200      NO  CURRENT

重新切换日志，到日志4

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

此时由于找不到日志组4 系统处于悬挂状态。因为此时数据库处于打开状态，可以执行以下命令进行日志清除并重建。

SQL> alter database clear unarchived logfile group 4;

Database altered.

$ ls log*.*

log4.log  log5.log  log6.log

$exit

    此时日志组4的序号是0，日志会在循环到大于系统当前最大的SEQUENCE#才会被使用。

SQL> select GROUP#, SEQUENCE#, ARCHIVED,STATUS  from v$log;



    GROUP#  SEQUENCE# ARC STATUS

---------- ---------- --- ----------------

         4          0 YES UNUSED

         5          7 NO  CURRENT

         6          6 YES INACTIVE

总结：我们知道数据库应该归档的日志没有归档后，需要做的第一件事就是做一个数据库的全备份。

当数据库以及crash，需要恢复的步骤如下：

$ mv log6.log log.bak

$ exit



SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.



Total System Global Area  267479512 bytes

Fixed Size                   735704 bytes

Variable Size             184549376 bytes

Database Buffers           81920000 bytes

Redo Buffers                 274432 bytes

Database mounted.

ORA-00313: open failed for members of log group 6 of thread 1

ORA-00312: online log 6 thread 1: '/opt/oradata/openview/log6.log'

SQL> select GROUP#, SEQUENCE#, ARCHIVED,STATUS  from v$log;



    GROUP#  SEQUENCE# ARC STATUS

---------- ---------- --- ----------------

         4          8 YES INACTIVE

         5          7 YES INACTIVE

         6          9 NO  CURRENT

此时数据库处于mount状态，日志组6处于当前状态，执行清除未归档日志时会出现如下错误。

SQL> alter database clear unarchived logfile group 6;

alter database clear unarchived logfile group 6

*

ERROR at line 1:

ORA-00313: open failed for members of log group 6 of thread 1

ORA-00312: online log 6 thread 1: '/opt/oradata/openview/log6.log'

ORA-27037: unable to obtain file status

HP-UX Error: 2: No such file or directory

Additional information: 3

此时需要执行以下语句恢复数据库，在恢复时为了尽量多的使用归档日志恢复，先选择auto,最后才使用cancel选项。

SQL> recover database until cancel;

Media recovery complete.

SQL> alter database open resetlogs;

Database altered.

SQL> ho ls log*.log

log4.log  log5.log  log6.log

此时系统已经重新生成了日志，但是由于是以resetlogs方式打开的数据库，因此最好进行一下数据库的全备份。

总结：当丢失当前联机日志文件后，肯定会丢失数据，同时丢失归档日志，为了保证恢复的准确性，最好完成恢复后做一个数据库的全备份。
2.6. 模拟控制文件丢失

一般来说一个系统控制文件都有3个一样的互为备份的控制文件。如果仅仅是一个控制文件损坏或者丢失，可以将控制文件拷贝即可。但是由于现在的系统大多上都只有一个硬盘，因此当硬盘坏了的话，控制文件肯定就丢失了。现在就讨论如果控制文件全部丢失时如何恢复系统。

如果有备份的控制文件，注意，必须是使用以下语句生成的：

alter database BACKUP CONTROLFILE TO TRACE as 'crontrolfile.txt' reuse RESETLOGS ;

红色字体是可以备份的控制文件的路径和名称，最好写上绝对路径。

生成的控制文件，事实上是一组sql语句，功能是将数据库启动到nomount下，然后创建控制文件，然后将数据库加载，然后使用备份文件恢复，最后再将数据库以resetlogs方式打开，不过这个文件的注释是shell的注释，需要修改。以下是我做的一个例子。

1.        备份控制文件

  alter database BACKUP CONTROLFILE TO TRACE as '/opt/oradata/openview/cf.txt' reuse RESETLOGS ;

2.        删除控制文件

rm control01.ctl control02.ctl control03.ctl

3.        当数据库的控制文件全部丢失时，是必须用shutdown abort将数据库down下来

SQL> shutdown immeidate

SP2-0717: illegal SHUTDOWN option

SQL> shutdown immediate



ORA-00210: cannot open the specified controlfile

ORA-00202: controlfile: '/opt/oradata/openview/control01.ctl'

ORA-27041: unable to open file

HP-UX Error: 2: No such file or directory

Additional information: 3

SQL> shutdown abort

ORACLE instance shut down.

4.        使用sqlplus "/as sysdba"连接到数据库

5.        将数据库启动到nomount下

SQL> startup nomount

ORACLE instance started.

Total System Global Area  267479512 bytes

Fixed Size                   735704 bytes

Variable Size             184549376 bytes

Database Buffers           81920000 bytes

Redo Buffers                 274432 bytes

6.        创建控制文件，完成后数据库已经处于mount状态

SQL> CREATE CONTROLFILE REUSE DATABASE "OPENVIEW" RESETLOGS  ARCHIVELOG

MAXLOGFILES 128

MAXLOGMEMBERS 5

MAXDATAFILES 500

MAXINSTANCES 1

MAXLOGHISTORY 226

LOGFILE

  GROUP 1 '/opt/oradata/openview/redo01.log'  SIZE 20M,

  GROUP 2 '/opt/oradata/openview/redo02.log'  SIZE 20M,

  GROUP 3 '/opt/oradata/openview/redo03.log'  SIZE 20M

DATAFILE

  '/opt/oradata/openview/system_1.dbf',

  '/opt/oradata/openview/temp_1.dbf',

  '/opt/oradata/openview/RBS1_1.dbf',

  '/opt/oradata/openview/tools_1.dbf',

  '/opt/oradata/openview/OV_DATA.dbf',

  '/opt/oradata/openview/OV_INDEX.dbf',

  '/opt/oradata/openview/OPC_1_1.dbf',

  '/opt/oradata/openview/OPC_2_1.dbf',

  '/opt/oradata/openview/OPC_3_1.dbf',

  '/opt/oradata/openview/OPC_4_1.dbf',

  '/opt/oradata/openview/OPC_5_1.dbf',

  '/opt/oradata/openview/OPC_6_1.dbf',

  '/opt/oradata/openview/OPC_7_1.dbf',

  '/opt/oradata/openview/OPC_8_1.dbf',

  '/opt/oradata/openview/OPC_9_1.dbf',

  '/opt/oradata/openview/OPC_10_1.dbf',

  '/opt/oradata/openview/OPC_INDEX1_1.dbf',

  '/opt/oradata/openview/OPC_INDEX2_1.dbf',

  '/opt/oradata/openview/OPC_INDEX3_1.dbf',

  '/opt/oradata/openview/TS_CM_1.dbf',

  '/opt/oradata/openview/TS_CM_IND_1.dbf',

  '/opt/oradata/openview/TS_PM_1.dbf',

  '/opt/oradata/openview/TS_PM_IND_1.dbf',

  '/opt/oradata/openview/TS_PMTMP_1.dbf',

  '/opt/oradata/openview/TS_TOOL_1.dbf',

  '/opt/oradata/openview/TS_SM_1.dbf',

  '/opt/oradata/openview/TS_FM_PT1_1.dbf',

  '/opt/oradata/openview/TS_FM_PT2_1.dbf',

  '/opt/oradata/openview/TS_FM_PT3_1.dbf',

  '/opt/oradata/openview/TS_FM_1.dbf',

  '/opt/oradata/openview/TS_FM_IND_1.dbf',

  '/opt/oradata/openview/boss_test_ts_1.dbf',

  '/opt/oradata/openview/boss_ipnms_ts_1.dbf',

  '/opt/oradata/openview/sddb_data.dbf',

  '/opt/oradata/openview/sddb_index.dbf',

  '/opt/oradata/openview/sddb_temp.dbf'

CHARACTER SET ZHS16CGB231280;

7.        执行数据库恢复

SQL> RECOVER DATABASE USING BACKUP CONTROLFILE;

ORA-00279: change 488461 generated at 12/23/2005 08:11:35 needed for thread 1

ORA-00289: suggestion : /opt/oracle/admin/openview/arch/T0001S0000000002.ARC

ORA-00280: change 488461 for thread 1 is in sequence #2

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

/opt/oracle/admin/openview/arch/T0001S0000000002.ARC

ORA-00308: cannot open archived log

'/opt/oracle/admin/openview/arch/T0001S0000000002.ARC'

ORA-27037: unable to obtain file status

HP-UX Error: 2: No such file or directory

Additional information: 3

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

cancel

Media recovery cancelled.

由于数据库是abort方式down的，因此T0001S0000000002.ARC没有正常归档，系统不存在这个日志文件。所以，选择cancel方式取消恢复。

8.        恢复完成后，需要以resetlogs方式打开数据库。

SQL> ALTER DATABASE OPEN RESETLOGS;

总结：由于控制文件丢失时，系统丢失所有的关键信息，归档日志号也需要重新计数，因此最好做一个全库备份。