nva*_*lik 6 oracle hardware infrastructure
我们正处于设置 Oracle 10gR2 生产环境的规划阶段。我们的预算使我们能够购买 Oracle DB 标准版的 2 个处理器许可。我们对 Oracle 的经验很少，所以我会尊重使用过它的任何人。我们正在尝试决定是否应该在 RAC 配置中设置单个双四核机箱或 2 个单独的四核机箱。
我们的数据库现在大约 60 GB，在我们的高峰期，我们将有多达 150 个并发用户。大多数大事都是在晚上通过批处理完成的。
我的直觉告诉我，在 RAC 配置中拥有 2 个盒子并不是一件坏事，因为它提供了真正的硬件故障转移解决方案。通过 iSCSI 存储在 SAN 上的共享 LUN 中的数据库。另外，如果我们需要增加容量，如果我们添加额外的许可证或 RAM，我们已经有可以使用额外 proc 升级的盒子（我假设停机时间为零，因为它是在 RAC 配置中设置的）。
RAC 是否有任何性能损失？它会增加额外的延迟吗？让双处理器盒运行这些系统真的有什么好处吗？如果我们使用特殊硬件构建 Oracle 盒子：硬件 iSCSI 卡、TOE NIC，这些盒子会坚固吗？我们正在 64 位 Windows 上部署。
那你会怎么做？一盒还是两盒？
如果可能，请保持简单。对于大多数数据库应用程序来说，一个盒子比许多盒子要好，除非你有特定的原因——比如性能。
硬件故障导致停机的可能性比由于配置错误而导致的故障的可能性要小得多。更简单的配置通常会因故障模式更少而获得回报。您可能会发现在实践中您实际上获得了一个更可靠的系统，只需一台服务器和备用机器上的一个简单的复制数据库。
不要寻求比您真正需要的更严格的 SLA，也不要构建具有额外复杂性的系统来实现软件、操作和硬件的所有方面都不支持的 SLA。
对“五个九”可靠性的看法略有不同。
毫无疑问，您的供应商会为其产品提供一些令人印象深刻的可靠性统计数据。作为一个计数器，这里有一个“九”，将各种级别的 SLA 与在实践中实现它们的实际需要相关联：
两个 9 (99%) 相当于 24 小时 DR 周期，并且可能与数据仓库系统等应用程序相关，其中系统不直接支持操作流程。此服务级别可通过从备份恢复系统来实现。
三个 9 (99.9%) 相当于一个 4 小时的 DR 窗口，这实际上是大多数业务应用程序所需要的。这种类型的 DR 策略可以通过简单的日志传送复制和备用服务器来实现。通常，这种架构的简单性意味着它具有相对较少的基于配置的故障模式，并且在实践中实现了相当好的可靠性。有很多两层 4GL 应用程序使用这种类型的配置实现了数月或数年的连续正常运行时间的实例。
四个 9 (99.99%) 可以看作是几分钟的 DR 窗口，并且需要热备用或热故障转移架构。在实践中实现这种类型的 SLA 非常困难，通常需要为其设计的软件。具有讽刺意味的是，由于配置错误或变更管理失误，集群 N 层架构的额外复杂性打开了更广泛的故障模式。
应该注意的是，配置错误和糟糕的变更管理是导致数据中心运营计划外停机的最大原因，并且比服务器上的硬件故障更有可能导致计划外停机。
5 个 9 (99.999%) 每年只需要不超过几秒钟的计划外停机时间。这种类型的 SLA 将您置于专为容错而构建的硬件和软件领域。实施这种类型的 SLA 成本高昂，需要专用平台（例如大型机）和具有大多数公司内部不具备的专业技能的人员。
大多数声称 99.999% SLA 的人都是狗屎，qv微软、埃森哲和伦敦证券交易所。
我会仔细考虑两件事：
1) 10gR2 支持已经开始脱离维护悬崖。大约一年后，获取补丁将变得非常昂贵，并且 Oracle 已经表示最后一个公共补丁将于 2010 年夏季发布。您有什么理由不使用版本 11 来构建新服务器？
2) RAC/Data Guard 的设置和维护实际上相当痛苦。它不仅需要企业许可证（比标准许可证贵得多），您的服务器操作系统也必须是企业版并在 Windows 集群中配置。
就个人而言，如果您可以容忍短暂的停机时间/潜在的数据丢失，那么使用单个盒子会更好，最好有一个可以启动的“备用”服务器。这些只是我的观点，我确信它们可能会引起争议，但实际上，具有 150 个峰值用户的 60GB DB 已经不再那么大了。双四核机箱的扩展性也可能比 RAC 配置更好，当然，如果您将双倍的 RAM 放入单个机箱中的话。