Snowpipeのトラブルシューティング¶

エラー通知¶

Snowpipeのエラー通知を構成します。読み込み中にSnowpipeでエラーが発生すると、この機能は設定されたクラウドメッセージングサービスに通知をプッシュし、データファイルの分析を可能にします。詳細については、 Snowpipeのエラー通知 をご参照ください。

一般的なトラブルシューティングステップ¶

次のステップを実行して、ファイルの自動ロードを妨げるほとんどの問題の原因を特定します。

Microsoft Azure Data Lake Storage Gen2ストレージで生成されたファイルが読み込まれていません¶

現在、一部のサードパーティクライアントは ADLS Gen 2 REST API にある FlushWithClose を呼び出しません。このステップは、Snowpipeにファイルをロードするように通知するイベントをトリガーするために必要です。Snowpipeをトリガーしてこれらのファイルをロードするために、手動による REST API の呼び出しを試みてください。

close 引数を使用した Flush メソッドの詳細については、https://docs.microsoft.com/en-us/dotnet/api/azure.storage.files.datalake.datalakefileclient.flushをご参照ください。 close パラメーターの負荷に関する追加の REST API 参照情報については、https://docs.microsoft.com/en-us/rest/api/storageservices/datalakestoragegen2/path/updateをご参照ください。

Amazon SNS トピックのサブスクリプションが削除された後に、Snowpipeによるファイルの読み込みが停止する¶

ユーザーが特定のAmazon Simple Notification Service（SNS）トピックを参照するパイプオブジェクトを初めて作成するとき、SnowflakeはSnowflakeが所有するAmazon Simple Queue Service（SQS）キューをトピックにサブスクライブします。AWS 管理者が SNS トピックへの SQS サブスクリプションを削除すると、トピックを参照するパイプはAmazon S3からイベントメッセージを受信しなくなります。

問題を解決するには、

1. SNS トピックサブスクリプションが削除されてから72時間待ちます。

   72時間後、Amazon SNS は削除されたサブスクリプションをクリアします。詳細については、 Amazon SNS ドキュメント をご参照ください。

2. トピックを参照するパイプを再作成します（CREATE OR REPLACE PIPE を使用）。パイプ定義で同じ SNS トピックを参照します。手順については、 ステップ3: 自動インジェストを有効にしたパイプを作成する をご参照ください。

SNS トピックサブスクリプションの削除前に機能していたすべてのパイプが、S3からのイベントメッセージの受信を再開するはずです。

72時間の遅延を回避するために、別の名前で SNS トピックを作成できます。CREATE OR REPLACE PIPE コマンドを使用してトピックを参照するパイプを再作成し、新しいトピック名を指定します。

Google Cloud Storageからのロードの遅延、またはファイルの欠落¶

Pub/Subメッセージを使用して、Google Cloud Storage（GCS）からの自動データロードが構成されている場合は、単一のステージングされたファイルのイベントメッセージのみを読み取ることができます。または、 GCS からのデータのロードを数分から1日以上遅らせることもできます。一般的に、どちらの問題も、 GCS 管理者がSnowflakeサービスアカウントに Monitoring Viewer ロールを付与していない場合に発生します。

手順については、 クラウドストレージへの安全なアクセスの構成 にある「ステップ2: Pub/SubサブスクリプションにSnowflakeアクセスを許可する」をご参照ください。

エラー通知¶

Snowpipeエラー通知のサポートは、Amazon Web Services（AWS）でホストされているSnowflakeアカウントで利用できます。データファイルの分析を可能にするデータロードトリガー通知中に発生したエラー。詳細については、 Snowpipeのエラー通知 をご参照ください。

一般的なトラブルシューティングステップ¶

次のステップを実行して、ファイルのロードを妨げるほとんどの問題の原因を特定します。

snowflake.ingest.error.IngestResponseError: Http Error: 401, Vender Code: 390144, Message: JWT token is invalid.

ファイルのセットがロードされません¶

ターゲットテーブルのデータが重複しています¶

SHOW PIPES を実行するか、Account Usageの PIPES ビューまたはInformation Schemaの PIPES ビューのいずれかをクエリして、アカウントにあるすべてのパイプの定義にある COPY INTO <テーブル> ステートメントを比較します。複数のパイプが、 COPY INTO <テーブル> ステートメントで同じクラウドストレージの場所を参照している場合は、ディレクトリパスが重複していないことを確認してください。そうしないと、複数のパイプが、同じデータファイルのセットをターゲットテーブルにロードする可能性があります。たとえば、この状況は、複数のパイプ定義が <ストレージの場所>/path1/ や <ストレージの場所>/path1/path2/ など、細分性のレベルが異なる同じストレージの場所を参照している場合に発生する可能性があります。この例では、ファイルが <ストレージの場所>/path1/path2/ でステージングされている場合は、両方のパイプがファイルのコピーをロードします。

