Hinweise zum Klonen

Unter diesem Thema werden wichtige Hinweise zum Klonen von Objekten in Snowflake, insbesondere von Datenbanken, Schemas und nicht temporäre Tabellen gegeben. Faktoren wie DDL- und DML-Transaktionen (auf dem Quellobjekt), Time Travel und Datenaufbewahrungsfristen können Auswirkungen auf den Objektklon haben.

Unter diesem Thema:

Zugriffssteuerungsrechte für geklonte Objekte

Wenn das Quellobjekt eine Datenbank oder ein Schema ist, erbt der Klon alle Berechtigungen, die allen Klonen der im Quellobjekt enthaltenen untergeordneten Objekte erteilt wurden:

  • Zu den enthaltenen Objekten für Datenbanken gehören Schemas, Tabellen, Ansichten usw.

  • Zu den enthaltenen Objekten für Schemas gehören Tabellen, Ansichten usw.

Beachten Sie, dass der Klon des Containers selbst (Datenbank oder Schema) nicht die Berechtigungen erbt, die für den Quellcontainer erteilt wurden.

Bei den meisten Objekten können mit CREATE <Objekt> … CLONE-Anweisungen keine Berechtigungszuweisungen zu dem Quellobjekt in den Objektklon kopiert werden. Mit CREATE <Objekt>-Befehlen, die die COPY GRANTS-Klausel unterstützen (z. B. CREATE TABLE, CREATE VIEW), können Sie jedoch optional Berechtigungszuweisungen zu Objektklonen kopieren. Beispielsweise unterstützt die CREATE TABLE … CLONE-Befehlssyntax den Parameter COPY GRANTS. Wenn der Parameter COPY GRANTS in einer CREATE TABLE-Anweisung angegeben wird, kopiert die Erstellungsoperation alle Berechtigungen, mit Ausnahme von OWNERSHIP, von der Quelltabelle in die neue Tabelle. Das gleiche Verhalten gilt für andere CREATE-Befehle, die die COPY GRANTS-Klausel unterstützen.

In allen anderen Fällen müssen Sie dem neu erstellten Klon alle erforderlichen Berechtigungen erteilen (mit GRANT <Berechtigungen>).

Klonen und Snowflake-Objekte

In diesem Abschnitt werden spezielle Überlegungen zum Klonen in Bezug auf bestimmte Snowflake-Objekte beschrieben.

Klonen und Objektparameter

Geklonte Objekte erben alle Objektparameter, die für das Quellobjekt zu dem Zeitpunkt festgelegt waren, als es geklont wurde. Wenn ein Objektparameter für einen Objektcontainer (d. h. Konto, Datenbank, Schema) festgelegt werden kann und wenn der Objektparameter nicht explizit für das Quellobjekt festgelegt ist, erbt der Objektklon den Standardparameterwert oder den auf der untersten Ebene überschriebenen Wert. Weitere Informationen zu Objektparametern finden Sie unter Parameter.

Klonen und Standardsequenzen

In einer Tabelle kann eine Spalte auf eine Sequenz verweisen, die Standardwerte generiert. Wenn eine Tabelle geklont wird, verweist die geklonte Tabelle auf die Quell- oder geklonte Sequenz:

  • Wenn die Datenbank oder das Schema, das sowohl die Tabelle als auch die Sequenz enthält, geklont wird, verweist die geklonte Tabelle auf die geklonte Sequenz.

  • Andernfalls verweist die geklonte Tabelle auf die Quellsequenz.

    Wenn die Sequenz z. B. in einer anderen Datenbank oder einem anderen Schema definiert ist, verweist die geklonte Tabelle auf die Quellsequenz. Wenn Sie aber nur die Tabelle selbst klonen, verweist die geklonte Tabelle auf die Quellsequenz.

    Wenn Sie nicht möchten, dass die neue Tabelle weiterhin die Quellsequenz verwendet, führen Sie folgenden Befehl aus:

    ALTER TABLE <table_name> ALTER COLUMN <column_name> SET DEFAULT <new_sequence>.nextval;
    
    Copy

Klonen und Fremdschlüsseleinschränkungen

Eine Tabelle kann eine Fremdschlüsseleinschränkung haben, die auf eine Tabelle verweist, die den Primärschlüssel enthält. Wenn eine Tabelle mit einer Fremdschlüsseleinschränkung geklont wird, verweist die geklonte Tabelle auf die Quell- oder geklonte Tabelle, die den Primärschlüssel enthält:

  • Wenn die Datenbank oder das Schema, das beide Tabellen enthält, geklont wird, verweist die geklonte Tabelle mit dem Fremdschlüssel auf den Primärschlüssel in der anderen geklonten Tabelle.

  • Wenn sich die Tabellen in getrennten Datenbanken oder Schemas befinden, verweist die geklonte Tabelle auf den Primärschlüssel in der Quelltabelle.

