有些時侯，我當(dāng)然指的是非常少的情況下，我們會感覺我們的庫”Hang”了，加了隱號的意思是說有時真的是Hang了，有一些則不是，是由于性能的問題引起的。 我碰到過幾次Hang的情況，結(jié)合著網(wǎng)上一些文章，把可能的原因、當(dāng)時我們應(yīng)該做的一些操作進(jìn)行了如下的總結(jié)，不對的地方大家可以發(fā)Mail給我:[email protected]。一、數(shù)據(jù)庫Hang時可能的現(xiàn)象1、最直觀的是你的大部分的業(yè)務(wù)操作，比如說一個查詢都使用好長的時間，或根本就返回不出結(jié)果。這和簡單那種鎖表是有區(qū)別的。2、在操作系統(tǒng)上用Hp-unix用glance、Aix用nmon及用sar做監(jiān)測會出現(xiàn)系統(tǒng)空閑的假象，表面看起來系統(tǒng)很閑，實(shí)際上系統(tǒng)已經(jīng)Hang了。3、查v$session_wait會出現(xiàn)大量的”latch free”、”enqueue”、” free buffer waits”等等待事件，有時后臺會出現(xiàn)大量的.trc文件，另外需要觀注一下$Oracle_HOME/rdbms/log這個位置，有一些時侯trace文件會生成到這里。二、Oracle庫Hang時一些有用的操作和查詢1、假如要尋求Oracle的技術(shù)支持，我們需要dump一下Oracle的systemstate，操作如下SQL>conn / as sysdba;SQL> alter session set events 'immediate trace name SYSTEMSTATE level 10';需要等幾分鐘的時間，這時在init<SID>.ora中所設(shè)置的user_dump_dest所標(biāo)識的位置就可以找到這個.trc文件，一般比較大。2、捕捉一些視圖的狀態(tài)值SQL>conn / as sysdba;SQL>set linesize 500SQL>set pagesize 0SQL>spool v_views.txtSQL> SELECT * FROM v$parameter;SQL>SELECT class, value, name FROM v$sysstat; SQL>SELECT sid, id1, id2, type, lmode, request FROM v$lock; SQL>SELECT l.latch#, n.name, h.pid, l.gets, l.misses, l.immediate_gets, l.immediate_misses, l.sleeps FROM v$latchname n, v$latchholder h, v$latch l WHERE l.latch# = n.latch# AND l.addr = h.laddr(+); SQL>SELECT * FROM v$session_wait ORDER BY sid--隔幾秒重復(fù)執(zhí)行3次。SQL>spool off3、有條件的話用statspack生成了一個Report，假如你對statspach不熟悉，可以參照http://www.itpub.net/showthread.PHP?s=&threadid=144448這個鏈接。三、產(chǎn)生Hang可能的幾個原因1、開歸檔的情況下，歸檔位置所在的文件系統(tǒng)滿了，這時lgwr就會等待歸檔進(jìn)程的完成，DML寫不了日志，都處于等待的狀態(tài)。2、在HP的系統(tǒng)開異步Io時，沒為dba的組設(shè)置MLOCK權(quán)限。正常來說Oracle的啟動是會報錯的，可是有些時侯比如Oracle8.1.6的版本就不報錯啟動，但是此時的異步Io是有問題的，仔細(xì)查看你會在$ORACLE_HOME/rdbms/log看到大量的.trc文件。這種情形引的Hang我碰到過。3、由于異常進(jìn)程引起的，我所說的是那些占用系統(tǒng)資源(cpu,memory)非凡大的進(jìn)程，這些進(jìn)程一般占用cpu會達(dá)到90%以上，相對其它的進(jìn)程比較突出。可以通過hp-unix的glance、topas，IBM的nmod,topas,ps等工具進(jìn)行監(jiān)測。4、由于主機(jī)系統(tǒng)、陣列的某方面的瓶頸引起的，在實(shí)際中最普遍的應(yīng)該是Io的問題，比如IO方面有瓶頸，則dbwr、lgwr就會引” free buffer waits”、” log buffer space”等一系列的等待事件，此時是性能的問題，感覺起來像Hang。5、也有bug的因素，我的庫都是最新的補(bǔ)丁，這方面的問題還沒碰到過。四、幾點(diǎn)處理建議當(dāng)?shù)玫絆racle的庫奇慢或Hang時保持冷靜的頭腦很重要的，可以按如下的方法進(jìn)行一些處理：1、首先要到操作系統(tǒng)上去，用glance等工具進(jìn)行一下觀察，看一下cpu、內(nèi)存、交換區(qū)、磁盤的繁忙程度與平時是不是相似的，同時看一看有沒有占系統(tǒng)資源非凡大的進(jìn)程，有些時侯是這些進(jìn)程引起的，通過v$process和v$session兩個視圖找到這Oracle進(jìn)程的sid,serial#,把它用Alter system kill session ‘sid,serial#’;殺掉就行了。假如平時同樣的時段你的磁盤的繁忙程度是95%，而些時它為20%，當(dāng)然是假設(shè)了，說明Oracle的庫沒準(zhǔn)真的hang了。 2、時間來得及的話執(zhí)行一下”二”中的語句是很必要的，這樣可以把這些信息提交給Oracle的supporter，讓你們給你分析一下，查一下原因。3、假如你的庫開歸檔了，出現(xiàn)Hang的時侯一定要看一下歸檔日志的文件系統(tǒng)是不是滿了，做一個完備一些的網(wǎng)管系統(tǒng)是很必要的。4、在HP系統(tǒng)上打開異步IO時一定不要忘記為dba這個組加上MLOCK的權(quán)限，我就吃過這個虧。5、時常的觀注一下v$session_wait或用statspack進(jìn)行觀注一下等待事件，一般IO相關(guān)的事件較多，為Oracle打開異步IO、多加幾個寫進(jìn)程及為Oracle數(shù)據(jù)文件所用的raw device使用條帶都是很必要的。與應(yīng)用的開發(fā)商交流也很重要，沒準(zhǔn)最近新上的一個應(yīng)用就特耗IO或特占CPU資源。6、盡量要使用比較穩(wěn)定的Oracle的版本,比如Oracle8.1.7.4及Oracel9.2.0.4(最新為 9.2.0.5)都很穩(wěn)定的，可以少去好多的麻煩。