Oracle OCP笔记(30)数据库恢复

1.恢复概述 在Oracle环境中，还原(restore)和恢复(recover)术语都有十分准确的含义，还原文件就是从备份中提取文件，并将其返回到原始位置。如果数据文件受到损坏或丢失，还原操作将用备份副本替换它。但与数据库其余部分比，还原的文件已经过期。为了恢复文件，从重做日志流提取相关的更改矢量，并予以应用，将文件更新到与数据库其他部分同步为止. 如果采取适当的预防措施，丢失数据库文件并不意味着丢失数据: ·控制文件的多重化(multiplex) ·联机重做日志文件多重化 ·备份控制文件和数据文件 ·以archivelog模式运行数据库. 2.控制文件恢复 (1)丢失控制文件后的恢复 永远都不能彻底丢失控制文件，必须实现控制文件的多重化。如果控制文件的任何副本受损，数据库实例将立即异常终止，如果尝试启动，实例将进入NOMOUNT模式，并停在那里，只有CONTROL_FILES实例参数指定的所有副本都有效，才会加载数据库. 添加控制文件副本步骤: ·查看控制文件位置 -- select name from v$controlfile ·关闭数据库 ·复制控制文件(处于打开或加载模式时进行复制，副本是无效的) ·以NOMOUNT模式启动实例 ·更改CONTROLFILES参数，以便包含新副本. -- alter system set control_files='/u01/app/oracle/oradata/ORATEST/control01.ctl','/u01/app/oracle/flash_recovery_area/ORATEST/control02.ctl','/u01/app/oracle/oradata/ORATEST/control03.ctl' scope=spfile; ·再次关闭 ·以OPEN模式启动数据库 在NOMOUNT模式中，如果由于无法加载数据库导致启动停止，通过参数文件查找控制文件副本位置. -- select value from v$parameter where name='control_files'; (2)控制文件副本受损恢复 如果启动实例时，控制文件副本受损，则立即终止，只有修复了问题，才可以加载数据库。 了解哪个控制文件副本受损或丢失，须看警报日志(alert_SID.ora)，警报日志位置: select value from v$parameter where name='background_dump_dest'; -- 10g及以前 select value from v$diag_info where name ='Diag Trace'; -- 11g 修复受损文件，用v$parameter查询中列出的继续存在的文件之一，覆盖受损文件. 3.联机重做日志文件恢复 如果实现了联机重做日志的多重化，丢失单个成员并不会带来问题，只要每个联机重做日志文件组至少还有一个有效成员，数据库会继续运行，如果数据库关闭，可以正常打开。但需要做很多工作，将多条信息写出到警报日志。但服务器警报系统不会报告重做日志文件成员丢失的问题。在联机重做日志文件组成员均丢失的情况下实例将终止，且无法打开。 了解联机重做日志文件成员多重化及文件状态 select * from v$logfile; SATATUS: INVALID -- 无效则需要采取行动更正. STALE -- 尚未使用，不是问题 alter database clear logfile group 3; -- 修复受损成员: 删除和重建日志文件组3 如果日志文件组是最新的、活动的或未归档的，clear将出错。执行下面的切换日志、归档后在修复。 alter system switch logfile; alter system checkpoint; alter system archive log all; 4.数据文件恢复 (1)在noarchivelog模式中丢失数据文件 noarchivelog模式中不存在任何恢复概念: 无法使用将还原的备份前移到当前状态的重做内容。无法打开包含过期数据文件的数据库，否则将损坏系统的一致性。 文件受损唯一采取的做法是通过删除文件所在的表空间而不再查找文件，或者还原整个数据库: 数据文件、控制文件和联机重做日志文件。 如果没有联机重做日志备份，则需要重建: alter database open resetlogs; 在noarchivelog模式下，唯一可能还原的是整个数据库，这种模式下可能不执行任何恢复。 (2)在archivelog模式中丢失数据文件 ·SYSTEM和UNDO表空间的数据文件是关键数据文件，如果在数据库打开状态受损，则将终止，在还原和恢复之前将无法打开数据库。 ·其它数据文件没那么重要，如果在数据库打开状态受损受损，数据库会自动使它们脱机，数据库继续处于打开状态。 ·SYSTEM和UNDO表空间的数据文件只能在加载状态(mount)修复数据文件。 ·其它数据文件可以在加载时修复，也可以在加载时脱机后打开数据库后再修复。 select name,online_status,error from v$datafile join v$recover_file using (file#) 加载模式恢复数据文件 ·加载数据库 -- startup mount ·还原受损的文件 -- 从备份的数据文件复制到需要还原的文件 ·进行恢复 -- recover datafile 6; -- 如果数据文件序号为6 ·联机数据文件 -- alter database datafile 6 online; -- system,undo表空间数据文件可能不需要联机操作. ·打开数据库 -- alter database open; 打开模式恢复数据文件(只能恢复普通数据文件，不能恢复system、undo表空间文件) ·加载数据库 -- startup mount ·脱机受损文件 -- alter database datafile 6 offline drop; -- 如果数据文件序号为6 ·打开数据库 -- alter database open; ·还原受损文件 -- 从备份的数据文件复制到需要还原的文件 ·进行恢复 -- recover datafile 6; -- 如果数据文件序号为6 ·联机数据文件 -- alter database datafile 6 online; 5.数据恢复顾问程序(Data Recovery Advisor) (1)健康检查和自动诊断仓库 健康检查(Health Monitor)会在错误情况出现时自动运行，也可以根据DBA的指示以手动方式运行。检查结果不存储在数据库中，而是存储在文件系统中，因为有些错误出现时数据库可能不可用，因此需要一个外部仓库来存储健康检查结果，这个仓库就是诊断仓库。 诊断仓库(Automatic Dagnostic Repository,ADR)，位于实例参数diagnostic_dest指定的目录中。 diagnostic_dest: /u01/app/oracle diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/alert diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/cdump diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/hm diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/incident diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/incpkg diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/ir diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/lck diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/log diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/Metadata diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/Metadata_dgif diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/Metadata_pv diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/stage diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/sweep diagnostic_dest/diag/rdbms/<DBNAME>/<INSTANCENAME>/trace (2)在数据库不同的运行阶段执行不同的健康检查 ·在nomount模式，只检查控制文件的完整性(DB Structure Integrity) ·在mount模式，检查控制文件、联机重做日志文件和数据文件头的完整性(DB Structure Integrity),检查联机日志和归档日志是否可用、是否受损(Redo Integrity Check). ·在open模式，可以检查每个数据块是否受损，检查数据字典和撤消段的完整性。 (3)使用数据恢复顾问DRA步骤: ·运行rman确定full备份集 rman target / RMAN> list backup of tablespace sysaux; RMAN> shutdown immediate; RMAN> exit ·模拟丢失文件场景(删除数据文件) rm sysaux01.dbf ·启动数据库，出现错误(被动运行Health Monitor，错误信息将会自动记录到诊断仓库ADR中) sqlplus / as sysdba; sql> startup ORA-01157: cannot identify/lock data file 3 - see DBWR trace file ORA-01110: data file 3: '/u01/app/oracle/oradata/sales/sysaux01.dbf' sql> exit ·列出故障(使用rman命令list failure) rman target / RMAN> list failure; ·提供修复建议(会生成修复脚本) RMAN> advise failure; Repair script: /u01/app/oracle/diag/rdbms/sales/sales/hm/reco_1545056905.hm ·执行修复(运行修复脚本) RMAN> repair failure; --或者运行脚本: @/u01/app/oracle/diag/rdbms/sales/sales/hm/reco_1545056905.hm 脚本的内容如下: # restore and recover datafile restore ( datafile 3 ); recover datafile 3; sql 'alter database datafile 3 online'; ·启动数据库 RMAN> startup; RMAN> exit; (4)手工运行Health Monitor检查(数据库必须处于打开状态) ·在sql*Plus调用PL/sql程序包DBMS_HM中的过程. ·在Database Control使用数据恢复顾问程序(Related Links/Advisor Central/Checkers). (5)完整还原(在rman中运行) restore database force; recover datebase; 原文链接：https://www.f2er.com/oracle/213560.html