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

Die folgenden Regeln gelten für das Klonen von Stagingbereichen oder von Objekten, die Stagingbereiche enthalten (d. h. Datenbanken und Schemas):

  • Einzelne extern benannte Stagingbereiche können geklont werden, intern benannte Stagingbereiche können nicht geklont werden.

  • Beim Klonen einer Datenbank oder eines Schemas:

    • Externe benannte Stagingbereiche, die zu Beginn der Klonierungsoperation in der Quelle vorhanden waren, werden geklont.

    • Tabellen werden geklont, d. h. ihre internen Stagingbereiche werden ebenfalls geklont.

    • Interne benannte Stagingbereiche werden nicht geklont.

Unabhängig davon, wie ein Stagingbereich geklont wurde, fügt der Klon keine der Dateien aus der Quelle hinzu, d. h. alle geklonten Stagingbereiche sind leer.

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.

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 und Tabellen)

In diesem Abschnitt werden Hinweise zur Verwendung von Time Travel zum Klonen von Objekten zu einem bestimmten Zeitpunkt in der Vergangenheit gegeben.

Klonen von historischen Objekten

Wenn das Quellobjekt zu dem in der AT | BEFORE-Klausel angegebenen 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.

Beachten Sie auch, dass ein untergeordnetes Objekt, das zum angegebenen Zeitpunkt nicht vorhanden war, nicht geklont wird.

Klonen von Metadaten historischer Objekte

Ein geklontes Objekt erbt die Definition des Quellobjekts zum Zeitpunkt der Ausführung der Anweisung. Die Definition beinhaltet Objektnamen, Kommentare, Tabellenspalten usw.

Im folgenden Beispiel wird die Tabelle t_sales in t_sales_20170522 umbenannt, und dann werden Daten in die umbenannte Tabelle eingefügt. Das Schema, das die Tabelle enthält, wird 30 Minuten vorher geklont, bevor die Tabelle umbenannt wurde und die Daten eingefügt wurden. Der Klon enthält eine Tabelle mit ihrem aktuellen Namen, nicht mit dem vorherigen Namen, aber mit einer Momentaufnahme der Daten zur angegebenen Zeit:

CREATE OR REPLACE TABLE t_sales (numeric integer) data_retention_time_in_days=1;

INSERT INTO  t_sales (numeric)
VALUES (1),(2),(3);

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

INSERT INTO  t_sales_20170522 (numeric)
VALUES (4);

CREATE OR REPLACE SCHEMA sales.private CLONE sales.public at(offset => -60*30);

USE SCHEMA sales.private;

SHOW TABLES;

+-------------------------------+------------------+---------------+-------------+-------+---------+------------+------+-------+----------+----------------+
| created_on                    | name             | database_name | schema_name | kind  | comment | cluster_by | rows | bytes | owner    | retention_time |
|-------------------------------+------------------+---------------+-------------+-------+---------+------------+------+-------+----------+----------------|
| 2017-05-24 10:15:07.110 -0700 | T_SALES_20170522 | SALES         | PRIVATE     | TABLE |         |            |    4 |  1024 | SYSADMIN | 1              |
+-------------------------------+------------------+---------------+-------------+-------+---------+------------+------+-------+----------+----------------+

SELECT * FROM T_SALES_20170522;

+---------+
| NUMERIC |
|---------|
|       1 |
|       2 |
|       3 |
+---------+