ORACLE数据仓库备份方案分析

1 27th, 2011 | Posted by admin | Filed under 大话技术

数据仓库环境,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,花小钱办大事。

我的技术理念:做解决方案就是搭积木,用简单的技术去解决问题,并不一定要发明新的东西,最佳实践也是很有价值的。

–EOF–

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

标签:
  1. orainxiong
    1 27th, 201115:29

    顶顶顶: )

  2. jacky
    1 27th, 201115:29

    @orainxiong
    一个看似无解的问题,最终得到了解决,是不是很有成就感?

  3. David.Guo
    1 27th, 201115:31

    好像是骗ou的杯子的时候在ou的那个论坛问的?是不是呀,哈哈哈。

  4. jacky
    1 27th, 201115:32

    @David.Guo
    不是在那问的,后来找了HA部门的老大问的,也是无解。

  5. orainxiong
    1 27th, 201115:56

    @jacky
    瑞哥v5,我们都是跟你混的

  6. jacky
    1 27th, 201115:58

    @orainxiong
    全靠兄弟们给力!

  7. 真的要填?
    1 27th, 201117:58

    瑞哥Geliable,很懒得写这么长的文章了

  8. 冬瓜头
    1 27th, 201118:06

    看明白了,最终靠的是oracle的那个块级增量备份,但是不是说rman里面也是用了块级增量备份的么?不知道两者有什么具体区别?

  9. jacky
    1 27th, 201118:47

    @冬瓜头
    块级别增量备份就是RMAN的功能,备份完之后直接应用到standby上去,然后再用归档恢复。

  10. 冬瓜头
    1 28th, 201110:00

    意思是说用RMAN实时的将增量数据恢复到备库?RMAN支持这种搞法,还是Jacky自己开发一些东西?

  11. 八神
    1 28th, 201114:19

    RMAN本身就支持的,将块级增量备份出来,然后应用到standby上面去,这个standby即可以用datafile change block往前滚,也可以用archivelog往前滚,只不过要达到open的一致性,一定要在open前,用archivelog来推,单纯的datafile block增量是不能达到一致性的

  12. 八神
    1 28th, 201114:21

    从10G开始,数据库有了block change file这个map文件专门记录标识哪些block变化了,所以做增量备份,不需要扫描整个数据库。
    并且nologging的操作,对他来说也没关系

  13. ArduousBonze
    1 28th, 201116:41

    终于看到一回block change tracking的真实的给力的使用案例,学这个的时候,只是知道能加快RMAN的增量备份,一直没想到在什么场景下,能发挥这个功能的极致,今天学习了。厉害,Jacky!

  14. jacky
    1 28th, 201117:00

    @ArduousBonze
    不仅仅是备份快,关键是恢复快,因为可以并行度可以很大,结合standby和归档恢复,可以解决DW的备份问题。

  15. 八神
    1 28th, 201119:39

    使用这个备份方式,也是逼上梁山,不得已而为之,数据仓库真的还是需要发挥大规模群集做计算,关系型数据库做最终结果的保存和展示
    目前的数据量,RAC已经是力不从心了

  16. rmans
    2 17th, 201123:15

    很好的实例,不知道对比下来速度提高了多少啊

  17. Kamus
    2 20th, 201102:32

    仍然有疑问。
    之前我们也讨论过这个问题,但是当时我认为最大的瓶颈在于DG要恢复每天5T的归档,这与你方案5中的增量备份并没有关系。
    即使在你现在的这个方案里,你也是每周做一次增量备份,那么当天的DG是如何推进到跟主库一样的SCN的?
    还是说备库根本就不和主库保持一致。那么假设某一周的最后一天主库完全崩溃了,现在手头上有的只是6天前的最后一次增量备份,还有30T的归档,你如何保证尽快打开备库。当然备库可以仅仅推进几个在增量备份时产生的归档就能够达到一致的状态,可以OPEN库,但是数据并不是最新的。
    也许是我还没有完全理解你说的方案5?

  18. jacky
    2 22nd, 201118:58

    @Kamus
    你的理解完全正确,最大的瓶颈是每天5T归档。每周做一次增量备份,然后马上将这个备份应用到standby上,应用增量备份比应用归档要快很多,这时,数据库是无法推送到一致状态的,所以,我们定期用归档将standby推送到一致状态去验证备份有效。
    主库和备库是存在一个时间差异的,目前我们的状况最大可能有7天的差异,如果主库存储全部挂掉,最坏情况可能需要恢复7天的归档日志。但是,我们的数据库是很多套存储通过ASM整合的,全部同时挂掉的概率很小,如果只有部分损坏,我直接把standby存储mount上去,恢复就很快了。
    这个方案好在standby可以定期开打验证,主备库存在一个时间差异,通过增量备份去恢复standby,如果出现灾难,恢复的方法也很简单。

  19. Kamus
    3 1st, 201111:36

    哦,如果说允许主备库有时间差,那你这个方案确实OK.

  20. jacky
    3 1st, 201112:31

    @Kamus
    允许有差异,但是不能过大,否则恢复就是个问题。

  21. 木匠Charlie
    3 5th, 201101:23

    Primary database 是 No Archive Mode 吗?

    如果DIRECT PATH INSERT (+APPEND) 批量加载, 是copy文件,还RMAN增量恢复数据文件?

    多谢. 几个不得其解的疙瘩.

  22. 木匠Charlie
    3 5th, 201101:26

    改正一下第一个问题, Primary database 不是 Force Logging 吗? (不该问Archive Mode).

  23. jacky
    3 5th, 201110:51

    @木匠Charlie
    primary database是archive mode,但不是force logging。我们的系统中有一些临时数据,是采用nologging+direct path insert,备份方案中不包括这类数据,因为他们不需要恢复。

  24. 木匠Charlie
    3 5th, 201113:23

    感谢确认,踏实了.

    那么这些临时数据是不是放在一个单独(或者多个隔离的)的表空间里, 恢复前, 先drop掉这个表空间, 然后重建之…? 一点猜想.

  25. 木匠Charlie
    3 9th, 201102:36

    可能是你忙的忘记了. 再问一遍, 怎样恢复临时数据所在的表空间呢? no force logging.

  26. jacky
    3 9th, 201113:18

    @木匠Charlie
    哈哈,不需要恢复,都是生数据,从文件中导入即可。

  27. 木匠Charlie
    3 9th, 201114:40

    很久没做备份和恢复的维护工作了,有点晕. 不恢复临时数据所在的表空间,SCN和主库不一致,能打开数据库吗?
    (“这个standby即可以用datafile change block往前滚”, 还可以理解)

  28. jacky
    3 9th, 201117:17

    @木匠Charlie
    不是这样的,恢复还是一样恢复的,但是因为表都是nologging+insert append插入的,所以表在standby上是无法访问的。但是这些表都是临时数据,处理完成后就不需要了,所以删除重建就可以了。
    整个备份和恢复过程,不需要对这些nologing table做额外的操作。

  29. 木匠Charlie
    3 10th, 201102:06

    原理和过程明白了,搭建一个模型测试一下.

    Explore, Invent, Apply. 这个是 Andy Hunt(Pragmatic Programmer) 推荐的学习和工作实践方法. 简单易用.