db2对缓冲池的性能优化

合集下载

DB2性能优化

• 数据库指标
• CPU使用率、内存使用率 • 高峰期IO吞吐量和IOWAIT • SQL平均执行时间和数据量
8
© 2010 IBM Corporation
性能优化原则 – 性能模型
• 保持数据库的最佳性能必须保证CPU、I/O和内存间的平衡
在理想情况下，这个三角形应该是一个等边三角形，使系统资源达到完美平衡。在DB2服务器端调优时，应该考虑资源是否平衡再做出调优决策。例如，调整一个数据库的排序性能，如果只调整内存（减少排序堆），将会使用临时表导致CPU和I/O使用率上升。最小化排序相关的I/O，需要增加分配给排序堆的内存和提高CPU使用率。
OLTP系统主要有内部系统和外部系统两类。
内部系统：面向公司内部人员使用，并发量较小，功能和性能问题不会造成太多的负面影响，如OA系统。外部系统：面向公众、客户使用，并发量很大，一般为内部系统的几十倍到几千倍，功能和性能问题会造成严重的负面影响，如网银系统、网上支付系统。
• OLAP系统：OLAP系统面向管理、决策层人员，数据来源于OLTP系统，通过
• 死锁和锁等待
5
©
• 影响系统正常运行
• 交易高峰期，系统资源使用率持续接近100%
• 交易高峰期，IO吞吐量接近存储极限，存储报警
• 当前性能不能满足业务要求
• 非高峰期，交易性能差
• 高峰期，交易性能差
• 日终作业未在规定时间窗口内完成、生成日志过多
• 建立性能/配置/效率的模型
• 未来业务发展必要时，进行扩容的依据
7
© 2010 IBM Corporation
性能优化概述 – 优化目标
• 优化考虑要素
• 性能底线
• 优化代价、时间、效果 • 优化后的性能能否支撑业务发展 • 制定可行的中短长期优化计划

DB2数据库的简单优化

内存配置优化a) 缓冲池（Buffer Pool）增加缓冲池大小以减少磁盘I/O：sql代码：ALTER BUFFERPOOL IBMDEFAULTBP SIZE 250000为不同的表空间创建专用缓冲池：sql代码：CREATE BUFFERPOOL BP_USERDATA SIZE 100000 PAGESIZE 32K b) 排序堆（Sort Heap）调整SORTHEAP参数：sql代码：UPDATE DB CFG FOR database_name USING SORTHEAP 1024 c) 包缓存（Package Cache）增加PCKCACHESz参数：sql代码：UPDATE DB CFG FOR database_name USING PCKCACHESz 640 I/O 优化a) 预读（Prefetch）调整PREFETCHSIZE参数：sql代码：UPDATE DB CFG FOR database_name USING PREFETCHSIZE 32 b) 异步I/O启用DFTDBHEAP参数：sql代码：UPDATE DB CFG FOR database_name USING DFTDBHEAP AUTOMATIC日志配置a) 日志缓冲区增加LOGBUFSZ参数：sql代码：UPDATE DB CFG FOR database_name USING LOGBUFSZ 1024 b) 日志文件大小调整LOGFILSIZ参数：sql代码：UPDATE DB CFG FOR database_name USING LOGFILSIZ 16384 锁管理a) 最大锁数增加MAXLOCKS参数：sql代码：UPDATE DB CFG FOR database_name USING MAXLOCKS 20 b) 锁列表大小调整LOCKLIST参数：sql代码：UPDATE DB CFG FOR database_name USING LOCKLIST 8192 并发控制a) 最大应用程序数增加MAXAPPLS参数：sql代码：UPDATE DB CFG FOR database_name USING MAXAPPLS 400 b) 代理数调整NUM_POOLAGENTS参数：sql代码：UPDATE DBM CFG USING NUM_POOLAGENTS 100统计信息收集a) 自动统计信息收集启用AUTO_RUNSTATS：sql代码：UPDATE DB CFG FOR database_name USING AUTO_RUNSTATS ON b) 统计信息采样调整统计信息采样率：sql代码：UPDATE DB CFG FOR database_name USING AUTO_SAMPLING YES 查询优化器a) 优化级别设置OPTLEVEL参数：sql代码：UPDATE DB CFG FOR database_name USING OPTLEVEL 5表空间管理a) 自动存储启用自动存储：sql代码：CREATE TABLESPACE ts_name MANAGED BY AUTOMATIC STORAGE b) 表空间扩展设置自动扩展：sql代码：ALTER TABLESPACE ts_name AUTORESIZE YES索引优化a) 索引重组定期重组索引：sql代码：REORG INDEXES ALL FOR TABLE table_name分区表对大表使用分区：sql代码：CREATE TABLE table_name (...) PARTITION BY RANGE(column_name) (...)压缩启用表压缩：sql代码：ALTER TABLE table_name COMPRESS YES并行度调整INTRA_PARALLEL参数：sql代码：UPDATE DB CFG FOR database_name USING INTRA_PARALLEL YES 监控和诊断a) 启用活动监控：sql代码：UPDATE DBM CFG USING DFT_MON_BUFPOOL ONUPDATE DBM CFG USING DFT_MON_LOCK ONUPDATE DBM CFG USING DFT_MON_SORT ONUPDATE DBM CFG USING DFT_MON_STMT ONb) 使用db2top工具实时监控性能c) 定期检查db2diag.log文件。

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 部分性能调优从配置和监控开始2009 年 3 月12 日本系列介绍了DB2 系统性能的最优方法，分两部分。

