IBM DB2数据库高级企业版方案建议书

 

 

 

IBM DB2数据库高级企业版方案建议书


 

第1章     概述... 3

第2章     IBM DB2数据库概述... 4

第3章     DB2企业版的主要特征... 5

第4章     DB2高级企业版的增强能力... 13

4.3.1        Optim Performance Manager Extended. 14

4.3.2      Optim Query Workload Tuner 15

4.3.3        Optim pureQuery Runtime 16

第5章     面向典型负载优化的实施方案... 21

5.1.1        pureScale集群的高可用性.. 21

5.1.2        pureScale集群的高性能和高扩展性.. 22

5.1.3        pureScale集群给客户带来的价值.. 23

5.1.4        pureScale数据库集群推荐的硬件平台.. 23

5.2.1        IBM数据仓库整体解决方案概述.. 24

5.2.2        DPF数据仓库集群特征.. 1

5.2.3        DPF方案的技术特点和优势.. 3

5.2.4        DPF数据仓库解决方案带来的价值.. 4

第6章     案例... 7

 

 

 

第1章       概述

在全球经济的竞争中,每个企业、组织都面临着许多挑战。 全球的企业都在试图通过将旧有的业务处理转换到互联的、集成的“电子”处理来获得竞争优势。 企业内部的业务系统, 象ERP等, 帮助企业增进了和客户、供应商、以及业务伙伴之间的联系, 拉近了相互的距离,创建了一个完整的价值链, 提高了生产效率和客户满意度。 对于一个企业, 紧盯企业外部的那些利润中心是非常关键的,而如果它的业务系统能够将客户、业务伙伴、供应商都紧密地结合到一起, 那么它就能快速的响应客户的需求和市场中的机会,并能够快速的应对外部的竞争。

企业实现信息电子化的目标是为了在竞争中获得优势。另外,在市场发生变化时,需要能动态的进行调整以应对各种挑战。而电子化的业务处理流程需要您将所有的业务信息都电子化以推动今天的随需应变的电子商务, 这就需要系统能够处理各种类型的信息, 包括结构化的和非结构化的。

在今天的商业环境下, 越来越多的组织将他们的系统小型化, 产生更多的目的明确并可重用的组件,以适应当前面向服务的架构(SOA)的需要。在这种大环境下,在系统间方便的交换数据就显得更为重要。而基于面向服务的架构, 我们的IT系统将以服务为基础, 这不但提高了代码重用, 并使得IT系统架构能够更好的适应企业业务的变化,市场的变化。面向服务的架构通常是用web服务这样的独立于平台之外的相关协议和标准来构建,象XML。 XML已经成为面向服务的架构的重要组成部分, 通过它还能够更灵活的在不同的应用或系统之间便捷的交换信息。

关系数据库作为商业计算的中坚力量,历经数十年的发展经久不衰,在信息技术日益发达的现代社会,不但没有落伍,反而体现出更加强大的生命力。信息技术在现代经济生活中不论是“广度”还是“深度”方面都不断拓展,其产生的大量的“黄金”信息需要通过关系数据库管理。随着互联网等新型计算技术的蓬勃兴起并与传统商业计算模式相结合,IT系统对数据库平台的高强度负荷、7x24小时持续可用性等方面的要求正达到一个前所未有高度。随着“并行计算”进化到“网格计算”并升华到“云计算”,传统关系数据库自身也需要不断的进步提升,适应新的计算架构模式下的管理需求:

高可靠

通过帮助建立数据库系统的集群应用,实现7X24小时不间断运行,避免由于某台服务器故障造成的数据访问中断;

高扩展性

采用负载均衡技术提升数据库集群整体性能,集群中服务器数量达到100台时,系统的扩展线性度能够达到80%以上,即整体系统效率能够提升至单台服务器处理能力的80倍以上。

易管理

“透明化”的部署,在增加系统资源时,企业只需将服务器轻松添加到集群系统中,无需做任何管理操作或程序修改。

深压缩

在“大数据”日益发展的时代,要求数据库能够提供高效的压缩能力,能够将原始数据进行深度压缩,大大减少物理存储所需的空间,降低成本,提高性能。

 

第2章    IBM DB2数据库概述

在过去的三十多年中,IBM公司一直在领导信息管理走向新的高度:

1968,IMS的研发成功标志着第一代数据库,即层次型数据库的诞生;

1970,IBM 研究中心E.F.Codd 博士提出了关系型数据库模型,紧接着IBM 研究中心发明了第一个关系型数据库SYSTEM R (1973)和 SQL语言;

80年代开始,基于SQL的关系型数据库逐渐成为数据库管理系统的主流,IBM的关系型数据库DB2主宰了大型机上的数据库应用,IBM DB2 提出了分布式数据库DRDA 架构;

2006,IBM推出了DB2 v9版本,它在关系数据库的基础上提供了对XML的强大内置支持,在业界具有里程碑意义。其后又陆续发布了DB2 9.5/9.7等升级版本,在性能、压缩、兼容性等方面不断提升。

2012,IBM发布了DB2 v10版本,将IBM大型主机DB2 for z/OS上的“黄金标准”引入到开放平台,推出了pureScale集群技术,提供强大的高可用高扩展集群能力。成为第一个同时支持Share-Nothing和Share-Disk的大型商用数据库产品,帮助客户应对不同负载的挑战。

选择IBM DB2至少具有以下优势:

DB2在提供强大的关系处理能力的基础上,引入独一无二的pureXML技术。

DB2具有业界最好的字典压缩技术,能够在OLTP系统中实现数据深度压缩。

DB2的性能一直遥遥领先于其他竞争产品(包括TPC-C和TPC-H)。对于象数据中心这样的大型应用而言,性能是一个非常重要的指标。

DB2具有最领先的数据库自主管理能力,能够根据负载和资源情况进行自适应调优,这将大大降低系统的运维成本,从而有效控制系统的总体拥有成本(TCO)。

DB2 在体系架构上的优势,同时支持Share-Nothing和Share-Disk的集群架构,使得其具有业界最好的平行处理能力和接近线性的强大扩展性。

第3章    DB2企业版的主要特征

3.1    卓越性能

IBM提供了大量的性能测试结果,您可以用来进行相应的对比。在这些性能测试中,IBM都取得了骄傲的成绩。这些测试覆盖了不同的硬件,包括IBM,HP,Sun等。这些性能测试展示了DB2的强大:

  • 强大的对交易类型应用的支持(如 TPC-C)
  • 强大的对数据仓库和分析应用的支持(如 TPC-H)
  • 广泛的硬件平台和操作系统的支持
  • 强大的工业标准 (TPC) 和应用程序伙伴标准 (SAP, i2, PeopleSoft, J. D. Edwards, etc.)的支持。

3.2    自动优化

IBM DB2从版本9开始引入了一个在业界具有革命性意义的内存自我调整系统——the Self Tuning Memory Manager (STMM)。STMM技术使得DB2能够自动控制DB2主要的内存对象:Sort, locklist, package cache, buffer pools, 和 total database memory;无需人工干预地进行内存自我在线调优;自我感知工作负载、按需调整内存大小;能够迅速适应工作负载的突然变化,自动重新划分内存区域;并自动化适应工作负载的周期性变化。在国内外的多个客户实际场合中,STMM对系统的优化效果甚至超过了一个具有多年经验的DBA的调优效果。

DB2中的自调整内存功能通过在启动时自动设置一些内存参数的值来简化管理任务。自调整内存管理器用智能控制和反馈机制来追踪工作量特性和内存使用情况的变化,以及各种共享资源的需求情况等, 并按照需要动态的调整内存的使用。自调整内存管理的优点包括:

  • 简化数据服务器的配置
  • 提高数据库管理员的效率,使得管理员有时间去处理其它重要的任务
  • 动态的调整以适应工作量的大幅变化
  • 自动控制允许数据库在工作峰值时使用更多的内存,并在工作量小时释放出不需要的内存

3.3    表分区(Table Partition)

表分区(Table Partition) 功能,通常称作范围分区,可用于定义每个分区的数据范围并根据数据范围将数据存储为单独的对象。存储对象可以在不同的表空间,相同的表空间,或者都有。此功能常常用于数据容量比较大的表,用来将数据分割成可单独处理的多个对象,从而提高系统的处理能力。此功能的优点包括:

  • 支持创建大型的表。一个分区表对于普通表而言可以支持更巨大的数据量。它通过将数据存储到不同的存储对象来显著的提高表所能容纳的数据量。
  • 更灵活的管理能力。现在可以在每一个独立的分区执行管理操作。对于耗时较长的操作,这相当于将这些操作分成小份来执行。
  • 更细化的索引存放控制。你可以将索引放置在不同的表空间并独立的管理它们。
  • 快速,简便的导入或导出数据。这个能力对于数据仓库这样需要经常移动数据来运行决策支持查询的系统非常有用。
  • 提高查询性能。将数据存放在不同的分区,使得在查询时可以避免检索不需要的数据。

3.4    物化查询表(MQT)

DB2的性能优化融合了三个模块的功能为复杂的查询,OLAP环境下的数据群集应用,和多处理器的高性能系统提供性能优化。此功能使用物化查询表(MQT),多维群集和查询并行等技术来实现完整的高性能方案:

  • 物化查询表(MQT)是基于查询结果而定义的表。基于MQT的查询能帮助您更快的获得查询结果。任何和MQT匹配的查询都可能体验到MQT带来的好处。
  • DB2的优化器以代价为基础决定是否使用MQT。MQT可以被用在联邦系统中(如WebSphere Information Integrator)以提高性能。一个包含nickname的MQT使得远程数据被复制到本地,因此减少网络负载。

