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

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

[大野高志，株式会社アシスト]

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

連載バックナンバー

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

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

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

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

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

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

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

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

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