Schéma :

ACCOUNT_USAGE

Vue ACCESS_HISTORY

Cette vue Account Usage peut être utilisée pour interroger l’historique des accès aux objets Snowflake (par exemple, table, vue, colonne) au cours des 365 derniers jours (1 année).

Colonnes

Cette section comporte trois tables :

  • La première table donne un exemple de chaque valeur de colonne.

  • La deuxième table définit les colonnes de la vue ACCESS_HISTORY.

  • La troisième table définit les champs du tableau JSON pour les colonnes base_objects_accessed, direct_objects_accessed et objects_modified.

Nom de la colonne

Exemple

query_id

a0fda135-d678-4184-942b-c3411ae8d1ce

query_start_time

2022-01-25 16:17:47.388 +0000

user_name

JSMITH

direct_objects_accessed

[
  {
    "objectDomain": "FUNCTION",
    "objectName": "GOVERNANCE.FUNCTIONS.RETURN_SUM",
    "objectId": "2",
    "argumentSignature": "(NUM1 NUMBER, NUM2 NUMBER)",
    "dataType": "NUMBER(38,0)"
  },
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "CONTENT"
      }
    ],
    "objectDomain": "Table",
    "objectId": 66564,
    "objectName": "GOVERNANCE.TABLES.T1"
  }
]
Copy

base_objects_accessed

[
  {
    "objectDomain": "FUNCTION",
    "objectName": "GOVERNANCE.FUNCTIONS.RETURN_SUM",
    "objectId": "2",
    "argumentSignature": "(NUM1 NUMBER, NUM2 NUMBER)",
    "dataType": "NUMBER(38,0)"
  },
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "CONTENT"
      }
    ],
    "objectDomain": "Table",
    "objectId": 66564,
    "objectName": "GOVERNANCE.TABLES.T1"
  }
]
Copy

objects_modified

[
  {
    "objectDomain": "STRING",
    "objectId":  NUMBER,
    "objectName": "STRING",
    "columns": [
      {
        "columnId": "NUMBER",
        "columnName": "STRING",
        "baseSources": [
          {
            "columnName": STRING,
            "objectDomain": "STRING",
            "objectId": NUMBER,
            "objectName": "STRING"
          }
        ],
        "directSources": [
          {
            "columnName": STRING,
            "objectDomain": "STRING",
            "objectId": NUMBER,
            "objectName": "STRING"
          }
        ]
      }
    ]
  },
  ...
]
Copy

object_modified_by_ddl

{
  "objectDomain": STRING,
  "objectName": STRING,
  "objectId": NUMBER,
  "operationType": STRING,
  "properties": ARRAY
}
Copy

policies_referenced

[
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "SSN",
        "policies": [
          {
              "policyName": "governance.policies.ssn_mask",
              "policyId": 68811,
              "policyKind": "MASKING_POLICY"
          }
        ]
      }
    ],
    "objectDomain": "VIEW",
    "objectId": 66564,
    "objectName": "GOVERNANCE.VIEWS.V1",
    "policies": [
      {
        "policyName": "governance.policies.rap1",
        "policyId": 68813,
        "policyKind": "ROW_ACCESS_POLICY"
      }
    ]
  }
]
Copy

Nom de la colonne

Type de données

Description

query_id

TEXT

Identificateur interne, généré par le système pour l’instruction SQL. Cette valeur est également mentionnée dans le Vue QUERY_HISTORY.

query_start_time

TIMESTAMP_LTZ

Heure de début de l’instruction (fuseau UTC).

user_name

TEXT

Utilisateur qui a émis la requête.

direct_objects_accessed

ARRAY

Tableau JSON d’objets de données, tels que des fonctions définies par l’utilisateur (c’est-à-dire des UDFs et des UDTFs), des procédures stockées, des tables, des vues et des colonnes nommés directement dans la requête de manière explicite ou par des raccourcis comme l’utilisation d’un astérisque (c’est-à-dire *).

