動的テーブル更新のスキップ、スロー、失敗のトラブルシューティング

このトピックでは、リフレッシュがスキップされた、遅い、または失敗した場合のトラブルシューティングを支援します。

動的テーブルのリフレッシュを監視する 場合、以下の点に注意してください。

リフレッシュのスキップ

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

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

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

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

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

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

リフレッシュが遅い、または失敗

動的テーブル・リフレッシュのパフォーマンスは、処理するワークロードやデータに関する特定の仮定に依存します。リフレッシュの失敗は通常、動的テーブルのクエリ定義、入力データ (解析エラーなど)、またはシステム内部の問題によるものです。

更新に時間がかかる場合は、 Snowsight の Refresh History ページ を使用して、動的テーブルの更新時間の変化を視覚化し、異常値を検出します。

Snowsightにおけるリフレッシュ履歴の一例。

リフレッシュに失敗した場合は、 Refresh History ページを使用して、リフレッシュの失敗が更新の遅延によるものか、データの不整合によるものかを判断します。 Source Data Timestamp 列には、最後に更新に成功した時刻が表示されます。リフレッシュに失敗しても、この値は上がりません。この値が指定されたターゲット・ラグに対して大きく遅れている場合、動的テーブルが遅れていることを示します。

さらに、各リフレッシュの横にある Show query profile をクリックすると、高度なトラブルシューティングのために Query Profile を使用できます。クエリのグラフが表示されます。

Snowsightのクエリプロファイル表示オプションを強調表示。

また、 Snowsight の Graph 表示を使用して、動的テーブルの依存関係を視覚化し、トラブルシューティングを行うこともできます。アップストリームの動的テーブルに障害が発生したり、中断したりすると、自動的にダウンストリームの動的テーブルのリフレッシュが失敗します。詳細については、 動的テーブルに接続されたテーブルのグラフ表示 をご参照ください。