Fastest Informix DBA

本文来自来自 IBM Data Management Magazine     Lester Knutsen, 总裁, Advanced DataTools Corp.

 

 

在 4 月的 IIUG Informix Conference 上，我们举行了一次最快的 Informix DBA 竞赛。我在一个简单的客户结账流程中添加了一些错误的 SQL，并在默认 ONCONFIG 文件中设置了一些错误的配置选项 —— 重建了日常生活中比较常见的挑战。未修改的基准测试需要运行大约 30 分钟时间，我给参赛者的任务是让它能更快地运行。最快的一名 DBA 让它能在 4 分钟之内运行。在上一期文章中，我讨论了这项挑战并列出了获胜者；这次，我将讲解他们是如何做到的。

首先，分析问题

成功的 DBA 都花费了足够的时间来研究问题。我们在一个文档中描述基准测试，包括所有代码和预期结果。我们还在一个视频中描述了他们需要解决的问题，并展示了如何运行基准测试。

花较长时间研究材料的选手取得了更好的成绩，因为他们可以更好地专注于自己的任务。举例来说，我故意改变了模式，将缓冲流通率设定为非常高的值，而最快的 DBA 在看了数据和模式后发现了这个问题。另外，基准测试系统只有一个磁盘，因此利用 Informix 并行磁盘读取和写入并不没有太大的用处。所有成功的 DBA 首先都研究了问题、分析了事实，然后才开始制订计划。

Informix 配置：ONCONFIG 文件更改在确定如何修改 Informix Dynamic Server (IDS) 配置文件过程中涉及的一项挑战是 ONCONFIG 文件。这些更改专门针对基准测试环境，并且不一定能适用于所有场景，但它们确实能为您提供一些关于 ONCONFIG 文件的启发。

BUFFERPOOL成绩优秀的 DBA 都增加了服务器所使用的缓冲数量。服务器拥有 3 GB RAM。最快的 DBA 使用了几乎一半的 RAM 用作缓冲，创建一个 16 KB 分页大小的 dbspace（大于默认 2 KB 分页大小），并分配了三分之一的内在作为这个 16 KB 分页的缓冲。这解决了记录太大而无法适应默认 2 KB 分页大小的问题，它将记录保存在一起，并将大多数记录放在内存中。总的来说，我认为 BUFFERPOOL 调整对性能的影响最大。

最快的 DBA 还特别控制了 BUFFERPOOL 的大小。而 BUFFERPOOL 过大会造成 OS 开始换出磁盘并会降低整个系统的速度。在添加缓冲时，您还需要考虑 Least Recently Used (LRU) 查询的数量，它们用于管理 BUFFERPOOL 中的所有这些额外的分页。最快的 DBA 增加了 LRU 查询，以便于更加有效地处理额外的内存。

SHMVIRTSIZE，这是 Informix 将分配给工作空间和虚拟内存的内存量。所有较快的 DBA 增加了这个值。而最快的 DBA 增加的最多。SQL 中还有大量 “group by” 语句，因此增加虚拟内存并对 Parallel Database Query (PDQ) 流程执行一些更改可以让任务更多地在内存中完成。

DS_TOTAL_MEMORY，这是 SHMVIRTSIZE 内存中将用于 PDQ 操作的内存量。其默认值非常小，增加这个值有助于排序和索引构建。

DS_NONPDQ_QUERY_MEM，这是在未使用 PDQ 执行排序时分配给排序任务的内存量。由于基准测试系统上只有一个磁盘驱动器，因此 PDQ 并没有太大用处。增加这个参数有助于排序和索引构建。

LOCKS，LOCKS 的数量和它们可用的内存量。如果此配置参数不够大，则 Informix 会动态增加它，但动态增加的值是非常有限的。最快的 DBA 都设置了 LOCKS 的数量，这样服务器就不需要动态增加这个值。

RESIDENT，设置这个值可以将 Informix 维持在内存中，并通知 OS 不要将数据库服务器换出到磁盘中。所有较快的 DBA 都设置了这个值，以便将 Informix 维持在内存中。CPU VP ——基准测试机构采用四核 CPU，并且可以支持四个 Informix CPU 虚拟处理器 (VP)。所有较快的 DBA 都将 CPU VP 的数量设置为 3 到 4 之间，以便于利用机器上的所有 CPU。

DBSPACETEMP，我在基本配置中创建了一个临时的 dbspace，但是并未在 ONCONFIG 文件中定义它，因此未使用它。而是将 rootdbs 用于排序和临时文件。所有较快的 DBA 都修改了 ONCONFIG 文件，在其中标识并定义了这个参数。一些 DBA 甚至创建了两个或三个额外的临时 dbspaces，因此 Informix 可以并行读取和写入 tempdbs。

一些最快的竞赛者还修改了其他 ONCONFIG 参数，包括 PHYSBUFF、LOGBUFF、DIRECT_IO、VP_MEMORY_CACHE_KB 和 CLEANERS。很难确定它们的作用有多大，但最快的 DBA 发现其中一些参数能极大提高速度。我还比较关注哪些参数未被更改。可能是时间不够，但没有人修改过 read-ahead 参数 RA_PAGES 和 RA_THRESHOLD，也没有人修改过 index-cleaning 参数和 BTSCANNER。

Informix 模式更改

我故意在数据库的两个表中使用了非常大的列：客户表中的 CHAR(2000) 列和账单表中的 CHAR(1000) 列。但是，这些空间通常都被浪费了。在客户表中，大约只使用了 100 个字符，而账单表中的字符都没有使用过。这不仅浪费空间，还造成表溢出了 2 KB 分页，从而导致大多数缓冲 Thrashing 非常高的缓冲流通率。有许多解决方案可解决此问题，其中之一是修改表并将这些列转换为 LVARCHAR 列。此更改减少了在基准测试期间读取和写入的缓冲数量，并且可能对总体性能造成了最大的影响。

一些 DBA 还对模式进行了另一项修改，即将账单表的索引创建工作移动到插入了所有数据之后进行，而不是在插入数据之前。这样可以更快地载入没有索引的表，并且创建的索引会更加紧凑和优化。此外，在 IDS 11.50 中，建立索引会对表自动执行 UPDATE STATISTICS HIGH，这将为 Informix 查询优化器提供关于表的更好的信息。一些 DBA 在客户表上添加了额外的索引，这有助于基准测试中的最后一项查询操作。

SQL 优化

基准测试包括两条针对账单的 INSERT 语句和三条 UPDATE 语句。UPDATE 语句还包含一些子查询。在基准测试流程结束时，它执行了两条带 Group By 从句的 SELECT 语句，用于检查数值。最后两条语句生成的数值需要与预期结果相吻合；这正是我们验证基准测试是否成功完成的方式。为增加难度，我还在 SQL 中添加了一些多余的、不必要的代码。

经过精心规划，我认为认为整个流程可以使用一条 INSERT 语句再加上一到两条 UPDATE 语句便可完成，但没人注意到这一点。但是，一些较快的 DBA 确实发现了 SQL 语句中存在一些没有用的代码，并从基准测试流程中删除了这些代码。