ACCESS_HISTORY 뷰¶

열¶

이 섹션에는 다음 세 개의 테이블이 있습니다.

• 첫 번째 표에는 각 열 값의 예가 나와 있습니다.

• 두 번째 테이블은 ACCESS_HISTORY 뷰의 열을 정의합니다.

• 세 번째 테이블은 base_objects_accessed, direct_objects_accessed, objects_modified 열에 대한 JSON 배열의 필드를 정의합니다.

[
  {
    "objectDomain": "FUNCTION",
    "objectName": "GOVERNANCE.FUNCTIONS.RETURN_SUM",
    "objectId": "2",
    "argumentSignature": "(NUM1 NUMBER, NUM2 NUMBER)",
    "dataType": "NUMBER(38,0)"
  },
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "CONTENT"
      }
    ],
    "objectDomain": "Table",
    "objectId": 66564,
    "objectName": "GOVERNANCE.TABLES.T1"
  }
]

[
  {
    "objectDomain": "FUNCTION",
    "objectName": "GOVERNANCE.FUNCTIONS.RETURN_SUM",
    "objectId": "2",
    "argumentSignature": "(NUM1 NUMBER, NUM2 NUMBER)",
    "dataType": "NUMBER(38,0)"
  },
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "CONTENT"
      }
    ],
    "objectDomain": "Table",
    "objectId": 66564,
    "objectName": "GOVERNANCE.TABLES.T1"
  }
]

[
  {
    "objectDomain": "STRING",
    "objectId":  NUMBER,
    "objectName": "STRING",
    "columns": [
      {
        "columnId": "NUMBER",
        "columnName": "STRING",
        "baseSources": [
          {
            "columnName": STRING,
            "objectDomain": "STRING",
            "objectId": NUMBER,
            "objectName": "STRING"
          }
        ],
        "directSources": [
          {
            "columnName": STRING,
            "objectDomain": "STRING",
            "objectId": NUMBER,
            "objectName": "STRING"
          }
        ]
      }
    ]
  },
  ...
]

{
  "objectDomain": STRING,
  "objectName": STRING,
  "objectId": NUMBER,
  "operationType": STRING,
  "properties": ARRAY
}

[
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "SSN",
        "policies": [
          {
              "policyName": "governance.policies.ssn_mask",
              "policyId": 68811,
              "policyKind": "MASKING_POLICY"
          }
        ]
      }
    ],
    "objectDomain": "VIEW",
    "objectId": 66564,
    "objectName": "GOVERNANCE.VIEWS.V1",
    "policies": [
      {
        "policyName": "governance.policies.rap1",
        "policyId": 68813,
        "policyKind": "ROW_ACCESS_POLICY"
      }
    ]
  }
]

direct_objects_accessed, base_objects_accessed, objects_modified, policies_referenced 열에 대한 JSON 배열의 필드는 아래에 설명되어 있습니다.

object_modified_by_ddl 열에 대한 필드는 아래에 설명되어 있습니다.

properties 필드의 경우:

• 원자성: 속성당 하나의 값(예: comment 에 단일 문자열 값이 있고 enabled 속성은 부울이며 값이 1개 있음).

• 복합형: 속성이 다중 값을 가집니다(예: 태그의 allowed_values, 마스킹 정책).

복합형 속성은 JSON 배열에 기록됩니다. 예를 들어 테이블에 EMAIL이라는 단일 열이 포함된 경우 이 열은 다음과 같이 기록됩니다.

columns: {
  "email": {
    objectId: {
      "value": 1
    },
    "subOperationType": "ADD"
  }
}

subOperationType 값은 다음 중 하나일 수 있습니다.

• ADD 는 복합형 속성 추가를 지정합니다(예: 열 추가, 허용되는 값 설정).

• DROP 은 복합형 속성 제거를 지정합니다.

• ALTER 는 복합형 속성 수정을 지정합니다.

