controlfile与备份恢复
controlfile与备份恢复
数据库正常关闭,trace controlfile信息.
***************************************************************************
DATABASE ENTRY
***************************************************************************
Database checkpoint: Thread=1 scn: 0x0000.000d39f4
.
.
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 11, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x1 flags:0x0 dirty:0
low cache rba:(0xffffffff.ffffffff.ffff) on disk rba:(0x2.1289.0)
on disk scn: 0x0000.000d39c9 09/20/2013 01:16:34
.
.
***************************************************************************
DATA FILE RECORDS
**************************************************************************
Checkpoint cnt:101 scn: 0x0000.000d39f4 09/20/2013 01:16:34
Stop scn: 0x0000.000d39f4 09/20/2013 01:16:34
此时数据文件状态为一致的,无须进行介质恢复.
我们知道重建的控制文件能够从当前的日志文件获得正确的SCN及时间点等信息。同样地，控制文件也能够从数据文件中获得详细的检查点信息等。
测试版本恢复前后控制文件的变化。
--当前control file的检查点信息 2013-09-20 05:19:58.492
DUMP OF CONTROL FILES, Seq # 1210 = 0x4ba
V10 STYLE FILE HEADER:
Compatibility Vsn = 186646528=0xb200000
Db ID=1395399339=0x532c1aab, Db Name='AUGUST'
Activation ID=0=0x0
Control Seq=1210=0x4ba, File size=594=0x252
File Number=0, Blksiz=16384, File Type=1 CONTROL
.
***************************************************************************
DATABASE ENTRY
***************************************************************************
Database checkpoint: Thread=1 scn: 0x0000.000d39f7
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
low cache rba:(0x2.4593.0) on disk rba:(0x2.45d2.0)
on disk scn: 0x0000.000d4621 09/20/2013 05:19:16
***************************************************************************
DATA FILE RECORDS
***************************************************************************
Checkpoint cnt:102 scn: 0x0000.000d39f7 09/20/2013 01:22:31
Stop scn: 0xffff.ffffffff 09/20/2013 01:16:34
--版本恢复
RMAN> shutdown abort
RMAN> startup mount;
RMAN> list backup of database;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
1 Full 964.65M DISK 00:02:07 19-SEP-13
BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20130919T011640
Piece Name: /u01/app/oracle/flash_recovery_area/august/AUGUST/backupset/2013_09_19/o1_mf_nnndf_TAG20130919T011640_93odqb65_.bkp
List of Datafiles in backup set 1
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 838482 19-SEP-13 /u01/app/oracle/oradata/august/august/system01.dbf
2 Full 838482 19-SEP-13 /u01/app/oracle/oradata/august/august/sysaux01.dbf
3 Full 838482 19-SEP-13 /u01/app/oracle/oradata/august/august/undotbs01.dbf
4 Full 838482 19-SEP-13 /u01/app/oracle/oradata/august/august/users01.dbf
RMAN> restore database;
Starting restore at 20-SEP-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/august/august/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/august/august/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/august/august/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/august/august/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/flash_recovery_area/august/AUGUST/backupset/2013_09_19/o1_mf_nnndf_TAG20130919T011640_93odqb65_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/flash_recovery_area/august/AUGUST/backupset/2013_09_19/o1_mf_nnndf_TAG20130919T011640_93odqb65_.bkp tag=TAG20130919T011640
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:05:47
Finished restore at 20-SEP-13
--版本恢复后的control file信息 Fri Sep 20 05:47:45 PDT 2013
DUMP OF CONTROL FILES, Seq # 1221 = 0x4c5
V10 STYLE FILE HEADER:
Compatibility Vsn = 186646528=0xb200000
Db ID=1395399339=0x532c1aab, Db Name='AUGUST'
Activation ID=0=0x0
Control Seq=1221=0x4c5, File size=594=0x252
File Number=0, Blksiz=16384, File Type=1 CONTROL
***************************************************************************
DATABASE ENTRY
***************************************************************************
Database checkpoint: Thread=1 scn: 0x0000.000d39f7
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
low cache rba:(0x2.49d1.0) on disk rba:(0x2.4a0c.0)
on disk scn: 0x0000.000d4925 09/20/2013 05:30:19
***************************************************************************
DATA FILE RECORDS
***************************************************************************
Checkpoint cnt:102 scn: 0x0000.000d39f7 09/20/2013 01:22:31
Stop scn: 0xffff.ffffffff 09/20/2013 01:16:34
看上去控制文件中的信息似乎并没有更新数据文件的检查点信息。
似乎这些信息，与数据库恢复关系不大。用着崩溃恢复时，确定恢复点。（自动进行恢复）
如果是版本恢复，restore database之后，需要手动进行前滚恢复 recover database，这个检查点似乎理解起来没什么关系。
OK，那么怎么确定从哪个归档日志开始恢复呢？
查看restore database后的数据文件头文件
SQL> alter session set events ‘ immediate trace name file_hdrs level 10’
Tablespace #2 - UNDOTBS1 rel_fn:3
Creation at scn: 0x0000.000b7982 08/13/2009 23:56:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x313e782e scn: 0x0000.000b8338
prev reset logs count:0x296a3120 scn: 0x0000.00000001
recovered at 09/20/2013 05:35:23
status:0x0 root dba:0x00000000 chkpt cnt: 19 ctl cnt:18
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.000ccb52 09/19/2013 01:16:41 /*换算成10进制：838482*/
thread:1 rba:(0x6.1f1d.10)
查看归档日志信息。
SQL> select sequence#,first_change#,next_change#,to_char(next_time,'yy-mm-dd hh24:MM:ss') next_time from v$archived_log;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# NEXT_TIME
---------- ------------- ------------ ----------------------------------
2 757280 767227 13-09-15 05:09:34
3 767227 780016 13-09-15 07:09:34
4 780016 811911 13-09-16 04:09:24
5 811911 835483 13-09-19 00:09:56
6 835483 840784 13-09-19 20:09:40
7 840784 841197 13-09-19 20:09:53
8 841197 845016 13-09-19 23:09:25
1 841198 864921 13-09-20 00:09:36
我们可以清楚的得知，需要从sequence 6的归档日志开始恢复。
注意我们的日志是reset过的，通过until sequence好像没有得到我们预期的结果。
RMAN> recover database until sequence 7;
Starting recover at 20-SEP-13
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 6 is already on disk as file /u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_19/o1_mf_1_6_93qgls17_.arc
archived log for thread 1 with sequence 7 is already on disk as file /u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_19/o1_mf_1_7_93qh7sqx_.arc
archived log for thread 1 with sequence 1 is already on disk as file /u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_20/o1_mf_1_1_93qzp568_.arc
archived log file name=/u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_19/o1_mf_1_6_93qgls17_.arc thread=1 sequence=6
archived log file name=/u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_19/o1_mf_1_7_93qh7sqx_.arc thread=1 sequence=7
archived log file name=/u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_20/o1_mf_1_1_93qzp568_.arc thread=1 sequence=1
unable to find archived log
archived log thread=1 sequence=2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 09/20/2013 06:27:33
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 2 and starting SCN of 864921
可以看出，RMAN找的是reset之后的sequence 6，但是这个log并没有产生，所以报错了。
那试一试，通过until time的方式进行恢复。
关于until time有两点要说明：
1. 时间格式的设置，如果不设置，RMAN很可能不认识你所输入的格式。
因为RMAN以环境变量来读取时间格式，这点与sqlplus的固定格式不同，需要进行设置。
RMAN> sql 'alter session set nls_date_format="yyyy-mm-dd hh24:mi:ss"';
2. RMAN-20207错误。
RMAN> recover database until time '2013-09-19 08:09:00';
Starting recover at 20-SEP-13
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 09/20/2013 06:54:46
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time
默认认为until time的时间不能早于RESETLOGS的时间。
查看日志生命周期版本信息。
RMAN> list incarnation of database 'august';
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 AUGUST 1395399339 PARENT 1 13-AUG-09
2 2 AUGUST 1395399339 PARENT 754488 15-SEP-13
3 3 AUGUST 1395399339 CURRENT 841198 19-SEP-13
切换到周期2中，也就是我们resetlogs之前的一个周期。
RMAN> reset database to incarnation 2;
database reset to incarnation 2
重新尝试recover database until time,一直提示RMAN-06556错误，改用scn。
RMAN> recover database until scn 845016;
Starting recover at 20-SEP-13
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 09/20/2013 07:48:30
RMAN-06556: datafile 1 must be restored from backup older than SCN 845016
依然报错。
重新restore后设置incarnation然后recover
RMAN> recover database until scn 845016;
Starting recover at 20-SEP-13
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 6 is already on disk as file /u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_19/o1_mf_1_6_93qgls17_.arc
archived log for thread 1 with sequence 7 is already on disk as file /u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_19/o1_mf_1_7_93qh7sqx_.arc
archived log for thread 1 with sequence 8 is already on disk as file /u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_19/o1_mf_1_8_93qs3s52_.arc
archived log file name=/u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_19/o1_mf_1_6_93qgls17_.arc thread=1 sequence=6
archived log file name=/u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_19/o1_mf_1_7_93qh7sqx_.arc thread=1 sequence=7
archived log file name=/u01/app/oracle/flash_recovery_area/august/AUGUST/archivelog/2013_09_19/o1_mf_1_8_93qs3s52_.arc thread=1 sequence=8
media recovery complete, elapsed time: 00:00:11
Finished recover at 20-SEP-13
成功，看来这样恢复是没有问题的。
RMAN> alter database open resetlogs;
database opened
--测试：新的sequence时候会将旧的归档覆盖掉？不会！
SQL> select sequence#,first_change#,next_change#,to_char(next_time,'yy-mm-dd hh24:MM:ss') next_time from v$archived_log;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# NEXT_TIME
---------- ------------- ------------ ----------------------------------
2 757280 767227 13-09-15 05:09:34
3 767227 780016 13-09-15 07:09:34
4 780016 811911 13-09-16 04:09:24
5 811911 835483 13-09-19 00:09:56
6 835483 840784 13-09-19 20:09:40
7 840784 841197 13-09-19 20:09:53
8 841197 845016 13-09-19 23:09:25
1 841198 864921 13-09-20 00:09:36
1 841198 864921 13-09-20 00:09:36
2 864921 2.8147E+14
0 0 0
查看当前incarnation情况。
RMAN> list incarnation of database 'august';
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 AUGUST 1395399339 PARENT 1 13-AUG-09
2 2 AUGUST 1395399339 PARENT 754488 15-SEP-13
3 3 AUGUST 1395399339 ORPHAN 841198 19-SEP-13
4 4 AUGUST 1395399339 CURRENT 845017 20-SEP-13
controlfile与备份恢复的更多相关文章
- Oracle RMAN备份恢复指导书
目 录 1 目的与范围... 1 2 术语和定义... 1 3 角色和职责... 2 4 使用RMAN备份数据库... 2 4.1.1 检查数据库模式... 2 4.1.2 连接到target数据库. ...
- 中小型数据库 RMAN CATALOG 备份恢复方案(一)
对于数据库的稳定性,高可用,跨平台以及海量数据库的处理,Oracle 数据库通常是大型数据库和大企业的首选.尽管如此,仍然不乏很多中小企业想要品尝一下Oracle腥味,因此在Oracle环境中也有不少 ...
- RMAN catalog备份恢复方案
对于数据库的稳定性,高可用,跨平台以及海量数据库的处理,Oracle 数据库通常是大型数据库和大企业的首选.尽管如此,仍然不乏很多中小企业想要品尝一下Oracle腥味,因此在Oracle环境中也有不少 ...
- 如何通过rman的增量备份恢复dataguard中standby端的数据
很多正在使用dataguard的客户,都会遇到一个棘手的问题: 在备份端与主库同步的过程中由于网络原因或磁盘问题导致一个或多个归档日志丢失,进而dataguard同步无法继续.很多客户都选择了重新全库 ...
- ORACLE 11G 利用泠备份恢复standby库
利用泠备份恢复standby数据库 開始使用泠备份进行db恢复 2.1,停止掉standby库 SQL> shutdown immediate; Database closed. Databas ...
- Oracle 备份恢复实例
Oracle 备份恢复实例:三思笔记 1 shutdown abort 系统归档模式,有备份 create table xx as select * from emp; update xx set e ...
- SYSTEM 表空间管理及备份恢复
标签: systemoraclesqldatabasefile数据库 2010-11-28 18:14 12689人阅读 评论(0) 收藏 举报 分类: -----Oracle备份恢复(16) 版权声 ...
- 手工备份恢复oracle数据库
手工备份恢复oracle数据库: 虽然已经有了rman工具 但是手工恢复oracle能够让你对oracle数据库有更加深入的了解 数据库一致性开机条件: 数据文件 scn,控制文件 scn,redo ...
- Oracle数据库备份恢复，巡检须要关注的对象设置以及相关恢复概述
数据库备份恢复.巡检须要关注的对象设置: 1.数据库名称,以及DBID: --dbid在v$database中 SYS@ORCL>select dbid,name from v$dat ...
随机推荐
- mybatis和spring整合
参考文档: http://www.cnblogs.com/jyh317/p/3834142.html http://www.cnblogs.com/xdp-gacl/p/4271627.html ht ...
- DotNetCore跨平台~服务总线_事件总线的重新设计
理论闲话 之前在.netFramework平台用的好好的,可升级到.net core平台之后,由于不再需要二进制序列化,导致咱们的事件机制遇到了问题,之前大叔的事件一直是将处理程序序列化后进行存储的, ...
- python多线程爬虫设计及实现示例
爬虫的基本步骤分为:获取,解析,存储.假设这里获取和存储为io密集型(访问网络和数据存储),解析为cpu密集型.那么在设计多线程爬虫时主要有两种方案:第一种方案是一个线程完成三个步骤,然后运行多个线程 ...
- 常用的一些js和css
/*给一组li里面写入12345.....*/ $("li").html(function(idx){ return idx+1; }) css限制文字字数: white-spac ...
- Luogu 1559 运动员最佳匹配问题（带权二分图最大匹配）
Luogu 1559 运动员最佳匹配问题(带权二分图最大匹配) Description 羽毛球队有男女运动员各n人.给定2 个n×n矩阵P和Q.P[i][j]是男运动员i和女运动员j配对组成混合双打的 ...
- Java用Cookie简单限制点赞次数
楼主最近在搞一个当下比较流行的点赞功能,这个功能也是让程序员又爱又恨啊 说起爱,点赞是个社会化的动作,全民都在为美好的事情,行为,动作,点赞. 说起恨,你很难在用户没有登录的情况下限制恶意点赞的机器人 ...
- 关于Docker中的Images与Containers
Docker engine提供了启动Images和containers核心的技术的支持.当你运行docker run hello-world 命令时,实际上可分为三个部分: 告诉你操作系统你正在使用的 ...
- Ubuntu14.04设置开机自启动程序
启动应用程序可以帮助我们选择开机启动项.但是在Ubuntu14.04通过Dash输入startup 找不到启动应用程序了,可以通过在控制台输入以下内容: gnome-session-propertie ...
- WEB安全：文件上传漏洞
文件上传漏洞过程 用户上传了一个可执行的脚本文件,并通过此脚本文件获得了执行服务器端命令的能力. 一般的情况有: 上传文件WEB脚本语言,服务器的WEB容器解释并执行了用户上传的脚本,导致代码执行: ...
- koa2 use里面的next到底是什么
koa2短小精悍,女人不爱男人爱. 之前一只有用koa写一点小程序,自认为还吼吼哈,知道有一天某人问我,你说一下 koa或者express中间件的实现原理.然后我就支支吾吾,好久吃饭都不香. 那么了解 ...