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

ACCESS_HISTORY

Historique

3 heures

Enterprise Edition (ou une édition supérieure)

Données conservées pendant 1 an.

AGGREGATE_ACCESS_HISTORY

Historique

3 heures

Enterprise Edition (ou une édition supérieure)

Données conservées pendant 1 an.

AGGREGATE_QUERY_HISTORY

Historique

3 heures

AGGREGATION_POLICIES

Objet

2 heures

ALERT_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

AUTOMATIC_CLUSTERING_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

CLASS_INSTANCES

Objet

3 heures

Données conservées pendant 1 an.

CLASSES

Objet

3 heures

Données conservées pendant 1 an.

COLUMNS

Objet

90 minutes

COMPLETE_TASK_GRAPHS

Historique

45 minutes

Données conservées pendant 1 an.

COPY_HISTORY

Historique

2 heures [2]

Données conservées pendant 1 an.

DATA_CLASSIFICATION_LATEST

Objet

3 heures

Enterprise Edition (ou une édition supérieure)

Les données sont conservées aussi longtemps que la table existe.

DATABASES

Objet

3 heures

DATABASE_REPLICATION_USAGE_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

DATABASE_STORAGE_USAGE_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

DATA_TRANSFER_HISTORY

Historique

2 heures

Données conservées pendant 1 an.

ELEMENT_TYPES

Objet

90 minutes

EVENT_USAGE_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

EXTERNAL_ACCESS_HISTORY

Historique

2 heures

Données conservées pendant 1 an.

FIELDS

Objet

90 minutes

FILE_FORMATS

Objet

2 heures

FUNCTIONS

Objet

2 heures

GRANTS_TO_ROLES

Objet

2 heures

GRANTS_TO_USERS

Objet

2 heures

HYBRID_TABLES

Objet

3 heures

HYBRID_TABLE_USAGE_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

INDEX_COLUMNS

Objet

3 heures

INDEXES

Objet

3 heures

LOAD_HISTORY

Historique

90 minutes [2]

Données conservées pendant 1 an.

LOCK_WAIT_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

LOGIN_HISTORY

Historique

2 heures

Données conservées pendant 1 an.

MASKING_POLICIES

Objet

2 heures

MATERIALIZED_VIEW_REFRESH_HISTORY

Historique

3 heures

Enterprise Edition (ou une édition supérieure)

Données conservées pendant 1 an.

METERING_DAILY_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

METERING_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

NETWORK_POLICIES

Objet

2 heures

NETWORK_RULE_REFERENCES

Objet

2 heures

NETWORK_RULES

Objet

2 heures

OBJECT_DEPENDENCIES

Historique

3 heures

PASSWORD_POLICIES

Objet

2 heures

PIPES

Objet

2 heures

PIPE_USAGE_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

POLICY_REFERENCES

Objet

2 heures

PROCEDURES

Objet

2 heures

PROJECTION_POLICIES

Objet

2 heures

QUERY_ACCELERATION_ELIGIBLE

Historique

3 heures

Enterprise Edition (ou une édition supérieure)

Données conservées pendant 1 an.

QUERY_ACCELERATION_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

QUERY_HISTORY

Historique

45 minutes

Données conservées pendant 1 an.

REFERENTIAL_CONSTRAINTS

Objet

2 heures

REPLICATION_GROUP_REFRESH_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

REPLICATION_GROUP_USAGE_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

REPLICATION_USAGE_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

ROLES

Objet

2 heures

ROW_ACCESS_POLICIES

Objet

2 heures

SCHEMATA

Objet

2 heures

SEARCH_OPTIMIZATION_HISTORY

Historique

3 heures

Enterprise Edition (ou une édition supérieure)

Données conservées pendant 1 an.

SEQUENCES

Objet

2 heures

SERVERLESS_TASK_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

SERVICES

Objet

3 heures

Données conservées pendant 1 an.

SESSION_POLICIES

Objet

2 heures

SESSIONS

Historique

3 heures

Données conservées pendant 1 an.

SNOWPARK_CONTAINER_SERVICES_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

SNOWPIPE_STREAMING_CLIENT_HISTORY

Historique

2 heures

Données conservées pendant 1 an.

SNOWPIPE_STREAMING_FILE_MIGRATION_HISTORY

Historique

12 heures

Données conservées pendant 1 an.

STAGES

Objet

2 heures

STAGE_STORAGE_USAGE_HISTORY

Historique

2 heures

Données conservées pendant 1 an.

STORAGE_USAGE

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.

