ORACLE备份&恢复案例
ORACLE BACKUP&RESTORE SCHEME
第一章. 理解什么是数据库恢复
当我们使用一个数据库时,总希望数据库的内容是可靠的、正确的,但由于计算机系统的故障(硬件故障、软件故障、网络故障、进程故障和系统故障)影响数据库系统的操作,影响数据库中数据的正确性,甚至破坏数据库,使数据库中全部或部分数据丢失。因此当发生上述故障后,希望能重构这个完整的数据库,该处理称为数据库恢复。恢复过程大致可以分为复原(Restore)与恢复(Recover)过程。
数据库恢复可以分为以下两类:
1.1实例故障的一致性恢复
当实例意外地(如掉电、后台进程故障等)或预料地(发出SHUTDOUM ABORT语句)中止时出现实例故障,此时需要实例恢复。实例恢复将数据库恢复到故障之前的事务一致状态。如果在在线后备发现实例故障,则需介质恢复。在其它情况ORACLE在下次数据库起动时(对新实例装配和打开),自动地执行实例恢复。如果需要,从装配状态变为打开状态,自动地激发实例恢复,由下列处理:
(1) 为了解恢复数据文件中没有记录的数据,进行向前滚。该数据记录在在线日志,包括对回滚段的内容恢复。
(2) 回滚未提交的事务,按步1重新生成回滚段所指定的操作。
(3) 释放在故障时正在处理事务所持有的资源。
(4) 解决在故障时正经历一阶段提交的任何悬而未决的分布事务。
1.2介质故障或文件错误的不一致恢复
介质故障是当一个文件、一个文件的部分或磁盘不能读或不能写时出现的故障。
文件错误一般指意外的错误导致文件被删除或意外事故导致文件的不一致。
这种状态下的数据库都是不一致的,需要DBA手工来进行数据库的恢复,这种恢复有两种形式,决定于数据库运行的归档方式和备份方式。
(1) 完全介质恢复可恢复全部丢失的修改。一般情况下需要有数据库的备份且数据库运行在归档状态下并且有可用归档日志时才可能。对于不同类型的错误,有不同类型的完全恢复可使用,其决定于毁坏文件和数据库的可用性。
(2) 不完全介质恢复是在完全介质恢复不可能或不要求时进行的介质恢复。重构受损的数据库,使其恢复介质故障前或用户出错之前的一个事务一致性状态。不完全介质恢复有不同类型的使用,决定于需要不完全介质恢复的情况,有下列类型:基于撤消、基于时间和基于修改的不完全恢复。
基于撤消(CANCEL)恢复:在某种情况,不完全介质恢复必须被控制,DBA可撤消在指定点的操作。基于撤消的恢复地在一个或多个日志组(在线的或归档的)已被介质故障所破坏,不能用于恢复过程时使用,所以介质恢复必须控制,以致在使用最近的、未损的日志组于数据文件后中止恢复操作。
基于时间(TIME)和基于修改(SCN)的恢复:如果DBA希望恢复到过去的某个指定点,是一种理想的不完全介质恢复,一般发生在恢复到某个特定操作之前,恢复到如意外删除某个数据表之前。
第二章. 数据库恢复案例测试环境
2.1 数据库环境
以下的所有案例都是通过测试经过,环境为:
OS:Windows 2000 Server
DB:Oracle 816
DBNAME:TEST
数据文件:
SQL> select file#,status,enabled,name from v$datafile;
FILE# STATUS ENABLED NAME
---------- ------- ---------- --------------------------------------------------------------------------------
1 SYSTEM READ WRITE D:ORACLEORADATATESTSYSTEM01.DBF
2 ONLINE READ WRITE D:ORACLEORADATATESTRBS01.DBF
3 ONLINE READ WRITE D:ORACLEORADATATESTUSERS01.DBF
4 ONLINE READ WRITE D:ORACLEORADATATESTTEMP01.DBF
5 ONLINE READ WRITE D:ORACLEORADATATESTTOOLS01.DBF
6 ONLINE READ WRITE D:ORACLEORADATATESTINDX01.DBF
控制文件:
SQL> select * from v$controlfile;
STATUS NAME
------- --------------------------------------------------------------------------------
D:ORACLEORADATATESTCONTROL01.CTL
D:ORACLEORADATATESTCONTROL02.CTL
D:ORACLEORADATATESTCONTROL03.CTL
联机日志:
SQL> select * from v$logfile;
GROUP# STATUS MEMBER
---------- ------- --------------------------------------------------------------------------------
1 STALE D:ORACLEORADATATESTREDO01.LOG
2 D:ORACLEORADATATESTREDO02.LOG
3 STALE D:ORACLEORADATATESTREDO03.LOG
2.2 数据库备份脚本
冷备份脚本
rem script:coldbak.sql
rem creater:chenjiping
rem date:5.8.2003
rem desc:offline full backup database
--connect database
connect internal/password;
--shutdown database
shutdown immediate;
--Copy Data file
!xcopy d:oracleoradatatest*.dbf d:database/H/R;
--Copy Control file
!xcopy d:oracleoradatatest*.ctl d:database/H/R;
--Copy Log file
!xcopy d:oracleoradatatest*.log d:database/H/R;
--startup database
startup;
说明:
1、以上脚本在数据库关闭状态下备份数据库所有的数据文件,联机日志,控制文件(在一个目录下),如果成功备份,所有文件是一致的。
2、没有备份参数文件,参数文件可以另外备份,没有必要每次都备份,只需要在改变设置后备份一次。
3、如果以上命令没有成功依次执行,那么备份将是无效的,如连接数据库不成功,那么肯定关闭数据库也不成功,那么备份则无效
4、冷备份建议下人工干预下执行。
数据库OS热全备份脚本
rem script:hotbak.sql
rem creater:chenjiping
rem date:5.8.2003
rem desc:backup all database datafile in archive
--connect database
connect internal/password;
--archive
alter system archive log current;
--start
alter tablespace system begin backup;
!xcopy d:oracleoradatatestsystem01.dbf d:databak/H/R;
alter tablespace system end backup;
alter tablespace rbs begin backup;
!xcopy d:oracleoradatatestrbs01.dbf d:databak/H/R;
alter tablespace rbs end backup;
alter tablespace users begin backup;
!xcopy d:oracleoradatatestusers01.dbf d:databak/H/R;
alter tablespace users end backup;
alter tablespace tools begin backup;
!xcopy d:oracleoradatatesttools01.dbf d:databak/H/R;
alter tablespace tools end backup;
alter tablespace indx begin backup;
!xcopy d:oracleoradatatestindx01.dbf d:databak/H/R;
alter tablespace indx end backup;
--end
--bak control file
--binary
alter database backup controlfile to 'd:databakcontrolbinbak.000';
--ascii
alter database backup controlfile to trace;
alter system archive log current;
说明:
1、热备份必须在数据库归档方式下才可以运行
2、以上脚本可以在数据库运行状态下备份数据库所有的数据文件(除了临时数据文件),没有必要备份联机日志。
3、归档日志至少需要一次完整备份之后的所有日志。
4、如果以上命令没有成功依次执行,那么备份也是无效的,如连接数据库不成功,那么备份则无效
RMAN备份只讲叙有恢复目录的情况,如果没有恢复目录,情形大致相似。以下是RMAN的热备份全备份的脚本:
# script:bakup.rcv
# creater:chenjiping
# date:5.8.2003
# desc:backup all database datafile in archive with rman
# connect database
connect rcvcat rman/rman@back;
connect target internal/virpure;
# start backup database
run{
allocate channel c1 type disk;
backup full tag 'dbfull' format 'd:backupfull%u_%s_%p' database
include current controlfile;
sql 'alter system archive log current';
release channel c1;
}
# end
说明:
1、 数据库必须运行在归档模式下
2、 RMAN将自动备份数据文件,运行可靠
3、 归档日志另外备份处理,但至少需要保存一次备份来的日志
4、 没有必要用RMAN做冷备份,效果不好
以上举例说明了数据库的恢复案例的测试环境与部分备份测试脚本,其它的备份脚本可以根据以上脚本演变而来或在案例中加以说明。
数据库的自动实例将不加以说明,这里只举例说明媒体错误或人为错误造成的恢复可能。
以上包括以下案例都是在WINDOWS+ORACLE816上测试验证的,在不同的操作系统与不同的数据库版本中略有差别。
第三章. 了解与恢复相关的信息
1、理解报警日志文件
报警日志文件一般记载了数据库的启动/关闭信息,归档信息,备份信息,恢复信息,常见错误信息,部分数据库修改记录等。一般令名规则为<SID>Alrt.log或Alrt<SID>.log,如我的测试数据库的报警日志文件的名称为testalrt.log。
报警日志文件的路径是根据初始化参数background_dump_dest来决定的,如在我的机器上,该参数值为 D:Oracleadmintestbdump,那么,你就可以在该路径下找到该文件
2、后台进程跟踪文件
后台进程跟踪文件的路径与报警日志文件的路径一致,在某些情况下,你可以通过后台跟踪文件的信息了解更多的需要恢复的信息。如在数据库需要恢复的时候,报警日志文件中常有这样的语句:
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
通过提示的DBWR跟踪文件,可以查询到更详细的信息。
3、v$recover_file与v$recovery_log
这是两个动态性能视图,可以在mount下查看,通过这两个视图,你可以了解详细的需要恢复的数据文件与需要使用到的归档日志。
第四章. 数据库恢复案例
4.1非归档模式下的备份与恢复
备份方案:采用OS冷备份
1.连接数据库并创建测试表
SQL*Plus: Release 8.1.6.0.0 - Production on Tue May 6 13:46:32 2003
(c) Copyright 1999 Oracle Corporation. All rights reserved.
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2.备份数据库
SQL> @coldbak.sql 或在DOS下 svrmgrl @coldbak.sql
3.再插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
4.关闭数据库
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
5.毁坏一个或多个数据文件,如删除user01.dbf
C:>del D:ORACLEORADATATESTUSERS01.DBF
模拟媒体毁坏
6.重新启动数据库,会发现如下错误
SQL> startup
ORACLE instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:ORACLEORADATATESTUSERS01.DBF'
在报警文件中,会有更详细的信息
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:ORACLEORADATATESTUSERS01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
7.拷贝备份复原到原来位置(restore过程)
C:>xcopy d:database*.* d:oracleoradatatest/H/R/S
8.打开数据库,检查数据
SQL> alter database open;
Database altered.
SQL> select * from test;
A
---------------------------------------
1
这里可以发现,数据库恢复成功,但在备份之后与崩溃之前的数据丢失了。
说明:
1、非归档模式下的恢复方案可选性很小,一般情况下只能有一种恢复方式,就是数据库的冷备份的完全恢复,仅仅需要拷贝原来的备份就可以(restore),不需要recover。
2、这种情况下的恢复,可以完全恢复到备份的点上,但是可能是丢失数据的,在备份之后与崩溃之前的数据将全部丢失。
3、不管毁坏了多少数据文件或是联机日志或是控制文件,都可以通过这个办法恢复,因为这个恢复过程是Restore所有的冷备份文件,而这个备份点上的所有文件是一致的,与最新的数据库没有关系,就好比把数据库又放到了一个以前的“点”上。
4、对于非归档模式下,最好的办法就是采用OS的冷备份,建议不要用RMAN来作冷备份,效果不好,因为RMAN不备份联机日志,restore不能根本解决问题。
5、如果没有备份联机日志,如RMAN的备份,就需要利用不完全恢复(until cancel)的方法来重新创建联机日志文件
4.2归档模式下丢失或损坏一个数据文件
4.2.1 OS备份方案
在归档方式下损坏或丢失一个数据文件,如果存在相应的备份与该备份以来的归档日志,恢复还是比较简单的,可以作到尽量少的Down机时间,并能作到数据库的完全恢复。
1、连接数据库,创建测试表并插入记录
SQL*Plus: Release 8.1.6.0.0 - Production on Tue May 6 13:46:32 2003
(c) Copyright 1999 Oracle Corporation. All rights reserved.
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int) tablespace users;
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、备份数据库
SQL> @hotbak.sql 或在DOS下 svrmgrl @hotbak.sql
3、继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
4、关闭数据库,模拟丢失数据文件
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down
C:>del D:ORACLEORADATATESTUSERS01.DBF
模拟媒体毁坏
5、启动数据库错误,脱机该数据文件
SQL> startup
ORACLE instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:ORACLEORADATATESTUSERS01.DBF'
还可以查看报警文件(见上一个恢复案例)或动态视图v$recover_file
如SQL> select * from v$recover_file;
FILE# ONLINE ERROR CHANGE# TIME
---------- ------- ------------------ ---------- -----------
3 ONLINE 1013500 2003-05-07
脱机数据文件
SQL> alter database datafile 3 offline drop;
Database altered.
6、打开数据库,拷贝备份回来(restore),恢复(recover)该数据文件,并联机
SQL> alter database open;
Database altered.
拷贝备份从备份处
copy d:databak users01.dbf d:oracleoradatatest;
恢复该数据文件
SQL> recover datafile 3;
ORA-00279: change 1053698 generated at 05/07/2003 17:51:26 needed for thread 1
ORA-00289: suggestion : D:ORACLEORADATATESTARCHIVETESTT001S00304.ARC
ORA-00280: change 1053698 for thread 1 is in sequence #304
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00279: change 1053701 generated at 05/07/2003 17:51:39 needed for thread 1
ORA-00289: suggestion : D:ORACLEORADATATESTARCHIVETESTT001S00305.ARC
ORA-00280: change 1053701 for thread 1 is in sequence #305
ORA-00278: log file 'D:ORACLEORADATATESTARCHIVETESTT001S00304.ARC' no
longer needed for this recovery
Log applied.
Media recovery complete.
恢复成功,联机该数据文件
SQL> alter database datafile 3 online;
Database altered.
7、检查数据库的数据(完全恢复)
SQL> select * from test;
A
---------------------------------------
1
2
说明:
1、采用热备份,需要运行在归档模式下,可以实现数据库的完全恢复,也就是说,从备份后到数据库崩溃时的数据都不会丢失。
2、可以采用全备份数据库的方式备份,对于特殊情况,也可以只备份特定的数据文件,如只备份用户表空间(一般情况下对于某些写特别频繁的数据文件,可以单独加大备份频率)
3、如果在恢复过程中,发现损坏的是多个数据文件,即可以采用一个一个数据文件的恢复方法(第5步中需要对数据文件一一脱机,第6步中需要对数据文件分别恢复),也可以采用整个数据库的恢复方法。
4、如果是系统表空间的损坏,不能采用此方法
4.2.2 RMAN备份方案
RMAN也可以进行联机备份,而且备份与恢复方法将比OS备份更简单可靠。
1、连接数据库,创建测试表并插入记录
SQL*Plus: Release 8.1.6.0.0 - Production on Tue May 6 13:46:32 2003
(c) Copyright 1999 Oracle Corporation. All rights reserved.
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int) tablespace users;
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、备份数据库表空间users
C:>rman
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> connect rcvcat rman/rman@back
RMAN-06008: connected to recovery catalog database
RMAN> connect target internal/virpure
RMAN-06005: connected to target database: TEST (DBID=1788174720)
RMAN> run{
2> allocate channel c1 type disk;
3> backup tag 'tsuser' format 'd:backuptsuser_%u_%s_%p'
4> tablespace users;
5> release channel c1;
6> }
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=16 devtype=DISK
RMAN-03022: compiling command: backup
RMAN-03025: performing implicit partial resync of recovery catalog
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03023: executing command: backup
RMAN-08008: channel c1: starting full datafile backupset
RMAN-08502: set_count=5 set_stamp=494177612 creation_time=16-MAY-03
RMAN-08010: channel c1: specifying datafile(s) in backupset
RMAN-08522: input datafile fno=00003 name=D:ORACLEORADATATESTUSER01.DBF
RMAN-08013: channel c1: piece 1 created
RMAN-08503: piece handle=D:BACKUPTSUSER_05EN93AC_5_1 comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:00:01
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: c1
RMAN>
3、继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL> alter system switch logfile;
System altered.
SQL>r
1* alter system switch logfile;
System altered.
4、关闭数据库,模拟丢失数据文件
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down
C:>del D:ORACLEORADATATESTUSER01.DBF
5、启动数据库,检查错误
SQL> startup
ORACLE instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:ORACLEORADATATESTUSER01.DBF'
6、先打开数据库
SQL> alter database datafile 3 offline drop;
Database altered.
SQL> alter database open;
Database altered.
7、恢复该表空间
恢复脚本可以是恢复单个数据文件
run{
allocate channel c1 type disk;
restore datafile 3;
recover datafile 3;
sql 'alter database datafile 3 online';
release channel c1;
}
也可以是,恢复表空间
run{
allocate channel c1 type disk;
restore tablespace users;
recover tablespace users;
sql 'alter database datafile 3 online';
release channel c1;
}
过程如下:
C:>rman
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> connect rcvcat rman/rman@back
RMAN-06008: connected to recovery catalog database
RMAN> connect target internal/virpure
RMAN-06005: connected to target database: TEST (DBID=1788174720)
RMAN> run{
2> allocate channel c1 type disk;
3> restore datafile 3;
4> recover datafile 3;
5> sql 'alter database datafile 3 online';
6> release channel c1;
7> }
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=13 devtype=DISK
RMAN-03022: compiling command: restore
RMAN-03022: compiling command: IRESTORE
RMAN-03023: executing command: IRESTORE
RMAN-08016: channel c1: starting datafile backupset restore
RMAN-08502: set_count=5 set_stamp=494177612 creation_time=16-MAY-03
RMAN-08089: channel c1: specifying datafile(s) to restore from backup set
RMAN-08523: restoring datafile 00003 to D:ORACLEORADATATESTUSER01.DBF
RMAN-08023: channel c1: restored backup piece 1
RMAN-08511: piece handle=D:BACKUPTSUSER_05EN93AC_5_1 tag=TSUSER params=NULL
RMAN-08024: channel c1: restore complete
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: recover
RMAN-03022: compiling command: recover(1)
RMAN-03022: compiling command: recover(2)
RMAN-03022: compiling command: recover(3)
RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-03022: compiling command: recover(4)
RMAN-06050: archivelog thread 1 sequence 332 is already on disk as file D:ORACLEORADATATESTARCHIVETESTT001S00332.ARC
RMAN-06050: archivelog thread 1 sequence 333 is already on disk as file D:ORACLEORADATATESTARCHIVETESTT001S00333.ARC
RMAN-06050: archivelog thread 1 sequence 334 is already on disk as file D:ORACLEORADATATESTARCHIVETESTT001S00334.ARC
RMAN-03023: executing command: recover(4)
RMAN-08515: archivelog filename=D:ORACLEORADATATESTARCHIVETESTT001S00332.ARC thread=1 sequence=332
RMAN-08055: media recovery complete
RMAN-03022: compiling command: sql
RMAN-06162: sql statement: alter database datafile 3 online
RMAN-03023: executing command: sql
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: c1
RMAN>
8、检查数据是否完整
SQL> alter database open;
Database altered.
SQL> select * from test;
A
---------------------------------------
1
2
说明:
1、RMAN也可以实现单个表空间或数据文件的恢复,恢复过程可以在mount下或open方式下,如果在open方式下恢复,可以减少down机时间
2、如果损坏的是一个数据文件,建议offline并在open方式下恢复
3、这里可以看到,RMAN进行数据文件与表空间恢复的时候,代码都比较简单,而且能保证备份与恢复的可靠性,所以建议采用RMAN的备份与恢复
4.3丢失多个数据文件,实现整个数据库的恢复
4.3.1 OS备份方案
OS备份归档模式下损坏(丢失)多个数据文件,进行整个数据库的恢复
1、连接数据库,创建测试表并插入记录
SQL*Plus: Release 8.1.6.0.0 - Production on Tue May 6 13:46:32 2003
(c) Copyright 1999 Oracle Corporation. All rights reserved.
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、备份数据库,备份除临时数据文件后的所数据文件
SQL> @hotbak.sql 或在DOS下 svrmgrl @hotbak.sql
3、继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
4、关闭数据库,模拟丢失数据文件
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down
C:>del D:ORACLEORADATATESTSYSTEM01.DBF
C:>del D:ORACLEORADATATESTINDX01.DBF
C:>del D:ORACLEORADATATESTTOOLS01.DBF
C:>del D:ORACLEORADATATESTRBS01.DBF
模拟媒体毁坏(这里删除多个数据文件)
5、启动数据库,检查错误
SQL> STARTUP
ORACLE instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:ORACLEORADATATESTSYSTEM01.DBF'
详细信息可以查看报警文件
ORA-1157 signalled during: ALTER DATABASE OPEN...
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:ORACLEORADATATESTSYSTEM01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 2 - see DBWR trace file
ORA-01110: data file 2: 'D:ORACLEORADATATESTRBS01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: 'D:ORACLEORADATATESTTOOLS01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: 'D:ORACLEORADATATESTINDX01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
通过查询v$recover_file可以看到
SQL> select * from v$recover_file;
FILE# ONLINE ERROR CHANGE# TIME
---------- ------- ------------------ ---------- -----------
1 ONLINE FILE NOT FOUND 0
2 ONLINE FILE NOT FOUND 0
5 ONLINE FILE NOT FOUND 0
6 ONLINE FILE NOT FOUND 0
有四个数据文件需要恢复
6、拷贝备份回到原地点(restore),开始恢复数据库(recover)
restore过程:
C:>copy D:DATABAKSYSTEM01.DBF D:ORACLEORADATATEST
C:>copy D:DATABAKTESTINDX01.DBF D:ORACLEORADATATEST
C:>copy D:DATABAKTESTTOOLS01.DBF D:ORACLEORADATATEST
C:>copy D:DATABAKTESTRBS01.DBF.DBF D:ORACLEORADATATEST
Recover过程:
SQL> recover database;
ORA-00279: change 1073849 generated at 05/08/2003 08:58:35 needed for thread 1
ORA-00289: suggestion : D:ORACLEORADATATESTARCHIVETESTT001S00311.ARC
ORA-00280: change 1073849 for thread 1 is in sequence #311
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 1073856 generated at 05/08/2003 09:03:27 needed for thread 1
ORA-00289: suggestion : D:ORACLEORADATATESTARCHIVETESTT001S00312.ARC
ORA-00280: change 1073856 for thread 1 is in sequence #312
ORA-00278: log file 'D:ORACLEORADATATESTARCHIVETESTT001S00311.ARC' no
longer needed for this recovery
ORA-00279: change 1073858 generated at 05/08/2003 09:11:43 needed for thread 1
ORA-00289: suggestion : D:ORACLEORADATATESTARCHIVETESTT001S00313.ARC
ORA-00280: change 1073858 for thread 1 is in sequence #313
ORA-00278: log file 'D:ORACLEORADATATESTARCHIVETESTT001S00312.ARC' no
longer needed for this recovery
ORA-00279: change 1073870 generated at 05/08/2003 09:11:46 needed for thread 1
ORA-00289: suggestion : D:ORACLEORADATATESTARCHIVETESTT001S00314.ARC
ORA-00280: change 1073870 for thread 1 is in sequence #314
ORA-00278: log file 'D:ORACLEORADATATESTARCHIVETESTT001S00313.ARC' no
longer needed for this recovery
Log applied.
Media recovery complete.
7、打开数据库,检查数据库的数据(完全恢复)
SQL> alter database open;
Database altered.
SQL> select * from test;
A
---------------------------------------
1
2
说明:
1、只要有备份与归档存在,就可以实现数据库的完全恢复(不丢失数据)
2、适合于丢失大量数据文件,或包含系统数据文件在内的数据库的恢复
3、恢复过程在mount下进行,如果恢复成功,再打开数据库,down机时间可能比较长一些。