ステートメントの実行トレース

ステートメントを実行すると、その実行のトレースを要求できます。また、クエリを実行する前に実行プランを取得することもできます。実行しないと判明しないパラメーター (実行時間など) を除けば、どちらの場合も表示される情報は同じです。

実行プランはツリー形式の図として表示され、各ノードは以下のエレメントのいずれかを表します。

  • ツリーのルートである「実行ノード」。クエリに関する情報が表示されます。

  • ステートメントの実行中に発生する中間ビュー

  • ソースからのデータの取得

これらのノードの主な属性は以下のとおりです。

  • Type: ノードがビューである場合は、ビューのタイプ (基本ビュー、和結合、結合、選択、投影など) を表します。ノードがデータソースへのアクセス (ラッパー) である場合は、ソースのタイプ (JDBC、ODBC、Web サービスなど) を表します。

    トレースで主要なノードは「実行」ノード (トレース最上位のノード) であり、その属性はクエリ全体の状態を表します。

  • Execution time: ノードとそのサブノードの実行に要した時間 (ミリ秒)。「実行」ノードの場合はクエリの実行時間です。

  • Start time: Virtual DataPort サーバーによってノードの実行が開始された日時。「実行」ノードの場合は、Virtual DataPort サーバーでクエリを受け取った日時です。

  • End time: Virtual DataPort サーバーによってノードとそのサブノードの実行が完了した日時。「実行」ノードの場合は、Virtual DataPort サーバーでクエリの実行を完了した日時です。

  • Response time: 処理する最初の行をノードで受け取った日時。「実行」ノードの場合は、クエリ結果の最初の行を Virtual DataPort サーバーで取得した日時です。

    どの行もノードで処理されなかった場合、この属性の値は unknown です。

  • Effective time: ノードの実行に要した時間。実行ツリーにある他のノードの作業完了を待機していた時間は算入されません。

  • Data serialization time (「実行プラン」ノードでのみ表示): クライアントアプリケーションに送信するバイトストリームにクエリ結果を変換するために Virtual DataPort サーバーで要した時間。

  • Number of rows: ノードから返された行の数。「実行」ノードの場合はクエリから返された行の数です。

  • State: ノードが正常に実行されたかどうか、またはノードの実行またはそのいずれかのサブノードの実行でエラーが発生したかどうかを示します。

    この属性のすべての値については、付録「 実行トレース情報 」の表「 クエリの実行トレースのノードの「State」属性の値 」を参照してください。

  • Completed: [yes] の場合、ノードの実行が正常に完了しています。[no] の場合、ノードの実行またはそのいずれかのサブノードの実行でエラーが発生しています。

  • Waiting time for execution (「実行」ノードのみ): Virtual DataPort サーバーによってクエリの実行が始まるまで、クエリがそのキューで待機していた時間 (ミリ秒)。

    同時リクエスト数がその制限値に達していると、クエリはそのキューに保持されます。この制限値は、[Administration] メニュー > [Server configuration] の [Concurrent requests] タブで構成します。この制限値の詳細については「 同時リクエスト数の制限 」を参照してください。

    [Execution time] の値には、[Waiting time for execution] の値も算入されます。

  • Static optimization (「実行」ノードのみ): 自動簡素化に関するパラメーター。「 クエリの自動簡素化 」を参照してください。

    • Optimization time: 実行エンジンによるクエリプランの分析に要した時間。

    • 分析後にクエリプランが簡素化された場合、[Static optimized] は [yes] です。

  • Cost optimization (「実行」ノードのみ): コストベースの最適化に関するパラメーター。この最適化については「 コストベースの最適化 」を参照してください。実行エンジンでコストオプティマイザーを使用して実行プランが選択される場合、トレースにも、その判断に関する以下の情報が保持されます。

    • Estimated number of rows, row size in bytes and data volume: クエリを実行せずに実行プランが取得された場合に表示されます。このノードから返される行数としてオプティマイザーで予測された値を示します。結合ノードの場合、その右側分岐での結合方針がハッシュまたはマージであると想定されます。

    • Indexes: 基盤となるデータソースでデータを取得するために使用されるとして、オプティマイザーで予測されるインデックス。

    • Total, Left Branch and Right Branch cost (結合ノードでのみ表示): 結合操作の合計コストおよびその分岐でのコスト。

  • Advanced parameters: 各ノードタイプの詳細を示します。その例を以下に示します。

    • 「ルート」ノードの場合、データソースに対して実行されたクエリおよびそのソースに接続するための URI。

    • Swapping and number of swapped rows: クエリのノードごとに、そのノードの実行中にデータがディスクにスワップされたかどうか、スワップされた場合はディスクにスワップされた行数を示します。

    • No delegation cause: クエリがソースデータベースに委任されなかった理由を示します。

      同一の JDBC または ODBC のデータソースから作成した複数のビューをクエリで使用している場合、Virtual DataPort では、クエリ全体をそのソースデータベースに委任しようとします。これにより、クエリを 1 つ実行するだけですべての結果を取得できます。クエリのプロセス全体をソースデータベースに委任できない場合は、委任できないビューの横に image0 アイコンが表示され、委任できない理由が [No delegation cause] パラメーターに示されます。たとえば、ソースデータベースでサポートされていない関数をクエリで使用していると、取得した結果を Virtual DataPort で後処理する必要があります。

      [No delegation cause] のメッセージは、委任されるようにビューを書き換えるうえで役に立ちます。

