CREATE DATABASE

Crée une nouvelle base de données dans le système.

De plus, cette commande peut être utilisée pour :

Voir aussi :

ALTER DATABASE , DESCRIBE DATABASE , DROP DATABASE , SHOW DATABASES , UNDROP DATABASE

DESCRIBE SHARE , SHOW SHARES

Syntaxe

Base de données standard

CREATE [ OR REPLACE ] [ TRANSIENT ] DATABASE [ IF NOT EXISTS ] <name>
    [ CLONE <source_db>
          [ { AT | BEFORE } ( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ] ]
    [ DATA_RETENTION_TIME_IN_DAYS = <integer> ]
    [ MAX_DATA_EXTENSION_TIME_IN_DAYS = <integer> ]
    [ DEFAULT_DDL_COLLATION = '<collation_specification>' ]
    [ COMMENT = '<string_literal>' ]
    [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' , ... ] ) ]
Copy

Base de données partagée (à partir d’un partage)

CREATE DATABASE <name> FROM SHARE <provider_account>.<share_name>
Copy

Base de données secondaire (réplication de base de données)

CREATE DATABASE <name>
    AS REPLICA OF <account_identifier>.<primary_db_name>
    [ DATA_RETENTION_TIME_IN_DAYS = <integer> ]
Copy

Paramètres requis

name

Indique l’identificateur de la base de données ; il doit être unique pour votre compte.

De plus, l’identificateur doit commencer par un caractère alphabétique et ne peut pas contenir d’espaces ou de caractères spéciaux à moins que toute la chaîne d’identificateur soit délimitée par des guillemets doubles (p. ex. "My object"). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

Pour plus de détails, voir Exigences relatives à l’identificateur.

Important

En tant que meilleure pratique pour la réplication et le basculement de la base de données, nous vous recommandons de donner à chaque base de données secondaire le même nom que sa base de données principale. Cette recommandation prend en charge le référencement d’objets pleinement qualifiés (c’est-à-dire '<bd>.<schéma>.<objet>') par d’autres objets dans la même base de données, comme la requête d’un nom de table complet dans une vue.

Si une base de données secondaire a un autre nom que celui de la base de données principale, ces références d’objet ne fonctionneraient plus dans la base de données secondaire.

Paramètres de Secure Data Sharing

provider_account.share_name

Spécifie l’identificateur du partage à partir duquel créer la base de données. Tel que documenté, le nom du partage doit être complet avec le nom du compte qui fournit le partage.

Paramètres de réplication de base de données

AS REPLICA OF account_identifier.primary_db_name

Spécifie l’identificateur d’une base de données principale à partir de laquelle créer un réplica (c’est-à-dire une base de données secondaire). Si l’identificateur contient des espaces, des caractères spéciaux ou des caractères majuscules et minuscules, toute la chaîne doit être délimitée par des guillemets doubles.

Requiert l’identificateur du compte et le nom de la base de données principale.

account_identifier

Identificateur unique du compte qui stocke la base de données principale. L’identificateur préféré est organization_name.account_name. Pour afficher la liste des comptes activés pour la réplication dans votre organisation, interrogez SHOW REPLICATION ACCOUNTS.

Bien que l’ancien localisateur de compte puisse également être utilisé comme identificateur de compte, son utilisation est déconseillée, car il pourrait ne plus fonctionner à l’avenir. Pour plus de détails sur l’utilisation du localisateur de compte comme identificateur de compte, voir Notes sur l’utilisation de la réplication de base de données.

primary_db_name

Nom de la base de données principale. Il est recommandé de donner à chaque base de données secondaire le même nom que sa base de données principale.

Note

Comme meilleure pratique pour la réplication et le basculement des bases de données, nous recommandons de définir le paramètre facultatif DATA_RETENTION_TIME_IN_DAYS sur la même valeur sur la base de données secondaire que sur la base de données principale.

Paramètres facultatifs

TRANSIENT

Spécifie une base de données comme transitoire. Les bases de données transitoires n’ont pas de période Fail-safe et n’encourent donc pas de coûts de stockage supplémentaires une fois qu’elles quittent la période Time Travel ; cependant, cela signifie également qu’elles ne sont pas protégées par Fail-safe en cas de perte de données. Pour plus d’informations, voir Compréhension et affichage de Fail-safe.

De plus, par définition, tous les schémas (et donc toutes les tables) créés dans une base de données transitoire sont transitoires. Pour plus d’informations sur les tables transitoires, voir CREATE TABLE.

Par défaut : aucune valeur (la base de données est permanente)

CLONE source_db

Spécifie de créer un clone de la base de données source spécifiée. Pour plus d’informations sur le clonage d’une base de données, voir CREATE <objet> … CLONE.

AT | BEFORE ( TIMESTAMP => timestamp | OFFSET => time_difference | STATEMENT => id )

Lors du clonage d’une base de données, la clause AT | BEFORE spécifie d’utiliser Time Travel pour cloner la base de données à ou avant un point spécifique dans le passé. Si la durée Time Travel spécifiée est antérieure ou égale à la date de création de la base de données, l’opération de clonage échoue avec une erreur.

DATA_RETENTION_TIME_IN_DAYS = integer

Spécifie le nombre de jours pendant lesquels des actions Time Travel (CLONE et UNDROP) peuvent être effectuées sur la base de données, ainsi que la durée de conservation Time Travel par défaut de tous les schémas créés dans la base de données. Pour plus de détails, voir Comprendre et utiliser la fonction « Time Travel ».

Pour une description détaillée de ce paramètre de niveau objet, ainsi que plus d’informations sur les paramètres d’objet, voir Paramètres.

Valeurs :

  • Édition Standard : 0 ou 1

  • Édition Enterprise :

    • 0 à 90 pour les bases de données permanentes

    • 0 ou 1 pour les bases de données transitoires

Par défaut :

  • Édition Standard : 1

  • Édition Enterprise (ou supérieure) : 1 (sauf si une valeur par défaut différente a été spécifiée au niveau du compte)

Note

Une valeur de 0 désactive effectivement Time Travel pour la base de données.

MAX_DATA_EXTENSION_TIME_IN_DAYS = integer

Paramètre d’objet qui spécifie le nombre maximum de jours pendant lesquels Snowflake peut prolonger la période de conservation des données pour les tables de la base de données, afin d’éviter que les flux sur les tables ne deviennent obsolètes.

Pour une description détaillée de ce paramètre, voir MAX_DATA_EXTENSION_TIME_IN_DAYS.

DEFAULT_DDL_COLLATION = 'collation_specification'

Spécifie une spécification de classement par défaut pour toutes les tables et tous les schémas ajoutés à la base de données. La valeur par défaut peut être remplacée au niveau du schéma et de la table individuelle.

Pour plus de détails sur le paramètre, voir DEFAULT_DDL_COLLATION.

COMMENT = 'string_literal'

Spécifie un commentaire pour la base de données.

Par défaut : aucune valeur

TAG ( tag_name = 'tag_value' [ , tag_name = 'tag_value' , ... ] )

Spécifie le nom de la balise et la valeur de la chaîne de la balise.

La valeur de la balise est toujours une chaîne de caractères et le nombre maximum de caractères pour la valeur de la balise est 256.

Pour plus de détails sur la spécification des balises dans une instruction, voir Quotas de balises pour les objets et les colonnes.

Exigences en matière de contrôle d’accès

Un rôle utilisé pour exécuter cette commande SQL doit avoir les privilèges suivants définis au minimum ainsi :

Privilège

Objet

Remarques

CREATE DATABASE

Compte

Only the SYSADMIN role, or a higher role, has this privilege by default. The privilege can be granted to additional roles as needed.

Pour obtenir des instructions sur la création d’un rôle personnalisé avec un ensemble spécifique de privilèges, voir Création de rôles personnalisés.

Pour des informations générales sur les rôles et les privilèges accordés pour effectuer des actions SQL sur des objets sécurisables, voir Aperçu du contrôle d’accès.

Notes générales sur l’utilisation

  • La création d’une base de données la définit automatiquement comme la base de données active/courante pour la session en cours (équivalant à l’utilisation de la commande USE DATABASE pour la base de données).

  • Si une base de données portant le même nom existe déjà, une erreur est renvoyée et la base de données n’est pas créée, sauf si le mot clé OR REPLACE facultatif est spécifié dans la commande.

    Important

    Utiliser OR REPLACE équivaut à utiliser DROP DATABASE sur la base de données existante et créer ensuite une nouvelle base de données avec le même nom ; cependant, la base de données détruite n’est pas supprimée définitivement du système. En revanche, elle est conservée dans Time Travel. Ceci est important, car les bases de données détruites dans Time Travel contribuent au stockage des données de votre compte. Pour plus d’informations, voir Coûts de stockage pour Time Travel et Fail-safe.

  • Les instructions CREATE OR REPLACE <objet> sont atomiques. En d’autres termes, lorsqu’un objet est remplacé, l’ancien objet est supprimé et le nouvel objet est créé dans une seule transaction.

  • La création d’une nouvelle base de données crée automatiquement deux schémas dans la base de données :

    • PUBLIC : schéma par défaut de la base de données.

    • INFORMATION_SCHEMA : schéma qui contient des vues et des fonctions de table qui peuvent être utilisées pour interroger les métadonnées sur les objets de la base de données, ainsi que sur tous les objets du compte.

  • Les bases de données créées à partir de partages diffèrent des bases de données standards de la façon suivante :

    • Elles ne possèdent pas les schémas PUBLIC ou INFORMATION_SCHEMA à moins que ces schémas n’aient été explicitement attribués au partage.

    • Elles ne peuvent pas être clonées.

    • Les propriétés telles que TRANSIENT et DATA_RETENTION_TIME_IN_DAYS ne s’appliquent pas.

  • Lorsqu’une base de données est active/courante, le schéma PUBLIC est également actif/courant par défaut sauf si un schéma différent est utilisé ou si le schéma PUBLIC a été détruit.

  • Concernant les métadonnées :

    Attention

    Les clients doivent s’assurer qu’aucune donnée personnelle (autre que pour un objet utilisateur), donnée sensible, donnée à exportation contrôlée ou autre donnée réglementée n’est saisie comme métadonnée lors de l’utilisation du service Snowflake. Pour plus d’informations, voir Champs de métadonnées dans Snowflake.

Notes sur l’utilisation de la réplication de base de données

Note

Snowflake recommande d’utiliser la Présentation de la réplication et du basculement à travers plusieurs comptes pour répliquer les bases de données. Les groupes de réplication et de basculement permettent la réplication de plusieurs bases de données et d’autres objets de compte avec une cohérence ponctuelle pour les objets du groupe. Pour une liste complète de la disponibilité des fonctionnalités et des objets pris en charge, reportez-vous à Présentation de la réplication et du basculement à travers plusieurs comptes.

  • La réplication de base de données utilise des ressources de calcul fournies par Snowflake au lieu de votre propre entrepôt virtuel pour copier des objets et des données. Cependant, le paramètre de session/objet STATEMENT_TIMEOUT_IN_SECONDS contrôle toujours le temps d’exécution d’une instruction avant son annulation. La valeur par défaut est de 172800 (2 jours). Étant donné que la réplication initiale d’une base de données principale peut durer plus de deux jours (en fonction de la quantité de métadonnées dans la base de données ainsi que de la quantité de données dans les objets de base de données), nous vous recommandons d’augmenter la valeur STATEMENT_TIMEOUT_IN_SECONDS et de la définir sur 604800 (sept jours, la valeur maximale) pour la session dans laquelle vous exécutez l’opération de réplication.

    Exécutez l’instruction ALTER SESSION suivante avant l’exécution de l’instruction ALTER DATABASE secondary_db_name REFRESH dans la même session :

    ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
    
    Copy

    Notez que le paramètre STATEMENT_TIMEOUT_IN_SECONDS s’applique également à l’entrepôt actif dans une session. Le paramètre respecte la valeur inférieure définie au niveau de la session ou de l’entrepôt. Si vous avez un entrepôt actif dans la session en cours, définissez également STATEMENT_TIMEOUT_IN_SECONDS sur 604800 pour cet entrepôt (avec ALTER WAREHOUSE).

    Par exemple :

    -- determine the active warehouse in the current session (if any)
    SELECT CURRENT_WAREHOUSE();
    
    +---------------------+
    | CURRENT_WAREHOUSE() |
    |---------------------|
    | MY_WH               |
    +---------------------+
    
    -- change the STATEMENT_TIMEOUT_IN_SECONDS value for the active warehouse
    
    ALTER WAREHOUSE my_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
    
    Copy

    vous pouvez réinitialiser la valeur du paramètre à la valeur par défaut une fois l’opération de réplication terminée :

    ALTER WAREHOUSE my_wh UNSET STATEMENT_TIMEOUT_IN_SECONDS;
    
    Copy
  • La méthode préférée pour identifier le compte qui stocke la base de données principale utilise le nom de l’organisation et le nom du compte comme identificateur du compte. Si vous décidez d’utiliser l’ancien localisateur de compte à la place, il se peut qu’il doive contenir des segments supplémentaires afin d’identifier le compte de manière unique. Voir le tableau ci-dessous à titre de référence :

    Identificateur du compte

    Emplacement du compte distant

    organization_name.account_name

    Identificateur de compte préféré qui peut être utilisé quelle que soit la région ou quel que soit le groupe de régions du compte stockant la base de données principale.

    account_locator

    Même région, mais compte différent du compte qui stocke la base de données principale.

    snowflake_region.account_locator

    Même groupe de régions, mais région différente du compte qui stocke la base de données principale

    region_group.snowflake_region.account_locator

    Groupe de régions différent du compte qui stocke la base de données principale.

  • La commande CREATE DATABASE … AS REPLICA ne prend pas en charge la clause WITH TAG.

    Cette clause n’est pas prise en charge, car la base de données secondaire est en lecture seule. Si votre base de données principale spécifie la clause WITH TAG, supprimez la clause avant de créer la base de données secondaire. Pour vérifier si votre base de données possède la clause WITH TAG, appelez la fonction GET_DDL dans votre compte Snowflake et spécifiez la base de données principale dans l’argument de la fonction. Si une balise est définie dans la base de données, la sortie de la fonction comprendra une instruction ALTER DATABASE… SET TAG.

    Pour plus de détails, voir Réplication et balises.

Exemples

Créer deux bases de données permanentes, dont une avec une période de conservation des données de 10 jours :

CREATE DATABASE mytestdb;

CREATE DATABASE mytestdb2 DATA_RETENTION_TIME_IN_DAYS = 10;

SHOW DATABASES LIKE 'my%';

+---------------------------------+------------+------------+------------+--------+----------+---------+---------+----------------+
| created_on                      | name       | is_default | is_current | origin | owner    | comment | options | retention_time |
|---------------------------------+------------+------------+------------+--------+----------+---------+---------+----------------|
| Tue, 17 Mar 2016 16:57:04 -0700 | MYTESTDB   | N          | N          |        | PUBLIC   |         |         | 1              |
| Tue, 17 Mar 2016 17:06:32 -0700 | MYTESTDB2  | N          | N          |        | PUBLIC   |         |         | 10             |
+---------------------------------+------------+------------+------------+--------+----------+---------+---------+----------------+
Copy

Créer une base de données transitoire :

CREATE TRANSIENT DATABASE mytransientdb;

SHOW DATABASES LIKE 'my%';

+---------------------------------+---------------+------------+------------+--------+----------+---------+-----------+----------------+
| created_on                      | name          | is_default | is_current | origin | owner    | comment | options   | retention_time |
|---------------------------------+---------------+------------+------------+--------+----------+---------+-----------+----------------|
| Tue, 17 Mar 2016 16:57:04 -0700 | MYTESTDB      | N          | N          |        | PUBLIC   |         |           | 1              |
| Tue, 17 Mar 2016 17:06:32 -0700 | MYTESTDB2     | N          | N          |        | PUBLIC   |         |           | 10             |
| Tue, 17 Mar 2015 17:07:51 -0700 | MYTRANSIENTDB | N          | N          |        | PUBLIC   |         | TRANSIENT | 1              |
+---------------------------------+---------------+------------+------------+--------+----------+---------+-----------+----------------+
Copy

Créer une base de données à partir d’un partage fourni par un compte ab67890 :

CREATE DATABASE snow_sales FROM SHARE ab67890.sales_s;
Copy

Pour des exemples plus détaillés de création d’une base de données à partir d’un partage, voir Consommation de données partagées.

Exemples de réplication de base de données

L’exemple suivant crée un réplica de la base de données principale myorg.account1.mydb1 dans le compte account1 de l’organisation myorg avec l’actualisation automatique des vues matérialisées dans le réplica activé. L’instruction SQL est exécutée dans le même groupe de régions AWS (public), mais dans une région différente du compte qui stocke la base de données principale :

CREATE DATABASE mydb1
  AS REPLICA OF myorg.account1.mydb1
  DATA_RETENTION_TIME_IN_DAYS = 10;
Copy