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 -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資料庫