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

Astuce

Notez que cette vue enregistre des informations sur les opérations de lecture. Snowflake prend en charge les opérations d’écriture dans cette vue en tant que fonctionnalité en avant-première. Pour plus d’informations, voir Opérations d’écriture dans la vue ACCESS_HISTORY.

Colonnes¶

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 horaireUTC).
USER_NAME	TEXT	Utilisateur qui a émis la requête.
DIRECT_OBJECTS_ACCESSED	ARRAY	Tableau JSON d’objets de données, tels que 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.
BASE_OBJECTS_ACCESSED	ARRAY	Tableau JSON de tous les objets de données de base, plus précisément, les colonnes des tables pour exécuter la requête. . Remarque : ce champ ne spécifiera jamais de noms de vues ou de colonnes de vues, y compris les colonnes virtuelles.

La requête dans Snowflake et la façon dont les objets de la base de données ont été créés déterminent les informations que Snowflake renvoie pour DIRECT_OBJECTS_ACCESSED et BASE_OBJECTS_ACCESSED.

Par exemple, considérons la série d’objets suivante : base_table » view_1 » view_2 » view_3.

Si une requête est effectuée sur view_2, Snowflake renvoie view_2 comme DIRECT_OBJECTS_ACCESSED car view_2 a été spécifié dans la requête. base_table est enregistré comme BASE_OBJECTS_ACCESSED car c’est la source d’origine des données dans view_2.

Dans cet exemple, view_1 et view_3 ne doivent pas être incluses dans DIRECT_OBJECTS_ACCESSED et BASE_OBJECTS_ACCESSED car aucune de ces vues n’a été incluse dans la requête et elles ne sont pas l’objet de base qui sert de source aux données dans view_2.

Les champs pour DIRECT_OBJECTS_ACCESSED et BASE_OBJECTS_ACCESSED 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.
objectId	NUMBER	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. . Voir `objectDomain`.
objectName	TEXT	Nom entièrement qualifié de l’objet auquel on a accédé.
objectDomain	TEXT	Un des éléments suivants :TABLE, VIEW, MATERIALIZED_VIEW, EXTERNAL_TABLE, STREAM

Voici un exemple du tableau JSON :

[
  {
    "objectDomain": <string>,
    "objectName": <string>,
    "objectId": <number>,
    "columns": [
      {
        "columnName": <string>,
        "columnId": <number>
      },
      {
        "columnName": <string>,
        "columnId": <number>
      },
        ...
      ]
  },
  ...
]

Notes sur l’utilisation¶

La vue affiche les données à partir de 22 février 2021.
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.
- Fonctions définies par l’utilisateur (c’est-à-dire 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.
Cette vue n’enregistre pas les accès des types suivants :
- Opérations d’écriture (par exemple INSERT, UPDATE, DELETE), TRUNCATE, Snowpipe et métadonnées de table.
  
  Par exemple, si une colonne de vue est produite par un service de tokenisation externe, les journaux de base n’incluront pas les accès à cette colonne, puisque les données ne proviennent pas d’une table Snowflake.
- Fonctions de table ou d’autres vues Account Usage.
- RESULT_SCAN pour obtenir des résultats antérieurs.
De plus, cette vue ne prend pas en charge :
- Les séquences, notamment la génération de nouvelles valeurs.
- Les données qui entrent ou sortent de Snowflake lors de l’utilisation d’une fonction externe.
- Les vues intermédiaires accessibles entre la table de base et l’objet direct.
  
  Par exemple, considérons une requête sur la vue_A avec la structure d’objet suivante : Vue_A » Vue_B » Vue_C » Table_base.
  
  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.
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 Data Sharing : les requêtes et les journaux sur les objets partagés exécutés dans le compte fournisseur ne seront pas visibles pour les comptes de consommateurs Data Sharing.
- Comptes de consommateurs Data Sharing : les requêtes sur le partage de données exécutées dans le compte de consommateur seront enregistrées et uniquement visibles par le compte de consommateur, et non par le compte de fournisseur Data Sharing. Les tables de base auxquelles on accède par le partage de données ne seront pas enregistrées.
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 des requêtes sur des tables de base pour des opérations d’extraction, de transformation et de chargement (c’est-à-dire ETL).

Exemples¶

Renvoie l’historique des accès utilisateur, classé par utilisateur et par heure de début de la requête, en commençant par l’accès le plus récent.

SELECT user_name
       , query_id
       , query_start_time
       , direct_objects_accessed
       , base_objects_accessed
FROM access_history
ORDER BY 1, 3 desc
;

Les exemples suivants permettent de faciliter les audits de conformité :

Ajoutez la valeur object_id pour déterminer qui a accédé à une table sensible au cours des 30 derniers jours :

SELECT distinct user_name
FROM access_history
     , lateral flatten(base_objects_accessed) f1
WHERE f1.value:"objectId"::int=<fill_in_object_id>
AND f1.value:"objectDomain"::string='Table'
AND query_start_time >= dateadd('day', -30, current_timestamp())
;

En utilisant la valeur object_id de 32998411400350, déterminez quand l’accès a eu lieu au cours des 30 derniers jours :

SELECT query_id
       , query_start_time
FROM access_history
     , lateral flatten(base_objects_accessed) f1
WHERE f1.value:"objectId"::int=32998411400350
AND f1.value:"objectDomain"::string='Table'
AND query_start_time >= dateadd('day', -30, current_timestamp())
;

En utilisant la valeur object_id de 32998411400350, déterminez quelles colonnes ont été consultées au cours des 30 derniers jours :

SELECT distinct f4.value AS column_name
FROM access_history
     , lateral flatten(base_objects_accessed) f1
     , lateral flatten(f1.value) f2
     , lateral flatten(f2.value) f3
     , lateral flatten(f3.value) f4
WHERE f1.value:"objectId"::int=32998411400350
AND f1.value:"objectDomain"::string='Table'
AND f4.key='columnName'
;