3.5    多维群集(MDC)

  • 多维群集(MDC)是通过多个维度来灵活的、连续的、自动的处理表中的群集数据的方法。多维群集(MDC)能显著的提高查询的性能。
  • 在不使用多维群集(MDC)的情况下,你必须维护多个独立的索引并且数据仅能够按照其中的一个索引来群集存储。只有符合这个群集索引顺序的查询才能获得群集的优势。而多维群集使得每一个维度都是按群集定义存储的,减少磁盘I/O,从而提高查询性能。

3.6    工作负载管理能力

DB2提供工作负载管理能力,可以评估发送至数据服务器的多个请求,将它们分配到预定义的工作负载类型,根据预定义的工作负载定义进行相应的管理。使用 DB2 工作负载管理可以更好地控制系统资源使用。

现在,由于数据库活动量日益增加,所以系统资源(如 CPU、I/O 和内存)的争用情况越来越成为达到业务目标的障碍。增强的 DB2 工作负载管理功能可以帮助您标识一组已定义的数据库活动并将它们隔离在自己的执行环境中,您可以对这些活动分配达到您的目标所需要的适当资源。在环境或服务类中,您可以显式管理系统资源,以便较重要的资源可供较高优先级的工作使用,并可以控制或消除与较低优先级工作的争用情况。

工作负载管理增加了系统的可预测性和稳定性

大多数企业都会遇到高峰期,增加的活动量和需求量影响数据服务器的工作负载。高峰期可能出现在中午,这时大多数用户都在系统上,也可能出现在月末,这时所有详细的月度报表都要进行处理。在这些高峰时间内,正常运行时可以预测时间量的工作负载的响应时间会变得不可预测。在数据服务器上执行其他工作的用户也可能造成无意的高峰期,因为没有进行任何控制来限制他们可以使用多少资源。例如,用户可能无意中提交了需要服务器执行大量处理的 SQL 语句或包含复杂连接(如 Cartesian 连接)的 SELECT 语句。

DB2 工作负载管理允许您预先确定适当的资源分配、活动的优先级划分和排队选项来高效地处理工作,从而可以平滑高峰工作负载。在您定义这些指示后,数据服务器使用它们来分配资源和划分工作的优先级。例如,您可以使工作远离流氓查询的影响,这些查询使用过量的数据库资源,因此会对系统上运行的其他查询带来负面影响并可能会影响整个数据库。通过使用阈值,您可以使用许多不同特征(如执行时间或系统临时表空间使用量)来定义系统内可接受的查询行为,并定义对不按要求执行的任何查询要执行哪些操作。这些操作包括收集关于查询的详细信息的功能以及自动取消查询的功能。

定制了具有混合工作负载的环境中的性能要求

同一台数据服务器上共存的混合工作负载共享相同的资源,但可能具有不同的性能要求。例如,批处理工作负载通常在晚上运行,这时数据服务器相对比较清闲,并且这些工作负载不会对中午运行的日常报表作业带来负面影响。

DB2 工作负载管理允许您有效地划分工作负载的优先级并将资源定向至最需要的位置,从而有助于您重点注意混合工作负载的性能。您可以通过使用定制控制和资源分配功能来使系统上数据服务器活动的整体吞吐量最大。

您也可以使用有形的和无形的方法来测量数据服务器的性能。有形的方法示例是数据库统计信息,它们显示完成一组特定活动所需要的时间量以及完成简单查询或更复杂的作业(如将数据装入仓库的批处理作业)所需要的各个时间量。无形的方法可能是用户对数据服务器响应时间的感觉和满意程度。

要使性能最优,您可以使用工作负载管理监视功能来获取关于数据服务器上正在运行的工作的聚集和时间点信息。如果某种类型的工作未在所需的时间范围内完成,那么您可以使用监视数据来帮助了解事态的进展并修改您的配置。例如,您可能决定将更多资源分配给某个服务类或对某种类型的工作指定资源使用控制。在作出这些更改后,您可以监视系统行为,以验证您作出的更改是否会产生您需要并且不会导致其他意外行为的响应时间。工作负载管理是一个反复进行的过程;您可以不断优化您的配置,直到获得满足业务需要的结果为止。

3.7    数据库安全和行列访问控制

DB2采用两种方式来控制对数据库系统数据和函数的访问。对 DB2 数据库系统的访问由位于 DB2 数据库系统外部的工具来管理(认证),而 DB2 数据库系统内的访问由数据库管理器管理(授权)。

认证

认证就是系统验证用户身份的过程。用户认证是由 DB2 数据库系统外部的安全性工具通过认证安全插件模块来完成的。当您安装 DB2 数据库系统时就包括了依赖于基于操作系统的认证的缺省认证安全插件模块。为方便起见,DB2 数据库管理器还提供了用于 Kerberos 和轻量级目录访问协议(LDAP)的认证插件模块。为了更灵活地适应您特定的认证需要,可以构建您自己的认证安全插件模块。

认证过程将生成一个 DB2 授权标识。用户的组成员资格信息也是在认证期间获得的。缺省情况下获得的组信息依赖于当您安装 DB2 数据库系统时包括的依赖于基于操作系统的组成员资格插件模块。如果愿意,可以通过使用特定的组成员资格插件模块(如 LDAP)来获取组成员资格信息。

权限

对用户进行认证之后,数据库管理器就会确定是否允许该用户访问 DB2 数据或资源。授权是这样一个过程:DB2 数据库管理器通过此过程来获取有关已认证的用户的信息,指示该用户可以执行哪些数据库操作,该用户可以访问哪些数据对象。

以下是可用于授权标识的许可权的不同来源:

主要许可权:直接授予授权标识的许可权。

辅助许可权:授予该授权标识作为其成员的组和角色的许可权。

公用许可权:授予 PUBLIC 的许可权。

上下文敏感许可权:授予可信上下文角色的那些许可权。

可以按下列类别将权限授予用户:

系统级别权限

系统管理员(SYSADM)、系统控制(SYSCTRL)、系统维护(SYSMAINT)和系统监视(SYSMON)权限提供了不同程度的对实例级别函数的控制权。权限提供一种方法来对特权分组和控制实例、数据库和数据库对象的维护和实用程序操作。

数据库级别权限

安全性管理员 (SECADM)、数据库管理员 (DBADM)、访问控制 (ACCESSCTRL)、数据访问 (DATAACCESS)、SQL 管理员 (SQLADM)、工作负载管理管理员 (WLMADM) 以及说明(EXPLAIN)权限提供了数据库内的控制权。其他数据库权限包括 LOAD(能够将数据装入到表中)和 CONNECT(能够连接至数据库)。

对象级别权限

对象级别权限涉及对对象执行操作时检查特权。例如,要从表中进行选择,用户就必须至少对该表具有 SELECT 特权。

RCAC 在行级别和/或列级别控制对表的访问。

行和列访问控制或 RCAC 具有下列优点:

不免除任何数据库用户是行和列访问控制规则固有的特性。

这些规则不会免除甚至具有更高级别权限的用户(例如,具有 DATAACCESS 权限的用户)。仅具有安全性管理员 (SECADM) 权限的用户才能管理数据库中的行和列访问控制。因此,您可以使用 RCAC 来阻止具有 DATAACCESS 权限的用户自由访问数据库中的所有数据。

不管如何通过 SQL 来访问表,表数据都受保护。

应用程序、临时提供的查询工具和报告生成工具都遵循 RCAC 规则。强制执行将以数据为中心。

任何应用程序更改都不需要使用数据安全性的这个附加层。

即,将以现有应用程序不知道的方式建立和定义行和列级别访问控制。然而,RCAC 在范例方面有一个重要的改变,即重点不再是请求了什么内容,而在于谁在请求这些内容。相同查询的结果集将根据执行查询所在的上下文而更改,并且不会返回警告或错误。此行为是该解决方案的真正意图。这意味着应用程序设计人员和 DBA 必须知道,查询并非可以查找表中的所有数据,除非授予了特定许可权执行这样的操作。

行和列访问控制 (RCAC) 规则

行和列访问控制 (RCAC) 在表级别对数据本身进行访问控制。对行和列创建的 SQL 规则是实现此功能的基础。

3.8    高可用和容灾

高可用性灾难恢复 (HADR) 功能提供针对部分站点故障和整个站点故障的高可用性解决方案。HADR 通过将数据更改从源数据库(称为主数据库)复制到一个或多个目标数据库(称为备用数据库)来防止数据丢失。

部分站点故障可能是由硬件、网络或软件(DB2® 数据库系统或操作系统)故障引起的。如果没有 HADR,发生部分站点故障时就需要重新启动数据库所在的数据库管理系统(DBMS)服务器。重新启动数据库和数据库所在的服务器所需的时间长度是不可预测的。可能在几分钟时间后,数据库才会恢复为一致状态并可用。使用 HADR 时,备用数据库可在数秒内接管。另外,还可以通过使用客户机自动重新路由功能,或重试应用程序中的逻辑,将使用原始主数据库的客户机重定向至新的主数据库。

