最简单有效——Bufferpool缓冲池是内存中的一块存储区域，用于临时读取和更改数据库页面（包括表行或索引条目）。缓冲池的目的是提高数据库系统的性能。从内存访问数据比从磁盘访问数据快得多。因此，数据库管理器需要从磁盘读取或写入磁盘的次数越少，性能就越好。配置一个或多个缓冲池是调优最重要的方面，因为连接到数据库的应用程序的大多数数据（不包括大对象和长字段数据）操作都发生在缓冲池中。默认情况下，应用程序使用缓冲池IBMDEFAULTBP，它是在创建数据库时创建的。当SYSCAT.BUFFERPOOLS目录表中缓冲池的NPAGES值为-1时，DB2数据库配置参数BUFFPAGE控制缓冲池的大小。否则将忽略BUFFPAGE参数，并使用NPAGES参数指定的页数创建缓冲池。建议对于仅使用一个缓冲池的应用程序，将NPAGES更改为-1，以便BUFFPAGE可以控制缓冲池的大小。这使得更新和报告缓冲池大小和其他DB2数据库配置参数变得更加容易。在确保可以使用数据库配置中的BUFFPAGE参数控制缓冲池大小后，将此参数设置为适当的值。根据数据库的大小和应用程序的性质，将此参数设置为一个相当大的值是安全的。通常这个参数的默认值很小，可能达不到要求。db2"getsnapshotforallbufferpools"在数据库快照或缓冲池快照的快照输出中，寻找下面的“逻辑读”和“物理读”，这样就可以计算出缓冲池的命中率，可以帮助调整缓冲池：缓冲池命中率表示数据库管理器可以在不从磁盘加载页面（即页面已经在缓冲池中）的情况下处理页面请求的时间百分比。缓冲池命中率越高，使用磁盘I/O的频率就越低。缓冲池命中率计算如下：(1-(((缓冲池数据物理读+缓冲池索引物理读)/ (缓冲池数据逻辑读+池索引逻辑读)) )*100%this计算考虑了缓冲池缓存中的所有页面（索引和数据）。理想情况下，该比率应超过95%，并尽可能接近100%。要提高缓冲池命中率，请尝试以下方法：1.增加缓冲池大小。2.考虑分配多个bufferpool，如果可能，为访问频繁的大表的每个tablespace分配一个bufferpool，为一组小表分配一个bufferpool，然后尝试使用不同大小的bufferpool查看哪种组合将提供最佳性能。3.如果分配的内存对性能没有帮助，请避免为缓冲池分配过多的内存。缓冲池的大小应根据从测试环境中获取的快照信息来确定。4.太小的缓冲池会产生过多的、不必要的物理I/O。太大的缓冲池会使系统面临操作系统分页的风险，并消耗不必要的CPU周期来管理过度分配的内存。正确的缓冲池大小介于“太小”和“太大”之间。合适的规模存在于回报将开始减少的地方。获得最佳性能——SQL一条糟糕的SQL语句可以彻底摧毁一切。一个相对简单的SQL语句可能会搞砸一个调整良好的数据库和机器。对于其中的许多语句，sun下（或文档中）没有任何DB2UDB配置参数可以纠正由错误的SQL语句导致的代价高昂的情况。更糟糕的是，DBA经常受到限制：不能更改SQL（可能是因为它是由应用程序供应商提供的）。这让DBA只有三个路径：1.更改或添加索引2.更改集群3.更改目录统计信息一个健壮的应用程序由数千条不同的SQL语句组成。这些语句的执行频率因应用程序的功能和日常业务需求而异。SQL语句的实际成本是执行一次的成本乘以执行的次数。每个DBA面临的一项主要任务是识别具有最高“实际成本”的语句并降低这些语句的成本。执行SQL语句的资源成本可以根据本机DB2Explain实用程序、来自某些第三方供应商的工具或DB2UDBSQL事件监视器数据来计算。但是语句执行频率只能通过对DB2UDBSQLEventMonitor数据进行仔细且耗时的分析才能了解。***性能要求不仅要排除代价高昂的SQL语句，还要保证相应的物理基础设施是合适的。当所有的调整旋钮都设置得恰到好处，内存被有效地分配给池和堆，I/O被均匀地分布在磁盘上时，就可以实现最佳性能。不容错过——Lock这些与锁相关的控制是数据库配置参数：LOCKLIST指示分配给锁列表的存储容量。每个数据库都有一个锁列表，其中包含并发连接到数据库的所有应用程序持有的锁。锁定是数据库管理器用来控制多个应用程序对数据库中数据的并发访问的机制。行和表都可以被锁定。根据对象是否持有其他锁，每个锁需要32或64字节的锁列表：1.需要64字节来持有未持有其他锁的对象的锁。锁。2.记录一个已经持有锁的对象的锁需要32个字节。MAXLOCKS定义在数据库管理器可以执行锁升级之前必须填充的应用程序持有的锁列表的百分比。当应用程序使用的锁列表的百分比达到MAXLOCKS时，数据库管理器会升级这些锁，这意味着用表锁替换行锁，从而减少列表中的锁数量。当任何一个应用程序持有的锁数量达到整个锁列表大小的这个百分比时，该应用程序持有的锁就会升级。如果锁定列表空间不足，也会发生锁定升级。数据库管理器通过查看应用程序的锁列表并查找具有最多行锁的表来决定升级哪些锁。如果将这些行锁替换为表锁，将不再超过MAXLOCKS值，并且锁升级停止。否则，锁升级将继续，直到持有的锁列表的百分比低于MAXLOCKS。MAXLOCKS参数乘以MAXAPPLS参数不能小于100。虽然升级过程本身不会花费太多时间，但锁定整个表（与锁定单个行相反）会降低并发性，并且整体数据库性能可能会因后续访问而降低受锁升级影响的表。LOCKTIMEOUT的默认值是-1，这意味着不会有锁超时（对于OLTP应用来说，这种情况可能是灾难性的）。许多DB2用户使用LOCKTIMEOUT=-1。将LOCKTIMEOUT设置为一个较短的时间值，例如10或15秒。在锁上等待太久会对锁产生雪崩效应。首先，使用以下命令检查LOCKTIMEOUT的值：db2"getdbcfgforDBNAME"并查找包含以下文本的行：Locktimeout(sec)(LOCKTIMEOUT)=-1如果值为-1，请考虑更改它用命令15秒（一定要先询问应用程序开发人员或供应商以确保应用程序可以处理锁定超时）：db2“使用LOCKTIMEOUT15为DBNAME更新dbcfg”还应该监视锁定等待的数量，锁定等待time,andthenumberoflocksbeingused锁列表内存量。发出以下命令：db2“getsnapshotfordatabaseonDBNAME”如果正在使用的锁列表内存（字节）超过定义的LOCKLIST大小的50%，则增加LOCKLIST数据库配置中4k页的数量。#p#掩盖问题——SORTHEAPSORTHEAP是一个数据库配置参数，它定义私有排序使用的私有内存页的最大数量，或者共享排序使用的共享内存页的最大数量。如果排序是私有排序，则此参数会影响代理程序私有内存。如果排序是共享排序，则此参数会影响数据库的共享内存。每个排序都有一个单独的排序堆，由数据库管理器按需分配。对排序堆中的数据进行排序。如果排序堆大小的分配是由优化器指导的，那么根据优化器提供的信息分配的排序堆大小小于该参数指定的排序堆大小。SHEAPTHRES是数据库管理器配置参数。私有排序和共享排序使用的内存来自不同的来源。共享排序内存区域的大小是在第一次连接到数据库时根据SHEAPTHRES值静态预先确定的。私有排序内存区域的大小是无限的。SHEAPTHRES参数对私有排序和共享排序的应用不同：对于私有排序，SHEAPTHRES是对私有排序在任何给定时间可以消耗的总内存的实例级“软”限制。当一个实例的私有排序总内存消耗达到这个限制时，为其他传入的私有排序请求分配的内存将大大减少。对于共享排序，SHEAPTHRES是对共享排序在任何给定时间可以消耗的总内存的数据库级“硬”限制。当达到此限制时，将不允许其他共享排序内存请求，直到总共享内存消耗量回落到SHEAPTHRES指定的限制以下。使用排序堆的操作示例包括散列连接和对内存表的操作。阈值的显式定义可防止数据库管理器为大型排序使用过多的内存。建议◆使用数据库系统监视器来跟踪排序活动。◆使用适当的索引以尽量减少排序堆的使用。◆当频繁需要大排序时增加SORTHEAP的值。◆如果增加SORTHEAP，确定是否还需要调整数据库管理器配置文件中的SHEAPTHRES参数。◆优化器使用排序堆大小来确定访问路径。考虑在更改此参数后重新绑定应用程序（使用REBINDPACKAGE命令）。◆理想情况下，排序堆阈值(SHEAPTHRES)参数应设置为数据库管理器实例中设置的SORTHEAP参数***值的合理倍数。此参数应至少是实例中任何数据库定义的***SORTHEAP值的两倍。如何更改这些参数要更改SORTHEAP和SHEAPTHRES的值，请运行以下命令：--SORTHEAP应该针对单个数据库进行更改-- db2"updatedbcfgforDB_NAMEusingSORTHEAPa_value" --SHEAPTHRES是一个数据库管理器参数-- db2"updatedbmcfgusingSHEAPTHRESb_value"研究步骤OLTP应用程序不应执行大排序。就CPU和I/O资源而言，大型排序非常昂贵。通常，SORTHEAP大小的默认值（256个4KB页）就足够了。事实上，对于高度并发的OLTP，可能需要降低此默认值。当需要进一步研究时，发出以下命令：db2"updatemonitorswitchesusingsorton"然后，让应用程序运行一段时间，然后输入：db2"getsnapshotfordatabaseonDBNAME"从这个输出中，可以计算事务，并可以计算溢出可用于排序的内存的排序百分比。SortsPerTransaction =(TotalSorts)/(Commitstatementsattempted+Rollbackstatementsattempted) PercentSortOverflow =(Sortoverflows*100)/(Totalsorts)经验：如果SortsPerTransaction大于5，可能表明那每个交易的种类太多了。如果PercentSortOverflow大于3%，则可能发生严重的、意外的大排序。发生这种情况时，增加SORTHEAP只会隐藏性能问题——它不会修复它。此问题的正确解决方案是通过添加正确的索引来改进有问题的SQL语句的访问计划。【编者推荐】DB2数据库移植常见问题全面分析DB2事务日志使用细节如何创建DB2服务器报表并在前端Access上展示
