Account Usage

SNOWFLAKE 데이터베이스에서 ACCOUNT_USAGE 및 READER_ACCOUNT_USAGE 스키마를 사용하면 계정, 그리고 계정과 연결된 모든 독자 계정(있는 경우)에 대한 오브젝트 메타데이터와 과거 사용 데이터를 쿼리하는 것이 가능합니다.

이 항목의 내용:

Account Usage 스키마 개요

ACCOUNT_USAGE

계정에 대한 오브젝트 메타데이터와 사용량 메트릭을 표시하는 뷰입니다.

일반적으로, 이러한 뷰는 Snowflake Snowflake Information Schema 의 해당 뷰와 테이블 함수를 미러링하지만 다음과 같은 차이점이 있습니다.

  • 각각의 뷰에 포함된 삭제된 오브젝트에 대한 레코드

  • 과거 사용량 데이터에 대해 더욱 길어진 보존 기간

  • 데이터 대기 시간

자세한 내용은 이 항목에 있는 Account Usage와 Information Schema의 차이점 섹션을 참조하십시오. 각 뷰에 대한 자세한 내용은 이 항목에 있는 ACCOUNT_USAGE 뷰 섹션을 참조하십시오.

READER_ACCOUNT_USAGE

Secure Data Sharing 공급자로서 귀하의 계정을 위해 생성된 모든 독자 계정에 대한 오브젝트 메타데이터와 사용량 메트릭을 표시하는 뷰입니다.

이러한 뷰는 READER_ACCOUNT_USAGE에서만 사용할 수 있는 RESOURCE_MONITORS 뷰를 제외하고 독자 계정에 적용되는 ACCOUNT_USAGE 뷰의 소규모 서브세트입니다. 또한, 이 스키마의 각 뷰에는 독자 계정별로 결과를 필터링하기 위한 추가적인 READER_ACCOUNT_NAME 열이 있습니다.

각 뷰에 대한 자세한 내용은 이 항목에 있는 READER_ACCOUNT_USAGE 뷰 섹션을 참조하십시오.

귀하의 계정을 위해 생성된 독자 계정이 없는 경우 이러한 뷰는 비어 있습니다.

Account Usage와 Information Schema의 차이점

Snowflake Information Schema 의 Account Usage 뷰 및 해당 뷰(또는 테이블 함수)는 동일한 구조와 명명 규칙을 사용하지만, 이 섹션에 설명된 대로 몇 가지 주요 차이점이 있습니다.

차이점

Account Usage

Information Schema

삭제된 오브젝트 포함

아니요

데이터 대기 시간

45분~3시간(뷰에 따라 다름)

없음

과거 데이터 보존 기간

1년

7일~6개월(뷰/테이블 함수에 따라 다름)

자세한 내용은 다음 섹션을 참조하십시오.

삭제된 오브젝트에 대한 레코드

계정 사용량 뷰에는 삭제된 모든 오브젝트에 대한 레코드가 포함됩니다. 오브젝트 유형에 대한 많은 뷰에는 오브젝트가 삭제되었을 때의 타임스탬프를 표시하는 추가적인 DELETED 열이 포함됩니다.

또한, 오브젝트를 삭제하고 똑같은 이름으로 다시 만들 수 있으므로 같은 이름을 가진 오브젝트 레코드를 구별하기 위해 해당되는 경우 계정 사용량 뷰에는 시스템에서 생성해 각각의 레코드에 할당하는 내부 IDs를 표시하는 ID 열이 포함 됩니다.

오브젝트 이름의 열(예: TABLE_NAME 열)이 NULL이라면 그 오브젝트가 삭제된 것입니다. 이 경우에는 상위 오브젝트의 이름과 ID의 열(예: DATABASE_NAMESCHEMA_NAME 열)도 NULL입니다.

어떤 뷰에서는 오브젝트가 삭제되었더라도 오브젝트 이름 열에 여전히 오브젝트 이름이 포함될 수 있습니다.

데이터 대기 시간

