Account Usage

In der SNOWFLAKE-Datenbank ermöglichen die Schemas ACCOUNT_USAGE und READER_ACCOUNT_USAGE die Abfrage von Objektmetadaten sowie von historischen Nutzungsdaten für Ihr Konto und für alle mit dem Konto verbundenen Leserkonten (falls vorhanden).

Unter diesem Thema:

Überblick über Account Usage-Schemas

ACCOUNT_USAGE

Ansichten, in denen Objektmetadaten und Nutzungsdaten für Ihr Konto angezeigt werden.

Im Allgemeinen spiegeln diese Ansichten die entsprechenden Ansichten und Tabellenfunktionen im Snowflake Snowflake Information Schema wider, allerdings mit folgenden Unterschieden:

  • Datensätze für gelöschte Objekte, die in einzelnen Ansichten enthalten sind.

  • Längere Aufbewahrungszeit für historische Nutzungsdaten.

  • Datenlatenz.

Weitere Informationen dazu finden Sie unter Unterschiede zwischen Account Usage und Information Schema (unter diesem Thema). Weitere Informationen zu den einzelnen Ansichten finden Sie unter ACCOUNT_USAGE-Ansichten (unter diesem Thema).

READER_ACCOUNT_USAGE

Ansichten, in denen Objektmetadaten und Nutzungsmetriken für alle Leserkonten angezeigt werden, die für Ihr Konto erstellt wurden (als ein Anbieter von Secure Data Sharing).

Diese Ansichten sind eine kleine Teilmenge der ACCOUNT_USAGE-Ansichten, die mit Ausnahme der RESOURCE_MONITORS-Ansicht, die nur in READER_ACCOUNT_USAGE verfügbar ist, für Leserkonten verfügbar sind. Außerdem enthält jede Ansicht in diesem Schema eine zusätzliche READER_ACCOUNT_NAME-Spalte zum Filtern von Ergebnissen nach Leserkonten.

Weitere Informationen zu den einzelnen Ansichten finden Sie unter READER_ACCOUNT_USAGE-Ansichten (unter diesem Thema).

Beachten Sie, dass diese Ansichten leer sind, wenn für Ihr Konto keine Leserkonten erstellt wurden.

Unterschiede zwischen Account Usage und Information Schema

Die Account Usage-Ansichten und die entsprechenden Ansichten (oder Tabellenfunktion) im Snowflake Information Schema basieren auf identischen Strukturen und Namenskonventionen, jedoch mit einigen wesentlichen Unterschieden, die in diesem Abschnitt beschrieben werden.

Unterschied

Kontonutzung

Information Schema

Enthält gelöschte Objekte

Ja

Nein

Latenz der Daten

45 Minuten bis 3 Stunden (variiert je nach Ansicht)

Keine

Aufbewahrung historischer Daten

1 Jahr

7 Tage bis 6 Monate (variiert je nach Ansicht/Tabellenfunktion)

Weitere Details dazu finden Sie in den folgenden Abschnitten.

Gelöschte Objektdatensätze

Account Usage-Ansichten enthalten Datensätze für alle Objekte, die gelöscht wurden. Viele der Ansichten für Objekttypen enthalten eine zusätzliche Spalte DELETED, die den Zeitstempel dafür anzeigt, wann das Objekt gelöscht wurde.

Da Objekte gelöscht und mit dem gleichen Namen neu angelegt werden können, beinhalten die Account Usage-Ansichten ggf. auch ID-Spalten, in denen die intern generierten und vom System den einzelnen Datensätzen zugeordneten IDs angezeigt werden. Dadurch kann zwischen Objektdatensätzen mit dem gleichen Namen unterschieden werden.

Wenn eine Spalte für einen Objektnamen (z. B. die Spalte TABLE_NAME) den Wert NULL hat, wurde dieses Objekt gelöscht. In diesem Fall haben die Spalten für die Namen und IDs der übergeordneten Objekte (z. B. die Spalten DATABASE_NAME und SCHEMA_NAME) ebenfalls den Wert NULL.

Beachten Sie, dass in einigen Ansichten die Spalte mit den Objektnamen immer noch den Namen des Objekts enthalten kann, auch wenn das Objekt gelöscht wurde.

Datenlatenz

Aufgrund der Extraktion der Daten aus dem internen Metadatenspeicher von Snowflake weisen die Kontonutzungsansichten eine natürliche Latenzzeit auf:

  • Bei den meisten Ansichten beträgt die Latenz 2 Stunden (120 Minuten).

  • Bei den anderen Ansichten variiert die Latenz zwischen 45 Minuten und 3 Stunden.

