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 d.name, 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, s.username, 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 <spacename> -p <path> -o <offset> -s <size>
5.9 表空间分配多，但使用的较少
如果通过“3.6 表空间的使用情况”检查发现表空间分配多，但使用的较少，建议重建该表。步骤参见“5.1表扩展块过多”

5.10 修改tempdbs
可以将原来1，2个tempdbs调整到4个，原来数据库空间平均划分。

使用

onsapces –d <spacename> [-p <path> -o <offset>] [-f] [-y]
删除原来的tempdbs

使用

onspaces -c { -d <DBspace> [-t] -p <path> -o <offset> -s <size> }
添加新的tempdbs

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