Time Travel 이해 및 사용하기

Snowflake Time Travel을 사용하면 정의된 기간 내의 모든 시점에서 과거 데이터(즉, 변경 또는 삭제된 데이터)에 액세스할 수 있습니다. Snowflake Time Travel은 다음과 같은 작업을 수행하기 위한 강력한 도구의 역할을 합니다.

  • 실수로 또는 의도적으로 삭제한 데이터 관련 오브젝트(테이블, 스키마, 데이터베이스) 복원.

  • 과거의 주요 시점에서 데이터 복제 및 백업.

  • 지정된 기간 동안의 데이터 사용/조작 분석.

이 항목의 내용:

Time Travel 소개

연속 데이터 보호 수명 주기의 Time Travel

Time Travel을 사용하면 정의된 기간 내에 다음과 같은 작업을 수행할 수 있습니다.

  • 업데이트 또는 삭제된 과거 데이터 쿼리.

  • 과거의 특정 시점 또는 그 이전의 전체 테이블, 스키마 및 데이터베이스 복제본 생성.

  • 삭제된 테이블, 스키마, 데이터베이스 복원.

참고

테이블 또는 구체화되지 않은 뷰에서 기록 데이터를 쿼리할 때 현재 테이블 또는 뷰 스키마가 사용됩니다. 자세한 내용은 AT | BEFORE에 대한 사용법 노트 섹션을 참조하십시오.

정의된 기간이 경과된 후, 데이터는 Snowflake Fail-safe 로 이동되며 이러한 작업을 더 이상 수행할 수 없습니다.

참고

장시간 실행 중인 Time Travel 쿼리가 있으면 이 쿼리가 완료될 때까지 계정의 모든 데이터와 오브젝트(테이블, 스키마, 데이터베이스)가 Fail-safe로 이동하는 과정이 지연됩니다.

Time Travel SQL 확장

Time Travel을 지원하기 위해 다음 SQL 확장이 구현되었습니다.

  • SELECT 문 및 CREATE … CLONE 명령에서 (오브젝트 이름의 바로 뒤에) 지정할 수 있는 AT | BEFORE 절. 이 절은 다음 매개 변수 중 하나를 사용하여 액세스할 정확한 과거 데이터를 찾습니다.

    • TIMESTAMP

    • OFFSET(현재 시간과의 초 단위 시간 차이)

    • STATEMENT(문의 식별자, 예: 쿼리 ID)

  • 테이블, 스키마, 데이터베이스에 대한 UNDROP 명령

    Time Travel SQL 확장

데이터 보존 기간

Snowflake Time Travel의 주요 구성 요소는 데이터 보존 기간입니다.

데이터 삭제 또는 데이터가 포함된 오브젝트의 삭제 등, 테이블에서 데이터가 수정되면 Snowflake는 업데이트를 수행하기 전까지 해당 데이터의 상태를 보존합니다. 데이터 보존 기간은 이러한 과거 데이터를 보존하고 그에 따라 해당 데이터에 대해 Time Travel 작업(SELECT, CREATE … CLONE, UNDROP)을 수행할 수 있는 일수를 지정합니다.

표준 보존 기간은 1일(24시간)이며 모든 Snowflake 계정에서 이 기간이 자동으로 설정됩니다.

  • Snowflake Standard Edition의 경우 계정 및 오브젝트(즉, 데이터베이스, 스키마, 테이블) 수준에서 보존 기간을 0으로 설정(또는 설정을 해제하여 기본값인 1일로 재설정)할 수 있습니다.

  • Snowflake Enterprise Edition 이상의 경우:

    • 일시적 데이터베이스, 스키마, 테이블로 사용하려면 보존 기간을 0으로 설정(설정을 해제하여 기본값인 1일로 재설정)할 수 있습니다. 임시 테이블의 경우도 마찬가지입니다.

    • 영구 데이터베이스, 스키마 및 테이블로 사용하려면, 보존 기간을 0~90일 사이의 값으로 설정할 수 있습니다.

참고

오브젝트의 보존 기간이 0일이면 해당 오브젝트의 Time Travel이 사실상 비활성화됩니다.