Weitere Informationen dazu finden Sie in der Ansichtsliste des jeweiligen Schemas (unter diesem Thema). Beachten Sie zudem, dass es sich dabei um maximale Werte handelt. Die tatsächliche Latenz einer bestimmten Ansicht zum Zeitpunkt der Abfrage kann geringer sein.

Im Gegensatz dazu weisen Ansichten/Tabellenfunktionen im Snowflake Information Schema keine Latenzen auf.

Aufbewahrung historischer Daten

Manche Kontonutzungsansichten bieten historische Nutzungsdaten. Die Aufbewahrungsfrist für diese Ansichten beträgt 1 Jahr (365 Tage).

Im Gegensatz dazu haben die zugehörigen Ansichten und Tabellenfunktionen im Snowflake Information Schema deutlich kürzere Aufbewahrungsfristen, die je nach Ansicht zwischen 7 Tagen und 6 Monaten liegen.

ACCOUNT_USAGE-Ansichten

Das Schema ACCOUNT_USAGE enthält die folgenden Ansichten:

Ansicht

Typ

Latenz: sup:[1]

Edition [3]

Anmerkungen

ACCESS_HISTORY

Historisch

3 Stunden

Enterprise Edition (oder höher)

Daten werden für 1 Jahr aufbewahrt.

AGGREGATE_QUERY_HISTORY

Historisch

3 Stunden

ALERT_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

AUTOMATIC_CLUSTERING_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

CLASS_INSTANCES

Objekt

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

CLASSES

Objekt

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

COLUMNS

Objekt

90 Minuten

COMPLETE_TASK_GRAPHS

Historisch

45 Minuten

Daten werden für 1 Jahr aufbewahrt.

COPY_HISTORY

Historisch

2 Stunden [2]

Daten werden für 1 Jahr aufbewahrt.

DATABASES

Objekt

3 Stunden

DATABASE_REPLICATION_USAGE_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

DATABASE_STORAGE_USAGE_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

DATA_TRANSFER_HISTORY

Historisch

2 Stunden

Daten werden für 1 Jahr aufbewahrt.

ELEMENT_TYPES

Objekt

90 Minuten

EVENT_USAGE_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

EXTERNAL_ACCESS_HISTORY

Historisch

2 Stunden

Daten werden für 1 Jahr aufbewahrt.

FIELDS

Objekt

90 Minuten

FILE_FORMATS

Objekt

2 Stunden

FUNCTIONS

Objekt

2 Stunden

GRANTS_TO_ROLES

Objekt

2 Stunden

GRANTS_TO_USERS

Objekt

2 Stunden

LOAD_HISTORY

Historisch

90 Minuten [2]

Daten werden für 1 Jahr aufbewahrt.

LOCK_WAIT_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

LOGIN_HISTORY

Historisch

2 Stunden

Daten werden für 1 Jahr aufbewahrt.

MASKING_POLICIES

Objekt

2 Stunden

MATERIALIZED_VIEW_REFRESH_HISTORY

Historisch

3 Stunden

Enterprise Edition (oder höher)

Daten werden für 1 Jahr aufbewahrt.

METERING_DAILY_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

METERING_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

OBJECT_DEPENDENCIES

Historisch

3 Stunden

PASSWORD_POLICIES

Objekt

2 Stunden

PIPES

Objekt

2 Stunden

PIPE_USAGE_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

POLICY_REFERENCES

Objekt

2 Stunden

PROCEDURES

Objekt

2 Stunden

QUERY_ACCELERATION_ELIGIBLE

Historisch

3 Stunden

Enterprise Edition (oder höher)

Daten werden für 1 Jahr aufbewahrt.

QUERY_ACCELERATION_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

QUERY_HISTORY

Historisch

45 Minuten

Daten werden für 1 Jahr aufbewahrt.

REFERENTIAL_CONSTRAINTS

Objekt

2 Stunden

REPLICATION_GROUP_REFRESH_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

REPLICATION_GROUP_USAGE_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

REPLICATION_USAGE_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

ROLES

Objekt

2 Stunden

ROW_ACCESS_POLICIES

Objekt

2 Stunden

SCHEMATA

Objekt

2 Stunden

SEARCH_OPTIMIZATION_HISTORY

Historisch

