数据仓库环境，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可以考虑推广我们的解决方案。