第一部分:手工备份与恢复
+第一章:备份恢复概述
+一)数据库故障类型:
+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;
+ ID
+-———
+ 1
+在这个状态下先在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;
+ ID
+-———
+ 2
+ 3 这条记录未提交,恢复时会回滚掉
+ 1
+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;
+ ID
+-———
+ 2
+ 1
+示例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
+-————————————————-
+1
+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;
+ID
+-————————————————-
+1
+示例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;
+ID
+-————————————————-
+1
+2
+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;
+ID
+-————————————————-
+1
+2
+第四章:手工不完全恢复
+一)基本概念
+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;
+ ID
+-———
+ 1
+ 2
+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;
+ ID
+-———
+ 1
+ 2
+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;
+ ID
+-———
+ 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;
+ ID
+-———
+ 1
+四)使用备份控制文件做不完全恢复
+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
+-———
+a
+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
+-—————————————
+a
+示例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;
+ ID
+-———
+ 1
+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;
+ ID
+-———
+