동적 테이블 수정하기

동적 테이블 수정하기 (ALTER DYNAMIC TABLE)

동적 테이블의 속성을 수정해요.

고정 영역(Frozen regions)은 이전에 불변성 제약 조건(immutability constraints)이라고 불렸고, FROZEN WHERE 절은 이전에 IMMUTABLE WHERE 구문을 사용했어요. 이전 버전의 IMMUTABLE WHERE 구문은 계속 지원되며, SHOW DYNAMIC TABLES는 여전히 immutable_where 열을 사용해요.

출처: 문서

본문

구문

ALTER DYNAMIC TABLE [ IF EXISTS ]  { SUSPEND | RESUME }

ALTER DYNAMIC TABLE [ IF EXISTS ]  RENAME TO 

ALTER DYNAMIC TABLE [ IF EXISTS ]  SWAP WITH 

ALTER DYNAMIC TABLE [ IF EXISTS ]  [ ,  ... ] REFRESH [ COPY SESSION ]

ALTER DYNAMIC TABLE [ IF EXISTS ]  { clusteringAction }

ALTER DYNAMIC TABLE [ IF EXISTS ]  { tableColumnCommentAction }

ALTER DYNAMIC TABLE  { SET | UNSET } COMMENT = ''

ALTER DYNAMIC TABLE [ IF EXISTS ]  dataGovnPolicyTagAction

ALTER DYNAMIC TABLE [ IF EXISTS ]  searchOptimizationAction

ALTER DYNAMIC TABLE [ IF EXISTS ]  storageLifecyclePolicyAction

ALTER DYNAMIC TABLE [ IF EXISTS ]  SET
  [ TARGET_LAG = { ' { seconds | minutes | hours | days }'  | DOWNSTREAM } ],
  [ SCHEDULER = DISABLE | ENABLE ],
  [ WAREHOUSE =  ],
  [ INITIALIZATION_WAREHOUSE =  ],
  [ DATA_RETENTION_TIME_IN_DAYS =  ],
  [ MAX_DATA_EXTENSION_TIME_IN_DAYS =  ]
  [ DEFAULT_DDL_COLLATION = '' ],
  [ LOG_LEVEL = '' ],
  [ CONTACT (  =  [ ,  =  ... ] ) ],
  [ FROZEN WHERE (  ) ],
  [ EXECUTE AS USER 
    [ USE SECONDARY ROLES { ALL | NONE |  [ , ... ] } ]
  ]
  [ ROW_TIMESTAMP = { TRUE | FALSE } ]

ALTER DYNAMIC TABLE [ IF EXISTS ]  UNSET
  [ INITIALIZATION_WAREHOUSE ],
  [ DATA_RETENTION_TIME_IN_DAYS ],
  [ MAX_DATA_EXTENSION_TIME_IN_DAYS ],
  [ DEFAULT_DDL_COLLATION ],
  [ LOG_LEVEL ],
  [ CONTACT  ],
  [ FROZEN WHERE ],
  [ EXECUTE AS USER ],
  [ ROW_TIMESTAMP ],
  [ DCM PROJECT ]

여기서:

clusteringAction ::=
  {
    CLUSTER BY (  [ ,  , ... ] )
    | { SUSPEND | RESUME } RECLUSTER
    | DROP CLUSTERING KEY
  }

자세한 내용은 Clustering Keys & Clustered Tables를 참조하세요.

tableCommentAction ::=
  {
    ALTER | MODIFY [ ( ]
                           [ COLUMN ]  COMMENT ''
                         , [ COLUMN ]  UNSET COMMENT
                       [ , ... ]
                   [ ) ]
  }

dataGovnPolicyTagAction ::=
  {
      ADD ROW ACCESS POLICY  ON (  [ , ... ] )
    | DROP ROW ACCESS POLICY 
    | DROP ROW ACCESS POLICY  ,
        ADD ROW ACCESS POLICY  ON (  [ , ... ] )
    | DROP ALL ROW ACCESS POLICIES
  }
  |
  {
    SET AGGREGATION POLICY 
      [ ENTITY KEY (  [, ... ] ) ]
      [ FORCE ]
  | UNSET AGGREGATION POLICY
  }
  |
  {
    { ALTER | MODIFY } [ COLUMN ] 
        SET MASKING POLICY 
          [ USING (  ,  , ... ) ] [ FORCE ]
      | UNSET MASKING POLICY
  }
  |
  { ALTER | MODIFY } [ COLUMN ]  SET TAG
       = '' [ ,  = '' ... ]
      , [ COLUMN ]  SET TAG
           = '' [ ,  = '' ... ]
  |
  {
    { ALTER | MODIFY } [ COLUMN ] 
        SET PROJECTION POLICY 
          [ FORCE ]
      | UNSET PROJECTION POLICY
}
|
  { ALTER | MODIFY } [ COLUMN ]  UNSET TAG  [ ,  ... ]
                  , [ COLUMN ]  UNSET TAG  [ ,  ... ]
  }
  |
  {
      SET TAG  = '' [ ,  = '' ... ]
    | UNSET TAG  [ ,  ... ]
  }