Klonen und Gruppierungsschlüssel

Eine Tabelle kann eine Teilmenge von Spalten haben, die als Gruppierungsschlüssel bezeichnet werden, um ähnliche Zeilen in derselben Mikropartition zusammenzulegen. Wenn eine Tabelle mit einem Gruppierungsschlüssel geklont wird, wird die neue Tabelle mit einem Gruppierungsschlüssel erstellt. Standardmäßig wird Automatic Clustering für die neue Tabelle angehalten. Um das automatische Clustering für die neue Tabelle wieder aufzunehmen, führen Sie den folgenden Befehl aus:

ALTER TABLE <name> RESUME RECLUSTER
Copy

Klonen und Stagingbereiche

Einzelne externe benannte Stagingbereiche können geklont werden. Ein externer Stagingbereich referenziert einen Bucket oder Container im externen Cloud-Speicher. Das Klonen eines externen Stagingbereichs hat keine Auswirkungen auf den referenzierten Cloudspeicher.

Interne (d. h. Snowflake) benannte Stagingbereiche können nicht geklont werden.

Beim Klonen einer Datenbank oder eines Schemas:

  • Es werden alle externen benannten Stagingbereiche geklont, die beim Starten der Klonoperation in der Quelle vorhanden waren.

  • Es werden Tabellen geklont, d. h. der zu jeder Tabelle gehörende interne Stagingbereich wird ebenfalls geklont. Alle Datendateien, die in der Quelldatenbank oder dem Quellschema in einem Tabellen-Stagingbereich vorhanden waren, werden nicht in den Klon kopiert (d. h. die geklonten Tabellen-Stagingbereiche sind leer).

  • Interne benannte Stagingbereiche werden nicht geklont.

Klonen und Pipes

Wenn eine Datenbank oder ein Schema geklont wird, werden alle im Quellcontainer enthaltenen Pipes, die auf einen internen (d. h. Snowflake) Stagingbereich verweisen, nicht geklont.

Alle Pipes, die auf einen externen Stagingbereich verweisen, werden jedoch geklont. Dazu gehören alle Pipeobjekte, bei denen der Parameter INTEGRATION gesetzt ist. Dieser Parameter verweist auf eine Benachrichtigungsintegration, um das automatische Testen von Snowpipe beim Laden von Daten aus Dateien in Google Cloud Storage oder Microsoft Azure-Blobspeicher zu aktivieren.

Wenn eine Datendatei in einem Stagingbereich (z. B. in einem Blobspeichercontainer) erstellt wird, wird eine Kopie der Benachrichtigung an jede Pipe gesendet, die mit dem Speicherort des Stagingbereichs übereinstimmt. Dies führt zu folgendem Verhalten:

  • Wenn eine Tabelle in der COPY-Anweisung der Pipedefinition vollqualifiziert ist (in der Form db_name.schema_name.table_name oder schema_name.table_name), dann lädt Snowpipe Duplikatdaten in die Quelltabelle (d. h. in database.schema.table der COPY-Anweisung) jeder Pipe.

  • Wenn eine Tabelle in der Pipedefinition nicht vollqualifiziert ist, lädt Snowpipe die Daten in die Tabelle (z. B. mytable) der Quell- und geklonten Datenbanken/Schemas.

Der Standardstatus eines Pipeklons ist wie folgt:

  • Bei AUTO_INGEST = FALSE wird eine geklonte Pipe standardmäßig angehalten.

  • Bei AUTO_INGEST = TRUE wird eine geklonte Pipe auf den Status STOPPED_CLONED gesetzt. In diesem Zustand sammeln Pipes keine Ereignisbenachrichtigungen, wenn Dateien im Stagingbereich bereitgestellt werden. Wenn eine Pipe explizit fortgesetzt wird, verarbeitet sie nur Datendateien, die aufgrund neuer Ereignisbenachrichtigungen ausgelöst wurden.

Ein Pipeklon in einem der beiden Zustände kann durch Ausführen einer ALTER PIPE … RESUME-Anweisung fortgesetzt werden:

Klonen und Streams

