動的テーブルの既知の制限¶
このトピックでは、次の動的テーブル機能の制限について説明します。
一般的な制限¶
動的テーブルの使用には、次の一般的な制限が適用されます。
1つのアカウントは最大4000個の動的テーブルを保持できます。
動的テーブルの定義:
100個を超えるテーブルをクエリすることはできません。
100個を超える動的テーブルをクエリすることはできません。
動的テーブルからデータを切り捨てることはできません。
仮の動的テーブルは作成できません。
動的テーブルを使用して 共有データをインジェストする 場合、クエリは共有動的テーブルまたは上流の動的テーブルを参照する共有セキュアビューから選択できません。
動的テーブルのリフレッシュが所有者ロールとして動作するため、動的テーブルではセカンダリロールを使用できません。詳細については、 施行モデル: プライマリロールおよびセカンダリロール をご参照ください。
ソーステーブルの DATA_RETENTION_TIME_IN_DAYS オブジェクトパラメータをゼロに設定することはできません。
動的テーブルの定義では、動的 SQL （例えば、セッション変数や匿名ブロックの未束縛変数）を使用することはできません。
動的テーブル定義では、ユーザー定義テーブル関数（UDTF）から読み込む SELECT ブロックは、明示的に列を指定する必要があり、
*を使用することはできません。動的テーブルは、入力テーブルの MAX_DATA_EXTENSION_TIME_IN_DAYS 期間内にリフレッシュされないと、古くなる可能性があります。いったん古くなった動的テーブルは、リフレッシュのたびに再作成しなければなりません。
動的テーブルは現在、 ACCESS_HISTORY ビュー のトラッキングをサポートしていません。つまり、動的テーブルに対して実行されたクエリや操作は、監査や監視の目的でSnowflakeの ACCESS_HISTORY にキャプチャされません。
サポートされているデータ型¶
動的テーブルは、すべての Snowflake SQL データ型 をインクリメンタルリフレッシュとフルリフレッシュの両方でサポートしていますが、次を例外とします:
構造化データ型。
地理空間データ型（フルリフレッシュのみ）。
クエリコンストラクトの制限¶
現在、動的テーブルのクエリでは以下のコンストラクトはサポートされていません。クエリでこれらを指定すると、エラーが発生します。
外部関数。
CURRENT_USER に依存する関数。動的テーブルのリフレッシュは、特別な SYSTEM ユーザーの所有者ロールとして機能します。
ディレクトリテーブル、外部テーブル、ストリーム、マテリアライズドビューを含むソース。
動的テーブルやその他のサポートされていないオブジェクトのビュー。
SQL で記述されたユーザー定義テーブル関数（UDTF）。
サブクエリ（例えば、 SELECT ステートメント）を含む、 SQL で記述されたユーザー定義関数（UDF）。
SAMPLE / TABLESAMPLE 構成は、動的テーブルの増分リフレッシュやフルリフレッシュではサポートされていません。
機能間の相互作用のサポート¶
次の機能間の相互作用はサポートされていません。
Query Acceleration Service（QAS）を使用して、動的テーブルのリフレッシュを実行する。
共有テーブルのデータベースロールによるマスキングポリシー。
機能間の相互作用には、次の制限が適用されます。
動的テーブルとベーステーブルが異なるフェールオーバーグループにあると、複製に失敗します。
増分リフレッシュのサポート¶
このセクションでは、 動的テーブル増分リフレッシュ で現在サポートされていない式、句、関数について説明します。クエリでこれらを使用すると、自動リフレッシュプロセスでフルリフレッシュが使用され、より多くのクレジットが消費される可能性があります。 増分リフレッシュまたはフルリフレッシュのいずれが使用されているかの判断 をご参照ください。
増分リフレッシュでは非決定性関数はサポートされていませんが、 フルリフレッシュでは一部の非決定性関数はサポートされています。
動的テーブルを作成する 場合、リフレッシュモードのデフォルト値は AUTO で、動的テーブルのインクリメンタルリフレッシュを選択します。CREATEDYNAMICTABLEステートメントが増分リフレッシュに対応していない場合、フルリフレッシュが自動的にリフレッシュモードとして選択されます。
ユースケースに最も適したリフレッシュモードを決定するために、リフレッシュモードと自動推奨を試してみてください。Snowflakeのリリース間で一貫した動作を維持するには、すべての動的テーブルで明示的にリフレッシュモードを設定する必要があります。例えば、ダイナミックテーブルをインクリメンタルにのみ更新したい場合は、作成時に明示的にリフレッシュモードを INCREMENTAL に設定する必要があります。詳細については、 すべての実稼働動的テーブルのリフレッシュモードを設定します。 をご参照ください。
動的テーブルのリフレッシュモードを確認するには、 動的テーブルリフレッシュモードを表示する をご参照ください。
サポートされていないコンストラクト、演算子、関数¶
動的テーブルは現在、一部の構成、演算子、関数の増分リフレッシュをサポートしていません。クエリで次のように指定すると、動的テーブルはフルリフレッシュによって更新されます。
-
UNION、 MINUS、 EXCEPT、 INTERSECT。
UNION [ ALL ] の次の使用状況:
テーブルの UNION ALL とそれ自身、またはそれ自身のクローン。
GROUP BY または DISTINCT と別の GROUP BY または DISTINCT の間の UNION ALL。
すべての サブクエリ演算子。
次の 外部結合 （左、右、またはフル）パターン:
両側が同じテーブルである外部結合。
両側が GROUP BY 句を持つサブクエリである外部結合。
等値でない述語を使用した外部結合。
ウィンドウ関数 の次の使い方:
同じ動的テーブル定義内に複数のウィンドウ関数があり、PARTITIONBY句が同一でないか、別々のクエリブロックに記述されている場合。
ウィンドウ関数 PERCENT_RANK 、 DENSE_RANK 、 RANK をスライディングウィンドウフレームで使用する。
非決定性関数なので ANY_VALUE を使用する。
ユーザー定義関数 （UDF）の次の使用状況：
UDFs と UDTFs がPython、Java、Scala、Javascriptで書かれ、 VOLATILE パラメーターを指定します。
サブクエリを含む SQL UDFs。
LATERAL を FLATTEN() と併用する場合を除く LATERAL 結合。
横方向のフラット化結合からフラット化 SEQ 列を選択することはできません。詳細については、 増分リフレッシュでサポートされるクエリ をご参照ください。
増分リフレッシュの追加制限¶
マスキングポリシーおよび行アクセスポリシー¶
動的テーブルのマスキングや行アクセスポリシーは、リフレッシュモードには影響しません。ただし、ソーステーブルに適用されたポリシーがリフレッシュモードに影響する場合があります:
ソーステーブルのポリシーが CURRENT_ROLE 関数を使用している場合、増分リフレッシュがサポートされます。
ソーステーブルのポリシーが他の関数、 INFORMATION_SCHEMA ビュー、またはテーブルへのクエリ（例えば、 マッピングテーブルルックアップ）を使用している場合、インクリメンタルリフレッシュはサポートされません。
複製¶
増分リフレッシュで 複製された動的テーブルは、フェールオーバー後に再初期化してから増分リフレッシュを再開します。
詳細については、 複製と動的テーブル をご参照ください。
クローニング¶
クローンされた増分動的テーブル は、作成後の最初のリフレッシュ時に再初期化が必要になることがあります。
動的テーブルが、ベーステーブルが削除された別の動的テーブルからクローンされた場合、クローンは中断され、再開やリフレッシュはできません。