searchOptimizationAction ::=
  {
    ADD SEARCH OPTIMIZATION [
      ON  [ ,  ... ]
        [ EQUALITY ]
      ]

    | DROP SEARCH OPTIMIZATION [
      ON {  |  |  }
        [ EQUALITY ]
        [ , ... ]
      ]

    | SUSPEND SEARCH OPTIMIZATION [
       ON {  |  |  }
          [ , ... ]
     ]

    | RESUME SEARCH OPTIMIZATION [
       ON {  |  |  }
          [ , ... ]
     ]
  }

자세한 내용은 을 참조하세요.

storageLifecyclePolicyAction ::=
  {
      ADD STORAGE LIFECYCLE POLICY  ON (  [ ,  ... ] )
    | DROP STORAGE LIFECYCLE POLICY
  }

자세한 내용은 Use storage lifecycle policies with dynamic tables를 참조하세요.

매개 변수

name

변경할 동적 테이블의 식별자예요.

식별자에 공백이나 특수 문자가 포함되어 있으면 전체 문자열을 큰따옴표로 묶어야 해요. 큰따옴표로 묶인 식별자는 대소문자를 구분해요.

자세한 내용은 Identifier requirements를 참조하세요.

SUSPEND | RESUME

동적 테이블에서 수행할 작업을 지정해요:

SUSPEND는 동적 테이블의 새로 고침을 일시 중단해요. 동적 테이블이 다른 동적 테이블에서 사용되는 경우 해당 테이블도 함께 일시 중단돼요.
RESUME는 동적 테이블의 새로 고침을 재개해요. 재개 작업은 수동으로 일시 중단되지 않은 모든 하위 동적 테이블로 연쇄적으로 적용돼요.

SCHEDULER = DISABLE이면 이 명령은 동적 테이블을 파이프라인 스케줄링에서 분리해요. TARGET_LAG 기반 새로 고침은 일시 중단되고, 이 동적 테이블에 대한 수동 새로 고침은 업스트림 동적 테이블로 연쇄되지 않아요.

RENAME TO new_name

지정된 동적 테이블을 스키마의 다른 동적 테이블에서 현재 사용하지 않는 새 식별자로 이름을 바꿔요.

동적 테이블 이름을 바꾸려면 해당 동적 테이블의 스키마에 대한 CREATE DYNAMIC TABLE 권한이 필요해요.

동적 테이블을 다른 데이터베이스 및/또는 스키마로 이동하면서 선택적으로 이름을 바꿀 수도 있어요. 이렇게 하려면 새 데이터베이스 및/또는 스키마 이름을 포함하는 정규화된 new_name 값을 각각 db_name.schema_name.new_name 또는 schema_name.new_name 형식으로 지정하세요.

다음 제한 사항이 적용돼요:

대상 데이터베이스 및/또는 스키마가 이미 존재해야 해요. 또한 새 위치에 같은 이름의 개체가 이미 있으면 안 돼요. 그렇지 않으면 문이 오류를 반환해요.
개체 소유자(즉, 개체에 대한 OWNERSHIP 권한이 있는 역할)가 대상 스키마도 소유하지 않는 한 개체를 관리형 액세스 스키마로 이동할 수 없어요.
개체(테이블, 열 등)의 이름을 바꾸면 해당 개체를 참조하는 다른 개체도 새 이름으로 업데이트해야 해요.

SWAP WITH target_dynamic_table_name

두 동적 테이블을 단일 트랜잭션에서 교환해요. 이 작업을 수행하는 역할은 두 동적 테이블 모두에 OWNERSHIP 권한이 있어야 해요.

다음 제한 사항이 적용돼요:

동적 테이블은 다른 동적 테이블과만 교환할 수 있어요.

REFRESH [ COPY SESSION ]

하나 이상의 동적 테이블을 수동으로 새로 고쳐요. 단일 문에서 여러 동적 테이블 이름을 쉼표로 구분하여 나열할 수 있어요.

사용자가 일시 중단한 동적 테이블과 자동으로 일시 중단된 동적 테이블 모두 수동으로 새로 고칠 수 있어요. 수동으로 새로 고친 동적 테이블은 DYNAMIC_TABLE_REFRESH_HISTORY 함수에서 refresh_trigger 출력으로 MANUAL을 반환해요.

SCHEDULER = DISABLE이면 단일 동적 테이블을 새로 고칠 때 해당 테이블만 새로 고쳐지고 다른 동적 테이블로는 연쇄되지 않아요.

