Übersicht zum Laden von Daten

Dieses Thema bietet einen Überblick über die wichtigsten Optionen zum Laden von Daten in Snowflake.

Um die Datenaufnahmelatenz Ihrer Datenpipelines einfach und genau zu messen, verwenden Sie Zeilenzeitstempel. Weitere Informationen dazu finden Sie unter Verwenden von Zeilenzeitstempeln, um die Latenz in Ihren Pipelines zu messen.

Unterstützte Dateispeicherorte

In Snowflake wird der Speicherort von Datendateien im Cloudspeicher als Stagingbereich bezeichnet. Der Befehl COPY INTO <Tabelle>, der sowohl für das massenhafte als auch für das kontinuierliche Laden von Daten (Snowpipe) verwendet wird, unterstützt sowohl Konten für Cloud-Speicher, die von Ihrer Geschäftseinheit verwaltet werden (externe Stagingbereiche), als auch Cloud-Speicher, die in Ihrem Snowflake-Konto enthalten sind (interne Stagingbereiche).

Externe Stagingbereiche

Das Laden von Daten von einem der folgenden Cloudspeicherdienste wird unabhängig von der Cloudplattform unterstützt, auf der sich Ihr Snowflake-Konto befindet:

  • Amazon S3

  • Google Cloud Storage

  • Microsoft Azure

Sie können nicht auf Daten in archivierten Cloudspeicherklassen zugreifen, die erst wiederhergestellt werden müssen, bevor sie abgerufen werden können. Zu diesen Archivspeicherklassen gehören zum Beispiel die Amazon S3-Speicherklassen Glacier Flexible Retrieval und Glacier Deep Archive oder Microsoft Azure Archive Storage.

Stellen Sie Daten im Stagingbereich bereit, indem Sie die Datendateien mit den vom Cloudspeicherdienst bereitgestellten Tools in Ihr Cloudspeicherkonto hochladen.

Ein benannter externer Stagingbereich ist ein Datenbankobjekt, das in einem Schema erstellt wurde. Dieses Objekt speichert die URL zu den Dateien im Cloudspeicher, die Einstellungen für den Zugriff auf das Cloudspeicherkonto und praktische Einstellungen wie die Optionen, die das Format der Stagingdateien beschreiben. Erstellen Sie Stagingbereiche mit dem Befehl CREATE STAGE.

Bemerkung

Beim Laden von Daten aus Dateien eines Cloudspeicherdienstes, der sich in einer anderen Region oder auf einer anderen Cloudplattform als Ihr Snowflake-Konto befinden, können einige Abrechnungsgebühren für die Datenübertragung anfallen. Weitere Informationen dazu finden Sie unter Erläuterungen zu Datentransferkosten.

Interne Stagingbereiche

Snowflake verwaltet die folgenden Stagingbereichstypen in Ihrem Konto:

Benutzer:

Jedem Benutzer wird ein Benutzer-Stagingbereich zum Speichern von Dateien zugewiesen. Dieser Stagingbereichstyp dient zum Speichern von Dateien, die von einem einzelnen Benutzer bereitgestellt und verwaltet werden, jedoch in mehrere Tabellen geladen werden können. Im Gegensatz zu benannten Stagingbereichen können Benutzer-Stagingbereiche nicht geändert oder gelöscht werden.

Tabelle:

Für jede in Snowflake erstellte Tabelle steht ein Tabellen-Stagingbereich zur Verfügung. Dieser Stagingbereichstyp dient zum Speichern von Dateien, die von einem oder mehreren Benutzern im Stagingbereich bereitgestellt und verwaltet werden, aber nur in eine einzelne Tabelle geladen werden. Tabellen-Stagingbereiche können nicht geändert oder gelöscht werden.

Beachten Sie, dass ein Tabellen-Stagingbereich kein separates Datenbankobjekt ist, sondern ein impliziter Stagingbereich, der an die Tabelle selbst gebunden ist. Ein Tabellen-Stagingbereich hat keine eigenen zuweisbaren Berechtigungen. Um Dateien in einem Tabellen-Stagingbereich bereitzustellen oder die Dateien im Stagingbereich aufzulisten, abzufragen oder zu löschen, müssen Sie der Tabelleneigentümer sein (die Rolle mit der Berechtigung OWNERSHIP für die Tabelle).

Benannt:

