Remarques relatives au clonage¶

Clonage et schémas d’accès gérés¶

Si vous clonez un schéma et que vous spécifiez la clause WITH MANAGED ACCESS, les privilèges requis varient selon que le schéma source est un schéma géré ou non géré. Pour plus de détails, voir les privilèges CREATE SCHEMA.

Clonage et paramètres des objets¶

Les objets clonés héritent de tous les paramètres d’objet qui ont été définis sur l’objet source lorsque cet objet a été cloné. Si un paramètre d’objet peut être défini sur des conteneurs d’objets (par exemple, compte, base de données, schéma) et qu’il n’est pas explicitement défini sur l’objet source, un clone d’objet hérite de la valeur par défaut du paramètre ou de la valeur remplacée au niveau le plus bas. Pour plus d’informations sur les paramètres des objets, voir Paramètres.

Clonage et séquences par défaut¶

Dans une table, une colonne peut faire référence à une séquence qui génère des valeurs par défaut. Lorsqu’une table est clonée, la table clonée fait référence à la séquence source ou clonée :

• Si la base de données ou le schéma contenant à la fois la table et la séquence est cloné(e), la table clonée fait référence à la séquence clonée.

• Sinon, la table clonée fait référence à la séquence source.

  Par exemple, si la séquence est définie dans une base de données ou un schéma différent(e), la table clonée fait référence à la séquence source. Ou si vous clonez uniquement la table elle-même, la table clonée fait référence à la séquence source.

  Si vous ne souhaitez pas que la nouvelle table continue à utiliser la séquence source, exécutez la commande suivante :

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

  Copy

Clonage et contraintes de clé étrangère¶

Une table peut avoir une contrainte de clé étrangère qui fait référence à une table qui inclut la clé primaire. Lorsqu’une table avec une contrainte de clé étrangère est clonée, la table clonée fait référence à la table source ou clonée qui inclut la clé primaire :

• Si la base de données ou le schéma contenant les deux tables est cloné, la table clonée avec la clé étrangère fait référence à la clé primaire de l’autre table clonée.

• Si les tables se trouvent dans des bases de données ou des schémas distincts, la table clonée fait référence à la clé primaire de la table source.

Clonage et clés de clustering¶

Une table peut avoir un sous-ensemble de colonnes désigné comme une clé de clustering afin de co-localiser des lignes similaires dans la même micro-partition. Lorsqu’une table avec une clé de clustering est clonée, la nouvelle table est créée avec une clé de clustering. Par défaut, Clustering automatique est suspendu pour la nouvelle table. Pour reprendre le clustering automatique pour la nouvelle table, exécutez la commande suivante :

ALTER TABLE <name> RESUME RECLUSTER

Clonage et zones de préparation¶

Il est possible de cloner des zones de préparation nommées externes individuelles. Une zone de préparation externe fait référence à un compartiment ou à un conteneur dans un stockage externe dans le Cloud ; le clonage d’une zone de préparation externe n’a pas d’impact sur le stockage dans le Cloud référencé.

Les zones de préparation nommées internes (c’est-à-dire Snowflake) ne peuvent pas être clonées.

Lors du clonage d’une base de données ou d’un schéma :

• Les zones de préparation nommées externes présentes dans la source au démarrage de l’opération de clonage sont clonées.

• Les tables sont clonées, ce qui signifie que la zone de préparation interne associée à chaque table est également clonée. Tous les fichiers de données qui étaient présents dans une zone de préparation de table dans la base de données ou le schéma source ne sont pas copiés sur le clone (c’est-à-dire que les zones de préparation de table clonées sont vides).

• Les zones de préparation nommées internes ne sont pas clonées.

Clonage et tables d’événements¶

Lors du clonage d’une table d’événements, vous ne pouvez effectuer le clonage que depuis et vers des tables d’événements. En d’autres termes, vous ne pouvez pas effectuer de clonage depuis une table normale vers une table d’événements, ni depuis une table d’événements vers une table normale.

Clonage et canaux¶

