데이터베이스 복제 고려 사항

이 항목에서는 보조 데이터베이스의 특정 Snowflake 기능의 동작을 설명하고 복제된 오브젝트 및 데이터 작업에 대한 일반적인 지침을 제공합니다.

이 항목의 내용:

복제 및 자동 클러스터링

기본 데이터베이스에서 Snowflake는 자동 클러스터링 를 사용하여 클러스터링된 테이블을 모니터링하고 필요에 따라 다시 클러스터링합니다. 새로 고침 작업의 일부로 클러스터된 테이블은 테이블 마이크로 파티션의 현재 정렬을 사용하여 보조 데이터베이스에 복제됩니다. 따라서 보조 데이터베이스의 클러스터링된 테이블에 대해 재클러스터링이 다시 수행되지 않으며 중복됩니다.

보조 데이터베이스에 클러스터된 테이블이 포함되어 있고 데이터베이스가 기본 데이터베이스가 되도록 승격되면 Snowflake는 이 데이터베이스의 테이블에 대한 자동 클러스터링을 시작하는 동시에 이전 기본 데이터베이스의 클러스터된 테이블 모니터링을 일시 중단합니다.

구체화된 뷰의 자동 클러스터링에 대한 자세한 내용은 이 항목의 복제 및 구체화된 뷰 섹션을 참조하십시오.

복제 및 구체화된 뷰

기본 데이터베이스에서 Snowflake는 구체화된 뷰의 자동 백그라운드 유지 관리를 수행합니다. 기본 테이블이 변경되면 테이블에 정의된 모든 구체화된 뷰가 Snowflake에서 제공하는 컴퓨팅 리소스를 사용하는 백그라운드 서비스에 의해 업데이트됩니다. 또한, 구체화된 뷰에 대해 자동 클러스터링이 활성화된 경우 기본 데이터베이스에서 필요에 따라 뷰가 모니터링되고 다시 클러스터링됩니다.

새로 고침 작업은 구체화된 뷰 정의 를 보조 데이터베이스에 복제하며, 구체화된 뷰 데이터 는 복제되지 않습니다. 보조 데이터베이스에서 구체화된 뷰의 자동 백그라운드 유지 관리는 기본적으로 활성화되어 있습니다. 기본 데이터베이스의 구체화된 뷰에 대해 자동 클러스터링이 활성화된 경우 보조 데이터베이스의 구체화된 뷰에 대한 자동 모니터링 및 재클러스터링도 활성화됩니다.

이 항목의 현수 참조 를 참조하십시오.

참고

  • 구체화된 뷰의 자동화된 백그라운드 동기화에 대한 요금은 보조 데이터베이스가 포함된 각 계정에 부과됩니다.

복제 및 외부 테이블

기본 데이터베이스의 외부 테이블

기본 데이터베이스의 외부 테이블로 인해 현재 다음 오류 메시지와 함께 복제 또는 새로 고침 작업이 실패합니다.

003906 (55000): SQL execution error:
Primary database contains an external table '<database_name>'.Replication of a database with external table is not supported

이 제한을 해결하려면 외부 테이블을 복제되지 않는 별도의 데이터베이스로 이동하는 것이 좋습니다. 또는 데이터베이스를 다른 계정으로 마이그레이션하는 경우 기본 데이터베이스를 복제하고 복제에서 외부 테이블을 삭제한 다음 복제된 데이터베이스를 복제할 수 있습니다. 대상 계정에서 보조 데이터베이스를 승격한 후에는 데이터베이스에서 외부 테이블을 다시 생성해야 합니다.

보조 데이터베이스의 외부 테이블

외부 테이블은 이전에 기본 데이터베이스였고 외부 테이블이 그 시간 중에 생성된 경우 보조 데이터베이스에 존재할 수 있습니다. 다른 데이터베이스가 지정된 기본 데이터베이스로 승격되면 그 데이터베이스가 보조 데이터베이스가 됩니다. 보조 데이터베이스의 외부 테이블로 인해 현재 다음 오류와 함께 새로 고침 작업이 실패합니다.

003958 (55000): SQL execution error:
Secondary database contains an external table '<table_name>'. Replication of a database with external table is not supported.

이 제한을 해결하려면 외부 테이블을 복제된 보조 데이터베이스가 아닌 별도의 데이터베이스로 이동하는 것이 좋습니다.

