MQT在DB2数据库性能优化中的应用

合集下载

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

精彩节摘
9.3如何定位及修复内存泄漏
在怀疑遇到内存泄漏的问题之前，必须谨慎地判断当前数据库中是否真实存在内存泄漏。判断数据库中存在内存泄漏时需要注意以下几点：
系统中的内存在逐渐减少，甚至导致换页（paging）；
SQL语句越来越慢（经常是换页导致）；
随着时间增长，由DB2分配的内存在不断增加。
第3篇性能分析及内部原理剖析
第4章对优化器的原理进行了探讨，阐述了优化器的重写机制、优化原理及编译原理，并介绍了如何检查优化器的估算结果的两种方法。
谢谢观看
并在DB2China数据库论坛担任热点讨论版块版主，主持多次热点讨论以及专家现场诊断，擅长DB2数据库及相关产品的性能调优及故障分析，对DB2技能及实践经验有多年积累。
近年来多位业界专家一直在积极推动DB2领域的技术交流，真正理解DB2技术人员真正的需求与痛楚，是DB2 系统知识及技巧精髓的热心分享者及贡献者。
而我本人正是一名数据的信徒，多年来在著书、培训、咨询和管理等多项工作中，始终在数据的海洋中忘我与痴迷。在受邀为本书作序之时，我回想起五年前正埋头于写作的我。那时，每日工作繁忙，仍笔耕不辍，把之前在数据库领域的各项工作中所获得的技术积累、经验总结都尽可能地通过文字展现给读者。自认为写数据库的书很苦，写DB2的书更苦，在出版多部著作之后，我对优秀数据库著作的评判标准，可以套用新闻界的行话： “如果事件报道得不够好，那是因为离得不够近”。
在常见的数据库问题中，性能问题不仅出现的频率较高并且很多生产系统中并不存在一个对性能问题进行隔离的高可用机制，正因为如此，在很多关键行业的系统中，性能问题往往成为影响生产系统正常运行的最大因素。而性能问题的影响时间有时长达数小时，这样不仅给生产系统带来了极大的负面影响，也使业务很难正常进行。

DB2 数据仓库性能_光环大数据培训

DB2 数据仓库性能_光环大数据培训光环大数据培训机构，在前一期 IBM Database Magazine 中，本专栏的第 1 部分从系统和数据库的角度讨论了 IBM DB2 数据仓库性能管理。

在本期中，我将针对 SQL 语句级性能调优提供一些建议。

首要问题：选择目标在进行查询调优时，不但要追求良好的性能，还要确保做正确的事。

您很可能希望先调整长时间运行的查询，但是这些查询不一定是“问题” 查询。

如果一个查询会频繁地执行，而且用户期望包含它的过程在一两秒内完成，那么即使它的运行时间只有 10 秒，也会引起用户的抱怨。

对于判断什么地方最需要调优，最好的依据往往是“用户的声音”。

如果用户没有什么抱怨，那么可以花时间调整那些运行时间（和/或 CPU 时间）长和执行频率高的查询。

市场上有一些工具可以帮助选择查询调优目标（IBM 提供的产品包括 DB2 Query Monitor for z/OS和 DB2 Performance Expert for Linux, UNIX, and Windows）。

但是，可以从 DB2 本身获得有助于选择查询调优目标的信息。

大型机管理员应该使用 EXPLAIN 语句的 STMTCACHE ALL 选项（这是在 DB2 for z/OS V9 中引入的，对于 V8 通过 APAR PQ88073 补丁提供）。

对于动态语句缓存中的每个 SQL 语句，EXPLAIN STMTCACHE ALL 会在 DSN_STATEMENT_CACHE_TABLE 中插入一行。

在DSN_STATEMENT_CACHE_TABLE 中的 40 多列中，记录了查询的语句文本、累积的流逝时间、累积的 CPU 时间和执行次数等信息。

这些信息应该有助于寻找可能产生良好的性能调优效果的语句。

在 Linux、UNIX 和 Windows (LUW) 上，DB2 管理员可以使用 DB2 9 引入的管理视图（这些视图的高层限定词是 SYSIBMADM；可以通过 DB2 9 for LUW System Monitoring Guide and Reference了解这些视图）。

DB2 最佳实践-性能调优和问题诊断最佳实践

DB2 最佳实践: 性能调优和问题诊断最佳实践，第1 部分性能调优从配置和监控开始2009 年 3 月12 日本系列介绍了DB2 系统性能的最优方法，分两部分。

第一部分首先介绍为了达到良好性能，我们如何从软硬件配置方面来保障，紧接着讨论了在多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。

第 2 部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。

内容提要大多数DB2 系统都经过了性能的演变。

首先，不论出于硬件还是软件的观点，该系统首先要能被配置。

在多数情况下，这将成为系统在实施后如何运行的基础。

其次，系统一经发布，勤勉的数据库管理员（DBA）将监控系统的性能，来监测任何可能的开发问题。

如果发现任何问题，我们就进入下一个阶段- 故障诊断阶段。

每个阶段都是基于上一阶段，如果没有适当的准备，我们极有可能需要处理比较困难的问题。

本文介绍了DB2 系统性能的最优方法。

我首先涉及到一些有助于我们确保良好软硬件性能的重要原则。

然后我们讨论多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。

