SPFILE文件损坏的恢复场景： 

场景

恢复操作

SPFILE文件损坏

有备份

SQL> startup nomount;

RMAN> restore spfile from '/backup/ctl_XXXX';

SQL> shutdown immediate;

Oracle instance shut down

SQL> startup;

无备份

手工创建pfile文件并生成spfile文件

一般只需几个关键参数就能把库拉起，但考虑到性能问题，得恢复到丢失前的参数设置，可以从以下几个地方找：

1.awr报告里面的spfile,在awr报告最后

2.alert log里面在库启动时都会很很多初始参数输出

 

控制文件恢复场景及演示：https://blog.51cto.com/wyzwl/1978252

场景

恢复方法

恢复条件

其中一个控制文件损坏

1.1 拷贝冗余的控制文件

1、具有多路冗余控制文件镜像

2、其它冗余控制文件没有损坏

1.2 修改control_files参数去除损坏文件

同上、但不推荐该方法进行恢复

所有的控制文件损坏

有备份

2.1 通过rman备份控制文件进行完全恢复

1、通过rman备份了控制文件

2、备份了控制文件之后有连续的归档和redo文件

2.2 通过rman备份控制文件进行不完全恢复

1、通过rman备份了控制文件

2、备份了控制文件之后归档或redo文件丢失

2.3 通过trace备份控制文件进行完全恢复

1、通过trace备份了控制文件

2、备份了控制文件之后有连续的归档和redo文件

2.4 通过trace备份控制文件进行不完全恢复

1、通过trace备份了控制文件

2、备份了控制文件之后归档或redo文件丢失

无备份

2.5 通过手工重建控制文件进行恢复(noresetlogs)

1、无有效的备份控制文件

2、redo文件无丢失和无损坏

2.6 通过手工重建控制文件进行恢复(resetlogs)

1、无有效的备份控制文件

2、redo文件丢失或损坏

2.7 通过SNAPSHOT CONTROLFILE文件进行恢复

此处为记录一个恢复控制文件的方法（不常使用）

 

日志文件（redo log）恢复场景及演示（不考虑非归档模式）：

场景

是否归档

恢复操作

STATUS=INACTIVE

日志信息无需写入数据文件

1.在线时损坏

2.正常关闭后损坏

ARC=YES

open和mount状态都可以执行，不会丢失数据

SQL>alter database clear logfile group 1;

ARC=NO

open和mount状态都可以执行，不会丢失数据

SQL>alter database clear unarchived logfile group 1;

STATUS=ACTIVE

日志信息需要写入数据文件

1.在线时损坏

2.不正常关闭后损坏

ARC=YES

1.实例在线时损坏，直接在线执行，不丢数据(千万别关库)

SQL>alter database clear unarchived logfile group 1;

2.实例不正常关闭后损坏，丢数据

SQL>startup nomount;

SQL>alter system set "_allow_resetlogs_corruption"=ture scope=spfile;

SQL>shutdown immediate;

SQL>startup mount;

SQL>recover database until cancel;

SQL>alter database open resetlogs;

ARC=NO

1.实例在线时损坏，直接在线执行，不丢数据

SQL>alter database clear unarchived logfile group 1;

2.实例不正常关闭后损坏，不丢数据

SQL>startup nomount;

SQL>alter system set "_allow_resetlogs_corruption"=ture scope=spfile;

SQL>shutdown immediate;

SQL>startup mount;

SQL>recover database until cancel;

SQL>alter database open resetlogs;

STATUS=CURRENT

日志信息无需写入数据文件

正常关闭后损坏

ARC=NO

实例正常关闭后损坏，不丢失数据

SQL>startup mount;

SQL>alter database clear unarchived logfile group 1;

日志信息需要写入数据文件

1.在线时损坏

2.不正常关闭后损坏

ARC=NO

1.实例在线时损坏，直接在线执行，不丢数据(千万别关库)

SQL>alter system switch logfile;

SQL>alter database clear unarchived logfile group 1;

2.实例不正常关闭后损坏，会丢失数据

SQL>startup nomount;

SQL>alter system set "_allow_resetlogs_corruption"=ture scope=spfile;

