2022_02 번들¶

계층 구조 데이터 쿼리: 반복 제한이 더 이상 적용되지 않음¶

계층 구조 데이터를 쿼리할 때 재귀적 CTE 또는 CONNECT BY 명령 을 사용하여 계층 구조의 각 수준을 반복할 수 있습니다.

(Snowflake가 내부적으로) 이전에 100으로 설정한 반복 횟수에 대한 제한이 이제는 더 이상 적용되지 않습니다.

이전:

쿼리가 최대 반복 횟수(100)를 초과한 경우 쿼리가 실패하고 다음 오류 메시지가 표시됩니다.

Recursion exceeded max iteration count (n)

여기서 n 은 허용된 최대 반복 횟수입니다.

이 오류의 오류 코드는 100189 였습니다.

현재:

수행되는 반복 횟수에 제한이 없습니다.

이전에 위의 오류 메시지가 나타나며 실패한 쿼리(특히 무한 루프를 발생시키는 쿼리)는 이제 더 이상 실패하지 않으며 쿼리가 성공하거나 STATEMENT_TIMEOUT_IN_SECONDS 매개 변수를 설정하여 제어할 수 있는 시간 제한을 초과할 때까지 계속 실행됩니다.

이 변경 사항이 활성화되기 전에 최대 반복 횟수를 초과한 쿼리가 있었는지 확인하려면 QUERY_HISTORY 뷰에서 오류 코드 100189 로 실패한 쿼리가 있는지 확인하십시오.

SELECT * FROM snowflake.account_usage.query_history WHERE error_code = 100189;

Copy

변경 사항이 활성화된 상태에서 이러한 동일한 쿼리가 실행될 경우 쿼리가 실패하지 않습니다. 무한 루프가 발생하면 쿼리가 일찍 종료되지 않습니다. 대신 쿼리가 성공하거나 시간 초과될 때까지(예: STATEMENT_TIMEOUT_IN_SECONDS 매개 변수에 설정된 시간(초) 초과 시까지) 실행됩니다.

무한 루프가 발생할 수 있는 방법, 이러한 루프의 식별 및 수정 방법에 대한 정보는 재귀 CTE 문제 해결 섹션을 참조하십시오.

Time Travel: 일시적 테이블에 상속된 DATA_RETENTION_TIME_IN_DAYS 매개 변수가 유지됨¶

DATA_RETENTION_TIME_IN_DAYS 매개 변수가 상위 오브젝트(계정, 데이터베이스 또는 스키마)에 대해 0 (일)로 명시적으로 설정될 때 일시적 테이블 에 대한 동작이 다음과 같이 변경되었습니다.

이전:

일시적 테이블은 데이터 보존 시간이 0 일일 때 상위 오브젝트에서 DATA_RETENTION_TIME_IN_DAYS 매개 변수 설정을 상속하지 않았습니다. 상위 오브젝트의 데이터 보존 시간에 관계없이, 1 일의 데이터 보존 시간으로 일시적 테이블이 생성되었습니다.

현재:

상위 오브젝트의 DATA_RETENTION_TIME_IN_DAYS 가 0 으로 설정된 경우 일시적 테이블은 상위 오브젝트(스키마, 데이터베이스, 계정)에 설정된 데이터 보존 시간을 상속합니다.

상위 오브젝트(스키마 또는 데이터베이스) 중 하나 이상에 0 으로 설정된 DATA_RETENTION_TIME_IN_DAYS가 있는 계정에서 일시적 테이블 목록을 생성하려면 다음 예의 문을 실행하십시오. 하지만 문을 실행하기 전에 다음 사항에 유의하십시오.

• 이 목록에는 DATA_RETENTION_TIME_IN_DAYS 매개 변수가 명시적으로 1 로 설정된 일시적 테이블이 포함됩니다.

  계정 수준 에서 DATA_RETENTION_TIME_IN_DAYS가 0 으로 설정된 경우 아래의 두 번째 예제에 있는 문 세트를 실행하여 DATA_RETENTION_TIME_IN_DAYS가 1 로 설정된 모든 일시적 테이블을 나열합니다.

• 테이블에 대한 매개 변수 설정을 해제하기 전에 그 테이블에 대해 Time Travel을 비활성화해야 하는지 확인하는 것이 좋습니다.

show tables in account;
set
  table_qid = (
    select
      last_query_id()
);

show schemas in account;
set
  schema_qid = (
    select
      last_query_id()
);

show databases in account;
set
  database_qid = (
    select
      last_query_id()
);

with table_v as (
    select
      "database_name" as database_name,
      "schema_name" as schema_name,
      "name" as table_name,
      "kind" = 'TRANSIENT' as is_transient,
      "retention_time" as table_retention_time
    from
      table(result_scan($table_qid))
  ),
  schema_v as (
    select
      "name" as schema_name,
      iff(
        try_to_number("retention_time") is null,
        0,
        try_to_number("retention_time")
      ) as schema_retention_time
    from
      table(result_scan($schema_qid))
  ),
  database_v as (
    select
      "name" as database_name,
      "retention_time" as database_retention_time
    from
      table(result_scan($database_qid))
  )
