我们正在寻找一个新环境来运行在 SUSE 上运行的 Oracle 数据库（可能迁移到 RedHat）。我们的数据库大约有 100GB，在当前硬件（x86_64）上性能良好，为其分配了大约 6GB 的内存。但是，我们的业务正在快速增长，不久将需要更高的性能。
考虑到 Oracle 许可证的成本，我们希望通过选择最合适的 CPU 来运行该软件，从而最大限度地提高每个许可证的价值。
问题是：
选择 Itanium 或 Sparc 硬件是否有实质性优势？是否存在缺点？是否存在一个更好的扩展点？
Itanium 的长期支持选项有哪些？鉴于 x86 的主导地位，长期坚持使用 x86 是否更安全？
平均而言，在 Itanium 或 Sparc 上实施 Oracle 数据库比在 x86_64 上实施性能优势如何？这到底是个问题还是其他因素（IO/RAM）会先达到上限？
如果有人可以向我指出一些关于平台之间比较的可靠文档，这些文档可以提供何时选择哪个平台的良好案例分析，我会非常乐意接受它作为答案。
编辑：- 添加 Sparc 作为选项，因为之前没有考虑过它，但是最近 Oracle 收购 Sun 似乎非常相关。
答案1
这不是您要求的可靠文件，但它可能有助于决策过程：
供应商（硬件和软件）正在全面停止对 Itanium 的支持 — 您可能很快就会很难从 HP 以外的任何供应商处购买 Itanium 套件。话虽如此，RedHat 不会在没有提前通知的情况下单方面放弃对某个平台的支持。
对我来说，最大的问题是未来的迁移 - 如果 Itanium 继续按照目前的趋势发展，那么几年后您可能会遇到更换或升级服务器的问题（除非英特尔同时开始在 x86_64 处理器上支持 IA64 指令集）。
Itanium 架构是否比 x86_64 有所改进，很大程度上取决于您的工作负载性质，但对于许多数据库应用程序，在架构差异变得特别明显之前，您会遇到 I/O 瓶颈和 RAM 不足（显然，我不知道这是否适用于您的情况）。由于 x86_64 的开发非常积极，根据应用程序的不同，差异将迅速接近于零。
答案2
人们曾经为了性能而购买 Itanium，但那个时代已经过去了。
直到非常最近，人们购买 Itanium 是因为它的可靠性、可用性和可服务性 (RAS) 特性 - 而英特尔 Xeon 75xx 系列的推出意味着，对于除极少数服务器购买者以外的所有人来说，这个时代也已经过去了。
正如其他人提到的那样，操作系统供应商正在放弃 Itanium - Itanium 的最大支持者 HP 正在退出该平台（但不要指望他们的产品经理会承认这一点）。
除了极少数老用户外，对于大多数用户来说，安腾的时代已经过去了。
无论价格是否高昂，Oracle 都是以量为导向的企业，因此虽然他们将始终立足于高性能/低量领域，但他们更专注于 x86/x64 市场。当然，他们将在未来几年内维护越来越少的处理器代码，想想维护合同裕度吧！但他们对这些次要平台的关注将会减弱，将更多的研发投资投入到 SPARC 也不符合 Oracle 的利益。
业务关键型数据库服务器的未来很明确，只有两条路可走；商用 x64（Xeon 56xx 系列和 AMD Magny-Cours 是当今的 CPU），占据 97-99% 的市场份额，集群将以相对较低的价格提供“五个九”的性能；而 Xeon 75xx 系列，则“零个九”是唯一的选择 - 除了大型机级别的机器，其他都是如此将要消失。
答案3
我猜测 Itanium 对于数据库系统来说会比 x64 (x86-64) 更快，但是正如 warren 和 Mo 之前所说，未来 Itanium 的支持看起来并不乐观。
Oracle 可能希望您尽快采用 SPARC。
因此，我建议在 x64 和 SPARC 之间做出决定，而不是在任何选项和 Itanium 之间做出决定。
微软表示，Windows Server 2008 R2 将是支持 Itanium 的最后一个 Windows 版本，但将持续支持到 2018 年：
然而，我记得 Windows 在 1997 年突然放弃了对 MIPS 和 PowerPC 的支持。
答案4
使用什么的关键取决于您的系统占用空间和要求，当然还有您的内部技能。
一般来说，从 Oracle 技术架构师/dba 的角度来看，您将面临以下问题：
- 我愿意在支持上投入多少开销？
在非 Oracle 平台上，您的反应时间自然会更差，特别是 IBM Pseries 以及 HP Itanium（由于历史原因）
- 我需要提供什么服务以及我想要使用哪些技术？
一般来说，您不应该混合具有相同用途的东西，例如 RAC 和虚拟化，因为这会增加层数并最终增加成本。
如今，您可以使用 x86-64 上的 Oracle VM (Xen) 和 Oracle Dataguard（最终将提供 Active Dataguard Option）等工具来做很多事情。保持简单和专注
对于大多数公司来说，RAC 管理起来太复杂，因为它大多没有得到正确实施。此外，它只能保护您免受主机故障的影响 => 您仍然需要处理共享存储。
由于我过去 10 年看到的大多数 RAC 安装都是基于“传统观点”，它们主要是 2 个节点集群。原因很简单：许可证成本/习惯
因此，更简单、更有价值的组合是使用 Oracle VM 实现 HA，它使您甚至可以在维护窗口中实时迁移主机，再加上 Oracle Dataguard 以应对站点故障。使用 Dataguard 时，您可以将备份卸载到备用站点，以免打扰用户。
这只是一个例子，它适用于 11g OLTP 数据库，如果您更关心可用性而不是性能，它也可以应用于 DW 数据库。
阅读 Oracle 的概念指南肯定会为您找到适合您的解决方案。
在规划虚拟化技术时，您还应考虑不要将太多东西整合到太少的机器中。您不会希望出现这样的情况：您将所有东西整合到 2 台大型企业级机器中，然后突然有一台机器坏了，导致您损失了 50% 的总容量。最好多使用一些服务器，而不是使用较小的服务器，原因如下：
IBM、HP、SUN 大型机上的按需扩容乍一听不错，但几年后你会发现，如果你需要购买旧的 RAM 模块，那么成本会相当昂贵
在某种程度上，你仍然需要关闭这些盒子并进行物理升级
如果一台服务器确实出现技术问题，你还有其他服务器，你可以有更多时间更换故障服务器，同时减少对性能和客户的影响
正如所说，作为 dba，您通常必须处理更多糟糕的应用程序错误、I/O 争用、网络问题。对于 I/O 争用，无论您使用 4.7Ghz IBM Power 6 还是 Intel 1.6 Ghz Itanium 进行 I/O 等待，都没有太大区别。您不能等待得更快。在这种情况下，如果您真的无法通过重新设计/调整应用程序来处理热数据块，您宁愿投资 PCI-E SSD。