3 Stunden

Enterprise Edition (oder höher)

Daten werden für 1 Jahr aufbewahrt.

SEQUENCES

Objekt

2 Stunden

SERVERLESS_TASK_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

SERVICES

Objekt

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

SESSION_POLICIES

Objekt

2 Stunden

SESSIONS

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

SNOWPARK_CONTAINER_SERVICES_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

SNOWPIPE_STREAMING_CLIENT_HISTORY

Historisch

2 Stunden

Daten werden für 1 Jahr aufbewahrt.

SNOWPIPE_STREAMING_FILE_MIGRATION_HISTORY

Historisch

12 Stunden

Daten werden für 1 Jahr aufbewahrt.

STAGES

Objekt

2 Stunden

STAGE_STORAGE_USAGE_HISTORY

Historisch

2 Stunden

Daten werden für 1 Jahr aufbewahrt.

STORAGE_USAGE

Historisch

2 Stunden

Kombinierte Nutzung für alle Datenbanktabellen und internen Stagingbereiche. Daten werden für 1 Jahr aufbewahrt.

TABLES

Objekt

90 Minuten

TABLE_CONSTRAINTS

Objekt

2 Stunden

TABLE_STORAGE_METRICS

Objekt

90 Minuten

TAG_REFERENCES

Objekt

2 Stunden

TAGS

Objekt

2 Stunden

TASK_HISTORY

Historisch

45 Minuten

TASK_VERSIONS

Objekt

3 Stunden

USERS

Objekt

2 Stunden

VIEWS

Objekt

90 Minuten

WAREHOUSE_EVENTS_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

WAREHOUSE_LOAD_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

WAREHOUSE_METERING_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

[1] Alle Latenzwerte sind ungefähre Werte. In einigen Fällen kann die tatsächliche Latenz geringer sein.

[2] Die Latenz der Ansichten für eine bestimmte Tabelle kann bis zu 2 Tage betragen, wenn die beiden folgenden Bedingungen erfüllt sind: 1. Seit der letzten Aktualisierung der gegebenen Tabelle in LOAD_HISTORY oder COPY_HISTORY wurden weniger als 32 DML-Anweisungen zur Tabelle hinzugefügt. 2. Seit der letzten Aktualisierung der gegebenen Tabelle in LOAD_HISTORY oder COPY_HISTORY wurden weniger als 100 Zeilen zur Tabelle hinzugefügt.

[3] Sofern nicht anders angegeben, ist die Account Usage-Ansicht für alle Konten verfügbar.

Account Usage-Tabellenfunktionen

Derzeit unterstützt Snowflake eine ACCOUNT_USAGE-Tabellenfunktion:

Tabellenfunktion

Datenaufbewahrung

Anmerkungen

TAG_REFERENCES_WITH_LINEAGE

N/A

Es werden nur Ergebnisse für die Rolle zurückgegeben, die Zugriff auf das angegebene Objekt hat.

Bemerkung

Ähnlich wie bei den Account Usage-Ansichten müssen Sie auch beim Aufruf dieser Tabellenfunktion die Latenz berücksichtigen. Die erwartete Latenz für diese Tabellenfunktion ist ähnlich der Latenz für die Ansicht TAG_REFERENCES.

READER_ACCOUNT_USAGE-Ansichten

Das Schema READER_ACCOUNT_USAGE enthält die folgenden Ansichten:

Ansicht

Typ

Latenz: sup:[1]

Anmerkungen

LOGIN_HISTORY

Historisch

2 Stunden

Daten werden für 1 Jahr aufbewahrt.

QUERY_HISTORY

Historisch

45 Minuten

Daten werden für 1 Jahr aufbewahrt.

RESOURCE_MONITORS

Objekt

2 Stunden

STORAGE_USAGE

Historisch

2 Stunden

Kombinierte Nutzung für alle Datenbanktabellen und internen Stagingbereiche. Daten werden für 1 Jahr aufbewahrt.

WAREHOUSE_METERING_HISTORY

Historisch

3 Stunden

Daten werden für 1 Jahr aufbewahrt.

[1] Alle Latenzwerte sind ungefähre Werte. In einigen Fällen kann die tatsächliche Latenz geringer sein.

Aktivieren der Nutzung der SNOWFLAKE-Datenbank für andere Rollen

