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

　具体的には、以下の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句）で条件を絞った確認ができます。