最后，尽管我们做了最好的准备，性能问题仍然可以降临到我们身上，我们讨论如何逐步地处理它们，并有条不紊的进行。

回页首简介任何形式的性能问题都将严重影响并降低一个系统对你组织的价值、削弱业务能力、服务中断、以及增加管理开销。

所有这些都会提升总的拥有成本。

缺乏对系统配置的基本原则，监视和性能故障诊断可能导致不同程度的性能低下，并且降低对于组织的价值。

因此，在前期花些时间去考虑基本的配置指导方针和建立健全的系统监控这样的做法，将使你对处理许多可能出现的典型性能问题，有充分的准备。

并使数据服务器得以高性能运行，以提高投资回报率。

回页首第一步：从配置上实现性能良好像InfoSphere 平衡的仓库（BW）这类的DB2 部署类型，或者那些在SAP 系统之内的系统，配置都是高度确定的。

在BW 案例中，像CPU 个数、内存对 CPU 的比率、硬盘的个数和配置这样的硬件因素，以及在预先指定版本的基础上，详尽的测试，以确定最优配置。

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数据库性能优化中，⼗个共性问题及难点的处理经验为了帮助⼤家更好地进⾏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数据库的使用经验，该文提出采用数据库技术解决软件性能问题的一些思路、原则和方法等。

关键词：db2；软件性能；数据库优化；优化方案中图分类号：f426.21 文献标识码：a 文章编号：1009-3044（2013）04-0671-03performance optimizations of db2 in application software ma qiu-hui（quality dept. ，but’one information corporation， xi’an 710043，china）abstract： this article gives some ideas， principles and methods to solve software performance issues by the specific case and the db2 database using experience.key words： db2； performance of software； database optimization； solution of optimization我公司为某煤炭集团开发了企业运销管理信息系统。

系统采用j2ee体系架构jsp+javabean+servlet三层结构实现，运行于websphere应用容器之上，使用db2数据库存储信息。

系统功能包括：调拨管理、发运管理、地销管理、结算管理、统计管理、市场运营、系统维护等13个功能模块，覆盖20多个部门日常业务，是一套符合客户其业务流程、切合其自身需要、充分发挥其营销优势、量身定制的信息化系统。

系统使用13个月后，随着客户业务量的猛增，软件终端的使用人数从最初的100人迅速增到300人，并仍在继续增加。

软件在上线之前已经通过功能性能测试，并保留有一定的冗余量。

DB2优化工具使用

DB2优化工具使用DB2提供了多种数据库优化工具，包括db2advis（设计顾问程序）、Visual Explain、db2exfmt、db2expln数据库优化工作最头疼的事情是什么？个人认为:一．没有具体的量化指标(这里指执行sql的开销,包括CPU、磁盘I/O等的开销)，来判断优化的效果。

程序员只能凭sql语句的执行时间和以往的经验来判断优化是否成功。

二．数据库查询优化器的优化结果是否理想，由于sql语句是要经过数据库引擎的查询优化器对sql语句进行重整优化，这一过程是黑盒的，我们无法了解，比如查询条件是否下推？我建立的索引是否被用到？sql语句执行的是全表扫描还是索引扫描？这些怎么确定是一个关键问题。

三．对于业务系统需求经常变更的应用系统，怎么从全局角度把握数据库的优化，在运行阶段可能做过优化工作，但是随着业务的变更，以前做的优化工作变的无效了，怎么重新优化？IBM为我们提供的这几款工具为使我们能够对这些开销的具体数据有全面的了解，了解查询优化器优化后的结果，全局角度了解目前业务系统的优化状况，从而制定优化目标。

以上是个人的一点感受，下面切入正题，go.一． db2advis（设计顾问程序）的使用设计顾问程序有命令行模式的db2advis，也有图形化界面的设计顾问程序。

