Bundle 2022_02

Unter diesem Thema werden die folgenden in diesem Monat vorgenommenen Verhaltensänderungen (falls vorhanden) beschrieben:

  • Features, die veraltet sind.

  • Gebündelte Änderungen, die aktiviert wurden.

  • Andere, nicht gebündelte Änderungen, die implementiert wurden.

Wenn Sie Fragen zu diesen Änderungen haben, wenden Sie sich an den Snowflake-Support.

Weitere Einzelheiten zu den in diesem Monat eingeführten neuen Features, Erweiterungen und Korrekturen finden Sie unter April 2022.

Wichtig

Sofern nicht anders angegeben, sind diese Änderungen in Bundle 2022_02 enthalten, das standardmäßig mit Release 6.9 aktiviert wurde.

Unter diesem Thema:

SQL-Änderungen – Allgemein

Abfragen von hierarchischen Daten: Iterationslimits werden nicht mehr erzwungen

Wenn Sie hierarchische Daten abfragen, können Sie rekursive CTEs oder den CONNECT BY-Befehl verwenden, um über jede Hierarchieebene zu iterieren.

Die Begrenzung der Anzahl der Iterationen, die zuvor auf 100 gesetzt war (intern von Snowflake), wird nun nicht mehr erzwungen:

Bisher:

Wenn eine Abfrage die maximale Anzahl von Iterationen (100) überschreitet, schlug die Abfrage mit der folgenden Fehlermeldung fehl:

Recursion exceeded max iteration count (n)

wobei n die maximal zulässige Anzahl von Iterationen war.

Der Fehlercode für diesen Fehler war 100189.

Jetzt:

Die Anzahl der durchgeführten Iterationen ist nicht begrenzt.

Abfragen, die zuvor mit der obigen Fehlermeldung fehlgeschlagen sind (insbesondere Abfragen, die zu Endlosschleifen führen), schlagen nun nicht mehr fehl und werden so lange ausgeführt, bis die Abfrage entweder erfolgreich ist oder eine Zeitüberschreitung eintritt, was durch Festlegen des Parameters STATEMENT_TIMEOUT_IN_SECONDS gesteuert werden kann.

Um festzustellen, ob Sie Abfragen hatten, die die maximale Anzahl von Iterationen überschritten haben, bevor die Änderung aktiviert wurde, prüfen Sie die Ansicht QUERY_HISTORY auf Abfragen, die mit dem Fehlercode 100189 fehlgeschlagen sind:

SELECT * FROM snowflake.account_usage.query_history WHERE error_code = 100189;
Copy

Wenn die Änderung aktiviert ist, wird die erneute Ausführung derselben Abfragen nicht fehlschlagen. Wenn eine Endlosschleife auftritt, wird die Abfrage nicht vorzeitig beendet. Stattdessen wird die Abfrage so lange ausgeführt, bis sie entweder erfolgreich ist oder eine Zeitüberschreitung eintritt (z. B. wenn die im Parameter STATEMENT_TIMEOUT_IN_SECONDS festgelegte Anzahl von Sekunden überschritten wird).

Weitere Informationen zum Entstehen, Erkennen und Beseitigen von Endlosschleifen finden Sie unter Problembehandlung bei rekursiven CTEs.

Time Travel: Vererbter Parameter DATA_RETENTION_TIME_IN_DAYS bleibt in transienten Tabellen erhalten

Das Verhalten von transienten Tabellen, deren Parameter DATA_RETENTION_TIME_IN_DAYS für ein übergeordnetes Objekt (Konto, Datenbank oder Schema) explizit auf 0 (Tage) gesetzt ist, wurde wie folgt geändert:

Bisher:

Transiente Tabellen erbten nicht die Einstellung des Parameters DATA_RETENTION_TIME_IN_DAYS von übergeordneten Objekten, wenn die Datenaufbewahrungsdauer 0 Tage betrug. Transiente Tabellen wurden mit einer Datenaufbewahrungsdauer von 1 Tag erstellt, unabhängig von der Datenaufbewahrungsdauer des übergeordneten Objekts.

Jetzt:

Transiente Tabellen erben die für ein übergeordnetes Objekt (Schema, Datenbank, Konto) festgelegte Datenaufbewahrungsdauer, wenn der Parameter DATA_RETENTION_TIME_IN_DAYS des übergeordneten Objekts auf 0 gesetzt ist.

Bemerkung

Diese Änderung betrifft nur neu erstellte transiente Tabellen und ändert nicht die Einstellung von DATA_RETENTION_TIME_IN_DAYS für transiente Tabellen, die vor der Aktivierung der Änderung erstellt wurden.