복제 및 보안 정책

정책

마스킹 정책과 행 액세스 정책 오브젝트 및 그 할당은 데이터베이스 복제와 복제 그룹을 사용하여 복제할 수 있습니다.

데이터베이스 복제 의 경우, 다음 조건 중 하나가 참이면 복제 작업이 실패합니다.

  • 기본 데이터베이스가 Enterprise 이상 계정에 있고 정책/태그가 포함되어 있지만, 복제가 승인된 1개 이상의 계정이 하위 에디션에 있습니다.

  • 기본 데이터베이스에 포함된 오브젝트에 다른 데이터베이스의 태그에 대한 현수 참조 가 있습니다.

복제 그룹 에서 여러 데이터베이스를 복제할 때 데이터베이스 복제에 대한 현수 참조 동작을 피할 수 있습니다.

참고

장애 조치 또는 장애 복구 작업을 사용하는 경우 Snowflake 계정은 Business Critical Edition 이상이어야 합니다.

자세한 내용은 데이터베이스 복제 및 장애 조치/장애 복구 섹션을 참조하십시오.

태그 기반 마스킹 정책

태그가 이전에 기본 데이터베이스에서 보조 데이터베이스로 데이터베이스 복제를 사용하여 복제되었고 기본 데이터베이스 내의 스키마에 저장된 태그에 마스킹 정책이 할당된 경우, 보조 데이터베이스에서의 새로 고침 작업과 관련하여 다음 사항에 유의하십시오.

  • 태그 기반 마스킹 정책이 보조 계정의 테이블, 뷰 또는 열에 할당된 경우 새로 고침 작업이 작동합니다.

  • 복제된 태그가 보조 계정의 스키마 또는 데이터베이스에 할당되거나 보조 계정 자체에 할당된 경우, 이러한 오브젝트에 대한 새로 고침 작업이 실패합니다.

이 정책에 대한 자세한 내용은 태그 기반 마스킹 정책 섹션을 참조하십시오.

네트워크 정책

자세한 내용은 네트워크 정책 복제 를 참조하십시오.

비밀번호 및 세션 정책

이러한 오브젝트는 데이터베이스 복제 및 복제 그룹을 사용하여 복제할 수 있습니다.

데이터베이스 복제의 경우, 다음 조건 중 하나가 참이면 복제 작업이 실패합니다.

  • 기본 데이터베이스가 Enterprise 이상 계정에 있고 정책이 포함되어 있지만, 복제가 승인된 1개 이상의 계정이 하위 에디션에 있습니다.

  • 기본 데이터베이스에 포함된 이러한 오브젝트 중 하나가 같은 계정의 사용자에게 연결됩니다. 이 경우 Snowflake는 복제 작업에 실패합니다.

사용자 참조로 인한 데이터베이스 복제 작업이 실패하지 않도록 하려면 복제 그룹 을 대신 사용하십시오.

자세한 내용은 계정 복제 항목의 복제 및 보안 정책 섹션을 참조하십시오.

복제 및 스트림

이 섹션에서는 데이터베이스 복제 및 장애 조치/장애 복구 또는 계정 복제 및 장애 조치/장애 복구 에서 스트림을 복제할 때 권장되는 방법과 잠재적인 관심 영역에 대해 설명합니다.

스트림에 대해 지원되는 원본 오브젝트

복제된 스트림은 같은 데이터베이스의 테이블과 뷰에 대한 변경 데이터를 성공적으로 추적할 수 있습니다.

현재, 다음 원본 오브젝트 유형은 지원되지 않습니다.

  • 디렉터리 테이블

  • 외부 테이블

  • 스트림 데이터베이스와 분리된 데이터베이스의 테이블 또는 뷰.

    이 디자인은 스트림 데이터베이스와 원본 오브젝트를 저장하는 데이터베이스가 모두 같은 복제 또는 장애 조치 그룹 에 포함된 경우 에 작동합니다.

  • 공유 데이터베이스(즉, 공급자 계정에서 자신의 계정으로 공유되는 데이터베이스)의 테이블 또는 뷰

기본 데이터베이스에 지원되지 않는 원본 오브젝트가 있는 스트림이 포함되는 경우 데이터베이스 복제 또는 새로 고침 작업이 실패합니다. 스트림에 대한 원본 오브젝트가 삭제된 경우에도 작업이 실패합니다.

