動的テーブルのリフレッシュに関する一般的な問題の診断¶

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

動的テーブルの実際の リフレッシュモード は作成時に決定され、その後は不変です。明示的に指定されない場合、リフレッシュモードのデフォルトは 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 チェックボックスをチェックして、ウェアハウスを使用してリフレッシュされたリフレッシュを表示します。

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