在oracle下我们如何正确的执行数据库恢复
当数据库需要进行介质恢复时，为了确保数据库能够顺利的执行恢复过程，恢复数据库到当前状态。我们要做的就是验证！验证什么呢？当然是验证备份集和归档是否能够进行有效的恢复。防止我们restore后，执行recover时却发现归档缺少了一堆，顿时傻眼。
比方说，在数据库当前日志序列号为时我们完全备份了数据库。在数据库当前联机日志序列号为时数据库损坏需要恢复。假设数据库联机日志组为组，则可以推断数据库联机日志序列号分别为、、。因此当数据库执行、、、、、、、以及联机日志、、来进行完全恢复。
为了能够顺利的执行完全恢复，我们在执行恢复前，需要对restore调用的备份集进行恢复验证（语句为：restorevalidate database）以及验证recover过程所需的归档3-10（语句为：restore validate archivelog sequence between 3 and10）。
以完全恢复为例，举例如下：
1数据库当前日志seq号为59，我们备份数据库
SQL> selectgroup#,archived,sequence#,status from v$log;
GROUP# ARC SEQUENCE# STATUS
---------- --- ---------- ----------------
1 YES 58 INACTIVE
2 NO 59 CURRENT
3 YES 57 INACTIVE
RMAN> backup database format'/backup/fullbk-%T-%U.bak';
Starting backup at 2014-02-17 12:03:28
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafilebackup set
channel ORA_DISK_1: specifying datafile(s)in backup set
input datafile file number=00004name=/oracle/CRM/CRM/users01.dbf
input datafile file number=00001name=/oracle/CRM/CRM/system01.dbf
input datafile file number=00002name=/oracle/CRM/CRM/sysaux01.dbf
input datafile file number=00003name=/oracle/CRM/CRM/undotbs01.dbf
input datafile file number=00005name=/oracle/CRM/CRM/crm.dbf
input datafile file number=00006name=/oracle/CRM/test.dbf
input datafile file number=00008name=/oracle/CRM/jxc.dbf
input datafile file number=00007name=/oracle/CRM/user01.dbf
channel ORA_DISK_1: starting piece 1 at2014-02-17 12:03:29
channel ORA_DISK_1: finished piece 1 at2014-02-17 12:05:57
piecehandle=/backup/fullbk-20140217-3ep0rj0h_1_1.bak tag=TAG20140217T120328 comment=NONE
channel ORA_DISK_1: backup set complete,elapsed time: 00:02:28
channel ORA_DISK_1: starting full datafilebackup set
channel ORA_DISK_1: specifying datafile(s)in backup set
including current control file in backupset
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at2014-02-17 12:06:01
channel ORA_DISK_1: finished piece 1 at2014-02-17 12:06:02
piecehandle=/backup/fullbk-20140217-3fp0rj56_1_1.bak tag=TAG20140217T120328comment=NONE
channel ORA_DISK_1: backup set complete,elapsed time: 00:00:01
Finished backup at 2014-02-17 12:06:02
2 当数据库联机日志为69时数据库崩溃需要进行介质恢复
SQL> selectgroup#,archived,sequence#,status from v$Log;
GROUP# ARC SEQUENCE# STATUS
---------- --- ---------- ----------------
1 YES 67 INACTIVE
2 YES 68 INACTIVE
3 NO 69 CURRENT
注意：这里其实我们可以推断，如果数据库需要恢复到当前状态，那么归档到归档的所有归档，必须能够进行有效的恢复。我们只需要发起restore database preview命令，Oracle便可以给出我们归档列表，继续往下看。
3 判定当前数据库恢复所需要备份集和归档条目
注意对于restore database preview列出的归档条目，recover执行完全恢复时并不会完全应用，因为完全恢复recover过程是：应用相关归档+ 所有联机日志，seq号从小到大依次应用。后面会抓取recover过程，这里先暂且提一下。
RMAN> restore database preview;
Starting restore at 2014-02-17 16:14:21
using target database control file insteadof recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=63 device type=DISK
List of Backup Sets
===================
BS Key Type LV Size Device TypeElapsed Time Completion Time
------- ---- -- ---------- ----------------------- -------------------
108 Full 2.03G DISK 00:02:26 2014-02-17 12:05:38
BP Key: 108 Status:AVAILABLE Compressed: NO Tag: TAG20140217T120328
Piece Name:/backup/fullbk-20140217-3ep0rj0h_1_1.bak
注意：这里显示备份片总是rman资料库中记录的数据文件最新的备份
List of Datafiles in backup set 108
File LV Type Ckp SCN CkpTime Name
---- -- ---- ---------- ------------------- ----
1 Full 4028039 2014-02-17 12:03:29/oracle/CRM/CRM/system01.dbf
2 Full 4028039 2014-02-17 12:03:29/oracle/CRM/CRM/sysaux01.dbf
3 Full 4028039 2014-02-17 12:03:29/oracle/CRM/CRM/undotbs01.dbf
4 Full 4028039 2014-02-17 12:03:29/oracle/CRM/CRM/users01.dbf
5 Full 4028039 2014-02-17 12:03:29 /oracle/CRM/CRM/crm.dbf
6 Full 4028039 2014-02-17 12:03:29 /oracle/CRM/test.dbf
7 Full 4028039 2014-02-17 12:03:29 /oracle/CRM/user01.dbf
8 Full 4028039 2014-02-17 12:03:29 /oracle/CRM/jxc.dbf
using channel ORA_DISK_1
List of Archived Log Copies for databasewith db_unique_name CRM
=====================================================================
Key Thrd Seq S Low Time
------- ---- ------- - -------------------
131 1 59 A 2014-02-17 11:55:37
Name:/oracle/archivelog/arch_1_59_839098938.arch
132 1 60 A 2014-02-17 12:10:20
Name:/oracle/archivelog/arch_1_60_839098938.arch
133 1 61 A 2014-02-17 12:10:21
Name:/oracle/archivelog/arch_1_61_839098938.arch
134 1 62 A 2014-02-17 12:10:26
Name:/oracle/archivelog/arch_1_62_839098938.arch
135 1 63 A 2014-02-17 12:10:30
Name:/oracle/archivelog/arch_1_63_839098938.arch
136 1 64 A 2014-02-17 12:10:31
Name:/oracle/archivelog/arch_1_64_839098938.arch
137 1 65 A 2014-02-17 12:10:32
Name:/oracle/archivelog/arch_1_65_839098938.arch
138 1 66 A 2014-02-17 12:10:33
Name:/oracle/archivelog/arch_1_66_839098938.arch
139 1 67 A 2014-02-17 12:10:34
Name:/oracle/archivelog/arch_1_67_839098938.arch
140 1 68 A 2014-02-17 12:10:36
Name:/oracle/archivelog/arch_1_68_839098938.arch
Media recovery start SCN is 4028039
Recovery must be done beyond SCN 4028039 toclear datafile fuzziness
Finished restore at 2014-02-17 16:14:24
注意：
（从前面可知数据库当前联机日志文件）也就是说restore database preview显示的归档列表结果中最后一个归档seq号总是比当前联机日志（当前联机日志也就是查看v$log状态为currnt的日志组）文件seq号小于1.
后，、、联机日志文件继续推进该数据库来实现整个数据库完全恢复过程。
下面将演示整个验证和恢复过程:
4 验证恢复时需要用到的备份集是否能够正常恢复。
RMAN> restore validate database;
注意：这条命令直接会去rman资料库中找最新的备份集进行验证，也就是restore database preview命令显示的备份集。
Starting restore at 2014-02-17 16:14:59
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation ofdatafile backup set
channel ORA_DISK_1: reading from backuppiece /backup/fullbk-20140217-3ep0rj0h_1_1.bak
channel ORA_DISK_1: piecehandle=/backup/fullbk-20140217-3ep0rj0h_1_1.bak tag=TAG20140217T120328
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete,elapsed time: 00:00:36
Finished restore at 2014-02-17 16:15:35
5 验证恢复时应用的归档
RMAN> restore validate archivelogsequence between 59 and 66;
Starting restore at 2014-02-17 16:16:34
using channel ORA_DISK_1
channel ORA_DISK_1: scanning archived log /oracle/archivelog/arch_1_59_839098938.arch
channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_60_839098938.arch
channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_61_839098938.arch
channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_62_839098938.arch
channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_63_839098938.arch
channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_64_839098938.arch
channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_65_839098938.arch
channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_66_839098938.arch
Finished restore at 2014-02-17 16:16:37
6 执行restore和recover过程如下
RMAN> restore database;
Starting restore at 2014-02-17 16:36:23
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=63 device type=DISK
channel ORA_DISK_1: starting datafilebackup set restore
channel ORA_DISK_1: specifying datafile(s)to restore from backup set
channel ORA_DISK_1: restoring datafile 00001to /oracle/CRM/CRM/system01.dbf
channel ORA_DISK_1: restoring datafile00002 to /oracle/CRM/CRM/sysaux01.dbf
channel ORA_DISK_1: restoring datafile00003 to /oracle/CRM/CRM/undotbs01.dbf
channel ORA_DISK_1: restoring datafile00004 to /oracle/CRM/CRM/users01.dbf
channel ORA_DISK_1: restoring datafile00005 to /oracle/CRM/CRM/crm.dbf
channel ORA_DISK_1: restoring datafile00006 to /oracle/CRM/test.dbf
channel ORA_DISK_1: restoring datafile00007 to /oracle/CRM/user01.dbf
channel ORA_DISK_1: restoring datafile00008 to /oracle/CRM/jxc.dbf
channel ORA_DISK_1: reading from backuppiece /backup/fullbk-20140217-3ep0rj0h_1_1.bak
channel ORA_DISK_1: piecehandle=/backup/fullbk-20140217-3ep0rj0h_1_1.bak tag=TAG20140217T120328
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete,elapsed time: 00:02:08
Finished restore at 2014-02-17 16:38:35
注意：归档开始应用。
或者也可以从restore database后数据文件头部的scn值，对比归档的first_change# 和 next_change# 推断出recover 需要应用归档开始。
SQL> select hxfil,fhscn,fhrba_seq fromx$kcvfh;
HXFIL FHSCN FHRBA_SEQ
---------- ---------------- ----------
1 4028039 59
2 4028039 59
3 4028039 59
4 4028039 59
5 4028039 59
6 4028039 59
7 4028039 59
8 4028039 59
8 rows selected.
当然restore database 后，我们也可以直接查询v$recvoery_log来得到recover过程需要应用的归档条目，如下所示：
select * from v$recovery_log;
THREAD# SEQUENCE# TIME ARCHIVE_NAME
---------- ---------- --------- ------------------------------------------------------------
1 59 17-FEB-14/oracle/archivelog/arch_1_59_839098938.arch
1 60 17-FEB-14/oracle/archivelog/arch_1_60_839098938.arch
1 61 17-FEB-14 /oracle/archivelog/arch_1_61_839098938.arch
1 62 17-FEB-14/oracle/archivelog/arch_1_62_839098938.arch
1 63 17-FEB-14/oracle/archivelog/arch_1_63_839098938.arch
1 64 17-FEB-14/oracle/archivelog/arch_1_64_839098938.arch
1 65 17-FEB-14/oracle/archivelog/arch_1_65_839098938.arch
1 66 17-FEB-14/oracle/archivelog/arch_1_66_839098938.arch
RMAN> recover database;
Starting recover at 2014-02-17 16:45:01
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 59is already on disk as file /oracle/archivelog/arch_1_59_839098938.arch
archived log for thread 1 with sequence 60is already on disk as file /oracle/archivelog/arch_1_60_839098938.arch
archived log for thread 1 with sequence 61is already on disk as file /oracle/archivelog/arch_1_61_839098938.arch
archived log for thread 1 with sequence 62is already on disk as file /oracle/archivelog/arch_1_62_839098938.arch
archived log for thread 1 with sequence 63is already on disk as file /oracle/archivelog/arch_1_63_839098938.arch
archived log for thread 1 with sequence 64is already on disk as file /oracle/archivelog/arch_1_64_839098938.arch
archived log for thread 1 with sequence 65is already on disk as file /oracle/archivelog/arch_1_65_839098938.arch
archived log for thread 1 with sequence 66is already on disk as file /oracle/archivelog/arch_1_66_839098938.arch
archived log for thread 1 with sequence 67is already on disk as file /oracle/archivelog/arch_1_67_839098938.arch
archived log for thread 1 with sequence 68is already on disk as file /oracle/archivelog/arch_1_68_839098938.arch
archived log filename=/oracle/archivelog/arch_1_59_839098938.arch thread=1 sequence=59
archived log file name=/oracle/archivelog/arch_1_60_839098938.archthread=1 sequence=60
archived log filename=/oracle/archivelog/arch_1_61_839098938.arch thread=1 sequence=61
archived log filename=/oracle/archivelog/arch_1_62_839098938.arch thread=1 sequence=62
archived log filename=/oracle/archivelog/arch_1_63_839098938.arch thread=1 sequence=63
archived log filename=/oracle/archivelog/arch_1_64_839098938.arch thread=1 sequence=64
archived log filename=/oracle/archivelog/arch_1_65_839098938.arch thread=1 sequence=65
archived log filename=/oracle/archivelog/arch_1_66_839098938.arch thread=1 sequence=66
media recovery complete, elapsed time:00:00:08
Finished recover at 2014-02-17 16:45:16
注意：这里可以清楚的看到应用的归档条目（红色标记处）
7 跟踪recover过程内容如下：
alter database recoverlogfile '/oracle/archivelog/arch_1_59_839098938.arch'
Media Recovery Log/oracle/archivelog/arch_1_59_839098938.arch
Mon Feb 17 16:45:12 2014
ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_59_839098938.arch'...
alter database recoverlogfile '/oracle/archivelog/arch_1_60_839098938.arch'
Media Recovery Log/oracle/archivelog/arch_1_60_839098938.arch
ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_60_839098938.arch'...
alter database recoverlogfile '/oracle/archivelog/arch_1_61_839098938.arch'
Media Recovery Log/oracle/archivelog/arch_1_61_839098938.arch
ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_61_839098938.arch'...
alter database recoverlogfile '/oracle/archivelog/arch_1_62_839098938.arch'
Media Recovery Log/oracle/archivelog/arch_1_62_839098938.arch
ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_62_839098938.arch'...
alter database recoverlogfile '/oracle/archivelog/arch_1_63_839098938.arch'
Media Recovery Log/oracle/archivelog/arch_1_63_839098938.arch
ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_63_839098938.arch'...
alter database recoverlogfile '/oracle/archivelog/arch_1_64_839098938.arch'
Media Recovery Log/oracle/archivelog/arch_1_64_839098938.arch
ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_64_839098938.arch'...
alter database recoverlogfile '/oracle/archivelog/arch_1_65_839098938.arch'
Media Recovery Log/oracle/archivelog/arch_1_65_839098938.arch
ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_65_839098938.arch'...
alter database recoverlogfile '/oracle/archivelog/arch_1_66_839098938.arch'
Media Recovery Log/oracle/archivelog/arch_1_66_839098938.arch
Mon Feb 17 16:45:14 2014
Recovery of Online RedoLog: Thread 1 Group 1 Seq 67 Reading mem 0
Mem# 0: /oracle/CRM/CRM/redo01.log
Recovery of Online RedoLog: Thread 1 Group 2 Seq 68 Reading mem 0
Mem# 0: /oracle/CRM/CRM/redo02.log
Recovery of Online RedoLog: Thread 1 Group 3 Seq 69 Reading mem 0
Mem# 0: /oracle/CRM/CRM/redo03.log
Media Recovery Complete(CRM)
注意：通过跟踪整个恢复过程，可以清楚的观察到在用recover进行完全恢复时，先应用归档，后再通过所有联机日志文件推进整个数据库来实现完全恢复的过程。
8 如果数据库进行不完全恢复如何获取恢复所需要的归档
以基于时间点恢复为例，我们可以这么使用得出恢复到这个时间点数据库需要的归档列表。
run{
sql 'alter session setnls_date_format="yyyy-mm-dd hh24:mi:ss"';
set until time='2013-12-09:05:50:12';
restore database preview;
}
总结：
1 在对数据库进行恢复的时，第一步先看看数据库是否归档，第二步看看数据库是否有备份，第三步验证备份和归档的有效性。最后执行整个恢复过程。
2 完全恢复时，通过对比restore database preview 显示的归档列表seq号和联机日志组的seq号，我们便可以清楚的推出数据库完全恢复时，recover需要应用的归档。
本文出自 “myblog” 博客，请务必保留此出处http://jiujian.blog.51cto.com/444665/1361353
在oracle下我们如何正确的执行数据库恢复的更多相关文章
- OCA读书笔记(16) - 执行数据库恢复
16. Performing Database Recovery 确定执行恢复的必要性访问不同接口(EM以及命令行)描述和使用可用选项,如RMAN和Data Recovery Advisor执行恢复- ...
- (Les16 执行数据库恢复)-表空间恢复
NOARCHIVELOG模式下丢失了数据文件 数据库处于NOARCHIVELOG模式时,如果丢失任何数据文件,执行以下步骤 1.如果实例尚未关闭,请关闭实例 2 ...
- (Les16 执行数据库恢复)-重做日志文件恢复
丢失重做日志文件 丢失了重做日志文件组中的某个成员,并且组中至少还有一个成员: -不会影响实例的正常操作. -预警日志中会收到一条信息, ...
- (Les16 执行数据库恢复)-控制文件恢复
测试丢失所有控制文件恢复[20180517] rman target / show all; configure channel 1 device type disk format ' ...
- Oracle 12c Dataguard 数据库恢复
http://allthingsoracle.com/rolling-forward-a-physical-standby-database-using-the-recover-command/ 当主 ...
- Oracle下的ArcSDE创建的空间数据库的备份与恢复
对Oracle下ArcSDE创建的空间数据库, 整体备份.恢复或迁移. 一.imp和exp命令方式 1.1 数据库完整备份 检查数据库字符集是否一致 SQL>select userenv(‘la ...
- 转：Oracle下创建ASM磁盘总结
Oracle下创建ASM磁盘总结 文章转载:https://blog.csdn.net/okhymok/article/details/78791841?utm_source=blogxgwz1 2. ...
- Oracle下的IF EXISTS()
妈蛋..作为一个使用了SQL SERVER有4 5年的程序猿,开始用Oracle真他妈不习惯.写法真他妈不一样.比如像写个像IF EXISTS(SELECT * FROM sys.tables WHE ...
- 对于Oracle中分页排序查询语句执行效率的比较分析
转自:http://bbs.csdn.net/topics/370033478 对于Oracle中分页排序查询语句执行效率的比较分析 作者:lzgame 在工作中我们经常遇到需要在Oracle中进行分 ...
随机推荐
- ES相关概念理解
Elasticsearch特点:分布式,高性能,高可用,高伸缩的搜索和分析: 1)可作为一个大型分布式集群,处理PB级别的数据,服务大型公司,亦可运行在少数或单台设备上服务小型公司 分布式的特性: E ...
- poj2455Secret Milking Machine(二分+最大流）
链接 二分距离,小于当前距离的边容量+1,使最后流>=t 注意 会有重边 #include <iostream> #include<cstdio> #include< ...
- 【转】哪个更快：Java堆还是本地内存
译文出处: shenzhang 原文出处:原文链接 使用Java的一个好处就是你可以不用亲自来管理内存的分配和释放.当你用new关键字来实例化一个对象时,它所需的内存会自动的在Java堆中分配.堆 ...
- mongodb的安装及配置安装服务
1. 安装mongodb数据库 mongodb官方网址:https://www.mongodb.org 安装好之后的步奏: 第一步:规划你的安装目录和数据库文件的存储路径,我打算将Mongo的程序文件 ...
- ubuntu 下service php5-fpm restart 报错 stop: Unknown instance: 解决
问题描述: 在安装完扩展后,重启php-fpm,发现一直停止报错 stop: Unknown instance: 通过查看进程,也查询不到该主进程 解决办法: 干掉现在正在执行的进程 pkill ph ...
- Javaweb学习笔记2—Tomcat和http协议
今天来讲javaweb的第二个阶段学习. 老规矩,首先先用一张思维导图来展现今天的博客内容. ps:我的思维是用的xMind画的,如果你对我的思维导图感兴趣并且想看到你们跟详细的备注信息,请点击下 ...
- 为sublime Text3 安装插件JS Format
1. 安装package control 菜单 View - Show Console 或者 ctrl + ~ 快捷键,调出 console.将以下 Python 代码粘贴进去并 enter 执行,不 ...
- Jmeter官网文档翻译
Jmeter目录 入门 1.0概述 测试计划建设 负载测试运行 负载测试分析 开始吧 1.1要求 1.1.1 Java版本 1.1.2操作系统 1.2可选 1.2.1 Java编译器 1.2.2 SA ...
- HashMap Hashtable TreeMap LinkedHashMap 分析
首先对hash的了解:就是关键字,和数据建立关系的映射. hash常用算法:假设我们中的字符有相应的内部编码,当然在实际过程中,我们不可能将所有的编码当做hash值. 平方取中法,将所得的内部编码平方 ...
- Python3简明教程（十二）—— 模块
在这节我们将要学习 Python 模块相关知识.包括模块的概念和导入方法,包的概念和使用,第三方模块的介绍,命令行参数的使用等. 模块 到目前为止,我们在 Python 解释器中写的所有代码都在我们退 ...