데이터 중복 방지하기

참고

이 섹션에 설명된 시나리오 외에도, 보조 데이터베이스의 스트림은 새로 고침 작업에 처음 포함될 때 중복 행을 반환할 수 있습니다. 이 경우 중복 행 은 여러 METADATA$ACTION 열 값이 있는 단일 행을 나타냅니다.

최초 새로 고침 작업 후에는 보조 데이터베이스에서 이 특정 문제가 발생하지 않아야 합니다.

데이터 중복은 DML 작업이 고유성 검사 없이 스트림에서 같은 변경 데이터를 여러 번 쓸 때 발생합니다. 스트림 변경 데이터의 대상 테이블과 스트림이 별개의 데이터베이스에 저장되고 이러한 데이터베이스가 같은 그룹에서 복제되고 장애 조치되지 않는 경우에 데이터 중복이 발생할 수 있습니다.

예를 들어 스트림 s 에서 테이블 dt 로 변경 데이터를 정기적으로 삽입한다고 가정합니다. (이 예에서는 스트림의 원본 오브젝트가 중요하지 않습니다.) 별개의 데이터베이스가 스트림 및 대상 테이블을 저장합니다.

  1. 타임스탬프 t1 에서 스트림 s 에 대한 원본 테이블에 행이 삽입되어 새 테이블 버전을 생성합니다. 스트림은 이 테이블 버전의 오프셋을 저장합니다.

  2. 타임스탬프 t2 에서 스트림을 저장하는 보조 데이터베이스가 새로 고쳐집니다. 복제된 스트림 s 는 이제 오프셋을 저장합니다.

  3. 타임스탬프 t3 에서 스트림 s 의 변경 데이터가 테이블 dt 에 삽입됩니다.

  4. 타임스탬프 t4 에서 스트림 s 를 저장하는 보조 데이터베이스가 장애 조치됩니다.

  5. 타임스탬프 t5 에서 스트림 s 의 변경 데이터가 테이블 dt 에 다시 삽입됩니다.

이 상황을 방지하려면 스트림과 대상 테이블을 저장하는 데이터베이스를 함께 복제하고 장애 조치하십시오.

작업 WHEN 절의 스트림 참조

WHEN boolean_expr 절에서 스트림을 참조하는 복제된 작업을 실행할 때 예기치 않은 동작을 방지하려면 다음 중 하나를 수행하는 것이 좋습니다.

  • 같은 데이터베이스에 작업과 스트림 생성 또는

  • 스트림이 해당 스트림을 참조하는 작업과는 다른 데이터베이스에 저장되어 있는 경우 두 데이터베이스를 모두 같은 장애 조치 그룹 에 포함합니다.

작업이 별개의 데이터베이스에 있는 스트림을 참조하고 두 데이터베이스가 모두 같은 장애 조치 그룹에 포함되지 않을 경우에는 작업이 포함된 데이터베이스를 스트림이 포함된 데이터베이스 없이 장애 조치할 수 있습니다. 이 시나리오에서는 작업이 장애 조치된 데이터베이스에서 재개되는 경우 작업이 실행을 시도하고 참조된 스트림을 찾을 수 없을 때 오류를 기록합니다. 이 문제는 스트림이 포함된 데이터베이스를 장애 조치하거나 작업이 포함된 장애 조치된 데이터베이스와 동일한 계정에 데이터베이스와 스트림을 다시 생성함으로써 해결할 수 있습니다.

스트림 부실

기본 데이터베이스의 스트림이 부실 해진 경우 보조 데이터베이스에서 복제된 스트림도 부실해져 쿼리할 수 없거나 스트림의 변경 데이터를 사용할 수 없습니다. 이 문제를 해결하려면 기본 데이터베이스에서 스트림을 다시 만드십시오(CREATE OR REPLACE STREAM 사용). 보조 데이터베이스가 새로 고쳐지면 복제된 스트림을 다시 읽을 수 있습니다.

다시 생성된 스트림의 오프셋은 기본적으로 현재 테이블 버전입니다. Time Travel을 사용하여 이전 테이블 버전을 가리키는 스트림을 다시 만들 수 있지만, 복제된 스트림은 읽을 수 없는 상태로 남습니다. 자세한 내용은 이 항목의 스트림 복제 및 Time Travel 을 참조하십시오.

