零数据丢失恢复设备

ORACLE白皮书|2014年11月零数据丢失恢复设备技术白皮书目录引言1业务数据保护的重要作用1数据保护面临的挑战1每周执行完全备份及每天执行增量备份2增量更新备份2每天向重复数据消除设备执行完全备份2存储快照2零数据丢失恢复设备3恢复设备技术4恢复设备操作8相关技术14最高可用性架构14Oracle数据库备份到云15ZS3备份设备16OracleMultitenant16总结161|零数据丢失恢复设备技术白皮书引言Oracle零数据丢失恢复设备是一个全新的云级工程化系统,旨在消除数据丢失风险以及显著降低企业中所有Oracle数据库的数据保护开销.
该设备与RecoveryManager(RMAN)相集成,使用完全容错的云级硬件和存储,为企业中的数百至数千个数据库实施一个集中的持续增量备份战略.
该设备为数据库提供亚秒级恢复点目标,并持续验证备份以确保Oracle数据的可恢复性.
OracleEnterpriseManager提供"单一管理界面"来控制该设备上的所有管理操作,从而为Oracle备份生命周期提供了完整、端到端的可见性.
本文将探讨该设备为Oracle数据库环境带来的主要数据保护功能和优势.
业务数据保护的重要作用信息技术在现代企业中的作用正在经历一场巨大的转变.
各个公司开展业务所需的数据量正在呈指数级增长,与此同时,他们越来越多地依赖这些数据实时做出重大决策.
他们在24x7全球经济中开展的业务越来越多,因此,任何长时间的停机或速度下降对关键系统而言都是完全不能接受的.
考虑到所有这些因素,公司的IT组织需要运用一个可伸缩、强健、非侵入性的数据保护战略来满足各个业务部门对所有服务级别协议的要求,这一点比以往任何时候都重要.
任何数据丢失,无论是重大还是轻微的数据丢失,对于当今的业务关键系统和应用程序都是完全不能接受的.
数据保护面临的挑战目前,许多数据保护解决方案主要专注于基于存储的镜像以及备份和恢复技术,而每个解决方案都有自己的缺点,特别是保护数据库时.
这些通用的解决方案将数据库视为文件系统数据,不了解底层数据的事务性本质.

对于Oracle数据库备份而言,面临的主要问题有:如何在不断缩短的备份时窗内有效备份数据库环境,同时确保在尽可能减少数据丢失的情况下无缝执行恢复当今市场中的备份和恢复技术范围极广,有软件方法和硬件方法,但在拥有数百个至数千个数据库的大型企业中只会加剧这一挑战.
我们来了解一下目前使用的几个数据库备份和恢复方法,如下所示.
图1:数据库备份和恢复方法2|零数据丢失恢复设备技术白皮书每周执行完全备份及每天执行增量备份该战略涉及到每周执行磁盘和/或磁带完全备份(0级)和每天执行磁盘和/或磁带增量备份(1级).
这意味着企业需承担每周执行完全备份带来的开销—当系统资源太紧张,无法以正常性能级别支持所有生产应用程序时,就形成了"备份时窗"的概念.
由于实施该战略时还会备份归档日志,因此可以恢复至完全备份时间戳与上次良好归档日志备份之间的任意时间点.
然而,要存放所需数量的完全备份和增量备份,需要大量的磁盘和/或磁带存储.

增量更新备份在该战略中,先将初始映像副本(0级)存放到磁盘,以后每天执行增量备份.
然后应用增量备份前滚映像副本,生成一个新的磁盘上副本,该副本对应于最新或以前的增量时间戳.
一旦前滚某副本后,将无法回滚该副本,除非先将副本归档或创建基于存储的快照.
映像副本使用的磁盘存储量与生产数据文件相同,这样一来,会明显增加总体存储需求,特别对于大型数据库而言更是如此.
每天向重复数据消除设备执行完全备份近年来,备份到重复数据消除设备变得更加流行,以便通过自动消除冗余备份数据来降低存储成本.
为了降低存储成本,必须提高重复数据消除(即节省)率,因此,存储供应商通常推荐仅执行完全备份战略来备份到这些设备.