Ein benannter interner Stagingbereich ist ein Datenbankobjekt, das in einem Schema erstellt wurde. Dieser Stagingbereichstyp dient zum Speichern von Dateien, die von einem oder mehreren Benutzern im Stagingbereich bereitgestellt und verwaltet werden und die in eine oder mehrere Tabellen geladen werden. Da benannte Stagingbereiche Datenbankobjekte sind, kann die Möglichkeit zum Erstellen, Ändern, Verwenden oder Löschen dieser Objekte mithilfe von sicherheitsspezifischen Zugriffssteuerungsrechten gesteuert werden. Erstellen Sie Stagingbereiche mit dem Befehl CREATE STAGE.

Laden Sie Dateien mit dem Befehl PUT von Ihrem lokalen Dateisystem in einen der internen Stagingbereichstypen hoch.

Massenladen vs. kontinuierliches Laden

Snowflake bietet die folgenden Hauptlösungen zum Laden von Daten. Die beste Lösung kann vom zu ladenden Datenvolumen und der Häufigkeit des Ladens abhängen.

Massenladen mit dem Befehl COPY

Diese Option ermöglicht das Laden von Datenbatches aus Dateien, die bereits in Cloudspeicher verfügbar sind, oder das Kopieren (d. h. Staging) von Datendateien von einem lokalen Computer zu einem internen (d. h. Snowflake) Cloudspeicherort, bevor die Daten mit dem COPY-Befehl in Tabellen geladen werden.

Computeressourcen

Das Massenladen basiert auf vom Benutzer bereitgestellten virtuellen Warehouses, die in der Anweisung COPY angegeben sind. Benutzer müssen das Warehouse entsprechend dimensionieren, um die erwarteten Lasten aufzunehmen.

Einfache Transformationen während eines Ladevorgangs

Snowflake unterstützt die Transformation von Daten beim Laden in eine Tabelle mit dem Befehl COPY. Zu den Optionen gehören:

  • Neuordnung von Spalten

  • Auslassung von Spalten

  • Umwandlungen

  • Kürzung von Textzeichenfolgen, die die Länge der Zielspalte überschreiten.

Es ist nicht erforderlich, dass die Datendateien die gleiche Anzahl und Reihenfolge der Spalten aufweisen wie die Zieltabelle.

Kontinuierliches Laden mit Snowpipe

Diese Option dient dazu, kleine Datenmengen (z. B. Microbatches) zu laden und diese schrittweise für die Analyse zur Verfügung zu stellen. Snowpipe lädt Daten innerhalb weniger Minuten, nachdem Dateien einem Stagingbereich hinzugefügt und zur Erfassung übermittelt wurden. Dies stellt sicher, dass Benutzer die neuesten Ergebnisse erhalten, sobald die Rohdaten verfügbar sind.

Computeressourcen

Snowpipe verwendet von Snowflake bereitgestellte Computeressourcen (d. h. ein serverloses Computemodell). Diese von Snowflake bereitgestellten Ressourcen werden bei Bedarf automatisch in der Größe angepasst und aufwärts bzw. abwärts skaliert und mithilfe einer sekundengenauen Abrechnung in Rechnung gestellt und aufgeschlüsselt. Die Datenerfassung wird auf der Grundlage der tatsächlichen Arbeitslasten berechnet.

Einfache Transformationen während eines Ladevorgangs

Die Anweisung COPY in einer Pipedefinition unterstützt dieselben COPY-Transformationsoptionen wie beim Massenladen von Daten.

Darüber hinaus können Daten-Pipelines Snowpipe nutzen, um mithilfe von automatisierten Aufgaben und den Change Data Capture (CDC)-Informationen in Streams kontinuierlich Microbatches an Daten in Stagingbereich-Tabellen zu laden und für Transformation und Optimierung der Daten zu sorgen.

Kontinuierliches Laden mit Snowpipe Streaming

Die Snowpipe Streaming-API schreibt Datenzeilen direkt in Snowflake-Tabellen, ohne dass Staging-Dateien erforderlich sind. Diese Architektur führt zu geringeren Latenzen und entsprechend niedrigeren Kosten für das Laden beliebiger Datenmengen, was dieses Feature zu einem leistungsstarken Tool für die Verarbeitung von Quasi-Echtzeit-Datenstreams macht.

Snowpipe Streaming ist auch für den Snowflake-Konnektor für Kafka verfügbar, der einen einfachen Upgrade-Pfad bietet, um die Vorteile der geringeren Latenz und der niedrigeren Kosten nutzen zu können.