스트림 복제 및 Time Travel

기본 데이터베이스가 장애 조치된 후 데이터베이스의 스트림이 Time Travel 을 사용하여 마지막 새로 고침 타임스탬프 이전의 시점에서 원본 오브젝트의 테이블 버전 을 읽는 경우 복제된 스트림을 쿼리할 수 없거나 변경 데이터를 사용할 수 없습니다. 마찬가지로, SELECT 문의 CHANGES 절을 사용하여 마지막 새로 고침 타임스탬프 이전의 시점에서 원본 오브젝트의 변경 데이터를 쿼리하면 오류가 발생하며 실패합니다.

이는 새로 고침 작업으로 테이블 기록이 단일 테이블 버전으로 축소되기 때문입니다. 새로 고침 작업 타임스탬프 전에 생성된 반복 테이블 버전은 복제된 원본 오브젝트의 테이블 기록에 보존되지 않습니다.

다음 예를 살펴보겠습니다.

Stream replication and Time Travel
  1. 테이블 t1 이 변경 추적을 사용하는 기본 데이터베이스에 생성됩니다(테이블 버전 tv0). 이후의 DML 트랜잭션으로 테이블 버전 t1t2 가 생성됩니다.

  2. 테이블 t1 이 포함된 보조 데이터베이스가 새로 고쳐집니다. 이 복제된 테이블의 테이블 버전은 t2 이지만, 테이블 기록은 복제되지 않습니다.

  3. Time Travel을 사용하여 오프셋이 테이블 버전 tv1 로 설정된 기본 데이터베이스에 스트림이 생성됩니다.

  4. 보조 데이터베이스가 장애 조치되어 기본 데이터베이스가 됩니다.

  5. 테이블 버전 tv1 이 테이블 기록에 없으므로 스트림 s1 을 쿼리하면 오류가 반환됩니다.

테이블 t1 에 대한 후속 DML 트랜잭션에서 테이블 버전을 tv3 으로 반복할 때 스트림 s1 에 대한 오프셋이 진행됩니다. 스트림을 다시 읽을 수 있습니다.

데이터 손실 방지하기

장애 조치 작업 전에 보조 데이터베이스에 대한 가장 최근 새로 고침 작업이 완료될 때 데이터 손실이 발생할 수 있습니다. 위험을 최소화하려면 보조 데이터베이스를 자주 새로 고치는 것이 좋습니다.

스트림 복제 사용하기

스트림 복제 미리 보기를 사용하는 방법은 스트림 및 작업 복제 미리 보기 사용하기 — 선택 사항 섹션을 참조하십시오.

복제 및 태그

태그 및 해당 할당은 데이터베이스 복제 및 복제 그룹을 사용하여 복제할 수 있습니다.

원본 계정의 태그 할당은 대상 계정으로 이어집니다. 하지만 복제가 발생한 후에는 대상 계정에서 원본 계정의 태그 할당을 수정할 수 없습니다. 예를 들어, 복제된 데이터베이스에서의 태그 설정은 허용되지 않습니다. 복제 새로 고침 작업에서 Snowflake는 원본 계정의 태그 할당과 일치하도록 대상 계정의 태그 할당을 업데이트합니다.

데이터베이스 복제 의 경우, 다음 조건 중 하나가 참이면 복제 작업이 실패합니다.

  • 기본 데이터베이스가 Enterprise 이상 계정에 있고 태그가 포함되어 있지만 복제가 승인된 1개 이상의 계정이 하위 에디션에 있습니다.

  • 기본 데이터베이스에 포함된 오브젝트에 다른 데이터베이스의 태그에 대한 현수 참조 가 있습니다.

복제 그룹 을 사용하여 계정 수준 오브젝트에 대한 허상 참조와 함께 데이터베이스 복제로 허상 참조 동작을 방지할 수 있습니다. 복제 그룹이 다음을 지정하도록 하십시오.

  • ALLOWED_DATABASES 속성의 태그를 포함하는 데이터베이스.

  • OBJECT_TYPES 속성에 태그가 있는 기타 계정 수준 오브젝트(예: ROLES, WAREHOUSES).

    자세한 내용은 CREATE REPLICATION GROUPCREATE FAILOVER GROUP 섹션을 참조하십시오.