Standardmäßig ist die Datenbank SNOWFLAKE für alle Benutzer sichtbar. Der Zugriff auf Schemas in dieser Datenbank kann jedoch von einem Benutzer mit der Rolle ACCOUNTADMIN mit einer der folgenden Methoden gewährt werden:

  • Erteilen der IMPORTED PRIVILEGES-Berechtigungen für die SNOWFLAKE-Datenbank.

  • Zuweisen einer SNOWFLAKE-Datenbankrolle zu einer Kontorolle.

Wichtig

Gehen Sie besonders sorgfältig vor, wenn Sie Berechtigungen für die SNOWFLAKE-Datenbank innerhalb eines Kontos erteilen, bei dem die Rolle ORGADMIN aktiviert ist. Innerhalb dieses Kontos kann jeder mit Berechtigungen für die SNOWFLAKE-Datenbank auf das Schema ORGANIZATION_USAGE zugreifen.

Um zu vermeiden, dass unbeabsichtigt Zugriff auf Daten auf Organisationsebene gewährt wird, sollten Sie stattdessen durch Verwendung von SNOWFLAKE-Datenbankrollen Zugriff auf Ansichten im ACCOUNT_USAGE-Schema gewähren.

Weitere Informationen dazu finden Sie unter GRANT DATABASE ROLE.

So weisen Sie beispielsweise zwei zusätzlichen Rollen die IMPORTED PRIVILEGES-Berechtigungen für die SNOWFLAKE-Datenbank zu:

USE ROLE ACCOUNTADMIN;

GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE SYSADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE customrole1;
Copy

Ein Benutzer, dem die Rolle customrole1 zugewiesen wurde, kann eine Ansicht wie folgt abfragen:

USE ROLE customrole1;

SELECT database_name, database_owner FROM SNOWFLAKE.ACCOUNT_USAGE.DATABASES;
Copy

Weitere Beispiele finden Sie unter Abfragen der Account Usage-Ansichten.

ACCOUNT_USAGE-Schema – SNOWFLAKE-Datenbankrollen

Darüber hinaus können Sie Konten mit SNOWFLAKE-Datenbankrollen eine differenziertere Kontrolle ermöglichen. Weitere Informationen zu Datenbankrollen finden Sie unter Datenbankrollen.

ACCOUNT_USAGE-Schemas haben vier definierte SNOWFLAKE-Datenbankrollen, die jeweils die SELECT-Berechtigung für bestimmte Ansichten haben.

Rolle

Zweck und Beschreibung

OBJECT_VIEWER

Die Rolle OBJECT_VIEWER bietet Einblick in die Metadaten eines Objekts.

USAGE_VIEWER

Die Rolle USAGE_VIEWER bietet Einblick in historische Nutzungsinformationen.

GOVERNANCE_VIEWER

Die Rolle GOVERNANCE_VIEWER bietet Einblick in richtlinienbezogene Informationen.

SECURITY_VIEWER

Die Rolle SECURITY_VIEWER bietet Einblick in sicherheitsrelevante Informationen.

ACCOUNT_USAGE-Ansichten nach Datenbankrolle

Die Rollen OBJECT_VIEWER, USAGE_VIEWER, GOVERNANCE_VIEWER und SECURITY_VIEWER haben die SELECT-Berechtigung, um die Account Usage-Ansichten der freigegebenen SNOWFLAKE-Datenbank abzufragen.

Ein Häkchen (d. h. ✔) bedeutet, dass die Rolle über die SELECT-Berechtigung für die Ansicht verfügt.

Ansicht

OBJECT_VIEWER-Rolle

USAGE_VIEWER-Rolle

GOVERNANCE_VIEWER-Rolle

SECURITY_VIEWER-Rolle

COLUMNS-Ansicht

Ansicht COMPLETE_TASK_GRAPHS

DATABASES-Ansicht

Ansicht ELEMENT_TYPES

Ansicht FIELDS

FILE_FORMATS-Ansicht

FUNCTIONS-Ansicht

Ansicht OBJECT_DEPENDENCIES

PIPES-Ansicht

REFERENTIAL_CONSTRAINTS-Ansicht

SCHEMATA-Ansicht

SEQUENCES-Ansicht

STAGES-Ansicht

TABLE_CONSTRAINTS-Ansicht

TABLES-Ansicht

TAGS-Ansicht

VIEWS-Ansicht

Ansicht AUTOMATIC_CLUSTERING_HISTORY

Ansicht CLASS_INSTANCES

Ansicht CLASSES

COPY_HISTORY-Ansicht