오브젝트의 보존 기간이 끝나면 과거 데이터가 Snowflake Fail-safe 로 이동되어 다음과 같이 됩니다.

  • 과거 데이터를 더 이상 쿼리할 수 없습니다.

  • 과거 오브젝트를 더 이상 복제할 수 없습니다.

  • 삭제된 과거 오브젝트를 더 이상 복원할 수 없습니다.

Time Travel을 위한 데이터 보존 기간을 지정하는 방법은 다음과 같습니다.

  • ACCOUNTADMIN 역할을 가진 사용자는 DATA_RETENTION_TIME_IN_DAYS 오브젝트 매개 변수를 사용하여 계정의 기본 보존 기간을 설정할 수 있습니다.

  • 이 매개 변수를 사용하여 데이터베이스, 스키마, 개별 테이블 생성 시 기본값을 명시적으로 재정의할 수 있습니다.

  • 데이터베이스, 스키마 또는 테이블에 대한 데이터 보존 기간은 언제든지 변경할 수 있습니다.

  • ACCOUNTADMIN 역할을 가진 사용자가 MIN_DATA_RETENTION_TIME_IN_DAYS 계정 매개 변수를 사용해 계정의 최소 보존 기간을 설정할 수 있습니다. 이 매개 변수는 DATA_RETENTION_TIME_IN_DAYS 매개 변수 값을 변경하거나 대체하지 않습니다. 하지만 유효 데이터 보존 시간을 변경할 수 있습니다. 이 매개 변수가 계정 수준에서 설정되면 오브젝트에 유효한 최소 데이터 보존 기간은 MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS)에 의해 결정됩니다.

Time Travel 활성화 및 비활성화

Time Travel을 활성화하기 위해 수행해야 할 작업은 없습니다. Time Travel은 자동으로 기본 1일의 보존 기간으로 활성화됩니다.

그러나 Snowflake Enterprise Edition으로 업그레이드하면 데이터베이스, 스키마 및 테이블에 최대 90일까지를 허용하는 더 긴 데이터 보존 기간을 구성할 수 있습니다. 데이터 보존 기간을 연장하려면 추가 저장소가 필요하며, 이와 관련한 월간 저장소 요금이 부과된다는 점에 유의하십시오. 저장소 요금에 대한 자세한 내용은 Time Travel 및 Fail-safe 관련 저장소 요금 을 참조하십시오.

계정에 대해 Time Travel을 비활성화할 수 없습니다. ACCOUNTADMIN 역할의 사용자도 계정 수준에서 DATA_RETENTION_TIME_IN_DAYS 를 0으로 설정할 수 있으며, 이는 계정에서 생성된 모든 데이터베이스(및 차후의 모든 스키마와 테이블)에 기본적으로 보존 기간이 없다는 의미이지만, 데이터베이스, 스키마 또는 테이블에 대한 이 기본값을 언제든지 재정의할 수 있습니다.

ACCOUNTADMIN 역할을 가진 사용자는 계정 수준에서 MIN_DATA_RETENTION_TIME_IN_DAYS 를 설정할 수도 있습니다. 이 매개 변수 설정은 데이터베이스, 스키마, 테이블에 대해 최소 데이터 보존 기간을 적용합니다. DATA_RETENTION_TIME_IN_DAYS의 설정이 MIN_DATA_RETENTION_TIME_IN_DAYS 매개 변수 값을 변경하거나 대체하지 않습니다. 하지만 오브젝트에 대한 유효 데이터 보존 기간은 변경될 수 있습니다. 이 매개 변수MIN_DATA_RETENTION_TIME_IN_DAYS가 계정 수준에서 설정되면 오브젝트에 대한 데이터 보존 기간은 MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS)에 의해 결정됩니다.

오브젝트의 값을 0으로 하여 DATA_RETENTION_TIME_IN_DAYS 를 지정하면 개별 데이터베이스, 스키마 및 테이블에 대해 Time Travel을 비활성화할 수 있습니다. 하지만 DATA_RETENTION_TIME_IN_DAYS가 0의 값으로 설정되고 MIN_DATA_RETENTION_TIME_IN_DAYS가 계정 수준에서 설정되고 0보다 크면 더 높은 값 설정이 우선합니다.

