CREATE <object> … CLONE
CREATE
시스템에서 기존 객체의 복사본을 만드는 명령이에요. 이 명령은 주로 데이터베이스, 스키마, 테이블의 제로 카피 클론(zero-copy clones)을 만드는 데 사용돼요. 외부 스테이지, 파일 형식, 시퀀스, 데이터베이스 역할을 포함한 다른 스키마 객체의 클론을 만드는 데도 사용할 수 있어요.
출처: 문서
본문
이 명령은 CLONE 키워드가 추가된 객체별 CREATE 명령의 변형이에요.
Time Travel로 객체 클론 (Clone objects using Time Travel)
데이터베이스, 스키마, 비임시 테이블의 경우 CLONE은 Time Travel을 사용한 클로닝을 위한 추가적인 AT | BEFORE 절을 지원해요.
데이터베이스와 스키마의 경우:
-
CLONE은 Time Travel에서 제거(purge)된 테이블(예: 데이터 보존 기간이 하루인 임시(transient) 테이블)을 건너뛰는 IGNORE TABLES WITH INSUFFICIENT DATA RETENTION 파라미터를 지원해요. -
CLONE은 필요에 따라 하이브리드 테이블(hybrid tables)을 건너뛰는 IGNORE HYBRID TABLES 파라미터를 지원해요.
참고
하이브리드 테이블을 포함한 데이터베이스 복제에 대한 정보는 Clone databases that contain hybrid tables을 참고하세요.
구문 (Syntax)
데이터베이스, 스키마
CREATE [ OR REPLACE ] { DATABASE | SCHEMA } [ IF NOT EXISTS ] <object_name>
CLONE <source_object_name>
[ { AT | BEFORE } ( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]
[ IGNORE TABLES WITH INSUFFICIENT DATA RETENTION ]
[ IGNORE HYBRID TABLES ]
[ INCLUDE INTERNAL STAGES ]
...
테이블
CREATE [ OR REPLACE ] TABLE [ IF NOT EXISTS ] <object_name>
CLONE <source_object_name>
[ { AT | BEFORE } ( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]
...
동적 테이블
CREATE [ OR REPLACE ] DYNAMIC TABLE <name>
CLONE <source_dynamic_table>
[ { AT | BEFORE } ( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]
[
TARGET_LAG = { '<num> { seconds | minutes | hours | days }' | DOWNSTREAM }
WAREHOUSE = <warehouse_name>
]
이벤트 테이블
CREATE [ OR REPLACE ] EVENT TABLE <name>
CLONE <source_event_table>
[ { AT | BEFORE } ( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]
Apache Iceberg™ 테이블
CREATE [ OR REPLACE ] ICEBERG TABLE [ IF NOT EXISTS ] <name>
CLONE <source_iceberg_table>
[ { AT | BEFORE } ( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]
[ COPY GRANTS ]
...
데이터베이스 역할
CREATE [ OR REPLACE ] DATABASE ROLE [ IF NOT EXISTS ] <database_role_name>
CLONE <source_database_role_name>
기타 스키마 객체
CREATE [ OR REPLACE ] { ALERT | FILE FORMAT | SEQUENCE | STAGE | STREAM | TASK }
[ IF NOT EXISTS ] <object_name>
CLONE <source_object_name>
...
Time Travel 파라미터
{ AT | BEFORE } ( { TIMESTAMP => *timestamp* | OFFSET => *time_difference* | STATEMENT => *id* } )
AT | BEFORE 절은 다음 파라미터 중 하나를 받아들여요:
TIMESTAMP => timestamp
Time Travel에 사용할 정확한 날짜와 시간을 지정해요. 값은 TIMESTAMP, TIMESTAMP_LTZ, TIMESTAMP_NTZ 또는 TIMESTAMP_TZ 데이터 유형으로 명시적으로 캐스팅해야 해요.
명시적 캐스팅이 지정되지 않으면 AT 절의 타임스탬프는 UTC 시간대의 타임스탬프(TIMESTAMP_NTZ와 동일)로 취급돼요. 명시적 캐스팅에 TIMESTAMP 데이터 유형을 사용해도 값이 TIMESTAMP_NTZ 값으로 취급될 수 있어요. 자세한 내용은 Date & time data types을 참고하세요.
OFFSET => time_difference
Time Travel에 사용할 현재 시간으로부터의 차이(초)를 -N 형식으로 지정해요. N은 정수 또는 산술 표현식일 수 있어요(예: -120은 120초, -30*60은 1800초 또는 30분).
STATEMENT => id
Time Travel의 기준점으로 사용할 문의 쿼리 ID를 지정해요. 이 파라미터는 다음 유형 중 하나의 모든 문을 지원해요:
-
DML(예: INSERT, UPDATE, DELETE)
-
TCL(BEGIN, COMMIT 트랜잭션)
-
SELECT
쿼리 ID는 지난 14일 내에 실행된 쿼리를 참조해야 해요. 쿼리 ID가 14일이 넘은 쿼리를 참조하면 다음 오류가 반환돼요:
Error: statement <query_id> not found
이 제한을 해결하려면 참조된 쿼리에 타임스탬프를 사용하세요.
IGNORE TABLES WITH INSUFFICIENT DATA RETENTION
클론할 Time Travel에 과거 데이터가 더 이상 없는 테이블을 무시해요. AT | BEFORE 절에 지정된 과거 시간이 데이터베이스나 스키마의 하위 테이블의 데이터 보존 기간을 넘어서면 하위 테이블의 복제 작업을 건너뛰어요. 자세한 내용은 Child Objects and Data Retention Time을 참고하세요.
하이브리드 테이블 파라미터
IGNORE HYBRID TABLES
데이터베이스나 스키마를 복제할 때 하이브리드 테이블을 무시해요. 복제된 데이터베이스나 스키마에 다른 객체는 포함되지만 하이브리드 테이블은 건너뛰어요. 자세한 내용은 Clone databases that contain hybrid tables을 참고하세요.
내부 스테이지 파라미터
INCLUDE INTERNAL STAGES
데이터베이스나 스키마를 복제할 때 이름 있는 내부 스테이지를 포함해요.
자세한 내용은 사용 참고사항을 참고하세요.
접근 제어 요구사항 (Access control requirements)
클론을 만들려면 현재 역할이 소스 객체에 다음 권한을 가져야 해요:
데이터베이스:
데이터베이스에 대한 USAGE.
데이터베이스 역할:
데이터베이스 역할에 대한 OWNERSHIP과 대상 데이터베이스에 대한 CREATE DATABASE ROLE 권한.
스키마:
WITH MANAGED ACCESS 절을 지정하면 필수 권한은 소스 스키마가 관리되는(managed) 스키마인지 여부에 달려 있어요. 자세한 내용은 CREATE SCHEMA privileges를 참고하세요.
테이블:
SELECT
경고, 파이프, 스트림, 태스크:
OWNERSHIP
기타 객체:
USAGE
또한 스키마나 스키마 내 객체를 복제하려면 현재 역할이 소스와 클론 양쪽의 컨테이너 객체에 필수 권한을 가져야 해요.
복제된 객체의 권한 상속에 대한 정보는 Cloning considerations을 참고하세요.
일반 사용 참고사항 (General usage notes)
-
클론은 쓰기 가능하며 소스와 독립적이에요. 소스나 클론에 대한 변경은 다른 객체에 반영되지 않아요.
-
소스 데이터베이스, 스키마, 테이블에 명시적으로 설정된 파라미터는 소스 컨테이너나 하위 객체에서 만들어진 모든 클론에 유지돼요.
-
데이터베이스 역할의 경우:
-
데이터베이스를 복제하기 위해 CREATE DATABASE … CLONE 명령을 실행하면 데이터베이스 역할이 복제돼요. 하지만 스키마나 테이블 같은 다른 데이터베이스 객체를 복제하면 데이터베이스의 데이터베이스 역할은 스키마나 테이블과 함께 복제되지 않아요.
-
데이터베이스 역할이 이미 대상 데이터베이스로 복제된 경우 명령이 실패해요. 이 경우 대상 데이터베이스에서 데이터베이스 역할을 삭제하고 CLONE 명령을 다시 시도해요.
-
-
데이터베이스와 스키마의 경우 복제는 재귀적이에요:
-
데이터베이스를 복제하면 데이터베이스의 모든 스키마와 기타 객체가 복제돼요.
-
스키마를 복제하면 스키마의 모든 포함 객체가 복제돼요.
-
복제에는 클론을 만드는 역할이 적절한 권한을 갖는 객체만 포함돼요.
-
하지만 다음 객체 유형은 복제되지 않아요:
-
외부 테이블
-
하이브리드 테이블은 데이터베이스에 대해 복제할 수 있지만 스키마에 대해서는 복제할 수 없어요.
-
데이터베이스나 스키마의 사용자 태스크는 CREATE SCHEMA … TIMESTAMP를 사용할 때 복제되지 않아요. 다음 예제에서 소스 스키마(S1)의 태스크는 타임스탬프가 있는 스키마(S2)로 복제되지 않지만 타임스탬프가 없는 스키마(S3)로는 복제돼요.
CREATE SCHEMA S1;
USE SCHEMA S1;
CREATE TASK T1 AS SELECT 1;
CREATE SCHEMA S2 CLONE S1 AT(TIMESTAMP => '2025-04-01 12:00:00');
-- T1 is not cloned into S2
CREATE SCHEMA S3 CLONE S1;
-- T1 is cloned into S3
-
데이터베이스, 스키마, 테이블의 경우 클론은 기존 데이터를 수정하거나 새 데이터를 추가하는 작업(예: 복제된 테이블에서 행 추가·삭제·수정, 복제된 스키마에서 새로 채워진 테이블 만들기)이 클론에서 수행될 때까지 객체의 전체 데이터 스토리지에 기여하지 않아요.
-
테이블을 복제하면 소스 테이블의 구조, 데이터, 일부 속성(예:
STAGE FILE FORMAT)이 복제돼요.
하지만:
-
복제된 테이블은 소스 테이블의 로드 기록(load history)을 포함하지 않아요. 그 결과로 소스 테이블에 로드된 데이터 파일을 그 클론에 다시 로드할 수 있어요.
-
복제된 테이블은 소스 테이블의 클러스터링 키를 복제하지만, 소스 테이블에서 자동 클러스터링(Automatic Clustering)이 중단되지 않았더라도 새 테이블은 자동 클러스터링이 중단된 상태로 시작해요.
-
스토리지 수명 주기 정책(Storage lifecycle policies)은 복제된 테이블에 자동으로 적용되지 않아요. 소스 테이블에 스토리지 수명 주기 정책이 연결되어 있으면 ALTER TABLE 명령으로 클론에 정책을 수동으로 연결해야 해요.
-
COPY GRANTS 파라미터는 새 테이블 클론에 다음과 같이 영향을 미쳐요:
-
COPY GRANTS 파라미터를 사용하면 새 객체는 원래 테이블에 부여된 명시적 접근 권한을 상속하지만, 스키마에서 객체 유형에 대해 정의된 future grants는 상속하지 않아요.
-
COPY GRANTS 파라미터를 사용하지 않으면 새 객체 클론은 원래 테이블에 부여된 명시적 접근 권한을 상속하지 않지만, (GRANT
… ON FUTURE 구문으로) 스키마에서 객체 유형에 대해 정의된 future grants는 상속해요.
-
참고
문이 같은 이름의 기존 테이블을 교체하는 경우 권한은 교체되는 테이블에서 복사돼요. 그 이름의 기존 테이블이 없으면 권한은 복제되는 소스 테이블에서 복사돼요.
-
Apache Iceberg™ 테이블의 경우 복제는 현재 Snowflake 관리 테이블에서만 지원돼요. 자세한 내용은 Cloning and Apache Iceberg™ tables을 참고하세요.
-
이름 있는 내부 스테이지의 경우:
-
복제는 데이터베이스 또는 스키마 수준에서만 지원돼요.
-
디렉터리 테이블이 활성화된 스테이지의 경우 Snowflake는 디렉터리 테이블을 스테이지 파일의 진실 원천으로 사용해요. 복제 전에 디렉터리 테이블을 새로고침하는 것을 권장해요.
복제된 스테이지는 복제 시점에 소스 디렉터리 테이블에 등록된 삭제되지 않은 파일의 복사본을 포함해요. 파일이 업데이트되었지만 디렉터리 테이블이 새로고침되지 않으면 업데이트된 파일은 복사되지 않아요. 복제 후 소스 스테이지와 클론은 연결되지 않아요. 소스 스테이지의 파일 변경은 복제된 스테이지의 파일에 영향을 주지 않아요(그 반대도 마찬가지).
-
디렉터리 테이블이 활성화되지 않은 스테이지의 경우 Snowflake는 빈 클론을 만들어요(소스 스테이지의 파일을 복사하지 않음).
-
Snowflake는 CREATE CLONE 문이 Time Travel(AT | BEFORE)을 사용하는지 여부와 무관하게 내부 스테이지를 현재 상태로 복제해요. 스테이지가 만들어지기 전의 시점을 지정하면 스테이지는 복제되지 않아요.
-
내부 스테이지 복제는 컴퓨트 및 파일 전송 요금이 발생하는 COPY FILES 서비스에 의존해요. 크레딧 사용과 복사된 바이트를 모니터링하려면 COPY_FILES_HISTORY 뷰를 쿼리할 수 있어요.
-
-
메타데이터에 관해: 고객은 Snowflake 서비스를 사용할 때 메타데이터로 개인 데이터(User 객체 외), 민감 데이터, 수출 통제 데이터 또는 기타 규제 데이터를 입력하지 않도록 해야 해요. 자세한 내용은 Metadata fields in Snowflake를 참고하세요.
-
OR REPLACE와IF NOT EXISTS절은 상호 배타적이에요. 같은 문에서 둘 다 사용할 수 없어요. -
CREATE OR REPLACE <object>문은 원자적이에요. 즉 객체를 교체할 때 기존 객체가 삭제되고 새 객체가 단일 트랜잭션으로 만들어져요.
객체 복제에 적용되는 추가 규칙
메타데이터:
객체 클론은 CREATE
하위 객체:
데이터베이스나 스키마 클론은 문이 실행된 시점 또는 지정된 과거 시점에 활성 상태였던 모든 하위 객체를 포함해요. 테이블 데이터의 스냅샷은 문이 실행될 때 또는 지정된 과거 시점의 소스 데이터 상태를 나타내요. 하위 객체는 문이 실행될 때 소스 하위 객체의 이름과 구조를 상속해요.
복제되지 않는 것:
데이터베이스나 스키마를 복제해도 데이터베이스나 스키마의 외부 테이블은 복제되지 않아요.
하이브리드 테이블은 데이터베이스에 대해 복제할 수 있지만 스키마에 대해서는 복제할 수 없어요.
파이프:
데이터베이스나 스키마 클론은 외부(Amazon S3, Google Cloud Storage, Microsoft Azure) 스테이지를 참조하는 파이프 객체만 포함해요. 내부(Snowflake) 파이프는 복제되지 않아요.
파이프 클론의 기본 상태는 다음과 같아요:
-
AUTO_INGEST = FALSE일 때 복제된 파이프는 기본적으로 일시 중지(paused)돼요. -
AUTO_INGEST = TRUE일 때 복제된 파이프는STOPPED_CLONED상태로 설정돼요. 이 상태에서 파이프는 새로 스테이징된 파일로 인한 이벤트 알림을 누적하지 않아요. 파이프가 명시적으로 다시 시작되면 새 이벤트 알림의 결과로 트리거된 데이터 파일만 처리해요.
어느 상태의 파이프 클론이든 ALTER PIPE … SET PIPE_EXECUTION_PAUSED = false 문을 실행해 다시 시작할 수 있어요.
태그:
데이터베이스나 스키마를 복제하면 그 데이터베이스나 스키마의 태그(tags)에 다음과 같이 영향을 미쳐요:
-
소스 객체(예: 테이블)의 태그 연관은 복제된 객체에 유지돼요.
-
데이터베이스나 스키마의 경우:
데이터베이스나 스키마가 복제되면 그 스키마나 데이터베이스에 있는 태그도 복제돼요.
테이블이나 뷰가 소스 스키마/데이터베이스에 있고 같은 스키마/데이터베이스의 태그를 참조하면, 복제된 테이블이나 뷰는 소스 스키마/데이터베이스의 태그 대신 해당하는 복제된 태그(대상 스키마/데이터베이스의)에 매핑돼요.
Java UDF:
Java UDF가 포함된 데이터베이스나 스키마가 복제될 때 Java UDF를 복제할 수 있어요. 복제되려면 Java UDF는 특정 조건을 충족해야 해요. 자세한 내용은 Limitations on cloning을 참고하세요.
데이터 메트릭 함수:
복제로 인해 대상 객체에 DMF 할당이 생기지는 않아요. DMF가 포함된 데이터베이스나 스키마를 복제하면 DMF가 대상 데이터베이스나 스키마로 복제돼요.
테이블 데이터:
데이터베이스, 스키마, 테이블을 복제할 때 각 테이블의 데이터 스냅샷이 찍혀 클론에 제공돼요. 스냅샷은 문이 실행될 때 또는 (Time Travel을 사용해) 지정된 과거 시점의 소스 데이터 상태를 나타내요.
객체 참조:
뷰, 스트림, 태스크 같은 객체는 정의에 객체 참조를 포함해요. 예:
-
뷰는 테이블 참조를 포함하는 저장된 쿼리를 갖고 있어요.
-
스트림은 소스 테이블을 가리켜요.
-
태스크나 경고는 저장 프로시저를 호출하거나 다른 객체를 참조하는 SQL 문을 실행해요.
이러한 객체 중 하나가 복제된 데이터베이스나 스키마에서 또는 개별 객체로 복제될 때, 복제를 지원하는 객체 유형의 경우 클론은 소스 객체의 정의에서 다른 객체에 대한 참조를 상속해요. 예를 들어 뷰의 클론은 쿼리의 테이블 참조를 포함한 저장된 쿼리를 소스 뷰에서 상속해요.
소스 객체 정의의 객체 이름이 완전히 또는 부분적으로 정규화되었는지 면밀히 주의하세요. 완전 정규화된 이름은 데이터베이스와 스키마 이름을 포함해요. 소스 객체의 모든 클론은 그 자체 정의에 이 부분들을 포함해요.
예:
-- Create a schema to serve as the source for a cloned schema.
CREATE SCHEMA source;
-- Create a table.
CREATE TABLE mytable (col1 string, col2 string);
-- Create a view that references the table with a fully-qualified name.
CREATE VIEW myview AS SELECT col1 FROM source.mytable;
-- Retrieve the DDL for the source schema.
SELECT GET_DDL ('schema', 'source', true);
+--------------------------------------------------------------------------+
| GET_DDL('SCHEMA', 'SOURCE', TRUE) |
|--------------------------------------------------------------------------|
| create or replace schema MPETERS_DB.SOURCE; |
| |
| create or replace TABLE MPETERS_DB.SOURCE.MYTABLE ( |
| COL1 VARCHAR(16777216), |
| COL2 VARCHAR(16777216) |
| ); |
| |
| create view MPETERS_DB.SOURCE.MYVIEW as select col1 from SOURCE.MYTABLE; |
| |
+--------------------------------------------------------------------------+
-- Clone the source schema.
CREATE SCHEMA source_clone CLONE source;
-- Retrieve the DDL for the clone of the source schema.
-- The clone of the view references the source table with the same fully-qualified name
-- as in the view in the source schema.
SELECT GET_DDL ('schema', 'source_clone', true);
+--------------------------------------------------------------------------------+
| GET_DDL('SCHEMA', 'SOURCE_CLONE', TRUE) |
|--------------------------------------------------------------------------------|
| create or replace schema MPETERS_DB.SOURCE_CLONE; |
| |
| create or replace TABLE MPETERS_DB.SOURCE_CLONE.MYTABLE ( |
| COL1 VARCHAR(16777216), |
| COL2 VARCHAR(16777216) |
| ); |
| |
| create view MPETERS_DB.SOURCE_CLONE.MYVIEW as select col1 from SOURCE.MYTABLE; |
| |
+--------------------------------------------------------------------------------+
뷰를 다른 데이터베이스나 스키마의 같은 이름의 테이블을 가리키게 하려면 기존 뷰를 복제하는 대신 새 뷰를 만드는 것을 권장해요. 이 지침은 정의에서 객체를 참조하는 다른 객체에도 적용돼요.
참고
-
복제 작업에는 특정 제한이 적용돼요. 예를 들어 복제 작업 중에 소스 객체에 영향을 주는 DDL 문은 결과를 바꾸거나 오류를 일으킬 수 있어요.
-
복제는 특히 큰 객체(데이터베이스, 스키마, 테이블)의 경우 즉각적이지 않고, 복제되는 객체를 잠그지 않아요. 따라서 복제 작업이 아직 실행 중인 동안 테이블 데이터에 적용된 DML 문은 클론에 반영되지 않아요.
이것과 복제 작업에 영향을 줄 수 있는 다른 사용 사례에 대한 자세한 내용은 Cloning considerations을 참고하세요.
Time Travel로 복제할 때의 참고사항
-
AT | BEFORE 절은 지정된 과거 시점 또는 지정된 SQL 문을 기준으로 데이터베이스, 스키마, 테이블을 복제해요:
-
AT키워드는 요청이 지정된 파라미터와 같은 타임스탬프를 가진 문이나 트랜잭션이 한 변경을 포함함을 지정해요. -
BEFORE키워드는 요청이 지정된 파라미터 직전의 시점을 가리킴을 지정해요.
-
-
STATEMENT을 사용한 복제는 지정된 문 ID로 식별되는 SQL 문(또는 그것을 포함하는 트랜잭션)의 기록된 실행 시간과 같은 값으로TIMESTAMP를 사용하는 것과 동일해요. -
다음 경우 오류가 반환돼요:
-
복제되는 객체가 AT | BEFORE 절에 지정된 과거 시점에 존재하지 않았을 때.
-
객체나 그 하위 객체(예: 복제된 스키마나 데이터베이스의 테이블)를 복제하는 데 필요한 과거 데이터가 제거(purge)되었을 때.
Time Travel에서 제거된 하위 객체에 대한 해결 방법으로 CREATE
-
-
복제된 데이터베이스나 스키마의 하위 객체가 AT | BEFORE 절에 지정된 과거 시점에 존재하지 않았다면 그 하위 객체는 복제되지 않아요.
시점을 지정하지 않으면 클론은 현재의 객체 상태(CURRENT_TIMESTAMP 값)로 기본 설정돼요.
자세한 내용은 Understanding & using Time Travel을 참고하세요.
Time Travel로 객체 복제 문제 해결
다음 시나리오는 Time Travel을 사용해 객체를 복제할 때 발생할 수 있는 문제를 해결하는 데 도움이 돼요.
000707 (02000): Time travel data is not available for <object_type>
<object_name>. The requested time is either beyond the allowed time
travel period or before the object creation time.
이 오류는 다음 이유로 반환될 수 있어요:
| Cause | AT | BEFORE 절이 지정한 과거 시간이 객체의 데이터 보존 기간을 넘어섰어요. |
|---|---|
| Solution | 적절한 SHOW |
IGNORE TABLES WITH INSUFFICIENT DATA RETENTION
| Cause | 하위 객체의 과거 데이터가 Time Travel 밖으로 이동했으면 데이터베이스나 스키마의 복제 작업이 실패해요. |
|---|---|
| Solution | Time Travel에 과거 데이터가 더 이상 없는 하위 테이블을 건너뛰려면 해당 파라미터를 사용해 복제 문을 실행해 이 테이블들을 건너뛰어요. |
... AT(TIMESTAMP => '2023-12-31 12:00:00') -- fails
... AT(TIMESTAMP => '2023-12-31 12:00:00'::TIMESTAMP) -- succeeds
| Cause | 어떤 경우에는 타임스탬프가 필요한 곳에 문자열을 사용해서 발생해요. |
|---|---|
| Solution | 문자열을 타임스탬프로 캐스팅해요. |
예제 (Examples)
현재 상태에서 데이터베이스와 그 안의 모든 객체를 복제하는 예제예요:
CREATE DATABASE mytestdb_clone CLONE mytestdb;
현재 상태에서 스키마와 그 안의 모든 객체를 복제하는 예제예요:
CREATE SCHEMA mytestschema_clone CLONE testschema;
현재 상태에서 테이블을 복제하는 예제예요:
CREATE TABLE orders_clone CLONE orders;
지정된 타임스탬프의 날짜와 시간 이전에 존재했던 스키마를 복제하는 예제예요:
CREATE SCHEMA mytestschema_clone_restore CLONE testschema
BEFORE (TIMESTAMP => TO_TIMESTAMP(40*365*86400));
지정된 타임스탬프의 날짜와 시간에 정확히 존재했던 테이블을 복제하는 예제예요:
CREATE TABLE orders_clone_restore CLONE orders
AT (TIMESTAMP => TO_TIMESTAMP_TZ('04/05/2013 01:02:03', 'mm/dd/yyyy hh24:mi:ss'));
지정된 문의 실행 직전에 존재했던 테이블을 복제하는 예제예요. 예제의 STATEMENT 파라미터에 대한 쿼리 ID를 바꾸고 다음 CREATE TABLE 문을 실행해요:
CREATE TABLE orders_clone_restore CLONE orders BEFORE (STATEMENT => '8e5d0ca9-005e-44e6-b858-a8f5b37c5726');
4일 전에 존재했던 데이터베이스와 그 모든 객체를 복제하고 데이터 보존 기간이 4일 미만인 테이블을 건너뛰는 예제예요:
CREATE DATABASE restored_db CLONE my_db
AT (TIMESTAMP => DATEADD(days, -4, current_timestamp)::timestamp_tz)
IGNORE TABLES WITH INSUFFICIENT DATA RETENTION;
표준 테이블과 하이브리드 테이블이 섞인 스키마를 복제하는 예제예요:
CREATE OR REPLACE SCHEMA clone_ht_schema CLONE ht_schema
IGNORE HYBRID TABLES;
새 스키마는 원래 스키마의 표준 테이블만 포함해요. 이 예제에서 IGNORE HYBRID TABLES를 지정하지 않으면 하이브리드 테이블을 포함한 스키마는 복제할 수 없으므로 명령이 오류로 실패해요.
더 알아보기 (Learn more)
CREATE , Cloning considerations, Understanding & using Time Travel