【文章內(nèi)容簡介】 kreads, (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_5_old 452_483 22412 31 根據(jù)從這個(gè)查詢獲得的輸出，您可能需要在 dbspace 間移動(dòng)一些表以使磁盤 I/O 平衡得更好。 共享內(nèi)存段 太多的虛擬共享內(nèi)存段（通常多于三個(gè)）表明：最初的虛擬共享內(nèi)存段太小，數(shù)據(jù)庫引擎必須不斷分配額外的虛擬共享內(nèi)存段。這反過來影響了 IDS 性能，并且最終會(huì)損害系統(tǒng)的性能。 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)存段多于三個(gè)，那么您需要提高配置文件中 SHMVERSIZE 參數(shù)的值。其思想是，讓 IDS 在初始化時(shí)分配足夠的虛擬共享內(nèi)存，以便在用戶登錄到系統(tǒng)并執(zhí)行數(shù)據(jù)庫操作時(shí)無需分配 更多的虛擬共享內(nèi)存。您可能還想使用 UNIX174。 ipcs 命令來查看 Informix 共享內(nèi)存的大小。有關(guān)如何計(jì)算 IDS 虛擬共享內(nèi)存段大小的詳細(xì)信息操作系統(tǒng)的整體性能 由于 Informix 數(shù)據(jù)庫引擎總是安裝在某個(gè)操作系統(tǒng)（主要是 UNIX）上，以準(zhǔn)確地監(jiān)控或評(píng)估 IDS 性能，因此我們需要將操作系統(tǒng)的行為作為一個(gè)整體來考慮，在數(shù)據(jù)庫引擎駐留在非專用數(shù)據(jù)庫服務(wù)器上時(shí)尤其要這樣考慮。如果 IDS 占用了太多 RAM（例如，如果系統(tǒng)有 512MB RAM，而 IDS 占用了 400MB 或更多作為其 共享內(nèi)存），那么當(dāng)用戶執(zhí)行內(nèi)存密集型操作時(shí)，操作系統(tǒng)可能會(huì)經(jīng)歷頻繁的交換和掛起。當(dāng)內(nèi)存不足時(shí)，系統(tǒng)必須將一些數(shù)據(jù)頁從內(nèi)存交換到磁盤，以便為新數(shù)據(jù)騰出更多空間。如果系統(tǒng)內(nèi)存不足，那么 CPU 可能也會(huì)遭殃。有不少 UNIX 實(shí)用程序可以監(jiān)控操作系統(tǒng) CPU 和內(nèi)存的整體利用率。以下是來自 ―top‖實(shí)用程序的輸出： load averages: , , 10:17:30 123 processes: 120 sleeping, 1 zombie, 2 on cpu CPU states: % idle, % user, % kernel, % iowait, % swap Memory: 3072M real, 76M free, 588M swap in use, 440M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND 28349 omcadmin 4 0 0 86M 55M cpu10 970:25 % 17782 informix 5 30 10 1631M 1594M sleep % 17784 informix 5 59 10 1631M 1594M sleep % 17786 informix 5 59 10 1631M 1591M sleep % 571 root 1 58 0 361M 129M sleep % em_mis 17785 informix 5 59 10 1631M 1592M sleep % 5470 omcadmin 1 0 0 1960K 1408K cpu15 0:00 % top 上面的輸出包含兩部分。第一部分為您匯總了操作系統(tǒng)的 CPU 和內(nèi)存的整體使用情況，第二部分則 提供了有關(guān)每個(gè)處理器的詳細(xì)信息。其它實(shí)用程序（如 vmstat、 iostat、 ps ef 和 sar ）在收集操作系統(tǒng)當(dāng)前的性能統(tǒng)計(jì)信息方面也很有用。 vmstat 顯示目前操作系統(tǒng)交換了多少內(nèi)存； iostat 和 sar 顯示了當(dāng)前在所有物理磁盤中磁盤 I/O 的分配；而 ps ef 打印出當(dāng)前各個(gè)處理器的登錄時(shí)間、 CPU 及內(nèi)存使用情況的詳細(xì)信息。此外也有許多圖形工具可用，這些工具使您能夠繪制操作系統(tǒng)資源利用率和性能的動(dòng)態(tài)變化。 監(jiān)控?cái)?shù)據(jù)庫活動(dòng) 對(duì)數(shù)據(jù)庫活動(dòng)進(jìn)行監(jiān)控的目的在于確保每個(gè)數(shù)據(jù)庫時(shí)刻都 將其能力發(fā)揮到了極致。這意味著：您必須留意潛在的性能問題，確定其根源并將其消滅在萌芽狀態(tài)。以下是要留意的幾個(gè)方面。 表擴(kuò)展塊 擴(kuò)展塊是一塊物理上連續(xù)的頁。然而，如果一個(gè)表有多個(gè)擴(kuò)展塊，那就不能保證這些擴(kuò)展塊是連續(xù)的；擴(kuò)展塊可能會(huì)散布在表所駐留的整個(gè) dbspace 上。物理頁的連續(xù)性對(duì)于性能十分重要。當(dāng)數(shù)據(jù)頁連續(xù)時(shí)，訪問磁盤數(shù)據(jù)所用的時(shí)間就最短，而數(shù)據(jù)庫也能連續(xù)地讀取行。如果表有太多擴(kuò)展塊，那么那些擴(kuò)展塊極有可能相互交錯(cuò)。這極大地影響了性能，因?yàn)楫?dāng)您檢索某個(gè)表的數(shù)據(jù)時(shí)，磁頭需要對(duì)屬于該表的多個(gè)非連續(xù)擴(kuò)展塊進(jìn) 行尋道，而不是對(duì)具有連續(xù)物理頁的一個(gè)大擴(kuò)展塊進(jìn)行尋道。這會(huì)顯著地降低磁盤尋道速度。下面的腳本檢測(cè)具有多個(gè)擴(kuò)展塊的數(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 如果除了大型分段表以外，任何表的擴(kuò)展塊超過了 10 個(gè)，那么您應(yīng)該考慮重新構(gòu)建這些表以合并擴(kuò)展塊。對(duì)于較大的數(shù)據(jù)庫或者大小設(shè)置不是很好的數(shù)據(jù)庫，我們可能還會(huì)關(guān)注擴(kuò)展塊的最大數(shù)目，或者會(huì)擔(dān)心針對(duì)索引的 32GB 限制。有關(guān)如何對(duì)表估計(jì)和分配數(shù)據(jù)塊大小的詳細(xì)信息， 索引層 索引 的層數(shù)也可能會(huì)對(duì)性能產(chǎn)生不利影響。索引層越多， IDS 到達(dá)索引葉節(jié)點(diǎn)所需的探測(cè)也就越多。而且，如果葉節(jié)點(diǎn)被拆分或合并，那么整個(gè)索引對(duì)這一變化進(jìn)行調(diào)整將要花費(fèi)更多的時(shí)間。例如，如果索引只有兩層，那么只需要調(diào)整兩層，但如果索引有四層，那么相應(yīng)地就需要對(duì)所有四層進(jìn)行調(diào)整。用于這一調(diào)整的時(shí)間當(dāng)然也就長得多。在 OLTP 環(huán)境中會(huì)進(jìn)行頻繁的插入、刪除和更新，這些操作會(huì)導(dǎo)致不斷地對(duì)索引進(jìn)行拆分和合并，因此上述問題也就格外明顯。下面的腳本標(biāo)識(shí)每個(gè)索引的層數(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 如果哪個(gè)索引超過了 4 層，您可能就需要考慮刪除和重新構(gòu)建該索引，從而合并其層，以獲取更好的性能。 索引唯一性 索引的重復(fù)程度很高會(huì)嚴(yán)重地影響更新和刪除的性能。假定表 customer 的 customer_type 列上有一個(gè)索引，而可能的 customer_type 代碼只有五種。如果這個(gè)表有一百萬行，那么可能有 202100 行具有相同的 customer_type 代碼。 B樹存儲(chǔ)鍵值，其后跟一個(gè)指向每個(gè)物理行的指針列表。在必須刪除或更新任何鍵值時(shí)，問題出現(xiàn)了。 IDS 必須找遍所有的重復(fù)內(nèi)容， 直到找到要?jiǎng)h除或更新的正確鍵為止！ 下面的腳本用來標(biāo)識(shí)重復(fù)程度很高的索引： select tabname, idxname, nrows, nunique from systables t, sysindexes I where = and 99 and nrows 0 and nunique 0 輸出如下所示： tabname idxname nrows nunique bsc_dte bscdte_i 6 6 omcgttready 231_413 1 1 systemrelease 451_478