免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

打開APP
userphoto
未登錄

開通VIP,暢享免費電子書等14項超值服

開通VIP
Informix 性能調優(yōu)案例講解

Informix 性能調優(yōu)案例講解

牛新莊 (niuxinzhuang.zh@ccb.com), 博士,IBM 官方高級培訓講師, 自由著者

2008 年 10 月 21 日

在實際的生產(chǎn)運行環(huán)境中,筆者在國內(nèi)很多客戶現(xiàn)場都看到開發(fā)人員和系統(tǒng)管理人員遇到很多有關于 Informix 數(shù)據(jù)庫引起的性能問題,進而被多次問起如何進行 Informix 數(shù)據(jù)庫性能調優(yōu),筆者根據(jù)自己在工作中對 Informix 數(shù)據(jù)庫的使用經(jīng)驗積累寫下這篇文章。

概述

在實際的生產(chǎn)運行環(huán)境中,筆者在國內(nèi)很多客戶現(xiàn)場都看到開發(fā)人員和系統(tǒng)管理人員遇到很多有關于 Informix 數(shù)據(jù)庫引起的性能問題,進而被多次問起如何進行 Informix 數(shù)據(jù)庫性能調優(yōu),筆者根據(jù)自己在工作中對 Informix 數(shù)據(jù)庫的使用經(jīng)驗積累寫下這篇文章。





回頁首


性能優(yōu)化原則

包括:

  • 性能規(guī)劃:深入了解應用與數(shù)據(jù)庫的交互特征,確立良好的設計、開發(fā)、測試迭代過程,上線前消除模型上的性能瓶頸。
  • 實例調優(yōu):建立性能基準,對比調節(jié)數(shù)據(jù)庫、操作系統(tǒng)、存儲、網(wǎng)絡等的配置,主動監(jiān)控、消除瓶頸。
  • SQL 調優(yōu):書寫高效 SQL,優(yōu)化相關數(shù)據(jù)庫對象,充分借助優(yōu)化器,確定最佳執(zhí)行計劃。




回頁首


性能優(yōu)化流程

  1. 首先執(zhí)行下面的初始檢查:
    • 獲取直接用戶的使用反饋,確定性能目標和范圍。
    • 獲取性能表現(xiàn)好與壞時的操作系統(tǒng)、數(shù)據(jù)庫、應用統(tǒng)計信息。
    • 對數(shù)據(jù)庫做一次全面健康檢查。
  2. 根據(jù)收集的信息,以及對應用特性的了解,構建性能概念模型,明確性能瓶頸所在,以及導致性能的根本原因。
    • 首先應該排除操作系統(tǒng)、硬件資源造成的瓶頸。
    • 然后針對數(shù)據(jù)庫系統(tǒng)性能進行分析
    • 必要時,還需要檢查應用日志,因為系統(tǒng)性能問題也可能由于應用非 SQL 部分造成瓶頸。
  3. 提出一系列針對的優(yōu)化措施,并根據(jù)它們對性能改善的重要程度排序,然后逐一加以實施。不要一次執(zhí)行所有的優(yōu)化措施,必須逐條嘗試,逐步對比。
  4. 通過獲取直接用戶的反饋驗證調節(jié)是否已經(jīng)產(chǎn)生預期的效果,否則,需要重新提煉性能概念模型,直到對應用特性了解進一步準確。
  5. 重復上述,直到性能達到目標或由于客觀約束無法進一步優(yōu)化。

當從操作系統(tǒng)層面判斷系統(tǒng)存在瓶頸并且是數(shù)據(jù)庫引起的,那么可以從下面的流程圖來解決


圖 1. 性能診斷優(yōu)化流程

(點擊查看大圖)





回頁首


典型性能問題案例

案例 1:數(shù)據(jù)庫應用突然變慢

問題特征

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

處理步驟

