rman中三个不完全恢复场景(r6笔记第16天)

rman在数据的备份恢复中还是发挥了重大的作用,把冷备,热备这种手工备份方式做了集成化的管理,可以基于这个工具集完成相对复杂额备份恢复工作。 当然了rman相对于传统的手工备份,提供了更多的改进, 比如压缩备份,我们手工测试的场景中,一个1.5G的小库,如果数据文件的使用率不到300M,那么生成的dump就在近300M,如果开启压缩备份的方式,生成的备份集差不多会在80M左右,改进的幅度还是很大的。比如并行备份,开启多个通道对于数据库中的多个数据文件备份进行分工,还可以在这个基础 上进行备份切分,把一个很大的备份集切分成多个指定单位大小的备份分片。 比如备份的加密方式,从安全性上也可以保证。 比如增量备份,这种方式通过手工方式是完成不了的。增量备份把数据的备份工作可以当做一个很有规划性的工作来做。 当然备份是基础,数据的恢复在这个基础上就更为重要了。如果数据恢复不了,备份的意义就会大打折扣。 自己做了下面三个简单的测试,属于三个不完全恢复额场景,我们来看看在手工备份恢复的繁琐之外,rman下是怎么做的,有哪些改进,有些时候还可能需要动用一些非常规手段。 第一个例子是一个删除用户的例子, 我们已经存在一个备份,归档都保留着,然后我们在制定的时间删除了数据库中某个用户,然后尝试基于时间点的不完全恢复 目前我们存在下面的数据库用户,我们就拿newtest这个用户开刀。

SQL> select *from all_users;
USERNAME                          USER_ID  CREATED
------------------------------ ----------  ---------
TEST_UPDATE                            33  29-JUL-15
NEWTEST                                32  19-JUL-15
MGMT_VIEW                              30  05-JUL-15
DBSNMP                                 24  04-JUL-15
TSMSYS                                 21  04-JUL-15
SYSMAN                                 28  05-JUL-15
DIP                                    19  04-JUL-15
OUTLN                                  11  04-JUL-15
SYSTEM                                  5  04-JUL-15
SYS                                     0 04-JUL-15
10 rows selected.

为了进行回复后的验证,我们随便拿出一个有数据的表来做一个基本的验证。

SQL> conn newtest/newtest
Connected.
SQL> select count(*)from t;
  COUNT(*)
----------
       6338

然后开始我们的不完全恢复。从下面可以看到目前的日志已经做了resetlogs启动,序列是从1开始,但是在10g之后,resetlogs 启动数据库,原来的备份依然可用。

SQL> select sequence#,status from v$log;
 SEQUENCE# STATUS
---------- ----------------
         1  CURRENT
         0 UNUSED
         0 UNUSED

我们标记一下时间戳,然后删除这个用户

SQL> select systimestamp from dual;
SYSTIMESTAMP
---------------------------------------------------------------------------
02-AUG-15  09.19.56.666830 PM +08:00
SQL> drop user newtest cascade;
User dropped.

破坏之后,我们停库启动到mount阶段,开始做不完全恢复

SQL> shutdown immediate
Database closed.
Database  dismounted.
ORACLE instance shut down.

通过rman来恢复,步骤就相对简单多了。

RMAN> startup mount
Oracle instance started
database mounted
Total System Global Area     314572800 bytes
Fixed Size                     1261564 bytes
Variable Size                 163577860 bytes
Database Buffers             142606336 bytes
Redo  Buffers                   7127040 bytes
RMAN> run
2> {
3> set until time  "to_date('2015-08-02:21:19:56','YYYY-MM-DD HH24:MI:SS')";
4> restore  database;
5> recover database;
6>  }

这样后台就会自动去完成还原和恢复的工作,恢复的部分日志如下:

starting media recovery
archive log thread 1 sequence 9 is already on disk as file  /u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_9_bvw5nrd2_.arc
archive  log thread 1 sequence 10 is already on disk as file  /u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_10_bvw60std_.arc
archive  log  filename=/u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_9_bvw5nrd2_.arc  thread=1 sequence=9
archive log  filename=/u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_10_bvw60std_.arc  thread=1 sequence=10
media recovery complete, elapsed time:  00:00:09
Finished recover at 02-AUG-15

就这样就轻松完成了时间点的恢复,使用resetlogs的方式打开数据库。

RMAN> alter database open resetlogs;
database opened

我们简单验证一下用户是否已经恢复回来。可以看到一切都在预料之中。

SQL> conn newtest/newtest
Connected.
SQL> select count(*)from t;
  COUNT(*)
----------
      6338
:

第二个例子是一个相对来说暴力的破坏,我们删除了所有的数据文件,日志文件,控制文件。然后尝试恢复。 先是破坏,我们到数据文件的目录下,删除全部文件

$ rm * 然后使用rman把数据库启动到nomount阶段,开始尝试恢复控制文件。 [oracle@oel1 TEST10G]$ rman target /

Recovery Manager: Release 10.2.0.3.0 - Production on Sun Aug 2 21:33:24 2015

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database (not started)

RMAN> startup nomount

Oracle instance started

Total System Global Area 314572800 bytes

Fixed Size 1261564 bytes Variable Size 163577860 bytes Database Buffers 142606336 bytes Redo Buffers 7127040 bytes 这个时候查看rman的配置会发现,原有的配置都会丢失,因为我们删除了所有的数据。

RMAN> show all;

这个时候如果还原控制文件,指定autobackup就会报错,因为配置丢失,压根找不到备份的配置。

RMAN> restore controlfile from autobackup;

Starting restore at 02-AUG-15 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=34 devtype=DISK

