Oracle数据仓库备份的五个方案分析

数据仓库环境,ORACLE RAC,100T数据,每日归档那个量5T(对于不需要产生备份的数据,已经采用了nologging方式,以减少归档数量),如何制定备份和恢复方案?

方案一:DataGuard

DataGuard是性价比最高的备份和容灾方案,但是当归档超过一定规模之后,DG的恢复就成为了瓶颈,每天产生的归档无法及时恢复完,我们也尝试过很多调优的方法,包括并行恢复,都无法解决,恢复的瓶颈不在存储的吞吐量,而在于standby的恢复方式,因为恢复的过程就是应用归档文件,RAC各个节点产生的归档必须在一个节点恢复,这个过程必须是遵循一定顺序的,大大限制了恢复的并发速度。

方案二:传统RMAN备份

采用传统RMAN备份,采用大吞吐量的虚拟带库设备,一周全备一次,每天备归档日志。很多时候,我们在做备份方案时,只考虑了备份,却没有考虑恢复。这个方案最大的问题就在于:恢复的代价非常高,一旦数据库出现问题,恢复可能需要数天之久,这是无法接受的。另外,还要额外购买备份设备。

方案三:存储镜像

数据库采用noarchivelog模式,采用ASM镜像两套存储。这个方案并不是备份方案,只是为了解决存储的单点问题而提出的,相当于对不同的存储做RAID 1。这个方案最大的问题是无法解决数据库逻辑错误,比如误删除数据。因为主库和备库通过存储镜像来实现,无法实现异地备份和容灾。

方案四:存储级别复制

采用存储级别的复制,各存储厂家都有解决方案,比如EMC SRDF等。Veritas也有类似的解决方案,比如卷复制(VERITAS Volume Replicator)。这种方案的基本原理都是通过捕获底层存储的IO,并通过网络同步到备份系统上。如果采用存储厂商的方案,那么主备库就必须使用同一家公司的产品,而且,能否承受每天4.5T的数据变化量,我们并没有验证过。另外,软件license费用不菲。

有人说:能用钱解决的问题不是问题。可是,问题是没钱!Alibaba虽然不缺钱,但是我们的目标就是花小钱办大事。我个人也不推荐使用存储厂商的解决方案,这不仅仅是钱的问题,而是这种方案基本上就是个黑盒,我们还是喜欢更简单开放的解决方案。

既然ORACLE DG是性价比最高的备份和容灾方案,我们还是想通过DG来解决这个问题。DG的好处在于可以随时打开备份,验证有效,standby延迟恢复还可以解决逻辑错误,防范ORACLE软件bug可能带来的损失。解决方案的核心就是要解决DG恢复速度慢的问题。

方案五:ORACLE DG+块级别增量备份/恢复+归档

从10g开始,ORACLE提供了一个功能:块改变跟踪(block change tracking),通过bitmap记录block的变化,通过这个块改变跟踪文件,就知道哪个block发生了变化,大大提高了增量备份的效率。具体方案为:首先为数据库建立一个0级备份(standby),然后将1级备份应用到0级备份上,相当于恢复的过程,这个恢复比应用归档日志要快很多,为什么?因为备份都是变化的block,只要将旧的block覆盖就可以了,所以不存在日志恢复过程中的顺序问题,所以恢复的并行度可以很大,可以充分发挥出设备的吞吐能力。另外,当一个block被重复变更多次时,增量备份只需要备份最新的block,恢复也只要覆盖旧的block即可,定期增量备份实际可以减少备份需要的空间使用量。而redo文件中记录了block变化的记录,所以应用redo恢复时需要多次变更该块,必须保留所有的归档文件才可以恢复成功。当然,应用1级备份之后,standby并不能打开,因为block并不是一致状态的(因为增量备份会持续很长的时间,在这个过程中,备份的block的时间点是不一致的),所以要利用归档文件将standby推到一致的状态才可以打开。

我们目前的方案:建立standby数据库,每周做一次增量备份,首先应用增量备份,然后应用归档日志文件将数据库推到一致状态,可以打开数据库,验证备份有效,归档日志文件循环备份到磁带库,整个过程通过脚本实现自动化。这个方案采用增量备份+archivelog恢复standby,可以打开standby验证备份有效,出现故障时可以直接standby switchover,大大节省了恢复的时间。而且,这个方案都是基于现有硬件基础,基本上没有采购额外的硬件设备和软件license,花小钱办大事。

后记:这个问题,我曾经在OOW上问过ORACLE的技术专家,他们也没有很好的解决方案,建议我们买两套Exadata来解决(我并没有搞清楚为什么Exadata恢复归档的速度会变快,是设备本身的能力提高了,还是ORACLE恢复的方式发生了变化),或者放弃数据库级别的备份,由应用程序写多份数据来解决。所以说,ORACLE也没有考虑到如此大数据量环境的备份问题,ORACLE可以考虑推广我们的解决方案。