Informix Dynamic Server维护手册

Informix Dynamic Server维护手册
1 onstat工具
1.1 监控虚拟处理器和线程
onstat –g ath 显示有关线程和处理器类的信息
onstat –g glo 显出当前每个处理器的信息以及有关每个处理器类的累积的统计信息
onstat –g ioq 使用onstat –g ioq可以确定你是否要分配附加的AIO虚拟处理器。监视AIO vp的gdf队列的长度，队列一贯短时表示对磁盘设备的处理速度与发生请求的速度一样快。如果gdf队列持续很长，考虑增加AIO vp的数目。
onstat –g wai 显示等待状态的线程
onstat –g act 显示活动状态的现场
onstat –g rea 监视就绪队列中的线程
onstat –g sle 显示睡眠状态的线程

1.2 操作系统进程与数据库session的关系
1)使用操作系统命令（例如topas）查看最繁忙的oninit进程，记录它的pid
2)用onstat –g glo查看vp class，看相应进程里运行的是那个vp（用pid去匹配）。确定瓶颈是在那一类vp上（比如是在cpu vp上还是在aio vp上）。记录vp，class。
3)用onstat –g act（或onstat –g ath）查看相应vp里运行的是那个线程（用vp class去匹配），记录它的tid，rstcb。
4)用onstat –g ses ses_id检查session信息（用tid，rstcb去匹配）

下面的shell用于获得所有session信息
!/usr/bin/ksh
###############################################################################
#
# Module: ses_all.sh
# Author: Henry Cheung
# Description: Get all sessiong information
# History
# Date Name Description.................
# 07/30/2004 Henry Cheung Start Program
#
###############################################################################

onstat -g ses | grep -v IBM |grep -v session |grep -v id | awk '{print $1}' | while read SES_ID
do
onstat -g ses $SES_ID
done



1.3 监控共享内存
onstat –o 捕获共享内存的静态快照用于今后的分析和比较
onstat –g seg 显示每个共享内存段的信息。一般用于检查有几个虚拟内存段。如果虚拟内存段过多，考虑调整SHMVIRSIZE，和SHMADD参数。
onstat –s 获取锁存器的信息
onstat –p 显示数据库活动的统计信息。比如cached的读写命中率。如果读写命中率较低，考虑调整BUFFERS参数。ovuserthread-用户尝试超过用户最大线程最大的次数，ovbuff数据库服务器无法找到共享内存缓冲区的次数，

1.4 监视磁盘使用
onstat -d
检查数据库dbspace、chunk使用情况。配合topas等系统命令，监控是否某个物理硬盘出现I/O瓶颈。

onstat –g iof 显示每个块的读取、写入的次数

1.5 其他
方法：onstat
目的：检查数据库服务器运行了多长时间，总共占用了多少内存。

方法：onstat –c 或 oncheck –pr
目的：检查数据库服务器当前使用的配置文件

方

法：onstat –g env
目的：检查数据库服务器当前使用的环境变量

onstat –l
检查逻辑日志情况。

onstat –m或vi online.log
检查数据库日志，包括检查点完成时间，是否有异常等。

onstat –g ses (session id), onstat –g sql
检查session状况

方法：onstat –u
目的：显示库用户活动信息

方法：onstat –x
目的：显示数据库服务器上的事务信息

2 oncheck工具
方法：oncheck -cr
目的：检查保留页

方法：oncheck –ce
目的：检查统空间使用情况

方法：oncheck –cc database
目的：检查应用数据库的系统表

方法：oncheck –ci, oncheck -cI
目的：检查数据库的索引情况，注意此命令会影响生产系统且耗时较长，应在适当的时候检查。

方法：oncheck –cd, oncheck –cD
目的：检查数据库的数据情况，，注意此命令会影响生产系统且耗时较长，应在适当的时候检查。