Lorsqu’une base de données ou un schéma est cloné, tous les canaux du conteneur source qui font référence à une zone de préparation interne (c’est-à-dire Snowflake) ne sont pas clonés.

Cependant, tous les canaux faisant référence à une zone de préparation externe sont clonés. Cela inclut tous les objets canal pour lesquels le paramètre INTEGRATION est défini. Ce paramètre pointe vers une intégration de notification pour activer l’auto-ingestion de Snowpipe lors du chargement de données à partir de fichiers dans Google Cloud Storage ou le stockage blob Microsoft Azure.

Lorsqu’un fichier de données est créé à un emplacement de zone de préparation (par exemple, un conteneur de stockage blob), une copie de la notification est envoyée à chaque canal correspondant à l’emplacement de la zone de préparation. Cela entraîne le comportement suivant :

• Si une table est pleinement qualifiée dans l’instruction COPY de la définition de canal (sous la forme db_name.schema_name.table_name ou schema_name.table_name), alors Snowpipe charge les données dupliquées dans la table source (c’est-à-dire database.schema.table de l’instruction COPY) pour chaque canal.

• Si une table n’est pas pleinement qualifiée dans la définition du canal, alors Snowpipe charge les données dans la même table (par exemple, mytable) dans les bases de données/schémas sources et clonés.

L’état par défaut d’un clone de canal est le suivant :

• Lorsque AUTO_INGEST = FALSE, un canal cloné est suspendu par défaut.

• Lorsque AUTO_INGEST = TRUE, un canal cloné est défini sur l’état STOPPED_CLONED. Dans cet état, les canaux n’accumulent pas de notifications d’événements à la suite de nouveaux fichiers mis en zone de préparation. Lorsqu’un canal est explicitement repris, il ne traite que les fichiers de données déclenchés à la suite de nouvelles notifications d’événements.

Un canal clone dans l’un ou l’autre état peut être repris en exécutant une instruction ALTER PIPE … RESUME.

Clonage et flux¶

Actuellement, lorsqu’une base de données ou un schéma contenant des tables source et des flux est cloné(e), tous les enregistrements non consommés dans les flux (dans le clone) sont inaccessibles. Ce comportement est cohérent avec Time Travel pour les tables. Si une table est clonée, les données historiques pour le clone de table commencent à l’heure/le moment où le clone a été créé.

Clonage et tâches¶

Quand une base de données ou un schéma contenant des tâches est cloné(e), les tâches du clone sont suspendues par défaut. Les tâches peuvent être reprises individuellement (avec ALTER TASK … RESUME).

Clonage et alertes¶

Quand une base de données ou un schéma contenant des alertes est cloné(e), les alertes du clone sont suspendues par défaut.

Pour reprendre une alerte suspendue, vous pouvez utiliser la commande ALTER ALERT … RESUME.

Clonage et objets de gouvernance¶

Politiques de masquage et d’accès aux lignes :

L’approche suivante permet de protéger les données des utilisateurs avec le privilège SELECT sur la table ou la vue lors de l’accès à un objet cloné :

• Le clonage d’un objet de politique individuel n’est pas pris en charge.

• Le clonage d’un schéma entraîne le clonage de toutes les politiques au sein du schéma.

• Une table clonée correspond aux mêmes politiques que la table source. En d’autres termes, si une politique est définie sur la table de base ou ses colonnes, la politique est attachée à la table clonée ou ses colonnes.

  • Lorsqu’une table est clonée dans le contexte de son clonage de schéma parent, si la table source a une référence à une politique dans le même schéma parent (c’est-à-dire une référence locale), la table clonée aura une référence à la politique clonée.

  • Si la table source fait référence à une politique dans un schéma différent (c’est-à-dire une référence étrangère), la table clonée conserve la référence étrangère.

Pour plus d’informations, voir CREATE <objet> … CLONE.

Voir aussi :

• Clonage des tables externes et des politiques de masquage.

• Clonage des tables externes et des politiques d’accès aux lignes.

Balises :

• Les associations de balises dans l’objet source (par ex. des tables) sont maintenues dans les objets clonés.

