說一說 Oracle庫的Hang

2021-04-17 07:45:14 字數 2885 閱讀 4159

有些時侯,我當然指的是非常少的情況下,我們會感覺我們的庫」hang」了,加了隱號的意思是說有時真的是hang了,有一些則不是,是由於效能的問題引起的。我遇到過幾次hang的情況,結合著網上一些文章,把可能的原因、當時我們應該做的一些操作進行了如下的總結,不對的地方大家可以發mail給我:[email protected]

一、資料庫hang時可能的現象

1、最直觀的是你的大部分的業務操作,比如說乙個查詢都使用好長的時間,或根本就返回不出結果。這和簡單那種鎖表是有區別的。

2、在作業系統上用hp-unix用glance、aix用nmon及用sar做監測會出現系統空閒的假象,表面看起來系統很閒,實際上系統已經hang了。

3、查v$session_wait會出現大量的」latch free」、」enqueue」、」 free buffer waits」等等待事件,有時後台會出現大量的.trc檔案,另外需要觀注一下$oracle_home/rdbms/log這個位置,有一些時侯trace檔案會生成到這裡。

二、oracle庫hang時一些有用的操作和查詢

1、如果要尋求oracle的技術支援,我們需要dump一下oracle的systemstate,操作如下

sql>conn / as sysdba;

sql> alter session set events 'immediate trace name systemstate level 10';

需要等幾分鐘的時間,這時在init.ora中所設定的user_dump_dest所標識的位置就可以找到這個.trc檔案,一般比較大。

2、捕獲一些檢視的狀態值

sql>conn / as sysdba;

sql>set linesize 500

sql>set pagesize 0

sql>spool v_views.txt

sql> 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;  --隔幾秒重複執行3次。

sql>spool off

3、有條件的話用statspack生成了乙個report,如果你對statspach不熟悉,可以參照http://www.itpub.net/showthread.php?s=&threadid=144448這個鏈結。

三、產生hang可能的幾個原因

1、開歸檔的情況下,歸檔位置所在的檔案系統滿了,這時lgwr就會等待歸檔程序的完成,dml寫不了日誌,都處於等待的狀態。

2、在hp的系統開非同步io時,沒為dba的組設定mlock許可權。正常來說oracle的啟動是會報錯的,可是有些時侯比如oracle8.1.6的版本就不報錯啟動,但是此時的非同步io是有問題的,仔細檢視你會在$oracle_home/rdbms/log看到大量的.trc檔案。這種情形引的hang我遇到過。

3、由於異常程序引起的,我所說的是那些占用系統資源(cpu,memory)特別大的程序,這些程序一般占用cpu會達到90%以上,相對其它的程序比較突出。可以通過hp-unix的glance、topas,ibm的nmod,topas,ps等工具進行監測。

4、由於主機系統、陣列的某方面的瓶頸引起的,在實際中最普遍的應該是io的問題,比如io方面有瓶頸,則dbwr、lgwr就會引」 free buffer waits」、」 log buffer space」等一系列的等待事件,此時是效能的問題,感覺起來像hang。

5、也有bug的因素,我的庫都是最新的補丁,這方面的問題還沒遇到過。

四、幾點處理建議

當得到oracle的庫奇慢或hang時保持冷靜的頭腦很重要的,可以按如下的方法進行一些處理:

1、首先要到作業系統上去,用glance等工具進行一下觀察,看一下cpu、記憶體、交換區、磁碟的繁忙程度與平時是不是相似的,同時看一看有沒有佔系統資源特別大的程序,有些時侯是這些程序引起的,通過v$process和v$session兩個檢視找到這oracle程序的sid,serial#,把它用alter system kill session 『sid,serial#』;殺掉就行了。如果平時同樣的時段你的磁碟的繁忙程度是95%,而些時它為20%,當然是假設了,說明oracle的庫沒準真的hang了。

2、時間來得及的話執行一下」二」中的語句是很必要的,這樣可以把這些資訊提交給oracle的supporter,讓你們給你分析一下,查一下原因。

3、如果你的庫開歸檔了,出現hang的時侯一定要看一下歸檔日誌的檔案系統是不是滿了,做乙個完備一些的網管系統是很必要的。

4、在hp系統上開啟非同步io時一定不要忘記為dba這個組加上mlock的許可權,我就吃過這個虧。

5、時常的觀注一下v$session_wait或用statspack進行觀注一下等待事件,一般io相關的事件較多,為oracle開啟非同步io、多加幾個寫程序及為oracle資料檔案所用的raw device使用條帶都是很必要的。與應用的開發商交流也很重要,沒準最近新上的乙個應用就特耗io或特佔cpu資源。

6、盡量要使用比較穩定的oracle的版本,比如oracle8.1.7.4及oracel9.2.0.4(最新為 9.2.0.5)都很穩定的,可以少去好多的麻煩。

簡單的說一說mmap

mmap memory map,就是記憶體對映 簡單的說就是將檔案對映到使用者的位址空間中。這麼做有什麼好處呢?1.傳統檔案訪問方式是,首先用open系統呼叫開啟檔案,然後使用read,write等呼叫進行順序或者隨即的i o.這種方式是非常低效的,每一次i o操作都需要一次系統呼叫.而通過mmap...

說一說JS的IIFE

iife immediately invoked function expression,意為立即呼叫的函式表示式,也就是說,宣告函式的同時立即呼叫這個函式。對比一下,這是不採用iife時的函式宣告和函式呼叫 function foo foo 下面是iife形式的函式呼叫 functionfoo 函...

說一說JS的IIFE

iife immediately invoked function expression,意為立即呼叫的函式表示式,也就是說,宣告函式的同時立即呼叫這個函式。對比一下,這是不採用iife時的函式宣告和函式呼叫 function foo window console.log a 2 js的模組就是函式...