Um eine Liste der transienten Tabellen in einem Konto zu erstellen, von denen bei mindestens einer der übergeordneten Tabellen (Schema oder Datenbank) DATA_RETENTION_TIME_IN_DAYS auf 0 gesetzt ist, führen Sie die Anweisungen aus dem folgenden Beispiel aus. Bevor Sie die Anweisungen ausführen, müssen Sie jedoch Folgendes beachten:

  • Die Liste enthält transiente Tabellen, bei denen der Parameter DATA_RETENTION_TIME_IN_DAYS explizit auf 1 gesetzt ist.

    Wenn DATA_RETENTION_TIME_IN_DAYS auf Kontoebene auf 0 gesetzt ist, führen Sie die Anweisungen im zweiten Beispiel unten aus, um alle transienten Tabellen aufzulisten, bei denen DATA_RETENTION_TIME_IN_DAYS auf 1 gesetzt ist.

  • Bevor Sie den Parameter für eine Tabelle deaktivieren, empfehlen wir Ihnen, zu überprüfen, ob Time Travel für diese Tabelle deaktiviert werden muss.

show tables in account;
set
  table_qid = (
    select
      last_query_id()
);

show schemas in account;
set
  schema_qid = (
    select
      last_query_id()
);

show databases in account;
set
  database_qid = (
    select
      last_query_id()
);

with table_v as (
    select
      "database_name" as database_name,
      "schema_name" as schema_name,
      "name" as table_name,
      "kind" = 'TRANSIENT' as is_transient,
      "retention_time" as table_retention_time
    from
      table(result_scan($table_qid))
  ),
  schema_v as (
    select
      "name" as schema_name,
      iff(
        try_to_number("retention_time") is null,
        0,
        try_to_number("retention_time")
      ) as schema_retention_time
    from
      table(result_scan($schema_qid))
  ),
  database_v as (
    select
      "name" as database_name,
      "retention_time" as database_retention_time
    from
      table(result_scan($database_qid))
  )
select
  *
from
  table_v
  left join schema_v using (schema_name)
  left join database_v using (database_name)
where
  is_transient
  and table_retention_time = 1
  and (
    schema_retention_time = 0
    or database_retention_time = 0
  );
Copy

Wenn DATA_RETENTION_TIME_IN_DAYS auf Kontoebene auf 0 gesetzt ist, führen Sie die folgenden Anweisungen aus, um alle transienten Tabellen aufzulisten, bei denen DATA_RETENTION_TIME_IN_DAYS auf 1 gesetzt ist:

-- Verify account level DATA_RETENTION_TIME_IN_DAYS setting is 0
show parameters like 'DATA_RETENTION_TIME_IN_DAYS' in account;

show tables in account;

select
  "database_name" as database_name,
  "schema_name" as schema_name,
  "name" as table_name,
  "kind" = 'TRANSIENT' as is_transient,
  "retention_time" as table_retention_time
from
  table(result_scan(last_query_id()))
where
  is_transient
  and table_retention_time = 1;
Copy

Um den Parameter DATA_RETENTION_TIME_IN_DAYS für eine bestehende transiente Tabelle zu deaktivieren, sodass sie die Parametereinstellung von einem übergeordneten Objekt erben kann, verwenden Sie ALTER TABLE:

ALTER TABLE <table_name> UNSET DATA_RETENTION_TIME_IN_DAYS;
Copy

Um die für eine Tabelle eingestellte Datenaufbewahrungsdauer zu überprüfen, verwenden Sie SHOW TABLES:

SHOW TABLES LIKE '<table_name>';
Copy

SQL-Änderungen – Befehle und Funktionen

Befehl SHOW ORGANIZATION ACCOUNTS: Neue Spalte

Der Ausgabe des Befehls SHOW TAGS wurden die folgenden Spalten hinzugefügt:

Spaltenname

Datentyp

Beschreibung

OLD_ACCOUNT_URL

TEXT

Die vorherige Konto-URL für ein bestimmtes Konto.

Befehl SHOW PROCEDURES: Ausgabe enthält sowohl benutzerdefinierte als auch integrierte gespeicherte Prozeduren

Snowflake unterstützt die Erstellung von gespeicherten Prozeduren als Objekte auf Schemaebene in jeder Datenbank eines Kontos. Der SHOW PROCEDURES-Befehl gibt Informationen über diese vom Benutzer erstellten gespeicherten Prozeduren zurück.

Mit der Einführung der Datenklassifizierung bietet Snowflake nun auch integrierte gespeicherte Prozeduren, die ähnlich wie integrierte Funktionen als globale Objekte aufgerufen werden können.

