2011/06/18

Oracle実習セミナー行ってきました(Part2)

先週(6/10)に引き続き、Oracle のパフォーマンスチューニングに関するセミナーに参加させていただきました。


前回(DB の全体的な稼働状況の確認)の続きで、「レスポンスが遅いんだけど」という問合せに対して、AWR レポートその他資料から詳細な調査を実施する手順についての演習。

  1. レスポンスが遅いときの AWR レポート
  2. 通常時の AWR レポート
  3. Active Session History(ASH) から抽出した時間ごとのアクティブセッション数のログ
  4. 待機イベント関連のビューから抽出した時間ごとのセッションウェイトのログ

  • 演習3 レスポンス遅延が発生していたと考えられる時間帯に、行ロックによって待機しているセッションの状況を確認してください
    • どのような状況ですか?
    • 現在の状況より、障害の原因としてどのようなことが考えられますか?
    • つぎに調査すべき項目は何ですか?
  • 演習4 行ロックにて待機している SQL_ID の SQL 文を特定し、処理状況を確認してください
    • どの SQL ですか?
    • 正常時と障害時で処理状況を比較し、どのような違いがありますか?
    • 比較結果より、どのようなことがかなえられますか?
  • 演習5 調査結果のまとめ

OpenOffice.org Calc にセッションウェイトのログ(CSV ファイル)を取り込んで待機セッションの状況を確認しました。障害発生時間帯の EVENT 列にはおびただしい数の「enq: TX - row lock contention」が出力されていました。それら複数のセッションでは同一 SQL_ID が見られたので、AWR レポートを確認するとそれらしき SQL 文を見つけるところまでは出来ましたが、そこで自分の調査は止まってしまいました。。。

加藤さまの調査、分析は次の通り。

  • セッションウェイトのログの状況として、
    • 多くのセッションが行ロックにて待機している。
    • 行ロックを保持しているセッション(BLOCKING_SESSION)は変化しており、各セッションの待機時間(SECONDS_IN_WAIT)も増加し続けている状況ではない。
    • 行ロックで待機しているセッションにて発行している SQL の SQL_IDは dc7xxxxxxxxxx である。
  • AWR レポートから SQL 文と処理状況の確認として、
    • SQL_ID から待機している SQL は
      SELECT ... FROM ... WHERE xxx = :1 FOR UPDATE
    • 正常時と障害時の処理状況は、
      • SQL 実行回数は、異常時の方が少ない。
      • CPU 処理時間は、ほぼ同じである。
      • 総処理時間および1実行当たりの処理時間が異なる。
      • 障害時の行ロックによる待機時間と本 SQL の総処理時間がほぼ同一である。
  • 前回からの調査で判明した状況をまとめると、
    • Oracle の CPU 使用率および処理量・負荷量は変化がない。
    • アクティブなセッションが特定の時間帯に増加している。
    • 障害時は行ロックによる待機時間が増加している。
    • SQL_ID dc7xxxxxxxxxx の SQL が行ロックにて待機している状況である。
    • 行ロックを保持しているセッションは変化しており、特定のセッションが長時間行ロックを保持している状況ではない。
    • SQL_ID dc7xxxxxxxxxx の実行回数は障害時の方が少ないかつ、総処理時間および1実行当たりの処理時間が長くなっている。
  • よって今回のレスポンス遅延は、
    • 特定時間帯に SQL_ID dc7xxxxxxxxxx の SQL 文(処理)がロックの獲得待ちにより待機していたことが原因だと考えられます。ただし、今回の調査からは根本原因の特定には至っていません。
  • この後考えられる調査
    • 実行計画がその特定時間帯にだけ変わっていないかも含めて確認する。
    • 問題のあった SQL の処理について、アプリケーション担当も含めて検討する。

今回与えられた情報だけでは根本原因は特定できませんでしたが、レスポンス遅延が発生した場合に調査すべき事項がよく分かりました。同様の事象が発生したときにはこの手順で調査しようと思います。

  1. DB の全体的な稼働傾向を確認
  2. DB における待機イベントの発生状況を確認
  3. 行ロックにより待機しているセッションの状況を確認
  4. SQL 文の特定および処理状況を確認

P.S. 前回に引き続き今回の懇親会も楽しめました。気づくと Oracle の方も何名かいらしていて驚きました。今回のセミナーは twitter 特別枠?で参加させていただきましたが、@Guutara さまをはじめ、twitter でフォローさせていただいている方々にご挨拶することができ、そのうえ調査手順まで学ばせていただいて、とても有意義な時間を過ごせました。(どっちがメインなんだかw)今回のような形式のセミナーは今後も予定されているとのことですので、自分としては開催日時は問わず、決まり調整して参加させていただきたいと思います。

@discus_hamburg さんの参観記にもあるように、今回のセミナーでは Oracle 界隈の濃〜っ方々が集まっていらしたので、そこで何か新しい動きが起きそうですのでそちらも要チェックです。

0 件のコメント:

コメントを投稿