Bundle 2022_02¶

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.

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

Befehl SHOW ORGANIZATION ACCOUNTS: Neue Spalte¶

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

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.

Ansicht LOGIN_HISTORY (Account Usage): Neue Spalte¶

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

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

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

• Ansichten ACCOUNT_USAGE.QUERY_HISTORY und READER_ACCOUNT_USAGE.QUERY_HISTORY

• Ausgabe der Tabellenfunktion INFORMATION_SCHEMA.QUERY_HISTORY

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.

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:

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

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.