ALTER TABLE (tables des événements)¶
Modifie les propriétés, les colonnes ou les contraintes d’une table d’événements existante.
- Voir aussi :
CREATE EVENT TABLE , DROP TABLE , SHOW EVENT TABLES , DESCRIBE EVENT TABLE
Syntaxe¶
ALTER TABLE [ IF EXISTS ] <name> RENAME TO <new_table_name>
ALTER TABLE [ IF EXISTS ] <name> clusteringAction
ALTER TABLE [ IF EXISTS ] <name> dataGovnPolicyTagAction
ALTER TABLE [ IF EXISTS ] <name> searchOptimizationAction
ALTER TABLE [ IF EXISTS ] <name> SET
[ DATA_RETENTION_TIME_IN_DAYS = <integer> ]
[ MAX_DATA_EXTENSION_TIME_IN_DAYS = <integer> ]
[ CHANGE_TRACKING = { TRUE | FALSE } ]
[ COMMENT = '<string_literal>' ]
ALTER TABLE [ IF EXISTS ] <name> UNSET {
DATA_RETENTION_TIME_IN_DAYS |
MAX_DATA_EXTENSION_TIME_IN_DAYS |
CHANGE_TRACKING |
COMMENT |
}
Où :
clusteringAction ::= { CLUSTER BY ( <expr> [ , <expr> , ... ] ) | { SUSPEND | RESUME } RECLUSTER | DROP CLUSTERING KEY }dataGovnPolicyTagAction ::= { SET TAG <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' ... ] | UNSET TAG <tag_name> [ , <tag_name> ... ] } | { ADD ROW ACCESS POLICY <policy_name> ON ( <col_name> [ , ... ] ) | DROP ROW ACCESS POLICY <policy_name> | DROP ROW ACCESS POLICY <policy_name> , ADD ROW ACCESS POLICY <policy_name> ON ( <col_name> [ , ... ] ) | DROP ALL ROW ACCESS POLICIES }searchOptimizationAction ::= { ADD SEARCH OPTIMIZATION [ ON <search_method_with_target> [ , <search_method_with_target> ... ] ] | DROP SEARCH OPTIMIZATION [ ON { <search_method_with_target> | <column_name> | <expression_id> } [ , ... ] ] }Pour plus de détails, voir Actions d’optimisation de la recherche (searchOptimizationAction).
Paramètres¶
name
Identificateur de la table d’événements à modifier. Si l’identificateur contient des espaces ou des caractères spéciaux, toute la chaîne doit être délimitée par des guillemets doubles. Les identificateurs entre guillemets doubles sont également sensibles à la casse.
RENAME TO new_table_name
Renomme la table d’événements spécifiée avec un nouvel identificateur qui n’est actuellement utilisé par aucune autre table d’événements du schéma.
Pour plus de détails sur les identificateurs de table d’événement, voir Exigences relatives à l’identificateur.
Vous pouvez déplacer l’objet vers une autre base de données et/ou un autre schéma tout en renommant éventuellement l’objet. Pour ce faire, spécifiez une valeur
new_name
qualifiée qui inclut le nouveau nom de la base de données et/ou du schéma sous la formedb_name.schema_name.object_name
ouschema_name.object_name
, respectivement.Note
La base de données et/ou le schéma de destination doivent déjà exister. En outre, un objet portant le même nom ne peut pas déjà exister dans le nouvel emplacement ; sinon, l’instruction renvoie une erreur.
Le déplacement d’un objet vers un schéma d’accès géré est interdit sauf si le propriétaire de l’objet (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur l’objet) est également propriétaire du schéma cible.
Lorsqu’un objet (table, colonne, etc.) est renommé, les autres objets qui le référencent doivent être mis à jour avec le nouveau nom.
SET ...
Spécifie un(e) ou plusieurs paramètre(s)/propriété(s) à définir pour la table d’événement (séparés par des espaces, des virgules ou de nouvelles lignes) :
DATA_RETENTION_TIME_IN_DAYS = integer
Paramètre au niveau de l’objet qui modifie la période de conservation de la table d’événements pour Time Travel. Pour plus de détails, voir Comprendre et utiliser la fonction « Time Travel » et Utilisation de tables temporaires et transitoires.
Pour une description détaillée de ce paramètre, ainsi que pour plus d’informations sur les paramètres d’objet, voir Paramètres.
Valeurs :
Édition Standard :
0
ou1
Édition Enterprise :
De
0
à90
pour les tables d’événements permanentes0
ou1
pour les tables d’événements temporaires et transitoires
Note
Une valeur de
0
désactive effectivement Time Travel pour la table d’événements.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 de la table d’événements, afin d’éviter que les flux sur la table d’événements ne deviennent obsolètes.
Pour une description détaillée de ce paramètre, voir MAX_DATA_EXTENSION_TIME_IN_DAYS.
CHANGE_TRACKING = TRUE | FALSE
Spécifie d’activer ou de désactiver le suivi des modifications sur la table d’événements.
TRUE
active le suivi des modifications sur la table d’événements. Cette option ajoute une paire de colonnes masquées à la table d’événement source et commence à stocker les métadonnées de suivi des modifications dans les colonnes. Ces colonnes consomment une petite quantité de stockage.Les métadonnées de suivi des modifications peuvent être interrogées à l’aide de la clause CHANGES pour les instructions SELECT, ou en créant et en interrogeant un ou plusieurs flux sur la table d’événement.
FALSE
désactive le suivi des modifications sur la table d’événements. La paire de colonnes masquées est détruite de la table d’événements.
COMMENT = 'string_literal'
Ajoute un commentaire ou écrase le commentaire existant pour la table d’événements.
UNSET ...
Spécifie un(e) ou plusieurs paramètres/propriété(s) à désactiver pour la table d’événement, ce qui les réinitialise à leurs valeurs par défaut :
DATA_RETENTION_TIME_IN_DAYS
MAX_DATA_EXTENSION_TIME_IN_DAYS
CHANGE_TRACKING
COMMENT
Politique de gouvernance des données et actions de balises (dataGovnPolicyTagAction
)¶
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 d’informations sur la spécification des balises dans une instruction, voir Quotas de balises pour les objets et les colonnes.
policy_name
Identificateur de la politique ; doit être unique pour votre schéma.
Les clauses suivantes s’appliquent à tous les types de tables qui prennent en charge les politiques d’accès aux lignes, notamment les tables, les vues et les tables d’événements. Pour simplifier, les clauses font simplement référence à la « table ».
ADD ROW ACCESS POLICY policy_name ON (col_name [ , ... ])
Ajoutez la politique d’accès aux lignes à la table.
Au moins un nom de colonne doit être spécifié. Des colonnes supplémentaires peuvent être spécifiées en séparant chaque nom de colonne par une virgule. Utilisez cette expression pour ajouter une politique d’accès aux lignes à la fois à une table d’événements et à une table externe.
DROP ROW ACCESS POLICY policy_name
Supprime une politique d’accès aux lignes de la table.
Utilisez cette clause pour supprimer la politique de la table.
DROP ROW ACCESS POLICY policy_name, ADD ROW ACCESS POLICY policy_name ON ( col_name [ , ... ] )
Supprime la politique d’accès aux lignes définie sur la table et ajoute une politique d’accès aux lignes pour la même table en une seule instruction SQL.
DROP ALL ROW ACCESS POLICIES
Supprime toutes les associations de politique d’accès aux lignes d’une table.
Cette expression est utile lorsqu’une politique d’accès aux lignes est détruite d’un schéma avant de détruire la politique d’une table d’événements. Utilisez cette expression pour supprimer les associations de politiques d’accès aux ligne de la table.
SET AGGREGATION POLICY policy_name [ FORCE ]
Attribue une politique d’agrégation à la table. Utilisez le paramètre facultatif FORCE pour remplacer atomiquement une politique d’agrégation existante par la nouvelle politique d’agrégation.
UNSET AGGREGATION POLICY
Détache une politique d’agrégation de la table.
Action de clustering (clusteringAction
)¶
CLUSTER BY ( expr [ , expr , ... ] )
Spécifie (ou modifie) une ou plusieurs colonnes de table d’événements ou expressions de colonne en tant que clé de clustering pour la table d’événements. Ce sont les colonnes/expressions pour lesquelles le clustering est assuré par le clustering automatique.
Important
Les clés de clustering ne sont pas recommandées ni conçues pour toutes les tables d’événements. Elles sont généralement intéressantes pour les tables d’événements très importantes (de plusieurs téraoctets).
Avant de spécifier une clé de clustering pour une table d’événements, consultez Fonctionnement des structures de table dans Snowflake.
SUSPEND | RESUME RECLUSTER
Active ou désactive Clustering automatique pour la table d’événements.
DROP CLUSTERING KEY
Détruit la clé de clustering pour la table d’événements.
Pour plus d’informations sur les clés de clustering et le reclustering à proprement parler, voir Fonctionnement des structures de table dans Snowflake.
Actions d’optimisation de la recherche (searchOptimizationAction
)¶
ADD SEARCH OPTIMIZATION
Ajoute l’optimisation de recherche pour la table d’événement entière ou, si vous spécifiez la clause ON facultative, pour des colonnes spécifiques.
Remarque :
L’optimisation de la recherche peut être coûteuse à maintenir, en particulier si les données de la table d’événements changent fréquemment. Pour plus d’informations, voir Optimisation de la recherche - Estimation et gestion des coûts.
Si vous essayez d’ajouter une optimisation de recherche sur une vue matérialisée, Snowflake renvoie un message d’erreur.
ON search_method_with_target [, search_method_with_target ... ]
Spécifie que vous voulez configurer l’optimisation de la recherche pour des colonnes ou des champs VARIANT spécifiques (plutôt que pour la table d’événement entière).
Pour
search_method_with_target
, utilisez une expression avec la syntaxe suivante :<search_method>(<target> [, ...])
Où :
search_method
spécifie l’une des méthodes suivantes qui optimisent les requêtes pour un type particulier de prédicat :Méthode de recherche
Description
EQUALITY
Prédicats d’égalité et IN
SUBSTRING
Prédicats qui correspondent à des sous-chaînes et à des expressions régulières (par exemple, [ NOT ] LIKE, [ NOT ] ILIKE, [ NOT ] RLIKE, REGEXP_LIKE, etc.)
GEO
Prédicats qui utilisent des types GEOGRAPHY.
target
spécifie la colonne, le champ VARIANT ou un astérisque (*).En fonction de la valeur de
search_method
, vous pouvez spécifier une colonne ou un champ VARIANT de l’un des types suivants :Méthode de recherche
Cibles prises en charge
EQUALITY
Colonnes de types numérique, chaîne, binaire et VARIANT, y compris les chemins d’accès aux champs dans des VARIANTs.
Pour spécifier un champ VARIANT, utilisez un chemin d’accès au champ délimité par deux points (par exemple,
my_column:my_field_name:my_nested_field_name
) ou utilisez la notation points ou parenthèses (par exemple,my_column:my_field_name.my_nested_field_name
oumy_column['my_field_name']['my_nested_field_name']
).Lorsque vous spécifiez un champ VARIANT, la configuration s’applique à tous les champs imbriqués sous ce champ. Par exemple, supposons que vous spécifiez
ON EQUALITY(src:a.b)
:Cette configuration peut améliorer les requêtes
on src:a.b
et sur tous les champs imbriqués (par exemplesrc:a.b.c
,src:a.b.c.d
, etc.).Cette configuration n’affecte pas les requêtes qui n’utilisent pas le préfixe
src:a.b
(par exemple,src:a
,src:z
, etc.).
SUBSTRING
Colonnes de types de données chaîne.
GEO
Colonnes du type de données GEOGRAPHY
Pour spécifier toutes les colonnes applicables de la table d’événements comme cibles, utilisez un astérisque (
*
).Notez que vous ne pouvez pas spécifier à la fois un astérisque et des noms de colonnes spécifiques pour une méthode de recherche donnée. Cependant, vous pouvez spécifier un astérisque dans différentes méthodes de recherche.
Par exemple, vous pouvez spécifier les expressions suivantes :
-- Allowed ON SUBSTRING(*) ON EQUALITY(*), SUBSTRING(*), GEO(*)
Vous ne pouvez pas spécifier les expressions suivantes :
-- Not allowed ON EQUALITY(*, c1) ON EQUALITY(c1, *) ON EQUALITY(v1:path, *) ON EQUALITY(c1), EQUALITY(*)
Pour spécifier plus d’une méthode de recherche sur une cible, utilisez une virgule pour séparer chaque méthode ultérieure et chaque cible :
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c1), EQUALITY(c2, c3);
Si vous exécutez la commande ALTER TABLE … ADD SEARCH OPTIMIZATION ON … sur la même table d’événements, chaque commande suivante s’ajoute à la configuration existante pour la table d’événements. Par exemple, supposons que vous ayez exécuté la commande suivante :
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c1, c2); ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c3, c4);
Cela ajoute des prédicats d’égalité pour les colonnes c1, c2, c3 et c4 à la configuration de la table d’événement. Ceci est équivalent à l’exécution de la commande :
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c1, c2, c3, c4);
Pour des exemples, voir Configuration de l’optimisation de la recherche pour des colonnes spécifiques.
DROP SEARCH OPTIMIZATION
Supprime l’optimisation de recherche pour l’ensemble de la table d’événement ou, si vous spécifiez la clause ON facultative, pour des colonnes spécifiques.
Remarque :
Si une table d’événements a la propriété d’optimisation de recherche, alors le fait de supprimer et de rétablir la table d’événements préserve la propriété d’optimisation de recherche.
La suppression de la propriété d’optimisation de recherche d’une table d’événements puis son rétablissement entraînent le même coût que lors du premier ajout.
ON search_method_with_target | column_name | expression_id [, ... ]
Spécifie que vous voulez détruire la configuration de l’optimisation de la recherche pour des colonnes ou des champs VARIANT spécifiques (plutôt que de détruire l’optimisation de la recherche pour la table d’événement entière).
Pour identifier la configuration de la colonne à détruire, spécifiez l’un des éléments suivants :
Pour
search_method_with_target
, spécifiez une méthode d’optimisation des requêtes pour une ou plusieurs cibles spécifiques, qui peuvent être des colonnes ou des champs VARIANT. Utilisez la syntaxe décrite précédemment.Pour
column_name
, spécifiez le nom de la colonne configurée pour l’optimisation de la recherche. La spécification du nom de la colonne détruit toutes les expressions pour cette colonne, y compris les expressions qui utilisent les champs VARIANT de la colonne.Pour
expression_id
, spécifiez l’ID d’une expression figurant dans la sortie de la commande DESCRIBE SEARCH OPTIMIZATION.
Pour en spécifier plusieurs, utilisez une virgule entre les éléments.
Vous pouvez spécifier toute combinaison de méthodes de recherche avec des cibles, des noms de colonnes et des IDs d’expressions.
Pour des exemples, voir Suppression de l’optimisation de la recherche pour des colonnes spécifiques.
Notes sur l’utilisation¶
Les modifications apportées à une table d’événements ne sont pas automatiquement propagées aux vues créées sur cette table d’événements.
Pour modifier une table d’événements, vous devez utiliser un rôle disposant du privilège de propriété sur la table d’événements.
Pour ajouter un clustering à une table d’événements, vous devez également disposer des privilèges USAGE ou OWNERSHIP sur le schéma et la base de données qui contiennent la table d’événements.
Pour les politiques d’accès aux lignes :
Snowflake prend en charge l’ajout et la suppression des politiques d’accès aux lignes dans une seule instruction SQL.
Par exemple, pour remplacer une politique d’accès aux lignes déjà définie sur une table par une politique différente, il faut d’abord détruire la politique d’accès aux lignes, puis ajouter la nouvelle politique d’accès aux lignes.
Pour une ressource donnée (c’est-à-dire une table ou une vue), pour
ADD
ouDROP
une politique d’accès aux lignes, vous devez disposer du privilège APPLY ROW ACCESS POLICY sur le schéma, ou du privilège OWNERSHIP sur la ressource et du privilège APPLY sur la ressource de la politique d’accès aux lignes.Une table ou une vue ne peut être protégée que par une seule politique d’accès aux lignes à la fois. L’ajout d’une politique échoue si le corps de la politique fait référence à une colonne de table ou de vue qui est protégée par une politique d’accès aux lignes ou à la colonne protégée par une politique de masquage.
De même, l’ajout d’une politique de masquage à une colonne de table échoue si le corps de la politique de masquage fait référence à une table qui est protégée par une politique d’accès aux lignes ou une autre politique de masquage.
Les politiques d’accès aux lignes ne peuvent pas être appliquées aux vues système ou aux fonctions de table.
Comme pour les autres opérations DROP <objet>, Snowflake renvoie une erreur en cas de tentative de destruction d’une politique d’accès aux lignes d’une ressource à laquelle aucune politique d’accès aux lignes n’a été ajoutée.
Si un objet possède à la fois une politique d’accès aux lignes et une ou plusieurs politiques de masquage, la politique d’accès aux lignes est évaluée en premier.
Si vous créez une clé étrangère, les colonnes de la clause
REFERENCES
doivent être répertoriées dans le même ordre que les celles répertoriées pour la clé primaire. Par exemple :create table parent ... constraint primary_key_1 primary key (c_1, c_2) ... create table child ... constraint foreign_key_1 foreign key (...) REFERENCES parent (c_1, c_2) ...
Dans les deux cas, l’ordre des colonnes est
c_1, c_2
. Si l’ordre des colonnes de la clé étrangère avait été différent (par exemple,c_2, c_1
), la tentative de création de la clé étrangère aurait échoué.
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.
ALTER TABLE … CHANGE_TRACKING = TRUE
Lorsqu’une table d’événements est modifiée pour permettre le suivi des modifications, elle est verrouillée pour la durée de l’opération. Les verrous peuvent entraîner une latence avec certaines opérations DDL/DML associées. Pour plus d’informations, reportez-vous à Verrouillage des ressources.
Exemples¶
Renommer la table d’événements t1
en a1
:
CREATE OR REPLACE TABLE t1(a1 number); SHOW TABLES LIKE 't1'; ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+ created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+ Tue, 17 Mar 2015 16:52:33 -0700 | T1 | TESTDB | MY_SCHEMA | TABLE | | | 0 | 0 | PUBLIC | 1 | ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+ ALTER TABLE t1 RENAME TO tt1; SHOW TABLES LIKE 'tt1'; ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+ created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+ Tue, 17 Mar 2015 16:52:33 -0700 | TT1 | TESTDB | MY_SCHEMA | TABLE | | | 0 | 0 | PUBLIC | 1 | ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+
Modifier l’ordre de la clé de clustering pour une table d’événements :
CREATE OR REPLACE TABLE T1 (id NUMBER, date TIMESTAMP_NTZ, name STRING) CLUSTER BY (id, date); SHOW TABLES LIKE 'T1'; ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------------+----------------+ created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------------+----------------+ Tue, 21 Jun 2016 15:42:12 -0700 | T1 | TESTDB | TESTSCHEMA | TABLE | | (ID,DATE) | 0 | 0 | ACCOUNTADMIN | 1 | ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------------+----------------+ -- Change the order of the clustering key ALTER TABLE t1 CLUSTER BY (date, id); SHOW TABLES LIKE 'T1'; ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------------+----------------+ created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------------+----------------+ Tue, 21 Jun 2016 15:42:12 -0700 | T1 | TESTDB | TESTSCHEMA | TABLE | | (DATE,ID) | 0 | 0 | ACCOUNTADMIN | 1 | ---------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+--------------+----------------+
L’exemple suivant ajoute une politique d’accès aux lignes sur une table d’événements en spécifiant une seule colonne. Après avoir défini la politique, vous pouvez vérifier en contrôlant Information Schema.
ALTER TABLE t1 ADD ROW ACCESS POLICY rap_t1 ON (empl_id);
L’exemple suivant ajoute une politique d’accès aux lignes tout en spécifiant deux colonnes dans une seule table d’événements.
ALTER TABLE t1 ADD ROW ACCESS POLICY rap_test2 ON (cost, item);
L’exemple suivant supprime une politique d’accès aux lignes d’une table d’événements. Vérifiez que les politiques ont été détruites en interrogeant Information Schema.
ALTER TABLE t1 DROP ROW ACCESS POLICY rap_v1;
L’exemple suivant montre comment combiner l’ajout et la destruction de politiques d’accès aux lignes dans une seule instruction SQL pour une table. Vérifiez les résultats en contrôlant Information Schema.
alter table t1 drop row access policy rap_t1_version_1, add row access policy rap_t1_version_2 on (empl_id);