首先,需要排除操作系統(tǒ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 得到的建表腳本,看是否建立了相應的索引,如果沒有合適的索引,應該創(chuàng)建;如果應用沒有合理應用已有索引,應該考慮修改應用 SQL。如果表上有合適的索引,應用 SQL 也沒有問題,那么就有可能是由于表中數(shù)據(jù)已經(jīng)變化較大而長時間未對表收集統(tǒng)計信息,造成數(shù)據(jù)庫引擎選擇了錯誤的查詢計劃。此時應該對該表收集統(tǒng)計信息后,通??梢允盏搅己玫男Ч?。

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

易出現(xiàn)時機

新應用 / 新模塊投入運行

案例 2:檢查點持續(xù)時間突然顯著增加

問題特征

數(shù)據(jù)庫應用突然變慢,查看系統(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)部錯誤,就需要了解一下是否有新的應用在進行大批量的數(shù)據(jù)操作,如 INSERT/DELETE/UPDATE,是否能將這些操作放在系統(tǒng)相對空閑的時候進行。對于大批量的數(shù)據(jù)導入操作,在 INFORMIX9.4 中提供了 RAW 類型的表,由于不記錄邏輯日志,插入速度會快很多,導入完成后,再將表修改為正常模式;對普通表應該先導入數(shù)據(jù),再創(chuàng)建索引,注意主鍵、外鍵默認都會創(chuàng)建索引,應該在數(shù)據(jù)導入后在創(chuàng)建。

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

易出現(xiàn)時機

案例 3:檢查點持續(xù)時間逐漸緩慢增加

問題特征

數(shù)據(jù)庫穩(wěn)定運行一段時間后,性能開始下降,檢查點持續(xù)時間 (checkpoint duration time) 開始逐漸增加,系統(tǒng) CPU 空閑降低,WIO 有所增加。這些情況往往出現(xiàn)在新的應用上線后一段時間,由于在開發(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,進行分析,采取相應辦法嘗試減少其上的順序掃描:

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




回頁首


常見調優(yōu)技巧

找到 CPU 占用最高的 SQL

1. 在 sysmaster 庫中執(zhí)行

select sqx_estcost,                        sqx_sqlstatement                        from syssqexplain                        order by sqx_estcost desc                        

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

需要多看幾次

2. onstat 命令

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

3. 示例

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)建相應索引

找到全表掃描較多的表及其 SQL

1. 得到全表掃描較多的表

  cat <<! > check.sql                        -- 系統(tǒng)順序掃描較多時,被多次順序掃描的大表,如果有,應該考慮增加索引                        select first 5 substr(t.tabname,0,20) tabname,substr(dbsname,0,10) dbname,                        nrows*rowsize*p.seqscans costs,                        substr(p.seqscans,0,8) seqscans,substr(nrows,0,8) nrows                        from sysmaster:sysptprof p , systables t,sysmaster:sysprofile s                        where p.tabname = t.tabname                        and p.seqscans > s.value/50                        and s.name = 'seqscans'                        --and s.value > 2000000                        and nrows > 2000                        order by 3 desc                        !                        dbaccess sysmaster <<!                        unload to /tmp/db delimiter ';'                        select 'dbaccess '||trim(name)||' check.sql' from sysdatabases                        where name not like 'sys%'                        !                        ksh /tmp/db                        

2. 利用 onstat –g ses 0 –r 5/ onstat –g stm 的輸出信息,根據(jù)表名,找到可能的 SQL 語句。由于以上獲取 SQL 的辦法是有局限的,如果無法獲取,建議通過查看應用日志或聯(lián)系開發(fā)人員查看源代碼的方式來找到。

3. 利用 set explain on 分析其查詢路徑,確認是在對表進行全表掃描,根據(jù)需要創(chuàng)建相應索引。





回頁首


免責聲明和公開聲明


本文所述觀點是基于作者個人對相關產(chǎn)品的理解,并不代表 IBM 的官方觀點,IBM 不對本文中的信息負責。



參考資料



關于作者

 

牛新莊博士是 IBM 官方高級培訓講師,于 2002 年獲 IBM 杰出軟件專家獎,于 2006 年獲得“首屆中國杰出數(shù)據(jù)庫工程師獎”,獲得“2006 年 IT168 技術卓越獎”,是中國建設銀行總行外聘資深技術專家,是中信銀行,山東農(nóng)信等公司的資深技術顧問,他擁有 OCP,AIX,DB2,HP-UX,MQ,CICS 和 WebSphere 等二十多項國際認證。曾經(jīng)幫助工農(nóng)商建招交六大行、上海移動、青島海爾、云南紅塔、江蘇電力公司等公司做過問題診斷、性能調優(yōu)和技術支持,他經(jīng)常往返于國內(nèi)大中城市解決數(shù)據(jù)庫技術難題,有著豐富的理論和實踐經(jīng)驗。他擁有 DB2 V5/V6 ,V7,V8,V9 所有 DB2 認證,是國內(nèi)擁有DB2 認證最多的 DBA。

本站僅提供存儲服務,所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權內(nèi)容,請點擊舉報。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
INFORMIX數(shù)據(jù)庫常用命令(未分析)
informix命令集
Informix on aix手冊
Informix 數(shù)據(jù)庫優(yōu)化
58到家數(shù)據(jù)庫30條軍規(guī)解讀
面向程序員的數(shù)據(jù)庫訪問性能優(yōu)化法則
更多類似文章 >>
生活服務
分享 收藏 導長圖 關注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權!
如果VIP功能使用有故障,
可點擊這里聯(lián)系客服!

聯(lián)系客服