Cloner des bases de données contenant des tables hybrides

Vous pouvez cloner des bases de données contenant des tables hybrides pour deux raisons principales :

  • Pour exécuter des opérations de restauration à un instant dans le passé. Le clonage fonctionne en combinaison avec Time Travel, qui crée par défaut des sauvegardes continues implicites. Après avoir défini une période de conservation des données, vous pouvez cloner une base de données à n’importe quel moment de son historique Time Travel pour restaurer la base de données dans un état sain (dans le cas où une corruption aurait été introduite). Vous n’avez besoin de créer un clone que lorsqu’une restauration est nécessaire.

  • Pour hydrater d’autres environnements à partir d’un environnement source, comme dans le cas du clonage d’une base de données de la production vers le développement ou le test.

Avant de tenter de créer des bases de données clonées contenant des tables hybrides, assurez-vous d’avoir bien lu et compris les exigences et les limites spécifiques énoncées dans les sections suivantes.

Cloner des tables hybrides au niveau de la base de données

Les clones de tables hybrides doivent être créés au niveau de la base de données. Par exemple :

CREATE DATABASE clone_db1 CLONE db1;
Copy

Vous ne pouvez pas cloner des tables hybrides au niveau du schéma ou de la table. Si vous essayez de créer une nouvelle table hybride en clonant une table hybride ou une table standard, la commande échoue avec une erreur. Par exemple :

CREATE HYBRID TABLE clone_ht1 CLONE ht1;
Copy
391411 (0A000): This feature is not supported for hybrid tables: 'CLONE'.

Si vous essayez de créer un schéma en clonant un autre schéma et que le schéma source possède une ou plusieurs tables hybrides, la commande échoue. Toutefois, vous pouvez cloner le schéma en utilisant le paramètre IGNORE HYBRID TABLES pour ignorer explicitement les tables hybrides du schéma. Ce paramètre permet également de créer des clones de bases de données. Par exemple :

CREATE OR REPLACE SCHEMA clone_ht_schema CLONE ht_schema IGNORE HYBRID TABLES;
Copy
+----------------------------------------------+
| status                                       |
|----------------------------------------------|
| Schema CLONE_HT_SCHEMA successfully created. |
+----------------------------------------------+

Notes sur l’utilisation du clonage de tables hybrides

  • Vous ne pouvez pas créer de clones incluant des tables hybrides en utilisant les paramètres AT BEFORE, OFFSET ou STATEMENT (UUID de requête). Vous devez spécifier, au choix, aucun paramètre, ou AT TIMESTAMP avec une valeur TIMESTAMP explicitement convertie.

  • Conformément au comportement des tables standard, l’historique d’une table source clonée n’est pas conservé par le clone lui-même. Les tables clonées perdent tout l’historique de leurs tables sources, ce qui signifie que vous ne pouvez pas utiliser Time Travel pour voir un état antérieur après qu’elles ont été clonées. Time Travel peut être utilisé pour voir le nouvel historique des tables qui s’accumule après l’opération de clonage.

  • Le clonage de tables hybrides est une opération liée à la taille des données, tandis que le clonage de tables standard ne concerne que les métadonnées. Cette différence a un impact sur le coût du calcul, le coût du stockage et les performances.

    • L’opération de clonage de la base de données elle-même entraîne des coûts de calcul lorsque celle-ci contient des tables hybrides.

    • Lorsque les tables hybrides sont clonées, les données sont physiquement copiées dans le magasin de lignes. Par conséquent, l’opération de clonage peut prendre beaucoup de temps pour les tables de grande taille, et le coût augmente de façon linéaire avec la taille des données.

    • La performance du clonage est similaire à celle d’un chargement en masse direct optimisé, effectué à l’aide de la commande CREATE TABLE AS SELECT. Voir Chargement des données.

Les exemples suivants mettent en évidence les principales exigences en matière de création de clones de bases de données contenant des tables hybrides. Pour des informations complètes sur la syntaxe et des notes sur l’utilisation, voir AT | BEFORE et CREATE <objet> … CLONE.

Exemple : CREATEDATABASE … CLONE

Vous pouvez cloner une base de données contenant des tables hybrides à l’aide de la commande CREATE DATABASE. .. CLONE. Cette commande spécifie le nom de la base de données source existante et le nom d’une nouvelle base de données de destination. La base de données clonée est créée à partir de la valeur AT TIMESTAMP que vous indiquez, ou à partir du moment présent si vous n’indiquez pas d’horodatage. La nouvelle base de données est une copie des schémas et des tables qui existaient dans la source à ce moment-là (que les tables soient du type standard ou hybride).