Snowflake의 내부 메타데이터 저장소에서 데이터를 추출하는 프로세스로 인해, 계정 사용량 뷰에는 자연스러운 대기 시간이 있습니다.

  • 대부분의 뷰에서 대기 시간은 2시간(120분)입니다.

  • 나머지 뷰의 대기 시간은 45분에서 3시간 사이입니다.

자세한 내용은 이 항목에 있는 각 스키마에 대한 뷰 목록을 참조하십시오. 또한, 이러한 대기 시간은 모두 최대 시간이라는 점에 유의하십시오. 주어진 뷰를 쿼리할 때 해당 뷰의 실제 대기 시간은 더 짧을 수 있습니다.

반대로, Snowflake Information Schema 의 뷰/테이블 함수에는 대기 시간이 없습니다.

과거 데이터 보존

과거 사용량 메트릭을 제공하는 계정 사용량 뷰가 있습니다. 이러한 뷰의 보존 기간은 1년(365일)입니다.

반대로, Snowflake Information Schema 에 있는 해당 뷰와 테이블 함수는 뷰에 따라 7일에서 6개월 사이로, 보존 기간이 훨씬 짧습니다.

ACCOUNT_USAGE 뷰

ACCOUNT_USAGE 스키마에는 다음과 같은 뷰가 있습니다.

타입

대기 시간 [1]

참고

ACCESS_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

AUTOMATIC_CLUSTERING_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

COLUMNS

오브젝트

90분

COMPLETE_TASK_GRAPHS

과거

45분

데이터는 1년간 보존됩니다.

COPY_HISTORY

과거

2시간 [2]

데이터는 1년간 보존됩니다.

DATABASES

오브젝트

3시간

DATABASE_REPLICATION_USAGE_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

DATABASE_STORAGE_USAGE_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

DATA_TRANSFER_HISTORY

과거

2시간

데이터는 1년간 보존됩니다.

FILE_FORMATS

오브젝트

2시간

FUNCTIONS

오브젝트

2시간

GRANTS_TO_ROLES

오브젝트

2시간

GRANTS_TO_USERS

오브젝트

2시간

LOAD_HISTORY

과거

90분:sup:[2]

데이터는 1년간 보존됩니다.

LOCK_WAIT_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

LOGIN_HISTORY

과거

2시간

데이터는 1년간 보존됩니다.

MASKING_POLICIES

오브젝트

2시간

MATERIALIZED_VIEW_REFRESH_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

METERING_DAILY_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

METERING_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

OBJECT_DEPENDENCIES

과거

3시간

PASSWORD_POLICIES

오브젝트

2시간

PIPES

오브젝트

2시간

PIPE_USAGE_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

POLICY_REFERENCES

오브젝트

2시간

PROCEDURES

오브젝트

2시간

QUERY_ACCELERATION_ELIGIBLE

과거

3시간

데이터는 1년간 보존됩니다.

QUERY_ACCELERATION_HISTORY

과거

3시간

Query Acceleration Service 미리 보기의 일부로 제공됩니다. 데이터는 1년간 보존됩니다.

QUERY_HISTORY

과거

45분

데이터는 1년간 보존됩니다.

REFERENTIAL_CONSTRAINTS

오브젝트

2시간

REPLICATION_GROUP_REFRESH_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

REPLICATION_GROUP_USAGE_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

REPLICATION_USAGE_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

ROLES

오브젝트

2시간

ROW_ACCESS_POLICIES

오브젝트

2시간

SCHEMATA

오브젝트

2시간

SEARCH_OPTIMIZATION_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

SEQUENCES

오브젝트

2시간

SERVERLESS_TASK_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

SESSION_POLICIES

오브젝트

2시간

SESSIONS

과거

3시간

데이터는 1년간 보존됩니다.

STAGES

오브젝트

2시간

STAGE_STORAGE_USAGE_HISTORY

과거

2시간

데이터는 1년간 보존됩니다.

STORAGE_USAGE

과거

2시간

모든 데이터베이스 테이블과 내부 스테이지에 걸친 총 사용량입니다. 데이터는 1년간 보존됩니다.

TABLES

오브젝트

90분

TABLE_CONSTRAINTS

오브젝트

