Interaktion von Tags mit Snowflake-Features¶
Replikation¶
Tags und deren Zuweisungen können von einem Quellkonto in ein Zielkonto repliziert werden.
Tag-Zuweisungen können nach der ersten Replikation vom Quellkonto im Zielkonto nicht mehr geändert werden. So ist beispielsweise das Setzen eines Tags auf eine Sekundärdatenbank (d. h. eine replizierte Datenbank) nicht zulässig. Um Tag-Zuweisungen im Zielkonto zu ändern, ändern Sie diese im Quellkonto, und replizieren Sie sie dann in das Zielkonto.
Bei der Datenbankreplikation kann die Replikationsoperation fehlschlagen, wenn eine der folgenden Bedingungen erfüllt ist:
Die Primärdatenbank befindet sich in einem Enterprise-Konto (oder höher) und enthält ein Tag, aber mindestens eines der zur Replikation genehmigten Konten befindet sich in einer niedrigeren Edition.
Ein in der Primärdatenbank enthaltenes Objekt hat eine verwaiste Referenz auf ein Tag in einer anderen Datenbank.
Um Fehler durch verwaiste Referenzen zu vermeiden, replizieren Sie die Datenbank und die Objekte auf Kontoebene mit einer Replikations- oder Failover-Gruppe. Stellen Sie sicher, dass die Replikationsgruppe Folgendes enthält:
Die Datenbank, die die Tags in der Eigenschaft
ALLOWED_DATABASESenthält.Andere Objekte auf Kontoebene, die ein Tag in der Eigenschaft
OBJECT_TYPEShaben (z. B.ROLES,WAREHOUSES).Weitere Informationen dazu finden Sie unter CREATE REPLICATION GROUP und CREATE FAILOVER GROUP.
Bemerkung
Bei Verwendung von Replikations-/Failover-Gruppen oder Datenbankreplikation:
Failover/Failback-Features sind nur für Snowflake-Konten mit Business Critical Edition (oder höher) verfügbar.
Weitere Informationen dazu finden Sie unter Einführung in Replikation und Failover über mehrere Konten.
Wenn Sie die
IGNORE EDITION CHECK-Klausel für die Datenbankreplikation in einer ALTER DATABASE-Anweisung oder in einer CREATE OR ALTER-Anweisung für eine Replikations- oder Failover-Gruppe angeben, kann eine Tag-Replikation erfolgen, wenn das Zielkonto eine niedrigere Edition als Business Critical aufweist.Weitere Informationen dazu finden Sie in der Klauselbeschreibung unter dem jeweiligen Befehl.
Klonen¶
Tag-Zuordnungen im Quellobjekt (z. B. Tabelle) bleiben in den geklonten Objekten erhalten.
Für eine Datenbank oder ein Schema:
Die in dieser Datenbank oder diesem Schema gespeicherten Tags werden ebenfalls geklont.
Wenn eine Datenbank oder ein Schema geklont wird, werden die Tags, die sich in diesem Schema oder dieser Datenbank befinden, ebenfalls geklont.
Wenn eine Tabelle oder Ansicht im Quellschema bzw. in der Quelldatenbank vorhanden ist und Verweise auf Tags in demselben Schema oder derselben Datenbank hat, wird die geklonte Tabelle oder Ansicht dem entsprechenden geklonten Tag (im Zielschema bzw. in der Zieldatenbank) zugeordnet und nicht dem Tag im Quellschema bzw. der Quelldatenbank.
Datenfreigabe (Data Sharing)¶
Wenn die freigegebene Ansicht und das freigegebene Tag in verschiedenen Datenbanken vorhanden sind, erteilen Sie der Freigabe die REFERENCE_USAGE-Berechtigung für die Datenbank, die das Tag enthält. Weitere Informationen dazu finden Sie unter Freigabe von Daten aus mehreren Datenbanken.
Für das Data Sharing-Verbraucherkonto gilt Folgendes:
Die Ausführung des Befehls SHOW TAGS gibt das gemeinsame Tag zurück, sofern die Rolle, die den Befehl SHOW TAGS ausführt, über die Berechtigung USAGE für das Schema verfügt, das das gemeinsame Tag enthält.
Wenn der Anbieter der Freigabe oder einer Rolle der freigegebenen Datenbank die READ-Berechtigung für das Tag erteilt, kann der Verbraucher die Tag-Zuweisungen für das freigegebene Tag anzeigen. Informationen finden Sie unter Referenzen für freigegebene Tags.
Wenn ein Tag des Data Sharing-Anbieterkontos einer freigegebenen Tabelle zugewiesen ist, kann der Data Sharing-Verbraucher die Funktion SYSTEM$GET_TAG oder die Information Schema-Funktion TAG_REFERENCES aufrufen, um die Tag-Zuweisung anzuzeigen.