然而,对于大多数企业数据库,仅执行完全备份战略从备份时窗和系统利用率角度讲效率都不高.
此外,恢复重复数据消除的备份需要首先再融合物理备份,而这会延长恢复时间.
重复数据消除设备通常基于单个控制器架构,在这种架构中,计算能力和带宽在给定的设备上是固定的,无法根据业务需求进行更改.
用户可以添加更多的存储扩展机架,但它们只能增加系统管理的总存储容量.
一旦单个设备达到最大存储限制,用户不得不铲车式升级到较高的型号或必须购买额外的设备.
如果用户需要额外的备份处理吞吐量,同样需要执行铲车式升级.
结果:由于在单一系统上扩大吞吐量存在物理限制,因此使用少量设备来支持大型Oracle企业(如有数百个至数千个数据库)的备份是几乎不可能的.
最后,单一控制器架构系统严重限制了系统的弹性.
控制器中的任何单个组件故障都会使设备无法使用,直到更换故障组件后才能使用.
存储快照生产数据库基于存储的快照是另一个"备份"战略,在该战略中,只存储新数据和更改的数据.
对于该技术,文件快照只是截至创建快照时,组成文件的所有未更改的块和更改前的块的一组指针.
由于快照与生产存储密切相关,因此在发生存储损坏、丢失或站点灾难时,它不能作为一个真正的备份1—但是,它可用于快速创建克隆数据库,以用1"快照不是备份(SnapshotsareNOTBackups)",http://www.
oracle.
com/technetwork/database/features/availability/rman-fra-snapshot-322251.
html3|零数据丢失恢复设备技术白皮书于开发/QA目的.
由于快照是在RMAN之外创建的,因此在它们恢复并打开数据库之前,未对它们验证Oracle块的正确性.
总之,目前的数据保护技术凸显出以下诸多缺点:数据丢失风险增加:数据只能恢复到上次良好的备份,如几小时或几天前.
此外,通用存储系统本身无法在Oracle块级验证备份来实现恢复一致性.
延长备份时窗:随着数据库不断增加,备份时窗也随之延长,而这会导致网络和存储资源占用的时间更长,使用更频繁,从而导致总体IT资源的利用率非常低.
降低生产性能:备份时窗延长意味着对生产性能的影响更久,这样可能会抢走更重要生产负载的周期和资源.

备份流程分散:重复数据消除设备和存储设备只将Oracle备份看作普通文件,不连接到所包含的数据库,这会导致缺乏可见性,而且无法保证备份状况良好且有用,无论备份是在磁盘、磁带或复制设备上.

降低操作可伸缩性:存储设备无法轻松扩展,来处理企业中数百个至数千个数据库的大量备份负载和并发连接.

简单地说,这些方法都未提供一个真正全面、高效的Oracle集成数据保护解决方案,来满足大规模企业Oracle环境的要求.
我们需要的是一个从头构建的全新解决方案,为数百个至数千个Oracle数据库提供事务数据保护.
零数据丢失恢复设备零数据丢失恢复设备旨在消除数据丢失风险以及显著降低企业中所有Oracle数据库的数据保护开销.
将备份处理分流到该设备以提高生产性能,同时通过实时重做传输将数据丢失风险降至最低.
OracleEnterpriseManagerCloudControl负责整个环境的管理和控制,为每个数据库提供整个备份生命周期的"单一管理界面"视图,无论备份是位于磁盘、磁带还是复制设备.
该设备的集成硬件基于经业界证明的Exadata平台,具有完全容错能力,可提供极高的性能并能够轻松扩展以满足企业数据增长的需求.
该环境中的主要组件和工作流程如下所示:图2:零数据丢失恢复设备环境4|零数据丢失恢复设备技术白皮书恢复设备技术架构该设备与RecoveryManager(RMAN)原生集成—系统的核心是嵌入式Oracle数据库,它运行OracleRealApplicationClusters(RAC),作为所有受保护数据库的集中RMAN恢复目录.
该目录在自动存储管理(ASM)磁盘组中维护所有备份元数据,这些元数据以高冗余模式运行在大容量磁盘上.
此外,备份数据本身以常规冗余性也保留在ASM磁盘组中.
只需添加更多的机架,即可扩大该设备的计算和存储容量.
通过标准的10GigE和InfiniBand端口将备份传入/传出系统.
为进行磁带归档操作,该设备的每个计算服务器上都预先安装了OracleSecureBackup(OSB)介质管理软件,并配备了一个16Gb光纤通道卡,以便直接连接到磁带硬件.
此外,其他供应商的磁带备份代理也可以部署在恢复设备上,与现有磁带备份软件和流程相集成.
在该配置中,这些代理必须连接到部署在该设备外部的专用介质服务器上.
受保护数据库恢复设备支持的数据库范围极广,涵盖OracleDatabase10g第2版到OracleDatabase12c等所有数据库,且这些数据库可运行在任何Oracle支持的OS平台上.
可通过安装与RMAN集成的恢复设备备份模块使数据库成为"恢复设备感知的".
不需要任何专用的备份代理,如果当前有任何此类代理用于Oracle数据库备份目的,可以将其移除.
有关如何针对恢复设备配置受保护数据的更多详细信息,可参阅"保护策略"一节.