2시간

TABLE_STORAGE_METRICS

오브젝트

90분

TAG_REFERENCES

오브젝트

2시간

TAGS

오브젝트

2시간

TASK_HISTORY

과거

45분

TASK_VERSIONS

오브젝트

3시간

USERS

오브젝트

2시간

VIEWS

오브젝트

90분

WAREHOUSE_EVENTS_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

WAREHOUSE_LOAD_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

WAREHOUSE_METERING_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

[1] 모든 대기 시간은 대략적인 수치로, 경우에 따라 실제 대기 시간은 더 짧을 수도 있습니다.

[2] DML 문이 32개 이하이거나 행 개수가 100개 이하인 테이블의 경우, 이러한 뷰의 대기 시간은 최대 1일까지 걸릴 수도 있습니다.

Account Usage 테이블 함수

현재, Snowflake는 다음 한 가지 ACCOUNT_USAGE 테이블 함수를 지원합니다.

테이블 함수

데이터 보존

참고

TAG_REFERENCES_WITH_LINEAGE

N/A

지정된 오브젝트에 액세스할 권한이 있는 역할에 대해서만 결과가 반환됩니다.

참고

Account Usage 뷰와 유사하게, 이 테이블 함수를 호출하는 경우에도 지연 시간을 고려해야 합니다. 이 테이블 함수의 예상 지연 시간은 TAG_REFERENCES 뷰의 지연 시간과 유사합니다.

READER_ACCOUNT_USAGE 뷰

READER_ACCOUNT_USAGE 스키마에는 다음과 같은 뷰가 있습니다.

타입

대기 시간 [1]

참고

LOGIN_HISTORY

과거

2시간

데이터는 1년간 보존됩니다.

QUERY_HISTORY

과거

45분

데이터는 1년간 보존됩니다.

RESOURCE_MONITORS

오브젝트

2시간

STORAGE_USAGE

과거

2시간

모든 데이터베이스 테이블과 내부 스테이지에 걸친 총 사용량입니다. 데이터는 1년간 보존됩니다.

WAREHOUSE_METERING_HISTORY

과거

3시간

데이터는 1년간 보존됩니다.

[1] 모든 대기 시간은 대략적인 수치로, 경우에 따라 실제 대기 시간은 더 짧을 수도 있습니다.

다른 역할에 대해 Snowflake 데이터베이스 사용 활성화하기

기본적으로, SNOWFLAKE 데이터베이스는 ACCOUNTADMIN 역할에만 제공됩니다.

다른 역할이 이 데이터베이스와 스키마에 액세스하고 뷰를 쿼리할 수 있도록 하려면 ACCOUNTADMIN 역할을 가진 사용자가 원하는 역할에 다음 데이터 공유 권한을 부여해야 합니다.

IMPORTED PRIVILEGES

예:

USE ROLE ACCOUNTADMIN;

GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE SYSADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE customrole1;

USE ROLE customrole1;

SELECT database_name, database_owner FROM snowflake.account_usage.databases;

ACCOUNT_USAGE 스키마 SNOWFLAKE 데이터베이스 역할

그 밖에도, SNOWFLAKE 데이터베이스 역할을 사용하여 계정에 더 세밀한 제어 권한을 부여할 수 있습니다. 데이터베이스 역할에 대한 자세한 내용은 데이터베이스 역할 을 참조하십시오.

ACCOUNT_USAGE 스키마에는 네 가지 정의된 SNOWFLAKE 데이터베이스 역할이 있는데, 각각 특정 뷰에 대한 SELECT 권한이 부여됩니다.

역할

목적 및 설명

OBJECT_VIEWER

OBJECT_VIEWER 역할은 오브젝트 메타데이터에 대한 가시성을 제공합니다.

USAGE_VIEWER

USAGE_VIEWER 역할은 과거 사용량 정보에 대한 가시성을 제공합니다.

GOVERNANCE_VIEWER

GOVERNANCE_VIEWER 역할은 정책 관련 정보에 대한 가시성을 제공합니다.

SECURITY_VIEWER

