整合 DB2 与 AIX 的 WLM 功能进行工作负载管理

核心提示： testusr 用户的访问不能占用过多性能影响主业务；除 testusr 用户以外以他用户和程序不受限，方案与分析其实我们发现很多时候客户的需求是有些笼统的，整合 DB2 与 AIX 的 WLM 功能进行工作负载管理(6)，这就需要我们来具体化，上面的四条也还是不够详细，而这两个操作都是需要用到

testusr 用户的访问不能占用过多性能影响主业务；

除 testusr 用户以外以他用户和程序不受限。

方案与分析

其实我们发现很多时候客户的需求是有些笼统的，这就需要我们来具体化。上面的四条也还是不够详细，我们接下来结合具体技术来逐步分析。

一个只读的 testusr 用户，这很简单，用权限去解决就好了。testusr 用户的访问不能影响主业务，这就比较笼统了，这需要我们更多地了解客户的实际需求，并转换为技术上很具体的东西。首先这里很容易想到使用 AIX WLM 来限制 CPU 资源，这里要注意 testusr 以外的用户是不受限的，那么我们为了简化而选择了 limits 方式没有选择 shares，原因是 shares 方式需要定义所有用户的资源分配。

CPU 资源限制了，testusr 就一定不会影响主业务了么？当然不是，还有很多方法可以占用较少 CPU 但是却能够极大程度地影响总体性能的方法 ( 或者说 SQL 语句 )，比如把磁盘带宽占光。所以这里我们通过了几个方面来进一步限制。首先是限制并发连接数，不过 DB2 WLM 不能直接限制连接数，这点要通过 Query Patroller 这个组件来实现，这里我觉得没有必要把这个简单场景的方案搞得这么复杂，所以我们退而求次选择了限制并发的活动协调代理数（CONCURRENTDBCOORDACTIVITIES）。这就是说我们允许有很大量的 testusr 用户并发连接到数据库，但是能够同时运行 SQL 命令的只有有限的数量。作为补充，我们配合的加上一个限制会话的空闲等待时间（CONNECTIONIDLETIME），这样就可以防止有过多的闲置会话浪费资源了。

对于资源占用有很重要的一点，我们知道，大多情况下很耗资源的 SQL 语句往往都是连接和排序导致的，而这两个操作都是需要用到排序区和临时表空间。那好，我们这里再加上一项临时空间的使用限制（SQLTEMPSPACE）。