借助恢复设备备份模块,可以将RMANSBT通道配置为通过标准HTTP(S)将数据备份到恢复设备或从恢复设备恢复数据,如下所示:CONFIGURECHANNELDEVICETYPESBTPARMS'SBT_LIBRARY=/u01/app/oracle/product/12.
1.
0.
0.
0/dbhome_1/lib/libra.
so,ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.
1.
0.
0.
0/dbhome_1/dbs/bacredential_alias=recoveryappliance2-ingest.
company.
com:1521/RecoveryAppliance2:dedicated')'图3:恢复设备的RMANSBT通道配置在该示例中,备份模块"libra.
so"允许SBT通道利用OracleWallet"RA_WALLET"中存储的凭证,经由接入点"recoveryappliance2-ingest.
company.
com",通过HTTP连接到恢复设备"recoveryappliance2".
下面我们将讨论恢复设备的两个独特的架构组件—增量推送和增量存储.
增量推送增量推送包含两个流程,这两个流程运行在每个受保护的数据库上:(i)RMAN增量备份和(ii)实时重做传输.
RMAN增量备份在常规操作中,恢复设备从每个受保护数据库接收定期计划的RMAN增量1级备份,其中仅包含相对于上次执行增量备份后发生的数据文件块更改.
在恢复设备中,将验证传入的备份数据以确保Oracle数据块中无物理损坏,然后使5|零数据丢失恢复设备技术白皮书用专用块级算法进行压缩,最后写入到一个或多个预配置的ASM磁盘组所包含的存储池中.
除了最初执行一次完全备份外,无需从受保护数据库执行常规的完全备份.
这样,恢复设备实施持续增量备份战略,从而消除了传统的备份时窗及相关的系统影响,同时提高了生产服务器的性能.
有关更多详细信息,请参阅"增量存储"一节.
实时重做传输如果生产系统和存储丢失,那么从根本上说,只能将数据恢复到上次良好备份的时间点,更具体地说,对于数据库而言,只能将数据恢复到上次良好归档日志备份的时间点.
由于归档日志包含数据库中所有发生更改的记录,因此必须定期备份这些关键文件,备份频率至少与数据文件一样(例如,对于活动系统每隔几小时备份一次).
如果生产系统确实丢失,需要恢复备份,频繁备份则减少了数据丢失的可能性.
事实上,如果创建数据文件后尚未执行备份而该数据文件损坏或丢失,可在介质恢复过程中使用归档日志从头重建数据文件.

