連載
» 2017年03月03日 05時00分 UPDATE

データベースサポート最前線の現場から(9):【Oracle Database】パフォーマンスダウンに備えて取得する「4つ」の重要情報 (1/3)

データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle Databaseのパフォーマンスダウンに備える「定常的に取得しておくべき4つの情報」を紹介します。

[大野高志,株式会社アシスト]
※本連載は、アシストのデータベースサポートスペシャリストによる「Database Support Blog」より、提供社の許可の下、一部修正して転載するものです。

連載バックナンバー

 アシストのサポートセンターには「パフォーマンスダウンが発生したので原因を教えてほしい」という問い合わせがよくあります。しかし、その原因を特定をするための調査に必要な情報が不足しているケースが多く、解決が非常に難しい課題の1つです。

 調査を効果的に行うには、サーバ、データベース、プロセスそれぞれの情報を普段から取得している必要があります。今回は、データベースのパフォーマンスダウンが発生してしまった場合に、原因を特定する確率を上げ、さらに再発を防ぐために必要な「網羅的な情報取得方法」を紹介します。

パフォーマンスダウンの調査が難しい理由

 「パフォーマンスダウンが発生した」場合の対処には、まず何が、なぜ遅くなったのかを切り分けるところから始めます。大まかに分けると、以下のような状況が考えられます。

  • サーバレベルでのパフォーマンスダウン(OSコマンドの応答に時間がかかる)
  • データベースレベルでのパフォーマンスダウン(あらゆるSQLの応答に時間がかかる)
  • 特定のSQLレベルでのパフォーマンスダウン(他のSQLは問題ない)
  • 接続レベルでのパフォーマンスダウン(データベースにつなるまでに時間がかかる)

 サーバやデータベースのレベルでパフォーマンスダウンが発生していた場合には、サーバ再起動などの対処を行った(行ってしまった)後で、原因を特定するための問い合わせを頂くケースが大半を占めます。

 サポートセンターでは、発生時の状況を伺い、その上で当時の状況を確認できる情報の提供を依頼します。しかし、調査で有効となる情報がそろっていることは、実はまれです。

 実際のサポートの現場での例として、「データベースで全体的にパフォーマンスダウンが発生した。当方はvmstatを定期的に取得している。それによると、該当時間帯ではCPU使用率が高かったようだ」と状況報告を頂くケースがあります。確かにvmstatから、パフォーマンスダウンが発生していた時間帯でCPU使用率が高かった事実は確認できます。しかし、どのプロセス/処理がCPU負荷を上げていたのかまでは分かりません。

 このケースでは、「プロセス単位の情報や該当時間帯のデータベースの稼働状況が分かる情報」も取得しておかなければなりません。それがなければ、該当時間帯に動作しているジョブや、過去の対応などからの推測をお伝えするにとどまり、解決のためには「再現時に備えた情報取得」を依頼することになります。この「再現時に備えた情報取得」とは、「もう1度その問題を発生をさせてください」と“その環境に不利益が発生することを承知の上”でお願いすることになります。個人的に、サポートをしていく上で最も避けたい回答の1つです。

       1|2|3 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。