【硬貨】Oracle資料庫出現問題時,這十個指令碼幫你快速定位原因

enmotech發表於2019-07-15

“喂,李總您好!”

“小張,快點看看ERP資料庫,應用又打不開了!”

“好的,馬上。”

小張從黑色揹包拿出電腦,連上手機熱點就開始檢查,剛連上資料庫,電話鈴聲又響起來了.....

這樣的場景對於Oracle DBA來說太熟悉了,只要應用一出問題,不論何時,不論何地,總是第一個接到電話,嚴重情況下會是一輪電話轟炸。

新手和專家之間遇到此類問題,首先是心態,新手遇到問題心裡慌,不知從何下手,膽小粗心,專家因為經驗豐富,往往沉著冷靜、運籌帷幄、抽絲剝繭、膽大心細,但是經驗這東西就跟吃過的鹽、走過的橋一樣,必須親自多做、多學才能獲得。而另外一個非常重要的就是診斷思路和輔助指令碼,本文講述各種場景下的通用處理思路,分享用到的一些指令碼,幫助大家快速定位問題並解決,減少業務的中斷事件,早日成為專家,升職加薪,迎娶...

>>>>檢視作業系統負載

登上資料庫伺服器後,第一個就是透過系統命令確認下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查會話等等。

--墨天輪 session_by_event 
SELECT /*+rule */ sid, s.serial#, spid, event, sql_id, seconds_in_wait ws, row_wait_obj# obj, s.username, s.machine,  
BLOCKING_INSTANCE||'.'||blocking_session b_sess FROM v$session s,  
v$process p WHERE event='&event_name' AND s.paddr = p.addr order by 6;

>>>>查詢某個會話詳情

得到會話列表之後,可以根據如下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查詢物件的詳細資訊。

--墨天輪 obj_info 
col OBJECT_NAME for a30 
select owner,object_name,subobject_name,object_type from dba_objects where  
object_id=&oid;

>>>>查詢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 ki

>>>>重啟方法

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

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

>>>>CRT按鈕小技巧

另外介紹一個小技巧,就是把常用的指令碼整理到SecureCRT的Button Bar中,只需要點一下設定好的button,就相當於直接執行相應的SQL語句,這樣就不用每次貼上複製執行,或者是把指令碼上傳到每個伺服器上。不過不要設定DDL等操作性的button,以免誤點。

【硬貨】Oracle資料庫出現問題時,這十個指令碼幫你快速定位原因

以上就是遇到資料庫問題用到的一些指令碼,特別是應用反應慢、卡的情況,另外建議首先對指令碼進行閱讀然後再使用,還可以根據自己的環境改寫,融會貫通,積累經驗。

我把這些指令碼都整理到 墨天輪的常用指令碼 中,上面還有許多其他監控、管理、診斷的工具指令碼,大家可以免費去上面複製下載使用。(點選下方下載即可免費複製下載~)

下載網址: cs.enmotech.com/scripts


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69933133/viewspace-2650516/,如需轉載,請註明出處,否則將追究法律責任。

相關文章