为了识别重做在数据丢失方面的重要性,对于OracleDatabase11g和12c,恢复设备支持实时重做传输,这在业内是前所未有的,可提供约亚秒级的数据丢失保护.
基于经业界证明的OracleDataGuard重做传输技术,恢复设备直接从这些受保护数据库的内存(SGA)接收传入的重做块,并将日志写入重做临时位置(预先配置的ASM磁盘组),从该临时位置将这些日志转换为压缩的归档日志备份,然后写入增量存储.
这意味着,生产系统上不再需要频繁且占用大量资源的归档日志备份,如同典型的备份战略一样.
该设备生成的归档日志备份以正常方式记录在恢复目录中,可通过标准的RMANRECOVER命令恢复并应用到数据文件中.
恢复设备图4:恢复设备实时重做传输如果重做数据流出现意外终止,该设备能够关闭传入的重做数据流,并创建一个部分归档重做日志,从而维持数据丢失保护.
检测到重做数据流重启后,该设备自动从受保护数据库检索所有缺少的归档日志,以维持恢复周期目标.
从OracleDatabase11.
1.
0.
7开始,恢复设备的重做传输支持Linux、Windows和Solarisx86平台.
此外,从OracleDatabase11.
2.
0.
4开始,重做传输还支持基于SPARC、Power和Itanium的平台.
6|零数据丢失恢复设备技术白皮书增量存储增量存储是恢复设备的主要处理引擎,它基于增量推送增量备份创建并存储虚拟完全备份.
增量存储技术将截至1级备份时间点的传入增量1级备份转换为增量0级备份(即完全备份)的虚拟表示.
例如,截至Day1的增量1级备份Day1_Incr整合为虚拟完全备份Day1_VB,这只是恢复目录中维护的一组元数据,其中包含对增量备份Day1_Incr的数据文件块的引用以及以前增量备份的块的引用,从而回归到初始的增量0级备份.
实际上,虚拟完全备份引用的块构成了物理完全备份集,可以恢复到时间点Day1.
这样,增量存储使恢复设备能够以只执行增量备份的成本创建"完全备份",只需标准完全备份操作耗用时间和存储的一部分,如下所示.

图5:增量存储虚拟完全备份由于受保护数据库使用熟悉的RMANBACKUP命令,因此所有虚拟完全备份在恢复目录中都显示为正常的增量0级备份,可根据需要用于将来的RMAN恢复操作.
当受保护数据库发出RMANRESTORE命令后,恢复设备将做出如下响应:读取适当的虚拟完全备份块,构建物理完全备份集,然后将备份集发送给数据库,最后在这些数据库中恢复这些备份.
下图展示了如何从虚拟完全备份创建第"N"天的物理完全备份集,虚拟完全备份引用了第1天、第2天和第"N"天增量备份块.
图6:第"N"天虚拟完全恢复7|零数据丢失恢复设备技术白皮书总之,虚拟完全备份的概念对RMAN和受保护数据库是完全透明的—DBA可继续对恢复设备利用其现有的RMAN技能.
复制当将本地恢复设备的备份复制到辅助恢复设备时也支持RMAN透明性模型,以防范服务器或站点中断.
本地恢复设备收到增量备份后,增量备份自动排队以转发到辅助恢复设备,即只复制更改的块,不是完全备份.
复制恢复设备收到增量备份后,会在系统上以正常方式创建虚拟完全备份,并在自己的恢复目录中创建新备份记录,然后将这些备份记录传播回本地恢复设备的目录.
图7:恢复设备复制模型由于本地恢复设备中也保存有辅助恢复设备中复制备份的记录,因此本地恢复设备无法满足的任何虚拟完全备份请求将自动转发到复制恢复设备,在复制恢复设备中,将以正常方式构建物理备份集,并发送回受保护数据库.
同样,DBA继续正常利用RMAN,无需了解备份集的起源位置或创建方式.
自发磁带归档与单纯磁盘备份系统相比,恢复设备非常适用于持续依赖磁带来实现长期数据保存和归档的IT组织.
如前所述,恢复设备的每个计算服务器上都预先安装了OracleSecureBackup软件,并配备了一个16Gb光纤通道卡,以便直接连接到磁带硬件.
当恢复设备执行复制到磁带作业来实现虚拟完全备份时,首先构建物理备份集,然后通过内置的SBT接口将其推送到磁带.
一旦磁带备份完成,即将适当的备份元数据写入恢复目录.
恢复设备执行所有磁带复制操作时对生产系统无任何影响.
8|零数据丢失恢复设备技术白皮书图8:将第"N"天虚拟完全备份复制到磁带恢复设备会自动检索需要从磁带恢复备份的请求—无需DBA采取任何操作.
此外,由于磁带上的备份是物理备份集,因此受保护数据库可根据需要直接恢复这些备份.
只需对受保护数据库配置随OracleSecureBackup一起安装的SBT插件模块,然后正常分配SBT通道,即可直接从磁带执行恢复操作.
恢复设备操作接下来,我们讨论一下该设备是如何操作的,包括保护策略的作用和增量存储的存储空间管理方面,所有这些都使用EnterpriseManagerCloudControl进行配置和监视.
保护策略恢复设备引入了保护策略的概念,保护策略定义了细粒度恢复周期目标,以便针对本地或复制恢复设备和/或磁带上的备份逐个数据库执行这些策略.
保护策略可用于按恢复服务层轻松对数据库进行分组,例如,"黄金级"层数据库要求本地恢复设备和磁带的恢复周期分别为35天和90天,而"白银级"层数据库则要求本地恢复设备和磁带的恢复周期分别只能为10天和45天.
可在某策略内定义可选的最长磁盘保留期(如数天、数周或数月),以硬性限制实施该策略的数据库占用的空间量.
也可在复制恢复设备设置单独的保护策略,以便控制复制备份的空间管理.

