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

Un objet cloné ne conserve aucun privilège accordé sur l’objet source lui-même (c’est-à-dire que les clones n’ont pas automatiquement les mêmes privilèges que leurs sources). Un administrateur système ou le propriétaire de l’objet cloné doit explicitement accorder tous les privilèges requis au clone nouvellement créé.

Cependant, si l’objet source est une base de données ou un schéma, pour les objets enfants (tables, vues, etc.) de la source, le clone réplique tous les privilèges accordés sur les objets enfants correspondants :

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

Clonage et objets Snowflake

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

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 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 entraîne le comportement suivant :

  • Si la table cible est pleinement qualifiée dans l’instruction COPY de la définition de canal (sous la forme nom_bdd.nom_schéma.nom_table ou nom_schéma.nom_table), cela peut entraîner le chargement de données en double dans la table cible de la base de données source ou du schéma par chaque canal.

  • Si la table cible n’est pas qualifiée entièrement dans la définition de canal, les données sont chargées dans la table cible (par exemple, mytable) et 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).

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