当由于灾难(例如,火灾)而导致整个站点被破坏时,就可能会发生整个站点故障。但是,因为 HADR 使用 TCP/IP 在主数据库和备用数据库之间进行通信,所以数据库可以位于不同位置。例如,主数据库可能位于某个城市的总部,而备用数据库位于另一城市的销售办事处。如果在主要站点发生了灾难,那么可以通过让远程备用数据库接管具有所有 DB2 功能的主数据库来维护数据可用性。执行接管操作之后,可以备份原始主数据库,并将其返回至主数据库状态;这即是所谓的故障回退。如果您可以使旧的主数据库与新的主数据库保持一致,那么可以启动故障回退。旧的主数据库作为备用数据库重新集成到 HADR 设置之后,可以切换数据库角色,以再次将原始主数据库启用为主数据库。

通过在主数据库上生成并递送到备用数据库的日志数据,备用数据库与主数据库保持同步。通过日志,备用数据库不断地前滚。您可以从四种不同同步方式中选择。这些同步方式为 SYNC、NEARSYNC、ASYNC 和 SUPERASYNC(按照保护级别从高到低排列)。

使用 HADR,您可以使用单备用数据库方式或多备用数据库方式。在多备用数据库方式下,您可以通过单一技术同时达到高可用性和灾难恢复目标。有关更多信息,请参阅HADR 多备用数据库。

除了将 HADR 备用数据库或其他备用数据库用于其 HA 或 DR 用途之外,您还可以将它们用于许多其他用途。

在备用数据库上读取

您可以使用“在备用数据库上读取”功能将只读工作负载导向到一个或多个备用数据库,但不影响备用数据库的 HA 或 DR 职责。此功能可帮助减轻主数据库上的工作负载,但不影响备用数据库的主要职责。有关该主题的更多信息,请参阅HADR“在备用数据库上读取”功能。

除非您已启用“在备用数据库上读取”,否则应用程序只能访问当前主数据库。如果您已启用“在备用数据库上读取”,那么可将只读应用程序重定向至备用数据库。如果发生故障转移,那么连接至备用数据库的应用程序不影响备用数据库的可用性。

延迟重放

您可以使用延迟重放来指定使备用数据库上的日志重放保留在早于主数据库的某个时间点。如果主数据库上发生数据丢失或损坏,那么您可以在时间延迟备用数据库上恢复此数据。有关更多信息,请参阅HADR 延迟重放。

滚动更新和升级

使用 HADR 设置,您可以在不停机的情况下对数据库进行各种类型的升级和 DB2 修订包更新。如果正在使用多备用数据库方式,那么您可以在执行升级的同时保留 HADR 所提供的保护。有关更多信息,请参阅在 DB2 高可用性灾难恢复 (HADR) 环境中执行滚动更新和升级。

如果数据库中的大多数或所有数据需要保护,或者如果执行必须在备用数据库上自动复制的 DDL 操作时,那么 HADR 可能是最佳选择。但是,HADR 只是 DB2 产品系列中提供的若干复制解决方案之一。InfoSphere® Federation Server 软件和 DB2 数据库系统包括 SQL 复制和 Q 复制解决方案,在某些配置中也可以使用这些解决方案来提供高可用性。这些解决方案在多个位置维护逻辑上一致的数据库表副本。另外,它们还提供灵活性和复杂功能,如支持列和行过滤、数据变换、任何表副本的更新。您还可以在分区数据库环境中使用这些解决方案。

3.9    备份和恢复

DB2支持脱机备份和联机备份,支持表空间级备份。DB2既支持数据库全备份,也支持增量备份,同时支持备份压缩。所有的操作都是通过BACKUP命令实现的。在对备份的映象进行恢复时,只需要执行RESTORE并选择性地进行前滚ROLLFORWARD即可。

DB2通过日志归档、日志镜像、日志迁移等多种备份技术,分别应对数据库损坏、数据库备份损坏、灾难等多种意外。

DB2的在线数据库备份和恢复功能帮助节省了大量的时间和资源。它可以更快的实现以下操作:

  • 恢复:通过自动的从存在的备份中生成重定向恢复的脚本来加快数据库的恢复,使得数据库尽快可用。
  • 重启动:通过这个新的恢复操作的功能,节省时间和资源
  • 重建:可以通过表空间级的备份来恢复整个数据库
  • 复原:即使在很严重的系统失败情况下,都可以通过HADR功能帮助系统尽快恢复运行

3.10           隔离级别和锁机制

DB2完全支持标准的四种隔离级别(UR、CS、RS、RR)。 并且在9.7版本中,对CS隔离级别提供了更灵活的“Currently committed”功能,减少锁冲突,进一步提高了数据库的并发处理能力。

在 DB2 9.7之前的版本中,当使用游标稳定性隔离级别(默认的隔离级别)时,一般只锁定事务声明并打开的游标当前引用的行,也就是说该事务一般只锁定当前行,对当 前行以外的记录不做锁定;对其所获取的锁一直有效,直到游标重定位或事务终止为止 。如果游标重定位,原来行上的锁就被释放,并获得游标现在引用的行上的锁 。如果事务修改了它检索到的任何行,那么在事务终止之前,其他事务不能更新或删除该行,即使游标不再位于被更新或删除的行 。

在 DB2 9.7中,在游标稳定性隔离级别下,通过启用“当前已落实”新特性,一个读操作已经不需要再等待该变更落实后再返回值,而是直接返回该行未变更前的值(也就是当 前已落实的结果值,忽略任何可能发生的未落实操作)。不过需要注意的是在可更新游标中存在例外的情况:如果某行基于它自己之前的内容被更新过,当前已落实 结果无法立即返回。

从 DB2 9.7开始,DB2 通过采用完全锁定避免(full lock avoidance techniques)技术,当能够明确获得数据或者页的“已落实”版本时,允许扫描避免使用行级锁。当无法获知索引或行记录是否已落实时,扫描将改为使 用传统的锁定方式。 DB2 通过在行级锁定中增加新的反馈机制,来标识哪些“日志记录”描述了该行的首次修改(从该行的首次修改,就可以获得修改前的数据值,也就是该行的已落实版 本),当发生一个锁冲突时锁管理器将使用该反馈机制直接返回这些日志记录编号。一个当前已落实扫描将用使用该反馈结果,用来从日志(日志缓冲区中或者活动 日志文件中)访问该行的“当前已落实”版本(也就是首次更新之前的结果值)。未提交的插入行在行级锁中是直接被标识的,允许“当前已落实”扫描直接忽略或 跳过该行。

3.11           XML支持

DB2 中实现了关系型引擎与层次型引擎的结合,实现了混合数据库。IBM将此技术称为pureXML技术。在两种数据存储(关系和 XML)的顶部的数据库引擎可以处理 XQuery、Xpath、SQL和 SQL/XML。

DB2 pureXML在以下领域具有显著优势:

存储:DB2 的pureXML 技术将以节点级(而非文档级)粒度存储 XML。在数据库中,物理存储层的主要存储单元是节点。每一页中都存在一个节点,而其它的节点则来自相同或不同的文档。每个节点不仅连结其父节点,还连结其子节点。因此,浏览到某个节点的父项、同级项或子项的效率都非常高,只要下一个引用的节点在同一页,其遍历速度将比指针的遍历速度还要快。 无需重写整个文档即可增加或减少节点,或者将节点重新部署到其它页。

索引机制:管理着数百万的 XML 文档的 XML 应用程序并不罕见;因此要提供高查询性能就要为大量的 XML 数据编制索引。DB2 支持在 XML 列上建立路径特定的索引,因此元素和属性常用作谓词且可以编制跨文档连接的索引。

基本的 XQuery 和 XPath 直接嵌入到查询引擎中。该查询编译器自身是双语的,带有两个可互操作的查询语言解析程序 — 一个用于 SQL,另一个用于 XQuery — 以产生查询图表模型(用于处理关系和 XML 数据)的新变量。因为中间的查询表达法是中性语言,XQuery、SQL 以及 XQuery 与 SQL的组合将编译成同样的中间表达法,经过同样的重写和转化,以类似的方式优化并产生类似的可执行代码。无论使用什么语言来指定查询设计,此过程都将产生最优的互操作查询设计。

DB2中对XML的支持彻底改变了开发基于XML数据交换应用系统的模式,XML的灵活性可以使得开发人员更专注于应用模型,而不需花费太多时间在细节数据的处理上。

另外,使用DB2的纯XML技术,还可以获得低开发成本、降低代码和开发的复杂度、提高开发的效率、易于适应数据和模式的变化、易于快速更新应用程序,降低维护的成本等优点。

3.12           数据库管理和应用开发

针对DB2的管理和应用开发 ,DB2企业版里提供了IBM Data Studio 和 InfoSphere Optim系列等工具,它们可帮助管理成本、增强性能、简化管理和加速应用程序开发。

使用 InfoSphere Optim 解决方案在数据和应用程序的整个生命周期(从收集需求到应用程序退出使用)内对其进行管理。各解决方案提供强大的功能,它们以特定数据管理角色和任务为目标;更重要的是,这些解决方案以无缝方式互操作,从而实现跨角色协作、高生产力和高效率。

IBM Data Studio 和 IBM InfoSphere Optim 工具可帮助您在整个生命周期内管理数据和应用程序。了解工具功能可帮助您为相应任务选择适当工具。

IBM Data Studio 为应用程序开发者提供单个集成开发环境,该集成开发环境可用于创建、部署和调试以数据为中心的应用程序。构建该环境是为了扩展 Eclipse 框架和 SQL 模型组件,该环境组合了 Eclipse 技术和共享库扩展以用于数据库开发。

