简介
不少书籍和文章都对 Informix® Dynamic Server®（IDS）及其体系结构和性能调优进行了详尽论述，但专门讨论监控这一主题的却很少。但在 IDS 管理中有效的监控却至关重要。它能帮助我们收集系统和数据库性能方面有价值的统计信息，还能帮助我们很早就确定问题，以便我们能够在故障诊断和性能调优方面取得主动。在成功地安装和配置 Informix Dynamic Server 并实现了 Informix 数据库以后，对 Informix Dynamic Server 进行监控就成为了数据库管理员的头等大事。
本文将详细讨论如何在各个级别有效地监控 Informix Dynamic Server，同时会就确定 Informix 引擎和数据库问题提供一些常规技巧。文章将同时涵盖故障诊断和性能调优这两个方面。
监控工具
Informix 提供了两个主要的工具来监控系统和数据库性能：
onstat 实用程序。
- sysmaster 数据库中众多的系统监控接口（SMI）表，该数据库是在 IDS 首次初始化时自动创建的。
onstat 实用程序和 SMI 表都通过检查 IDS 共享内存活动来监控 IDS 性能，但它们给出那些统计信息的方式却有所不同。onstat 实用程序总是以固定的方式给出统计信息，而使用 SMI 表则允许您以更有意义、更可读的格式重新组织那些统计信息。
需要注意的一点是，无论是通过 onstat 收集还是在 SMI 表中收集，这些统计信息都是从系统重新引导或 IDS 初始化开始累积而来的。因此，对于那些统计信息我们必须格外小心，并且总是要考虑 IDS 运行时间。例如，服务器运行超过一个月所累积的 100000 条 bufwait 与一天所累积的 100000 条 bufwait 就完全不同。要获取当前的统计信息，我们必须执行 onstat -z 以清除旧值。
Informix 还提供了一个图形监控工具 — onperf。onperf 收集 IDS 服务器的性能统计信息，并将它们描绘成度量值。它还可以将那些统计信息保存为文本文件以供日后分析。请参考 Performance Guide for Informix Dynamic Server 以获取更多有关 onperf 实用程序的详细信息。
IDS 活动可以分为三类：
通过使用上面讨论的工具，我们可以有效地监控所有那些 IDS 活动。
监控实例活动
IDS 实例是指 Informix 共享内存、Informix 处理器、Informix 数据库以及分配给 Informix 的物理设备。以下是部分需要监控的最重要的实例活动。
操作方式
第一个也是最重要的实例活动当然是 IDS 的操作方式。IDS 运行正常还是有问题，或是已当机了？onstat -p 命令捕获了 IDS 的当前操作方式，如下所示：
Informix Dynamic Server 2000 Version 9.21.UC4 -- On-Line -- Up 01:01:17 --
1654784 Kbytes
Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
86923 101304 3116565 97.21 1651 15022 26196 93.70
isamtot open start read write rewrite delete commit rollbk
2585879 118500 286631 1032967 1972 914 2 2 0
gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0
ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 478.11 71.63 13 26
bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
3502 0 7065882 0 0 0 1266 11280
ixda-RA idx-RA da-RA RA-pgsused lchwaits
10120 51 69387 79557 482
我们也可以查询 sysmaster 数据库中的 sysprofile 表来获取同样的统计信息。
输出的第一行显示了当前的 IDS 操作方式。本例中，Informix 引擎是“On-Line”。总共有六种操作方式，其中三种特别重要：Off-Line、Quiescent 和 On-Line。Off-Line 方式表明 IDS 当前没有在运行。Quiescent 方式表明 IDS 正在以单用户方式运行，在这种方式下，只有 DBA 可以进行管理和维护工作。On-Line 方式表明 IDS 正在正常运行，所有用户都可以连接到数据库服务器，并可以执行各种数据库操作。在大多数情况下，IDS 应该始终处于 On-Line 方式。如果因为种种原因 IDS 当机了或处于 Off-Line 方式，那么上面的命令将显示下面的消息：
Shared memory not initialized for INFORMIXSERVER 'cassprod_shm'
在这种情况下，您需要检查消息日志或 Informix 联机日志，以进一步确定问题的根源（请参阅消息日志）。
除了当前的操作方式以外，上面的输出还提供了一些重要的 Informix 实例性能统计信息。两个 %cache 字段表明 IDS 目前使用内存高速缓存的效率。第一个 %cache 字段显示了读高速缓存比例的百分比，而第二个则显示了写高速缓存比例。读高速缓存比例和写高速缓存比例会随应用程序及正在操作的数据的类型和大小而动态变化。但读高速缓存比例和写高速缓存比例一般都应该在 80 到 90 个百分点之间。这是十分保守的数字，应该根据具体环境加以调整。如果这些比例始终低于 80%，那么您需要考虑提高 Informix 配置文件中 BUFFERS 参数的值，以获取较高的读写高速缓存比例。较低的读写高速缓存比例表明 IDS 正在进行的磁盘读写操作比它应该进行的要多得多，这会大大降低数据库引擎的整体性能。
输出的 seqscan 字段表明自数据库启动或联机以来执行了多少次顺序扫描。如果这个数字相当大，比如说超过了 100000，并且还在不断增加，那么这可能表明性能有问题，当系统处于 OLTP 环境时更是如此。因而，您需要做进一步的调查以搞清楚出现过多顺序扫描的根源。在本文的后面我们将更详细地讨论这一问题。
ovlock 字段表明 IDS 在使用了最大数量的锁之后尝试过再使用锁的次数。如果该数字非零，那么您可能需要提高配置文件中 LOCKS 参数的值。ovbuf 字段表明 IDS 在使用了最大数量的缓冲区之后尝试过再使用缓冲区的次数。如果该数字很大，比如说超过 100000，那么您需要提高 BUFFERS 参数，以便用户在需要从磁盘访问数据时不必等待缓冲区。这会缩短响应时间，因而可以改善整体性能。我们还需要检查与 LRU 有关的参数，将它们的值调整到较低的 bufwait。请参考 Administrator's Guide for Informix Dynamic Server 以获取更多详细信息。
另一组重要字段包括 ixda-RA、idx-RA、da-RA 及 RA-pgused。这些字段组合在一起表明 IDS 使用 Informix 预读机制的效率。预读是这样一种操作：它在顺序扫描或索引读期间提前将数据页的数目从磁盘读入内存。理想情况是，预读的页数（即 ixda-RA、idx-RA 和 da-RA 之和）等于顺序扫描或索引读期间所使用的页数（即 RA-pgused）。这表明预读的页百分之百地用于顺序扫描和索引读。如果二者之间存在显著的差异，比如正负差值达到 10000 以上，那么 IDS 目前就没有很有效地使用预读，而您可能需要调优您的预读参数（即 RA_PAGES 和 RA_THRESHOLD）以获取更好的性能。请参考 Administrator's Guide for Informix Dynamic Server（本文称为 Administrator's Guide）以获取有关如何调优这些参数的详细信息。
消息日志也称为联机日志。它含有各种有关关键实例活动的信息，如检查点的时间和持续时间、实例启动和停止、备份和恢复状态、逻辑日志备份状态以及对主要配置参数的更改。消息日志还包含关键的错误（Informix 称之为断言失败），如磁盘 I/O 错误、镜像错误、当机块、数据完整性错误以及共享内存错误等等。在发生断言失败时，消息日志通常会将我们引向有关断言失败的（“af.xxx”）文件，该文件会记录在数据库引擎当机时有关实例活动的更详细信息，还会就如何解决这一问题给我们提供一些建议。以下内容摘自消息日志：
00:57:53
00:57:53 Assert Failed: Unexpected virtual processor termination, pid =586, exit = 0x9
00:57:53 Who: Session(13709, omcadmin@nvlsys, 6538, 654709000)
Thread(13740, sqlexec, 2704a558, 1)
00:57:53 Results: Fatal Internal Error requires system shutdown
00:57:53 Action: Restart OnLine
00:57:53 See Also: /var/tmp/af.35acfee1
00:57:53 Stack for thread: 13740 sqlexec
上面的输出告诉我们：某个 Informix 虚拟处理器终止了，并毁坏了数据库引擎。当用户“omcadmin”登录到名为 nvlsys 的机器并执行了一些数据库操作（大部分是未正确执行的 SQL 查询），该机器上发生了这一错误。文件 /var/tmp/af.35acfeel 记录了出错时有关数据库引擎状态的详细统计信息。
块状态
块是物理存储设备。它们应该始终联机。如果有任何块当机了，那么这表明数据遭到毁坏，需要立即引起注意。onstat -d 命令监控当前的块状态，以下是该命令的输出：
Informix Dynamic Server 2000 Version 9.21.UC4 -- On-Line -- Up 7 days 23:35:56 --
1654784 Kbytes
Dbspaces
address number flags fchunk nchunks flags owner name
6510c7d0 1 0x1 1 1 N informix rootdbs
65866468 2 0x1 2 4 N informix airgen_idx_dbs
658665b0 3 0x1 3 3 N informix spare
658666f8 4 0x1 4 5 N informix logs
65866840 5 0x1 5 2 N informix pm1
65866988 6 0x1 7 1 N informix pm_gen
65866ad0 7 0x2001 8 1 N T informix temp_dbspace2
65866c18 8 0x1 10 2 N informix pm2
65866d60 9 0x1 11 3 N informix airgen_main_dbs
65866ea8 10 0x1 14 1 N informix mso_meta
65867018 11 0x1 16 2 N informix pm3
65867160 12 0x2001 18 1 N T informix temp_dbspace3
658672a8 13 0x2001 20 1 N T informix temp_dbspace1
658673f0 14 0x1 25 2 N informix pm4
65867538 15 0x2001 29 1 N T informix temp_dbspace4
15 active, 2047 maximum
Chunks
address chk/dbs offset size free bpages flags pathname
6510c918 1 1 0 63069 51985 PO- /usr/informix/dblink
6514b5f0 2 2 65000 750000 1 PO- /usr/informix/dblink
6514b760 3 3 815000 60000 59747 PO- /usr/informix/dblink
6514b8d0 4 4 875000 125000 4947 PO- /usr/informix/dblink
6514ba40 5 5 0 1000000 299290 PO- /usr/informix/dblink1
6514bbb0 6 2 0 1000000 207877 PO- /usr/informix/dblink2
6514bd20 7 6 0 200000 179043 PO- /usr/informix/dblink3
6514be90 8 7 200000 250000 249939 PO- /usr/informix/dblink3
6510ca88 9 3 450000 250000 249997 PO- /usr/informix/dblink3
6510cbf8 10 8 0 1000000 299086 PO- /usr/informix/dblink4
6510cd68 11 9 0 1000000 4 PO- /usr/informix/dblink5
6513c830 12 9 0 500000 10 PO- /usr/informix/dblink6
6513c9a0 13 8 500000 300000 299997 PO- /usr/informix/dblink6
6513cb10 14 10 800000 200000 27596 PO- /usr/informix/dblink6
6513cc80 15 9 0 1000000 782331 PO- /usr/informix/dblink7
6513cdf0 16 11 0 1000000 296827 PO- /usr/informix/dblink8
65865018 17 4 0 400000 9997 PO- /usr/informix/dblink9
65865188 18 12 400000 250000 249947 PO- /usr/informix/dblink9
658652f8 19 5 0 300000 299997 PO- /usr/informix/dblink10
65865468 20 13 300000 250000 249947 PO- /usr/informix/dblink10
658655d8 21 4 550000 150000 14997 PO- /usr/informix/dblink10
65865748 22 4 0 350000 4997 PO- /usr/informix/dblink11
658658b8 23 11 350000 300000 299997 PO- /usr/informix/dblink11
65865a28 24 2 0 1000000 999997 PO- /usr/informix/dblink12
65865b98 25 14 0 1000000 299014 PO- /usr/informix/dblink13
65865d08 26 2 0 750000 749997 PO- /usr/informix/dblink14
65865e78 27 4 750000 250000 39997 PO- /usr/informix/dblink14
65866018 28 14 0 300000 299997 PO- /usr/informix/dblink15
65866188 29 15 300000 250000 249939 PO- /usr/informix/dblink15
658662f8 30 3 550000 50000 49997 PO- /usr/informix/dblink15
30 active, 2047 maximum
上面的输出包含两部分。第一部分列出了所有的 dbspace，第二部分则列出了所有的块。在块（Chunk）部分中，我们需要特别注意 flags 字段。该字段的第一个字符表明块是主（P）块还是镜像（M）块。第二个字符表明块的当前状态，是联机（O）还是脱机（D）。由于 O 和 D 看起来很相象，尤其是您匆匆一瞥时，因此您可能想将结果用管道输入到 grep PD，即 onstat -d |grep PD，以确保您不会遗漏任何当机块。如果有任何主块当机，那么您需要立即从备份磁带执行冷或暖恢复，以确保数据完整性。我们也可以查询 sysmaster 数据库中的 syschunks 和 sysdbspaces 表来获取类似的统计信息。
检查点
检查点是使磁盘上的页与共享内存缓冲池中的页同步的过程。在检查点期间，IDS 阻止用户线程进入临界会话，并阻止所有的事务活动。因此，如果检查点持续时间过长，那么用户可能会经历系统挂起。在存在几千个事务并且响应时间至关重要的 OLTP 环境中，情况尤其如此。正如上面所解释的那样，可以通过查看消息日志来监控检查点持续时间，但更好更快的方法是使用 onstat -m 命令。以下是该命令的样本输出：
15:25:10 Checkpoint Completed: duration was 0 seconds.
15:25:10 Checkpoint loguniq 231, logpos 0x1bb2018
15:35:30 Checkpoint Completed: duration was 19 seconds.
15:35:30 Checkpoint loguniq 231, logpos 0x31b9018
Fri Dec 20 11:48:02 2002
11:48:02 Checkpoint Completed: duration was 7 seconds.
11:48:02 Checkpoint loguniq 231, logpos 0x32e5018
14:27:37 Logical Log 231 Complete.
14:27:40 Process exited with return code 142: /bin/sh /bin/sh -c
/usr/informix/etc/log_full.sh 2 23 "Logical Log 231 Complete." "Logical Log 231
Complete."
14:28:24 Checkpoint Completed: duration was 22 seconds.
14:28:24 Checkpoint loguniq 232, logpos 0x458018
14:38:46 Checkpoint Completed: duration was 7 seconds.
14:38:46 Checkpoint loguniq 232, logpos 0x10f5018
如果检查点持续时间始终超过 10 秒，那么您可能需要减少 LRU_MIN_DIRTY 和 LRU_MAX_DIRTY 配置参数的值以获取更短的检查点持续时间。同样，如果 onstat -F 的输出显示极高的块写（比如高于 10000），并且这个数字还在不断增加，那么这可能表明出现了以下两个问题中的一个：要么检查点时间间隔太短，从而在检查点之间清除程序没有足够的时间将所有经过修改的缓冲区写入磁盘，要么 AIO VP 太少，无法在检查点期间共享繁重的磁盘写。这样，您需要重新检查 CKPINTVL、LRUS、CLEANERS 和 NUMAIOVPS 配置参数的设置，并相应地增加它们的值。我们可能还需要查看 onstat -F 的输出来作为确定那些参数值的参考。有关如何调优那些参数的详细信息，请参考 Administrator's Guide。
dbspace 使用情况
Informix 数据库管理员要不断了解各个 dbspace 中的空间，这一点十分重要。如果某个 dbspace 缺少空间或把空间用完了，那么 IDS 会碰到麻烦。各种问题都可能出现：无法导入任何数据库，无法创建任何表和索引，甚至无法对任何表和索引执行插入和更新操作。这一点对于生产数据库至关重要。我们需要监控每个 dbspace 的增长，以便能够对这些问题采取更主动的方法。下面的脚本报告了各个 dbspace 的当前空间使用情况，并计算其百分比。
select name dbspace, sum(chksize) allocated, sum(nfree) free,
round(((sum(chksize) - sum(nfree))/sum(chksize))*100) pcused
from sysdbspaces d, syschunks c
where d.dbsnum = c.dbsnum
group by name
order by name
输出如下所示：
dbspace allocated free pcused
airgen_idx_dbs 1000000 763405 24
airgen_main_dbs 1500000 295789 80
llog 1000000 9947 99
rootdbs 50000 36220 28
temp1 250000 249947 0
temp2 250000 249939 0
上面的输出有助于我们确定哪些 dbspace 已把空间用完了。要取得主动，请考虑在某个 dbspace 的磁盘使用情况接近 90% 时向该 dbspace 分配额外的磁盘空间；本例中，我们需要特别注意 llog dbspace，并且可能的话，就给它分配更多空间，以防止它把空间用完。
dbspace I/O
Dbsapce I/O 是由磁盘读和磁盘写来衡量的。如果某些 dbspace 有繁重的磁盘读写操作，而另外一些 dbspace 几乎不进行任何读写操作，那么系统可能会出现一些磁盘 I/O 瓶颈。平衡得较好的 dbspace I/O 将减轻系统磁盘 I/O 负载，从而会改善系统的整体性能。以下脚本将显示各个 dbspace 的当前 I/O 统计信息：
select d.name, fname[15,25] path_name, sum(pagesread) diskreads,
sum(pageswritten) diskwrites
from syschkio c, syschunks k, sysdbspaces d
where d.dbsnum = k.dbsnum
and k.chknum = c.chknum
group by 1, 2
order by 1
输出如下所示：
name path_name diskreads diskwrites
airgen_idx_dbs uild95/ltmp 3672 7964
airgen_main_dbs uild95/ltmp 13545 32903
llog uild95/ltmp 19 51633
rootdbs uild95/ltmp 211 43117
temp1 uild95/ltmp 3015 3122
temp2 uild95/ltmp 3218 3317
我们的目标是要使所有的 dbspace 都有平衡的磁盘读写操作。在大多数情况下，这是不现实的，但上面的输出至少让您对 dbspace I/O 的分配方式有了一个概念，可以帮助您标识“最热门的”dbspace — 那些磁盘读写最多的 dbspace。如果有些 dbspace 的磁盘读写操作相当繁忙而另外一些的读写操作则相当空闲，那么您可能需要为 Informix 引擎调整甚至重新安排物理磁盘布局。我们可以使用 onstat -D 和 onstat -g ioq 获得类似的信息，前者显示各个块的磁盘读和写，而后者显示磁盘 I/O 等待队列信息。
您可以通过查询 sysmaster 数据库中的 sysptprof 表来进一步标识哪些表具有最多的磁盘读写操作：
select dbsname, tabname, (isreads + pagreads) diskreads, (iswrites + pagwrites)
diskwrites
from sysptprof
order by 3 desc, 4 desc
输出类似于：
dbsname tabname diskreads diskwrites
airgen_10_0 fanout_param 84567 3094
airgen_cm_db sysindices 78381 0
airgen_10_0 ne_nmo_i 75819 5
airgen_10_0 ne_nmo 75440 297
airgen_cm_db sysprocbody 62610 28322
airgen_10_0 systables 37342 466
airgen_10_0 syscolumns 34539 4609
airgen_10_0 457_484 32838 42
airgen_10_0 453_480 30009 1
airgen_10_5_old syscolumns 29531 4550
airgen_10_5 syscolumns 28824 4552
airgen_10_0 456_483 25448 14
airgen_10_0 458_485 23278 177
airgen_10_5_old 452_483 22412 31
根据从这个查询获得的输出，您可能需要在 dbspace 间移动一些表以使磁盘 I/O 平衡得更好。
共享内存段
太多的虚拟共享内存段（通常多于三个）表明：最初的虚拟共享内存段太小，数据库引擎必须不断分配额外的虚拟共享内存段。这反过来影响了 IDS 性能，并且最终会损害系统的性能。onstat -g seg 命令显示了 Informix 数据库引擎目前拥有多少共享内存段：
Informix Dynamic Server 2000 Version 9.21.UC4 -- On-Line -- Up 28 days
15:49:33 -- 205824 Kbytes
Segment Summary:
id key addr size ovhd class blkused blkfree
0 1381386241 a000000 177209344 220688 R 42984 280
1 1381386242 14900000 8388608 856 V 2048 0
2 1381386243 15100000 1048576 632 M 164 92
3 1381386244 15200000 8388608 856 V 2048 0
4 1381386245 15a00000 8388608 856 V 2008 40
5 1381386246 16200000 8388608 856 V 50 1998
Total: - - 211812352 - - 49302 2410
(* segment locked in memory)
如果输出显示虚拟共享内存段多于三个，那么您需要提高配置文件中 SHMVERSIZE 参数的值。其思想是，让 IDS 在初始化时分配足够的虚拟共享内存，以便在用户登录到系统并执行数据库操作时无需分配更多的虚拟共享内存。您可能还想使用 UNIX® ipcs 命令来查看 Informix 共享内存的大小。有关如何计算 IDS 虚拟共享内存段大小的详细信息，请参考 Administrator's Guide。
操作系统的整体性能
由于 Informix 数据库引擎总是安装在某个操作系统（主要是 UNIX）上，以准确地监控或评估 IDS 性能，因此我们需要将操作系统的行为作为一个整体来考虑，在数据库引擎驻留在非专用数据库服务器上时尤其要这样考虑。如果 IDS 占用了太多 RAM（例如，如果系统有 512MB RAM，而 IDS 占用了 400MB 或更多作为其共享内存），那么当用户执行内存密集型操作时，操作系统可能会经历频繁的交换和挂起。当内存不足时，系统必须将一些数据页从内存交换到磁盘，以便为新数据腾出更多空间。如果系统内存不足，那么 CPU 可能也会遭殃。有不少 UNIX 实用程序可以监控操作系统 CPU 和内存的整体利用率。以下是来自“top”实用程序的输出：
load averages: 1.12, 1.02, 1.07 10:17:30
123 processes: 120 sleeping, 1 zombie, 2 on cpu
CPU states: 70.5% idle, 26.5% user, 2.8% kernel, 0.3% iowait, 0.0% swap
Memory: 3072M real, 76M free, 588M swap in use, 440M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
28349 omcadmin 4 0 0 86M 55M cpu10 970:25 6.85% CS_App.prt
17782 informix 5 30 -10 1631M 1594M sleep 50.0H 4.66% oninit.exe
17784 informix 5 59 -10 1631M 1594M sleep 102.9H 4.12% oninit.exe
17786 informix 5 59 -10 1631M 1591M sleep 25.5H 2.53% oninit.exe
571 root 1 58 0 361M 129M sleep 19.0H 1.36% em_mis
17785 informix 5 59 -10 1631M 1592M sleep 57.8H 1.05% oninit.exe
5470 omcadmin 1 0 0 1960K 1408K cpu15 0:00 0.26% top
上面的输出包含两部分。第一部分为您汇总了操作系统的 CPU 和内存的整体使用情况，第二部分则提供了有关每个处理器的详细信息。其它实用程序（如 vmstat、iostat、ps -ef 和 sar）在收集操作系统当前的性能统计信息方面也很有用。vmstat 显示目前操作系统交换了多少内存；iostat 和 sar 显示了当前在所有物理磁盘中磁盘 I/O 的分配；而 ps -ef 打印出当前各个处理器的登录时间、CPU 及内存使用情况的详细信息。此外也有许多图形工具可用，这些工具使您能够绘制操作系统资源利用率和性能的动态变化。
监控数据库活动
对数据库活动进行监控的目的在于确保每个数据库时刻都将其能力发挥到了极致。这意味着：您必须留意潜在的性能问题，确定其根源并将其消灭在萌芽状态。以下是要留意的几个方面。
表扩展块
扩展块是一块物理上连续的页。然而，如果一个表有多个扩展块，那就不能保证这些扩展块是连续的；扩展块可能会散布在表所驻留的整个 dbspace 上。物理页的连续性对于性能十分重要。当数据页连续时，访问磁盘数据所用的时间就最短，而数据库也能连续地读取行。如果表有太多扩展块，那么那些扩展块极有可能相互交错。这极大地影响了性能，因为当您检索某个表的数据时，磁头需要对属于该表的多个非连续扩展块进行寻道，而不是对具有连续物理页的一个大扩展块进行寻道。这会显著地降低磁盘寻道速度。下面的脚本检测具有多个扩展块的数据库表：
select t.tabname, count(*) num_ext
from sysmaster:sysextents e, airgen:systables t
where e.tabname=t.tabname
and dbsname = "airgen"
and t.tabname not like "sys%"
group by 1
having count(*) > 1
order by 2 desc
输出如下所示：
tabname num_ext
nmoattrclassmap 14
attrclass 11
networkmoclass 3
fanout_param 3
fanout_comp 2
ne_nmo 2
nenmoclassmap 2
join_map 2
如果除了大型分段表以外，任何表的扩展块超过了 10 个，那么您应该考虑重新构建这些表以合并扩展块。对于较大的数据库或者大小设置不是很好的数据库，我们可能还会关注扩展块的最大数目，或者会担心针对索引的 32GB 限制。有关如何对表估计和分配数据块大小的详细信息，请参考 Performance Guide。
索引层
索引的层数也可能会对性能产生不利影响。索引层越多，IDS 到达索引叶节点所需的探测也就越多。而且，如果叶节点被拆分或合并，那么整个索引对这一变化进行调整将要花费更多的时间。例如，如果索引只有两层，那么只需要调整两层，但如果索引有四层，那么相应地就需要对所有四层进行调整。用于这一调整的时间当然也就长得多。在 OLTP 环境中会进行频繁的插入、删除和更新，这些操作会导致不断地对索引进行拆分和合并，因此上述问题也就格外明显。下面的脚本标识每个索引的层数：
select idxname, levels from sysindexes
order by 2 desc
输出如下所示：
idxname levels
objdesc 3
fanout_param_i 3
458_485 3
457_484 3
idxname 2
tabgtor 2
tabgtee 2
如果哪个索引超过了 4 层，您可能就需要考虑删除和重新构建该索引，从而合并其层，以获取更好的性能。
索引唯一性
索引的重复程度很高会严重地影响更新和删除的性能。假定表 customer 的 customer_type 列上有一个索引，而可能的 customer_type 代码只有五种。如果这个表有一百万行，那么可能有 200000 行具有相同的 customer_type 代码。B-树存储键值，其后跟一个指向每个物理行的指针列表。在必须删除或更新任何键值时，问题出现了。IDS 必须找遍所有的重复内容，直到找到要删除或更新的正确键为止！
下面的脚本用来标识重复程度很高的索引：
select tabname, idxname, nrows, nunique
from systables t, sysindexes I
where t.tabid =i.tabid
and t.tabid > 99
and nrows > 0
and nunique > 0
输出如下所示：
tabname idxname nrows nunique
bsc_dte bscdte_i 6 6
omcgttready 231_413 1 1
systemrelease 451_478 3 3
neclass 452_479 31 12
sysrelneclassmap 453_480 33 3
proxynemgrmap 454_481 1 1
networkmoclass 455_482 362 199
nenmoclassmap 456_483 492 12
attrclass 457_484 1191 924
nmoattrclassmap 458_485 2901 199
fanout_comp fanout_comp_i 915 199
fanout_comp fanout_comp_i2 915 199
fanout_comp fanout_comp_i3 915 82
fanout_param fanout_param_i 2894 196
在理想情况下，nunique 列中所出现的全部值都应该与 nrow 列中的全部值相等，即索引中的每个键都是唯一的。根据行数（上面的 nrows 列）和唯一键数（上面的 nunique 列），我们可以计算每个索引唯一性的百分率：
(nunique/nrows)*100
百分率越高，索引的唯一性就越高。为了避免因索引重复程度很高而引起的性能瓶颈，您可以使用复合索引来替换原来的索引，复合索引结合了重复程度很高的列与唯一性比较高的列。利用上面的示例，您可以将主键列 customer_id 添加到原来的索引，将它变成一个复合列（例如，“create index index_name on customer (customer_type, customer_id)”）。
顺序扫描
对表进行顺序存取有时会降低性能，因为数据库引擎必须扫描整个表以选取满足查询条件的行。如果表很小，比如说几百行，那么顺序存取不会对性能造成什么影响；因为当数据库引擎第一次扫描它时，该表会驻留于内存中，而当数据库引擎下一次扫描它时，可以直接从内存检索该表中的所有数据。这实际上是使用顺序扫描的有效方式。但如果表很大，比如说超过了 100000 行，那么重复的顺序扫描会对性能造成致命的影响。下面的脚本将标识具有多重顺序扫描的表：
select dbsname, tabname, sum(seqscans) tot_scans
from sysptprof
where seqscans > 0
and dbsname not like "sys%"
group by 1,2
order by 3 desc
输出如下所示：
dbsname tabname tot_scans
airgen_10_0 systemrelease 2352
airgen_10_5_old systemrelease 1596
airgen_10_5 systemrelease 1596
airgen_10_0 fanout_comp 1587
airgen_10_5_old sysusers 1248
airgen_10_0 sysusers 1241
airgen_10_5 sysusers 1231
airgen_10_0 join_map 1036
airgen_10_0 fanout_param 958
airgen_10_0 func_call 770
airgen_10_5 nenmoclassmap 586
airgen_10_5_old nenmoclassmap 586
从上面的输出可以看出 airgen_10_0 表的顺序扫描数很高。如果它是一个具有几千甚至几百万行的大表，那么您可能需要考虑向该表添加一些索引，或者考虑使用程序伪指令来强制内部查询优化器为访问该表中的数据选择索引而不是顺序扫描。
监控会话活动
有关会话活动的统计信息在确定潜在的性能问题及故障诊断方面很有用。使用本文前面讨论的监控工具，我们可以收集哪些会话活动统计信息呢？
常规会话统计信息
sysmaster 数据库中的 syssessions 表存储各个会话的常规信息，如登录名、登录时间、会话所登录的主机机器、操作系统的进程标识和当前状态等等。可以使用以下查询来查询该表来获取全部此类信息：
select sid, username, hostname, connected logint_time,
hex(state) s_state
from syssessions
输出类似于：
sid username hostname logint_time s_state
233989 omcadmin localhost 1041348844 0x00080021
233982 omcadmin gcsys-e1 1041348608 0x00080001
233981 omcadmin nysys4-e1 1041348608 0x00080001
233980 omcadmin nysys5-e1 1041348608 0x00080001
233979 omcadmin ffsys-e1 1041348608 0x00080001
233973 omcadmin nysys1 1041348608 0x00080001
233781 wsadmin2 gcmmi 1041346036 0x00080001
233697 omcadmin localhost 1041344008 0x00080001
233694 wsadmin4 nymmi1 1041343932 0x00080001
233693 wsadmin4 nymmi1 1041343932 0x00080001
230550 omcadmin nysys1 1041293396 0x00080001
230476 omcadmin ffsys-e1 1041292665 0x00080001
230421 omcadmin gcsys-e1 1041292365 0x00080001
230278 omcadmin nysys5-e1 1041291208 0x00080001
s_tate 是一个指出会话的当前活动状态的十六进制数，请参考 Administrator's Guide 的第 27-38 页，以获取对这其中每个活动状态的详细描述。login_time 是一个指出会话登录时间的整数，使用 C 程序很容易将它转换成常规时间格式。可以向 Informix 技术支持请求以获取该 C 程序。
sysmaster 数据库中的 syssesprof 表提供了各会话的更多详细信息。使用以下查询，您可以更好地理解各个会话是如何与数据库交互的：
select sid, (isreads+bufreads+bufwrites+pagreads+pagwrites) access, locksheld,
seqscans, total_sorts, dsksorts
from syssesprof
输出如下所示：
Sid access locksheld seqscans tot_sorts disksorts
233982 246 0 2 0 0
230421 7789 12 456 1000 0
225679 9981 213 669 876 2
247869 10098 440 578 98 2
78 70 45 6 0 0
447 46 89 6 0 0
access 字段显示了会话命中数据库的次数。locksheld 显示各会话正使用多少锁。seqscans 表明各会话使用顺序扫描访问数据的次数；如果该数字太高，比如说高于 100000，那么您可能要质疑会话是否曾经使用过索引来检索数据，而且要更仔细地检查其查询执行计划以确定它是否最佳。total_sorts 和 dsksorts 表明各会话使用内存进行排序操作的效率。您可能会使用以下公式来计算各会话使用内存进行排序的百分数：
((total_sorts - dsksorts)/total_sorts)*100
该百分数越高，排序操作效率也就越高。您可以将 syssessions 表与 syssesprof 表连接以进一步确定每个会话的用户名和主机机器名，以便了解哪些地方可能会出现数据库和系统问题。以下查询可以检索所有这类信息：
select username, hostname,
(isreads+bufreads+bufwrites+pagreads+pagwrites) access, locksheld, seqscans,
total_sorts, dsksorts
from syssessions s, syssesprof f
where s.id =f.sid
您也可以将 syssessions 表与 syslocks 表连接以获取关于锁的更多详细信息，如哪个会话当前锁定了哪个数据库中的哪个表，以此来帮助您确定各用户之间潜在的锁冲突：
select owner, username, hostname, dbsname, tabname, type
from syssessions s, syslocks l
where sid = owner
and tabname not like "sys%"
输出类似于：
Owner username hostname dbsname tabname type
1422 wsine apple prod customer S
1567 jlinder sys3524 dev products S
2237 ejhonson case prod orders X
6679 cjz020 sys4800 dev shipment S
889654 jfjianing omega test prices X
77622 hong build50 test items S
如果在锁使用方面存在某些冲突，例如某个用户需要对已被别的用户锁定的表进行专有访问，那么您可以方便地确定该锁的所有者，并根据用户的优先级发出 onmode -z sid 命令来杀死会话，然后释放该锁；sid 这个编号是从上面输出中的 owner 字段中获取的；请注意，只有用户“Informix”可以执行该命令。
查询统计信息
查询统计信息对于故障诊断和查询优化至关重要。onstat -g sql sid 命令捕获当前会话的查询及相关统计信息；其中 sid 是会话标识，它可以通过硬编码手工插入，也可以通过 UNIX shell 脚本动态插入。例如，如果您想知道某个会话正在执行什么查询，那么您可能要首先使用命令 onstat -g ses 来查明其会话标识，然后将该标识插入上面的命令。例如，如果您想监控的会话标识为 28953，那么您可以使用 onstat -g sql 28953 来捕获其当前查询。
输出如下所示：
Informix Dynamic Server 2000 Version 9.21.UC4 -- On-Line -- Up 38 days
11:26:22 -- 1654784 Kbytes
session #RSAM total used
id user tty pid hostname threads memory memory
134709 omcadmin 3 29580 localhos 1 65536 61120
tid name rstcb flags curstk status
147311 sqlexec 6511e728 Y--P--- 1648 6511e728 cond wait(netnorm)
Memory pools count 1
name class addr totalsize freesize #allocfrag #freefrag
134709 V 669b9020 65536 4416 162 6
name free used name free used
overhead 0 1648 scb 0 96
opentable 0 6000 filetable 0 920
log 0 2152 temprec 0 1608
keys 0 192 ralloc 0 20480
gentcb 0 1256 ostcb 0 2520
sort 0 56 sqscb 0 11960
sql 0 40 rdahead 0 640
hashfiletab 0 280 osenv 0 1584
buft_buffer 0 4272 sqtcb 0 3240
fragman 0 2176
Sess SQL Current Iso Lock SQL ISAM F.E.
Id Stmt type Database Lvl Mode ERR ERR Vers
134709 SELECT mso_db CR Not Wait 0 0 9.03
Current SQL statement :
SELECT ne_type, config_set_version FROM ne WHERE ne_inst = 46176 AND
msospace_id = 1
Last parsed SQL statement :
SELECT ne_type, config_set_version FROM ne WHERE ne_inst = 46176 AND
msospace_id = 1
输出的第一部分给出了关于正在执行的查询的一些常规统计信息，如对哪个数据库执行查询、其隔离级别以及锁方式。最有趣的两个字段是 SQL error 和 ISAM error。如果这些字段非零，就表明查询出了一些问题，没有正确地执行。可以使用 Informix finderr 实用程序来查明到底是什么问题，随后在解决了该问题之后，杀死该会话并重新执行该查询。
“Current SQL statement”部分显示了正在执行的查询的完整 SQL 语法。它对于诊断问题查询和查询优化非常有帮助。如果您发现了该查询的一些问题，如响应时间太长，消耗了太多的系统 CPU 或内存，那么您可以按其显示状态为该查询制作一个副本，以便稍后研究和分析之用。您随后可以对 Informix dbaccess 实用程序运行同一个查询，以获取该查询性能方面更多详细的统计信息（如其执行计划和连接策略），从而确定问题的根源。根据研究所收集的统计信息，您可以进一步优化查询以获取更好的性能。“Last parsed SQL statement”部分显示了在内存中已经过解析的查询。由于在内存中已经解析过的查询在大多数情况下都是正在执行的查询，因此这一部分与前一部分在大多数时候都是相同的。
最后的一些技巧
要想在监控方面采取更主动的方式，您可以在 IDS 安装期间修改由 Informix 提供的警报程序。警报程序实际上是一个 UNIX shell 脚本，在发生某些错误时 IDS 会自动调用该脚本。IDS 将所有的实例错误分为五个严重性级别：第一级最低，第五级最高。您可以设置警报程序，使之能够在发生实例断言失败时向 DBA 发送电子邮件，或者向 DBA 的寻呼机发送消息。有关如何修改警报程序和样本程序的详细信息，请参考 Administrator's Guide 及 Performance Guide。
此外，您还应该执行一些必要的维护例程，以确保数据库健康运行。一些基本的例程是：
- 验证和修复数据及索引完整性
- 为查询优化器更新内部统计信息
- 回收无用的共享内存段
结束语
监控 Informix Dynamic Server 的性能是一项正在进行的任务。这项任务的价值并不在于收集统计信息本身，而在于确定和解决潜在的系统和数据库问题。
通过本文中所描述的这些有效的监控实践，我们将能够成功地在最初阶段确定系统和数据库问题，这样我们就能够采取更为主动的方式来进行故障诊断和性能调优。
