十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
SPFILE文件损坏的恢复场景:
创新互联建站基于分布式IDC数据中心构建的平台为众多户提供西部信息服务器租用 四川大带宽租用 成都机柜租用 成都服务器租用。
场景 | 恢复操作 | |
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 SQL>alter database open; |
无完整备份(缺归档等) | 否 | RMAN不完全恢复 1、基本时间恢复 c:\set nls_date_format=yyyy-dd-mm hh34: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 hh34: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 SQL>alter database recover datafile SQL>alter tablespace datafile | |
无完整备份(缺归档等) | 否 | 如果缺失归档:对库进行基于时间点不完整恢复 如果无备份: 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 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 hh34: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 hh34: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; |