informix onstat

监控工具
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
我们也可以查询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 方式，那么上面的命令将显示下面的消息：
在这种情况下，您需要检查消息日志或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”）文件，该文件会记录在数据库引擎当机时有关实例活动的更详细信息，还会就如何解决这一问题给我们提供一些建议。

以下内容摘自消息日志：
上面的输出告诉我们：某个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 的当前空间使用情况，并计算其百分比。

输出如下所示：
上面的输出有助于我们确定哪些dbspace 已把空间用完了。

要取得主动，请考虑在某个dbspace 的磁盘使用情况接近90% 时向该dbspace 分配额外的磁盘空间；本例中，我们需要特别注意llog dbspace，并且可能的话，就给它分配更多空间，以防止它把空间用完。

dbspace I/O
Dbsapce I/O 是由磁盘读和磁盘写来衡量的。

如果某些dbspace 有繁重的磁盘读写操作，而另外一些dbspace 几乎不进行任何读写操作，那么系统可能会出现一些磁盘I/O 瓶颈。

平衡得较好的dbspace I/O 将减轻系统磁盘I/O 负载，从而会改善系统的整体性能。

以下脚本将显示各个dbspace 的当前I/O 统计信息：
输出如下所示：
我们的目标是要使所有的dbspace 都有平衡的磁盘读写操作。

在大多数情况下，这是不现实的，但上面的输出至少让您对dbspace I/O 的分配方式有了一个概念，可以帮助您标识“最热门的”dbspace —那些磁盘读写最多的dbspace。

如果有些dbspace 的磁盘读写操作相当繁忙而另外一些的读写操作则相当空闲，那么您可能需要为Informix 引擎调整甚至重新安排物理磁盘布局。

我们可以使用onstat -D和onstat -g ioq获得类似的信息，前者显示各个块的磁盘读和写，而后者显示磁盘I/O 等待队列信息。

您可以通过查询sysmaster 数据库中的sysptprof表来进一步标识哪些表具有最多的磁盘读写操作：
输出类似于：
根据从这个查询获得的输出，您可能需要在dbspace 间移动一些表以使磁盘I/O 平衡得更好。

共享内存段
太多的虚拟共享内存段（通常多于三个）表明：最初的虚拟共享内存段太小，数据库引擎必须不断分配额外的虚拟共享内存段。

这反过来影响了IDS 性能，并且最终会损害系统的性能。

onstat -g seg命令显示了Informix 数据库引擎目前拥有多少共享内存段：
如果输出显示虚拟共享内存段多于三个，那么您需要提高配置文件中SHMVERSIZE 参数的值。

其思想是，让IDS 在初始化时分配足够的虚拟共享内存，以便在用户登录到系统并执行数据库操作时无需分配更多的虚拟共享内存。

您可能还想使用UNIX® ipcs命令来查看Informix 共享内存的大小。

有关如何计算IDS 虚拟共享内存段大小的详细信息，请参考Administrator's Guide。

操作系统的整体性能
由于Informix 数据库引擎总是安装在某个操作系统（主要是UNIX）上，以准确地监控或评估IDS 性能，因此我们需要将操作系统的行为作为一个整体来考虑，在数据库引擎驻留在非专用数据库服务器上时尤其要这样考虑。

如果IDS 占用了太多RAM（例如，如果系统有512MB RAM，而IDS 占用了400MB 或更多作为其共享内存），那么当用户执行内存密集型操作时，操作系统可能会经历频繁的交换和挂起。

当内存不足时，系统必须将一些数据页从内存交换到磁盘，以便为新数据腾出更多空间。

如果系统内存不足，那么CPU 可能也会遭殃。

有不少UNIX 实用程序可以监控操作系统CPU 和内存的整体利用率。

以下是来自“top”实用程序的输出：
上面的输出包含两部分。

第一部分为您汇总了操作系统的CPU 和内存的整体使用情况，第二部分则提供了有关每个处理器的详细信息。

其它实用程序（如vmstat、iostat、ps -ef和sar）在收集操作系统当前的性能统计信息方面也很有用。

vmstat显示目前操作系统交换了多少内存；iostat和sar显示了当前在所有物理磁盘中磁盘I/O 的分配；而ps -ef打印出当前各个处理器的登录时间、CPU 及内存使用情况的详细信息。

此外也有许多图形工具可用，这些工具使您能够绘制操作系统资源利用率和性能的动态变化。

回页首
监控数据库活动
对数据库活动进行监控的目的在于确保每个数据库时刻都将其能力发挥到了极致。

这意味着：您必须留意潜在的性能问题，确定其根源并将其消灭在萌芽状态。

以下是要留意的几个方面。

表扩展块
扩展块是一块物理上连续的页。

然而，如果一个表有多个扩展块，那就不能保证这些扩展块是连续的；扩展块可能会散布在表所驻留的整个dbspace 上。

物理页的连续性对于性能十分重要。

当数据页连续时，访问磁盘数据所用的时间就最短，而数据库也能连续地读取行。

如果表有太多扩展块，那么那些扩展块极有可能相互交错。

这极大地影响了性能，因为当您检索某个表的数据时，磁头需要对属于该表的多个非连续扩展块进行寻道，而不是对具有连续物理页的一个大扩展块进行寻道。