3 使用SMI
3.1 dbspace使用情况
--FileName: dbspaces.sql
--dbspace使用情况：输入dbspace name, allocated, free, percent of used
unload to dbs.txt delimiter " "
SELECT name[1,15] dbspace, SUM(chksize) allocated, SUM(nfree) free,
ROUND(((SUM(chksize) - SUM(nfree))/SUM(chksize))*100) pcused
FROM sysmaster:sysdbspaces d, sysmaster:syschunks c
WHERE d.dbsnum = c.dbsnum
GROUP BY 1
ORDER BY 4 DESC
及时监控dbspace的使用情况，以便分配新的空间给数据库使用
3.2 dbspace I/O
--FileName: dbs_io.sql
--dbspace、chunk I/O: dbspace name, path, disk reads, disk writes
UNLOAD TO dbs_io.txt DELIMITER " "
SELECT first 10 , fname path_name, SUM(pagesread) diskreads, SUM(pageswritten) diskwrites
FROM sysmaster:syschkio c, sysmaster:syschunks k, sysmaster:sysdbspaces d
WHERE d.dbsnum = k.dbsnum
AND k.chknum = c.chunknum
GROUP BY 1, 2
ORDER BY 3 DESC
监视是否存在某个dbspace I/O较高的情况，如果有就要考虑更为合理的数据分布和硬盘划分。
3.3 统计数据库占用的空间
--FileName: database_size.sql
--统计数据库占用的空间：dbspace, database_name, size
SELECT dbsname[1,15] database_name, SUM(pe_size) size
FROM sysmaster:sysptnext,
OUTER sysmaster:systabnames
WHERE pe_partnum = partnum
GROUP BY 1
ORDER BY 2 DESC
3.4 表扩展块情况
--FileName: extents.sql
--获取系统中extents最多的表的表名，所在的数据库名，extents的数量
--sysextents表9.2版本和9.4版本的结构有不同，但不影响本sql执行
UNLOAD TO extents.txt DELIMITER " "
SELECT FIRST 20 t.dbsname, t.tabname, count(*)
FROM sysmaster:systabnames t, sysmaster:sysextents e
WHERE t.dbsname = e.dbsname
AND t.tabname = e.tabname
AND t.tabname[1,3] != "sys"
GROUP BY 1,2
ORDER BY 3 DESC
如果发现表的extents数量过多，就要考虑调整extents的大小，并且重建表。
3.5 表I/O
--FileName: tab_io.sql
--table I/P: dbsname, tabname, disk reads, disk writes, disk io sum

UNLOAD TO tab_io.txt DELIMITER " "
SELECT first 5 dbsname, tabname, (isreads + pagreads) diskreads, (iswrites + pagwrites) diskwrites,
(isreads + pagreads + iswrites + pagwrites) disk_io
FROM sysmaster:sysptprof
WHERE tabname[1,3] != "sys"
ORDER BY 5 DESC
监视是否存在某张表I/O较高的情况，如果有就要考虑更为合理的数据分布和硬盘划分。
3.6 表空间的使用情况
--FileName: tab_space.sql
--表空间的使用情况: table name, dbspace, allocated_space, used_space, free_space
--针对每个应用库
UNLOAD TO tab_used.txt DELIMITER " "
SELECT FIRST 10 t.tabname[1,20] table_name,
Cast(dbinfo( "DBSPACE" , t.partnum ) as char(10)) dbspace ,
p.nptotal allocated_space,
p.npused used_space,
(p.nptotal - p.npused) free_space,
ROUND((p.npused/p.nptotal)*100) percent_used
FROM sysmaster:systabnames t, APPDB:systables a, sysmaster:sysptnhdr p
WHERE a.partnum = p.partnum
AND a.partnum = t.partnum
AND tabid > 99
GROUP BY 1,2,3,4,5
ORDER BY 3 DESC
如果表空间分配的较多而使用的较少，就要考虑重建表。
3.7 索引层数
--FileName: idx_lvl.sql
--索引层: table name, index name, levels
--应用库
SELECT FIRST 5 t.tabname, i.idxname, i.levels
FROM APPDB:systables t, APPDB:sysindexes i
WHERE t.tabid = i.tabid
AND t.tabname[1,3] != "sys"
ORDER BY 3 DESC
当索引层数超过4层就要考虑是否需要重建索引。
3.8 索引唯一性
--FileName: idx_unq.sql
--索引唯一性: table name, index name, table rows, index unique, percent of unique
--应用库
--i.nunique/t.nrows有可能会除零，
UNLOAD TO idx_unq.txt DELIMITER " "
SELECT FIRST 10 t.tabname, i.idxname, t.nrows, i.nunique
FROM APPDB:systables t, APPDB:sysindexes i
WHERE t.tabid =i.tabid
AND t.tabid > 99
ORDER BY 3 DESC