第一部分首先介绍为了达到良好性能，我们如何从软硬件配置方面来保障，紧接着讨论了在多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。

第 2 部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。

内容提要大多数DB2 系统都经过了性能的演变。

首先，不论出于硬件还是软件的观点，该系统首先要能被配置。

在多数情况下，这将成为系统在实施后如何运行的基础。

其次，系统一经发布，勤勉的数据库管理员（DBA）将监控系统的性能，来监测任何可能的开发问题。

如果发现任何问题，我们就进入下一个阶段- 故障诊断阶段。

每个阶段都是基于上一阶段，如果没有适当的准备，我们极有可能需要处理比较困难的问题。

本文介绍了DB2 系统性能的最优方法。

我首先涉及到一些有助于我们确保良好软硬件性能的重要原则。

然后我们讨论多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。

最后，尽管我们做了最好的准备，性能问题仍然可以降临到我们身上，我们讨论如何逐步地处理它们，并有条不紊的进行。

回页首简介任何形式的性能问题都将严重影响并降低一个系统对你组织的价值、削弱业务能力、服务中断、以及增加管理开销。

所有这些都会提升总的拥有成本。

缺乏对系统配置的基本原则，监视和性能故障诊断可能导致不同程度的性能低下，并且降低对于组织的价值。

因此，在前期花些时间去考虑基本的配置指导方针和建立健全的系统监控这样的做法，将使你对处理许多可能出现的典型性能问题，有充分的准备。

并使数据服务器得以高性能运行，以提高投资回报率。

回页首第一步：从配置上实现性能良好像InfoSphere 平衡的仓库（BW）这类的DB2 部署类型，或者那些在SAP 系统之内的系统，配置都是高度确定的。

在BW 案例中，像CPU 个数、内存对 CPU 的比率、硬盘的个数和配置这样的硬件因素，以及在预先指定版本的基础上，详尽的测试，以确定最优配置。

DB2培训讲义_DB2性能优化入门

DML性能问题：查询优化
同时还要考虑到 RUNSTATS/REORG 因素。 RUNSTATS 命令可以更新表中的统计信息。当表中的数据经过频繁的增删改后其相应的统计信息会发生变化，而优化器选择执行计划的时候是根据这种统计信息来计算的，所以运行 RUNSTATS 此时显得尤为重要。 REORG 可以整理数据存储的物理结构，也能减少数据扫描的时间，提高查询的性能。从存储方面应当注意的是选取裸设备的 DMS 要比 SMS 性能要好，因为它少了一层文件系统的缓冲而直接访问缓冲池。
学会使用 optimize for n rows 子句，它可以提高前面 n 条记录的显示速度。这样可以使用户能够先快速查看这 n 条记录，然后再看其他纪录。减少了用户的等待时间。
DML性能问题：查询优化
针对复杂查询时可以将数据库配置参数 DFT_QUERYOPT( 缺省查询优化类 ) 的值设得高一些（7 或 9），针对简单查询可以将它设得低一些 (3 或 5)，因为设置越高优化器所作的分析就越深入，耗费在生成计划上的时间就越多。针对 C/S 结构的查询可以将查询语句写在服务器端生成存储过程来减少数据的网络传输以及客户端的压力。而经过编译的存储过程执行得更加高效。
DB2培训讲义
性能优化入门
有关的概念
DB2 性能优化的三个方面
内存 CPU I/O
内存因素
在内存方面，主要是考虑缓冲池 (BUFFERPOOL) 的使用。缓冲池是一片用来缓冲从磁盘上读取的数据和索引的内存区域，这些数据和索引信息在缓冲池中进行运算后最终还要写回磁盘。缓冲池的页面大小有四种 (4K,8K,16K,32K)，分别对应四种不同页面大小的表空间。缓冲池的大小决定了能够从磁盘上缓冲数据的容量大小。当然缓冲池也不是越大越好，缓冲池过大可能会导致连接数据库的时间过长，因为在连接数据库时要为数据库的缓冲池分配内存空间。可以通过计算缓冲池的命中率来评估缓冲池的使用效率：缓冲池命中率 =(1-(( 数据物理读 + 索引物理读 )/( 数据逻辑读 + 索引逻辑读 ))) *100%，缓冲池命中率越大说明缓冲池的使用效率高。缓冲池命中率太小说明缓冲池太小应当调大。其中的数据物理读，索引物理读以及数据逻辑读和索引逻辑读都可以从缓冲池的快照中获取。

