少し前に、アプリケーション開発スタッフにExplainPlanのチュートリアルを提供しました。出てきた質問の1つは、どのSQLステートメントを調整する必要があるかをどのように決定するかということでした。私はいくつかの異なるアプローチを使用し、さまざまな角度からSQLチューニングの候補を見つけています。
- データベースにヒットするSQLステートメントのコードレビューを定期的に実行します。私は自分の経験を活用して、SQLをさらに調査する必要があるかどうかを判断するために、新しいSQLステートメントまたは大幅に変更されたSQLステートメントをすばやく確認します。たとえば、テーブルのクエリがPKまたはUnique列を検索している場合、高速に実行されると確信できます。 SQLステートメントが疑わしいと思われる場合は、Explain Planを実行するか、ステートメントのタイミングを調整して、SQLステートメントが十分に実行されるようにします。
- テストデータベースシステムでのリソースの競合について、OracleのEnterpriseManagerから警告を受けました。コードレビュー中に見逃したSQLステートメントは、ここで見つかることがあります。リソース競合のアラートを受け取った場合は、ジャンプして、SQLステートメントが1つか2つ問題を引き起こしていないかどうかを確認します。これは、SQLステートメントが本番環境に移行する前にキャッチする最後のチャンスです。
- IgniteforOracleを活用しています。この製品はConfioからのものですが、Confioは現在Solarwindsの一部です。通常、ベンダーの製品をプラグインしませんが、この場合は例外とします。 Igniteで気に入っているのは、毎週月曜日にレポートをメールで送ってもらうことです。レポートには、待機時間に基づく上位N人の違反者が含まれています。このレポートを見るのに数秒かかります。レポートで大きなバーを探します。以下のスクリーンショットの例では、すぐに注意を引く青いバーを見ることができます。右側の数字はid値であり、それをクリックするとSQLテキストを取得できます。これは、調整が必要なSQLステートメントを識別するための優れた方法です。とても速くてとても簡単です。
ご覧のとおり、問題のあるSQLは、開発中、テストシステム内にあるとき、および本番環境に到達した後でも、問題のあるSQLを見つけようとしています。