为你的数据仓库的灾难恢复计划做最后一次审查和测试的时间是什么时候？对于你的数据仓库，你有过灾难恢复计划吗？

　　尽管自然和地理政治灾害——包括龙卷风、雷暴和石油价格的上涨——在上升，但对于你的商业智能（BI）环境来说，它们不是最大的威胁。根据对于业务主管来说具有领导性的一家英国杂志信息时代（Information Age）的研究表明，大多数IT业务主管认为，影响他们IT运维连续性的最大威胁是内部系统故障（65％）和病毒（45％）。与此同时，已经登记的自然灾害占32％，电力和通讯中断占33％。

　　时代变了

　　十年前，对于数据仓库和它们支撑的报表与应用，很少需要建立灾难恢复计划。在当时，绝大多数的数据仓库每月从半打左右的源系统被批量装载。大多数负载相当小，甚至最大的数据仓库小于几百GB的规模。毫不奇怪，大多数数据仓库团队没有灾难恢复计划，更不用说备份策略。共同的想法是，如果数据仓库崩溃，可以简单地从源系统刷新整个数据仓库，一切将恢复在线。

　　今天，大多数数据仓库已成为关键任务系统。现在，许多数据仓库实时捕捉和更新事务，并支持数十个运行业务的应用。现在业务用户越来越依赖数据仓库信息来做出日常的业务决策，以至于他们叮嘱数据仓库管理员不要让系统发生甚至几个小时的脱机。此外，作为决策引擎，当灾难袭来时，数据仓库可以帮助企业以最佳的方式做出响应。数据仓库报表可以帮助管理人员计算出如何划分活动的优先级、分配资源和重新分配人手以应付紧急情况。十年前，数据仓库可能是灾难发生后最后一个恢复的系统；今天，它应该是在紧急情况下第一个恢复在线的系统。

　　如何保护？

　　研究显示，大多数组织对于他们的IT系统的弹性都显得很有信心。大多数组织都有灾难恢复计划以保障业务系统在短期和长期不至于中断。也许灾难恢复计划甚至包括数据仓库、它运行的服务器、它支持的报表和应用。由于现在许多数据仓库都运行在由IT策略管理的公司内部数据中心，IT策略包括业务连续性和灾难恢复计划，在某种程度上，这是一个不错的选择，你的组织已经为它的数据仓库资产加了保险。

　　不幸的是，大多数灾难恢复计划在保护组织免于成本上的损失方面，还做的远远不够。灾难恢复计划是保险措施，大多数公司只保证他们能够负担得起，而不考虑他们需要什么。

　　你的组织对于它的运转至关重要的业务流程和应用已经划分优先级了吗？如果数据仓库是最高优先级，那么填充数据仓库的提取、转换和负载（ETL）引擎以及生成和分发关键报表的BI服务器呢？ 一个链条的强度取决于其最薄弱的环节，数据仓库是由多个系统、应用和相互依赖的内部和外部系统组成的一个复杂的环境。只有数据仓库的每个组件恢复在线，整个数据仓库环境才能完全恢复。

　　为数据仓库的灾难恢复计划做最后一次测试的时间是什么时候？如果你进行数据库失效恢复的实践，你仅仅完成了测试的一部分。你需要恢复客户端、服务器、网络、存储、应用程序和数据库以完整地模拟一次恢复场景。如果你一年前进行了测试，那么它是一个很好的机会，因为你的计划已经过时了。由于数据仓库是一个适应系统，它需要不断地变化以回答业务人员问的新问题。因此，自从你上次测试以来，查询、报表、元数据、ETL工作流程和聚合等等可能已经发生了变化。此外，在紧急情况下，业务人员问的问题可能和正常情况下问的问题不同。

　　弹性的关键不只是灵活性、冗余系统，它也包括人。灾难发生期间，有很多混乱和困惑。许多关键的人员可能不在场，或者无法工作或访问系统。因此，不仅在你的系统中需要冗余，而且在你的人员安排上也需要冗余。应该培训你的团队，在各种紧急情况下如何应对，并随时准备根据需要扮演多种角色。