DB2数据库设计：取得最佳性能的准则-电脑资料

DB2数据库设计：取得最佳性能的准则-电脑资料在开发过程的早期作出的很多设计决定对DB2应用程序和数据库的性能有着巨大的影响，。

本文为在z/OS环境中取得更好的性能提供了一些一般性的指南和建议。

一、简介本文的目的是为IBM业务伙伴提供关于DB2 Universal Database?(UDB)for z/OS(后面将简称为DB2)环境中DB2数据库性能的重要信息。

本文试图从多处收集材料，并尽可能有效地将它们表述出来。

本文无意包含很全面的范围，也不会包含很深的细节。

我曾打算讨论对DB2数据库的性能影响最大的一些因素。

但是，并不是所有可能的情形都可以预测到，也不是所有潜在的考虑都能顾及到，更不用说在期望的范围内对它们进行描述了。

我希望本文可以为不同环境下的DB2用户提供一个通用的指南，以帮助他们取得最佳的DB2数据库性能。

本文的目的是成为一个良好的起点，用以处理任何给定安装环境下的数据库性能问题。

本文的范围是数据库设计性能。

DB2性能远不止这一部分，它肯定要受到数据库设计以外的很多因素的影响。

例如，程序的编码逻辑和其中使用的实际的SQL语句，可以列为应用程序设计一类。

DB2系统性能可以包括诸如安装选项、缓冲池大小设置、DB2相关地址空间的调度优先级等等之类的因素。

本文的焦点是DB2数据库的设计。

不过，有时候这些性能因素类别之间的界线可能会有些模糊。

例如，在某种安装环境下进行配置时，缓冲池大小的设置和数量的选择通常被认为是一项系统性能因素。

但是，倘若是将特定的表空间和索引指派给那些缓冲池，那么这些因素又可以看作是数据库设计一类的因素了。

在这里，我假设读者对z/OS环境中的DB2有一个基本的理解。

本文的头几页将讨论性能管理的一些基本概念和准则，以便进行“级别设置” 。

我的建议有点综合的性质，因而不会总是详细地给出技术性的描述和语法。

读者如果想了解关于这些内容的更详细的信息，那么应该去阅读关于用户本地所安装的DB2版本的最近的IBM文档。

（转）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性能调节工作总结近期负责了Metric项目的服务器性能维护，对DB2的性能调节做了些研究。

整体感觉数据库调优的关键点应该还是在建库阶段，好的查询更能得到更好的性能。

而后期对数据库参数等的调节结果并不是非常明显的。

