Remarques relatives au clonage

Ce chapitre fournit des remarques importantes sur le clonage d’objets dans Snowflake, en particulier sur le clonage de bases de données, de schémas et de tables (hors tables temporaires). Des facteurs tels que les transactions DDL et DML (sur l’objet source), Time Travel et les périodes de conservation des données peuvent affecter le clone d’objet.

Dans ce chapitre :

Privilèges de contrôle d’accès pour les objets clonés

Si l’objet source est une base de données ou un schéma, le clone hérite de tous les privilèges accordés sur les clones de tous les objets enfants contenus dans l’objet source :

  • Pour les bases de données, les objets contenus incluent les schémas, les tables, les vues, etc.

  • Pour les schémas, les objets contenus incluent les tables, les vues, etc.

Notez que le clone du conteneur lui-même (base de données ou schéma) n’hérite pas des privilèges accordés sur le conteneur source.

Les instructions CREATE <objet> … CLONE pour la plupart des objets ne copient pas les permissions de l’objet source vers l’objet clone. Cependant, les commandes CREATE <objet> qui prennent en charge la clause COPY GRANTS (par exemple, CREATE TABLE, CREATE VIEW) vous permettent de copier facultativement des autorisations sur des clones d’objets. Par exemple, la syntaxe de la commande CREATE TABLE … CLONE prend en charge le paramètre COPY GRANTS. Lorsque le paramètre COPY GRANTS est spécifié dans une instruction CREATE TABLE, l’opération de création copie tous les privilèges, sauf OWNERSHIP, de la table source vers la nouvelle table. Le même comportement est vrai pour les autres commandes CREATE qui prennent en charge la clause COPY GRANTS.

Dans tous les autres cas, vous devez accorder tous les privilèges requis au clone nouvellement créé (en utilisant GRANT <privileges> … TO ROLE).

Clonage et objets Snowflake

Cette section décrit des considérations de clonage particulières concernant des objets Snowflake spécifiques.

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;
    

Clonage et contraintes de clés étrangères

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

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.

Conséquence de DDL sur le clonage

Le clonage est rapide, mais pas instantané, en particulier pour les gros objets (par exemple les tables). Ainsi, si des instructions DDL sont exécutées sur des objets source (par exemple, renommer des tables dans un schéma) pendant que l’opération de clonage est en cours, les modifications peuvent ne pas être représentées dans le clone. La raison est que les instructions DDL sont atomiques et ne font pas partie des transactions à plusieurs instructions.

De plus, Snowflake n’enregistre pas les noms d’objets qui étaient présents lorsque l’opération de clonage a commencé et ceux qui ont changé de nom. Ainsi, les instructions DDL qui renomment (ou détruisent et recréent) les objets enfants sources sont en concurrence avec toute opération de clonage en cours et peuvent provoquer des conflits de nom.

Dans l’exemple suivant, la table t_sales est détruite, et une autre table est modifiée et reçoit le même nom que la table détruite pendant le clonage de la base de données mère, produisant une erreur :

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.

Astuce

Pour éviter les conflits dans la résolution des noms au cours d’une opération de clonage, nous vous suggérons de ne pas renommer les objets par un nom précédemment utilisé par un objet détruit jusqu’à ce que le clonage soit terminé.

Conséquence de DML et de la conservation des donnée sur le clonage

Le paramètre DATA_RETENTION_TIME_IN_DAYS spécifie le nombre de jours pendant lesquels Snowflake conserve les données historiques pour effectuer des actions de Time Travel sur un objet. Comme les données conservées pour le Time Travel entraînent des coûts de stockage au niveau de la table, certains utilisateurs définissent ce paramètre sur 0 pour certaines tables, désactivant ainsi la conservation des données pour ces tables (c’est-à-dire que lorsque la valeur est définie sur 0, les données de Time Travel conservées pour les transactions DML sont purgées, entraînant des coûts de stockage supplémentaires négligeables).

Les opérations de clonage nécessitent du temps, en particulier pour les grandes tables. Pendant cette période, les transactions DML peuvent modifier les données d’une table source. Par la suite, Snowflake tente de cloner les données de la table telles qu’elles existaient lorsque l’opération a commencé. Cependant, si les données sont purgées pour les transactions DML qui se produisent pendant le clonage (car la durée de conservation de la table est 0), les données ne sont pas disponibles pour terminer l’opération, ce qui produit une erreur similaire à ce qui suit :

ProgrammingError occured: "000707 (02000): None: Data is not available." with query id None

Astuce

Comme solution, nous vous recommandons l’une des pratiques suivantes pour le clonage d’un objet :

  • S’abstenir, si possible, d’exécuter des transactions DML sur l’objet source (ou l’un de ses enfants) avant la fin de l’opération de clonage.

  • Si ce n’est pas possible, avant de commencer le clonage, définissez DATA_RETENTION_TIME_IN_DAYS=1 pour toutes les tables du schéma (ou de la base de données si vous clonez une base de données entière). Une fois l’opération terminée, n’oubliez pas de réinitialiser la valeur du paramètre sur 0 pour les tables de la source, si vous le souhaitez.

    Vous pouvez également définir la valeur sur 0 pour les tables clonées (si vous prévoyez d’apporter des modifications DML aux tables clonées et que vous ne souhaitez pas subir de frais de stockage supplémentaires pour Time Travel sur les tables).

Clonage avec Time Travel (bases de données, schémas, tables et flux uniquement)

Cette section fournit des informations à prendre en compte lors de l’utilisation de Time Travel pour cloner des objets à un moment ou à un point précis dans le passé.

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.

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

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

Note

Pour garantir un comportement cohérent dans les opérations de clonage longues, lorsqu’une clause AT ou BEFORE n’est pas spécifiée pour un CREATE <objet> … CLONE, l’opération de clonage définit en interne la valeur de la clause AT comme l’horodatage de l’initiation de l’instruction.

Revenir au début