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