RMAN restore & recovery

1. Restore and Recovery
with RMAN

2. Overview
• 前面介绍了RMAN的备份, 这一章的主题是使用
RMAN进行还原(restore)和恢复(recovery)操作. 还
原指的是从某个备份中还原整个文件, 恢复指的
是应用重做日志, 将数据恢复到最新的状态. 本章
包含以下内容:
– 数据恢复顾问(DRA, Data Recovery Advisor)
– 使用DRA进行数据库恢复
– 对数据文件丢失执行完全恢复
– 执行不完全恢复
– 使用增量备份执行恢复
– 执行基于镜像备份的快速恢复
– 使用控制文件备份进行恢复
– 执行介质恢复(Block Media Recovery)

3. Data Recovery Advisor
• DRA用于诊断与数据库恢复相关的问题, 它能够生成相应的脚本对
数据文件和控制文件进行修复, 可以通过RMAN或者database control
调用DRA. DRA依赖于Health Monitor和Automatic diagnostic repository
(ADR).
• Health Monitor & ADR
HM用于执行预定义的检查(自动执行或者由DBA手动执行)并将检查
的结果存放在指定的文件系统目录中, 目录的位置由数据库参数
DIAGNOSTIC_DEST参数指定. 该目录就被称为ADR. 不同的HM检查在
不同的数据库运行阶段被执行:
– 在nomount阶段, 只有”db structure integrity”检查能够执行, 它用于检查
控制文件的完整性;
– 在mount阶段, ”db structure integrity”用于检查控制文件、在线重做日
志文件以及数据文件的完整性; “redo integrity check”检查在线重做日志
和归档日志的可访问性和是否有损坏;
– 在open阶段, 可以运行相应的检查扫描数据文件发现是否有坏块, 检查
数据字典和回滚段的完整性.
当数据库处于open状态时, 可以通过DMBS_HM接口或者database
control调用HM检查, 路径Advisor Central -> Checkers.

4. Data Recovery Advisor
- Capabilities & Limitations
• DRA可以提供下面的功能:
– 当数据库处在nomount阶段, DRA可以诊断控制文件是否有问题, 并生成相应的修复脚本;
– 当数据库处在mount阶段, DRA检查与数据文件、在线重做日志文件相关的问题, 并生成相应的
修复脚本.
Tip: DRA只能使用在单实例的情况, 不能使用在RAC环境.
• DRA Exercise
-- 登录RMAN并备份sysaux表空间, 之后关闭数据库
rman target /;
backup as backupset tablespace sysaux;
shutdown immediate;
-- 使用操作系统命令删除sysaux表空间文件
mv sysaux01.dbf sysaux01.dbf.bak
-- 启动数据库, 在mount阶段出现错误
startup;
-- 登录rman使用DRA查看错误并修复
rman target /;
list failure; -- 指出sysaux表空间文件丢失
advise failure; -- 生成修复脚本, 并指明脚本的位置. 该脚本包含如下RMAN指令:
restore datafile 2;
recover datafile 2;

5. Data Recovery Advisor
- DRA in Action
• DRA使用HM收集的信息发现问题, 并生成RMAN脚本,
按照如下方式使用DRA:
– 运行HM检查收集错误信息, 比如在启动数据库时会自动运
行HM;
– 列出错误, 在RMAN中运行命令list failure列出错误;
– 生成错误建议, 在RMAN中运行命令advise failure;
– 执行RMAN脚本进行修复. 可以通过手动执行修复脚本中的
命令或者直接运行命令repair failure.
可以通过RMAN交互式命令行执行DRA或者使用
database control图形界面进行操作, 接下来演示使用
后者.

6. Data Recovery Advisor
- DRA in Action
启动之后数据库处在mount阶段,
此时登录em将显示perform
recovery按钮, 点击.
点击Advise and Recover按钮生成
RMAN修复脚本.
点击执行RMAN脚本.

7. Database Restore
& Recovery
• 对于oracle数据库而言有的文件是关键的(critical), 另一些文件则是非关键
(non-critical)文件. 关键文件有:
– 控制文件的所有拷贝;
– SYSTEM表空间的数据文件;
– 回滚表空间的数据文件.
非关键文件有:
– 在线重做日志文件的多路复用拷贝;
– 临时表空间数据文件;
– 非SYSTEM表空间和回滚表空间的数据文件.
• 作为一个通用的原则, 对于数据文件的错误应该使用完全修复(complete
recovery): 还原数据文件, 并应用重做日志恢复所有数据; 非完全修复
(incomplete recovery)则是将数据文件恢复到过去的某个时间点, 该时间点
之后的数据被丢失. 应该尽量执行完全修复, 但是在某些情况下比如归档日
志丢失则需要执行不完全修复. 执行完全修复的步骤如下:
– 将数据文件设置为offline;
– 还原数据文件;
– 恢复数据文件;
– 将数据文件设置为online.

