性能sql

版权所有IBM公司2011商标developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第1页,共25developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章我看DB2设计与优化王飞鹏软件工程师IBM陈辉软件工程师IBM张广舟软件工程师IBM成孜论数据库咨询专家作者2011年5月05日本书原汁原味地展示了DB2设计和优化技术,深入剖析了DB2的工作原理.
本书适合DB2数据库设计人员、DBA、数据库性能分析人员、数据库开发人员、运维人员及应用开发工程师阅读和参考,也可用做高校相关专业或培训班的教材.
在此我们推出了本书的前言、第1章和第2章供大家在线浏览.
更多推荐书籍请访问developerWorks图书频道.
查看本系列更多内容数据库是一种生命体,随着周围环境的变化,自身也在迅速地演变,就如同现代社会人们快速的生活节奏一样——吃快餐、拍快照、喝速溶咖啡、做速成培训,连感冒药都要吃速效的.
快速的影响无处不在,DBA们昨日还在问:"你的数据库容量有多大",今天,话题已经成了:"你的数据库速度有多快"数据库市场纷繁多样,有的数据库性能稳定,有的则频频宕机;有的数据库效率非凡,有的则"不堪重负".
这种巨大的反差迫使数据库技术人员停下匆匆的脚步,思考一个问题:高质量的数据库是怎样炼成的本章就从这个话题开始.
developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第2页,共251.
1数据库设计与性能优化随着数据库应用的日益复杂,人们开始使用一种结构化的方法来设计数据库,这种数据库设计方法由一系列阶段组成.
取决于数据库开发模型,这些阶段出现的次数也有所不同.
在瀑布式模型中,这些阶段出现一次;在迭代式模型中,这些阶段会出现多次.
如图1-1所示,本书建议的数据库设计过程可以按照下面的步骤来做.
图1-1数据库设计的一系列阶段(查看大图)首先需要以用户的眼光来看待现实世界的业务,做到真正理解客户的业务需求,这就是通常所说的收集需求阶段;随后业务人员根据业务需求设计概念模型,并且该模型需要和现实世界相对应,这就是概念模型设计阶段;接着进入逻辑结构设计阶段,在这个阶段数据库设计人员使用业务人员的概念设计结果,将其转换为具体数据库的对象结构,例如表、视图等;然后是完成逻辑结构设计后的物理结构设计阶段,需要为逻辑数据模型选取一个最适合逻辑结果的物理环境,例如需要做表空间设计、缓冲池定义等,需要确定I/O、CPU、内存硬件等;最后是实施、运行和维护阶段,这个阶段会将前面物理设计的结果部署在目标机器上进行开发和测试,经过验证后正式上线运行,上线后还需要进行日常监控和维护工作.
实际上DB2性能优化工作贯穿于上述结构化设计的各个阶段中,所以需要用系统化的观点来对待性能问题.
从理论上来看,数据库设计的好坏直接关系到数据库运行的性能,所以在每个阶段都需要对性能需求做全方位的分析和规划,否则,等到了运行阶段真正遭遇性能问题再考虑,就为时已晚.
理论上如此,而从我们为金融、电信行业客户做数据库咨询的实践来看,也证明了上述判断.
现实中数据库开发团队最容易忽视的就是数据库的性能需求,这种前期对性能需求的忽视直接导致了问题定位难和解决难.
为了避免上述问题,我们认为:数据库的性能优化时机虽然主要发生在运行过程中,但数据库的初始设计对性能有着重大的影响,因此本章在介绍我们的优化技术之前,先谈一下我们从开发和咨询实践中总结出来的一个数据库的生命周期各个阶段中需要注意的性能相关事项.
1.
1.
1收集需求收集需求是整个结构化设计过程的基础,也是最困难、最耗费时间的第一步.
这个阶段的目标是准确了解用户的需求.
首先调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界.
随后调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性及完整性要求,最终得到数据流图表达的数据和处理过程的关系.
从方法来看,通常采取自上而下的结构化分析方法,即从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图描述.
ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第3页,共25除了上述功能需求外,性能需求也应该在这个阶段被定义.
通常包括有并发要求的需求、有响应时间要求的需求;数据库容量的需求,例如I/O吞吐能力;系统用户容量的需求;系统运行时间的需求,例如7*24小时不间断运行,或者可连续运行一周或一月.
在真实设计实践中,如何才能获得真正有效的性能需求呢这需要从以下三个方面加以考虑.
1.
性能指标必须量化指标量化应该不难理解,但是有时候有了数字未必就不模糊.
例如常见的一种需求是"系统需要支持5000用户",或者"最大在线用户数为8000".
这些有数字的需求仍然不够明确,因为还需要考虑区分系统中不同业务模块的负载,以及区分在线用户和并发用户的区别.
为便于理解,我们来看一个性能需求的例子,以获得感性的认识.
某个金融行业交易系统的需求如下:系统总容量达到日委托9000万笔,成交9000万笔.
系统处理速度每秒7300笔,峰值处理能力达到每秒10000笔.
实际股东账号数3000万.
这个例子中已经包括如下三个明确的性能需求.
最佳并发用户数需求:每秒7300笔.
最大并发用户数需求:峰值处理能力达到每秒10000笔.
基础数据容量:实际股东账号数3000万.
2.
有实际操作意义一般来说,性能需求要么由集成商提出,要么由客户提出.
对于第一种情况,性能需求不能简单地来源于项目组成员、项目经理或者测试工程师的估计或者猜测,要保证性能需求的提出是有根据的,所使用的数据和计算公式是有出处的.
通常电信、银行、保险、证券及一些其他运营商级系统的客户属于第二种情况,这个时候要保证需求合理,有现实意义,要让客户明白性能是有成本的.
3.
通过沟通,确保相关人员对性能需求理解的一致性相关人员对性能需求的理解不一致是由于参考对象的不同导致的.
例如有的人员根据客户以往的业务情况,来分析客户的业务量;有的人员参考其他规模类似客户的需求;有的人员参考其他同行企业的公布出来的数据;有的人员参考类似行业的应用的需求.
如果相关人员不能对性能需求达成一致,那么会影响后面的验收测试.
1.
1.
2设计概念模型概念模型是按用户的观点来对数据和信息建模,通常用实体-关系图(E-R图)表示.
通过对用户需求进行综合、归纳与抽象,形成一个不依赖于具体数据库管理系统(DBMS)的概念数据模型,但可以转换为计算机上某一DBMS支持的特定数据模型.
概念模型具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识.
除此之外,概念模型清晰、易于理解,是用户与业务人员之间进行交流的语言.
定义实体developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第4页,共25实体成员都有一个共同的特征和属性集,这可以从收集需求阶段收集的基本数据资料表中直接或间接标识出大部分实体.
例如,根据名字表中表示物的术语以及以"代码"结尾的术语,如客户代码、代理商代码、产品代码等,将其名词部分代表的实体标识出来,从而找出潜在的实体,形成实体表.
定义关系关系模型中只允许二元关系,n元关系必须定义为n个二元关系.
根据实际的业务需求和规则,使用实体联系矩阵来标识实体间的二元关系,然后根据实际情况确定出关系名和说明.
这里的关系类型需要明确,是标识关系还是非标识关系如果是非标识关系,是强制的还是非强制如果子实体的每个实例都需要通过和父实体的关系来标识,则为标识关系,否则为非标识关系.
非标识关系中,如果每个子实体的实例都与而且只与一个父实体关联,则为强制的,否则为非强制的.
定义码通过引入交叉实体除去上一阶段产生的非确定关系,然后从非交叉实体和独立实体开始标识候选码属性,以便唯一识别每个实体的实例,再从候选码中确定主码.
为了确定主码和关系的有效性,通过非空规则和非多值规则来保证,即一个实体实例的一个属性不能是空值,也不能在同一时刻有一个以上的值.
定义属性从基本数据表中抽取说明性的名词开发出属性表,确定属性的所有者.
定义非主码属性,检查属性的非空及非多值规则.
此外,还要检查完全依赖函数规则和非传递依赖规则,保证一个非主码属性必须依赖于主码.
以此得到了至少符合关系理论第三范式的改进的全属性视图.
定义其他对象和规则定义属性的数据类型、长度、精度、非空、缺省值、约束规则等.
1.
1.
3设计逻辑结构逻辑结构是按计算机系统的观点对数据建模,主要用于DBMS的实现.
设计逻辑结构首先选择最适合描述与表达相应概念结构的数据模型.
数据模型是数据库系统的核心,主要包括网状模型、层次模型、关系模型等,DB2就是基于关系型数据模型来实现的.
逻辑结构的设计过程就是将E-R图转换为关系模型,即将实体、实体的属性和实体之间的联系进行转化.
这种转换一般遵循如下原则:一个实体型转换为一个关系模式,实体的属性就是关系的属性,实体的码就是关系的键值.
最后,这些关系模型体现在对具体DBMS的表设计上.
表设计:在关系表中,表中的每个数据行都是相关数据值的集合.
一个表的每一列都必须具有对于该表唯一的名称.
数据类型和长度指定对该列有效的数据类型和最大长度.
主键是在一个表上定义的唯一键中的一个,而且该键被选为最重要的键.
一个表上只能有一个主键.
表之间的关系:主要包括一对一,一对多和多对多.
一对一关系在两个方向都是单值的,例如一个经理管理一个部门,一个部门只有一个经理.
一对多关系中,一个职员只能在一个部门工作,对于职员,此关系是单值的.
另一方面,一个部门可有许多职员,对于部门,此关系是多值的.
职员(单值的)和部门(多值的)之间的关系是一对多的关系.
两个方向都是多值的关系是多对多关系.
一个职员可以处理多个项目,而一个项目可以有多个职员.
数据完整性设计:约束使DBMS能够防止不正确的或意外的数据输入表中,从而确保表中数据的完整性.
一共有四种类型的约束.
唯一约束(uniqueconstraint)防止一个值在表中的特定列里出现不止一次.
它还防止一组值在特定的一组列里出现不止一次.
必须将唯一约束中所引用的列定义为非空(NOTNULL).
引用约束(referentialconstraint)用来在表之间建立引用关系,这两个表通常称为子表和父表.
当在父表或子表中插入/删除/更新的数据满足预定义的条件时,就执行这个操作.
表检查约束(tablecheckconstraint)针对一个或多个表列定义检查ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第5页,共25约束,它们可以对这些表列实施指定的规则,使这些列中插入或更新的数据满足检查约束中预先定义的条件.
信息约束(informationalconstraint)是SQL编译器的规则.
完成了数据模型设计后,需要对结果进行优化.
从经验来看,数据模型优化的关键在于确定数据依赖,消除冗余的联系,确定关系模式属于第几范式.
取决于数据库应用是事务型还是分析型,所采用的范式也会不同.
数据库系统从应用上划分为事务性的(OLTP)和分析性的(OLAP).
OLTP(On-lineTransactionProcessing)即事务型应用数据规范化应尽量避免重复,通常采用第五范式(5NF).
而OLAP(On-lineAnalysisProcessing)在做数据规范化的时候允许有重复,通常采用第三范式(3NF).
一般情况下,OLTP系统向数据仓库(OLAP系统)提供源数据,数据仓库将帮助分析数据.
OLTP的特点是,在应用程序中预先定义和优化了大量短期在线事务(INSERT、UPDATE、DELETE).
OLTP系统考虑的重点是非常快地处理查询和事务,从而支持组织的关键任务操作.
支持生产、销售、金融/财务、物流、工资支付和市场营销的ERP、SCM和CRM系统是OLTP系统的典型例子.
OLAP的特点是事务量相当低,查询常常非常复杂,非常专门化,可能涉及聚合.
对于OLAP系统,响应时间是一个有效性指标,因为这些系统的用户通常是业务分析师和执行官,他们需要查看多种业务功能的战略性视图.
由于OLAP数据库与OLTP数据库在应用上有根本差异,所以在逻辑设计上也不同.
为了提高查询响应时间和方便多维分析,OLAP数据库通常设计为维数据库的形式,表的结构采用多维数据集、星型或雪花型模型.
在这些模型中,业务指标(例如成本、收入)存储在事实表中,而分析这些指标所依赖的数据(例如时间、地区、产品、客户)存储在维表中.
关于OLTP和OLAP之间的差异如表1-1所示.
表1-1OLTP和OLAP系统之间的主要差异特点OLTP系统OLAP系统主要用途支持日常操作,控制并运行基本业务任务支持管理、战略规划和问题解决及决策支持需求查询短期事务;相当简单的SQL长期事务;复杂的SQL和分析更新随机更新;访问的行很少连续/大批量更新;访问的行很多处理速度和响应时间响应时间不到一秒响应时间几秒到几分钟数据库模型ER建模;尽可能避免冗余维建模;可以有冗余数据规范化规范化的数据(5NF);尽可能避免重复非规范化的数据(3NF);可以有重复索引少量索引;避免写操作的索引维护成本可以有更多索引;主要是只读操作工作负载的可预测性和调优预先编译的查询;重复执行查询专门的查询;不可预测的负载1.
1.
4设计物理结构物理结构设计是为逻辑数据模型选取一个最适合应用环境的物理部署.
通常根据DB2的特点和处理的需要,包含进行表空间设计、制订数据组织方案、工作负载管理、硬件部署和存储规划等.
逻辑数据模型是数据的理想蓝图,物理数据模型才是对数据的物理实现.
规范化只关注数据的意义,而没有考虑对于访问数据的应用程序的性能需求.
完全规范化的数据库设计在性能方面要受到质疑.
规范化过程最终将相关的信息放入不同的表中,于是应用程序需要从多个这样的表中访问数据.
关系数据库为SQL语句提供了从一个以上的表中访问信息的能力,这是通过连接多个表来完成developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第6页,共25的.
所以这种性能问题的最常见的情况是连接(join)操作.
连接操作可能要消耗大量的资源和时间,这取决于表的数量以及这些表各自的长度.
存储规划首先估计数据库对象的空间需求,随后再选择相应厂商的存储产品.
数据库对象的大小估计不可能做到很精确.
磁盘碎片、可用空间及使用变长列所造成的开销都使大小估计变得十分困难,因为可能的列类型和行长度的范围实在是太广了.
在最初估计数据库大小后,创建一个测试数据库,并用有代表性的数据对其进行填充.
估计数据库的大小时,必须考虑下列各项的影响:系统目录表的空间要求用户表数据的空间要求长字段数据的空间要求大对象(LOB)数据的空间要求索引的空间要求日志文件的空间要求临时表的空间要求另外,物理设计中需要考虑数据组织方案,DB2数据库提供了一种三级数据组织方案.
CREATETABLE语句的每个子句都包含一种算法,指示应如何组织数据.
下列三个子句演示了可以任意组合在一起使用的不同的数据组织级别.
数据库分区(DPF):DISTRIBUTEBY用于将数据均匀地分布在数据库分区上,以启用查询内并行性并平衡每个数据库分区上的负载.
表分区(TablePartition):PARTITIONBY用于对同一个数据分区中具有类似单维值的行进行分组.
多维集群(MDC):ORGANIZEBY用于对同一表扩展数据块中在多个维上具有类似值的行进行分组.
在一个表中,可以组合每个数据组织方案中使用的子句来创建更先进的数据组织算法.
每个子句可以单独使用,也可与其他子句结合使用.
例如可以通过组合使用CREATETABLE语句的DISTRIBUTEBY和PARTITIONBY子句,可以在跨多个表空间的数据库分区之间分布数据.
在物理设计中,最重要的是需要完成表空间定义.
表空间是一种存储结构,包含表、索引、大对象和长类型数据.
有两种类型的表空间,分别是系统管理的空间(SMS)和数据库管理的空间(DMS).
DMS表空间与SMS表空间之间的差异在于,对于DMS表空间,空间是在创建表空间时分配的;对于SMS表空间,空间是根据需要分配的.
在创建表空间时,需要为表及数据指定存放容器,这里容器可以是目录名、设备名或者文件名.
为了提供改善的性能和更灵活的配置,单个表空间可跨多个容器.
在同一个物理磁盘上创建多个容器是可以的,但是为提高性能,每个容器应使用不同的磁盘.
关于这方面的详细介绍,请参阅本书第4章相关内容.
DB2数据库创建完毕后,至少包含以下三个表空间:一个目录表空间,它包含该数据库的所有系统目录表.
此表空间称为SYSCATSPACE,它不能被删除.
IBMCATGROUP是此表空间的默认数据库分区组.
一个或多个用户表空间,它们包含所有用户定义的表.
默认情况下,会创建一个表空间USERSPACE1.
IBMDEFAULTGROUP是此表空间的默认数据库分区组.
一个或多个临时表空间,它们包含临时表.
临时表空间可以是系统临时表空间或用户临时表空间.
ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第7页,共251.
1.
5实施、运行和维护阶段运用DB2提供的工具,根据逻辑设计和物理设计的结果,建立数据库,编制与调试应用程序,组织数据入库,并进行试运行.
在试运行阶段来验证设计是否满足了需求,并做必要的调整.
经过试运行后,数据库应用系统即可投入正式运行.
在数据库系统运行过程中必须不断地对系统及工作负载进行性能监控、诊断与优化.
1.
2性能问题在实践中,应用系统运行一段时间后,用户通常会报告系统变慢,例如处理查询或者事务花费了过长的时间,或者系统在某些时段变慢.
如果在数据库设计的过程中非常清晰地定义了性能需求,那么很容易确定应用或者系统是否有性能问题.
相反,如果没有定义性能需求,那么就不容易为性能问题进行定量分析.
1.
2.
1什么是性能问题性能问题比功能性问题难解决.
根本原因在于根据症状不容易找到问题的根源.
例如发现系统变慢或者有大量的锁超时现象发生,问题的根源是过时的统计信息导致优化器选择了错误的访问计划从而引发表扫描,这是很不容易定位的.
另一方面,性能问题往往是断断续续发生的,不容易被捕捉.
那么什么是性能呢性能是一个系统在某一特定工作负载下所表现出的行为.
一个工作负载由一系列来自应用的对系统的请求组成.
通常认为一个系统的资源例如存储、CPU和内存等越多,资源被调度得越有效,能处理的工作负载就越大.
换句话说,性能受两个关键因素的影响.
其一是系统可用资源,其二是这些资源是如何被使用和共享的.
性能的好坏可以通过下面三个指标定量描述.
系统响应时间:数据库服务器收到应用请求后完成处理并返回给应用总共所消耗的时间,它反映了服务器的处理速度.
吞吐量:通常用每分钟处理的事务数(TPM)来计算,这个指标反映了系统的事务处理能力.
资源利用率:数据库服务器在处理事务或者查询的过程中,系统资源包括CPU、I/O及磁盘的使用情况,这个指标反映了系统资源是否被服务器有效利用.
1.
2.
2为系统做性能基准测试制订性能优化目标之前,首先需要对系统做基准测试(BenchmarkTest,BMT).
基准测试通常会在特定条件下对选择好的工作负载进行测试,随后将结果和标准硬件最大阈值进行比较,例如每秒钟I/O吞吐量和执行的事务数.
如果在同等配置条件下,当前工作负载的性能结果接近标准参数阈值,则说明当前已无须优化,否则说明还有较大的优化空间.
另外一种情况是,在系统或应用没有改动前做基准测试,等改动后将再次测试的性能值和改动前进行对比,以确认性能变化情况.
例如在开发阶段,应该使用基准测试来确定应用程序是否出现性能倒退.
那么什么是基准测试呢基准测试指通过设计科学的测试方法、测试工具和测试系统,实现对测试对象的某项性能指标进行定量的和可对比的测试.
例如对DB2数据库的查询响应时间和事务处理能力等方面的性能指标进行基准测试.
基准测试的三大原则是可测量、可重复和可对比.
其中可测量developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第8页,共25是指测试的输入和输出之间是可达的,也就是测试过程是可以实现的,并且测试的结果可以量化表现;可重复是指按照测试过程实现的结果是相同的或处于可接受的置信区间之内,而不受测试的时间、地点和执行者的影响;可对比是指测试对象的测试结果具有一定关系,即测试结果的大小直接决定性能的高低.
基准测试能帮助你理解数据库在不同条件下的响应情况.
这种条件可以是配置参数更改,也可以是一个应用的新版本发布,这个时候可以对因条件的变化而导致的性能变化做定量分析.
基于每个用户或某个事务基准,你可以为整个程序或者某一个特定的工作负载例如死锁处理机制、DB2实用程序性能、不同的数据加载方式、读写速度等设计不同的测试场景.
你可以按照常规方式启动所有应用,随后逐级限定在某个可能问题源头.
这个时候,就可以为这个问题源头开发特定的测试用例.
在这个特定的测试用例中,不需要模拟整个应用来获得有价值的信息,只需要从最简单的评估开始,随后根据需要逐渐增加复杂度.
基准测试通常是应用程序开发生命周期的一部分,应用开发人员和DBA通常都需要参与进来.
从最佳实践来看,通常可以运行多个迭代来获得应用程序的最佳或次佳性能,而调整系统配置、SQL语句、索引、表空间和硬件配置等可以放在不同迭代之间进行.
综上所述,一个好的基准测试具有下面的要求:测试是可重现的.
每个迭代起始于相同的系统状态.
没有其他的应用在系统后台运行.
软硬件测试环境和生产环境基本一致.
1.
2.
3制订性能优化目标根据成本效益分析(Cost-BenefitAnalysis)模型,付出的努力永远要和获得的收益取得平衡.
优化无止境,没有目标就不知道何时停止研究更好的解决方案,因为性能是有时间和金钱成本的.
当DBA考虑需要多少时间和金钱用于性能优化时,要评估一下所花费的时间成本和金钱成本.
性能优化通常可以解决的问题包括减少响应时间和提高事务吞吐量.
在具体实践中,可以通过上一节描述的基准测试方法找到系统诸如响应时间和吞吐量的阈值.
这个阈值具有如下重大意义:方便用来对性能目标进行量化.
例如需要将系统优化到95%的阈值能力.
方便了解当前系统性能状态.
例如增加了一个新模块,容易判断新的模块对整个软件系统的性能影响.
方便决定是否还需要进一步的优化.
例如,现在系统性能已经到达90%以上阈值,考虑到边际效应,以后的优化只能产生越来越少的效益.
最后,必须指出的是如果所有的优化方法都不太有效,这个时候,就需要重新调整优化目标和预期.
为了取得更加显著的性能提高,需要有针对性地增加存储,使用更快的CPU、更多的内存、更快的网络连接,或者三者的组合.
1.
2.
4把问题分类性能优化的背后实际上是业务需求驱动的.
首先需要从业务角度将问题分类并识别结果,即从业务角度确定问题,设定每个问题的优化目标,并设定每个问题的优先级.
随后从系统角度确定原因,ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第9页,共25弄清楚时间花在何处时间是如何被消耗的如何减少时间耗费同时要考虑到不同问题之间的连带效应,避免解决一个问题的同时带来新的问题.
在为性能问题分类前,我们可以从考虑下面的问题入手,这样非常有助于后续工作的开展,例如:是否有性能降低,与什么相关我们的"基准"是什么一个系统的性能看起来在随时间流逝下降了还是与一个不同的系统或不同的应用比较下降了数据量是否增加了所有的硬件都运行正常吗性能下降是什么时候发生的在另一个工作负载运行之前、之中还是之后性能下降是否周期性地发生甚至如果这个任务没有直接和数据库相关,它也可能由于消耗网络或者CPU资源影响数据库性能.
性能下降的前后关系有什么变化吗通常是添加了新硬件、或应用程序被更改了、大量数据被加载、或者更多的用户访问这个系统.
能不能向数据库管理员、应用程序开发人员以及架构师多了解一些业务和系统情况因为DB2服务器几乎总是硬件、其他中间件和应用程序这样复杂环境的一部分.
1.
3使用PAT方法学解决问题性能问题在一定程度上是可以避免的.
但是在实际生产环境中,性能问题的定位和解决是非常复杂的.
这导致当性能问题发生的时候,很多不熟悉性能优化的技术人员往往会陷入恐慌,甚至会做随机的调整.
然而他们这样做定位到根本原因的可能性仍然非常低,甚至会让问题变得更糟糕.
1.
3.
1什么是PAT方法学从某种角度说,DB2数据库性能优化和诊断是一门艺术,因为这需要较长的学习时间和经验积累,特别是方法学的创新.
本书写作团队在实践过程中,总结了一套系统的方法学来进行性能调优和故障诊断.
这套方法学命名为基于PAT(ProblemAddresingTree)方法学,已经在电信和金融行业客户的数据库性能优化中得到了检验,证明是行之有效的.
PAT方法学是一种系统化的性能诊断和优化方法,首先以高质量的数据库设计为前提,以数据库正确配置为基础,当出现性能问题时,监控应用或者系统来确定瓶颈,最后做有针对性的调整,这里的调整包括更改配置、修改SQL语句、更改应用或调整数据库设计.
所有这些内容都反映在PAT决策树上.
PAT决策树的根节点用来指明性能问题分类;非叶节点用来存放监控和诊断信息;叶子节点给出了具体的优化方法.
这些方法和本书的相应章节紧密结合在了一起,这是PAT决策树一个最重要的特点.
关于PAT决策树的具体内容,读者可以在本书的附录中找到.
1.
3.
2PAT方法学优化策略对一个方法系统来说,首先要考虑的就是策略问题.
我们在性能优化实践中总结的优化策略共分为如下四步:1.
问题监控2.
配置检查3.
设计检查developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第10页,共254.
性能优化这样一来解决所有数据库性能问题的步骤都得到了统一,即按照上述顺序检查,各个问题的区别只是检查的结果有所不同.
例如有些问题在第二步就查出问题了,有些没有而是在第三步查出问题,但最终都是通过第四步完成优化的.
另外,我们在为金融电信行业客户讲解PAT优化策略时,同时提出了下述四项指导原则,取得了非常好的实践效果.
这四项指导原则是对上述优化策略的有益补充.
1.
数据库性能问题监控针对性原则在定位应用或系统瓶颈时,需要对数据库进行监控,要针对业务分析和系统分析后的性能问题进行有针对性的监控,这是提高优化速度的关键所在.
在本书的第7章有数据库监控的详细介绍.
通常DBA安装好DB2数据库后,DB2可以自动检测资源并做相应配置.
但是我们还是必须弄清楚系统运行情况及DB2对资源的使用情况,例如内存使用情况、CPU占用情况、I/O吞吐量以及网络吞吐等.
换句话说,对DB2数据库进行有效监控,当系统变慢或出现资源瓶颈后能快速找到线索并定位,是确保数据库系统稳定、可控运行的必要条件.
那么如何去监控DB2数据库所在平台如何监控DB2这可以利用操作系统和DB2本身提供的一些工具来实现.
下面就从如下几个方面来阐述.
(1)系统监控DB2服务器支持在多平台运行,通常情况下,很多系统具有类似的架构,所以所使用的工具在不同的平台上可能略有不同,但本质原理是一致的.
例如使用vmstat工具对磁盘、内存、CPU监控;使用iostat工具对I/O、内存监控等.
一些常见的系统监控工具如表1-2所示.
表1-2常见的系统监控工具工具平台监控内容IostatUNIX、Linux磁盘Vmstat/sarUNIX、LinuxCPU、内存、磁盘PerfmonWindowsCPU、内存、磁盘NmonAIXCPU、内存、磁盘NetstatUNIX、Linux网络TopLinuxCPU、内存(2)快照监控(snapshotmonitoring)可以使用快照监控工具捕获数据库、已连接上的应用在任何指定时间的信息.
通常快照用来诊断数据库系统的状态,有助于观察运行趋势及预见潜在问题.
快照数据可以通过下面的方式获得.
1)getsnapshot命令:格式化文本输出,可以捕获当前数据库管理器、数据库、缓冲池、表和表空间等快照信息.
2)管理视图(AdministrativeViews):提供了基于SQL的接口来访问快照信息,但不适用于跨分区查询.
ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第11页,共253)表函数(TableFunctions):比管理视图更加灵活,更适合于跨分区或者指定分区快照信息收集.
(3)事件监控(eventmonitoring)事件监控用来收集当指定事件发生时数据库和已连接上的应用的快照信息,例如语句、锁等.
事件监控器使用DDL语句来操作,其状态可以是激活或者去激活.
只有状态是激活时,才启动信息收集.
(4)db2pd最方便的性能监控工具就是db2pd了.
db2pd的最大优点是信息获取非常快,并且不需要消耗数据库引擎资源.
2.
数据库配置优先原则在进行系统分析确定性能问题的根源时,要优先检查数据库配置,包括DB参数、DBM参数以及DB2环境变量等.
如果发现是配置的问题,那么就可以优先通过调整配置来低成本地解决问题.
配置的目标是能够使得数据服务器得以高性能运行,以提高投资回报率.
从实际生产环境的例子来看,大多数DB2系统都经过了性能的演变.
为了达到良好性能,不论出于硬件还是软件的观点,我们都需要从软硬件配置方面来保障.
因此,在前期花些时间去考虑基本的配置指导方针和建立健全系统监控这样的做法,将使你对处理许多可能出现的典型性能问题,有充分的准备.
(1)硬件配置对于系统性能,CPU的能力是各项配置中一个最主要的独立变量.
因为所有其他的硬件配置取决于它.
例如一个新系统需要多处理50%的用户请求,每个用户运行的SQL的复杂度类似现有系统,那么就可以合理地假设需要增加超过50%的CPU能力.
一旦我们对CPU需求有了很好的认识并正确选型,那么硬件配置的其他方面例如内存、磁盘等就能基于CPU的处理能力完成选择.
在一个数据库系统中,内存的主要作用是避免I/O,归结为一点,拥有更多内存的系统能工作得更好.
幸运的是,在过去几年中内存的成本已经有了显著的下降,并且系统拥有几十到上百GB的内存已经不再罕见了.
通常,对于大多数应用程序每个处理器内核拥有4~8GB内存是比较合适的.
虽然CPU的发展在过去十年在速度上有了惊人的增长,然而磁盘的发展相对落后.
尽管磁盘的寻道时间和数据传输速率已经有了相当程度的提高,但是仍然无法跟上CPU的速度.
因此为了达到系统总体性能需求,使用多个磁盘比之前任何时候都要重要,尤其是对于那些需要驱动繁重随机磁盘I/O的系统.
很多时候,诱惑来自于使用最低的磁盘数目来存放所有的数据,然而这通常会导致较差的性能.
对于使用RAID存储的情况,凭经验估计合理的配置是每个处理器内核最少10~20个磁盘.
为DB2事务日志分配专门的非共享的磁盘是很好的实践.
这是由于日志的I/O特性与DB2容器有很大的不同.
日志I/O与其他类型的I/O的竞争能导致日志成为一个瓶颈,尤其是对于那些有大量行写入行为的系统而言.
(2)操作系统配置developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第12页,共25DB2数据库通常运行在包括AIX、Solaris、HP-UX、Linux等多平台上.
为了取得比较好的性能,对于不同的平台需要做不同的参数调整.
对于AIX平台,需要调整AIO、VMO等和CPU、磁盘有关参数的默认值;对于Linux平台,需要调整和共享内存有关的一些内核参数;对于Solaris或HP-UX上运行的DB2,根据系统的大小,利用db2osconf工具来检测和推荐内核参数.
关于操作系统配置的具体技术细节,可以参考本书第7章DB2配置优化与监控的相关部分.
(3)DB2注册变量、DBM和DB参数配置在DB2数据库中,有DB2注册变量、实例级别配置参数(DBMCFG)和数据库级别配置参数(DBCFG).
通过对这些参数进行手工或者自动(DB2AUTOCONFIGURE)调整,可以提升数据库性能.
关于DB2参数的具体技术细节,可以参考本书第7章的相关部分.
(4)负载管理配置DB2工作负载管理是为了满足不同应用程序的业务优先权,并通过为不同的业务优先权定义的DB2服务类很好地反映出来.
负载管理的基本概念包括工作负载、服务类、阈值、工作活动集和监控.
DB2工作负载作为主要控制点,基于工作提交者源,并通过连接属性将工作路由到服务类.
DB2服务类是所有进行中的工作活动的主要资源控制点.
DB2阈值基于预测性和响应性元素,为发生在数据库或服务类中的所有活动提供数据库行为控制.
关于DB2工作负载管理的细节描述,读者可以参考本书第6章DB2工作负载设计.
总结来看,DB2工作负载管理具有下述的几大优点:提供稳定,可预测的执行环境.
对监控活动任务提供轻量化及细粒度的解决方案.
更好的资源管理.
更好的请求管理.
提高性能优化专家对数据库系统的高级分析能力.
3.
数据库设计高质量原则考虑周详的数据库设计使得为DB2应用或系统提供最佳性能提供了保证,这需要在应用系统的早期就开始加以注意.
因为数据库系统设计开发阶段是DB2应用优化的最佳阶段,也是主动优化阶段,能达到以最小成本获得最大性能增益的目的.
凡是在DB2数据库设计开发阶段,创建一个设计优良的数据库,可以获得最小的系统开销,能从根本上大大提高应用系统的整体性能,这对于以后的数据库性能调整和优化都有很大的益处.
从数据库设计实现过程来看,首先需要明确性能需求,做好性能规划,随后从业务角度做好逻辑设计,最后完成数据库物理设计.
系统上线进入运行维护阶段出现性能问题时,如果确认是设计上的问题,就尽量通过调整设计来解决.
具体设计细节参考本书第3~5章的相关设计部分.
4.
数据库优化平衡性原则在确定性能问题的根源后,按照本书第8~11章对性能问题进行针对性优化;同时,根据成本效益分析(Cost-BenefitAnalysis)模型,我们不能片面追求优化的高性能,因为到了最后,取得的性能和所要付出的成本是强关联的.
在当前范围内,只要能满足性能需求即可.
ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第13页,共251.
3.
3使用PAT方法学性能问题往往分为两大类:影响了整个系统的问题和只影响了部分系统的问题.
影响了部分系统的情况如某一特定应用或SQL语句.
我们在研究的过程中发现一种类型的问题可能转化为另外一种类型的问题,或者相反.
一个常见的情况是:造成整个系统性能降低的只是一个单独的语句,或者是整个系统的问题只是在一个特定的区域被发现.
我们在优化实践中注意到,找到性能降低原因的方法就是从高层入手并逐次向低层推进来排查定位.
不论对于整个系统或者局部的问题,这个定位过程都可以使用本书提供的PAT决策树进行.
为了方便读者使用这一方法,我们将生产环境中遇到的性能问题进行了归纳整理.
如图1-2所示,我们把引起性能问题的原因归结为6种类型.
磁盘瓶颈:磁盘I/O是数据库性能的瓶颈.
CPU瓶颈:CPU是数据库性能的瓶颈.
内存瓶颈:内存是数据库性能的瓶颈.
网络瓶颈:客户端和数据库服务器之间,或者数据库DPF节点之间存在网络瓶颈,从而导致了数据库性能变慢.
"懒惰系统":数据库运行变慢,但没有磁盘、CPU、内存或网络瓶颈.
性能上限(高级技术优化):数据库性能已经达到了硬件上限,软件也没有继续优化的空间,这时候可以考虑使用数据库高级技术.
在本书的第四部分中,会向读者介绍如何使用DB2pureScale海量事务处理技术和solidDB高速缓存技术来提升数据库系统性能.
为了方便读者能快速掌握上述6种类型,下面几节我们结合PAT决策树来详细探讨在实际的性能优化中这6种问题是如何处理的.
图1-2性能瓶颈种类(查看大图)1.
3.
3.
1问题SQL语句优化磁盘瓶颈和CPU瓶颈的相当一部分原因最后归结为问题SQL语句的优化,所以首先我们先讲解一下问题SQL语句的优化方法,作为后面内容的技术储备.
另外关于SQL语句优化的细节方面,可以参阅本书第8章有关内容.
如图1-3所示,问题SQL语句包括动态语句和静态语句,其优化方法包括手工方式和DesignAdvisor工具方式.
使用DesignAdvisor工具方式可以非常方便地为SQL语句或者工作负载设计索引,或者developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第14页,共25使用DB2高级技术例如MQT或MDC来加快SQL语句的执行.
关于手工方式和工具方式的具体用法,读者可以从图1-3中的PAT叶子节点中找到相应的章节进行深入学习.
1.
3.
3.
2磁盘问题磁盘瓶颈的基本症状是:在vmstat或iostat结果中,出现较长的I/O等待时间,较低的CPU利用率(25%~50%),磁盘较高的繁忙程度(80%).
如果存在磁盘瓶颈,我们首先需要找到繁忙设备所在的文件系统路径.
可以按照下面的线索确定这些繁忙文件系统的路径:1.
数据表空间容器为了判断是什么导致容器成为瓶颈,我们需要判断都有哪些表存储在这个表空间而且最活跃.
找到了之后进一步向下钻取,我们需要找出是什么造成了这个表的高度活跃.
是动态SQL语句造成的高度活跃还是静态SQL语句导致的高度活跃如果我们能确定并得出一个或多个SQL语句导致了I/O瓶颈,下一步我们需要确认这个语句是否可以被优化以降低I/O.
例如,这个语句是否发起了一个不期望的表扫描这可以通过用db2exfmt检查查询计划来验证.
另一方面,如果受到影响的表非常小,那么增加缓冲池大小对减少I/O和消除瓶颈或许已经足够了.
整个分析过程如图1-4所示.
关于问题SQL语句优化,请读者参阅上一节.
图1-3问题SQL语句优化树(查看大图)ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第15页,共25图1-4数据表空间性能优化树2.
引表空间容器如图1-5所示为PAT树分析过程,表空间中有什么索引其中哪些索引是高度活跃的找到后,可以尝试这样的方法,例如增加缓冲池的大小,或为索引指定专门的缓冲池,可能足以降低I/O来消除瓶颈(见本书4.
5.
2节"缓冲池设计"和7.
1.
3节"DB参数优化").
但在OLAP环境中的索引通常非常大,分配足够的缓冲池来消除I/O不大可能,这种情况下,通过增加额外的容器以提高磁盘I/O带宽来消除瓶颈或许更加有效.
图1-5索引表空间优化树(查看大图)3.
临时表空间容器developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第16页,共25如果这个繁忙的容器属于一个临时表空间,这个临时表空间的I/O繁忙是否是由于排序溢出这是由于排序从设计的内存缓冲溢出必须使用一个临时表空间来代替.
是由于庞大的中间结果导致的吗如果是,这表明通过大量的临时数据的物理读写.
分析诊断过程如图1-6所示.
4.
存储设计问题有时却会出现这种情况,我们看不到任何明显的原因.
没有繁忙的表,没有繁忙的索引,没有繁忙的SQL语句.
可以调查如图1-7所示的几种可能的原因,来分析诊断过程.
图1-6临时表空间容器优化树(查看大图)图1-7存储设计问题优化树(查看大图)5.
日志存储日志磁盘瓶颈能对系统性能产生更大的影响.
这是因为写日志的速度能影响系统中所有的INSERT/UPDATE/DELETE语句.
另外日志瓶颈也会造成事件监控器更长的提交时间,造成应用程序快照中更多的代理程序处于"commitactive"状态.
建议在数据运行中,日志不和任何"active"对象共享磁盘.
一旦我们确认日志配置遵循了上面描述的原则,或许就需要通过提高日志系统的能力来解决问题.
要么通过添加额外的磁盘到日志RAID队列中,要么提供一个专门的或者升级了的磁盘缓冲控制器.
另外对DB2诊断日志db2diag.
log繁重的磁盘写入能造成整个系统的性能下降.
在多分区环境中所有分区都写入同样的诊断日志路径,它一般是通过网络共享NFS文件系统.
解决这个问题最简单的ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第17页,共25办法就是为每个分区指定一个单独的诊断日志路径(并指定一个专门的诊断日志文件).
关于日志存储的整个分析诊断过程如图1-8所示.
图1-8日志存储问题优化树(查看大图)1.
3.
3.
3CPU问题CPU瓶颈表现在两个方面:用户态CPU瓶颈和系统态CPU瓶颈.
一种是处理器正在运行操作系统内核以外的软件比如DB2应用程序或者中间件,导致用户CPU时间增多.
一种是在运行操作系统内核的时候导致CPU时间增多.
这两个在数量上是分开显示的,并且根据它们之间的分布情况,可以帮助我们找到CPU瓶颈的原因.
用户态CPU和系统态CPU时间比率在3:1到4:1之间是正常的.
如果在有瓶颈的系统中,用户和系统时间比率高于这个区间,我们应该收集调查用户CPU时间增加的原因.
1.
用户态CPU瓶颈对用户态CPU瓶颈的诊断分析如图1-9所示.
要定位DB2服务器上造成用户态CPU瓶颈的原因,首先通过监控工具找到对应的动态SQL语句和静态SQL语句.
随后从下面几个方面去考虑:一个频繁运行的对缓冲池中的表扫描能消耗令人吃惊的CPU时间.
如果应用程序执行一个SQL语句却只会用到一小部分产生的数据,使用OPTIMIZEFORnROWS(OFnR)和FETCHFIRSTnROWSONLY(FFnRO)子句能帮助减少所有类型的资源消耗,也包括CPU消耗.
获取和释放锁的过程也会消耗大量的CPU时间.
比起使用参数标记,许多应用程序通过连接语句片段和字符串值来构建它们的SQL语句,这会消耗CPU时间.
为了尽快完成工作,DB2实用工具被设计成扩展良好并充分利用系统资源.
就是说在一个实用工具正在运行时,可能CPU使用率会有显著的增加.
Load和runstats就是实用程序的很好的例子,它们经常导致高CPU使用.
当一个系统临时表不再需要然后可以删除的时候,DB2必须从缓冲池中移除不再需要的页面.
如果这经常发生,而且如果临时表和普通用户数据共享缓冲池,会导致耗费额外的CPU时钟周期来解决冲突.
developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第18页,共25图1-9用户CPU瓶颈优化树(查看大图)2.
系统态CPU瓶颈在大多数CPU受限的环境中用户CPU往往是决定因素,不过系统CPU有时也能成为决定因素.
如图1-10所示,系统CPU瓶颈可以从以下方面入手:系统CPU时间高的一个原因是与之相关的DB2在操作系统(OS)中上下文切换率过高.
一个上下文切换是OS用来切换它需要处理的不同任务.
上下文开关被系统中不同的规则触发.
然而如果上下文切换得太频繁,它们自己最终可能导致消耗大量CPU时间.
在DB2系统中导致上下文切换率高的原因是大量的数据库连接.
设备中断也会导致CPU时间高.
一次中断的成本并不高,然而如果中断的频率太高,系统的总的负载会非常高.
在一个DB2数据库系统中,我们通常尽可能地让系统有很少的空闲内存.
不幸的是,如果我们过多地分配了系统内存,使用了超过系统物理内存的总量,页清除操作将造成系统CPU开销.
图1-10系统CPU瓶颈优化树(查看大图)ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第19页,共251.
3.
3.
4内存问题如果没有充足的内存,数据在填满缓冲后就将转向I/O,在这个过程中常常会造成磁盘瓶颈.
另外,内存也被用来存储元数据和运算结果,比如SQL查询计划和锁.
如果缺少内存,系统不得不取消或销毁那些重要信息,并在稍后需要时重新计算,从而增加了CPU的开销.
因此,有时候一个内存瓶颈的表现形式可能是磁盘或CPU问题.
如图1-11所示,DB2的内存分配分成两大类:数据库和实例级分配:包括共享数据库内存,从缓冲池、排序堆、锁列表到包缓存等.
对于定位内存过度分配的原因,共享内存非常容易处理,因为分配和数据库连接数没有关系.
这些分配都受到DATABASE_MEMORY配置参数的限制.
连接层面或应用程序级分配:包括应用程序堆和语句堆,另外连接层总的内存消耗明显依赖于连接数,这可能会使得在系统初始化配置时很难预估.
无论是直接指定堆大小还是启用STMM,判断DB2内存实际用量的最好办法就是查看数据库、数据库管理器和应用程序快照的内存使用部分,它们提供了数据库、实例和应用层面各自的配置堆大小和当前堆大小.
图1-11内存瓶颈优化树(查看大图)1.
3.
3.
5网络问题如图1-12所示,通常网络方面的问题主要表现在两个方面:客户端和服务器之间的网络问题.
例如业务数据量达到网络所能允许的峰值,或者服务器端返回客户端并不需要的大量数据等.
在多分区环境下,不同节点之间通信的问题.
例如,不同节点之间通信数据量过大,导致网络延时,响应时间变慢等.
developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第20页,共25图1-12网络瓶颈种类1.
3.
3.
6懒惰系统问题还有一种"懒惰系统"的瓶颈.
没有明显的CPU、磁盘、内存或网络瓶颈,系统也不忙,如图1-13所示.
在"懒惰系统中"一个最常见的原因是锁争抢.
幸运的是,锁争抢是很容易在快照数据中被检查到的.
快照元素lock_wait_time和locks_waiting通过sysibmadm.
snapdb分别显示总的锁等待时间和当前正在等待锁的代理进程数,活动代理等待锁的百分比很高(如20%或者更高)和锁等待的时间增加是发生瓶颈的明显迹象.
锁升级也会成为发生争抢的主要原因.
反之,经过良好设计的应用程序持有的个别行锁或许不会发生冲突,锁升级导致的块或表级别的锁常常会导致对象串行化以及严重的性能问题.
每1000笔事务发生死锁次数超过一次通常意味着有问题.
死锁的频率有时可以很容易降低,通过保证所有应用程序以相同的顺序访问它们的数据.
DB2预取器、页清除器数目过小,也是导致懒系统的一个重要原因.
部署了一个新版的应用程序、客户端和服务器之间存在网络瓶颈以及客户端系统负载过大都可能导致系统变慢,不过这也可能是由于应用程序对DB2的请求成功率下降的缘故.
图1-13懒惰系统优化树(查看大图)1.
3.
3.
7高级技术优化使用上述的优化方法并不能解决所有的性能问题,所以有时候需要针对应用情况寻找高级技术来提升系统性能,如图1-14所示为高级优化技术.
ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第21页,共25图1-14高级优化技术如果DB2数据库的用户数大幅增加、DB2数据库容量大幅增加,而要在极短时间内处理复杂事务,处理峰值型的工作负载,DB2数据库就很难处理了,因为这受到磁盘的读写能力限制,而DB2数据库的数据访问是基于磁盘的.
针对这种情况可以考虑使用solidDB高速缓存加速.
另外,随着数据量的不断增长,单机数据库在性能方面面临很大挑战.
为了提高吞吐量以及高性能的需要,DB2数据库提供了水平(ScaleOut)和垂直(ScaleUp)两种伸缩方式.
垂直扩展方式中,通过在单个服务器内增加CPU、内存及存储来提升处理能力;而在水平扩展方式中,通过增加服务器节点,分担用户的访问请求并提供高可靠性的解决方案.
DB2pueScale使用了水平扩展、共享磁盘的方式来提升数据库系统的事务处理能力,有关这部分的介绍请参考本书第4部分第10章.
1.
3.
4使用PAT方法学的步骤在制定性能优化步骤之前,读者首先需要考虑下面的建议:有备而来,去了解系统一切正常的情况下性能怎么样.
搜集运行监视信息来跟踪一段时间内系统行为的变化.
了解整个场景,不要局限于你从DB2上看到的,也要搜集并分析来自于操作系统、存储、应用程序甚至来自用户的数据.
了解系统本身将有助于你解释监控数据.
只调整能解释你看到的症状的参数,如果连发动机都无法启动就不要更换轮胎.
不要试图通过降低CPU来解决磁盘的瓶颈.
一次只改一个参数,在更改其他参数之前先观察效果.
按照上面的原则,图1-15列出了性能优化的执行步骤.
首先,从业务角度识别结果,从业务角度确定问题,设定每个问题的优先级,设定每个问题的优化目标;其次,从系统角度确定原因:时间花在何处时间是如何被消耗的来找到时间耗费的原因;再次,使用PAT方法学来解决问题;最后对性能进行验证.
developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第22页,共25图1-15使用PAT方法学调优步骤(查看大图)1.
3.
5PAT树使用建议读者在使用本书的时候,需要重视下面的建议来加快解决问题或者学习的进度:从解决问题的角度来看.
读者在学习了第1章的PAT方法学和第2章的金融电信行业经营分析系统的真实案例后,就可以用来解决自己实际中的性能问题.
从学习知识的角度来看.
读者可以直接从第3章开始学习DB2数据库有关的设计、监控和优化的知识.
从解决问题和学习结合的角度来看.
PAT决策树最重要的特点就是叶子节点给出的具体的优化方法和本书的相应章节对应,所以要利用好这一点达到在解决性能问题的同时,也能学到知识.
1.
4小结本章讲解了数据库设计的整个阶段以及在每个阶段如何考虑性能问题.
随后引出数据库性能问题,说明了如何定义性能问题、如何把问题分类、如何制订性能优化目标以及如何设定每个问题的优先级.
基于作者在实际案例中的性能优化实践,提出了PAT方法学,特别是深入讲解了PAT方法学所强调的用于制订优化策略时所必须遵守的四项原则.
在此基础上,说明了如何使用PAT决策树来解决6种实际性能问题,即磁盘瓶颈、CPU瓶颈、内存瓶颈、"懒惰系统"、网络瓶颈和性能上限(高级技术优化).
结合业务角度和系统角度,本章给出了使用PAT方法学的步骤,以方便读者了解性能优化的整个过程.
案例分析总结接下来向大家共享一段工作笔记,其中回顾了"PAT树"在重大系统事故中,被应用于实践的现场记录.
ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第23页,共252010年4月11日笔记整理,地点:北京凌晨4:15,移动通信系统性能优化现场,17位技术人员已连续工作9个多小时,此前在12:20和3:05已发生过两次险情.
此刻,我快速迈入运维大厅.
4:30,所有业务数据第三次加载到生产数据库上,所有人都盯着屏幕等待传回捷报,亦或是警报.
"话单无法生成!
"负责测试的小白在大厅的另一端急呼.
"密码改不了!
""二级页面打不开!
""开户失败!
"……David、Chen和我三个人决定放弃原定计划,启动应急预案.
41个业务分布在7台服务器上,现在要把出问题的2台主机切到备机上,结果发现一台服务器挂起.
再次敲下"reboot",等了10分钟,还是无法访问,此时桌上的几部电话铃声此起彼伏.
最先出问题的系统,是客户关系管理系统,涉及7000多万用户数据,有表2000张,视图3000个,存储过程5万行,总数据量超过300TB.
繁重的工作量,但仅有12个工作日的优化期限,这个压力层层传递到我们.
同时对于共同参与这个项目的7个单位来说,沟通协调也是一个很棘手的问题.
最终,一个普通的性能优化项目,却演变成了数据库、硬件、网络和业务纠缠在一起的隐患问题大爆发.
我看了看表,对走过来的Chen说,现在要立刻启用"PAT树",奋力一搏,力挽狂澜.
developerWorksibm.
com/developerWorks/cn/developerWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第24页,共25参考资料学习在developerWorksInformationManagement专区,了解关于信息管理的更多信息.
查找技术文档、操作文章、培训、下载、产品信息等信息.
阅读本书的第1章:我看DB2设计与优化.
阅读本书的第2章:性能优化利器——PAT方法.
更多推荐书籍,请访问developerWorks图书频道.
通过InformationManagement专区DB29技术资源中心,了解IBMDB2产品家族的更多产品信息和相关技术.
通过访问DB29.
7信息中心,了解DB29.
7的新特性概述和使用方法随时关注developerWorks技术活动和网络广播.
获得产品和技术现在可以免费使用DB2.
下载DB2Express-C,这是为社区提供的DB2ExpressEdition的免费版本,它提供了与DB2ExpressEdition相同的核心数据特性,为构建和部署应用程序奠定了坚实的基础.
下载信息管理软件试用版,体验它们强大的功能.
讨论参与developerWorksblogs并加入developerWorks中文社区,developerWorks社区是一个面向全球IT专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区.
ibm.
com/developerWorks/cn/developerWorksdeveloperWorks图书频道:DB2设计与性能优化--原理、方法与实践,第1章第25页,共25作者简介王飞鹏王飞鹏,DB2数据库资深顾问.
曾为电信、银行、中央部委、中国高铁等大型数据库项目做出了重要贡献.
首次提出PAT方法学,为解决数据库性能问题提供了分析标准.
发表数据库论文12篇,拥有软件专利3项.
每年通过大量咨询、讲座、培训等方式,为数据库人才更好的运用数据库技术作出了最大的努力.
陈辉陈辉,DB2数据库内核开发工程师.
来自IBM中国DB2开发团队,具有多年DB2引擎开发经验.
目前从事DB2内核开发和客户技术支持工作,精于DB2问题诊断处理,拥有系统分析师认证、IBMDB2各项认证.
张广舟张广舟,DB2数据库资深软件工程师.
多年来一直从事DB2核心开发工作.
现任IBM中国SQL编译器和优化器开发组长.
曾发表多篇数据库技术论文,擅于解决大型数据库性能问题,并拥有软件专利1项.
成孜论成孜论,数据库咨询专家.
曾为荷兰银行(香港)系统数据库技术顾问、KDDI通信数据库咨询师.
现受聘为中国大陆某金融机构数据库SeniorConsultant.
版权所有IBM公司2011(www.
ibm.
com/legal/copytrade.
shtml)商标(www.
ibm.
com/developerworks/cn/ibm/trademarks/)