Data Studio Web 控制台 是一个基于 Web 的工具,用于监视 DB2 for Linux, UNIX, and Windows 数据库的运行状况和可用性。此监视器提供状态信息,例如,数据库是否已启动并运行以及应用程序是否被阻止访问数据库。

IBM InfoSphere Optim Performance Manager 提供了 Web 控制台,可使用该控制台来找出和分析典型数据库性能问题。可查看数据库的运行状况摘要并深入研究以获取更多详细信息。

第4章       DB2高级企业版的增强能力

DB2高级企业版在企业版的基础上,提供了更加强大的数据库功能,例如深度压缩技术、列式存储与压缩、行列安全控制等,最核心的能力是提供了数据库“多活”的集群技术。

4.1        深度压缩技术

DB2 提供独创的行级存储优化技术,它不仅能够极大减少存储关系数据所需的空间和成本,而且还能够提高查询性能。压缩能够节省可观的空间:行业标准 TPC-H 数据仓库基准测试表明,可节省 45% - 69% 的磁盘空间。现在,压缩功能更易于使用。DB2 支持用户在将数据装入数据库时对数据进行自动压缩,这有助于降低维护成本。

除了减少存储的使用,降低成本之外,压缩功能还能够显著的提高性能。使用行数据压缩技术减少了读取数据时的I/O操作,从而降低了相对缓慢的I/O操作对系统性能的影响,提高了整体的性能。甚至对于消耗CPU较多的操作,使用行数据压缩技术仍能够提高性能。

DB2的压缩解技术是将数据行中重复的数据模式映射到一个占用空间较少的符号,从而减少表格数据的总大小。此解决方案采用了一种静态的基于字典的压缩算法,并按行进行压缩。存储优化的优点包括:

  • 大幅减少磁盘的使用,降低总体成本;
  • 减小表、索引和交易日志的大小,便于分布和存放数据;
  • 节省备份所需磁盘空间,便于管理;
  • 提高系统的整体性能;
  • 通过最小化I/O,并提高DB2缓冲池的命中率来加强性能;
  • 包含压缩评估功能来帮助计算使用数据压缩带来的节省;
  • 降低对内存的需求(或者更有效的使用存在的内存);
  • 在数据仓库环境下带来更大的节省。

4.2    异构数据“虚拟”整合

DB2 数据库系统对于各种异构数据源例如Informix、Oracle、Sybase、SQLServer、MySQL等非DB2数据库提供实施透明访问的联邦能力。联邦提供如下能力:

对用户是透明的。用户不需要关心数据具体存放在哪里。

允许访问不同的数据源中存储的数据和内容。

好的扩展能力。联邦能力可以扩展到大量的数据源。 DB2的开发和管理工具也支持使用联邦访问来集成新的数据源。优化器也可以对联邦访问进行优化。使得访问信息更灵活。

丰富的功能。SQL基础的联邦能力提供对标准SQL操作的支持,可以补充后台数据源缺少的功能。

高性能。DB2的SQL基础的联邦能力有业内领先的优秀性能。它通过使用查询优化,并行,内部资源访问,和缓存等技术达到高性能。

两阶段提交的支持。实现在一个交易中完成对多个数据源的更新。这也确保了数据在多个数据源之间保持一致。

联邦能力简化了开发人员的工作, 方便了对多个数据源的访问,这些都给快速、优质的项目实施提供了帮助。 它也通过标准的方式提高了代码的可重用性。

4.3    管理和性能优化高级工具

DB2高级企业版提供了Optim系列数据库性能管理和优化解决方案,主要包括Optim Performance Manager Extended Edititon、Optim Query Workload Tuner、Optim pureQuery Runtime、IBM InfoSphere Optim Configuration Manager。

4.3.1      Optim Performance Manager Extended

InfoSphere® Optim™ Performance Manager Extended Insight 仪表板显示有关整个数据库应用程序系统(包括客户机、应用程序服务器、数据服务器和网络)的端到端数据。监视在您启动事务时开始,在每个组件(例如客户机、网络和数据服务器)处理事务时继续,在应用程序完成处理并生成结果时结束。

监视和分析整个数据库应用程序系统的性能。

使用 Extended Insight,您就可以通过利用工作负载组对来自特定组件的事务进行分组和监视,从而隔离性能问题的来源。工作负载组是基于所定义过滤器的数据库工作负载段。例如,过滤器可以按用户、按应用程序名称、按主机名或按 WebSphere® Application Server 进行过滤。

工作负载组的监视和分析

您可以根据需求创建特定的工作负载组,也可以使用已经激活的预定义工作负载组。工作负载组是在应用过滤器之后仍然存在的数据库工作负载段。还提供了其他预定义工作负载组,您可以将它们激活。

您可以使用详细信息图表和表来监视响应时间的增加,并确定单个 SQL 语句、客户机和分区的问题。您可以找出性能问题并确定问题对工作负载有何影响。

图形工作负载管理控制和监视

如果具有 DB2® Workload Manager V9.5 或更高版本,可以使用 InfoSphere Optim Performance Manager 中的工作负载管理器工具,以应用可实现业务优先级的并行控制。在应用并行控制之后,可以分析现场监视数据,以跟踪资源消耗量、系统容量、响应时间、性能问题等等。如需并行解决方案的简化替代方法,可以应用优先级老化,这样会自动降低长时间运行数据库工作的优先级。

操作系统性能的监视和分析

如果安装针对 Tivoli® Enterprise Portal (TEP) 的可选 InfoSphere Optim Performance Manager 插件,可以获得扩展的操作系统性能数据,并在“系统”仪表板上查看此数据。您也可以从 TEP 控制台内运行 Extended Insight 监视。

其他InfoSphere Optim 产品系列集成

与 InfoSphere Optim 产品系列集成可帮助您解决在 InfoSphere Optim Performance Manager 内找到的问题。

  • 与 IBM® Data Studio 或InfoSphere Optim Query Workload Tuner 集成可以将有问题的 SQL 语句直接传递至查询调整会话,以便可以将查询分析、调整和重新部署至生产。
  • 与 IBM Data Studio 和 InfoSphere Optim pureQuery Runtime 集成使 SQL 语句能够隔离到 Java(或 Java 框架)源代码,并有利于数据库管理员 (DBA) 和开发者之间协作解决问题。使用 InfoSphere Optim pureQuery Runtime,您还可以在不更改应用程序的情况下更改 SQL,从而在等待从开发者或供应商获得应用程序修订时应用紧急修订。

4.3.2  Optim Query Workload Tuner

IBM Optim Query Workload Tuner 提供一系列的调优工具和专家建议,对SQL查询语句进行可视化分析和优化,使得数据库管理员或应用程序开发人员能够在开发阶段分析和解决SQL查询的性能问题,从而减少执行成本提高效能。

  • IBM Optim Query Workload Tuner能够在应用程序开发阶段帮助开发人员调试SQL查询语句,在此阶段发现的SQL性能问题通常情况下易于解决且耗费的成本较低
  • 采用业界通用的Eclipse架构实现,易于操作使用,且可以和IBM Integrated Data Management家族中的其他产品实现无缝结合
  • 易于使用的工具和专家系统能够极大的降低分析和调试SQL性能问题的难度和时间
  • 增强数据库管理员和应用程序开发人员之间的协作,共同解决SQL性能问题

通过使用 Optim Query Workload Tuner,数据库管理员或应用程序开发人员能够:

  • 查看格式化的SQL查询语句
  • 查看带有统计信息和执行成本注释的SQL查询语句
  • 查看SQL查询语句的访问路径
  • 比较不同访问路径之间的差异
  • 获取SQL查询语句改写建议
  • 获取数据库统计信息优化建议
  • 获取索引优化建议
  • 获取访问路径优化建议
  • 生成SQL查询报告

Optim Query Tuner调优专家组件包括:查询语句调优专家(Query Advisor)、访问路径调优专家(Access Path Advisor)、统计信息调优专家(Statistics Advisor)和索引调优专家(Index Advisor)。