• Pour une base de données ou un schéma :

  Les balises stockées dans cette base de données ou ce schéma sont également clonées.

  Lorsqu’une base de données ou un schéma est cloné, les balises qui résident dans ce schéma ou cette base de données sont également clonées.

  Si une table ou une vue existe dans le schéma/la base de données source et a des références à des balises dans le même schéma ou la même base de données, la table ou la vue clonée est mappée sur la balise clonée correspondante (dans le schéma ou la base de données cible) au lieu de la balise dans le schéma ou la base de données source.

Politiques de masquage basées sur les balises :

Dans le cas d’une politique de masquage basée sur des balises, où la balise est stockée dans un schéma différent de celui de la politique et de la table de masquage, le clonage du schéma contenant la politique et la table de masquage fait que la table clonée est protégée par la politique de masquage dans le schéma source et non dans le schéma cloné.

Cependant, pour une politique de masquage basée sur une balise, où la balise, la politique de masquage et la table existent toutes dans le schéma, le clonage du schéma fait que la table est protégée par la politique de masquage dans le schéma cloné, et non dans le schéma source.

Si la table est clonée ou déplacée vers un autre schéma ou une autre base de données et qu’elle était à l’origine protégée par une politique de masquage basée sur des balises définie sur le schéma ou la base de données, la table n’est pas protégée par la politique de masquage basée sur des balises définie sur le schéma ou la base de données source. La table est protégée par la politique de masquage basée sur les balises définie sur le schéma ou la base de données cible, s’il existe une politique de masquage basée sur les balises définie sur le schéma ou la base de données cible.

Clonage et rôles de base de données¶

Vous pouvez cloner un rôle de base de données à l’aide de la commande CREATE DATABASE ROLE … CLONE si le rôle de base de données n’existe pas déjà dans la base de données cible. Pour plus de détails, voir CREATE <objet> … CLONE.

Clonage et UDFs Java¶

Une UDF Java peut être clonée lorsque la base de données ou le schéma contenant l’UDF Java est cloné(e). Pour être clonée, l’UDF Java doit remplir certaines conditions. Pour plus d’informations, voir Limites du clonage.

Clonage d’objets historiques¶

Si l’objet source n’existait pas à l’instant ou au point spécifié dans la clause AT | BEFORE, une erreur est renvoyée.

Dans l’exemple suivant, une instruction CREATE TABLE … CLONE tente de cloner la table source à un moment dans le passé (30 minutes avant) où elle n’existait pas :

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

Tout objet enfant dans une base de données ou un schéma cloné qui n’existait pas à l’heure/au moment spécifié n’est pas cloné.

L’opération de clonage échoue dans les scénarios suivants :

• Si la durée Time Travel spécifiée est supérieure à la durée de conservation de tout enfant actuel de la base de données ou du schéma cloné.

  En guise de solution de contournement pour les objets enfants qui ont été purgés de Time Travel, utilisez le paramètre IGNORE TABLES WITH INSUFFICIENT DATA RETENTION de la commande CREATE <objet> … CLONE. Pour plus d’informations, voir Objets enfants et durée de conservation des données.

• Si un objet canal avec AUTO-INGEST = TRUE défini a été recréé (en utilisant la syntaxe CREATE OR REPLACE PIPE) ou détruit depuis le point dans le temps spécifié dans la clause AT | BEFORE . Cette limitation ne s’applique pas aux objets canal créés pour l’ingestion manuelle de Snowpipe à l’aide de l’API REST (c’est-à-dire avec AUTO-INGEST = FALSE).

Clonage de métadonnées d’objets historiques¶

Un clone d’objet hérite de la structure et du nom de l’objet source actuel au moment de l’exécution de l’instruction CREATE <objet> … CLONE ou à l’heure/au point spécifié dans le passé à l’aide de Time Travel. Un clone d’objet hérite de toutes les autres métadonnées, telles que les commentaires ou les clés de clustering de table, qui sont actuels dans l’objet source au moment de l’exécution de l’instruction, que l’on utilise ou non Time Travel.