objectId 는 식별자가 없는 허용된 태그 값을 제외하고 열 또는 오브젝트의 식별자를 지정합니다.

사용법 노트¶

대기 시간 및 기록 데이터:

• 뷰에는 2021년 2월 22일부터 시작되는 데이터가 표시됩니다.

• 뷰의 지연 시간은 최대 180분(3시간)입니다.

상위 쿼리:

parent_query_id 및 root_query_id 열은 기본적으로 활성화됨으로 전환하는 2023_08 동작 변경 번들을 기반으로 Snowflake 계정이 업데이트된 시점에 따라 2024년 1월 15일~16일부터 데이터를 기록하기 시작합니다. 이 날짜는 뷰에서 다음 레코드를 구별하는 데 필요합니다.

• 번들이 기본적으로 활성화되기 전에 실행된 쿼리.

• 기능이 기본적으로 활성화된 후에 실행되었지만 parent_query_id 에 값이 없는 쿼리.

하이브리드 테이블:

하이브리드 테이블에 대해서만 작동하는 단기 실행 쿼리는 더 이상 QUERY_HISTORY 뷰, QUERY_HISTORY 또는 QUERY_HISTORY 테이블 함수의 출력에서 레코드를 생성하지 않습니다. 이러한 쿼리를 모니터링하려면 AGGREGATE_QUERY_HISTORY 를 사용하십시오.

이러한 쿼리에 대한 액세스 기록을 모니터링하려면 AGGREGATE_ACCESS_HISTORY 를 사용하십시오. 이 뷰를 사용하면 액세스 기록에 대한 처리량이 높은 운영 워크로드를 더 쉽게 모니터링할 수 있습니다.

일반 노트:

• 성능 향상을 위해 query_start_time 열에서 쿼리를 필터링하고 더 좁은 시간 범위를 선택하십시오. 샘플 쿼리는 ACCESS_HISTORY 뷰 쿼리하기 섹션을 참조하십시오.

• 보안 뷰. 로그 레코드에는 뷰를 생성하기 위한 기반 기본 테이블(즉, base_objects_accessed)이 포함됩니다. 예에는 다른 Account Usage 뷰와 Organization Usage 뷰에 대한 쿼리, 그리고 추출, 변환, 로딩(즉, ETL) 작업을 위한 기본 테이블에 대한 쿼리가 포함됩니다.

• QUERY_HISTORY 뷰의 레코드가 항상 ACCESS_HISTORY 뷰에 기록되는 것은 아닙니다. SQL 문의 구조에 따라 Snowflake가 ACCESS_HISTORY 뷰에 항목을 기록할지 여부가 결정됩니다.

• 이 뷰를 쿼리하는 동안 USING 절을 지정하면 참조되지 않은 열이 direct_objects_accessed 필드에 기록될 수 있습니다. 해결 방법으로, USING 절을 JOIN ... ON ... 절로 바꿔보십시오. 자세한 내용은 다음을 참조하십시오.

  • (JOIN 참조 항목의) JOIN 및 USING

  • (액세스 기록 쿼리 예의) 민감한 스테이지 데이터 이동 추적하기

읽기 쿼리 노트:

이 뷰는 다음 형식의 읽기 쿼리를 지원합니다.

• SELECT, 포함: CREATE TABLE … AS SELECT(즉 CTAS).

  • Snowflake는 CTAS 작업에서 SELECT 하위 쿼리를 기록합니다.

• CREATE TABLE … CLONE

  • Snowflake는 CLONE 작업에서 소스 테이블을 기록합니다.

• COPY INTO … TABLE

  • Snowflake는 테이블이 FROM 절에서 소스로 지정된 경우에 한해 이 쿼리를 로그합니다.

• 데이터를 읽는 DML 작업(예: SELECT 하위 쿼리 포함, WHERE 또는 JOIN의 특정 열 지정): INSERT … SELECT, UPDATE, DELETE 및 MERGE.