SCHEDULER = ENABLE이면 동적 테이블을 새로 고칠 때 모든 업스트림 동적 테이블도 새로 고쳐지지만, SCHEDULER = DISABLE인 업스트림 동적 테이블에서 연쇄가 멈춰요.

단일 문에 여러 동적 테이블을 나열하면 각 나열된 동적 테이블의 SCHEDULER 설정과 관계없이 해당 테이블을 새로 고쳐요. SCHEDULER = DISABLE이어도 나열된 동적 테이블이 새로 고침 집합에서 제외되지 않아요.

다중 테이블 목록의 의미

Snowflake는 나열된 각 동적 테이블의 업스트림 종속성을 하나의 파이프라인으로 병합하고 단일 데이터 타임스탬프에서 해당 파이프라인을 새로 고쳐요. 나열된 두 동적 테이블이 업스트림을 공유하는 경우 해당 업스트림은 정확히 한 번 새로 고쳐져요. 나열된 각 동적 테이블은 자체 구성된 웨어하우스에서 새로 고쳐져요. IF EXISTS를 사용하면 Snowflake는 목록에서 기존 동적 테이블로 확인되지 않는 이름을 조용히 건너뛰고 나머지 동적 테이블에 대해서는 문이 성공해요.

제한 사항

나열된 각 동적 테이블은 고유한 개체여야 해요. 같은 테이블로 확인되는 짧은 이름, 따옴표로 묶인 이름, 정규화된 이름을 포함한 중복 이름은 오류를 발생시켜요.
이 문은 다중 문 트랜잭션 내에서 실행할 수 없어요.
다중 테이블 목록의 경우 역할의 OPERATE(또는 OWNERSHIP) 권한이 나열된 모든 동적 테이블과 파이프라인의 일부로 새로 고쳐지는 모든 업스트림 동적 테이블에 적용되어야 해요. 일반적인 권한 모델은 을 참조하세요.
나열된 동적 테이블 중 하나라도 FAILED, UPSTREAM_FAILED 또는 CANCELLED 새로 고침 상태로 끝나면 문이 오류를 반환해요. 이미 성공적으로 새로 고쳐진 동적 테이블은 새로 고침된 상태로 유지되며 해당 새로 고침 기록 행은 롤백되지 않아요.

원인과 해결 방법이 포함된 오류 코드는 Error code reference for dynamic tables를 참조하세요.

동적 테이블 새로 고침 상태에 대한 자세한 내용은 DYNAMIC_TABLE_REFRESH_HISTORY를 참조하세요.

COPY SESSION

현재 사용자와 웨어하우스를 사용하여 현재 세션의 복사본에서 새로 고침 작업을 실행해요.

이 기능은 단일 수동 새로 고침에만 적용되며 동적 테이블의 자격 증명을 영구적으로 업데이트하지 않아요. 예약된 새로 고침의 소유권을 이전하려면 GRANT OWNERSHIP 명령을 사용하세요. 자세한 내용은 을 참조하세요.

기본 역할은 동적 테이블을 소유한 역할이며 보조 역할은 사용자의 DEFAULT_SECONDARY_ROLES 속성과 일치해요.

SET ...

테이블에 설정할 하나 이상의 속성/매개 변수를 지정해요(공백, 쉼표 또는 새 줄로 구분):

TARGET_LAG = { num { seconds | minutes | hours | days } | DOWNSTREAM }

동적 테이블의 대상 지연 시간을 지정해요:

'num seconds | minutes | hours | days'

동적 테이블의 콘텐츠가 기본 테이블의 변경 사항보다 얼마나 지연될 수 있는지 최대 시간을 지정해요.

예를 들어:

동적 테이블의 데이터가 5분 이하로 지연되어야 한다면 5 minutes를 지정해요.
동적 테이블의 데이터가 5시간 이하로 지연되어야 한다면 5 hours를 지정해요.

최소 값은 1분이에요. 동적 테이블 A가 다른 동적 테이블 B에 의존하는 경우, A의 최소 지연 시간은 B의 지연 시간보다 크거나 같아야 해요.

DOWNSTREAM

동적 테이블의 하위에 있는 동적 테이블이 새로 고쳐지면 이 동적 테이블도 새로 고쳐지도록 지정해요.

SCHEDULER = { DISABLE | ENABLE }

Snowflake가 동적 테이블을 자동으로 새로 고칠지 여부를 지정해요.

DISABLE

동적 테이블을 자동 백그라운드 새로 고침에서 제외해요. 이 테이블은 직접 또는 하위 종속성을 통해 일정에 따라 새로 고쳐지지 않아요.

수동 제어: ALTER DYNAMIC TABLE ... REFRESH를 사용하여 새로 고침을 수동으로 트리거해야 해요.
격리: 비활성화된 테이블을 수동으로 새로 고쳐도 상위 종속성이 자동으로 새로 고쳐지지 않아요. 이로 인해 "격리 경계"가 생성되어 dbt와 같은 외부 오케스트레이터가 전체 파이프라인을 트리거하지 않고 특정 테이블 새로 고침을 격리하여 관리할 수 있어요.
SCHEDULER = DISABLE인 경우 TARGET_LAG를 정의할 수 없어요.