Weitere Informationen dazu finden Sie unter Snowpipe Streaming.

Laden von Daten aus Apache Kafka-Themen

Mit Snowflake-Konnektor für Kafka können Benutzer eine Verbindung zu einem Apache Kafka-Server herstellen, Daten aus einem oder mehreren Themen lesen und diese Daten in Snowflake-Tabellen laden.

DML-Fehlerprotokollierung

Wenn Sie eine Reihe von DML-Anweisungen ausführen und eine der Anweisungen einen Fehler zurückgibt, endet die DML-Operation, und die von der DML-Anweisung vorgenommenen Änderungen werden rückgängig gemacht. Wenn Sie die restlichen DML-Anweisungen ausführen und den aufgetretenen Fehler protokollieren möchten, können Sie die DML-Fehlerprotokollierung für die Tabelle aktivieren. Die Tabelle, für die die DML-Fehlerprotokollierung aktiviert ist, wird als Basistabelle bezeichnet. Fehler werden in einer Fehlertabelle protokolliert, die mit der Basistabelle verbunden ist.

Die DML-Fehlerprotokollierung wird für eine Tabelle nur aktiviert, wenn beide der folgenden Bedingungen erfüllt sind:

  • Die ERROR_LOGGING-Eigenschaft ist für die Tabelle auf TRUE eingestellt.

  • Der Parameter OPT_OUT_ERROR_LOGGING ist für die aktuelle Sitzung auf FALSE gesetzt.

Die DML-Fehlerprotokollierung wird für eine Tabelle nur deaktiviert, wenn eine der folgenden Bedingungen erfüllt ist:

  • Die ERROR_LOGGING-Eigenschaft ist für die Tabelle auf FALSE eingestellt.

  • Der Parameter OPT_OUT_ERROR_LOGGING ist für die aktuelle Sitzung auf TRUE gesetzt.

In den folgenden Abschnitten finden Sie weitere Informationen zur DML-Fehlerprotokollierung:

Anwendungsfälle für die DML-Fehlerprotokollierung

Sie könnten die DML-Fehlerprotokollierung verwenden, um Ausfälle bei Fehlern für die folgenden Anwendungsfälle zu vermeiden:

  • Migration von Daten von Drittanbietern, die auf die DML-Fehlerprotokollierung angewiesen ist, wie z. B. Daten aus einer Oracle-Datenbank.

  • Durchsetzung einiger Tabelleneinschränkungen, wie z. B. NOTNULL-Einschränkungen bei der Datenaufnahme.

Konfigurieren der DML-Fehlerprotokollierung für eine Tabelle

Sie können die DML-Fehlerprotokollierung für eine standardmäßige Snowflake-Tabelle oder eine von Snowflake verwaltete Iceberg-Tabelle aktivieren oder deaktivieren, wenn Sie die Tabelle erstellen oder ändern.

Um die Fehlerprotokollierung für eine Tabelle zu aktivieren oder zu deaktivieren, verwenden Sie die folgenden SQL-Befehle, um die ERROR_LOGGING-Eigenschaft für die Tabelle festzulegen:

In den folgenden Beispielen wird die DML-Fehlerprotokollierung für Tabellen konfiguriert, und es wird gezeigt, wie Fehler in Fehlertabellen protokolliert werden:

In den folgenden Beispielen wird die DML-Fehlerprotokollierung für Tabellen konfiguriert, und es wird gezeigt, wie Fehler in Fehlertabellen protokolliert werden:

Fehler beim direkten Einfügen von Zeilen protokollieren

Das folgende Beispiel protokolliert Fehler, die beim direkten Einfügen von Zeilen in eine Tabelle auftreten:

  1. Erstellen Sie eine Tabelle, und aktivieren Sie die DML-Fehlerprotokollierung für diese:

    CREATE TABLE test_dml_error_logging(
  n NUMBER(4, 0) NOT NULL,
  t VARCHAR(5)
  )
  ERROR_LOGGING = true;

  2. Führen Sie eine INSERT-Anweisung aus, die versucht, mehrere Zeilen einzufügen, einschließlich gültiger und ungültiger Werte:

    INSERT INTO test_dml_error_logging
  VALUES
    ('invalid_cast', '1'),
    (10, 'valid'),
    (NULL, 'toolong');

    +-------------------------+
