A DB2 Performance Tuning Roadmap

　庖丁为文惠君解牛，手之所触，肩之所倚，足之所履，膝之所踦，砉然向然，奏刀騞然，莫不中音。合于《桑林》之舞，乃中《经首》之会。 文惠君曰：“嘻，善哉！技盖至此乎？

说起DB2，大家可能比较陌生，更多的是对oracle，SQLserver，MYSQL以及大行其道的NOSQL如MongoDB,REDIS等了解的比较多。笔者由于工作的原因对DB2接触的比较多，在这里谈一下自己的理解。由于笔者自身的局限性，对很多问题的描述可能准确，欢迎指正。 大家都知道MYSQL是单进程多线程，ORACLE在Window和linux上表现不同，windows下是单进程多线程，linux下是多进程方式提供服务。DB2也是以类似多地址空间（与进程相类似）的方式提供服务。

 Architected around the address space Conceptually, DB2 is a relational database management system. Physically, DB2 is an amalgamation of address spaces and intersystem communication links that, when adequately tied together, provide the services of a relational database management system. 

DB2 的这种进程处理方式，OVERHEAD便是进程间通信，引入了很多的子线程的分类，如CICS THREAD,ALLIED ADDRESS SPACE,DATABASE ACCESS THREAD,这些概念可能通过进程间通信这种方式来理解就比较好接受了，这也引入了所谓的不同的CALL ATTACHEMENT FACILITY的概念，其实都是由于DB2对外开放的不同API而已。 关于DB2 cluster的工作方式更多的是DB2 DATA SHARING,可以参考

1. 浅析DB2 中的DBMS CLUSTER技术
2. DBMS-DSG初探之XCF
3. DSG CF 之cache 漫谈
4. DSG CF 之cache 漫谈1
5. DSG CF 之cache 漫谈2
6. DB2 Buffer 原理简介
7. 数据库设计的理论依据

OUTLOOK OF PERFORMANCE

本篇内容是在写完后，在次进行的梳理，同时增加了应用调优的部分。知识的学习本身也是一个循序渐进的过程。 首先我们需要明确性能的概念，何为性能，它对应的英文单词为performance，维基百科给出的解释--- 计算机完成某项有用的工作所消耗的时间与资源。所以好的高性能，也就意味着使用更少的资源，更快的完成工作。 性能的目标是没有蛀牙，哈哈

1. realistic 即性能在当前的技术下可以实现，如交易平均响应时间0.1就是可以实现的，0.000001，NOT REALISTIC
2. reasonable 合理的
3. quantifiable 可以量化的如RATIO,PERCENTAGES,NUMBERS,而不是good,perfect,这种空洞的描
4. measurable 可以度量的

根据国情，所有这些都是要满足leader的需求为前提，指定上述目标后，就是monitor，看看当前的系统是否满足上去要求，从而进行调优。monitor根据执行的频度有三种：

1. routine monitoring
2. online/realtime event monitoring
3. exception monitoring

其实DBA面对更多的是2,3所发现的问题，时间紧，任务重，如果可以规避还好，如果不能规避，需要实施紧急变更。但是如果monitor 1 基础打得好，可以提前发现很多问题，将问题消灭在萌芽状态。monitor 1 更多是收集性能信息，以及系统整体的运行情况。

总体指导思想

1. TOP-DOWN TUNEING
2. DEVIDE AND CONQUER
3. 二八原则。花80%的时间解决20%的问题，带来80%的收益，即最佳性价比
4. 一个前提：当系统运行或是应用出现问题的时候，我们总是假定这是一个由量变到质变的过程[变更除外，这种情况下需要紧急回退]，即我们总是假设系统或是应用在以前是正常的，我们需要一个benchmark.这就给我提供了一个思路，当你没有思路时，你可以和历史数据进行比较，从而发现问题
5. 关于定性和定量的问题,相对来说，定性容易，定量有时候还是比较困难的
6. 从管理的角度，调优是一个持续改进的过程,应该是一个闭环，即监控发现问题，分析问题，解决问题，而后继续监控

7. 一点体会： 其实调优本身也是一个资源配置的问题，在特定的场景之下，如何把有限的资源进行有效的配置，从而达到组织的目的。 整个组织目前拥有的资源，这里只对计算机系统调优而言：

   1. CPU
   2. IO
   3. LOCKING
   4. STORAGE5. human resource 当然就是你了
   5. NETWORKING 可忽略
   6. SYSTEM HARDWARE & OTHER SOFTWARE SUCH AS CICS/ZOS/CFCC

影响这些resource的方式不外乎：

1. got enough 2. not enouth 3. too much 4. inefficient 5. what are the available controls? (fixes) 

两大方向

系统调优 应用调优

系统调优

关于系统调优前面已经介绍过了--,这里的任务就是如何在总结提炼.那篇文章介绍的更多内容其实对应的是routine monitor，

CICS性能数据收集

交易性能数据对应的SMF 类型为110,对应的分析工具CICS PA

SMF Type 110 (subtype0) — CICS Journal Record SMF Type 110 (subtype1) — CICS Monitoring Record SMF Type 110 (subtype2) — CICS Statistics Record 

DB2 性能数据收集

DB2 SMF 对应的SMF TYPE 为100,101,102,其中

SMF TYPE=100 DB2 SUBSYSTEM STATISTICS
SMF TYPE=101 DB2 ACCOUNTING 
SMF TYPE=102 ALL OTHERE PERFORMANCE 

SMF TYPE=100 的表格如下

CLASS	DATA COLLECTED	IFCID
1	Statistics data	1, 2, 105,106, 202, 225
2	Installation-defined statistics record	152
3	Deadlock, lock escalation, group buffer pool, data set,extension information, indications of long-running URs, and active log space shortages	172, 196, 250, 258, 261, 262, 313, 330, 335, 337
4	DB2 exceptional conditions	173,191-195, 203-210, 235, 236, 238, 267, 268, 343, 402
5	DB2 data sharing statistics record	254
6	Storage usage details	225
7	DRDA location statistics	365
8	Data set I/O statistics	199

SMF 本身的结构也是一个树形层级结构,如果打算收取某一类型的trace，你需要关注三个方面，

1. TRACE TYPE
2. CLASS
3. IFCID

这样对应的收取trace的命令就很好理解了

START TRACE(S) CLASS() IFCID(172) DEST(SMF) ---TNO
DIS TRACE
STOP TRACE(S) TNO(XX) recommand defualt trace:
start trace(s) c(1,3,5,6,7,8) 

解读stat

这里首先介绍SMF TYPE=100,由上面的表格，我们可以了解到stat报表包括的大体内容，下面我们逐一介绍，让你对报表有一个大体的了解，有时候自下而上解决不了问题的时候，stat就是一个关键的突破口。 STATISTICS 性能数据收取的时间颗粒度为1分钟，相比较SMF TYPE101，102，它的量是很少。 考虑解读性能数据的重要性，后续单独写一篇来介绍，你放心，绝对值得写一章。 在结束准备工作之前，在向你介绍一个性能数据在一个颗粒度内是如何计数的，主要分为3类：

1. SNOPSHOT VALUE--current value 即性能数据收取时间时对应的实时值
2. HWK --HIGH WATER MARK 对应的时间颗粒度内的最高水位值
3. ACCUMULATE VALUE--累加值，时间颗粒度内一个逐渐累加计数值作者注明确这一点对性能数据解读很重要。

16年第一篇，希望有一个好彩头