网上数据库调节方面的资料也很多，但大多数都是转来转去的，在此只做下我个人的工作总结;（//表示对上诉解释##表示对下面解释）############1,Monitoring##################db2 get database manager monitor switches//显示监视开关的情况db2 update dbm cfg using DFT_MON_BUFPOOL ONDFT_MON_LOCK ONdb2 update dbm cfg using DFT_MON_SORT ONDFT_MON_STMT ONdb2 update dbm cfg using DFT_MON_TABLE ONDFT_MON_UOS ONdb2 terminatedb2stopdb2start//在实例级打开监视开关，这样随着实例的重启，开关生效db2 get database manager monitor switchesdb2 get monitor switches//发现实例级和下面的数据库监视开关都打开了db2 deacivate database tp1db2 activate database tp1//重新激活数据库，刷新监视数据selectagent_id,rows_read,rows_written,rows_selected,rows_inserted from sysibmadm.snapappl//监视每个代理读写查询的情况，如果read的数量远高于select的数量，考虑是不是缺少索引//在我的工作中，很少遇到写多的情况，所以对这方面也没深入db2 get snapshot for tables on tp1 > sntab1.txt//接下来监视tp1数据库下所有表的读写啦##下一步，就是抓到那个有大量读大于写的表，然后提取该表上的查询SQL##这里就要考虑两种情况了，是静态的还是动态的##@@@静态的，从包里提取db2bfd -s sqltp1st.bnd##@@@动态的，可以用snapshot SQL STATEMENT抓取,这里不写了//然后就要提取出我们关注的大量读的查询SQL//我不太喜欢这部，累眼睛，还烦琐!!!如果有大量查询SQL，还需要想办法自己找出db2 describe indexes for table acct show detail//然后就是从提出的SQL中找到表，从表中看有没有索引，没有的话，新建##之后呢，就可以从访问计划中看索引有没有生效##静态SQL可以用db2expln从包里弄，本人比较喜欢db2exfmt,因为动静SQL都可以弄##后面有db2exfmt关于动静的例子,我比较习惯把SQL statement拿出来##然后放进文本里,db2expln -d GTSSTGMS -f SQL.txt -g -z \; -o GTSSTGMS_sort.txt##或者，db2 connect to tp1##db2 set current explain mode explain##db2 set current explain snapshot explain##db2 "select name,address from acct where ......"##db2exfmt -l -d tp1 -o extp2.txt => vi extp2.txt############2,Talespace and I/OPerformance##################db2 select bpname，bufferpoolid,npages,pagesize fromsyscat.bufferpools//查看数据库的缓冲池，syscat.bufferpools中的bufferpoolid 字段和sysibmadm.snapdb_memory_pool//的pool_secondary_id是关联的，从后一张表中记载着用户用户间的缓冲池和系统自建的缓冲池//CURRENT_SIZE 当前大小;POOL_CONFIG_SIZE 设置大小;HIGH_WATERMARK 最高记录;//我发现,这和使用db2pd -db GTSSTGMS -mempools是对应的PhySz PhyUpBnd PhyHWM//使用db2pd -db GTSSTGMS -memset，将同类内存集合并计算//在这里插一段缓冲池自调节功能介绍@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@下面我们创建示例缓冲池MYBP1，其使用自调整功能（注意其create bufferpool语句使用了automatic），初始大小为400K，具体如清单4所示：创建使用自动自调整功能的示例缓冲池MYBP1db2 create bufferpool mybp1 immediate size 100 automatic pagesize 4kdb2 "select BPNAME, NPAGES from sysibm.sysbufferpools"当缓冲池启用了自调整功能时，该特定缓冲池的sysibm.sysbufferpools 表中的NPAGES 字段将设置为-2。

DB2数据库性能优化

DB2数据库性能优化1.设计合理的数据库结构：合理的数据库结构对于性能优化至关重要。

通过合理设计数据库的表结构、关系和索引，可以减少查询和数据操作的复杂度，提高数据库的响应速度。

2.使用合适的数据类型：选择合适的数据类型可以减少存储空间的占用，提高数据的存取速度。

例如，使用整型数据类型代替字符类型可以减少存储空间的占用和索引的大小，提高查询的效率。

3.创建适当的索引：索引是提高查询效率的重要手段。

通过创建合适的索引，可以加快查询速度和数据检索的准确性。

但是过多的索引会增加数据写入的开销，因此需要权衡索引的创建和维护的成本。

4.优化查询语句：查询是数据库操作中最常见的操作，优化查询语句可以显著提升数据库的性能。

在编写查询语句时，应尽量避免使用复杂的连接和子查询，选择合适的查询优化器，使用合适的查询计划，提高查询的效率。

5.控制事务的粒度和并发访问：合理的控制事务的粒度和并发访问可以减少锁冲突和等待，提高并发操作的效率。

通过合理设置数据库的并发模式、锁策略和事务提交的时机，可以有效提高数据库的并发性能。

6.适当的内存配置：DB2数据库可以通过内存缓存提高数据的读取和写入速度。

合理的内存配置可以减少磁盘I/O操作，提高数据库的性能。

通过调整数据库的缓存大小、内存池和高速缓存参数，可以提高数据库的性能。

