Account Usage¶
Dans la base de données SNOWFLAKE, les schémas ACCOUNT_USAGE et READER_ACCOUNT_USAGE permettent d’interroger les métadonnées des objets, ainsi que les données historiques d’utilisation, pour votre compte et tous les comptes de lecteurs (le cas échéant) associés au compte.
Dans ce chapitre :
Aperçu des schémas Account Usage¶
- ACCOUNT_USAGE:
Vues qui affichent les métadonnées de l’objet et les métriques d’utilisation pour votre compte.
En général, ces vues reflètent les vues et les fonctions de table correspondantes dans le Schéma d’information de Snowflake Snowflake, mais avec les différences suivantes :
Enregistrements pour les objets détruits inclus dans chaque vue.
Durée de conservation plus longue pour les données historiques d’utilisation.
Latence des données.
Pour plus de détails, voir Différences entre Account Usage et Information Schema (dans ce chapitre). Pour plus de détails sur chaque vue, voir Vues ACCOUNT_USAGE (dans ce chapitre).
- READER_ACCOUNT_USAGE:
Vues qui affichent les métadonnées de l’objet et les métriques d’utilisation pour tous les comptes lecteurs qui ont été créés pour votre compte (en tant que fournisseur de Secure Data Sharing).
Ces vues sont un petit sous-ensemble des vues ACCOUNT_USAGE qui s’appliquent aux comptes de lecteurs, à l’exception de la vue RESOURCE_MONITORS, qui n’est disponible qu’en format READER_ACCOUNT_USAGE. De plus, chaque vue de ce schéma contient une colonne
READER_ACCOUNT_NAME
supplémentaire pour filtrer les résultats par compte de lecteur.Pour plus de détails sur chaque vue, voir Vues READER_ACCOUNT_USAGE (dans ce chapitre).
Notez que ces vues sont vides si aucun compte lecteur n’a été créé pour votre compte.
Différences entre Account Usage et Information Schema¶
Les vues Account Usage et les vues correspondantes (ou fonctions de tables) dans Schéma d’information de Snowflake utilisent des structures et des conventions d’appellation identiques, mais avec quelques différences importantes, comme le décrit cette section :
Différence |
Utilisation du compte |
Information Schema |
---|---|---|
Inclut les objets détruits |
Oui |
Non |
Latence des données |
Entre 45 minutes et 3 heures (varie selon la vue) |
Aucun |
Conservation des données historiques |
1 an |
Entre 7 jours et 6 mois (varie selon la vue/la fonction de table) |
Pour plus de détails, voir les sections suivantes.
Enregistrements d’objets détruits¶
Les vues d’utilisation de compte comprennent des enregistrements pour tous les objets qui ont été détruits. De nombreuses vues de types d’objets contiennent une colonne supplémentaire DELETED
qui affiche l’horodatage de l’objet détruit.
En outre, comme les objets peuvent être détruits et recréés avec le même nom, les vues d’utilisation des comptes comprennent des colonnes ID pour différencier les enregistrements d’objets portant le même nom, qui affichent les IDs internes générés et affectés à chaque enregistrement par le système, le cas échéant.
Si la colonne d’un nom d’objet (par exemple, la colonne TABLE_NAME
) est NULL, cet objet a été détruit. Dans ce cas, les colonnes des noms et IDs des objets parents (par exemple, les colonnes DATABASE_NAME
et SCHEMA_NAME
) sont également NULL.
Notez que dans certaines vues, la colonne du nom de l’objet peut encore contenir le nom de l’objet, même si celui-ci a été détruit.
Latence des données¶
En raison du processus d’extraction des données de l’entrepôt interne de métadonnées de Snowflake, les vues Account Usage ont une certaine latence naturelle :
Pour la plupart des vues, la latence est de 2 heures (120 minutes).
Pour les autres vues, la latence varie entre 45 minutes et 3 heures.
Pour plus de détails, voir la liste des vues pour chaque schéma (dans cette rubrique). Notez également qu’il s’agit de longueurs maximales ; la latence réelle d’une vue donnée au moment où la vue est interrogée peut être inférieure.
En revanche, les vues/fonctions de la table dans le Schéma d’information de Snowflake n’ont pas de latence.
Conservation des données historiques¶
Certaines des vues d’utilisation du compte fournissent des métriques historiques d’utilisation. La période de conservation limite pour ces vues est d’un an (365 jours).
En revanche, les vues correspondantes et les fonctions de tables dans le Schéma d’information de Snowflake ont des périodes de conservation beaucoup plus courtes, allant de 7 jours à 6 mois, selon la vue.
Vues ACCOUNT_USAGE¶
Le schéma ACCOUNT_USAGE contient les vues suivantes :
Vue |
Type |
Latence [1] |
Édition [3] |
Remarques |
---|---|---|---|---|
Historique |
3 heures |
Enterprise Edition (ou une édition supérieure) |
Données conservées pendant 1 an. |
|
Historique |
3 heures |
Enterprise Edition (ou une édition supérieure) |
Données conservées pendant 1 an. |
|
Historique |
3 heures |
|||
Objet |
2 heures |
|||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Objet |
3 heures |
Données conservées pendant 1 an. |
||
Objet |
3 heures |
Données conservées pendant 1 an. |
||
Objet |
90 minutes |
|||
Historique |
45 minutes |
Données conservées pendant 1 an. |
||
Historique |
2 heures [2] |
Données conservées pendant 1 an. |
||
Objet |
3 heures |
Enterprise Edition (ou une édition supérieure) |
Les données sont conservées aussi longtemps que la table existe. |
|
Objet |
3 heures |
|||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
2 heures |
Données conservées pendant 1 an. |
||
Objet |
90 minutes |
|||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
2 heures |
Données conservées pendant 1 an. |
||
Objet |
90 minutes |
|||
Objet |
2 heures |
|||
Objet |
2 heures |
|||
Objet |
2 heures |
|||
Objet |
2 heures |
|||
Objet |
3 heures |
|||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Objet |
3 heures |
|||
Objet |
3 heures |
|||
Historique |
90 minutes [2] |
Données conservées pendant 1 an. |
||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
2 heures |
Données conservées pendant 1 an. |
||
Objet |
2 heures |
|||
Historique |
3 heures |
Enterprise Edition (ou une édition supérieure) |
Données conservées pendant 1 an. |
|
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Objet |
2 heures |
|||
Objet |
2 heures |
|||
Objet |
2 heures |
|||
Historique |
3 heures |
|||
Objet |
2 heures |
|||
Objet |
2 heures |
|||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Objet |
2 heures |
|||
Objet |
2 heures |
|||
Objet |
2 heures |
|||
Historique |
3 heures |
Enterprise Edition (ou une édition supérieure) |
Données conservées pendant 1 an. |
|
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
45 minutes |
Données conservées pendant 1 an. |
||
Objet |
2 heures |
|||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Objet |
2 heures |
|||
Objet |
2 heures |
|||
Objet |
2 heures |
|||
Historique |
3 heures |
Enterprise Edition (ou une édition supérieure) |
Données conservées pendant 1 an. |
|
Objet |
2 heures |
|||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Objet |
3 heures |
Données conservées pendant 1 an. |
||
Objet |
2 heures |
|||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
2 heures |
Données conservées pendant 1 an. |
||
Historique |
12 heures |
Données conservées pendant 1 an. |
||
Objet |
2 heures |
|||
Historique |
2 heures |
Données conservées pendant 1 an. |
||
Historique |
2 heures |
Utilisation combinée de toutes les tables de la base de données et des zones de préparation internes. Données conservées pendant 1 an. |
||
Objet |
90 minutes |
|||
Objet |
2 heures |
|||
Objet |
90 minutes |
|||
Objet |
2 heures |
|||
Objet |
2 heures |
|||
Historique |
45 minutes |
|||
Objet |
3 heures |
|||
Objet |
2 heures |
|||
Objet |
90 minutes |
|||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
3 heures |
Données conservées pendant 1 an. |
||
Historique |
3 heures |
Données conservées pendant 1 an. |
[1] Tous les temps de latence sont approximatifs. Dans certains cas, la latence réelle peut être inférieure.
[2] La latence des vues pour une table donnée peut aller jusqu’à 2 jours si les deux conditions suivantes sont remplies : 1. Moins de 32 instructions DML ont été ajoutées à la table donnée depuis sa dernière mise à jour dans LOAD_HISTORY ou COPY_HISTORY. 2. Moins de 100 lignes ont été ajoutées à la table donnée depuis sa dernière mise à jour dans LOAD_HISTORY ou COPY_HISTORY.
[3] Sauf indication contraire, la vue Account Usage est disponible pour tous les comptes.
Fonctions de table Account Usage¶
Actuellement, Snowflake prend en charge une fonction de table ACCOUNT_USAGE :
Fonction de la table |
Données Conservation |
Remarques |
---|---|---|
N/A |
Les résultats ne sont renvoyés que pour le rôle qui a accès à l’objet spécifié. |
Note
Comme pour les vues Account Usage, veuillez tenir compte de la latence lorsque vous appelez cette fonction de table. La latence attendue pour cette fonction de table est similaire à la latence pour la vue TAG_REFERENCES.
Vues READER_ACCOUNT_USAGE¶
Le schéma READER_ACCOUNT_USAGE contient les vues suivantes :
Vue |
Type |
Latence [1] |
Remarques |
---|---|---|---|
Historique |
2 heures |
Données conservées pendant 1 an. |
|
Historique |
45 minutes |
Données conservées pendant 1 an. |
|
Objet |
2 heures |
||
Historique |
2 heures |
Utilisation combinée de toutes les tables de la base de données et des zones de préparation internes. Données conservées pendant 1 an. |
|
Historique |
3 heures |
Données conservées pendant 1 an. |
[1] Tous les temps de latence sont approximatifs. Dans certains cas, la latence réelle peut être inférieure.
Activation de l’utilisation de la base de données SNOWFLAKE pour d’autres rôles¶
Par défaut, la base de données SNOWFLAKE est visible par tous les utilisateurs, mais l’accès aux schémas de cette base de données peut être accordé par un utilisateur titulaire du rôle ACCOUNTADMIN via l’une des approches suivantes :
Accord de IMPORTED PRIVILEGES sur la base de données SNOWFLAKE.
Accord d’un rôle de base de données SNOWFLAKE au rôle d’un compte.
Important
Soyez prudent lorsque vous accordez des privilèges à la base de données SNOWFLAKE dans un compte dont le rôle ORGADMIN est activé. Dans ce compte, toute personne ayant des privilèges sur la base de données SNOWFLAKE peut accéder au schéma ORGANIZATION_USAGE.
Pour éviter d’accorder involontairement l’accès à des données au niveau de l’organisation, envisagez d’utiliser des rôles de base de données SNOWFLAKE pour accorder l’accès à des vues dans le schéma ACCOUNT_USAGE.
Pour plus d’informations, reportez-vous à GRANT DATABASE ROLE.
Par exemple, pour accorder des IMPORTED PRIVILEGES sur la base de données SNOWFLAKE à deux rôles supplémentaires :
USE ROLE ACCOUNTADMIN; GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE SYSADMIN; GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE customrole1;
Un utilisateur auquel a été attribué le rôle customrole1
peut interroger une vue comme suit :
USE ROLE customrole1; SELECT database_name, database_owner FROM SNOWFLAKE.ACCOUNT_USAGE.DATABASES;
Pour d’autres exemples, voir Interrogation des vues d’utilisation du compte.
Rôles de base de données SNOWFLAKE du schéma ACCOUNT_USAGE¶
En outre, vous pouvez accorder un contrôle plus précis aux comptes en utilisant les rôles de bases de données SNOWFLAKE. Pour plus d’informations sur les rôles de base de données, voir Rôles de base de données.
Les schémas ACCOUNT_USAGE ont quatre rôles de base de données SNOWFLAKE définis, chacun bénéficiant du privilège SELECT sur des vues spécifiques.
Rôle |
Objectif et description |
---|---|
OBJECT_VIEWER |
Le rôle OBJECT_VIEWER permet de visualiser les métadonnées des objets. |
USAGE_VIEWER |
Le rôle USAGE_VIEWER offre une visibilité sur les informations historiques d’utilisation. |
GOVERNANCE_VIEWER |
Le rôle GOVERNANCE_VIEWER permet de visualiser les informations relatives aux politiques. |
SECURITY_VIEWER |
Le rôle SECURITY_VIEWER permet de visualiser les informations relatives à la sécurité. |
Vues ACCOUNT_USAGE par rôle de base de données¶
Les rôles OBJECT_VIEWER, USAGE_VIEWER, GOVERNANCE_VIEWER et SECURITY_VIEWER ont le privilège SELECT permettant d’interroger les vues Account Usage dans la base de données SNOWFLAKE partagée.
Une coche (c’est-à-dire ✔) indique que le rôle bénéficie du privilège SELECT sur la vue.
Vue |
Rôle OBJECT_VIEWER |
Rôle USAGE_VIEWER |
Rôle GOVERNANCE_VIEWER |
Rôle SECURITY_VIEWER |
---|---|---|---|---|
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
✔ |
|||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
✔ |
|||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
Rôles de base de données SNOWFLAKE du schéma READER_ACCOUNT_USAGE¶
Le rôle de base de données READER_USAGE_VIEWER SNOWFLAKE bénéficie du privilège SELECT sur toutes les vues READER_ACCOUNT_USAGE. Les comptes de lecteur étant créés par les clients, le rôle READER_USAGE_VIEWER est censé être accordé aux rôles utilisés pour contrôler l’utilisation des comptes de lecteur.
Vue |
---|
Interrogation des vues d’utilisation du compte¶
Cette section présente les considérations à prendre en compte lors de l’interrogation des vues Account Usage, ainsi que des exemples d’interrogation.
Sélection de colonnes¶
Les vues spécifiques à Snowflake sont susceptibles d’être modifiées. Évitez de sélectionner toutes les colonnes dans ces vues. À la place, sélectionnez les colonnes que vous voulez. Par exemple, si vous voulez la colonne name
utilisez SELECT name
, plutôt que SELECT *
.
Rapprochement des vues de coûts¶
Plusieurs vues Account Usage contiennent des données relatives au coût des ressources de calcul, du stockage et des transferts de données. Si vous essayez de rapprocher ces vues avec une vue correspondante dans le schéma ORGANIZATION_USAGE, vous devez d’abord définir le fuseau horaire de la session sur UTC.
Par exemple, si vous essayez de rapprocher ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY des données du compte dans ORGANIZATION_USAGE.WAREHOUSE_METERING_HISTORY, vous devez exécuter la commande suivante avant d’interroger la vue Account Usage :
ALTER SESSION SET TIMEZONE = UTC;
Exemples¶
Les exemples suivants présentent quelques requêtes typiques/utiles utilisant les vues du schéma ACCOUNT_USAGE.
Note
Ces exemples supposent que la base de données SNOWFLAKE et le schéma ACCOUNT_USAGE sont utilisés pour la session en cours. Les exemples supposent également que le rôle ACCOUNTADMIN (ou un rôle ayant obtenu des PRIVILEGES IMPORTED pour la base de données) est utilisé. S’ils ne sont pas utilisés, exécutez les commandes suivantes avant d’exécuter les requêtes dans les exemples :
USE ROLE ACCOUNTADMIN; USE SCHEMA snowflake.account_usage;
Exemples : métriques de connexion utilisateur¶
Nombre moyen de secondes entre les tentatives de connexion échouées, par utilisateur (depuis le début du mois) :
select user_name, count(*) as failed_logins, avg(seconds_between_login_attempts) as average_seconds_between_login_attempts from ( select user_name, timediff(seconds, event_timestamp, lead(event_timestamp) over(partition by user_name order by event_timestamp)) as seconds_between_login_attempts from login_history where event_timestamp > date_trunc(month, current_date) and is_success = 'NO' ) group by 1 order by 3;
Échec de connexions, par utilisateur (depuis le début du mois) :
select user_name, sum(iff(is_success = 'NO', 1, 0)) as failed_logins, count(*) as logins, sum(iff(is_success = 'NO', 1, 0)) / nullif(count(*), 0) as login_failure_rate from login_history where event_timestamp > date_trunc(month, current_date) group by 1 order by 4 desc;
Échec des connexions par utilisateur et client connecté (depuis le début du mois) :
select reported_client_type, user_name, sum(iff(is_success = 'NO', 1, 0)) as failed_logins, count(*) as logins, sum(iff(is_success = 'NO', 1, 0)) / nullif(count(*), 0) as login_failure_rate from login_history where event_timestamp > date_trunc(month, current_date) group by 1,2 order by 5 desc;
Exemples : performance des entrepôts¶
Cette requête calcule les métriques de performance de l’entrepôt virtuel comme le débit et la latence pour des intervalles de temps de 15 minutes au cours d’une journée.
Dans l’exemple de code ci-dessous, vous pouvez remplacer CURRENT_WAREHOUSE()
par le nom d’un entrepôt pour calculer les métriques pour cet entrepôt. De plus, modifiez les dates time_from
et time_to
dans la clause WITH pour spécifier la période de temps.
WITH params AS ( SELECT CURRENT_WAREHOUSE() AS warehouse_name, '2021-11-01' AS time_from, '2021-11-02' AS time_to ), jobs AS ( SELECT query_id, time_slice(start_time::timestamp_ntz, 15, 'minute','start') as interval_start, qh.warehouse_name, database_name, query_type, total_elapsed_time, compilation_time AS compilation_and_scheduling_time, (queued_provisioning_time + queued_repair_time + queued_overload_time) AS queued_time, transaction_blocked_time, execution_time FROM snowflake.account_usage.query_history qh, params WHERE qh.warehouse_name = params.warehouse_name AND start_time >= params.time_from AND start_time <= params.time_to AND execution_status = 'SUCCESS' AND query_type IN ('SELECT','UPDATE','INSERT','MERGE','DELETE') ), interval_stats AS ( SELECT query_type, interval_start, COUNT(DISTINCT query_id) AS numjobs, MEDIAN(total_elapsed_time)/1000 AS p50_total_duration, (percentile_cont(0.95) within group (order by total_elapsed_time))/1000 AS p95_total_duration, SUM(total_elapsed_time)/1000 AS sum_total_duration, SUM(compilation_and_scheduling_time)/1000 AS sum_compilation_and_scheduling_time, SUM(queued_time)/1000 AS sum_queued_time, SUM(transaction_blocked_time)/1000 AS sum_transaction_blocked_time, SUM(execution_time)/1000 AS sum_execution_time, ROUND(sum_compilation_and_scheduling_time/sum_total_duration,2) AS compilation_and_scheduling_ratio, ROUND(sum_queued_time/sum_total_duration,2) AS queued_ratio, ROUND(sum_transaction_blocked_time/sum_total_duration,2) AS blocked_ratio, ROUND(sum_execution_time/sum_total_duration,2) AS execution_ratio, ROUND(sum_total_duration/numjobs,2) AS total_duration_perjob, ROUND(sum_compilation_and_scheduling_time/numjobs,2) AS compilation_and_scheduling_perjob, ROUND(sum_queued_time/numjobs,2) AS queued_perjob, ROUND(sum_transaction_blocked_time/numjobs,2) AS blocked_perjob, ROUND(sum_execution_time/numjobs,2) AS execution_perjob FROM jobs GROUP BY 1,2 ORDER BY 1,2 ) SELECT * FROM interval_stats;Note
Analysez séparément les différents types d’instructions (par exemple, les instructions SELECT indépendamment des instructions INSERT ou DELETE ou autres).
La valeur NUMJOBS représente le débit pour cet intervalle de temps.
Les P50_TOTAL_DURATION (médiane) et P95_TOTAL_DURATION (pic) représentent la latence.
Le SUM_TOTAL_DURATION est la somme des valeurs SUM_<zone_de_préparation_tâche>_TIME pour les différentes zones de préparation de la tâche (COMPILATION_AND_SCHEDULING, QUEUED, BLOCKED, EXECUTION).
Analysez les valeurs de <zone_de_préparation_tâche>_RATIO lorsque la charge (NUMJOBS) augmente. Recherchez les changements de ratio ou les écarts par rapport à la moyenne.
Si le QUEUED_RATIO est élevé, il se peut que la capacité de l’entrepôt soit insuffisante. Ajoutez plus de clusters ou augmentez la taille de l’entrepôt.
Exemple : utilisation du crédit d’entrepôt¶
Crédits utilisés par chaque entrepôt de votre compte (depuis le début du mois) :
select warehouse_name, sum(credits_used) as total_credits_used from warehouse_metering_history where start_time >= date_trunc(month, current_date) group by 1 order by 2 desc;
Crédits utilisés au fil du temps par chaque entrepôt de votre compte (depuis le début du mois) :
select start_time::date as usage_date, warehouse_name, sum(credits_used) as total_credits_used from warehouse_metering_history where start_time >= date_trunc(month, current_date) group by 1,2 order by 2,1;
Exemples : utilisation du stockage de données¶
Téraoctets facturables stockés dans votre compte au fil du temps :
select date_trunc(month, usage_date) as usage_month , avg(storage_bytes + stage_bytes + failsafe_bytes) / power(1024, 4) as billable_tb from storage_usage group by 1 order by 1;
Exemples : totaux de requêtes utilisateur et temps d’exécution¶
Total des tâches exécutées sur votre compte (depuis le début du mois) :
select count(*) as number_of_jobs from query_history where start_time >= date_trunc(month, current_date);
Total des tâches exécutées par chaque entrepôt de votre compte (depuis le début du mois) :
select warehouse_name, count(*) as number_of_jobs from query_history where start_time >= date_trunc(month, current_date) group by 1 order by 2 desc;
Temps moyen d’exécution des requêtes par utilisateur (depuis le début du mois) :
select user_name, avg(execution_time) as average_execution_time from query_history where start_time >= date_trunc(month, current_date) group by 1 order by 2 desc;
Temps moyen d’exécution des requêtes par type de requête et taille de l’entrepôt (depuis le début du mois) :
select query_type, warehouse_size, avg(execution_time) as average_execution_time from query_history where start_time >= date_trunc(month, current_date) group by 1,2 order by 3 desc;
Exemples : obtenir un nombre de requêtes pour chaque événement de connexion¶
Joignez les colonnes de LOGIN_HISTORY, QUERY_HISTORY et SESSIONS pour obtenir un nombre de requêtes pour chaque événement de connexion utilisateur.
Note
La vue SESSIONS enregistre les informations à partir du 20-21 juillet 2020, par conséquent le résultat de la requête ne contiendra que des informations se chevauchant pour chacune des trois vues à partir de cette date.
select l.user_name, l.event_timestamp as login_time, l.client_ip, l.reported_client_type, l.first_authentication_factor, l.second_authentication_factor, count(q.query_id) from snowflake.account_usage.login_history l join snowflake.account_usage.sessions s on l.event_id = s.login_event_id join snowflake.account_usage.query_history q on q.session_id = s.session_id group by 1,2,3,4,5,6 order by l.user_name ;