クエリ実行ツリーの各ノードには、最も関連性が深いパラメーターが表示されます。パラメーターを右クリックして [Copy] をクリックすることで、その値をコピーできます。[Copy trace to clipboard] (image1) をクリックすると、トレース全体をコピーできます。

実行トレースとその図を保存するには [Save] (image2) をクリックします。


以下のクエリの実行トレースを、 の図に示します。

SELECT *
FROM internet_inc
WHERE summary REGEXP_LIKE '.*(Incident)|(Error).*'

データベースで REGEXP_LIKE 演算子がサポートされていない場合、そのデータベースにはクエリを委任できず、選択ノードには image0 アイコンが表示されます。このアイコンは、指定した選択条件が Virtual DataPort で実行されることを意味しています。

実行トレースの主な用途はデバッグです。クエリの実行でエラーが発生した場合、その発生元ノードが赤色で表示されます。このノードをクリックすると、エラーの詳細を表示できます。クエリの実行トレースに表示されるアイコンと色の意味については、付録「 実行トレース情報 」を参照してください。

クエリの自動簡素化 (「 クエリの自動簡素化 」を参照) が有効な場合、クエリの実行対象のビューで定義されている階層と実行トレースが一致しないことがあります。

internet_inc view execution trace

internet_inc ビューの実行トレース

以下 の図は、Web サービスデータソースにアクセスできない場合の incidents_sales 結合ビューの実行トレースを示しています。

Join view execution trace with errors

エラーが発生している結合ビューの実行トレース

クエリの実行トレースを表示する以外に、クエリの実行前にその「クエリプラン」を確認できる方法があります。これにより、Virtual DataPort サーバーによってクエリがどのように実行されるかを、クエリを実行せずに知ることができます。この機能は、Virtual DataPort サーバーによって各結合操作 (マージ、ハッシュ、ネストなど) で使用される方法や、クエリがどのようにデータベースに委任されるかなどを確認できるので、複雑な階層を持つビューを扱う場合にきわめて効果的です。

これを表示するには、[Execute view] ダイアログで [Query Plan] をクリックします。クエリプランを計算するプロセスは、実際にクエリを実行する場合にきわめてよく似ていて、相違点は実際のデータソースにはアクセスしないことだけです。たとえば、ネスト結合の右側分岐の実行をシミュレーションするには、結合条件の右辺の属性値を Virtual DataPort サーバーで生成する必要があります。それらの値は必須であり、実行時には結合の左辺から取得した値が使用されるからです。ただし、クエリプランを取得する場合は実際の値が存在しないので、以下の表に示す値が使用されます。

クエリプランを生成するために使用される値

データ型

クエリプランを生成するために使用される値

boolean

false

date

現在日時

decimal

0.0

double

0.0

float

0.0

int

0

long

0

text

'' (empty string)

xml

'' (empty string)

array

{ } 空の配列

register

すべて NULL に設定されたエレメントを持つレジスター

クエリの実行トレースの保存

クエリの実行トレースが保存されるように、Virtual DataPort のロギングエンジンを構成できます。管理ツールからではなく外部アプリケーションから実行したクエリをトラブルシューティングする際に、この保存機能が便利です。実行トレースの保存先として、Trace Viewer から開くことができるファイルまたはプレーンテキストファイルを選択できます。

この機能を有効にするには、以下のコマンドを実行します。

SET 'com.denodo.vdb.interpreter.execution.saveTrace' = '<save trace configuration>';
パラメーター <save trace configuration> に指定できる値

パラメーターの意味

ALL_LOG

すべてのクエリのトレースをプレーンテキストで保存します。

ALL_FILE

すべてのクエリのトレースを、Trace Viewer で開くことができるファイルに保存します。

ALL_FULL

すべてのクエリのトレースをプレーンテキストで保存するほか、Trace Viewer で開くことができるファイルにも保存します。

ERROR_LOG

失敗したクエリのトレースのみをプレーンテキストで保存します。

ERROR_FILE

失敗したクエリのトレースのみを、Trace Viewer で開くことができるファイルに保存します。