주의

오브젝트에 대한 DATA_RETENTION_TIME_IN_DAYS 를 0으로 설정하기 전, 특히 삭제된 오브젝트 복구와 관련되므로 오브젝트에 대한 Time Travel을 비활성화할 것인지 고려해야 합니다. 보존 기간이 없는 오브젝트를 삭제하면 해당 오브젝트를 복원할 수 없습니다.

일반적으로는 모든 오브젝트에서 (최소한) 1일의 값을 유지하는 것이 좋습니다.

Time Travel 보존 기간이 0으로 설정된 경우 수정되거나 삭제된 모든 데이터는 백그라운드 프로세스에 의해 Fail-safe로 이동되거나(영구 테이블의 경우) 삭제됩니다(일시적 테이블의 경우). 완료하는 데 시간이 조금 걸릴 수 있습니다. 이 시간 동안 테이블 저장 메트릭의 TIME_TRAVEL_BYTES는 Time Travel 보존 기간이 0일인 경우에도 0이 아닌 값을 포함할 수 있습니다.

오브젝트에 데이터 보존 기간 지정하기

기본적으로 최대 보존 기간은 1일(즉, 24시간 기간 1개)입니다. Snowflake Enterprise Edition 이상의 경우 계정의 기본값을 최대 90일까지의 값으로 설정할 수 있습니다.

  • 테이블, 스키마 또는 데이터베이스를 생성할 때 계정 기본값은 명령에서 DATA_RETENTION_TIME_IN_DAYS 매개 변수를 사용하여 재정의할 수 있습니다.

  • 데이터베이스 또는 스키마에 대한 보존 기간이 지정되면 해당 데이터베이스/스키마에서 생성된 모든 오브젝트에 해당 기간이 기본적으로 상속됩니다.

MIN_DATA_RETENTION_TIME_IN_DAYS 매개 변수를 사용하여 계정에 대한 최소 보존 기간을 설정할 수 있습니다. 이 매개 변수가 계정 수준에서 설정되면 오브젝트에 대한 데이터 보존 기간은 MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS)에 의해 결정됩니다.

오브젝트의 데이터 보존 기간 변경하기

테이블의 데이터 보존 기간을 변경하면 새 보존 기간은 활성 상태의 모든 데이터뿐만 아니라 현재 Time Travel 내의 모든 데이터에도 영향을 줍니다. 그러한 영향은 기간의 증가 또는 감소 여부에 따라 다릅니다.

보존 기간 늘리기:

현재 Time Travel의 데이터를 더 오랜 기간 동안 보존합니다.

예를 들어, 보존 기간이 10일인 테이블이 있고 보존 기간을 20일로 늘리면, 10일 이후에 제거되던 데이터가 이제는 추가로 10일 더 보존된 후에 Fail-safe로 이동하게 됩니다.

10일 이상 지나 이미 Fail-safe로 이동된 데이터에는 이러한 설정이 적용되지 않음에 유의하십시오.

보존 기간 줄이기:

Time Travel에서 데이터가 보존되는 기간을 줄입니다.

  • 보존 기간을 줄인 후에 수정된 활성 데이터에는 새로 더 짧아진 기간이 적용됩니다.

  • 현재 Time Travel에 있는 데이터의 경우:

    • 데이터가 새로 더 짧아진 기간 이내인 경우 Time Travel에 보존됩니다.

    • 데이터가 새로운 기간을 벗어나는 경우, Fail-safe로 이동합니다.

예를 들어, 보존 기간이 10일인 테이블이 있고 보존 기간을 1일로 줄이면, 2일~10일에 해당하는 데이터는 Fail-safe로 이동되어 1일에 해당하는 데이터만 Time Travel을 통해 액세스할 수 있습니다.

그러나 Time Travel에서 Fail-safe로 데이터를 이동하는 프로세스는 백그라운드 프로세스로 수행되므로 변경 사항이 즉시 표시되지는 않습니다. Snowflake는 해당 데이터가 이동될 것이라는 점은 보장하지만, 프로세스 완료 시점을 지정하지는 않습니다. 백그라운드 프로세스가 완료될 때까지 Time Travel을 통해 해당 데이터에 액세스할 수 있습니다.

