外部テーブルのトラブルシューティング¶

動的テーブルは増分リフレッシュではなくフルリフレッシュを使用しています。

動的テーブルの実際の リフレッシュモード は作成時に決定され、その後は不変です。明示的に指定されない場合、リフレッシュモードのデフォルトは AUTO です。これは、クエリの複雑さ、サポートされていない構成要素、演算子、関数などの様々な要因に基づいてリフレッシュモードを選択します。

Snowflakeのリリース間で一貫した動作を維持するには、すべての動的テーブルで明示的にリフレッシュモードを設定する必要があります。たとえば、動的テーブルを増分的にのみリフレッシュさせたい場合は、作成時にリフレッシュモードを明示的に INCREMENTAL に設定する必要があります。 増分リフレッシュの使用には、制限がある かもしれないことを念頭に置いてください。詳細については、 すべての実稼働動的テーブルのリフレッシュモードを設定します。 をご参照ください。

必要な権限 を持つロールを使用して、以下のいずれかの方法でリフレッシュモードを検証できます。

• SQLの使用：SHOWDYNAMICTABLESステートメントを実行します。出力で、 text 列はユーザーが指定したリフレッシュモードを示し、 refresh_mode 列は実際のリフレッシュモードを示し、 refresh_mode_reason は実際のリフレッシュモードが選択された理由を示しています。

• Snowsight の使用：ナビゲーションメニューで、 Monitoring » Dynamic Tables を選択し、動的テーブルを選択します。動的テーブルのリフレッシュモードは、 Table Details タブに表示できます。

動的テーブルが空のリフレッシュを実行していますが、コストが表示されています。

動的テーブルが参照する上流オブジェクトの変更に関連する場合、正味の新しい行がゼロ（つまり、追加、リフレッシュ、削除された行がゼロ）のリフレッシュはウェアハウスリソースを消費します。

たとえば、関連する仮想ウェアハウスが中断され、ベースオブジェクトの変更が識別子で確認されない場合、中断された仮想ウェアハウスは再開されず、クレジットも消費されません。これは、 NO_DATA リフレッシュと呼ばれています。逆に、変更が識別された場合、更新を処理するために仮想ウェアハウスが自動的に再開され、その結果、動的テーブルに適用される行がゼロであってもウェアハウスのリソースが消費されます。

動的テーブルに変更を加えていないにもかかわらずコストが表示される場合は、ソーステーブルの変更が原因である可能性があります。 Snowsight の Refresh History タブを使用して、仮想ウェアハウスのクレジットが消費されたかどうかを確認できます。

1. Snowsight にサインインします。

2. ナビゲーションメニューで Monitoring » Dynamic Tables を選択します。

3. 動的テーブルを選択し、 Refresh History タブを開きます。

4. Warehouse used only チェックボックスをチェックして、ウェアハウスを使用してリフレッシュされたリフレッシュを表示します。

詳細については、 動的テーブルのコストを理解する をご参照ください。

動的テーブルのリフレッシュに失敗しました。

通常のSnowflakeクエリと同様に、動的テーブルのクエリ定義、入力データ（解析エラーなど）、または内部システムの問題が原因で、動的テーブルのリフレッシュに失敗することがあります。

リフレッシュに失敗した原因を特定するには、以下を実行してください：

1. Snowsight にサインインします。

2. ナビゲーションメニューで Monitoring » Dynamic Tables を選択します。

3. 動的テーブルを選択し、 Table Details タブを開きます。

4. Details の下にある Last Completed Refresh にカーソルを合わせます。リフレッシュに失敗したエラーコードとメッセージの詳細が表示されます。

upstream_failed エラーコードによってリフレッシュに失敗した場合は、上流の動的テーブルのいずれかに問題がある可能性があります。どの上流テーブルで障害が発生したかを特定するには：

1. Snowsight ナビゲーションメニューで、 Monitoring » Dynamic Tables を選択し、動的テーブルを選択します。

2. Graph ページを開き、動的テーブルのグラフ履歴を表示します。

3. グラフから、赤く表示されている上流の動的テーブルを選択し、 Refresh History を確認します。

動的テーブルの作成に時間がかかっています。

CREATE DYNAMIC TABLEステートメントを使用して動的テーブルを作成すると、初期リフレッシュははスケジュールされた時間（ON_SCHEDULE）に実行されるか、作成時（ON_CREATE）に同期的に実行されます。初期データ入力、つまり 初期化 は、この初期リフレッシュがいつ発生するかによって決まります。例えば、同期的な初期化は、参照されている上流の動的テーブルのリフレッシュをトリガーし、初期化の総所要時間に処理時間が追加される可能性があります。

スキャンされるデータの量に応じて、初期化に時間がかかる場合があります。進行状況を表示するには、以下を実行します。

1. Snowsight にサインインします。

2. ナビゲーションメニューで Monitoring » Query History を選択します。

3. Filters ドロップダウンで、 SQL Text フィルターに CREATE DYNAMIC TABLE と入力し、 Warehouse フィルターにウェアハウス名を入力します。

4. SQL text で動的テーブルを含むクエリを選択し、 Query Details と Query Profile タブを使用して進行状況を追跡します。

初期化に関する一般的な情報については、 動的テーブル初期化の理解 をご参照ください。

動的テーブルのメタデータが表示されません。

動的テーブルのメタデータとInformation Schemaを表示するには、その動的テーブルの MONITOR 権限を持つロールを使用する必要があります。詳細については、 動的テーブルのメタデータを表示する権限 をご参照ください。