SECURITY_VIEWER 역할은 보안 기반 정보에 대한 가시성을 제공합니다.

데이터베이스 역할별 ACCOUNT_USAGE 뷰

OBJECT_VIEWER, USAGE_VIEWER, GOVERNACE_VIEWER, SECURITY_VIEWER 역할에는 공유 SNOWFLAKE 데이터베이스에서 Account Usage 뷰를 쿼리할 SELECT 권한이 있습니다.

확인 표시(즉, ✔)는 역할에 뷰에 대한 SELECT 권한이 부여되었음을 나타냅니다.

OBJECT_VIEWER 역할

USAGE_VIEWER 역할

GOVERNANCE_VIEWER 역할

SECURITY_VIEWER 역할

COLUMNS 뷰

COMPLETE_TASK_GRAPHS 뷰

DATABASES 뷰

FILE_FORMATS 뷰

FUNCTIONS 뷰

OBJECT_DEPENDENCIES 뷰

PIPES 뷰

REFERENTIAL_CONSTRAINTS 뷰

SCHEMATA 뷰

SEQUENCES 뷰

STAGES 뷰

TABLE_CONSTRAINTS 뷰

TABLES 뷰

TAGS 뷰

VIEWS 뷰

AUTOMATIC_CLUSTERING_HISTORY 뷰

COPY_HISTORY 뷰

DATA_TRANSFER_HISTORY 뷰

DATABASE_STORAGE_USAGE_HISTORY 뷰

LOAD_HISTORY 뷰

MATERIALIZED_VIEW_REFRESH_HISTORY 뷰

METERING_DAILY_HISTORY 뷰

METERING_HISTORY 뷰

PIPE_USAGE_HISTORY 뷰

REPLICATION_USAGE_HISTORY 뷰

REPLICATION_GROUP_REFRESH_HISTORY 뷰

REPLICATION_GROUP_USAGE_HISTORY 뷰

SEARCH_OPTIMIZATION_HISTORY 뷰

SERVERLESS_TASK_HISTORY 뷰

STAGE_STORAGE_USAGE_HISTORY 뷰

STORAGE_USAGE 뷰

TABLE_STORAGE_METRICS 뷰

TASK_HISTORY 뷰

WAREHOUSE_EVENTS_HISTORY 뷰

WAREHOUSE_LOAD_HISTORY 뷰

WAREHOUSE_METERING_HISTORY 뷰

MASKING_POLICIES 뷰

QUERY_ACCELERATION_ELIGIBLE 뷰

QUERY_HISTORY 뷰

POLICY_REFERENCES 뷰

ROW_ACCESS_POLICIES 뷰

TAG_REFERENCES 뷰

ACCESS_HISTORY 뷰

GRANTS_TO_ROLES 뷰

GRANTS_TO_USERS 뷰

LOGIN_HISTORY 뷰

PASSWORD_POLICIES 뷰

ROLES 뷰

SESSION_POLICIES 뷰

SESSIONS 뷰

USERS 뷰

READER_ACCOUNT_USAGE 스키마 SNOWFLAKE 데이터베이스 역할

READER_USAGE_VIEWER SNOWFLAKE 데이터베이스 역할에는 모든 READER_ACCOUNT_USAGE 뷰에 대한 SELECT 권한이 부여됩니다. 클라이언트가 독자 계정을 생성하므로 독자 계정 사용 모니터링에 사용되는 역할에 READER_USAGE_VIEWER 역할이 부여될 것으로 예상됩니다.

LOGIN_HISTORY 뷰

QUERY_HISTORY 뷰

RESOURCE_MONITORS 뷰

STORAGE_USAGE 뷰

WAREHOUSE_METERING_HISTORY 뷰

Account Usage 뷰 쿼리

이 섹션에서는 ACCOUNT_USAGE 스키마의 뷰를 사용하는 몇 가지 일반적이고 유용한 쿼리의 예를 제시합니다.

