C24 analyzing oracle database hang issues using various diagnostics_pubic by Ryota Watabe
Upcoming SlideShare
Loading in...5
×
 

C24 analyzing oracle database hang issues using various diagnostics_pubic by Ryota Watabe

on

  • 466 views

 

Statistics

Views

Total Views
466
Views on SlideShare
466
Embed Views
0

Actions

Likes
0
Downloads
23
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

C24 analyzing oracle database hang issues using various diagnostics_pubic by Ryota Watabe C24 analyzing oracle database hang issues using various diagnostics_pubic by Ryota Watabe Presentation Transcript

  • Analyzing Oracle Database Hang Issuesusing diagnostics2013年05月30日JPOUGボードメンバー / 株式会社コーソル 渡部亮太
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reserved自己紹介+所属会社紹介 渡部 亮太(わたべ りょうた) JPOUG 共同創設者、ボードメンバー Oracle ACE 著書「プロとしてのOracleアーキテクチャ入門」「プロとしてのOracle運用管理入門」 ブログ「コーソルDatabaseエンジニアのBlog」http://co-sol.jp/techdb/ 株式会社コーソル 「CO-Solutions=共に解決する」の理念のもと、Oracle技術に特化した事業を展開中。心あるサービスの提供とデータベースエンジニアの育成に注力している。 社員数: 103名 (2013年5月現在) ORACLE MASTER Platinum Award 2012受賞1
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reservedこのセッションの概要 Oracle Databaseは極めて品質の高いデータベースソフトウェアです。 しかし、極めて稀なことではありますが、OS/ハードウェアなどの外的な要因やBugにより、ハングに類似した状況が発生することがあります。 Oracle Databaseには多くの優れた診断機能があるため、このような状況においても問題の特定や絞り込みができます。また、OSの診断機能も有効な場合があります。 本セッションでは、これらの診断機能を活用してハング事象を分析する方法について説明します。 あるハング事象を調査する流れに沿ったボトムアップアプローチでの説明を試みます。 都度調査に必要な知識を説明22
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reserved事象: 複数セッションがハング 複数のセッションの処理がハングした アラートログには特にエラーは出力されていない 処理のハングを確認したのは21:55~21:58の時間帯 21:58以降解消したように見える 21:55以前の状況はよくわからない 問題発生時に実行されていたセッションIDやSQLなどの情報は不明 再発に備えて原因を特定したい3調査対象となるこの事象を、以後「本事象」と記載します
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reservedハング分析に有用な診断情報1. HANG ANALYZE ハングに関係するセッション相互の待機関係(待機させている、待機している)をトレースファイルにDumpしたもの2. ASH(Active Session History) セッション情報(V$SESSION)を1秒おきに収集(+1/10に間引き)した情報 過去のある時点におけるセッションの状態、時系列でのセッション状態の推移を確認できる3. System State Dump インスタンス全体の極めて詳細な情報をトレースファイルにDumpしたもの 情報の取得と出力に時間を要する場合がある4. プロセスのスタックトレース 既知のBugに該当しているかの判断に有用 Oracleの関数命名ルールに熟知していれば、処理中の内容を推測できる 通常、System State Dumpを取得すると同時に取得される4要手動取得要手動取得自動収集要手動取得
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reservedそれぞれの診断情報の概念55HANGANALYZEコマンド実行時点のプロセス(セッション)間の待機関係System State Dumpコマンド実行時点のインスタンス全体の詳細情報ASH全セッションの推移(アイドルセッションを除く)Oracleインスタンス
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reserved併せて見ておくべき情報5. AWRレポート(Statspackレポート) Oracleインスタンスの重要統計を抜粋し、レポート化したもの マクロな視点からのパフォーマンス分析に使用される6. ログファイル類:アラートログ、syslogなど エラー発生有無 その他の情報メッセージ7. ユーザーが確認したOracle Databaseの動作にかかわる情報をヒアリングする 日時情報は重要 できるだけ具体的に 「確認方法」も抑えておくと誤解を減らすことができる 例) DBサーバにsshで接続してsqlplus scott/tigerを実行しても接続できなかった など6自動収集自動出力
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedKROWN:665597 ハング分析関連情報を一括収集する方法が記載されています ASH、 AWRレポート、一部OS情報は別途収集する必要ありMOS限定情報のためちょっと自粛
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reserved一般的な調査アプローチ 多面的かつ相互補完的なアプローチが求められる 診断情報を突き合わせて、総合的に判断する 「推論」の確からしさを高める とはいっても、どの順序で情報をみてゆくのか?1. HANGANALYZE2. ASH3. 状況に応じてOS観点の情報やSystem State Dump8
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedHANGANALYZE Oracle Databaseに組み込まれたハング診断情報 プロセス相互の待機関係を分析し、トレースファイルに出力する 待機関係=待機チェーン (Chain) 「待たせているプロセス」と「待たされているプロセス」の関係 待機原因が待機イベント(V$SESSIONではevent列)として表示される場合が多い HANGANALYZEの取得方法 ALTER SESSION SET EVENTS immediatetrace name HANGANALYZE level 3; SYSユーザーで実行する9待たせている待たされている待たせている待たされている
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedHANGANALYZEの出力例10*** 2013-05-27 21:55:52.883===============================================================================HANG ANALYSIS:(略)===============================================================================Chains most likely to have caused the hang:[a] Chain 1 Signature: log file parallel write<=log buffer space<=buffer busy waitsChain 1 Signature Hash: 0xf27e57e2[b] Chain 2 Signature: log file parallel write<=log buffer spaceChain 2 Signature Hash: 0x56c5cf5[c] Chain 3 Signature: log file parallel write<=log buffer space<=latch: In memory undo latchChain 3 Signature Hash: 0x1d6eb75b===============================================================================Non-intersecting chains:-------------------------------------------------------------------------------Chain 1:-------------------------------------------------------------------------------Oracle session identified by:{instance: 1 (b203.b203)os id: 5860process id: 15, oracle@l64rw3.domain (MMON)session id: 15session serial #: 1}is waiting for buffer busy waits with wait info:{p1: file#=0x3p2: block#=0x80p3: class#=0x11time in wait: 52.137595 secインスタンス内の全待機チェーンからの抜粋1番目の待機チェーンの待機関係を表示
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reserved本事象のChain 1 (抜粋)11-------------------------------------------------------------------------------Chain 1:-------------------------------------------------------------------------------Oracle session identified by:{instance: 1 (b203.b203)os id: 5860process id: 15, oracle@l64rw3.domain (MMON)session id: 15session serial #: 1}is waiting for buffer busy waits with wait info:{p1: file#=0x3p2: block#=0x80p3: class#=0x11time in wait: 52.137595 sec(略)}and is blocked by=> Oracle session identified by:{instance: 1 (b203.b203)os id: 6011process id: 21, oracle@l64rw3.domain (J000)session id: 43session serial #: 11}which is waiting for log buffer space with wait info:{time in wait: 1 min 2 sectimeout after: never(略)J000 21/43enq: CF -contentionlog buffer spaceMMON 15/15enq: CF -contentionbuffer busywaitsプロセスID 15のプロセス情報+セッション情報プロセスID 15の待機状態Chain 1プロセスID 21のプロセス情報+セッション情報プロセスID 21の待機状態
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reserved本事象のChain 1 (抜粋)12and is blocked by=> Oracle session identified by:{instance: 1 (b203.b203)os id: 6011process id: 21, oracle@l64rw3.domain (J000)session id: 43session serial #: 11}which is waiting for log buffer space with wait info:{time in wait: 1 min 2 sectimeout after: never(略)}and is blocked by=> Oracle session identified by:{instance: 1 (b203.b203)os id: 5852process id: 11, oracle@l64rw3.domain (LGWR)session id: 11session serial #: 1}which is waiting for log file parallel write with wait info:{p1: files=0x2p2: blocks=0x6d5cp3: requests=0xetime in wait: 1 min 8 sectimeout after: never(略)J000 21/43enq: CF -contentionlog buffer spaceLGWR 11/11enq: CF -contentionlog fileparallel write
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reserved本事象の全待機チェーン13LGWR 11/11log file parallel writeJ000 21/43enq: CF -contentionlog buffer spaceMMON 15/15enq: CF -contentionbuffer busy waits名称 pid/sid待機イベント名称 pid/sid待機イベント待機させているプロセス待機しているプロセスFG 39/22enq: CF -contentionlog buffer spaceFG 42/17enq: CF -contentionlog buffer spaceLGWRに何らかの問題がある可能性が疑われるFG 27/22enq: CF -contentionlatch: In memoryundo latchFG 29/28enq: CF -contentionlatch: In memoryundo latchFG 43/30enq: CF -contentionbuffer busy waits
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedASHの概要とデータの流れ1414OracleインスタンスV$SESSION表領域に保管+10秒単位にサンプリング1秒おきに取集V$SESSION V$SESSIONV$ACTIVE_SESSION_HISTORYDBA_HIST_ACTIVE_SESS_HISTORY• 必要ライセンス:Enterprise Edition + Diagnositc Pack全セッションの状態を定期的に取得した情報であるため、動作状態の変化を時系列に従って追うことが可能→ 慣れていないと実際の解析に時間を要しがち
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedASHのデータ構造15SAMPLE_TIME SESSION_IDSESSION_SERIAL#・・・ PROCESS ・・・ EVENT ・・・13-05-30 00:00:00 1 101 SMON rdbms ipc13-05-30 00:00:00 2 102 LGWR rdbms ipc13-05-30 00:00:0013-05-30 00:00:00 99 15 oracle SQL*Net …13-05-30 00:00:10 1 101 SMON rdbms ipc …13-05-30 00:00:10 2 102 LGWR rdbms ipc …13-05-30 00:00:1013-05-30 00:00:10 99 15 oracle SQL*Net13-05-30 00:00:20キー※:大幅に簡略化して書いています。実際のDBA_HIST_ACITVE_SESS_HISTORYの列定義についてはリファレンスマニュアルを参照してください。V$SESSION属性↑時間 ↑セッションの識別子DBA_HIST_ACTIVE_SESS_HISTORY
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedASHの分析方法1. ASHにSQLを発行して分析 特定の時間帯のデータのみを抜粋 キー(時刻、セッションID)や、識別子・ハッシュ値(SQL_ID,SQL_EXEC_ID, PLAN_HASH _VALUE)でGROUP BYして傾向分析 属性でフィルタして、注目すべきデータを抜粋する2. Excelにインポートして分析 オートフィルタ:キー、属性でフィルタして、注目すべきデータを抜粋する ピボットテーブル: (X軸,Y軸)= (時刻, セッション)の2次元分析が有用 複数のセッションの時系列変化を直観的に理解できる3. Oracle Enterprise Managerパフォーマンス画面 パフォーマンス分析への活用を目的としているため、ハング分析には若干マクロすぎる16
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedASH分析用SQLの例1. 事象発生時間帯を抽出2. セッション数の推移をみる(1分単位)17SELECT … FROM DBA_HIST_ACTIVE_SESS_HISTORYWHERE sample_time BETWEENto_timestamp(&start_time, yyyy-mm-dd HH24:mi:ss)AND to_timestamp(&end_time, yyyy-mm-dd HH24:mi:ss)SELECT to_char(sample_time, yyyy-mm-dd HH24:mi), count(distinct session_id)FROM DBA_HIST_ACTIVE_SESS_HISTORYWHERE sample_time betweento_timestamp(&start_time, yyyy-mm-dd HH24:mi:ss)AND to_timestamp(&end_time, yyyy-mm-dd HH24:mi:ss)GROUP BY to_char(sample_time, yyyy-mm-dd HH24:mi)ORDER BY to_char(sample_time, yyyy-mm-dd HH24:mi);
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedASH分析用SQLの例3. 長時間実行SQL上位30件を抽出4. 3. で特定したSQLを実行していたセッションを抽出18SELECT * FROM (SELECT sql_id, sql_exec_id, min(sample_time) , max(sample_time), max(sample_time) - min(sample_time) exec_timeFROM DBA_HIST_ACTIVE_SESSION_HISTORYGROUP BY sql_id, sql_exec_idORDER BY exec_time desc) WHERE rownum <=30;SELECT session_id, session_serial#, min(sample_time),max(sample_time)FROM DBA_HIST_ACTIVE_SESSION_HISTORYWHERE sql_id=<sql_id>GROUP BY session_id, session_serial#;参考) http://co-sol.jp/techdb/2013/05/oracle_database_11g_ash_enhancements_sql_exec_id.html
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedピボットテーブルによるASH分析19ピボットテーブルの作成方法についてはhttp://co-sol.jp/techdb/2013/05/analyze_ash_by_excel_db_tech_showcase_osaka_2013.html
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedHANGANALYZEとASHを踏まえて LGWRが怪しい HANG ANALYZE LGWRが全待機チェーンの末端に位置していた ASHの時系列分析 LGWRのlog file parallel write待機から問題動作が広がっているように見える ファイルI/Oに関する問題であるため、OSの観点から調査を継続したい LGWRのOS プロセスIDは585220and is blocked by=> Oracle session identified by:{instance: 1 (b203.b203)os id: 5852process id: 11, oracle@l64rw3.domain (LGWR)session id: 11session serial #: 1}which is waiting for log file parallel write with wait info:{(略)HANG ANALYZEからの抜粋
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedOSの視点から 問題プロセスに着目して ps コマンドの実行結果 /proc疑似ファイルシステム /proc/<pid>/status /proc/<pid>/stack など syslog21
  • Copyright (C) 2013 CO-Sol Inc. All Rights ReservedLGWRプロセスの動作状況を調査22[oracle@l64rw3 ~]$ pid=5852[oracle@l64rw3 ~]$ ps auxwww |grep $pid |grep -v greporacle 5852 0.2 0.7 1808136 14880 ? Ds 21:51 0:00 ora_lgwr_b203[oracle@l64rw3 ~]$ cat /proc/$pid/statusName: oracleState: D (disk sleep)Tgid: 5852Pid: 5852PPid: 1(略)[oracle@l64rw3 ~]$ cat /proc/$pid/stack[<ffffffff81119d0d>] sync_page+0x3d/0x50[<ffffffff81119ca7>] __lock_page+0x67/0x70[<ffffffff8111ad50>] find_lock_page+0x50/0x80[<ffffffff8111adcd>] grab_cache_page_write_begin+0x4d/0xe0[<ffffffffa0384277>] nfs_write_begin+0x77/0x220 [nfs][<ffffffff8111a673>] generic_file_buffered_write+0x123/0x2e0[<ffffffff8111c0e0>] __generic_file_aio_write+0x260/0x490[<ffffffff8111c398>] generic_file_aio_write+0x88/0x100[<ffffffffa0384f9e>] nfs_file_write+0xde/0x1f0 [nfs][<ffffffff81180c9a>] do_sync_write+0xfa/0x140[<ffffffff81180f98>] vfs_write+0xb8/0x1a0[<ffffffff81181952>] sys_pwrite64+0x82/0xa0[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b[<ffffffffffffffff>] 0xffffffffffffffffD=Interrutible Sleep割り込み不可状態一般にI/O中であることを示すpwrite()システムコール実行中であることがわかる
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reservedkhungtaskdのsyslog出力23May 27 21:57:33 l64rw3 kernel: INFO: task oracle:5852 blocked for more than 120 seconds.May 27 21:57:33 l64rw3 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables thismessage.May 27 21:57:33 l64rw3 kernel: oracle D 0000000000000000 0 5852 1 0x00000084May 27 21:57:33 l64rw3 kernel: ffff88000e6319c8 0000000000000082 ffff880037f09588 ffff880002216768May 27 21:57:33 l64rw3 kernel: ffff88000e631948 ffffffff810572f0 ffff880037f09578 ffff88003533a040May 27 21:57:33 l64rw3 kernel: ffff88003533a5f8 ffff88000e631fd8 000000000000fb88 ffff88003533a5f8May 27 21:57:33 l64rw3 kernel: Call Trace:May 27 21:57:33 l64rw3 kernel: [<ffffffff810572f0>] ? __dequeue_entity+0x30/0x50May 27 21:57:33 l64rw3 kernel: [<ffffffff810a1aa9>] ? ktime_get_ts+0xa9/0xe0May 27 21:57:33 l64rw3 kernel: [<ffffffff81119cd0>] ? sync_page+0x0/0x50May 27 21:57:33 l64rw3 kernel: [<ffffffff8150de73>] io_schedule+0x73/0xc0May 27 21:57:33 l64rw3 kernel: [<ffffffff81119d0d>] sync_page+0x3d/0x50May 27 21:57:33 l64rw3 kernel: [<ffffffff8150e6da>] __wait_on_bit_lock+0x5a/0xc0May 27 21:57:33 l64rw3 kernel: [<ffffffff81119ca7>] __lock_page+0x67/0x70May 27 21:57:33 l64rw3 kernel: [<ffffffff81096cc0>] ? wake_bit_function+0x0/0x50May 27 21:57:33 l64rw3 kernel: [<ffffffff8111ad50>] find_lock_page+0x50/0x80May 27 21:57:33 l64rw3 kernel: [<ffffffff8111adcd>] grab_cache_page_write_begin+0x4d/0xe0May 27 21:57:33 l64rw3 kernel: [<ffffffffa0384277>] nfs_write_begin+0x77/0x220 [nfs]May 27 21:57:33 l64rw3 kernel: [<ffffffff8111a673>] generic_file_buffered_write+0x123/0x2e0May 27 21:57:33 l64rw3 kernel: [<ffffffff8111c5c5>] ? mempool_free+0x95/0xa0May 27 21:57:33 l64rw3 kernel: [<ffffffff8111c0e0>] __generic_file_aio_write+0x260/0x490May 27 21:57:33 l64rw3 kernel: [<ffffffffa00ac2c1>] ? ext4_sync_file+0x191/0x260 [ext4]May 27 21:57:33 l64rw3 kernel: [<ffffffff811b1a47>] ? vfs_fsync_range+0xb7/0xe0May 27 21:57:33 l64rw3 kernel: [<ffffffff8111c398>] generic_file_aio_write+0x88/0x100May 27 21:57:33 l64rw3 kernel: [<ffffffffa00abbf0>] ? ext4_file_open+0x0/0x130 [ext4]May 27 21:57:33 l64rw3 kernel: [<ffffffffa0384f9e>] nfs_file_write+0xde/0x1f0 [nfs]May 27 21:57:33 l64rw3 kernel: [<ffffffff81180c9a>] do_sync_write+0xfa/0x140May 27 21:57:33 l64rw3 kernel: [<ffffffff81096c80>] ? autoremove_wake_function+0x0/0x40May 27 21:57:33 l64rw3 kernel: [<ffffffff8121baf6>] ? security_file_permission+0x16/0x20May 27 21:57:33 l64rw3 kernel: [<ffffffff81180f98>] vfs_write+0xb8/0x1a0May 27 21:57:33 l64rw3 kernel: [<ffffffff81181952>] sys_pwrite64+0x82/0xa0May 27 21:57:33 l64rw3 kernel: [<ffffffff8100b072>] system_call_fastpath+0x16/0x1bカーネルスタックNFSファイルに対するwrite中である可能性が高い
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reserved考察 ハング事象の原因 PID=5852 ログライター(LGWR) のI/Oがハングしていた可能性が高い カーネル空間のコールスタックより、NFS経由のI/Oアクセスに問題がありそう ログライターのハングにより更新系の処理が軒並み停止した 参照系の処理についてもラッチ待機で停止した ハング事象解消に関する推測 I/Oのハングが解消するとともに、そのほかの処理も正常に処理されるようになったのでは24
  • Copyright (C) 2013 CO-Sol Inc. All Rights Reservedまとめに代えて Oracleには優れた診断機能があるため、セッション相互の待機関係や時系列などの観点からの調査が可能です 一方で、OracleはOS上で動作するアプリケーションにすぎないため、OSやハードウェア、ネットワークが正常に機能していない場合は、影響を受ける可能性があります。このため、OSの観点からの診断情報取得と調査が必要な場合があります 診断情報には現象発生時点に取得しないと意味がないものがあります。取得すべき診断情報はKROWN:66559にまとめられているため、ハング発生時はこの手順に従い速やかに情報を収集するようにしてください 必要に応じて、テクニカルサポートの支援を依頼してください25