CSDN博客

img YY_MM_DD

oracle物理备份

发表于2008/9/28 9:24:00  1539人阅读

分类: 数据库

ORACLE热备份恢复手册

1.   概要

1.1. 本文的目的

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

1.2. 系统概况

系统环境:hp unix11 oracle 9201

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

备份方式:热备份

备份文件:数据文件、归档日志、控制文件、初始化文件。

2.   恢复情况介绍

2.1. 模拟回滚表空间损坏丢失

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

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

假设在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;

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

阅读全文
0 0

相关文章推荐

img
取 消
img