使用针对工作负载的正确的性能调节技术以避免硬件升级和优化DB性能
性能通过响应时间吞吐量峰值响应时间命中和每秒会话来衡量SQL编码和调节技术直接影响性能开发高性能的DB应用需要对DB技术的深入了解
当然在小数据量时这些技术无足轻重忽略的连接子查询表的表达式和CASE表达式的程序完全可以在轻量级负载下工作的很好使用%的SELECT INFO语句来进行数据获取的程序在开始会非常的迅速但是一旦数据量和会话速度增加性能将受到很大影响DB的可扩展性需要小的优化的SQL加上方案设计性能结构缓沖池和针对工作负载模式优化的存储另外的方案就是升级硬件了当然对于有着硬件升级的无尽预算的人来说不用阅读本文了对于其他人我将讲解如何编码聪明的SQL以及调优的访问路径
指针对于DB性能的影响
曾经有段时间在一个大的复杂的银行应用程序中存在着一个批处理程序这个新的批处理程序和访问路径被通过代码走查的方式检查过了因为项目截止日期的原因测试很少;在实际的首次运行中程序在运行个小时之后终止了一个很慢的代码走查之后发现了个指针每个指针访问一个不同的表中的数据每个指针在其他打开的指针的循环中被打开在彼此间传递数据也就是说这个程序在DB以外竟然结合了个表这不是聪明的SQL这个信息需要进入到个表;然而每个指针只能进入一个因此个指针被合并为一个聪明的指针
这个批处理在第二天用了四分钟就完成了大多数人可能会结束这个成功的任务了但是务实的人不会一个缓慢的EXPLAIN信息走查发现了一个有趣的表连接序列问题优化器选择了开始个表的复杂的循环连接还使用了一系列的大的数据表(ADDR和NAME)它们每个都包含千万行数据这不是DB优化器的典型行为然而有一些使用<>比较小表之间列的连接情况这些比较对于优化器来说很难估计因为DB catalog包含了相等列而非不等列这里就需要访问路径优化了DB优化者脑中肯定有多种推荐的解决方案一些可以在包或语句层次上另外的一些工作在谓词层次当然还有其他一些传统方式不奏效情况下的终极技术一个要求就是如下的性能调节技术提供给你的catalog以足够的统计使用统计向导来保证优化器有关于你的数据的精确全景
DB性能调节技术
包级别的SQL调优——需要REOPT(ONCE/ALWAYS/AUTO) BIND选项这个语句通告优化器来在运行时重新优化包中的每个语句至少ONCE或者ALWAYS(每次执行)在DB 中可以AUTO(需要时)这项技术的开销由选择的选项和SQL语句的数量及复杂性决定这些开销在批处理程序中可以忽略不计但是在短期运行的交易中会有很大影响在我们的例子中批处理程序指针只有一个谓词和一个基数为的主机变量REOPT是一个调节选项用来优化非统一列值分布和主机变量内容高可变的情况是COLCARDF=的反面包级别的调节并不合适
语句级别的调节技术——包括OPTIMIZE FOR n ROWS和FETCH FIRST n ROWS ONLY这些语句放在SELECT语句末尾是在不需要结果集的情况下进行优化的优化器假设除了这些语句的所有的SELECT语句需要整个结果这些结果偏向于诸如数序和表预取的访问路径因为我们的批处理指针一定需要整个结果因此语句级别的调节也不是合适的技术
谓词界别的调节技术——包括增加一个假的过滤器(TXCX=TXCX)或增加一个空操作到谓词上(+/* CONCAT )一个假的过滤器能够通过减少总过滤器因素(表中满足资格的行的比例)改变优化器这个方法能够改变表连接的顺序索引选择和连接方法多个假过滤器是允许的但是必须在没有引用过的一列上空操作(no op)能够通过降级一个过滤器从符合到不符合来改变优化器的工作方式但是只在z/OS上有用LUW优化器却不受其影响这个改变也会影响一个表连接序列索引选择和连接方法谓词级别的技术可以被一起使用来获取想要的结果我们例子中的指针对多个谓词级别调节的结合不起反应因此是采用重武器的时候了
一些终极调节技术包括使用DISTINCE的表的表达式和其他终极跨查询的块优化方法这些技术要求手动查询重写它们强制使得优化器以一个指定顺序的方式执行查询块使用这些技术视需要终极提醒的因为他们能把表连接序列索引选择和连接方法从好改到坏DISTINCE表表达式强制优化器优先于其他查询块执行圆括号中的查询如果SELECT DISTINCE中指定的列引用了不同的表表表达式可以被实例化为唯一的以供排序我们的批处理指针有一个非优化的连接序列使用该技术得到如下查询
这样的查询重写迫使优化器通过T连接表T来连接ADDR和NAME如果关键字DISTINCT在上例中省略了DB优化器合并表表达式查询和输出查询这样就和原来的语句和连接序列一样了SELECT DISTINCT是一个关键的组件然而因为列列表跨越了多个表临时的个表连接结果实例为一个唯一的工作文件以供排序排序的开销平均在每次执行几千行这是可以忽略的负载批处理程序现在可以在两分钟之内完成任务了
更多未来的调节技术
其他的一些查询重写技术从全异的查询块中获取信息以重写查询IBM曾经将此技术成为跨查询块优化;DB 中被成为全局优化一个好消息就是这项技术开始在DB优化器的自我查询重写(QWR)阶段中出现了所有DB查询都能使用它也是指日可待了同时我们也需要将一些终极方法掌握在自己的手里