图9:恢复设备—数据库保护即服务9|零数据丢失恢复设备技术白皮书对于这种独特的实现,恢复设备引入了数据库保护即服务的概念,通过它,可以基于业务应用程序的重要性,而不是仅基于存储空间的可用性,轻松实施数据库保护战略.
空间管理和恢复周期一旦创建了保护策略,即可为其分配数据库以及最小预留空间(如以GB或TB计),恢复设备将使用该空间根据定义的恢复周期目标供应备份空间.
数据库预留空间定义了数据库备份始终可用的最小空间量.
首先使用所有可用空间供应空间,然后如果需要,再通过清除过时的虚拟完全备份(即不再需要满足数据库恢复周期目标的备份)来供应空间.
图10:基于保护策略的空间管理例如,如果HR数据库今天需要1TB空间来支持为期3周的恢复周期,但其备份空间明天需要增加到2TB以承载明天更高的负载,那么存储位置将首先利用任何可用的空间来增加1TB空间,如有必要,再通过清除过时的虚拟完全备份和与其他数据库(如FIN、CRM)有关的相应归档日志备份来增加空间.
反之,当HR数据库上的负载减少,再次只需要1TB空间来支持为期3周的恢复周期时,如果其他数据库需要更多的空间满足自己的恢复周期目标,恢复设备可清除HR数据库上任何过时的虚拟完全备份.
也可以根据需要主动清除备份,以满足预期的未来空间需求—这种"预测清除"后台进程基于历史空间使用模式.
如果所有过时备份已清除,但某些数据库仍然需要更多空间来满足自己的恢复周期,那么存储位置将开始清除占用空间高于最小预留空间的数据库中最早的虚拟完全备份,优先清除空间超额百分比最高的数据库.
请注意,在某些情况下,该操作可能会影响数据库的恢复周期目标.
如果影响数据库的恢复周期目标,系统会向管理员发出警报,提示需要增加容量以维持规定的恢复周期.
然后管理员可采取措施增加磁盘容量,提高预留空间,以允许系统返回到平衡状态,从而满足所有恢复周期.
总之,恢复设备可全面管理所有备份空间,以满足每个数据库的恢复周期目标,可根据需要自动重新供应空间,主动清除备份以满足未来的空间需求.
10|零数据丢失恢复设备技术白皮书备份验证一个成熟的备份和恢复战略的一项基本原则是确保创建的备份确实能够成功恢复和使用.
要确保备份数据块中没有物理损坏,可正确恢复,必须定期验证备份.
这通常意味着定期运行RMANRESTOREVALIDATE作业,以及定期向单独的计算机执行完全还原和恢复操作.
所有这些操作都会增加已满负荷运行的生产系统的开销.
使用恢复设备,会联机自动验证传入备份中Oracle块的正确性.
同样,也会验证复制到辅助恢复设备和/或复制到磁带的备份.
此外,虚拟完全备份本身也会通过设备上运行的一个后台任务定期进行验证.
另一个优势是备份验证操作现在从生产系统分流到了恢复设备,从而提高了生产系统的性能.
最后,由于使用ASM来在设备上存储备份数据,因此可以通过ASM镜像副本使其具有完全冗余性,主磁盘上ASM发现的损坏块可通过镜像副本自动修复.
还原和恢复对于恢复设备,使用RMAN执行数据库还原和恢复操作的方式与任何其他备份目标一样.
采用最基本的形式,发出的命令非常简单:RESTOREDATABASE;RECOVERDATABASE;当在某受保护数据库上发出RESTORE时,RMAN客户端会查阅恢复设备目录,以根据所需的时间点确定要还原的最适当的增量0级备份(虚拟完全备份).
然后通过为恢复设备配置的SBT通道请求虚拟完全备份.
该设备接收请求,根据增量存储中的适当虚拟完全备份块构建物理备份集,然后通过相同的SBT通道将备份集发送给RMAN客户端.
在RMAN客户端,接收备份集并进行验证,并将数据文件块还原到生产存储位置.
当发出RECOVERY时,RMAN客户端查阅恢复设备目录,确定请求的适当归档日志备份,以将还原的数据文件恢复到所需的时间点并允许打开数据库.
如果启用了重做传输,恢复设备将提供最新的归档日志,包括所有部分归档日志.
这样,可使用最新的数据版本恢复数据库,如下所示.
ArchivedLogBackupsSent&Applied图11:受保护数据库的还原和恢复过程11|零数据丢失恢复设备技术白皮书监视和管理OracleEnterpriseManagerCloudControl提供了恢复设备管理的全面、端到端的备份生命周期视图—从在数据库上开始RMAN备份直至存储至磁盘、磁带和/或复制到辅助设备中.
通过安装EnterpriseManagerRecoveryAppliance插件可启用设备的所有监视和管理功能.
从该控制台可轻松访问标准量度,如总体备份量/性能和总数据库空间占用/每个数据库空间占用.