참고

  • 이러한 예에서는 SNOWFLAKE 데이터베이스와 ACCOUNT_USAGE 스키마가 현재 세션에 사용 중인 것으로 가정합니다. 또한, 이들 예에서는 ACCOUNTADMIN 역할(또는 데이터베이스에서 IMPORTED PRIVILEGES가 부여된 역할)이 사용 중이라고 간주합니다. 이들이 사용 중이지 않는 경우에는 다음 명령을 실행한 후에 예제의 쿼리를 실행하십시오.

    USE ROLE ACCOUNTADMIN;
    
    USE SCHEMA snowflake.account_usage;
    
  • Snowflake 관련 뷰는 변경될 수 있습니다. 이러한 뷰에서 모든 열을 선택하지 마십시오. 대신, 원하는 열을 선택하십시오. 예를 들어, name 열을 원하면 SELECT * 대신 SELECT name 을 사용하십시오.

예: 사용자 로그인 메트릭

사용자의 로그인 시도 실패 간 평균 시간(초)(당월 합계):

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;

사용자별 로그인 실패 횟수(당월 합계):

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;

사용자 및 연결 중인 클라이언트별 로그인 실패 횟수(당월 합계):

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;

예: 웨어하우스 성능

이 쿼리는 하루 동안 15분 간격으로 처리량 및 대기 시간과 같은 가상 웨어하우스 성능 메트릭을 계산합니다.

아래 코드 샘플에서 CURRENT_WAREHOUSE()'MY_WH' 로 대체하여 특정 웨어하우스에 대한 메트릭을 계산합니다. 또한 WITH 절에서 time_fromtime_to 날짜를 변경합니다.

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;

참고

다른 문 유형을 별도로 분석합니다(예: INSERT 또는 DELETE 또는 기타 문과 독립적인 SELECT 문).

  • NUMJOBS 값은 해당 시간 간격에 대한 처리량을 나타냅니다.

  • P50_TOTAL_DURATION(중앙값) 및 P95_TOTAL_DURATION(피크) 값은 대기 시간을 나타냅니다.

  • SUM_TOTAL_DURATION은 다양한 작업 스테이지(COMPILATION_AND_SCHEDULING, QUEUED, BLOCKED, EXECUTION)에 대한 SUM_<job_stage>_TIME 값의 합계입니다.

  • 부하(NUMJOBS)가 증가할 때 <job_stage>_RATIO 값을 분석합니다. 평균에서 비율 변경 또는 편차를 찾습니다.

    • COMPILATION_AND_SCHEDULING_RATIO가 높으면 웨어하우스는 높은 동시성과 낮은 대기 시간 변경의 이점을 얻을 수 있습니다. 이러한 개선 사항은 모든 리전의 웨어하우스에서 제공됩니다.

    • QUEUED_RATIO가 높으면 웨어하우스에 용량이 충분하지 않을 수 있습니다. 클러스터를 더 추가하거나 웨어하우스 크기를 늘리십시오.

예: 웨어하우스 크레딧 사용

계정의 각 웨어하우스에서 사용한 크레딧(당월 합계):

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;

계정의 각 웨어하우스에서 시간의 경과에 따라 사용한 크레딧(당월 합계):

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;

예: 데이터 저장소 사용량

시간의 경과에 따라 계정에 저장된 청구 가능한 테라바이트 수:

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;

예: 사용자 쿼리 합계 및 실행 시간

계정에서 실행된 총 작업 수(당월 합계):

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

계정의 각 웨어하우스에서 실행된 총 작업 수(당월 합계):

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;

사용자별 평균 쿼리 실행 시간(당월 합계):

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;

쿼리 유형 및 웨어하우스 크기별 평균 쿼리 실행 시간(당월 합계):

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;

예: 모든 로그인 이벤트에 대한 쿼리 수 가져오기

LOGIN_HISTORY, QUERY_HISTORY, SESSIONS의 열을 조인하여 각 사용자 로그인 이벤트에 대한 쿼리 수를 가져옵니다.

참고

SESSIONS 뷰는 2020년 7월 20일~21일부터 정보를 기록하기 시작하므로, 쿼리 결과에는 이 날짜부터 시작해 세 가지 뷰 각각에 대해 겹치는 정보만 포함됩니다.

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
;
맨 위로 이동