在今天的商业时代，随着互联网重要性的日益增长，越来越多的应用需要全天候在线，一个明显的例子就是在线商城，如淘宝，许多公司希望他们的在线商城可以7*24小时365天全时在线，可以为来自全球不同地区不同时区的用户提供一直可用的商品浏览和购买。
HA（High availability) 对非面向用户的应用也同样重要，IT部门通常都有应用连接到多个数据源，比如从在线商城统计销售数据到Reporting系统。这类应用的典型特征是任何非意料中的DOWN机时间可能导致大量的损失或者客户。Oracle数据库通常是这类门面系统的关键，所以数据库的可用性对整个生态系统的稳定性有重要影响。
第二个特性是应用的可扩展性。随着业务发展，可能事务量相比之前的规划成倍或者多倍的增长，或者说在短时间内业务出现波动，比如五一大促等，所以要求Oracle数据能够灵活扩展，弹性伸缩，以应对高负载需求。老折Unix系统在可扩展性上较差，过去十年，更多的是用切换到x86-64服务器，使用相对低价的x86服务器组成集群，来承担关键业务应用 ，在可扩展性和灵活性上更具优势。运行于x86上的Oracle RAC是很常用的标准方案，以满足可扩展和高可用的需求。
高可用和可扩展性：
什么是高可用？
如之前讲的在线商城的案例，业务需求促使IT部门提供应用高可用的方案，而数据库作为应用系统的核心，更需要有高可用的方案支持。
在大部分IT组织,SLA用来定义业务部门和IT部门的应用可用性。可以是可用百分比或者是可停机时间。比如是99.99%的可用性，或者是凌晨0:00到4：00可以停机，比如每季度周六停机进行硬件或者软件的维护。
在实现高可用的时候，同时也意味着付出更多的硬件或者软件成本，往往是通过停机造成的损失和投入之间的比较，来达成业务和IT之间的SLA.
许多业务应用由跑在不同网络中的多层应用组成。如web server,application server ,database servers，我们主要关注的是DBA关心的数据库层。
数据库可用性在应用可用性中扮演关键角色，我们使用downtime来表示数据库不可用时间。可能是计划或者非计划停机。非计划停机以存储损坏最为严重，通过RAID1或者RAID10，以及ASM DISK GROUP来做冗余。Recovery methods聚焦于通过数据库还原或者闪回（flashback)或者切换到dataguard 的standby database.
服务故障通常是硬件或者软件故障。
数据库可扩展性：
数据库扩展是指在业务负载增加的时候，如何通过增加更多计算、存储和网络设备来增加数据库吞吐量并且减少数据库反应时间。
可以通过oracle em或者 aws报告来分析性能瓶颈。如果是磁盘IOPS的影响，可以通过ASM STRIPPING或者io load balance on disk dirves.
如果是CPU性能不满足要求，可以有水平和垂直两种方式。水平则是增加更多服务。
如果更低的事务延迟要求，则推荐使用scale-up的方式。水平扩展相对成本更低，因为支持更多CPU或者内存的硬件成本会更高。而scale-out也需要RAC的license。
RAC解决以下两个问题，使多个节点就像是一台服务器：
多个节点共用一个数据库时，如何确保数据一致性。
如何同步不同节点以达到最佳性能。
CACHE FUSION技术管理多个节点上的缓存一致性，并为应用提供一个一致性的数据库系统镜像（database system image ），不管应用是连的哪一个节点。