ERROR_FULL

失敗したクエリのトレースのみをプレーンテキストで保存するほか、Trace Viewer で開くことができるファイルにも保存します。

DISABLED

この機能を無効にします (デフォルト値)。

注釈

失敗したクエリだけではなく、すべてのクエリの実行トレースを保存する場合は、必要なディスク容量を考慮してください。簡単なクエリ 1 回の実行トレースであっても、プレーンテキストで保存すると約 4 KB のディスク容量が消費されます。

プレーンテキストでの実行トレースの保存

実行トレースをプレーンテキストで保存する場合 (ALL_LOGALL_FULLERROR_LOG 、または ERROR_FULL のいずれかのオプションを使用した場合)、すべてのトレースは同じファイルに保存されます。トレースの保存先ファイルとして以下のファイルを指定できます。

  1. vdp.log ファイル (<DENODO_HOME>/conf/vdp/): このオプションは、簡単なテストの場合に適しています。セットアップが容易なうえ、有効にするために Virtual DataPort の再起動を必要としないからです。ただし、実行トレースが毎回保存されるようにする場合は、オプション b) が推奨されます。オプション a) では、実行トレースが Virtual DataPort のエラーメッセージと混在するので、今後の問題の検出が困難になるからです。

    このオプションを有効にするには、(SET 'com.denodo.vdb.interpreter.execution.saveTrace'... コマンドのほかに) 以下のコマンドも実行します。

    CALL LOGCONTROLLER('com.denodo.vdp.traces', 'DEBUG');
    

    Virtual DataPort を再起動した場合は、上記のコマンドを再度実行する必要があります。そうしないと、実行トレースが保存されません。

  2. vdp.log とは別のファイルへの保存 (推奨されるオプション): そのためには、 <DENODO_HOME>/conf/vdp/log4j2.xml を以下に示す構成に変更します。

    以下に示すテキスト RollingFileLogger をそれぞれ AppendersLoggers の中に追加する必要があります。ファイルは以下のようになります。

    <Appenders>
    
    [...]
    
        <RollingFile name="TRACESOUT" fileName="../logs/vdp/vdp-traces${env:vdp.instance.log}.log" filePattern="../logs/vdp/trace/vdp-traces${env:vdp.instance.log}.log.%i">
            <Policies>
                <SizeBasedTriggeringPolicy size="10 MB" />
            </Policies>
            <DefaultRolloverStrategy max="7" />
            <PatternLayout pattern="%-4r [%t] %d{yyyy-MM-dd'T'HH:mm:ss.SSS} %x -\t%m  %n" />
        </RollingFile>
    
    [...]
    
    </Appenders>
    
    <Loggers>
    
    [...]
    
        <Logger name="com.denodo.vdp.traces" level="debug" additivity="false">
            <AppenderRef ref="TRACESOUT" />
        </Logger>
    
    [...]
    
    </Loggers>
    

    このファイルを保存し、変更内容を適用するために Virtual DataPort を再起動します。

    この構成の意味を以下に示します。

    • 実行トレースは <DENODO_HOME>/logs/vdp/trace/vdp-traces.log ファイルに保存されます。必要に応じて、このパスを変更できます。

    • ファイルのサイズが 10 MB に到達すると、ファイルの名前が vdp-traces.log.1 に変更され、新しいファイル vdp-traces.log が作成されます。生成されたファイルの数が 7 つになるまで、このプロセスが繰り返されます。それ以降は、最も古いファイルが削除されます。実行トレースによってディスクに空き容量がなくなることを防止するために、このような設定になっています。

zip ファイルへの実行トレースの保存

実行トレースをプレーンテキストで保存するのではなく、管理ツール ([Tools] メニュー) の Trace Viewer で開くことができるファイルに保存できます。これは、 ALL_FILEALL_FULLERROR_FILE 、または ERROR_FULL のいずれかのオプションを使用する場合です。Trace Viewer では、トレースをグラフィカルに表示したり、各ノードをクリックしてその実行の詳細を表示したりできます。この zip ファイルには、プレーンテキストの実行トレースも格納されます。

このモードでは、クエリごとに別々の zip ファイルにトレースが保存されます。

このオプションを選択した場合は、Virtual DataPort を再起動する必要はないので、 SET 'com.denodo.vdb.interpreter.execution.saveTrace'... コマンドのみを実行します。

デフォルトでは、これらのファイルは <DENODO_HOME>/logs/vdp/trace ディレクトリに保存されます。このディレクトリを変更するには、以下のコマンドを実行します。

SET 'com.denodo.vdb.interpreter.execution.saveTraceDir' = '<directory to store the traces>';

このディレクトリが存在しない場合、Denodo によって作成されます。変更内容を適用するために Virtual DataPort を再起動する必要はありません。