ENABLE

동적 테이블에 대한 자동 일정을 활성화해요. Snowflake는 스냅샷 일관성을 유지하기 위해 테이블을 해당 종속성과 함께 새로 고치며, 정의된 TARGET_LAG를 충족하도록 새로 고침을 예약해요.

WAREHOUSE = warehouse_name

동적 테이블을 새로 고치는 데 필요한 컴퓨팅 리소스를 제공하는 웨어하우스의 이름을 지정해요.

이 웨어하우스에 대한 USAGE 권한이 있는 역할을 사용해야 해요. 자세한 내용은 을(를) 참조하세요.

최적의 새로 고침 성능을 위한 웨어하우스 선택에 대한 지침은 을(를) 참조하세요.

INITIALIZATION_WAREHOUSE = warehouse_name

모든 동적 테이블 초기화 및 재초기화에 사용할 웨어하우스를 지정해요.

이 매개 변수를 설정하면 지정된 웨어하우스가 모든 초기화 및 재초기화에 사용되고, 그렇지 않으면 동적 테이블은 모든 새로 고침에 필수 WAREHOUSE 매개 변수로 지정된 웨어하우스를 사용해요.

이 웨어하우스에 대한 USAGE 권한이 있는 역할을 사용해야 해요. 자세한 내용은 을(를) 참조하세요.

DATA_RETENTION_TIME_IN_DAYS = integer

Time Travel을 위해 동적 테이블의 보존 기간을 수정하는 객체 수준 매개 변수예요. 자세한 내용은 Understanding & using Time Travel 및 Working with Temporary and Transient Tables을(를) 참조하세요.

이 매개 변수에 대한 자세한 설명과 객체 매개 변수에 대한 자세한 내용은 Parameters을(를) 참조하세요.

값:

Standard Edition: 0 또는 1
Enterprise Edition:
- 영구 동적 테이블의 경우 0~90
- 임시 동적 테이블의 경우 0 또는 1

0 값은 동적 테이블에 대해 Time Travel을 사실상 비활성화해요.

MAX_DATA_EXTENSION_TIME_IN_DAYS = integer

동적 테이블의 스트림이 오래되지 않도록 Snowflake가 데이터 보존 기간을 연장할 수 있는 최대 일 수를 지정하는 객체 매개 변수예요.

이 매개 변수에 대한 자세한 설명은 을(를) 참조하세요.

DEFAULT_DDL_COLLATION = 'collation_specification'

동적 테이블에 추가되는 모든 새 열에 대한 기본 collation specification을(를) 지정해요.

이 매개 변수를 설정해도 기존 열의 데이터 정렬 사양은 변경되지 않아요.

자세한 내용은 을(를) 참조하세요.

LOG_LEVEL = 'log_level'

활성 이벤트 테이블에 수집되어 제공되는 이 동적 테이블의 이벤트의 심각도 수준을 지정해요. 지정된 수준 이상의 이벤트가 수집돼요.

수준에 대한 자세한 내용은 을(를) 참조하세요. 로그 수준 설정에 대한 자세한 내용은 Setting levels for logging, metrics, and tracing을(를) 참조하세요.

CONTACT purpose = contact [ , purpose = contact ... ]

기존 객체를 하나 이상의 contacts와 연결해요. 유효한 목적의 목록은 을(를) 참조하세요.

같은 문에서 CONTACT 속성을 다른 속성과 함께 설정할 수 없어요.

FROZEN WHERE

동적 테이블의 고정 영역을 정의하는 조건을 지정해요. 자세한 내용은 Frozen regions and backfill을(를) 참조하세요. 동적 테이블에 RELY 속성이 있는 기본 키 또는 고유 제약 조건이 있는 경우, 조건자의 열은 모든 RELY PRIMARY KEY 및 RELY UNIQUE 제약 조건에 나타나야 해요(즉, 모든 RELY 제약 조건 열 집합의 교집합). 자세한 내용은 을(를) 참조하세요.

EXECUTE AS USER user_name

SYSTEM 사용자가 아닌 지정된 사용자로 동적 테이블을 새로 고쳐요.

EXECUTE AS USER를 지정하려면 user_name 사용자에 대한 IMPERSONATE 권한이 부여된 역할을 사용해야 해요. 이 권한을 부여하려면 GRANT <privileges> ... TO ROLE 명령을 실행하세요.

USE SECONDARY ROLES { ALL | NONE | role [ , ... ] }

동적 테이블에서 사용할 보조 역할을 지정해요. 실행에 기본적으로 사용되는 기본 보조 역할을 재정의하는 데 사용할 수 있어요.