Wenn eine Datenbank oder ein Schema geklont wird, die bzw. das eine Quelltabelle und einen Stream enthält, kann derzeit auf keinen der nicht verbrauchten Datensätze in den Streams (des Klons) zugegriffen werden. Dieses Verhalten ist konsistent mit Time Travel für Tabellen. Wenn eine Tabelle geklont wird, beginnen die historischen Daten für den Tabellenklon zu dem Zeitpunkt, an dem der Klon erstellt wurde.

Klonen und Aufgaben

Wenn eine Datenbank oder ein Schema mit Aufgaben geklont wird, werden die Aufgaben im Klon standardmäßig angehalten. Die Aufgaben können einzeln fortgesetzt werden (mit ALTER TASK … RESUME).

Klonen und Alerts

Wenn eine Datenbank oder ein Schema mit Alerts geklont wird, werden die Alerts im Klon standardmäßig unterbrochen.

Um einen unterbrochenen Alert fortzusetzen, können Sie den Befehl ALTER ALERT … RESUME verwenden.

Klonen und Governance-Objekte

Richtlinien für Maskierung und Zeilenzugriff:

Der folgende Ansatz hilft, Daten vor Benutzern mit SELECT-Berechtigung für die Tabelle oder Ansicht zu schützen, wenn diese auf ein geklontes Objekt zugreifen:

  • Das Klonen eines einzelnen Richtlinienobjekts wird nicht unterstützt.

  • Das Klonen eines Schemas führt zum Klonen aller Richtlinien innerhalb des Schemas.

  • Einer geklonten Tabelle sind dieselben Richtlinien zugeordnet wie der Quelltabelle. Das heißt, wenn eine Richtlinie für die Basistabelle oder deren Spalten festgelegt ist, wird die Richtlinie an die geklonte Tabelle oder deren Spalten angehängt.

    • Wenn eine Tabelle im Kontext des Klonens ihres übergeordneten Schemas geklont wird und die Quelltabelle einen Verweis auf eine Richtlinie im selben übergeordneten Schema enthält (d. h. eine lokale Referenz), dann enthält auch die geklonte Tabelle einen Verweis auf die geklonte Richtlinie.

    • Wenn die Quelltabelle auf eine Richtlinie in einem anderen Schema verweist (d. h. eine Fremdreferenz), dann behält die geklonte Tabelle die Fremdreferenz bei.

Weitere Informationen dazu finden Sie unter CREATE <Objekt> … CLONE.

Siehe auch:

Tags:

  • 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.

Tag-basierte Maskierungsrichtlinien:

Bei einer Tag-basierten Maskierungsrichtlinie, bei der das Tag in einem anderen Schema als Maskierungsrichtlinie und Tabelle gespeichert ist, führt das Klonen des Schemas, das die Maskierungsrichtlinie und die Tabelle enthält, dazu, dass die geklonte Tabelle durch die Maskierungsrichtlinie im Quellschema und nicht durch das geklonte Schema geschützt wird.

Bei einer Tag-basierten Maskierungsrichtlinie, bei der das Tag, die Maskierungsrichtlinie und die Tabelle alle in demselben Schema vorhanden sind, führt das Klonen des Schemas jedoch dazu, dass die Tabelle durch die Maskierungsrichtlinie im geklonten Schema und nicht im Quellschema geschützt wird.

Wenn die Tabelle geklont oder in ein anderes Schema oder eine andere Datenbank verschoben wird und ursprünglich durch eine Tag-basierte Maskierungsrichtlinie auf dem Schema oder der Datenbank geschützt war, wird die Tabelle nicht durch die Tag-basierte Maskierungsrichtlinie auf Quellschema oder Quelldatenbank geschützt. Die Tabelle ist durch die auf dem Zielschema oder der Zieldatenbank festgelegte Tag-basierte Maskierungsrichtlinie geschützt, wenn auf Zielschema oder Zieldatenbank eine Tag-basierte Maskierungsrichtlinie festgelegt ist.

Klonen und Datenbankrollen

Sie können eine Datenbankrolle mit dem Befehl CREATE DATABASE ROLE … CLONE klonen, wenn die Datenbankrolle noch nicht in der Zieldatenbank vorhanden ist. Weitere Details dazu finden Sie unter CREATE <Objekt> … CLONE.

Klonen und Java-UDFs

Eine Java-UDF kann geklont werden, wenn die Datenbank oder das Schema, das die Java-UDF enthält, geklont wird. Um geklont zu werden, muss die Java-UDF bestimmte Bedingungen erfüllen. Weitere Informationen dazu finden Sie unter Einschränkungen beim Klonen.

Auswirkungen von DDL auf das Klonen