L’exemple suivant illustre le comportement attendu lorsque vous clonez une base de données contenant une ou plusieurs tables hybrides. La première commande montre les deux tables présentes dans le schéma testdata de la base de données testdb. La table ht1 est une table hybride et la table st1 est une table standard.

SHOW TERSE TABLES;
Copy
+-------------------------------+------+-------+---------------+-------------+
| created_on                    | name | kind  | database_name | schema_name |
|-------------------------------+------+-------+---------------+-------------|
| 2024-11-14 15:59:32.683 -0800 | HT1  | TABLE | TESTDB        | TESTDATA    |
| 2024-11-14 16:00:01.360 -0800 | ST1  | TABLE | TESTDB        | TESTDATA    |
+-------------------------------+------+-------+---------------+-------------+

La commande suivante clone cette base de données à 16 h 01 le 14 novembre, peu après la création des tables :

CREATE OR REPLACE DATABASE clone_testdb
  CLONE testdb AT(TIMESTAMP => '2024-11-14 16:01:00'::TIMESTAMP_LTZ);
Copy
+---------------------------------------------+
| status                                      |
|---------------------------------------------|
| Database CLONE_TESTDB successfully created. |
+---------------------------------------------+

Pour voir les tables clonées, utilisez le schéma testdata défini dans la base de données clone_testdb :

USE DATABASE clone_testdb;
USE SCHEMA testdata;
Copy

Utilisez une commande SHOW TABLES pour vérifier que le clonage des tables a abouti :

SHOW TERSE TABLES;
Copy
+-------------------------------+------+-------+---------------+-------------+
| created_on                    | name | kind  | database_name | schema_name |
|-------------------------------+------+-------+---------------+-------------|
| 2024-11-14 16:05:14.102 -0800 | HT1  | TABLE | CLONE_TESTDB  | TESTDATA    |
| 2024-11-14 16:05:14.102 -0800 | ST1  | TABLE | CLONE_TESTDB  | TESTDATA    |
+-------------------------------+------+-------+---------------+-------------+

Exemple : Création d’un clone qui restaure une table hybride détruite

En reprenant la base de données testdb de l’exemple précédent, supposez qu’un utilisateur crée et charge une autre table hybride nommée ht2. Cependant, quelques minutes plus tard, un autre utilisateur supprime par erreur la table ht2.

SHOW TERSE TABLES;
Copy
+-------------------------------+------+-------+---------------+-------------+
| created_on                    | name | kind  | database_name | schema_name |
|-------------------------------+------+-------+---------------+-------------|
| 2024-11-14 15:59:32.683 -0800 | HT1  | TABLE | TESTDB        | TESTDATA    |
| 2024-11-14 17:37:24.304 -0800 | HT2  | TABLE | TESTDB        | TESTDATA    |
| 2024-11-14 16:00:01.360 -0800 | ST1  | TABLE | TESTDB        | TESTDATA    |
+-------------------------------+------+-------+---------------+-------------+

DROP TABLE HT2;
Copy
+---------------------------+
| status                    |
|---------------------------|
| HT2 successfully dropped. |
+---------------------------+

SHOW TERSE TABLES;
Copy
+-------------------------------+------+-------+---------------+-------------+
| created_on                    | name | kind  | database_name | schema_name |
|-------------------------------+------+-------+---------------+-------------|
| 2024-11-14 15:59:32.683 -0800 | HT1  | TABLE | TESTDB        | TESTDATA    |
| 2024-11-14 16:00:01.360 -0800 | ST1  | TABLE | TESTDB        | TESTDATA    |
+-------------------------------+------+-------+---------------+-------------+

Vous pouvez restaurer la base de données à son état « sain », c’est-à-dire au moment où elle contenait trois tables, en créant un clone de testdb (nommé restore_testdb dans cet exemple) avec un horodatage approprié. L’horodatage spécifié ici est très proche du moment où la table a été créée (mais antérieur à sa destruction). Dans la pratique, vous devrez choisir l’horodatage avec soin, en fonction du moment où les données ont été chargées dans la table ou d’autres mises à jour ont été appliquées. Dans cet exemple, l’objectif principal est de capturer l’état de la table précédant immédiatement sa destruction.

CREATE OR REPLACE DATABASE restore_testdb
  CLONE testdb AT(TIMESTAMP => '2024-11-14 17:38'::TIMESTAMP_LTZ);
Copy
+-----------------------------------------------+
| status                                        |
|-----------------------------------------------|
| Database RESTORE_TESTDB successfully created. |
+-----------------------------------------------+

Vous pouvez maintenant vérifier le contenu du nouveau clone et vous assurer que la table ht2 s’y trouve :

