Bundle 2022_06¶

Replikationsgruppen: Auf Datenbanken und Freigaben beschränkte Objekttypen für Konten, die keine Business Critical Edition sind¶

Das Feature „Kontoreplikation“ unterstützt die Replikation von Kontoobjekten wie Benutzern, Rollen, Datenbanken und Freigaben. Die vollständige Liste der unterstützten Objekttypen finden Sie unter Replizierte Objekte. Replikationsgruppen können beliebige oder alle unterstützten Objekttypen enthalten.

Dieses Verhalten hat sich wie folgt geändert:

Bisher

Alle für die Kontoreplikation unterstützten Objekttypen können in eine Replikationsgruppe aufgenommen werden.

Jetzt

Die Unterstützung von Objekttypen, die einer Replikationsgruppe für Konten hinzugefügt werden können, die keine Business Critical Edition (oder höher) haben, ist auf Datenbanken und Freigaben beschränkt.

Weitere Informationen zur Feature-Unterstützung je nach Edition finden Sie in der Tabelle zur Feature-Unterstützung für Kontoreplikation.

Fail-safe-Speicher: Fehlerbehebung für Grenzfälle (Corner Cases), die zu einer Unterfakturierung führen¶

Aufgrund eines internen Systemfehlers wurden bei einigen permanenten Tabellen die Bytes für den Fail-safe-Speicher nicht abgerechnet. Insbesondere, wenn eine transiente Tabelle als Klon einer permanenten Tabelle erstellt wird und die permanente Tabelle anschließend gelöscht wird, hat Snowflake den Fail-safe-Speicher der permanenten Tabelle nicht berechnet.

Die Abrechnung für Fail-safe wurde daher wie folgt geändert:

Bisher

Bei einigen permanenten Tabellen wurde die Fail-safe-Speicherung nicht in Rechnung gestellt.

Jetzt

Kunden wird der Fail-safe-Speicher aller permanenten Tabellen in Rechnung gestellt.

Befehle CREATE DATABASE und CREATE SCHEMA: Ergebnisse der OR REPLACE-Klausel führen zu verwaisten Referenzen zu Richtlinien¶

Das Verhalten der Befehle CREATE DATABASE und CREATE SCHEMA hat sich wie folgt geändert:

Bisher

Snowflake erlaubte die Ausführung der Befehle CREATE OR REPLACE DATABASE und CREATE OR REPLACE SCHEMA in der Datenbank oder dem Schema, die/das eine Maskierungsrichtlinie oder eine Zeilenzugriffsrichtlinie enthält, die ein Objekt in einer anderen Datenbank oder einem anderen Schema schützt. Beispiel:

• Die Maskierungsrichtlinie mit dem Namen db1.s1.p1 schützt die Spalte mit dem Namen db2.s1.t1.c1.

• Eine Zeilenzugriffsrichtlinie mit dem Namen db1.s1.p2 schützt eine Tabelle mit dem Namen db2.s1.t1.

Das Ergebnis war eine verwaiste Referenz, die dazu führte, dass alle Abfragen auf die Spalte oder das Objekt fehlschlugen.

Beachten Sie, dass dieses Verhalten auch für CLONE-Anweisungen wie CREATE OR REPLACE SCHEMA S1 CLONE S2; gilt.

Jetzt

Die Befehle CREATE OR REPLACE DATABASE und CREATE OR REPLACE SCHEMA schlagen fehl, wenn das Ergebnis eine verwaiste Referenz auf ein richtliniengeschütztes Objekt ist. Snowflake gibt eine der folgenden Fehlermeldungen aus:

• Für CREATE OR REPLACE DATABASE: Cannot drop database because: Policy '<db.schema.policy>' used by schema '<db.schema>' in another database

• Für CREATE OR REPLACE SCHEMA: Cannot drop schema because: Policy '<db.schema.policy>' used by another schema '<db.schema>'

Wenn eine der beiden Fehlermeldungen auftritt, fragen Sie die Account Usage-Ansicht POLICY_REFERENCES ab, verwenden Sie eine Rolle, um die Maskierungs- oder Zeilenzugriffsrichtlinie zu deaktivieren, und versuchen Sie dann die CREATE OR REPLACE-Anweisung erneut.

