转）DB2日常维护——REORG TABLE命令优化数据库性能 2009-04-24 16:18 一个完整的日常维护规范可以帮助 DBA 理顺每天需要的操作，以便更好的监控和维护数据库，保证数据库的正常、安全、高效运行，防止一些错误重复发生。 由于DB2使用CBO作为数据库的优化器，数据库对象的状态信息对数据库使用合理的 ACCESS PLAN至关重要。DB2 优化器使用目录统计信息来确定任何给定查询的最佳访问方案。如果有关表或索引的统计信息已过时或者不完整，则会导致优化器选择不是最佳的方案，并且会降低执行查询的速度。当数据库里某个表中的记录变化量很大时，需要在表上做REORG操作来优化数据库性能 一、完整的REORG表的过程 值得注意的是，针对数据库对象的大量操作，如反复地删除表，存储过程，会引起系统表中数据的频繁改变，在这种情况下，也要考虑对系统表进行REORG 操作。一个完整的REORG表的过程应该是由下面的步骤组成的： RUNSTATS -> REORGCHK -> REORG -> RUNSTATS -> BIND或REBIND 注：执行下面命令前要先连接数据库 1 RUNSTATS 由于在第二步中REORGCHK时可以对指定的表进行RUNSTATS操作(在REORGCHK时指定UPDATE STATISTICS)，所以第一步事实上是可以省略的。 2 REORGCHK 在对表数据进行许多更改之后，逻辑上连续的数据可能会位于不连续的物理数据页上，在许多插入操作创建了溢出记录时尤其如此。按这种方式组织数据时，数据库管理器必须执行其他读操作才能访问顺序数据。另外，在删除大量行后，也需要执行其他的读操作。 表重组操作会整理数据碎片来减少浪费的空间，并对行进行重新排序以合并溢出记录，从而加快数据访问速度并最终提高查询性能。还可以指定根据特定索引来重新排序数据，以便查询时通过最少次数据读取操作就可以访问数据。 下列任何因素都可能指示用户应该重组表： 1）自上次重组表之后，对该表进行了大量的插入、更新和删除活动。
DB2 MDC 表的优化策略 如果创建多维集群 (MDC) 表，那么可以提高许多查询的性能，这是因为优化器可 以应用附加的优化策略。这些策略主要依赖于块索引效率有所提高，但根据多个维进行集群这一优点还能提高数据检索速度。 MDC 表优化策略还可以利用分区内并行性和分区间并行性的性能优点。请考虑MDC 表的下列具体优点： ?维块索引查找操作可以标识表的所需部分，并且能够快速地仅扫描所需的块。 ?因为块索引小于记录标识（RID）索引，所以查找速度更快。 ?可以在块级别执行索引 AND 和 OR 运算，并可以将这些运算与 RID 相结合。 ?保证在扩展数据块内集群数据，这有助于提高检索速度。 ?如果可以使用转出方法，那么删除行的速度将更快。 请考虑名为 SALES 的 MDC 表的以下简单示例，这个表对 REGION 和 MONTH 列 定义了维： select * from sales where month = 'March' and region = 'SE' 对于此查询，优化器可以执行维块索引查找操作，以寻找月份为三月且地区为 SE 的块。然后，它可以只扫描那些块，以便快速地访存结果集。 转出删除 当条件允许使用转出方法来进行删除时，将使用这种从 MDC 表中删除行的更高效 方法。必需的条件包括： ?该 DELETE 语句是搜索型 DELETE，而不是定位型 DELETE（该语句不使用 WHERE CURRENT OF 子句）。 ?没有 WHERE 子句（将删除所有行），或者 WHERE 子句只包含应用于维的条件。 ?定义表时，未指定 DATA CAPTURE CHANGES 子句。 ?该表不是引用完整性关系中的父表。 ?未对该表定义 ON DELETE 触发器。 ?未在任何立即刷新的 MQT 中使用该表。 ?如果级联删除操作的外键是该表的维列的子集，那么它可能适合于转出。 ?在由 CREATE TRIGGER 语句的 OLD TABLE AS 子句指定的触发 SQL 操作之前，该 DELETE 语句不能出现在对临时表执行并标识了受影响行集的 SELECT 语句中。
[经验分享] db2数据库性能参数优化笔记整理 数据库, 笔记, 性能, 参数, 调优 1、Application Support Layer Heap Size (ASLHEAPSZ) 它是app和agent通信的buffer，占用实例共享内存空间。 监控: get snapshot for all on | grep –i “Rejected Block Remote Cursor requests” Rejected Block Remote Cursor requests = 2283 如果Rejected Block Remote Cursor requests值比较高，增大ASLHEAPSZ值，直到该值为0 配置： update dbm cfg using aslheapsz 20 2、Maximum Requester I/O Block Size (RQRIOBLK) 它是client和server通信的buffer，占用每个agent的私有内存空间。 监控:无法监控 配置：建议设置为最大值64K，缺省32767bytes，（设到最大值不会影响其它性能） update dbm cfg using rqrioblk 65536 3、Sort Heap Threshold (SHEAPTHRES) 私有模式排序空间最大阀值，值＝并发数×SORTHEAP 监控： 需要打开sort监控开关－db2 update monitor switches using sort on get snapshot for dbm | grep –i “sort” 如果Post threshold sorts值比较大，增加SORTHEAP 、SHEAPTHRES参数值 如果(Piped sorts accepted/Piped sorts requested)值比较低，增加SORTHEAP 、SHEAPTHRES参数值配置： update dbm cfg using sheapthres 80000 4、Enable Intra-Partition Parallelism (INTRA_PARALLEL) 在SMP环境中打开该选项，提高表和索引扫描速度 监控： list applications 看application对应的Agents（# of Agents）数目是否大于1 配置： update dbm cfg using intra_parallel yes 5、Maximum Query Degree of Parallelism (MAX_QUERYDEGREE)
关于数据库优化有很多方法，这里针对数据库的runstat（运行统计）和reorg（重组）进行以下说明； 一、runstats： 1、runstats的作用： 一个SQL在写完并运行之后，其实我们只是告诉了DB2去做什么，而不是如何去做。而，具体的如何去做，就取决于优化器。优化器为了生成最优的执行计划，就得掌握当前的系统信息，目录中的统计信息等等。 runstats命令就是用来收集数据库对象的状态信息，这对优化器生成最优的执行计划至关重要。 2、什么时候需要runstats： 在给表创建一个index后，我们最好做一次runstat，否则可能index没有生效。不过有说法称在8.2版本以后的DB2中，会在INDEX之后自动进行runstats； 在对table做了一次reorg后，记得要做一次runstats。因为对表做reorg，会修改表的很多信息，比如高水位等，所以做一次runstats,可以更新统计信息。 当表里数据发生了比较大的变化，一般来说，大约表里面的数据量的10%-20%发生了变化，就应该作一次runstats。这些变化包括删除，修改，插入。对于一些非常大的表，比方在某些医院，出院明细账表非常巨大。这个时候，完整的对一个大表做runstats可能花费时间相当大，需要提前做好准备； 3、runstats的语法： runstats on table [模式名].[表名] with distribution and detailed indexes all 你可以在所有列上，或者仅仅在某些列或列组（除了LONG和LOB列）上执行RUNSTA TS。如果没有指定特定列的子句，系统则会使用默认的ON ALL COLUMNS子句。 使用RUNSTA TS WITH DISTRIBUTION 当您已确定表中包含不是统一分布的数据时，可以运行包含WITH DISTRIBUTION子句的RUNSTA TS。目录统计信息表通常包含关于表中最高和最低值的信息，而优化器假定数据值是在两个端点值之间均匀分布的。然而，如果数据值彼此之间差异较大，或者群集在某些点上，或者是碰到许多重复的数据值，那么优化器就无法选择一个最佳的访问路径，除非收集了分布统计信息。使用WITH DISTRIBUTION子句还可以帮助查询处理没有参数标志符（parameter marker）或主机变量的谓词，因为优化器仍然不知道运行时的值是有许多行，还是只有少数行。 如果为单一索引进行runstats，可以使用： runstats on table [模式名].[表名] for indexes [索引名] 4、图像界面下runstats； 首先在维护机上编目需要优化的的数据库； 连接数据库； 找到需要做runstats的表，右键，选择运行统计信息；
db2 对缓冲池的性能优化 博客分类： DB2 db2 对缓冲池的性能优化 需求：因为项目开始的时候没有对DB2数据库进行深入的熟悉，所以造成项目后期做性能测试的时候，导致应用访问过慢，后来决定从数据方面做做一下性能优化，主要在于缓冲池方面。 解决方案：因为数据库中只有一个常规表空间表空间USERSPACE1和一个缓冲池 IBMDEFAULTDP（1G）,所以决定重新再建一个大的缓冲池BP2，将USERSPACE1赋给BP2 CREATE BUFFERPOOL BP2 SIZE 2048 PAGESIZE 4K; ALTER TABLESPACE USERSPACE1 BUFFERPOOL BP2; 附注： 以下为对网上资源学习后的一个总结： 1、表空间 I、数据存储层级关系：数据库-->表空间-->容器-->表， II、表空间分类： 目录表空间 特性：每个数据库只有一个目录表空间，它是在发出CREATE DATABASE 命令时创建的. 目录表空间被DB2 命名为SYSCATSPACE， 用途：它保存了系统目录表； 常规表空间
特性：创建数据库时指定该表空间的缺省名为USERSPACE1。长表空间是可选的，缺省情况下一个都不创建， 用途：保存表数据和索引、还可以保存LOB之类的长数据； 系统临时表空间 特性：随数据库创建的系统临时表空间的缺省名为TEMPSPACE1， 用途：用于存储SQL 操作（比如排序、重组表、创建索引和连接表）期间所需的内部临时数据； 以上是由系统管理的空间（SMS），必须有一个 以下是由数据库管理的空间（DMS），可选 长表空间 用途：用于存储长型或LOB 表列，存储结构化类型的列或索引数据 用户临时表空间 用途：存储已声明的全局临时表 LOB(large object)的定义： 是一种用于存储大对象的数据类型，如医学记录（如X-射线）、视频、图像等。LOB有三种类型：BLOB：Binary Large Object、 CLOB：Character Large Object、DBCLOB：Double-byte Character Large Object。每个LOB可以有2GB III、页大小（暂无）： IIII、创建表空间： 最有效的表空间设置属性：PAGESIZE（表空间大小）、EXTENTSIZE（将数据写入到下一个容器之前写入到当前容器中的数据的页数）和PREFETCHSIZE（预取）
DB2数据库性能优化 DB2问世于1983年，其被贴上的标签之一就是：最早使用SQL（同样最早被IBM 开发）的关系型数据库产品。此前，IBM已经有了一个层次性数据库产品，在当时已属数据库中的"大哥大"，所以当发布关系型数据库时，IBM为自己的数据库产品排座次，新的数据库产品理所当然的是数据库二代，也被大家戏称为"库二代"，就这样，DB2的命名也就被人们接受了。实际上，DB2的渊源可以追溯至上世纪70年代初，那时还是个登月的年代，阿波罗登月的壮举时刻激励科学家们开拓创新。当时在IBM工作的考德(E.F.Codd)博士在1970年6月用划时代的论文描述了关系型数据库理论，这使得后来诞生的"库二代"被赋予了强有力的数学基础和逻辑基因。接下来，IBM把对E.F.Codd想法的实施交给了一个程序小组，这个程序小组使用SEQUEL作为查询语言。当IBM公布其第一个关系型数据库产品时，对SEQUEL重新命名，这就是后来大名鼎鼎的SQL。而在那一段时间，刚遭受离婚重创的犹太人Larry Ellision也发现了其中的秘密，他创立的Oracle，着实与DB2经历了一起"穿开裆裤"的起步阶段，之后你追我干30年，成为一组最有趣的竞争对手。 在上世纪80年代，DB2作为一个全功能的数据库管理系统，被IBM大型机所专用。到了上世纪90年代早期，IBM将DB2带向了其它平台，包括OS/2、UNIX以及Windows服务器，然后是Linux和手持设备。让大家一目了然的是，DB2 所有的产品都要被命名为"产品 for 平台"（例如，DB2 for OS/390）。 进入上世纪90年代中期，IBM发布了一组最初应用在AIX上的被称为DB2 Parallel的版本，此版本通过无分享（Share Nothing）架构而提供更强的伸缩性，即将一个大型数据库，分布到多个服务器上。后来，这个DB2版本被扩展到所有的Linux、UNIX以及Windows平台，并被重新命名为DB2 Extended Enterprise Edition(EEE)。现在，这个特性被称为Database Partitioning Feature(DPF)。目前，DPF在数据仓库中已得到了广泛应用。 DB2有众多的版本，除了支持OLTP的Express、Workgroup和Enterprise等版本外，还提供了支持数据仓库的版本，Infosphere Wareshouse（缩写为ISW）。这个版本偏重于混合工作负荷（OLTP和OLAP）和商业智能的实现，包含一些商务智能的特性例如ETL工具、数据发掘、OLAP加速等。 DB2 V10是最近发布的版本。这个版本提供了多时态表（Temporal Tables）、多表星型连接、行列访问控制（RCAC）、多温度存储（Multi-temperature Storage）等特性；在DB2 V10中，通过自适应压缩（Adaptive Compression）特性大幅度提升了压缩比；DB2集群技术（pureScale）得到进一步的完善。 本课程循序渐进，由浅入深，从DB2基础讲起，再深入讲授性能调优方法学和核心技能，最后会分享培训老师在一线多年的实战案例。内容包括：DB2优化方法系统、数据库监控、配置参数调整、日志优化、运维工具优化、锁机制、索引调优、优化器与SQL语句调优等。另外，最最重要的是本课程包含众多一线实战案例，包括某ERP数据库性能优化、某数据采集平台数据库性能优化等。
1，打开监视器记录开关 >db2 update monitor switches using BUFFERPOOL ON 2,查看BUFFERPOOL相关指标 >db2 connect to BANK >db2 get snapshot for BUFFERPOOLS on BANK ... Buffer pool data logical reads = 16359 Buffer pool data physical reads = 209 Buffer pool index logical reads = 90 Buffer pool index physical reads = 52 ... buffer pool hit ratio = (1- ((Buffer pool data physical reads + Buffer pool index physical reads) / (Buffer pool data logical reads + Buffer pool index logical reads))) * 100% 3，查看BUFFERPOOL大小 >db2 connect to BANK >db2 "select BPNAME,NPAGES,PAGESIZE from SYSCAT.BUFFERPOOLS" BPNAME NPAGES PAGESIZE ------------------------------------------------------------------------- ------------------------------------------------ ----------- ----------- IBMDEFAULTBP 250 4096 1 条记录已选择。 看到，250 pages,每页4096 bytes(4k) 4，运行performer,记录Test Result 5,打开Windows任务管理器，注意当前内存使用情况 6，加大IBMDEFAULTBP >db2 "alter bufferpool IBMDEFAULTBP immediate size 10000" 7,注意Windows任务管理器显示的当前内存使用情况 8，运行performer,记录Test Result，与调整前比较。
1.1 DB2性能调优 1.1.1 常规性能优化 1、以超级管理员登录到服务器上 1、再用db2管理员组中的成员登录: db2inst1 2、运行如下命令，以便连接到数据库jcrdb 3、为数据库做常规性能优化 A) 常规性能优化执行的命令命令 db2 -x -r "runstats.db2" "select rtrim(concat('runstats on table ',concat(rtri m(tabSchema),concat('.',concat(rtrim(tabname),' on all columns with distrib ution on all columns and sampled detailed indexes all allow write access '))))) from syscat.tables where type='T'"
大约经过2个小时后，命令执行完毕。
B) 执行动态性能调优命令：db2 -v -f "runstats.db2"
大约2-3个小时后命令执行成功结束
4、执行以下命令以便缩短数据库死锁时间 db2set DB2_EVALUNCOMMITTED=YES db2set DB2_INLIST_TO_NLJN=YES 1.1.2 设置参数以便提高性能的策略 1、以DB2管理员组成员登录，如：db2inst1 2、执行：db2set DB2_INLIST_TO_NLJN=YES 3、检查DB2现行参数：db2set 4、重起DB2以便使设置生效。 1.1.3 增加Member Manager数据库连接池缓存 1、以超级管理员登录WAS控制台，并找到数据库wmmdb
分区数据库环境下 DB2 LOAD 性能调优 吴磊, 软件工程师, IBM 简介：本文详细阐述了分区数据库环境下 DB2 LOAD 的线程模型，并以 LOAD 线程模型为纲，详细分析每个线程的作用和特点，多方面、多角度地剖析影响其性能的因素，同时对性能的改进提供了参考建议。最后，以实例演示展示了性能调优的效果。DB2 LOAD 实用程序广泛应用于各行业、各领域的数据移动场景中，通过本文，相关读者可以充分理解 DB2 LOAD 的线程模型，影响各相关线程性能的关键参数，文中给出的参考建议与实例场景对读者有借鉴意义。 本文的标签：dpf, 关于产品, 性能, 管理 发布日期：2011 年 12 月 12 日 级别：中级访问情况 ：806 次浏览 DB2 LOAD 线程模型 在本文中，除非特别声明，对于 DB2 LOAD 的讨论都是在分区数据库环境下。同时本文专注于讨论分区数据库环境下 DB2 LOAD 的性能调优，不再对分区数据库中的基本概念进行赘述，阅读本文的读者需要对分区数据库概念有基本的了解。LOAD 作为DB2 的实用程序，广泛地应用于各种数据移动场景中，尤其是在数据仓库的 ETL 过程中，LOAD 更是占据了主导地位。因此如何有效地提升 LOAD 性能，在数据移动场景中满足客户的需求和期望，是至关重要的。在对LOAD 性能进行调优之前，首先需要理解 LOAD 中各相关线程的作用和特点，从而有针对性地进行调整、优化。LOAD 线程模型如图 1 所示。 图1. LOAD 线程模型 在 DB2 中，LOAD 操作请求由代理线程 db2agent 受理，该线程负责派生、协调、监视相关LOAD 线程。LOAD 内部
db2编程使用技巧一（转帖） 1 DB2编程 1.1 建存储过程时CREATE 后一定不要用TAB键3 1.2 使用临时表3 1.3 从数据表中取指定前几条记录3 1.4 游标的使用4 注意commit和rollback 4 游标的两种定义方式4 修改游标的当前记录的方法5 1.5 类似DECODE的转码操作5 1.6 类似CHARINDEX查找字符在字串中的位置5 1.7 类似DATEDIF计算两个日期的相差天数5 1.8 写UDF的例子5 1.9 创建含IDENTITY值(即自动生成的ID)的表6 1.10 预防字段空值的处理6 1.11 取得处理的记录数6 1.12 从存储过程返回结果集(游标)的用法6 1.13 类型转换函数8 1.14 存储过程的互相调用8 1.15 C存储过程参数注意8 1.16 存储过程FENCE及UNFENCE 8 1.17 SP错误处理用法9 1.18 IMPORT用法9 1.19 VALUES的使用9 1.20 给SELECT 语句指定隔离级别10 1.21 ATOMIC及NOT ATOMIC区别10 2 DB2编程性能注意10 2.1 大数据的导表10 2.2 SQL语句尽量写复杂SQL 10 2.3 SQL SP及C SP的选择10 2.4 查询的优化(HASH及RR_TO_RS) 11 2.5 避免使用COUNT(*) 及EXISTS的方法11 3 DB2表及SP管理12 3.1 看存储过程文本12 3.2 看表结构12 3.3 查看各表对SP的影响(被哪些SP使用) 12 3.4 查看SP使用了哪些表12 3.5 查看FUNCTION被哪些SP使用12 3.6 修改表结构12 4 DB2系统管理13 4.1 DB2安装13
DB2缓冲池和索引调优的方法 1 DB2性能问题的表现 应用系统(OA)上的表现：一般是登录、首页、待办列表等数据量比较大的模块，响应时间长，耗时数秒到数十秒都有可能。有时候是用户访问高峰期慢，下班时间又比较正常。 操作系统上的表现：一般是中间件服务器(W AS)系统正常，CPU和IO占用不会持续超过50%，系统运行进程不会有持续的等待。数据库服务器则非常繁忙，CPU占用持续在50%以上，往往会达到持续90%左右，IO占用可能不高。从系统层面判断，性能瓶颈出在数据库上。 2 调优的基本思路 DB2的性能和操作系统、锁、缓冲池、索引等参数，以及SQL的写法都有很大关系，受限于个人认识，这里主要介绍缓冲池和索引的调优方法。 缓冲池的调整比较简单，一般可以先调整缓冲池，若效果不明显，则再调整索引和SQL。 3 缓冲池调优 缓冲池是内存中的一块区域，DB2会将用到数据放到缓冲池中提高性能。缓冲池太小，每次查询仍然要到磁盘中操作，达不到缓冲的效果。缓冲池太大，超出操作系统管理的限制，会导致数据库无法连接的错误。 缓冲池是通过表空间与数据表发生联系的，数据表存放在指定的表空间中，每个表空间又有指定的缓冲池。因为每张数据表存储的数据量都不同，一般根据每条记录存放的最大数据量，我们会为数据表分别指定4k-32k不同的表空间来存放，以达到优化存储和性能的目的，缓冲池也是类似。这个一般在创建数据库时就会分配好了。 在*unix下，可以使用下面的命令查看缓冲池相关信息： 切换到db2inst1账号 su – db2inst1 连接到pzbdw数据库
db2 connect to pzbdw 查看缓冲池定义 db2 "select BPNAME,NPAGES,PAGESIZE from syscat.bufferpools" 查看表空间的定义，包含表空间名称(TableSpaceName)、使用的缓冲池名称(BufferpoolName)，表空间的页大小(TBSPageSize)，缓冲池的数量(BufferpoolPages)，缓冲池的页大小数据(BufferpoolSize)信息。 db2 "select s.TBSPACE TableSpaceName,b.BPNAME BufferpoolName,s.PAGESIZE TBSPageSize,b.NPAGES BufferpoolPages, b.PAGESIZE BufferpoolSize from SYSCA T.BUFFERPOOLS b,SYSCA T.TABLESPACES s where s.BUFFERPOOLID=b.BUFFERPOOLID"|more 查看mv_workitem表所在表空间和缓冲池信息，一般“MV_”开头的表使用的缓冲池是重点关注对象： db2 "select TABSCHEMA TableSchemaName, TABNAME TableName, t.TBSPACE TableSpaceName,b.BPNAME BufferpoolName, b.NPAGES BufferpoolPages, b.PAGESIZE BufferpoolSize from SYSCA T.TABLES t ,SYSCA T.BUFFERPOOLS b,SYSCA T.TABLESPACES s where tabname='MV_WORKITEM' and s.BUFFERPOOLID=b.BUFFERPOOLID and t.TBSPACE=s.TBSPACE" 开启缓冲池监控器： db2 update monitor switches using bufferpool on 在应用系统重现问题后，检查缓冲池的快照： db2 get snapshot for bufferpools on pzbdw|grep -i buffer|more
解决软件性能问题的DB2数据库优化方案 摘要：通过应用软件的具体案例，结合db2数据库的使用经验，该文提出采用数据库技术解决软件性能问题的一些思路、原则和方法等。 关键词：db2；软件性能；数据库优化；优化方案 中图分类号：f426.21 文献标识码：a 文章编号：1009-3044（2013）04-0671-03 performance 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多个部门日常业务，是一套符合客户其业务流程、切合其自身需要、充分发挥其营销优势、
DB2优化工具使用 DB2提供了多种数据库优化工具，包括db2advis（设计顾问程序）、Visual Explain、db2exfmt、db2expln 数据库优化工作最头疼的事情是什么？ 个人认为: 一．没有具体的量化指标(这里指执行sql的开销,包括CPU、磁盘I/O等的开销)，来判断优化的效果。程序员只能凭sql语句的 执行时间和以往的经验来判断优化是否成功。 二．数据库查询优化器的优化结果是否理想，由于sql语句是要经过数据库引擎的查询优化器对sql语句进行重整优化，这一过 程是黑盒的，我们无法了解，比如查询条件是否下推？我建 立的索引是否被用到？sql语句执行的是全表扫描还是索引 扫描？这些怎么确定是一个关键问题。 三．对于业务系统需求经常变更的应用系统，怎么从全局角度把握数据库的优化，在运行阶段可能做过优化工作，但是随着 业务的变更，以前做的优化工作变的无效了，怎么重新优化？IBM为我们提供的这几款工具为使我们能够对这些开销的具体数据有全面的了解，了解查询优化器优化后的结果，全局角度了解目前业务系统的优化状况，从而制定优化目标。以上是个人的一点感受，下面切入正题，go.
一． db2advis（设计顾问程序）的使用 设计顾问程序有命令行模式的db2advis，也有图形化界面的设计顾问程序。需要注意的是图形化界面的设计顾问程序依赖于db2advis，如果没有建立过执行计划表的话，先要建立执行计划表，需要在相应数据库里执行 EXPLAIN.DDL,命令如下 db2cmd 进入DB2CLP db2 connect to
主要讲DB2的SQL优化，也许你在面 试的时候用得着 关于DB2SQL的优化 程序员之殇 相忘于江湖
目录 1. 前言 (2) 2. 为什么要进行SQL 优化 (3) 3. 怎样知道一个SQL 的优劣 (4) 3.1 图形化方案 (4) 3.2 命令行方案 (5) 3.2.1 Db2expln (5) 3.2.2 Db2batch (6) 4. 怎么样去优化我们的SQL语句 (7) 4.1改写 IN (7) 4.2改写 LIKE (7) 4.3改写 OR 或<> (8) 4.4 合理使用Not in 和Not Exists (9) 4.5避免使用distinct (10) 4.6不兼容的数据类型 (10) 4.7表连接 (11) 4.8利用子查询结果 (14) 4.9其他注意小点 (15) 5. 如何建立合理的索引 (18) 6. 避免死锁和锁等待 (20) 7. 几个经典案例 (23)
1.前言 这篇文档综合了网上技术同仁的观点和作者的亲身实践，有不足和落伍之处还请读者明辨，这是因为计算机技术日新月异，今天看起来对的东西明天可能就不对了。 如果读者缺乏明辨的能力，请自己到网上google或baidu一下。若你要问我多年的IT工作总结出了什么经验，我只能用4个字来概括：网络搜索。
2.为什么要进行SQL 优化 为什么要做 SQL 优化？这是不是一个无聊的工作？ 那么我问你现在是面向什么编程？面对对象吗？也许吧，可网上有人说得好，现在做信息化的大部分人都在面向数据库编程，是的，我们大部分的ERP、OA、CRM中充满了SQL，没有SQL，没有数据库，就没有现在各种信息化应用。 不少人觉得查询优化是数据库管理系统的任务，与所编写的SQL语句关系不大，这种认识是不正确的，虽然现在的数据库产品在查询优化方面已经做得越来越好了，但提交的SQL语句是系统优化的基础，很难设想一个原本糟糕的查询语句经过系统的优化之后会变得高效。 据统计，SQL语句消耗了70%-90%的数据库资源，而其中读的SQL语句又占 去70%-90%的资源。一个好的查询语句往往可以使程序性能提高数倍或数十倍，因此所写SQL语句的优劣至关重要！下面就与大家一起分享一下相关知识，希望对日常工作有所帮助。
reorgchk，检查table index 是否需要重组。reorg 重组，重新放置数据位置。runstats 统计信息，可以优化查询器 一个完整的日常维护规范可以帮助DBA 理顺每天需要的操作，以便更好的监控和维护数据库，保证数据库的正常、安全、高效运行，防止一些错误重复发生。 由于DB2使用CBO作为数据库的优化器，数据库对象的状态信息对数据库使用合理的ACCESS PLAN至关重要。DB2 优化器使用目录统计信息来确定任何给定查询的最佳访问方案。如果有关表或索引的统计信息已过时或者不完整，则会导致优化器选择不是最佳的方案，并且会降低执行查询的速度。当数据库里某个表中的记录变化量很大时，需要在表上做REORG操作来优化数据库性能 一、完整的REORG表的过程 值得注意的是，针对数据库对象的大量操作，如反复地删除表，存储过程，会引起系统表中数据的频繁改变，在这种情况下，也要考虑对系统表进行REORG操作。一个完整的REORG 表的过程应该是由下面的步骤组成的： RUNSTATS -> REORGCHK -> REORG -> RUNSTATS -> BIND或REBIND 注：执行下面命令前要先连接数据库 1 RUNSTATS
由于在第二步中REORGCHK时可以对指定的表进行RUNSTATS操作(在REORGCHK 时指定UPDATE STATISTICS)，所以第一步事实上是可以省略的。 2 REORGCHK 在对表数据进行许多更改之后，逻辑上连续的数据可能会位于不连续的物理数据页上，在许多插入操作创建了溢出记录时尤其如此。按这种方式组织数据时，数据库管理器必须执行其他读操作才能访问顺序数据。另外，在删除大量行后，也需要执行其他的读操作。 表重组操作会整理数据碎片来减少浪费的空间，并对行进行重新排序以合并溢出记录，从而加快数据访问速度并最终提高查询性能。还可以指定根据特定索引来重新排序数据，以便查询时通过最少次数据读取操作就可以访问数据。 下列任何因素都可能指示用户应该重组表： 1）自上次重组表之后，对该表进行了大量的插入、更新和删除活动。 2）对于使用具有高集群率的索引的查询，其性能发生了明显变化。 3）在执行RUNSTATS 命令以刷新统计信息后，性能没有得到改善。 4）REORGCHK 命令指示需要重组表（注意：在某些情况下，REORGCHK 总是建议重组表，即使在执行了重组后也是如此）。例如，如果使用32KB 页大小，并且平均记录长度为15 字节且每页最多包含253 条记录，则每页具有32700- (15 x 253)=28905 个未使用字节。这意味着大约88% 的页面是可用空间。用户应分析REORGCHK 的建议并针对执行重组所需的成本平衡利益。
1、Application Support Layer Heap Size (ASLHEAPSZ) 它是app和agent通信的buffer，占用实例共享内存空间。 监控: db2 get snapshot for all on dbname | grep -i "Rejected Block Remote Cursor requests" Rejected Block Remote Cursor requests = 2283 如果Rejected Block Remote Cursor requests值比较高，增大ASLHEAPSZ值，直到该值为0 配置： update dbm cfg using aslheapsz 20 2、Maximum Requester I/O Block Size (RQRIOBLK) 它是client和server通信的buffer，占用每个agent的私有内存空间。 监控:无法监控 配置：建议设置为最大值64K，缺省32767bytes，（设到最大值不会影响其它性能）update dbm cfg using RQRIOBLK 65536 3、Sort Heap Threshold (SHEAPTHRES) 私有模式排序空间最大阀值，值＝并发数×SORTHEAP 监控： 需要打开sort监控开关－db2 update monitor switches using sort on db2 get snapshot for dbm | grep "sort" 如果Post threshold sorts值比较大，增加SORTHEAP 、SHEAPTHRES参数值 如果(Piped sorts accepted/Piped sorts requested)值比较低，增加SORTHEAP 、SHEAPTHRES 参数值 配置： update dbm cfg using sheapthres 80000 4、Enable Intra-Partition Parallelism (INTRA_PARALLEL) 在SMP环境中打开该选项，提高表和索引扫描速度 监控： db2 list applications 看application对应的Agents（# of Agents）数目是否大于1 配置： db2 update dbm cfg using intra_parallel yes 5、Maximum Query Degree of Parallelism (MAX_QUERYDEGREE) 指定一个SQL语句的最大subagent数目，当INTRA_PARALLEL值为yes时该参数起作用。如果该值为ANY (-1)，那么优化器将使用服务器的最大cpu数目。 监控： db2 list applications 看application对应的Agents（# of Agents）数目是否大于1 配置： db2 update dbm cfg using MAX_QUERYDEGREE 4 IMMEDIATE 6、Query Heap Size (QUERY_HEAP_SZ)
DB2相关程序优化建议 一、程序开发建议 注意程序锁的使用 DB2有十分严格的锁机制，存在锁升级的概念，锁也需要占用一定的缓 存空间，当程序的行级锁达到一定数量后可升级为表级锁，表锁达到一 定数量后可升级为库级锁，将整个数据库锁住。所以在写程序的时候我 们要十分关注程序锁的使用，尤其是对应并发性高的程序。 隔离级别主要用于控制在DB2根据应用提交的SQL语句向DB2数据库中 的相应对象加锁时，会锁住哪些纪录，也就是锁定的范围。隔离级别 的不同，锁定的纪录的范围可能会有很大的差别。 隔离级别分为RR/RS/CS/UR这四个级别。下面让我们来逐一论述： 1．RR隔离级别：在此隔离级别下，DB2会锁住所有相关的纪录。在 一个SQL语句执行期间，所有执行此语句扫描过的纪录都会被加上相应 的锁。具体的锁的类型还是由操作的类型来决定，如果是读取，则加共 享锁；如果是更新，则加独占锁。由于会锁定所有为获得SQL语句的 结果而扫描的纪录，所以锁的数量可能会很庞大，这个时候，索引的 增加可能会对SQL语句的执行有很大的影响，因为索引会影响SQL语句扫 描的纪录数量。 2．RS隔离级别：此隔离级别的要求比RR隔离级别稍弱，此隔离级别下 会锁定所有符合条件的纪录。不论是读取，还是更新，如果SQL语句 中包含查询条件，则会对所有符合条件的纪录加相应的锁。如果没有条 件语句，也就是对表中的所有记录进行处理，则会对所有的纪录加锁。 3．CS隔离级别：此隔离级别仅锁住当前处理的纪录。 4．UR隔离级别：此隔离级别下，如果是读取操作，不会出现任何的行 级锁。对于非只读的操作，它的锁处理和CS相同。 在这四种隔离级别中，CS是缺省值。这四种隔离级别均可以保证DB2 数据库在并发的环境下不会有数据丢失的情况发生。要注意的是如果对 纪录进行了修改，需要在相应的纪录上加独占类型的锁，这些独占类型 的锁直到交易结束时才会被释放，这一点在四种隔离级别下都是相同的。 到这里，我们已经对DB2中的表锁，行锁，隔离级别进行了论述。DB2 数据库的并发控制主要是通过这些机制。理解了这些概念，我们就可以 在使用DB2数据库时根据系统的实际需要来设计锁模式和隔离级别，来 实现我们的系统要求，在保障数据安全的前提下，提供较好的并发性。 如上针对隔离级别的解释，我们在对大表，尤其是并发性高的大表进行查询是一定要指定隔离级别，在语句的最后加上with ur。 注意清空表的方式 不管是在oracle还是DB2中delete的性能都是较低的，因为delete需要 回归段记录日志，oracle提供了一种全表清空的高效方法truncate语句，