需要注意的是图形化界面的设计顾问程序依赖于db2advis，如果没有建立过执行计划表的话，先要建立执行计划表，需要在相应数据库里执行 EXPLAIN.DDL,命令如下db2cmd 进入DB2CLPdb2 connect to <dbname> user <username> using <password> db2 -tf $INSTHOME\sqllib\misc\EXPLAIN.DDL如下图:执行完后会在数据库中看到建立的执行计划表接着就是在DB2CLP中执行db2advis命令,db2advis -d <dbname> -n <schema name>–m I –s "sql stmt" –t <time> -a <username>/<password> -o <filename>这里解释一下上面的参数–d 数据库名称或数据库别名–m 执行优化的类型(I 索引 M MQT物化查询表 C 多维集群 P 分区)-n schema name-a 数据库用户名和密码-s 要执行的sql-o 将结果保存到文件中 (注意-o只给出了优化方案,并没给出开销和性能提升的百分比,可以不用这个而在最后加上 >xxx.txt 来包结果输出到文本中)详细的参数可以在DB2CLP中输入 db2advis 命令查看以下是一个执行的例子:db2advis -d cs -n db2inst1 -m I -s "selectbp.id,bc.brand_code,cb.brand_name,bbp.id as b_id,sbp.id as s_id, sbp.plan_amount1 as ssg,sc.sg as sg ,sbp.is_normal1s_is1,bbp.plan_amount1 as bsg, sbp.plan_amount2 as szg,sc.zg as zg ,sbp.is_normal2 s_is2,bbp.plan_amount2 as bzg,sbp.plan_amount3 as sxl,sc.xl as xl ,sbp.is_normal3s_is3,bbp.plan_amount3 as bxl, sbp.plan_amount4 assscfe,sc.scfe as scf ,sbp.is_normal4 s_is4,bbp.plan_amount4 as bscfe,case when coalesce(h.OCT_LOWER_LIMIT,0)>0 or coalesce(h.OCT_UPPER_LIMIT,0)>0 then case whencoalesce(sc.sg,0)<h.OCT_LOWER_LIMIT or coalesce(sc.sg,0)> h.OCT_UPPER_LIMIT then '否' else '是' end whencoalesce(h.OCT_LOWER_LIMIT,0)>0 then case whencoalesce(sc.sg,0)<h.OCT_LOWER_LIMIT then '否' else '是' end else '是' end as sg_is_good,case whencoalesce(h.REP_LOWER_LIMIT,0)>0 orcoalesce(h.REP_UPPER_LIMIT,0)>0 then case whencoalesce(sc.zg,0)<h.REP_LOWER_LIMIT or coalesce(sc.zg,0)> h.REP_UPPER_LIMIT then '否' else '是' end whencoalesce(h.REP_LOWER_LIMIT,0)>0 then case whencoalesce(sc.zg,0)<h.REP_LOWER_LIMIT then '否' else '是' end else '是' end as zg_is_good,case whencoalesce(h.SALE_LOWER_LIMIT,0)>0 orcoalesce(h.SALE_UPPER_LIMIT,0)>0 then case whencoalesce(sc.xl,0)<h.SALE_LOWER_LIMIT or coalesce(sc.xl,0)> h.SALE_UPPER_LIMIT then '否' else '是' end whencoalesce(h.SALE_LOWER_LIMIT,0)>0 then case whencoalesce(sc.xl,0)<h.SALE_LOWER_LIMIT then '否' else '是' end else '是' end as xl_is_good,case whencoalesce(h.MARKER_LOWER_LIMIT,0)>0 orcoalesce(h.MARKER_UPPER_LIMIT,0)>0 then case whencoalesce(sc.scfe,0)<h.MARKER_LOWER_LIMIT orcoalesce(sc.scfe,0)> h.MARKER_UPPER_LIMIT then '否' else '是' end when coalesce(h.MARKER_LOWER_LIMIT,0)>0 then case when coalesce(sc.scfe,0)<h.MARKER_LOWER_LIMIT then '否'else '是' end else '是' end asscf_is_good,cb.BRAND_TRADEMARK,i.count2,rate2,decimal(hhh.a _amt,18,2),iii.zyrate,bbp.plan_sghs,bbp.plan_zghs Fromdb2inst1.work135_person_plan bp left join ( selectv.person_code,mb.brand_code fromdb2inst1.v_work135_manager_person_relation v left joindb2inst1.work135_person_plan p on _code = _code and p.person_code = v.manager_code left joindb2inst1.work135_sale_attention_brand mb on mb.plan_id = p.id where _code='11652901' and v.type_code='SALE' andv.person_code='29000092' and plan_type=30 and year=2011 and month=12 union select cb.person_code,cb.brand_code fromdb2inst1.work135_sale_attention_brand cb where cb.plan_id = '1000011121900003733' ) bc on bp.person_code =bc.person_code left join db2inst1.work135_brand_plan bbp on bbp.plan_id = bp.id and bbp.brand_code = bc.brand_code left join db2inst1.work135_person_plan sp on sp.person_code = bp.person_code and sp.year = 2011 and sp.month = 11 and sp.plan_type = bp.plan_type left joindb2inst1.work135_brand_plan sbp on sp.id = sbp.plan_id and sbp.brand_code = bc.brand_code left joindb2inst1.WORK135_BRAND_MONTH_ACCOUNT sc on sc.person_code =bp.person_code and sc.brand_code = bc.brand_code and sc.year = 2011 and sc.month = 11 left join _brand cb on cb.brand_code = bc.brand_code left joinDB2INST1.V_WORK135_MANAGER_PERSON_RELATION g onbp.PERSON_CODE=g.PERSON_CODE left joinDB2INST1.WORK135_THRESHOLD_brand h onh.PERSON_CODE=g.MANAGER_CODE and bc.brand_code=h.BRAND_CODE left join (select cust_mgr_code,count(distinct a.custom_id) count2 from _customer a left joinDB2INST1.custom_regie_info b on a.custom_id=b.custom_id where current_status not in (4,13) and a.cust_mgr_code is not null and a.cust_mgr_code<>'' and a.cust_mgr_code not like '未知' GROUP BY cust_mgr_code) i on bp.PERSON_CODE=i.cust_mgr_code left join(select cust_mgr_code,brand_code,count(distinct custom_id) rate2 from (selectcust_mgr_code,brand_code,a.custom_id fromDB2INST1.custom_month_account a left join_customer c on a.custom_id=c.custom_id left join DB2INST1.custom_regie_info d on d.custom_id=c.custom_id where a.year= 2011 and a.month = 11 and sale_amount<>0 andcurrent_status not in (4,13)) a group bycust_mgr_code,brand_code) ggg onggg.cust_mgr_code=bc.person_code andggg.brand_code=bc.brand_code left join (selectcust_mgr_code,brand_code,sum(sale_amount) a_amt from (select brand_code,custom_id,sale_amount fromDB2INST1.custom_month_account where year=2011 and month=11) a left join (select * from _customer wherecust_mgr_code is not null and cust_mgr_code<>'' andcust_mgr_code not like '未知') c on a.custom_id=c.custom_id left join DB2INST1.custom_regie_info d ond.custom_id=c.custom_id and sale_amount<>0 and current_status not in (4,13) and c.cust_mgr_code='29000092' group bycust_mgr_code,brand_code) hhh onhhh.cust_mgr_code=bc.person_code andhhh.brand_code=bc.brand_code left join (selecta.cust_mgr_code,brand_code,decimal(decimal(a_amt,18,6)/b_amt*100,18,2) zyrate from (select cust_mgr_code,a.brand_code,sum(sale_amount)a_amt,category_id from DB2INST1.custom_month_account a left join _customer c on a.custom_id=c.custom_id left join DB2INST1.custom_regie_info d on d.custom_id=c.custom_id left join (select a.category_id,brand_code fromDB2INST1.Brand_Category_Set a left joinDB2INST1.Brand_Category b on a.category_id=b.category_id where org_code='11650001') e on a.brand_code=e.brand_code where a.year =2011 and a.month=11 and sale_amount<>0 and current_status not in (4,13) and cust_mgr_code is not null and cust_mgr_code<>'' and cust_mgr_code not like '未知' group by cust_mgr_code,a.brand_code,category_id) a left join (select cust_mgr_code,sum(sale_amount) b_amt,category_id fromDB2INST1.custom_month_account a left join_customer c on a.custom_id=c.custom_id left join DB2INST1.custom_regie_info d on d.custom_id=c.custom_id left join (select a.category_id,brand_code fromDB2INST1.Brand_Category_Set a left joinDB2INST1.Brand_Category b on a.category_id=b.category_id where org_code='11650001') e on a.brand_code=e.brand_code where a.year =2011 and a.month=11 and sale_amount<>0 and current_status not in (4,13) and cust_mgr_code is not null and cust_mgr_code<>'' and cust_mgr_code not like '未知' group by cust_mgr_code,category_id) b ona.cust_mgr_code=b.cust_mgr_code anda.category_id=b.category_id) iii oniii.cust_mgr_code=bc.person_code andiii.brand_code=bc.brand_code where bp.id ='1000011121900003733' and bc.brand_code is not null and bc.person_code='29000092'" -a db2inst1/db2inst1 >1.TXT执行完成后的结果如下图Timeron为执行这个sql语句的总开销,下面是给出的优化建议. 这个太长,下面给个其它语句的执行结果主要列出的是:建议的索引、推荐的索引、没有用到的索引建立建议的索引，对推荐的索引做RUNSTATS来收集信息以便数据库查询优化器来做优化，没用的索引要根据整体情况来看。

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 参数。