SQL>shutdown immediate;

SQL>startup mount;

SQL>recover database until cancel;

SQL>alter database open resetlogs;

表空间和数据文件恢复场景及演示： 

场景

是否完全恢复

恢复操作

数据文件

系统表空间数据文件(system,sysaux,undo)

有完整备份（归档，rman）

是

SQL>startup mount;

SQL>alter database recover datafile <file_id>;

SQL>alter database open;

无完整备份（缺归档等）

否

RMAN不完全恢复

 1、基本时间恢复

  c:\set nls_date_format=yyyy-dd-mm hh24:mi:ss

  c:\rman target  sys/oracle@test nocatalog

  RMAN>run {

   startup force mount;

   set until time='2010-08-22 12:00:08';

   restore database;

   recover database;

   sql 'alter database open resetlogs;

   }

 2、基于SCN恢复

  RMAN>run {

   startup force mount;

   set until scn=123456;

   restore database;

   recover database;

   sql 'alter database open resetlogs';

   }

 3、基于日志序列号恢复

  RMAN>run {

   startup force mount;

   set until seqence=10;

   restore database;

   recover database;

   sql 'alter database open resetlogs';

   }

 4、基于备份控制文件恢复

  c:\set nls_date_format=yyyy-dd-mm hh24:mi:ss

  c:\rman target  sys/oracle@test nocatalog

  RMAN>startup force nomount;

  RMAN>set dbid=1113606269;

  RMAN>restore controlfile from autobackup maxseq 6;

  RMAN>alter database mount;

  RMAN>run {

   set until time='2010-08-22 12:00:08';

   restore database;

   recover database;

   sql 'alter database open resetlogs;

   }

普通表空间数据文件

有完整备份（归档，rman）

是

SQL>alter database datafile <datafile_name> offlie;

SQL>alter database recover datafile <datafile_name>;

SQL>alter tablespace datafile <datafile_name>  online;

无完整备份（缺归档等）

否

如果缺失归档：对库进行基于时间点不完整恢复

如果无备份：

alter database datafile ‘xxx’ offline drop;

或者重建控制文件，代价就是丢失这个数据文件里的数据

表空间

系统表空间

有完整备份（归档，rman）

是

SQL> shutdown immediate  --如果无法使用immediate关闭数据库，则使用shutdown abort

RMAN> run

{

  startup mount;

  restore tablespace system;

  recover tablespace system;

  alter database open;

}

无完整备份（缺归档等）

否

同系统表空间数据文件无完整备份恢复一样，得进行不完全恢复：

1、基本时间恢复

2、基于SCN恢复

3、基于日志序列号恢复

4、基于备份控制文件恢复

普通表空间

有完整备份（归档，rman）

是

SQL>alter tablespace users offlie;

SQL>alter database recover tablespace <tablespace_name>;

SQL>alter tablespace users online;

无完整备份（缺归档等）

否

如果缺失归档：对库进行基于时间点不完整恢复

如果无备份：

alter database datafile ‘xxx’ offline drop;

全库恢复

所有表空间

有完整备份（归档，rman）

是

RMAN>run {

   startup mount;

   restore database;

   recover database;

   sql 'alter database open resetlogs;

   }

无完整备份（缺归档等）

否

同系统表空间数据文件无完整备份恢复一样，得进行不完全恢复：

1、基本时间恢复

2、基于SCN恢复

3、基于日志序列号恢复

4、基于备份控制文件恢复

各种误删表数据操作恢复场景：

场景

恢复操作

误删表数据恢复（delete)

闪回查询，闪回版本查询

select * from emp as of timestamp to_timestamp('2004-04-04 09:30:00', 'yyyy-mm-dd hh:mi:ss');

若11g开启了闪回归档，可利用这个新特性恢复

12c的rman新特性可单独恢复表

误删表数据恢复（truncate)

利用fy_recover_data离线数据文件恢复

误删表恢复（drop)

1.没有相同名字

flashback table 原表名 to before drop [rename to 新表名];

或

flashback table "回收站中的表名" to before drop [rename to 新表名];

2.有相同的名字

