DB2性能监控和调优(Bufferpool篇)
DB2 性能调优入门(1-Tools)
DB2 snapshot switches on
当前挂起的锁定 =0 锁定等待 =0 数据库等待锁定时间（毫秒） = 0 在使用的锁定列表内存（以字节计）= 3360 检测到死锁 =0 锁定升级 =0 互斥锁定升级 =0 当前正等待锁定的代理程序数 = 0 锁定超时 =0 不确定事务数 =0
已分配的专用排序堆总数 =0 已分配的共享排序堆总数 =4 共享排序堆高水位标记 =4 后阈值排序（共享内存） =0 总计排序 =0 总计排序时间（毫秒） =0 排序溢出 =0 活动排序数 =0
RESET MONITOR {ALL [DCS] | FOR [DCS] DATABASE databasealias} [AT DBPARTITIONNUM db-partition-number | GLOBAL]
© 2007 IBM Corporation
DB2 9.5 Administration for the Oracle DBA – Proof of Technology – Part 1
© 2007 IBM Corporation
DB2 9.5 Administration for the Oracle DBA – Proof of Technology – Part 1
DB2 Information Management
学习目标 了解DB2日常监控的过程 熟悉DB2常用的监控工具 能够熟练使用snapshot工具 能够熟练使用event monitor工具 能够熟练使用db2pd工具 能够使用SQL访问监控结果 能够熟练使用recovery expert工具
UPDATE MONITOR SWITCHES USING {switch-name {ON | OFF} ...} [AT DBPARTITIONNUM db-partition-number | GLOBAL]
DB2数据库-性能测试监控
Index_hit_rate
数据库索引命中率
Total_Locks
数据库当前锁总数
Memory_Current_size
数据库当前内存使用大小
Memory_percent_total
数据库内存使用比例
Memory_hight_watermark
数据库内存高水位
Sort_Overflows
建议：根据业务需求，修改锁超时时间。
修改锁超时时间
Update db cfgLOCKTIMEOUTusing 1 ---表示锁等待超时时间为1秒
数据库最大应用数
Db2 get db cfg |grep–iapplications返回MAXAPPLS
建议：将此指标值设置为自动增长
最大应用数修改方法
Db2update db cfgMAXAPPLSusingAUTOMATIC
执行catalog database xir_trd at node node1为监控数据库分配节点，其中xir_trd为需要监控的数据库、node1为上一步创建的节点名
Spotlight客户端配置
完成DB2客户端的安装及配置
点击file选择connect ---spotlight on db2 LUN----new connection
DB2
一．
1.
概要介绍
DB2是IBM公司研发的关系数据库产品，目前广泛应用于金融、通信、交通等行业，在IBM随需应变的战略体系中扮演着重要角色。因为川农信属于金融行业，因此也在使用DB2，其版本为v9.7，所以在这里介绍一些9.7版本的新特性。
支持索引压缩、临时表数据压缩和xml压缩，更加降低了存储空间成本。
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通用数据库
表 2. 监视器开关在数据库管理器级别，监视器开关设置在dft_monswitches数据库管理器配置参数中。
要查看所有的监视器开关设置的设置选项，请使用 GET DATABASE MANAGER MONITOR SWITCHES 命令。
要启用或禁用数据库管理器级别的监视器开关设置，请使用 UPDATE DBM CFG 命令，并指定要更改的个别监视器开关。
例如，以下命令关闭 DFT_MON_TIMESTAMP 监视器开关，来终止时间戳记监视器数据的收集：db2 update dbm cfg using DFT_MON_TIMESTAMP off每个连接至数据库的应用程序都有其自己的监视器开关集，这些监视器开关与数据库管理器和其它应用程序无关。
应用程序在连接至数据库时，从数据库管理器上继承它们的监视器开关设置。
要查看应用程序的所有监视器开关设置的设置选项，请使用 GET MONITOR SWITCHES 命令。
您可以使用 UPDATE MONITOR SWITCHES 命令来更改应用程序的监视器开关设置。
例如，下面的命令打开 LOCK 监视器开关，从而启用 SNAPSHOT_LOCK 快照表函数所使用的监视器元素的收集：对快照数据进行直接访问时，已授权用户用快照表函数发出查询，并接收包含监视器数据的结果集。
已授权用户（要执行快照监控任务）意味着必须拥有 SYSADM、SYSCTRL 或 SYSMAINT 权限。
通过文件访问，已授权用户可以使所有用户都可以使用特定的快照数据集合。
要这样做，已授权用户调用 SNAPSHOT_FILEW 存储过程，来确定快照请求类型和受影响的分区和数据库。
SNAPSHOT_FILEW 存储过程将监视器数据保存到数据库服务器上的文件中。
随后任何数据库用户都可以使用对应的快照表函数（使用指出文件访问的参数）来发出查询。
从 SNAPSHOT_FILEW 存储过程生成的文件中抽取出他们接收的监视器数据。
DB2及表空间和缓冲池
DB2及表空间和缓冲池DB2的表空间和缓冲池对于刚涉足DB2 领域的DBA 或未来的DBA 而言，新数据库的设计和性能选择可能会很令人困惑。
在本文中，我们将讨论DBA 要做出重要选择的两个方面：表空间和缓冲池。
表空间和缓冲池的设计和调优会对DB2 服务器的性能产生深远的影响，因此我们将着重讨论这些活动。
表空间数据库中的所有数据都存储在许多表空间中。
可以认为表空间是孩子而数据库是其父母，其中表空间（孩子）不能有多个数据库（父母）。
由于表空间有不同用途，因此根据它们的用途和管理方式将它们分类。
根据用途有五种不同的表空间：目录表空间每个数据库只有一个目录表空间，它是在发出CREATE DATABASE 命令时创建的。
目录表空间被DB2 命名为SYSCATSPACE，它保存了系统目录表。
总是在创建数据库时创建该表空间。
常规表空间常规表空间保存表数据和索引。
它还可以保存诸如大对象（Large Object，LOB）之类的长数据，除非这些数据显式地存储在长表空间中。
如果某些表空间是数据库管理的空间（Database Managed Space，DMS），则可以将表及其索引分别放到单独的常规表空间中。
我们将在本文后面定义DMS 和系统管理的空间（System Managed Space，SMS）之间的区别。
每个数据库中必须至少有一个常规表空间。
创建数据库时指定该表空间的缺省名为USERSPACE1。
长表空间长表空间用于存储长型或LOB 表列，它们必须驻留在DMS 表空间中。
它们还可以存储结构化类型的列或索引数据。
如果没有定义长表空间，那么将把LOB 存储在常规表空间中。
长表空间是可选的，缺省情况下一个都不创建。
系统临时表空间系统临时表空间用于存储SQL 操作（比如排序、重组表、创建索引和连接表）期间所需的内部临时数据。
每个数据库必须至少有一个系统临时表空间。
随数据库创建的系统临时表空间的缺省名为TEMPSPACE1。
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數據庫性能調整的十個實用技巧，詳細內容請讀者參考下文。
（本文主要針對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数据库性能参数优化笔记整理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性能调优
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 参数。