自营

让DB2跑得更快——DB2内部解析与性能优化

  
本书作者在DB2China数据库论坛担任热点讨论版块版主，主持多次热点讨论以及专家现场诊断，擅长DB2数据库及相关产品的性能调优及故障分析，对DB2技能及实践经验有多年积累，并且近年来多位业界专家一直在积极推动DB2领域的技术交流，真正理解DB2技术人员真正的需求与痛楚，是DB2系统知识及技巧精髓的热心分享者及贡献者。
作者本人出于对DB2的狂热与追求，通过长期的凝练与汇聚，将DB2知识系统化，把DB2数据库调优技巧的精髓热心地分享给广大读者，并且凭借深厚而扎实的理论及经验，对DB2数据库的内部进行了深入解析，这是对数据库领域所做出的重要贡献与精彩强音！
单看“内部解析”四个字，就已经能体现本书的宝贵价值，在“内部解析”的基础上进行“性能调优”，定会让您的DB2“跑得更快”！

  
推荐序一
画家相信绘画可以描绘我们的人生，哲学家认为意识可以归纳我们的生活，物理学家想找个支点来撬动地球，而我们从事数据领域的工作者大概更倾向于通过数据来改变世界。
为什么数据可以改变世界？为什么数据可以改善生活？为什么数据会带来艺术品位，提供心灵享受，推动科技成果？有人会想到苹果，有人会想到微博，更多的数据库技术人员还会列出许多数据引起的科技革命：物联网、大数据、云计算、移动互联网……数据正在撼动每一个角落：金融业、制造业、电力、国防、医药、交通等众多领域。简单来讲，数据蕴含着神奇而美妙的能量，它正使更多的人变成数据的信徒。
而我本人正是一名数据的信徒，多年来在著书、培训、咨询和管理等多项工作中，始终在数据的海洋中忘我与痴迷。在受邀为本书作序之时，我回想起五年前正埋头于写作的我。那时，每日工作繁忙，仍笔耕不辍，把之前在数据库领域的各项工作中所获得的技术积累、经验总结都尽可能地通过文字展现给读者。自认为写数据库的书很苦，写DB2的书更苦，在出版多部著作之后，我对优秀数据库著作的评判标准，可以套用新闻界的行话：“如果事件报道得不够好，那是因为离得不够近”。
本书正符合优秀数据库著作的评判标准。其对于DB2的技术理念与解决方法、实战性与科学性贯穿始终，这也与作者多年的DB2技能经验的积累与自我不断地改进完善有重要关系，同时，作者与多位业界专家一直在积极推动DB2领域的技术交流，这也使得他们距离DB2微观社会“足够近”，因此可以与DB2读者“同呼吸”，理解DB2技术人员真正的需求与痛楚，分析与归纳出专业的技术总结。
作为数据库领域的一位积极参与者，看到这样一部精彩的DB2著作出炉，我深感欣喜与慰藉。本书作者从浩如烟海的数据库宝库中挑选出重要的知识点，引述了许多有意义的案例、搭配实例与配图，以轻松的笔调深入浅出、娓娓道来。可以看出，作者并非以单纯地解决DB2问题为目的，本书也不仅仅单纯地是为希望找到能解决这些问题的人们而写的，作者的写作目的更多的是为了传播DB2知识，激发读者对数据库技术的热情！
说到这里，又想起让我推而崇之的那句话：古之成大事者，不唯有超世之才，亦唯有坚韧不拔之志也！学习数据库技能，从事数据库技术工作，建议大家去除浮躁，认真学习，不断积累，寻找机遇，从而通过一己之力，与志同道合者共同为我们国家添砖加瓦，做出自己的奉献！
牛新庄
国内顶尖数据架构和信息治理专家
对外经济贸易大学客座教授、北京交通大学兼职教授
中国DB2用户协会（CDUG）理事长
亚洲金融合作联盟信息科技委员会主任
中国民生银行总行科技部总经理
推荐序二
DB2的发展需要什么？答案很多，在本书的序言里，我更想提到的是，DB2的发展需要更多的粉丝及草根。一名粉丝的评论或许无力，一名草根的声音可能无法被人听清，但是数量多了呢？气势大了呢？有句话说到：世间最柔最弱的事物是水，遇到小的石子也会改变流向，盛在碗里就是圆形，倒在樽里就是方形。不过，如果水聚成川，那么再大的岩石都无法阻挡。
如今，我们可以欣喜地在论坛、微博、讲坛、大会等众多传播媒介中，看到与日俱增的DB2粉丝们的热情，听到DB2草根们的声音，得到DB2新手们的关注。这是我们IBM工作者的动力，也是最好的鞭策。可以这样讲：对于汲取DB2知识的渴望，有如细碎的火花，遍布辽阔的原野；针对DB2解决方案的执著，好像汇聚的江川，奔流不息。
同样令人喜悦的是，本书作者出于对DB2的狂热与追求，通过长期的凝练与汇聚，将DB2知识系统化，把DB2技巧的精髓热心地分享给广大读者，这是对数据库领域所做出的重要贡献与精彩强音！
为了满足社会高速发展的需求，已然历经百年的IBM正经历着前所未有的积极变革与快速发展。在数据库领域，我们可以看到DB2
pureScale技术正绽放于中国众多关系国计民生的系统中；我们的大数据解决方案PureData
Systems，正在引领数据行业发展潮流；而DB2
10.5即将吹起新一代数据分析技术BLU的号角，使我们的客户对IBM数据库解决方案的信仰更加坚定。这么多的精彩时刻，离不开粉丝们的积极参与，离不开草根们的支持。
而在出版领域，本书将给我们带来最新的收获。我相信这本汇集作者的技术、经验和总结于一身的专业书籍，一定能吸引中国广大DB2爱好者沉浸于书中，并帮助他们取得重要的技术提升与进步。在DB2领域，你、我、他、她，都需要这份吸引力，使DB2获得更多的粉丝、更广泛的草根群和更令人满意的沟通、交流渠道。
干毅民
DB2开发及客户支持总监，IBM中国开发中心
2013年5月26日
推荐序三
一直以来，我都认为数据管理与数据维护是一项神圣且充满爱心的职责与工作。我在讲课中常以“提灯女神Florence
Nightingale”为例，她是世界上第一位真正意义上的护士，开创了护理之先河，不但是护理大师，还是数据大师、统计大师。
Florence
Nightingale出身富贵，却心系穷苦人。在当时残酷的克里米亚战争中，战死数十万人。她自愿担任战地护士，每晚提灯巡视，她通过考察发现，因伤致亡的人数远大于在前线阵亡的人数。之后她通过自学的统计学知识提炼收集的数据，绘制了世界上首例扇形图。清晰的伤亡数据对比图形的震撼展示传回国内后，舆论哗然，政府立刻组建战地医院，大力增加护理人员，从而挽救了更多的生命。她的壮举在中国也成就了奉献与爱心的代名词：南丁格尔精神。我想，对于同样从事维护与治理工作的数据人员，这种精神与睿智同样具有榜样的力量！
本书所要面对的数据库管理与性能优化的读者，应该心存几个长久不衰的问题：
如何著书立传？怎样写出高水平的著作
写作这门艺术，是我多年探索的目标。在出版几部数据库著作后，通过亲身经历，现在为有志向著书立说的朋友分享一些经验。从技术著作的写作技巧来看，按水平高低分为几个档次：
1．善用图、表、例者，赞而嘉之
视觉效果需要冲击。人的大脑皮层中，有41%是视觉反应区。图像比文字传递信息更加快捷、直观，无论是对会场中的听众，还是对高高在上的决策者，抑或正在翻看书籍的读者。因此，善用图表来解释证明技术问题，是聪明而合理的方式。在数据领域，这种美学范畴也导致了商业智能、数据可视化等细分学科的迅猛发展。因而在写作过程中，应毫不吝啬地增加图表的数量与质量。
而举例，则是写作技巧中更能展示实力的方法。实际上读者更倾向于阅读实战类的书籍，例子多多益善、案例不胜枚举的书想必会大受欢迎。
2．比喻，是讲述问题的更高层次的方式
从事计算机领域的工作，需要逻辑思维、形象思维、抽象思维。枯燥的理论阐述常使读者昏昏欲睡，不知所云。而打比喻，无疑是亮点。通过打比喻，可以把深奥的技术点带进我们熟知的领域。我所仰慕的墨家学说里有种理念是：世间的道理只有那么一点点。所谓大道至简，分化在各个领域出现了不同的形态，而比喻恰恰能够把看似复杂的理论提炼为我们易懂的道理。记得王涛有篇文章是通过我们所熟悉的在银行交易的场景做比喻，来讲解代理进程、分区内并行、分区间并行、分区数据库等概念，这种讲述方式受到了广泛赞许，也是比喻这种方式的功力展现。
3．讲故事，是比喻的更为生活化的阐述方法
我们现在已经可以接触到越来越多的笔记类的数据库著作，我在著作中也曾有尝试，也期待着有更多类似书籍的出现。
4．什么样的著作才称得上经典中的经典
我认为，一本读物，尤其是数据库著作，如果能使读者在通读全书后，对人生有所感悟，在哲理层面有所收获，甚至还有励志的效果，那么这样的著作实为经典中的经典。
为什么性能优化这么重要
数据库性能优化之所以愈发重要，究其原因是数据爆炸的发生，迫使我们追求更为快捷、高效的生活状态与工作方式。这其中涉及多种词汇：信息增长、数据爆炸、海量数据、大数据等。
之前我曾读过一本关于数据的科幻小说，叫作Cagatis。它讲的是在未来，人类掌握了预知本领，那并非是占卜，而是通过关联数据分析来预测人类的行为，比如一个人的信用卡记录、网聊记录、驾驶记录、旅行记录、医疗记录、通话记录等，之后对这个人自出生后的所有相关数据进行综合分析，利用生物数据库模型与人类行为分析算法，就可以准确地预测此人下一步的所作所为。事情遥远吗？其实正逐步发生！有新闻报道，美国曾发生有公职人员参与非法赌博，通过获取对手的车牌号、教育背景、网络留言等个人信息，分析预测出对方在投赌时的心理。
而从目前看来，微博、微信都已不再是新鲜事物，个人的数据逐渐开放与透明，而计算机系统捕捉与分析信息的能力也愈发强大，这延伸了一个伦理层面的重大问题：在不远的将来，是我们更懂我们，还是机器更懂我们？古老中国的“知己知彼，百战不殆”的精髓将会被数据预测系统演绎得淋漓尽致！也许你我正一步步地从生物王国走向数据王国，而在这根链条上，与日俱增的海量信息的处理与分析，一定对系统的运营优化与性能处理提出了持久的需求与考验。
如何深入学习数据库知识
要想深入学习数据库知识，不能仅仅着眼于技术问题的积累，更要通观体系与全局。回顾整个数据库的发展史，可以说，数据的演进发展使我们的生活趋向开放与透明，是从封闭到开放的过程。最初，二进制的出现，是对数据组织与处理的革命性贡献，也是软件运行的支点。之后IBM的研究员Edgar
F.Codd提出了关系型数据库，首次将之前软件的混沌形态分解为数据与程序，使对信息的禁锢得以解放。最显著的效果就是基于事务处理的OLTP（Online Transaction
Processing）系统的诞生，在航空、金融、军事等领域遍地开花。在这个过程产生了大量的数据（Data），大量的记录（Record）被存储，但是数据并非信息（Information），也不是知识（Knowledge），更不能成为智慧（Wisdom）。当系统愈发庞大、复杂时，人们发现正确、合理的决策愈发困难，面对大量的数据，竟然会失去对数据的正确判断与控制！
之后，决策支持系统应运而生，这需要将原有的数据系统进一步划分为运营处理系统与决策分析支持系统，这使得数据仓库横空出世。数据仓库是从数据到智慧的过程中的转折点，是对多类数据源的强有力的整合，又通过ETL（Extraction
Transformation Load）工具的支持辅佐，一跃成为进入21世纪时的明星。不过对于真正的由数据衍生出的智慧，还需要更高层面上的系统——OLAP（Online Analytical
Processing）联机分析处理系统。它首次将多维的理念引入分析领域，使得我们可以在各个维度之间任意切换，从不同的维度、粒度对数据进行分析整理，继而得到动态、完整、灵活的分析报告。
之后离商业智能的实现越来越近，这主要基于新的技术走向前台——数据挖掘。最典型的案例就是啤酒与尿布的例子，它代表着数据挖掘技术带来的智慧与体验。它可以发现规律，而发现规律意味着可在一定程度上预测未来。这种从已知到未知的进程，使数据的生命发生了质变。
报表，这一将数据转化为知识的展现工具已经成熟，新一代的数据展现工具百花齐放，这实现了商业智能从数据整合、分析、挖掘到展现的完整链条。这个链条的发端是若干独立的关系型数据库，经过数据整合而形成多源统一的数据仓库，之后经过联机分析处理，或者是数据挖掘，找到其内在的趋势，而这就形成了知识。如果将这些知识进行可视化处理，合理的展现结果就会为决策者形成意识与认识。如今，大数据时代的到来，更加个人化、更加分散、更加难以处理的非结构化的海量数据，给高效地形成认识这一数据库的终极目标，带来了有趣而艰巨的挑战。
深入理解数据库的过程就像数据库本身的历史一样漫长而复杂。本书有一章在讲述SQL语句性能优化武器时，套用了武侠小说里的7种武器。这是作者在写作风格上的大胆尝试，也是从古龙小说中借鉴的对数据库工作在哲学层面上的思考。这说明了数据库性能优化技术是单调的，但使用这一技术的人是灵活的，不管掌握的是武器，还是工具，都不如对人的心灵与精神的把握更具有内涵与力量。想起年少时，武术老师讲授内家功与外家拳，曾讲到：“内家十年不出手，十年之后打平手，十年下来遍地走”。本书书名中“内部解析”其实就是在讲授“内练一口气，外练筋骨皮”的道理。若按此精神坚持下去，一定会有所建树，绽放光彩。
笔者在为本序落笔时，再次建议大家加入知识分享与传播智慧的大军中来，所谓以小爱博众终无大智慧，以大爱感召必会惊天动地。
成孜论
资深数据库专家、著名数据库专著作者
推荐序四
读书，品书，回味与思索，一直是我工作生活的一部分。对于本书，一见书名《让DB2跑得更快——DB2内部解析与性能优化》，立刻就使我产生了兴趣与期望。在读过上百本数据库方面的书籍后，感到有的书催人思考，有的书主推实践，还看过有的书是技术达人对技术菜鸟的煽动，也见过技术牛人写书像是摆下擂台孤独求败，但是结合数据库内部机理介绍性能调优等方面的书籍却非常缺乏。本人在银行业从事系统设计及性能优化的十多年时间里，深切感受到DB2这方面书籍的稀少对从业者的困惑。因此我更青睐于那些重在强调理论与实践结合的技术作品，而对有关数据库性能优化的书籍则更是期待。
一直以来，数据库性能优化都是大型应用系统中技术含量较高的工作。是否能够针对业务特点合理地设计一个数据库的架构，能否更好地保证扩展性并将应用性能发挥到最大化，能否编写高效的SQL语句，这对于系统的稳定与安全运行至关重要。而在解决问题的表象背后，数据库性能优化的工作远远不止表面看到的那么简单，有时发现的问题只是冰山一角，有时解决掉的故障只是偏安一隅。值得注意的是，本书作者曾经在DB2技术支持的第一线奋斗过，其对于DB2性能优化、故障排除等各种技术工作的经验总结与技能提炼，对读者来说肯定是极好的知识盛宴与分享。
在思考为本书作序时，突然想起在一次数据库技术交流会上，有位业界朋友描述了两种典型的DBA工作状态：一种是不求有功但求无过；另一种是只见树木，不见森林。
第一种工作状态可以延伸到一个有趣的现象：羊群效应。这种效应说的是头羊向哪个方向走，后面的羊就低着头跟在头羊后面没有异议，没有怀疑地走。在金融与投资领域，这被解释为跟从模仿与盲目效仿的行为方式。其实这种现象，在从事数据库技术的领域中也常有发生：当之前有人说该如何做时，后来的人往往以为这就是定论，怀疑的人不多，想去尝试的人就更少；当不曾有人尝试，或者讲授改动某个参数的设置，调整某个参数，避免某种隐患的时候，有些技术人员往往对问题避而远之，抑或知其然而不知所以然。常可以见闻有些DBA的工作态度是：多一事不如少一事；能少做，就少做；能不动就不动，能不改就不改，因为担忧困扰的是在这一改一动之间，不知道会引发什么样的事故。不求功但求无过的想法，确实成了数据库技术人员提高能力、优化思路、增强实战解决问题能力的拦路虎。
接着讲一下前面提及的第二种工作状态：只见树木，不见森林。对于已经有一定DB2使用经验的技术人员，比如做过安装、管理、备份操作，对DB2数据库具备一定感性认识，但是大脑里还没有形成完整的理论框架的技术人员，在接下来的工作积累的过程中，随着经验的增加，是不是离把控全局的阶段更近了呢？我们可以做个比喻：画一个圆圈，圆内代表你拥有的知识，圆外代表未知领域，这个圆圈画得越大，代表你拥有的知识就越多，而圆圈接触到的未知领域就更广。因此，这就可以解释为何有的技术人员，在

  
本书以优化为主题，根据数据库内部原理将DB2数据库对SQL语句及其他操作的内部机制进行详细剖析，并将RDS、DMS、IXM、BPS等DB2内部组件不为人知的一面展现给大家，以期做到对数据库的调优过程知其然并知其所以然。同时本书结合响应时间与资源瓶颈两种性能问题的现象，对数据库调优的整体思路进行详细讲解，对原来老式的调优思路进行整理和改动，结合了DB2 V10.1版本的一些新的监控工具及特性，以一种全新的方式阐述DB2数据库性能调优的基本思路及实践方法。
本书适合DB2数据库管理员、数据库相关应用程序开发人员、系统管理员、系统架构师及有一定数据库基础的用户自学和参考，也可作为DB2培训的参考用书。

  
第1篇 性能定义及整体架构
第1章 DB2性能优化概述
1.1 性能目标
1.1.1 响应时间
1.1.2 吞吐量
1.2 工作负载类型
1.2.1 联机事务处理（OLTP）
1.2.2 联机分析处理（OLAP）
1.2.3 决策支持系统（DSS）
1.2.4 企业资源规划（ERP）
1.3 影响性能的因素
1.3.1 软件代码编写对性能的影响
1.3.2 应用程序架构设计对性能的影响
1.3.3 数据库设计对性能的影响
1.3.4 系统设计对性能的影响
1.4 本章小结
第2章 DB2架构介绍
2.1 DB2整体概况
2.1.1 DB2进程/线程体系简介
2.1.2 DB2内存体系简介
2.1.3 DB2相关文件简介
2.2 DB2组件介绍
2.2.1 操作系统服务
2.2.2 基本系统调度
2.2.3 关系数据服务
2.2.4 数据管理服务
2.2.5 缓冲池服务
2.2.6 数据保护服务
2.3 SQL语句处理过程
2.3.1 数据查询语言（DQL）
2.3.2 数据操作语言（DML）
2.3.3 事务处理语言（TPL）
2.4 本章小结
第2篇 性能监控工具及监控技巧
第3章 性能监控工具
3.1 实时监控工具
3.1.1 db2trc
3.1.2 db2top
3.1.3 db2pd
3.2 历史监控工具
3.2.1 快照
3.2.2 快照视图及快照函数
3.2.3 事件监视器
3.3 DB2工作负载管理（DB2 Workload Manager）
3.3.1 标识阶段（Identification Stage）
3.3.2 管理阶段（Management Stage）
3.3.3 监控阶段（Monitoring Stage）
3.4 语句解释说明工具
3.4.1 db2exfmt
3.4.2 db2expln
3.4.3 语句解释说明工具对比
3.5 监控技巧
3.5.1 查找数据库中耗时最长的语句
3.5.2 分析特定语句的时间分布
3.5.3 捕获所有的SQL语句
3.6 本章小结
第3篇 性能分析及内部原理剖析
第4章 深入探讨优化器
4.1 语法语义分析
4.1.1 查询解析
4.1.2 语义检查
4.2 SQL语句重写
4.2.1 谓词简介
4.2.2 扫描方式
4.2.3 连接运算
4.2.4 查询重写
4.3 优化器编译
4.3.1 生成备选执行计划
4.3.2 基数评估
4.3.3 成本计算公式
4.3.4 生成可执行的代码
4.4 基数评估检查
4.4.1 通过COUNT语句检查基数评估
4.4.2 使用Section Actuals分析执行计划
4.5 本章小结
第5章 SQL语句性能优化之7种武器
5.1 长生剑——基本统计信息
5.1.1 统计信息收集方法
5.1.2 统计信息收集策略
5.2 碧玉刀——分布统计信息
5.3 孔雀翎——列组统计信息
5.4 离别钩——REOPT
5.4.1 REOPT处理机制
5.4.2 REOPT的启用方式及监控
5.5 多情环——静态视图
5.6 霸王枪——优化概要文件
5.6.1 优化概要文件的使用方法
5.6.2 优化概要文件规则
5.7 拳头——语句优化
5.8 本章小结
第6章 数据对象存储设计
6.1 表类型及设计方法
6.1.1 常规表
6.1.2 MDC表
6.1.3 分区表
6.1.4 MQT
6.1.5 表设计原则
6.2 索引类型及设计方法
6.2.1 索引的作用
6.2.2 索引创建原则
6.2.3 索引键顺序的选择
6.2.4 索引设计性能考虑
6.3 DB2设计顾问程序
6.3.1 战略性的索引创建
6.3.2 战略性的表类型选择
6.4 本章小结
第7章 DB2物理结构深入解析
7.1 表空间结构剖析
7.1.1 SMS（系统管理表空间）结构剖析
7.1.2 DMS（数据库管理表空间）结构剖析
7.1.3 高水位对于性能的影响
7.1.4 对容器进行重新平衡对性能的影响
7.2 数据页详解
7.2.1 数据页结构剖析
7.2.2 字段类型与行迁移
7.2.3 页重组
7.3 索引页详解
7.3.1 索引内部结构剖析
7.3.2 索引的分裂
7.3.3 索引维护和清除
7.4 日志文件结构剖析
7.5 本章小结
第8章 I/O管理及优化
8.1 数据I/O管理
8.1.1 缓冲池I/O原理
8.1.2 缓冲池逻辑读取
8.1.3 缓冲池物理读取
8.1.4 缓冲池写入操作
8.1.5 基于块的缓冲池I/O
8.1.6 缓冲池I/O监控
8.1.7 直接I/O管理
8.2 日志I/O管理
8.2.1 日志读取
8.2.2 日志写入
8.2.3 日志I/O原理
8.2.4 日志文件I/O相关调优参数
8.2.5 归档日志对I/O的影响
8.3 本章小结
第9章 内存管理
9.1 内存模型
9.1.1 实例共享内存
9.1.2 数据库共享内存
9.1.3 应用程序全局内存
9.1.4 代理程序私有内存
9.1.5 排序堆
9.1.6 其他内存区域
9.2 STMM
9.2.1 STMM运行机制
9.2.2 STMM监控
9.3 如何定位及修复内存泄漏
9.3.1 内存泄漏诊断方法
9.3.2 内存泄漏的处理方法
9.4 本章小结
第10章 DB2等待事件
10.1 锁对象及兼容性
10.1.1 锁对象及锁模式
10.1.2 锁兼容性及锁转换
10.2 锁问题的监控与解决
10.2.1 锁事件监控
10.2.2 锁问题解决方法
10.2.3 锁案例分享
10.3 latch事件
10.3.1 latch监控
10.3.2 案例分析
10.4 本章小结
第4篇 实用工具调优及操作系统优化
第11章 实用工具调优
11.1 备份恢复工具
11.1.1 backup
11.1.2 restore
11.2 数据移动
11.2.1 export
11.2.2 import
11.2.3 load
11.3 其他管理工具
11.3.1 reorg
11.3.2 runstats
11.4 本章小结
第12章 操作系统相关问题
12.1 AIX
12.1.1 虚拟内存管理
12.1.2 磁盘及文件系统管理
12.1.3 网络调优参数
12.1.4 操作系统相关参数
12.1.5 系统监控工具
12.2 Windows
12.2.1 内存管理
12.2.2 磁盘及文件系统相关参数
12.2.3 系统监控工具
12.3 本章小结
第5篇 性能分析思路及优化总结
第13章 性能问题分析思路
13.1 响应时间问题
13.1.1 响应时间总结
13.1.2 通过快照进行分析
13.1.3 通过快照函数进行分析
13.2 资源占用问题
13.2.1 磁盘瓶颈
13.2.2 CPU瓶颈
13.2.3 内存瓶颈
13.3 本章小结

  
9.3 如何定位及修复内存泄漏
在怀疑遇到内存泄漏的问题之前，必须谨慎地判断当前数据库中是否真实存在内存泄漏。判断数据库中存在内存泄漏时需要注意以下几点：
— 系统中的内存在逐渐减少，甚至导致换页（paging）；
— SQL语句越来越慢（经常是换页导致）；
— 随着时间增长，由DB2分配的内存在不断增加。
9.3.1 内存泄漏诊断方法
正如之前介绍的，从DB2
V9.5版本开始，可以很轻松地检查当前各个内存集的使用情况。每个数据库分区都会保留当前分区中内存使用信息的实时状态。其中包括所有的私有内存、应用内存、数据库共享内存、数据库管理器共享内存及分区间共享的FCM内存。我们可以通过db2pd
-dbptnmem命令观察当前数据库中各部分内存的使用情况。输出结果如下：
>>>> Database Partition 0 Memory Statistics
<<<<
Controller Enabled: Y
Controller Automatic: Y
Memory Limit:
28609436 KB 内存限制（INSTANCE_MEMORY的值）
Current usage: 898240
KB 当前内存的使用量
HWM
usage:
898240 KB 内存最高使用量
Cached memory: 271424
KB 总共的缓存大小
Individual Memory Consumers:
Name
Mem Used (KB) HWM Used (KB) Mem Cached (KB)
============================================================
APPL-LIAM
160000
160000
159616
DBMS-lfinnie
36608
36608
3648
FMP_RESOURCES
22528
22528
0
PRIVATE
12032
12032
256
FCM_RESOURCES
10048
10048
0
LCL-p1130882
128
128
0
DB-LIAM
656896
656896
107904
可以看到当前分区中INSTANCE_MEMORY的限制值大约为28GB，当前内存总共使用了898MB大小。其中271MB作为申请后并未使用的内存，意味着当前已经提交的内存大约为627MB。如果将这些内存按照内存集分开观察，可以分为以下几个部分：Mem
Used代表向操作系统中已经申请的内存部分，DB2会提前向操作系统申请部分多余内存；Mem
Used区域是目前可以被DB2分配给各个内存池的总共大小；CACHED部分是还没有被任何内存池占用的内存数量，同时也代表当操作系统中内存不足时，可以释放的最大内存数量。
对于单次调用db2pd
-dbptnmem命令所得到的输出结果，很难从中发现当前是否存在潜在的内存泄漏问题。还需要了解以下情况来证实我们的猜测：
— 如果没有任何激活的应用程序，实际提交的应用共享内存应该非常小（Used -Cached）；
— 如果没有任何监控开关打开，则实例共享内存的值应该非常小；
—
私有内存的大小应该根据线程数量浮动。如果发现每个线程需要消耗1～2MB的内存，代表可能会发生内存泄漏（除非启用私有排序，如果启用私有排序，则每个线程消耗的内存应该不大于SORTHEAP定义的值）；
—
对于单分区实例，FCM_RESOURCES应该是不变的。对于多分区实例，如果存在大量跨节点连接的操作，则FCM_RESOURCES会占用相当大一部分内存；
— 对于数据库共享内存，其内存集大小应该等于内部所有内存池之和（缓冲池、锁列表、Package cache等）。
如果有缓慢的内存泄露发生，仅仅祈祷是不起作用的，需要定期检查当前正在使用的内存量。在开发环境中，以下几个关键点在对内存泄露检查时非常有用。例如：
— 数据库激活之后，还没有任何应用程序连接时；
— 应用程序准备执行前；
— 应用程序执行过程中；
— 应用程序执行后。
判断内存泄漏需要定期地对比当前数据库中的内存情况。在应用程序数量、执行语句类型及数据量变化不大的情况下，内存的使用应该也会保持恒定。如果发现内存在缓慢增长，则可以认为是内存出现泄漏。但是有一点例外，当启用STMM功能且数据库参数DATABASE_MEMORY是自动调整的情况下，可能会出现数据库共享内存会基于数据库中的空闲内存数量增加或减少，但是其他内存集不会受到任何影响。
……