{
SELECT FIRST 10 t.tabname, i.idxname, t.nrows, i.nunique, (i.nunique/t.nrows)*100 pcniq
FROM APPDB:systables t, APPDB:sysindexes i
WHERE t.tabid =i.tabid
AND t.tabid > 99
ORDER BY 3 DESC, 5 DESC
}
索引唯一性的百分率越高，索引的唯一性就越高，性能就越好。为了避免因索引重复程度很高而引起的性能瓶颈，您可以使用复合索引来替换原来的索引，复合索引结合了重复程度很高的列与唯一性比较高的列。
3.9 顺序扫描
--FileName: seq_scans.sql
--顺序扫描: database name, table name, number of rows, total sequence scans
--应用库
UNLOAD TO seq_scans.txt DELIMITER " "
SELECT FIRST 10 p.dbsname, p.tabname, t.nrows, sum(p.seqscans) tot_seqscans
FROM sysmaster:sysptprof p, systables t
WHERE p.dbsname NOT LIKE "sys%"
AND p.dbsname = APPDB
AND p.tabname = t.tabname
AND t.tabname NOT LIKE "sys%"
GROUP BY 1,2,3
ORDER BY 3 DESC,4 DESC
如果一个具有几千甚至几百万行大表的顺序扫描数很高，那么您可能需要考虑向该表添加一些索引，或者考虑使用程序伪指令来强制内部查询优化器为访问该表中的数

据选择索引而不是顺序扫描。
3.10 获取session信息
可以从syssespro(各用户操作计数)，syssesions(对每个已连接用户的描述)表中获取sessions信息。
--FileName: sessions.sql
--sessions信息: session id, user name, host name, access, locks, sequence scans, total sorts, disk sorts, percent of memory sorts
SELECT s.sid, ername, s.hostname,
(isreads+iswrites+bufreads+bufwrites+pagreads+pagwrites) access,
locksheld, seqscans, total_sorts, dsksorts,
((total_sorts - dsksorts)/total_sorts)*100 pct_memsorts
FROM sysmaster:syssessions s, sysmaster:syssesprof f
WHERE s.sid=f.sid
ORDER BY 4
如果一个session有过多的顺序扫描，或占用过多的锁资源，或使用了较多的disk sorts就需要关注这个session。
3.11 sessions持有lock的情况
--FileName: lock.sql
--sessions持有lock的情况: sid, username, hostname, database name, table name, lock type
SELECT owner, username, hostname, dbsname, tabname, type
FROM sysmaster:syssessions s, sysmaster:syslocks l
WHERE sid = owner
AND tabname NOT LIKE "sys%"
如果在锁使用方面存在某些冲突，例如某个用户需要对已被别的用户锁定的表进行专有访问，那么您可以方便地确定该锁的所有者，并根据用户的优先级发出 onmode -z sid 命令来杀死会话，然后释放该锁；sid 这个编号是从上面输出中的 owner 字段中获取的；请注意，只有用户“Informix”可以执行该命令。
3.12 锁信息
--锁信息：数据库名，表名，该表占有互斥锁的个数
--FileName: lock_count.sql
--锁信息：数据库名，表名，该表占有互斥锁的个数
SELECT FIRST 10 dbsname, tabname, COUNT(*)
FROM syslocks
WHERE type LIKE "%X%"
GROUP BY 1, 2
ORDER BY 3
4 性能瓶颈时应急方法
4.1 收集系统运行信息
收集全面的系统运行信息，以便今后分析问题所在。使用onstat –a，onstat –g all，并保留输出信息到文件中。保留online.log。如果数据库宕机有core文件生成，请保留core文件。

