Vue ACCESS_HISTORY¶

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.

[
  {
    "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"
  }
]

[
  {
    "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"
  }
]

[
  {
    "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"
          }
        ]
      }
    ]
  },
  ...
]

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

[
  {
    "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"
      }
    ]
  }
]

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

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

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"
  }
}

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.

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 à :

  • JOIN et USING (dans le sujet de référence JOIN)

  • Suivi du mouvement des données sensibles de la zone de préparation (dans l’exemple de la requête sur l’historique des accès)

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.

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.

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.

• Un enregistrement de l’historique des accès est généré lorsque des opérations DDL sont effectuées sur les séquences. Il n’est pas généré lorsqu’une séquence est utilisée dans d’autres opérations, y compris 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.

• Les requêtes ayant échoué, bien qu’enregistrées dans la vue QUERY_HISTORY, ne seront pas enregistrées dans la vue ACCESS_HISTORY.

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 :

• CREATE TABLE … AS SELECT (CTAS)

• CREATE TABLE … CLONE

• INSERT … SELECT …

• MERGE

• UPDATE, deux variantes possibles, par exemple :

  • Mise à jour personnelle :

    UPDATE mydb.s1.t1 SET col_1 = col_1 + 1;
    

    Copy

  • Mise à jour de deux tables :

    UPDATE mydb.s1.t1 FROM mydb.s2.t2 SET t1.col1 = t2.col1;
    

    Copy

• ALTER TABLE … RENAME TO

Conditions de la requête:

• Query profile/plan

  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

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.