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 |
---|---|---|---|---|
Historisch |
3 Stunden |
Enterprise Edition (oder höher) |
Daten werden für 1 Jahr aufbewahrt. |
|
Historisch |
3 Stunden |
Enterprise Edition (oder höher) |
Daten werden für 1 Jahr aufbewahrt. |
|
Historisch |
3 Stunden |
|||
Objekt |
2 Stunden |
|||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
90 Minuten |
|||
Historisch |
45 Minuten |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
2 Stunden [2] |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
3 Stunden |
Enterprise Edition (oder höher) |
Die Daten bleiben so lange erhalten, wie die Tabelle existiert. |
|
Objekt |
3 Stunden |
|||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
2 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
90 Minuten |
|||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
2 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
90 Minuten |
|||
Objekt |
2 Stunden |
|||
Objekt |
2 Stunden |
|||
Objekt |
2 Stunden |
|||
Objekt |
2 Stunden |
|||
Objekt |
3 Stunden |
|||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
3 Stunden |
|||
Objekt |
3 Stunden |
|||
Historisch |
90 Minuten [2] |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
2 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
2 Stunden |
|||
Historisch |
3 Stunden |
Enterprise Edition (oder höher) |
Daten werden für 1 Jahr aufbewahrt. |
|
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
2 Stunden |
|||
Objekt |
2 Stunden |
|||
Objekt |
2 Stunden |
|||
Historisch |
3 Stunden |
|||
Objekt |
2 Stunden |
|||
Objekt |
2 Stunden |
|||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
2 Stunden |
|||
Objekt |
2 Stunden |
|||
Objekt |
2 Stunden |
|||
Historisch |
3 Stunden |
Enterprise Edition (oder höher) |
Daten werden für 1 Jahr aufbewahrt. |
|
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
45 Minuten |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
2 Stunden |
|||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
2 Stunden |
|||
Objekt |
2 Stunden |
|||
Objekt |
2 Stunden |
|||
Historisch |
3 Stunden |
Enterprise Edition (oder höher) |
Daten werden für 1 Jahr aufbewahrt. |
|
Objekt |
2 Stunden |
|||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
2 Stunden |
|||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
2 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
12 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
2 Stunden |
|||
Historisch |
2 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
2 Stunden |
Kombinierte Nutzung für alle Datenbanktabellen und internen Stagingbereiche. Daten werden für 1 Jahr aufbewahrt. |
||
Objekt |
90 Minuten |
|||
Objekt |
2 Stunden |
|||
Objekt |
90 Minuten |
|||
Objekt |
2 Stunden |
|||
Objekt |
2 Stunden |
|||
Historisch |
45 Minuten |
|||
Objekt |
3 Stunden |
|||
Objekt |
2 Stunden |
|||
Objekt |
90 Minuten |
|||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
Historisch |
3 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
||
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 |
---|---|---|
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 |
---|---|---|---|
Historisch |
2 Stunden |
Daten werden für 1 Jahr aufbewahrt. |
|
Historisch |
45 Minuten |
Daten werden für 1 Jahr aufbewahrt. |
|
Objekt |
2 Stunden |
||
Historisch |
2 Stunden |
Kombinierte Nutzung für alle Datenbanktabellen und internen Stagingbereiche. Daten werden für 1 Jahr aufbewahrt. |
|
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;
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;
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 |
---|---|---|---|---|
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
✔ |
|||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
✔ |
|||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
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 |
---|
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;
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;
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;
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;
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;
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;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;
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;
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;
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);
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;
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;
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;
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 ;