Oracle ADG远程数据保护方案Word文件下载.docx
- 文档编号:6841631
- 上传时间:2023-05-07
- 格式:DOCX
- 页数:32
- 大小:425.76KB
Oracle ADG远程数据保护方案Word文件下载.docx
《Oracle ADG远程数据保护方案Word文件下载.docx》由会员分享,可在线阅读,更多相关《Oracle ADG远程数据保护方案Word文件下载.docx(32页珍藏版)》请在冰点文库上搜索。
该解决方案能够在一个或多个远程位置维护生产数据库的一个或多个同步物理副本,从而以最简单和最经济的方式防止数据丢失和停机。
如果生产数据库由于任何原因变为不可用,应用程序可以迅速地
(在某些配置中可以透明地)故障切换至同步副本以恢复服务。
此外,ActiveDataGuard还支持将报告应用程序、即席查询和数据提取分流到生产数据库的只读副本,从而消除高昂的闲置冗余成本。
ActiveDataGuard与Oracle数据库深度集成,并且完全专注于实时数据保护和可用性,避免了同类数据保护解决方案中出现的不利影响。
DataGuard是唯一具备保护和恢复双重能力的Oracle数据库复制解决方案,如果生产数据库由于任何原因变为不可恢复,该解决方案不仅可提供零数据丢失保护,还可接近即时地恢复服务。
这是因为,该解决方案在备用数据库上结合使用了DataGuard同步重做传输和复制感知的应用进程。
然而,当主数据库与副本数据库相隔很远的距离时,任何同步复制方法都可能对数据库性能产生影响,这往往使得实现零数据丢失保护变得不切实际。
为了不影响数据库性能,许多企业宁愿实施异步复制,在数据保护上做出让步,接受无法恢复的中断将导致程度不等的数据丢失这一事实。
ActiveDataGuard远程同步是OracleDatabase12c中的一项新功能,可将零数据丢失保护扩展至距主数据库任意距离的副本数据库,从而避免这种让步。
与其他远距离数据保护和可用性解决方案相比,ActiveDataGuard远程同步只需投入极少的成本,并且复杂性也最小。
本文将描述用于成功实施ActiveDataGuard远程同步以实现任意距离的零数据丢失保护的Oracle最高可用性架构(OracleMAA)最佳实践和实施洞察。
DataGuard零数据丢失保护
要实现零数据丢失保护,需要生产数据库(主数据库)与用于数据保护和可用性的副本数据库(位于远程目标的备用数据库)之间进行同步通信。
DataGuard或ActiveDataGuard的最常用的零数据丢失配置是结合使用最高可用性保护模式和同步重做传输(SYNC)。
SYNC传输与DataGuard应用服务对Oracle事务语义的深入理解相结合,可在主数据库发生意外中断期间确保零数据丢失。
用户在主数据库中提交事务时,Oracle会生成重做记录并将它们写入本地联机日志文件。
与此同时,DataGuard传输服务会直接从主数据库日志缓冲区(系统全局区域中分配的内存)将相同的重做传输到备用数据库,并在此将其写入备用重做日志文件。
SYNC传输需要主数据库等待本地和远程日志文件写入完成,然后再向应用程序发送提交成功通知。
然而,随着主数据库与备用数据库之间距离的增加,确认远程日志文件写入所需的总往返时间可能会达到这样一种地步,即对数据库性能的影响非常大以至于使得支持零数据丢失保护变得不切实际。
在OracleDatabase12c之前,跨广域网实现零数据丢失保护的唯一解决方案是部署包含两个备用数据库的Data
Guard配置。
第一个备用数据库位于主数据库的一定距离之内,其往返网络延迟不高,因而同步通信实际可行。
第二个备用数据库部署在远程位置,并利用异步通信(ASYNC)。
零数据丢失故障切换至位于远程位置的备用数据库是一个两步过程:
首先,零数据丢失故障切换至本地备用数据库,随后零数据丢失转换(计划事件)至远程备用数据库,在此位置将运行生产负载。
虽然该解决方案有许多优点,但如果其唯一目的就是实现零数据丢失故障切换至远程位置,那么部署第二个备用数据库带来的额外的费用和复杂性很难说是合理的。
ActiveDataGuard远程同步
ActiveDataGuard远程同步是OracleDatabase12c中的一项新功能,能够执行零数据丢失故障切换至远程备用数据库,且无需第二个备用数据库或复杂的操作。
远程同步在距离主数据库的可接受的范围内部署一个远程同步实例
(轻型Oracle实例,仅包含控制文件、spfile、口令文件和备用日志文件,不包含数据库文件或联机重做日志)以实现SYNC传输,藉此实现零数据丢失故障切换。
远程同步实例通过SYNC传输从主数据库接收重做,并立即通过ASYNC传输将该重做转发至最多29个远程备用数据库,如图1所示。
远程同步实例还可将重做转发至新的
Oracle数据库备份、日志记录与恢复一体机1。
DataGuard配置中远程同步实例的存在对于其在转换或故障切换过程中的运行而言是透明的,管理员可以使用适用于任何DataGuard配置的相同命令。
利用远程同步,用户无需学习新知识或执行任何其他过程,即可跨广域网
(WAN)执行零数据丢失故障切换。
远程同步实例从主数据库分流了任何以下任务带来的任何开销:
»
解析远程备用数据库接收的存档日志中的差异(如发生网络或备用数据库中断后)。
采用多个备用数据库的配置的重做传输开销。
主数据库向远程同步实例传输一次重做,然后由远程同步负责传输至多个目标。
1
远程同步实例还可以执行主机外网络压缩,从而节省WAN带宽且不会影响主数据库性能。
远程同步实例的轻型性质和透明运行相比于以前的WAN零数据丢失保护的多备用数据库解决方案有明显的改进;
远程同步实例无需任何用户数据文件、任何介质恢复以及任何Oracle数据库许可。
远程同步实例仅需要足够的磁盘空间来存储备用重做日志文件,以及保留存档重做日志以解析可能发生的任何差异。
远程同步实例需要很少的SGA空间(远远少于生产数据库)且占用的CPU不到一个(同时执行重做传输压缩时除外)。
图1:
ActiveDataGuard远程同步架构
对于希望实现零数据丢失保护的用户,远程同步让他们可以更灵活地选择灾难恢复站点的位置。
甚至已部署Data
Guard同步传输的用户也可以通过使用远程同步而获益,他们可以在比其当前备用数据库更靠近主数据库的位置配置远程同步实例,以减少对生产数据库的性能影响。
此外,远程同步也为当前使用异步传输的用户带来了好处。
通过使用远程同步升级到零数据丢失保护,不再需要像异步配置中那样在发生故障切换后排解数据丢失问题,从而消除了相应的不确定性和管理负担。
以前,人们寄希望于自行解决中断问题,从而不丢失数据,因而往往倾向于推迟故障切换的执行。
使用远程同步消除了这种倾向,从而提高了可用性。
远程同步可确保零数据丢失,因此鼓励人们立即执行故障切换,以快速恢复服务同时解决导致中断的问题。
ASYNC配置下的主数据库也可享受上述的同样好处,即分流差异解析开销、为多个备用数据库提供服务和重做传输压缩。
在几乎所有情况下,要获得最高程度的数据保护和实现最小的性能影响同时降低网络带宽消耗,远程同步都是理想之选。
请注意,ActiveDataGuard许可包括远程同步使用权。
主数据库和从远程同步实例接收重做的任何备用数据库都必须获得ActiveDataGuard许可。
ActiveDataGuard许可还包括在单实例(非RAC)数据库上部署远程同步实例的权利,无需另行购买Oracle数据库许可。
然而,如果在OracleRAC上部署远程同步,则需要另行购买Oracle
RAC许可。
远程同步部署架构—示例
以下是远程同步的几个常见用例。
用例1:
使用一个远程同步实例的简单配置
这是最基本的配置示例,其中主数据库使用一个远程同步实例将零数据丢失故障切换扩展至一个远程备用数据库
(图2)。
理想情况下,远程同步实例与主数据库部署在不同的位置,以便使其免受站点故障的影响,但两者之间的距离要在城域距离之内(根据性能测试,网络RTT为5毫秒或更短)。
即使没有另外的位置可用于部署,在同一个数据中心内部署远程同步实例仍有一定的好处,除完全站点故障之外,所有无法恢复的中断都可实现快速的零数据丢失故障切换。
图2:
使用ASYNC备用目标的简单远程同步
在这个简单的用例中,只有一个远程同步实例,且配有远程备用数据库,该数据库定义为主数据库的备用目标。
这样,如果远程同步实例发生中断,DataGuard可自动使用异步传输直接传输到远程目标,以维护接近零的数据丢失保护。
一旦远程同步实例已经修复并重新建立连接,DataGuard自动将配置恢复为零数据丢失保护。
用例2:
远程同步HA
该用例建立于前一个示例之上,该示例添加了第二个远程同步实例作为第一个远程同步实例的备用目标(图3)。
DataGuard可以自动从一个远程同步实例切换到另一个远程同步实例,最大程度地降低了对零数据丢失保护的中断。
在此情景下远程同步实例的HA指的是维护零数据丢失保护的能力。
如果一个远程同步实例发生中断,永远不会对主数据库或备用数据库的可用性造成任何影响。
图3:
零数据丢失保护的HA配置
实现HA的一个有效的替代方案是在OracleRAC上部署远程同步(需要OracleRAC许可),这里我们没有给出图示。
OracleRAC可消除或尽量缩短远程同步中断期间配置低于零数据丢失保护级别的时间段。
本文后面部分将对此详细讨论。
用例3:
角色转换之后的零数据丢失保护
该用例建立于用例1和用例2之上,该示例在距远程备用数据库的城域距离内添加了一个远程同步实例(图4)。
当备用数据库处于备用角色时,这个远程的远程同步实例处于闲置状态。
当备用数据库转换为主数据库角色时,这个远程同步实例变为活动状态,允许零数据丢失故障切换至新的备用数据库(原来的主数据库)。
当原始主数据库处于备用角色时,其本地的远程同步实例变为非活动状态。
图4:
用例4:
ReaderFarm
远程同步最多可支持30个远程目标。
这使其成为支持readerfarm的一个非常有用的工具,readerfarm是一种ActiveDataGuard配置,它具有多个活动的备用数据库以轻松扩展读取性能。
在该示例中,在远离主数据库的远程位置配置readerfarm(图5)。
主数据库通过WAN向位于远程目标的远程同步实例传输一次重做,然后远程同步在本地将重做分发给readerfarm中的所有活动备用数据库。
图5:
ReaderFarm—传输一次,分发给多个
上例只是配置readerfarm的一个方法。
例如,主数据库也可以有一个备用数据库,以用于灾难恢复。
进行转换或故障切换后,新的主数据库会自动接替着将重做传输至远程同步实例。
DR备用数据库也可与ReaderFarm位于同一位置。
主数据库可向DR备用数据库传输一次重做,接着该备用数据库可将重做传输至远程同步实例,然后远程同步实例再将重做分发给readerfarm。
用例5:
云部署—远程同步中心
远程同步是一个非常轻量级的进程。
单台物理服务器可支持多个远程同步实例,每个远程同步实例都可提供到远程目标的零数据丢失故障切换。
在图6所示的示例中,主数据库将重做传输至作为远程同步中心的单台物理机器上,这台机器上运行着多个远程同步实例。
主数据库和远程同步中心在内部部署,而备用数据库远程部署在云中。
请注意,这种配置中的所有系统(主数据库主机和备用数据库主机以及远程同步主机)都必须满足DataGuard配置中的一般兼容性要求,如MyOracleSupport说明413484.1所述。
图6:
云部署
远程同步配置最佳实践
远程同步实例的行为完全类似于为SYNC传输配置的任何其他DataGuard/ActiveDataGuard存档目标。
这意味着,影响往返网络延迟的光速物理定律没有任何变化;
主数据库性能将仍受主数据库与远程同步实例之间的网络往返时间的影响。
然而,远程同步为实现长距离的零数据丢失保护提供了灵活的方案,利用远程同步,可以在距主数据库的城域距离内部署远程同步实例,让该远程同步实例处理与位于数百或数千英里之外的远程备用数据库的所有通信。
这样,除影响大范围地理区域,导致主数据库和远程同步实例同时中断的灾难之外,对于所有情况均可实现零数据丢失故障切换。
其本身几乎没有必需的配置最佳实践。
大多数配置最佳实践与应用于任何SYNC重做传输目标的配置最佳实践相同。
它们是:
主数据库与远程同步实例之间的网络必须:
使往返延迟足够低,以便对主数据库的响应时间和吞吐量的影响不超过业务要求。
影响程度和应用程序有很大关系,需要通过测试来进行验证。
总地来说,经验表明,尽管往返延迟较高时也有成功的部署,但如果延迟低于5毫秒,成功的概率会更高。
在主数据库与远程同步实例之间提供足够的带宽,以便不仅能够容纳共享该网络的所有其他流量,还能应对高峰重做量。
可以使用重做传输压缩来减少对网络带宽的需求。
理想情况下,还可以使用冗余网络链路,从而容许网络组件故障。
标准DataGuard网络最佳实践,例如将TCP发送和接收缓冲区大小适当设置为带宽时延积的三倍。
有关详细信息,请参见DataGuard网络传输MAA实践。
2
远程同步实例的备用重做日志(SRL)应放置在具有足够IOPS(每秒写入次数)容量的存储上,该容量应超过其他活动的任何IOPS以及高峰活动期间主数据库上LGWR进程的I/O。
这是一个重要的考虑因素。
例如:
如果远程同步实例上的高性能磁盘少于主数据库,那么可能无法以接收重做的速度将重做转发至远程目标,因此可能会产生存档日志差异。
在因对备用数据库进行计划维护或网络中断等原因而需要进行重做差异解析的情况下,将基于当前事务的重做产生额外的IO请求以进行差异解析。
如果远程同步实例拥有更少的高性能磁盘,将延迟向主数据库发送确认,从而增加主数据库与备用数据库之间的总往返时间并影响应用程序的响应时间。
通过在主数据库与远程同步实例之间使用快速同步,可以消除这种影响(请参见本文后面有关快速同步的详细信息)。
根据标准MAA最佳实践,对于每个线程,远程同步实例的备用重做日志(SRL)中包含的重做日志组数应为(主数据库上的重做日志组数+1)。
备用远程同步的SRL在使用之前应手动清除,以便激活备用远程同步时以最快的速度恢复SYNC传输以及零数据丢失保护。
性能测试表明,小的远程同步实例SGA不会影响远程同步实例的性能,也不会影响主数据库的性能。
MAA建议配置远程同步运行所需的最小SGA。
使用实例囚笼3,以实现尽可能最小的SGA。
在测试期间减少CPU_COUNT,发现这对远程同步实例的性能无任何影响。
MAA测试确定,在Linux上CPU_COUNT=1的300MBSGA300对于远程同步来说足够了。
(CPU_COUNT=1SGA_TARGET=300M)
在远程同步实例上将RMAN存档日志删除策略配置为“SHIPPEDTOSTANDBY”或“APPLIEDONSTANDBY”,以自动管理远程同步实例上的磁盘空间。
假若主数据库或备用数据库存在适当的备份计划,则不必在远程同步实例备份存档日志。
既为主数据库也为备用数据库配置远程同步实例,以便在角色转换后维护零数据丢失保护。
在距备用数据库城域距离内部署的远程同步实例在备用数据库成为主数据库之前处于闲置状态。
请注意,在DataGuardBroker配置中,在最高可用性模式下不会进行转换(计划角色转换),除非可以从目标备用站点启用保护模式。
如果备用数据库没有自己的远程同步实例,则只能将其配置为反转角色后通过
ASYNC将重做传输到原始主数据库。
除非主数据库的保护模式首先从最高可用性下降到最高性能,否则这将阻止进行转换。
2
3
快速同步是DataGuard12c中的一项新功能,相比于SYNC,它让主数据库的性能提升了4%至12%,具体提升程度取决于网络延迟和远程同步实例硬件的I/O速度。
请参阅本文后面描述快速同步的章节。
如果将远程同步实例放置在虚拟机上,假若满足CPU、I/O和网络需求,相比于物理硬件配置无任何性能差异。
配置远程同步—示例和中断场景
在最高可用性模式下运行的远程同步实例发生中断对主数据库的可用性无任何影响,只是暂时断开,同时主数据库收到错误通知。
主数据库在收到通知后继续处理数据库事务。
大多数情况下,会立即发出通知,但在某些故障情况下会暂时挂起故障通知直到net_timeout阈值过期(用户可配置的DataGuard参数,默认值为30秒)。
对于使用最高可用性模式的任何DataGuard配置,这是标准操作。
一旦解决导致DataGuard断开的问题后,DataGuard的自我修复机制将自动重新连接并重新同步备用数据库。
这些自动机制同样适用于远程同步。
如果出现双重故障情况,如远程同步中断后紧跟着出现主数据库中断或主数据库中断后紧跟着出现远程同步中断,远程同步环境下的HA能够消除或最大程度地减少数据丢失的潜在风险。
这种环境下的HA可通过多种方法来实现。
每种方法都有自己的权衡和考虑,下面各节将对每种方法逐一进行介绍。
结合使用这里给出的不同方法也是可行的。
注意:
《DataGuard概念和管理》中的第5.1节介绍了如何创建远程同步实例。
4
通过使用终端备用数据库作为备用目标实现HA
远程同步中断期间维护数据保护的最简单方法是创建一个直接指向终端备用数据库(最终故障切换目标)的备用
LOG_ARCHIVE_DEST_N,采用的架构类似于图2所示的架构。
最有可能的选择是使用异步传输(ASYNC)将重做传输至远程目标,以避免WAN网络延迟引起的性能影响。
ASYNC可实现接近零的数据丢失保护(只有亚秒级数据丢失风险),但由于它从不等待备用数据库确认,因此无法保证零数据丢失。
在远程同步中断期间,重做传输将自动故障切换至使用备用目标。
一旦远程同步实例已经修复并恢复运行,传输将自动切换回远程同步实例,从而恢复零数据丢失保护。
请注意,在转换至终端备用数据库(计划角色转换)过程中,该配置的保护模式必须降低至最高性能,以便可以在角色转换的目标启用保护模式。
更改保护模式和传输方法是一种无需停机的动态操作。
4
该方法具有以下特点:
无需管理额外的远程同步硬件或实例。
远程同步实例中断期间丧失零数据丢失保护。
数据保护级别下降至UNSYNCHRONIZED(ASYNC传输),直到远程同步实例能够恢复运行,这时会重新建立同步通信,备用数据库变成完全同步。
该示例的相关配置参数包括:
主数据库(primary):
log_archive_dest_2=service="
farsync"
SYNCNOAFFIRMdelay=0optionalcompression=disablemax_failure=1max_connections=1reopen=5db_unique_name="
net_timeout=8,alternate=LOG_ARCHIVE_DEST_3valid_for=(online_logfile,all_roles)
log_archive_dest_3=service="
standby"
ASYNCNOAFFIRMdelay=0optionalcompression=disablemax_failure=1max_connections=1reopen=5db_unique_name="
alternate=LOG_ARCHIVE_DEST_2valid_for=(online_logfile,all_roles)
log_archive_dest_state_2=ENABLElog_archive_dest_state_3=ALTERNATElog_archive_config=dg_config=(primary,farsync,standby)fal_server=standby
主远程同步“A”(farsync)
log_archive_dest_2=”service="
ASYNCNOAFFIRMdelay=0optionalcompression=disablemax_failure=0max_connections=1reopen=5db_unique_name="
net_timeout=8,valid_for=(standby_logfile,all_roles)
log_archive_dest_state_2=ENABLE
log_archive_config=dg_config=(primary,farsync,standby)fal_server=primary
备用数据库(standby):
primary"
ASYNCreopen=5db_unique_name="
valid_for=(online_logfile,all_roles)
log_archive_config=dg_config=(primary,farsync,standby)fal_server=farsync,primary
上述参数是通过SQL*Plus进行设置时与此配置有关的参数,在此提供这些参数以便读者清晰了解该配置的所有细节,然而Oracle建议使用DataGuardBroker来配置远程同步,这种方法更简单。
有关使用DataGuardBroker配置远程同步的步骤,请参见附录C
对于OracleRDBMS版本12.1,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Oracle ADG远程数据保护方案 ADG 远程 数据 保护 方案