數(shù)據(jù)庫應(yīng)用突然變慢，查看系統(tǒng)信息，發(fā)現(xiàn) CPU 空閑突然很低，IO 性能沒有明顯惡化。

首先，需要排除操作系統(tǒng)上其他應(yīng)用程序的問題。通過 top(HP)/topas(AIX/Linux) 命令可以看到當前占用 CPU 資源最多的進程，確認是 oninit 進程。Solaris 上默認沒有 top 命令，可以通過 /usr/ucb/ps –aux | more 的方式來查看，該輸出是根據(jù) CPU 占用情況來排序的。

數(shù)據(jù)庫進程占用了大量 CPU 資源時，往往是在對大表在做全表掃描。通過 4.1 中的辦法初步確認問題 SQL 后，如果是條件查詢 SQL，如帶 WHERE 條件的 SELECT /UPDATE /DELETE，還可以通過得到具體的 SQL 查詢計劃來確認是在進行全表掃描。此時需要對比 dbschema 得到的建表腳本，看是否建立了相應(yīng)的索引，如果沒有合適的索引，應(yīng)該創(chuàng)建；如果應(yīng)用沒有合理應(yīng)用已有索引，應(yīng)該考慮修改應(yīng)用 SQL。如果表上有合適的索引，應(yīng)用 SQL 也沒有問題，那么就有可能是由于表中數(shù)據(jù)已經(jīng)變化較大而長時間未對表收集統(tǒng)計信息，造成數(shù)據(jù)庫引擎選擇了錯誤的查詢計劃。此時應(yīng)該對該表收集統(tǒng)計信息后，通?？梢允盏搅己玫男Ч?。

有時候問題 SQL 還會是 INSERT 語句，此時通常需要查看表的建表腳本，看看表上是否有過多的索引，是否該表上有不適當?shù)耐怄I指向另一個大表，也可以通過適當刪除表中的記錄來實現(xiàn)優(yōu)化。

新應(yīng)用 / 新模塊投入運行

數(shù)據(jù)庫應(yīng)用突然變慢，查看系統(tǒng)信息，發(fā)現(xiàn) CPU 空閑突然很低，IO 性能明顯惡化。和問題 1 的顯著不同在于，此時 IO 惡化現(xiàn)象非常明顯。

Vmstat 顯示 b(block) 很大，有很多等待 IO 的進程， sar 顯示 wio 明顯超過平時值。觀察數(shù)據(jù)庫日志，發(fā)現(xiàn)數(shù)據(jù)庫檢查點持續(xù)時間 (checkpoint duration time) 顯著增加，平時在 3 秒以內(nèi)就能完成，此時需要 10 秒甚至更長時間才能完成。

首先還是查看數(shù)據(jù)庫日志和操作系統(tǒng)日志，排除數(shù)據(jù)庫內(nèi)部錯誤和操作系統(tǒng) IO 錯誤。如果用的是陣列 (RAID)，最好再查看一下陣列的日志，出現(xiàn)這種情況最常見的原因是陣列出了問題，比如電池沒電，cache 沒有打開等等。

排除了操作系統(tǒng)和數(shù)據(jù)庫內(nèi)部錯誤，就需要了解一下是否有新的應(yīng)用在進行大批量的數(shù)據(jù)操作，如 INSERT/DELETE/UPDATE，是否能將這些操作放在系統(tǒng)相對空閑的時候進行。對于大批量的數(shù)據(jù)導(dǎo)入操作，在 INFORMIX9.4 中提供了 RAW 類型的表，由于不記錄邏輯日志，插入速度會快很多，導(dǎo)入完成后，再將表修改為正常模式；對普通表應(yīng)該先導(dǎo)入數(shù)據(jù)，再創(chuàng)建索引，注意主鍵、外鍵默認都會創(chuàng)建索引，應(yīng)該在數(shù)據(jù)導(dǎo)入后在創(chuàng)建。

不恰當?shù)膽?yīng)用 SQL 也會導(dǎo)致 IO 量非常大，可以用案例 1 中的辦法來找到問題 SQL，根據(jù)實際情況進行處理。

• 新應(yīng)用 / 新模塊投入運行
• 陣列、存儲的硬件問題

數(shù)據(jù)庫穩(wěn)定運行一段時間后，性能開始下降，檢查點持續(xù)時間 (checkpoint duration time) 開始逐漸增加，系統(tǒng) CPU 空閑降低，WIO 有所增加。這些情況往往出現(xiàn)在新的應(yīng)用上線后一段時間，由于在開發(fā)和測試環(huán)境中數(shù)據(jù)量小，性能問題不會暴露，當生產(chǎn)環(huán)境數(shù)據(jù)量增長到一定程度后，性能問題就會出現(xiàn)。

針對這種情況，需要確認定期在對數(shù)據(jù)庫，尤其是對數(shù)據(jù)庫中的大表，在定期做收集統(tǒng)計數(shù)據(jù)的工作 (update statistics)，避免數(shù)據(jù)量的增大造成系統(tǒng)性能急劇下降。

利用 4.2 中描述的辦法找到被順序掃描多次的大表及其上的問題 SQL，進行分析，采取相應(yīng)辦法嘗試減少其上的順序掃描：

• 創(chuàng)建相應(yīng)索引；
• 修改應(yīng)用 SQL；
• 及時刪除表中不必要的數(shù)據(jù)。

回頁首

select sqx_estcost,
                        sqx_sqlstatement
                        from syssqexplain
                        order by sqx_estcost desc
                        

注意：此時看到的僅僅是當前正在執(zhí)行的 SQL

需要多看幾次

onstat -g act 得到當前正在執(zhí)行的 SQL

Running threads:
                        tid tcb rstcb prty status vp-class name
                        75 a327318 a14d6b4 2 cond wait(sm_read) 1cpu sqlexec
                        76 a327b40 a14d280 2 yield lockwait 1cpu sqlexec
                        

根據(jù) rstcb 列（不要包括前面的 C0000 等，僅要后面部分）

onstat -u | grep a14d6b4

從第三列 sessid 得到 session id

onstat -g sql <sessid> 即可得到當時正在執(zhí)行的 SQL

一般多找?guī)讉€ threads 后，就基本可以確定問題 SQL

onstat –g act
                        Threads:
                        tid tcb rstcb prty status vp-class name
                        141904 84176538 8030eab8 2 running 1cpu sqlexec
                        onstat –u | grep 8030eab8
                        Userthreads
                        address flags sessid user tty wait tout locks nreads nwrites
                        8030eab8 Y--P--- 131047 informix - 84022480 0 1 11671 14722
                        onstat –g sql 131047
                        Sess SQL Current Iso Lock SQL ISAM F.E.
                        Id Stmt type Database Lvl Mode ERR ERR Vers
                        131047 DELETE (all) testdb DR Wait 10 0 0 9.03
                        Current SQL statement :
                        delete from my_tab
                        Last parsed SQL statement :
                        delete from my_tab
                        

得到 SQL 后，利用 set explain on 分析其查詢路徑，

看是否未利用索引，在對大表進行全表掃描

根據(jù)需要創(chuàng)建相應(yīng)索引