EXECUTE AS USER 옵션과 함께만 사용할 수 있어요.

자세한 내용은 을(를) 참조하세요.

ROW_TIMESTAMP = { TRUE | FALSE }

테이블에 행 타임스탬프를 추가하거나 제거해요.

TRUE는 테이블에 행 타임스탬프를 추가합니다.
FALSE는 테이블에서 행 타임스탬프를 제거합니다. 이 매개변수 설정은 저장된 모든 METADATA$ROW_LAST_COMMIT_TIME 값을 영구적으로 삭제합니다. 다시 활성화해도 이러한 값은 복원되지 않으며 Time Travel 쿼리는 아무것도 반환하지 않습니다.

UNSET ...

동적 테이블에서 하나 이상의 속성/매개변수를 설정 해제하여 기본값으로 재설정합니다:

INITIALIZATION_WAREHOUSE
DATA_RETENTION_TIME_IN_DAYS
MAX_DATA_EXTENSION_TIME_IN_DAYS
DEFAULT_DDL_COLLATION
LOG_LEVEL
CONTACT 목적
FROZEN WHERE
EXECUTE AS USER
ROW_TIMESTAMP
DCM PROJECT

UNSET DCM PROJECT

현재 동적 테이블을 관리하는 DCM 프로젝트에서 동적 테이블을 분리합니다. 이 명령은 동적 테이블을 삭제하지 않고 동적 테이블과 %dcm-object% 간의 연결을 제거합니다. 자세한 내용은 을 참조하십시오.

클러스터링 작업 (`clusteringAction`)

CLUSTER BY ( expr [ , expr , ... ] )

동적 테이블의 클러스터링 키로 하나 이상의 테이블 열 또는 열 표현식을 지정(또는 수정)합니다. 이들은 Automatic Clustering에 의해 클러스터링이 유지되는 열/표현식입니다. 동적 테이블에 클러스터링 키를 지정하기 전에 마이크로 파티션을 이해해야 합니다. 자세한 내용은 Snowflake 테이블 구조 이해를 참조하십시오.

동적 테이블에서 클러스터링 키를 사용할 때 다음 사항에 유의하십시오:

열 정의는 필수이며 명령문에 명시적으로 지정해야 합니다.
클러스터링 키는 모든 테이블에 사용하도록 의도되거나 권장되지 않습니다. 일반적으로 매우 큰(예: 수 테라바이트) 테이블에 유용합니다.

SUSPEND | RESUME RECLUSTER

동적 테이블에 대해 Automatic Clustering을 활성화하거나 비활성화합니다.

DROP CLUSTERING KEY

동적 테이블의 클러스터링 키를 제거합니다.

클러스터링 키 및 리클러스터링에 대한 자세한 내용은 Snowflake 테이블 구조 이해를 참조하십시오.

테이블 주석 작업 (`tableCommentAction`)

ALTER | MODIFY [ ( ] [ COLUMN ] COMMENT '' , [ COLUMN ] UNSET COMMENT [ , ... ] [ ) ]

동적 테이블의 열에 대한 주석을 변경하거나 기존 주석을 덮어씁니다.

SET | UNSET COMMENT = ''

동적 테이블에 주석을 추가하거나 기존 주석을 덮어씁니다.

데이터 거버넌스 정책 및 태그 작업 (`dataGovnPolicyTagAction`)

TAG tag_name = 'tag_value' [ , tag_name = 'tag_value' , ... ]

태그 이름과 태그 문자열 값을 지정합니다.

태그 값은 항상 문자열이며, 태그 값의 최대 문자 수는 256자입니다.

명령문에서 태그를 지정하는 방법에 대한 자세한 내용은 을 참조하십시오.

policy_name

정책의 식별자입니다. 스키마 내에서 고유해야 합니다.

ADD ROW ACCESS POLICY policy_name ON (col_name [ , ... ])

동적 테이블에 행 액세스 정책을 추가합니다.

최소 하나의 열 이름을 지정해야 합니다. 추가 열은 각 열 이름을 쉼표로 구분하여 지정할 수 있습니다.

DROP ROW ACCESS POLICY policy_name

동적 테이블에서 행 액세스 정책을 제거합니다.

DROP ROW ACCESS POLICY policy_name, ADD ROW ACCESS POLICY policy_name ON ( col_name [ , ... ] )

동적 테이블에 설정된 행 액세스 정책을 제거하고 동일한 동적 테이블에 행 액세스 정책을 단일 SQL 문으로 추가합니다.

DROP ALL ROW ACCESS POLICIES

동적 테이블에서 모든 행 액세스 정책 연결을 제거합니다.