참고

데이터베이스 또는 스키마의 데이터 보존 기간을 변경하는 경우 변경 사항은 데이터베이스 또는 스키마 내에 포함된 활성 오브젝트에만 영향을 미칩니다. 삭제된 오브젝트(예: 테이블)는 영향을 받지 않습니다.

예를 들어 보존 기간이 90일인 스키마 s1 이 있고 테이블 t1 이 스키마 s1 에 있는 경우 테이블 t1 은 90일의 보존 기간을 상속합니다. 테이블 s1.t1 을 삭제하면 t1 이 90일 동안 Time Travel에 유지됩니다. 나중에 스키마의 데이터 보존 기간을 1일로 변경할 경우 삭제된 테이블 t1 의 보존 기간은 변경되지 않습니다. 테이블 t1 은 90일 동안 Time Travel에 계속 유지됩니다.

삭제된 오브젝트의 보존 기간을 변경하려면 오브젝트 삭제를 취소한 다음 보존 기간을 변경해야 합니다.

오브젝트의 보존 기간을 변경하려면 적절한 ALTER <오브젝트> 명령을 사용하십시오. 예를 들어, 테이블의 보존 기간을 변경하는 방법은 다음과 같습니다.

CREATE TABLE mytable(col1 NUMBER, col2 DATE) DATA_RETENTION_TIME_IN_DAYS=90;

ALTER TABLE mytable SET DATA_RETENTION_TIME_IN_DAYS=30;
Copy

주의

계정 또는 개별 오브젝트의 보존 기간을 변경하면 보존 기간이 명시적으로 설정되지 않은 모든 하위 수준 오브젝트의 값이 변경됩니다. 예:

  • 계정 수준에서 보존 기간을 변경하면, 보존 시간이 명시적으로 설정되지 않은 모든 데이터베이스, 스키마 및 테이블이 새 보존 기간을 자동으로 상속합니다.

  • 스키마 수준에서 보존 기간을 변경하면, 보존 기간이 명시적으로 설정되지 않은 스키마의 모든 테이블이 새 보존 기간을 상속합니다.

변경으로 인해 예상하거나 의도하지 않은 Time Travel 결과가 발생할 수 있으므로, 계정 또는 계정의 오브젝트에 대한 보존 기간을 변경할 때 이 점을 염두에 두십시오. 특히, 계정 수준에서는 보존 기간을 0으로 변경하지 않는 것이 좋습니다.

삭제된 컨테이너 및 오브젝트 보존 상속

현재, 데이터베이스를 삭제할 때 하위 스키마 또는 테이블의 데이터 보존 기간을 데이터베이스의 보존 기간과 다르게 명시적으로 설정했다면 이 데이터 보존 기간은 허용되지 않습니다. 하위 스키마 또는 테이블은 데이터베이스와 같은 기간 동안 보존됩니다.

유사하게, 스키마를 삭제할 때 하위 테이블의 데이터 보존 기간을 스키마의 보존 기간과 다르게 명시적으로 설정했다면 이 데이터 보존 기간 역시 허용되지 않습니다. 하위 테이블은 스키마와 같은 기간 동안 보존됩니다.

이러한 하위 오브젝트(스키마 또는 테이블)의 데이터 보존 기간을 적용하려면 해당 오브젝트를 명시적으로 삭제한 데이터베이스 또는 스키마를 삭제하십시오.

과거 데이터 쿼리하기

테이블에서 DML 연산을 수행할 때, Snowflake는 정의된 기간 동안 이전 버전의 테이블 데이터를 보존합니다. 이를 통해 AT | BEFORE 절을 사용하여 데이터의 이전 버전을 쿼리할 수 있습니다.

이 절을 사용하면 보존 기간 이내에 테이블 내역에서 지정된 시점 또는 직전의 데이터를 쿼리할 수 있습니다. 지정된 시점은 시간 기반(예: 타임스탬프 또는 현재로부터의 시간 오프셋)이거나 완료된 문(예: SELECT 또는 INSERT)의 ID일 수 있습니다.