Des colonnes virtuelles peuvent être renvoyées dans ce champ.

Pour des remarques supplémentaires sur les UDFs, voir les Remarques sur les UDF (dans cette rubrique).

base_objects_accessed

ARRAY

Tableau JSON de tous les objets de données de base pour exécuter une requête, y compris les colonnes, les fonctions externes, les UDFs et les procédures stockées.

Dans cet exemple, les champs du premier tableau spécifient une UDF. Ces mêmes champs du premier tableau spécifient également une procédure stockée, le cas échéant.

Remarques :

  • Ce champ spécifie les noms de vue ou les colonnes de vue, y compris les colonnes virtuelles, si une vue partagée est accessible dans un compte de consommateur de partage de données.

  • Pour des remarques supplémentaires sur les UDFs, voir les Remarques sur les UDF (dans cette rubrique).

objects_modified

ARRAY

Un tableau JSON qui spécifie les objets qui ont été associés à une opération d’écriture dans la requête.

L’UDF et le tableau de procédures stockées sont identiques à ceux présentés précédemment et apparaissent dans les tableaux pour baseSources et directSources en fonction de la manière dont l’accès a eu lieu. Par souci de concision, cet exemple omet l’UDF et le tableau de procédures stockées.

Pour des remarques supplémentaires sur les UDFs, voir les Remarques sur les UDF (dans cette rubrique).

object_modified_by_ddl

OBJECT

Spécifie l’opération DDL sur une base de données, un schéma, une table, une vue et une colonne. Ces opérations comprennent également des instructions qui spécifient une politique d’accès aux lignes sur une table ou une vue, une politique de masquage sur une colonne et des mises à jour de balises (par exemple, définition d’une balise, modification d’une valeur de balise) sur l’objet ou la colonne.

policies_referenced

ARRAY

Spécifie des informations sur la politique de masquage appliquée à la colonne et la politique d’accès aux lignes appliquée à la table, y compris les politiques appliquées aux objets ou aux colonnes intermédiaires.

parent_query_id

TEXT

La requête ID de la tâche parent ou NULL si la tâche n’a pas de parent.

root_query_id

TEXT

La requête ID de la tâche la plus élevée de la chaîne ou NULL si la tâche n’a pas de parent.

Les champs du tableau JSON pour les colonnes direct_objects_accessed, base_objects_accessed, objects_modified et policies_referenced sont décrits ci-dessous.

Champ

Type de données

Description

columnId

NUMBER

ID de colonne qui est unique dans le compte. Cette valeur est identique à columnID de la vue COLUMNS.

columnName

TEXT

Nom de la colonne à laquelle on accède. Pour les politiques, spécifie la colonne sur laquelle la politique de masquage est définie.

objectId

NUMBER

Un identificateur pour l’objet, qui est unique dans un compte et un domaine donnés. Ce numéro correspondra :

  • Au numéro TABLE_ID pour une table, une vue, et une vue matérialisée.

  • S’il y a eu un accès à la zone de préparation, ce numéro correspondra :

    • À l’identificateur NAME pour un utilisateur (zone de préparation de l’utilisateur).

    • Au numéro TABLE_ID pour une table (zone de préparation de table).

    • Au numéro STAGE_ID pour une zone de préparation (zone de préparation nommée).

objectName

TEXT

Nom entièrement qualifié de l’objet auquel on a accédé.

Si une politique de masquage est définie sur une colonne ou si une politique d’accès aux lignes est définie sur une table ou une vue, la valeur fait référence au nom complet de la table ou de la vue sur laquelle la politique d’accès aux lignes est définie ou la vue qui a une politique de masquage définie sur l’une de ses colonnes.

S’il y a eu un accès à la zone de préparation, cette valeur sera :

  • username (zone de préparation de l’utilisateur).

  • table_name (zone de préparation de table).

  • stage_name (zone de préparation nommée).

objectDomain

TEXT