4.2 数据库宕机
重启数据库保证关键业务运行。保留online.log，core文件。查看online.log，core文件，初步判断宕机原因，并于IMB技术支持联系。如果重启失败，考虑切换到备份机。

4.3 系统运行突然变慢，系统资源被占用过多
4.3.1 检查系统资源
首先用topas，nmon，sar， vmstat，iostat等命令检查CPU，内存、硬盘资源的使用情况。

topas
Topas Monitor for host: S1_C_HZ_SHUJUKU EVENTS/QUEUES FILE/TTY
Tue Jul 27 13:01:26 2004 Interval: 2 Cswitch 1907 Readch 2750
Syscall 7513 Writech 581
Kernel 2.2 |# | Reads 21 Rawin 0
User 62.0 |################# | Writes 8 Ttyout 238
Wait 0.0 | | Forks 0 Igets 0
Idle

35.6 |########## | Execs 0 Namei 7
Runqueue 3.7 Dirblk 0
Interf KBPS I-Pack O-Pack KB-In KB-Out Waitqueue 1.0
en1 628.9 880.4 1057.9 111.4 517.5
en2 0.2 1.9 0.9 0.1 0.1 PAGING MEMORY
Faults 0 Real,MB 4095
Disk Busy% KBPS TPS KB-Read KB-Writ Steals 0 % Comp 84.5
hdisk3 93.4 3981.8 234.9 3571.9 409.9 PgspIn 0 % Noncomp 15.6
hdisk2 78.9 2695.8 269.4 2145.9 549.9 PgspOut 0 % Client 0.5
hdisk22 71.4 1317.8 104.4 677.9 639.9 PageIn 0
hdisk4 59.9 3125.8 129.9 485.9 2639.9 PageOut 0 PAGING SPACE
hdisk10 47.4 5095.9 153.4 5095.9 0.0 Sios 0 Size,MB 5120
% Used 56.6
oninit (35894) 17.1% PgSp: 1.2mb informix % Free 43.3
oninit (21698) 11.7% PgSp: 1.2mb informix
oninit (38944) 10.7% PgSp: 1.2mb informix
oninit (42688) 10.7% PgSp: 1.2mb informix Press "h" for help screen.
oninit (15774) 7.5% PgSp: 1.2mb informix Press "q" to quit program.


图 1

上图可以看出CPU idle 35.6%，hdisk3最繁忙93.4%，最繁忙的oninit进程和其进程号。

通过这一步的检查确定是否有CPU、内存或磁盘I/O操作的异常。如果CPU突然繁忙，就要检查是否正在运行某个特殊的应用程序，或者在执行一些大批量处理的业务。如果确定某个应用程序会占用过多的系统资源考虑中止该应用程序。

4.3.2 检查数据库
使用”1 onstat工具”提到的检查虚拟处理器、共享内存、磁盘使用的方法检查。

使用”1.2 操作系统进程与数据库session的关系”中提到的方法检查session情况。

1) 使用操作系统命令（例如topas）查看最繁忙的oninit进程，记录它的pid

参见图1红色部分

2) 用onstat –g glo查看vp class，看相应进程里运行的是那个vp（用pid去匹配）。确定瓶颈是在那一类vp上（比如是在cpu vp上还是在aio vp上）。记录vp，class。

Informix Dynamic Server 2000 Version 9.21.FC7 -- On-Line -- Up 3 days 20:05s

MT global info:
sessions threads vps lngspins
72 114 12 20536081

