rac的不完全恢复
模拟rac的不完全恢复,虽然小鱼对常规的完全和不完全恢复已经轻车熟路了,还是记录一个不完全恢复完整过程记录下来。
1 首先小鱼做了一个完全备份。
RMAN> backup database include current controlfile format '/home/oracle/backup_db_%U'
2> plus archivelog format '/db/oracle/backup_arch_%U' delete all input;
然后关闭数据库删除掉所有的数据文件和联机日志文件。
RMAN> shutdown abort;
2 重新启动数据库到mount状态(上面小鱼并没有删除controlfile文件),恢复所有的数据文件
RMAN> startup mount;
RMAN> restore database;
3 由于database备份完成后,还产生了一定的归档日志,而此时我们后面的事情就是确定恢复的终点。
SQL> set heading off;
SQL> select name,first_change#,next_change# from v$archived_log;
。。
+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707
1095851 1095962
+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707
1095854 1095964
+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717
1095962 1095977
+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_4.257.810362719
1095964 1095986
由于最后的归档日志最后的连续点只到scn 1095977,所以这个恢复的终点只能到scn 1095977
RMAN> run{
2> set until scn 1095977;
3> recover database;
4> }
executing command: SET until clause
Starting recover at 18-MAR-13
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 3 is already on disk as file +ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707
archive log thread 1 sequence 4 is already on disk as file +ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717
archive log thread 2 sequence 3 is already on disk as file +ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707
archive log thread 2 sequence 4 is already on disk as file +ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_4.257.810362719
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=2 sequence=2
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=2
channel ORA_DISK_1: reading from backup piece /db/oracle/backup_arch_0eo4q9n8_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/db/oracle/backup_arch_0eo4q9n8_1_1 tag=TAG20130318T044320
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archive log filename=+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_2.311.810363219 thread=1 sequence=2
archive log filename=+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_2.323.810363219 thread=2 sequence=2
archive log filename=+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707 thread=1 sequence=3
archive log filename=+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707 thread=2 sequence=3
archive log filename=+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717 thread=1 sequence=4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/18/2013 04:53:46
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter
database recover logfile
'+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717'
ORA-00283: recovery session canceled due to errors
ORA-00313: open failed for members of log group 4 of thread 2
ORA-00312: online log 4 thread 2: '+ARCH/xiaoyu/onlinelog/group_4.311.810362175'
ORA-17503: ksfdopn:2 Failed to open file +ARCH/xiaoyu/onlinelog/group_4.311.810362175
ORA-15012: ASM file '+ARCH/xiaoyu/onlinelog/group_4.311.810362175' does not exist
ORA-00312: online log 4 thread 2: '+DATA/xiaoyu/onlinelog/group_4.259.810362171'
ORA-17503: ksfdopn:2 Failed to open file +DATA/xiaoyu/onlinelog/grou
小鱼简单说下上面的rman操作的错误缘由,这个是因为小鱼只是restore database,并没有利用备份或者重建控制文件,此时oracle会默认认为所有的联机日子都存在,才报出上面的错误信息。
此时虽然出现上面的日志文件丢失,但是并不影响这个恢复,对应的alert日志,可以看出其中利用归档日志恢复的信息。
Mon Mar 18 04:53:37 EDT 2013
alter database recover datafile list clear
Mon Mar 18 04:53:37 EDT 2013
Completed: alter database recover datafile list clear
Mon Mar 18 04:53:37 EDT 2013
alter database recover datafile list
1 , 2 , 3 , 4 , 5
Completed: alter database recover datafile list
1 , 2 , 3 , 4 , 5
Mon Mar 18 04:53:37 EDT 2013
alter database recover if needed
start until change 1095977
Media Recovery Start
ORA-279 signalled during: alter database recover if needed
start until change 1095977
...
Mon Mar 18 04:53:40 EDT 2013
Archivelog restore complete. Elapsed time: 0:00:00
Archivelog restore complete. Elapsed time: 0:00:01
Mon Mar 18 04:53:40 EDT 2013
alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_2.311.810363219'
Mon Mar 18 04:53:40 EDT 2013
Media Recovery Log +ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_2.311.810363219
ORA-279 signalled during: alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_2.311.810363219'...
Mon Mar 18 04:53:41 EDT 2013
alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_2.323.810363219'
Mon Mar 18 04:53:41 EDT 2013
Media Recovery Log +ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_2.323.810363219
ORA-279 signalled during: alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_2.323.810363219'...
Mon Mar 18 04:53:42 EDT 2013
alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707'
Mon Mar 18 04:53:42 EDT 2013
Media Recovery Log +ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707
ORA-279 signalled during: alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707'...
Mon Mar 18 04:53:42 EDT 2013
alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707'
Mon Mar 18 04:53:42 EDT 2013
Media Recovery Log +ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707
ORA-279 signalled during: alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707'...
Mon Mar 18 04:53:43 EDT 2013
alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717'
Mon Mar 18 04:53:43 EDT 2013
Media Recovery Log +ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717
然后open resetlogs打开数据库即可。
RMAN> alter database open resetlogs;
database opened
http://www.dbaxiaoyu.com/archives/910
rac的不完全恢复的更多相关文章
- oracle rac理解和用途扩展
Oracle RAC的优势在于利用多个节点(数据库实例)组成一个数据库,这样在保证了数据库高可用性的情况下更充分的利用了多个主机的性能,而且可以通过增加节点进行性能的扩展.实现Oracle RAC需要 ...
- rac 11g_生产库日志组损坏处理
原创作品,出自 "深蓝的blog" 博客,转载时请务必注明出处,否则有权追究版权法律责任. 深蓝的blog:http://blog.csdn.net/huangyanlong/ar ...
- 大话RAC介质恢复---联机日志损坏
对联机日志的损坏要根据日志状态进行分析,联机日志一般会有Current.Active和Inactive三种状态.Inactive状态不会造成数据丢失.而Active和Current状态的日志一般会造成 ...
- 大话RAC介质恢复---只有备份文件的恢复
场景:Oracle 10g RAC:数据文件.控制文件.联机日志.参数文件都使用ASM,归档到ASM.完整备份后,删除所有控制文件.联机日志.数据文件:最后利用备份进行不完全恢复. 1.模拟灾难场景( ...
- RAC 之 RMAN 恢复
RAC 下的RMAN 讲究的是备份和还原的策略要一致.备份策略的不同,会导致备份结果的分步不同,进而影响恢复的策略和步骤.一般情况下,恢复策略和备份策略必须是对应的.如果备份策略进行了修改,那么恢复也 ...
- Oracle RAC学习笔记:基本概念及入门
Oracle RAC学习笔记:基本概念及入门 2010年04月19日 10:39 来源:书童的博客 作者:书童 编辑:晓熊 [技术开发 技术文章] oracle 10g real applica ...
- RAC之RMAN恢复
之前整理的RMAN 有关还原的文章: RMAN 系列(五) ---- RMAN 还原 与 恢复 http://blog.csdn.net/tianlesoftware/archive/2010/07/ ...
- Oracle RAC的机制与测试方法
Oracle RAC的机制与测试方法 标签: rac 机制 测试 2016-05-25 09:54 1150人阅读 评论(0) 收藏 举报 分类: oracle(2) 1.RAC原理 Oracle ...
- oracle 11g r2 使用rman进行迁移rac到rac
源端服务器主机名 rac05 rac06公共IP地址(eth0) 10.15.8.15 10.15.8.16 虚拟IP地址(eth0) 10.15.8.17 10.15.8.18私有IP地址(eth1 ...
随机推荐
- css中常见中文字体的英文名称
曾经看过一些文章,建议CSS中字体应用英文来替代,但一直未引起我重视.最近官网改版,今天同事测试发现Mac的Safari总是显示宋体 → → 修改font-family:"微软雅黑" ...
- Apache Kylin Cube 的存储
不多说,直接上干货! 简单的说Cuboid的维度会映射为HBase的Rowkey,Cuboid的指标会映射为HBase的Value. Cube映射成HBase存储 如上图原始表所示:Hive表有两个维 ...
- Dom 获取、Dom动态创建节点
一.Dom获取 1.全称:Document Object Model 文档对象模型 2.我们常用的节点类型 元素(标签)节点.文本节点.属性节点(也就是标签里的属性). 3.docum ...
- Debian9镜像安装问题
Debian9下载地址 https://www.debian.org/distrib/ Debian9有三个镜像文件 第一个包含系统2.3两个主要是一些软件的安装包只需下载第一个安装系统即可 默认安装 ...
- 洛谷 P1802 5倍经验日
题目背景 现在乐斗有活动了!每打一个人可以获得5倍经验!absi2011却无奈的看着那一些比他等级高的好友,想着能否把他们干掉.干掉能拿不少经验的. 题目描述 现在absi2011拿出了x个迷你装药物 ...
- HTML5应用 + Cordova = 平台相关的混合应用
Jerry之前的一篇文章 SAP Fiori应用的三种部署方式 曾经提到SAP Fiori应用的三种部署方式: On Premise环境下以ABAP BSP应用作为Fiori应用部署和运行的载体 部署 ...
- Java 游戏报错 看不懂求教
Java 飞机小游戏 报错 看不懂求救 at java.awt.Component.dispatchEvent(Unknown Source)at java.awt.EventQueue.dispat ...
- XtraBackUp 热备份工具
是一款强大的在线热备份工具 备份的过程中,不锁表 使用percona-xtrabackup-24-2.4.7-1.el7.x86_64.rpm yum源安装: 1.安装Percona的库: ...
- Hystrix 断路器
断路器: 当客户端访问服务端,发现服务端有异常不能进行访问时,就会执行一个fallback 方法.
- golang 解析json 动态数组
#cat file { "Bangalore_City": "35_Temperature", "NewYork_City": " ...