图12:恢复设备EnterpriseManager主页—总体性能和存储量度图13:存储位置—总大小、恢复周期空间、预留的空间图14:存储位置详细信息—为满足恢复周期目标每个数据库所需的备份空间12|零数据丢失恢复设备技术白皮书通过单一控制台可提供整个数据库备份生命周期的端到端监视,如上次备份到设备的时间、上次复制到磁带的时间和上次复制的时间、下次计划备份到设备的时间.
图15:受保护数据库详细信息因为数据库恢复周期目标是恢复设备保护策略的核心组成部分,因此管理员可从恢复设备主页立即查看是否有任何数据库目前未满足自己的目标,然后下钻到受保护数据库页面,确定需要增加多少空间才会满足这些目标.

图16:恢复设备EnterpriseManager主页—"STORE26"不满足恢复周期目标13|零数据丢失恢复设备技术白皮书恢复周期当前满足目标所需的目标恢复周期空间预留空间为满足目标所需的空间超出了预留空间图17:"DB1116SM"需要更多的空间以确保满足恢复周期目标该控制台还提供了有关每个数据库数据保护状态的全面视图,可向恢复设备管理员立即发出有关任何备份或设备问题的警报—例如,备份未在"3天"内得到处理,或由于可用空间不足存储位置无法满足特定数据库的恢复周期目标等问题.
同样,如果发现损坏的备份,管理员需要立即得到通知,以便可从磁带或复制设备上的完好副本修复备份,或立即执行新的完全备份以确保可完全恢复从而修复备份.
EMCloudControl还为恢复设备管理员和DBA提供了一组丰富的状态报告,以便他们进行容量规划以及维持规定的恢复周期目标.
例如,管理员可以接收历史空间和网络使用情况报告来识别备份量和吞吐量趋势—将来可能需要增加额外系统以满足所有恢复周期目标和备份时窗要求.
最近7天存储增长率(GB/天,平均值)5810.
78容量超出之前的天数*5.
12图18:恢复设备存储容量规划报告管理员还可以接收当前未满足恢复周期目标的特定数据库的相关报告.
最后,在受保护数据库级,DBA可接收自定义的备份历史报告,这样他们可快速发现问题,如备份有故障或缺少等问题.