참고

데이터베이스 복제 또는 복제 그룹을 사용하는 경우:

복제 및 작업

이 섹션에서는 데이터베이스 복제 및 장애 조치/장애 복구 또는 계정 복제 및 장애 조치/장애 복구 에서의 작업 복제에 대해 설명합니다.

복제 시나리오

다음 표에는 다양한 작업 시나리오에 대한 설명이 나와 있고 작업의 복제 여부가 명시되어 있습니다. 명시된 경우를 제외하면 이들 시나리오는 독립 실행형 작업과 DAG 의 작업에 모두 적용됩니다.

시나리오

복제됨

참고

작업이 생성되어 (EXECUTE TASK 를 사용해) 수동으로 재개되거나 실행되었습니다. 작업을 재개하거나 실행하면 초기 작업 버전이 생성됩니다.

작업이 생성되었지만 재개되거나 실행되지 않았습니다.

(CREATE OR REPLACE TASK 를 사용해) 작업이 다시 생성되었지만 재개되거나 실행되지 않았습니다.

작업이 다시 생성되기 전의 최신 버전이 복제됩니다.

작업을 재개하거나 수동으로 실행하면 새 버전이 커밋됩니다. 데이터베이스가 다시 복제되면 새 버전이나 최신 버전이 보조 데이터베이스에 복제됩니다.

작업이 생성되고 재개 또는 실행된 이후에 수정되었지만(ALTER TASK 사용), 재개되거나 다시 실행되지 않았습니다.

작업을 재개하거나 수동으로 실행하면 작업 매개 변수에 대한 모든 변경 사항을 포함한 새 버전이 커밋됩니다. 새 변경 사항이 커밋되지 않았으므로 작업이 일시 중단되고 수정되기 전의 최신 버전이 복제됩니다.

수정된 작업이 보존 기간(현재 30일) 이내에 재개되지 않으면 작업의 최신 버전이 삭제됩니다. 이 기간 이후, 작업이 다시 재개되지 않으면 보조 데이터베이스에 복제되지 않습니다.

독립 실행형 작업이 생성되고 재개 또는 실행되었지만, 그 이후에 삭제되었습니다.

DAG의 루트 작업이 생성되고 재개 또는 실행되었지만, 그 이후에 일시 중단되고 삭제되었습니다.

전체 DAG가 보조 데이터베이스에 복제되지 않습니다.

DAG의 하위 작업이 생성되고 재개 또는 실행되지만, 그 이후에 일시 중단되고 삭제됩니다.

(작업이 일시 중단되고 삭제되기 전) 최신 버전의 DAG가 보조 데이터베이스에 복제됩니다.

복제된 작업의 재개 또는 일시 중단 상태

다음 조건이 모두 충족되면 작업이 재개된 상태의 보조 데이터베이스에 복제됩니다.

  • 작업이 완료될 때까지 복제 또는 새로 고침 작업이 시작될 때 독립 실행형 또는 루트 작업은 기본 데이터베이스에서 재개된 상태입니다. 작업이 이 기간의 일부 동안에만 재개된 상태인 경우에도 재개된 상태로 복제될 수 있습니다.

    하위 작업은 최신 버전의 작업에서 재개된 상태입니다.

  • 상위 데이터베이스가 같거나 다른 복제 또는 장애 조치 그룹 의 역할 오브젝트와 함께 대상 계정에 복제되었습니다.

    역할과 데이터베이스가 복제된 후 각각 ALTER REPLICATION GROUP … REFRESH 또는 ALTER FAILOVER GROUP … REFRESH 를 실행하여 대상 계정의 오브젝트를 새로 고쳐야 합니다. ALTER DATABASE … REFRESH 를 실행하여 데이터베이스를 새로 고치면 데이터베이스에서 작업의 상태가 일시 중단으로 변경됩니다.

    복제 또는 새로 고침 작업은 최신 테이블 버전이 커밋될 때 최신 상태였던 작업에 대한 권한 부여를 포함합니다. 자세한 내용은 이 항목의 복제 작업 및 권한 부여 를 참조하십시오.

이러한 조건이 충족되지 않으면 작업이 일시 중단된 상태에서 보조 데이터베이스에 복제됩니다.

