存档

Archive by

众所周知,我在微博上开辟了一个AskHelloDBA专栏回答各种数据库问题,分享数据库最佳实践和研究成果。但是我一个人的能力有限,而我周围有很多技术牛人,所以我想打造一个数据库技术问答社区,集合社区的力量解答大家碰到的各种问题,大家可以互相交流技术,讨论人生和理想。
AskHelloDBA有别于传统的技术论坛,我们将其定义为技术问答社区,所以我们的定位更高端和小众一些,希望通过问答的形式,形成一个互助的平台,在这个平台上,大家互相交流技术,共同进步提高。
欢迎大家访问AskHelloDBA(askhellodba.com)!交流数据库技术,讨论DBA生涯!希望大家多多支持!
–EOF–

4 28th, 2012 | 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 27th, 2011 | Filed under 大话技术
标签:

当初年少无知,对残酷的社会现实缺乏了解,导致HelloDBA在国内注册域名,这几年吃尽了苦头,被迫做了域名备案也就算了,而且多次申请转移域名不成功,因为怕麻烦就选择了续费。
今年,实在忍无可忍,投诉到ICANN,注册商终于打来电话,要求提供资料,然后又很无耻的在验证身份这个环节做文章,总之就是故意阻挠域名转移,耗费精力无数,实在不愿意再和这个注册商打交道了。
宁为玉碎不为瓦全,我决定放弃HelloDBA.net这个域名,在Godaddy上新申请了一个HelloDB.net的域名,坚决不再给这个无耻的注册商一分钱,我再次强烈呼吁大家不要在国内的任何一家域名注册服务商注册域名,也不要使用他们的任何服务。
近期我将把博客迁移到新的域名下,原有的域名我会继续投诉到ICANN,抗争到底!
–EOF–
经过再三考虑,最终将新的域名修改HelloDB.net,希望大家继续支持!

1 10th, 2011 | Filed under 大话技术

终于有了自己的空间,目前还在测试阶段,希望大家多多支持。
–EOF–

4 11th, 2008 | Filed under IT江湖
标签: