您的位置:首页 > 数据库 > Oracle

Oracle案例:损坏数据文件的恢复方法

2011-05-03 13:17 555 查看
一:非归档模式下丢失或者损坏数据文件

在非归档模式下损坏或者丢失数据文件,如果有相应的备份,在一定程度上是可以恢复的,但是如果oracle过多的读写操作记录信息而导致redo重写的时候,恢复就会停滞,非归档下系统能自动恢复的仅仅限于redo中存在的记录。

可以成功恢复案例

SQL> startup

ORACLE instance started.

Total System Global Area 235999352 bytes

Fixed Size 450680 bytes

Variable Size 201326592 bytes

Database Buffers 33554432 bytes

Redo Buffers 667648 bytes

Database mounted.

Database opened

SQL> create table test(a int);

Table created.

SQL> insert into test values(1);

1 row created.

SQL> /

1 row created.

SQL> /

1 row created.

SQL> /

1 row created.

SQL> commit;

Commit complete.

SQL> exit;

[oracle@www oradata]$ cd cicro/

[oracle@www cicro]$ ls

control01.ctl cwmlite01.dbf indx01.dbf redo02.log temp01.dbf users01.dbf control02.ctl drsys01.dbf odm01.dbf redo03.log tools01.dbf xdb01.dbf control03.ctl example01.dbf redo01.log system01.dbf undotbs01.dbf

[oracle@www cicro]$ pwd

/opt/oracle/oradata/cicro

[oracle@www cicro]$ sqlplus "/as sysdba"

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL>exit;

