高可用性和减少计划内(甚至是计划外)停机时间是数据库系统的目标，在需要24*7无障碍运行的环境中尤其如此。让数据库停机进行维护或者甚至是硬件问题导致的停机都是不能接受的，因为这些故障可以给企业带来重大损失。幸运的是，我们有Oracle 11g来扭转局面，它具有高可用性特性，例如：真正应用集群(RAC)，自动存储管理(ASM)和数据卫士(Data Guard)。在设计数据库环境的架构时，真正应用集群和数据卫士的结合会提供数据库实例的失败转移(failover)，甚至是灾难恢复到离线的备用服务器。在规划配置和组合时，你必须从成本效益方面考虑来提供给企业需要的可用性。审查这些特性并了解怎样实施这些特性会帮助你提供可靠的，可扩展的，稳定的环境，可以处理硬件设备的损失或者在发生意外事件时可以恢复。我们还不能忘了Oracle 11g数据库的维护需求。通过给集群中的节点一个一个地打补丁，我们可以保证在打补丁时至少有一台节点是可用的，甚至计划内的维护窗口现在也变得更小了。

　　定义高可用性

　　高可用性对企业来说意味着什么呢?可以承受的风险级别是什么呢?可以接受丢失多少数据呢?当前存在备份或者报表方面的问题吗?所有这些问题都需要在开始规划需要的组件功能时提出来。你可能断定绝对不能忍受数据丢失，或者，也可能觉得应用程序停个一两天也没啥大问题。

　　同时，这样做还有助于看清会发生什么样的问题，并给这些问题构建容错机制。例如：常见的意外事件是硬件故障，比如磁盘或者服务器故障;人为错误，比如误删了一个数据文件或者做了错误的修改;也有网络或站点故障。那么，加上列举的这些情况，还有计划内的停机需求：打补丁，数据库修改和迁移，应用程序修改(可能包括表和数据库对象的修改和升级)。应该寻找系统中存在单点故障的区域，然后采取相应的解决方案来开始排除这些区域。

　　本文只是涉及了构建高可用环境所必须的几个领域：真正应用集群RAC，自动存储管理ASM和数据卫士Data Guard。理解这些组件，并研究Oracle的其他功能(比如：闪回查询，事务和数据库，闪回恢复区，数据恢复助手和安全备份)会帮助使环境实现和企业在可用性方面的需求得到同步。

　　因此，在了解应用和企业需求时，如果存在计划内停机维护，可以容忍打补丁产生的停机时间，那么滚动补丁就不太需要关注。相反，通过闪回技术，或者通过在一台类似生产服务器测试应用程序变化的能力，测试应用程序修改和补丁的解决方案可能是可行的。如果企业不允许停机，或者定期维护窗口，而且你知道每停机一分钟就会损失公司大量的金钱，你可以采用该解决方案组件的组合：滚动补丁，预防硬件故障引起的停机，通过集群和数据卫士实现故障时切换服务器。

　　为了设计一个满足预算限制和业务需要的解决方案架构会发生一些讨论和规划，要与业务团队一起工作，要对可用的不同选择有一定理解。本章的其它部分会让你对这些领域中的一部分内容以及如何实施它们有所理解。