DB2SQL性能优化准则在武钢物流管理系统中的实践

developerWorks 中国 > Information Management >DB2 最佳实践: 性能调优和问题诊断最佳实践，第 2 部分有条不紊地进行性能调优和故障诊断级别：初级developerWorks 中国网站编辑团队, 编辑, IBM2009 年 3 月 12 日本系列介绍了 DB2 系统性能的最优方法，分两部分。

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

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

概述就算是配置最仔细的系统也终究会发现它仍然需要一定的性能调优，并且这时我们已经搜集了的运行监控数据，将来非常便于搜集。

保持一种系统的方法来调优和进行故障诊断对我们非常重要。

当发生了一个问题，为了解决这个问题，很容易随意的进行调整。

然而，当我们这么做了，事实上定位到问题的可能性非常低，甚至让问题更糟糕。

性能调优的一些基本原则：1.有备而来，去了解系统一切正常的情况下性能怎么样。

搜集运行监视信息来跟踪一段时间内系统行为的变化。

2.了解整个场景，不要局限于你从 DB2 上看到的 – 也要搜集并分析来自于操作系统、存储、应用程序甚至来自用户的数据。

了解系统本身将有助于你解释监控数据。

3.只调整能解释你看到的症状的参数，如果连发动机都无法启动就不要更换轮胎。

不要试图通过降低 CPU 来解决磁盘的瓶颈。

4.一次只改一个参数，在更改其它参数之前先观察效果。

你可能遇到的问题类型性能问题往往分为两大类：影响了整个系统的问题和只影响了部分系统的问题。

比如某一特定应用或 SQL 语句，在研究的过程中－种类型的问题可能转化为另外一种类型的问题，或者相反。

例如造成整个系统性能降低可能是一个单独的语句，或者是整个系统的问题只是在一个特定的区域被发现。

下面我们从整个系统的问题开始。

数据库管理系统DB2的最佳实践数据库管理系统（DBMS）是组织和管理数据的软件工具，而DB2则是由IBM开发和管理的一种企业级DBMS。

在当今互联网和移动设备的普及背景下，DB2的应用越来越广泛，各种规模的企业都在使用DB2进行数据存储和管理，因此也涌现出了许多DB2的最佳实践。

本文将着重介绍数据库管理系统DB2的最佳实践，主要包括以下方面：DB2的基本架构和组成，DB2的安装与配置，DB2的备份与恢复，DB2的性能优化以及DB2的安全和权限管理。

一、DB2的基本架构和组成DB2是基于客户端/服务器体系结构构建的，它由多个组件组成，包括数据库管理器（DBM）、数据库配置助手（DBCA）、数据管理客户端（DMC）以及数据库监听程序（DB2监听程序）。

其中，数据库管理器（DBM）是整个DB2体系结构的核心组件，它负责协调和控制整个DB2数据库系统的运行。

数据库配置助手（DBCA）是用于创建和修改DB2数据库的工具，数据管理客户端（DMC）则提供了一个桌面界面，用于通过图形方式管理和监视DB2数据库。

二、DB2的安装与配置DB2的安装和配置是使用DB2之前必须完成的工作。

在进行DB2的安装和配置前，需要进行一些准备工作，例如确认操作系统的版本、准备DB2安装媒体等。

DB2的安装过程相对简单，大多数操作都是自动完成的，用户只需要按照提示进行操作即可。

在安装完成之后，需要进行一系列的配置操作，例如创建用户组、用户账号、创建数据库等。

三、DB2的备份与恢复备份和恢复是DBA日常维护工作中必备的技能。

备份数据可以防止数据丢失，而恢复数据则可以让我们及时恢复数据以保障业务的连续性。

DB2提供了多种备份和恢复的方法，例如在线备份、离线备份、增量备份等，用户需要根据具体需求选择不同的备份和恢复方法。

在备份和恢复工作中，用户需要注意备份的策略和周期，以及对备份文件进行妥善管理，同时还需要进行恢复的测试。

四、DB2的性能优化DB2的性能优化也是DBA日常工作的一个重要部分。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DB2之SQL优化浅析SQL优化是DB2数据库性能调优的重要环节，它能有效提升数据库查询效率，提高系统的响应速度。

本文将对DB2中的SQL优化进行浅析。

1.索引优化索引是加快数据库查询速度的关键因素之一、在进行SQL优化时，首先要考虑的是是否有适当的索引。

索引可以加快查询的速度，但过多的索引会降低插入和更新的性能。

因此，需要根据具体的业务需求和数据访问模式来选择适当的索引。

可以使用DB2的Explain工具对SQL查询语句进行分析，提供最佳的索引策略。

2.谓词下推谓词下推是指将过滤条件尽早地应用到表中，减少待处理的数据量。

在编写SQL语句时，应尽量将过滤条件写在WHERE子句中，并使用AND、OR等运算符将多个条件连接起来，避免使用临时表或视图进行数据过滤。

此外，还可以使用DB2的统计信息来了解表的数据分布情况，从而更好地选择合适的过滤条件。

3.使用合适的连接方式在对多个表进行关联查询时，应选择合适的连接方式。

DB2提供了多种连接方式，如INNERJOIN、LEFTJOIN、RIGHTJOIN等。

根据具体的业务需求和数据分布情况，选择合适的连接方式可以显著提高查询性能。

此外，还可以使用子查询或临时表来优化多表关联查询。

4.避免全表扫描全表扫描是指对整个表进行遍历，需要较长的时间和大量的系统资源。

在进行SQL优化时，应尽量避免全表扫描。

可以通过合理的索引设计和谓词下推来避免全表扫描，从而提高查询性能。

5.优化聚合和排序操作聚合操作（如SUM、COUNT、AVG等）和排序操作是常见的数据库查询操作，其效率对系统性能影响较大。

为了优化这些操作，可以使用合适的聚合函数和排序字段，避免不必要的数据计算和排序操作。

另外，还可以使用分区表或分区索引来加快聚合和排序操作的速度。

6.优化SQL语句的执行计划DB2会根据查询语句自动生成执行计划，选择最佳的查询策略。

为了优化执行计划，可以使用DB2的Explain工具来分析查询语句，了解执行计划的选择和执行代价。

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的性能优化，社区组织社区专家针对⼀些共性问题及难点分享经验。

以下内容来⾃活动“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_SQL优化
1、对SQL语句进行整体优化
在进行DB2SQL优化之前，首先要对SQL语句进行整体优化，这需要考虑数据库表的数据量、存储索引的有效性以及数据库系统的功能特性。

一般来说，进行整体优化需要遵循以下几点原则：
（1）优化SQL语句的语法。

要检查SQL语句中是否存在语法错误，并尽可能减少不必要的运算和空语句；
（2）把变量与常量进行区分，优先使用常量；
（3）使用合适的数据类型，减少不必要的转换操作；
（4）优化查询条件，尽量不要使用*，减少查询数据量；
（5）减少不必要的函数操作，例如使用 "case when" 语句取代"if" 语句；
（6）尽量不要使用子查询，子查询会降低查询效率，应当尽量使用关联查询。

2、使用索引提高查询性能
索引是数据库中实现快速检索的重要机制，针对查询表中不同的字段构建适当的索引可以有效地减少查询的时间，提高查询性能。

（1）最常用的方式是使用普通索引，普通索引可以提高SELECT和ORDERBY的查询性能；
（2）使用唯一索引，可以满足检索结果中每条记录的唯一性；
（3）使用组合索引，它是多个字段的索引；
（4）使用复合索引，它是多个组合索引组成的一种索引。