| number of rows inserted |
|-------------------------|
|                       1 |
+-------------------------+

  3. Fragen Sie die Tabelle ab, um zu bestätigen, dass eine gültige Zeile eingefügt wurde:

    SELECT * FROM test_dml_error_logging;

    +----+-------+
|  N | T     |
|----+-------|
| 10 | valid |
+----+-------+

  4. Fragen Sie die Fehlertabelle für die test_dml_error_logging-Basistabelle ab, um die protokollierten Fehler anzuzeigen:

    SELECT * FROM ERROR_TABLE(test_dml_error_logging);

    +-------------------------------+--------------------------------------+------------+----------------------------------------------------------------------+--------------------+
| TIMESTAMP                     | QUERY_ID                             | ERROR_CODE | ERROR_METADATA                                                       | ERROR_DATA         |
|-------------------------------+--------------------------------------+------------+----------------------------------------------------------------------+--------------------|
| 2026-03-12 12:18:39.470 -0700 | 01c2fc06-000e-6668-0000-76b90170a28e |     100038 | {                                                                    | {                  |
|                               |                                      |            |   "error_code": 100038,                                              |   "N": [           |
|                               |                                      |            |   "error_message": "Numeric value 'invalid_cast' is not recognized", |     "invalid_cast" |
|                               |                                      |            |   "error_source": "N",                                               |   ],               |
|                               |                                      |            |   "sql_state": "22018"                                               |   "T": "1"         |
|                               |                                      |            | }                                                                    | }                  |
| 2026-03-12 12:18:39.470 -0700 | 01c2fc06-000e-6668-0000-76b90170a28e |     100072 | {                                                                    | {                  |
|                               |                                      |            |   "error_code": 100072,                                              |   "N": [           |
|                               |                                      |            |   "error_message": "NULL result in a non-nullable column",           |     null           |
|                               |                                      |            |   "error_source": "N",                                               |   ],               |
|                               |                                      |            |   "sql_state": "22000"                                               |   "T": [           |
|                               |                                      |            | }                                                                    |     "toolong"      |
|                               |                                      |            |                                                                      |   ]                |
|                               |                                      |            |                                                                      | }                  |
+-------------------------------+--------------------------------------+------------+----------------------------------------------------------------------+--------------------+

  5. Deaktivieren Sie die DML-Fehlerprotokollierung für die test_dml_error_logging-Tabelle:

    ALTER TABLE test_dml_error_logging
  SET ERROR_LOGGING = false;

  6. Versuchen Sie das Gleiche mit der INSERT-Anweisung, die Sie zuvor ausgeführt haben. Ein Fehler wurde zurückgegeben, und in einer Fehlertabelle werden keine Fehler protokolliert:

    INSERT INTO test_dml_error_logging
  VALUES
    ('invalid_cast', '1'),
    (10, 'valid'),
    (NULL, 'toolong');

    100038 (22018): DML operation to table TEST_DML_ERROR_LOGGING failed on column N with error: Numeric value 'invalid_cast' is not recognized

Fehler beim Einfügen von Zeilen aus einer Tabelle in eine andere Tabelle protokollieren

Das folgende Beispiel protokolliert Fehler beim Einfügen von Zeilen aus einer Tabelle in eine andere Tabelle:

  1. Erstellen Sie eine Quelltabelle, und fügen Sie Zeilen ein:

    CREATE TABLE dml_error_logging_source(col1 INT);

INSERT INTO dml_error_logging_source VALUES (1), (0), (-1);

  2. Erstellen Sie eine Zieltabelle mit derselben Definition wie die Quelltabelle:

    CREATE TABLE dml_error_logging_target(col1 INT);

  3. Aktivieren Sie die DML-Fehlerprotokollierung in der dml_error_logging_target-Tabelle:

    ALTER TABLE dml_error_logging_target
  SET ERROR_LOGGING = true;

  4. Fügen Sie Werte in die Zieltabelle ein, indem Sie die Quelltabelle abfragen, sodass eine der Einfügungen zu einem Fehler aufgrund einer Division durch Null führt:

    INSERT INTO dml_error_logging_target(col1)
  SELECT 1/col1 FROM dml_error_logging_source;

    +-------------------------+
| number of rows inserted |
|-------------------------|
|                       2 |
+-------------------------+

  5. Fragen Sie die Tabelle ab, um zu bestätigen, dass zwei gültige Zeilen eingefügt wurden:

    SELECT * FROM dml_error_logging_target;

    +------+
