db2 实践+性能调优和问题诊断最佳实践+第+2+部分
让DB2跑得更快——DB2内部解析与性能优化
精彩节摘
9.3如何定位及修复内存泄漏
在怀疑遇到内存泄漏的问题之前，必须谨慎地判断当前数据库中是否真实存在内存泄漏。判断数据库中存在 内存泄漏时需要注意以下几点：
系统中的内存在逐渐减少，甚至导致换页（paging）；
SQL语句越来越慢（经常是换页导致）；
随着时间增长，由DB2分配的内存在不断增加。
第3篇性能分析及内部原理剖析
第4章对优化器的原理进行了探讨，阐述了优化器的重写机制、优化原理及编译原理，并介绍了如何检查优化 器的估算结果的两种方法。
谢谢观看
并在DB2China数据库论坛担任热点讨论版块版主，主持多次热点讨论以及专家现场诊断，擅长DB2数据库及 相关产品的性能调优及故障分析，对DB2技能及实践经验有多年积累。
近年来多位业界专家一直在积极推动DB2领域的技术交流，真正理解DB2技术人员真正的需求与痛楚，是DB2 系统知识及技巧精髓的热心分享者及贡献者。
而我本人正是一名数据的信徒，多年来在著书、培训、咨询和管理等多项工作中，始终在数据的海洋中忘我 与痴迷。在受邀为本书作序之时，我回想起五年前正埋头于写作的我。那时，每日工作繁忙，仍笔耕不辍，把之 前在数据库领域的各项工作中所获得的技术积累、经验总结都尽可能地通过文字展现给读者。自认为写数据库的 书很苦，写DB2的书更苦，在出版多部著作之后，我对优秀数据库著作的评判标准，可以套用新闻界的行话： “如果事件报道得不够好，那是因为离得不够近”。
在常见的数据库问题中，性能问题不仅出现的频率较高并且很多生产系统中并不存在一个对性能问题进行隔 离的高可用机制，正因为如此，在很多关键行业的系统中，性能问题往往成为影响生产系统正常运行的最大因素。 而性能问题的影响时间有时长达数小时，这样不仅给生产系统带来了极大的负面影响，也使业务很难正常进行。
DB2数据库性能优化
DB2数据库性能优化DB2问世于1983年，其被贴上的标签之一就是：最早使用SQL（同样最早被IBM 开发）的关系型数据库产品。
此前，IBM已经有了一个层次性数据库产品，在当时已属数据库中的"大哥大"，所以当发布关系型数据库时，IBM为自己的数据库产品排座次，新的数据库产品理所当然的是数据库二代，也被大家戏称为"库二代"，就这样，DB2的命名也就被人们接受了。
实际上，DB2的渊源可以追溯至上世纪70年代初，那时还是个登月的年代，阿波罗登月的壮举时刻激励科学家们开拓创新。
当时在IBM工作的考德(E.F.Codd)博士在1970年6月用划时代的论文描述了关系型数据库理论，这使得后来诞生的"库二代"被赋予了强有力的数学基础和逻辑基因。
接下来，IBM把对E.F.Codd想法的实施交给了一个程序小组，这个程序小组使用SEQUEL作为查询语言。
当IBM公布其第一个关系型数据库产品时，对SEQUEL重新命名，这就是后来大名鼎鼎的SQL。
而在那一段时间，刚遭受离婚重创的犹太人Larry Ellision也发现了其中的秘密，他创立的Oracle，着实与DB2经历了一起"穿开裆裤"的起步阶段，之后你追我干30年，成为一组最有趣的竞争对手。
在上世纪80年代，DB2作为一个全功能的数据库管理系统，被IBM大型机所专用。
到了上世纪90年代早期，IBM将DB2带向了其它平台，包括OS/2、UNIX以及Windows服务器，然后是Linux和手持设备。
让大家一目了然的是，DB2 所有的产品都要被命名为"产品 for 平台"（例如，DB2 for OS/390）。
进入上世纪90年代中期，IBM发布了一组最初应用在AIX上的被称为DB2 Parallel的版本，此版本通过无分享（Share Nothing）架构而提供更强的伸缩性，即将一个大型数据库，分布到多个服务器上。
DB2数据库性能优化
DB2数据库性能优化
一、建立索引
（1）添加新索引
在DB2中，可以使用CREATEINDEX命令来建立索引。
通过添加索引来提高SQL语句的执行效率。
建议在经常使用的字段上建立索引，例如，WHERE子句中的字段，GROUPBY子句中的字段，ORDERBY子句中的字段或者连接条件中的字段。
（2）更新索引
如果表中的数据经常发生变化，则建议定期更新索引。
DB2有一项特殊的REORG操作，可以重新建立表中的索引，以提高查询效率。
（3）复合索引
在DB2中，可以使用复合索引来建立索引，以便提高查询效率。
复合索引可以使用多个字段，比普通索引更有效地提高查询速度。
二、查询优化
（1）使用合适的连接方式
（2）使用合适的排序方式
（3）使用子查询
（4）尽量少使用通配符
（5）尽量少使用函数
（6）查询中使用表别名
（7）使用EXISTS和NOTEXISTS
（8）使用适当的索引
三、周期性维护
（1）定期检查磁盘空间
（2）定期检查表和索引
（3）定期更新统计信息
（4）定期重新排序和重新组织表
（5）定期检查死锁
四、构造良好的数据模型
（1）正确定义数据字段
（2）使用算法优化数据存储
（3）及时删除无用的数据
（4）构造适当的表结构
五、其他
（1）设置合理的日志文件。
DB2 HADR最佳实践
DB2 HADR最佳实践摘要DB2 High Availability Disaster Recovery (HADR) 是一个简单易用的数据复制特性，该特性为局部和全面站点故障提供一个高可用性（HA）解决方案。
但是，由于用户的需求千差万别，因此不存在绝对理想的HADR 配置。
您的HADR 环境设置、调优和维护决策通常是权衡利弊的结果。
比如，您可能需要在数据库可用性要求和防止数据丢失之间进行权衡。
好消息是，进行权衡并不一定意味着需要以牺牲某项需求为代价。
本文就设置和维护您的HADR 环境提供了一些推荐方法，以帮助您在HADR 提供的保护与性能和成本之间找到平衡点。
本文重点关注以下领域：∙为快速故障转移设置系统∙调优参数以改进网络性能∙调优参数以最小化HADR 相关日志记录对性能的影响∙在HADR 环境中选择适当的表重组方法和负载操作HADR 简介HADR 从一个源数据库（称为主数据库）向一个目标数据库（称为备用数据库）复制数据更改。
由于这是一个无共享架构，每个数据库都使用自己的存储器。
HADR 在主数据库失败时提供快速故障转移。
您还可以在实施更新和实施维护等场景中便捷地转换主数据库和备用数据库的角色，从而将停机时间减至最小。
HADR 用途广泛，并被完全集成到DB2 数据库，不需要任何特殊硬件和软件，使用标准TCP 接口连接主数据库和备用数据库，其设置只需几个数据库配置参数。
HADR 的一个核心原则是：数据库的性能和可用性不能被某些挑战所影响，比如工作负载的突然波动（这影响备用数据库上的日志重放活动量）和服务器或网络失败（这将导致故障转移）。
为实现最优性能而调优您的HADR 解决方案应该遵循一些基本原则，以避免一段时间后出现的潜在问题。
另外，您需要了解几个涉及您的数据库维护行为的HADR 设置项目。
这个最佳实践文档将解决这些问题。
本文着眼于为您设计HADR 基础设施和配置数据库提供指南和推荐方法，从而改进HADR 相关性能，特别是日志记录和故障转移速度。
DB2性能调优
DB2性能调优：设计并配置你的数据库2009年12月03日IT168网站原创作者：itpubblog 编辑：李倩评论：0条本文Tag：IBM DB2数据库优化DB2【IT168 技术文章】有很多数据库设计和配置选项可以影响查询性能。
对数据库设计的更多建议参考“ Planning your Physical Database Design ”最佳实践文章。
使用约束来提高查询优化考虑定义的唯一性，检查并参考一致性约束。
这些约束提供了语义信息，允许 DB2 优化器重写查询来评估连接，通过连接来降低聚合和 FETCH FIRST N ROWS，去掉不必要的 DISTINCT 选项被和一些其它的优化。
当应用程序可以保证它自己的关系时，信息约束也可以被用来检查并参考一致性约束。
相同的优化也是可以的。
当更新（插入或删除）行的时候，来自数据库管理器的强制约束可能导致很高的系统开销，尤其在更新很多有一致性约束的行的时候。
如果一个应用程序在更新一行之前已经验证的信息，这样使用信息约束比起正常的约束更有效例如，考虑 2 个表 DAILY_SALES 和 CUSTOMER 。
在 CUSTOMER 表中的每一行都有一个唯一的客户键值（CUST_KEY）。
DAILY_SALES 包含一个 CUST_KEY 列并且每一行都引用一个 CUSTOMER 表中的客户键。
可以创建一个参考一致性约束来防止在 CUSTOMER 和 DAILY_SALES 之间发生 1:N 的关系。
如果应用程序要强制约束这个关系，可以创建一个信息化的约束。
那么下面的查询避免了在CUSTOMER 和 DAILY_SALES 之间进行连接，因为没有从 CUSTOMER 获取任何列，而且来自于 DAILY_SALES 的每一行都可以在 CUSTOMER 里面找到与之匹配的行，所以查询优化器将自动删除连接SELECT AMT_SOLD, SALE PRICE, PROD_DESCFROM DAILY_SALES, PRODUCT, CUSTOMERWHEREDAILY_SALES.PROD_KEY = PRODUCT.PRODKEY ANDDAILY_SALES.CUST_KEY = CUSTOMER.CUST_KEY应用程序必须执行信息约束，否则查询可能返回不正确的结果。
（转）Db2数据库性能优化中，十个共性问题及难点的处理经验
（转）Db2数据库性能优化中，⼗个共性问题及难点的处理经验为了帮助⼤家更好地进⾏DB2的性能优化，社区组织社区专家针对⼀些共性问题及难点分享经验。
以下内容来⾃活动“Db2数据库性能优化经验交流”，主要由以下社区专家及会员分享：leilin、topzgm、岳彩波、beyondmch、yellow-fin等提醒：⽂章末尾有彩蛋，如果你是Db2达⼈，可不要错过~01如何发现性能问题？通过什么定位？1、收集信息。
2、分析3、找到问题点解决第⼀步操作系统级别性能CPU监控：ps -elf | sort +5 -rn | more 第6列代表CPU使⽤的计数器I/O使⽤率：iostat -D 收集磁盘I/O信息内存占⽤率：讨论的内存指的是虚拟内存（virtual memory），包括物理内存（physical memory）与交换空间（swap space）vmstat -> avm 当前系统中已经激活的虚拟内存页的数量（该数值不包含⽂件系统缓存）vmstat -> fre 系统中平均空闲页的数量（不能完全代表系统中可⽤的空闲内存：⽂件系统缓存驻留内存，并不会返还给空闲列表，除⾮被虚拟内存管理器盗取）svmon -> clnt与in use交叉项代表有多少内存被⽂件系统使⽤（加上free项，可以初步认为是该系统中可以被应⽤程序所使⽤的内存）第⼆步数据库级别性能1. db2grep -dump | more 查看服务器安装了⼏个DB2版本2. ps -elf | grep db2inst1 查看数据库进程的CPU计数器3. db2 get dbm cfg | grep -i dft_mon 确认快照打开4. 实例级快照，了解当前实例有多少应⽤程序在执⾏db2 get snapshot for database manager -> Remote connections & Local connections5. 数据库级快照连接数信息：applications connected currently，appls executing in db manager currently锁信息：锁总数，锁等待数量，锁等待总时间，当前数据库锁列表占⽤内存，死锁次数，锁升级次数，锁超时次数排序信息：排序是CPU杀⼿，过多的排序会造成CPU的极⼤消耗；排序溢出是说，如果排序堆⽆法容纳排序数据，就会被溢出到临时空间；排序是⼀种状态，根源在SQL语句；数据索引I/O信息：逻辑读 DB2向缓冲池请求的次数逻辑读越多，需要的物理I/O就越少物理读如果请求的数据页不在缓冲池，需要从磁盘中读取数据页的次数吞吐量或事务信息：提交/回滚事务数，执⾏动态和静态语句次数，增删改查次数( rows read / rows selected ) 是⼀个⾮常重要的性能指标，它表⽰为了检索⼀⾏数据需要读取多少⾏，该值越⼤，表⽰代价越⾼，需要的I/O 越多，可调优的余地越⼤事务⽇志信息：⽇志I/O在很⼤程度上会影响数据库整体的性能6. 应⽤程序快照在数据库快照中发现存在⼤量的逻辑读，通过应⽤程序快照可以细化到某条特定的语句7. 表空间快照在数据库快照中发现存在⼤量的逻辑读，通过表空间快照可以轻松地定位哪个表空间被频繁使⽤8. 表快照如果发现⼀个表的页数很少，但是读的⾏数⾮常多，那么可以合理地猜测该表在某些查询语句中可能处于NLJOIN的内部⼦节点9. 动态SQL快照：SQL执⾏次数，总共读的⾏数，消耗的CPU，逻辑物理读数量，排序数量等第三步内存使⽤监控1. db2pd -osinfo系统内存使⽤情况2. db2pd -dbptnmem整个实例的内存使⽤情况3. db2pd -memsets内存段使⽤情况在实例中会有多个不同的内存段，每⼀个内存段中可能有⼀个或者多个内存池ipcs -a | grep 578814120 内存段映射到操作系统共享内存IPC段FMP与trace内存段很少造成性能问题4. db2pd -mempool深⼊内存池信息5. db2pd -db <dbname> -memsets / -mempool数据库级别内存段和内存池信息02优化过程中的优先级问题？在Db2优化过程中，我已知的有如下⼿段1.索引2.sql语句优化（分析执⾏语句后重写sql）3.runstats信息收集请问优化过程中，⼊⼿的优先级顺序是什么呢，还有其他⼿段吗？这“三板斧”已经可以解决很多问题了，DB2的优化⼿段很多，如果想深⼊了解，上传⼏个⽂件供参考。
优化DB2数据库的十个最佳实(下)
---优化DB2数据库的十个最佳实践(下)DB2优化技巧6: 使数字和数据日期类型相匹配在先前的版本中，对于处理谓词和比较数据类型长度的变化，阶段1 处理是非常精确的。
在DB2 v7 之前, 这种不匹配导致了谓词被降级在阶段2 处理。
但是，一个DB2 v7的新特点允许数字化的数据类型可以被手动的转换以避免阶段2 降级。
ON DECIMAL(A.INTCOL, 7, 0) = B.DECICOL ON A.INTCOL = INTEGER(B.DECICOL)如果两个列都被索引, 会得到到更大的结果集。
如果只有一个列被索引, 就转换同伴。
对于促进阶段1，重新绑定索引是必要的。
DB2优化技巧7: 以表单和谓词类型从最高限制性到最低限制性进行排序过滤当写一个SQL 语句用到多种谓词时, 确定的谓词将从结果集中过滤掉大多数的数据，并且把那个谓词放在列表的开始。
由于采用这种方式排序您的谓词, 这令随后的谓词将会过滤较少的数据。
DB2 默认的优化器将分类您的谓词并将处理那个谓词的情况然后顺序的在下面列出。
但是, 如果您的查询引用到多个谓词并且属于相同的种类, 那么这些谓词将以他们被输入的次序来执行。
这就是为什么排序谓词是如此重要，排序并且把最大过滤能力的谓词放在序列的顶部（尽最大能力的排序）。
在以后的版本中，最终的查询重写将考虑到这些, 但在今天，当您写查询的时候是应该知道这些的。
图5：谓词过滤顺序WHERE A.COL2 = 'abracadabra'AND A.COL4 < 999AND A.COL3 < :hvcol3AND A.COL5 LIKE '%SON'最应该限制的条件应该被首先列出, 以便第二种情况的额外处理能够被避免。
DB2优化技巧8: 删除SELECT表单被SELECTed 的每一列都消耗了很多资源进行处理。
有几处地方用以检查确定是否列选择的是真正必要的。
DB2 HADR最佳实践
DB2 HADR最佳实践摘要DB2 High Availability Disaster Recovery (HADR) 是一个简单易用的数据复制特性，该特性为局部和全面站点故障提供一个高可用性（HA）解决方案。
但是，由于用户的需求千差万别，因此不存在绝对理想的HADR 配置。
您的HADR 环境设置、调优和维护决策通常是权衡利弊的结果。
比如，您可能需要在数据库可用性要求和防止数据丢失之间进行权衡。
好消息是，进行权衡并不一定意味着需要以牺牲某项需求为代价。
本文就设置和维护您的HADR 环境提供了一些推荐方法，以帮助您在HADR 提供的保护与性能和成本之间找到平衡点。
本文重点关注以下领域：∙为快速故障转移设置系统∙调优参数以改进网络性能∙调优参数以最小化HADR 相关日志记录对性能的影响∙在HADR 环境中选择适当的表重组方法和负载操作HADR 简介HADR 从一个源数据库（称为主数据库）向一个目标数据库（称为备用数据库）复制数据更改。
由于这是一个无共享架构，每个数据库都使用自己的存储器。
HADR 在主数据库失败时提供快速故障转移。
您还可以在实施更新和实施维护等场景中便捷地转换主数据库和备用数据库的角色，从而将停机时间减至最小。
HADR 用途广泛，并被完全集成到DB2 数据库，不需要任何特殊硬件和软件，使用标准TCP 接口连接主数据库和备用数据库，其设置只需几个数据库配置参数。
HADR 的一个核心原则是：数据库的性能和可用性不能被某些挑战所影响，比如工作负载的突然波动（这影响备用数据库上的日志重放活动量）和服务器或网络失败（这将导致故障转移）。
为实现最优性能而调优您的HADR 解决方案应该遵循一些基本原则，以避免一段时间后出现的潜在问题。
另外，您需要了解几个涉及您的数据库维护行为的HADR 设置项目。
这个最佳实践文档将解决这些问题。
本文着眼于为您设计HADR 基础设施和配置数据库提供指南和推荐方法，从而改进HADR 相关性能，特别是日志记录和故障转移速度。
调优DB2的最佳实践
简介性能是关系到随需应变型应用程序成功与否的关键。
当那些应用程序使用IBM® DB2 Universal Database™作为数据存储时，至关重要的是，从一开始就应该知道有关如何在 DB2 UDB 上取得尽可能好的性能的基础知识。
在本文中，我将给出关于调优 DB2 UDB V8 系统的一些比较深入的建议。
我们将谈论这一过程中自始至终存在的性能问题。
您可以遵循从创建一个新数据库到运行应用程序这之间的流程。
通过本文可以看到如何使用 DB2 自动配置实用程序来初始配置数据库管理器和数据库环境。
接着，我将讨论创建缓冲池、表空间、表和索引的最佳实践。
另外，您可能还想改变一些重要配置参数的初始值，以便更好地支持应用程序，因此我们还将简介这些配置参数。
我们将论述基于监视器（monitor）细节输出的调优，从而展示如何使用快照监视（snapshot monitoring）帮助调优 SQL、缓冲池和各种不同的数据库管理器以及数据库配置参数。
接着，我们将进一步研究应用程序发送给 DB2 的 SQL。
通过使用 Explain，可以生成 SQL 采用的访问计划（access plan），并寻找可以进一步优化的机会。
我们将考察 Design Advisor 这样一个工具，它可以根据所提供的 SQL 负载推荐出新的索引，或者评估现有的索引。
最后，我们还将讨论一些 DB2 SQL 选项。
此外，持续（on-going）维护对于维持最佳性能非常重要。
所以我们将讨论一些可以帮助我们进行持续维护的实用程序。
对于那些正使用 DB2 ESE Database Partitioning Feature (DPF) 的读者，我会用一节的篇幅谈论为使数据库高效运行而应该考虑的一些问题。
有时候可能会存在某种外在的瓶颈（来自 DB2）而使您无法达到性能目标，本文列出了一些常见的瓶颈，以及用于监视这些瓶颈的实用程序。
最后，本文列出了一些有价值的 IBM 资源，以帮助您发现有价值的DB2 信息。
DB2性能调优
DB2 UDB性能调优目录DB2 UDB性能调优文档 (1)目录 (3)1.文档说明 (4)2.数据库配置 (5)3.性能监控 (16)4.性能优化 (26)5.附录 (58)1.文档说明1.1目的本文档用于指导DB2 UDB数据库的参数配置、性能监控、性能优化，它提供了DB2性能问题处理的通用思路和常规解决办法。
1.2术语及说明本文提及术语来自于信息中心以及IBM官方网站。
2.数据库配置优化在进行系统分析确定性能问题的根源时，要先检查数据库的配置，这包括DB2注册变量(Registry Variable)、DBM参数、DB参数等。
如果发现是配置的问题，那么就可以通过调整配置来解决问题。
2.1硬件配置首先，需要确认CPU的配置。
其他的硬件配置都可以从CPU配置进行推导。
而CPU应该采取什么配置，可以从现有系统的经验来进行判断。
例如：一个新系统需要处理超出现有系统50%的用户请求，且每个用户运行的SQL语句的复杂度也与现有系统类似，那么我们就可以假设新系统需要超出现有系统50%的CPU能力。
内存的主要作用是避免I/O操作。
通常来说，拥有更多内存的系统性能更好。
我们认为为每个处理器内核配置4~8GB内存是相对合适的。
对于使用RAID存储的情况，通常应该为每个处理器内核配置最少10~20个磁盘。
为DB2事务日志分配专门的专用的磁盘。
这是因为日志I/O特性与DB2容器有很大的不同。
日志I/O与其它类型的I/O的竞争可能导致日志成为一个瓶颈，尤其是对于那些有大量数据行写入行为的系统。
2.2操作系统配置2.2.1 AIX配置如果DB2运行在AIX系统上，建议使用VMO命令将系统参数maxperm%设置为90，maxclient%设置为90，minperm%设置为3，lru_file_repage设置为0。
我们可以使用”vmo -a”命令(在AIX 6.1中，需要使用” vmo -a -F”命令)查看VMM 参数。
DB2十佳性能调优技巧
查找与以下示例类似的 TEMPSPACE 表空间定义：
Hale Waihona Puke Tablespace ID= 1
Name= TEMPSPACE1
Type= System managed space
Contents= Temporary data
State= 0x0000
Detailed explanation: Normal
为了帮助 DB2 DBA 避免性能灾难并获得高性能，我为我们的客户、用户和 DB2 专家同行总结了一套故障诊断流程。以下详细说明在 Unix、Windows 和 OS/2 环境下使用 DB2 UDB 的电子商务 OLTP 应用程序的 10 条最重要的性能改善技巧 － 并在本文的结束部分作出总结。
9. 代理程序
确保有足够的 DB2 代理程序来处理工作负载。要找出代理程序的信息，请发出命令：
db2 "get snapshot for database manager"
并查找以下行：
High water mark for agents registered = 7
High water mark for agents waiting for a token = 0
Rows Read= 98857
Overflows= 0
Page Reorgs= 0
Overflows 的数量很大就可能意味着您需要重组表。当由于更改了行的宽度从而 DB2 必须在一个不够理想的页上定位一个行时就会发生溢出。
3. 表空间分析
表空间快照对理解访问什么数据以及如何访问是极其有价值的。要得到一个表空间快照，请发出以下命令：
10. 监视开关
DB2性能调优与技巧
DB2数据库提供了高层次的数据利用性、完整性、安全性、可恢复性，以及小规模到大规模的执行能力，其性能是非常强大的，首先介绍一下最简单而最见成效的——Bufferpool缓冲池是内存中的一块存储区域，用于临时读入和更改数据库页(包含表行或索引项)。
缓冲池的用途是为了提高数据库系统的性能。
从内存访问数据要比从磁盘访问数据快得多。
因此，数据库管理器需要从磁盘读取或写入磁盘的次数越少，性能就越好。
对一个或多个缓冲池进行配置之所以是调优的最重要方面，是因为连接至数据库的应用程序的大多数数据(不包括大对象和长字段数据)操作都在缓冲池中进行。
缺省情况下，应用程序使用缓冲池 IBMDEFAULTBP，它是在创建数据库时创建的。
当 SYSCAT.BUFFERPOOLS 目录表中该缓冲池的 NPAGES 值为 -1 时，DB2 数据库配置参数 BUFFPAGE 控制着缓冲池的大小。
否则会忽略BUFFPAGE 参数，并且用 NPAGES 参数所指定的页数创建缓冲池。
建议对于仅使用一个缓冲池的应用程序，将 NPAGES 更改成 -1，这样 BUFFPAGE 就可以控制该缓冲池的大小。
这使得更新和报告缓冲池大小以及其它 DB2 数据库配置参数变得更加方便。
确保可以使用数据库配置中的 BUFFPAGE 参数来控制缓冲池大小之后，将该参数设置成合适的值。
根据数据库的大小和应用程序的性质将该参数设置成一个合理的大值，这种做法很安全。
通常，该参数的缺省值非常小，可能满足不了要求。
db2 "get snapshot for all bufferpools"在数据库快照或缓冲池快照的快照输出中，查找下列"logical reads"和"physical reads"，这样就可以计算出缓冲池命中率，它可以帮助调优缓冲池:缓冲池命中率表明数据库管理器不需要从磁盘装入页(即该页已经在缓冲池中)就能处理页请求的时间百分比。
DB2数据库系统调优实践经验谈
• 容器布局 • 区段大小 • 预取大小
– Prefetch Size = (# Containers of the table space on different physical disks) * Extent Size
数据库设计：表设计和调优
• MDC多维群集表 • MQT集体查询表 • Create Table选项
– 执行了 REORG 和 RUNSTATS 之后，您需要 REBIND 所有的数据库包
DBM和DB设置
• • • • • DB2内存模型 应该增加 SORTHEAP，以避免排序溢出 LOCKLIST和MAXLOCKS 日志相关配置参数 其他的性能参数
– INTRA_PARALLEL (DBM)
– DFT_QUERYOPT (DB)
性能调优的原则
• 通过大约 10% 的配置变化，就可以达到最 佳性能的 90%。 • 每次调整只针对一处
– 有效地了解调整的效果
Agenda
• 性能调优的原则 • 应用程序方面
– SQL语句调优 – 应用程序调优
• 数据库方面
– 数据库设计（表空间，表，索引，缓冲池，日志） – 数据库的日常维护（收集统计信息，重组） – 数据库管理器以及数据库的参数配置（锁定，排序， 内存等）
数据库设计：表空间设计与调优
• 确定要创建的表空间的类型（DMS 或 SMS） • 确定页面大小 • 确定表空间的数量
– – – – – – 对于每种页面大小，创建一个： 系统临时表空间。 用于索引的常规表空间。 用于频繁访问的表的常规表空间。 用于访问不多的表、随机访问的表及顺序访问表的常规表空间。 用于 LOB 数据的大型表空间。
Agenda
• 性能调优的原则 • 应用程序方面
DB2 最佳实践-性能调优和问题诊断最佳实践
DB2 最佳实践: 性能调优和问题诊断最佳实践，第1 部分性能调优从配置和监控开始2009 年 3 月12 日本系列介绍了DB2 系统性能的最优方法，分两部分。
第一部分首先介绍为了达到良好性能，我们如何从软硬件配置方面来保障，紧接着讨论了在多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。
第 2 部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。
内容提要大多数DB2 系统都经过了性能的演变。
首先，不论出于硬件还是软件的观点，该系统首先要能被配置。
在多数情况下，这将成为系统在实施后如何运行的基础。
其次，系统一经发布，勤勉的数据库管理员（DBA）将监控系统的性能，来监测任何可能的开发问题。
如果发现任何问题，我们就进入下一个阶段- 故障诊断阶段。
每个阶段都是基于上一阶段，如果没有适当的准备，我们极有可能需要处理比较困难的问题。
本文介绍了DB2 系统性能的最优方法。
我首先涉及到一些有助于我们确保良好软硬件性能的重要原则。
然后我们讨论多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。
最后，尽管我们做了最好的准备，性能问题仍然可以降临到我们身上，我们讨论如何逐步地处理它们，并有条不紊的进行。
回页首简介任何形式的性能问题都将严重影响并降低一个系统对你组织的价值、削弱业务能力、服务中断、以及增加管理开销。
所有这些都会提升总的拥有成本。
缺乏对系统配置的基本原则，监视和性能故障诊断可能导致不同程度的性能低下，并且降低对于组织的价值。
因此，在前期花些时间去考虑基本的配置指导方针和建立健全的系统监控这样的做法，将使你对处理许多可能出现的典型性能问题，有充分的准备。
并使数据服务器得以高性能运行，以提高投资回报率。
回页首第一步：从配置上实现性能良好像InfoSphere 平衡的仓库（BW）这类的DB2 部署类型，或者那些在SAP 系统之内的系统，配置都是高度确定的。
在BW 案例中，像CPU 个数、内存对 CPU 的比率、硬盘的个数和配置这样的硬件因素，以及在预先指定版本的基础上，详尽的测试，以确定最优配置。
关于DB2常见性能问题的解决参考
关于DB2常见性能问题的解决参考关于DB2常见性能问题的解决参考最近⼀个项⽬在做性能测试时，在并发达到⼀定数后，DB2数据库资源占⽤很⼤，必须对数据库和应⽤进⾏优化。
该项⽬要求性能指标（CPU<70%，内存占⽤<70%，IO<60），按照⽹友介绍的经验，分别针对CPU、内存、IO进⾏问题排查和分析。
现将过程总结如下：⼀、CPU分析通过资源监视器查看⼀个或多个CPU 的使⽤率，确定确实存在CPU使⽤率⼀直居⾼不下的情况。
1、⾸先排除掉存在死循环的情况。
（并发下来后，CPU使⽤率会降下来）。
2、DB2占⽤CPU的主要⾏为有：语句编译、⼤量排序、DB2实⽤⼯具运⾏。
3、先查看是否有⼤量的语句编译：通过DB2的表函数MON_GET_WORKLOAD，可以查看到：select varchar(workload_name,30) asworkload_name,sum(total_cpu_time),sum(total_compile_proc_time),sum(act_rqsts_total),um(total_compilations),sum(total_act_time), sum(pkg_cache_inserts), sum(pkg_cache_lookups) fromTABLE(MON_GET_WORKLOAD('',-2)) as T group by workload_name如果compile_proc_time ⾼于5-10% 的total_cpu_time，并且pkg_cache_inserts/pkg_cache_lookups ⾼于4-5%，则数据库在语句编译上花费了太多的时间。
必须调⼤语句集中器STMT_CONC的⼤⼩。
采⽤逐步调⼤的⽅式来跟踪效果。
4、查看是否存在⼤量的SORT⾸先通过db2的快照，看是否存在⼤量的sort溢出Sort overflows/Total sorts * 100% 表⽰排序溢出百分⽐，通常情况下，该值应该⼩于3。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
developerWorks 中国 > Information Management >DB2 最佳实践: 性能调优和问题诊断最佳实践，第 2 部分有条不紊地进行性能调优和故障诊断级别：初级developerWorks 中国网站编辑团队, 编辑, IBM2009 年 3 月 12 日本系列介绍了 DB2 系统性能的最优方法，分两部分。
第 1 部分首先介绍为了达到良好性能，我们如何从软硬件配置方面来保障，紧接着讨论了在多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。
第 2 部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。
概述就算是配置最仔细的系统也终究会发现它仍然需要一定的性能调优，并且这时我们已经搜集了的运行监控数据，将来非常便于搜集。
保持一种系统的方法来调优和进行故障诊断对我们非常重要。
当发生了一个问题，为了解决这个问题，很容易随意的进行调整。
然而，当我们这么做了，事实上定位到问题的可能性非常低，甚至让问题更糟糕。
性能调优的一些基本原则：1.有备而来，去了解系统一切正常的情况下性能怎么样。
搜集运行监视信息来跟踪一段时间内系统行为的变化。
2.了解整个场景，不要局限于你从 DB2 上看到的 – 也要搜集并分析来自于操作系统、存储、应用程序甚至来自用户的数据。
了解系统本身将有助于你解释监控数据。
3.只调整能解释你看到的症状的参数，如果连发动机都无法启动就不要更换轮胎。
不要试图通过降低 CPU 来解决磁盘的瓶颈。
4.一次只改一个参数，在更改其它参数之前先观察效果。
你可能遇到的问题类型性能问题往往分为两大类：影响了整个系统的问题和只影响了部分系统的问题。
比如某一特定应用或 SQL 语句，在研究的过程中－种类型的问题可能转化为另外一种类型的问题，或者相反。
例如造成整个系统性能降低可能是一个单独的语句，或者是整个系统的问题只是在一个特定的区域被发现。
下面我们从整个系统的问题开始。
我们发现的所有导致性能降低的原因的方法就是从高层入手并逐渐提炼我们的诊断。
这个“判断树”策略可以帮助我们尽可能早的排除那些不能解释我们所看到症状的因素，适用于整个系统或者更加局部的问题。
我们将把瓶颈分成下面4 种普通类型：1.磁盘2.CPU3.内存4.‘懒惰系统’在开始一个对 DB2 调查之前，首先考虑一些准备问题常常是有帮助的，比如：1.是否有性能降低，与什么相关？我们的‘基准’是什么？2.一个系统的性能看起来在随时间流逝下降了？与一个不同的系统或不同的应用比较下降了？这个问题可以对性能降低的原因展开不同的可能性。
数据量增加了？所有的硬件都运行正常吗？3.性能下降是什么时候发生的？在另一个任务运行之前、之中、之后，性能下降或许周会期性的发生。
甚至如果这个任务没有直接和数据库相关，它也可能由于消耗网络或者 CPU 资源影响数据库性能。
4.性能下降的前后关系有什么变化吗？通常是，添加了新硬件、或应用程序被更改了、大量数据被加载、或者更多的用户访问这个系统。
5.在据库专家和应用程序以及架构方面的专家一起工作的情况下，这些问题通常是一个综合分析方法一个很重要的部分。
DB2 服务器几乎总是硬件、其它中间件、和应用程序这样一个复杂环境的一部分，所以解决问题可能需要有多领域的技能。
回页首磁盘瓶颈System Bottleneck > Disk Bottleneck?磁盘瓶颈的基本症状是：•在 vmstat 或 iostat 结果中出现较高的 I/O 等待时间。
这显示系统会花费一小段时间等待磁盘 I/O 完成请求。
等待时间达到 20% 或 25% 是很少见的。
如果 CPU 时间非常低，那么高 I/O 等待时间是一个很好的预示了瓶颈所在。
•从 iostat 或 perfmon 显示磁盘高达 80% 的繁忙程度。
•从 vmstat 输出中看到较低的 CPU 利用率（25%-50%）可能最终我们可能需要添加磁盘，但现在我们将检查我们是否能通过调优 DB2 系统消除这个瓶颈。
如果存在一个磁盘瓶颈，系统管理员可以帮忙映射一个繁忙设备镜像的文件系统路径。
从这里你可以决定 DB2 如何使用这些受到影响的路径 :•瓶颈是表空间容器？这取决于在 sysibmadm.snapcontainer 中查询 TBSP_NAME,TBSP_ID 和CONTAINER_NAME 的结果，查看造成瓶颈的路径是否在 CONTAINER_NAME 结果中。
•瓶颈是事务日志路径？这取决于检查数据库配置参数的结果，查看造成瓶颈的路径是否是“日志文件路径”。
•作为诊断日志路径？这取决于检查数据库管理配置参数的结果，查看造成瓶颈的路径是否是 DIAG_PATH 。
我们将分别考虑这几种情况。
System Bottleneck > Container Disk Bottleneck > Hot Data Container > Hot Table?为了判断是什么导致容器成为瓶颈的，我们需要判断都有哪些表存储在这那个表空间而且最活跃。
1.要判断什么表在这个表空间，需要查询 syscat.tables，把 TBSPACEID 同上面的snapcontainer.TBSP_ID 匹配2.要找出哪些表最活跃，需要查询 sysibmadm.snaptab，选择在我们繁忙的容器上的表的 ROW_READ 和ROW_WRITTEN 。
查看那些水平活跃程度比其它要高很多的表。
注意这需要打开实例级表监控开关DFT_MON_TABLESystem Bottleneck > Container Disk Bottleneck > Hot Data Container > Hot Table > Dynamic SQL stmt?进一步向下钻取，我们需要找出什么造成了这个表的高水平的活跃程度。
是动态 SQL 语句造成的高度活跃？通过sysibmadm.snapdyn_sql.TBSP_ID 查询动态 SQL 快照，来找出我们感兴趣的那些涉及这个表的语句：select … from sysibmadm.snapdyn_sql where translate（cast（substr（stmt_text,1,32672）as varchar（32672））） like ‘ %<tbname>% ’order by …列返回能包含行的读和写，缓冲池活跃程度，执行时间，CPU 时间，等等。
我们能在列上使用 ORDER BY 子句，比如 ROWS_READ,ROWS_WRITTEN 和 NUM_EXECUTIONS 来集中那些对表有最大影响的语句。
注意我们假设这里的表名在 SQL 语句的头 32672 个字符中。
这个假设虽然不完美，却在大多数情况下正确，也是需要使用 LIKE 。
select … from sysibmadm.snapdyn_sql where translate（cast（substr（stmt_text,1,32672）as varchar（32672））） like ‘ %<tbname>% ’ order by …System Bottleneck > Container Disk Bottleneck > Hot Data Container > Hot Table > Static SQL stmt?是否是静态 SQL 语句导致的高活跃程度？在这里我们需要使用系统编目表和 db2pd 来找出哪写语句最活跃。
查询syscat.statements, 参考那些我们关注的表：select PKGSCHEMA, PKGNAME, SECTNO, substr（TEXT,1,80）from syscat.statements where translate（cast（substr（text,1,32672）as varchar（32672））） like ‘ %<tbname>% ’一旦我们有了涉及到我们感兴趣的那些表的静态 SQL 语句的包名和片段数字，我们就可以使用 db2pd – static 来找出它们中哪些是高度活跃的。
Db2pd – static 的输出都有一条从实例启动并执行过的每一个静态 SQL 语句的记录。
NumRef 计数器这条语句已经运行了多少次，并且 RefCount 计数器显示了当前有多少 DB2 代理程序正在运行这条语句。
监视 db2pd – static 结果中的每一条调用记录。
NumRef 值的迅速攀升、 RefCount 的值经常超过2 或 3，往往表明这是一个高度活跃的语句：select PKGSCHEMA, PKGNAME, SECTNO, substr（TEXT,1,80）from syscat.statements where translate（cast（substr（text,1,32672）as varchar（32672））） like ‘ %<tbname>% ’System Bottleneck > Container Disk Bottleneck > Hot Data Container > Hot Table > HotSQL statement如果我们能确定并得出一个或多个 SQL 语句导致了 I/O 瓶颈，下一步我们需要确这个语句是否可以被优化以降低I/O 。
这个语句是否发起了一个不期望的表扫描？这可以通过用 db2exfmt 检查查询计划以及比较这个问题语句的ROWS_READ 和 ROW_SELECTED 来验证。
由于在表扫描中使用了过时的统计信息或有索引问题，经常在临时查询的时候不可避免会发生表扫描，但是一个导致过多 I/O 并造成瓶颈的重复查询还是应该被讨论的。
另一方面，如果受到的影响的表非常小，那么增加缓冲池大小对减少 I/O 和消除瓶颈或许已经足够了。
详情参考这里对于查询优化和物理设计的最佳实践文章。
在我们讨论索引容器之前，先介绍两个数据容器磁盘瓶颈的情况：1.我们希望一个产生大量磁盘读取的表扫描通过预取器完成。
如果在预取过程中有任何问题（见下面的懒惰系统），读入缓冲池操作都将被代理程序自己完成，并且－每次只读取一页。
在这种情况下，会产生导产生大量闲置的“懒惰系统”，或（如我们在此讨论的）磁盘瓶颈。
因此如果有磁盘瓶颈是由于表扫描造成的，但是在 iostat 中却显示的读入大小比那个表空间的预取大小要小很多的话，可能是预取不足导致的问题。
2.通常，为了保证表空间后续读取时候有足够的可用缓冲池页面，页清理会对这个表空间产生一个稳定的写出流。