select
  *
from
  table_v
  left join schema_v using (schema_name)
  left join database_v using (database_name)
where
  is_transient
  and table_retention_time = 1
  and (
    schema_retention_time = 0
    or database_retention_time = 0
  );

Copy

계정 수준 에서 DATA_RETENTION_TIME_IN_DAYS가 0 으로 설정된 경우 다음 문을 실행하여 DATA_RETENTION_TIME_IN_DAYS가 1 로 설정된 모든 일시적 테이블을 나열합니다.

-- Verify account level DATA_RETENTION_TIME_IN_DAYS setting is 0
show parameters like 'DATA_RETENTION_TIME_IN_DAYS' in account;

show tables in account;

select
  "database_name" as database_name,
  "schema_name" as schema_name,
  "name" as table_name,
  "kind" = 'TRANSIENT' as is_transient,
  "retention_time" as table_retention_time
from
  table(result_scan(last_query_id()))
where
  is_transient
  and table_retention_time = 1;

Copy

상위 오브젝트에서 매개 변수 설정을 상속할 수 있도록 기존의 일시적 테이블에 대한 DATA_RETENTION_TIME_IN_DAYS 매개 변수를 설정 해제하려면 ALTER TABLE 을 사용하십시오.

ALTER TABLE <table_name> UNSET DATA_RETENTION_TIME_IN_DAYS;

Copy

테이블에 설정된 데이터 보존 시간을 확인하려면 SHOW TABLES 를 사용하십시오.

SHOW TABLES LIKE '<table_name>';

Copy

SHOW ORGANIZATION ACCOUNTS 명령: 새 열¶

SHOW TAGS 명령의 출력에 추가된 새 열은 다음과 같습니다.

SHOW PROCEDURES 명령: 출력에 사용자 생성 저장 프로시저와 기본 제공 저장 프로시저가 모두 포함됨¶

Snowflake는 계정의 모든 데이터베이스에서 저장 프로시저를 스키마 수준 오브젝트로 만드는 기능을 지원합니다. SHOW PROCEDURES 명령은 이러한 사용자 생성 저장 프로시저에 대한 정보를 반환합니다.

Snowflake는 데이터 분류 를 도입해 이제는 기본 제공 함수와 유사한 전역 오브젝트로 호출할 수 있는 기본 제공 저장 프로시저도 제공합니다.

SHOW PROCEDURES 명령의 출력은 기본 제공 저장 프로시저를 지원하도록 다음과 같이 변경되었습니다.

이전:

이 명령은 현재 데이터베이스/스키마 또는 지정된 데이터베이스/스키마에서(또는 전체 계정에 대해) 사용자 생성 저장 프로시저만 반환했습니다.

Snowflake에서 제공하는 기본 제공 저장 프로시저를 보려면 이 명령에서 BUILTIN 키워드를 사용할 수 있습니다. 예:

SHOW BUILTIN PROCEDURES;

Copy

하지만 Snowflake는 단일 기본 제공 저장 프로시저 ASSOCIATE_SEMANTIC_CATEGORY_TAGS 만 제공합니다.

현재:

이 함수는 사용자 생성 저장 프로시저와 기본 제공 저장 프로시저를 둘 다 포함한 모든 저장 프로시저를 반환합니다.

이를 통해 SHOW PROCEDURES 명령이 SHOW FUNCTIONS 명령과 일치하게 됩니다.

이 변경 사항은 기본 제공 저장 프로시저 또는 사용자 생성 저장 프로시저를 명시적으로 반환하는 데 사용할 수 있는 BUILTIN 또는 USER 키워드에 영향을 미치지 않습니다. 예:

SHOW BUILTIN PROCEDURES;

SHOW USER PROCEDURES;

Copy

SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 함수: 추정 기준 변경 사항¶

SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 는 테이블에 검색 최적화 를 추가하는 데 드는 예상 비용을 결정하기 위해 호출할 수 있는 시스템 함수입니다.

이 함수는 작은 샘플을 비용 추정을 위한 기초로 사용하도록 변경되었습니다. 이러한 변경으로 이 함수는 더욱 정확한 비용 추정치를 보고합니다. 하지만 이 변경 사항은 웨어하우스 사용과 함수의 출력뿐 아니라, 아래의 설명과 같이 함수의 성능에도 영향을 미칠 수 있습니다.

이전:

이 함수는 간단한 모델을 사용해 비용을 추정했습니다. 이 함수가 간단한 모델을 사용해 비용을 추정했기에 다음과 같았습니다.

• 함수 호출 시 사용 중인 웨어하우스가 있을 필요가 없었습니다.

• 함수가 웨어하우스를 사용하지 않았으므로 이 함수를 위한 웨어하우스 사용량에 대한 비용이 청구되지 않았습니다.

• 함수가 몇 초 이내에 실행되고 결과를 반환했습니다.

• 반환된 JSON 출력에서 costPositions 배열에 BuildCosts 및 StorageCosts 로 명명된 오브젝트에 대해 다음과 같았습니다.

  • comment 필드가 없었습니다.

  • computationMethod 필드가 "EstimatedUpperBound" 로 설정되었습니다.