优化DB2数据库的十个最佳实践(上)

优化DB2数据库的十个最佳实践(上)结构化查询语言(SQL)对于关系型DBMS是把双刃剑，利弊参半。

因为从关系型数据库检索任何数据都需要SQL，本文所要探讨的话题就是：不论是终端用户还是开发人员或是数据库管理员（DBA），他们将如何访问一个关系型数据库。

当使用高效的SQL 时,系统会变得易于升级、灵活、而且便于管理。

当使用低效的SQL 时, 响应时间和程序运行时间都会延长，并且还会产生应用系统的中断。

鉴于通常的数据库系统一般要花费90% 的处理时间用于从数据库检索数据，由此很明显的可以看出尽可能的保证SQL的高效是多么的重要。

考察通常的SQL 语句问题譬如"SELECT * FROM"仅是冰山一角,我们将在本文中探讨其他容易确定的普遍的问题。

需要记住的是, 检索得到同一数据的SQL 语句有很多种殊途同归的写法，所以不存在好的查询语句或是坏的查询语句，而只有满足适当需求的查询语句。

各关系型数据库都有自己的方式来优化和执行查询语句。

因此，各DBMS都拥有自己的最佳性能的查询技巧。

本文将使用Quest 软件中Quest Central for DB2 的例子和概述来集中讨论DB2 for OS/390 和z/0S。

要是在十七年前，这张技巧单会更长，并且会包含对最小化的SELECT 场景的矫正方法。

每一个新版本的DB2 都会增加成千上万行的新代码，用以扩展智能优化，和查询重写及执行。

例如，多年来一种被称为数据管理器的组件, 通常被提供作为"第一阶段处理"以增加它的过滤容量一百倍。

另一组件是关系型数据服务器，通常被提供作为"第二阶段处理"来进行其主函数的查询重写和优化。

另一关键组件就是基于当前的SQL，并使用存取路径以决定检索数据的DB2 优化器。

DB2 优化器改善了每一个DB2 的版本, 考虑到另外的DB2目录中的统计, 可以提供新的和改善过的存取路径。

OLTP类应用系统之DB2数据库优化最佳实践

OLTP类应用系统之DB2数据库优化最佳实践本文所涉及的优化技巧均建立在您的数据库物理架构已经设计完成后而为了保证您的应用有最佳表现所必须做的后续优化工作。

