動的テーブルの手動更新

動的テーブルを手動でリフレッシュすると、次の スケジュールされたリフレッシュ を待たずに、最新のデータを含めることができます。これは、1回限りの更新や、テーブルのターゲットラグが大きく、次のリフレッシュがかなり後になる場合に便利です。

Tip

ターゲットラグに従ってリフレッシュすることが期待される下流の動的テーブルでは、動的テーブルの頻繁な手動リフレッシュは避けてください。このような手動リフレッシュは、スケジュールされたリフレッシュをスキップさせ、下流のテーブルの更新を妨げる可能性があります。

手動でリフレッシュするには、次の手順に示すように ALTER DYNAMIC TABLE ... REFRESH コマンドまたは Snowsight を使用します。

ALTER DYNAMIC TABLE my_dynamic_table REFRESH
Copy

外部システムのスケジュールやバッチ処理ウィンドウに合わせてリフレッシュするなど、正確なリフレッシュタイミングが必要な状況では、 CRON 式を持つタスクを使用してリフレッシュをトリガーすることができます。

例:

-- Create the task
CREATE TASK my_dt_refresh_task
  WAREHOUSE = my_wh
  SCHEDULE = 'USING CRON 0 0 * * * America/Los_Angeles' -- Example: daily at midnight PST
  COMMENT = 'Daily 5pm PT manual refresh of my_dynamic_table'
  AS
    ALTER DYNAMIC TABLE my_dynamic_table REFRESH;

-- Enable the task
ALTER TASK my_dt_refresh_task RESUME;

-- Show the task
SHOW TASKS LIKE 'my_dt_refresh_task';
Copy
+------------+-----------------+-------------------------------------+---------------+-------------+--------------+-------------------------------------------------+-----------|-------------------------------------------+------------------+---------+----------------------------------------------+-----------+-----------------------------+-------------------+-------------------------------|-------------------+-----------------+--------+---------------------+-----------------------+---------------------+-----------------+----------------------------+-----------------+
| CREATED_ON | NAME            | ID                                  | DATABASE_NAME | SCHEMA_NAME | OWNER        | COMMENT                                         | WAREHOUSE | SCHEDULE                                  | [ ] PREDECESSORS | STATE   | DEFINITION                                   | CONDITION | ALLOW_OVERLAPPING_EXECUTION | ERROR_INTEGRATION | LAST_COMMITTED_ON             | LAST_SUSPENDED_ON | OWNER_ROLE_TYPE | CONFIG | TASK_RELATIONS      | LAST_SUSPENDED_REASON | SUCCESS_INTEGRATION | SCHEDULING_MODE | TARGET_COMPLETION_INTERVAL | EXECUTE_AS_USER |
|------------+-----------------+-------------------------------------+---------------+-------------+--------------+-------------------------------------------------+-----------+-------------------------------------------+------------------+---------+----------------------------------------------+-----------+-----------------------------+-------------------+-------------------------------+-------------------+-----------------+--------+---------------------+-----------------------+---------------------+-----------------+----------------------------+-----------------|
| 2025-10-02 | DT_REFRESH_TASK | 01bf6f0d-690f-f373-0000-000000025e3d| mydb          | my_schema   | ACCOUNTADMIN | Daily 5pm PT manual refresh of my_dynamic_table | mywh      | USING CRON 0 17 * * * America/Los_Angeles | []               | Started | ALTER DYNAMIC TABLE my_dynamic_table REFRESH | null      | false                       | null              | 2025-10-02 05:08:52.897 +0000 | null              | ROLE            | null   | {"Predecessors":[]} | null                  | null                | null            | null                       | null            |
+------------+-----------------+-------------------------------------+---------------+-------------+--------------+-------------------------------------------------+-----------|-------------------------------------------+------------------+---------+----------------------------------------------+-----------+-----------------------------+-------------------+-------------------------------|-------------------+-----------------+--------+---------------------+-----------------------+---------------------+-----------------+----------------------------+-----------------+

ほとんどの場合、Snowflakeはターゲットラグの使用を推奨しています。これはリフレッシュの頻度を最適化し、不必要に実行される可能性のある固定の CRON スケジュールと比較してコストを削減できます。