TABLES

Objet

90 minutes

TABLE_CONSTRAINTS

Objet

2 heures

TABLE_STORAGE_METRICS

Objet

90 minutes

TAG_REFERENCES

Objet

2 heures

TAGS

Objet

2 heures

TASK_HISTORY

Historique

45 minutes

TASK_VERSIONS

Objet

3 heures

USERS

Objet

2 heures

VIEWS

Objet

90 minutes

WAREHOUSE_EVENTS_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

WAREHOUSE_LOAD_HISTORY

Historique

3 heures

Données conservées pendant 1 an.

WAREHOUSE_METERING_HISTORY

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

TAG_REFERENCES_WITH_LINEAGE

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

LOGIN_HISTORY

Historique

2 heures

Données conservées pendant 1 an.

QUERY_HISTORY

Historique

45 minutes

Données conservées pendant 1 an.

RESOURCE_MONITORS

Objet

2 heures

STORAGE_USAGE

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.

WAREHOUSE_METERING_HISTORY

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 :

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;
Copy

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;
Copy

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

Vue COLUMNS

Vue COMPLETE_TASK_GRAPHS

Vue DATABASES

Vue ELEMENT_TYPES

Vue FIELDS

Vue FILE_FORMATS

Vue FUNCTIONS

Vue HYBRID_TABLES

Vue INDEXES

Vue INDEX_COLUMNS

Vue OBJECT_DEPENDENCIES

Vue PIPES

Vue REFERENTIAL_CONSTRAINTS

Vue SCHEMATA

Vue SEQUENCES

Vue STAGES

Vue TABLE_CONSTRAINTS

Vue TABLES

Vue TAGS

Vue VIEWS

Vue AUTOMATIC_CLUSTERING_HISTORY

Vue CLASS_INSTANCES

Vue CLASSES

Vue COPY_HISTORY

Vue DATA_TRANSFER_HISTORY

Vue DATABASE_STORAGE_USAGE_HISTORY

Vue EVENT_USAGE_HISTORY

Vue EXTERNAL_ACCESS_HISTORY

Vue HYBRID_TABLE_USAGE_HISTORY

Vue LOAD_HISTORY

Vue MATERIALIZED_VIEW_REFRESH_HISTORY

Vue METERING_DAILY_HISTORY

Vue METERING_HISTORY

Vue PIPE_USAGE_HISTORY

Vue REPLICATION_USAGE_HISTORY

Vue REPLICATION_GROUP_REFRESH_HISTORY

Vue REPLICATION_GROUP_USAGE_HISTORY

Vue SERVICES

Vue SNOWPARK_CONTAINER_SERVICES_HISTORY

Vue SEARCH_OPTIMIZATION_HISTORY

Vue SERVERLESS_TASK_HISTORY

Vue STAGE_STORAGE_USAGE_HISTORY

Vue STORAGE_USAGE

Vue TABLE_STORAGE_METRICS

Vue TASK_HISTORY

Vue WAREHOUSE_EVENTS_HISTORY

Vue WAREHOUSE_LOAD_HISTORY

Vue WAREHOUSE_METERING_HISTORY

Vue ACCESS_HISTORY

Vue AGGREGATE_ACCESS_HISTORY

Vue AGGREGATE_QUERY_HISTORY

Vue AGGREGATION_POLICIES

Vue DATA_CLASSIFICATION_LATEST

Vue MASKING_POLICIES

Vue QUERY_ACCELERATION_ELIGIBLE

Vue QUERY_HISTORY

Vue POLICY_REFERENCES

Vue PROJECTION_POLICIES

Vue ROW_ACCESS_POLICIES

Vue TAG_REFERENCES

Vue GRANTS_TO_ROLES

Vue GRANTS_TO_USERS

Vue LOGIN_HISTORY

Vue NETWORK_POLICIES

Vue NETWORK_RULES

Vue NETWORK_RULE_REFERENCES

Vue PASSWORD_POLICIES

Vue ROLES

Vue SESSION_POLICIES

Vue SESSIONS

Vue USERS

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

Vue LOGIN_HISTORY

Vue QUERY_HISTORY

Vue RESOURCE_MONITORS

Vue STORAGE_USAGE

Vue WAREHOUSE_METERING_HISTORY

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;
Copy

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;
    
    Copy

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;
Copy

É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;
Copy

É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;
Copy

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;
Copy

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;
Copy

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;
Copy

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;
Copy

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);
Copy

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;
Copy

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;
Copy

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;
Copy

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
;
Copy