Un des éléments suivants : EXTERNAL TABLE, FUNCTION, MATERIALIZED VIEW, PROCEDURE, STAGE, STREAM, ou VIEW.

Notez que FUNCTION spécifie des UDFs, des UDTFs et des fonctions externes.

Pour les politiques, spécifie le domaine de l’objet sur lequel la politique d’accès aux lignes est définie.

emplacement

TEXT

L’URL de l’emplacement externe lorsque l’accès aux données est un emplacement externe (par exemple, s3://mybucket/a.csv). . Si la requête n’accède pas à une zone de préparation, ce champ est omis.

stageKind

TEXT

Lors de l’écriture sur une zone de préparation, l’un des éléments suivants : Table | User | Internal Named | External Named Si la requête n’accède pas à une étape, ce champ est omis.

baseSources

TEXT

Les colonnes qui servent de colonnes sources pour les colonnes spécifiées par directSources. Ces colonnes facilitent la lignée des colonnes.

directSources

TEXT

Les colonnes spécifiquement mentionnées dans la partie write des données de l’instruction SQL qui sert de colonnes sources dans la table cible dans laquelle les données sont écrites. Ces colonnes facilitent la lignée des colonnes.

policyName

TEXT

Nom complet de la politique.

policyId

NUMBER

Un identificateur pour la politique, qui est unique dans un compte et un domaine donnés. Cette valeur correspond à l’identificateur d’une politique de masquage dans la Vue MASKING_POLICIES ou à l’identificateur d’une politique d’accès aux lignes dans la Vue ROW_ACCESS_POLICIES

policyKind

TEXT

Soit MASKING_POLICY soit ROW_ACCESS_POLICY

argumentSignature

TEXT

Nom et type de données de chaque argument de l’UDF ou de la procédure stockée.

dataType

Type de données de la valeur renvoyée pour une UDF ou une procédure stockée.

Cette valeur permet de différencier deux UDFs ou plus qui ont le même nom, mais des types de retour différents.

Les champs de la colonne object_modified_by_ddl sont décrits ci-dessous.

fieldName

Type de données

Description

objectDomain

TEXT

Domaine de l’objet défini ou modifié par l’opération DDL, qui comprend tous les objets pouvant être balisés et MASKING POLICY | ROW ACCESS POLICY | TAG.

objectId

NUMBER

Identificateur de l’objet, qui est unique au sein d’un compte et d’un domaine donnés, défini ou modifié par l’opération DDL.

objectName

TEXT

Nom complet de l’objet défini ou modifié par l’opération DDL.

operationType

TEXT

Mot-clé SQL qui spécifie l’opération sur la table, la vue ou la colonne : ALTER | CREATE | DROP | REPLACE | UNDROP

properties

ARRAY

Tableau JSON qui spécifie les propriétés de l’objet ou de la colonne lorsque vous créez, modifiez ou supprimez l’objet ou la colonne ou que vous annulez sa suppression. Il existe deux types de propriétés : atomiques et composées.

Pour le champ properties :

  • Atomique : une valeur par propriété (par exemple, un comment a une seule valeur de chaîne, la propriété enabled est un booléen et a une seule valeur).

  • Composé : la propriété peut avoir plusieurs valeurs (par exemple allowed_values pour une balise, une politique de masquage).

Les propriétés composées sont enregistrées dans un tableau JSON. Par exemple, si une table contient une seule colonne nommée EMAIL, la colonne est enregistrée comme suit :

columns: {
  "email": {
    objectId: {
      "value": 1
    },
    "subOperationType": "ADD"
  }
}
Copy

La valeur subOperationType peut être l’une des valeurs suivantes :

  • ADD spécifie l’ajout d’une propriété composée (par exemple, ajouter une colonne, définir les valeurs autorisées).

  • DROP spécifie la suppression d’une propriété composée.

  • ALTER spécifie la modification d’une propriété composée.

Le objectId spécifie l’identificateur de la colonne ou de l’objet, à l’exception des valeurs de balises autorisées qui n’ont pas d’identificateur.

Notes sur l’utilisation

Latence et données historiques:
  • La vue affiche les données à partir de 22 février 2021.

  • La latence pour la vue peut atteindre 180 minutes (3 heures).

Requêtes ancêtres:

Les colonnes parent_query_id et root_query_id commencent à enregistrer des données à partir du 15-16 janvier 2024, en fonction de la date à laquelle votre compte Snowflake a été mis à jour sur la base de la grappe du bundle de changements de comportement 2023_08 passant au statut Activé par défaut. Cette date est nécessaire pour distinguer les enregistrements suivants dans la vue :

  • Requêtes exécutées avant que le bundle ne soit activé par défaut.

  • Requêtes qui ont été exécutées après l’activation par défaut de la fonctionnalité, mais qui n’ont pas de valeur dans le champ parent_query_id.

Tables hybrides:

Les requêtes de courte durée qui utilisent exclusivement des tables hybrides ne génèrent plus d’enregistrement dans la vue QUERY_HISTORY, dans QUERY_HISTORY, ou dans la sortie de la fonction de table QUERY_HISTORY. Pour surveiller ces requêtes, utilisez la fonction AGGREGATE_QUERY_HISTORY.

Pour surveiller l’historique des accès pour de telles requêtes, utilisez la vue AGGREGATE_ACCESS_HISTORY. Cette vue vous permet de surveiller plus facilement les charges de travail opérationnelles à haut débit pour l’historique des accès.

Notes générales:
  • Pour améliorer les performances, filtrez les requêtes sur la colonne query_start_time et choisissez des périodes plus restreintes. Pour des exemples de requêtes, voir Interrogation de la vue ACCESS_HISTORY Vue.

  • Vues sécurisées. L’enregistrement du journal contient la table de base sous-jacente (c’est-à-dire base_objects_accessed) pour générer la vue. Les exemples incluent des requêtes sur d’autres vues Account Usage et Utilisation de l’organisation, et des requêtes sur des tables de base pour des opérations d’extraction, de transformation et de chargement (c’est-à-dire ETL).

  • Les enregistrements de la vue QUERY_HISTORY ne sont pas toujours enregistrés dans la vue ACCESS_HISTORY. La structure de l’instruction SQL détermine si Snowflake enregistre une entrée dans la vue ACCESS_HISTORY.

  • En spécifiant la clause USING lors de l’interrogation de cette vue, des colonnes non référencées peuvent être enregistrées dans le champ direct_objects_accessed. Comme solution de rechange, remplacez la clause USING par une clause JOIN ... ON .... Pour plus de détails, reportez-vous à :

Remarques sur les requêtes de lecture:

Cette vue prend en charge les requêtes de type lecture suivantes :

  • SELECT dont CREATE TABLE … AS SELECT (c’est-à-dire CTAS).

    • Snowflake enregistre la sous-requête SELECT dans une opération CTAS.

  • CREATE TABLE … CLONE

    • Snowflake enregistre la table source dans une opération CLONE.

  • COPY INTO … TABLE

    • Snowflake enregistre cette requête seulement lorsque la table est spécifiée comme source dans une clause FROM.

  • Opérations DML qui lisent des données (par exemple, contient une sous-requête SELECT, spécifie certaines colonnes dans WHERE ou JOIN) : INSERT … SELECT, UPDATE, DELETE et MERGE.

  • UDFs et UDFs SQL tabulaires (UDTFs) si les tables sont incluses dans les requêtes à l’intérieur des fonctions. Ceci est enregistré dans le champ base_objects_accessed.

    Pour plus de détails sur les UDFs, voir les remarques sur les UDF (dans cette rubrique).

Remarques sur les opérations d’écriture:

Cette vue prend en charge les opérations d’écriture du type suivant :

  • GET <zone_de_préparation_interne>

  • PUT <zone_de_préparation_interne>

  • DELETE

  • TRUNCATE

  • INSERT

    • INSERT INTO … FROM SELECT *

    • INSERT INTO TABLE … VALUES ()

  • MERGE INTO … FROM SELECT *

  • UPDATE

    • UPDATE TABLE … FROM SELECT * FROM …

    • UPDATE TABLE … WHERE …

  • Instructions de chargement de données :

    • COPY INTO TABLE FROM internalStage

    • COPY INTO TABLE FROM externalStage

    • COPY INTO TABLE FROM externalLocation

  • Instructions de déchargement des données :

    • COPY INTO internalStage FROM TABLE

    • COPY INTO externalStage FROM TABLE

    • COPY INTO externalLocation FROM TABLE

  • CREATE:

    • CREATE DATABASE … CLONE

    • CREATE SCHEMA … CLONE

    • CREATE TABLE … CLONE

    • CREATE TABLE … AS SELECT

  • Pour les opérations d’écriture qui font appel à la fonction CASE pour déterminer les colonnes auxquelles accéder, comme une instruction CTAS avec la fonction CASE dans la requête SELECT, toutes les colonnes référencées dans chaque branche CASE sont enregistrées dans la colonne base_objects_accessed, la colonne direct_objects_accessed, ou les deux colonnes selon la façon dont l’instruction CTAS est écrite.

Remarques sur le partage des données:

Si un compte de fournisseur Data Sharing partage des objets avec des comptes de consommateurs Data Sharing par le biais d’un partage :

  • Comptes de fournisseurs : les requêtes et les journaux sur les objets partagés exécutés dans le compte de fournisseur ne seront pas visibles pour les comptes de consommateurs de partage de données.

  • Comptes de consommateurs : les requêtes sur le partage de données exécutées dans le compte de consommateur sont enregistrées et uniquement visibles par le compte de consommateur, et non par le compte de fournisseur de partage de données.

    Par exemple, si le fournisseur partage une table et une vue construite à partir de la table avec le compte de consommateur, et qu’il y a une requête sur la vue partagée, Snowflake enregistre l’accès à la vue partagée dans la colonne base_objects_accessed. Cet enregistrement, qui comprend les valeurs columnName et objectName , permet au consommateur de savoir à quel objet on a accédé dans son compte et protège également le fournisseur, car la table sous-jacente (via objectId et columnId) n’est pas révélée au consommateur.

  • Pour la lignée de colonnes :

    Si un fournisseur de partage de données met une vue à la disposition du consommateur du partage de données, les colonnes sources de la vue ne sont pas visibles pour le consommateur car les colonnes proviennent du fournisseur du partage de données.

    Si le consommateur de partage de données déplace les données de la vue partagée vers une table, Snowflake n’enregistre pas les colonnes de la vue comme baseSources pour la table qui vient d’être créée.

  • Pour les UDFs et les UDTFs partagées :

    • Dans le compte du consommateur, la vue locale ACCESS_HISTORY enregistre l’UDF/UDTF qui a été partagée par le fournisseur lorsque l’UDF/UDTF partagée est invoquée par le consommateur.

    • Dans le compte du fournisseur, la vue locale ACCESS_HISTORY enregistre l’utilisation par le fournisseur d’une UDF/UDTF partagée. Les utilisateurs du compte du consommateur ne peuvent pas voir comment le compte du fournisseur utilise l’UDF/UDTF partagée.

  • Pour le suivi des références des politiques :

    La colonne policies_referenced contient des politiques qui sont locales au compte qui interroge les données.

    Si un fournisseur partage une table protégée par une politique et qu’un consommateur accède à cette table, le consommateur ne peut pas voir la politique que le fournisseur a définie sur la table ou ses colonnes.

    Si un consommateur crée une vue (v1) à partir de l’objet partagé, définit une politique pour la vue (v1) ou ses colonnes, et qu’un utilisateur du compte du consommateur accède à la vue protégée (v1) ou à une autre vue (v2) créée à partir de la vue protégée (v1), la vue ACCESS_HISTORY du compte du consommateur contient la politique qui protège la vue (v1) et ses colonnes. Le fournisseur ne peut pas voir l’enregistrement qui correspond à v1.

Remarques Snowflake Native App Framework:

Certaines requêtes liées à une Snowflake Native App sont expurgées. Pour plus de détails, voir Informations expurgées des commandes et des vues SQL..

Notes de masquage basées sur les balises:

Si un utilisateur accède à une table ou à une vue protégée par une politique de masquage basée sur des balises, la colonne policies_referenced contient la politique de masquage appliquée par le biais de la balise lorsque Snowflake applique la politique de masquage sur la colonne protégée.

La vue ACCESS_HISTORY n’enregistre pas d’informations sur les balises.

Remarques sur les UDFs et les procédures stockées:

Ces notes s’appliquent aux fonctions externes, aux UDFs et aux UDTFs pour tous les langages, y compris lorsque ces fonctions ont la propriété SECURE et aux procédures stockées avec les droits du propriétaire et les droits de l’appelant :

Détails des colonnes :

  • La colonne direct_objects_accessed enregistre la mention explicite de ces fonctions et procédures dans une requête.

    Snowflake n’enregistre pas les UDFs imbriqués (c’est-à-dire une UDF mentionnée dans la définition d’un autre UDF) dans cette colonne.

  • La colonne base_objects_accessed enregistre les fonctions externes, les fonctions partagées, les UDFs non-SQL et les procédures stockées qui sont appelées dans une requête.

  • La colonne objects_modified enregistre :

    • Les UDF/UDTF lorsque le résultat de l’appel de la fonction copie le résultat dans une autre colonne.

    • Les UDF, les UDTF et une fonction externe peuvent être enregistrés dans les tableaux pour baseSources et directSources en fonction de la façon dont la requête est écrite.

Non pris en charge:

Cette vue n’enregistre pas les accès des types suivants :

  • Fonctions de table fournies par Snowflake, vues Account Usage et vues Utilisation de l’organisation.

  • RESULT_SCAN pour obtenir des résultats antérieurs.

  • Les séquences, notamment la génération de nouvelles valeurs.

  • Les vues intermédiaires accessibles entre la table de base et l’objet direct.

    Par exemple, considérons une requête sur View_A avec la structure d’objet suivante : View_A » View_B » View_C » Base_Table.

    La vue ACCESS_HISTORY enregistre la requête sur la Vue_A et la Table_base, pas sur la Vue_A ni la Vue_B.

  • Les opérations de mise à jour des flux.

  • Mouvement de données résultant de la réplication.

Notes sur l’utilisation : lignée de colonnes

Ces notes supplémentaires se rapportent à la lignée des colonnes :

Opérations prises en charge:

La lignée de colonnes suit les détails des opérations SQL suivantes :

Conditions de la requête:
  • Profil/plan de requête

    Le plan de requête que Snowflake écrit détermine si la vue ACCESS_HISTORY contient la lignée des colonnes. Si une colonne doit être évaluée dans le cadre du plan de requête, Snowflake contient la colonne dans la vue ACCESS_HISTORY, même si le résultat final du plan de requête est que la colonne n’est pas incluse dans le résultat final.

    Par exemple, considérez l’instruction INSERT suivante avec une clause WHERE pour une valeur de colonne particulière :

    insert into a(c1)
    select c2
    from b
    where c3 > 1;
    
    Copy

    Même si la clause WHERE est évaluée à FALSE, Snowflake enregistre la colonne c2 comme une colonne source pour la colonne c1. La colonne c3 n’est pas répertoriée comme une colonne source pour baseSources ou directSources.

  • Colonnes masquées :

    • La colonne masquée est toujours répertoriée dans le champ directSources.

    • L’enregistrement dans le champ baseSources dépend de la définition de la politique. Par exemple :

      • Si les conditions de la politique de masquage utilisent une fonction CASE, alors toutes les colonnes référencées dans chacune des branches CASE sont enregistrées dans le champ baseSources.

      • Si les conditions de la politique de masquage ne spécifient qu’une valeur constante (par exemple, *****), le champ baseSources est vide.

  • UDFs :

    • Lorsqu’on valide une colonne en argument dans une UDF et qu’on écrit le résultat dans une autre colonne, la colonne validée en argument est enregistrée dans le champ directSources. Par exemple :

      insert into A(col1) select f(col2) from B;
      
      Copy

      Dans cet exemple, Snowflake enregistre col2 dans le champ directSources parce que la colonne est un argument pour l’UDF nommée f.

    • L’enregistrement dans le champ baseSources dépend de la définition de l’UDF.

Colonnes Vue:

Les colonnes Vue ne sont pas considérées comme des colonnes sources et ne sont pas répertoriées dans le champ baseSources lorsque les données d’une colonne de vue sont copiées dans une colonne de table. Dans ce cas, les colonnes de vue sont énumérées dans le champ directSources.

Sous-requête EXISTS:

Les colonnes qui sont référencées dans la clause de sous-requête EXISTS ne sont pas considérées comme des colonnes sources.

Notes sur l’utilisation : colonne object_modified_by_ddl

  • Clauses IF [ NOT ] EXISTS : la colonne object_modified_by_ddl n’enregistre que CREATE ou REPLACE lors de la création ou de la modification d’un objet.

  • Snowflake prend en charge les domaines d’objets suivants.

    • Table et table externe.

    • Vue et vue matérialisée.

    • Schéma

    • Base de données.

La colonne enregistre ces changements sur la base des opérations SQL suivantes. Les opérations DROP et UNDROP s’appliquent aux tables et aux vues, et non aux colonnes.

CREATE OR REPLACE

ALTER ... { SET | UNSET }

ALTER ... ADD ROW ACCESS POLICY

ALTER ... DROP ROW ACCESS POLICY

ALTER ... DROP ALL ROW ACCESS POLICIES

DROP | UNDROP
Copy

La table suivante résume la relation entre les opérations DDL, les domaines pris en charge et les propriétés enregistrées par Snowflake.

Fonctionnement

Domaine

Propriétés

Remarques

CREATE [ OR REPLACE ]

TABLE | EXTERNAL TABLE | VIEW | MATERIALIZED VIEW

Nom de la colonne, identificateur de la colonne.

Les opérations CREATE DATABASE et CREATE SCHEMA n’ont pas de propriétés enregistrées.

CREATE

TABLE … { AS SELECT | USING TEMPLATE | LIKE | CLONE }

Nom de la colonne, identificateur de la colonne.

Snowflake enregistre la source de création pour les opérations LIKE et CLONE.

Snowflake n’enregistre pas la source de création lorsque l’objet source provient d’un partage ou est créé avec la clause USING TEMPLATE.

ALTER … RENAME TO

ALTER TABLE … RENAME COLUMN

TABLE | VIEW | MATERIALIZED VIEW | DATABASE | SCHEMA

Le nouveau nom de l’objet ou de la colonne.

ALTER … SWAP WITH

TABLE | SCHEMA | DATABASE

objectName, objectId, objectDomain

La vue comporte deux enregistrements, un pour chaque cible d’échange. Chaque enregistrement contient la même valeur d’identificateur de requête.

ALTER … { ADD | DROP } COLUMN

TABLE

Nom de la colonne, identificateur de la colonne et ADD ou DROP subOperationType.

DROP

TABLE | VIEW | MATERIALIZED VIEW | DATABASE | SCHEMA

Snowflake n’enregistre pas les propriétés de ces opérations.

UNDROP

TABLE | SCHEMA | DATABASE

Snowflake n’enregistre pas les propriétés de ces opérations.