【Oracle Database】パフォーマンスダウンに備えて取得する「4つ」の重要情報:データベースサポート最前線の現場から(9)(2/3 ページ)
データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle Databaseのパフォーマンスダウンに備える「定常的に取得しておくべき4つの情報」を紹介します。
具体的には、以下の4つの情報を普段から取得しておくことで、サーバ再起動後であってもトラブル原因の特定に至る確率を上げられます。
- サーバリソース監視
- AWR/STATSPACK
- V$SESSION/V$PROCESS
- 統計情報の履歴
サーバリソース監視
Oracle Databaseも、OS上で動くアプリケーションの1つです。パフォーマンスダウンの原因がサーバリソースの競合にあるケースは少なくありません。そのために、サーバリソースの監視が必要となります。例えば、パフォーマンスダウンが発生した時間帯にシステムのバックアップやウイルス検知の別のプロセスが動いており、サーバの負荷を上げていた(=データベースは被害者だった)ことが原因だった、などです。
Linux系OSであれば、以下のコマンドを定期的に実行し、それぞれログにリダイレクトするようにします。この際、必ず時間もセットで取得します。「vmstat」のようなサーバ全体の情報だけではなく、OS上の各プロセスがCPUやメモリなどをどの程度使用しているのかを「ps」「top」でも確認できるようにするのがポイントです。
# date;vmstat # date;ps -elf # top
これらの情報は取得間隔が短いほど問題が発生した時間に近い情報を確認できることから、可能ならば1分以内の間隔で取得しておきたい情報です。取得による負荷はほぼないはずですが、psコマンドの出力量はシステム環境に依存します。いきなり定期取得を開始するのではなく、まずはコマンドを実行してから、負荷と出力量を考慮した上で許容可能な取得間隔と保持期間を検討するようにしてください。
なおオラクルからも、定期的な情報収集と管理を自動化できる「OSWatcher Black Box(OSWbb)」というツールが提供されています。vmstat、ps、topなどの複数の負荷情報をデフォルトで30秒間隔で取得し、2日分保持してくれますので、こちらを活用するのもよいでしょう。
AWR/STATSPACK
データベースレベルでのパフォーマンスダウンが発生した際には、発生前と比較して「ブロック読み込み量」「トランザクション数」「メモリの使用状況や待機イベントの傾向」などに差異がないかを確認します。
Enterprise Edition+Diagnostics Packのライセンスを所持しているのであれば、「AWR(Automatic Workload Repository)」を使用すると簡単です。AWRスナップショットの保持期間は「DBA_HIST_WR_CONTROL.RETENTION列」にて確認できます。ただし、Oracle Database 12cにおけるAWRスナップショットのデフォルト保持期間は「8日間」なので注意してください。サポートセンターに問い合わせをいただいた時には情報がなかったこともよくあります。定期的にレポート出力しておくなどの対応を併せて検討してください。
一方、Enterprise Edition+Diagnostics Packのライセンスのない環境では、「STATSPACK」を使用して確認します。STATSPACKはスナップショットのレベルごとに取得できる情報が異なります。デフォルトは「Level 5」ですが、これを「Level 6」で取得することにより、STATSPACKスナップショットに含まれたSQLの実行計画までを確認できるようになります。ここまで取得しておくと、特定のSQLのパフォーマンスダウンが発生した場合など、当時の実行計画を確認したいケースで重宝するので、取得負荷が許容範囲ならば、Level 6での定期取得を推奨しています。ただし、最大レベルの「Level 10」ではシステムへの負荷が非常に高くなるので、通常の運用で取得することはありません。
なお、STATSPACKスナップショットは自動でローテートされません。定期的にメンテナンスを行わないと格納領域が肥大化したり、データファイルの拡張エラーが発生したりするので注意してください。例えば、STATSPACKのインストール時に専用の表領域を作成、指定し、定期的なレポート出力と削除を行うフローを設けるようにするとよいでしょう。
V$SESSION/V$PROCESS
サーバリソース監視によってデータベースのプロセスが負荷を上げている状況を確認できた場合、そのプロセスがどのセッションにひも付き、何をしているのかを確認する「動的パフォーマンスビューの情報」を確認します。具体的には、「V$SESSION/V$PROCESS」の結果を定期的にログへリダイレクトすることで、パフォーマンスダウンの原因となっているセッション(プロセス)や実行しているSQLの情報、接続元のクライアントなどを確認できます。
前述したSTATSPACKをLEVEL 6で取得し、スナップショット内に確認したいSQLが含まれているならば、「V$SESSION.SQL_HASH_VALUE」から、そのセッションが実行していたSQLの実行統計や実行計画を確認できます。これを確認できれば、調査の確度が飛躍的に上がります。
取得方法は以下の通りです。
SELECT ''||TO_CHAR (SYSDATE ,'YY/MM/DD HH24:MI:SS')||','||SADDR||','||SID||'…<略>…,'||ECID||'' FROM V$SESSION ORDER BY SID; --出力例 15/12/03 21:22:11,000007FF115E14D8,1…<略>…, 15/12/03 21:22:11,000007FF115DE668,2…<略>…, 15/12/03 21:22:11,000007FF115DB7F8,3…<略>…, 15/12/03 21:22:11,000007FF115D8988,4…<略>…,
V$SESSION/V$PROCESSの情報はサーバで取得したリソース情報と突き合わせて確認をするので、上記のコマンド例のように、日付の情報を含めつつ、取得の間隔をサーバのリソース監視情報と同じか、それよりも短い間隔で取得するようにします。
また、カンマ区切りで出力させることで、Microsoft Excel上でグルーピングしたり、「SQL*Loader」などを使用したデータベースへのロードしたりすることが容易になります。なお、データベースにロードできれば、使い慣れたSQL(WHERE句)で条件を絞った確認ができます。
関連記事
- 「新機能」「廃止機能」「サポート状況」から見たユーザーにとってのOracle Database 12c
Oracle Database導入を実施ならびに支援するサービスプロバイダという筆者の立場から、ユーザーにとっての新バージョンの意義を考えながら、新機能や廃止された機能などを紹介します。 - オラクルが確約した「クラウド6箇条」と「Database 12c R2」の気になるトコロ
米オラクルのラリー・エリソンCTOが、同社の年次イベントで今後のクラウド事業の行方を確約する「Oracle Cloud、6つの設計目標」を掲げました。同時に発表された基幹製品「Oracle Database 12c」の次期バージョンのポイントと共に、そこにどんな狙いがあるかを振り返ります。 - オラクルのエリソン会長、「Oracle Database」最新版や多数のクラウドイノベーションを発表
米オラクルのラリー・エリソン氏は「Oracle OpenWorld 2016」の開幕基調講演を行い、同社のクラウドコンピューティングプラットフォーム全般にわたる多くのイノベーションを披露した。 - 【Oracle Database】忘れていませんか? 「アラートログ調査」に必要な、たった3つのキホン
データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は基本編として「アラートログの調査で押さえるべき3つのポイント」を解説します。【Oracle Database 12c対応版】 - Oracle運用の基本「ログ」を理解しよう
本連載では、Oracle Database運用の鍵となるトラブル対処法について紹介していきます。第1回、第2回では情報収集の要となるログについて見ていきます。ログの出力情報は10gと11gとでは大きく異なる点がありますので、それぞれについても確認しておきましょう。 - カーソル・エラーとオブジェクトの問題切り分け
Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。(編集局) - IF文のネスト地獄から抜け出せるMERGE文
Copyright © ITmedia, Inc. All Rights Reserved.