下面这些有关数据库配置调优的技巧将使您在OLTP 环境中取得非常好的性能，同时使您能够避免显而易见的“陷阱”。

在配置参数中，数据库管理器配置参数需要重新启动数据库管理器，而为了使更改生效，大多数数据库配置参数都要求应用程序重新连接到数据库。

这里要优化的配置参数如下所示：一、配置缓冲池大小缓冲池命中率表明数据库管理器不需要从磁盘装入页（即该页已经在缓冲池中）就能处理页请求的时间百分比。

缓冲池的命中率越高，使用磁盘 I/O 的频率就越低。

按如下计算缓冲池命中率：db2pd -d dbname -bufferpools这个计算考虑了缓冲池高速缓存的所有页（索引和数据）。

理想情况下，该比率应当超过95%，并尽可能接近100%。

要提高缓冲池命中率，请尝试下面这些方法：1) 增加缓冲池大小#db2 "alter bufferpool bpname immediate size 40000"2) 考虑分配多个缓冲池，如果可能的话，为每个经常被访问的大表所属的表空间分配一个缓冲池，为一组小表分配一个缓冲池，然后尝试一下使用不同大小的缓冲池以查看哪种组合会提供最佳性能。

#db2 "create bufferpool bpname SIZE 200 PAGESIZE 8K"如果已分配的内存不能帮助提高性能，那么请避免给缓冲池分配过多的内存。

应当根据取自测试环境的快照信息来决定缓冲池的大小。

二、配置日志缓冲区大小（LOGBUFSZ）LOGBUFSZ 是一个数据库配置参数。

它是用于日志缓冲区的参数。

它允许您指定数据库共享内存的大小以用作在将日志记录写到磁盘之前这些记录的缓冲区。

当下列事件之一发生时会将日志记录写到磁盘：1) 事务提交；2) 日志缓冲区已满；3) 其它某个内部数据库管理器事件发生时。

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数据库设计：取得最佳性能的准则-电脑资料在开发过程的早期作出的很多设计决定对DB2应用程序和数据库的性能有着巨大的影响，。

本文为在z/OS环境中取得更好的性能提供了一些一般性的指南和建议。

一、简介本文的目的是为IBM业务伙伴提供关于DB2 Universal Database?(UDB)for z/OS(后面将简称为DB2)环境中DB2数据库性能的重要信息。

本文试图从多处收集材料，并尽可能有效地将它们表述出来。

本文无意包含很全面的范围，也不会包含很深的细节。

我曾打算讨论对DB2数据库的性能影响最大的一些因素。

但是，并不是所有可能的情形都可以预测到，也不是所有潜在的考虑都能顾及到，更不用说在期望的范围内对它们进行描述了。

我希望本文可以为不同环境下的DB2用户提供一个通用的指南，以帮助他们取得最佳的DB2数据库性能。

本文的目的是成为一个良好的起点，用以处理任何给定安装环境下的数据库性能问题。

本文的范围是数据库设计性能。

DB2性能远不止这一部分，它肯定要受到数据库设计以外的很多因素的影响。

例如，程序的编码逻辑和其中使用的实际的SQL语句，可以列为应用程序设计一类。

DB2系统性能可以包括诸如安装选项、缓冲池大小设置、DB2相关地址空间的调度优先级等等之类的因素。

本文的焦点是DB2数据库的设计。

不过，有时候这些性能因素类别之间的界线可能会有些模糊。

例如，在某种安装环境下进行配置时，缓冲池大小的设置和数量的选择通常被认为是一项系统性能因素。

但是，倘若是将特定的表空间和索引指派给那些缓冲池，那么这些因素又可以看作是数据库设计一类的因素了。

在这里，我假设读者对z/OS环境中的DB2有一个基本的理解。

本文的头几页将讨论性能管理的一些基本概念和准则，以便进行“级别设置” 。

我的建议有点综合的性质，因而不会总是详细地给出技术性的描述和语法。

读者如果想了解关于这些内容的更详细的信息，那么应该去阅读关于用户本地所安装的DB2版本的最近的IBM文档。

DB2性能调节工作总结

DB2性能调节工作总结近期负责了Metric项目的服务器性能维护，对DB2的性能调节做了些研究。

整体感觉数据库调优的关键点应该还是在建库阶段，好的查询更能得到更好的性能。

而后期对数据库参数等的调节结果并不是非常明显的。

