本文的受众是对采用IBM BladeCenter® H、Oracle Database®10g Real Application Cluster(RAC)和Linux®操作系统，构建灵活数据库基础架构感兴趣的客户。
新IBM BladeCenter H提高了BladeCenter系列的性能，并为其增添了很多新功能，而且还与BladeCenter系列产品保持兼容。凭借简洁的智能设计，IBM BladeCenter H集存储、网络、服务器、管理和应用于一身。
Oracle Database 10g RAC旨在帮助您在Linux上构建灵活、高性能、高度可用的集群数据库解决方案。通过将这些集群连接到具有故障恢复能力的光纤通道存储区域网络（SAN），能够为被成为"灵活数据库集群（FDC）"的计算基础架构奠定基础。
FDC 集群是一系列测试的目标，这些测试深入了解的不是1个应用而是3个应用的运行和管理情况。本白皮书中将提供这些测试结果。
简介
IBM和PolyServe联手打造了一个数据库集群，它采用了一个运行Red Hat Linux的BladeCenter H，并将其连接到可配置超过84个物理硬盘的SAN上（参见图1）。在PolyServe Matrix Server上安装Oracle10g RAC可以简化RAC的部署和管理，并支持其关键特性。整个系统在一个标准的42U机架中完成全部配置和部署。
FDC集群是一系列测试的目标，这些测试深入了解了不是1个而是3个独立应用的运行和管理。该测试结果证明灵活数据库集群提供了：
- l 将多个数据库和相关的应用整整合部署在一个单一、易于管理的集群环境中的方法；
Page 2:
- l 通过PolyServe Matrix Server集群的文件系统，简化大型数据库集群管理；
- l 动态的"随需应变的可扩展性"架构，支持接近线性的加速度运行应用–仅有很少的中断或根本无中断；
- l 按照需求动态重新分配服务器资源，从而能够迅速、轻松地将处理能力转移到最需要的地方；
- l 一个自治的全天候运行环境，拥有迅速、甚至即时自我恢复能力，且对性能影响很小或者根本没有影响（因此，也可以提高利用率）；
- l 通过提高可管理性、可扩展性、延伸性、可用性和资产利用率，降低总体拥有成本（TCO）
灵活数据库集群的概念
整合的经济性
构建在Linux上运行Oracle10g RAC的集群，其成本效益经过验证也非常可观。在Linux上部署Oracle的通用方法就是为每个数据库应用创建一个小型集群。但是，正如在一个大型SMP系统上整合应用是一种经过验证的节约成本行为，在大型集群上整合应用还能提供更大优势，特别是对于向外扩展的应用和中间件（例如RAC等）。使用RAC创建灵活数据库集群可以产生整合收益，包括减少管理开销和提高灵活性。
灵活数据库集群组件
灵活数据库集群需要灵活的架构，例如IBM BladeCenter、PolyServe Matrix Server软件和Oracle Database 10g RAC等。这些组件相互补充，共同创建一个功能强大的支持多种应用的平台。
IBM BladeCenter H架构
支持灵活数据库集群概念验证所需的基本计算基础架构，选择能够展示灵活性和管理能力的硬件平台至关重要。而IBM BladeCenter H即可提供这两种属性。
IBM BladeCenter H创新的9U机柜可以容纳多达14个热插拔、基于双槽位AMD皓龙TM处理器的刀片服务器。该机柜还集成了2至7层千兆以太网交换机、SAN交换和集中管理工具等主要基础架构组件。
该机柜还设计提供了许多资源，如电源、交换、管理和吹风机等模，并在所有刀片服务器中共享这些资源。该机柜可以为所有的模块提供高速I/O功能，支持汇聚I/O吞吐量，并减少数据中心中所需的线缆数量。BladeCenter管理模块方便从远程对机箱内的组件进行访问控制。
IBM BladeCenter H支持数据中心减少"服务器蔓延"，显著降低其分布式IT基础架构的复杂度。这些刀片服务器还提供了更出色的管理软件，而且与同水平机架优化解决方案相比，它们需要的空间更小，因而具有更强的扩展能力。
Page 3:
灵活数据库集群概念验证需要将大量高可用性的磁盘存储器连接到BladeCenter。该存储子系统是围绕IBM TotalStorage® DS4500存储服务器设计的。DS4500是一个RAID存储子系统，它包含光纤通道接口，可以连接主机系统和磁盘机箱。凭借其2Gbps控制器和高可用性设计，DS4500提供了支持FDC概念验证所必须吞吐率。
通过采用完全冗余的交换光纤通道SAN和由PolyServe Matrix Server提供的多通道I/O特性，显著降低了在FDC测试系统的单一故障点。
如需有关IBM BladeCenter H的更多信息，请访问IBM网站：
http://www-1.ibm.com/servers/eserver/bladecenter/。
PolyServe Matrix Server
PolyServe Matrix Server支持多个低成本、基于Linux或Windows 操作系统的服务器，形成一个单一、易于使用且具有高可用性的系统。Matrix Server包括一个完全对称的集群文件系统，支持可扩展的数据共享和具有高可用性的服务，从而提高系统的正常运行时间和利用率，以及集群和存储系统管理功能，将服务器和存储系统作为一个整体进行管理。通过Matrix Server，客户在扩展应用和部署RAC等中间件方面，可以获得无与伦比的可扩展性、可用性和可管理性。
Matrix Server集群文件系统组件即可用于通用目的，也可以优化用于Oracle。在FDC分析方面，它可以提供以下优势：
- l 改进的应用管理和共享的Oracle Home；
- l 在应用间进行简单、受限的数据库移动（例如，无需访问网络，即可将可传输表空间从OLTP移动到DSS）；
- l 支持External Tables和Parallel Query的大型数据库负载；
- l 服务器的动态添加或重新分配，可以改进特定工作负载的吞吐率和响应时间。
"共享的Oracle Home"功能是灵活数据库集群架构的一个关键要素。Matrix Server的集群文件系统组件支持为Oracle Home创建单独的目录。Oracle只能安装一次–在Matrix Server集群文件系统上安装为单一节点。随后，通过使用Oracle的MetaLink网站提供的方法，即可将单独目录的Oracle Home"转换"为一个共享的Oracle Home，允许将所有可执行文件都存储在同一个地方，使得集群的所有节点都能够使用相同的可执行文件。配置文件也将存储在Matrix Server集群文件系统中，且可以从该集群中的任何节点对其进行编辑。
当然，除Oracle10g RAC之外，Matrix Server还能够为与Oracle共同运行（或在独立的集群中运行）的应用和中间件提供"共享主页"，并使所有这些应用和中间件服务具有高可用性。
通过共享安装Oracle10g RAC和应用，可以显著简化增加替代节点的工作。唯一需要在增加或替换的节点上安装的软件是操作系统，和易于安装的Matrix Server RPM。一旦一个节点连接到SAN，则在5分钟之内该节点即可加入该集群。如果需要在替代或增加节点的专用驱动器上安装Oracle，则节点加入Oracle10g RAC集群的时间将在45到60分钟之间。
Page 4:
Matrix Server提供的共享Oracle Home和快速补丁方法等功能，可以显著简化RAC集群对于单个或多个Oracle工作负载的部署和管理，并同时降低存储需求。
在Oracle10g RAC环境中，Matrix Server还能够提供以下优势：
- l 通过Matrix Server，所有Oracle文件都可以存储在文件系统中。包括但不限于：Oracle Cluster Management仲裁磁盘、srvconfig文件、控制文件、在线和归档重做日志、数据文件、imp/exp文件、SQL*Loader源文件和External Tables；
- l Matrix Server提供集群范围内的统一设备命名，可以减少"设备滑移（device slippage）"和相关问题。设备滑移可以导致集群管理复杂化，且若处理不当，还有可能破坏数据。
- l Matrix Server支持Oracle10g RAC环境中的Oracle Managed Files特性。通过Oracle Managed Files，数据库自身即可以按照需求动态地创建和扩展表空间，简化了数据库管理。
- l Matrix Server支持在标准的文件系统文件中存储数据库表空间，并支持采用标准备份工具和实用程序进行访问。这使得可以在Oracle数据库表中使用标准的第三方备份工具。
- l Matrix Server支持Oracle的External Table特性，允许所有集群节点都能够访问在平面文件中存储的数据；
- l Matrix Server允许Extract/Transform/Load (ETL)进程在集群中的所有节点间并行运行。
- l 通过提供系统范围内的健康情况和针对应用、中间件、服务器、网络和文件系统的故障切换，Matrix Server扩展了Oracle的可用性能力。
- l Matrix Server还通过集成的多通道I/O支持从服务器到SAN的多条光纤通道连接，和SAN中的多次交换，提高了可用性。在这种配置中，即使出现多个线缆、主机总线适配器（HBA）或交换故障，所有的集群节点依然能够继续运行。
- l Matrix Server集成了结构访问控制机制，可以确保只有行使正确职责的集群成员能够访问共享的数据。
如需有关PolyServe Matrix Server对于Oracle10g RAC的价值主张的更多信息，请访问：
http://www.polyserve.com/ibm/ibm_oracle.html或者
http://www.polyserve.com/products_literature.html。
Matrix Server Oracle Disk Manager
PolyServe Matrix Server还提供了一个Oracle Disk Manager (ODM)接口的实施。Matrix Server ODM实施通过集群范围内的文件访问密钥，改进了数据文件的完整性，并支持Oracle10g在直接I/O安装的文件系统（用于存储数据文件和其他数据库文件，例如重做日志）上使用异步I/O。Matrix Server ODM的监控功能是FDC架构部署中的一个重要优势。
Matrix Server ODM的I/O统计数据包提供集群范围级（汇聚所有数据库）、数据库全局级、实例级或节点级的I/O性能信息。因为Matrix Server ODM了解Oracle文件、进程和I/O类型，所以，它能够提供针对Parallel Query Option (PQO)、Log Writer和Database Writer等关键Oracle"子系统"的专门报表。
Page 5:
Oracle Database 10g RAC
Oracle10g RAC既可以用于大型灵活集群，也可以用于将多个Oracle工作负载（或集群）整合形成的单一集群。Oracle10g RAC功能包括：
- l 可用性–Oracle10g RAC可以实现故障恢复，并在某个服务器停机的情况下，支持节点加入应用。
- l 可扩展性–部分归功于Oracle Cache Fusion技术，应用可以顺利扩展。
- l 灵活性–多个Oracle数据库应用能够在单一集群中共享SAN，从而降低管理开销，并使节点可以从一个应用重新配置到另一个应用。
Page 6:
概念验证
图1展示了灵活数据库集群测试系统的组件。整个环境是在一个标准的42U机架内配置并部署的。
图1. 灵活数据库集群系统组件
系统概述
IBM BladeCenter H机柜配置如下：
- l 服务器节点：4台采用AMD皓龙处理器的LS20 IBM BladeCenter刀片服务器。这些服务器基于双路、支持SMP的皓龙TM处理器，且具有高度可扩展性。每个LS20可支持高达2.80GHz的单核处理器和高达2.40GHz的双核处理器。AMD皓龙处理器提供一个集成的内存控制器，可以提高带宽并减少延迟。LS20支持64位和32位两种应用，即可顺利迁移到支持64位的应用，又能够利用现有应用的价格和性能。
- l 该服务器架构有助于实现FDC环境的高可用性，当与Matrix Server提供的多通道I/O特性相结合时，还可以建立一个具有最少单点故障的SAN子系统。
- l BladeCenter I/O 模块：4端口的千兆以太网交换模块和2端口的光纤通道交换模块，提供标准的千兆以太网连接，以及到可实现故障恢复的光纤通道SAN的连接。
- l 存储：配备8个EXP700扩展机箱的IBM TotalStorage DS4500存储服务器，可容纳共（84块）36.4GB硬盘。采用了IBM Storage Manager软件配置阵列和磁盘。
BladeCenter H包含一个基于Web的内置GUI，可用于配置和管理任务以及查看系统状态。它还可以远程访问BladeCenter，远程启动和关闭刀片服务器并管理I/O模块。
Page 7:
数据库概述
为了测试灵活数据库集群架构，我们采用Oracle10g Release 2在Matrix Server集群文件系统中创建一个基于ERP计划的数据库。该数据库包含多个支持Order Entry和Order Fulfillment应用的表和索引，以及客户信用活动表。其目标是实现在该系统上运行的进程的真正混合，同时还要能够评估FDC架构的可管理性、性能和可用性。
联机交易处理（OLTP）计划
OLTP计划基于一个订单录入系统，它包含客户、订单、线项目、产品、仓库和信用卡应用表。总共的数据库容量约为1.1 TB。
访问OLTP数据库的应用工作负载为每个节点连接200个会话。测试的节点负载均衡分配。每个用户循环从事一组交易。每个交易结束时，随机确定客户端进程进行短期睡眠，以模仿人工交互。
决策支持系统（DSS）计划
DSS工作负载包括有关客户信用的分析查询。此决策支持所使用的事实表是来自OLTP计划的信用卡活动表，该表拥有20亿行数据，大约占用了整个卡表空间中的75GB。
分析
FDC概念验证的目标是验证FDC架构，并确定在高可用性和"随需应变"的可扩展性等关键领域中的增值。通过该测试得出的关键点如下：
- l IBM BladeCenter H架构和技术为灵活数据库集群提供了一个高可用性的平台；
- l 无需用户中断即可动态、透明地增加容量，从而缩短了工作负载的完成时间；
- l 可扩展性与I/O吞吐率直接相关。通过IBM TotalStorage SAN架构，向阵列中添加磁盘可以解决性能瓶颈。
OLTP工作负载日志分析
在概念验证过程中，我们测量了DS4500存储阵列写缓存对于OLTP吞吐率的影响。
通过Oracle10g，可以在禁用Log Writer I/O的模式下启动数据库实例。虽然不能将此模式用于生产目的¹，但它却是测试存储阵列写缓存功能效果的便捷方法²。Oracle初始化参数为_disable_logging。若该参数设置为"TRUE"，则在日志文件同步事件过程中，服务器进程依然安排Log Writer进程刷新日志，而不是真正发布一个I/O请求，Log Writer只是将刷新标记为完成。通过以这种方式运行服务器，为给定的交易组合建立一个最佳理论值吞吐率基准³。在此基准和正常模式（即，_disable_logging=TRUE）间在吞吐率方面只要存在较大的差距，即证明存在着日志I/O瓶颈。
¹只要该数据库以任何非正常方式关闭，则该数据库都将完全不可恢复。
²TotalStorage管理软件可以启用和禁用写缓存。
³假定其他所有的因素均保持不变。
Page 8:
当然，只有可以呈现大量交易日志的工作负载才能够显示此测试中存在的任何性能差异，所以，指出下列事实至关重要：我们选择用于此测试的工作负载的读写比例大约为65：35，且4个节点每秒平均可以生成大约500个Log Writer I/O。
图2显示了测试结果。TotalStorage阵列中的写缓存技术极为有效，使得吞吐率在正常启用Redo Writer日志和关闭时一样出色。从本质上讲，TotalStorage阵列缓存的作用是为此OLTP工作负载提供了无成本交易日志I/O。
此测试说明的另外一个重点是，PolyServe Cluster Filesystem (CFS)对于交易日志没有产生任何性能影响。若PolyServe CFS采用直接I/O，则不会产生任何额外开销，暴露此开销的最佳方式就是将之与根本不使用I/O的情况相比较。
图文翻译：
OLTP Logging Performance Analysis：OLTP日志性能分析
Logging Disabled：禁用日志
Normal Logging：正常使用日志
Oracle Logging Mode：Orcale日志模式
图2：OLTP吞吐率比较。TotalStorage阵列与禁用重做日志相对比。
高可用性：故障注入测试
该测试证明了Oracle10g RAC处理4个节点之一出现崩溃的能力，以及重新配置一个DSS节点替代已崩溃节点的能力。该测试的要点如下：
- l 无需重新配置应用。
- l 节点的崩溃和替换对于用户是完全透明的。
- l 所有操作是完全动态的。
Page 9:
所有集群架构的真正价值在于，以一种支持Real Application Cluster可用性特性的方式应对系统故障。为了建立PolyServe Database Utility for RAC的适用性，需要进行带有恢复时间选择的故障注入测试。
几乎所有的集群架构都可以以很低的系统利用率水平从故障中恢复。对于真正出色的集群架构的测试，是所有的平台组件（例如，操作系统、集群文件系统等）都能够对某节点故障及时做出响应–即使在极端负载的情况下也是如此。当PolyServe Matrix Server集群中的众多服务器中有一台出现故障时，必须要做的第一件事情就是恢复集群系统文件。虽然集群文件系统是完全记录的，但是恢复必须由依然能够运行的某一个节点进行。若该恢复节点效率低下，则在Oracle能够开始进行内部恢复之前，需要经历长时间的延迟。
为了达到此目的，将该测试设置为使4个RAC节点以服务器的最高利用率水平执行OLTP。图3显示的是一个屏幕截图，显示一台服务器在执行OLTP工作负载达到稳态时的最高使用率。这就是所有节点在准备故障注入测试时的服务器利用率。如图3所示，负载平均值大于13–一台明显超载的服务器。分析集群架构应对故障的能力，再没有比极端负载更好的解决方案了。
图3：进行故障注入测试之前的系统负载
Page 10:
图4为i.sql脚本的输出。在14：30：43这一时刻，正在共有4个RAC实例在运行。
图4：在进行故障注入测试时的RAC实例状态
在图5中，我们执行io.sql脚本以显示在14：23：13Oracle每秒在集群范围内正在执行约9,424个物理I/O。这说明该集群已经达到了一个饱和稳定阶段。
图5：由gv$性能视图报告的集群范围内的物理I/O
Page 11:
通过使用TotalStorage Performance Monitor，我们还可以轻松地获得集群范围内I/O活动的概况图。如图6所示，在14：28：37 I/O速率为每秒9,985次传输。
图6：节点3出现故障前一时刻的TotalStorage Performance Monitor
当工作负载达到稳定状态时，我们随即突然断掉该集群节点3的电源，模拟一次服务器故障。图7显示了来自一个RAC节点的PolyServe Matrix Server matrix.log文件屏幕截图，说明在14：38：24节点3 (192.168.3.23)脱离PolyServe Matrix集群。
时钟旋即开始计时，测量需要花费多长时间才能恢复OLTP处理。
4 TotalStorage Performance Monitor可以在左下角显示监控会话何时开始（14:26:59），并在右下角显示监控会话共运行了多长时间（1分钟38秒）。此屏幕截图于14:28:37截取。
Page 12:
图7：正如PolyServe matrix.log文件中所报告的，该集群的节点3在14:38:24停机
此时，在OLTP处理恢复之前，需要进行3种形式的恢复：
- 1. PolyServe Matrix Server恢复。PolyServe将重放任何可能由于新出现的节点分离而产生问题的日志项。
- 2. Oracle Clusterware 恢复。Oracle 群件必须弄清楚在一个节点"死亡"以后，该集群所处的状态。
指出下列事实非常重要：用于Linux和Windows的Oracle10g Release 2 Real Application Cluster，不再以任何方式与任何主机群件集成。取而代之的是，Oracle群件与主机群件并行运行。由于PolyServe Matrix Server是等级更低的主机群件5，以"内核"模式执行其集群状态代码，所以，它总能确定一个节点是否已经死亡，并远在Oracle Clusterware意识到该节点已经死亡之前将其隔离。因为Oracle Clusterware没有与主机群件集成，所以它必须自己判断出一个节点是否已经死亡。
用于确定某节点是否已死亡的方法取决于节点死亡的方式，但是为了简化，该方法将基于节点与Oracle Cluster Synchronization Services (CSS)主机定期"登记联系"的方案。若某RAC节点已经在一段可调整的时间内没有"登记"了，则Oracle群件可以将其从RAC集群中排除6。错过登记的容限是可调整的，默认值为60秒。在极极端系统负载条件下，若将此参数调得过低可能会导致错误出现，所以必须要保持一个平衡。这就是Oracle Clusterware的架构方式，它与PolyServe Database Utility for Oracle无关。
- 3. Oracle实例恢复。若一个Oracle实例死亡，则其他实例中的一个必须执行交易回滚/前滚，完成重做线程。
由于PolyServe Matrix Server是以完全对称的分布式方法锁定管理，并以联机模式完成某些恢复工作，所以，其全面恢复的部分过程极为简洁。图7说明了PolyServe可以在12秒内（14:38:36）以联机模式开始其恢复工作。联机恢复一旦开始，即可启动Oracle处理。
5 在所有Unix 群件（例如HACMP）上的Oracle10gR2都遵循此同一个模式。
6 Oracle以通知服务器重新启动自己的方式将该服务器从RAC集群中驱逐。
Page 13:
图8显示在14:38:58，Oracle Clusterware确定节点3不再"活动"7。同时，Oracle Clusterware开始进行恢复。
图8：正如ocssd.log文件中所报告的，Oracle Clusterware在14:38:58将节点3排除
最后，这些单独的恢复水平指标并不是特别重要，重要的是恢复OLTP交易所花费的时间有多长。图9显示了一个在14:39:07执行–i.sql脚本的会话的屏幕截图，说明当时共有3个实例在线。截至此时，从节点3死亡开始时间已经过去了63秒。事实上i.sql脚本的执行时间是14:39:07，但是，这并不能准确地描述交易恢复的时间。事实上，查看TotalStorage Performance Monitor可以更有效地完成此任务。
图9：恢复之后，gv$instance视图报告说明共存在3个依然存在的节点。
7 Oracle Clusterware使用可调整的参数，以减少错过登记的次数。您可以使用crsctl命令了解默认值， Linux 10.2.0.1版本的默认值为60。
Page 14:
图10为14:39:068的屏幕截图，显示集群范围内RAC I/O请求数量已经上升到每秒2,799次。在获取此屏幕截图之前，该数据库至少已经有一段时间可以使用了，因此才能回升到此I/O水平。
图10：TotalStorage Performance Monitor显示，在故障注入42秒内，I/O已回升到每秒2,799次
图10显示I/O是在14:39:06开始回升。而另一方面，图11显示，在节点3死亡（14:39:339）的69秒内，集群范围内的I/O速率已经回升到每秒7,777个I/O，占4个节点取得的I/O速率的77%。所以，PolyServe能够得到恢复，而Oracle能够执行其60秒CSS战略，而OLTP I/O也在近69秒内恢复到预计的3个节点的水平。毫无疑问，调整Oracle Clusterware的时间容限将加速此任务的完成。关键是在损失一个负载繁重的节点后，集群架构能够得到恢复。
8监控会话于15:26:59开始启动，此屏幕截图是在该会话开始启动12分钟零6秒后–即14:39:06获取的。
9监控会话于15:26:59开始启动，此屏幕截图是在该会话开始启动12分钟46秒后–即14:39:33获取的。
Page 15:
图11：TotalStorage Performance Monitor显示，I/O速率已回升到3个依然存在节点的预期值
故障恢复总结
通过在OLTP峰值吞吐率期间将集群中的一个节点断电，此测试确定PolyServe Database Utility for Oracle中恢复Real Application Cluster的能力。不进行任何调整，用户可以观察到的唯一效果是PolyServe集群文件系统访问存在12秒的停顿。从这一时刻仅过了30秒，物理I/O便恢复到故障前水平（每秒9,984次I/O）的约28%。如上所述，在损失节点3后的69秒内，该集群所有3个依然运行的节点的OLTP吞吐率已经恢复到故障前的水平。没有对Oracle 群件进行任何专门调整，获得这样的结果已经非常了不起了。最重要的是，当节点3出现故障时，与其余3个节点上的Oracle实例相连的会话并没有中断。它们依然能够保持连接，而Oracle的恢复刚刚完成，它们的交易也随之立即恢复。
Page 16；
按照需要动态、透明地进行扩展
决策支持系统（DSS）：轻量级扫描
按照配置，为了测试TotalStorage DS4500 SAN的性能情况，我们进行了Oracle Parallel Query Option (PQO)轻量级扫描测试。
图文翻译：
Light Weight Scan (LWS) Workload：轻量级扫描（LWS）工作负载
Scan of 2 Billion Rows (75GB)：扫描20亿行（75GB）
Throughput (MB/sec)：吞吐率（MB/秒）
1 Node：1个节点
2 Nodes： 2个节点
Blades：刀片服务器
图12.决策支持系统（DSS）：轻量级扫描（LWS）工作负载
轻量级扫描由对20亿行的信用卡交易表进行的select count(*)组成。Parallel Query Option的I/O设置为直接路径读取（direct-path reads）。直接路径读取是1MB异步串行I/O操作，在PGA内进行缓存，在个并行查询从进程同时可以并行进行4或8个查询。测试Oracle服务器在给定的硬件配置上能够实现的基本扫描吞吐率，Parallel Query轻量级扫描是最简单的方法。
决策支持系统（DSS）：数据加载吞吐率
我们还测量了卡表的加载。该测试包括将20亿pipe-delimited格式的数据记录。从平面文件同步加载到卡表中。平面文件和目标卡表空间都驻留在PolyServe Matrix Serve集群文件系统中。单一节点测试包括8个SQL*Loader流，每个流将加载等量的平面文件数据。在4个节点中，每个节点都有2个并发SQL*Loader进程，且4个节点的每个节点都并发地执行2个加载（loader）流。记录长度约为54个字节。平面文件总共需要约110GB文件系统空间。一经插入，该表需要约75GB空间。图13显示了一个集群文件系统，列出了8个平面文件，并显示了其中一个文件的几个最新记录。
Page 17:
图13.集群文件系统列表
LS20刀片数据加载时间展示了出色的可扩展性。图14显示，当LS20刀片服务器从1个节点扩展到4个节点使，大块数据加载的扩展能力实现了82%。一个节点的插入速率为每秒564,972行，完成任务需要59分钟…增加第二个节点并再次执行测试，结果为每秒可以插入1,075,269行，完成任务需要31分钟–扩展能力实现了95%。最后，在4个节点上执行该测试，结果为每秒插入1,851,852行，完成任务需要18分钟。
图文翻译：
Decision Support Sustem (DSS)Workload：决策支持系统（DSS）工作负载
Reduction in Completion Time：完成时间缩短
Time to Completion (Minutes)：完成时间（分钟）
1 Node：1个节点
2 Nodes：2个节点
4 Nodes：4个节点
Blades：刀片服务器
图14.随着节点数量的增加，完成时间缩短
Page 18:
DSS测试亮点如下：
- l 通过增加节点加快工作负载的完成是一种非侵入式方法。在另一台刀片服务器上启动DSS数据库实例，然后再次运行任务，完成时间缩短了。
- l Oracle10g RAC和PolyServe Matrix Server，可以充分利用所有可用的磁盘子系统带宽，而且没有显示出软件层的扩展能力限制。
- l 虽然每个测试的CPU和内存需求都存在显著差异，但是可扩展能力属性却是相同的。若存在服务器瓶颈，会明显出现重大性能差异。
OLTP环境中的可扩展性
为了测试灵活数据库集群架构在OLTP环境中的可扩展性，我们在RAC集群的节点1到节点4执行了前面描述的Order Entry工作负载。此工作负载极具争议，其读写率为约65:35。没有使用任何形式的分区（如工作负载、依赖于数据的请求路由等）。
图15显示测试得到的从1个节点（310 TPS）到4个节点（1081 TPS）的可扩展性为87%。
图文翻译：
On-Line Transaction Processing (OLTP) Workload：联机交易处理（OLTP）工作负载
Transactions per Second：每秒处理的交易
1 Node：1个节点
2 Nodes：2个节点
3 Nodes：3个节点
4 Nodes：4个节点
Blades：刀片服务器
图15. OLTP环境中的可扩展性
此工作负载耗尽CPU资源，但是对了解生成的I/O负载也是很重要的。如图16所示，I/O曲线与吞吐率曲线极为相像，这也说明了工作负载始终在扩展。4个节点每秒的物理I/O操作数量峰值超过了6,500，显而易见，LS20刀片服务器能够处理大量OLTP I/O负载。
Page 19:
图文翻译：
On-Line Transaction Processing (OLTP) Workload：联机交易处理（OLTP）工作负载
Physical I/O per Second：每秒处理的物理I/O数量
1 Node：1个节点
2 Nodes：2个节点
3 Nodes：3个节点
4 Nodes：4个节点
Blades：刀片服务器
图16. 运行OLTP工作负载的I/O可扩展性
如图16所示，在1个节点上测量的物理I/O数量为2,185，但是，LS20刀片并不局限于此。这是一个Oracle OLTP工作负载，在交易层处理从磁盘读入数据时，包含了大量CPU密集型工作。无需运行生成I/O请求的全处理器密集型交易工作负载，即可测量一个服务器能够处理的Oracle OLTP I/O的最大理论值。Orion测试工具包可以用于此类测量。
Oracle I/O工作负载(Orion)
Orion代表Oracle IO数量。可以从Oracle网站上获得Orion10。简言之，Orion工具包由在生产中运行Oracle时执行I/O的实际服务器代码组成。它还带有一个驱动这些具有不同工作负载性质（例如，大量连续扫描和随机单块传输）的I/O例程层。如需深入了解Orion测试工具包，请访问Oracle网站上的Orion Web页面。
为了在单一LS20节点上测试单节点Oracle服务器OLTP读取吞吐率的理论最大值，我们在PolyServe Matrix Server集群文件系统中创建一个256GB的Orion文件，并通过直接I/O进行访问。
Orion测试显示，单一LS20刀片服务器每秒能够从256GB文件中完成9,496次随机的4KB传输。因为目标文件要比TotalStorage阵列缓存大得多，Orion测量的每秒9,496次操作的I/O延迟为10.12ms。此测说明，LS20中的I/O子系统完全能够满足完成OLTP I/O请求的要求–事实上，对于全Oracle Server的驱动程度比以往要高得多。
10 http://www.oracle.com/technology/software/tech/orion/index.html。
Page 20:
总结
IBM BladeCenter H、PolyServe Matrix Server和Oracle10g RAC相互协作，使灵活数据库集群成为了一个支持多应用的强大平台。本文中提供的FDC分析验证了FDC架构和技术，并证实了以下内容：
- l 在IBM BladeCenter H为PolyServe Matrix Server和Oracle10g RAC提供了全面支持。
- l BladeCenter架构和技术，为实施灵活数据库集群提供了一个具有无与伦比的高可用性的平台。
- l IBM、PolyServe和Oracle是扩展计算的技术开发领先企业。
- l 灵活数据库集群架构和技术支持随需应变的计算。集群节点提供了供各应用使用的灵活的资源池，而且Oracle10g RAC的可用性得到了提高，因为通过使用Matrix Server，可以动态地重新配置节点，弥补其他节点的损失。
- l 灵活数据库集群提供了Matrix Server等强大的管理工具，从而提高了性能和可用性。单一的大集群要比众多小集群易于管理。
- l 像Matrix Server中所包含的集群文件系统那样的通用集群文件系统，提供了单一系统的感觉，显著增强了可管理性。由所有节点共同使用的共享Oracle主页也简化了管理。提供了可用于所有需要文件系统的数据库操作的支持。
- l 改善的FDC集群可管理性、可扩展性、延伸性、可用性和资产利用率，还显著降低了总拥有成本。
Page 21:
©2006年，IBM及其他公司版权所有。
IBM Systems and Technology Group
Department 23U
Research Triangle Park, NC 27709
美国制造
4-06
保留所有权利。
如需有关安全和有效计算方面的最新信息，请定期访问www.ibm.com/pc/safecomputing如需获得适当产品的保修副本，请写信至：Warranty Information, P.O. Box 12195, RTP, NC 27709, Attn: Dept. JDJA/B203。IBM 对于有关第三方产品或服务（包括指定为ServerProven或ClusterProven的产品或服务）不作任何声明或保证。
IBM、八条杠标志、xSeries、BladeCenter、BladeCenter H、ServerProven和TotalStorage是国际商业机器公司在美国和/或其他国家的商标或注册商标。如需其他IBM商标清单，请访问：http://www.ibm.com/legal/copytrade.shtml。
AMD和皓龙是Advanced Micro Devices公司的商标或注册商标。
Oracle和Oracle10g Java是Oracle公司的商标或注册商标。
UNIX是The Open Group在美国和/或其他国家的注册商标。
PolyServe和PolyServe标志是PolyServe公司的商标。
其他公司、产品或服务的名称可能是其他公司的商标或服务标志。
本文中有关非 IBM 产品的信息来自于那些产品的制造商或他们发布的声明。IBM 尚未对这些产品进行测试，因此无法证实其性能、兼容性或任何与非 IBM 产品相关的声明。有关非 IBM 产品性能的问题应该由那些产品的供应商解决。
IBM保留改变规范或其他产品信息的权利，无需另行通知。本文引用了 IBM 的产品或服务，但并不意味着 IBM 计划在公司业务涉及的所有国家提供这些产品或服务。IBM是"按原样"提供此出版物，并不提供任何明示或暗含的保证，包括对于适销和适用于某种特定用途的暗示保证。有些国家或地区不允许在免责声明中对于某些交易进行明示或暗示保证，所以，此声明可能对您并不适用。
此出版物可能包含到第三方站点的链接，它们不受IBM的控制或由IBM维护。访问任何第三方网站的风险由用户自行承担，且IBM不对这些网站上的任何信息、数据、观点、建议或声明的准确性和可靠性负责。IBM只是将这些链接作为一种方便条件提供，包含这种站点的链接并不意味着对其的认可。
本文仅用于提供信息的目的，对于由PolyServe公司提供或将要提供的任何软件、软件特性或服务不提供任何明示或暗示的保证。PolyServe公司保留随时更改本文的权利，无需另行通知，且不对其使用负责。此信息文档中描述的特性可能目前尚未上市。如需有关特性和产品可用性的信息，请联系PolyServe公司总部。
IBM TotalStorage IBM Server Proven
