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 ...
随机推荐
- 浅谈关于特征选择算法与Relief的实现
一. 背景 1) 问题 在机器学习的实际应用中,特征数量可能较多,其中可能存在不相关的特征,特征之间也可能存在相关性,容易导致如下的后果: 1. 特征个数越多,分析特征.训练模型所需的时间就越 ...
- [基础架构]PeopleSoft Application Server 重要文件说明
我们都知道PeopleSoft是由几个不同的服务组成的,他们在PeopleSoft体系结构中扮演着自己的角色.这些服务具有不同的文件结构并包含重要的可执行文件和配置文件. 以下是Peoplesoft体 ...
- Chrome浏览器扩展开发系列之十八：扩展的软件国际化chrome.i18n API
i18n是internationalization 的简写,这里将讨论软件国际化的问题.熟悉软件国际化的朋友应该知道,软件国际化要求,页面中所有用户可见的字符串都必须置于资源属性文件中.资源属性文件中 ...
- Invert a binary tree 翻转一棵二叉树
Invert a binary tree 翻转一棵二叉树 假设有如下一棵二叉树: 4 / \ 2 7 / \ / \ 1 3 6 9翻转后: 4 / \ 7 ...
- SpringMVC原理及非注解配置详解
1. Spring介绍 Spring MVC是Spring提供的一个强大而灵活的web框架.借助于注解,Spring MVC提供了几乎是POJO的开发模式,使得控制器的开发和测试更加简单. 这些控制器 ...
- 初次使用Mybatis配置出现错误待解决
数据库: create table STUDENT ( STUID NUMBER(9) not null, SNAME VARCHAR2(50) not null, SEX VARCHAR2(4), ...
- 【高斯消元】兼 【期望dp】例题
[总览] 高斯消元基本思想是将方程式的系数和常数化为矩阵,通过将矩阵通过行变换成为阶梯状(三角形),然后从小往上逐一求解. 如:$3X_1 + 2X_2 + 1X_3 = 3$ $ ...
- Python学习之数据类型
整数 Python可以处理任意大小的整数,在程序中的表示方法和数学上的写法一模一样,例如:1,100,-8080,0,等等. 用十六进制表示整数比较方便,十六进制用0x前缀和0-9,a-f表示,例如: ...
- css的背景background的相关属性
今天需要做一个占满设备宽度的轮播图,这里作为demo仅展示一张图,下面分别是要操作的图片(这里做了缩放处理,实际的图比较大),以及要实现的效果图,很明显两者是不成比例的: (图一) ...
- NLP —— 图模型（三）pLSA（Probabilistic latent semantic analysis，概率隐性语义分析）模型
LSA(Latent semantic analysis,隐性语义分析).pLSA(Probabilistic latent semantic analysis,概率隐性语义分析)和 LDA(Late ...