Oracle 12c系列(八)｜RMAN (FROM SERVICE)
原创Oracle 12c系列(八)｜RMAN (FROM SERVICE)
原创
相信大家在Dataguard环境中遇到过主库丢失归档日志，而备库也没有及时接收，导致备库出现了GAP的现象。因为日志的中断，备库无法再去应用之后的日志，就无法起到容灾的效果。
遇到这种故障，往往主库如果数据很大的时候，大家都不会去选择重新搭建来恢复备库，而会去选择更轻的增量恢复来解决问题。
即使如此，一旦主库数据量过大，每日变化量也极多，进行一次增量恢复其实也需要大量的时间以及备份集所需要的空间。甚至，在GAP期间，如果主库新增了数据文件，那么也会增加任务量。
在12cR1开始，RMAN提供了一个from service的子句让备库可以通过网络来执行recover和restore命令。
The FROM SERVICE clause provides the service name of the physical standby database from which the files must be restored. During the restore operation, RMAN creates backup sets, on the physical standby database, of the files that need to be restored and then transfers these backup sets to the target database over the network.
那在哪些情况下可以使用这个新特性呢
- 当备库出现GAP，而主库丢失归档需要做增量备份的时候
- 当备库丢失数据文件、控制文件以及表空间的需要restore的时候
这个特性其实大大缩减了备库在一些丢失归档需要做增量备份的情况下的工作量，将需要在主备库来回切换的操作简化为只需要在备库进行操作就可以完成。
关于如何运用这一特性，用些简单的例子来试验下。
备库增量恢复演示
模拟一个拥有GAP的备库的环境：
SQL> select * from v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# CON_ID
---------- ------------- -------------- ----------
1 1231 1234 1
2 762 765 1
SQL> show parameter fal
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
fal_client string slave_db
fal_server string primary_db查询可知主库tnsname连接串名为primary_db
step 1 查询备库当前SCN
RMAN> select current_scn from v$database;
CURRENT_SCN
-----------
37537287这里提一下，12c 开始，RMAN可以直接执行很多命令，而不需要去使用sql 'sql'的句式去执行。
然后起至nomount状态
RMAN> startup force nomount
Oracle instance started
Total System Global Area 2147483648 bytes
Fixed Size 8794848 bytes
Variable Size 486542624 bytes
Database Buffers 1644167168 bytes
Redo Buffers 7979008 bytesstep 2
备库通过from service子句进行增量恢复
RMAN> restore standby controlfile from service primary_db;
Starting restore at 2018-06-01 12:26:40
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service primary_db
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output file name=/data/data1/control01.ctl
Finished restore at 2018-06-01 12:26:43
RMAN> alter database mount;为防止在GAP期间有新增的数据文件
可以在主库查询断档之后主库新增的数据文件
SQL> select file# from v$datafile where creation_change# > =37537287;
FILE#
----------
47通过from service恢复命令将新增的数据文件通过网络在备库恢复。
RMAN>run
{
SET NEWNAME FOR DATABASE TO '/data/data1/AXTEST/datafile/%f_%U';
RESTORE DATAFILE 47 FROM SERVICE primary_db;
}
executing command: SET NEWNAME
Starting restore at 2018-06-01 12:35:12
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=785 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service primary_db
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00047 to /data/data1/AXTEST/datafile/47_data_D-ZZ_TS-TEST1_FNO-47
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
Finished restore at 2018-06-01 12:35:28因为主备库数据文件路径不一致，需要使用catalog与copy将数据名更新一致。
RMAN> catalog start with '/data/data1';
RMAN> switch database to copy;step 3 至此，可以进行增量恢复了 在from service句式中还是可以使用常规备份时候使用的参数
- SECTION SIZE （在传输时使用并发备份集传输）
- USING COMPRESSED BACKUPSET （在传输时使用压缩，减轻网络压力）
RMAN> recover database from service primary_db noredo SECTION SIZE 1G USING COMPRESSED BACKUPSET;
....
destination for restore of datafile 00037: /data/data1/AXTEST/688A86E561085C8CE053BB3C0A0A7969/datafile/o1_mf_undo_2_88t4ahp9_.dbf
channel ORA_DISK_1: restoring section 1 of 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
Finished recover at 2018-06-01 13:45:00
#接下来就是正常的起库开启实时日志恢复了通过这种方式可以很快的去解决一些备库需要做增量恢复或者数据文件丢失的故障。
当然，需要使用from service句式时有些必要的条件：
- 两个数据库之间tns必须保持可以连接的状态
- 两个数据库密码文件必须保持一致
- 两个数据库的 COMPATIBLE参数必须为12.0
| 作者简介
陈康，沃趣科技数据库技术专家
主要参与公司产品实施、测试、维护以及优化。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。