USE DATABASE restore_testdb;
USE SCHEMA testdata;
SHOW TERSE TABLES;
Copy
+-------------------------------+------+-------+----------------+-------------+
| created_on                    | name | kind  | database_name  | schema_name |
|-------------------------------+------+-------+----------------+-------------|
| 2024-11-14 17:47:58.984 -0800 | HT1  | TABLE | RESTORE_TESTDB | TESTDATA    |
| 2024-11-14 17:47:58.984 -0800 | HT2  | TABLE | RESTORE_TESTDB | TESTDATA    |
| 2024-11-14 17:47:58.984 -0800 | ST1  | TABLE | RESTORE_TESTDB | TESTDATA    |
+-------------------------------+------+-------+----------------+-------------+

Exemple : Restauration d’une base de données à un moment antérieur à une opération DML incorrecte

Une base de données nommée ht_sensors possède un schéma ht_schema qui contient une table nommée sensor_data_device2. Supposons qu’une série d’opérations DELETE a été exécutée sur cette table le 25 novembre. Vous pouvez accéder à Monitoring Query History dans Snowsight pour obtenir des informations sur ces opérations DELETE. (Dans cet exemple, le filtre SQL Text est défini sur DELETE afin de les isoler.)

Historique des requêtes filtré par Texte SQL pour afficher une série de quatre opérations DELETE.

Si la deuxième opération DELETE de la liste a été exécutée par erreur (les lignes dont la valeur motor_rpm est supérieure à 1504 ont été supprimées), vous pouvez cloner la base de données pour la restaurer dans l’état où elle se trouvait juste avant la validation de cette opération. (Pour simplifier cet exemple, supposons qu’aucune autre modification, telle que mise à jour ou insertion, n’a été apportée à cette table ou à toute autre table de la base de données pendant cette période.)

Avant de cloner la base de données, vous pouvez vérifier les résultats de Time Travel à l’aide d’une simple requête. De cette manière, vous pouvez vérifier que le clone capture les données attendues avant d’exécuter l’opération de restauration, plus coûteuse.

Par exemple, comparez les résultats des deux requêtes Time Travel suivantes, qui se situent à une minute d’intervalle :

SELECT COUNT(*) FROM sensor_data_service2
  AT(TIMESTAMP => 'Mon, 25 Nov 2024 14:09:00'::TIMESTAMP_LTZ) WHERE MOTOR_RPM>1504;
Copy
+----------+
| COUNT(*) |
|----------|
|     1855 |
+----------+

SELECT COUNT(*) FROM sensor_data_service2
  AT(TIMESTAMP => 'Mon, 25 Nov 2024 14:10:00'::TIMESTAMP_LTZ) WHERE MOTOR_RPM>1504;
Copy
+----------+
| COUNT(*) |
|----------|
|        0 |
+----------+

Les résultats confirment la différence attendue. Vous pouvez maintenant cloner la base de données en utilisant le même horodatage que pour la première requête :

USE DATABASE ht_sensors;
USE SCHEMA ht_schema;

CREATE OR REPLACE DATABASE restore_ht_sensors
  CLONE ht_sensors AT(TIMESTAMP => 'Mon, 25 Nov 2024 14:09:00'::TIMESTAMP_LTZ);
Copy
+---------------------------------------------------+
| status                                            |
|---------------------------------------------------|
| Database RESTORE_HT_SENSORS successfully created. |
+---------------------------------------------------+

Vérifiez maintenant l’état de la base de données clonée. Gardez à l’esprit que la version clonée de la table sensor_data_device2 ne contient pas de données Time Travel.

USE DATABASE restore_ht_sensors;
USE SCHEMA ht_schema;
SELECT COUNT(*) FROM SENSOR_DATA_DEVICE2 WHERE motor_rpm>1504;
Copy
+----------+
| COUNT(*) |
|----------|
|     1855 |
+----------+

La requête Time Travel suivante sur la nouvelle table échoue comme prévu :

SELECT COUNT(*) FROM SENSOR_DATA_DEVICE2 AT(TIMESTAMP => 'Mon, 25 Nov 2024 14:09:00'::TIMESTAMP_LTZ) WHERE MOTOR_RPM>1504;
Copy
000707 (02000): Time travel data is not available for table SENSOR_DATA_DEVICE2. The requested time is either
beyond the allowed time travel period or before the object creation time.

Enfin, notez que vous aurez peut-être besoin de réappliquer l’opération DELETE la plus récente dans l’historique des requêtes, dans la mesure où la table clonée a conservé les lignes où la colonne timestamp était supérieure à 2024-04-03 07:30:00.000.

Langage: Français