sched calls thread switches yield 0 yield n yield forever
total: 1331551216 803593811 604838347 1639523 333477762
per sec: 518 513 43 3 225

Virtual processor summary:
class vps usercpu syscpu total
cpu 6 1096903.92 27302.29 1124206.21
aio 2 7.85 13.40 21.25
lio 1 3.52 5.91 9.43
pio 1 3.20 6.07 9.27
adm

1 10.40 17.29 27.69
msc 1 314.72 92.50 407.22
total 12 1097243.61 27437.46 1124681.07

Individual virtual processors:
vp pid class usercpu syscpu total
1 32440 cpu 249667.07 7407.37 257074.44
2 32914 adm 10.40 17.29 27.69
3 30830 cpu 192338.19 7340.19 199678.38
4 23202 cpu 167720.65 3326.55 171047.20
5 34752 cpu 165780.54 3250.53 169031.07
6 32102 cpu 162890.54 3086.34 165976.88
7 26454 cpu 158506.93 2891.31 161398.24
8 35392 lio 3.52 5.91 9.43
9 31568 pio 3.20 6.07 9.27
10 15788 aio 4.53 6.80 11.33
11 30090 msc 314.72 92.50 407.22
12 27966 aio 3.32 6.60 9.92
tot 1097243.61 27437.46 1124681.07


图 2

3) 用onstat –g act（或onstat –g ath）查看相应vp里运行的是那个线程（用vp class去匹配），记录它的tid，rstcb。


Informix Dynamic Server 2000 Version 9.21.FC7 -- On-Line -- Up 3 days 20:08:
11 -- 3493088 Kbytes

Running threads:
tid tcb rstcb prty status vp-class
name
35 7000000a22b4028 0 4 running 3cpu
kaio
52 7000000a2710028 0 4 running 4cpu
kaio
56 7000000a2802028 0 4 running 6cpu
kaio
382844 7000000d81cee18 7000000a16e14b0 2 running 5cpu
sqlexec
386225 7000000c8730190 7000000a16c7650 2 running 1cpu
sqlexec


图 3

4) 用onstat –g ses ses_id检查session信息（用tid，rstcb去匹配），可以用shell将所有的session详细信息都写入到文件中，再在文件中搜索tid或rstcb。

Informix Dynamic Server 2000 Version 9.21.FC7 -- On-Line -- Up 3 days 20:11:
29 -- 3493088 Kbytes

session #RSAM total used
id user tty pid hostname threads memory memory
377298 cics - 65720 S1SDYY 1 3284992 3156424

tid name rstcb flags curstk status
382844 sqlexec 7000000a16e14b0 Y--P--- 2816 7000000a16e14b0cond wait(ne
tnorm)

Memory pools count 1
name class addr totalsize freesize #allocfrag #freefrag
377298 V 7000000d8133040 3284992 128568 4927 66

name free used name free used
overhead 0 3248 mtmisc 0 1496
scb 0 200 opentable 0 423176
filetable 0 40432 ru 0 328
blobio 0 9192

log 0 4216
temprec 0 10104 keys 0 24912
ralloc 0 2211752 gentcb 0 1776
ostcb 0 3448 sort 0 104
sqscb 0 91784 sql 0 72
rdahead 0 1120 hashfiletab 0 552
osenv 0 2408 buft_buffer 0 139128
sqtcb 0 33992 fragman 0 151496
shmblklist 0 1488

Sess SQL Current Iso Lock SQL ISAM F.E.
Id Stmt type Database Lvl Mode ERR ERR Vers
377298 - sdboss DR Wait 10 0 0 9.03

Last parsed SQL statement :
select vc_prodname from yx_pp_prod where int_prodid = ?

7168 byte(s) of memory is allocated from the sscpool


图4


如果监控到某个session占用系统资源过多，决定要中止该session时，使用onstat –g ses (session id)查看client端的pid，首先考虑中止相应的client应用程序，如果失败使用kill命令中止client端进程，如果还失败使用onmode –z (session id)中止该session。