8. Complete Recovery
- Data File Loss
• 根据数据库归档模式的设置, 数据文件的修复需要采取不同的动作:
– 非归档模式
对整个数据库进行还原, 这会造成大量的数据丢失. 执行下面
的脚本:
shutdown abort;
startup mount;
restore database;
alter database open resetlogs;
如果数据库执行了增量备份则需要在还原之后执行下面的命
令应用增量备份:
recover database noredo;
– 归档模式/non-critical
非关键文件损坏会导致数据库仅部分可用(partial available), 相应的文件被
设置为offline状态而不能被访问. 如果备份是使用RMAN进行的, 那么非关
键文件的修复可以完全自动进行. RMAN会选择最有效的全量备份和增量
备份, 并应用相应的归档日志实现文件的修复.
Tip: 如果存在增量备份, 那么RMAN会优先应用这些增量备份而不是使用
归档日志.

9. Complete Recovery
- Data File Loss
– 归档模式/non-critical
演示非关键数据文件的恢复.
• 创建一个表空间, 并在其中创建一张表;
create tablespace noncrit
datafile '/opt/oracle/oradata/noncrit.dbf' size 2m;
create table ex16(c1 date) tablespace noncrit;
insert into ex16 values(sysdate);
commit;
• 备份该表空间
backup as backupset tablespace noncrit;
• 使用文本编辑器(vi/notepad)删除数据文件的前几个字节, 这会导致该
数据文件损坏.
• 清空SGA数据块缓存, 之后查询ex16表将出现错误.
alter system flush buffer_cache;
select * from ex16; sql 'alter database datafile 7 offline';
• 使用DRA修复数据文件, restore datafile 7;
list failure; -- 提示数据文件损坏; recover datafile 7;
advise failure; -- 生成RMAN修复脚本 sql 'alter database datafile 7 online';
repair failure; -- 执行数据文件修复

10. Complete Recovery
- Data File Loss
– 归档模式/critical
关键数据文件的损坏或者丢失会导致实例被立即终
止, 应该使用硬件冗余的手段防止这种问题出现, 比
如使用RAID. 关键数据文件的修复步骤与非关键文件
的基本是相同的, 差别在于:
• 将数据库启动到mount阶段;
• 无需将数据文件offline, 此时数据库实例已经终止.

11. Incomplete Recovery
• 不完全恢复首先将整个数据库还原到某一个时间点, 然后应用自该时间点
开始的部分重做日志, 这意味着有一部分数据被丢失. 通常而言只有在归档
日志文件丢失或者丢失所有的在线重做日志文件时, 才会执行不完全恢复.
另外一种执行部分恢复的理由是, 用户进行了误操作(比如批量更新和删除)
需要将数据库还原到某个时间点.
Tip: 对于用户的误操作, oracle提供了一系列的闪回技术, 可以在不执行恢
复的情况下将数据库”闪回”到之前的状态.
• 不完全恢复按照以下四个步骤执行:
– 启动数据库到mount阶段;
– 还原所有的数据文件;
– 恢复数据库到指定的时间点;
– 使用reset logs选项打开数据库.
与完全恢复的区别是:
– 在丢失非关键文件的情况下, 完全恢复可以在数据库open阶段执行; 不完全恢
复只能在数据库处于mount阶段执行;
– 完全恢复只需要处理特定的数据文件(已损坏或者丢失), 不完全恢复则首先需
要对所有的数据文件进行还原.
– 非完全恢复仅应用部分重做日志到某个时间点, 完全恢复应用所有.
– 非完全恢复使用reset logs选项打开数据库.

