2022_06 번들¶

복제 그룹: Business Critical Edition이 아닌 계정에 대한 데이터베이스 및 공유로 제한된 오브젝트 유형¶

계정 복제 기능은 사용자, 역할, 데이터베이스, 공유를 포함한 계정 오브젝트의 복제를 지원합니다. 지원되는 오브젝트 유형의 전체 목록은 복제된 오브젝트 섹션을 참조하십시오. 복제 그룹 은 지원되는 오브젝트 유형 중 일부 또는 전부를 포함할 수 있습니다.

이 동작이 다음과 같이 변경되었습니다.

이전

지원되는 모든 계정 복제 오브젝트 유형이 복제 그룹에 포함될 수 있습니다.

현재

Business Critical Edition(또는 그 이상)이 아닌 계정의 복제 그룹에 추가할 수 있는 오브젝트 유형에 대한 지원은 데이터베이스와 공유로 제한됩니다.

에디션별 기능 지원에 대한 자세한 내용은 계정 복제 기능 지원 표 를 참조하십시오.

Fail-safe 저장소: 과소 청구를 초래하는 코너 케이스에 대한 버그 수정¶

내부 시스템 오류로 인해, 일부 영구 테이블에 대해 Fail-safe 바이트의 저장소 요금이 청구되지 않았습니다. 특히, 일시적 테이블이 영구 테이블의 복제본으로 생성되고 그 이후에 영구 테이블이 삭제되는 경우 Snowflake는 영구 테이블의 Fail-safe 저장소에 대해 요금을 청구하지 않았습니다.

Fail-safe에 대한 요금 청구가 다음과 같이 변경되었습니다.

이전

일부 영구 테이블은 Fail-safe 저장소에 대해 요금이 청구되지 않았습니다.

현재

모든 영구 테이블에 대한 Fail-safe 저장소 요금이 고객에게 청구됩니다.

CREATE DATABASE 및 CREATE SCHEMA 명령: 정책에 대한 허상 참조의 OR REPLACE 절 결과¶

CREATE DATABASE 및 CREATE SCHEMA 명령의 동작이 다음과 같이 변경되었습니다.

이전

Snowflake는 CREATE OR REPLACE DATABASE 명령과 CREATE OR REPLACE SCHEMA 명령이 다른 데이터베이스 또는 스키마의 오브젝트를 보호하는 마스킹 정책 또는 행 액세스 정책이 포함된 데이터베이스 또는 스키마에서 실행할 수 있도록 허용했습니다. 예:

• db1.s1.p1 이라는 마스킹 정책은 db2.s1.t1.c1 이라는 열을 보호합니다.

• db1.s1.p2 라는 행 액세스 정책은 db2.s1.t1 이라는 테이블을 보호합니다.

열 또는 오브젝트에 대한 모든 쿼리가 실패하게 만드는 허상 참조가 그 결과였습니다.

이 동작은 CREATE OR REPLACE SCHEMA S1 CLONE S2; 와 같은 CLONE 문에도 적용됩니다.

현재

결과가 정책으로 보호되는 오브젝트에 대한 허상 참조인 경우 CREATE OR REPLACE DATABASE 명령 또는 CREATE OR REPLACE SCHEMA 명령은 실패합니다. Snowflake는 다음 오류 메시지 중 하나를 반환합니다.

• CREATE OR REPLACE DATABASE: Cannot drop database because: Policy '<db.schema.policy>' used by schema '<db.schema>' in another database 의 경우

• CREATE OR REPLACE SCHEMA: Cannot drop schema because: Policy '<db.schema.policy>' used by another schema '<db.schema>' 의 경우

두 오류 메시지 중 하나가 발생하면 Account Usage POLICY_REFERENCES 뷰를 쿼리하고, 역할을 사용하여 마스킹 정책이나 행 액세스 정책을 설정 해제한 다음, CREATE OR REPLACE 문을 다시 시도하십시오.

예:

1. 뷰를 쿼리합니다.

   • 교체하기 전에 제거해야 하는 교차 스키마 정책 참조:

     select * from snowflake.account_usage.policy_references
     where policy_db=<policy_db> and
     policy_schema=<policy_schema_to_replace> and ref_schema_name != <policy_schema>;
     

     Copy

   • 교체하기 전에 제거해야 하는 교차 데이터베이스 정책 참조:

     select * from snowflake.account_usage.policy_references
     where policy_db=<policy_db_to_replace>’ and ref_database_name != <policy_db>;
     

     Copy

2. 정책 설정을 해제합니다.

   • 마스킹 정책 의 경우:

     alter table <table_name> modify column <col_name> unset masking policy;
     

     Copy

   • 행 액세스 정책 의 경우:

     alter table <table_name> drop all row access policies;
     

     Copy

3. CREATE OR REPLACE 명령을 다시 시도합니다.

CLONE 작업 사용 시, CLONE 문을 실행하기 전에 정책 오브젝트를 별도의 데이터베이스나 스키마에 저장해야 합니다.

INFER_SCHEMA 함수: 출력의 새 ORDER_ID 열¶

INFER_SCHEMA 함수의 출력에 이제는 스테이징된 파일에서의 열 순서를 나타내는 새로운 ORDER_ID 열이 포함됩니다.

현재, 스테이징된 파일 세트에서 파생된 열 정의를 사용하여 테이블을 만들 때(CREATE TABLE … USING TEMPLATE 사용), 테이블의 열 순서는 임의적입니다. Snowflake에서는 테이블 열 순서가 중요하지 않지만, 파일 열 순서를 테이블 열 순서와 비교할 때 혼동을 일으킬 수 있습니다. INFER_SCHEMA 출력의 새로운 ORDER_ID 열은 감지된 스키마로 생성된 테이블이 똑같은 열 순서를 갖도록 하는 데 도움이 될 수 있습니다.

다음 예제에서 보여주는 바와 같이, INFER_SCHEMA를 사용하여 모든 파일의 스키마를 검색할 수 있습니다. 출력은 새 열 ORDER_ID를 포함하고 단일 스키마 시나리오에 대해 ORDER_ID를 기준으로 자동으로 정렬됩니다.

SELECT *
  FROM TABLE(
  INFER_SCHEMA(
  LOCATION=>'@***_****_STAGE/' , FILE_FORMAT=>'FFPARQUET'
  )
  );

Copy

또한 다음 예제에서 보듯이 스테이징된 파일에서 감지된 스키마를 사용하여 테이블을 만들고 ORDER_ID를 기준으로 열을 정렬할 수도 있습니다.

CREATE OR REPLACE TABLE BIG_TABLE
  USING TEMPLATE (
  SELECT ARRAY_AGG(OBJECT_CONSTRUCT(*))
  WITHIN GROUP (ORDER BY ORDER_ID) // NEW
  FROM TABLE( INFER_SCHEMA(LOCATION=>'@***_****_STAGE/', FILE_FORMAT=>'FFPARQUET')
  )
  );

DESC TABLE BIG_TABLE;

Copy

ORDER_ID를 기준으로 한 열 정렬은 모든 스테이징된 파일이 단일 스키마를 공유하는 경우에만 적용됩니다. 스테이징된 데이터 파일 세트에 공유 열 이름이 있는 여러 스키마가 포함된 경우 ORDER_ID 열에 표시된 순서가 어떤 단일 파일과도 일치하지 않을 수 있습니다.

FUNCTIONS 뷰(Account Usage): 뷰의 새 열¶

Account Usage FUNCTIONS 뷰의 출력에는 이제 다음과 같은 새 열이 포함됩니다.