7.定期维护和优化：定期维护和优化是保持数据库性能的重要手段。

通过定期进行数据库的备份和恢复、数据清理和压缩、表和索引的重组和优化等工作，可以保持数据库的健康运行和高效性能。

8.监控和调优工具的使用：DB2数据库提供了丰富的监控和调优工具，可以帮助管理员追踪和诊断数据库的性能问题。

通过使用这些工具，可以及时发现和解决数据库的性能瓶颈，提高数据库的运行效率。

总结起来，DB2数据库性能优化是一个持续改进的过程，需要综合考虑数据库结构、查询语句、系统配置和运行环境等因素。

通过合理的设计、优化和维护，可以最大限度地提升DB2数据库的性能和运行效率。

db2数据库性能参数优化笔记整理

db2数据库性能参数优化笔记整理1、Application Support Layer Heap Size (ASLHEAPSZ)它是app和agent通信的buffer，占用实例共享内存空间。

监控:get snapshot for all on | grep –i “Rejected Block Remote Cursor requests”Rejected Block Remote Cursor requests = 2283如果Rejected Block Remote Cursor requests值比较高，增大ASLHEAPSZ值，直到该值为0配置：update dbm cfg using aslheapsz 202、Maximum Requester I/O Block Size (RQRIOBLK)它是client和server通信的buffer，占用每个agent的私有内存空间。

监控:无法监控配置：建议设置为最大值64K，缺省32767bytes，（设到最大值不会影响其它性能）update dbm cfg using rqrioblk 655363、Sort Heap Threshold (SHEAPTHRES)私有模式排序空间最大阀值，值＝并发数×SORTHEAP监控：需要打开sort监控开关－db2 update monitor switches using sort onget snapshot for dbm | grep –i “sort”如果Post threshold sorts值比较大，增加SORTHEAP 、SHEAPTHRES参数值如果(Piped sorts accepted/Piped sorts requested)值比较低，增加SORTHEAP 、SHEAPTHRES参数值配置：update dbm cfg using sheapthres 800004、Enable Intra-Partition Parallelism (INTRA_PARALLEL)在SMP环境中打开该选项，提高表和索引扫描速度监控：list applications看application对应的Agents（# of Agents）数目是否大于1 配置：update dbm cfg using intra_parallel yes5、Maximum Query Degree of Parallelism (MAX_QUERYDEGREE)指定一个SQL语句的最大subagent数目，当INTRA_PARALLEL 值为yes时该参数起作用。

调优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缓冲池问题的诊断及优化背景知识缓冲池是内存中的一块存储区域，用于临时读入和更改数据库页（包含表行或索引项）。

缓冲池的用途是为了提高数据库系统的性能。

从内存访问数据要比从磁盘访问数据快得多。

因此，数据库管理器需要从磁盘读取或写入磁盘的次数越少，性能就越好。

对一个或多个缓冲池进行配置之所以是调优的最重要方面，是因为连接至数据库的应用程序的大多数数据（不包括大对象和长字段数据）操作都在缓冲池中进行。

缺省情况下，应用程序使用缓冲池IBMDEFAULTBP，它是在创建数据库时创建的。

当 SYSCAT.BUFFERPOOLS 目录表中该缓冲池的NPAGES 值为-1 时，DB2 数据库配置参数BUFFPAGE 控制着缓冲池的大小。

否则会忽略BUFFPAGE 参数，并且用 NPAGES 参数所指定的页数创建缓冲池。

建议对于仅使用一个缓冲池的应用程序，将 NPAGES 更改成 -1，这样BUFFPAGE 就可以控制该缓冲池的大小。

这使得更新和报告缓冲池大小以及其它 DB2 数据库配置参数变得更加方便。

确保可以使用数据库配置中的 BUFFPAGE 参数来控制缓冲池大小之后，将该参数设置成合适的值。

根据数据库的大小和应用程序的性质将该参数设置成一个合理的大值，这种做法很安全。

通常，该参数的缺省值非常小，可能满足不了要求。

请考虑下列情况：一开始，如果您的机器上有足够大的内存，请将BUFFPAGE 设置成 40000 个页（160 MB），或者等于机器总内存的 10%。

对于大型OLTP 数据库，在保持系统稳定的同时为缓冲池留出尽可能多的内存。

一开始，先尝试使用1.6 GB 的内存，然后尝试用更多内存。

如何更改该参数运行下面这个脚本，以便：验证目录值启用数据库配置参数 BUFFPAGE更新所有数据库的 BUFFPAGE 值。