[oracle@www cicro]$ cp ./*.dbf ../

[oracle@www cicro]$ sqlplus "/as sysdba"

SQL*Plus: Release 9.2.0.1.0 - Production on Tue Jul 25 19:44:31 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:

Oracle9i Release 9.2.0.1.0 - Production

JServer Release 9.2.0.1.0 – Production

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 235999352 bytes

Fixed Size 450680 bytes

Variable Size 201326592 bytes

Database Buffers 33554432 bytes

Redo Buffers 667648 bytes

Database mounted.

Database opened.

SQL> insert into test values(3333);

1 row created.

SQL> /

1 row created.

SQL> /

1 row created.

SQL> /

1 row created.

SQL> commit;

Commit complete.

SQL> select * from test;

A

----------

1

1

1

1

3333

3333

3333

3333

8 rows selected.

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL>exit;

[oracle@www cicro]$ rm –rf ./*.dbf

[oracle@www cicro]$ sqlplus "/as sysdba"

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 235999352 bytes

Fixed Size 450680 bytes

Variable Size 201326592 bytes

Database Buffers 33554432 bytes

Redo Buffers 667648 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 1 - see DBWR trace file

ORA-01110: data file 1: '/opt/oracle/oradata/cicro/system01.dbf'

SQL> quit

[oracle@www cicro]$ mv ../*.dbf .

[oracle@www cicro]$ ls

control01.ctl cwmlite01.dbf indx01.dbf redo02.log temp01.dbf users01.dbf control02.ctl drsys01.dbf odm01.dbf redo03.log tools01.dbf xdb01.dbf control03.ctl example01.dbf redo01.log system01.dbf undotbs01.dbf

[oracle@www cicro]$ sqlplus "/as sysdba"

SQL*Plus: Release 9.2.0.1.0 - Production on Tue Jul 25 17:56:06 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:

Oracle9i Release 9.2.0.1.0 - Production

JServer Release 9.2.0.1.0 - Production

SQL> recover database;

Media recovery complete.

SQL> alter database open;

Database altered.

SQL> select * from test;

A

----------

1

1

1

1

33333

33333

33333

33333

8 rows selected.

至此,恢复成功!

不完全恢复的案例

基本操作与上面相同,还是首先建立一张表,然后插入数据:

1:建表,写入数据,然后关闭数据库

SQL> create table gaojf1 as select * from all_objects;

Table created.

SQL> insert into gaojf1 select * from gaojf1;

29614 rows created.

SQL> /

59228 rows created. (即为现在此表数据有118456列)

SQL>commit;

SQL>shutdown immediate

2:备份所有的数据文件

3:启动数据库继续插入数据

[oracle@www cicro]$ sqlplus "/as sysdba"

SQL*Plus: Release 9.2.0.1.0 - Production on Tue Jul 25 18:07:19 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:

Oracle9i Release 9.2.0.1.0 - Production

JServer Release 9.2.0.1.0 - Production

SQL> insert into gaojf1 select * from gaojf1;

118456 rows created.

SQL> /

236912 rows created.

SQL> /

473824 rows created.

SQL> /

947648 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from gaojf1;

COUNT(*)

----------

1895296

SQL> /

1895296 rows created.

SQL> /

3790592 rows created.(如果能够完全恢复,此表应该有3790592*2列)

SQL> commit;

Commit complete.

期间,查看日志信息如下:

Wed Jul 26 13:02:54 2006

Thread 1 opened at log sequence 1

Current log# 3 seq# 1 mem# 0: /opt/oracle/oradata/cicro/redo03.log

Successful open of redo thread 1.

Wed Jul 26 13:03:56 2006

Thread 1 advanced to log sequence 2

Current log# 1 seq# 2 mem# 0: /opt/oracle/oradata/cicro/redo01.log

Wed Jul 26 13:05:41 2006

Thread 1 advanced to log sequence 3

Current log# 2 seq# 3 mem# 0: /opt/oracle/oradata/cicro/redo02.log

Wed Jul 26 13:09:04 2006

Thread 1 advanced to log sequence 4

Current log# 3 seq# 4 mem# 0: /opt/oracle/oradata/cicro/redo03.log

Wed Jul 26 13:09:29 2006

Thread 1 advanced to log sequence 5

Current log# 1 seq# 5 mem# 0: /opt/oracle/oradata/cicro/redo01.log

可以看到,redo文件在不断的循环重写,当一个redo写完后继续写第二个redo,然后是第三个,当第三个写完后继续回来重写第一个,依此类推。此时sequence也在不断的增加。

从上面的时间可以看出,redo的切换频率,但是不能单纯看上面的两个时间间隔就确定redo的切换频率是多少,redo切换的频率应该是个平均值,不是看单纯的两个redo之间的切换时间来计算,应看应用的环境,业务的繁忙程度。

一般建议redo的正常切换频率为20-30分钟切换一次。

因此应该根据业务的大小,合理的设计redo文件的大小,保证正常的切换频率!

4:关闭数据库,删除现有的所有数据文件。

5:重新启动数据库,进行恢复测试

[oracle@www cicro]$ sqlplus "/as sysdba"

SQL*Plus: Release 9.2.0.1.0 - Production on Tue Jul 25 18:15:57 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 235999352 bytes

Fixed Size 450680 bytes

Variable Size 201326592 bytes

Database Buffers 33554432 bytes

Redo Buffers 667648 bytes

Database mounted.

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: '/opt/oracle/oradata/cicro/system01.dbf'

SQL> recover database;

ORA-00279: change 19476655 generated at 07/25/2006 17:54:46 needed for thread 1

ORA-00289: suggestion : /opt/oracle/product/9.2.0/dbs/arch1_98.dbf

ORA-00280: change 19476655 for thread 1 is in sequence #98

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

此时由于没有arch1_98.dbf归档文件,所以这样恢复输入auto显然不行,那么只有输入CANCEL

SQL> recover database;

ORA-00279: change 19476655 generated at 07/25/2006 17:54:46 needed for thread 1

ORA-00289: suggestion : /opt/oracle/product/9.2.0/dbs/arch1_98.dbf

ORA-00280: change 19476655 for thread 1 is in sequence #98

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

cancel

Media recovery cancelled.

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: '/opt/oracle/oradata/cicro/system01.dbf'

仍然不能打开数据库,还是提示system01.dbf'需要恢复。

输入此时的在线日志试试看。

SQL> recover database;

ORA-00279: change 19476655 generated at 07/25/2006 17:54:46 needed for thread 1

ORA-00289: suggestion : /opt/oracle/product/9.2.0/dbs/arch1_98.dbf

ORA-00280: change 19476655 for thread 1 is in sequence #98

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

/opt/oracle/oradata/cicro/redo01.log

ORA-00310: archived log contains sequence 104; sequence 98 required

ORA-00334: archived log: '/opt/oracle/oradata/cicro/redo01.log'

SQL> recover database;

ORA-00279: change 19476655 generated at 07/25/2006 17:54:46 needed for thread 1

ORA-00289: suggestion : /opt/oracle/product/9.2.0/dbs/arch1_98.dbf

ORA-00280: change 19476655 for thread 1 is in sequence #98

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

/opt/oracle/oradata/cicro/redo02.log

ORA-00310: archived log contains sequence 105; sequence 98 required

ORA-00334: archived log: '/opt/oracle/oradata/cicro/redo02.log'

SQL> recover database;

ORA-00279: change 19476655 generated at 07/25/2006 17:54:46 needed for thread 1

ORA-00289: suggestion : /opt/oracle/product/9.2.0/dbs/arch1_98.dbf

ORA-00280: change 19476655 for thread 1 is in sequence #98

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

/opt/oracle/oradata/cicro/redo03.log

ORA-00310: archived log contains sequence 106; sequence 98 required

ORA-00334: archived log: '/opt/oracle/oradata/cicro/redo03.log'

看来现在的情况是redo文件的中记录的sequence值大于需要的sequence值98,所以恢复也是不成功的。

由此可知,redo文件每写满一个文件,sequence号码就会增加一次,然后覆盖原来信息从头开始继续写入,如果是归档模式,则把写满的redo文件备份归档,然后sequence值增加一次,继续下一轮的写redo操作。因为上面的insert语句操作记录很大,导致redo文件覆盖重写了3次,sequence也从原来的redo03的98上升到redo03的106,这个就是没有归档导致redo重写,丢失数据是在所难免的。但是现在的问题是要如何打开数据库。

6:重新关闭数据库,修改数据库启动参数initsid.ora参数,加入以下隐含参数:

_allow_resetlogs_corruption=true

然后用initsid.ora参数启动数据库。

7:进行不完全恢复

[oracle@www cicro]$ sqlplus "/as sysdba"

SQL*Plus: Release 9.2.0.1.0 - Production on Tue Jul 25 18:15:57 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 235999352 bytes

Fixed Size 450680 bytes

Variable Size 201326592 bytes

Database Buffers 33554432 bytes

Redo Buffers 667648 bytes

Database mounted.

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: '/opt/oracle/oradata/cicro/system01.dbf'

数据库在加入隐含参数后,只是告诉oracle,启动时候不再检测文件的一致性,但是如果有文件损坏,文件要进行恢复等等,还会有不能open的报错提示,此时可以根据情况,如果报错的文件不存在或者不能修复,就offline掉,如果能恢复就输入恢复命令,然后用resetlogs打开数据库。

SQL> recover database until cancel;

ORA-00279: change 19476655 generated at 07/25/2006 17:54:46 needed for thread 1

ORA-00289: suggestion : /opt/oracle/product/9.2.0/dbs/arch1_98.dbf

ORA-00280: change 19476655 for thread 1 is in sequence #98

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

输入cancel

Media recovery cancelled.

SQL>alter database open resetlogs (进行不完全恢复)

SQL>select count(*) from gaojf1;

COUNT(*)

----------

118456

这样基本就可以打开数据库了,但是原来的表gaojf1中的数据有一部分丢失了,存在的仅仅为备份数据时刻的信息。

追究丢失的原因,就是由于数据库没有归档,导致redo文件被覆盖重写,数据丢失。

打开数据库后要马上备份数据,然后去掉刚才加入的隐含参数。最好重新建库,把数据重新导入。

二:归档模式下丢失或损坏一个数据文件

首先就using bakcup controlfile的使用简单说明如下:

(1):如果你的redo和archive log都正常的话,可以作用

1. CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS

2. RECOVER DATABASE

3. ALTER DATABASE OPEN

(2):如果是redo和/或archive log损坏,而数据库恢复又必需的话,才用

1. CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS

2. RECOVER DATABASE USING BACKUP CONTROLFILE

3. ALTER DATABASE OPEN RESETLOGS

如果你用了 using backup controlfile,就必须用resetlogs同步。

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、备份数据库

热备脚本hotbak.sql如下:

rem script:hotbak.sql

rem creater:gaojf

rem date:5.8.2003

rem desc:backup all database datafile in archive

--connect database

connect /as sysdba;

--archive

alter system archive log current;

--start

alter tablespace system begin backup;

!cp /opt/oracle/oradata/gaojf/system01.dbf /opt/oracle/oradata.bak;

alter tablespace system end backup;

alter tablespace users begin backup;

!cp /opt/oracle/oradata/gaojf/users01.dbf /opt/oracle/oradata.bak;

alter tablespace users end backup;

alter tablespace tools begin backup;

!cp /opt/oracle/oradata/gaojf/tools01.dbf /opt/oracle/oradata.bak;

alter tablespace tools end backup;

alter tablespace indx begin backup;

!cp /opt/oracle/oradata/gaojf/indx01.dbf /opt/oracle/oradata.bak;

alter tablespace indx end backup;

alter tablespace indx begin backup;

!cp /opt/oracle/oradata/gaojf/gaojfdb.dbf /opt/oracle/oradata.bak;

alter tablespace indx end backup;

alter tablespace indx begin backup;

!cp /opt/oracle/oradata/gaojf/temp01.dbf /opt/oracle/oradata.bak;

alter tablespace indx end backup;

alter tablespace indx begin backup;

!cp /opt/oracle/oradata/gaojf/undotbs01.dbf /opt/oracle/oradata.bak;

alter tablespace indx end backup;

--end

--bak control file

--binary

alter database backup controlfile to '/opt/oracle/oradata.bak/controlfile.000';

--ascii

alter database backup controlfile to trace;

执行此脚本

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:\ORACLE\ORADATA\TEST\USERS01.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:\ORACLE\ORADATA\TEST\USERS01.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:\oracle\oradata\test;

恢复该数据文件

SQL> recover datafile 3;(对某个数据文件进行恢复)

ORA-00279: change 1053698 generated at 05/07/2003 17:51:26 needed for thread 1

ORA-00289: suggestion : D:\ORACLE\ORADATA\TEST\ARCHIVE\TESTT001S00304.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:\ORACLE\ORADATA\TEST\ARCHIVE\TESTT001S00305.ARC

ORA-00280: change 1053701 for thread 1 is in sequence #305

ORA-00278:logfile'D:\ORACLE\ORADATA\TEST\ARCHIVE\TESTT001S00304.ARC' nolonger needed for this recovery

Log applied.

Media recovery complete.

恢复成功,联机该数据文件

SQL> alter database datafile 3 online;

Database altered.

SQL> alter database datafile 3 offline drop;

Database altered.

SQL> alter database datafile 3 online;

alter database datafile 3 online

*

ERROR at line 1:

ORA-01113: file 3 needs media recovery

ORA-01110: data file 3: ''D:\ORACLE\ORADATA\TEST\USERS01.DBF'

如果是单纯的offline datafile,那么将不会触发文件检查点,只有针对offline tablespace的时候才会触发文件检查点,这就是上面为什么online datafile需要media recovery。而online tablespace不需要。

进行recover 恢复:

SQL> recover datafile 3;

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、如果是系统表空间的损坏,不能采用此方法

三:丢失多个数据文件,实现整个数据库的恢复

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>

System altered.

SQL> alter system switch logfile;

System altered.

4、关闭数据库,模拟丢失数据文件

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down

C:\>del D:\ORACLE\ORADATA\TEST\SYSTEM01.DBF

C:\>del D:\ORACLE\ORADATA\TEST\INDX01.DBF

C:\>del D:\ORACLE\ORADATA\TEST\TOOLS01.DBF

C:\>del D:\ORACLE\ORADATA\TEST\RBS01.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:\ORACLE\ORADATA\TEST\SYSTEM01.DBF'

详细信息可以查看报警文件

ORA-1157 signalled during: ALTER DATABASE OPEN...

Thu May 08 09:39:36 2003

Errors in file D:\Oracle\admin\test\bdump\testDBW0.TRC:

ORA-01157: cannot identify/lock data file 1 - see DBWR trace file

ORA-01110: data file 1: 'D:\ORACLE\ORADATA\TEST\SYSTEM01.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:\Oracle\admin\test\bdump\testDBW0.TRC:

ORA-01157: cannot identify/lock data file 2 - see DBWR trace file

ORA-01110: data file 2: 'D:\ORACLE\ORADATA\TEST\RBS01.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:\Oracle\admin\test\bdump\testDBW0.TRC:

ORA-01157: cannot identify/lock data file 5 - see DBWR trace file

ORA-01110: data file 5: 'D:\ORACLE\ORADATA\TEST\TOOLS01.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:\Oracle\admin\test\bdump\testDBW0.TRC:

ORA-01157: cannot identify/lock data file 6 - see DBWR trace file

ORA-01110: data file 6: 'D:\ORACLE\ORADATA\TEST\INDX01.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:\DATABAK\SYSTEM01.DBF D:\ORACLE\ORADATA\TEST\

C:\>copy D:\DATABAK\TEST\INDX01.DBF D:\ORACLE\ORADATA\TEST\

C:\>copy D:\DATABAK\TEST\TOOLS01.DBF D:\ORACLE\ORADATA\TEST\

C:\>copy D:\DATABAK\TEST\RBS01.DBF.DBF D:\ORACLE\ORADATA\TEST\

Recover过程:

SQL> recover database;(全库恢复)

ORA-00279: change 1073849 generated at 05/08/2003 08:58:35 needed for thread 1

ORA-00289:suggestion D:\ORACLE\ORADATA\TEST\ARCHIVE\TESTT001S00311.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:\ORACLE\ORADATA\TEST\ARCHIVE\TESTT001S00312.ARC

ORA-00280: change 1073856 for thread 1 is in sequence #312

ORA-00278:logfile'D:\ORACLE\ORADATA\TEST\ARCHIVE\TESTT001S00311.ARC' nolonger needed for this recovery

ORA-00279: change 1073858 generated at 05/08/2003 09:11:43 needed for thread 1

ORA-00289:suggestion:D:\ORACLE\ORADATA\TEST\ARCHIVE\TESTT001S00313.ARC

ORA-00280: change 1073858 for thread 1 is in sequence #313

ORA-00278:logfile'D:\ORACLE\ORADATA\TEST\ARCHIVE\TESTT001S00312.ARC' nolonger needed for this recovery

ORA-00279: change 1073870 generated at 05/08/2003 09:11:46 needed for thread 1

ORA-00289:suggestion:D:\ORACLE\ORADATA\TEST\ARCHIVE\TESTT001S00314.ARC

ORA-00280: change 1073870 for thread 1 is in sequence #314

ORA-00278:logfile'D:\ORACLE\ORADATA\TEST\ARCHIVE\TESTT001S00313.ARC' nolonger 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机时间可能比较长一些。
本文出自 “爱维Linux” 博客,请务必保留此出处http://ixdba.blog.51cto.com/2895551/558261
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: