동적 테이블 관리
동적 테이블 관리
이 페이지는 생성 후 동적 테이블의 수명 주기 작업을 다뤄요: 일시 중단(suspend), 다시 시작(resume), 웨어하우스·target lag 변경, 삭제(drop) 또는 복원(undrop).
전체 구문 참조는 ALTER DYNAMIC TABLE 문서를 참조하세요.
- 일시 중단, 다시 시작, 변경(웨어하우스, target lag,
SCHEDULER)에는OWNERSHIP또는OPERATE권한이 필요해요. - 삭제와 복원에는
OWNERSHIP권한이 필요해요.
전체 권한 참조는 동적 테이블 접근 제어 문서를 참조하세요.
출처: Snowflake 문서
본문
동적 테이블 일시 중단
동적 테이블을 일시 중단하면 모든 예약 갱신이 중지돼요. 테이블 데이터는 그대로 유지되고 쿼리 가능하지만, 다시 시작할 때까지 새 예약 갱신이 실행되지 않아요. 일시 중단된 동적 테이블에서 ALTER DYNAMIC TABLE … REFRESH를 사용해 수동 갱신을 트리거할 수는 있어요.
동적 테이블을 기본 테이블의 DATA_RETENTION_TIME_IN_DAYS보다 오래 일시 중단하면 변경 추적 창이 만료되고 테이블이 정상적으로 다시 시작될 수 없어요. 아래의 장기 일시 중단 후 다시 시작을 참조하세요. 일시 중단된 동적 테이블은 갱신 컴퓨팅 비용이 아니라 스토리지 비용만 발생해요.
유지 관리 창 동안 컴퓨팅 지출을 줄이거나, 갱신 실패를 트러블슈팅하거나, 지금 필요 없는 파이프라인을 일시 중단하기 위해 동적 테이블을 일시 중단할 수 있어요.
동적 테이블을 일시 중단하려면 OWNERSHIP 또는 OPERATE 권한이 필요해요.
⚠️ 동적 테이블을 일시 중단하면 그에 의존하는 모든 다운스트림 동적 테이블도 일시 중단돼요. 그 다운스트림 테이블은 업스트림 테이블이 먼저 다시 시작될 때까지 개별적으로 다시 시작할 수 없어요.
동적 테이블을 일시 중단하려면 ALTER DYNAMIC TABLE <name> SUSPEND를 실행하세요.
스케줄링 상태를 확인해요:
SELECT name,
scheduling_state:state::STRING AS state,
scheduling_state:reason_code::STRING AS reason_code
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_GRAPH_HISTORY())
WHERE name = 'DT_ORDERS'
ORDER BY valid_from DESC
LIMIT 1;
+------------+-----------+----------------+
| NAME | STATE | REASON_CODE |
|------------+-----------+----------------|
| DT_ORDERS | SUSPENDED | USER_SUSPENDED |
+------------+-----------+----------------+
- Snowsight에 로그인해요.
- 탐색 메뉴에서 Transformation » Dynamic tables를 선택해요.
- 목록에서 동적 테이블을 찾아
» Suspend를 선택해요. - 팝업에서 동적 테이블을 일시 중단할지 확인해요.
5회 연속 오류 후 자동 일시 중단
Snowflake는 예약 갱신이 5회 연속 실패한 후 동적 테이블을 자동으로 일시 중단해요. 이는 실패하는 테이블이 무기한 웨어하우스 리소스를 소비하는 것을 방지해요.
오류 카운터의 핵심 규칙:
- 예약 갱신 실패만 집계돼요. 수동 트리거 갱신(
ALTER DYNAMIC TABLE … REFRESH)의 오류는 카운터를 증가시키지 않아요. - 성공적인 갱신(예약 또는 수동)은 카운터를 0으로 재설정해요.
- 자동 일시 중단 후 다운스트림 동적 테이블도
UPSTREAM_SUSPENDED_DUE_TO_ERRORS사유로 일시 중단돼요. - 동적 테이블은 근본 오류가 고쳐져도 자동으로 다시 시작되지 않아요. 명시적으로
ALTER DYNAMIC TABLE … RESUME을 실행해야 해요.
동적 테이블이 자동으로 일시 중단됐는지 확인하려면 스케줄링 상태를 쿼리해요:
SELECT name,
scheduling_state:state::STRING AS state,
scheduling_state:reason_code::STRING AS reason_code,
scheduling_state:reason_message::STRING AS reason_message,
scheduling_state:suspended_on::TIMESTAMP AS suspended_on
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_GRAPH_HISTORY())
WHERE name = 'DT_ORDERS'
ORDER BY valid_from DESC
LIMIT 1;
+------------+-----------+---------------------------+---------------------------------------------------+----------------------------------+
| NAME | STATE | REASON_CODE | REASON_MESSAGE | SUSPENDED_ON |
|------------+-----------+---------------------------+---------------------------------------------------+----------------------------------|
| DT_ORDERS | SUSPENDED | SUSPENDED_DUE_TO_ERRORS | The dynamic table was suspended due to 5 consecutive refresh | 2025-01-16 08:27:29.142 -0700 |
| | | | errors. | |
+------------+-----------+---------------------------+---------------------------------------------------+----------------------------------+
📌
SHOW DYNAMIC TABLES는 활성 스케줄링 상태를RUNNING으로 보고하는데, 이는DYNAMIC_TABLE_GRAPH_HISTORY의ACTIVE에 해당해요. 둘 다 동일한 운영 상태를 나타낸다.
일시 중단 사유 코드
SCHEDULING_STATE 컬럼의 reason_code 필드는 동적 테이블이 일시 중단된 이유를 나타내요:
| 사유 코드 | 설명 |
|---|---|
USER_SUSPENDED |
사용자가 ALTER DYNAMIC TABLE … SUSPEND를 실행. |
UPSTREAM_USER_SUSPENDED |
업스트림 동적 테이블이 사용자에 의해 일시 중단됐고, 그것이 캐스케이드됨. |
SUSPENDED_DUE_TO_ERRORS |
5회 연속 예약 갱신 오류가 자동 일시 중단을 트리거. |
UPSTREAM_SUSPENDED_DUE_TO_ERRORS |
업스트림 동적 테이블이 자동 일시 중단됐고, 그것이 캐스케이드됨. |
동적 테이블 다시 시작
동적 테이블을 다시 시작하면 갱신 스케줄이 재개돼요. Snowflake는 중단된 지점부터 이어서, 일시 중단 동안 누적된 데이터 변경을 처리해요.
다시 시작에는 OWNERSHIP 또는 OPERATE 권한이 필요해요.
동적 테이블을 다시 시작하려면 ALTER DYNAMIC TABLE <name> RESUME을 실행하세요.
- Snowsight에 로그인해요.
- 탐색 메뉴에서 Transformation » Dynamic tables를 선택해요.
- 목록에서 동적 테이블을 찾아
» Resume을 선택해요. - 팝업에서 동적 테이블을 다시 시작할지 확인해요.
다시 시작 캐스케이드 동작
동적 테이블을 다시 시작하면 캐스케이드 효과로 일시 중단된 다운스트림 테이블(사유 코드 UPSTREAM_USER_SUSPENDED 또는 UPSTREAM_SUSPENDED_DUE_TO_ERRORS)도 자동으로 다시 시작돼요. 사용자가 직접 일시 중단한 다운스트림 테이블(사유 코드 USER_SUSPENDED)은 자동으로 다시 시작되지 않아요. 개별적으로 다시 시작해야 해요.
장기 일시 중단 후 다시 시작
증분 갱신이 있는 동적 테이블이 기본 테이블의 Time Travel 보존 기간보다 오래 일시 중단되면, 필요로 하는 변경 추적 데이터가 더 이상 없어요. 다시 시작하면 증분 갱신이 그 데이터 없이는 수행될 수 없으므로 다음 갱신이 실패해요.
위험을 확인하려면 테이블이 일시 중단된 기간을 기본 테이블의 DATA_RETENTION_TIME_IN_DAYS 설정(기본: 1일)과 비교하세요.
⚠️ 변경 추적 데이터가 만료됐다면 유일한 복구 방법은 동적 테이블을 삭제하고 다시 만드는 것이에요. 동적 테이블을 오래 일시 중단 상태로 두기 전에 기본 테이블의
DATA_RETENTION_TIME_IN_DAYS설정을 확인하세요.
SCHEDULER = DISABLE vs SUSPEND
SUSPEND와 SCHEDULER = DISABLE은 모두 갱신을 중지하지만 용도가 달라요. 둘 다 OWNERSHIP 또는 OPERATE 권한이 필요해요.
| 작업 | 동작 | 사용 시기 |
|---|---|---|
ALTER DYNAMIC TABLE ... SUSPEND |
스케줄링을 일시 중단. 모든 구성(target lag, 웨어하우스)을 보존. 다시 시작하면 갱신 재개. 수동 갱신은 여전히 업스트림·다운스트림 테이블로 정상적으로 캐스케이드. | 유지 관리나 트러블슈팅 중 같은 임시 정지가 필요할 때. |
ALTER DYNAMIC TABLE ... SET SCHEDULER = DISABLE |
테이블을 스케줄링에서 완전히 제거. TARGET_LAG가 NULL로 보고됨. 스케줄링을 다시 활성화하려면 새 TARGET_LAG 값을 설정해야 함. 수동 갱신이 업스트림·다운스트림 테이블로 캐스케이드되지 않아 dbt 같은 외부 오케스트레이터를 위한 격리 경계를 만듦. |
스케줄링에서 영구적으로 분리하고 싶을 때(정적 스냅샷 또는 외부 오케스트레이터). |
SCHEDULER = DISABLE 후 스케줄링을 다시 활성화하려면 새 TARGET_LAG를 설정하세요. 스케줄링을 완전히 비활성화하려면 ALTER DYNAMIC TABLE <name> SET SCHEDULER = DISABLE을 실행하세요. 다시 활성화하려면 ALTER DYNAMIC TABLE <name> SET TARGET_LAG = '<interval>'을 실행하세요.
한 문에서 여러 동적 테이블 갱신
한 시점에 여러 동적 테이블을 갱신하려면 ALTER DYNAMIC TABLE 뒤에 쉼표로 구분해 나열하세요:
ALTER DYNAMIC TABLE dt_orders, dt_orders_daily REFRESH;
Snowflake는 나열된 모든 동적 테이블의 업스트림 의존성을 하나의 파이프라인으로 병합하고 모두 같은 데이터 타임스탬프로 갱신해요. 나열된 두 동적 테이블이 업스트림을 공유하면 그 업스트림은 정확히 한 번 갱신돼요. 각 동적 테이블은 자신의 구성된 웨어하우스에서 갱신해요.
나열된 모든 동적 테이블과 갱신될 업스트림 동적 테이블에 OPERATE 권한이 필요해요. 전체 규칙은 REFRESH [COPY SESSION] 문서를 참조하세요.
캐스케이드된 업스트림을 포함해 문의 일부로 갱신된 전체 동적 테이블 집합을 보려면 refresh_trigger='MANUAL'과 일치하는 data_timestamp로 필터링한 갱신 기록을 쿼리하세요. 갱신별 기록 보기 문서를 참조하세요.
IF EXISTS를 사용하면 Snowflake는 목록에서 기존 동적 테이블로 해결되지 않는 이름을 조용히 건너뛰고, 문은 나머지 동적 테이블에 대해 성공해요.
📌 여러 동적 테이블을 나열하면 각 동적 테이블이
SCHEDULER설정과 관계없이 갱신되므로SCHEDULER=DISABLE은 나열된 동적 테이블을 갱신 집합에서 제거하지 않아요.
부분 실패
다중 테이블 수동 갱신은 원자적(atomic)이지 않아요. 나열된 동적 테이블 중 하나라도 FAILED, UPSTREAM_FAILED, 또는 CANCELLED 갱신 상태로 끝나면 문은 오류를 반환하지만, 이미 성공적으로 갱신된 동적 테이블은 갱신된 상태로 유지돼요.
📌 Snowflake는 성공한 동적 테이블과 실패한 동적 테이블 모두에 대해 갱신 기록 행을 기록해요. 롤백되는 것은 없어요.
특정 다중 테이블 갱신에서 어떤 동적 테이블이 성공했는지 실패했는지 확인하려면 같은 data_timestamp를 공유하는 행을 갱신 기록에서 쿼리하세요:
-- 실패한 ALTER DYNAMIC TABLE ... REFRESH 문이 출력한 data_timestamp로 바꾸세요.
SET failed_ts = '2026-07-22 10:15:00.000';
SELECT name, state, state_message
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY())
WHERE refresh_trigger = 'MANUAL'
AND data_timestamp = $failed_ts
ORDER BY name;
다시 시도하려면 문을 다시 실행하고 다시 갱신할 동적 테이블만 나열하세요. 갱신을 원자적으로 만들기 위해 문을 명시적 트랜잭션(BEGIN … COMMIT 사용)으로 감쌀 수 없어요. 수동 갱신은 다중 문 트랜잭션 내에서 지원되지 않아요.
전체 제한 사항 목록은 제한 사항 문서를 참조하세요.
원인과 해결 방법이 있는 오류 코드는 동적 테이블 오류 코드 참조 문서를 참조하세요.
웨어하우스 또는 target lag 변경
ALTER DYNAMIC TABLE을 사용해 테이블을 다시 만들지 않고 웨어하우스나 target lag를 변경해요. 이 속성 변경은 재초기화를 트리거하지 않아요.
웨어하우스 변경
비용 효율성이나 더 무거운 워크로드를 처리하기 위해 다른 웨어하우스로 전환하려면 ALTER DYNAMIC TABLE <name> SET WAREHOUSE = <warehouse_name>을 실행하세요.
target lag 변경
데이터 신선도와 컴퓨팅 비용의 균형을 맞추기 위해 target lag를 조정해요. ALTER DYNAMIC TABLE <name> SET TARGET_LAG = '<interval>'을 실행해 특정 간격을 설정하세요.
다운스트림 테이블이 필요로 할 때만 갱신해야 하는 중간 파이프라인 테이블에는 ALTER DYNAMIC TABLE <name> SET TARGET_LAG = DOWNSTREAM을 사용하세요.
올바른 target lag를 선택하는 지침은 동적 테이블의 target lag 설정 문서를 참조하세요.
동적 테이블 삭제
동적 테이블을 삭제하면 환경에서 제거되고 관련된 모든 갱신이 중지돼요. 스토리지 비용을 줄이고 파이프라인을 정리하려면 사용하지 않는 동적 테이블을 삭제하세요.
동적 테이블 삭제에는 OWNERSHIP 권한이 필요해요.
⚠️ 삭제된 테이블을 참조하는 다운스트림 동적 테이블은 다음 갱신에서 실패해요. 삭제하기 전에
DYNAMIC_TABLE_GRAPH_HISTORY로 다운스트림 의존성을 확인하세요.
동적 테이블을 삭제하려면 DROP DYNAMIC TABLE <name>을 실행하세요. 테이블이 존재하지 않을 수 있을 때 오류를 피하려면 DROP DYNAMIC TABLE IF EXISTS <name>을 사용하세요.
- Snowsight에 로그인해요.
- 탐색 메뉴에서 Transformation » Dynamic tables를 선택해요.
- 목록에서 동적 테이블을 찾아
» Drop을 선택해요. - 팝업에서 동적 테이블을 삭제할지 확인해요.
삭제된 동적 테이블 복원
UNDROP DYNAMIC TABLE을 사용해 삭제된 동적 테이블과 그 데이터를 복원해요. Undrop은 기본적으로 24시간인 Time Travel 보존 기간 내에서만 사용할 수 있어요. 보존 기간을 변경하려면 삭제하기 전에 테이블에 DATA_RETENTION_TIME_IN_DAYS를 설정하세요.
동적 테이블 복원에는 OWNERSHIP 권한이 필요해요. 복원하려면 UNDROP DYNAMIC TABLE <name>을 실행하세요.
원본이 삭제된 후 같은 이름의 새 동적 테이블이 생성됐거나, 테이블이 이미 복원됐다면 UNDROP이 실패해요:
UNDROP DYNAMIC TABLE dt_orders;
Dynamic table 'DT_ORDERS' already exists.
복원 후 SHOW DYNAMIC TABLES LIKE '<name>'로 스케줄링 상태를 확인하고, 필요하면 ALTER DYNAMIC TABLE <name> RESUME으로 다시 시작하세요.
다음 단계
- 갱신 기록과 스케줄링 상태를 모니터링하려면, 동적 테이블 모니터링 문서를 참조하세요.
- 갱신 실패 또는 일시 중단 문제를 트러블슈팅하려면, 동적 테이블 갱신 문제 트러블슈팅 문서를 참조하세요.
- 갱신 모드나 정의 쿼리를 변경하려면, 동적 테이블 수정 문서를 참조하세요.
- 갱신 작업의 비용 영향을 이해하려면, 동적 테이블 비용 이해 문서를 참조하세요.