Oracle RAC環境で、最終的にブロックされたセッションを特定して殺す-続き

以前は、Oracle RAC環境で最終的にブロックされたセッションを特定して殺していましたが、最終的にSQLを使用してRACインスタンス間のすべてのブロック関係をクエリーしました.しかし、実際には極端な生産環境では、複雑なSQL文を実行することは許されず、実行可能な現場でもSQLのコピーが容易ではなく、手で叩くと効率が低下するため、最終的なブロックセッション、すなわちDBAでよく使われるoradebug hanganalyzeを迅速に位置決めする別の簡単な方法を紹介します.

1.シミュレーション障害

2.oradebug hanganalyze

3.解析traceファイル

1.模擬故障

Oracle RAC環境で最終的にブロックされたセッションを特定して殺すことに基づいてシミュレーションを行います.前のSQLクエリーに従った場合、結果は次のとおりです.

SYS@jyzhao1 >--cascade blocking@gv$session
SYS@jyzhao1 >select *
  2    from (select a.inst_id, a.sid, a.serial#,
  3                 a.sql_id,
  4                 a.event,
  5                 a.status,
  6                 connect_by_isleaf as isleaf,
  7                 sys_connect_by_path(a.SID||'@'||a.inst_id, ' 

2.oradebug hanganalyze

現在、SQLクエリーを使用する環境が不便であると仮定すると、oradebug hanganalyzeを使用して分析する必要があります.oradebug hanganalyze 3
ここではRAC環境なので、すべてのインスタンスを分析する必要があります:oradebug-g all hanganalyze 3

SYS@jyzhao1 >oradebug -g all hanganalyze 3
Hang Analysis in /opt/app/oracle/diag/rdbms/jyzhao/jyzhao1/trace/jyzhao1_diag_1919.trc

3.traceファイルの分析

この生成されたtrcファイルを分析すると、HANG分析部分がはっきりと見え、2つのchainが存在する.例えば、私のこの実験の場合、Chain 1:インスタンス1のセッション29がインスタンス2のセッション148によってブロックされ、インスタンス2のセッション148がインスタンス1のセッション26によってブロックされていることがわかる.Chain 2:インスタンス2のセッション23は、インスタンス2のセッション148によってブロックされ、インスタンス2のセッション148は、第1のchainにあることがわかる.これは私が以前SQLで検索した結果と同じ意味であることがわかり、最終的にブロックされたセッションがインスタンス1のセッション26であることを迅速に特定し、お客様と確認して殺すことができます.
添付:oradebug hanganalyze 3分析のtraceファイルのコア情報

*** 2018-04-21 07:51:44.975
===============================================================================
HANG ANALYSIS:
  instances (db_name.oracle_sid): jyzhao.jyzhao1, jyzhao.jyzhao2
  oradebug_node_dump_level: 3
  analysis initiated by oradebug
  os thread scheduling delay history: (sampling every 1.000000 secs)
    0.000000 secs at [ 07:51:44 ]
      NOTE: scheduling delay has not been sampled for 0.305046 secs    0.000000 secs from [ 07:51:40 - 07:51:45 ], 5 sec avg
    0.000000 secs from [ 07:50:45 - 07:51:45 ], 1 min avg
    0.000000 secs from [ 07:46:45 - 07:51:45 ], 5 min avg
  vktm time drift history
===============================================================================
 
Chains most likely to have caused the hang:
 [a] Chain 1 Signature: 'SQL*Net message from client'<='enq: TX - row lock contention'<='enq: TX - row lock contention'
     Chain 1 Signature Hash: 0x42598823
 [b] Chain 2 Signature: 'SQL*Net message from client'<='enq: TX - row lock contention'<='enq: TX - row lock contention'
     Chain 2 Signature Hash: 0x42598823
 
===============================================================================
Non-intersecting chains:
 
-------------------------------------------------------------------------------
Chain 1:
-------------------------------------------------------------------------------
    Oracle session identified by:
    {
                instance: 1 (jyzhao.jyzhao1)
                   os id: 2712
              process id: 42, oracle@jyrac1 (TNS V1-V3)
              session id: 29
        session serial #: 81
    }
    is waiting for 'enq: TX - row lock contention' with wait info:
    {
                      p1: 'name|mode'=0x54580006
                      p2: 'usn<<16 | slot'=0xe0002
                      p3: 'sequence'=0x3a3
            time in wait: 8 min 21 sec
           timeout after: never
                 wait id: 37
                blocking: 0 sessions
             current sql: update emp set job = 'CEO' where empno = 7839
             short stack: ksedsts()+465 Oracle session identified by:
    {
                instance: 2 (jyzhao.jyzhao2)
                   os id: 23427
              process id: 41, oracle@jyrac2 (TNS V1-V3)
              session id: 148
        session serial #: 17715
    }
    which is waiting for 'enq: TX - row lock contention' with wait info:
    {
                      p1: 'name|mode'=0x54580006
                      p2: 'usn<<16 | slot'=0x50008
                      p3: 'sequence'=0x9e6
            time in wait: 9 min 9 sec
           timeout after: never
                 wait id: 152
                blocking: 2 sessions
             current sql: update emp set job = 'MANAGER' where empno = 7788
             short stack: ksedsts()+465 Oracle session identified by:
    {
                instance: 1 (jyzhao.jyzhao1)
                   os id: 1648
              process id: 32, oracle@jyrac1 (TNS V1-V3)
              session id: 26
        session serial #: 3479
    }
    which is waiting for 'SQL*Net message from client' with wait info:
    {
                      p1: 'driver id'=0x62657100
                      p2: '#bytes'=0x1
            time in wait: 9 min 28 sec
           timeout after: never
                 wait id: 168
                blocking: 3 sessions
             current sql: 
             short stack: ksedsts()+465

このoradebug hanganalyzeで生成されたtrcファイルはそれほど理解しにくいものではなく、専門的なOracle DBAとして、このようなchainの記述がより明確になっていることがわかります.