Snowpipe-Fehlerbehebung¶

Fehlerbenachrichtigungen¶

Konfigurieren Sie Fehlerbenachrichtigungen für Snowpipe. Wenn Snowpipe während eines Ladevorgangs auf Fehler stößt, sendet das Feature eine Benachrichtigung an einen konfigurierten Cloudmessagingdienst und ermöglicht so die Analyse Ihrer Datendateien. Weitere Informationen dazu finden Sie unter Snowpipe-Fehlerbenachrichtigungen.

Allgemeine Problembehandlung¶

Führen Sie die folgenden Schritte aus, um die Ursache für typische Probleme zu ermitteln, die das automatische Laden von Dateien verhindern.

In Microsoft Azure Data Lake Storage Gen2-Speicher generierte Dateien werden nicht geladen¶

Derzeit rufen einige Clients von Drittanbietern FlushWithClose nicht in der ADLS Gen 2 REST-API auf. Dieser Schritt ist notwendig, um Ereignisse auszulösen, die Snowpipe benachrichtigen, die Dateien zu laden. Versuchen Sie, die REST-API manuell aufzurufen, um das Laden der Daten in Snowpipe auszulösen.

Weitere Informationen zur Flush-Methode mit dem Argument close finden Sie unter https://docs.microsoft.com/en-us/dotnet/api/azure.storage.files.datalake.datalakefileclient.flush. Zusätzliche REST-API-Referenzinformationen zum Laden mit dem Parameter close finden Sie unter https://docs.microsoft.com/en-us/rest/api/storageservices/datalakestoragegen2/path/update.

Snowpipe stoppt das Laden von Dateien nach dem Löschen eines Amazon SNS-Themenabonnements¶

Wenn ein Benutzer zum ersten Mal ein Pipeobjekt erstellt, das ein bestimmtes Thema des Amazon Simple Notification Service (SNS) referenziert, abonniert Snowflake eine Snowflake-eigene Warteschlange des Amazon Simple Queue Service (SQS) zu diesem Thema. Wenn ein AWS-Administrator das SQS-Abonnement für das SNS-Thema löscht, erhält jede Pipe, die das Thema referenziert, keine Ereignismeldung mehr von Amazon S3.

So beheben Sie das Problem:

1. Warten Sie 72 Stunden ab dem Zeitpunkt, an dem das SNS-Themenabonnement gelöscht wurde.

   Nach 72 Stunden löscht Amazon SNS das gelöschte Abonnement. Weitere Informationen finden Sie in der Amazon SNS-Dokumentation.

2. Erstellen Sie alle Pipes neu, die auf das Thema verweisen (mit CREATE OR REPLACE PIPE). Verweisen Sie in der Pipedefinition auf dasselbe SNS-Thema. Eine Anleitung dazu finden Sie unter Schritt 3: Pipe mit aktivierter automatischer Erfassung erstellen.

Alle Pipes, die vor der Löschung des SNS-Themenabonnements funktionierten, sollten nun wieder Ereignismeldungen von S3 empfangen können.

Um die 72-stündige Verzögerung zu umgehen, können Sie ein SNS-Thema mit einem anderen Namen erstellen. Erstellen Sie mit dem Befehl CREATE OR REPLACE PIPE alle Pipes neu, die auf das Thema verweisen, und geben Sie den neuen Themennamen an.

Ladevorgänge aus Google Cloud Storage verzögern sich oder es fehlen Dateien¶

Wenn das automatische Laden von Daten aus Google Cloud Storage (GCS) unter Verwendung von Pub/Sub-Meldungen konfiguriert ist, konnte die Ereignismeldung möglicherweise nur für eine einzelne Stagingdatei gelesen werden. Alternativ können sich die Datenladungen von GCS zwischen einigen Minuten und einem Tag oder länger verzögern. Im Allgemeinen werden beide Probleme verursacht, wenn ein GCS-Administrator dem Snowflake-Dienstkonto nicht die Rolle Monitoring Viewer zugewiesen hat.

Eine Anleitung dazu finden Sie unter Konfigurieren des sicheren Zugriffs auf Cloudspeicher im Abschnitt „Schritt 2: Snowflake Zugriff auf die Speicherorte gewähren“.

Fehlerbenachrichtigungen¶

Die Unterstützung für Snowpipe-Fehlerbenachrichtigungen ist für Snowflake-Konten verfügbar, die auf Amazon Web Services (AWS) gehostet werden. Fehler, die beim Laden von Daten auftreten, lösen Benachrichtigungen aus, die eine Analyse Ihrer Datendateien ermöglichen. Weitere Informationen dazu finden Sie unter Snowpipe-Fehlerbenachrichtigungen.

Allgemeine Problembehandlung¶

Führen Sie die folgenden Schritte aus, um die Ursache für typische Probleme zu ermitteln, die das Laden von Dateien verhindern:

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

Menge von nicht geladenen Dateien¶

Doppelte Daten in Zieltabellen¶

Vergleichen Sie die COPY INTO <Tabelle>-Anweisungen in den Definitionen aller Pipes des Kontos durch Ausführen von SHOW PIPES oder durch Abfragen der Ansicht PIPES in Account Usage oder der Ansicht PIPES in Information Schema. Wenn in den COPY INTO <Tabelle>-Anweisungen mehrere Pipes auf denselben Cloudspeicherort verweisen, stellen Sie sicher, dass sich die Verzeichnispfade nicht überschneiden. Andernfalls könnten mehrere Pipes denselben Satz von Datendateien in die Zieltabellen laden. Diese Situation kann beispielsweise eintreten, wenn mehrere Pipe-Definitionen auf denselben Speicherort mit unterschiedlicher Granularität verweisen, wie <Speicherort>/path1/ und <Speicherort>/path1/path2/. Wenn in diesem Beispiel Dateien in <Speicherort>/path1/path2/ bereitgestellt werden, würden beide Pipes eine Kopie der Dateien laden.