| COL1 |
|------|
|    1 |
|   -1 |
+------+

  6. Fragen Sie die Fehlertabelle für die dml_error_logging_target-Basistabelle ab, um die protokollierten Fehler anzuzeigen:

    SELECT * FROM ERROR_TABLE(dml_error_logging_target);

    +-------------------------------+--------------------------------------+------------+----------------------------------------+-------------+
| TIMESTAMP                     | QUERY_ID                             | ERROR_CODE | ERROR_METADATA                         | ERROR_DATA  |
|-------------------------------+--------------------------------------+------------+----------------------------------------+-------------|
| 2026-03-12 12:25:56.297 -0700 | 01c2fc0d-000e-6696-0000-76b90170b64a |     100051 | {                                      | {           |
|                               |                                      |            |   "error_code": 100051,                |   "COL1": [ |
|                               |                                      |            |   "error_message": "Division by zero", |     1,      |
|                               |                                      |            |   "error_source": "COL1",              |     0       |
|                               |                                      |            |   "sql_state": "22012"                 |   ]         |
|                               |                                      |            | }                                      | }           |
+-------------------------------+--------------------------------------+------------+----------------------------------------+-------------+

Fehlerprotokollierung und Fehlertabellen

Wenn die Fehlerprotokollierung für eine Tabelle aktiviert ist, erstellt Snowflake automatisch eine Fehlertabelle, die mit der Basistabelle verknüpft ist. DML-Operationen, bei denen unterstützte Fehler auftreten, protokollieren die Fehler in der Fehlertabelle, anstatt fehlzuschlagen.

Wenn die DML-Fehlerprotokollierung für eine Tabelle aktiviert ist, werden die folgenden Typen von DML-Anweisungen protokolliert:

  • Einzelne Tabelle INSERT

  • UPDATE

  • MERGE

Fehlertabellen haben eine feste Definition und können nur vom Besitzenden der Basistabelle oder einem Benutzenden aufgerufen werden, der über eine Rolle verfügt, der die SELECT ERROR TABLE-Berechtigung für die Basistabelle zugewiesen wurde. Die einzigen unterstützten direkten Operationen für eine Fehlertabelle sind SELECT- und TRUNCATE-Anweisungen. Sie können andere Arten von Anweisungen nicht direkt in Fehlertabellen ausführen. Fehlertabellen können nicht indirekt in materialisierten Ansichten oder dynamischen Tabellen verwendet werden.

Sie können die Daten aus der Fehlertabelle in andere Tabellen kopieren. Sie können die Daten in einer Fehlertabelle entfernen, indem Sie den Befehl TRUNCATE ausführen.

In den folgenden Abschnitten finden Sie weitere Informationen zur Fehlerprotokollierung und zu Fehlertabellen:

Definition der Fehlertabelle

Snowflake erstellt Fehlertabellen mit einer Standarddefinition, die nicht geändert werden kann.

Wenn Sie die DML-Fehlerprotokollierung für eine Basistabelle deaktivieren oder eine Basistabelle löschen, die eine Fehlertabelle enthält, wird die mit der Basistabelle verbundene Fehlertabelle automatisch gelöscht.

Eine Fehlertabelle hat die folgenden Spalten:

Name

Typ

Beschreibung

timestamp

TIMESTAMP

Der Zeitstempel der Anweisung, die den Fehler ausgelöst hat.

query_id

VARCHAR

Die eindeutige ID der Anweisung, die den Fehler ausgelöst hat.

error_code

NUMBER

Der Fehlercode. Wenn mehrere Spalten einer Zeile Fehler enthalten, wird in dieser Spalte nur der erste auftretende Fehler erfasst.

error_metadata

OBJECT

Die Fehlermetadaten.

Die OBJECT-Werte haben die folgende Struktur:

{
  "error_code": <value>,
  "error_message": "<value>",
  "error_source": "<value>",
  "sql_state": "<value>"
}

Die OBJECT-Werte enthalten die folgenden Schlüssel-Werte-Paare:

  • error_code: Der Fehlercode.

  • error_message: Die Fehlermeldung.

  • error_source: Der Ursprung des Fehlers, z. B. ein Spaltenname.

  • sql_state: Ein fünfstelliger Code, der auf dem ANSI SQL-Standard SQLSTATE basiert. Snowflake verwendet zusätzliche Werte, die über die Werte des ANSI-SQL-Standards hinausgehen.