Zur Unterstützung von integrierten gespeicherten Prozeduren wurde die Ausgabe des SHOW PROCEDURES-Befehls wie folgt geändert:

Bisher:

Der Befehl gab nur die benutzerdefinierten gespeicherten Prozeduren zurück, die zur aktuellen oder angegebenen Datenbank bzw. zum aktuellen oder angegebenen Schema (oder zum gesamten Konto) gehörten.

Um die von Snowflake bereitgestellten, integrierten gespeicherten Prozeduren anzuzeigen, können Sie in dem Befehl das Schlüsselwort BUILTIN verwenden. Beispiel:

SHOW BUILTIN PROCEDURES;
Copy

Beachten Sie jedoch, dass Snowflake nur eine einzige integrierte gespeicherte Prozedur bereitstellt: ASSOCIATE_SEMANTIC_CATEGORY_TAGS.

Jetzt:

Die Funktion gibt alle gespeicherten Prozeduren zurück, sowohl die benutzerdefinierten als auch die integrierten gespeicherten Prozeduren.

Dadurch ist der Befehl SHOW PROCEDURES mit dem Befehl SHOW FUNCTIONS konsistent.

Die Änderung betrifft nicht die Schlüsselwörter BUILTIN und USER, die verwendet werden können, um explizit entweder integrierte oder benutzerdefinierte gespeicherte Prozeduren zurückzugeben. Beispiel:

SHOW BUILTIN PROCEDURES;

SHOW USER PROCEDURES;
Copy

Funktion SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS: Änderung der Basis von Schätzungen

SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS ist eine Systemfunktion, die Sie aufrufen können, um die geschätzten Kosten für das Hinzufügen der Suchoptimierung zu einer Tabelle zu ermitteln.

Diese Funktion wurde dahingehend geändert, dass eine kleine Stichprobe als Basis für die Schätzung der Kosten verwendet wird. Mit dieser Änderung kann die Funktion genauere Kostenschätzungen abgeben. Die Änderung wirkt sich jedoch auf die Nutzung des Warehouses und die Ausgabe der Funktion aus und kann die Leistung der Funktion beeinträchtigen, wie unten beschrieben:

Bisher:

Die Funktion verwendete ein einfaches Modell zur Kostenschätzung. Die Verwendung eines einfachen Modells zur Kostenschätzung hatte folgende Auswirkungen:

  • Zum Zeitpunkt des Funktionsaufrufs musste kein Warehouse verwendet werden.

  • Da für die Funktion kein Warehouse verwendet wurde, wurde Ihnen für diese Funktion auch keine Warehouse-Nutzung in Rechnung gestellt.

  • Ausführung und Rückgabe des Ergebnisses der Funktion erfolgte innerhalb von Sekunden.

  • Die zurückgegebenen JSON-Ausgabe für die Objekte BuildCosts und StorageCosts im Array costPositions hatte folgende Eigenschaften:

    • Es gab kein comment-Feld.

    • Das Feld computationMethod war auf "EstimatedUpperBound" gesetzt.

Jetzt:

Die Funktion nimmt nun eine kleine Stichprobe von Daten aus der angegebenen Tabelle, erstellt einen temporären Suchzugriffspfad, analysiert die Kosten des Prozesses und extrapoliert die Ergebnisse, um die Kosten für die gesamte Tabelle zu schätzen. Die Verwendung einer Stichprobe zur Kostenschätzung hatte folgende Auswirkungen:

  • Zum Aufrufen der Funktion ist ein aktives Warehouse erforderlich. Wenn derzeit kein aktives Warehouse vorhanden ist, gibt die Funktion die folgende Meldung aus:

    No active warehouse selected in the current session.

    Wählen Sie mit dem Befehl USE WAREHOUSE ein aktives Warehouse aus. Um diese Funktion auszuführen, können Sie ein X-Small-Warehouse verwenden. Die Größe des Warehouses hat keinen Einfluss auf die Geschwindigkeit und Leistung dieser Funktion.

  • Da die Funktion ein Warehouse verwendet, wird Ihnen nun die Warehouse-Nutzung für diese Funktion in Rechnung gestellt.

  • Die Ausführung der Funktion und die Rückgabe der Ergebnisse dauern nun etwas länger (im Bereich von 20 Sekunden bis 10 Minuten). Wie bereits erwähnt, führt die Verwendung einer größeren Warehouse-Größe nicht zu einer schnelleren Ausführung dieser Funktion.

  • Die zurückgegebenen JSON-Ausgabe für die Objekte BuildCosts und StorageCosts im Array costPositions hatte folgende Eigenschaften:

    • Das Feld comment wird auf "estimated via sampling" gesetzt.

    • Das Feld computationMethod wird auf "Estimated" gesetzt.

