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

Ein geklontes Objekt behält keine der für das Quellobjekt erteilten Berechtigungen (d. h. Klone haben nicht automatisch die gleichen Berechtigungen wie ihre Quellen). Ein Systemadministrator oder der Eigentümer des geklonten Objekts muss dem neu erstellten Klon explizit alle erforderlichen Berechtigungen erteilen.

Wenn es sich bei dem Quellobjekt jedoch um eine Datenbank oder ein Schema für untergeordnete Objekte (Tabellen, Ansichten usw.) 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 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. Dies führt zu folgendem Verhalten:

  • Wenn die Zieltabelle in der COPY-Anweisung der Pipe-Definition vollständig qualifiziert ist (in Form von Datenbankname.Schemaname.Tabellenname oder Schemaname.Tabellenname), kann dies dazu führen, dass von jeder Pipe doppelten Daten in die Zieltabelle der Quelldatenbank oder des Quellschema geladen werden.

  • Wenn die Zieltabelle in der Pipe-Definition nicht vollständig qualifiziert ist, werden die Daten in die Zieltabelle (z. B. mytable) in den Quell- und Klon-Datenbanken/Schemas geladen.

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.

Wenn ein Pipeobjekt seit dem in der AT | BEFORE-Klausel angegebenen Zeitpunkt neu erstellt (unter Verwendung der CREATE OR REPLACE PIPE-Syntax) oder gelöscht wurde, schlägt die Klonoperation fehl.

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.