変更済みデータをリロードできません、変更済みデータが意図せずにロードされました¶

Snowflakeはファイルロードメタデータを使用して、テーブル内の同じファイル（およびデータの複製）の再ロードを防ぎます。Snowpipeは、後で変更された（つまり、異なるeTagを持つ）場合でも、同じ名前のファイルをロードしません。

ファイルロードメタデータは、テーブルではなく、 パイプオブジェクト に関連付けられています。その結果：

• 既にロードされたファイルと同じ名前のステージングされたファイルは、新しい行の追加や、ファイルのエラーの修正などの変更があっても無視されます。

• TRUNCATE TABLE コマンドを使用してテーブルを切り捨てても、メタデータをロードしているSnowpipeファイルは削除 されません 。

ただし、パイプは 14日間 のロード履歴メタデータのみを保持します。したがって、次のようになります。

14日以内に変更され、再度ステージングされたファイル:

Snowpipeは、再度ステージングされた変更済みファイルを無視します。現在、同じデータファイルをリロードするには、 CREATE OR REPLACE PIPE 構文を使用してパイプオブジェクトを再作成する必要があります。

次の例では、 Snowpipe REST APIを使用したデータロードの準備 のステップ1の例に基づいて mypipe パイプを再作成します。

create or replace pipe mypipe as copy into mytable from @mystage;

Copy

14日後に変更され、再びステージングされたファイル:

Snowpipeはデータを再度ロードするため、ターゲットテーブルに記録が重複する可能性があります。

さらに、アクティブなSnowpipeロードと同じバケット/コンテナ、パス、およびターゲットテーブルを参照する COPY INTO <テーブル> ステートメントが実行された場合、ターゲット記録に重複記録をロードできます。COPY コマンドとSnowpipeのロード履歴は、Snowflakeに個別に保存されます。履歴ステージングデータを読み込んだ後、パイプ構成を使用して手動でデータを読み込む必要がある場合は、 ALTER PIPE ... REFRESH ステートメントを実行します。詳細については、このトピック内の ロードされていないファイルのセット をご参照ください。

COPY_HISTORY ビューの LOAD_TIME 値より前の CURRENT_TIMESTAMP を使用して挿入されたロード時間¶

テーブル設計者は、記録がテーブルにロードされるときに、現在のタイムスタンプをデフォルト値として挿入するタイムスタンプ列を追加できます。目的は、各記録がテーブルにロードされた時間をキャプチャすることです。ただし、タイムスタンプは、 COPY_HISTORY 関数 （Information Schema）または COPY_HISTORY ビュー （Account Usage）によって返される LOAD_TIME 列の値よりも前です。その理由は、 CURRENT_TIMESTAMP は、記録がテーブルに挿入されたとき（つまり、ロード操作のトランザクションがコミットされたとき）ではなく、クラウドサービスでロード操作がコンパイルされたときに評価されるためです。

Error: Integration {0} associated with the stage {1} cannot be found¶

003139=SQL compilation error:\nIntegration ''{0}'' associated with the stage ''{1}'' cannot be found.

このエラーは、外部ステージと、ステージにリンクされているストレージ統合との関連付けが壊れている場合に発生する可能性があります。これは、ストレージ統合オブジェクトが再作成されたときに発生します（ CREATE OR REPLACE STORAGE INTEGRATION を使用）。ステージは、ストレージ統合の名前ではなく、非表示の ID を使用してストレージ統合にリンクします。バックグラウンドでは、 CREATE OR REPLACE 構文はオブジェクトをドロップし、別の非表示の IDでオブジェクトを再作成します。

1つ以上のステージにリンクされた後にストレージ統合を再作成する必要がある場合は、 ALTER STAGE stage_name SET STORAGE_INTEGRATION = storage_integration_name を実行して、各ステージとストレージ統合間の関連付けを再確立する必要があります。ここで、

• stage_name は、ステージの名前です。

• storage_integration_name は、ストレージ統合の名前です。

Snowpipeの政府リージョン参照エラー¶

アカウントが商用リージョンにあり、Snowpipeが政府リージョンのバケットを参照するとエラーが発生する場合があります。クラウドプロバイダーの政府リージョンでは、他の商用リージョンとの間でイベント通知を送受信することは許可されていないことに注意してください。詳細については、 AWSGovCloud （US） および Azure Government をご参照ください。