14|零数据丢失恢复设备技术白皮书可进行扩展以应对数据增长恢复设备可轻松扩展,以容纳不断增长的受保护数据库、备份流量和存储用量,只需添加计算服务器和存储服务器即可进行扩展.
基本机架包括2台计算服务器和3台存储服务器,最多为备份提供42TB可用容量.
如果通过增加存储服务器来升级基本机架,可增加最多14台存储服务器,可用容量达到245TB,为虚拟完全备份提供的有效容量高达2.
45PB,虚拟备份速率达120TB/小时(持续增量摄取率高达12TB/小时).
如果需要增加计算服务器,可搭建另一个机架,并通过Infiniband连接到第一个机架—如同第一个机架一样,可轻松扩展存储容量.
最多可将18个全配置机架连接在一起,提供多达4.
5PB的可用容量,可有效存储45PB的虚拟完全备份,虚拟备份速率高达2PB/小时(增量摄取率高达216TB/小时).
一个全机架可支持高达12TB/小时的恢复速度,18个全配置机架则可支持高达216TB/小时的恢复速度.
请参阅恢复设备产品介绍2,了解更多的产品规格.
图19:恢复设备机架配置相关技术下面我们将了解恢复设备如何完善了相关的Oracle产品和解决方案.
最高可用性架构最高可用性架构(MAA)是Oracle为了部署Oracle高可用性产品和特性而提供的最佳实践蓝图3.
对于数据库,该架构提供了高可用性技术,其中包括RAC、ASM和闪回,还提供了灾难恢复解决方案,如RMAN、ActiveDataGuard和GoldenGate,如下所示.
2零数据丢失恢复设备产品介绍,http://www.
oracle.
com/us/products/engineered-systems/recovery-appliance-twp-2313693.
pdf3最高可用性架构,http://www.
oracle.
com/goto/maa15|零数据丢失恢复设备技术白皮书图20:恢复设备和最高可用性架构正如我们所看到的,恢复设备充当数据中心内所有数据库(无论是主数据库还是备用数据库)的整合备份存储.
虽然ActiveDataGuard备用数据库可为特定生产数据库提供零数据丢失和快速故障切换功能,但恢复设备为所有数据库提供了一个高效且可靠的备份基础,还为OracleDatabase11g和12c提供了亚秒级数据丢失保护.
如前所述,该设备可将备份复制到磁带,从而提供了集中的企业磁带归档.
如果出现本地存储中断或甚至发生双站点故障,恢复设备可随时作为可靠的备份存储来执行关键数据库恢复.
Oracle数据库备份到云Oracle数据库备份服务(ODBS)是一款全新、RMAN集成、基于订阅的备份存储产品,它基于Oracle公有云.
用户只需为其在备份过程中传输数据所用的带宽及使用的备份存储付费,且按月支付—数据传输过程中完全支持RMAN压缩和加密.
借助该服务,只需使用专用的RMANSBT备份模块(可验证Oracle公有云的身份并进行连接),即可通过安全、低成本的备份解决方案快速、轻松地设置数据库,没有构建内部基础架构的成本和开销.

同样,可在恢复设备上安装并配置ODBSSBT备份模块,为Oracle公有云提供备份到云服务.
例如,对于某些数据库层,DBA可以选择将虚拟完全备份归档到云,而不是供应磁带硬件.
恢复设备灵活地支持磁带归档和云归档这两种方法,完全由企业自己决定如何将这些方法用于自己的特定数据库.

16|零数据丢失恢复设备技术白皮书图21:恢复设备—归档到Oracle公有云ZS3备份设备ZFS存储设备ZS3-BA是一款低成本的备份设备,用于Oracle环境和非Oracle的类似环境.
除了提供RAID-Z和压缩特性来提高存储效率之外,ZS3-BA还支持只读和可读写快照以用于开发和测试目的,而且内置有数据库快照工具.
虽然ZS3-BA可能是支持少量受保护数据库的经济高效型备份目标,但恢复设备支持实时重做传输且与RMAN紧密集成,是整个数据库中心内大规模数据库保护的最佳选择.
OracleMultitenantOracleDatabase12cMultitenant是一个新的数据库选件,它允许将运行在不同计算机上的多个数据库整合("插入")到一个大型的"容器"数据库,从而与独立运行相比,每个"可插拔数据库"可更好地利用单个计算机的聚合计算和内存资源.
RMAN支持备份和恢复各个可插拔数据库和容器数据库.
特别是,整合数据库后,容器级备份能够备份所有可插拔数据库,因此相比于对每个数据库运行单独的RMAN备份会话则更高效,也可以对特定的可插拔数据库进行恢复,而不会影响其他可插拔数据库的状态.
恢复设备的"持续增量"备份战略完全支持多租户数据库.
RMAN负责处理可插拔数据库与其组合数据文件的所有必要转换,该设备只需将增量备份作为标准的虚拟完全备份进行接收和存储并进行编目即可.