Informix Dynamic Server 2000 Version 9.21.FC7 -- On-Line -- Up 3 days 20:09:
50 -- 3493088 Kbytes

session #RSAM total used
id user tty pid hostname threads memory memory
380767 informix - 0 - 0 12288 11240
380766 billadm - 51296 s2sd_svc 1 106496 98432
380764 billadm - 49068 s2sd_svc 1 102400 96920
380738 billadm - 58844 s2sd_svc 1 143360 85576
380714 billadm - 57098 s2sd_svc 1 151552 84312
380661 billadm - 56326 s2sd_svc 1 184320 146304
380505 cics - 58196 S2SDYY 1 126976 91560
380503 cics - 81138 S2SDYY 1 184320 182904
380502 cics - 31242 S2SDYY 1 2228224 2149256
380500 cics - 50182 S2SDYY 1 1654784 1644072
380499 cics - 79292 S2SDYY 1 671744 634600
380399 cics - 56446 S1SDYY 1 2260992 2243024
380343 cics - 46380 S1SDYY 1 118784 80520
380326 cics - 65994 S1SDYY 1 2342912 2285824
380279 cics - 21972 S2SDYY 1 589824 549560
380276 cics - 79814 S2SDYY 1 905216 876624
380275 cics - 25926 S2SDYY 1 667648 641392
380274 cics - 48294 S2SDYY 1 2203648 2176776


图5

4.4 定期检查数据库
根据“3 使用SMI”中提供的方法，定期执行相关的SQL语句检查数据库。下列原因都会造成系统

运行效率低：

r dbspace，chunk的I/O不均匀。考虑重新分布磁盘空间。

r 表的扩展块过多。考虑调整extent size，并重建表。

r 表空间分配很大，但空闲的较多。考虑重建表。

r 索引层数过多：大于4层，或表的记录数不多但索引层数大于3层。考虑重建索引。

r 索引的唯一性差。考虑重新设计索引。

r 表的顺序扫描过多。检查应用，考虑重新设计索引



5 性能优化
对于本章的操作，设计到数据变更的建议操作之前都做0级备份，用于发生异常情况时恢复。要修改onconfig文件的，建议备份旧文件。

5.1 表扩展块过多
如果通过“3.4表扩展块情况”检查出表扩展块较多，则需要重新计算合理的extent size，并重建表。具体操作步骤如下：
5.1.1 方式一 unload，load
1. 对数据库做0级备份，用于发生异常情况时恢复

2. 编写新表建表文件

执行

dbschema –d database –t table_name –ss > cre_table.sql
将建表的SQL输出到cre_table.sql文件中，做如下修改：

r 设定合理的extent size, next extent size，建议以一张表只有一个extent。

3. 记录对旧表信息，用于检查新、旧表的一致性

通过SELECT COUNT(*)，或对某个字段做SUM，或抽查某些记录来保证新、旧表记录的一致性

4. 用unload备份旧表数据

UNLOAD TO FILE SELECT * FROM old_tale
5. 删除旧表

DROP TABLE old_table
6. 用cre_table.sql文件创建新表

7. 用load导入数据到新表

LOAD FROM file INSERT INTO new_table

8. 检查新、旧表的一致性

通过SELECT COUNT(*)，或对某个字段做SUM，或抽查某些记录来保证新、旧表记录的一致性

5.1.2 方式二 从旧表查询插入到新表
1. 对数据库做0级备份，用于发生异常情况时恢复

2. 将旧表该名

RENAME TABLE new_table TO old_table
3. 编写新表建表文件

执行

dbschema –d database –t table_name –ss > cre_table.sql
将建表的SQL输出到cre_table.sql文件中，做如下修改：

r 为提高insert数据的速度，将表修改为RAW方式。RAW方式的表为非日志记录，不能有索引或参考约束但可以对其进行更新，使用此类型表来快速装入数据。