查询语句优化专家(Query Advisor

SQL查询语句的不同写法可能导致DB2运行时性能不佳。查询语句优化专家基于一系列的优化规则提供查询重写建议。

访问路径优化专家(Access Path Advisor

DB2对数据的访问方式称之为访问路径。访问路径优化专家针对访问路径中的性能瓶颈,给用户提供相应的警告及解释。

统计信息优化专家(Statistics Advisor

数据的统计信息是DB2优化器的基础。统计信息优化专家能够分析SQL查询语句,发现存在问题的统计信息,并生成收集统计信息的RUNSTATS命令。

索引优化专家(Index Advisor

索引优化专家能够根据SQL查询语句的特征和当前数据的实际状况,设计出满足用户要求的最优索引方案。

 

除了上述调优专家组件外,Optim Query Tuner还提供一组实用的调优工具,包括访问路径图(Access Plan Graph)、查询注释工具(Query Annotation)和查询报告(Query Report)

访问路径图(Access Plan Graph

访问路径图用图形化的方式表现DB2的数据访问路径,展现DB2对存取数据过程中的各个具体步骤。

语句查询注释(Query Format & Annotation

SQL语句查询注释对SQL语句进行格式化整理,并且对SQL语句中所涉及的表(Table),列(Column)以及谓词(Predicate)的统计信息和执行成本给出标注。

查询报告(Summary Report

查询报告将SQL语句所涉及到的表,索引,谓词以及相应的统计信息进行解析整理,给出结构化的完整分析报告。

4.3.3  Optim pureQuery Runtime

IBM InfoSphere Optim pureQuery Runtime 提供了一些优化功能部件,它们旨在提升数据驱动的应用程序的性能并提供 SQL 锁定机制以降低 SQL 注入的风险。 pureQuery Runtime 可与 Java 应用程序一起使用。pureQuery Runtime 也可与 DB2 ODBC/CLI and Microsoft .NET 应用程序一起使用。功能会因应用程序类型不同而有所不同

4.3.3.1   支持 pureQuery 客户机优化的 Java 应用程序

pureQuery 客户机优化不使用预处理器,它不同于对嵌入式 SQL 使用预处理器的 COBOL 编程语言。

客户机优化更改了 JDBC 驱动程序与应用程序的交互方式,因此不需要这些组件,也不必更改您的代码。pureQuery 客户机优化提供以下功能:

  • 安全存储 pureQuery 数据

pureQuery 配置信息、pureQueryXML 数据(其中包括 pureQuery Runtime 使用的 SQL 数据)和捕获的 SQL 数据可以存储在安全位置,并由 pureQuery Runtime 按需访问。pureQuery Runtime 可以配置为从安全位置检索 pureQuery 数据。pureQuery Runtime 可以将从使用 pureQuery 客户机优化的支持 pureQuery 的应用程序中捕获到的 SQL 数据存储在安全位置。

  • DB2 专用寄存器支持

从应用程序捕获 SQL 语句时,pureQuery 客户机优化将跟踪 SQL 语句使用的 DB2 专用寄存器信息。pureQuery 客户机优化将记录常用及可能影响 SQL 语句行为的专用寄存器的专用寄存器值。在某些情况下,当两次发出相同的 SQL 语句时,如果专用寄存器的值在第一次和第二次运行该语句之间发生更改,那么该语句的行为会有所不同。

pureQuery Configure 实用程序选项 -optionsFileForBind 可以根据与捕获的 SQL 语句一并记录的专用寄存器信息来生成包含绑定选项的 StaticBinder 选项文件。选项文件还包含有关 pureQueryXML 文件中的语句集和 SQL 语句的信息和警告,以及专用寄存器信息。

该文件中的信息可帮助您指定一组绑定选项,这样在静态运行某个 SQL 语句时,其行为类似于从应用程序发出并动态运行该语句的行为。当您绑定包含 SQL 语句的 DB2 程序包时,可使用 pureQuery StaticBinder 实用程序指定绑定选项。

  • 轻松管理 pureQueryXML 文件

以下功能部件可帮助您管理 pureQueryXML 文件中的 SQL 语句和语句集:

Configure 实用程序可以按 SQL 语句中的文本(例如,表名或列名)或按专用寄存器使用情况对 SQL 语句进行分组。

对于在指定天数内应用程序没有发出的 SQL 语句,Configure 实用程序可以从 pureQueryXML 文件将其删除。当 SQL 语句从某个应用程序发出时,pureQuery Runtime 可以进行跟踪,并更新 pureQueryXML 文件中的信息。

Configure 实用程序可以在处理 pureQueryXML 文件之前或之后设置语句集的状态。语句集的状态可控制 Configure 实用程序是否尝试修改语句。

Configure 实用程序可以更改 pureQueryXML 文件中 SQL 语句的数据库位置名和模式名。

StaticBinder 实用程序可以在 pureQueryXML 文件中的 SQL 语句绑定过程返回错误时处理该语句。该实用程序可将语句标记为无效,或将其从文件除去。如果语句标记为无效,该语句仍保留在文件中,但不作为可绑定的语句进行处理。可以使用 Configure 实用程序将语句更改为有效可绑定的语句或除去无效语句。

Configure、Merge 和 StaticBinder 实用程序可以对输入 pureQueryXML 文件执行 XML 模式验证。

ManageRepository 实用程序可以生成报告,列出两个 pureQueryXML 文件之间的差异。通过将更新的 pureQueryXML 文件与原始文件进行比较,可以轻松查看对更新文件所做的更改。

4.3.3.2   ODBC/CLI 应用程序和 .NET 应用程序的功能

调用级接口 (CLI) 是用于关系数据库访问的 C 和 C++ 应用程序编程接口。 CLI 使用函数调用将动态 SQL 语句作为函数参数传递。.NET 应用程序包含以任何基于 .NET 的语言编写的应用程序,如 C# 和 VB.NET。

在为连接到 DB2 数据库或 Informix® 数据库的 CLI 或 .NET应用程序启用 pureQuery 客户机优化之后,即可控制应用程序发出的 SQL 语句。例如,如果应用程序连接到 DB2 数据库,那么可以将应用程序配置为针对数据库静态运行 SQL 语句。您可以控制允许针对数据库运行的 SQL 语句。

pureQuery 客户机优化的优点包括:

  • 针对 DB2 数据库静态运行 SQL 语句。
  • 使用工具诊断 SQL 语句的问题,以追溯至应用程序源代码。
  • 使用优化语句替换执行欠佳的 SQL 语句。
  • 通过运行有限的 SQL 语句集来降低 SQL 注入攻击的风险。

对于 CLI 应用程序,您可以运行 SQL 语句,并使用 DB2 命令 db2cli 来验证 SQL 语句。指定准备好 SQL 语句,但不运行以验证 SQL 语句。您可以捕获在 pureQueryXML 文件中运行或验证的 SQL 语句。

4.4    高级复制技术

DB2提供多种不同的方案来帮助您在关系数据库之间复制数据,也包括和DB2之外的数据源之间的数据复制。这两种方案是C复制和Q复制。对于SQL复制,复制源的修改会被记录并被复制到目标系统。对于Q复制,对于复制源的修改将透明的通过WebSphere® MQ消息队列传递到目标系统。

SQL复制

对于SQL复制,复制源的修改将被系统捕获,并且提交的交易数据将被临时存储到数据库的分段(staging)表中。而后,系统会从分段表中读取这些被修改的数据再复制到相应目标表中。通过分段表,修改的数据可以在只读取一次的情况下,按照不同的格式和不同的时间间隔,被复制到多个目标。DB2中包括了SQL复制这个功能。

Q复制

Q 复制是一种复制解决方案,它可以在很短的等待时间内复制大量数据。Q 复制捕获对源表所做的更改并将已落实的事务性数据转换为消息。

不会使数据在表中登台。当数据在源中已落实并由 Q 复制读取之后,就会立即发送数据。消息将通过 WebSphere® MQ 消息队列发送至目标位置。在目标位置,将从队列中读取消息并将消息重新转换为事务性数据。然后事务将通过一个可以保护数据的完整性的高并行性方法应用到目标表。

您可以将 Q 复制用于各种需要已复制的数据的目的,包括故障转移、容量补偿、按地理位置分布的应用程序和卷动升级或其他计划内中断期间的数据可用性。

通过Q复制,可以在较低系统参与和影响的情况下,实现大批量数据的复制。Q复制将捕获到的复制源的改变转换为交易数据消息。数据在被修改后将在尽可能短的时间内被发送,并被Q复制服务器读取。这些数据并不存放在分段表中。消息将通过WebSphere MQ的消息队列发送到目标位置,再转换回交易数据。而后,这些交易将在目标表上被执行,以实现复制。对于每一个目标将存在一个对应的交易队列。

使用 Q 复制,可以通过 Q Capture 和 Q Apply 这两个程序将已落实的事务性数据从源表复制到目标表。

Q Capture 程序

Q Capture 程序读取恢复日志以获取已更改的源数据并将这些更改写入 WebSphere® MQ 队列。对于经典复制源服务器,经典捕获组件读取更改并将这些更改写入 WebSphere MQ 队列。

Q Apply 程序

Q Apply 程序从队列中检索捕获的更改并将这些更改写入目标。

Q Capture 和 Q Apply 程序都使用一组控制表来跟踪它们执行其任务所需要的信息以及存储它们自己生成的信息,如您可以用来查明它们的执行情况的信息。您应先创建这些表,然后再告诉 Q 复制您的复制源和目标是什么。

Q Capture 程序使用的一组控制表称为 Q Capture 控制表。这些表包含有关您的复制源及其对应目标,以及 Q Capture 程序正在使用哪些 WebSphere MQ 队列管理器和队列的信息。这些表还包含可用于检查和监视 Q Capture 程序性能的数据,如有关 Q Capture 程序在恢复日志中的当前位置的信息。

可以运行多个 Q Capture 程序。每个 Q Capture 程序使用自己的一组控制表。与一组 Q Capture 控制表相关联的模式标识使用那些控制表的 Q Capture 程序。此模式称为 Q Capture 模式

Q Apply 程序使用的一组控制表称为 Q Apply 控制表。这些表包含有关目标及其对应源所在位置的信息,以及有关 Q Apply 程序正在使用哪些 WebSphere MQ 队列管理器和队列的信息。与 Q Capture 控制表一样,这些表还包含可用于检查和监视 Q Apply 程序性能的数据。

与 Q Capture 程序一样,您可以运行多个 Q Apply 程序。每个 Q Apply 程序使用自己的一组控制表。与一组 Q Apply 控制表相关联的模式标识使用那些控制表的 Q Apply 程序。此模式称为 Q Apply 模式

SQL 复制与 Q 复制的基础结构比较

SQL 复制与 Q 复制中基础结构的比较

比较点

SQL 复制

Q 复制

捕获程序的控制表的位置

必须在运行 Capture 程序的 DB2® 服务器上为 Capture 程序创建控制表。在大多数情况下,此服务器就是与该程序相关联的源所在的同一个 DB2 服务器。

必须在运行 Q Capture 程序的服务器(DB2 或非 DB2)上为 Q Capture 程序创建控制表。此服务器就是与该程序相关联的源表所在的同一个 DB2 服务器。

每个 DB2 服务器上可以使用的捕获程序数

多个,每个程序具有自己的一组控制表并由那些控制表的模式进行标识。

多个,每个程序具有自己的一组控制表并由那些控制表的模式进行标识。

Apply Q Apply 程序的控制表的位置

您可在任何能连接至源服务器和目标服务器的服务器上为 Apply 程序创建控制表。一般情况下,控制表应该位于运行 Apply 程序的服务器上。

必须在与 Q Apply 程序相关联的目标表所在的服务器(DB2 或非 DB2)上为 Q Apply 程序创建控制表。

每个 DB2 服务器上可以使用的 Apply Q Apply 程序数

多个,每个程序共享一组控制表并由一个称为 Apply 限定符的字符串进行标识。

多个,每个程序具有自己的一组控制表并由那些控制表的模式进行标识。

4.5        复杂集群技术

IBM DB2高级企业版提供最完整的数据库集群方案,既支持非共享架构的面向OLAP分析的数据仓库类型负载的DPF集群部署,又支持共享磁盘架构的面向极高并发的OLTP交易性负载的pureScale集群部署。两种方案中,所有的集群成员都是完全“活动”对外提供服务,最大程度保护和利用客户的投资。在实际选择部署方案的时候,完全根据客户的实际需求和负载特征,进行针对性部署,最大程度的灵活满足负载优化的需求。

第5章       面向典型负载优化的实施方案

5.1     面向交易优化的pureScale集群数据库解决方案

pureScale的设计基于DB2 15年来在System z上运行的架构和成功经验,体现了专门为Power Systems优化的IBM软件技术的优势;

避免系统宕机造成的业务数据无法访问,切换时间快,实验数据显示切换只需秒级计算;

实现Information On Demand,随时可加入系统资源,增加系统性能;管理员可以增加产能,而不需要重新调优或重新测试;

集群对应用和开发人员“透明”,传统应用可以平滑迁移到集群上。

性能提升优势:在系统性能测试中,DB2 pureScale在100余台Power服务器上将整体系统效率提升至80%。事实上,如果采用64台服务器进行测试,DB2 pureScale可以实现90%的系统效率。这些扩展能力为数据库系统扩展的经济性树立了新的标准;

采用集中缓存管理技术减少内部通信,提升性能,并能立刻发现故障等现象;

集群间通讯机制采用RDMA协议,不经过CPU直接访问内存,降低CPU的处理负载,RDMA协议可以由Infiniband或者RoCE万兆以太网支持。

如果其中一个成员出现故障,不会造成其他成员 I/O 阻塞,并且以内存速度恢复运行。

5.1.1    pureScale集群的高可用性

横向扩展的架构不仅为了处理能力的增加。采用这种架构设计的系统在遇到组件故障时可以继续处理事务,从而能够交付更高的可用性。

与分布式平台上的其他产品相比,DB2 pureScale 将可用性提升到了一个新的高度。DB2 pureScale 允许访问所有不需要恢复的数据页面,并且随时可以洞察哪些页面需要恢复,而不需要执行任何 I/O 操作。这是通过集中化 CF 的独特功能实现的另一项重要创新。

每当成员将一个页读取到它的缓冲池中时,CF 都会感知到这一事件并持续对其进行跟踪。任何时候当成员希望更新一页中的行,CF 同样能够感知这一事件。当一个应用提交事务时,成员会将脏页直接写入到 CF 的内存中。此流程允许集群中希望读取这些经过更改的页面的任何其他成员直接从 CF 获取更新。更加重要的是,从恢复的角度来说,如果任何成员出现故障,CF 中会保留该失败成员正在更新的一些页面列表,以及已经完成更新和提交但尚未写入磁盘的页面列表。

任何关系数据库管理系统(RDBMS)的恢复流程首先都需要重新执行任何已提交的事务,以确保磁盘上这些事务的页是最新的(此流程称作redo恢复)。此外,任何数据库服务器都需要撤销任何In-flight的事务,即在故障之前数据写入了磁盘但尚未提交(此流程称作undo恢复)。

在共享磁盘集群中,非常关键的一点是要确保集群中的其他节点没有读取或更新尚未恢复的磁盘中的任何页面(恢复这些页之后才可以对这些行执行新的事务)。这正是 CF 的闪光之处:由于 CF 知道哪些页正处于故障节点的更新过程之中,并且 CF 已经将该节点提交的脏页保存在它的集中缓冲池中,DB2 pureScale 在确定哪些页面需要恢复时不必阻塞其他成员持续处理事务。而其他架构下由于分布式的锁信息则可能需要大量处理时间来确定哪些是需要恢复的。

从较高的层面来看,可以很容易地解释 DB2 pureScale 环境中的这种恢复进程。每个成员都有空闲的进程,但它们都随时准备着处理故障事件。如果某个成员出现故障时,其中一个恢复进程便会激活;既然这些进程已经存在,因此操作系统不必浪费宝贵的系统时间来创建进程,为它分配内存等。此恢复进程会立即将 CF 中的脏页预取到它自己的本地缓冲池中。大部分恢复过程都不需要 I/O 操作,因为需要恢复的页面已经在 CF 的集中缓冲池中了。此外,页预取机制使用轻量级的 RDMA 在 CF 与恢复成员之间实现迅速有效的传输。在这段时间内,所有其他成员上的所有其他应用将继续处理请求。如果它们需要从不需要恢复的任何页面获取任何数据,那么它们可以继续执行自己的事务。因此,它们可以继续从磁盘读取页,因为 CF 已经知道磁盘上的哪些页面是干净的,以及哪些页需要恢复。然后,恢复进程读取故障成员的日志文件,以便于重放必要的事务来重做或撤销故障成员已做的更新。

对于典型的交易工作负载来说,从成员出现故障到故障节点处于更新in-flight的页面可供其他事务使用的时间间隔通常在 20 秒以内。注意,这同时还包括故障检测时间,而某些供应商在提到恢复时间时都排除了这一时间。数据库中的所有其他页面无时不刻(甚至在成员出现故障之后)都是完全可用的。

此外,系统中像 Couple Facility(CF) 集群加速器这样的组件是冗余的。DB2 pureScale 支持双重CF 功能,这样锁和共享缓存信息就可以存储在两个相互独立的位置,以应对主 CF 出现故障的情况。

5.1.2    pureScale集群的高性能和高扩展性

在横向扩展的数据库环境中节省成本的关键是实现真正透明的应用扩展机制。透明的扩展意味着数据库引擎可以为 OLTP 应用提供更大的吞吐量和更快的响应速度,而对数据本地性没有要求。

数据的本地性表示应用所需的数据位于它所连接的服务器上,并且节点之间很少会争用相同的数据页面。在横向扩展架构中,如果采用基于网络的消息架构共享集群中的数据,数据的本地性就显得格外重要。

依靠本地性实现有效扩展的横向扩展架构要求开发人员创建复杂的事务应用来实现集群感知性。集群感知的应用在开发和部署方面不仅更加复杂,而且成本更加高昂,同时当集群发生更改时还要求重新设计应用。一些供应商可能声称它们的架构能运行任何应用,而不需要修改;但是,如果在设计时没有实现某种形式的集群感知性,它们将不能扩展任何应用。

透明的应用扩展意味着应用不需要具备集群感知性便可利用横向扩展架构。DB2 pureScale 是分布式平台上所特有的,其高效性源于对现代网络和硬件架构,以及 pureScale 的集中化锁和缓存机制的利用。

为了减少集群中各节点之间的通信,以便实现锁管理和全局缓存服务,DB2 pureScale 使用 Couple Facility(CF) 集群加速设备(以下简称为 CF)和 RDMA 技术来提供透明的应用可伸缩性。

RDMA 允许集群中的各个成员直接访问 CF 中的内存,而 CF 也可以直接访问各成员的内存。举例来说,假定集群中的某成员(成员 1)希望读取未存储在本地缓冲池中的数据页面。DB2 会分配一个代理(或线程)来执行此事务;然后,代理使用 RDMA 直接向 CF 的内存写入数据,声称自己需要读取某个特定页面。如果成员 1 希望读取的页面位于 CF 的全局集中缓冲池中,则 CF 会将该页面直接推送到成员 1 的内存中,而不是让该成员的代理执行 I/O 操作从磁盘读取它。通过使用 RDMA,成员 1 的代理只需向远程服务器发起一个 memcopy(内存复制)调用,从而避免了成本较高的进程间通信、处理器中断、IP 栈调用等。简单来说,pureScale 允许成员的代理通过执行看似本地的内存复制操作来执行远程内存复制操作。

这些轻量级的远程内存调用,连同集中缓冲池和锁管理设备,意味着应用不需要连接到已经包含数据的成员。集群中的任何成员都可以有效地从全局缓冲池接收数据页面,无论集群有多大。大多数 RDMA 调用都非常迅速,这使得发起调用的 DB2 进程在等待 CF 的响应时不需要让出已分配的 CPU 时间,并且不需要重新调度便可完成任务。举例来说,为了向 CF 通知某行即将更新(因此需要一个 X 锁),某个成员的代理需要执行 Set Lock State (SLS) 请求,也就是将锁信息直接写入到 CF 上的内存中。CF 会确认集群中的其他成员没有锁定这个行,并直接修改请求成员的内存以批准锁请求。

这个 SLS 只需 15 微秒就可以完成整个过程,因此代理不需要让出已分配的 CPU 时间。代理可以持续高效运行,而不需要像其他横向扩展架构那样等待 IP 中断(避免不必要的上下文切换)。对于长时间运行的批量事务等特定操作来说,DB2 代理有必要让出 CPU 时间,而 DB2 会自动决定是否动态让出 CPU 时间。

DB2 pureScale 内置的针对集群成员的负载均衡机制是另一个重要的 DB2 可伸缩性特性。应用不需要具备集群感知性便可利用负载均衡机制。DB2 pureScale 与 DB2 for Z/OS数据共享客户使用了相同的客户端驱动来实现集群负载的均衡特性。

5.1.3    pureScale集群给客户带来的价值

利用DB2 pureScale 数据管理解决方案,带来以下价值:

  • 高可用,持续提供数据访问能力:

避免系统宕机带来的业务损失;并且无需停机便可随时增加新资源,从而减少停机时间、保持数据持续访问能力。

  • 高性能,提升系统整体性能:

在传统的数据库集群技术中,服务器之间经常采用局域网等业务网络资源来进行数据交换;DB2 pureScale采用InfiniBand独立网络进行管理,不会占用宝贵的业务网络资源;并且DB2 pureScale采用RDMA(远程内存直接访问)技术,减少对系统CPU的使用,从而从进一步提升系统的性能。

  • 高扩展,按需进行横向扩展

采用pureScale的“负载均衡”技术,合理分配系统资源,从而避免了单台服务器负荷过重而影响数据访问的情况。并且,最多可加入128台服务器几乎“无限”满足对数据访问的性能要求;

  • 易管理,节省管理及开发、维护成本:

在增加数据库系统资源时,无需人为管理或修改应用程序,pureScale解决方案通过自身集成的IBM Tivoli System Automation技术对系统进行自动管理,从而节省了相应的各种成本。

5.1.4    pureScale数据库集群推荐的硬件平台

服务器

Power7/7+ 全系列服务器

或者IBM X3850X5/X3650M3/4服务器

存储

IBM DS8000/V7000/DS5000/DS3000

或者EMC VMAX

或者HDS VSP

或者NetApp FAS

高速网络

QDR Infiniband网络

或者RoCE网络

更多的硬件配置信息请参看IBM相关信息中心

http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/index.jsp

5.2     面向分析优化的DPF集群数据仓库解决方案

5.2.1    IBM数据仓库整体解决方案概述

IBM利用强大的数据库服务器技术及大量工具的最新特性,实现了跨Linux,UNIX,Microsoft Windows平台的整合环境。它提供了通用的开发接口和用户管理接口,并支持应用开发,数据建模和匹配,SQL转换,OLAP和数据挖掘功能。它为您提供了一个完整的平台,用于功能性、可扩展的报表发布、数据整合以及高效处理的数据仓库解决方案:

IBM数据仓库解决方案整体架构

  1. 提供了无共享架构(share nothing)数据库分区功能(DPF)。允许您定义一种方法,对相同或不同服务器上的存储进行数据分段。这种功能允许同时跨多个分区进行查询,极大地提高了查询性能。此外,DPF 可用来管理通常用在数据仓库中的历史数据的归档和存储。经过业界实践证明,无共享架构的数据仓库成为了行业客户的不二选择。
  2. 提供了强大的数据整合能力,能够满足绝大多数苛刻的数据整合需求所需的功能、灵活性和可扩展性,并且提供了基于同一模型的元数据整合模块帮助客户实现业务元数据和技术元数据的统一管理。
  3. 提供了实时数据整合的能力,如果客户对数据整合的实时性要求较高,IBM可以提供变化数据的实时捕获功能。
  4. 提供了仓库开发工作台,整合了企业级数据建模,OLAP设计和开发,文本分析,数据挖掘并整合了外部数据转换(如IBM Information Server software),数据质量和元数据开发管理。
  5. 具有业务仓库元数据管理和内嵌的应用分析能力。许多供应商也都提供这些功能,但是,当进一步研究时,就会发现只有DB2数据仓库真正的考虑了完整的数据仓库生命周期性,整合性、精致性、易用性。
  6. 可以为数据库管理员、数据架构师、BI设计师和BI部署专家提供一个环境,使他们在这个环境中以内嵌和集成的方式在仓库工程上协同工作。DB2数据仓库通过提供通用开发接口、管理接口、以及协作和团队合作功能以保证从设计到部署的流程整合性。
  7. DB2数据仓库套件提供用户配置选项,它允许组织机构的仓库从小规模开始并循环增大,同时还可以随着业务需求的增长线性地报告环境状况。因此,达到了既满足业务需求的目的,又不降低功能和性能。

IBM数据仓库解决方案由许多应用组件组成,其中包含了一个强大的数据仓库引擎套件、数据整合工具、实时数据获取工具、前端应用分析展现工具、数据挖掘工具等。用户可根据自身的需要选择合适的套件分段分布实施。

 

5.2.2    DPF数据仓库集群特征

IBM为客户提供了一个强大的数据仓库引擎平台,该数据仓库平台解决方案是以IBM DB2 10.1为核心基础,利用其具有强大可伸缩性和非共享的分布式架构,提供了高性能的混合工作负载查询处理能力(既可以高效处理交易(OLTP),又可以高效进行在线数据分析(OLAP)),满足现代动态数据仓库实时数据更新的同时进行深入数据统计、分析和挖掘的需要。大量高级特性使 DB2 10.1 成为一个功能强大的动态数据仓库引擎,这些特性包括数据分区、行级别压缩、多维集群(MDC)以及物化查询表(MQT),其中MQT 和多维集群也有助于提高性能。

5.2.2.1   数据分区技术 (DPF)

DB2 10.1 数据分区技术 – DPF,允许DB2数据仓库数据仓库用户在单个服务器或一群服务器中对数据库进行分区。企业可以灵活地利用 DB2 数据分区,来支持数据仓库环境中常见的特大型数据库以及复杂的工作负荷和更多的并行查询任务。对 DB2 数据服务器进行分区需要 DB2 数据分区功能。

DB2提供了先进的“哈希(HASH)算法”映射数据库的每一条记录到特定的数据库分区中。“哈希算法”使用表中的一列(或一组列)作为分区关键字,得到0至65535的数值。分区图定义了为65536个值中的每一个值分配的特定的数据库分区。

DB2为数据存储提供了灵活的拓扑结构以达到高性能及高并行。每个数据库由一些数据库分区组成,每个数据库分区实际上是数据库的一个子集,它包含自己的用户数据,索引,交易日志及配置文件。在数据库中,管理员需要定义节点组(Node Group)——数据库分区所分布的节点集合。节点组能够跨越为该数据库设置的数据库分区的一部分或全部。在节点组中,还要定义表空间,以说明用来存储表数据及索引的容器(Container)(文件或设备)。在数据库分区中,如果为每个表空间定义多个容器,则数据库管理系统可以利用I/O的并行机制提高性能。

DB2数据库分区的体系结构具有很多优势:

  • 一张数据库表被分布在多个数据库分区上,因此一张大规模数据库表可以大到TB级。
  • DB2在数据定义语言(DDL),数据操作SQL,以及运行时都引用了分区的模式。其分区方法还可以看作为装载平衡的工具(通过修改分区关键字及分区图,各分区中的记录数可以调整)。DB2优化器利用分区的知识来估价不同操作的耗费,从而为每个SQL语句选择最优的执行策略。
  • 数据的分布通过对分区关键字进行哈希算法完成,分区图中提供了每条记录的存放位置。如果在初次分布数据之后,出现了数据存放不均的现象,DB2能够自动分析并更正。DB2可以通过修改分区的分布自动创建一个新的分区图来平均分布当前不均的数据。其中涉及到的数据记录自动移到它新被分到的数据分区。
  • 对于不断增长的数据库,我们可以增加分区(同时增加处理能力),修改分区图来包含这些新的数据库分区,而后系统能够自动的重新分布数据,以达到新的平衡。DB2 UDB提供了这一功能,使得系统具有非常好的扩展性。
  • 处理能力较强的数据库分区可以存放较多的数据,从而在一切非共享的体系架构下可以充分利用各节点的处理能力使其负载均衡。DB2可以用来按比例的将更多的数据分布在具有更强处理能力的数据库分区上。
  • 应用可以调用API找到记录的存放位置,然后将交易送到记录所在的节点。该API也可以直接被交易处理应用来调用,如IBM CICS,Encina,将交易送到适当的节点而提高性能。
  • IBM DB2支持在多个小型数据库表上增加一个UNION ALL VIEW,从而建立一个逻辑上的大表。如果由于硬件等原因,使得对一张大数据表的存储处理变得困难时,我们可以支持将数据分布在多个较小型的数据表中,然后使用UNION ALL VIEW技术来实现一个逻辑大表的组织和访问。透过UNION ALL VIEW,用户可以透明地对View中的多个较小规模的表实现Update、Delete、Insert、Select操作。

5.2.2.2   范围分区和MDC表

DB2表分区和MDC表选项在DB2 Warehouse包中可用,但是在Starter包不可用。这两个功能可以更有效的管理和访问仓库中的数据,达到减少需要管理的工作负载并提高数据仓库的性能和使用。

表分区

表分区是一种数据组织模型,它将表数据按照一个或多个表字段的值分割成多个存储对象,这些对象称为数据块或数据域。每个数据块都是单独存储的。这些存储对象可以存放在不同的表空间中,也可以存放在同一个表空间中,或者混合前面两种情况。所以,表分区提供了简易的表数据roll-in和rollout,简化的管理,灵活的索引定位和更好的查询过程。

如果有以下情况,请考虑使用表分区:

  • 如果表数据roll-in和rollout有利于你的数据仓库
  • 如果数据仓库中有大表
  • 如果你想将数据从以前的DB2版本或其他的数据库产品中移植到DB2 10.1数据库中
  • 如果你想更有效地使用层次存储管理(HSM)方案

MDC

MDC能自动根据纬度并以灵活、连续的方式来聚类表中的数据。MDC可以大大的提高查询性能,特别是对于OLAP和纬度式数据模型。另外,MDC也可以大大的减少数据维护的开销,如插入、更新、删除操作中的重组和索引维护工作。

MDC块数据是基于维度来绑定。例如,图8中显示了一个立方体,其中数据被封锁在国家和颜色这两个纬度里。数据是以每一个单独的维度为单位存放在一个连续的块中,并且只有一个索引路口点指向这个块,而不是以行为单位存放。所以,MDC表将存储残片放入一个块中并最小化每张表索引的大小。这意味着较少的换页I/O操作,从而提高查询性能。

 MDC块数据演示

5.2.2.3   多重分区技术

下图了数据分区特性如何管理多个数据库分区中的分布式数据。每个数据库分区的部分分区表将数据按月分布,MDC块中的表数据按区域分布。反过来,这导致了更少的索引需求,更多的并行查询和直接查询。所以它能提供更高的性能和更简单的管理环境。

5.2.3    DPF方案的技术特点和优势

本方案的整体设计考虑到行业客户的业务需求,系统性能,开放性和扩展性。以下列举的是本方案的一些主要技术特点。

系统技术需求

IBM解决方案特点

成熟产品

本方案采用的软件产品,是业界最成熟稳定的产品之一。

DB2数据仓库索引优化和查询优化技术,使DWE支持着全国最大的数据仓库(广东移动),并在银行和电信业广泛应用。

优异性能

本方案推荐采用的软件平台具有优越的处理性能,保障企业/政府部门的系统响应速度。

在数据库引擎方面,DB2是业界处理速度最快的数据仓库之一,迄今为止仍然保持着世界第一的TPC-H(10TB)最佳性能的记录。

高扩展性

本建议书提供了对硬件扩展性、数据量扩展性和应用扩展性的支持。

DB2数据仓库在设计上对数据量的扩展程度的支持是无限度的。在SMP环境中,经SUN在64 CPU E1000上的测量,可达到90%的扩展性(详细信息参见www.tpc.org)。

数据仓库的三层架构形式,使数据与分析手段分在两个不同层次,因此,即使用户将来的分析手段的不断进步和变化,数据仓库的基础结构和原有数据都能够提供支持.

可靠性

支持Cluster、Standby等双机热备份、联机快速备份、快速加载数据和快速备份数据恢复。

易管理性/易开发性

完整的图形接口允许快速开发和灵活管理。

5.2.4    DPF数据仓库解决方案带来的价值

IBM数据仓库解决方案有助于提高日常业务处理产生的数据价值,帮助您获得最大的信息投资回报,同时还可以帮助您实现:

  • 降低数据分析人员工作的复杂度,提高系统的数据挖掘和分析能力,为管理层提供及时、精确、有效的营销和辅助决策分析;
  • 提高数据仓库的可扩展性与可维护性,降低IT运营成本,提高信息投资回报;
  • 高效率的数据压缩和数据备份技术,不仅降低数据的存储成本,并有效提高数据的安全性与可用性;
  • 更为灵活的数据架构和模型,构建统一的企业业务运营数据模型。

5.3     面向查询优化的列式存储(BLU)数据集市解决方案

DB2从10.5版本开始支持全新的列式存储技术,将传统的行存储和列存储整合在一起。

  • 即时分析

数据分析的有效性和性能经常受限于基础设施,这些基础设施的更新换代往往跟不上数据量增长和变化的速度。DB2及BLU加速器通过已验证的内存列存储技术和高级数据压缩技术相结合的方式,并充分利用硬件的处理能力,将分析型工作负载处理能力大大提升了一步。可以预期的效果是,可以处理更广泛的在线分析型查询负载,性能更佳且更可靠,不再仅仅局限于“内存型”分析系统。DB2 BLU加速器由IBM研究院和开发实验室共同研制,是新一代数据管理理念的代表,其创新包括:

  • 动态内存列式处理,动态迁移未使用数据到外置存储
  • 最佳压缩,保留数据顺序,使用数据前通常不用解压
  • 并行向量处理,支持多核和数据流单指令多数据扩展
  • 数据过滤功能,避免处理无效数据

BLU加速器额外新增了一个存储引擎,并和DB2核心系统集成在一起,以支持按列方式存储的表。这个列存储引擎和传统的行存储引擎并行工作,使得DB2在同一个系统里面能够同时处理按行、按列方式存储的表。如上图所示。这样设计的好处包括:显著提升查询性能,大量节约存储,轻松管理交易型和数据分析型负载。

  • 使用DB2 BLU加速器,典型分析型应用提升8到25倍性能
  • 使用动态内存技术提升性能,降低成本

 

DB2使用高级存储管理方式,获得内存型分析系统的所有好处,避免其他内存型分析系统内存不足时性能急速下降问题。DB2可以使用所有可用内存,并在需要时扩展至磁盘存储及其他资源。如果一个表太大,超过了分配到的内存,DB2将继续处理,无需执行内存和磁盘交换,避免性能急速下降。

 

  • 最佳压缩,获取更深入的洞察力

DB2 BLU集成了内存型分析系统、列式存储和数据压缩等先进技术,可以让您的查询运行速度更快,可以进行更多的业务分析,比其他任何时候都获取更深入的业务洞察能力。高级编码方式使得压缩效率更高。由于压缩编码有序,压缩数据无需解压即可快速进行分析,这使得CPU和内存使用效率更高,I/O大量减少,这也就意味着系统性能更好,存储成本更低。

  • 使用并行向量实现快速处理

 

DB2充分利用硬件的最新优势技术以提升查询处理效率。如SIMD技术,在同一条指令里面执行多项任务。工作负载通过分摊到多个处理器核上大幅提升性能,以帮助业务决策这快速得到业务问题的答案。

 

  • 使用数据过滤技术提高数据处理的效率

 

DB2通过自动探测和过滤技术,跳过和查询无关的大量数据,消除无效I/O,使得数据处理效率更高,系统性能更好。

 

  • 多项易用特性使得IT运维管理的成本更低

 

IBM简化了从数据中获取业务价值的处理流程,同时大幅降低了对IT人员的需求。使用DB2 BLU加速器,和传统的数据仓库系统不同,无需创建和维护索引,无需重整表,以及执行其他日常运维任务。

 

  • 使用列存储和编码式数据压缩,优化计算资源

 

计算友好型按列存储和压缩技术可以大幅存储节约,大量减少I/O,内存和CPU利用率更高。测试表明,相比DB2 10.1版本全压缩方式,DB2 BLU加速器可以再节约1.6到2.6倍存储。客户使用DB2 BLU加速器实际数据压缩比达到10倍以上。

第6章       案例

6.1     某大型国有银行支付系统

随着互联网、电子商务的兴起,第三方支付等新型金融业务模式对传统银行造成了巨大的影响,为了应对新的业务挑战,适应新的市场需要。传统银行也开始大力发展互联网相关业务例如电子支付等,某大型国有银行在电子银行的基础上开发了新一代支付系统,能够满足客户在网上完成煤气、电话、水电费等生活缴费,与商户、第三方支付公司、地方政府等合作,构建一站式缴费平台。新一代电子支付系统必须满足互联网的高并发全天候业务特点,作为全国性的大型国有银行,该行创新性的提出要最大化利用硬件资源,将传统的“容灾中心”资源也利用起来,参与日常生产计算。该行最终采用了IBM的“双中心双活”整体解决方案,硬件平台采用IBM Power小型机平台,数据库软件采用IBM DB2 for Linux, UNIX, And Windows,加上DB2 pureScale集群许可,采用地理分散的部署架构(GDPC),实现了同城“双数据中心双活”的基础架构。整体架构如下:

6.2     某省级农村商业银行新一代信贷系统

农村支农贷款、消费信贷等小额贷款的蓬勃发展,对农村商业银行的信贷系统的性能、稳定性和灵活扩展性都提出了巨大的挑战,为了应对这种高并发压力挑战,该行决定建设新一代信贷系统,把信贷功能从核心银行剥离出来,独立成一个新的完整系统。为了应对性能、可靠性以及未来业务规模迅速扩张的需求,该行信息部要求新一代信贷系统应该从端到端的满足全集群的需求,即从应用服务器到数据库服务器都应该是一个活动的集群,任何一个单点的故障都不能对全局构成影响,避免发生全行级业务中断的事故。为了达到这一目标,该行最终选择了了IBM的整体解决方案,硬件平台采用IBM Power系列小型机,中间件软件采用WebSpere Application Server Network Deployment,数据库软件采用IBM DB2 for Linux,UNIX, and Windows以及pureScale集群许可。

 

文章转载于互联网

联系我们

地  址:北京市朝阳区华严北里甲1号健翔山庄C11
电  话:400 6090 633 / 8285 7738
Email:3uni@3-uni.com/hr@3-uni.com

© 2016 思锐联科技有限公司   京ICP备13022022号