【轉載】Oracle數據庫出現問題時,這十個腳本幫你快速定位原因

查看操作系統負載

    登上數據庫服務器後,第一個就是通過系統命令確認下CPU、內存、I/O是否異常,每個系統的命令不一樣,常見的有top、topas、vmstat、iostat。

 

查看等待事件

    第二步就是連到數據庫查看活動的等待事件,這是監控、巡檢、診斷數據庫最基本的手段,通常81%的問題都可以通過等待事件初步定爲原因,它是數據庫運行情況最直接的體現,如下腳本是查看每個等待事件的個數、等待時長,並排除了一些常見的IDLE等待事件。

--wait_event
col event for a45
SELECT  inst_id,EVENT, SUM(DECODE(WAIT_TIME, 0, 0, 1)) "Prev", SUM(DECODE(WAIT_TIME, 0, 1, 0)) "Curr", COUNT(*) "Tot" , sum(SECONDS_IN_WAIT) SECONDS_IN_WAIT
FROM GV$SESSION_WAIT
WHERE event NOT
IN ('smon timer','pmon timer','rdbms ipc message','SQL*Net message from client','gcs remote message')
    AND event NOT LIKE '%idle%'
    AND event NOT LIKE '%Idle%'
    AND event NOT LIKE '%Streams AQ%'
GROUP BY inst_id,EVENT
ORDER BY 1,5 desc

    這裏就需要掌握一些常見異常等待事件的原因,並形成條件反射,比如library cache lock、read by other session、row cache lock、buffer busy waits、latch:shared pool、gc buffer busy、cursor: pin S on X、direct path read、log file sync、enq: TX - index contention、PX Deq Credit: send blkd、latch free、enq: TX - row lock contention等等,如果異常等待事件的個數和等待時間很長,那麼排查原因的入口就在這裏。

 

根據等待事件查會話

    得到異常等待事件之後,我們就根據等待事件去查會話詳情,也就是查看哪些會話執行哪些SQL在等待,另外還查出來用戶名和機器名稱,以及是否被阻塞。另外如下腳本可改寫成根據用戶查會話、根據SQL_ID查會話等等。

 

-- wait_event
col event for a45
SELECT  inst_id,EVENT, SUM(DECODE(WAIT_TIME, 0, 0, 1)) "Prev", SUM(DECODE(WAIT_TIME, 0, 1, 0)) "Curr", COUNT(*) "Tot" , sum(SECONDS_IN_WAIT) SECONDS_IN_WAIT
FROM GV$SESSION_WAIT
WHERE event NOT
IN ('smon timer','pmon timer','rdbms ipc message','SQL*Net message from client','gcs remote message')
    AND event NOT LIKE '%idle%'
    AND event NOT LIKE '%Idle%'
    AND event NOT LIKE '%Streams AQ%'
GROUP BY inst_id,EVENT
ORDER BY 1,5 desc

 

查詢某個會話詳情

    得到會話列表之後,可以根據如下SQL查詢某個會話的詳細信息,如上次個執行的SQL_ID,登錄時間等,該SQL也可改寫成多個。

-- session_by_sid
SELECT s.sid, s.serial#, spid, event, sql_id, PREV_SQL_ID, seconds_in_wait ws, row_wait_obj# obj,
s.username, s.machine, module,blocking_session b_sess,logon_time  
FROM v$session s, v$process p 
WHERE sid = '&sid' AND s.paddr = p.addr

 

查詢對象信息

    從前面兩個SQL都可以看到會話等待的對象ID,可以通過如下SQL查詢對象的詳細信息。

 

-- session_by_sid
SELECT s.sid, s.serial#, spid, event, sql_id, PREV_SQL_ID, seconds_in_wait ws, row_wait_obj# obj,
s.username, s.machine, module,blocking_session b_sess,logon_time  
FROM v$session s, v$process p 
WHERE sid = '&sid' AND s.paddr = p.addr

 

查詢SQL語句

    根據SQL_ID、HASH_VALUE查詢SQL語句。如果v$sqlarea中查不到,可以嘗試DBA_HIST_SQLTEXT視圖中查詢。

-- sql_text
select sql_id,SQL_fullTEXT 
from v$sqlarea 
where (sql_id='&sqlid' or hash_value=to_number('&hashvale') ) 
and rownum<2

    關於SQL語句的執行計劃、對象的統計信息、性能診斷、跟蹤SQL等這裏就不展開,後面計劃出一個類似的系列,敬請關注。

 

