データベースの [Query Details] ウィンドウの機能
データベースの [Query Details] ウィンドウでは、次のことができます。
- [Execution Plan] をクリックすると、SELECT クエリであった場合に [Queries] ウィンドウで選択したクエリの説明プランが表示されます。
- グラフをクリックすると、その特定の時点のメトリックが表示されます。
-
ページの上部にあるデータベースコレクタ名の横にある下矢印をクリックして、別のデータベースコレクタのクエリの詳細を表示できます。
-
（21.5 以降）戻る矢印（
）アイコンをクリックすると、[Database Queries] ウィンドウの一番上のクエリビューに戻ります。
[Database Query Details] ウィンドウで、次の情報を確認できます。
| プロパティ | 説明 |
|---|---|
|
Resource consumption over time |
SQL Server、Azure、Oracle、SAP HANA、および DB2 の場合、リソースを使用してデータベースでクエリにかかった時間、実行数、セッション数、消費された CPU 時間の合計を表示します。クエリ統計情報は、前述のデータベース プラットフォームでのみ使用できます。 注: SAP HANA バージョンが 2.0 SPS 05 の場合、CPU 時間の消費はグラフに表示されません。
リソース消費カードは、クエリグループにも使用できます。グループ内のすべてのクエリにクエリメトリック（経過時間と実行回数など）がある場合は、グループのメトリックの集計が表示されます。グループ内のクエリのいずれにもクエリメトリックがない場合は、待機状態のインデックスから取得された、グループ内のクエリの合計経過時間が表示されます。グループ内の一部のクエリにクエリメトリックがあり、他のクエリにはない場合は、使用可能なクエリメトリックの集計値が表示されます。 |
| Business Transactions Executing Similar Queries | （SAP HANA には適用されません）このクエリと同様のクエリを実行する Java または PHP のビジネストランザクションを表示します。 |
| Disk and buffer usage | （SAP HANA には適用されません）このデータベースコレクタのハードウェアモニタリングが有効になっている場合にデータを表示します。このグラフは、データベースバッファがどれだけ効果的に使用されているかを一目でわかるように示しています。物理ディスクの読み取りには非常に時間がかかるため、頻繁に実行される SQL はバッファに保存するのがベストです。Buffer Gets に対する物理読み取りの比率が高すぎることがわかっている場合は、バッファマネージャを最適化する必要があることがあります。 |
| Clients | 選択した SQL ステートメントを実行したマシン、経過時間、および各マシンで実行されたステートメントの実行に要した合計時間の割合を表示します。このテーブルには、アプリケーション、ノード、およびマシンのティアも示されています。 |
| Sessions | クライアントが開いたセッション ID、経過時間、およびステートメントの実行に要した合計時間の割合を表示します。 |
|
<database_type> wait states |
選択した SQL ステートメントにデータベースがサービスを提供するのにかかる時間に寄与するアクティビティ。最も時間がかかっている待機状態は、パフォーマンスのボトルネックを指している可能性があります。たとえば、db file sequential read 待機状態は、インデックス上のセグメントヘッダーの競合またはディスクの競合が原因で発生している可能性があります。SQL 待機状態と推奨アクションの説明については、データベース プラットフォームのドキュメントを参照してください。 |
| Query Active in Database/Schema | この SQL によってアクセスされたスキーマを表示します。 |
|
Query ID (Oracle) SQL Handle (SQL Server) | データベースサーバーがキャッシュのこの SQL ステートメントをより迅速に検索できるようにする一意の ID。 |
|
Query |
選択した SQL ステートメントの構文全体。クエリカードの右上隅にある鉛筆アイコンをクリックすると、クエリ名を編集して簡単に識別できるようにすることができます。 |
|
Queries in Group (only in Group Details view) | クエリグループ内の上位 100 クエリ。 |
|
Users | このクエリを実行したユーザー。 |
|
Programs/Applications | このクエリが実行されたプログラム/アプリケーション。 |
|
Procedures | モニターするクエリの手順のリスト。 |
|
Containers | クエリが実行されるコンテナ。 |
SQL がデータベース内で内部的にどのように実行されたかを確認するには、[Execution Plan] タブをクリックします。ステートメント実行プランは、データベースがステートメントを実行するために実行する一連の操作です。
Oracle Explain Plan の制限事項
Oracle の場合、Splunk AppDynamics データベースの可視性では、SELECT、UPDATE、INSERT、および DELETE ステートメントのみの実行プランが表示されます。これは、データベースの可視性は実行プランを取得するために Oracle EXPLAIN PLAN ステートメントに依存していて、Oracle EXPLAIN PLAN ステートメントでは、SELECT、UPDATE、INSERT、および DELETE ステートメントに対してのみ Oracle オプティマイザの実行プランを提供しているためです。「Oracle のユーザー権限」も参照してください。
調整しようとしている SQL の一部が適切に実行されていない場合は、実行プランの最もコストのかかるステップを確認することが明らかな出発点になります。
SQL の調整には膨大なトピックがありますが、次の点に注意します。
- インデックスまたはテーブルスキャン：より良いまたは追加のインデックスが必要であることを示している可能性があります。
- Bookmark Lookup：現在のクラスタ化インデックスの変更、Covering Index の使用、および SELECT ステートメントのカラム数の制限を検討します。
- フィルタ：WHERE 句で、Transact-SQL コードのビューを含まない、追加のインデックスが必要になる可能性があるすべての関数を削除します。
- ソート：データをソートする必要があるか。ソートを回避するためにインデックスを使用できるか。クライアントでソートをより効率的に行うことができるか。