복제 작업 및 권한 부여

상위 데이터베이스가 같거나 다른 복제 또는 장애 조치 그룹의 역할 오브젝트와 함께 대상 계정에 복제되면 데이터베이스의 작업에 부여된 권한도 복제됩니다.

다음 논리에 따라 복제 또는 새로 고침 작업에서 복제되는 작업 권한이 결정됩니다.

  • 현재 작업 소유자(즉, 작업에 대한 OWNERSHIP 권한이 있는 역할)가 작업이 마지막으로 재개되었을 때와 동일한 역할인 경우에는 작업에 대한 모든 현재 권한 부여가 보조 데이터베이스에 복제됩니다.

  • 현재 작업 소유자가 작업이 마지막으로 재개되었을 때와 동일한 역할이 아닌 경우에는 작업 버전에서 소유자 역할에 부여된 OWNERSHIP 권한만 보조 데이터베이스에 복제됩니다.

  • 현재 작업 소유자 역할을 사용할 수 없는 경우(예: 하위 작업이 삭제되지만 새 버전의 작업 DAG가 아직 커밋되지 않은 경우) 작업 버전에서 소유자 역할에 부여된 OWNERSHIP 권한만 보조 데이터베이스에 복제됩니다.

장애 조치 후 작업 실행

보조 장애 조치 그룹이 기본 그룹 역할을 하도록 승격된 후 장애 조치 그룹 내의 데이터베이스에서 재개된 모든 작업은 점진적으로 예약됩니다. 재개된 모든 독립 실행형 작업과 DAG의 정상적인 예약을 복원하는 데 필요한 시간은 데이터베이스에서 재개된 작업 수에 따라 다릅니다.

작업 복제 사용하기

작업 복제 미리 보기를 사용하는 방법은 스트림 및 작업 복제 미리 보기 사용하기 — 선택 사항 섹션을 참조하십시오.

복제 및 Time Travel

Time TravelFail-safe 데이터는 보조 데이터베이스용으로 독립적으로 유지 관리되며 기본 데이터베이스에서 복제되지 않습니다. Time Travel을 사용하여 보조 데이터베이스의 테이블 및 뷰를 쿼리하면 기본 데이터베이스에서 동일한 쿼리를 실행할 때와 다른 결과가 생성될 수 있습니다.

과거 데이터

Time Travel을 사용하여 기본 데이터베이스에서 쿼리할 수 있는 과거 데이터는 보조 데이터베이스에 복제되지 않습니다.

예를 들어, Snowpipe를 사용하여 10분마다 데이터가 테이블에 지속적으로 로드되고 보조 데이터베이스가 1시간마다 새로 고쳐진다고 가정해 보겠습니다. 새로 고침 작업은 최신 버전의 테이블만 복제합니다. 보존 윈도우 내 테이블의 모든 시간별 버전은 Time Travel을 사용하는 쿼리에 사용할 수 있지만 각 시간(개별 Snowpipe 로드) 내의 반복 버전은 사용할 수 없습니다.

데이터 보존 기간

보조 데이터베이스의 테이블에 대한 데이터 보존 기간은 기본 데이터베이스의 테이블에 기록된 DML 연상(즉, 데이터 변경 또는 삭제)으로 보조 데이터베이스를 새로 고칠 때 시작됩니다.

참고

데이터 보존 기간 매개 변수 DATA_RETENTION_TIME_IN_DAYS 는 데이터베이스 자체가 아니라 보조 데이터베이스의 데이터베이스 오브젝트에만 복제됩니다. 매개 변수 복제에 대한 자세한 내용은 매개 변수 를 참조하십시오.

복제 및 대규모의 변동이 많은 테이블

테이블의 하나 이상의 행이 업데이트되거나 삭제되면 이 데이터를 기본 데이터베이스에 저장하는 영향을 받는 모든 마이크로 파티션이 다시 생성되고 보조 데이터베이스와 동기화되어야 합니다. 대규모의 변동이 큰 차원 테이블의 경우 복제 비용이 많이 소요될 수 있습니다.

상당한 복제 비용이 발생하는 대규모의 변동이 큰 차원 테이블의 경우 다음과 같은 완화 조치를 사용할 수 있습니다.

  • 낮은 빈도로 이러한 테이블을 저장하는 모든 기본 데이터베이스를 복제합니다.

  • 데이터 모델을 변경하여 변동을 줄입니다.