查詢會話阻塞情況

    通過如下SQL查詢某個會話阻塞了多少個會話。

-- blocking_sess
select count(*),blocking_session 
from v$session 
where blocking_session is not null 
group by blocking_session;

 

查詢數據庫的鎖

 

    通過如下SQL查詢某個會話的鎖,有哪些TM、TX鎖,以及會話和鎖關聯查詢的SQL,注意這裏指定了ctime大於100秒,30%的情況是人爲誤操作鎖表,導致應用SQL被阻塞,無法運行。

-- lock
set linesize 180
col username for a15
col owner for a15
col OBJECT_NAME for a30
col SPID for a10
--查詢某個會話的鎖
select /*+rule*/SESSION_ID,OBJECT_ID,ORACLE_USERNAME,OS_USER_NAME,PROCESS,LOCKED_MODE 
from gv$locked_object where session_id=&sid;
--查詢TM、TX鎖
select /*+rule*/* from v$lock 
where ctime >100 and type in ('TX','TM') order by 3,9;
--查詢數據庫中的鎖
select /*+rule*/s.sid,p.spid,l.type,round(max(l.ctime)/60,0) lock_min,s.sql_id,s.USERNAME,b.owner,b.object_type,b.object_name 
from v$session s, v$process p,v$lock l,v$locked_object o,dba_objects b 
where  o.SESSION_ID=s.sid and s.sid=l.sid and o.OBJECT_ID=b.OBJECT_ID 
and s.paddr = p.addr and l.ctime >100 and l.type in ('TX','TM','FB') 
group by s.sid,p.spid,l.type,s.sql_id,s.USERNAME,b.owner,b.object_type,b.object_name 
order by 9,1,3

 

保留現場證據

    有的問題可能需要分析很長時間,或者是需要外部人員協助分析,那麼保留現場證據就非常重要了,下面腳本是systemstate dump和hanganalyze步驟,如果有sqlplus無法登陸的情況,可以加-prelim參數。

--systemstate dump
sqlplus -prelim / as sysdba
oradebug setmypid
oradebug unlimit;
oradebug dump systemstate 266;
--wait for 1 min
oradebug dump systemstate 266;
--wait for 1 min
oradebug dump systemstate 266;
oradebug tracefile_name;

--hanganalyze
oradebug setmypid
oradebug unlimit;
oradebug dump hanganalyze 3
--wait for 1 min
oradebug dump hanganalyze 3
--wait for 1 min
oradebug dump hanganalyze 3
oradebug tracefile_name

 

殺會話

    通常情況下,初步定爲問題後爲了快速恢復業務,需要去殺掉某些會話,特別是批量殺會話,有時還會直接kill所有LOCAL=NO的進程,再殺會話時一定要檢查確認,更不能在別的節點或者別的服務器上執行。

-- kill_sess
set line 199
col event format a35
--殺某個SID會話
SELECT /*+ rule */ sid, s.serial#, 'kill -9 '||spid, event, blocking_session b_sess 
FROM v$session s, v$process p WHERE sid='&sid' AND s.paddr = p.addr order by 1;
--根據SQL_ID殺會話
SELECT /*+ rule */ sid, s.serial#, 'kill -9 '||spid, event, blocking_session b_sess 
FROM v$session s, v$process p WHERE sql_id='&sql_id' AND s.paddr = p.addr order by 1;
--根據等待事件殺會話
SELECT /*+ rule */ sid, s.serial#, 'kill -9 '||spid, event, blocking_session b_sess 
FROM v$session s, v$process p WHERE event='&event' AND s.paddr = p.addr order by 1;
--根據用戶殺會話
SELECT /*+ rule */ sid, s.serial#, 'kill -9 '||spid, event, blocking_session b_sess 
FROM v$session s, v$process p WHERE username='&username' AND s.paddr = p.addr order by 1;
--kill所有LOCAL=NO進程
ps -ef|grep LOCAL=NO|grep $ORACLE_SID|grep -v grep|awk '{print $2}' |xargs kill -9

 

重啓大法

    如需要修改靜態參數、內存等問題,需要重啓數據庫,(不要覺得重啓很LOW,在很多情況下爲了快速恢復業務經常使用這個從網吧裏傳出來的絕招),記住千萬不要在這個時候死磕問題原因、當作課題研究,我們的首要任務是恢復業務。

 

tail -f alert_.log
alter system checkpoint;
alter system switch logfile;
shutdown immediate;

startup

 

轉載來源:https://mp.weixin.qq.com/s/T0V7rgd-BGL2fhzKd-nD5A

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章