用户可能会经常多次创建和删除同一个表，第一个版本恢复到 TEST1，将第二个版本恢复到 TEST2

FLASHBACK TABLE "BIN$04LhcpnoanfgMAAAAAANPw==$0" TO BEFORE DROP RENAME TO TEST1;

FLASHBACK TABLE "BIN$04LhcpnqanfgMAAAAAANPw==$0" TO BEFORE DROP RENAME TO TEST2;

误修改的VIEW,FUNTION,PROCEDURE,PACKAGE代码恢复

1、使用ODU恢复

2、利用闪回查询恢复

3、通过基表进行恢复

闪回的场景及演示介绍：

技术

应用场景

步骤

限制

TSPITR

1、表空间中，某个表的重要数据被破坏或删除。

2、误用DDL语言更改了表空间中的一个或多个表的结构，因此无法使用闪回来恢复这些表。

3、表被误删，并且已不在回收站中，如使用了带purge选项的删表操作。

set nls_date_format=yyyy-mm-dd hh24:mi:ss;

recover tablespace users until time '2018-01-15 09:20:00' auxiliary destination '/auxdata';

sql 'alter tablespace users online';

1、数据库必须位于归档模式，且存在相应的备份集合。

2、要恢复的表空间必须是自包含的，不依赖于其它表空间中的对象。例如，如果一个表在其它表空间中包含索引，则它们或者一起参与恢复，或者先将依赖关系解除才能做恢复。

flashback

在正式生产环境一般都不会轻易闪回整库，在测试环境中，可以利用这个特性来还原数据，比如第一轮UAT测试完成后，回到初始化状态，可以进行下一轮测试

启用flashback database步骤

查询数据库是否开启闪回：select flashback_on from v$database;

关闭数据库à启动到mount状态à开启归档，设置闪回，不能设置归档路径，归档存放在闪回日志目录下：alter system set log_archive_dest=’’;à设置闪回日志目录：alter system set db_recovery_file_dest=’+data’;à设置闪回日志保留3天时间，默认1440分钟：alter system set flashback_retention_target=4320;à设置闪回日志存储空间大小：alter system set db_recovery_file_dest_size=5000g;à打开闪回alter database flashback on;à查询是否开启à打开DB:alter database open;

如何闪回

查询闪回能恢复的最久时间段

Select oldest_flashback_scn,oldest_flashback_time from v$flashback_database_log;

重启DB到MOUNT状态à闪回数据库到某个时间点：flashback database to timestamp to_timestamp(‘2016-01-02 00:00:00’,’yyyy-mm-dd hh24:mi:ss’);

或闪回DB到某SCN:flashback database to scn xxx;

1.flashback 数据库不能解决media failure 这种错误rman是唯一选择

2.若删除了数据文件或用户shrink 缩小了数据文件大小，flashback不能用，需要先利用rman把删除之前或缩小文件之前恢复，再闪回

3.如果控制文件恢复出来或重建控制文件，不能闪回

4.闪回恢复到最早SCN，取决flashback log 中记录的最早SCN

其它恢复工具的介绍：

恢复工具

恢复参考

ODU工具的使用

强大的恢复工具，需要版权，有试用版，功能较小

http://www.oracleodu.com/cn/

AMDU恢复

针对ASM磁盘无法挂载后的数据文件抽取恢复

http://www.eygle.com/archives/2012/03/asm_amdu_recovery.html

logmnr

在delete误删数据无法使用快照闪回恢复时，使用logmnr挖归档，可以恢复数据

添加需要分析的在线日志

exec dbms_logmnr.add_logfile(logfilename=>'/opt4/arch/1_22560_911528823.dbf',options=>dbms_logmnr.new);

添加其他在线日志

exec dbms_logmnr.add_logfile(logfilename=>'/opt4/arch/1_22560_911528823.dbf',options=>dbms_logmnr.addfile);

分析添加的文件

execute dbms_logmnr.start_logmnr(options => dbms_logmnr.dict_from_online_catalog + dbms_logmnr.committed_data_only+dbms_logmnr.print_pretty_sql);

查询对应内容

select * from v$logmnr_contents;