Ansicht DATA_TRANSFER_HISTORY

DATABASE_STORAGE_USAGE_HISTORY-Ansicht

Ansicht EVENT_USAGE_HISTORY

Ansicht EXTERNAL_ACCESS_HISTORY

LOAD_HISTORY-Ansicht

MATERIALIZED_VIEW_REFRESH_HISTORY-Ansicht

Ansicht METERING_DAILY_HISTORY

Ansicht METERING_HISTORY

PIPE_USAGE_HISTORY-Ansicht

Ansicht REPLICATION_USAGE_HISTORY

Ansicht REPLICATION_GROUP_REFRESH_HISTORY

Ansicht REPLICATION_GROUP_USAGE_HISTORY

Ansicht SERVICES

Ansicht SNOWPARK_CONTAINER_SERVICES_HISTORY

SEARCH_OPTIMIZATION_HISTORY-Ansicht

Ansicht SERVERLESS_TASK_HISTORY

STAGE_STORAGE_USAGE_HISTORY-Ansicht

STORAGE_USAGE-Ansicht

Ansicht TABLE_STORAGE_METRICS

Ansicht TASK_HISTORY

Ansicht WAREHOUSE_EVENTS_HISTORY

WAREHOUSE_LOAD_HISTORY-Ansicht

WAREHOUSE_METERING_HISTORY-Ansicht

Ansicht MASKING_POLICIES

Ansicht QUERY_ACCELERATION_ELIGIBLE

QUERY_HISTORY-Ansicht

Ansicht AGGREGATE_QUERY_HISTORY

Ansicht POLICY_REFERENCES

ROW_ACCESS_POLICIES-Ansicht

Ansicht TAG_REFERENCES

ACCESS_HISTORY-Ansicht

Ansicht GRANTS_TO_ROLES

Ansicht GRANTS_TO_USERS

LOGIN_HISTORY-Ansicht

Ansicht PASSWORD_POLICIES

Ansicht ROLES

Ansicht SESSION_POLICIES

SESSIONS-Ansicht

Ansicht USERS

READER_ACCOUNT_USAGE-Schema – SNOWFLAKE-Datenbankrollen

Die Datenbankrolle READER_USAGE_VIEWER SNOWFLAKE hat die SELECT-Berechtigung für alle READER_ACCOUNT_USAGE-Ansichten. Da Leserkonten von Clients erstellt werden, wird erwartet, dass die Rolle READER_USAGE_VIEWER denjenigen Rollen zugewiesen wird, die zur Überwachung der Nutzung von Leserkonten verwendet werden.

Ansicht

LOGIN_HISTORY-Ansicht

QUERY_HISTORY-Ansicht

RESOURCE_MONITORS-Ansicht

STORAGE_USAGE-Ansicht

WAREHOUSE_METERING_HISTORY-Ansicht

Abfragen der Account Usage-Ansichten

Dieser Abschnitt enthält Hinweise zum Abfragen der Account Usage-Ansichten sowie Abfragebeispiele.

Auswählen von Spalten

Die Snowflake-spezifischen Ansichten können sich noch ändern. Vermeiden Sie es, in diesen Ansichten alle Spalten auszuwählen. Wählen Sie stattdessen nur die wirklich erforderlichen Spalten aus. Wenn Sie zum Beispiel die Spalte name benötigen, verwenden Sie SELECT name und nicht SELECT *.

Abstimmen der Kostenansichten

Es gibt mehrere Account Usage-Ansichten zur Kontonutzung, die Daten zu den Kosten für Computeressourcen, Speicher und Datentransfers enthalten. Wenn Sie versuchen, diese Ansichten mit einer entsprechenden Ansicht im Schema ORGANIZATION_USAGE abzustimmen, müssen Sie zunächst die Zeitzone der Sitzung auf UTC einstellen.

Wenn Sie beispielsweise versuchen, ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY mit den Daten des Kontos in ORGANIZATION_USAGE.WAREHOUSE_METERING_HISTORY abzustimmen, müssen Sie erst den folgenden Befehl ausführen, bevor Sie die Account Usage-Ansicht abfragen:

ALTER SESSION SET TIMEZONE = UTC;
Copy

Beispiele

Die folgenden Beispiele zeigen einige typische/nützliche Abfragen unter Verwendung der Ansichten im ACCOUNT_USAGE-Schema.