Beispiel:

1. Abfragen der Ansicht:

   • Schemaübergreifende Richtlinienreferenzen, die vor der Ersetzung entfernt werden müssen:

     select * from snowflake.account_usage.policy_references
     where policy_db=<policy_db> and
     policy_schema=<policy_schema_to_replace> and ref_schema_name != <policy_schema>;
     

     Copy

   • Datenbankübergreifende Richtlinienreferenzen, die vor der Ersetzung entfernt werden müssen:

     select * from snowflake.account_usage.policy_references
     where policy_db=<policy_db_to_replace>’ and ref_database_name != <policy_db>;
     

     Copy

2. Deaktivieren der Richtlinien:

   • Bei Maskierungsrichtlinien:

     alter table <table_name> modify column <col_name> unset masking policy;
     

     Copy

   • Bei Zeilenzugriffsrichtlinien:

     alter table <table_name> drop all row access policies;
     

     Copy

3. Wiederholen Sie den Befehl CREATE OR REPLACE.

Beachten Sie, dass Sie bei CLONE-Operationen die Richtlinienobjekte vor Ausführung der CLONE-Anweisungen in einer separaten Datenbank oder einem separaten Schema speichern sollten.

INFER_SCHEMA-Funktionen: Neue ORDER_ID-Spalte in der Ausgabe¶

Die Ausgabe der Funktion INFER_SCHEMA enthält nun eine neue Spalte ORDER_ID, die die Reihenfolge der Spalten in den Stagingdateien angibt.

Wenn Sie derzeit eine Tabelle erstellen, deren Spaltendefinitionen aus einer Menge von Stagingdateien abgeleitet sind (unter Verwendung von CREATE TABLE … USING TEMPLATE), ist die Reihenfolge der Spalten in der Tabelle zufällig. Während die Reihenfolge der Tabellenspalten für Snowflake keine Rolle spielt, kann dies zu Verwirrung führen, wenn Sie die Reihenfolge der Dateispalten mit der Reihenfolge der Tabellenspalten vergleichen. Mithilfe der neuen ORDER_ID-Spalte in der INFER_SCHEMA-Ausgabe können Sie sicherstellen, dass Tabellen, die mit dem ermittelten Schema erstellt wurden, die gleiche Spaltenreihenfolge haben.

Sie können das Schema einer beliebigen Datei mit INFER_SCHEMA abrufen, wie im folgenden Beispiel gezeigt. Die Ausgabe enthält eine neue Spalte ORDER_ID, nach der im Einzelschema-Szenario automatisch sortiert wird:

SELECT *
  FROM TABLE(
  INFER_SCHEMA(
  LOCATION=>'@***_****_STAGE/' , FILE_FORMAT=>'FFPARQUET'
  )
  );

Copy

Sie können mithilfe des aus Stagingdateien ermittelten Schemas auch eine Tabelle erstellen und die Spalten nach ORDER_ID sortieren, wie das folgende Beispiel zeigt:

CREATE OR REPLACE TABLE BIG_TABLE
  USING TEMPLATE (
  SELECT ARRAY_AGG(OBJECT_CONSTRUCT(*))
  WITHIN GROUP (ORDER BY ORDER_ID) // NEW
  FROM TABLE( INFER_SCHEMA(LOCATION=>'@***_****_STAGE/', FILE_FORMAT=>'FFPARQUET')
  )
  );

DESC TABLE BIG_TABLE;

Copy

Beachten Sie, dass die Sortierung der Spalten nach ORDER_ID nur gilt, wenn alle Stagingdateien ein Einzelschema gemeinsam verwenden. Wenn die Menge der bereitgestellten Staging-Datendateien mehrere Schemas mit gemeinsamen Spaltennamen enthält, kann die in der Spalte ORDER_ID dargestellte Reihenfolge möglicherweise mit keiner der Einzeldateien übereinstimmen.

Ansicht FUNCTIONS (Account Usage): Neue Spalten in der Ansicht¶

Die Ausgabe der Account Usage-Ansicht FUNCTIONS enthält jetzt die folgenden neuen Spalten: