Hinweise zum Klonen¶

Klonen und verwaltete Zugriffsschemas¶

Wenn Sie ein Schema klonen und die WITH MANAGED ACCESS-Klausel angeben, hängen die erforderlichen Berechtigungen davon ab, ob das Quellschema ein verwaltetes oder ein nicht verwaltetes Schema ist. Weitere Informationen dazu finden Sie unter CREATE SCHEMA-Berechtigungen.

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

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 Ereignistabellen¶

Wenn Sie eine Ereignistabelle klonen, können Sie nur in und aus Ereignistabellen klonen. Mit anderen Worten, Sie können weder von einer regulären Tabelle zu einer Ereignistabelle noch von einer Ereignistabelle zu einer regulären Tabelle klonen.

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:

• Klonen externer Tabellen und Maskierungsrichtlinien.

• Klonen externer Tabellen und Zeilenzugriffsrichtlinien.

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.

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.

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.