下载文档原格式
db2数据库优化方案随着企业数据量的不断增加，数据库的性能优化变得越来越重要。
在众多数据库中，DB2是一款功能强大的关系型数据库管理系统。
本文将为您介绍一些针对DB2数据库的优化方案，以提高数据库的性能和效率。
一、合理设计数据库结构良好的数据库设计是优化数据库性能的基础。
以下是一些设计数据库结构的准则：1. 使用适当的数据类型：根据数据的特性选择适当的数据类型，减小存储空间的占用，提高查询和更新速度。
2. 设计有效的主键和外键：将主键和外键应用到表的关键字段上，以确保数据的完整性和一致性，并加速查询操作。
二、合理设置数据库参数通过调整数据库参数，可以改善DB2的性能表现。
以下是一些常用的数据库参数设置建议：1. 缓冲池设置：调整缓冲池的大小，使得主要用于查询的表和索引可以被缓存，减少磁盘I/O操作。
2. 日志设置：根据业务需求设置日志的大小和数量，以平衡事务处理的性能和数据恢复的能力。
3. 并发设置：根据并发操作的需求和服务器硬件性能合理设置并发连接数和锁定策略，以提高系统的并发处理能力。
三、优化查询语句优化查询语句可以提高DB2数据库的性能和响应时间。
以下是一些优化查询语句的建议：1. 使用索引：根据查询的字段和条件创建适当的索引，加快查询速度。
2. 正确使用JOIN操作：避免使用不必要的JOIN操作，优化表之间的关联关系，减少查询的复杂性。
3. 避免全表扫描：尽量避免使用SELECT *的方式查询数据，只选择需要的字段，减少数据库的负载。
四、定期维护数据库定期维护数据库可以确保数据库的正常运行和优化性能。
以下是一些数据库维护的建议：1. 优化表和索引：根据数据库的使用情况定期重新组织表和索引，保持数据的连续性和最佳性能。
2. 清理无用数据：定期删除或归档不再使用的数据，减少数据库的存储空间占用。
3. 备份和恢复策略：制定完备的数据库备份和恢复策略，以防止数据丢失和灾难恢复。
五、硬件优化优化数据库的硬件环境可以提高系统的性能和可靠性。
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性能调优：设计并配置你的数据库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數據庫性能調整的十個實用技巧，詳細內容請讀者參考下文。
（本文主要針對e-business OLTP10個性能方面的Tips）1.SQL COST ANALYSIS許多情況下，一個簡單的SQL就可能讓DB2系統處於尷尬的狀態。
調整參數也不能解決此問題。
由於DBA很難去改變這些垃圾SQL的現狀，所以留給DBA的就是下面的情況：(1). Change or add indexes(2). Change clustering(3). Change catalog statistics.註：一個SQL語句的cost=每次執行的資源代價*執行的次數。
目前，DBA面臨的挑戰就是要找到那些有很高cost的語句，並且盡力去減少它的代價。
可以借助DB2 Explain工具或者DB2 UDB SQL Event Monitor數據來分析SQL語句的代價。
尤其是對SQL Event Monitor的數據分析，但這麼做需要耗費很大的精力和時間。
一般DBA的流程是：(1). Create an SQL Event Monitor, write to file:$> db2 "create event monitor SQLCOST for statements write to ..."(2). Activate the event monitor (be sure ample free disk space is available):$> db2 "set event monitor SQLCOST state = 1"(3). Let the application run.(4). Deactivate the event monitor:$> db2 "set event monitor SQLCOST state = 0"(5). Use the DB2-supplied db2evmon tool to format the raw SQL Event Monitor data (hundreds of megabytes of free disk space may be required depending on SQL throughput rates):$> db2evmon -db DBNAME -evm SQLCOST> sqltrace.txt(6). Browse through the formatted file scanning for unusually large cost numbers, a time-consuming process:$> more sqltrace.txt(7). Undertake a more complete analysis of the formatted file that attempts to identify unique statements (independent of literal values), each unique statement's frequency (how many times it occurred), and the aggregate of its total CPU, sort, and other resource costs. Such a thorough analysis could take a week or more on just a 30-minute sample of application SQL activity.為了以最快的速度找到相應的SQL，我們可以考慮上文講過的一些方法：針對第4個tip：計算每個交易從一個table裡面取出的行數。
（转）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性能调节工作总结近期负责了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数据库是一种关系型数据库管理系统，由IBM开发和维护。
为了提高DB2数据库的性能和效率，需要进行一系列的优化操作。
下面将介绍一些常见的DB2数据库优化方法。
1.确保合适的硬件配置：DB2数据库的性能很大程度上依赖于底层硬件的性能。
因此，为了获得最佳性能，需要确保数据库运行在合适的硬件配置下。
这包括选择合适的处理器、内存和磁盘配置。
2.优化数据库设计：良好的数据库设计可以提高数据库的性能。
可以通过合理的表设计、索引设计和关联设计来减少数据的冗余和重复，从而提高查询和更新的效率。
3.数据库分区：当数据库中的数据量增加时，可以考虑对数据库进行分区，将数据划分为多个分区存储。
这样可以提高查询和更新的效率，减少锁冲突，并且可以利用多个处理器并行处理多个分区。
4.合理使用索引：索引是提高数据库查询性能的重要手段。
在创建索引时，需要根据实际情况选择合适的列和索引类型，并避免创建过多的索引，以防止影响更新操作的性能。
5.定期收集统计信息：收集数据库表的统计信息可以帮助DB2优化器生成更高效的查询计划。
可以使用DB2提供的统计信息收集工具来定期收集表的统计信息，并确保统计信息是最新的。
6.合理设置数据库参数：DB2数据库有很多参数可以进行优化配置。
这些参数包括缓冲池大小、日志文件大小和数据库连接数等。
通过合理设置这些参数，可以提高数据库的性能和响应速度。
7.优化SQL查询语句：SQL查询语句的性能直接影响数据库的性能。
可以通过使用合适的连接方式、避免使用不必要的子查询和关联查询等方式来优化查询语句。
8.避免长事务：长时间运行的事务会占用数据库资源，影响其他查询和更新操作的性能。
因此，需要尽量避免长时间运行的事务，或者使用事务分解等方式将长事务分解为多个短事务。
9.定期清理无用数据：数据库中的无用数据会占用磁盘空间，并影响查询和更新操作的性能。
因此，需要定期清理无用数据，例如删除过期的日志文件、归档数据和临时表等。
DB2数据库性能优化1.设计合理的数据库结构：合理的数据库结构对于性能优化至关重要。
通过合理设计数据库的表结构、关系和索引，可以减少查询和数据操作的复杂度，提高数据库的响应速度。
2.使用合适的数据类型：选择合适的数据类型可以减少存储空间的占用，提高数据的存取速度。
例如，使用整型数据类型代替字符类型可以减少存储空间的占用和索引的大小，提高查询的效率。
3.创建适当的索引：索引是提高查询效率的重要手段。
通过创建合适的索引，可以加快查询速度和数据检索的准确性。
但是过多的索引会增加数据写入的开销，因此需要权衡索引的创建和维护的成本。
4.优化查询语句：查询是数据库操作中最常见的操作，优化查询语句可以显著提升数据库的性能。
在编写查询语句时，应尽量避免使用复杂的连接和子查询，选择合适的查询优化器，使用合适的查询计划，提高查询的效率。
5.控制事务的粒度和并发访问：合理的控制事务的粒度和并发访问可以减少锁冲突和等待，提高并发操作的效率。
通过合理设置数据库的并发模式、锁策略和事务提交的时机，可以有效提高数据库的并发性能。
6.适当的内存配置：DB2数据库可以通过内存缓存提高数据的读取和写入速度。
合理的内存配置可以减少磁盘I/O操作，提高数据库的性能。
通过调整数据库的缓存大小、内存池和高速缓存参数，可以提高数据库的性能。
7.定期维护和优化：定期维护和优化是保持数据库性能的重要手段。
通过定期进行数据库的备份和恢复、数据清理和压缩、表和索引的重组和优化等工作，可以保持数据库的健康运行和高效性能。
8.监控和调优工具的使用：DB2数据库提供了丰富的监控和调优工具，可以帮助管理员追踪和诊断数据库的性能问题。
通过使用这些工具，可以及时发现和解决数据库的性能瓶颈，提高数据库的运行效率。
总结起来，DB2数据库性能优化是一个持续改进的过程，需要综合考虑数据库结构、查询语句、系统配置和运行环境等因素。
通过合理的设计、优化和维护，可以最大限度地提升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。
---优化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数据库性能参数优化笔记整理数据库, 笔记, 性能, 参数, 调优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时该参数起作用。
如果该值为ANY (-1务器的最大cpu数目。
监控：list applications看application对应的Agents（# of Agents）数目是否大于1配置：update dbm cfg using MAX_QUERYDEGREE 4 IMMEDIATE6、Query Heap Size (QUERY_HEAP_SZ)占用agent的私有内存空间，存储每个agent运行时所有的sql文，包括the input SQLDA，the output SQLDA the SQLCA，the package name，the package creator，the section number，a consistency token，th k for any blocking cursors。
监控：无法监控配置：一般不需要修改，如果访问大的LOB，可能需要增加该值update dbm cfg using query_heap_sz 100007、Number of FCM Buffers (FCM_NUM_BUFFERS)在multi-partitioned database（partition之间）和intra-partition parallelism enabled（subagent之间）环在AIX上，如果DBM有充足的空间，每个partition依照FCM配置拥有独立的空间，如果不够，所有partition依照在其它操作系统上，所有partition依照FCM配置共享空间；如果DB2_FORCE_FCM_BP注册变量设置为YES，所有partition将一直共享空间，但大小将受32bit的OS限制监控：get snapshot for FCM for all dbpartitionnums配置：update dbm cfg using fcm_num_buffers 4096 immediate8、Connection、Agent配置监控：db2 get snapshot for dbm | grep -i agentHigh water mark for agents registered = 2High water mark for agents waiting for a token = 0Agents registered = 2Agents waiting for a token = 0Idle agents = 1Agents assigned from pool = 146Agents created from empty pool = 3Agents stolen from another application = 0High water mark for coordinating agents = 2Max agents verflow = 0Gateway connection pool agents stolen = 09、Keep Fenced Process (KEEPFENCED)UDF和SP按照运行模式分为两种：fenced和unfenced，fenced模式是一种c/s的通信方式，存储过程为客户端请为其执行业务逻辑。
unfenced模式是一种直接调用db2进程并在进程的地址空间内执行，有不安全性，但该模式可以nced模式做不到。
如果KEEPFENCED设置为YES，可以使UDF或SP所调用fenced进程或线程一直保持并被重复使用，一直到实例关一定资源（如内存）。
例如，使用java写的sp，sp运行完成后不会结束JVM，下次运行sp将省去启动JVM的时间配置：update dbm cfg using keepfenced YES10、Maximum Total of Files Open (MAXFILOP)服务器打开文件的最大数目，如果使用SMS容器，要求该值比较高，也需要检查操作系统对该值的限制。
配置：update db cfg using maxfilop 2000监控：（需要bufferpool的monitor：db2 update monitor switches using bufferpool on）db2 get snapshot for db on testdb |grep -i …close‟11、Default Buffer Pool Size (BUFFPAGE)调整缓冲池的大小办法：1、alter bufferpool IBMDEFAULTBP size -1，修改所有bufferpool大小为-1，然后依赖BUFFPAGE参数控制，的）＋创建的缓冲池（含IBMDEFAULTBP），每个创建的缓冲池大小＝pagesize×buffpage×（1＋5％）2、直接修改bufferpool大小，建议使用该方法，可以控制pagesize大小不同缓冲池的大小。
配置：update db cfg for using BUFFPAGE bigger_valuealter bufferpool IBMDEFAULTBP size -1监控：get snapshot for db on db_name12、Log Buffer Size (LOGBUFSZ)从logbuff写到磁盘的激活条件：1）A transaction commits (or MINCOMMIT transactions commit). （最小提交事务数时flush）2）The log buffer is full（日志缓冲满时flush）3）One second has elapsed since the last log buffer flush.（间隔1秒时flush）配置：update database cfg for using LOGBUFSZ 256监控：get snapshot for database on | grep –i “Log space”Log space available to the database (Bytes) = 4549916Log space used by the database (Bytes) = 550084Maximum secondary log space used (Bytes) = 0Maximum total log space used (Bytes) = 550084CLSA(current amount of log space available ) = Log space available to the database - Log space u e, CLSA就是LOGBUFSZ参数可以配置的最大值。
get snapshot for database on | grep –i “Log pages”Log pages read = 0Log pages written = 12644日志页面读（Log pages read）是日志记录器（logger）从磁盘读取的日志页面的数目，而日志页面写（Log page 器（logger）写入磁盘的日志页面的数目。
理想状态，Log pages read为0，如果该值比较大，考虑增加LOGBUF13、Application Heap Size (APPLHEAPSZ)存放agent或subagent当前sql文处理的所需内存，大小决定于sql文的复杂度及宿主变量大小。
如果是分区数据库_CTL_HEAP_SZ堆，而不在应用程序堆。
在运行时按需要分配内存，这个值仅是上限值。
配置：update database cfg for using applheapsz 1024监控：无法监控，如果应用报错，加倍该值，看应用错误是否消失14、Sorting (SORTHEAP, SHEAPTHRES_SHR)只有INTRA_PARALLEL 数据库管理器配置参数是ON 或启用集中器（concentrator）时（即当MAX_CONNECT RDAGENTS 时），才可以使用共享排序。