현재:

이제 이 함수는 지정된 테이블에서 작은 데이터 샘플을 가져와 임시 검색 액세스 경로를 생성하고 프로세스 비용을 분석하고 결과를 외삽하여 전체 테이블의 비용을 추정합니다. 이 함수가 샘플링을 사용해 비용을 추정하므로 다음과 같습니다.

• 함수를 호출하려면 사용 중인 웨어하우스가 있어야 합니다. 현재 사용 중인 웨어하우스가 없을 경우 이 함수는 다음 메시지를 인쇄합니다.

  No active warehouse selected in the current session.

  USE WAREHOUSE 명령으로 활성 웨어하우스를 선택합니다. X-Small 웨어하우스를 사용하여 이 함수를 실행할 수 있습니다. 웨어하우스 크기는 이 함수의 속도와 성능에 아무런 영향도 미치지 않습니다.

• 함수가 웨어하우스를 사용하지 않으므로 이제는 이 함수를 위한 웨어하우스 사용량에 대한 비용이 청구됩니다.

• 함수가 실행되어 결과를 반환하는 데 더 오랜 시간이 걸립니다(20초에서 10분 사이의 범위). 위에서 언급했듯이, 더 큰 웨어하우스 크기를 사용한다고 해서 이 함수가 더 빨리 실행되는 것은 아닙니다.

• 반환된 JSON 출력에서 costPositions 배열에 BuildCosts 및 StorageCosts 로 명명된 오브젝트에 대해 다음과 같았습니다.

  • comment 필드가 "estimated via sampling" 으로 설정됩니다.

  • computationMethod 필드가 "Estimated" 로 설정됩니다.

LOGIN_HISTORY 뷰(Account Usage): 새 열¶

이 릴리스에서 ACCOUNT_USAGE. LOGIN_HISTORY 뷰에 새로 추가된 열은 다음과 같습니다.

QUERY_HISTORY 뷰(Account Usage): QUERY_HISTORY 함수와 일치하는 출력¶

인바운드 및 아웃바운드 데이터 전송 바이트의 값이 다음 사이에서 일치하지 않습니다.

• ACCOUNT_USAGE.QUERY_HISTORY 및 READER_ACCOUNT_USAGE.QUERY_HISTORY 뷰

• INFORMATION_SCHEMA.QUERY_HISTORY 테이블 함수 출력

Account Usage 뷰는 데이터 전송 클라우드 값(각각 INBOUND_DATA_TRANSFER_CLOUD 또는 OUTBOUND_DATA_TRANSFER_CLOUD)이 Null일 때 인바운드 및 아웃바운드 데이터 전송 바이트를 포함합니다.

이들 뷰는 다음과 같이 변경되었습니다.

이전:

ACCOUNT_USAGE 및 READER_ACCOUNT_USAGE의 QUERY_HISTORY 뷰에는 다음이 포함되었습니다.

• INBOUND_DATA_TRANSFER_CLOUD 값이 Null일 때 INBOUND_DATA_TRANSFER_BYTES 열에 데이터 전송 바이트가 포함되었습니다.

• OUTBOUND_DATA_TRANSFER_CLOUD 값이 Null일 때 OUTBOUND_DATA_TRANSFER_BYTES 열에 데이터 전송 바이트가 포함되었습니다.

현재:

이제 뷰는 INFORMATION_SCHEMA QUERY_HISTORY 테이블 함수의 출력과 일치합니다.

INBOUND_DATA_TRANSFER_BYTES 및 OUTBOUND_DATA_TRANSFER_BYTES 열은 연결된 INBOUND_DATA_TRANSFER_CLOUD 또는 OUTBOUND_DATA_TRANSFER_CLOUD 값이 Null일 때 파일 전송의 바이트를 포함하지 않습니다.

DESCRIBE STREAM / SHOW STREAM 명령: 출력의 새 열¶

DESCRIBE STREAM 및 SHOW STREAMS 명령의 출력에는 이제 다음의 추가 열이 포함됩니다.

기존 TABLE_NAME 열과 TYPE 열 사이에 새 열이 삽입되었습니다.

디렉터리 테이블: 스테이지 생성 시 메타데이터가 자동으로 한 번 새로 고쳐짐¶

디렉터리 테이블을 포함하는 스테이지를 만들 때 디렉터리 테이블 메타데이터가 이제 자동으로 한 번 즉시 새로 고쳐집니다. 디렉터리 테이블 메타데이터를 새로 고치면 지정된 스테이지 경로의 현재 데이터 파일 목록과 메타데이터가 동기화됩니다.

이전에는 디렉터리 테이블 메타데이터에 기존 데이터 파일을 등록하려면 스테이지가 생성된 후 사용자가 ALTER STAGE … REFRESH 문을 실행해야 했습니다.

개선된 이 기능은 CREATE STAGE 명령의 새 REFRESH_ON_CREATE 매개 변수를 통해 구현됩니다. REFRESH_ON_CREATE = TRUE(기본값)일 때 스테이지 생성 시 Snowflake가 디렉터리 테이블 메타데이터를 자동으로 한 번 새로 고칩니다.