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_NAME
및 SCHEMA_NAME
열)도 NULL입니다.
어떤 뷰에서는 오브젝트가 삭제되었더라도 오브젝트 이름 열에 여전히 오브젝트 이름이 포함될 수 있습니다.
데이터 대기 시간¶
Snowflake의 내부 메타데이터 저장소에서 데이터를 추출하는 프로세스로 인해, 계정 사용량 뷰에는 자연스러운 대기 시간이 있습니다.
대부분의 뷰에서 대기 시간은 2시간(120분)입니다.
나머지 뷰의 대기 시간은 45분에서 3시간 사이입니다.
자세한 내용은 이 항목에 있는 각 스키마에 대한 뷰 목록을 참조하십시오. 또한, 이러한 대기 시간은 모두 최대 시간이라는 점에 유의하십시오. 주어진 뷰를 쿼리할 때 해당 뷰의 실제 대기 시간은 더 짧을 수 있습니다.
반대로, Snowflake Information Schema 의 뷰/테이블 함수에는 대기 시간이 없습니다.
과거 데이터 보존¶
과거 사용량 메트릭을 제공하는 계정 사용량 뷰가 있습니다. 이러한 뷰의 보존 기간은 1년(365일)입니다.
반대로, Snowflake Information Schema 에 있는 해당 뷰와 테이블 함수는 뷰에 따라 7일에서 6개월 사이로, 보존 기간이 훨씬 짧습니다.
ACCOUNT_USAGE 뷰¶
ACCOUNT_USAGE 스키마에는 다음과 같은 뷰가 있습니다.
뷰 |
타입 |
대기 시간 [1] |
에디션 [3] |
참고 |
---|---|---|---|---|
과거 |
3시간 |
Enterprise Edition 이상 필요 |
데이터는 1년간 보존됩니다. |
|
과거 |
3시간 |
Enterprise Edition 이상 필요 |
데이터는 1년간 보존됩니다. |
|
과거 |
3시간 |
|||
오브젝트 |
2시간 |
|||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
3시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
3시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
90분 |
|||
과거 |
45분 |
데이터는 1년간 보존됩니다. |
||
과거 |
2시간 [2] |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
3시간 |
Enterprise Edition 이상 필요 |
테이블이 존재하는 동안 데이터가 유지됩니다. |
|
오브젝트 |
3시간 |
|||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
2시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
90분 |
|||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
2시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
90분 |
|||
오브젝트 |
2시간 |
|||
오브젝트 |
2시간 |
|||
오브젝트 |
2시간 |
|||
오브젝트 |
2시간 |
|||
오브젝트 |
3시간 |
|||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
3시간 |
|||
오브젝트 |
3시간 |
|||
과거 |
90분:sup:[2] |
데이터는 1년간 보존됩니다. |
||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
2시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
2시간 |
|||
과거 |
3시간 |
Enterprise Edition 이상 필요 |
데이터는 1년간 보존됩니다. |
|
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
2시간 |
|||
오브젝트 |
2시간 |
|||
오브젝트 |
2시간 |
|||
과거 |
3시간 |
|||
오브젝트 |
2시간 |
|||
오브젝트 |
2시간 |
|||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
2시간 |
|||
오브젝트 |
2시간 |
|||
오브젝트 |
2시간 |
|||
과거 |
3시간 |
Enterprise Edition 이상 필요 |
데이터는 1년간 보존됩니다. |
|
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
45분 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
2시간 |
|||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
2시간 |
|||
오브젝트 |
2시간 |
|||
오브젝트 |
2시간 |
|||
과거 |
3시간 |
Enterprise Edition 이상 필요 |
데이터는 1년간 보존됩니다. |
|
오브젝트 |
2시간 |
|||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
3시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
2시간 |
|||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
2시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
12시간 |
데이터는 1년간 보존됩니다. |
||
오브젝트 |
2시간 |
|||
과거 |
2시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
2시간 |
모든 데이터베이스 테이블과 내부 스테이지에 걸친 총 사용량입니다. 데이터는 1년간 보존됩니다. |
||
오브젝트 |
90분 |
|||
오브젝트 |
2시간 |
|||
오브젝트 |
90분 |
|||
오브젝트 |
2시간 |
|||
오브젝트 |
2시간 |
|||
과거 |
45분 |
|||
오브젝트 |
3시간 |
|||
오브젝트 |
2시간 |
|||
오브젝트 |
90분 |
|||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
||
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
[1] 모든 대기 시간은 대략적인 수치로, 경우에 따라 실제 대기 시간은 더 짧을 수도 있습니다.
:sub:`[2] 다음 조건이 둘 다 참인 경우 특정 테이블에 대한 뷰의 대기 시간은 최대 2일일 수 있습니다. 1. LOAD_HISTORY 또는 COPY_HISTORY에서 마지막으로 업데이트된 이후 특정 테이블에 32개 미만의 DML 문이 추가되었습니다. 2. LOAD_HISTORY 또는 COPY_HISTORY에서 마지막으로 업데이트된 이후 특정 테이블에 100개 미만의 행이 추가되었습니다.
[3] 달리 명시되지 않는 한 Account Usage 뷰는 모든 계정에서 사용할 수 있습니다.
Account Usage 테이블 함수¶
현재, Snowflake는 다음 한 가지 ACCOUNT_USAGE 테이블 함수를 지원합니다.
테이블 함수 |
데이터 보존 |
참고 |
---|---|---|
N/A |
지정된 오브젝트에 액세스할 권한이 있는 역할에 대해서만 결과가 반환됩니다. |
참고
Account Usage 뷰와 유사하게, 이 테이블 함수를 호출하는 경우에도 지연 시간을 고려해야 합니다. 이 테이블 함수의 예상 지연 시간은 TAG_REFERENCES 뷰의 지연 시간과 유사합니다.
READER_ACCOUNT_USAGE 뷰¶
READER_ACCOUNT_USAGE 스키마에는 다음과 같은 뷰가 있습니다.
뷰 |
타입 |
대기 시간 [1] |
참고 |
---|---|---|---|
과거 |
2시간 |
데이터는 1년간 보존됩니다. |
|
과거 |
45분 |
데이터는 1년간 보존됩니다. |
|
오브젝트 |
2시간 |
||
과거 |
2시간 |
모든 데이터베이스 테이블과 내부 스테이지에 걸친 총 사용량입니다. 데이터는 1년간 보존됩니다. |
|
과거 |
3시간 |
데이터는 1년간 보존됩니다. |
[1] 모든 대기 시간은 대략적인 수치로, 경우에 따라 실제 대기 시간은 더 짧을 수도 있습니다.
다른 역할에 대한 SNOWFLAKE 데이터베이스 사용 활성화하기¶
기본적으로 SNOWFLAKE 데이터베이스는 모든 사용자에게 표시되지만, 다음 접근 방법 중 하나를 사용하여 ACCOUNTADMIN 역할을 가진 사용자가 이 데이터베이스의 스키마에 대한 액세스 권한을 부여할 수 있습니다.
SNOWFLAKE 데이터베이스에 IMPORTED PRIVILEGES 권한을 부여합니다.
계정 역할에 SNOWFLAKE 데이터베이스 역할 을 부여합니다.
중요
ORGADMIN 역할이 활성화된 계정 내에서 SNOWFLAKE 데이터베이스에 권한을 부여할 때 주의하십시오. 해당 계정 내에서 SNOWFLAKE 데이터베이스에 대한 권한이 있는 사람은 누구나 ORGANIZATION_USAGE 스키마 에 액세스할 수 있습니다.
실수로 조직 수준 데이터에 대한 액세스 권한을 부여하지 않으려면 SNOWFLAKE 데이터베이스 역할 을 사용하여 ACCOUNT_USAGE 스키마의 뷰에 대한 액세스 권한을 부여해 보십시오.
자세한 내용은 GRANT DATABASE ROLE 섹션을 참조하십시오.
예를 들어 SNOWFLAKE 데이터베이스의 IMPORTED PRIVILEGES를 두 개의 추가 역할에 부여하려면 다음을 수행하십시오.
USE ROLE ACCOUNTADMIN; GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE SYSADMIN; GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE customrole1;
customrole1
역할이 부여된 사용자는 다음과 같이 뷰를 쿼리할 수 있습니다.
USE ROLE customrole1; SELECT database_name, database_owner FROM SNOWFLAKE.ACCOUNT_USAGE.DATABASES;
추가적인 예를 보려면 Account Usage 뷰 쿼리 섹션을 참조하십시오.
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, GOVERNANCE_VIEWER, SECURITY_VIEWER 역할에는 공유 SNOWFLAKE 데이터베이스에서 Account Usage 뷰를 쿼리할 SELECT 권한이 있습니다.
확인 표시(즉, ✔)는 역할에 뷰에 대한 SELECT 권한이 부여되었음을 나타냅니다.
뷰 |
OBJECT_VIEWER 역할 |
USAGE_VIEWER 역할 |
GOVERNANCE_VIEWER 역할 |
SECURITY_VIEWER 역할 |
---|---|---|---|---|
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
✔ |
|||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
✔ |
|||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
||||
✔ |
READER_ACCOUNT_USAGE 스키마 SNOWFLAKE 데이터베이스 역할¶
READER_USAGE_VIEWER SNOWFLAKE 데이터베이스 역할에는 모든 READER_ACCOUNT_USAGE 뷰에 대한 SELECT 권한이 부여됩니다. 클라이언트가 독자 계정을 생성하므로 독자 계정 사용 모니터링에 사용되는 역할에 READER_USAGE_VIEWER 역할이 부여될 것으로 예상됩니다.
뷰 |
---|
Account Usage 뷰 쿼리¶
이 섹션에는 쿼리 예제와 함께 Account Usage 뷰를 쿼리할 때의 고려 사항이 포함되어 있습니다.
열 선택하기¶
Snowflake 관련 뷰는 변경될 수 있습니다. 이러한 뷰에서 모든 열을 선택하지 마십시오. 대신, 원하는 열을 선택하십시오. 예를 들어, name
열을 원하면 SELECT *
대신 SELECT name
을 사용하십시오.
비용 뷰 조정¶
컴퓨팅 리소스, 저장소 및 데이터 전송 비용과 관련된 데이터가 포함된 Account Usage 뷰가 여러 개 있습니다. ORGANIZATION_USAGE 스키마 의 해당 뷰에 대해 이러한 뷰를 조정하려는 경우, 먼저 세션의 시간대를 UTC로 설정해야 합니다.
예를 들어 ORGANIZATION_USAGE.WAREHOUSE_METERING_HISTORY에서 계정의 데이터에 맞춰 ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY를 조정하려는 경우 다음 명령을 실행한 후 Account Usage 뷰를 쿼리해야 합니다.
ALTER SESSION SET TIMEZONE = UTC;
예¶
다음 예제에서는 ACCOUNT_USAGE 스키마의 뷰를 사용하는 몇 가지 전형적이고 유용한 쿼리를 보여줍니다.
참고
이러한 예에서는 SNOWFLAKE 데이터베이스와 ACCOUNT_USAGE 스키마가 현재 세션에 사용 중인 것으로 가정합니다. 또한, 이들 예에서는 ACCOUNTADMIN 역할(또는 데이터베이스에서 IMPORTED PRIVILEGES가 부여된 역할)이 사용 중이라고 간주합니다. 이들이 사용 중이지 않는 경우에는 다음 명령을 실행한 후에 예제의 쿼리를 실행하십시오.
USE ROLE ACCOUNTADMIN; USE SCHEMA snowflake.account_usage;
예: 사용자 로그인 메트릭¶
사용자의 로그인 시도 실패 간 평균 시간(초)(당월 합계):
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()
를 웨어하우스 이름으로 바꾸어 해당 웨어하우스의 메트릭을 계산할 수 있습니다. 또한 WITH 절에서 time_from
및 time_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 값을 분석합니다. 평균에서 비율 변경 또는 편차를 찾습니다.
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 ;