网上数据库调节方面的资料也很多，但大多数都是转来转去的，在此只做下我个人的工作总结;（//表示对上诉解释##表示对下面解释）############1,Monitoring##################db2 get database manager monitor switches//显示监视开关的情况db2 update dbm cfg using DFT_MON_BUFPOOL ONDFT_MON_LOCK ONdb2 update dbm cfg using DFT_MON_SORT ONDFT_MON_STMT ONdb2 update dbm cfg using DFT_MON_TABLE ONDFT_MON_UOS ONdb2 terminatedb2stopdb2start//在实例级打开监视开关，这样随着实例的重启，开关生效db2 get database manager monitor switchesdb2 get monitor switches//发现实例级和下面的数据库监视开关都打开了db2 deacivate database tp1db2 activate database tp1//重新激活数据库，刷新监视数据selectagent_id,rows_read,rows_written,rows_selected,rows_inserted from sysibmadm.snapappl//监视每个代理读写查询的情况，如果read的数量远高于select的数量，考虑是不是缺少索引//在我的工作中，很少遇到写多的情况，所以对这方面也没深入db2 get snapshot for tables on tp1 > sntab1.txt//接下来监视tp1数据库下所有表的读写啦##下一步，就是抓到那个有大量读大于写的表，然后提取该表上的查询SQL##这里就要考虑两种情况了，是静态的还是动态的##@@@静态的，从包里提取db2bfd -s sqltp1st.bnd##@@@动态的，可以用snapshot SQL STATEMENT抓取,这里不写了//然后就要提取出我们关注的大量读的查询SQL//我不太喜欢这部，累眼睛，还烦琐!!!如果有大量查询SQL，还需要想办法自己找出db2 describe indexes for table acct show detail//然后就是从提出的SQL中找到表，从表中看有没有索引，没有的话，新建##之后呢，就可以从访问计划中看索引有没有生效##静态SQL可以用db2expln从包里弄，本人比较喜欢db2exfmt,因为动静SQL都可以弄##后面有db2exfmt关于动静的例子,我比较习惯把SQL statement拿出来##然后放进文本里,db2expln -d GTSSTGMS -f SQL.txt -g -z \; -o GTSSTGMS_sort.txt##或者，db2 connect to tp1##db2 set current explain mode explain##db2 set current explain snapshot explain##db2 "select name,address from acct where ......"##db2exfmt -l -d tp1 -o extp2.txt => vi extp2.txt############2,Talespace and I/OPerformance##################db2 select bpname，bufferpoolid,npages,pagesize fromsyscat.bufferpools//查看数据库的缓冲池，syscat.bufferpools中的bufferpoolid 字段和sysibmadm.snapdb_memory_pool//的pool_secondary_id是关联的，从后一张表中记载着用户用户间的缓冲池和系统自建的缓冲池//CURRENT_SIZE 当前大小;POOL_CONFIG_SIZE 设置大小;HIGH_WATERMARK 最高记录;//我发现,这和使用db2pd -db GTSSTGMS -mempools是对应的PhySz PhyUpBnd PhyHWM//使用db2pd -db GTSSTGMS -memset，将同类内存集合并计算//在这里插一段缓冲池自调节功能介绍@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@下面我们创建示例缓冲池MYBP1，其使用自调整功能（注意其create bufferpool语句使用了automatic），初始大小为400K，具体如清单4所示：创建使用自动自调整功能的示例缓冲池MYBP1db2 create bufferpool mybp1 immediate size 100 automatic pagesize 4kdb2 "select BPNAME, NPAGES from sysibm.sysbufferpools"当缓冲池启用了自调整功能时，该特定缓冲池的sysibm.sysbufferpools 表中的NPAGES 字段将设置为-2。

（转）物化查询表简介

（转）物化查询表简介物化查询表（MQT）的定义是以⼀次查询的结果为基础的。

MQT 可以显著提⾼查询的性能。

本⽂将介绍 MQT、总结表（summary）和staging 表，并通过⼀些实⽤的例⼦展⽰如何创建和使⽤物化查询表。

物化查询表（MQT）是⼀种以⼀次查询的结果为基础定义的表。

包含在物化查询表中的数据来⾃定义物化查询表时所基于的⼀个或多个表。

⽽总结表（也称⾃动总结表，AST）对于 IBM® DB2® Universal Database™（UDB）for Linux、 UNIX® 和 Windows®（DB2 UDB）的⽤户来说应该感到⽐较熟悉，它们可以看作是特殊的 MQT。

fullselect 是总结表定义的⼀部分，它包含⼀个 GROUP BY ⼦句，该⼦句总结fullselect 中所引⽤表中的数据。

您可以将 MQT 看作⼀种物化的视图。

视图和 MQT 都是基于⼀个查询来定义的。

每当视图被引⽤时，视图所基于的查询便会运⾏。

但是，MQT 实际上则是将查询结果保存为数据，您可以使⽤ MQT 中的这些数据，⽽不是使⽤底层表中的数据。

物化查询表可以显著提⾼查询的性能，尤其是提⾼复杂查询的性能。

如果优化器确定查询或查询的⼀部分可以⽤⼀个 MQT 来解决，那么就会重写查询，以便利⽤ MQT。

MQT 可以在创建表时定义，或者定义为系统维护的 MQT，或者定义为⽤户维护的 MQT。

下⾯的⼏个⼩节将介绍这两种类型的 MQT，另外再介绍总结表和 staging 表。

后⾯的例⼦要求连接到 SAMPLE 数据库。

如果您系统上还没有创建 SAMPLE 数据库，那么可以通过在命令⾏提⽰符下输⼊ db2sampl 命令来创建这个数据库。

系统维护的 MQT这种物化查询表中的数据是由系统维护的。

当创建这种类型的 MQT 时，可以指定表数据是 REFRESH IMMEDIATE 还是 REFRESH DEFERRED。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