백업을 생성할 때 테이블에 행 액세스 정책이 적용되어 있었고 나중에 해당 정책이 삭제된 경우, 백업에서 복원한 동적 테이블에 액세스하려면 이 절도 사용해야 합니다. 동적 테이블이 복원된 후에는 DROP ALL ROW ACCESS POLICIES 절과 함께 ALTER TABLE 명령을 실행할 때까지 해당 테이블을 쿼리할 수 없습니다.

{ ALTER | MODIFY } [ COLUMN ] ...

USING ( col_name , cond_col_1 ... )

조건부 마스킹 정책에 전달할 인수를 지정합니다.

목록의 첫 번째 열은 정책 조건에 따라 마스킹 또는 토큰화할 데이터를 지정하며, 마스킹 정책이 적용되는 열과 일치해야 합니다.

추가 열은 첫 번째 열에서 선택할 때 쿼리 결과의 각 행에서 마스킹 또는 토큰화를 평가할 데이터를 지정합니다.

USING 절을 생략하면 Snowflake는 조건부 마스킹 정책을 일반 마스킹 정책으로 처리합니다.

SET AGGREGATION POLICY {policy_name}

[ ENTITY KEY ({col_name} [ , ... ]) ] [ FORCE ]

동적 테이블에 집계 정책을 할당합니다.

선택적 ENTITY KEY 매개변수를 사용하여 동적 테이블 내에서 엔터티를 고유하게 식별하는 열을 정의합니다. 자세한 내용은 집계 정책으로 엔터티 수준 개인 정보 보호 구현을 참조하십시오.

선택적 FORCE 매개변수를 사용하여 기존 집계 정책을 새 집계 정책으로 원자적으로 교체합니다.

UNSET AGGREGATION POLICY

동적 테이블에서 집계 정책을 분리합니다.

FORCE

단일 문에서 열에 현재 설정된 마스킹 또는 프로젝션 정책을 다른 정책으로 교체합니다.

FORCE 키워드를 마스킹 정책과 함께 사용하는 경우, ALTER DYNAMIC TABLE 문에서 정책의 데이터 타입(즉, STRING)이 열에 현재 설정된 마스킹 정책의 데이터 타입(즉, STRING)과 일치해야 합니다.

열에 마스킹 정책이 현재 설정되어 있지 않은 경우 이 키워드를 지정해도 효과가 없습니다.

자세한 내용은 또는 을 참조하십시오.

검색 최적화 작업 (`searchOptimizationAction`)

ADD SEARCH OPTIMIZATION

전체 동적 테이블에 대해 search optimization을(를) 추가하거나, 선택적 ON 절을 지정하면 특정 열에 대해 추가합니다.

검색 최적화는 유지 관리 비용이 많이 들 수 있으며, 특히 테이블의 데이터가 자주 변경되는 경우 더욱 그렇습니다. 자세한 내용은 을(를) 참조하세요.

ON search_method_with_target [, search_method_with_target ... ]

특정 열 또는 VARIANT 필드에 대해 검색 최적화를 구성하려는 경우 지정합니다(전체 동적 테이블이 아닌).

search_method_with_target에는 다음 구문의 표현식을 사용하세요.

( [, ...])

여기서:

search_method는 특정 유형의 조건자에 대한 쿼리를 최적화하는 다음 방법 중 하나를 지정합니다:
- GEO: GEOGRAPHY 유형을 사용하는 조건자입니다.
- SUBSTRING: 부분 문자열 및 정규 표현식과 일치하는 조건자입니다(예: [ NOT ] LIKE, [ NOT ] ILIKE, [ NOT ] RLIKE, REGEXP_LIKE 등).
- EQUALITY: 동등 및 IN 조건자입니다.
target은 열, VARIANT 필드 또는 별표(*)를 지정합니다.

search_method의 값에 따라 다음 유형 중 하나의 열 또는 VARIANT 필드를 지정할 수 있습니다:
- GEO: GEOGRAPHY 데이터 타입의 열.
- SUBSTRING: 문자열 또는 VARIANT 데이터 타입의 열. VARIANT 내 필드 경로를 포함합니다. 필드 경로는 EQUALITY에서 설명한 대로 지정합니다. 중첩 필드에 대한 검색도 동일한 방식으로 개선됩니다.
- EQUALITY: 숫자, 문자열, 이진 및 VARIANT 데이터 타입의 열. VARIANT 열의 필드 경로를 포함합니다.
  
  VARIANT 필드를 지정하려면 dot or bracket notation을(를) 사용하세요. 예:
  - my_column:my_field_name.my_nested_field_name
  - my_column['my_field_name']['my_nested_field_name']
  콜론으로 구분된 필드 경로를 사용할 수도 있습니다. 예:
  - my_column:my_field_name:my_nested_field_name
  VARIANT 필드를 지정하면 해당 필드 아래의 모든 중첩 필드에 구성이 적용됩니다.
  
  예를 들어 ON EQUALITY(src:a.b)를 지정하면:
  - 이 구성은 on src:a.b 및 모든 중첩 필드(예: src:a.b.c, src:a.b.c.d 등)에 대한 쿼리를 개선할 수 있습니다.
  - 이 구성은 src:a.b 접두사를 사용하는 쿼리(예: src:a, src:z 등)에만 영향을 미칩니다.