Wenn mehrere Spalten einer Zeile Fehler enthalten, wird in dieser Spalte nur der erste auftretende Fehler erfasst.

error_data

OBJECT

Die Daten, die den Fehler verursacht haben.

Die OBJECT-Werte haben die folgende Struktur:

{
  "<column_name>": [
    <invalid_column_values>
  ]
  "<column_name>": <valid_column_values>
  ...
}

Die OBJECT-Werte enthalten die Schlüssel-Wert-Paare, die jede Spalte in der Basistabelle darstellen. Der Schlüssel ist der Spaltenname. Bei ungültigen Spaltenwerten, die das Fehlschlagen der DML-Operation verursacht haben, ist der Wert im Schlüssel-Wert-Paar ein Array, das die Werte enthält. Gültige Werte werden direkt angezeigt. das heißt, sie werden nicht in Arrays angezeigt.

Wenn die Daten nicht in einem OBJECT-Wert dargestellt werden können, ist der Wert NULL.

Interagieren mit Fehlertabellen

Sie können SELECT-Anweisungen und TRUNCATE-Anweisungen für Fehlertabellen unter Verwendung der folgenden Syntax ausführen:

SELECT ... FROM ERROR_TABLE( <base_table_name> )

TRUNCATE [ TABLE ] [ IF EXISTS ] ERROR_TABLE( <base_table_name> )

Wobei:

base_table_name

Der Name der Tabelle, für die die Fehlertabelle erstellt wurde.

Wenn der Name der Basistabelle beispielsweise my_table lautet, fragt die folgende Anweisung die Fehlertabelle für diese Basistabelle ab:

SELECT * FROM ERROR_TABLE(my_table);

Die folgende Anweisung schneidet die Fehlertabelle ab:

TRUNCATE ERROR_TABLE(my_table);

Anforderungen an die Zugriffssteuerung von Fehlertabellen

Jede Rolle, die Einfügungen in eine Basistabelle vornehmen kann, kann Einfügungen in deren Fehlertabelle auslösen. Unabhängig von der aktuellen Rolle ist das direkte Einfügen in eine Fehlertabelle nicht zulässig.

Die folgenden Benutzenden können SELECT-Anweisungen für eine Fehlertabelle ausführen:

  • Der Besitzende der Basistabelle der Fehlertabelle.

  • Benutzende, denen die SELECT ERROR TABLE-Berechtigung für die Basistabelle zugewiesen wurde, entweder über eine Rolle oder direkt.

    Um einer Basistabelle die SELECT ERROR TABLE-Berechtigung zuzuweisen, führen Sie eine GRANT <Berechtigungen> … TO ROLE-Anweisung oder eine GRANT <Berechtigungen> … TO USER-Anweisung aus.

    Diese Anweisungen verwenden die folgende Syntax:

    GRANT SELECT ERROR TABLE ON TABLE <base_table_name> TO ROLE <role_name>

GRANT SELECT ERROR TABLE ON TABLE <base_table_name> TO USER <user_name>

    Um zum Beispiel die SELECT ERROR TABLE-Berechtigung in einer Basistabelle namens mybasetable einer Rolle namens myrole zuzuweisen, führen Sie die folgende Anweisung aus:

    GRANT SELECT ERROR TABLE ON TABLE mybasetable TO ROLE myrole;

Um anderen Rollen Zugriff auf eine Fehlertabelle zu gewähren, kann der Besitzende der Basistabelle alternativ auch eine Ansicht erstellen, die auf der Fehlertabelle basiert, und Zugriff auf diese Ansicht gewähren.

Metadaten für die Fehlerprotokollierung

Um festzustellen, ob die Fehlerprotokollierung für eine Tabelle aktiviert ist, können Sie die GET_DDL-Funktion ausführen und den Namen der Basistabelle übergeben:

SELECT GET_DDL('TABLE', '[<namespace>.]<base_table_name>');

Beispiel: Für eine Basistabelle mit dem Namen test_dml_error_logging im aktuellen Schema führen Sie die folgende Anweisung aus:

SELECT GET_DDL('TABLE', 'test_dml_error_logging');

