分类： DB2/Informix
2005-07-08 12:18:16
简介
不 少书籍和文章都对 Informix® Dynamic Server®（IDS）及其体系结构和性能调优进行了详尽论述，但专门讨论监控这一主题的却很少。但在 IDS 管理中有效的监控却至关重要。它能帮助我们收集系统和数据库性能方面有价值的统计信息，还能帮助我们很早就确定问题，以便我们能够在故障诊断和性能调优方 面取得主动。在成功地安装和配置 Informix Dynamic Server 并实现了 Informix 数据库以后，对 Informix Dynamic Server 进行监控就成为了数据库管理员的头等大事。
本文将详细讨论如何在各个级别有效地监控 Informix Dynamic Server，同时会就确定 Informix 引擎和数据库问题提供一些常规技巧。文章将同时涵盖故障诊断和性能调优这两个方面监控工具
Informix 提供了两个主要的工具来监控系统和数据库性能：
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,
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
块状态
块是物理存储设备。它们应该始终联机。如果有任何块当机了，那么这表明数据遭到毁坏，需要立即引起注意。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
65866468 2 0x1 2 4 N informix airgen_idx_dbs
658665b0 3 0x1 3 3 N informix spare
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
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
65867538 15 0x2001 29 1 N T informix temp_dbspace4
15 active, 2047 maximum
Chunks
address chk/dbs offset size free bpages flags pathname
6514b
6514b760 3 3 815000 60000 59747
6514b8d0 4 4 875000 125000 4947
6514ba40 5 5 0 1000000 299290
6514bbb0 6 2 0 1000000 207877
6514bd20 7 6 0 200000 179043
6514be90 8 7 200000 250000 249939
6510ca88 9 3 450000 250000 249997
6510cbf8 10 8 0 1000000 299086
6510cd68 11 9 0 1000000 4
6513cb10 14 10 800000 200000 27596
6513cc80 15 9 0 1000000 782331
6513cdf0 16 11 0 1000000 296827
65865018 17 4 0 400000 9997
65865188 18 12 400000 250000 249947
65865468 20 13 300000 250000 249947
658655d8 21 4 550000 150000 14997
65865748 22 4 0 350000 4997
658658b8 23 11 350000 300000 299997
65865b98 25 14 0 1000000 299014
65865d08 26 2 0 750000 749997
65865e78 27 4 750000 250000 39997
65866018 28 14 0 300000 299997