자세한 내용은 변동이 많은 대규모 테이블 요금 관리하기 섹션을 참조하십시오.

복제 및 물리적 복제

복제된 오브젝트는 보조 데이터베이스에 논리적이 아닌 물리적으로 복제됩니다. 즉, 표준 데이터베이스에서 복제된 테이블은 복제본에서 DML 연산을 통해 기존 데이터를 추가하거나 수정할 때까지 또는 그러한 경우를 제외하고 전체 데이터 저장소에 영향을 주지 않습니다. 그러나 복제된 테이블이 보조 데이터베이스에 복제되면, 물리적 데이터도 복제되며 계정의 데이터 저장소 사용량이 증가하게 됩니다.

현수 참조

다른 데이터베이스 오브젝트에 대한 참조

기본 데이터베이스의 뷰 또는 테이블 제약 조건이 다른 데이터베이스의 오브젝트를 참조하는지 주의 깊게 분석하십시오.

  • 다른 데이터베이스의 오브젝트를 참조하는 구체화되지 않은 뷰(예: 테이블 열, 다른 뷰, UDFs 또는 스테이지)의 경우 이러한 타입의 참조는 이름을 기반으로 하므로 복제가 가능합니다. 이름 기반 참조이므로 복제가 실패하지 않지만, 다른 데이터베이스가 동일한 리전에서 복제되지 않으면 보조 데이터베이스의 뷰에 대한 쿼리가 실패합니다.

    예를 들어, d1 데이터베이스의 v1 뷰가 d1d2 데이터베이스의 t1t2 테이블을 각각 참조한다고 가정해 보겠습니다. d1 보조 데이터베이스에서 V1 뷰를 쿼리하려면 d2 보조 데이터베이스도 계정에 있어야 합니다(예: 다른 보조 데이터베이스). 또한, 기본 데이터베이스와의 일관된 쿼리 결과를 위해서는 보조 데이터베이스 d1d2 를 동시에 새로 고쳐야 합니다.

  • 다른 데이터베이스의 오브젝트를 참조하는 구체화된 뷰로 인해 현재 다음 오류 메시지와 함께 복제 또는 새로 고침 작업이 실패합니다.

    Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])
    

    구체화된 뷰는 이름이 아닌 ID로 오브젝트를 참조하기 때문입니다. 데이터베이스 스냅샷은 데이터베이스 외부의 오브젝트에 대한 ID 기반 참조를 확인할 수 없습니다.

    이러한 제한을 해결하려면 구체화된 뷰 및 해당 참조 오브젝트를 동일한 데이터베이스에 저장하는 것이 좋습니다.

제약 조건

현재 외래 키가 현수된 경우 복제가 실패하며 다음과 같은 오류 메시지가 표시됩니다.

Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])

이러한 상황은 기본 데이터베이스의 외래 키가 다른 데이터베이스의 기본 키를 참조하거나 그 반대의 경우에 발생합니다. 이는 제약 조건 참조가 ID 기반이기 때문입니다. 데이터베이스 스냅샷은 자체 데이터베이스 외부의 오브젝트에 대한 ID 기반 참조를 확인할 수 없습니다.

계정에서 외래 키 참조를 보려면 Information Schema 또는 ACCOUNT_USAGE 스키마에서 TABLE_CONSTRAINTS 뷰를 쿼리합니다.

이러한 제한을 해결하려면 연결된 테이블을 동일한 데이터베이스에 저장하는 것이 좋습니다.

시퀀스

현재, 현수 시퀀스로 인해 복제가 실패하고 다음 오류 메시지가 표시됩니다.

Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])

이러한 상황은 기본 데이터베이스의 테이블이 다른 데이터베이스의 시퀀스를 참조할 때 발생합니다. 이는 시퀀스 참조가 ID 기반이기 때문입니다. 데이터베이스 스냅샷은 자체 데이터베이스 외부의 오브젝트에 대한 ID 기반 참조를 확인할 수 없습니다.

이 제한을 해결하려면 동일한 데이터베이스의 시퀀스를 참조하는 것이 좋습니다.

정책 및 태그

