【正文】 Informix工具 Informix 提供的用來收集詳細(xì) SQL 查詢計劃和執(zhí)行統(tǒng)計數(shù)據(jù)的最全面的工具是 SET EXPLAIN 實 用程序。如果指定了 interval， vmstat 將立即反復(fù)按照最新的間隔總結(jié)系統(tǒng)活動的概要信息。通過輸出，我們可以確定該查詢的響應(yīng)時間是 秒。資源利用率指的是執(zhí)行 SQL 查詢時， CPU、內(nèi)存和磁盤等系統(tǒng)資源的使用。您隨后可以對 Informix dbaccess 實用程序運行同一個查詢，以獲取該查詢性能方面更多詳細(xì)的統(tǒng)計信息（如其執(zhí)行計劃和連接策略），從而確定問題的根源。例如，如果您想監(jiān)控的會話標(biāo)識為 28953，那么您可以使用 onstat g sql 28953 來捕獲其當(dāng)前查詢。 seqscans 表明各會話使用順序掃描訪問數(shù)據(jù)的次數(shù)；如果該數(shù)字太高，比如說高于 100000，那么您可能要質(zhì)疑會話是否曾經(jīng)使用過索引來檢索數(shù)據(jù)，而且要更仔細(xì)地檢查其查詢執(zhí)行計劃以確定它是否最佳。 監(jiān)控會話活動 有關(guān)會話活動的統(tǒng)計信息在確定潛在的性能問題及故障診斷方面很有用。為了避免因索引重復(fù)程度很高而引起的性能瓶頸，您可以使用復(fù)合索引來替換原來的索引，復(fù)合索引結(jié)合了重復(fù)程度很高的列與唯一性比較高的列。下面的腳本標(biāo)識每個索引的層數(shù)： select idxname, levels from sysindexes order by 2 desc 輸出如下所示： idxname levels objdesc 3 fanout_param_i 3 458_485 3 457_484 3 idxname 2 tabgtor 2 tabgtee 2 如果哪個索引超過了 4 層，您可能就需要考慮刪除和重新構(gòu)建該索引，從而合并其層，以獲取更好的性能。下面的腳本檢測具有多個擴展塊的數(shù)據(jù)庫表： select , count(*) num_ext from sysmaster:sysextents e, sysmaster:systables t where = and dbsname = airgen and not like sys% group by 1 having count(*) 1 order by 2 desc 輸出如下所示： tabname num_ext nmoattrclassmap 14 attrclass 11 workmoclass 3 fanout_param 3 fanout_p 2 ne_nmo 2 nenmoclassmap 2 join_map 2 如果除了大型分段表以外，任何表的擴展塊超過了 10 個，那么您應(yīng)該考慮重新構(gòu)建這些表以合并擴展塊。以下是要留意的幾個方面。有不少 UNIX 實用程序可以監(jiān)控操作系統(tǒng) CPU 和內(nèi)存的整體利用率。 onstat g seg 命令顯示了 Informix 數(shù)據(jù)庫引擎目前擁有多少共享內(nèi)存段： Informix Dynamic Server 2021 Version OnLine Up 28 days 15:49:33 205824 Kbytes Segment Summary: id key addr size ovhd class blkused blkfree 0 1381386241 a000000 177209344 220688 R 42984 280 1 1381386242 14900000 8388608 856 V 2048 0 2 1381386243 15100000 1048576 632 M 164 92 3 1381386244 15202100 8388608 856 V 2048 0 4 1381386245 15a00000 8388608 856 V 2021 40 5 1381386246 16202100 8388608 856 V 50 1998 Total: 211812352 49302 2410 (* segment locked in memory) 如果輸出顯示虛擬共享內(nèi)存段多于三個，那么您需要提高配置文件中 SHMVERSIZE 參數(shù)的值。平衡得較好 的 dbspace I/O 將減輕系統(tǒng)磁盤 I/O 負(fù)載，從而會改善系統(tǒng)的整體性能。各種問題都可能出現(xiàn)：無法導(dǎo)入任何數(shù)據(jù)庫，無法創(chuàng)建任何表和索引，甚至無法對任何表和索引執(zhí)行插入和更新操作。以下是該命令的 樣本輸出： 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 2021 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/ 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 如果檢查點持續(xù)時間始終超過 10 秒，那么您可能需要減少 LRU_MIN_DIRTY 和 LRU_MAX_DIRTY 配置參數(shù)的值以獲取更短的檢查點持續(xù)時間。由于 O 和 D 看起來很相象，尤其是您匆匆一瞥時，因此您可能想將結(jié)果用管道輸入到 grep PD ，即 onstat d |grep PD ，以確保您不會遺漏任何當(dāng)機塊。 塊狀態(tài) 塊是物理存儲設(shè)備。s Guide）以獲取有關(guān)如何調(diào)優(yōu)這些參數(shù)的詳細(xì)信息。 另一組重要字段包括 ixdaRA、 idxRA、 daRA 及 RApgused 。 ovlock 字段表明 IDS 在使用了最大數(shù)量的鎖之后嘗試過再使用鎖的次數(shù)。但讀高速緩存比例和寫高速緩存比例一般都應(yīng)該在 80 到 90 個百分點之間。 OnLine 方式表明 IDS 正在正常運行，所有用戶都可以連接到數(shù)據(jù)庫服務(wù)器，并可以執(zhí)行各種數(shù)據(jù)庫操作。以下是部分需要監(jiān)控的最重要的實例活動?？偣灿辛N操作方式，其中三種特別重要： OffLine、 Quiescent 和 OnLine。兩個 %cache 字段表明 IDS 目前使用內(nèi)存高速緩存的效率。如果這個數(shù)字相當(dāng)大，比如說超過了 100000，并且還在不斷增加，那么這可能表明性能有問題，當(dāng)系統(tǒng)處于 OLTP 環(huán)境時更是如此。我們還需要檢查與 LRU 有關(guān)的參數(shù)，將它們的值調(diào)整到較低的 bufwait。如果二者之間存在顯著的差異，比如正負(fù)差值達到 10000 以上，那么 IDS 目前就沒有很有效地使用預(yù)讀，而您可能需要調(diào)優(yōu)您的預(yù)讀參數(shù)（即 RA_PAGES 和 RA_THRESHOLD）以獲取更好的性能。以下內(nèi)容摘自消息日志： 00:57:53 00:57:53 Assert Failed: Unexpected virtual processor termination, pid =586, exit = 0x9 00:57:53 Who: Session(13709, omcadminnvlsys, 6538, 654709000) Thread(13740, sqlexec, 2704a558, 1) 00:57:53 Results: Fatal Internal Error requires system shutdown 00:57:53 Action: Restart OnLine 00:57:53 See Also: /var/tmp/ 00:57:53 Stack for thread: 13740 sqlexec 上面的輸出告訴我們：某個 Informix 虛擬處理器終止了，并毀壞了數(shù)據(jù)庫引擎。在塊（ Chunk）部分中，我們需要特別注意 flags 字段。因此，如果檢查點持續(xù)時間過長，那么用戶可能會經(jīng)歷系統(tǒng)掛起。s Guide。要取得主動，請考慮在某個 dbspace 的磁盤使用情況接近 90% 時向該 dbspace 分配額外的磁盤空間；本例中，我們需要特別注意 llog dbspace，并且可能的話，就給它分配更多空間，以防止它把空間用完。 您可以通過查詢 sysmaster 數(shù)據(jù)庫中的 sysptprof 表來進一步標(biāo)識哪些表具有最多的磁盤讀寫操作： select dbsname, tabname, (isreads + pagreads) diskreads, (iswrites + pagwrites) diskwrites from sysptprof order by 3 desc, 4 desc 輸出類似于： dbsname tabname diskreads diskwrites airgen_10_0 fanout_param 84567 3094 airgen_cm_db sysindices 78381 0 airgen_10_0 ne_nmo_i 75819 5 airgen_10_0 ne_nmo 75440 297 airgen_cm_db sysprocbody 62610 28322 airgen_10_0 systables 37342 466 airgen_10_0 syscolumns 34539 4609 airgen_10_0 457_484 32838 42 airgen_10_0 453_480 30009 1 airgen_10_5_old syscolumns 29531 4550 airgen_10_5 syscolumns 28824 4552 airgen_10_0 456_483 25448 14 airgen_10_0 458_485 23278 177 airgen_10_