计量辅助系统由应用服务器、数据库服务器以及相关网络等组成。经过排查网络运行情况良好，
应用服务器的性能监控结果显示ＣＵ负载只在Ｐ
从命令的输出可以发现，有条ＳＬ语句的执行Ｑ
２１０２年５月第二期
ｓ．ＥＳＮＤ＝ｓ．ＢｅＹＨ）ｌｔｉｎ２ＰＲＯ＿Ｉ１Ｊ—Ｒｎ —Ｂｅｏｆｉ
ｉｐ．ＢｌｔＪ —ＹｕＳＪｓｎｏｎＧ３ｏ
２存在ＴＢＥＪＯＴＪＹＣＬＹ）ＡＬ：ＬＰ．Ｌ１Ｊｓ的重复扫描，次扫描的成本分别为１９８８和１１２９占两６９．８３．，
ｓＺ１６．３
３关闭ｅｐａ模式）ｘｌｎｉ
ｄ２ｓｔｃｒｅｔｅｐａｎｍｏｅｎｂｅｕｒｎｘｌｄｏｉ
４格式化输出分析结果）
ｄ２ｘｔ—ｄｈｊｔ—ｇ—Ｔ —Ｏｅ＼ｔｐ＼ｅ— ｂｅｆｍｇｘｌ：ｅｍｘ
控发现，ＰＣＵ负载情况（控时间共约７监３个小时）并不正常（图１示）从图中可以看出，天７如所，每：３０到１：０的时间段，据库服务器ＣＵ负载几乎６０数Ｐ为１０非常繁忙，反映的ＣＵ负载也跟实际０％，其Ｐ工作相吻合，白天工作时间段业务交易多，晚问相
ｆｍｌｔＪＹＣＬＹＳｒｉｐ．ＬｉＪ＿ｏｏ
ｗｈｒＷＬｉ｝－Ｆｅｅ皿ＬＨｌｅ ’０％ ’ ｏ Ⅵ ｉｋｒＷｅＤ｜Ｆｌｅ ’ ％ ’ ｉＬ＿Ｈｉｒｋ１
优化方法，立合适的ＭＱ建Ｔ来优化性能，被认为是
对空闲。
图所基于的查询便会运行，但是ＭＴ是把查询的Ｑ结果保存为磁盘上存在的数据，以直接使用ＭＱ可Ｔ
中的这些数据，而不是使用底层表中的数据。正因为这些特点，于数据量大、对经常需要分组统计而数据又不会频繁变更的应用场景中，物化查询表相
Ｗｅ订Ｄ｝ＩＨｉｅ ’ ％ ’ ＬＳｌｋ１
ｇｏｐｂｒｕｙＷＴ—Ｗ＿ＴＨ—ＳｅＤｉＨ）ｓｎｓ．５ｏ１
一Ｗ＿Ｔｅ — ｉ
Ｄ＝ｓＷＴＨ５． —ＷｅＨ—Ｓｉ Ⅱ）Ｈ）ｌｆｉｎｅｏｔｉ（ｅｅｔＷＬＷｌＴ＿ＦｃｕｔＷＬＷｅＴｓｌｃｅＤＨ＿Ｈ，ｏｎ（ｉｉＤＨ＿
ｐｎ．ｘｉｔｔ
ｆｍ（（ｊｐ．＿ＷｅＪＸｌｌｔｏｌｔｒｏ（（ｏｔＷＴｌｉＢＸｓｅｉｊｐ．Ｔｆｊｎｏ
Ｔ—ＰＥＲＳＯＮ２ｏｓｎ
分析输出文件ｅｐｎｔ的内容，ｘｌ．ｔｘ情况反应主要
有以下几点：１ＳＬ的Ｔｔｌｏｔ总成本）达３５３８）Ｑ０ｓａＣ（高７８．。
１把当前会话模式设置为ｅｐａ）ｘｌｎｉ
ｄ２ｓｔｃｒｅｔｅｐａｎｍｏｅｅｐａｎｂｅｕｎｘｌｉｄｘｌｉ
Ｎｍｌｓｌ（ＬＪｇ）ａＺ１ｕ，ｎＪｉＺｓＩｕｎｆｍｊｐ．ＪＪＳｒｐｂ＿ＷｅＤｒｏｔＪｉ１ＪｇｕｙＷＴｏｌＬａＪｏｉＨＴ
较可行的方法。
ｇｏｐｂｒｕｙＷＴ— ｉＤＷｅＴＨ—Ｆ ’ ６ｏ１ＷＴＨ）ｓｎｓ． —Ｗ＿Ｔｅ－ｉ
ＤＨ＝ｓＷＴ＿ＷｅＴＤＨ＿Ｆ６．一ｉＨ
３ＭＴ优化设计Ｑ
３１ＭＱ．Ｔ优化查询的关键节点
ｗｅｈｒ１＝１ａｄｓ．＿ｉｕＲ＝０ａｄｓ．Ｂｅｎ１ＷＴｓｅＱ１Ｊ一ｎ
ＭＴ在Ｄ２数据库性能优化中的应用ＱＢ
５
时间比较长，遍执行时间在２以上，ＳＬ语普０秒该Ｑ
句为：
ｓｌｃ１＊，ｓｅｅｔｓ．２．Ｂ ℃Ｈ，ｓＪ —Ｃ３．Ｂ—ＹｎＧ — ｕＳＪ
ＭＣ，４．ｍｌ，４．ｌ，５．ｍ２，５．ＩｓＮｕｓＮｕｓＺｌｓＮｕｓＺ２，６．ｍ３，
到了事半功倍的效果。
关键词：ＢＤ；Ｑ（ａｒｌｅｕｒＴｂ，Ｄ２ＵＢＭＴＭｔｉｉｄｅａｌ物化查询表）性能；ｅａｚＱｙｅ；优化
５％左右，不存在网纲瓶颈和计算资源瓶颈，除并排
了网纲和应用服务器的性能问题。另外利用系统
ＣｈＨ：’Ｙ —２９ｚ４１’
ｏｄｒｂｓｒｅｙ１．ＷｌＷｅＴＩ＿ｉＤＨｓＦｔｈｉ１０ＤｅｃｅｃＦｍｔ０ＲｏＯｎｙｗｌ
仔细分析上述ＳＬ语句，以发现该语句主要Ｑ可由三个子查询的返回结果相关联而成：
比其它性能优化手段更能发挥它的优势。在杭钢计量辅助系统的系统性能优化过程中，手段的应该
用被认为起到了事半功倍的效果。
１应用缘由
杭钢计量辅助系统作为重要的辅助系统，公在
司ＥＰ系统中起到极为重要的作用，Ｒ对于系统交易
ｇｏｐｂ＿ＷｅＤｒｕｙＷＴｉＨ）ｓｎｓ．＿ＷｅＤ＝Ｔ４ｏ１ＷＴｉＨＴＳＷｒ４．ＩＷｅＤｉＨ）ｌｆｉｉＴｅｏｎｔ
（ｅｅｔＷＴ— ｉＤ＿Ｈ，ｏｎ（ —ＷｅＴ＿ｓｌｃＷｅＴＨ＿ＳｃｕｔＷＴｉＤＨ＿
图１优化前数据库服务器ＣＵ负载图Ｐ
２原因分析与系统优化方法
２１原因分析．
要，重影响了用户的业务操作。因而查找系统瓶严
颈所在，取相应措施，采提高计量辅助系统的事务
根据上述ＣＵ和１载情况，步估计系统Ｐ０负初
性能不佳是由于ＳＬ语句引起的。为了分析ＳＬＤ２快照命令：执Ｂ
Ｄ２＝＞ＧＴＳＡＳＯＯＹＡＩＱＢＥＮＰＨＴＦＲＤＮＭＣＳＬ
ＦＲＪｘＯＨＧＬＴ
１）子查询１
ｓｌｔＷＬＷｅＤｅｃｅｉＨ，ｃｕｔ（＿ｉＤ）ａＴｏｎＷＴＷｅＨｓＴ
为进一步定位性能瓶颈所在，要了解该句需
ＳＬ的ＡＣＳＬＮＱＣＥＳＰＡ。详细的ＡＣＳＬＮ通过ＣＥＳＰＡ下述步骤得到（保存在文件ｅｐｎｔ中）ｘｌ．ｔ：ｘ
４
冶舍
２２月二０年５第期１
ＭＱＴ在Ｄ２数据库性能优化中的应用Ｂ
方国洪
（，钢铁集团公司信息管理部杭ｒｌ１杭州３０２）１０２
摘要：在杭钢计量辅助系统优化过程中，通过设计合理的物化查询表ＭＴ提高Ｄ２数据库系统性能，Ｑ，Ｂ达
２子查询２）
ｓｌｃＴｅｅｔＷ＿ＷｅｒＬＳ，ｃｕｔ（＿Ｗｅ皿ｎｉＤ｝＿ＨｏｎＷＴＩｉ
２执行需要分析的ｓｌ）ｑｄ２需要分析的ｓｌＳＬ太长此处省略，上ｂｑ，Ｑ见
ｆｍｏｔＪＪａＪＪｒｏｌｐ．ＬｉＳｎ
３全表扫描的存在。ＴＢＥＪＯＴＪＪＮＪ）ＡＬ：ＬＰ．ＬＩＳＡ的全表扫描（ＢＣＮ）全表扫描会随着表记录数ＴＳＡ，
的增多极其影响系统性能。２２系统优化方法．影响系统性能的问题已经找到后，优化的目标
总成本的比重为（６９．１９８８＋１１２９／７８．８３。）３５３８＝
９５％。３．
ｓ．ＢｕＳＪＨ：ｓ．ＢＹｎＧ—Ｂ１Ｊ＿ＹｎＧ —Ｂ３Ｊ — ｕＳＪＨ）ｌｔｅｆ
ｊｉｏｎ（ｅｃＷＴＷｅＤｃｕｔＷＴＷｅＤｓｌｔｅ — ｉＨ，ｏｎ（ — ｉＨ）ａＴＴｓＮｍｌｓｍ（ＬＪｇ）ａｌｕ，ｕＪ＿ｉＺｓＺｌｎ
数据库管理系统，有Ｍ的功能特性。物化查具询表（Ｑ）以查询的结果为基础定义的一种物ＭＴ是化的视图。视图（ＩＷ）ＭＴ都是基于查询定义ＶＥ和Ｑ的。Ｖｅｉｗ和ＭＴ的区别是，当视图被引用时，Ｑ每视
０前言
Ｄ２Ｂ通用数据库（ｎｅａＤｔａ，Ｄ）ＵｉｒｌａｂｓＵＢ是ｖｓａｅ
ＩＭ公司的用于构建任务关键型应用系统的关系Ｂ