分类： Oracle
2012-06-12 12:56:14
可伸缩性和应用程序性能的改进可以通过3种方法完成。
●更努力地工作。
●更聪明地工作。
●获取帮助。
“更努力地工作”意味着添加更多的CPU和更多的内存，使处理能力增强，以处理任意数量的工作量。这是常用方法，由于增加CPU可以解决工作量问题，因此这种方法通常是有帮助的。但是，这种方法并不是特别经济，因为计算能力的平均成本并非总是线性增加的。为单个SMP计算机增加计算能力通常会导致成本和复杂度以对数比例增大。另外，其性能(和可用性)也经常会受到基础设施层的瓶颈限制，例如将存储器连接到服务器的可用带宽和速度。
“更聪明地工作”是通过在应用层或存储层采用智能、高效的算法来实现的。通过在存储层引入“智能性”，可以大幅减少为获得期望结果所需完成的总工作量。要在应用层更聪明地工作，经常需要重新编写应用程序或者改变它的工作方式(有时需要改变应用程序的设计本身)，这对于一个正在运行的应用程序是不可能做到的，它需要的停机时间是不可接受的。有时，对于第三方供应商和封装的应用程序来说，这一选项也是几乎不可能实现的，因为要让所有人都参与进来可能会变成一项极为单调和耗费时间的任务。
在存储层更聪明地工作是通过引入智能存储服务器来实现的，存储服务器会卸载一定数量的处理进程。这需要一些特殊设计的存储服务器(例如在Oracle计算机中使用的Oracle Exadata存储服务器)在临近存储器的地方处理一定数量的关键工作量。在临近存储器的地方处理工作量可以极大地提高应用程序的性能，这样可以大大限制存储器与主机之间的往返次数，同时还能限制向数据库基础设施传递的数据规模。
“获取帮助”非常简单，就是使用其他计算机的计算能力来完成任务。换句话说，“获取帮助”就是对硬件进行集群化，使用空闲节点的多余处理能力，并在最后合并处理事务的结果。更重要的是，这一方法并不需要对应用程序进行任何修改，因为它对应用程序是透明的。使用这一方法的另一个好处是它支持按需伸缩，可以选择在需要时获取帮助，而不需要对大量硬件进行投资。
Oracle Exadata和智能扫描
前面提到，为了提高性能和可伸缩性，可以采用“更聪明地工作”方法，而新发布的Oracle Exadata存储服务器正好适合这一方法。传统数据库实现方式将这种存储用作转储和获取数据的简单容器，这些存储容器对于它们经常存储的数据来说是相对“简易”的。所有数据库处理工作都是在数据库主机内存中处理的，通常需要将大量数据从存储设备传递到实际完成数字处理的主机上。然后，将汇总的结果传递到终端用户应用程序的较高层。为了验证所需业务智能操作的有效性，需要向这些列级数据应用筛选条件，处理数量非常庞大的原始数据。
专用存储服务器在存储层设有额外智能，这些存储器完全“了解”磁盘上存储的数据。当主机处理复杂业务智能报表时，它会与存储服务器进行对话，针对正在从存储服务器请求的数据集提供更多的相关信息。这些存储服务器对存储器中的数据进行筛选(称为“智能扫描”处理)，并传递与主机指定条件相匹配的记录。一定数量的处理工作是在存储层处理的，数据库主机在处理查询时不需要处理巨量原始数据。
在传统的存储器托管的数据库中，SQL查询处理工作是在数据库服务器中处理的。磁盘中存储的数据以块的方式获取到数据库服务器中，并加载到数据库缓冲区缓存中进行处理。图中显示了传统存储体系结构中的表扫描处理。
传统存储体系结构中的表扫描处理
(1)应用层(终端用户客户端)发出SQL查询。为简单起见，我们假定这是一条带有WHERE条件的SELECT语句。
(2)数据库内核查询数据字典，确定存储表数据的文件和扩展块。
(3)数据库内核发出I/O调用，从磁盘中读取所有物理数据块。
(4)来自磁盘的物理数据块加载到数据库服务器的内存中(SGA中的缓冲器缓存)。
(5)数据库服务器读取内存缓冲区，根据谓词(WHERE条件)筛选满足条件的行。
(6)匹配行被返回到客户端。
如果这些表比较小且有很好的索引，那么这种传统SQL处理过程会工作良好。但对于涉及多个大型表的复杂业务智能查询来说，从磁盘中读取所有数据并将它们传送到主机内存是一项成本很高的任务，需要通过网络将大量原始数据传递到主机内存。此外，那些不满足筛选条件的记录会在主机级别被丢弃。这是一种效率极低的I/O操作，对查询响应时间有着严重影响。在这种情况下，我们经常要多次读取匹配筛选条件所需要的数据；构造不佳的查询会对存储子系统产生不必要的开销，并影响到整体系统性能。
但是，在Exadata智能扫描模型中，整个工作流程完全不同，它采用非常智能化的方式进行处理。执行表扫描的查询被卸载到Exadata存储服务器，只有那些满足筛选条件的记录才会返回数据库服务器。诸如行筛选、列筛选等任务以及一定数量的连接处理都是在存储服务器中完成的。另外，Exadata还使用一种特殊类型的未缓冲直接读取机制来扫描表，效率很高。它类似于Oracle并行查询操作，下图显示了这一操作。
使用Exadata进行智能扫描
(1)应用层(终端用户应用程序)发出SELECT查询。
(2)当数据库服务器检测exadata时，它构建一个表示这一SQL语句的exadata构造(称为iDB命令)，并将之发送到Exadata存储服务器。iDB是一种基于无限带宽协议的数据传递机制(低延迟、高带宽)，在Exadata存储服务器和数据库服务通信之间使用。
(3)Exadata存储服务器对表执行“智能扫描”，并直接在存储器上应用WHERE条件以提取感兴趣的数据行。
(4)结果集被直接传递到数据库实例。这个结果集就是查询结果，而不是满足筛选条件的数据块。它被直接发送到用户会话的“程序全局区”(PGA)，而不是缓存在“系统全局区”(SGA)中。
(5)匹配行被返回到客户端。
将SQL处理卸载到Exadata服务器极大地提高了查询处理速度，释放了数据库服务器中的CPU周期。另外，在接近存储器的地方处理数据可以减少大量的低效I/O，提高存储子系统的可伸缩性。
集群体系结构的类型
根据节点之间共享存储的方式，可以将集群体系结构宽泛地分为3种类型：
●无共享体系结构
●共享磁盘的体系结构
●完全共享的体系结构
1.无共享体系结构
无共享体系结构是使用一组独立服务器构建的，每台服务器接受预先确定的工作量(参见下图)。例如，如果集群中有许多服务器，那么将总体工作量除以服务器数量，每台服务器处理特定的工作量。无共享体系结构有一个最大的缺点，那就是它需要非常仔细的应用程序分区，并且不能动态添加节点。要添加节点，就需要全面重新部署，所以它不是一种可伸缩的解决方案。Oracle不支持无共享体系结构。
无共享体系结构
在无共享集群中，数据通常被分割到独立节点中。由于每个节点负责整体数据库中的不同子集，因此很少需要对这些节点进行协调。但在一个严格的无共享体系结构中，如果一个节点停机，它负责的部分数据就是不可用的。
集群服务器既不共享磁盘，也不镜像数据——它们都有自己的资源。在发生故障时，服务器将其各自磁盘的所有权传递给其他服务器。无共享集群使用软件来完成这些转移。这一体系结构可以避免在共享磁盘时发生的分布式锁管理器(DLM)瓶颈问题，同时还能提供相当的可用性和可伸缩性。无共享集群解决方案的示例包括Tandem NonStop、Informix OnLine Extended Parallel Server (XPS)和MicrosoftCluster Server。
无共享集群的主要问题之一就是它们在数据分区方面需要非常精心的部署计划。如果分区出现偏差，就会对整体系统性能产生负面影响。另外，当磁盘属于另一个节点时(在任意成员节点出现故障期间通常会发生这种情况)，处理开销也会显著增大。
无共享集群的最大好处是它们为数据仓库应用程序提供了线性可伸缩性——它们非常适合于这种情况。但是，它们不适用于联机事务处理(OLTP)工作量，并且它们不是完全冗余的，当一个节点发生故障时，会使该节点上运行的应用程序不可用。但是，大多数主流数据库，如IBM DB2企业版、Informix XPS和NCR Teradata，的确实现了无共享集群。
|
注意： 一些无共享体系结构需要在服务器之间复制数据，以便这些数据能够供所有节点使用。这样就不再需要应用程序分区，但需要一种高速复制机制，与高速的“内存至内存”传送相比，这种机制几乎总是不可能实现的。 |
2.共享磁盘的体系结构
为获得高可用性，需要对数据磁盘的共享访问(参见下图)。在共享磁盘存储集群的低端解决方案中，如果一个节点发生故障，那么另一个节点可以接管存储器(和应用程序)。在高级解决方案中，在多个节点上运行的应用程序有可能同时访问数据，但在某一时刻，由单一节点负责协调对给定数据磁盘的所有访问，并向其余节点提供存储。在繁忙的配置中，这个单一节点可能会成为数据访问的瓶颈。
共享磁盘集群
在简单的故障转移集群中，一个节点运行应用程序并更新数据；另一个节点一直保持空闲，在需要时完全接管。在更高级的集群中，多个节点可以访问数据，但在某一时刻通常由一个节点向其余节点提供文件系统，并执行对该文件系统的所有协调工作。
3.完全共享的体系结构
完全共享集群利用可供该集群内所有计算机(节点)访问的磁盘。它们也经常称为“完全共享集群”，这是因为所涉及的I/O通常用作普通文件和/或数据库的磁盘存储。这些集群依赖于一个公共通道进行磁盘访问，因为所有节点可能会同时在这些中心磁盘上读写数据。因为所有节点对集中式共享磁盘子系统拥有同等访问权限，所以必须使用一个同步机制来保证系统的一致性。集群软件的一个独立部分DLM承担着这一角色。
在一个完全共享的集群中，所有节点可以同时访问所有数据磁盘，任何一个节点都不需要通过一个分离的对等节点来访问数据(参见下图)。具有这一功能的集群采用一个集群范围内的文件系统(CFS)，所以所有节点都是同等看待文件系统的，它们提供了一个DLM，使节点能够协调对文件、记录和数据库的共享及更新。
CFS对集群中所有节点的磁盘数据提供相同的视图。这意味着对于用户和应用程序来说，每个节点上的环境看起来都是相同的，所以在任何时刻，应用程序或用户在哪个节点上运行是没有关系的。
完全共享集群
完全共享的集群支持更高级别的系统可用性：如果一个节点发生故障，那么其他节点不会受到影响。但是，这种更高的可用性是有代价的：由于在使用DLM时会产生开销，另外共享硬件中可能出现潜在瓶颈，因此多少会降低这些系统的性能。完全共享的集群以较好的伸缩特性来弥补这一缺陷。
Oracle 是完全共享体系结构的经典示例。Oracle RAC是Oracle数据库的一种特殊配置，它充分利用了硬件集群技术，将集群扩展到应用程序级别。数据库文件存储在共享磁盘存储中，从而使所有节点都能同时读写它们。共享存储是一种典型的联网存储，如Fibre Channel SAN或基于IP的Ethernet NAS，它以物理形式或逻辑形式连接所有节点。
Oracle RAC的历史
硅谷饥饿的流浪汉们倡导了“大规模并行处理”(MPP)的概念，并将之命名为“集群”。Digital、IBM和Cray是集群领域的一些先行者。DataPoint于1977年成功地开发了第一个集群产品ARCnet。
尽管ARCnet在研究实验室中算是一件优秀产品，是学术领域的宠儿(对于整个大学的研究团体、系和计算机集群资源来说)，但它在商业上并不成功，直到Digital Equipment Corporation(DEC)于20世纪80年代为VAX/VMS操作系统发布了它的VAX集群产品，集群才真正开始腾飞。ARCnet和VAX集群产品不仅支持并行计算，还共享文件系统和外围设备。它们计划在维护数据原子性的同时提供并行处理的好处。
Oracle的集群数据库是随着Oracle6一起为Digital VAX集群产品发布的，在nCUBE机器上运行。Oracle是第一个在数据库级别支持集群的商业数据库。由于原来由Digital出品的锁管理器对于数据库应用程序来说其可伸缩性不是很强，而且数据库需要在数据块级别进行细粒度锁定，因此Oracle为VAX/VMS集群创建了锁管理器。Oracle 6.2中加入了“Oracle并行服务器”(OPS)，它使用Oracle自己的DLM，能够与Digital的VAX集群很好地协同工作。Oracle是第一个运行并行服务器的数据库。
在20世纪90年代早期，当开放系统主导计算机行业时，许多UNIX供应商启动了集群技术，主要就是以Oracle的DLM实现为基础的。Oracle 7并行服务器(OPS)使用了由供应商提供的集群件。OPS几乎拥有所有UNIX特性，而且工作状态极佳，但其安装和管理比较复杂，这是因为在此过程中涉及了多个层。
当Oracle在第8版中引入通用锁管理器时，它清楚地为Oracle自己的集群件和锁管理器的未来版本指明了方向。Oracle的锁管理器通过一个名为OSD(操作系统相关性)的附加层与Oracle代码集成在一起。Oracle的锁管理器不久与内核集成在一起，在Oracle的稍后版本中称为IDLM(集成分布式锁管理器)。
Oracle RAC 9i版本使用了相同的IDLM，并依赖于外部集群件。Oracle在Oracle 9i中为Linux和Windows提供了自己的集群件，从10g开始为所有操作系统提供集群件，在Oracle 11g中引入了服务器池和用于管理第三方应用程序的补充API，从而集群件得到大幅提升。“Oracle集群件”是事实上的集群件，是运行Oracle RAC必不可少的组成部分。表中列出了各种操作系统的最常用集群件。
各种操作系统的常用集群件
|
操 作 系 统 |
集 群 件 |
|
Solaris HP-UX HP Tru64 Windows Linux IBM AIX |
Sun Cluster、Veritas Cluster Services HP MC/ServiceGuard、Veritas Cluster Services TruCluster Microsoft Cluster Services Oracle集群件 HACMP (高可用性集群多处理) |
本文摘自《Oracle Database 11g RAC手册(第2版)》清华大学出版社
预售地址：