ALTER TABLE new_table TYPE (RAW)

r 建表时不创建主键和索引

r 设定合理的extent size, next extent size，建议以一张表只有一个extent。

r 为减少插入数据时锁的数量，可以将表设为页锁，插入数据后再修改回设计的值。

ALTER TABLE new_talbe MODIFY LOCK MODE (PAGE)
4. 导入数据

INSERT INTO new_table SELECT * FROM old_table
注意检查数据库空间是否足够
5. 将新表改为STANDARD方式

ALTER

TABLE new_table TYPE (STANDARD)
6. 创建主键、索引

SET PDQPRIORITY 60
CREATE INDEX index_name ON table_name(column)
SET PDQPRIORITY 0
7. 检查新、旧表的一致性

通过SELECT COUNT(*)，或对某个字段做SUM，或抽查某些记录来保证新、旧表记录的一致性

8. 用unload备份旧表数据

UNLOAD TO FILE SELECT * FROM old_table
9. 删除旧表

DROP TABLE old_table
5.2 索引层数过多
如果通过“3.5索引层数”检查出索引层数过多，则需要重新创建表。具体操作步骤如下：

先删除旧索引

DROP INDEX index_name
再创建新索引

CREATE INDEX index_name ON table_name(column)
5.3 索引唯一性低如果通过“3.8索引唯一性”检查出索引层唯一性较低，则需要检查应用，使用复合索引来替换原来的索引，复合索引结合了重复程度很高的列与唯一性比较高的列。重新创建表的步骤参见“5.2索引层数过多”。

5.4 表存储空间分布不合理
如果应为表存储空间分布不合理导致某块硬盘I/O较高，造成系统瓶颈需要重新对表空间进行分配。

如果要重建表的步骤可以参考“5.1表扩展块过多”，存储分配的SQL参见《IBM Informix Guide to SQL- Syntax》中“CREATE TABLE”存储选项部分。

如果不重建表，修改存储分配的SQL参见《IBM Informix Guide to SQL- Syntax》中“ALTER FRAGMENT”部分。

5.5 dbspace I/O 较高
如果通过“3.2 dbspace I/O”检查出某个dbspace I/O过高，则需要检查dbspace的划分是否合理，如果需要重新划分表在dbspace中的存储参见“5.4表存储空间分布不合理”
5.6 table I/O较高
如果通过“3.5 表 I/O”检查出某个表I/O过高，则需要检查应用系统设计上是否该表就是需要访问频繁的表，如果不是则需要检查应用程序。
5.7 虚拟段过多
共享内存的虚拟段包括：共享内存内部表，大缓冲区，会话区，线程区，数据分布高速缓存，字典高速缓存，SPL例程高速缓存，SQL例程高速缓存，排序池，全局池。
如果通过onstat –g seg检查发现虚拟段多于3个，建议修改onconfig文件中SHMVIRTSIZE、SHMADD参数，最好保证虚拟段为1-2个。修改参数后需要重新Informix。
如果在检查了应用后，发现对虚拟段的需求仍然很大，建议增加物理内存或将部分应用移出该informix instance。
5.8 dbspace已使用超过了90%，
如果通过“3.1 dbspace使用情况”检查发现dbspace使用超过了90%，就需要往该dbspace中添加chunk。使用命令
onspaces -a -p -o -s
5.9 表空间分配多，但使用的较少
如果通过“3.6 表空间的使用情况”检查发现表空间分配多，但使用的较少，建议重建该表。步骤参见“5.1表扩展块过多”

5.10 修改tempdbs
可以将原来1，2个tempdbs调整到4个，

原来数据库空间平均划分。

使用

onsapces –d [-p -o ] [-f] [-y]
删除原来的tempdbs

使用

onspaces -c { -d [-t] -p -o -s }
添加新的tempdbs

并修改onconfig文件中DBSPACETEMP参数，需要重启Informix数据库