예:

  • 다음 쿼리는 지정된 타임스탬프 가 나타내는 날짜 및 시간을 기준으로 테이블에서 과거 데이터를 선택합니다.

    SELECT * FROM my_table AT(TIMESTAMP => 'Fri, 01 May 2015 16:20:00 -0700'::timestamp_tz);
    
    Copy
  • 다음 쿼리는 5분 전의 테이블에서 과거 데이터를 선택합니다.

    SELECT * FROM my_table AT(OFFSET => -60*5);
    
    Copy
  • 다음 쿼리는 지정된 문에 의한 변경 사항을 제외하고 테이블에서 그때까지의 과거 데이터를 선택합니다.

    SELECT * FROM my_table BEFORE(STATEMENT => '8e5d0ca9-005e-44e6-b858-a8f5b37c5726');
    
    Copy

참고

AT | BEFORE 절에 지정된 TIMESTAMP, OFFSET 또는 STATEMENT가 테이블의 데이터 보존 기간을 벗어나는 경우 해당 쿼리는 실패하고 오류를 반환합니다.

과거 오브젝트 복제하기

쿼리뿐만 아니라, 테이블, 스키마 또는 데이터베이스에 대한 CREATE 명령에서 CLONE 키워드와 함께 AT | BEFORE 절을 사용하여 오브젝트 내역의 특정 시점에서 오브젝트의 논리적인 복제본을 생성할 수 있습니다.

예:

  • 다음 CREATE TABLE 문은 지정된 타임스탬프로 표시된 날짜 및 시간에 해당하는 테이블의 복제본을 생성합니다.

    CREATE TABLE restored_table CLONE my_table
      AT(TIMESTAMP => 'Sat, 09 May 2015 01:01:00 +0300'::timestamp_tz);
    
    Copy
  • 다음 CREATE SCHEMA 문은 현재 시간으로부터 1시간 전에 있었던 스키마 및 모든 오브젝트의 복제본을 생성합니다.

    CREATE SCHEMA restored_schema CLONE my_schema AT(OFFSET => -3600);
    
    Copy
  • 다음 CREATE DATABASE 문은 지정된 문이 완료되기 전에 있었던 데이터베이스 및 모든 오브젝트의 복제본을 생성합니다.

    CREATE DATABASE restored_db CLONE my_db
      BEFORE(STATEMENT => '8e5d0ca9-005e-44e6-b858-a8f5b37c5726');
    
    Copy

참고

데이터베이스 또는 스키마의 복제 작업이 실패하는 경우는 다음과 같습니다.

  • 지정된 Time Travel 시간이 엔터티의 모든 현재 하위 항목 (예: 테이블)의 보존 시간을 벗어나는 경우.

    Time Travel에서 삭제된 하위 오브젝트에 대한 해결 방법으로 CREATE <object> … CLONE 명령의 IGNORE TABLES WITH INSUFFICIENT DATA RETENTION 매개 변수를 사용하십시오. 자세한 내용은 하위 오브젝트 및 데이터 보존 시간 섹션을 참조하십시오.

  • 지정된 Time Travel 시간이 오브젝트가 생성된 시점 또는 그 이전인 경우.

  • 다음 CREATE DATABASE 문은 4일 전에 존재했던 데이터베이스와 데이터베이스의 모든 오브젝트의 복제본을 생성하고 데이터 보존 기간이 4일 미만인 테이블은 건너뜁니다.

    CREATE DATABASE restored_db CLONE my_db
      AT(TIMESTAMP => DATEADD(days, -4, current_timestamp)::timestamp_tz)
      IGNORE TABLES WITH INSUFFICIENT DATA RETENTION;
    
    Copy

오브젝트 삭제 및 복원하기

오브젝트 삭제하기

테이블, 스키마 또는 데이터베이스를 삭제할 때 시스템에서 즉시 덮어쓰기나 제거가 되지 않습니다. 대신, 오브젝트의 데이터 보존 기간 동안 보존되며 그동안 오브젝트를 복원할 수 있습니다. 삭제한 오브젝트가 Fail-safe 로 이동되고 나면 이를 복원할 수 없습니다.