Bemerkung

  • In diesen Beispielen wird davon ausgegangen, dass die SNOWFLAKE-Datenbank und das ACCOUNT_USAGE-Schema für die aktuelle Sitzung aktiv sind. Außerdem wird vorausgesetzt, dass die ACCOUNTADMIN-Rolle (oder eine Rolle, der in der Datenbank IMPORTED PRIVILEGES gewährt wurden) zum Einsatz kommt. Wenn diese nicht verwendet werden, führen Sie folgende Befehle aus, bevor Sie die Abfragen in den Beispielen ausführen:

    USE ROLE ACCOUNTADMIN;
    
    USE SCHEMA snowflake.account_usage;
    
    Copy

Beispiele: Benutzeranmeldemetriken

Durchschnittliche Anzahl von Sekunden zwischen fehlgeschlagenen Anmeldeversuchen nach Benutzern (aktueller Monat):

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

Fehlgeschlagene Anmeldungen nach Benutzer (aktueller Monat):

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

Fehlgeschlagene Anmeldungen nach Benutzern und zu verbindenden Clients (aktueller Monat):

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

Beispiele: Performance von Warehouses

Diese Abfrage berechnet die Leistungsmetriken des virtuellen Warehouses wie Durchsatz und Latenz für 15-minütige Zeitintervalle im Verlauf eines Tages.

Im folgenden Codebeispiel können Sie CURRENT_WAREHOUSE() durch den Namen eines Warehouses ersetzen, um die Kennzahlen für dieses Warehouse zu berechnen. Ändern Sie außerdem die Datumsangaben für time_from und time_to in der WITH-Klausel, um einen bestimmten Zeitraum anzugeben.

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

Bemerkung

Analysieren Sie verschiedene Anweisungstypen getrennt (z. B. SELECT-Anweisungen unabhängig von INSERT oder DELETE oder anderen Anweisungen).

  • Der NUMJOBS-Wert stellt den Durchsatz für dieses Zeitintervall dar.

  • Die Werte P50_TOTAL_DURATION (Median) und P95_TOTAL_DURATION (Spitzenwert) stellen die Latenz dar.

  • Der Wert SUM_TOTAL_DURATION ist die Summe der SUM_<Jobphase>_TIME-Wert für die verschiedenen Jobphasen (COMPILATION_AND_SCHEDULING, QUEUED, BLOCKED, EXECUTION).

  • Analysieren Sie die <Jobphase>_RATIO-Werte, wenn der Workload (NUMJOBS) steigt. Achten Sie auf Verhältnisänderungen oder Abweichungen vom Durchschnitt.

  • Wenn der Wert für QUEUED_RATIO hoch ist, bietet das Warehouse möglicherweise nicht ausreichend Kapazität. Fügen Sie weitere Cluster hinzu, oder vergrößern Sie das Warehouse.

Beispiele: Credit-Nutzung von Warehouses

Credits, die von den einzelnen Warehouses in Ihrem Konto verbraucht werden (aktueller Monat):

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

Credits, die im Zeitverlauf von einzelnen Warehouses in Ihrem Konto verbraucht wurden (aktueller Monat):

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

Beispiele: Datenspeichernutzung

Abrechnungsfähige Terabyte, die im Zeitverlauf in Ihrem Konto gespeichert wurden:

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

Beispiele: Gesamtzahl der Benutzerabfragen und Ausführungszeiten

Gesamtzahl der in Ihrem Konto ausgeführten Jobs (aktueller Monat):

select count(*) as number_of_jobs
from query_history
where start_time >= date_trunc(month, current_date);
Copy

Gesamtzahl der Aufträge, die von den einzelnen Warehouses in Ihrem Konto ausgeführt wurden (aktueller Monat):

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

Durchschnittliche Ausführungszeit für Abfragen nach Benutzer (aktueller Monat):

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

Durchschnittliche Ausführungszeit für Abfragen nach Abfragetyp und Warehouse-Größe (aktueller Monat):

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

Beispiele: Abfrageanzahl für jedes Anmeldeereignis abrufen

Verknüpfen Sie Spalten aus LOGIN_HISTORY, QUERY_HISTORY und SESSIONS, um die Anzahl der Abfragen für jedes Benutzeranmeldeereignis zu erhalten.

Bemerkung

In der SESSIONS-Ansicht werden Informationen ab 20./21. Juli 2020 aufgezeichnet. Daher wird das Abfrageergebnis nur überlappende Informationen für jede der drei Ansichten ab diesem Datum enthalten.

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