通过RDS备份:Oracle Secure Backup简介

通过RDS备份:Oracle Secure Backup简介

「oracle secure backup」的圖片搜尋結果

 

背景

最早听说这个名字是在几年前实施第一台EXADATA的时候,当时只是在投标文件里认识了这个东西,知道有一个软件叫Oracle Secure Backup(OSB,此OSB不是彼OSB,另一个OSB,Oracle Service Bus,可能名气更大些),这个OSB是Oracle推荐的备份EXADATA的最佳选择。

但是,当时的产品介绍中也没有说清楚,到底为什么OSB是备份EXADATA的最佳选择,而且采用这种方式备份的客户几乎没有,所以也就没再关注这个产品。

近2年,基于类似EXADATA架构的,分布式存储+高速网络+闪存的,x86平台的数据库整体解决方案越来越多,在这种体系架构下,备份依然是一个问题。所以又回头来研究这个软件,看看Oracle所说的EXADATA的最佳备份工具到底好在哪?

从OSB 最新版本的介绍上看,有几点比较吸引我:

可以在Infiniband网络上,通过RDS/RDMA方式进行备份

首先第一点,可能正是当时Oracle宣称OSB是最佳EXADATA备份工具的原因,因为EXADATA最先采用了infiniband网络,这种高带宽,低延时的网络,一定会给rman备份提供足够的带宽。

我们知道,决定rman备份效率的三个主要环节:

l 读阶段

l 复制阶段(通过channel)

l 写阶段

一般来讲,最弱的可能就是复制阶段(通过网络传输备份),而EXADATA的infiniband(IB)网络,首先从硬件基础上提升了这个通道的带宽,剩下的就是备份软件怎么利用这个带宽了。当然,如果只是简单的IP over IB,效率可能也会比传统的IP网络强上不少,但是那没有充分利用IB网络的能力。Oracle使OSB具备通过RDS/RDMA方式进行备份传输的功能,可以极大降低CPU消耗和延时,充分利用IB网络。(RDS/RDMA的概念大家百度吧,我就不再这里用它们凑字数了)

从OSB 12c开始,支持使用文件系统作为备份介质

再说OSB 12c的新功能,可以支持“磁盘池“作为备份介质,实质上就是支持使用一个介质管理服务器可以访问的文件系统来保存备份。这样算下来,我们可以使用标准PC服务器来同时满足备份架构中的三个角色:

l 备份介质管理服务器

l 备份管理服务器

l 备份介质

clip_image001

而一般我们备份的目标系统本身就具备了IB网络交换机,我们需要投入的只是备份服务器上的IB板卡和线缆,加上必须的软件投入,这应该是一个性价比不错的备份解决方案。

唯一支持空块压缩备份的备份软件

只有磁盘备份和OSB支持rman空块压缩备份,其他第三方的备份软件都不支持。没办法,如果是我,我也会这么做的。

测试

测试环境

 

机器配置

阵列卡

存储介质

磁盘RAID级别

数据库服务器

2*6核CPU, 32G内存

LSI 9361-8i

6Gb/s 10k rpm SAS机械硬盘(5块)

RAID 0

备份服务器

2*6核CPU, 32G内存

LSI 9361-8i

6Gb/s 10k rpm SAS机械硬盘(8块)

RAID 0

数据库版本是12.1.0.2,单机, OSB软件版本是12.1

安装、配置

OSB的安装非常简单,具体过程略过。

在数据库服务器上要安装OSB的client端,安装过程中,安装程序会自动替换磁带备份所要用到的动态库,保证磁带方式备份可以调用OSB的介质管理层。

OSB管理服务器安装后,系统会自动启动web服务,OSB的所有管理、配置都是在web界面上完成的,配置过程在网上都有文章,这里就略过了。

为了保证能够使用RDS/RDMA方式进行备份,需要按照文档《OSB – Using RDS / RDMA over InfiniBand (Doc ID 1510603.1)》检查所有配置。

另外,在主机配置中,一定要选择开启RDS,Disable RDS选择no或者用系统缺省选项:

clip_image003

系统缺省会查看是否有infiniband链路,如果有,就使用RDS,其次才是普通IP网络。在preferred network interfaces里面一定要选中infiniband链路对应的主机名或IP:

clip_image005

RMAN测试

使用OSB进行RMAN备份,居然不能通过OSB的管理界面来发起,这也让我很不理解,备份普通文件反而可以在OSB管理界面发起。查了半天文档,发现都是讲如何手工写RMAN脚本来做,这个真是觉得需要改进啊,不过有些DBA可能更喜欢这样吧,给他一个管理界面调RMAN,他反而不会了。。。

注意rman脚本在分配channel时必须用这样的写法:

run

{

allocate channel ch1 device type sbt PARMS ‘ENV=(OB_DEVICE=testdp)’;

allocate channel ch2 device type sbt PARMS ‘ENV=(OB_DEVICE=testdp)’;

allocate channel ch3 device type sbt PARMS ‘ENV=(OB_DEVICE=testdp)’;

allocate channel ch4 device type sbt PARMS ‘ENV=(OB_DEVICE=testdp)’;

backup database;

}

即使我们知道使用磁盘池做备份介质,这里备份设备类型也必须写sbt,这样才能保证rman能调用介质管理层的功能,后面的参数注意,testdp是我们在OSB中定义的设备,这个设备的定义里,指向一个备份服务器的本地文件系统(8块机械硬盘做的RAID 0)。

备份开始后,可以在OSB的web界面上查看job状态:

clip_image007

测了几次,最后得到的测试结果,1000GB的数据,备份花了1个小时左右。数据库所有数据文件大小之和是1100多GB,而备份文件大小,以及从dba_segments中汇总的数据量都是1000GB,也证明了空块压缩功能,的确如文档所说是被OSB的介质管理层支持。

我还想进一步提升备份速度,甚至烧包地用了几块闪存盘做备份端的文件系统,可是速度没有什么提高。所以我意识到现在的瓶颈不是在写入阶段了,也不是在复制阶段,而是在读取阶段,数据库进程读取数据库的速度是瓶颈。

但是我也没有兴趣再测了,因为我们知道在EXADATA或其他一体机架构下,读取速度肯定不是问题。

另外,如果是RAC数据库,还可以用多个备份服务器,从多个实例分别备份,这个速度应该能满足大部分的备份需求了。

Comments are closed.