Klonen ist schnell, aber nicht unmittelbar, insbesondere bei großen Objekten (z. B. Tabellen). Wenn also DDL-Anweisungen auf Quellobjekten ausgeführt werden (z. B. Tabellen in einem Schema umbenennen), während die Klon-Operation ausgeführt wird, werden die Änderungen möglicherweise nicht im Klon dargestellt. Dies liegt daran, dass DDL-Anweisungen atomar sind und nicht Teil von Transaktionen mit mehreren Anweisungen.

Außerdem zeichnet Snowflake nicht auf, welche Objektnamen beim Start der Klon-Operation vorhanden waren und welche Namen sich geändert haben. Daher konkurrieren DDL-Anweisungen, mit denen untergeordnete Quellobjekte umbenannt (oder gelöscht und neu erstellt) werden, mit allen laufenden Klonoperationen und können Namenskonflikte verursachen.

Im folgenden Beispiel wird die Tabelle t_sales gelöscht, und eine andere Tabelle wird geändert und erhält den gleichen Namen wie die gelöschte Tabelle, während die übergeordnete Datenbank geklont wird, was zu einem Fehler führt:

CREATE OR REPLACE DATABASE staging_sales CLONE sales;

DROP TABLE sales.public.t_sales;

ALTER TABLE sales.public.t_sales_20170522 RENAME TO sales.public.t_sales;

002002 (42710): None: SQL compilation error: Object 'T_SALES' already exists.
Copy

Tipp

Um während einer Klonoperation Konflikte bei der Namensauflösung zu vermeiden, empfehlen wir, Objekte erst dann in einen Namen umzubenennen, der zuvor von einem gelöschten Objekt verwendet wurde, wenn die Klonoperation abgeschlossen ist.

Auswirkungen von DML und Datenaufbewahrung auf das Klonen

Der Datenaufbewahrungsfrist gibt die Anzahl der Tage an, für die Snowflake historische Daten zu einem Objekt zur Durchführung von Time Travel-Aktionen speichert. Da die für Time Travel aufbewahrten Daten Speicherkosten auf Tabellenebene verursachen, setzen einige Benutzer diesen Parameter für einige Tabellen auf 0, wodurch die Datenaufbewahrung für diese Tabellen deaktiviert wird (d. h. wenn der Wert auf 0 gesetzt wird, werden die für DML-Transaktionen aufbewahrten Time Travel-Daten bereinigt, wodurch nur geringe zusätzliche Speicherkosten anfallen).

Klonoperationen erfordern Zeit, insbesondere bei großen Tabellen. Während dieses Zeitraums können DML-Transaktionen die Daten einer Quelltabelle ändern. Anschließend versucht Snowflake, die Tabellendaten so zu klonen, wie sie zu Beginn der Operation existierten. Wenn jedoch Daten von DML-Transaktionen bereinigt werden, die während des Klonens auftreten (weil die Aufbewahrungsdauer für die Tabelle 0 ist), sind diese Daten nicht verfügbar, um die Operation abzuschließen, was zu einem Fehler ähnlich dem folgenden führt:

ProgrammingError occured: "000707 (02000): None: Data is not available." with query id None
Copy

Tipp

Als Problemumgehung empfehlen wir beim Klonen eines Objekts eine der folgenden Best Practices:

  • Unterlassen Sie es nach Möglichkeit, DML-Transaktionen auf dem Quellobjekt (oder einem seiner Unterobjekte) auszuführen, bis die Klonoperation abgeschlossen ist.

  • Wenn dies nicht möglich ist, setzen Sie vor Beginn des Klonens DATA_RETENTION_TIME_IN_DAYS=1 für alle Tabellen im Schema (oder in der Datenbank, wenn Sie die gesamte Datenbank klonen). Denken Sie nach Abschluss der Operation daran, den Parameterwert für diese Tabellen in der Quelle auf 0 zurückzusetzen, falls gewünscht.

    Sie können auch den Wert für die geklonten Tabellen auf 0 setzen (wenn Sie DML-Änderungen an den geklonten Tabellen vornehmen und keine zusätzlichen Speicherkosten für Time Travel auf den Tabellen verursachen möchten).

Klonen mit Time Travel (nur Datenbanken, Schemas, Tabellen, dynamische Tabellen und Streams)

In diesem Abschnitt werden Informationen bereitgestellt, wie mithilfe von Time Travel Objekte zu einem bestimmten Zeitpunkt in der Vergangenheit geklont werden können.

Klonen von historischen Objekten

Wenn das Quellobjekt zu dem in der AT | BEFORE-Klausel festgelegten Zeitpunkt nicht vorhanden war, wird ein Fehler zurückgegeben.

