欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

RMAN中三个不完全恢复场景

程序员文章站 2022-06-12 19:24:24
...

RMAN在数据的备份恢复中还是发挥了重大的作用,把冷备,热备这种手工备份方式做了集成化的管理,可以基于这个工具集完成相对复杂

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