备份与恢复

第一部分：手工备份与恢复

第一章：备份恢复概述

一）数据库故障类型：

1）user process failure： pmon 自动处理

2）instance failure: smon 自动处理

3）user errors ：需要dba通过备份恢复解决

4）media failure：必须通过备份和日志恢复

二）备份和恢复计划

1）根据生产环境的恢复周期，制定详细的备份计划，然后严格执行

2）对备份，要在一定的时间内利用测试环境，进行故障恢复的练习

三）备份恢复分类

1）逻辑备份与恢复– 面向object

①传统的导入导出：exp/imp：

②数据泵导入导出：expdp/impdp

逻辑备份就是热备数据库对象某一时刻状态，不能运用在media failure上，逻辑备份的恢复就是还原备份，没有recover的概念。

2）物理备份与恢复– 面向media failure

①手工备份与恢复，也叫用户管理的备份与恢复，通过OS 的命令，完成备份与还原，然后再运用日志进行恢复。

②自动备份与恢复，利用oracle 的备份恢复工具rman，使还原与恢复过程自动完成，可以备份恢复ASM FILE。

物理备份从方式上可以有一致性备份（冷备）和非一致性备份（热备）

完整的备份策略应该以物理备份为主，逻辑备份为辅（用于备份一些重要的表）

3）闪回技术– 面向人为的逻辑错误

一种利用undo数据或闪回日志的快速恢复技术。可以针对不同层面问题进行逻辑恢复，11g支持七种flashback方式。

四）完全恢复与不完全恢复

media failure后，需要运用日志进行recover。

1）完全恢复：

利用完整备份或部分备份，可以将datafile恢复到failure前得最后一次commit，不会出现数据丢失。

2）不完全恢复

需要运用完整备份和日志将database恢复到过去的某个时间点（或SCN），有数据丢失。

五）归档与非归档

1）归档模式：redo log 写入 archive log

2）非归档模式：没有archive log, redo log file循环覆盖

当处于非归档模式下时，在丢失数据文件后唯一的选择是执行完整的数据库还原，而不能进行recover。

第二章：手工备份与恢复

一）相关命令

1）备份和还原都使用OS命令，如linux中的cp

2）恢复用sqlplus命令:recover

二）备份前进行检查:

1）检查需要备份的数据文件

SQL> select name from v$datafile;

SQL> select file_id,file_name,tablespace_name from dba_data_files;

2）检查要备份的控制文件

SQL> select name from v$controlfile;

3）在线redo日志不需要做备份

三）dbv检查坏块

在手工备份前，应该检查datafile 是否有坏块，备份完后对备份也要做检查。

对某个datafile做坏块检查

$ dbv file=/u01/oradata/prod/users01.dbf feedback=50

DBVERIFY - 开始验证: FILE = /u01/oradata/prod/users01.dbf

…….

四）冷备的注意事项：

1）必须干净的关闭数据库，以保证数据一致性。

SQL>shutdwon immediate;

2）在OS下必须备份所有数据文件