+--------------------------------------------------+
| GET_DDL('TABLE', 'TEST_DML_ERROR_LOGGING')       |
|--------------------------------------------------|
| create or replace TABLE TEST_DML_ERROR_LOGGING ( |
|     N NUMBER(4,0) NOT NULL,                      |
|     T VARCHAR(5)                                 |
| ) ERROR_LOGGING = true                           |
| ;                                                |
+--------------------------------------------------+

Die Kennzahlen für Fehlertabellen werden in den folgenden Ansichten erfasst:

Streams auf Fehlertabellen

Streams werden nicht direkt in Fehlertabellen unterstützt. Um die Änderungsverfolgung für Fehlertabellen zu aktivieren, erstellen Sie zunächst eine Ansicht in der Fehlertabelle, und erstellen Sie dann einen Stream in der Ansicht.

Das folgende Beispiel zeigt Ihnen, wie Sie die Änderungsverfolgung für Fehlertabellen aktivieren:

  1. Führen Sie den CREATE VIEW-Befehl aus, um eine Ansicht in der Fehlertabelle zu erstellen:

    CREATE VIEW my_error_view AS
  SELECT timestamp,
         query_id,
         error_code,
         error_metadata,
         error_data
    FROM ERROR_TABLE(test_dml_error_logging);

  2. Führen Sie den CREATE STREAM-Befehl aus, um einen Stream in der Ansicht zu erstellen:

    CREATE STREAM my_error_stream ON VIEW my_error_view;

Nutzungshinweise zur DML-Fehlerprotokollierung

Die folgenden Nutzungshinweise gelten, wenn die Fehlerprotokollierung für eine Tabelle aktiviert ist:

  • Es werden nur Fehler protokolliert, die sich direkt auf die Basistabelle beziehen.

  • Die folgenden Arten von Fehlern werden protokolliert:

    • Verstöße gegen NOT NULL-Tabelleneinschränkungen.

    • Typkonvertierungsfehler, die auftreten, wenn versucht wird, einen Wert in die Basistabellenspalte zu konvertieren.

    • Inkompatible Genauigkeits- und Skalierungswerte.

    • Inkompatible Länge für Zeichenfolgen- und Binärtypen.

    • Einige Auswertungsfehler für Ausdrücke, wie z. B. Division durch Null oder PARSE_JSON-Funktionsfehler.

  • INSERT- und CREATE TABLE … AS SELECT (CTAS)-Anweisungen für mehrere Tabellen werden normal ausgeführt. Sie scheitern an DML-Fehlern und protokollieren diese nicht.

  • Wenn Sie versuchen, eine COPY INTO-Anweisung für eine Tabelle mit aktivierter Fehlerprotokollierung auszuführen, wird der Fehler Error logging is not supported in statement 'COPY INTO' zur Kompilierungszeit zurückgegeben.

  • Fehler, die von der DML-Fehlerprotokollierung nicht unterstützt werden, verursachen, dass die DML-Operation direkt fehlschlägt.

  • Wenn eine SQL-Anweisung zu einem Kompilierungsfehler führt, endet die Operation, und es werden keine Fehler in der Fehlertabelle protokolliert.

  • Fehler, die in anderen Pfaden der Datenaufnahme auftreten, wie z. B. COPY und Snowpipe, werden nicht in Fehlertabellen protokolliert. Weitere Informationen Fehlerprotokollierung in der High-Performance-Architektur von Snowpipe Streaming finden Sie unter Fehlerprotokollierung in Snowpipe Streaming mit High-Performance-Architektur.

  • Die folgenden Hinweise beziehen sich auf die DML-Fehlerprotokollierung und Leistung:

    • Wenn die DML-Fehlerprotokollierung für eine Basistabelle aktiviert ist, und es keine Fehler in einer DML-Anweisung gibt, die in der Basistabelle ausgeführt wird, wird kein oder nur ein sehr geringer Leistungsunterschied erwartet.

    • Wenn die DML-Fehlerprotokollierung für eine Basistabelle aktiviert ist, und es Fehler in einer DML-Anweisung gibt, die in der Basistabelle ausgeführt wird, ist zusätzliche Zeit für die Ausführung der DML-Anweisung erforderlich, da die Fehlerinformationen in die Fehlertabelle eingefügt werden.

  • Wenn eine Basistabelle mit einer zugehörigen Fehlertabelle geklont wird, ist das Verhalten wie folgt:

    • Das Schema und der Inhalt der Basistabelle werden geklont.

    • Der Inhalt der Fehlertabelle wird nicht geklont.

    • Die geklonte Basistabelle hat die ERROR_LOGGING-Eigenschaft aktiviert, wodurch implizit eine leere Fehlertabelle erstellt wird.