12. Incomplete Recovery
• 非完全恢复在执行了数据文件的还原之后, 可以有以下三个选项将
数据库恢复到某个时间点,
– 指定时间(until time)
在RMAN中使用”until time”;
– 指定SCN(util system change number)
在RMAN中使用”until SCN”;
– 指定日志切换序号(util log sequence number).
在RMAN中使用”until SEQUENCE”.
使用RMAN进行不完全恢复, 示例:
run {startup mount;
set until time = "to_date('27-10-08 10:00:00','dd-mm-yy hh24:mi:ss')";
restore database;
recover database;
alter database open resetlogs;}
也可以使用如下语法:
restore database until time 'sysdate - 7';
recover database until time '27-OCT-08';

13. Controlfile
- Autobackup & Restore
• 控制文件对于oracle数据库至关重要, 控制文件的丢失或者损坏会导
致数据库直接崩溃. 另外RMAN也严重依赖于控制文件, 因为RMAN将
所有的备份信息存储在控制文件. 有两种方式可以避免控制文件丢
失导致的灾难性后果, 使用RMAN目录数据库(RMAN catalog database)
或者启用控制文件自动备份, 这里介绍后者.
• 在RMAN中使用如下configure命令开启控制文件的自动备份:
configure controlfile autobackup on;
在这种情况下, 每一个RMAN操作都会自动对控制文件和SPFILE进行
备份. 在需要的时候使用如下命令还原控制文件:
restore controfile from autobackup; -- nomount phase
如果SPFILE丢失, 首选创建一个包含DB_NAME参数的静态pfile文件,
使用该文件启动实例, 然后再执行以下命令:
set dbid 1234567890; -- dbid column of v$database
restore spfile from autobackup; -- nomount phase
Tip: 以上两个从自动备份中恢复SPFILE和控制文件的命令可以在数
据库处在nomount阶段执行, 其他的RMAN命令均需要数据库处在
mount和open阶段.

14. Using Image Copies
for Recovery
• 如果对数据库作了镜像备份(实际上是将数据库文件拷贝至另一个位置, 文件名
会发生变化), 那么应该使用该镜像对数据库进行还原, 这会大大地提高
还原的速度. 使用下面的命令执行镜像备份:
backup as copy database;
backup as copy datafile 4 format '/u02/df_copies/users.dbf';
使用如下RMAN脚本将数据文件切换到镜像:
run {sql 'alter database datafile 4 offline';
set newname for datafile 4 to '/u02/df_copies/users.dbf';
switch datafile 4;
recover datafile 4;
sql 'alter database datafile 4 online';}
使用以下命令将整个数据库还原至某个镜像:
switch database to copy;
镜像备份的另一个用法是, 首先创建一个镜像然后定时对该镜像应
用增量备份, 这样可以保证该镜像处在较新的状态, 从而大大缩小数
据库修复的时间, 使用下面的脚本:
run {backup incremental level 1 for recover of copy with tag 'inc_copy' database;
recover copy of database with tag 'inc_copy' ;}

15. Block Recovery
- Detection
• 如果数据文件仅仅是少数的数据块(非header部分)被损
坏, 那么该文件仍可以保持可用, 只有在查询需要读取
这些坏块的数据时会提示错误. RMAN可以用于检查数
据文件中的坏块, 并进行修复.
• Detection of Corrupt Blocks
RMAN在执行备份时, 如果遇到坏块默认会立即停止备
份并且抛出错误. 可以设置RMAN允许一定的坏块存在,
示例允许最多100个坏数据块:
run {set maxcorrupt for datafile 7 to 100;
backup datafile 7;}
备份中的坏块信息根据备份类型的不同分别保存在视
图v$backup_corruption和v$copy_corruption中. 另外可
以设置RMAN不检查物理坏块, 如下:
backup nochecksum datafile 7;

16. Block Recovery
- Block Media Recovery
• RMAN在检测到数据文件坏块时可以执行数据块介质恢复
(BMR), 这样的好处是: 数据文件仍可用并且恢复的时间大大
减少. BMR会使用相应的数据块备份对坏块进行还原, 之后
再应用重做日志. 块恢复必须是完全的.
• 使用如下命令执行坏块的恢复:
– 指定单个数据文件的单个数据块进行恢复
block recover datafile 7 block 5;
– 指定多个数据文件的多个数据块进行恢复
block recover datafile 7 block 5,6,7 datafile 9 block 21,25;
– 使用指定序号或者标签的备份集进行坏块恢复
block recover datafile 7 block 5 from backupset 1093;
block recover datafile 7 block 5 from tag monthly_whole;
– 修复上一次备份中所有的坏块, 使用至少7天之前的备份
block recover corruption list until time sysdate - 7;

17. END