3）在OS下必须备份控制文件(至少备份一个）

4）非归档备份还原策略

恢复时还原所有备份，重建所有在线日志, 没有recover步骤。

SQL>startup mount

SQL>alter database clear logfile group n;（n为所有在线日志组）

SQL>alter database open;

五）手工非一致性备份（热备份）

1）在备份前要进入热备模式，备份后要结束热备模式

执行begin backup 设置备份模式（在数据文件上生成检查点，写入scn ，将来恢复的时候以此scn为起点）

对只读的表空间不能做热备份，临时表空间不需要备份，特别强调：NOARCHIVE模式下不支持手工热备。

对整个数据库设置热备模式：SQL> alter database begin backup

对整个数据库结束热备模式：SQL> alter database end backup;

对单个表空间设置热备模式：SQL> alter tablespace users begin backup;

对单个表空间结束热备模式：SQL> alter tablespace users end backup;

2）手工热备利用v$backup 监控

例；

SQL> alter tablespace test begin backup;

SQL> select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#

1 2414314

2 2414314

3 2414314

4 2414314

5 2414314

6 2430480 在备份期间，scn被冻结，它是恢复阶段运用日志的起点。

7 2414314

SQL> select * from v$backup;

FILE# STATUS CHANGE# TIME

1 NOT ACTIVE 0

2 NOT ACTIVE 0

3 NOT ACTIVE 0

4 NOT ACTIVE 0

5 NOT ACTIVE 0

6 ACTIVE 2430480 2012-07-30 11:07:19

7 NOT ACTIVE 0

STATUS 是ACTIVE，表示可以备份相应的数据文件。

$cp test01.dbf test01.bak

SQL> alter tablespace test end backup;

SQL> select * from v$backup;

备份完毕，尽快执行end backup

如果在end backup之前发生数据库abort,那么可以在下次启动到mount时end backup，从而完成实例恢复。

六）split block问题

一个Oracle block一般包含多个OS block,，当手工热备时，OS的cp单位不是Oracle block而是OS block，而Oracle的DBWR又可能不时的从内存中刷新Oracle block(，如此，OS级的脏块)到磁盘上拷贝便可能造成：一个Oracle Block是由不同的版本组成，比如未被DBWR刷新Header block 加上另一部分被刷新的foot block，这样cp出来的Oracle blcok就是split block。

数据库的一致性是不允许oracle block是split的, Oracle采取的办法是：在backup mode后，如果发现首次DBWR要写脏块，则将该块被刷新之前的镜像数据记录到redo buffer，这样，虽然cp后的文件里仍然含有split block，而当需要恢复时，日志会前滚该块的前镜像，以保证所有被恢复的oracle block最终是一个完整的版本。

这就是我们常常发现在热备时日志文件会急剧增大的原因。

第三章：手工完全恢复

一）基本概念

1）完全恢复的步骤

1）restore: OS拷贝命令还原所有或部分datafile

2）recover：SQL*PLUS利用归档日志和当前的redo日志做恢复

2）完全恢复可以基于三个级别

recover database：所有数据文件损坏，或包括大部分datafile丢失，一般是在mount状态完成

recover tablespace：非关键表空间损坏，表空间下某些数据文件不能访问，一般是在open下完成

recover datafile：单一或少数数据文件损坏，可以在mount或open 状态完成

3）什么是关键文件

如果关键文件损坏，数据库将不能维持在open状态，或崩溃或死机！

哪些文件是关键文件：①system01 file，②undotbs file，③control file，④current log file

4）恢复过程可以查看的视图：

1）v$recover_file 查看需要恢复的datafile

2）v$recovery_log 查看recover 需要的redo 日志

3）v$archvied_log 查看已经归档的日志

二）适用场景

1）recover database (所有或大部分数据文件损坏，mount或open下进行)

OS：使用cp 还原受损的dbf（不一定是全部，v$recover_file记录的都需要还原）

SQLPLUS：

①recover database;

②alter database open;

2）recover tablespace (针对表空间的非关键数据文件损坏，一般是open下进行)

OS:使用cp 还原该表空间XXX下的所有数据文件

SQLPLUS：

①alter tablespace XXX offline;

②recover tablespace XXX;

③alter tablespace XXX online;

3）recover datafile (单个或几个数据文件损坏，关键文件在mount下进行，非关键文件在open下进行)

第一种情形

OS:使用cp 还原相关的关键数据文件(mount)

SQLPLUS：

①recover datafile 6,8;

②alter database open;

第二种情形

OS:使用cp 还原相关的非关键数据文件(open)

SQLPLUS：

①alter database datafile 6,8 offline;

②recover datafile 6,8;

③alter database datafile 6,8 online;

三）示例

前提: 有一套datafile全备, 使用当前控制文件, 自上次备份以来的归档日志和当前联机日志是完整的。

示例1：recover database （如果是system01.dbf损坏只能在mount下恢复。）

sys:

SQL> select * from scott.test;

-———

在这个状态下先在OS下做一个数据文件和控制文件的冷备。

SQL> shutdown immediate

[oracle@prod ~] $cp /u01/oradata/prod/*.dbf /u01/back1

[oracle@prod ~] $cp /u01/oradata/prod/*.ctl /u01/back1

[oracle@prod ~] $startup

SQL> insert into scott.test values(2);

SQL> commit;

SQL> insert into scott.test values(3);

SQL> select * from scott.test;

-———

3 这条记录未提交，恢复时会回滚掉

1）模拟介质失败

[oracle@prod ~]$ rm /u01/oradata/prod/system01.dbf 数据库在打开的情况下就删除关键文件

[oracle@prod ~]$ rm/u01/oradata/prod/users01.dbf

[oracle@prod ~]$ rm/u01/oradata/prod/example01.dbf

$sqlplus / as sysdba 换个session登录,然后关闭数据库

SQL> shutdown abort 数据库直接abort了

2）启动database，报错！

SQL> startup

SQL>select file#,error from v$recover_file;

3）还原损坏的三个数据文件

[oracle@prod ~]$ cp /u01/back1/system01.dbf /u01/oradata/prod

[oracle@prod ~]$ cp /u01/back1/users01.dbf /u01/oradata/prod

[oracle@prod ~]$ cp /u01/back1/example01.dbf /u01/oradata/prod

4）比较控制文件和数据文件头的SCN

SQL> select file#,heckpoint_change# from v$datafile;

SQL> select file#,heckpoint_change# from v$datafile_header;

SQL> recover database;

SQL> select file#,checkpoint_change# from v$datafile;

5)打开数据库

SQL> alter database open;

6）验证

SQL> select * from scott.test;

-———

示例2：recover tablespace（状态：database open)

针对的是非关键表空间的损坏，基于表空间的完全恢复实际上还是对其下的datafile的恢复

模拟这种情形非常实用，通常是某个非关键表空间下的数据文件受损，但并没有造成Oracle崩溃，我们只需针对个别有问题的tablespace去做单独的在线恢复操作，也就是说恢复时数据库整体是online的，而局部表空间是offline的，数据库不需要shutdown。

恢复表空间（删除了tablespace下的所有的datafile）

1）了解一下当前状态，在test表空间上建立scott.t1表，

SQL> conn scott/scott

SQL> create table t1 (id int) tablespace test;

SQL> insert into t1 values(1);

SQL> commit;

SQL> select * from t1;

NAME

-————————————————-

2）模拟表空间损坏，数据库open下，直接删除表空间下的数据文件

[oracle@prod ~]$ rm /u01/oradata/prod/test01.dbf

3）查证该表空间上的表不可访问了

SQL> alter system flush buffer_cache; 清除data buffer

SQL> conn / as sysdba 换个session登陆，访问t1表，因内存里已清除了buffer块，只好去做物理读，所以报错!

SQL> select * from scott.t1;

4）看看scn的情况

SQL> select file#,checkpoint_change# from v$datafile;

SQL> select file#,checkpoint_change# from v$datafile_header;

5）将test表空间offline

SQL> alter tablespace test offline immediate; immediate使表空间能立即脱机，不等Oracle对任何数据文件做检查

6）数据库open下，使用备份还原这个表空间下的所有数据文件

[oracle@prod ~]$ cp /u01/back1/test01.dbf /u01/oradata/prod

7）恢复tablespace

SQL> recover tablespace test;

8）使表空间online

SQL> alter tablespace test online; 此时数据库状态一直是open的

9）验证

SQL> select * from scott.t1;

-————————————————-

示例3：recover datafile（database mount或open状态）

恢复datafile, 同范例2不同的是模拟UNDO文件损坏: 因UNDO数据文件也是关键文件，所以只能在mount状态下恢复。

1）模拟环境：

SQL> insert into scott.t1 values(2); 插入一行记录是为了使t1和备份有区别

SQL> commit;

SQL> select * from scott.t1;

-————————————————-

SQL> delete scott.t1; 注意：删掉了t1并没有提交，老值在UNDO里。

2）在open 状态下删除datafile

[oracle@prod ~]$ rm /u01/oradata/prod/undotbs01.dbf

3）关闭数据库

SQL> shtudown abort

4）启动数据库mount

SQL> startup

数据库装载完毕。

ORA-01157: 无法标识/锁定数据文件 3 - 请参阅 DBWR 跟踪文件

ORA-01110: 数据文件 3: ‘/u01/oradata/prod/undotbs01.dbf’

5）还原并恢复UNDO数据文件

[oracle@prod prod]$ cp /u01/back1/undotbs01.dbf ./

SQL> recover datafile 3;

完成介质恢复。

6）打开数据库（会完成UNDO表空间数据的回滚）

SQL> alter database open;

数据库已更改

7）验证

SQL> select * from scott.t1;

-————————————————-

第四章：手工不完全恢复

一）基本概念

1）不完全恢复的特点：

①必须停机，在mount下运行重做日志。

②必须以sysdba身份连接进行不完全恢复。

③让整个database 回到过去某个时间点，不能避免数据丢失。

2）不完全恢复（Incomplete recover）适用环境：

①在过去的某个时间点重要的数据被破坏。

②最小化备份测试。

③在做完全恢复时，丢失了部分归档日志或当前online redo log（考点）

④当误删除了表空间时（使用备份的控制文件）

3）不完全恢复的基本类型：

①基于时间点（until time）使整个数据库恢复到过去的一个时间点前

②基于scn（until change）使整个数据库恢复到过去的某个SCN前

③基于cancel (until cancel) 使整个数据库恢复到归档日志或当前日志的断点前

④基于误删除表空间（使用备份的controlfile）使整个数据库恢复到误删除表空间前

二）不完全恢复的步骤

1）利用logminer 工具，找出在某个时间点所作的DDL 或DML 误操作（包括：时间点、scn、sql语句）

2）做当前数据库的最新全备。

3）使用还原点前的备份还原数据文件，

4）运用日志恢复所有数据文件，前滚至需要的时间点前停止。

5）使用resetlogs方式打开数据库。

三）使用当前控制文件做不完全恢复

示例1: 恢复过去某个时间点误删除的table（基于时间点的不完全恢复）

1）环境：scott用户在test表空间下有个t1表

SQL> conn scott/scott

SQL> select * from t1;

-———

2）误删除了t1表，并purge了。

SQL> drop table t1 purge;

SQL> select * from v$log;

SQL> alter system switch logfile;

SQL> /

SQL> select name from v$archived_log;

NAME

-——————————————————————————-

/u01/disk1/prod/arch_1_782662700_131.log

/u01/disk1/prod/arch_1_782662700_132.log

/u01/disk1/prod/arch_1_782662700_133.log drop table t1 purge的日志条目切换到此归档日志里了。

/u01/disk1/prod/arch_1_782662700_134.log

/u01/disk1/prod/arch_1_782662700_135.log

3）通过logmr 找出误操作的ddl命令的timestamp 或 scn，然后做一个不完全恢复。

①建目录、设置参数

$>mkdir -p /home/oracle/logmnr

SQL> alter system set utl_file_dir=’/home/oracle/logmnr’ scope=spfile;

SQL> startup force;

SQL> show parameter utl_file_dir

NAME TYPE VALUE

utl_file_dir string /home/oracle/logmnr

②指定logmnr目录

SQL> execute dbms_logmnr_d.build(‘dict.ora’,’/home/oracle/logmnr’,dbms_logmnr_d.store_in_flat_file);

③添加第一条日志条目

SQL> execute dbms_logmnr.add_logfile(logfilename=>’/u01/disk1/prod/arch_1_782662700_133.log’,options=>dbms_logmnr.new);

④添加后续日志条目

SQL> execute dbms_logmnr.add_logfile(logfilename=>’/u01/disk1/prod/arch_1_782662700_134.log’,options=>dbms_logmnr.addfile);

⑤解析日志条目

SQL> execute dbms_logmnr.start_logmnr(dictfilename=>’/home/oracle/logmnr/dict.ora’,options=>dbms_logmnr.ddl_dict_tracking);

⑥查看v$logmnr_contents视图

SQL> select username,scn,to_char(timestamp,’yyyy-mm-dd hh24:mi:ss’) time,sql_redo from v$logmnr_contents WHERE lower(sql_redo) like ‘drop table%’;

USERNAME SCN TIME SQL_REDO

SCOTT 1918000 2012-08-01 17:28:29 drop table t1 purge;

⑦关闭lognmr

SQL> execute dbms_logmnr.end_logmnr;

4）关闭数据库，删除所有dbf，准备做不完全恢复

SQL> shutdown abort

[oracle@prod ~]$ cd /u01/oradata/prod

[oracle@prod ~]$ rm *.dbf

5）还原所有备份的数据文件

[oracle@prod ~]$ cp /u01/back1/*.dbf ./

6）根据log miner提供的信息，做基于时间点的不完全恢复

SQL> startup

SQL> recover database until time ‘2012-08-01 17:28:29’;

ORA-00279: change 1917581 generated at 07/18/2012 16:46:34 needed for thread 1

ORA-00289: suggestion : /u01/disk1/prod/arch_1_782662700_133.log

ORA-00280: change 1917581 for thread 1 is in sequence #133

17:33:17 Specify log: {=suggested | filename | AUTO | CANCEL}

auto

Log applied.

Media recovery complete.

7）resetlogs方式打开数据库

SQL> alter database open resetlogs;

8）验证

SQL> select * from scott.t1;

-———

9）看看在resetlogs后，日志sequence重置了。

SQL> select * from v$log;

示例2：当前日志组损坏，造成数据库崩溃。

session 1

SQL> create table scott.t1(id int);

SQL> insert into scott.t1 values(1);

SQL> commit;

SQL> alter system archive log current;

SQL> insert into scott.t1 values(2);

SQL> commit;

SQL> select * from scott.t1;

-———

1 这条已经归档

2 这条在当前日志中，没有归档

SQL> select group#,sequence#,status from v$log;

GROUP# SEQUENCE# STATUS

1 22 CURRENT 查v$logfile知道group1是redo01.log

2 20 INACTIVE

3 21 ACTIVE

session 2

[oracle@cuug prod]$ rm redo01.log

session 1

SQL> shutdown abort

session 2

[oracle@cuug prod]$ rm *.dbf

[oracle@cuug prod]$ cp /u01/back1/*.dbf ./ 还原所有数据文件备份

session 1

SQL> startup

ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员 ORA-00312:

联机日志 1 线程 1: ‘/u01/oradata/prod/redo01.log’

SQL> recover database until cancel;

ORA-00279: 更改 1016334 (在 04/08/2016 15:45:03 生成) 对于线程 1 是必需的 ORA-00289:

建议: /u01/arch/prod/arch_1_904564083_22.log 一定要确认一下这个日志是否是当前日志。

ORA-00280: 更改 1016334 (用于线程 1) 在序列 #22 中

Specify log: {=suggested | filename | AUTO | CANCEL}

cancel

Media recovery cancelled.

SQL> alter database open resetlogs;

SQL> select * from scott.t1;

-———

四）使用备份控制文件做不完全恢复

1）为什么会使用备份的控制文件?

①当前控制文件全部损坏，而数据文件和控制文件的备份及当前日志处于不同的SCN版本

②当前控制文件没有损坏，但想要恢复误删除的表空间。

2）使用备份的控制文件恢复数据库的语法：

recover database until [time|change] using backup controlfile;

[time|change]是可选的，就是说如果条件满足，仍然可以做到完全恢复。

接下来会有如下选项：

Specify log: {=suggested | filename | AUTO | CANCEL}

此语法的出现是由于控制文件和当前日志不一致，当前日志的scn总是最新的，而控制文件可能是旧的或尚未更新的（类似shutdwon abort操作)。

AUTO：根据v$archived_log记录的归档日志前滚恢复，不包括前滚current log;

filename：不在v$archived_log中的日志，指控制文件中受损的归档记录或current log

CANCEL：退出。

3）使用backup controlfile子句的恢复数据库之后，一律要使用alter database open resetlogs打开数据库。

示例1

环境：当前所有控制文件损坏，数据文件损坏，有数据文件全备，但之后增加了表空间，并备份了配套的控制文件。

模式：所有数据文件备份（老）——(新建表空间abcd)—–备份控制文件（次新）——日志文件（新）

分析：新建表空间数据文件损坏, 全备里没有该数据文件的备份及控制文件描述，当前控制文件又丢失，只能用备份的控制文件恢复。

1）环境：

SQL> select * from v$tablespace;

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

GROUP# SEQUENCE# STATUS

1 7 CURRENT

2 5 INACTIVE

3 6 INACTIVE

SQL> create tablespace abcd datafile ‘/u01/oradata/prod/abcd01.dbf’ size 5m;

SQL> create table scott.a1 (name char(10)) tablespace abcd;

SQL> insert into scott.a1 values(‘a’);

SQL> commit;

SQL> select * from scott.a1;

NAME

-———

SQL> alter system switch logfile;

2）备份控制文件

SQL> alter database backup controlfile to ‘/u01/oradata/prod/con.bak1’;

3）模拟abcd01.dbf损坏和所有ctl损坏

[oracle@prod ~]$rm /u01/oradata/prod/abcd01.dbf 数据库open状态，删除abcd01.dbf数据文件

SQL> alter system flush buffer_cache; db buffer 清空

SQL> conn / as sysdba 换个session查看 a1表物理读失败

SQL> select * from scott.a1;

[oracle@prod ~]$ rm *.ctl

4）关闭数据库

SQL> shutdown abort;

5）恢复所有数据文件备份，准备做不完全恢复

[oracle@prod ~]$ cd /u01/oradata/prod

[oracle@prod ~]$ rm *.dbf

[oracle@prod ~]$ cp /u01/back1/*.dbf ./

[oracle@prod ~]$ cp con.bak1 control01.ctl

[oracle@prod ~]$ cp con.bak1 control02.ctl

[oracle@prod ~]$ cp con.bak1 control03.ctl

SQL> startup

SQL> col name for a50;

SQL> select file#,checkpoint_change#,name from v$datafile;

FILE# CHECKPOINT_CHANGE# NAME

1 6676574 /u01/oradata/prod/system01.dbf

2 6676574 /u01/oradata/prod/sysaux01.dbf

3 6676601 /u01/oradata/prod/abcd01.dbf

4 6676574 /u01/oradata/prod/user01.dbf

5 6676574 /u01/oradata/prod/example01.dbf

6 6676574 /u01/oradata/prod/test01.dbf

7 6676574 /u01/oradata/prod/undotbs01.dbf

SQL> select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#

1 6676343

2 6676343

3 0

4 6676343

5 6676343

6 6676343

7 6676343

可以看出：

①file3 在控制文件里记录是abcd01.dbf,而与之对应的数据文件3是不存在的，

②备份的数据备份的scn比控制文件scn还老。

6）使用备份控制文件恢复

SQL> recover database using backup controlfile;

ORA-00283: 恢复会话因错误而取消

ORA-01110: 数据文件 3: ‘/u01/oradata/prod/abcd01.dbf’

ORA-01157: 无法标识/锁定数据文件 3 - 请参阅 DBWR 跟踪文件

ORA-01110: 数据文件 3: ‘/u01/oradata/prod/abcd01.dbf’

此错是因为老备份里没有abcd表空间，但只要控制文件里记录了abcd就好办，方法是建一个datafile的空文件，而其中内容可由日志文件recover(前滚)时填补出来。

SQL> alter database create datafile ‘/u01/oradata/prod/abcd01.dbf’;

SQL> recover database using backup controlfile; 再次使用备份控制文件恢复

ORA-00308: 无法打开归档日志 ‘/u01/disk1/prod/arch_1_804846837_9.log’

ORA-27037: 无法获得文件状态

Linux Error: 2: No such file or directory

Additional information: 3

archive日志前滚结束了，但当前日志里还有信息需要恢复

注意: 对于这个例子来说，一定要看清提示：如果提示的不是归档的日志（是当前日志），则要直接要输入filename 而不能输入auto，否则open时会失败。

SQL> recover database using backup controlfile; 再次使用备份控制文件恢复

指定日志: {=suggested | filename | AUTO | CANCEL}

/u01/oradata/prod/redo03.log 把当前日志它。

已应用的日志。

完成介质恢复。

7）resetlogs打开数据库

SQL> alter database open resetlogs;

8）验证

SQL> select * from scott.a1;

NAME

-—————————————

示例2：

环境：当前控制文件损坏，新建表空间在备份控制文件之后

模式：全备（老）—–备份控制文件（次新）—–新建表空间abcd——日志文件（新）

分析：整个恢复过程中datafile结构有了变化，变化发生在备份控制文件之后，新增了表空间abcd。控制文件备份里没有此表空间记录，但日志里有。

1）环境

SQL> drop tablespace abcd including contents and datafiles;

SQL> alter database backup controlfile to ‘/u01/oradata/prod/con.bak’;

控制文件备份中没有abcd表空间

SQL> create tablespace abcd datafile ‘/u01/oradata/prod/abcd01.dbf’ size 5m;

SQL> create table scott.r1 (id int) tablespace abcd ;

SQL> insert into scott.r1 values(1);

SQL> commit;

SQL> select * from v$tablespace;

SQL> select * from scott.r1;

-———

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

GROUP# SEQUENCE# STATUS

1 1 CURRENT

2 0 UNUSED

3 0 UNUSED

2）模拟新建数据文件损坏

[oracle@prod ~]rm abcd01.dbf

SQL>alter system flush buffer_cache;

SQL>conn / as sysdba

SQL>select * from scott.r1;

3）关闭数据库

SQL>shutdown abort

4）还原所有数据文件，以老控制文件替换当前控制文件

[oracle@prod ~]$ cd /u01/oradata/prod

[oracle@prod ~]$ rm *.ctl

[oracle@prod ~]$ rm *.dbf

[oracle@prod ~]$ cp /u01/back1/*.dbf ./

[oracle@prod ~]$ cp con.bak2 control01.ctl

[oracle@prod ~]$ cp con.bak2 control02.ctl

[oracle@prod ~]$ cp con.bak2 control03.ctl

5）启动数据库

SQL> startup

ORACLE 例程已经启动。

……

数据库装载完毕。

ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项

SQL> select file#,checkpoint_change#,name from v$datafile;

SQL> select file#,checkpoint_change# from v$datafile_header;

6）使用备份控制文件恢复数据库

SQL> recover database using backup controlfile;

ORA-00279: 更改 6676343 (在 01/16/2013 14:11:39 生成) 对于线程 1 是必需的

ORA-00289: 建议: /u01/disk1/prod/arch_1_804846837_4.log

ORA-00280: 更改 6676343 (用于线程 1) 在序列 #4 中

指定日志: {=suggested | filename | AUTO | CANCEL}

auto

指定日志: {=suggested | filename | AUTO | CANCEL}

/u01/oradata/prod/redo01.log

ORA-00283: 恢复会话因错误而取消

ORA-01244: 未命名的数据文件由介质恢复添加至控制文件

ORA-01110: 数据文件 3: ‘/u01/oradata/prod/abcd01.dbf’

ORA-01112: 未启动介质恢复

SQL> select file#,checkpoint_change#,name from v$datafile;

FILE# CHECKPOINT_CHANGE# NAME

1 6678002 /u01/oradata/prod/system01.dbf

2 6678002 /u01/oradata/prod/sysaux01.dbf

3 6677999 /u01/oracle/dbs/UNNAMED00003 这是从日志回写到控制文件中的名字，需要重命名

4 6678002 /u01/oradata/prod/user01.dbf

5 6678002 /u01/oradata/prod/example01.dbf

6 6678002 /u01/oradata/prod/test01.dbf

7 6678002 /u01/oradata/prod/undotbs01.dbf

SQL> select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#

1 6678002

2 6678002

3 0 这里需要建立一个空的数据文件。

4 6678002

5 6678002

6 6678002

7 6678002

7）建立数据文件并对控制文件中未知的数据文件重命名

SQL> alter database create datafile ‘/u01/oracle/dbs/UNNAMED00003’ as ‘/u01/oradata/prod/abcd01.dbf’;

上面的命令一石二鸟，自动完成了两个动作

①加了一个数据文件abcd01.dbf，

②重命名控制文件UNNAMED00003为abcd01.dbf

SQL> select file#,checkpoint_change#,name from v$datafile;

FILE# CHECKPOINT_CHANGE# NAME

1 6678002 /u01/oradata/prod/system01.dbf

2 6678002 /u01/oradata/prod/sysaux01.dbf

3 6677999 /u01/oradata/prod/abcd01.dbf

4 6678002 /u01/oradata/prod/user01.dbf

5 6678002 /u01/oradata/prod/example01.dbf

6 6678002 /u01/oradata/prod/test01.dbf

7 6678002 /u01/oradata/prod/undotbs01.dbf

SQL> recover database using backup controlfile;

8）resetlogs打开数据库

SQL> alter database open resetlogs;

9）验证

SQL> select * from scott.r1;

-———