Im folgenden Beispiel versucht eine CREATE TABLE … CLONE-Anweisung die Quelltabelle an einem Zeitpunkt in der Vergangenheit (30 Minuten vorher) zu klonen, an dem diese nicht existiert hat:

CREATE TABLE t_sales (numeric integer) data_retention_time_in_days=1;

CREATE OR REPLACE TABLE sales.public.t_sales_20170522 CLONE sales.public.t_sales at(offset => -60*30);

002003 (02000): SQL compilation error:
Object 'SALES.PUBLIC.T_SALES' does not exist.
Copy

Jedes untergeordnete Objekt in einer geklonten Datenbank oder in einem geklonten Schema, das zum angegebenen Zeitpunkt nicht vorhanden war, wird nicht geklont.

Die Klonoperation schlägt in den folgenden Szenarios fehl:

  • Wenn die angegebene Time Travel-Zeit außerhalb der Aufbewahrungsdauer eines beliebigen aktuellen untergeordneten Objekts (z. B. einer Tabelle) der Entität liegt.

    Als Problemumgehung für untergeordnete Objekte, die aus Time Travel gelöscht wurden, verwenden Sie den Parameter IGNORE TABLES WITH INSUFFICIENT DATA RETENTION des Befehls CREATE <object> … CLONE. Weitere Informationen dazu finden Sie unter Untergeordnete Objekte und Datenaufbewahrungsdauer.

  • Wenn ein Pipeobjekt mit der Einstellung AUTO-INGEST = TRUE seit dem in der AT | BEFORE-Klausel angegebenen Zeitpunkt neu erstellt (mit der CREATE OR REPLACE PIPE-Syntax) oder gelöscht wurde. Diese Einschränkung gilt nicht für Pipeobjekte, die für die manuelle Snowpipe-Erfassung unter Verwendung der REST API (d. h. mit AUTO-INGEST = FALSE) erstellt wurden.

Untergeordnete Objekte und Datenaufbewahrungsdauer

Wenn ein untergeordnetes Objekt (z. B. eine Tabelle) eine kürzere Datenaufbewahrungsfrist hat als die Datenaufbewahrungsfrist für sein übergeordnetes Objekt (z. B. eine Datenbank oder ein Schema), werden die historischen Daten des untergeordneten Objekts aus Time Travel verschoben, bevor die historischen Daten des übergeordneten Objekts aus Time Travel verschoben werden.

Beispielsweise beträgt die Datenaufbewahrungsfrist für die Datenbank db1 sieben Tage und die Datenaufbewahrungsfrist für die Tabelle t1 in db1 einen Tag. Wenn Sie db1 mithilfe von Time Travel zu einem Zeitpunkt 12 Stunden in der Vergangenheit klonen, erstellt die Klonoperation erfolgreich einen Klon von db1, der die geklonte Tabelle t1 enthält.

Wenn Sie jedoch versuchen, db1 zu einem Zeitpunkt zu klonen, der zwei Tage in der Vergangenheit liegt, sind die historischen Daten für Tabelle t1 zu diesem Zeitpunkt nicht mehr in Time Travel verfügbar und die Klonoperation schlägt fehl.

Als Problemumgehung können Sie den Parameter IGNORE TABLES WITH INSUFFICIENT DATA RETENTION des Befehls CREATE <Objekt> … CLONE verwenden, um eine Datenbank oder ein Schema zu klonen. Der Parameter überspringt die Tabellen, für die in Time Travel zu dem für die Klonoperation angegebenen Zeitpunkt keine historischen Daten mehr zur Verfügung stehen.

Klonen von Metadaten historischer Objekte

Ein Objektklon erbt den Namen und die Struktur des Quellobjekts, das zum Zeitpunkt der Ausführung der CREATE <Objekt> … CLONE-Anweisung oder zu einem angegebenen Time Travel-Zeitpunkt in der Vergangenheit aktuell war. Ein Objektklon erbt alle anderen Metadaten, wie z. B. Kommentare oder Tabellen-Gruppierungsschlüssel, die zum Zeitpunkt der Ausführung der Anweisung im Quellobjekt aktuell sind, unabhängig davon, ob Time Travel verwendet wird.

Bemerkung

Wenn bei einer CREATE <Objekt> … CLONE-Anweisung keine AT- oder BEFORE-Klausel angegeben wurde, wird zur Sicherstellung eines konsistenten Verhaltens von aufwändigen Klonoperationen der Wert der AT-Klausel intern auf den Zeitstempel der Initiierung der Anweisung gesetzt.