Geänderte Daten konnten nicht neu geladen werden, geänderte Daten wurden unbeabsichtigt geladen¶

Snowflake verwendet Metadaten zum Laden von Dateien, um das erneute Laden derselben Dateien (und das Duplizieren von Daten) in einer Tabelle zu verhindern. Snowpipe verhindert das Laden von Dateien mit dem gleichen Namen, auch wenn sie später geändert wurden (d. h. ein anderes eTag haben).

Die Metadaten zum Laden von Dateien sind dem Pipeobjekt zugeordnet und nicht der Tabelle. Infolgedessen:

• Stagingdateien mit dem gleichen Namen wie bereits geladene Dateien werden ignoriert, auch wenn sie geändert wurden, z. B. wenn neue Zeilen hinzugefügt oder Fehler in der Datei korrigiert wurden.

• Das Kürzen der Tabelle mit dem Befehl TRUNCATE TABLE löscht nicht die Snowpipe-Datei, die die Metadaten lädt.

Beachten Sie jedoch, dass Pipes die Metadaten des Ladeverlaufs nur für 14 Tage beibehalten. Daher:

Dateien wurden innerhalb von 14 Tagen geändert und erneut bereitgestellt

Snowpipe ignoriert geänderte Dateien, die erneut bereitgestellt werden. Um die gleichen Datendateien neu zu laden, ist es derzeit notwendig, das Pipeobjekt mit der CREATE OR REPLACE PIPE-Syntax neu zu erstellen.

Im folgenden Beispiel wird die mypipe-Pipe basierend auf dem Beispiel in Schritt 1 von Vorbereiten des Ladens von Daten über die Snowpipe REST-API neu erstellt:

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

Copy

Dateien wurden nach 14 Tagen geändert und erneut bereitgestellt

Snowpipe lädt die Daten erneut und führt möglicherweise zu doppelten Datensätzen in der Zieltabelle.

Darüber hinaus können doppelte Datensätze in die Zieltabelle geladen werden, wenn COPY INTO <Tabelle>-Anweisungen ausgeführt werden, die auf denselben Bucket/Container, Pfad und dieselbe Zieltabelle verweisen wie beim Laden Ihrer aktiven Snowpipe. Die Ladeverläufe für den COPY-Befehl und Snowpipe werden in Snowflake separat gespeichert. Wenn Sie nach dem Laden historischer Stagingdaten die Daten manuell über die Pipekonfiguration laden müssen, führen Sie eine ALTER PIPE … REFRESH-Anweisung aus. Weitere Informationen dazu finden Sie unter Menge von nicht geladenen Dateien unter diesem Thema.

Mit CURRENT_TIMESTAMP eingefügte Ladezeiten liegen vor LOAD_TIME-Werten der COPY_HISTORY -Ansicht¶

Tabellendesigner können eine Zeitstempelspalte hinzufügen, die den aktuellen Zeitstempel als Standardwert einfügt, wenn Datensätze in eine Tabelle geladen werden. Dadurch kann die Zeit erfasst werden, zu der jeder Datensatz in die Tabelle geladen wurde, jedoch liegen die Zeitstempel vor den LOAD_TIME-Spaltenwerten, die von der COPY_HISTORY-Funktion (Information Schema) oder der COPY_HISTORY-Ansicht (Account Usage) zurückgegeben werden. Der Grund dafür ist, dass CURRENT_TIMESTAMP ausgewertet wird, wenn der Ladevorgang in den Clouddiensten kompiliert wird, und nicht, wenn der Datensatz in die Tabelle eingefügt wird (d. h., wenn die Transaktion für die Ladeoperation mit Commit bestätigt wird).

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.

Dieser Fehler kann auftreten, wenn die Zuordnung zwischen dem externen Stagingbereich und der mit dem Stagingbereich verknüpften Speicherintegration unterbrochen wurde. Dies geschieht, wenn das Speicherintegrationsobjekt neu erstellt wurde (mithilfe von CREATE OR REPLACE STORAGE INTEGRATION). Ein Stagingbereich ist mit einer Speicherintegration verknüpft, wobei anstelle des Namens der Speicherintegration eine ausgeblendete ID verwendet wird. Im Hintergrund löscht die CREATE OR REPLACE-Syntax das Objekt und erstellt es mit einer anderen verborgenen ID neu.

Wenn Sie eine Speicherintegration neu erstellen müssen, nachdem diese mit einer oder mehreren Stagingbereichen verknüpft wurde, müssen Sie die Zuordnung zwischen einem Stagingbereich und der Speicherintegration neu einrichten, indem Sie ALTER STAGE stage_name SET STORAGE_INTEGRATION = storage_integration_name ausführen, wobei:

• stage_name ist der Name des Stagingbereichs.

• storage_integration_name ist der Name der Speicherintegration.

Fehler bei Snowpipe, das auf Regionen für Regierungsbehörden verweist¶

Sie können einen Fehler erhalten, wenn Snowpipe auf einen Bucket in einer Regionen für Regierungsbehörden verweist, während sich das Konto in einer kommerziellen Region befindet. Beachten Sie, dass in den von den Cloudanbietern bereitgestellten Regionen für Regierungsbehörden das Senden und Empfangen von Ereignisbenachrichtigungen an oder aus anderen kommerziellen Regionen nicht zulässig ist. Weitere Informationen dazu finden Sie unter AWS GovCloud (US) und Azure Government.