Enterprise Editionじゃなくてもパフォーマンスダウンは解決可能
昨今、企業のビジネスの多くはITで支えられており、データベースの性能低下はビジネスに直接影響を与えます。例えば、ECサイトのバックエンドで稼働するデータベース性能の低下は、ユーザが操作するWeb画面の応答時間が長くなることを意味します。応答時間が2秒以上になると直帰率が上がるとも言われており、データベースのパフォーマンスダウンは売上機会の損失につながる可能性があります。
アシストのサポートセンターには「処理が遅くなってしまいセッションが滞留した」「本来数分で終わるべき処理が1時間以上かかっても終わらなかった」などのパフォーマンスダウンに関するお問い合わせをいただくことがあります。
データベースのパフォーマンスダウンは主にメモリ、CPU、I/Oなどのハードウェアのリソース競合か、ロック、ラッチなどのデータベースのリソース競合で起こります。
具体的に何が原因で処理のパフォーマンスダウンが発生してしまっているのかを確認する情報として、Oracle Databaseでは動的パフォーマンスビュー（V$ビュー）があります。
V$ビューはデータベースがオープンしている間、セッションやメモリ、ロックの獲得状況といった内部的な情報が継続的に更新される、参照専用の特別なビューです。
今まさにパフォーマンスダウンが発生中であれば、V$ビューの結果を取得し、ボトルネックの特定を行います。しかし実際のお問い合わせでは、処理が遅延し、滞留していたセッションのKILLや処理実行元のアプリケーションサーバの再起動などでリソースの解放を行い、パフォーマンスダウンが解消してから、発生原因の調査を依頼いただくケースがほとんどです。
過去のパフォーマンス情報を確認する方法としては、Automatic Workload Repository（AWR）とActive Session History（ASH）があります。これらは自動でパフォーマンス情報を取得しています。ただし、これらの情報を参照するにはEnterprise EditionとDiagnostics Packのオプションライセンスの契約が必要です。
これらの契約がない環境で過去のパフォーマンス情報を得るには、AWRに代わるSTATSPACKの導入やASHに代わるV$ビューの定期情報取得など、ユーザ側での事前準備が必要です。
パフォーマンスダウンに関するトラブルのお問い合わせのうち、ライセンスごとの解決率を示しているのが図1です。
ここで言う「解決」とは、処理遅延の原因がどこにあったのか（ロック競合、リソース不足など）の特定までを指します。その後のチューニングまでは含んでいないにもかかわらず、パフォーマンス情報の有無で解決率に2倍以上の差があります。
過去のパフォーマンス情報が取得できていない場合、遅延処理を実行していたセッションの状態などが確認できません。該当時間帯のログファイルにエラーや警告などのメッセージが出力されているようなケースを除いて、多くのケースでは推測での調査しか行えないため、解決率が低くなっています。
言い換えればAWRやASHが利用できない環境でも、STATSPACKやV$ビューの定期取得を行うことで解決率をライセンス所持環境に近いレベルまで上げることができます。そこで今回はパフォーマンスダウンのトラブルに備えたV$ビューの定期取得方法と、取得した情報を使用した調査方法をご紹介します。