• 함수 내부의 쿼리에 테이블이 포함된 경우 UDF 및 테이블 형식 SQL UDF(UDTF). 이는 base_objects_accessed 필드에 로그됩니다.

  UDF에 대한 자세한 내용은 이 항목의 UDF 노트 를 참조하십시오.

쓰기 작업 노트:

이 뷰는 다음 유형의 쓰기 작업을 지원합니다.

• GET <내부_스테이지>

• PUT <내부_스테이지>

• DELETE

• TRUNCATE

• INSERT

  • INSERT INTO … FROM SELECT *

  • INSERT INTO TABLE … VALUES ()

• MERGE INTO … FROM SELECT *

• UPDATE

  • UPDATE TABLE … FROM SELECT * FROM …

  • UPDATE TABLE … WHERE …

• 데이터 로딩 문:

  • COPY INTO TABLE FROM internalStage

  • COPY INTO TABLE FROM externalStage

  • COPY INTO TABLE FROM externalLocation

• 데이터 언로딩 문:

  • COPY INTO internalStage FROM TABLE

  • COPY INTO externalStage FROM TABLE

  • COPY INTO externalLocation FROM TABLE

• CREATE:

  • CREATE DATABASE … CLONE

  • CREATE SCHEMA … CLONE

  • CREATE TABLE … CLONE

  • CREATE TABLE … AS SELECT

• SELECT 쿼리에서 CASE 함수를 포함한 CTAS 문과 같이, 액세스할 열을 결정하려고 CASE 함수를 호출하는 쓰기 작업의 경우 모든 CASE 분기에서 참조되는 모든 열은 base_objects_accessed 열, direct_objects_accessed 열 또는 CTAS 문의 작성 방식에 따라 두 열 모두에 기록됩니다.

데이터 공유 노트:

데이터 공유 공급자 계정이 공유를 통해 데이터 공유 컨슈머 계정에 오브젝트를 공유하는 경우:

• 공급자 계정: 공급자 계정에서 실행된 공유 오브젝트에 대한 쿼리와 로그는 데이터 공유 컨슈머 계정에 표시되지 않습니다.

• 컨슈머 계정: 컨슈머 계정에서 실행된 데이터 공유에 대한 쿼리는 로그되며, 데이터 공유 공급자 계정이 아닌 컨슈머 계정에만 표시됩니다.

  예를 들어 공급자가 테이블과 테이블에서 작성된 뷰를 컨슈머 계정에 공유하고 공유된 뷰에 대한 쿼리가 있는 경우, Snowflake는 base_objects_accessed 열에 공유 뷰 액세스를 기록합니다. 컨슈머는 columnName 및 objectName 값을 포함하는 이 레코드를 통해 자신의 계정에서 액세스한 오브젝트를 알 수 있는데, 기본 테이블이 (objectId 및 columnId 를 통해) 컨슈머에게 공개되지 않으므로 이 레코드는 공급자도 보호합니다.

• 열 계보의 경우:

  데이터 공유 공급자가 데이터 공유 컨슈머에게 뷰를 제공하면 열이 데이터 공유 공급자에서 시작되므로 뷰의 원본 열이 컨슈머에게 표시되지 않습니다.

  데이터 공유 컨슈머가 데이터를 공유 뷰에서 테이블로 이동하는 경우 Snowflake는 새로 생성된 테이블에 대해 뷰 열을 baseSources 로 기록하지 않습니다.

• 공유 UDF 및 UDTF의 경우:

  • 컨슈머 계정에서 로컬 ACCESS_HISTORY 뷰는 컨슈머가 공유 UDF/UDTF를 호출할 때 공급자가 공유한 UDF/UDTF를 기록합니다.

  • 공급자 계정에서 로컬 ACCESS_HISTORY 뷰는 공유 UDF/UDTF의 공급자 사용을 기록합니다. 컨슈머 계정의 사용자는 공급자 계정이 공유 UDF/UDTF를 사용하는 방법을 볼 수 없습니다.