这会显著地降低磁盘寻道速度。

下面的脚本检测具有多个扩展块的数据库表：
输出如下所示：
如果除了大型分段表以外，任何表的扩展块超过了10 个，那么您应该考虑重新构建这些表以合并扩展块。

对于较大的数据库或者大小设置不是很好的数据库，我们可能还会关注扩展块的最大数目，或者会担心针对索引的32GB 限制。

有关如何对表估计和分配数据块大小的详细信息，请参考Performance Guide。

索引层
索引的层数也可能会对性能产生不利影响。

索引层越多，IDS 到达索引叶节点所需的探测也就越多。

而且，如果叶节点被拆分或合并，那么整个索引对这一变化进行调整将要花费更多的时间。

例如，如果索引只有两层，那么只需要调整两层，但如果索引有四层，那么相应地就需要对所有四层进行调整。

用于这一调整的时间当然也就长得多。

在OLTP 环境中会进行频繁的插入、删除和更新，这些操作会导致不断地对索引进行拆分和合并，因此上述问题也就格外明显。

下面的脚本标识每个索引的层数：
输出如下所示：
如果哪个索引超过了 4 层，您可能就需要考虑删除和重新构建该索引，从而合并其层，以获取更好的性能。

索引唯一性
索引的重复程度很高会严重地影响更新和删除的性能。

假定表customer的customer_type列上有一个索引，而可能的
customer_type代码只有五种。

如果这个表有一百万行，那么可能有200000 行具有相同的customer_type代码。

B-树存储键值，其后跟一个指向每个物理行的指针列表。

在必须删除或更新任何键值时，问题出现了。

IDS 必须找遍所有的重复内容，直到找到要删除或更新的正确键为止！
下面的脚本用来标识重复程度很高的索引：
输出如下所示：
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列），我们可以计算每个索引唯一性的百分率：
百分率越高，索引的唯一性就越高。

为了避免因索引重复程度很高而引起的性能瓶颈，您可以使用复合索引来替换原来的索引，复合索引结合了重复程度很高的列与唯一性比较高的列。

利用上面的示例，您可以将主键列customer_id添加到原来的索引，将它变成一个复合列（例如，“create index index_name on customer ( customer_type , customer_id)”）。

顺序扫描
对表进行顺序存取有时会降低性能，因为数据库引擎必须扫描整个表以选取满足查询条件的行。

如果表很小，比如说几百行，那么顺序存取不会对性能造成什么影响；因为当数据库引擎第一次扫描它时，该表会驻留于内存中，而当数据库引擎下一次扫描它时，可以直接从内存检索该表中的所有数据。

这实际上是使用顺序扫描的有效方式。

但如果表很大，比如说超过了100000 行，那么重复的顺序扫描会对性能造成致命的影响。

下面的脚本将标识具有多重顺序扫描的表：
输出如下所示：
从上面的输出可以看出airgen_10_0表的顺序扫描数很高。

如果它是一个具有几千甚至几百万行的大表，那么您可能需要考虑向该表添加一些索引，或者考虑使用程序伪指令来强制内部查询优化器为访问该表中的数据选择索引而不是顺序扫描。

监控会话活动
有关会话活动的统计信息在确定潜在的性能问题及故障诊断方面很有用。

使用本文前面讨论的监控工具，我们可以收集哪些会话活动统计信息呢？
常规会话统计信息
sysmaster 数据库中的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表提供了各会话的更多详细信息。

使用以下查询，您可以更好地理解各个会话是如何与数据库交互的：
输出如下所示：
access 字段显示了会话命中数据库的次数。

locksheld显示各会话正使用多少锁。

seqscans表明各会话使用顺序扫描访问数据的次数；如果该数字太高，比如说高于100000，那么您可能要质疑会话是否曾经使用过索引来检索数据，而且要更仔细地检查其查询执行计划以确定它是否最佳。

total_sorts和dsksorts表明各会话使用内存进行排序操作的效率。

您可能会使用以下公式来计算各会话使用内存进行排序的百分数：
该百分数越高，排序操作效率也就越高。

您可以将syssessions表与syssesprof表连接以进一步确定每个会话的用户名和主机机器名，以便了解哪些地方可能会出现数据库和系统问题。

以下查询可以检索所有这类信息：
您也可以将syssessions表与syslocks表连接以获取关于锁的更多详细信息，如哪个会话当前锁定了哪个数据库中的哪个表，以此来帮助您确定各用户之间潜在的锁冲突：
输出类似于：
如果在锁使用方面存在某些冲突，例如某个用户需要对已被别的用户锁定的表进行专有访问，那么您可以方便地确定该锁的所有者，并根据用户的优先级发出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.
输出的第一部分给出了关于正在执行的查询的一些常规统计信息，如对哪个数据库执行查询、其隔离级别以及锁方式。

最有趣的两个字段是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 的性能是一项正在进行的任务。

这项任务的价值并不在于收集统计信息本身，而在于确定和解决潜在的系统和数据库问题。

通过本文中所描述的这些有效的监控实践，我们将能够成功地在最初阶段确定系统和数据库问题，这样我们就能够采取更为主动的方式来进行故障诊断和性能调优。