마스킹 정책, 행 액세스 정책 또는 태그 에 대한 현수 참조로 인해 다음 오류 메시지와 함께 복제가 실패하게 됩니다.

Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])

이 상황은 정책/태그와 정책/태그가 할당된 오브젝트가 다른 데이터베이스에 존재할 때 발생합니다. 예를 들어 db1.s1.t1 로 명명된 테이블, db2.s1.rap1 로 명명된 행 액세스 정책, 행 액세스 정책이 테이블에 할당됩니다.

이 현수 참조 동작은 데이터베이스 복제에 적용됩니다.

이 문제를 해결하려면 복제 그룹 을 사용하여 데이터베이스를 복제하십시오.

현수 참조는 계정 복제 및 장애 조치 컨텍스트에서 네트워크 정책 이 사용자에게 할당될 때도 발생할 수 있습니다. 자세한 내용은 네트워크 정책 복제 를 참조하십시오.

삭제된 오브젝트 참조

동일한 또는 다른 데이터베이스의 다른 오브젝트가 참조하는 오브젝트를 삭제하면 현수 참조가 생성됩니다. 기본 데이터베이스의 오브젝트가 삭제된 오브젝트를 참조하는 경우 복제 작업이 실패하며 다음 메시지가 표시됩니다.

Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])

이 제한을 해결하려면 다음 단계 중 하나 를 완료하는 것이 좋습니다.

  • 참조된 오브젝트의 삭제를 취소합니다.

  • 참조 오브젝트를 수정합니다(예: ALTER MATERIALIZED VIEW 를 사용하여 구체화된 뷰 수정). 다른 오브젝트를 참조하거나 삭제된 오브젝트에 대한 참조를 제거합니다.

  • 삭제된 오브젝트를 참조하는 기본 데이터베이스의 모든 오브젝트를 삭제합니다.

저장 프로시저 및 사용자 정의 함수(UDF)의 복제

저장 프로시저와 UDF는 기본 데이터베이스에서 보조 데이터베이스로 복제됩니다.

스테이지 복제는 아직 지원되지 않습니다. 저장 프로시저 또는 UDF가 어떤 스테이지의 파일에 종속되는 경우(예: 저장 프로시저가 어떤 스테이지에서 업로드되는 Python 코드로 정의된 경우), 스테이지와 스테이지의 파일을 보조 데이터베이스에 수동으로 복제해야 합니다.

예를 들어 기본 데이터베이스에 스테이지에 저장된 코드를 가져오는 인라인 Python UDF가 있는 경우, UDF는 보조 데이터베이스에 복제되지만 스테이지와 가져온 코드를 보조 데이터베이스에서 수동으로 복제해야 작동합니다.

복제 및 액세스 제어

보조 데이터베이스는 읽기 전용이지만, 데이터베이스 소유자(즉, 보조 데이터베이스에 대한 OWNERSHIP 권한 역할)는 GRANT <권한> 를 사용하여 데이터베이스 오브젝트(즉, 스키마, 테이블, 뷰 등)에 대한 권한을 다른 역할에 부여할 수 있습니다.

여러 데이터베이스 복제

여러 데이터베이스가 복제되는 경우 데이터베이스 전반에서 시점 일관성을 사용할 수 없습니다. 각 기본 데이터베이스의 스냅샷은 독립적으로 생성되고 보조 데이터베이스에 대한 변경 사항은 독립적으로 커밋됩니다. 이는 서로 다른 데이터베이스의 테이블 간에 조인하거나 데이터베이스 간 트랜잭션을 사용하는 뷰가 있는 경우 문제가 될 수 있습니다. 예를 들어, 두 개의 기본 데이터베이스를 원자적으로 업데이트하는 트랜잭션은 보조 데이터베이스에 동시에 반영되지 않을 수 있습니다.

과거 사용 데이터

기본 데이터베이스의 활동에 대한 과거 사용 데이터는 보조 데이터베이스에 복제되지 않습니다. 각 계정에는 고유한 쿼리 내역, 로그인 내역 등이 있습니다.

과거 사용 데이터에는 다음 Snowflake Information Schema 테이블 함수 또는 Account Usage 뷰에서 반환된 쿼리 데이터가 포함됩니다.

  • COPY_HISTORY

  • LOGIN_HISTORY

  • QUERY_HISTORY

맨 위로 이동