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

Bei den meisten Snowflake-Objekten behält ein geklontes Objekt keine Berechtigungen, die für das Quellobjekt erteilt wurden. Das heißt, die Objektklone haben nicht automatisch die gleichen Berechtigungen wie ihre Quellobjekte. Der Eigentümer des geklonten Objekts oder eine Rolle mit der MANAGE GRANTS-Berechtigung muss dem neu erstellten Klon explizit alle erforderlichen Berechtigungen erteilen. Die Ausnahme sind Tabellen. Die CREATE TABLE … CLONE-Befehlssyntax unterstützt 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.

Wenn es sich bei dem Quellobjekt um eine Datenbank oder ein Schema für untergeordnete Objekte in der Quelle handelt, repliziert der Klon alle erteilten Berechtigungen für die entsprechenden untergeordneten Objekte:

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

Klonen und Snowflake-Objekte

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

Klonen und Objektparameter

Objektparameter werden auf Kontoebene festgelegt, können aber für einzelne Objekte überschrieben werden. Geklonte Objekte erben standardmäßig den auf Kontoebene eingestellten Parameterwert. Wenn ein Parameter explizit in einer Quelldatenbank, einem Schema oder einer Tabelle festgelegt ist, erbt der Objektklon den Überschreibungswert entsprechend der Vererbungshierarchie für den Parameter. 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;
    

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

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 Form von Datenbankname.Schemaname.Tabellenname oder Schemaname.Tabellenname), dann lädt Snowpipe Duplikatdaten in die Quelltabelle (d. h. in Datenbank.Schema.Tabelle 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).

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.

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 Parameter DATA_RETENTION_TIME_IN_DAYS 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

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

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.

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

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.

Zurück zum Anfang