• 정책 참조 추적의 경우:

  policies_referenced 열에는 데이터를 쿼리하는 계정에 국한된 정책이 포함됩니다.

  공급자가 정책으로 보호되는 테이블을 공유하고 컨슈머가 이 테이블에 액세스하는 경우 컨슈머는 공급자가 테이블 또는 테이블의 열에 설정한 정책을 볼 수 없습니다.

  컨슈머가 공유 오브젝트에서 뷰(v1)를 생성하고 뷰(v1) 또는 뷰의 열에 대한 정책을 설정하고 컨슈머 계정의 사용자가 보호된 뷰(v1) 또는 보호된 뷰(v1)에서 생성된 또 다른 뷰(v2)에 액세스하는 경우, 컨슈머 계정의 ACCESS_HISTORY 뷰에는 뷰(v1)와 뷰의 열을 보호하는 정책이 포함됩니다. 공급자는 v1 에 해당하는 레코드를 볼 수 없습니다.

Snowflake Native App Framework 참고 사항:

Snowflake Native App 과 관련된 일부 쿼리를 수정했습니다. 자세한 내용은 SQL 명령 및 뷰에서 수정된 정보 섹션을 참조하십시오.

태그 기반 마스킹 노트:

사용자가 태그 기반 마스킹 정책 으로 보호되는 테이블 또는 뷰에 액세스하면 policies_referenced 열에 Snowflake가 보호된 열에 마스킹 정책을 적용할 때 태그를 통해 적용된 마스킹 정책이 포함됩니다.

ACCESS_HISTORY 뷰는 어떤 태그 정보도 기록하지 않습니다.

UDF 및 저장 프로시저 노트:

이러한 참고 사항은 이들 함수에 SECURE 속성이 있는 경우를 포함하여 외부 함수, 모든 언어의 UDF와 UDTF, 소유자 권한과 호출자 권한이 있는 저장 프로시저에 적용됩니다.

열 세부 정보:

• direct_objects_accessed 열에는 쿼리에서 이러한 함수 및 프로시저에 대한 명시적 언급을 기록됩니다.

  Snowflake에서는 이 열에 중첩된 UDF(즉, 다른 UDF의 정의에 언급된 UDF)를 기록하지 않습니다.

• base_objects_accessed 열에는 쿼리에서 호출되는 외부 함수, 공유 함수, 비 SQL UDF, 저장 프로시저가 기록됩니다.

• objects_modified 열에는 다음이 기록됩니다.

  • 함수 호출 결과가 다른 열에 결과를 복사할 때는 UDF/UDTF.

  • 쿼리 작성 방법에 따라 baseSources 및 directSources 에 대한 배열에 UDF, UDTF, 외부 함수가 기록될 수 있습니다.

지원되지 않음:

이 뷰는 다음 형식의 액세스를 로그하지 않습니다.

• Snowflake에서 제공하는 테이블 함수, Account Usage 뷰, 조직 사용 뷰.

• 이전 결과를 얻기 위한 RESULT_SCAN.

• 새로운 값 생성을 포함한 시퀀스.

• 기본 테이블과 직접 오브젝트 간에 액세스되는 중간 뷰입니다.

  예를 들어 다음과 같은 오브젝트 구조를 가진 뷰_A에 대한 쿼리를 생각해 보십시오. 뷰_A » 뷰_B » 뷰_C » 기본_테이블.

  ACCESS_HISTORY 뷰는 뷰_B 및 뷰_C가 아니라 뷰_A 및 기본_테이블에 대한 쿼리를 기록합니다.

• 스트림을 업데이트하는 작업입니다.

• 복제에 따른 데이터 이동.

사용법 노트: 열 계보¶

다음 추가 노트는 열 계보와 관련이 있습니다.

지원되는 작업:

열 계보는 다음 SQL 작업의 세부 정보를 추적합니다.

