数据仓库已经成为紧急任务系统，它能帮助行政人员进行日常决策。在这个月的专栏里，BI专家Wayne Eckerson就如何有效地保护你的数据仓库提出了具体建议。

　　你最后一次回顾和测试数据仓库灾难恢复计划是在什么时候？你有数据仓库灾难恢复计划吗？虽然自然和地理政治概念上的灾难——包括龙卷风、雷暴天气以及油价上涨——正逐步增多，他们还不是你商业智能环境（BI）的最大的威胁。据Information Age调查，英国某主要的准们为主管编辑的杂志表示大多数的IT行政人员都相信对IT操作持续性的造成最大威胁是内部系统故障（65%）和病毒（45%）。同时，自然灾难占32% 能量和运输损耗占33%。

　　时代变了

　　十年前根本就没有必要为数据仓库制定恢复计划、报表和它们支持的应用程序。当时，绝大多数数据仓库每月都被装在半打或者开源系统上。大多数负载量都很小，即使是最大的数据仓库都比一些兆字节大小要小得多。所以大多数数据仓储团队都没有灾难恢复计划一点都不感到奇怪，更不用说备份策略了。一般来说如果数据仓库被损坏，你可以简单对它整体做一下更新。

　　今天，大多数数据仓库已经成为了紧急任务执行系统。一些数据仓库在实时的基础上捕捉业务并对它进行了更新，并且这些数据仓库支持许多业务运营应用程序。如果系统脱机几个小时的话。业务运营程序用户就对制定日常决策的数据仓储信息非常依赖所以这些程序对数据仓储主管的要求也特别苛刻。再者，作为决策程序，数据仓库可以在灾难发生时帮助企业或机构作出最理想的反应。数据仓库报表能够帮助行政人员解决如何区分活动顺序、进行资源配置以及分配人员处理紧急事务。

　　你的公司将操作所需的业务过程和应用程序区分开了么？如果数据仓库应予以有先考虑的话，那么数据抽取、转换和装载过程（ETL）呢？ETL可以组装数据仓库以及绘制、分发报表的BI服务器。这条链很脆弱，数据仓库环境很复杂，包含多个系统和应用程序、并且和内部、外部系统相互依赖，所以数据仓库的环境不能在它所有元件都联机之前完全恢复。

　　你最后一次真正测试数据仓库恢复计划是什么时候？如果你在数据库故障中测试恢复，那你还只完成了一部分。你还需要恢复客户、服务器、网络、存储、应用程序和数据库，对恢复环境进行完全模拟。如果你是在一年之前进行的测试，那这就是测试你的恢复计划是否过期的好机会。由于数据仓库是个能更新的系统，所以它会经常回答业务人员提出的新问题。因此查询、报表、元数据、ETL workflow等也许从你上次测试开始就已经改变了。再次，业务人员在这种紧急情况下问的问题和他们在平时问得问题可能会完全不一样。

　　快速恢复的关键不仅仅是灵活多余的系统的，还有人。在灾难发生的过程中一定很混乱。许多主要的人员也许不在或不能登陆操作系统。因此你不仅需要系统的冗余量而且还需要进行分配。你的团队应该锻炼具备适应各种紧急情况的能力并且还要准备扮演多个角色。

　　准备

　　灾难恢复重视质量好、最新的、端到端的元数据，一些公司已经成功安装了这些数据。元数据至关重要的，它影响评估——当一些数据在开元系统里发生变化时，你要知道它将怎样在终端用户的报表里影响系统里的其它元件。在紧急情况下，数据仓储团队的能力可能会受到影响，达不到恢复时间的目标（如恢复业务功能）、危急数据点（需要及时恢复数据的点）以及恢复点对象（恢复数据的时间）而不需要登录动态综合元数据管理系统。
　
　　数据当然是数据仓储环境的心腹，所以企业必须确保数据不会出现能量故障、储运损耗或其它灾难。许多企业都作了低成本的磁带备份并且进行运距离储运。虽然从磁带中恢复数据仓库要花很长的时间，这些数据都是历史性并且在紧急情况中没有很高的价值。为了保护更多更新的信息，公司还应该在数据通过ETL过程中对数据进行进行复制和快照然后把它们储存在灾难恢复系统里的磁盘上，这种方法能在一段时间（通常是几天或几周）后将数据存档或删除。大多数数据仓储团队都了解处理数据仓储信息的生命周期的必要性。

　　遗憾的是，这些团队通常不参加两次灾难恢复。最理想的状态就是，联机备份系统远距离保存，因此数据中心并不能同时破坏原来的系统以及备份的系统（这样做的费用明显要高得多并需要高速网络连接）。如果远程系统出现故障，他们同样没有对备份文件进行备份。许多企业没有预料到灾难会持续许多天。如果在Katrina的激发下一些业务仍然不能完全恢复，我们就需要延长对灾难预计的时间。最后，许多远程备份系统不能保护公司免遭病毒攻击，而且这些病毒还在系统内部进行繁殖。远程系统应该有一扇内置门，这扇门能将真正的病毒繁殖时间能的延长几个小时从而保护软件免遭攻击。

　　总结

　　在这种郁闷的环境中提出意见并不是很有趣，并且没有人想在转移那些可能永远不会发生的东西上面花钱。但是似乎对我来说，我们目睹了许多由环境退化和政治两极分化引起的危险期、灾难期和地理政治的紧张期。一种比较好的老式的灾难促使我们中断灾难恢复计划。这样做比等待现实灾难测试来我们的恢复计划效果要好得多。