recovery area destination: /u02/oracle/flash_recovery_area database name (or database unique name) used for search: TEST10G channel ORA_DISK_1: no autobackups found in the recovery area autobackup search outside recovery area not attempted because DBID was not set RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 08/02/2015 21:33:49 RMAN-06172: no autobackup found or specified handle is not a valid copy or piece

这个时候,我们可以手工指定需要还原参照的控制文件备份即可。 比如我们在备份目录下看到最新的控制文件备份,直接应用还原。

RMAN> restore controlfile from '/u02/oracle/flash_recovery_area/TEST10G/ctl_c-1135735312-20150802-0b';

Starting restore at 02-AUG-15 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=38 devtype=DISK

channel ORA_DISK_1: restoring control file channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 output filename=/u02/oracle/oradata/TEST10G/control01.ctl output filename=/u02/oracle/oradata/TEST10G/control02.ctl Finished restore at 02-AUG-15

然后数据库启动到Mount阶段,开始还原和恢复数据库, RMAN> run{ 2> restore database; 3> recover database; 4> } 还原还是很平滑的过程,关键就在于恢复的过程,最后肯定会抛出一些问题来,类似下面的形式。 unable to find archive log archive log thread=1 sequence=1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 08/02/2015 21:37:15 RMAN-06054: media recovery requesting unknown log: thread 1 seq 1 lowscn 1151365 这个时候我们就需要做不完全恢复,我们来采用基于sequence的恢复。 RMAN> run{ 2> set until sequence 1; 3> recover database; 4> } 然后使用resetlogs的方式就可以打开数据库了。

RMAN> alter database open resetlogs;

database opened

这种方式也还是相对比较简单的过程。 第三种场景略微复杂。 如果存在备份,但是备份集出现了一些问题,或者出现了一些归档文件的缺失,restore可以顺利完成,但是在recover的时候会报出下面的错误来。

RMAN> recover database;

Starting recover at 02-AUG-15 using channel ORA_DISK_1 using channel ORA_DISK_2

starting media recovery

unable to find archived log archived log thread=1 sequence=1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 08/02/2015 12:26:43 RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1 and starting SCN of 1094536

这种情况下采用基于sequence的不完全恢复也没有基础。 如果这个时候我们无招可用,看看resetlogs的方式能不能启动数据库,会有下面的错误。

RMAN> alter database open resetlogs;

RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of alter db command at 08/02/2015 12:28:06 ORA-01152: file 3 was not restored from a sufficiently old backup ORA-01110: data file 3: '/u02/ora11g/oradata/TEST/undotbs01.dbf'

可见还是备份集出现一些问题,主要原因还是控制文件中记录的scn号和备份集中的scn出现了gap,尝试恢复的时候又没有相应的归档。 我们可以采用隐含参数来做, 在pfile中加入下面的三个隐含参数

_allow_resetlogs_corruption=true
_corrupted_rollback_segments=true
_offline_rollback_segments=true

然后,重新启动数据库到mount阶段之后,使用resetlogs的方式即可强制打开数据库。 这种方式存在着一定的风险,但是也是无奈的场景下的一种方式。毕竟数据库能够open是一个很重要的检查点,数据库都启动不了的话,整个恢复的意义就会大打折扣了。 所以通过上面的三个简单的例子,可以看到在数据的不完全恢复中,还是有很多的选择,不完全恢复相对于完全恢复来说,场景真是数不胜数,各种破坏各种坑。合理利用手中的备份是我们数据恢复的一个基础。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-08-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏乐沙弥的世界

使用RMAN实现异机备份恢复(WIN平台)

--================================= -- 使用RMAN实现异机备份恢复(WIN平台) --================...

1223
来自专栏杨建荣的学习笔记

使用logon trigger完成动态的session跟踪(r4笔记第29天)

在之前讨论过 关于oracle中session跟踪的总结,可以参见链接 http://blog.itpub.net/23718752/viewspace-115...

2874
来自专栏小白安全

phpmyadmin新姿势getshell

在一个有WAF、并且mysql中的Into outfile禁用的情况下,我该如何getshell? 首先环境如下: OS:Windows 2003 ...

4176
来自专栏java系列博客

pl/sql导入excel到oracle表

2277
来自专栏PHP在线

总结

1.安装完成后备份快照 2.不插网线使用虚拟机,查看vmware的IP网段,设置linux系统相同的网段。 3.rpm -qa 软件名字 //查询软件是...

3255
来自专栏散尽浮华

Mysql读写分离方案-MySQL Proxy环境部署记录

Mysql的读写分离可以使用MySQL Proxy和Amoeba实现,其实也可以使用MySQL-MMM实现读写分离的自动切换。MySQL Proxy有一项强大功...

4278
来自专栏zhangdd.com

mysql proxysql+mgr集群 centos7系统安装配置

wget https://codeload.github.com/sysown/proxysql/tar.gz/v1.4.4

2703
来自专栏杨建荣的学习笔记

关于Oracle数据恢复的两个临界点(r5笔记第42天)

有的网友对我之前写的一篇技术博文中的描述提出了疑问,http://blog.itpub.net/23718752/viewspace-1436965/ 其中的主...

3734
来自专栏数据和云

时过境迁:Oracle跨平台迁移之XTTS方案与实践

作者简介 ? 谢金融 云和恩墨东区交付部 Oracle 工程师,多年来从事 Oracle 第三方服务,曾服务过金融、制造业、物流、政府等许多行业的客户,精通数据...

1.2K10
来自专栏乐沙弥的世界

使用外部表管理Oracle 告警日志(ALAERT_$SID.LOG)

--================================================

671

扫码关注云+社区

领取腾讯云代金券