• CREATE TABLE … AS SELECT (CTAS)

• CREATE TABLE … CLONE

• INSERT … SELECT …

• MERGE

• 예를 들어 UPDATE, 두 가지 가능한 변형:

  • 자체 업데이트:

    UPDATE mydb.s1.t1 SET col_1 = col_1 + 1;
    

    Copy

  • 두 테이블 업데이트:

    UPDATE mydb.s1.t1 FROM mydb.s2.t2 SET t1.col1 = t2.col1;
    

    Copy

• ALTER TABLE … RENAME TO

쿼리 조건:

• 쿼리 프로필/계획

  Snowflake가 작성하는 쿼리 계획에 따라 ACCESS_HISTORY 뷰가 열 계보를 포함하는지 여부가 결정됩니다. 열을 쿼리 계획의 일부로 평가해야 하는 경우, 쿼리 계획의 최종 결과가 열이 최종 결과에 포함되지 않는 것이라 하더라도 Snowflake는 ACCESS_HISTORY 뷰에 열을 포함합니다.

  예를 들어, 특정 열 값에 대한 WHERE 절이 있는 다음 INSERT 문을 고려하십시오.

  insert into a(c1)
  select c2
  from b
  where c3 > 1;
  

  Copy

  WHERE 절이 FALSE 로 평가되더라도, Snowflake는 c2 열을 c1 열의 원본 열로 기록합니다. c3 열은 baseSources 또는 directSources 에 대한 원본 열로 나열되지 않습니다.

• 마스킹된 열:

  • 마스킹된 열은 항상 directSources 필드에 나열됩니다.

  • baseSources 필드의 레코드는 정책 정의에 따라 다릅니다. 예:

    • 마스킹 정책 조건이 CASE 함수를 사용하는 경우 각 CASE 분기에서 참조하는 모든 열이 baseSources 필드에 기록됩니다.

    • 마스킹 정책 조건이 상수 값(예: *****)만 지정하는 경우에는 baseSources 필드가 비어 있습니다.

• UDF:

  • 열을 UDF에 인자로 전달하고 결과를 다른 열에 쓸 때 인자로 전달된 열은 directSources 필드에 기록됩니다. 예:

    insert into A(col1) select f(col2) from B;
    

    Copy

    이 예제에서 열이 f 라는 UDF의 인자이므로 Snowflake는 directSources 필드에 col2 를 기록합니다.

  • baseSources 필드의 레코드는 UDF 정의에 따라 다릅니다.

뷰 열:

뷰 열은 원본 열로 간주되지 않으며 뷰 열의 데이터가 테이블 열로 복사될 때 baseSources 필드에 나열되지 않습니다. 이 경우 뷰 열은 directSources 필드에 나열됩니다.

EXISTS 하위 쿼리:

EXISTS 하위 쿼리 절에서 참조되는 열은 원본 열로 간주되지 않습니다.

사용법 노트: object_modified_by_ddl 열¶

• IF [ NOT ] EXISTS 절: object_modified_by_ddl 열은 오브젝트를 생성하거나 수정할 때 CREATE 또는 REPLACE 만 기록합니다.

• Snowflake는 다음 오브젝트 도메인을 지원합니다.

  • 테이블 및 외부 테이블.

  • 뷰 및 구체화된 뷰

  • 스키마

  • 데이터베이스.

열은 다음 SQL 작업을 기반으로 이러한 변경 사항을 기록합니다. DROP 및 UNDROP 작업은 열이 아닌 테이블과 뷰에 적용됩니다.

CREATE OR REPLACE

ALTER ... { SET | UNSET }

ALTER ... ADD ROW ACCESS POLICY

ALTER ... DROP ROW ACCESS POLICY

ALTER ... DROP ALL ROW ACCESS POLICIES

DROP | UNDROP

다음 표는 DDL 작업, 지원되는 도메인, Snowflake가 기록하는 속성 사이의 관계를 요약한 것입니다.