[20191125]探究等待事件的本源.txt

lfree發表於2019-11-25

[20191125]探究等待事件的本源.txt

--//當工作中遇到oracle的效能問題時,檢視awr報表提供很好的解決問題途徑.但是有時候很容易想當然.
--//比如以前我一看到 log file sync等待事件就很主觀的認為redo 磁碟IO不行,實際上真實的情況可能有許多.
--//比如提交程式太多,cpu排程不過來.總之需要wait chains確定問題的本源.
--//上午看了大師Tanel Poder的dash_wait_chains.sql與ash_wait_chains.sql指令碼,簡單學習它的使用.
--//dash_wait_chains.sql 是基於DBA_HIST_ACTIVE_SESS_HISTORY檢視.而ash_wait_chains.sql基於V$ACTIVE_SESSION_HISTORY檢視.
--//二者命令執行格式差不多,僅僅學習ash_wait_chains.sql就ok了.

--//實際上根本不需要學習與記憶,看看指令碼的開頭就知道如何執行與使用:
-- Usage:
--     @ash_wait_chains <grouping_cols> <filters> <fromtime> <totime>
--
-- Example:
--     @ash_wait_chains username||':'||program2||event2 session_type='FOREGROUND' sysdate-1/24 sysdate
--
-- Other:
--     This script uses only the in-memory V$ACTIVE_SESSION_HISTORY, use
--     @dash_wait_chains.sql for accessiong the DBA_HIST_ACTIVE_SESS_HISTORY archive
--
--     Oracle 10g does not  have the BLOCKING_INST_ID column in ASH so you'll need
--     to comment out this column in this script. This may give you somewhat
--     incorrect results in RAC environment with global blockers.
--
--------------------------------------------------------------------------------

--//我做一點點簡單的修改:
COL wait_chain FOR A300 WORD_WRAP
--//修改為:
COL wait_chain FOR A200 WORD_WRAP

--//我的工作環境最大顯示寬度是271列.如果設定再小,字型顯示就太小,我同事許多設定才237.
$ echo $COLUMNS
271

--//因為我還需要管理10g的資料庫,根據前面的說明,可以複製指令碼命名為ash_wait_chains10g.sql.
--//註解如下,當然對於rac環境可能不正確.
--         AND PRIOR d.blocking_inst_id = d.inst_id

--//作者還重新定義欄位program,event為program2,event2.這樣顯示更加直觀,佔用寬度更小一些.
--//以下是測試部分:

1.環境:
qqqqqqqqqqq> @ ver1
PORT_STRING         VERSION    BANNER
------------------- ---------- ----------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