SQL-Änderungen – Nutzungsansichten & Information Schema-Ansichten/Tabellenfunktionen

Ansicht LOGIN_HISTORY (Account Usage): Neue Spalte

Der Ansicht ACCOUNT_USAGE.LOGIN_HISTORY wurde folgende neue Spalte hinzugefügt:

Spaltenname

Datentyp

Beschreibung

CONNECTION

TEXT

Dieses Snowflake-Objekt repräsentiert eine Verbindungs-URL, für die über mehrere Konten hinweg ein Failover ausgeführt werden kann, um Geschäftskontinuität und Notfallwiederherstellung zu ermöglichen. In dieser Spalte wird der Name der vom Client verwendeten Verbindung angezeigt. Wenn ein Client keine Verbindungs-URL verwendet, ist dieses Feld leer.

Ansicht QUERY_HISTORY (Account Usage): Ausgabe konsistent mit Funktion QUERY_HISTORY

Die Werte für eingehende und ausgehende Datentransfer-Bytes sind nicht konsistent zwischen:

Die Account Usage-Ansichten enthalten eingehende und ausgehende Datentransfer-Bytes, wenn der Wert der Datentransfer-Cloudwert (INBOUND_DATA_TRANSFER_CLOUD bzw. OUTBOUND_DATA_TRANSFER_CLOUD) „Null“ ist.

Diese Ansichten haben sich wie folgt geändert:

Bisher:

Für die QUERY_HISTORY-Ansichten in ACCOUNT_USAGE und READER_ACCOUNT_USAGE galt Folgendes:

  • Spalte INBOUND_DATA_TRANSFER_BYTES enthält Datentransfer-Bytes, wenn der INBOUND_DATA_TRANSFER_CLOUD-Wert „Null“ ist.

  • Spalte OUTBOUND_DATA_TRANSFER_BYTES enthält Datentransfer-Bytes, wenn der OUTBOUND_DATA_TRANSFER_CLOUD-Wert „Null“ ist.

Jetzt:

Die Ansichten sind jetzt mit der Ausgabe der Tabellenfunktion INFORMATION_SCHEMA.QUERY_HISTORY konsistent.

Die Spalten INBOUND_DATA_TRANSFER_BYTES und OUTBOUND_DATA_TRANSFER_BYTES enthalten keine Bytes aus Dateitransfers, wenn der zugehörige INBOUND_DATA_TRANSFER_CLOUD- oder OUTBOUND_DATA_TRANSFER_CLOUD-Wert „Null“ ist.

Änderungen bei Datenpipelines

Befehle DESCRIBE STREAM / SHOW STREAM: Neue Spalten in Ausgabe

Die Ausgabe der Befehle DESCRIBE STREAM und SHOW STREAMS enthält jetzt die folgenden zusätzlichen Spalten:

Spaltenname

Datentyp

Beschreibung

SOURCE_TYPE

TEXT

Das Quellobjekt des Streams: Tabelle, Ansicht, Verzeichnistabelle oder externe Tabelle.

BASE_TABLES

TEXT

Wenn der Stream auf einer Ansicht erstellt wurde, zeigt diese Spalte die der Ansicht zugrunde liegenden Tabellen.

Die neuen Spalten wurden zwischen den bestehenden Spalten TABLE_NAME und TYPE eingefügt.

Änderungen bei Data Lakes

Verzeichnistabellen: Metadaten werden einmalig bei Erstellen des Stagingbereichs automatisch aktualisiert

Wenn Sie einen Stagingbereich erstellen, der eine Verzeichnistabelle enthält, werden die Metadaten der Verzeichnistabelle jetzt automatisch einmalig und sofort aktualisiert. Durch das Aktualisieren der Metadaten der Verzeichnistabelle werden die Metadaten mit der aktuellen Liste der Datendateien im angegebenen Stagingbereichspfad synchronisiert.

Um bestehende Datendateien in den Metadaten der Verzeichnistabelle zu registrieren, mussten die Benutzer bisher nach dem Erstellen des Stagingbereichs eine ALTER STAGE … REFRESH-Anweisung ausführen.

Diese Verbesserung wird durch den neuen Parameter REFRESH_ON_CREATE des Befehls CREATE STAGE implementiert. Wenn REFRESH_ON_CREATE = TRUE (Standardwert) gilt, aktualisiert Snowflake die Metadaten der Verzeichnistabelle automatisch ein einziges Mal beim Erstellen des Stagingbereichs.