db2 -v connect to DB_NAMEdb2 -v select * from syscat.bufferpoolsdb2 -v alter bufferpool IBMDEFAULTBP size -1db2 -v connect resetdb2 -v update db cfg for dbname using BUFFPAGE bigger_valuedb2 -v terminate研究步骤要确定数据库的缓冲池大小是否由 BUFFPAGE 参数所决定，请运行：db2 -v connect to DB_NAMEdb2 -v SELECT * from SYSCAT.BUFFERPOOLSdb2 -v connect resetdb2 -v terminate检查结果。

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性能调整

1性能监控开关1.1打开开关db2 update dbm cfg using DFT_MON_BUFPOOL ON DFT_MON_LOCK ON DFT_MON_SORT ONdb2 update dbm cfg using DFT_MON_STMT ON DFT_MON_TABLE ON DFT_MON_UOW ON1.2查看开关db2 get dbm cfg|grep –i "DFT_MON"db2 get dbm cfg|findstr "DFT_MON"db2 get db cfg for s_d_1303 >>E:\Doc\技术文档\8.DB\DB2资料\cfg.txtdb2 get dbm cfg >>E:\Doc\技术文档\8.DB\DB2资料\cfg.txt缺省数据库监视开关1.3获取快照1.4内存快照1.5锁监控方法1.6监控收集信息2操作系统监控2.1top2.2vmstatProcs（进程）：1.r: 运行队列中进程数量r表示运行队列(就是说多少个进程真的分配到CPU)，我测试的服务器目前CPU 比较空闲，没什么程序在跑，当这个值超过了CPU数目，就会出现CPU瓶颈了。

这个也和top的负载有关系，一般负载超过了3就比较高，超过了5就高，超过了10就不正常了，服务器的状态很危险。

top的负载类似每秒的运行队列。

如果运行队列过大，表示你的CPU很繁忙，一般会造成CPU使用率很高。

2.b: 等待IO的进程数量b表示阻塞的进程,这个不多说，进程阻塞。

⏹Memory（内存）：3.swpd: 使用虚拟内存大小swpd虚拟内存已使用的大小，如果大于0，表示你的机器物理内存不足了，如果不是程序内存泄露的原因，那么你该升级内存了或者把耗内存的任务迁移到其他机器。

4.free: 可用内存大小free 空闲的物理内存的大小，我的机器内存总共8G，剩余3415M。

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 对缓冲池的性能优化博客分类：DB2db2 对缓冲池的性能优化需求：因为项目开始的时候没有对DB2数据库进行深入的熟悉，所以造成项目后期做性能测试的时候，导致应用访问过慢，后来决定从数据方面做做一下性能优化，主要在于缓冲池方面。

解决方案：因为数据库中只有一个常规表空间表空间USERSPACE1和一个缓冲池IBMDEFAULTDP（1G）,所以决定重新再建一个大的缓冲池BP2，将USERSPACE1赋给BP2CREATE BUFFERPOOL BP2 SIZE 2048 PAGESIZE 4K;ALTER TABLESPACE USERSPACE1 BUFFERPOOL BP2;附注：以下为对网上资源学习后的一个总结：1、表空间I、数据存储层级关系：数据库-->表空间-->容器-->表，II、表空间分类：目录表空间特性：每个数据库只有一个目录表空间，它是在发出CREATE DATABASE 命令时创建的.目录表空间被DB2 命名为SYSCATSPACE，用途：它保存了系统目录表；常规表空间特性：创建数据库时指定该表空间的缺省名为USERSPACE1。

长表空间是可选的，缺省情况下一个都不创建，用途：保存表数据和索引、还可以保存LOB之类的长数据；系统临时表空间特性：随数据库创建的系统临时表空间的缺省名为TEMPSPACE1，用途：用于存储SQL 操作（比如排序、重组表、创建索引和连接表）期间所需的内部临时数据；以上是由系统管理的空间（SMS），必须有一个以下是由数据库管理的空间（DMS），可选长表空间用途：用于存储长型或LOB 表列，存储结构化类型的列或索引数据用户临时表空间用途：存储已声明的全局临时表LOB(large object)的定义：是一种用于存储大对象的数据类型，如医学记录（如X-射线）、视频、图像等。

LOB有三种类型：BLOB：Binary Large Object、CLOB：Character Large Object、DBCLOB：Double-byte Character Large Object。