Schemaerkennung von Spaltendefinitionen in semistrukturierten Staging-Datendateien

Semistrukturierte Daten können Tausende von Spalten enthalten. Snowflake bietet robuste Lösungen für den Umgang mit diesen Daten. Zu den Optionen gehören der direkte Verweis auf die Daten im Cloudspeicher über externe Tabellen, das Laden der Daten in eine einzelne Spalte vom Typ VARIANT oder das Transformieren und Laden der Daten in separate Spalten in einer relationalen Standardtabelle. Alle diese Optionen erfordern Kenntnisse zu den Spaltendefinitionen in den Daten.

Eine andere Lösung beinhaltet die automatische Erkennung des Schemas in einem Satz von semistrukturierten Staging-Datendateien und das Abrufen der Spaltendefinitionen. Die Spaltendefinitionen enthalten die Namen, Datentypen und die Reihenfolge der Spalten in den Dateien. Generieren Sie die Syntax in einem Format, das für die Erstellung von Snowflake-Standardtabellen, externen Tabellen oder Ansichten geeignet ist.

Bemerkung

Diese Feature unterstützt Apache Parquet-, Apache Avro-, ORC-, JSON- und CSV-Dateien.

Diese Unterstützung wird durch die folgenden SQL-Funktionen implementiert:

INFER_SCHEMA

Erkennt die Spaltendefinitionen in einem Satz von Staging-Datendateien und ruft die Metadaten in einem Format ab, das für die Erstellung von Snowflake-Objekten geeignet ist.

GENERATE_COLUMN_DESCRIPTION

Generiert eine Liste von Spalten aus einem Satz von Stagingdateien unter Verwendung der INFER_SCHEMA-Funktionsausgabe.

Diese SQL-Funktionen unterstützen sowohl interne als auch externe Stagingbereiche.

Erstellen Sie Tabellen oder externe Tabellen mit den Spaltendefinitionen, die aus einer Menge von Stagingdateien mit der Syntax CREATE TABLE … USING TEMPLATE bzw. CREATE EXTERNAL TABLE … USING TEMPLATE abgeleitet wurden. Die USING TEMPLATE-Klausel akzeptiert einen Ausdruck, der die SQL-Funktion INFER_SCHEMA aufruft, um die Spaltendefinitionen in den Dateien zu erkennen. Sobald die Tabelle erstellt ist, können Sie eine COPY-Anweisung mit der Option MATCH_BY_COLUMN_NAME verwenden, um Dateien direkt in die strukturierte Tabelle zu laden.

Die Schemaerkennung kann auch in Verbindung mit der Tabellenschemaentwicklung verwendet werden, mit der die Struktur von Tabellen automatisch weiterentwickelt wird, um die Struktur neuer Daten in den Datenquellen zu unterstützen.

Alternativen zum Laden von Daten

Sie können die folgende Option verwenden, um Ihre Daten im Cloudspeicher abzufragen, ohne sie in Snowflake-Tabellen laden zu müssen.

Externe Tabellen (Data Lake)

Externe Tabellen ermöglichen das Abfragen vorhandener Daten, die in einem externen Cloudspeicher gespeichert sind, für Analysen, ohne dass sie zuerst in Snowflake geladen werden müssen. Die Quelle der Wahrheitswerte für die Daten verbleibt im externen Cloudspeicher. In Snowflake über materialisierte Ansichten materialisierte Datasets sind schreibgeschützt.

Diese Lösung ist besonders vorteilhaft für Konten, bei denen große Datenmengen im externen Cloudspeicher gespeichert sind, von denen aber nur ein Teil abgefragt werden soll, zum Beispiel die neuesten Daten. Benutzer können materialisierte Ansichten für Teilmengen dieser Daten erstellen, um die Abfrageleistung zu verbessern.

Verwenden von Amazon S3-kompatiblem Speicher

Sie können in Snowflake externe Stagingbereiche und Tabellen erstellen, um auf Speicher in einer Anwendung oder auf einem Gerät zuzugreifen, das mit Amazon S3 kompatibel ist. Mit diesem Feature können Sie Ihre Daten verwalten, steuern und analysieren, unabhängig davon, wo die Daten gespeichert sind. Weitere Informationen dazu finden Sie unter Work with Amazon S3-compatible storage.