DB2数据库管理最佳实践笔记-16优化器与能调优.docx

优化器优化器是关系数据库的核心，相当于汽车的发动机，DB2在业界最值得称道的功能之一就是其强大的优化器。大多数情况下，用户不必干预优化器的执行，而且DB2优化器总是足够聪明地选择最佳访问计划，当然前提是数据库的统计信息被及时收集。统计信息-每个数据库对象状态的信息，可以使用SYSSTAT模式的视图访问：db2 list tables for all|grep -i SYSSTAT不同数据对象类型的统计信息使用不同的视图访问。相比Visual Explain工具，作者强烈推荐使用db2exfmt工具，生成文本访问计划。相比前者生成图形化的访问计划，后者包含更多重要的信息。例：db2sampldb2 connect to sample#创建访问计划表db2 -tvf C:Program FilesIBMSQLLIBMISCEXPLAIN.DDLc:db2a.txtdb2 select empno,firstnme,lastname from employee,department where employee.workdept =department.deptno and mgrno=000060#打开访问计划选项db2 set current explain mode explain#然后执行以下sql，此时会生成针对该sql的访问计划被存储在EXPPLAN.DDL文件中db2 select empno,firstnme,lastname from employee,department where employee.workdept =department.deptno and mgrno=000060#关闭访问计划选项db2 set current explain mode explain no#使用以下工具将这些信息汇总到一个文件中db2exfmt -d SAMPLE -g TIC -w -l -n % -s % -# 0 -o prod_sample_exfmt.txt接下来分析此文件！系统信息系统设置数据库中对优化器起作用的参数：Parllelism = None 代表单分区 = Interparallel 代表多分区 = Intraparallel 代表分区内并行 CPU速度：当前cpu速度的一个估算值，该值并不代表任何有意义的单位，而是DB2在优化其中使用CPU速度作为一个参数，该数值在实例启动时自动计算。Comm Speed：通信速度，在多分区系统中默认为100，可以根据需求调节。Buffer Pool Size：系统中缓冲池总页数的和，注意DB2优化器在计算访问计划时，并不知道有哪些缓冲池将被使用（譬如说某些计划可能需要一些临时表，而临时表的缓冲池也许不同于数据表），因此缓冲池大小只是简单地将数据库中所有缓冲池的页面数量相加。Sort Heap Size:排序区的大小，用来估算排序或者哈希关联是否会溢出。Database Heap size:数据库堆栈大小，在通常情况下对访问计划不会产生决定性的影响。Lock List Size、Maximum Lock List 、Average Applications与Locks Available是锁列表的信息，用来估算某些类型的数据访问是否有足够锁列表容纳相关数据。要点：DB2的优化器足够强大，可以通过不同的查询条件排列次序估算出执行时哪个条件在前会比较有利。因此用户自己的排列不会被优化器所认可，优化器完全基于开销对访问计划进行评估。访问计划估算值并没有实际单位，比较两个访问计划时，一定要基于同一个系统。在不同系统间的开销不具有可比性。读访问计划时从上到下、从左到右。 性能调优性能调优在很多方面与问题诊断有相通之处，甚至从某种程度上说，性能调优是建立在成功的问题诊断的基础之上。性能诊断强调的是“诊断”二字，也就是弄明白系统为什么慢，瓶颈出在什么地方，弄明白问题但却不一定能真正解决这个问题。调优的最终目的不是完全挖掘出问题的根源，而是用不同的手段提升系统的单位时间内吞吐量。性能调优比性能分析更加直观与灵活。有的时候只要了解了系能问题的现象，通过经验与一定程度上对应用与数据库的理解，就能够大体上给出一个调优的方向（譬如是磁盘问题、CPU问题或者内存问题）调优思路：首先，尝试理解系统的架构。至少弄明白系统多少CPU、多少内存，多少连接之类的最基本问题。其次，将问题细化到CPU、内存、I/O或者系统懒惰的大方向。再次，就是要给出一个期望值，尝试用不同的手段将某种指标提高的目标之上，然后再次重复细化问题的步骤，直到系统的整体性能达到预期。两个难点（第一个更重要）1.如何找到一个合理的目标与期望值。（参考最佳实践文档或IBM官方网站寻找资料）2.用什么手段达到目的。另一个更具体的思路KPI（国内外无数性能专家多年来的总结）KPI可以被分为以下几个级别：数据库级别实例级别操作系统级别数据索引缓冲池命中率 数据库、缓冲池、表空间快照 （逻辑读-物理读）/逻辑读 优秀：95% 良好：80% 读行v.s.选择行 数据库快照 Rows Read/Rows Select OLTP系统：=5 SAP系统：SHEAPTHRES物理磁盘数量 操作系统信息 每个CPU内核对应620个物理磁盘数量以下引用网友文章/club/thread-23175-1-1.html性能优化的几个关键指标（KPI）在性能调优时，经常有无从下手的困惑，尤其是当发现数据库变慢时，不知道如何进行量化分析。我们将从经验的角度给出一些关键参数的阀值，这样在进行性能分析时，就可以从这些关键参数入手了。下面的关键性能指标，我们又称之为KPI（Key Performance Indicator），供大家参考。 数据缓冲区命中率（Data Bufferpool Hit Ratio）： 95% 索引缓冲区命中率（Index Bufferpool Hit Ratio）： 98% 平均读写时间（Read / Write Avarage Times）： 98% 编目缓冲区命中率（Catalog Cache Hit Ratio）： 98% 锁升级及死锁（Lock Escalations and Deadlocks）：仅有少量的锁升级或死锁 日志缓冲区（Log Buffer Hit Ratio）： 98% 排序溢出次数 / 排序次数 （Sort Overflow / Total Sort）： 1%注意：我们给出的KPI阀值并不是一个严格的限制，比如某些参数略低于KPI阀值也是允许的。另外，也需要考虑将这些值与性能问题出现之前的值进行比较，如果相差不大，则需要从其他角度考虑，例如数据库布局、磁盘或者网络是否有瓶颈等。实例1Linux 64位 8颗CPU内核，32G内存，db2版本9.5 Fixpack 5 一个实例 单分区。问题描述：每年年底在运行结算程序时，系统性能严重下降。平时表现一般，每年年底结算程序运行时，一定要减少并发数量，否则会轻易造成100%CPU使用率。分析方法：用户重置快照后，15分钟收集了若干包括数据库、实例、表空间、sql、应用程序等快照和一些系统信息进行分析vmstat 收集的信息可观察到CPU使用率维持在50%-70%左右。可从侧面反映客户描述的CPU资源消耗情况。ps -elf输出中，db2sysc进程的C列维持在99，db2fmp也在使用不少的CPU,但比前者少很多。由上可定位db2sysc中存在大量消耗CPU的任务。然后在数据库快照中看到：Buffer pool data logical reads = 3037962816Buffer pool index logical reads = 854461868两者比例相差将近4倍，也就是非常多的读是走表扫描，而不是索引扫描。（当然，对于OLAP系统来讲，有时候这种现象是正常的，分析人员一定要理解应用程序正在执行的业务）继续观察到Rows selected =76395867Rows read = 45143452324比例达到500以上，对比KPI，在OLTP系统中预期数值是5，这个系统显然是OLAP，但这也是明显不合理的。然后进入SQL快照，通过计算Total user cpu time/Number of executions 得到单一SQL的平均消耗CPU时间。从而定位消耗CPU资源的SQL，发现INSERT占用大量的资源。然后查看应用程序快照，统计UOW Executing的连接，与以上SQL进行对应，发现两个JAVA程序都是执行同样的INSERT，另外8个.exe程序都在执行前面所看到的那个消耗CPU最大的查询。到此有足够的理由认为，这几个（尤其那个消耗CPU最大的查询）查询需要被进一步优化，而入手点则应该从减少逻辑读开始。因为单纯的内存读并不占用I/O,但是大量的内存访问绝对对CPU是一大负担。从DBA的角度，可以尝试加一些索引或其他一些物理设计影响优化器的执行计划，减少表扫描或排序，降低CPU和其它资源的占用。如果不能解决问题，那就要协调设计开发从逻辑角度减少数据访问的数量。实例22010年初国外一家银行。系统运行DB2 V8,主要用于全国各地支行的柜台业务员在工作时间的一些业务处。问题集中在一个存储过程的执行中，该存储过程并不复杂，最主要一部分是一个INSERT操作，从4个表中做SELECT然后插入一个临时表。每周开始执行大概在0.5秒左右。可是随着数据量得增加该存储过程的性能不断下降。到了周五就需要3-4秒了。然后第二个周一恢复正常，在一周中持续下降，到周五又变成3-4秒了。通过描述，第一个问题就是：每天的数据量是否相同。深入研究后，发现用户每周的维护时间都使用脚本将一个大表清空一半左右的数据，然后进行REORG RUNSTATS REBIND,开始新一周的工作。由此推断，随着数据量得上升，系统的统计信息无法反应最真实的当前状态，优化器一直认为表中数据量相对较少，因而选择了一个对当前数据量并非最优的访问计划。逻辑上的推理完全能够解释这个现象。根据当时的数据观察，问题的大表所被读取的行数在一天内每天都有增长，同时对应的语句在一周内不同时间使用动态SQL抓exfmt,所显示的访问计划与维护完成之后的计划明显有所区别。这些数据都可以从侧面证实我们的推论（与性能诊断相同，在调优中千万不要由于某几条快照信息就匆忙的下结论，一定要从多方向多角度分析）但是用户的系统维护策略无法让他们每天运行RUNSTATS和REBIND,因此我们必须使用其他的方法来保证存储过程使用最优的访问计划。通过一般的逻辑判断，假设一个查询的访问计划对于大数据量时是最优的，那么当数据量减少后，尽管该计划可能并非最优，但是执行时间应该不会比数据量占用更多时间长。因为按照同样访问数据的方法，在数据量减少的情况下，性能不会比数据量多时更差。在这个前提条件下，我们测试了手工RUNSTATS和REBIND,发现在数据量最多的情况下，使用最新的统计数据可以使存储过程维持在一秒之内。最终解决此问题，有三种方法：1.使用profile,比较复杂。2.在删除数据之前做RUNSTATS REBIND,然后REBIND表释放空间。3.找一个周末，删除数据之前做RUNSTATS+REBIND的存储过程，然后在今后的维护脚本中永远不进行REBIND。经过两个实例的讲解，再次强调，性能调优不同于性能分析，我们的终极目标并不是找到根源并且硬碰硬地解决它，而是通过各种迂回的办法绕过这些问题。在很多时候，我们可能并不知道问题的根源，而是凭着处理过大量性能问题后得到的宝贵经验，对某一个或几个参数进行调整后提升性能，都是被认可的成功性能调优。索引索引实际上就是B+树，树中的每一个节点包含键值与一系列RID。索引之所以能够提升性能，就是在于当查找SQL的某个谓词时，可以使用B+树迅速的找到对应的一系列键值，而不去扫描整个表中所有的数据页。对于给定的谓词，能够将谓词中的条件与索引键值所代表的列相匹配，并且当优化器判定使用B+树扫描的效率高于全表数据页扫描的时候，这个索引就是有效的。两个条件第一个条件是，怎样能够让谓词条件与索引键值对应的数据列所匹配；第二个条件是，怎样让优化器认为使用索引的效率更高。以下有第一个条件相关假设一个键中包含数据列（C1，C2，C3）,那么想要判定C2的时候，给定的谓词条件中必须包含C1。同理，想要判定C2的时候，谓词条件必须保证C1、C2列都被包含。只有满足这个条件的谓词，才能够在索引扫描时使用Start/Stop Key谓词检索。否则即使使用索引，也是Sargable谓词或者Residual谓词扫描整个B+树，其开销在很多情况下甚至高于表扫描。具体这些谓词含义的解释，可见DB2数据库高级管理中优化器部分的讨论。Start/Stop Key与Sargable谓词显示的例子：db2 create table t1(c1 int,c2 int,c3 int,c4 int)db2 create index i1 on t1(c1,c2,c3)#插入一些不同的数据db2 insert into t1 values(1,2,3,4)db2 set current query potimization 0db2 set current explain mode explaindb2 select * from t1 where c1=? and c2=? and c3=?and c4=? #此语句索引扫描时将使用Start/Stop Key谓词检索。db2 select * from t1 where c1=? and c2=? and c3=?and c4=? #此语句索引扫描时将使用Sargable谓词检索。db2 set current explain mode explain nodb2exfmt -d SAMPLE -g TIC -w -l -n % -s % -# 0 -o prod_sample_exfmt.txt而第二个条件，就是一个更为复杂的问题。由于对优化器的详细介绍在下一本数据仓库书中进行，在这里不讨论优化器的算法。一般来说，想要使用优化器，需要从统计信息上做文章。如果用户发现即使建立的索引合法，但是有时候优化器依然使用全表扫描，这个时候用户可以将优化级别调为0，或者在表上加volatile(意思是可变的、容易变的)标识，使优化器更倾向于使用索引扫描而不是全表扫描。如果一个表被设定了volatile属性，优化器就会尽量忽略该表的统计信息，尽量使用索引扫描，避免执行根据不够实时的统计信息制定不够优化的访问计划。用户可以通过alter table voliatile来设定其属性。在创建索引时，应该遵循以下最佳实践1.分析组合索引键的顺序，如：（a,b）和（b,a）是完全不一样的。2.不要创建冗余索引，如：某张表有（a）,(a,b)两个索引，前者是多余的。3.验证索引是否被用到，如果没有用到，建议删除。4.尽可能通过include创建index-only索引，减少数据获取I/O,提升效能。索引是DBA的性能调优器，主要优点概括1.最主要的目的是提高查询速度。2.避免不必要的表扫描，表扫描是CPU的第一杀手。3.避免排序操作，排序是CPU的第二杀手。4.减少死锁发生的概率。索引缺点1.增加了insert/update/delete等操作的负担。2.索引需要占用额外的磁盘空间。3.增加了运维成本，如RUNSTATS,REORG,LOAD等操作都需要维护索引。因此，索引并不是越多越好，对于DBA来说，需要找出长期不需要的索引并将其删除，这也是一项比较重要的工作。怎样找出无效的索引以下方法可供选择：1.通过db2pd -d sample tcbstats -index。有一个字段是scans，找到一段时间内scans为0的值，表示这个索引没有被用到，即可删除。2.DB2 9.7提供了一个新的监控表MON_GET_INDEX用来识别没有用到的索引。？3.DB2 9.7还提供了一个方法用来查看索引最后使用的时间。9.7在syscat.tables,syscat.indexes和syscat.packages视图中增加了一个字段lastused，用来表示此对象最后一次被访问的时间。01/01/0001表示此对象从来没有被访问过，因此可用其作为过滤条件：db2 select indname,lastused from syscat.indexes where lastused=01/01/0001排序在DB2数据库性能监控中，经常会遇到CPU资源使用过高问题，造成此类问题的原因很多，但最主要的原因有两个：第一，过多的I/O读取；第二，过多的排序（Sort）。这两个因素有时也成为CPU的两大杀手。所谓过多的逻辑I/O读取，通常指发生在缓冲池中的表扫描。排序是指某些数据按照某个（或某些）字段从大到小或从小到大排列的过程。如果排序字段上没有索引，或者DB2认为索引的开销比表扫描更大时，DB2就会对数据进行排序。除了ORDER BY之外，以下操作也可能引起排序：1.对于包含DISTINCT、GROUP BY、HAVING、INTERSECT、EXCEPT 、UNION等操作的SQL语句，如果没有索引满足所取的顺序要求，或者优化器认为排序的代价低于索引扫描，就需要进行排序。2.对于包含Max/Min/Sum/Cube/Rollup/Rank等聚集函数，DB2会把语句重写成一个使用排序的嵌套子查询。3.对于查询计划中的Dynamic Bitmap Index ANDing (IXAND)、Hash Join(HSJOIN)等操作的生成的Hash表会放在SORTHEAP中。通常情况下，大量排序会对性能造成极大影响。比如，排序会导致很高的CPU使用时间；增加SQL的执行时间；增加锁超时和死锁发生的几率；排序会严重的消耗有限的内存空间；排序溢出会临时表空间的频繁I/O等。排序的原理正常情况下，DB2排序发生在内存中，这块内存叫做排序堆，即SORTHEAP。当需要排序的数据超出SORTHEAP大小限制时，就会发生排序溢出。溢出的数据就会写到临时表中，从而产生更多的I/O,因此对性能会有较大影响。DB2的内存集包括实例内存集、数据库共享内存集、应用程序内存集和代理私有内存集等。内存池是从内存集中分配的。根据排序内存池的分配来源，分为私有排序和共享排序。私有排序是从代理私有内存集中分配的，而共享排序从数据库共享内存集中分配。DB2选择私有排序还是共享排序，是由3个排序参数决定的。在不同配置组合下,DB2对排序内存的分配使用方式也大不相同，不同版本的DB2对排序内存的使用也存在较大差异。1.SORTHEAP：数据库配置参数，指定为每个排序分配的最大内存大小，实际使用的大小有优化器来决定的。如果表的统计信息不准确，会导致优化器对要使用的排序内存的大小估算不准，有可能分配比实际需要要少的内存，导致不必要的排序溢出。这就提醒我们经常使用runstats更新统计信息。2.SHEAPTHRES_SHR：数据库配置参数，该参数指定了数据库共享内存集中共享排序内存池的大小，它限制了该数据库上的所有应用能达到的共享排序内存上限。在DB2 8版本中，这个值是硬限制，当达到此限制后请求排序的应用会收到SQL0955(reason code2)错误。从DB2 9.1起，这个参数改为软限制，超过此值的共享排序请求可以从数据共享内存集的溢出区（Database overflow Buffer）获得。3.SHEAPTHRES:实例配置参数，指定为本实例中所有私有排序分配的内存上限的软限制。当私有排序分配的内存达到了此限制，新请求的私有排序的内存大小分配将会小于sortheap配置的大小。简单的说，每个排序是从SORTHEAP中分配的。如果使用私有排序，那么允许分配的排序内存大小不能超过SHEAPTHRES实例参数；如果使用共享排序，允许分配的排序大小不能超过SHEAPTHRES_SHR的参数值。从DB2 9.1开始，如果将SHEAPTHRES实例参数设置为0，DB2将使用共享排序，即排序内存从共享排序内存池中分配，最大限制受SHEAPTHRES_SHR控制。排序的监控db2 get snapshot for database on dbname|more关键字：Total sorts:表示发生总排序次数。Total sort time(ms):表示发生总排序时间Sort overflows:表示发生排序溢出的次数Active sorts:表示监控时正在进行的排序次数几个关键指标：Sort overflows/Total sorts * 100%表示排序溢出百分比，通常情况下，该值应该小于3。否则，表示溢比例太高，需要优化Total sort time/Total sorts 每次排序花费的时间（ms）,对于交易系统来说，最好小于50msTotal sort time(ms)/(Commit statements attempted+Rollback statements attempted)表示每个事务花费在排序上的时间。一个事务响应时间包含很多方面，比如读/写时间，锁时间、排序时间、CPU时间等。除了数据库快照、应用程序快照、动态sql快照也包含一些排序信息。排序的优化影响排序的因素主要包括排序的行数，排序列的宽度和ORDER BY的列数等，排序的行数乘以排序列的宽度决定了一次排序占用的空间。因此，应该尽量减少排序的行数（很多情况下，排序列无法更改）。常用排序优化方法1.参数调优从DB2 9.1开始，SHEAPTHRES_SHR实例参数的默认值为0，表示排序内存从数据库共享内存区分配，排序总量由SHEAPTHRES数据库参数控制。SORTHEAP的默认大小为256页，即1MB。假定要排序的数据每行是1KB大小，那么每个SORTHEAP最多允许排序1M/1K=1024行，超出1024行的数据，排序将会溢出。db2 get db cfg for sample|grep -i sortSHEAPTHRES_SHR（4KB） = 5000SORTHEAP = 256对于数据仓库系统来说，一般行记录很长，排序的行数也很多，可以适当增大SORTHEAP大小。SHEAPTHRES_SHR该值的大小有两个指标来决定，SORTHEAP和同时排序的个数。但是同时间排序的个数很难估计，一般用并发数来估计。并发数：db2 get snapshot for database on dbnameappls.executing in db manager currently = 10考虑到单个应用可能需要多个排序，可设置：SHEAPTHRES_SHR = SORTHEAP * 应用并发数 *2 在DB2 9.1及以上版本，DB2提供了自动调优（STMM）,好处是DB2根据负载和资源情况，决定一些内存的分配和回收，比如缓冲池、排序堆、所列表和Package cache大小，对于稳定的系统，可考虑启用STMM,启用方法：db2 update db cfg for dbname using SORTHEAP automaticdb2 update db cfg for dbname using SHEAPTHRES automatic2.逻辑和物理设计优化调参只是尽量减少排序溢出的几率，并不能减少排序的次数。几乎99%的排序概率是SQL语句引起的，在SQL语句无法更改的情况下，作为DBA，能够做的就是在物理/逻辑设计上做优化。通过动态SQL快照和应用快照监控，找到大量排序的SQL语句后，可以通过一些物理设计来优化SQL，如索引、物化视图（MQT）等。当然，一些影响优化器的运维工作也必不可少，如runstats、reorg、rebind等操作。索引是减少排序的利器，当SQL语句中出现以下操作时，可以考虑在相应的字段上创建索引：1.ORDER BY/GROUP BY操作SELECT A,B,C FROM TAB1 ORADER BY A,BSELECT A,B,C FROM TAB1 WHERE A=100 ORDER BY BSELECT A,B,COUNT(*),SUM(*) FROM TAB1 GROUP BY A,B可考虑在TAB1(A,B)上建索引2.DISTINCT操作SELECT DISTINCT A FROM TAB1可考虑在TAB1(A)上建索引HASH JOIN操作需要在SORTHEAP中建立哈希表，对于发生大量HASH JOIN的表，可考虑建立索引。CREATE INDEX IDX_1 ON TAB1(A) ALLOW REVERSE SCAN (索引值逆向扫描)3.调优SQL语句如果通过前面两部仍然不能解决排序问题，那就需要对SQL进行逻辑调整或修改比如：1）能否在SQL语句中省略ORDER BY , DISTINCT等操作，如果无法省略，能否尽量减少排序的的行数或列数，比如增加过滤条件等。2）如果UNION ALL能满足需求，就避免用UNION，因为前者不需要排序。3）写优化的SQL语句，比如不要在排序字段上使用函数（因为函数无法走索引）排序问题的诊断分析1.搭建实验环境以下实验在DB2 9.5 for Linux下运行。首先创建一个SORTDB数据库，然后创建一个EMPLOYEE员工表，并插入100万行数据，其中DEPT_ID字段是随机产生的1000个部门编号，所有员工数据均匀分布在1000个部门里，每个部门大概包含100万/1000=1000个员工。脚本create.ddl:create db sortdb-更改日志参数，否则会在插入数据时出现log fullupdate db cfg for sortdb using logfilsiz 2000update db cfg for sortdb using logprimary 20update db cfg for sortdb using logsecond 30-需要断掉连接才会生效force applications allconnect to sortdbcreate Bufferpool bp4k size 10000-创建automatic storaged tablespacecreate tablespace emp_dms Bufferpool bp4k-创建tablecreate table db2inst1.employee(emp_id int not null primary key,name char(20)dept_id int,salary decimal,address char(30),remark char(40) in emp_dms-向表里插入100万条数据，其中dept_id的范围为0-1000，其余几个char字段值都是根据count值产生begin atomicdeclare count int default 1;while (count 1000000) doinsert into db2inst1.employee values(count,-emp concat char(count),ceiling(rand()*1000),20000.50,-address concat char(count) concat -remark concat char(count) concat -);set count=count+1;end while;end-对表做runstatsrunstats on table db2inst1.employee 执行 db2 -td -f create.ddl然后设置排序参数，并打开监控开关db2 update db cfg for sortdb using sheapthres_shr 10000 sortheap 250db2 update dbm cfg using sheapthres 0db2 update dbm cfg using DFT_MON_SORT ONdb2stop force db2start然后查询dept_id100的记录，并按dept_id 排序，大概会有9万9千行记录返回db2 select dept_id , name from db2inst1.employee where dept_id100 order by dept_id|grep selected2.对排序问题的诊断分析1）数据库监控分析db2 get snapshot for db on sortdb|more 通过监控结果可知，在共享内存区发生了一次排序，并且发生了排序溢出，排序时间是206ms，因为监控是SQL语句执行完后执行的，所以total shared sort heap allocated的结果是0，否则会显示当前分配的排序堆页数。因为是共享排序，所有与私有排序相关的参数都是0。然后监控缓冲池临时数据和临时索引的逻辑读/写页数，当排序溢出时，会溢出到临时表空间中。如果发现临时表空间数据读写值较高，那么很可能是SORT引起的。db2 get snapshot for database on sortdb|grep -i temporary data2)监控sql语句根据动态SQL语句快照，找到排序多、溢出多的sql语句。我们会发现，该语句执行了一次，执行时间花费了7.6秒，Rows Read =1099018 , Rows Written =9901。排序发生了一次，溢出一次。为什么select语句会产生rows written呢？这就是因为排序溢出写到临时表空间，产生了写I/O，溢出的行数为99011，正对应前面的查询结果。当然，也可以使用SYSIBMADM.SNAPDYN_SQL管理视图找到排序最多的动态SQL语句。3）SQL语句分析通过explain工具生成sql语句的执行计划，并通过db2exfmt进行格式化。db2 -tvf EXPLAIN.DDLdb2 set current explain mode explainmore query.sqlselect dept_id , name from db2inst1.employee where dept_id95% 良好：80%读行v.s.选择行 数据库快照 Rows Read/Rows Select OLTP系统：=5 SAP系统：SHEAPTHRES物理磁盘数量 操作系统信息 每个CPU内核对应620个物理磁盘数量以下引用网友文章/club/thread-23175-1-1.html性能优化的几个关键指标（KPI）在性能调优时，经常有无从下手的困惑，尤其是当发现数据库变慢时，不知道如何进行量化分析。我们将从经验的角度给出一些关键参数的阀值，这样在进行性能分析时，就可以从这些关键参数入手了。下面的关键性能指标，我们又称之为KPI（Key Performance Indicator），供大家参考。 数据缓冲区命中率（Data Bufferpool Hit Ratio）： 95% 索引缓冲区命中率（Index Bufferpool Hit Ratio）： 98% 平均读写时间（Read / Write Avarage Times）： 98% 编目缓冲区命中率（Catalog Cache Hit Ratio）： 98% 锁升级及死锁（Lock Escalations and Deadlocks）：仅有少量的锁升级或死锁 日志缓冲区（Log Buffer Hit Ratio）： 98% 排序溢出次数 / 排序次数 （Sort Overflow / Total Sort）： 1%注意：我们给出的KPI阀值并不是一个严格的限制，比如某些参数略低于KPI阀值也是允许的。另外，也需要考虑将这些值与性能问题出现之前的值进行比较，如果相差不大，则需要从其他角度考虑，例如数据库布局、磁盘或者网络是否有瓶颈等 1.数据池命中率命中率是判定物理I/O频繁程度的一个最重要的指标之一，很多优化不足的系统中是一个最容易出现的问题。缓冲池命中 hit未命中 hit miss对于OLTP一般要求数据Bufferpool达到90%的命中率。对于OLAP，由于经常需要进行表扫描，所以不必追求很高的命中率，但临时数据和索引的命中率需要关注，因为仓库系统中一些复杂的SQL语句需要进行大量的排序或哈希关联操作，而排序和哈希关联可能需要在临时表空间完成。数据库整体缓冲池命中率：(1 - (Buffer pool data physical reads + Buffer pool temporary data physical reads + Buffer pool index physical reads + Buffer pool temporary index physical reads) / (Buffer pool data logical reads + Buf-fer pool temporary data logical reads + Buffer pool index logical reads + Buffer pool temporary index logical reads)* 100%请问：Buffer pool index physical reads和index logical reads 的数据从何而来？打开DBM 配置参数 DFT_MON_BUFPOOL使用：db2 get snapshot for Bufferpools on db_name数据缓冲池命中率：（1-（Buffer pool data physical reads）/(Buffer pool data logical reads)）*100%索引缓冲池命中率：（1-（Buffer pool index physical reads）/(Buffer pool data index reads)*100%临时空间缓冲池命中率：（1-（Buffer pool temporary data physical reads + Buffer pool temporary index + Buffer pool temporary index physical reads）/(Buf-fer pool temporary data logical reads