原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://jiujian.blog.51cto.com/444665/1361353

当数据库需要进行介质恢复时,为了确保数据库能够顺利的执行恢复过程,恢复数据库到当前状态。我们要做的就是验证!验证什么呢?当然是验证备份集和归档是否能够进行有效的恢复。防止我们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 执行restorerecover过程如下

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下我们如何正确的执行数据库恢复的更多相关文章

  1. OCA读书笔记(16) - 执行数据库恢复

    16. Performing Database Recovery 确定执行恢复的必要性访问不同接口(EM以及命令行)描述和使用可用选项,如RMAN和Data Recovery Advisor执行恢复- ...

  2. (Les16 执行数据库恢复)-表空间恢复

    NOARCHIVELOG模式下丢失了数据文件     数据库处于NOARCHIVELOG模式时,如果丢失任何数据文件,执行以下步骤         1.如果实例尚未关闭,请关闭实例         2 ...

  3. (Les16 执行数据库恢复)-重做日志文件恢复

    丢失重做日志文件         丢失了重做日志文件组中的某个成员,并且组中至少还有一个成员:             -不会影响实例的正常操作.             -预警日志中会收到一条信息, ...

  4. (Les16 执行数据库恢复)-控制文件恢复

    测试丢失所有控制文件恢复[20180517]     rman target /   show all;   configure channel 1 device type disk format ' ...

  5. Oracle 12c Dataguard 数据库恢复

    http://allthingsoracle.com/rolling-forward-a-physical-standby-database-using-the-recover-command/ 当主 ...

  6. Oracle下的ArcSDE创建的空间数据库的备份与恢复

    对Oracle下ArcSDE创建的空间数据库, 整体备份.恢复或迁移. 一.imp和exp命令方式 1.1 数据库完整备份 检查数据库字符集是否一致 SQL>select userenv(‘la ...

  7. 转:Oracle下创建ASM磁盘总结

    Oracle下创建ASM磁盘总结 文章转载:https://blog.csdn.net/okhymok/article/details/78791841?utm_source=blogxgwz1 2. ...

  8. Oracle下的IF EXISTS()

    妈蛋..作为一个使用了SQL SERVER有4 5年的程序猿,开始用Oracle真他妈不习惯.写法真他妈不一样.比如像写个像IF EXISTS(SELECT * FROM sys.tables WHE ...

  9. 对于Oracle中分页排序查询语句执行效率的比较分析

    转自:http://bbs.csdn.net/topics/370033478 对于Oracle中分页排序查询语句执行效率的比较分析 作者:lzgame 在工作中我们经常遇到需要在Oracle中进行分 ...

随机推荐

  1. 用python编写的excel拆分小工具

    from datetime import date,datetime from openpyxl import Workbook from openpyxl import load_workbook ...

  2. 关于list,字符串的小记录

    1.关于操作list的命令: a.append("hi") 这个可以在list的最后一项加上个这个字符串"hi",a是list的名字. del a[3] 删去l ...

  3. 如何正确从他人机器MySQL数据库下拷贝出.sql,再导入到自己windows下MySQL数据库(图文详解)

    不多说,直接上干货! 我这里,是放在桌面上. 登陆数据库 然后, mysql -uroot -p 默认是回车. 创建数据库 CREATE DATABASE securityonion_db; 目的,就 ...

  4. linux高负载下mysql数据库彻底优化

    同时在线访问量继续增大 对于1G内存的服务器明显感觉到吃力严重时甚至每天都会死机 或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月MySQL使用是很具伸缩性的算法,因此你通常能用很少的内存运行或 ...

  5. C# 控制台如何播放音频文件

    OK,先看下代码: using System.Reflection; using System.Media; namespace ThePlay { class Program { static vo ...

  6. 通用mapper的generator

    <plugin> <groupId>org.mybatis.generator</groupId> <artifactId>mybatis-genera ...

  7. JDBC基础-setFetchSize方法

    在Statement和ResultSet接口中都有setFetchSize方法 void setFetchSize(int rows) throws SQLException 查看API文档 Stat ...

  8. 给Sublime Text3 设置自定义快捷键

    Preferrences -> Key Bindings-User打开用户自定义快捷键文件,添加以下代码,保存. [ { "keys": ["ctrl+shift+ ...

  9. 学习Python的一些Tips

    0. Python安装 官网提供多种方式,一般Windows下直接安装exe即可:Linux下基本上自带python:另外也提供源码,也可自行编译: 若安装后无法使用,则检查一下环境变量是否设置正确. ...

  10. zipkin 服务追踪

    服务追踪,就是对请求接口的追踪并保存. 在测试的过程中我们会发现,有时候,程序刚刚启动后,刷新几次,并不能看到任何数据,原因就是我们的spring-cloud-sleuth收集信息是有一定的比率的,默 ...