Sina Visitor System治感冒咳嗽验方
当前位置： &nbsp>&nbsp&nbsp>&nbsp&nbsp>&nbsp
治感冒咳嗽验方
来源：&0000000&&&&
字体：&&&&&
常用百合15克、梨1个、白糖15克、混合蒸2小时即可。有清热、润肺、止咳及利大小便的功效，用于治感冒咳嗽。
用大生梨1个，削去皮，挖去心，加入川贝母3克，覆盖好，放碗内隔水蒸1小时～2小时，喝汤吃梨，每天1个，用于治感冒咳嗽。川贝能润肺止咳，化痰散结。梨能生津润燥，清热化痰，用于肺热咳嗽。
梨川贝白菊汤
雪梨1个，去核切片，川贝、桔梗、白菊花各3克，水煎去渣，加冰糖适量饮服。用于治感冒、气管炎和咳嗽。桔梗味苦、辛，性平，有增强免疫力、抗炎、祛痰和镇咳作用。白菊花性微寒，有散风清热、平肝明目功效，用于风热感冒。
杏仁生姜萝卜汤
杏仁10克、生姜3片、白萝卜60克，加水煎服。用于治感冒咳嗽。杏仁味苦，性微温，有小毒，有顺气、止咳、平喘和润肠通便功效，用于治咳嗽、气喘。姜有发表散寒、去湿利水、祛痰功效。白萝卜性味甘辛、性平、无毒，有下气消食、除痰润肺、止咳喘作用；白萝卜还含有芥子油和淀粉酶，有促进食欲帮助消化的作用。萝卜里的木质素，能增强人体的免疫力。
芫荽9克、鲜姜3片，加红糖少许，煎汤取汁饮。用于治感冒咳嗽。芫荽味辛性温，能发汗，有消食下气功效。芫荽叶中的维生素A可提高人体免疫力，增强抵抗力。保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
单击提交则表示您同意developerWorks
的条款和条件。 .
所有提交的信息确保安全。
developerWorks 社区:
我的概要信息
选择语言：
本书原汁原味地展示了 DB2 设计和优化技术，深入剖析了 DB2 的工作原理。本书适合 DB2 数据库设计人员、DBA、数据库性能分析人员、数据库开发人员、运维人员及应用开发工程师阅读和参考，也可用做高校相关专业或培训班的教材。在此我们推出了本书的 、第 章和第 章供大家在线浏览。更多推荐书籍请访问 。
, 软件工程师, IBM
王飞鹏，DB2 数据库资深顾问。曾为电信、银行、中央部委、中国高铁等大型数据库项目做出了重要贡献。首次提出 PAT 方法学，为解决数据库性能问题提供了分析标准。发表数据库论文 12 篇，拥有软件专利 3 项。每年通过大量咨询、讲座、培训等方式，为数据库人才更好的运用数据库技术作出了最大的努力。
, 软件工程师, IBM
陈辉，DB2 数据库内核开发工程师。来自 IBM 中国 DB2 开发团队，具有多年 DB2 引擎开发经验。目前从事 DB2 内核开发和客户技术支持工作，精于 DB2 问题诊断处理，拥有系统分析师认证、IBM DB2 各项认证。
, 软件工程师, IBM
张广舟，DB2 数据库资深软件工程师。多年来一直从事 DB2 核心开发工作。现任 IBM 中国 SQL 编译器和优化器开发组长。曾发表多篇数据库技术论文，擅于解决大型数据库性能问题，并拥有软件专利 1 项。
, 数据库咨询专家, 作者
成孜论，数据库咨询专家。曾为荷兰银行（香港）系统数据库技术顾问、KDDI通信数据库咨询师。现受聘为中国大陆某金融机构数据库 Senior Consultant。
数据库系统出现性能问题，好比人得了病一样，需要治疗。俗话说，“症见于四肢五官，病隐于五脏六腑”。本章阐述如何从体系层面上运用 PAT 方法学定位问题、调理系统、优化性能。PAT 方法学使用 PAT 树来定位数据库性能问题，其本质是提供了一套系统化的优化思路。这已成为一种标准，被大量实践证明是切实可行的。在本章结尾的“案例分析总结”中，就记录了 PAT 方法学的现场应用。如果对一位经常感冒的病人，医生只开出感冒药；对一位经常咳嗽的病人，医生只开出止咳药，那么患者可能碰到庸医了。因为这是在治标而非治本。庸医治病引发的后果就是，症状不但没好，病却越来越多。其实需要重点治疗的是发病的脏器，以及调理生活习惯。内在系统通顺了，外在症状自然消除。对于数据库性能的症状，我在第 1 章作了介绍，给出的是 PAT 方法系统，它可以协助你梳理问题的来龙去脉，从而清除掉性能优化的障碍。接下来通过一个经营分析系统的优化案例，开始熟悉 PAT 的应用过程。在电信和金融行业中，经营分析系统能最大限度地整合企业的各类历史数据和交易数据，为企业提供统一的数据支撑平台，并提供相应的统计分析报表、多维分析（OLAP）、数据挖掘（Data Mining）等应用功能。经营分析的目的是发现数据中的趋势，从而能够更有效地满足企业的战略决策支持需求、业务操作需要及技术需求，同时也为企业进一步建立有效的客户关系管理系统提供坚实的数据基础。概括来说，经营分析系统是为企业经营管理、市场营销和业务运营提供分析决策支持的系统。2.1
优化步骤介绍经营分析系统的架构后，本案例采用本书第 1 章 1.3.4 节所阐述的优化步骤：即首先业务角度来确定性能问题，并设定每个问题的优化目标及优先级；随后，从系统角度确定性能问题的根本原因，找到时间是如何被消耗的；进而，使用 PAT 方法学四项原则制订优化策略；最后成功优化数据库并完成性能验证。2.2
业务分析2.2.1
经营分析系统的架构如图 2-1 所示，经营分析系统是企业的信息集成平台，因为业务架构往往都是基于基础数据仓库的。与面向事务的数据库不同，数据仓库的重要特点是面向主题。主题是一个在较高层次将数据归类的标准，是用户使用数据仓库进行决策分析时所关心的重点方面。每个主题对应一个分析领域，通常与多个操作型信息系统相关。数据仓库数据的组织方式可能已经完全不同于原始的业务系统。根据业务需求的不同，数据仓库的组织形式以第三范式模型为主，在有的系统中也可能采用星型或雪花模型。经营分析系统为应用提供了在线分析处理（OLAP）能力。这使得用户可对数据进行分析以获得透视能力，并在此基础上采取行动。用户可以访问、计算及共享信息，以便跨越产品、市场、职权、流程、时期和情景等进行绩效检查、质量评判及因果分析。信息门户网站为整个公司的内网用户管理报告出版及订阅，另外，既然已建起了信息访问平台，并且具备了实时信息，配置相应的门户网站应用程序必然轻而易举。图 2-1
经营分析系统（）在本例中，从来源复杂的数据进入数据仓库之前，必须经过 ETL（Extract、Transform and Load）过程，来消除来自不同数据源的数据不一致之处，以保证数据仓库内的信息是一致的全局信息。全局信息包括未经汇总的客户交易数据，用户资料数据、客户服务数据等。此外一些相关数据如竞争对手，成本投资数据也包括在内。由于基础数据仓库中的数据是对原始业务数据的再现，所以数据量会非常庞大，根据不同业务的需要数据保留的时间在 6 个月到 2 年不等。通常根据需求将数据仓库数据分类成几个不同的数据集市，每个数据集市完成不同的分析和查询需求，数据集市中的数据通常由基础数据仓库的详细数据聚合而来。根据数据聚合程度的不同包含轻度聚合、中度聚合和高度聚合三种不同的层次。数据聚合方式将依据数据量的大小和使用频度综合考虑。
本例中的经营分析系统从架构上来看，自下而上主要包括 4 层，即获取层、存储层、应用层和访问层，具有下面的特点：
一个中心数据库，以便为所有可用信息资产提供在线目录。
一组全面的、集成的信息视图。
为决策所需信息提供简便的返回方式。
完善的应用程序、门户网站产品、报告及商务智能工具、对迅速生成特定报告所需信息的快速建模及重建模能力。
可满足现存报告及分析流程的灵活环境。
对多变的业务需求的快速支持，同时需考虑到高度的可用性、性能及可伸缩性。
通过有选择地将那些不需要实时处理的数据转移到数据仓库，从而使得操作型数据库系统减轻负担。2.2.2
性能问题的提出在第 1 章讲过基于 CBA 的性能优化策略，这个策略是用来找到成本和性能的最佳平衡点的。性能优化并不意味着片面追求性能的最大化，因为优化是无止境的。我们必须根据业务需求来设定目标，没有目标就不知道何时停止研究更好的解决方案。我们知道，提升应用或者系统的性能是为了给业务带来价值，那么当开始处理性能问题的时候，必须先理解业务问题和需求。在系统分析前，首先向数据库管理员、应用程序开发人员及架构师了解了该经营分析系统的业务情况，如表 2-1 所示，最终确认了目前经营分析系统存在的 6 个性能问题。其中概要部分描述了每个问题的症状，影响范围说明了该问题仅仅存在于某个应用还是影响了整个系统。另外，对每一个性能问题，我们都制订了可量化的目标，例如对编号为“Perf_Load_App”的数据转入问题，我们的量化目标是“数据转入不超过 30 分钟”。在实际的优化过程中由于时间或预算是有限的，所以我们为每个问题排定了优先级。表 2-1
性能问题（业务角度）
Perf_Load_App
数据使用 ETL 日转入，记录数在 500 万条左右，用时超过 2 个小时
数据转入时间不超过 30 分钟
Perf_Customer_App
客户流失分析进行汇总，响应时间超过 10 个小时
响应时间不超过 3 个小时
Perf_ACC_App
账户资费应用对请求的响应时间超过 10 个小时
响应时间不超过 1 个小时
Perf_Data_App
数据质量管理应用响应时间比以前基准测试慢 5 倍
响应时间恢复到以前
Perf_SlowAfterNoon_Sys
每天下午系统响应时间比正常情况慢很多
系统响应时间恢复到正常情况
Perf_SlowDown_Sys
系统逐渐变慢
系统性能稳定
系统分析系统分析方法是指把要解决的性能问题作为一个系统，对系统要素进行综合分析，找出解决问题的可行方案的方法。例如，我们可以把一个性能问题看成系统工程，通过系统目标分析、系统要素分析、系统环境分析、系统资源分析和系统管理分析，可以准确地诊断问题，深刻地揭示问题起因，从而提出满足客户业务需要的解决方案。所谓问题，是现实情况与计划目标或理想状态之间的差距。系统分析的核心内容有两个：其一是进行“诊断”，即找出问题及其原因；其二是“开处方”，即提出解决问题的最可行方案。所谓限定问题，就是要明确问题的本质或特性、问题存在范围和影响程度、问题产生的时间和环境、问题的症状和原因等。限定问题是系统分析中关键的一步，因为如果“诊断”出错，以后开的“处方”就不可能对症下药。在限定问题时，要注意区别症状和问题，探讨问题原因不能先入为主，同时要判别哪些是局部问题，哪些是整体问题。另外，为了降低问题之间的连带作用，建议每次只解决一个问题。针对每个问题，进行系统分析，即首先必须确定时间花在何处，其次确定时间是如何被消耗的，例如多少时间花在了 CPU 上、多少时间花在了 I/O 上。但是要注意，由于问题之间有时总会有连带效应，有时候修复一个问题会带来新的问题，反之也有可能修复一个问题也会修复另一个问题。对此连带效应，需要在系统分析的时候加以考虑，特别是在调整后需要通过测试来验证调整效果。就这个案例来说，完成业务分析后接下来需要弄清楚整个系统的情况，这包括存储、主机、操作系统以及数据库服务器。建议读者在进行系统分析的时候，要多和系统管理员、网络管理员及 DBA 进行沟通，尽量全面地收集信息以方便问题的定位。另外，由于 DB2 数据库只是整个企业应用系统的一部分，所以如果条件允许，也应该向应用开发人员了解一些上层应用系统的情况。2.3.1
硬件和操作系统如图 2-2 所示，该经营分析系统的存储使用了 1 台 TS3500 和 2 台 DS5300。其中，TS3500 磁带库用于数据库备份，DS5300 用于存放数据。存储划分是这样的：每台 DS5300 有 16 个磁盘扩展柜，每个扩展柜有 16 个硬盘，分成 2 个 7 ＋ 1 的 RAID 5。主机包括 1 台 P6-520 和 2 台 P6-570。P6-520 配置为 4 CPU，16GB 内存；P6-570 的配置为 16CPU，128GB 内存。主机的操作系统是 AIX 6.1，安装有 DB2 V9.5 for AIX 企业版数据库。所有的主机和存储通过 2 台 SAN 交换机相连。每台 p6-570 或 P6-520 上安装有 2 块 HBA 卡，分别连接 2 台 SAN 交换机，其中 1 块 HBA 卡、或者 1 个 SAN 交换机发生故障时，通过另一块实现 HBA 卡切换。图 2-2
硬件结构图（）系统配置细节如表 2-2 所示。表 2-2
硬件配置列表
存储及规划
磁盘阵列 A
16 个磁盘扩展柜。每个扩展柜有 16 个硬盘，分成 2 个 7 ＋ 1 的 RAID 5
磁盘阵列 B
16 个磁盘扩展柜。每个扩展柜有 16 个硬盘，分成 2 个 7 ＋ 1 的 RAID 5
SAN 交换机 A
Catalyst 6509
用于建立存储网络
SAN 交换机 B
Catalyst 6509
用于建立存储网络
DB2 管理节点
4CPU,4.7GHZ,16GB Mem
DB2 数据节点 A
16CPU,4.2GHZ,128GB Mem
DB2 数据节点 B
16CPU,4.2GHZ,128GB Mem
DB2 V9.5 for AIX
数据库物理设计如图 2-3 所示，经营分析系统的数据仓库构建在上述的 1 台 P6 520 和 2 台 P6 570 上。P6 520 作为管理节点，P6 570 作为数据节点。由于每台 P6 570 有 16 颗 CPU，因此设计逻辑节点为每台机器 16 个数据节点，一共 32 个数据节点。图 2-3
数据仓库物理部署图（）数据仓库中表的 PAGESIZE 使用 32KB，DPF 的 32 个数据分区按照 Single，AllPart 和 IBMTEMPGROUP 三个分区组组成。数据和索引放在不同的表空间上。Single 分区组下面的 Single 和 Single_index 分别用来存放不需要分区的小表以及其上的索引。分区组 AllPart 下面的表空间和索引表空间用来存放需要分区的大表以及其上的索引。分区组 IBMTEMPGROUP 跨所有 32 个节点，用来存放用户临时表空间和系统临时表空间。DB 和 DBM 参数都是使用 DB2 AUTOCONFIGURE 命令自动配置，另外 DBA 也做了一些经验调整。DB2 的环境变量采用系统默认。关于 DPF 分区和表空间配置细节如表 2-3 所示。表 2-3
数据仓库分区和表空间
表空间类型
Single_index
App1_index
App … _index
AppN_index
IBMTEMPGROUP
系统临时表空间
用户临时表空间
使用 DB2 AUTOCONFIGURE 命令配置 + DBA 经验参数配置
使用 DB2 AUTOCONFIGURE 命令配置 + DBA 经验参数配置
DB2 环境变量
分析结果了解了软硬件以及数据库系统现状后，接下来对 2.2.2 节提出的每一个问题进行系统分析，最终确定时间花在了何处以及是如何消耗的。如表 2-4 所示的“系统分析”列说明了每一个性能问题产生的原因，从而确定了时间是如何被消耗的。表 2-4
性能问题（系统角度）
Perf_Load_App
目前数据转入机制是从操作型数据源中提取数据，执行数据清理和转换，再使用 DB2 LOAD 加载海量数据到数据节点，I/O 吞吐量巨大是导致性能问题的原因。
另外目标表存在主外键约束并建有索引
Perf_Customer_App
该应用用到的表很多，有 1000 多张，而且有大数据表之间的连接，以及诸如 AVG、SUM 之类的聚类计算
Perf_ACC_App
该应用用到的表较少，仅 30 张表，但每张表都使用了 DPF，平均记录数在 10 亿条以上，分布在 32 个数据节点上
Perf_Data_App
该应用使用到的表很少，仅 8 张表，每张表都使用了 DPF，平均记录数在 5 亿条以上，分布在 32 个数据节点上。
另外使用了 Order By，需要做大量的排序工作
Perf_SlowAfterNoon_Sys
下午系统的业务负载情况和上午完全一致，但每天下午响应时间快速变慢，说明后台有高 CPU 使用率的进程运行
Perf_SlowDown_Sys
硬件（存储、主机）一切正常；数据库物理设计（表空间、缓冲池）没有问题。CPU 利用率和 I/O 吞吐都在正常范围内
制订优化计划2.4.1
优化计划安排上一节使用系统分析的方法确定了优化策略，接下来就到了制订优化计划的时候了。我们基于如下的原则来制订优化计划：
按照优先级从高到低的顺序。
在优先级一样的情况下，按照影响范围从系统到应用的顺序。
迭代使用 PAT 方法学，逐次逐步优化每一个性能问题。从实战的角度来看，尽管 Perf_SlowDown_Sys 造成的影响是系统范围，但是由于具有最低的优先级，所以放在最后。另外对于不同问题间的连带效用，需要预留一定的缓冲时间做测试验证。如表 2-5 所示为我们制定的该经营分析系统性能问题的优化时间表。表 2-5
优化时间表
Perf_SlowAfterNoon_Sys
Perf_Load_App
Perf_Customer_App
Perf_ACC_App
Perf_Data_App
Perf_SlowDown_Sys
实践优化策略完成经营分析系统的业务分析和系统分析后，我们接下来对每一个问题按照本书 1.3.2 节的描述来实践优化策略。在这个案例中，我们对每一个性能问题都将采取下面的四步：
性能优化2.5
使用 PAT 方法根据上一节的优化计划，使用 PAT 优化策略对经营分析系统的 6 个真实案例进行逐一优化。为了防止连带效应，每次只优化一个问题。其中，在优化中所用到的诸如设计、配置及监控的技术细节都可以在本书的后续章节找到，为了方便读者阅读，我们给出了这些技术所在的具体章节。2.5.1
优化“每天下午系统响应慢”问题（Perf_SlowAfterNoon_Sys）此问题由于 CPU 瓶颈导致，如图 2-4 所示，查找 PAT 树，按照下面的步骤优化：图 2-4 “每天下午系统响应慢”PAT 分析树1. 问题监控。首先通过管理视图等工具排除了高成本 SQL 语句的问题，随后通过下面的方法确认性能问题的原因，即 LOAD 例程每天下午 1 点都会被用户 johnh 调度执行。
使用“db2pd – edus”找到 CPU 使用率最高的线程 17
ID TID Kernel TID EDU Name USR (s) SYS (s)
10227 db2agent (DS2) 2..
10226 db2lfr (DS2) 0..
10225 db2loggw (DS2) 1..
10224 db2loggr (DS2) 2..
10214 db2agent (DS2) 29..
使用“db2pd – db edwdata – applications”找到与线程 17 相应的后台进程
Address App-[nod-index] Num-Coor-Status L-Anch-L-Stmt-Appid
HandlAgents EDUID ID UID
0x20A55FD0 12 [000-0 ConnectCompleted 0 0 *LOCAL.DB2.
0x20A0-0 ConnectCompleted 0 0 *LOCAL.DB2.
0x20A06C00 8 [000-0 ConnectCompleted 0 0 *LOCAL.DB2.
0x20A0-0 PerformingLoad 937 1 *LOCAL.johnh.2. 配置检查：正常。3. 设计检查：LOAD 例程调度时间错误导致系统性能降低。4. 性能优化。找到原因后，就可以非常容易地解决问题了。数据库管理员可以通过下面的方法解决：（1）使用工作负载管理来管理 LOAD 例程，这可以参考本书工作负载管理设计的相关内容（6.4 节）。（2）另外一个权宜之计是将 LOAD 例程安排在业务负载不太繁忙的时间段，例如凌晨左右。2.5.2
优化“大数据转入”问题（Perf_Load_App）此问题由数据转入设计不良导致，首先进行配置检查，随后重新设计数据转入方式：1. 问题监控：存在 I/O 瓶颈。2. 配置检查：检查了 DB 参数 NUM_IOSERVERS 和 NUM_IOCLEANERS，发现一切正常。3. 设计检查：数据转入设计不好导致性能低下。4. 性能优化。考虑到数据日转入的记录数在 500 万条左右、用时超过 2 个小时，采取如下措施：（1）使用表分区加速大数据量的日转入。有关表分区（Table Partition）的内容，请参考本书 3.4 节表分区设计的相关内容。使用表分区的语句如下所示： CREATE TABLE NewDayRecords
// 创建空的 staging 表
LOAD/Insert into NewDayRecords
// 对 NewDayRecords 执行 ETL
// 极快的操作，不需要数据移动，稍后完成索引的维护
ALTER TABLE CDR_Table ATTACH PARTITION STARTING '01/01/2011
'ENDING '01/02/2011'FROM TABLE NewDayRecords
SET INTEGRITY FOR CDR_Table
// 验证数据
// 新数据变成可视（2）加载时将主外键或相关索引删除，加载完成后重建相关键以及索引，对主外键约束尽量通过加载程序来保证它的数据完整性。这一点往往会被大家忽略，为了提高加载效率，需要在真正加载数据前检查一下所有表的索引状态及主外键约束。2.5.3
优化“客户流失分析”问题（Perf_Customer_App）此问题存在 CPU 瓶颈，如图 2-5 所示，查找 PAT 树，按照下面的步骤优化：图 2-5 “客户流失分析”PAT 分析树1. 问题监控。使用下面的语句找到 CPU 代价最高的前 10 条 SQL 语句： SELECT MEMBER,SECTION_TYPE ,varchar(stmt_text,200) as statement,
num_exec_with_metricsas numExec, TOTAL_CPU_TIME/NUM_EXEC_WITH_METRICS
as AVG_CPU_TIME,TOTAL_CPU_TIMEFROM
TABLE(MON_GET_PKG_CACHE_STMT( 'D', NULL, NULL, -2)) as T
WHERE T.NUM_EXEC_WITH_METRICS && 0
ORDER BY AVG_CPU_TIME
descfetch first 10 rows only发现涉及的都是大数据量的表，而且有多表之间的连接，以及诸如 AVG，SUM 之类的聚类计算。2. 配置检查：正常。3. 设计检查：高耗时 SQL 语句设计不良。4. 性能优化。找到原因后，如图 2-6 所示，查找 PAT 树来解决问题。数据库管理员可以通过下面的方法解决：（1）首先使用 visual Explain 或者 db2exfmt 来分析这些高代价 SQL 语句。（2）随后使用 Design Advisor 工具来重新设计这些 SQL 语句。（3）最后该性能问题通过更改索引、使用 MQT 表成功解决。关于 MQT 的相关内容，请参考 3.6 节。图 2-6 “客户流失分析”问题 SQL 优化（）2.5.4
优化“账户资费”问题（Perf_ACC_App）根据系统分析的结果，性能问题是由于磁盘瓶颈导致的，如图 2-7 所示，查找 PAT 树，按照下面的步骤优化：1. 问题监控。1）找到热表查询 syscat.tables 和 sysibmadm.snaptab，查看当前表空间活跃程度比其他要高很多的表，从而确定热表。在本例中，我们确定了欠费账户信息表 DWD_ACC_OWE_ITEM 具有最高的活跃度。 CREATE TABLE "BI"."DWD_ACC_OWE_ITEM" (
"BILLING_CYCLE_ID" VARCHAR(6) ,
"BILL_DTL_ID" DECIMAL(15,0) ,
"DEFAULT_ACCT_ID" DECIMAL(9,0) ,
"ACCT_ID" DECIMAL(9,0) ,
"USER_ID" DECIMAL(9,0) ,
"SVC_NUM" VARCHAR(64) ,
"AREA_ID" VARCHAR(3) ,
"ETL_TIME" TIMESTAMP ,
"ETL_DATA_CYCLE" DATE )
COMPRESS YES
DISTRIBUTE BY HASH("USER_ID")
INDEX IN "TBS_INDEX"
ORGANIZE BY (
( "BILLING_CYCLE_ID" ) )图 2-7 “账户资费”PAT 分析树2）热表中数据在各个分区分布不均匀根据图 2-8 所示的 PAT 树搜索路径，确认了具有 10 亿条记录以上的欠费账户信息表 DWD_ACC_OWE_ITEM 存在数据分布不均匀的问题。下面是查找该表在 32 个节点上数据分布所使用的语句： select DBPARTITIONNUM,SUM(DATA_OBJECT_L_SIZE) lszkb,
SUM(DATA_OBJECT_P_SIZE),pszkb,
SUM(INDEX_OBJECT_P_SIZE) iszkb
from TABLE
(SYSPROC.ADMIN_GET_TAB_INFO_V95('BI', 'DWD_ACC_OWE_ITEM')) AS T
GROUP BY DBPARTITIONNUM
ORDER BY DBPARTITIONNUM2. 配置检查：正常。3. 设计检查：经过分析该表发现，开始设计账户欠费信息表（DWD_ACC_ OWE_ITEM）的时候认为，每个账户都会有一个关联的用户。但是后来由于历史数据被导入，导致很多账户没有对应的用户。反映在表设计上就是，DWD_ACC_OWE_ITEM 是按照 user_id 字段做 DPF 的 hash key，但是历史数据导入后发现有相当一部分记录的 user_id 为 0。关于 DPF 相关内容，请参考本书 3.5 节。4. 性能优化。在 2.3.3 节我们分析过这个问题，现在发现其实是当初业务的问题，所以采用重新设计 hash key。最后，改用了 acct_id 作为 hash key 解决了这个问题。图 2-8
确认数据分布不均匀问题2.5.5
优化“数据质量管理”问题（Perf_Data_App）在 2.3.3 节对该问题判断为内存瓶颈引起，下面我们根据图 2-9 所示的 PAT 树搜索路径来定位并解决问题。图 2-9 “数据质量管理”PAT 分析树1. 问题监控。使用 vmstat 和 ps 工具监控“数据质量管理”应用的资源利用率情况，发现数据库内存的使用要远超越以前的基准。2. 配置检查。获取 DB 的配置参数，发现 SELF_TUNNING_MEM 的设定是 OFF。3. 设计检查：正常。4. 性能优化。综合起来看，响应时间变慢是由于大量排序导致的，而这种大量排序必然会对内存有大量的需求。另外，由于该经营分析系统是从 DB2 8 升级而来，数据库管理员没有激活 STMM，导致有大量排序发生时，数据库系统无法使用 STMM 的自调整功能；但为什么以前的基准测试数据的性能表现不错呢？后来对该问题涉及的 8 张表进行了历史调查，发现这些表原先建有索引，排序的时候可以使用索引扫描（Index Scan），后来由于应用升级，这些索引忘记重建。最后，我们通过下面的方法成功地解决了该性能问题。（1）重建索引。（2）激活 STMM。2.5.6
优化“系统逐渐变慢”问题（Perf_SlowDown_Sys）该问题比较棘手，需要用系统化的方法解决，即对图 2-10 所示的 PAT 树进行一次自上而下、自左而右的搜索即可。图 2-10 “懒惰系统”PAT 分析树（）1. 问题监控。1）系统内部存在明显的锁等待问题。在系统正常负载下，首先通过下面语句从 snapdb 中获得锁的使用情况，发现目前系统中有 51 次锁等待发生。 SELECT LOCKS_HELD, LOCK_WAITS, LOCK_WAIT_TIME, DEADLOCKS,LOCK_ESCALS,
LOCKS_WAITING,LOCK_TIM EOUTS, INT_DEADLOCK_ROLLBACKS
FROM SYSIBMADM.SNAPDB
输出结果如下：
SNAPDBLOCKS_HELD LOCK_WAITS LOCK_WAIT_TIME DEADLOCKS LOCK_ESCALS LOCKS_WAITING
LOCK_TIMEOUTS NT_DEADLOCK_ROLLBACKS
------------------------------------------------------
接下来再从 SYSIBMADM.LOCKWAITS 中获得锁等待的详细信息
DWD_CUSTOMER_BUSINESS_DATA
SELECT SUBSTR(TABSCHEMA,1,8) AS TABSCHEMA,
SUBSTR(TABNAME,1,15) AS TABNAME,
LOCK_OBJECT_TYPE,
LOCK_MODE,
LOCK_MODE_REQUESTED,
AGENT_ID_HOLDING_LK
FROM SYSIBMADM.LOCKWAITS;
TABSCHEMA TABNAME LOCK_OBJECT_TYPE LOCK_MODE LOCK_MODE_REQUESTED
AGENT_ID_HOLDING_LK
--------------------------------------------------------
EDW DWD_CUSTOMER_BUSINESS_DATA TABLE_LOCK X S
402）定位引起锁等待的 SQL 语句。可以通过 db2pd 工具和 db2 get snapshot 结合使用来获得引起锁等待的 SQL 语句，在本书第 9 章有相关的详细介绍，所以在此不再详述。2. 配置检查。检查下面的参数配置，作为进行下一步的参考。预取器、清除器有关的 DB 参数： NUM_IOCLEANERS=AUTOMATIC
NUM_IOSERVERS=AUTOMATIC锁有关的 DB 参数： MAXLOCKS=AUTOMATIC
LOCKLIST=AUTOMATICDB2 注册表变量： DB2_EVALUNCOMMITTED=ON
DB2_SKIPINSERTED=ON
DB2_SKIPDELETED=OFF日志配置。其他参数配置正常，但是发现了诊断日志和事务日志写入路径的问题。1）DB2 诊断日志 db2diag.log 存放路径问题。由于经营分析系统采用了多分区环境（DPF），所以 32 个分区通过网络共享 NFS 文件系统来向同一路径写入诊断日志。2）事务日志和数据表空间共享磁盘。获得事务日志存放路径： db2 get db config for edwdata
'path to log files'
Path to log files = /db2fs/EDW/NODE0000/SQL00006/SQLOGDIR/获得数据表空间存放路径： SELECT SUBSTR(TBSP_NAME,1,20) AS TBSP_NAME, INT(TBSP_ID) AS
TBSP_ID,SUBSTR(CONTAINER_NAME,1,45) AS CONTAINER_NAME FROM
SYSIBMADM.CONTAINER_UTILIZATION
TBSP_NAME TBSP_ID CONTAINER_NAME
--------------------------------------------------------------
SYSCATSPACE 0 /db2fs/EDW/NODE0000/ EDWDATA/T0
TEMPSPACE1
1 /db2fs/EDW/NODE0000/ EDWDATA/T0
db2 get db config for edwdata
'path to log files'3. 设计检查。通过代码检查，本例中一些报表和分析类应用的业务逻辑涉及的 SQL 语句非常复杂，而且都在客户端实现，这导致随着数据量的增加，数据库服务器对客户端应用的响应速度在变慢。4. 性能优化。找到了导致系统变慢的原因后，最后我们组合使用下面的方法成功解决了这个棘手的性能问题。1）DB2 诊断日志 db2diag.log 存放路径问题。解决这个问题最简单的办法就是为每个分区指定一个单独的诊断日志路径，并指定一个专门的诊断日志文件。2）事务日志和数据分开存放，不共享磁盘。3）从应用角度，优化引起锁等待的 SQL 语句。例如，对查询语句的 WHERE 子句进行严格的谓词过虑，而不是依赖应用来对返回的大量记录进行处理。例如使用“OPTIMIZE FOR n ROWS”，“FETCH FIRST n ROWS ONLY”，“FOR READ ONLY”，“FOR FETCH ONLY”以及“FOR UPDATE”等语句来限定返回记录数。4）从技术角度，优化引起锁等待的 SQL 语句。首先使用 visual Explain 或者 db2exfmt 来分析这些 SQL 语句；随后使用 Design Advisor 工具创建合适的索引。5）除了优化外，本问题还从设计角度进行了必要的处理。由于报表和分析应用的 SQL 语句非常复杂，所以将引起锁等待的这些 SQL 语句通过存储过程实现。这样客户端只需要调用存储过程而无须在应用中硬编码业务逻辑，从而实现了减少响应时间的目标。2.5.7
优化总结现在我们已经使用 PAT 方法学完成了对经营分析系统 6 个性能问题的全部解决。其中所采取的步骤完全一致，只是结果不一样，对应的优化方法不一样。表 2-6 列出了解决上述 6 个问题的结果和优化方法。表 2-6
性能优化表
Perf_SlowAfterNoon_Sys
LOAD 例程启动时间错误
使用工作负载管理调整 LOAD 例程启动时间
Perf_Load_App
数据转入设计不好
使用表分区加速大数据量转入
Perf_Customer_App
高耗时 SQL 语句设计不良
更改索引、使用 MQT 表解决
Perf_ACC_App
表 DWD_ACC_ OWE_ITEM 用于数据库分区的 hash key 设计错误
调整设计，改用 acct_id 作为 hash key
Perf_Data_App
SELF_TUNNING_MEM 的设定为 OFF，即 STMM 没有激活
Perf_SlowDown_Sys
懒惰系统问题，存在明显锁等待
DB2 诊断日志 db2diag.log 存放路径问题；事务日志和数据表空间共享磁盘问题
一些报表和分析类应用的业务逻辑非常复杂而且都在客户端实现，随着数据库中数据量的增加，这些应用的客户端接收到数据库服务器的响应速度在变慢
1）为每个分区指定一个单独的诊断日志路径
2）事务日志和数据分开存放
3）优化引起锁等待的 SQL 语句
4）将一些报表和分析类应用的业务逻辑使用存储过程实现
小结本章以电信金融行业的经营分析系统为例，讲解了如何通过业务分析来确认性能问题，如何通过系统分析来确定性能原因，随后基于业务分析和系统分析的结果来制订优化计划，希望大家能够从中得到一些启发。在实际生产环境中发生性能问题时，问题的原因并不单一，往往比较复杂，使用 PAT 方法就能很好地解决这一难题。本章中，经营分析系统的 6 个真实案例的性能原因就比较复杂，但是我们使用 PAT 四大原则和系统化方法可以很好地加以解决。在后面的章节，读者可以更加清晰地理解 PAT 方法学，它是本书的一个思路，也是数据库性能优化的思想体系。把握了这种思想体系，一定会成为一名出色的“医生”。案例分析总结第 1 章结尾我们看到了启用“PAT 树”的背景是，通信运营商系统性能优化时，在深夜发生崩溃。接下来我们看一看工程师们是如何运用“PAT 树”的。2010 年 4 月 15 日 笔记整理， 地点：北京离最后“回退”时间还有 55 分钟，项目组经过激烈讨论后决定：立即执行“PAT”方案。“PAT”强调的是思路和方法，现在情况紧急且复杂，依靠经验调整会找出一堆“疑似”问题，而冒然在生产系统上“敲敲打打”是极其危险的，这会由于考虑不周引起更严重的后果。于是，急救任务被划分为三组：第一组，安排 David 立即和运营商业务人员、应用开发人员召开会议，从客户管理系统本身来确定性能问题，重新设定每个问题的优化目标及优先级。第二组，派 Chen 和资深运维人员取得联系，对每一个性能问题，从系统角度来分析原因。由于资深运维人员对系统非常熟悉，很快就把性能问题定位到磁盘瓶颈上。第三组，我组织人员对确认的性能问题，按照优先级从高到低，影响范围从系统到应用的顺序进行优化。我先讲述 PAT 优化策略的四个步骤：（1）问题监控；（2）配置检查；（3）设计检查；（4）性能优化。然后在白板上画出与磁盘瓶颈有关的“PAT 树”。“通常对 DB2 这样基于磁盘的数据库来说，磁盘瓶颈是很容易发生的，”我一边讲解，一边在投影仪上放大“PAT 树”。 之前已接受过 PAT 方法培训的运维人员开始执行 PAT 优化第一步——收集磁盘瓶颈子树中不同路径的监控信息，然后将收集的报告“架”在这棵树上。很快，问题暴露无遗——客户关系管理应用存在“热表”，而在这些“热表”上存在 costly SQL 语句，这些 costly SQL 语句执行时导致表空间高度活跃而引发磁盘瓶颈。终于找出了根本原因，大家仿佛看到了一丝曙光，精力更加集中起来。David 通过 PAT 优化第二步——配置检查，还发现了事务日志和数据表空间共享磁盘的问题。接着是 PAT 优化第三步：设计检查。“用 DB2 Design Advisor 分析一下这几个 costly SQL 语句，看看是否发起了一个不期望的表扫描，检查一下缓冲池的命中率，”我掰着指头对 Chen 说，“记住，我要的是已经优化好的 SQL 方案！”Chen 久经沙场，带着他的人迅速完成了所有设计检查工作，并拿出一个通过安全测试的优化方案。我通知运维人员，启动第四步——性能优化操作。他们与 3 位 DBA 按照新的优化方案，开始执行优化操作，包括：调整事务日志的存放路径；增大缓冲区大小；建立索引避免执行那些 costly SQL 时启用表扫描；最后使用 DB2 物化查询表（MQT）技术进一步加速这些 costly SQL 的执行速度。经过漫长的等待，DBA 告知方案操作完成，小白带着测试小组立刻启动测试。过了一段时间，终于听到小白在那边喊起来：“PASS ！全都 PASS 了！”几个层面的测试都宣告成功，大厅里欢呼声一片。下楼时研发工程师出身的 Chen 小声对我说：“这个数据库的逻辑设计很糟糕，今天这颗定时炸弹爆炸了。”我迈着沉重的脚步走出大楼，这时天已经亮了。我仍然没有停止思考，上车后又开始揣摩逻辑设计上的问题。
参考资料 在 ，了解关于信息管理的更多信息。查找技术文档、操作文章、培训、下载、产品信息等信息。阅读本书的 。阅读本书的 。更多推荐书籍，请访问 。通过 Information Management 专区 ，了解 IBM DB2 产品家族的更多产品信息和相关技术。
通过访问 ，了解 DB2 9.7 的新特性概述和使用方法随时关注 developerWorks 和 。现在可以免费使用 DB2 。下载 ，这是为社区提供的 DB2 Express Edition 的免费版本，它提供了与 DB2 Express Edition 相同的核心数据特性，为构建和部署应用程序奠定了坚实的基础。下载 ，体验它们强大的功能。参与 并加入 ，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
developerWorks: 登录
标有星（*）号的字段是必填字段。
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
选择您的昵称
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。
您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
标有星（*）号的字段是必填字段。
(昵称长度在 3 至 31 个字符之间)
单击提交则表示您同意developerWorks 的条款和条件。 .
所有提交的信息确保安全。
IBM PureSystems(TM) 系列解决方案是一个专家集成系统
通过学习路线图系统掌握软件开发技能
软件下载、试用版及云计算
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=Information ManagementArticleID=656825ArticleTitle=developerWorks 图书频道: DB2 设计与性能优化 -- 原理、方法与实践，第 2 章publish-date=}