動的テーブルのリフレッシュがスキップされた、または失敗した場合のトラブルシューティング¶

リフレッシュのスキップ¶

動的テーブルはスケジュールに従ってリフレッシュされます。スケジュールされたリフレッシュが開始されると、次のような状況でリフレッシュがスキップされることがあります。

• リフレッシュされる動的テーブルの上流に別の動的テーブルがあり、上流のリフレッシュが失敗したかスキップされた場合。

• 動的テーブルの以前のリフレッシュがまだ実行されている場合。

• 動的テーブルのリフレッシュに目標遅延よりも長い時間がかかることが多い場合、またはターゲットラグと実際のラグに大きな違いがある場合、Snowflakeはリフレッシュをスキップして将来のスキップ率を下げる可能性があります。

  たとえば、動的テーブルのターゲットラグが1分でも、通常はリフレッシュに1時間かかる場合、システムはそれに応じて「実際のラグ」を調整します。

  リフレッシュのパフォーマンスを向上させるには、 動的テーブルのパフォーマンスの最適化 をご参照ください。

手動リフレッシュがスキップされることはありませんが、特に動的テーブルで頻繁に手動リフレッシュを行う場合、スケジュール・リフレッシュがスキップされる可能性があります。これを行うと、下流の動的テーブルがリフレッシュされなくなります。このため、Snowflakeでは、ターゲットラグに従ってリフレッシュが期待されるダウンストリームの動的テーブルで、手動リフレッシュを頻繁に実行しないことを推奨しています。

失敗したリフレッシュ¶

リフレッシュの失敗は通常、動的テーブルのクエリ定義、入力データ（解析エラーなど）、または上流の失敗が原因です。

SELECT
  name,
  data_timestamp,
  state,
  state_code,
  state_message
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME_PREFIX => 'MY_DB.MY_SCHEMA',
  ERROR_ONLY => TRUE
));

リフレッシュ失敗の診断¶

各リフレッシュの隣にある Show query profile を選択して、 Query Profile を使用します。これは、クエリの実行グラフを示します。

Snowsight の Graph ビューを使用して、依存関係を視覚化します。上流の動的テーブルが失敗または中断されると、その下流のテーブルが失敗します。詳細については、 動的テーブルに接続されたテーブルのグラフ表示 をご参照ください。

SELECT
  timestamp,
  resource_attributes:"snow.executable.name"::VARCHAR AS dt_name,
  resource_attributes:"snow.query.id"::VARCHAR AS query_id,
  value:message::VARCHAR AS error
FROM my_event_table
WHERE
  resource_attributes:"snow.executable.type" = 'DYNAMIC_TABLE' AND
  resource_attributes:"snow.database.name" = 'MY_DB' AND
  value:state = 'FAILED'
ORDER BY timestamp DESC;