테이블의 모든 적용 가능한 열을 대상으로 지정하려면 별표(*)를 사용하세요.

특정 검색 방법에 대해 별표와 특정 열 이름을 함께 지정할 수 없습니다. 그러나 서로 다른 검색 방법에서는 별표를 지정할 수 있습니다.

예를 들어 다음 표현식을 지정할 수 있습니다:

ON SUBSTRING(*)
ON EQUALITY(*), SUBSTRING(*), GEO(*)

다음 표현식은 지정할 수 없습니다:

ON EQUALITY(*, c1)
ON EQUALITY(c1, *)
ON EQUALITY(v1:path, *)
ON EQUALITY(c1), EQUALITY(*)

대상에 여러 검색 방법을 지정하려면 쉼표를 사용하여 각 후속 방법과 대상을 구분하세요:

ALTER DYNAMIC TABLE my_dynamic_table ADD SEARCH OPTIMIZATION ON EQUALITY(c1), EQUALITY(c2, c3);

같은 테이블에서 ALTER DYNAMIC TABLE ... ADD SEARCH OPTIMIZATION ON ... 명령을 여러 번 실행하면 각 후속 명령이 테이블의 기존 구성에 추가됩니다. 예를 들어 다음 명령을 실행한다고 가정합니다:

ALTER DYNAMIC TABLE my_dynamic_table ADD SEARCH OPTIMIZATION ON EQUALITY(c1, c2);
ALTER DYNAMIC TABLE my_dynamic_table ADD SEARCH OPTIMIZATION ON EQUALITY(c3, c4);

그러면 테이블 구성에 c1, c2, c3, c4 열에 대한 동등 조건자가 추가됩니다. 이는 다음 명령을 실행하는 것과 동일합니다:

ALTER DYNAMIC TABLE my_dynamic_table ADD SEARCH OPTIMIZATION ON EQUALITY(c1, c2, c3, c4);

예제는 을(를) 참조하세요.

DROP SEARCH OPTIMIZATION

전체 동적 테이블에 대해 search optimization을(를) 제거하거나, 선택적 ON 절을 지정하면 특정 열에서 제거합니다.

다음 제한 사항이 적용됩니다:

동적 테이블에 검색 최적화 속성이 있으면 동적 테이블을 삭제했다가 다시 복원해도 검색 최적화 속성이 유지됩니다.
동적 테이블에서 검색 최적화 속성을 제거한 후 다시 추가하면 처음 추가할 때와 동일한 비용이 발생합니다.

ON search_method_with_target | column_name | expression_id [, ... ]

특정 열 또는 VARIANT 필드에 대한 검색 최적화 구성을 제거하려는 경우 지정합니다(전체 동적 테이블에 대한 검색 최적화를 제거하는 대신).

제거할 열 구성을 식별하려면 다음 중 하나를 지정하세요:

search_method_with_target의 경우 하나 이상의 특정 대상(열 또는 VARIANT 필드)에 대한 쿼리를 최적화하는 방법을 지정합니다. 앞에서 설명한 구문을 사용합니다.
column_name의 경우 검색 최적화를 위해 구성된 열의 이름을 지정합니다. 열 이름을 지정하면 해당 열의 모든 표현식(열의 VARIANT 필드를 사용하는 표현식 포함)이 제거됩니다.
expression_id의 경우 DESCRIBE SEARCH OPTIMIZATION 명령의 출력에 나열된 표현식의 ID를 지정합니다.

항목 사이에 쉼표를 사용하여 대상이 있는 검색 방법, 열 이름, 표현식 ID의 조합을 지정할 수 있습니다.

예제는 을(를) 참조하세요.

스토리지 수명 주기 정책 작업 (`storageLifecyclePolicyAction`)

ADD STORAGE LIFECYCLE POLICY policy_name ON ( col_name [ , col_name ... ] )

동적 테이블에 storage lifecycle policy을(를) 연결합니다.

ON 절에 지정된 열은 정책 함수 시그니처에 정의된 인수 개수 및 데이터 타입과 일치해야 합니다. Snowflake는 이러한 열을 사용하여 정책 표현식을 평가하고 삭제하거나 보관할 행을 결정합니다.

동적 테이블에서 스토리지 수명 주기 정책을 사용하는 방법에 대한 자세한 내용은 Use storage lifecycle policies with dynamic tables을(를) 참조하세요.

DROP STORAGE LIFECYCLE POLICY

동적 테이블에서 스토리지 수명 주기 정책을 제거해요.