테이블, 스키마 또는 데이터베이스를 삭제하려면 다음 명령을 사용하십시오.

참고

오브젝트를 삭제한 후에 이름이 같은 오브젝트를 생성해도 해당 오브젝트가 복원되지 않습니다. 대신, 새로운 버전의 오브젝트가 생성됩니다. 삭제한 원래 버전을 여전히 사용할 수 있으며 복원이 가능합니다.

삭제한 오브젝트를 복원하면 원래 위치에 복원됩니다(즉, 새 오브젝트가 생성되지 않음).

삭제된 오브젝트 나열

HISTORY 키워드를 지정하여 다음 명령을 사용하면 삭제된 테이블, 스키마 및 데이터베이스를 나열할 수 있습니다.

예:

SHOW TABLES HISTORY LIKE 'load%' IN mytestdb.myschema;

SHOW SCHEMAS HISTORY IN mytestdb;

SHOW DATABASES HISTORY;
Copy

출력에는 삭제된 모든 오브젝트와 추가 DROPPED_ON 열이 포함되며, 여기에는 오브젝트가 삭제된 날짜 및 시간이 표시됩니다. 오브젝트가 두 번 이상 삭제되면 각 버전의 오브젝트가 출력에서 별도의 행으로 포함됩니다.

참고

오브젝트의 보존 기간이 경과하고 오브젝트가 제거된 후에는 더 이상 SHOW <object_type> HISTORY 출력에 표시되지 않습니다.

오브젝트 복원하기

시스템에서 제거되지 않은 삭제된 오브젝트(즉, SHOW <object_type> HISTORY 출력에 표시되는 오브젝트)는 다음 명령을 사용하여 복원할 수 있습니다.

UNDROP을 호출하면 DROP 명령이 실행되기 전의 가장 최근 상태로 오브젝트가 복원됩니다.

예:

UNDROP TABLE mytable;

UNDROP SCHEMA myschema;

UNDROP DATABASE mydatabase;
Copy

참고

이름이 같은 오브젝트가 이미 있으면 UNDROP이 실패합니다. 기존 오브젝트의 이름을 바꿔야 하며, 그러면 이전 버전의 오브젝트를 복원할 수 있습니다.

액세스 제어 요구 사항 및 이름 확인

오브젝트 삭제와 유사하게, 오브젝트를 복원하려면 사용자에게 오브젝트에 대한 OWNERSHIP 권한이 있어야 합니다. 또한, 사용자는 삭제한 오브젝트를 복원할 데이터베이스 또는 스키마의 오브젝트 유형에 대한 CREATE 권한도 있어야 합니다.

정규화된 오브젝트 이름이 지정된 경우에도, 테이블 및 스키마 복원은 현재 스키마 또는 현재 데이터베이스에서만 지원됩니다.

예: 테이블을 여러 차례 삭제 및 복원하기

다음 예에서 mytestdb.public 스키마에는 loaddata1proddata1 의 두 테이블이 있습니다. loaddata1 테이블은 두 번 삭제된 후 다시 생성되어 다음과 같이 세 가지 테이블 버전이 생성됩니다.

  • 현재 버전

  • 두 번째(즉, 가장 최근) 삭제 버전

  • 첫 번째 삭제 버전

이 예는 테이블의 두 삭제 버전을 복원하는 방법을 보여줍니다.

  1. 우선, 이름이 같은 현재 테이블의 이름이 loaddata3 으로 바뀝니다. 따라서 타임스탬프를 기준으로 삭제된 테이블의 가장 최근 버전을 복원할 수 있습니다.

  2. 그런 다음, 가장 최근에 삭제된 버전의 테이블이 복원됩니다.

  3. 복원된 테이블의 이름이 loaddata2 로 바뀌어 삭제된 테이블의 최초 버전을 복원할 수 있게 됩니다.

  4. 마지막으로, 삭제된 테이블의 최초 버전이 복원됩니다.

SHOW TABLES HISTORY;

