如何减少CUP使用

如果症状表现为大量的CPU资源请求，那么原因是什么?在SQL语句层面可能包括：

•糟糕的SQL代码;

•糟糕的应用程序代码;

•交易应用的提交策略不佳;

•过度使用批量卸载/加载/备份流程;

•频繁使用RunStats;

•对缓冲池大小的选择不当;

•对BP页集选择的不当分配;

•排序池/RID池的内存分配不足;

•内存管理不当导致实际存储的分页;

•对DB2子系统的配置不当;

•DB2配置为最大I/O吞吐量，而非最小CPU利用率;

•DB2配置为高性能写访问;

•频繁执行备份;

•执行LOAD ... LOG YES。

进行SQL语句调优将解决CPU容量问题，在正确得出类似结论之前，DBA必须首先收集相关数据。甚至还需要做更多的工作来证明通过给DB2子系统添加CPU容量可以增加吞吐量。

我并不是说SQL调优总是在浪费时间，如果你不衡量在这一过程中资源耗费和节省的状况，你又怎么能知道这样做值不值得呢?作为一个管理者，我更倾向于DBA能将它们宝贵的时间投入到灾难恢复准备，数据可用性和安全性等这些高优先级的问题中去。

开发人员编写性能不佳的SQL代码

这可以说是一个普遍的事实存在。DBA可以给开发人员提供最佳实践以及SQL实现标准，让他们知道好的SQL开发人员应该怎样写代码，然后提供SQL代码示例。

另一个常被忽视的问题是： IT部门有对用户的资源成本负责吗?也就是说，他们有对CPU和磁盘存储的使用进行支付吗?对于事务/应用程序有没有订立服务水平协议以及配套的处罚措施呢?如果不存在任何的这样的机制，那么程序开发人员就会没有动力去编写性能优良的代码。

那么我到底要不要做SQL调优?

要摆脱疲于应付SQL调优的状态就要做根本原因分析。为什么不良SQL总是不断汹涌而来?难道是开发人员写代码太糟糕?如果是这样，也许解决之道就是培训，或是让他们自己进行调优。工具是否会自动生成性能不佳的SQL呢?答案可能会比较复杂，因为它会涉及到工具的升级，索引管理，RunStats管理，甚至是DB2子系统调优等诸多方面。

最后，DB2子系统，数据共享以及操作系统配置是最常影响应用程序和SQL性能的。如果你花费大量时间在SQL查询调优上，也仅仅是发现系统参数值造成这样的结果，难道你不会觉得烦躁吗?难道你就真的希望每每配置发生改变就要一遍又一遍的对单条不良SQL语句进行调优吗?

总结

如果DBA花费时间去做SQL调优而不是修复导致问题的根本原因，那么支持人员和IT部门要如何成长?你又如何才能有机会变得积极主动呢?企业则会越来越依赖于各种问题专家。

如果你花费职业生涯来做SQL调优，你可能会成为这方面的专家。这意味着类似子系统配置，新功能实施，协调灾难恢复等工作就会被交给其他人去做。这对于DBA职业的发展其实是很不利的。