스토리지 수명 주기 정책을 삭제하면 다음 새로 고침 때 전체 재초기화가 발생해요. Snowflake는 이전에 만료 영역에 있던 행을 포함한 모든 행을 새로 고쳐요. 재초기화를 유발하는 전체 변경 사항 목록은 를 참조하세요.

액세스 제어 요구 사항

이 작업을 실행하는 데 사용되는 역할은 최소한 다음 권한을 보유해야 해요.

권한	개체	참고
OWNERSHIP or OPERATE	변경하려는 동적 테이블.	일부 작업은 OWNERSHIP 권한으로만 지원돼요. 자세한 내용은 를 참조하세요.

스키마의 개체를 운영하려면 상위 데이터베이스에 대한 권한이 하나 이상, 상위 스키마에 대한 권한이 하나 이상 필요해요.

지정된 권한 집합으로 사용자 지정 역할을 만드는 방법은 를 참조하세요.

보안 개체에 대해 SQL 작업을 수행하기 위한 역할 및 권한 부여에 대한 일반적인 내용은 Overview of Access Control를 참조하세요.

사용 참고 사항

동적 테이블을 변경하려면 해당 동적 테이블에 대한 OPERATE 권한이 있는 역할을 사용해야 해요. 일반적인 내용은 를 참조하세요.
기본 테이블의 마스킹 정책을 변경하면 재초기화가 발생해요.
기존 동적 테이블을 업데이트하려고 하고 현재 정의를 확인해야 한다면 GET_DDL 함수를 호출하세요.
ALTER TABLE 명령을 실행하여 동적 테이블에서 데이터 메트릭 함수를 사용할 수 있어요. 자세한 내용은 Use SQL to set up data metric functions를 참조하세요.
IDENTIFIER()를 사용하여 변경할 동적 테이블의 이름을 지정할 수 없어요. 예를 들어 다음 문은 지원되지 않아요: ```sql ALTER DYNAMIC TABLE IDENTIFIER(my_dynamic_table) SUSPEND;
재초기화 또는 전체 새로 고침 후에는 동적 테이블의 검색 인덱스가 다시 빌드돼요. 이 과정은 기존 인덱스를 삭제하고 처음부터 다시 빌드하는 작업을 포함하므로 비용이 더 높을 수 있어요. 자세한 내용은 Search optimization cost estimation and management를 참조하세요.
메타데이터 관련:

고객은 Snowflake 서비스를 사용할 때 메타데이터로 개인 데이터(User 개체의 경우 제외), 민감한 데이터, 수출 통제 데이터 또는 기타 규제 대상 데이터가 입력되지 않도록 해야 해요. 자세한 내용은 Metadata fields in Snowflake를 참조하세요.

예제

my_dynamic_table이라는 동적 테이블의 대상 지연 시간을 1시간으로 변경:

ALTER DYNAMIC TABLE my_dynamic_table SET
  TARGET_LAG = '1 hour';

my_dynamic_table의 다운스트림 대상 지연 시간 지정:

ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = DOWNSTREAM;

동적 테이블 일시 중단:

ALTER DYNAMIC TABLE my_dynamic_table SUSPEND;

동적 테이블 재개:

ALTER DYNAMIC TABLE my_dynamic_table RESUME;

my_dynamic_table 이름 변경:

ALTER DYNAMIC TABLE my_dynamic_table RENAME TO my_updated_dynamic_table;

my_dynamic_table을 my_new_dynamic_table과 교체:

ALTER DYNAMIC TABLE my_dynamic_table SWAP WITH my_new_dynamic_table;

동적 테이블의 클러스터링 키 변경:

ALTER DYNAMIC TABLE my_dynamic_table CLUSTER BY (date);

동적 테이블에서 클러스터링 제거:

ALTER DYNAMIC TABLE my_dynamic_table DROP CLUSTERING KEY;

현재 세션의 사용자, 보조 역할, 웨어하우스 설정을 사용하여 my_dynamic_table의 수동 새로 고침을 수행: 이렇게 하면 새로 고침 작업이 사용자 세션의 정확한 컨텍스트로 실행돼요.

ALTER DYNAMIC TABLE my_dynamic_table REFRESH COPY SESSION

기존 고정 영역(frozen region) 조건자를 수정하거나 제거하려면 교체할 수 있어요:

ALTER DYNAMIC TABLE my_dynamic_table SET FROZEN WHERE (  );

또는 고정 영역 조건자를 제거:

ALTER DYNAMIC TABLE my_dynamic_table UNSET FROZEN WHERE;

동적 테이블에 스토리지 수명 주기 정책 추가:

ALTER DYNAMIC TABLE dt_orders ADD STORAGE LIFECYCLE POLICY expire_after_1w ON (order_date);

동적 테이블에서 스토리지 수명 주기 정책 제거:

ALTER DYNAMIC TABLE dt_orders DROP STORAGE LIFECYCLE POLICY;

동적 테이블 수정하기