qqqqqqqqqqq> @ tpt/ash/ash_wait_chains  program2||':'||event2 1=1 trunc(sysdate)+9/24 trunc(sysdate)+10/24
-- Display ASH Wait Chain Signatures script v0.2 BETA by Tanel Poder ( http://blog.tanelpoder.com )
%This     SECONDS        AAS WAIT_CHAIN
------ ---------- ---------- -------------------------------------------------------------------
  33%        4362         .1 -> (XXXYYY.EXE) :ON CPU
  10%        1368          0 -> (NSSn) :LNS wait on SENDREQ
  10%        1323          0 -> (LGWR) :LGWR-LNS wait on channel
   6%         735          0 -> (XXXYYY.EXE) :log file sync  -> (LGWR) :LGWR-LNS wait on channel
   5%         605          0 -> (CAPAA-PIPE) :ON CPU
   5%         604          0 -> (XXXYYY.exe) :ON CPU
   4%         573          0 -> (wnwp.exe) :ON CPU
   3%         378          0 -> (DIAn) :ON CPU
   2%         274          0 -> (sqlplus) :ON CPU
   2%         246          0 -> (httpd.exe) :ON CPU
   2%         230          0 -> (PSPn) :ON CPU
   1%         115          0 -> (CKPT) :ON CPU
   1%         111          0 -> (LMSn) :ON CPU
   1%         111          0 -> (wnwp.exe) :log file sync  -> (LGWR) :LGWR-LNS wait on channel
   1%          89          0 -> (routine.exe) :ON CPU
   1%          87          0 -> (oracle) :ON CPU
   1%          86          0 -> (sqlplus) :control file sequential read
   1%          83          0 -> (LGWR) :ON CPU
   1%          76          0 -> (routine.exe) :log file sync  -> (LGWR) :LGWR-LNS wait on channel
   1%          72          0 -> (ARCn) :ON CPU
   1%          69          0 -> (XXXYYY.EXE) :gc current block 2-way
   1%          68          0 -> (XXXYYY.EXE) :gc cr block 2-way
   0%          63          0 -> (LGWR) :log file parallel write
   0%          55          0 -> (LMON) :ON CPU
   0%          55          0 -> () :null event
   0%          47          0 -> (XXXYYY.EXE) :log file sync
   0%          46          0 -> (nnnn.exe) :log file sync  -> (LGWR) :LGWR-LNS wait on channel
   0%          39          0 -> (LMSn) :gcs log flush sync  -> (LGWR) :LGWR-LNS wait on channel
   0%          38          0 -> (XXXYYY.EXE) :direct path read
   0%          38          0 -> (XXXYYY.EXE) :gc cr block busy
30 rows selected.

--//開始不理解AAS表示什麼.表示如下
ROUND(COUNT(*) / ((CAST(&4 AS DATE) - CAST(&3 AS DATE)) * 86400), 1) AAS
--//相當於每秒取樣幾次.
--//引數3,引數4是時間範圍,我建議使用類似例子的格式.你僅僅需要知道1/24表示1小時,1/1440表示1分鐘就ok了.
--//比如你需要檢視當天8:15到9:10的情況,時間可以寫成:
trunc(sysdate)+8/24+15/1440 trunc(sysdate)+9/24+10/1440
--//另外注意一點:V$ACTIVE_SESSION_HISTORY保留資訊有限制,時間太久的可能查詢不到.要改用dash_wait_chains.sql指令碼查詢.
--//引數2可以加入一些過濾例子:session_type='FOREGROUND' 或者使用 1=1 表示全部.

--//你可以看到這臺伺服器的log file sync等待事件實際上由於(LGWR) :LGWR-LNS wait on channel.
--//問題在與安裝配置dg時的引數:

qqqqqqqqqqq> show parameter log_archive_dest_2
NAME               TYPE   VALUE
------------------ ------ ----------------------------------------------------------------------------------------------------
log_archive_dest_2 string service=rzdbra lgwr sync reopen=15 max_failure=10 net_timeout=30 optional noaffirm db_unique_name=XXXXXX
--//對方配置了sync,這樣在提交時要確定dg方已經寫入日誌檔案才算提交.
--//如果改成async,相關等待LNS wait on SENDREQ,LGWR-LNS wait on channel,log file sync都會消失或者減少.

--//再來看看另外1個10g的資料庫:
WWWWWWWWW> @ ver1
PORT_STRING         VERSION        BANNER
------------------- -------------- ----------------------------------------------------------------
x86_64/Linux 2.4.xx 10.2.0.4.0     Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi

WWWWWWWWW> @ tpt/ash/ash_wait_chains10g  program2||':'||event2 1=1 trunc(sysdate)+9/24 trunc(sysdate)+10/24
-- Display ASH Wait Chain Signatures script v0.2 BETA by Tanel Poder ( http://blog.tanelpoder.com )
%This     SECONDS        AAS WAIT_CHAIN
------ ---------- ---------- ------------------------------------------------------------------------
  30%        3602         .1 -> (xxxzzzz.exe) :db file sequential read
  19%        2244          0 -> (DBWn) :ON CPU
  11%        1321          0 -> (LGWR) :log file parallel write
   9%        1113          0 -> (xxxzzzz.exe) :ON CPU
   7%         890          0 -> (xxxzzzz.exe) :db file scattered read
   6%         784          0 -> (xxxzzzz.exe) :log file sync  -> (LGWR) :log file parallel write
   5%         633          0 -> (aaatobbbb.exe) :log file sync  -> (LGWR) :log file parallel write
   4%         490          0 -> (CKPT) :control file parallel write
   1%         106          0 -> (wnwp.exe) :db file sequential read
   1%          88          0 -> (JDBC Thin Client) :db file sequential read
   1%          86          0 -> (aaatobbbb.exe) :db file scattered read
   1%          82          0 -> (mnnn) :db file sequential read
   0%          59          0 -> (xxxzzzz.exe) :read by other session
   0%          55          0 -> (wnwp.exe) :ON CPU
   0%          54          0 -> (JDBC Thin Client) :ON CPU
   0%          45          0 -> (plsqldev.exe) :enq: TX - row lock contention
   0%          44          0 -> (sqlplus) :ON CPU
   0%          27          0 -> (wnwp.exe) :log file sync  -> (LGWR) :log file parallel write
   0%          27          0 -> (aaatobbbb.exe) :ON CPU
   0%          25          0 -> (xxxzzzz.exe) :SQL*Net more data from dblink
   0%          25          0 -> (mnnn) :ON CPU
   0%          24          0 -> (ARCn) :log file sequential read
   0%          19          0 -> (xxxzzzz.exe) :db file parallel read
   0%          13          0 -> (CTWR) :ON CPU
   0%          13          0 -> (aaatobbbb.exe) :db file sequential read
   0%          12          0 -> (Jnnn) :db file sequential read
   0%          10          0 -> (aaatobbbb.exe) :log file sync
   0%          10          0 -> (SMON) :db file sequential read
   0%          10          0 -> (ARCn) :ON CPU
   0%          10          0 -> (CJQn) :ON CPU
30 rows selected.
--//可以發現這臺系統磁碟io已經不行.如果負荷在增加就不行.順便說一下這臺機器硬體配置很差.

WWWWWWWWW> @ tpt/ash/ash_wait_chains10g  event2 1=1 trunc(sysdate)+7/24 sysdate
-- Display ASH Wait Chain Signatures script v0.2 BETA by Tanel Poder ( http://blog.tanelpoder.com )
%This     SECONDS        AAS WAIT_CHAIN
------ ---------- ---------- -----------------------------------------------------------
  32%        4910         .1 -> db file sequential read
  32%        4887         .1 -> ON CPU
  12%        1896          0 -> log file sync  -> log file parallel write
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  11%        1761          0 -> log file parallel write
   7%        1078          0 -> db file scattered read
   4%         650          0 -> control file parallel write
   0%          59          0 -> read by other session
   0%          45          0 -> enq: TX - row lock contention
   0%          34          0 -> SQL*Net more data to client
   0%          34          0 -> SQL*Net more data from dblink
   0%          24          0 -> log file sequential read
   0%          23          0 -> db file parallel read
   0%          21          0 -> log file sync
   0%           7          0 -> log file switch completion
   0%           6          0 -> null event
   0%           5          0 -> change tracking file synchronous write
   0%           4          0 -> SQL*Net more data from client
   0%           4          0 -> control file sequential read
   0%           3          0 -> os thread startup
   0%           2          0 -> enq: CF - contention  -> control file parallel write
   0%           1          0 -> SQL*Net break/reset to client
   0%           1          0 -> Log archive I/O
   0%           1          0 -> latch: library cache
   0%           1          0 -> log file sync  -> ON CPU
24 rows selected.

--//注意看下劃線,log file sync主要是由於log file parallel write太慢造成的,與前面的不同.這樣定位問題就不會太盲目亂猜.

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

相關文章