DB2性能优化
让DB2跑得更快——DB2内部解析与性能优化
精彩节摘
9.3如何定位及修复内存泄漏
在怀疑遇到内存泄漏的问题之前，必须谨慎地判断当前数据库中是否真实存在内存泄漏。判断数据库中存在 内存泄漏时需要注意以下几点：
系统中的内存在逐渐减少，甚至导致换页（paging）；
SQL语句越来越慢（经常是换页导致）；
随着时间增长，由DB2分配的内存在不断增加。
第3篇性能分析及内部原理剖析
第4章对优化器的原理进行了探讨，阐述了优化器的重写机制、优化原理及编译原理，并介绍了如何检查优化 器的估算结果的两种方法。
谢谢观看
并在DB2China数据库论坛担任热点讨论版块版主，主持多次热点讨论以及专家现场诊断，擅长DB2数据库及 相关产品的性能调优及故障分析，对DB2技能及实践经验有多年积累。
近年来多位业界专家一直在积极推动DB2领域的技术交流，真正理解DB2技术人员真正的需求与痛楚，是DB2 系统知识及技巧精髓的热心分享者及贡献者。
而我本人正是一名数据的信徒，多年来在著书、培训、咨询和管理等多项工作中，始终在数据的海洋中忘我 与痴迷。在受邀为本书作序之时，我回想起五年前正埋头于写作的我。那时，每日工作繁忙，仍笔耕不辍，把之 前在数据库领域的各项工作中所获得的技术积累、经验总结都尽可能地通过文字展现给读者。自认为写数据库的 书很苦，写DB2的书更苦，在出版多部著作之后，我对优秀数据库著作的评判标准，可以套用新闻界的行话： “如果事件报道得不够好，那是因为离得不够近”。
在常见的数据库问题中，性能问题不仅出现的频率较高并且很多生产系统中并不存在一个对性能问题进行隔 离的高可用机制，正因为如此，在很多关键行业的系统中，性能问题往往成为影响生产系统正常运行的最大因素。 而性能问题的影响时间有时长达数小时，这样不仅给生产系统带来了极大的负面影响，也使业务很难正常进行。
db2数据库优化方案
db2数据库优化方案随着企业数据量的不断增加，数据库的性能优化变得越来越重要。
在众多数据库中，DB2是一款功能强大的关系型数据库管理系统。
本文将为您介绍一些针对DB2数据库的优化方案，以提高数据库的性能和效率。
一、合理设计数据库结构良好的数据库设计是优化数据库性能的基础。
以下是一些设计数据库结构的准则：1. 使用适当的数据类型：根据数据的特性选择适当的数据类型，减小存储空间的占用，提高查询和更新速度。
2. 设计有效的主键和外键：将主键和外键应用到表的关键字段上，以确保数据的完整性和一致性，并加速查询操作。
二、合理设置数据库参数通过调整数据库参数，可以改善DB2的性能表现。
以下是一些常用的数据库参数设置建议：1. 缓冲池设置：调整缓冲池的大小，使得主要用于查询的表和索引可以被缓存，减少磁盘I/O操作。
2. 日志设置：根据业务需求设置日志的大小和数量，以平衡事务处理的性能和数据恢复的能力。
3. 并发设置：根据并发操作的需求和服务器硬件性能合理设置并发连接数和锁定策略，以提高系统的并发处理能力。
三、优化查询语句优化查询语句可以提高DB2数据库的性能和响应时间。
以下是一些优化查询语句的建议：1. 使用索引：根据查询的字段和条件创建适当的索引，加快查询速度。
2. 正确使用JOIN操作：避免使用不必要的JOIN操作，优化表之间的关联关系，减少查询的复杂性。
3. 避免全表扫描：尽量避免使用SELECT *的方式查询数据，只选择需要的字段，减少数据库的负载。
四、定期维护数据库定期维护数据库可以确保数据库的正常运行和优化性能。
以下是一些数据库维护的建议：1. 优化表和索引：根据数据库的使用情况定期重新组织表和索引，保持数据的连续性和最佳性能。
2. 清理无用数据：定期删除或归档不再使用的数据，减少数据库的存储空间占用。
3. 备份和恢复策略：制定完备的数据库备份和恢复策略，以防止数据丢失和灾难恢复。
五、硬件优化优化数据库的硬件环境可以提高系统的性能和可靠性。
DB2数据库优化策略
DB2数据库优化策略当涉及到DB2数据库优化时，具体的案例取决于数据库的具体情况和性能问题。
请注意，这些只是一些常见的DB2优化案例和步骤。
具体的优化策略取决于您的特定情况和需求。
在进行任何优化之前，建议先进行充分的需求分析和性能测试，以确保所选的优化策略能够真正解决您的问题并带来显著的性能提升。
一．索引优化：识别慢查询：首先，通过慢查询日志或性能监控工具识别慢查询。
分析查询：查看查询的执行计划，确定是否可以利用索引加速查询。
创建或优化索引：如果发现缺少必要的索引，创建索引；如果存在冗余或低效的索引，则进行优化或删除。
二．查询优化：重写复杂查询：将复杂的联接和子查询重写为更高效的查询方式，例如使用JOIN替代子查询。
使用合适的函数：避免在查询中使用复杂的函数，这可能会影响索引的使用和查询性能。
三．数据库设计优化：规范化：确保数据库表结构经过规范化，以减少数据冗余和潜在的更新、插入和删除异常。
反规范化：在适当的情况下，通过反规范化来提高查询性能，减少数据检索的复杂性。
四．硬件和配置优化：增加内存：提高数据库缓冲池的大小，以便数据库可以缓存更多的数据和索引。
使用更快的存储：选择高性能的硬盘或使用SSD来提高I/O性能。
调整数据库配置参数：根据数据库的工作负载和硬件资源，调整数据库的配置参数，如缓冲池大小、线程数等。
五．监控和调优：定期监控数据库性能：使用性能监控工具定期检查数据库的性能指标，如CPU利用率、磁盘I/O、查询响应时间等。
调整优化策略：根据监控结果，定期评估和调整优化策略，以保持数据库的最佳性能。
六．并发和负载管理：资源争用管理：分析并解决多个用户或应用程序之间的资源争用问题，确保数据库资源得到合理分配。
分区：使用分区技术将大型表和索引分成较小的、更易于管理的片段，以提高管理和查询性能。
七．定期维护：数据库维护：定期进行数据库维护，如重建索引、清理旧数据、更新统计信息等，以保持数据库性能和效率。
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性能优化入门
DML性能问题：查询优化
n DML(Data Manipulation Language) 包括了查询，增加，删除和更新 纪录等操作。首先看一下查询的性能问题，在查询一张表或多张表的 联合查询时有时反应时间会比较长，这使得用户难以忍受。针对这种 问题，可以通过下述方法来分析：
n 在查询的连接或条件子句中的相关字段是否加了索引。 n 察看缓冲池的大小，缓冲池太小会造成很多数据不能读到缓冲池而直
I/O 因素
n 其次要考虑的是日志文件的大小，当数据库在写事务日志时当一个日 志文件写满后会转向另外一个日志文件，这种日志文件的切换会造成 操作系统上的开销。所以应当尽量将日志文件大小（LOGFILSIZ）设 得大一些，这样可以减少日志文件切换的次数。但是日志文件过大难 免会造成一些空间的浪费。
I/O 因素
CPU 因素
n 在考虑 CPU 因素时还要考虑 CPUSPEED 这个参数，这个参数标明了 CPU 的运行速度，它会帮助优化器评估最好的访问计划。一般来说这 个参数设为 -1，优化器将自动计算 CPU 的速度。另外运用多分区的特 性可以把一个数据库分布到多台机器上，这样可以充分利用多台机器 的 CPU 的资源对应用程序的事务进行并行处理，从而提高数据库的性 能。
发性。 n 最后要考虑的还是关于多分区的特性。在多分区数据库中，一个请求
首先传到协调分区，然后由协调分区将请求细分成多个部分发送到其 他分区，这样数据可以在各个分区进行并行读写，实现 I/O 最大化。
性能优化工具
n 在 DB2 中有很多和性能优化相关的工具和命令，下面简单地介绍几种： Ø SNAPSHOT Ø DB2PD Ø RUNSTATS Ø REORG Ø DB2DART Ø DB2SUPPORT
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参数有NEWLOGPATH状态，需要做全备份后数据库才能使用。
对于主日志数目（LOGPRIMARY）来说，其空间是预先分配的，用于记录事务的处理。
日志需要的磁盘空间一定的，不管其内容是空的还是写满的。
主日志文件最大数目是256，默认为3。
一般来说，只用主日志就可以满足日常的数据库运行所需。
如果LOGPRIMARY的值设置的过小，就可能会总遇到“log-full”的情况。
如果DB2总是分配辅助日志，就说明主日志大小不够。
对于高负载的OLTP系当分配的日志数达到规定的最大数目，还不能完成当前事务，则前事务会被撤销并返回错误信息。
辅助日志一旦分配，就会一直存在直到数据库去激活。
LOGSECOND 默认值为2，设置范围从0到254。
如果将其设置为-1，表示启用无限日志。
优化日志缓冲区参数对于日志缓冲区LOGBUF Z来说，是关系到日志读写性能的重要参数，其用来定义缓冲区的内存大小，使日志I/O更加高效。
日志缓冲已满是日志写回磁盘的关键OLTP应用调优的合适起点。
执行UPDATEUSING LOGBUFZ可以对其进行调整。
OLAP初始值需小而定。
64 GB的内LOGBUFSZ等。
当然，根据系统的工作符合而定。
不过日志越好，其可能对系统性能造成影响。
来减少日志数据。
如果预计在一个表上大批量操作，可NOT LOGGED INITIALLY。
对于临时表（包含声明的全局临时表和创建来说，一般作为中间数据的中转之用，和删除等上使用MOT使其不记录到数据时，使通过SQL引擎直接写数据页，这样就不且速度很速率高的情况，O次数高。
例如，照和应用程序快照显示提交的数目非常高等。
对应的优化措施是率，如果因为因为日志缓冲区太小导致出现日志磁盘O瓶颈，可的大小，通SNAPDB（数据库快照）LOG_BUFFER_FULL（除）进行监控来确定。
（转）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数据库优化DB2数据库是一种关系型数据库管理系统，由IBM开发和维护。
为了提高DB2数据库的性能和效率，需要进行一系列的优化操作。
下面将介绍一些常见的DB2数据库优化方法。
1.确保合适的硬件配置：DB2数据库的性能很大程度上依赖于底层硬件的性能。
因此，为了获得最佳性能，需要确保数据库运行在合适的硬件配置下。
这包括选择合适的处理器、内存和磁盘配置。
2.优化数据库设计：良好的数据库设计可以提高数据库的性能。
可以通过合理的表设计、索引设计和关联设计来减少数据的冗余和重复，从而提高查询和更新的效率。
3.数据库分区：当数据库中的数据量增加时，可以考虑对数据库进行分区，将数据划分为多个分区存储。
这样可以提高查询和更新的效率，减少锁冲突，并且可以利用多个处理器并行处理多个分区。
4.合理使用索引：索引是提高数据库查询性能的重要手段。
在创建索引时，需要根据实际情况选择合适的列和索引类型，并避免创建过多的索引，以防止影响更新操作的性能。
5.定期收集统计信息：收集数据库表的统计信息可以帮助DB2优化器生成更高效的查询计划。
可以使用DB2提供的统计信息收集工具来定期收集表的统计信息，并确保统计信息是最新的。
6.合理设置数据库参数：DB2数据库有很多参数可以进行优化配置。
这些参数包括缓冲池大小、日志文件大小和数据库连接数等。
通过合理设置这些参数，可以提高数据库的性能和响应速度。
7.优化SQL查询语句：SQL查询语句的性能直接影响数据库的性能。
可以通过使用合适的连接方式、避免使用不必要的子查询和关联查询等方式来优化查询语句。
8.避免长事务：长时间运行的事务会占用数据库资源，影响其他查询和更新操作的性能。
因此，需要尽量避免长时间运行的事务，或者使用事务分解等方式将长事务分解为多个短事务。
9.定期清理无用数据：数据库中的无用数据会占用磁盘空间，并影响查询和更新操作的性能。
因此，需要定期清理无用数据，例如删除过期的日志文件、归档数据和临时表等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
性能调优的限制
• 多少时间和金钱可以被投入? • 考虑投资回报率 • 调优可以解决的问题 • 响应时间慢的问题 • 事务吞吐低的问题 • 更好的解决方案是从架构着手 • 更快更多的存储 • 更快更多的CPU
• 更多的内存
• 更快的网络
14
© 2009 IBM Corporation
Agenda
• 教你三招 • 什么是性能问题 • 找到性能瓶颈 • 硬件规划
10 to 20 disk per core • 10 for Intel/AMD (System x) • 20 for POWER5 and POWER6 (System p)
17
© 2009 IBM Corporation
内存
• CPU和磁盘之间的缓冲 • 受共享内存的限制 • 32 bit ~4GBs (Windows /Linux) • 64 bit ~无限制 • 4-8GB RAM per core • 4GB per core for Intel/AMD (System x) • 8GB per core for POWER5 and POWER6 (System p)
18
© 2009 IBM Corporation
Agenda
• 教你三招 • 什么是性能问题 • 找到性能瓶颈 • 硬件规划
• 实战案例分享
19
© 2009 IBM Corporation
索引优化-加强治理
背景：
在客户环境中，我们通常通过在表上建各种索引来提高查询速度，但索引 过多过滥严重影响了插入和更新时的性能和存储开销，如何选择合适的列 作为索引成了用户比较头疼的问题。
11
© 2009 IBM Corporation
测试的方法：性能基准测试（Benchmarking）
• 涉及开发和运维整个数据生命周期 • 基于可控条件 • 重复运行有性能问题的应用 • 迭代之间，更换条件: • 参数配置 • SQL语句 • 索引 • 表空间配置 • 硬件配置 • 重复，直到整个应用性能满足要求 • 性能基准测试的要求： • 测试可重复 • 每次迭代启动时，系统状态相同 • 没有其他应用干扰 • 软硬件和生产环境一致
20
© 2009 IBM Corporation
大表优化-启用压缩
背景：
在生产环境中，经常面临数据快速增长的问题，为了减少存储空间，我们 通过对大表或者流水表进行压缩来减少存储空间。
案例： 某银行，有一个非常大的流水表，目前已近有2600万行记录，每天增长 100万条，数据量增长非常快，按照目前的增长速度，再过一段时间就会 把表空间占满。 解决办法： 1，方法一：使用DB2 v9.7提供的表压缩技术对其进行压缩，取得了一定 效果，但是还不够。 2，方法二：利用DB2 Galileo提供的自适应压缩（Adaptive Compression ）技术，再次对底层的数据页进行压缩，这使得在表压缩的基础上，数据 再压缩40% - 50%。
案例： 某电信公司，一个表上建立了包含3个列(A, B, C)的索引，如果(A, C)或者 (B, C)这样的组合查询条件很多情况下是无法利用(A, B, C)索引的，那么怎 么提升他们的查询速度呢？ 解决办法： 1，方法一：单独为(A, C)和(B, C)建立索引，这导致索引过多过滥。 2，方法二：利用DB2 Galileo提供的Jump Scan技术，无需建立额外索引 ，(A, C)和(B, C)这样的查询可以直接用上（A,B,C）上的索引。
DB2 性能优化
王飞鹏 wangfp@
© 2012 IBM Corporation
Agenda
• 教你三招 • 什么是性能问题 • 找到性能瓶颈 • 硬件规划
• 实战案例分享
2
© 2009 IBM Corporation
第一招：解决硬解析的利器-绑定变量
背景： 绑定变量是解决动态语句硬解析的利器，能解决OLTP系统中Package cache的过度耗用以提高性能。 用法： //激活语句集中器
db2 update db cfg using STMT_CONC LITERALS
//下面的JAVA代码使用绑定变量，避免对动态语句硬解析
PreparedStatement p = conn.prepareStatement ("SELECT name FROM emp WHERE id = ? AND dept = ?"); p.setInt(1, 314159);
制定优化目标
• 根据成本效益分析（Cost-Benefit Analysis）模型，付出的努力永远 要和获得的收益取得平衡。
•
•
优化无止境，因为没有目标就不知道何时停止研究更好的解决方案。因 为性能是有时间和金钱成本的。
当DBA考虑需要多少时间和金钱用于性能优化时，要评估一下所花费的 时间成本和金钱成本。
16
© 2009 IBM Corporation
存储
考虑因素: 1. I/O吞吐
• • I/Os per Second (IOPS) Megabytes per Second (MPS)
2. 3.
容量 单独的日志空间
经验公式:
•
•
15K RPM drive = ~150-175 IOPS @ 7-8 milliseconds response time
• 解决性能问题的通常办法（假如是新手） • 慌乱 • 买更多的硬件（CPU、内存、磁盘等） • 指责DB2…
• AIX / Windows / Linux… • IBM / HP / Sun /…
• 随机性调整，靠运气
7
© 2009 IBM Corporation
六种类型的瓶颈
系统性能问题
1. 硬件检查 2. vmstat 3. iostat 4. nmon 5. netstat 6. top 7. db2top
sql = “insert into t values(?,?)” statement = connection.prepareStatement(sql); for(int i=1; i<100000;i++) { statement.setInt(1,i); statement.setString(2,”hello…”); statement.addBatch(); } statement.executeBatch(); statement.close();
使用场合：
应用程序请求驱动从数据库返回记录的时候，会读取多条满足条件的记录 并存储在客户端的内存中，这样后续的请求可以从客户端内存中直接去读
4
© 2009 IBM Corporation
第三招：从应用到数据库-批量提交
背景： 有时候，我们需要插入大量记录到数据库，如果逐条逐条的插入，则性能 低下，这个也不是数据库引擎导致的，应用需要优化，那么如何解决呢？ 用法：
• 资源利用率:
数据库服务器在处理事务或者查询的过程中，系统资源包括CPU、I/O以 及磁盘的使用情况，这个指标反映了系统资源是否被服务器有效利用。
9
© 2009 IBM Corporation
Agenda
• 教你三招 • 什么是性能问题 • 找到性能瓶颈 • 硬件规划
• 实战案例分享
10
© 2009 IBM Corporation
• 实战案例分享
15
© 2009 IBM Corporation
CPU
• OLAP/BI应用: • 每处理器内核支撑200-300 GB活动数据 • OLTP: 浏览 TPC-C DB2 9 测试结果
• • • • • 8 core IBM POWER5 1.9 GHz = ~430K TPM 8 core IBM POWER6 4.2 GHz = ~630K TPM 64 core IBM POWER6 5.0 GHz = ~6M TPM 8 core Intel Xeon 3.33 GHz = ~314K TPM 16 core Intel Xeon 2.93 GHz = ~517K TPM
Байду номын сангаас• 创建表空间
db2 create tablespace tbshot using stogroup sg_hot； db2 create tablespace tbswarm using stogroup sg_warm； db2 create tablespace tbscold using coldgroup sg_cold； • 表空间在线更改（从sg_wam->sg_hot） db2 alter tablespace tbswarm using stogroup sg_hot；
磁盘瓶颈
CPU瓶颈
懒惰系统
内存瓶颈
网络瓶颈
（性能上限） 高级技术优化
8
© 2009 IBM Corporation
度量性能的三个指标
• 响应时间:
数据库服务器收到应用请求后完成处理并返回给应用总共所消耗的时间， 它反映了服务器的处理速度。
• 吞吐量:
通常用每分钟处理的事务数（TPM）来计算，这个指标反映了系统的事务 处理能力。
21
© 2009 IBM Corporation
热表优化-将表按照访问频度分组（1）
背景： 数据库存在“二八法则”，20%的表往往是被80%的用户经常访问， 80%的表被20%的用户经常访问。针对这种不同访问频度的表，需要有针 对性的优化方案。 案例： 某券商在某个月，某些持仓大户的数据需要频繁读取并且对IO性能要求高 ；某些持仓散户的数据需要一般性的读取；其他散户则不怎么读取。用户 数据的访问频度不固定，下个月可能就会发生变化了。 解决办法： 1，方法一：为不同读取频度的用户数据，创建不同的表空间，数据访问 越频繁，容器就建在越快速的I/O设备上。如果发生变化，DBA需要花费很 多精力在不同表空间之间移动数据。 2，方法二：（下一页）