+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
| created_on                      | name      | database_name | schema_name | kind  | comment | cluster_by | rows | bytes | owner  | retention_time | dropped_on                      |
|---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------|
| Tue, 17 Mar 2016 17:41:55 -0700 | LOADDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 48   | 16248 | PUBLIC | 1              | [NULL]                          |
| Tue, 17 Mar 2016 17:51:30 -0700 | PRODDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 12   | 4096  | PUBLIC | 1              | [NULL]                          |
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+

DROP TABLE loaddata1;

SHOW TABLES HISTORY;

+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
| created_on                      | name      | database_name | schema_name | kind  | comment | cluster_by | rows | bytes | owner  | retention_time | dropped_on                      |
|---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------|
| Tue, 17 Mar 2016 17:51:30 -0700 | PRODDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 12   | 4096  | PUBLIC | 1              | [NULL]                          |
| Tue, 17 Mar 2016 17:41:55 -0700 | LOADDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 48   | 16248 | PUBLIC | 1              | Fri, 13 May 2016 19:04:46 -0700 |
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+

CREATE TABLE loaddata1 (c1 number);
INSERT INTO loaddata1 VALUES (1111), (2222), (3333), (4444);

DROP TABLE loaddata1;

CREATE TABLE loaddata1 (c1 varchar);

SHOW TABLES HISTORY;

+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
| created_on                      | name      | database_name | schema_name | kind  | comment | cluster_by | rows | bytes | owner  | retention_time | dropped_on                      |
|---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------|
| Fri, 13 May 2016 19:06:01 -0700 | LOADDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 0    | 0     | PUBLIC | 1              | [NULL]                          |
| Tue, 17 Mar 2016 17:51:30 -0700 | PRODDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 12   | 4096  | PUBLIC | 1              | [NULL]                          |
| Fri, 13 May 2016 19:05:32 -0700 | LOADDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 4    | 4096  | PUBLIC | 1              | Fri, 13 May 2016 19:05:51 -0700 |
| Tue, 17 Mar 2016 17:41:55 -0700 | LOADDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 48   | 16248 | PUBLIC | 1              | Fri, 13 May 2016 19:04:46 -0700 |
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+

ALTER TABLE loaddata1 RENAME TO loaddata3;

UNDROP TABLE loaddata1;

SHOW TABLES HISTORY;

+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
| created_on                      | name      | database_name | schema_name | kind  | comment | cluster_by | rows | bytes | owner  | retention_time | dropped_on                      |
|---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------|
| Fri, 13 May 2016 19:05:32 -0700 | LOADDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 4    | 4096  | PUBLIC | 1              | [NULL]                          |
| Fri, 13 May 2016 19:06:01 -0700 | LOADDATA3 | MYTESTDB      | PUBLIC      | TABLE |         |            | 0    | 0     | PUBLIC | 1              | [NULL]                          |
| Tue, 17 Mar 2016 17:51:30 -0700 | PRODDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 12   | 4096  | PUBLIC | 1              | [NULL]                          |
| Tue, 17 Mar 2016 17:41:55 -0700 | LOADDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 48   | 16248 | PUBLIC | 1              | Fri, 13 May 2016 19:04:46 -0700 |
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+

ALTER TABLE loaddata1 RENAME TO loaddata2;

UNDROP TABLE loaddata1;

+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
| created_on                      | name      | database_name | schema_name | kind  | comment | cluster_by | rows | bytes | owner  | retention_time | dropped_on                      |
|---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------|
| Tue, 17 Mar 2016 17:41:55 -0700 | LOADDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 48   | 16248 | PUBLIC | 1              | [NULL]                          |
| Fri, 13 May 2016 19:05:32 -0700 | LOADDATA2 | MYTESTDB      | PUBLIC      | TABLE |         |            | 4    | 4096  | PUBLIC | 1              | [NULL]                          |
| Fri, 13 May 2016 19:06:01 -0700 | LOADDATA3 | MYTESTDB      | PUBLIC      | TABLE |         |            | 0    | 0     | PUBLIC | 1              | [NULL]                          |
| Tue, 17 Mar 2016 17:51:30 -0700 | PRODDATA1 | MYTESTDB      | PUBLIC      | TABLE |         |            | 12   | 4096  | PUBLIC | 1              | [NULL]                          |
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
Copy