Verstehen und Verwenden von Time Travel

Snowflake Time Travel ermöglicht den Zugriff auf historische Daten (d. h. Daten, die geändert oder gelöscht wurden) zu jedem Zeitpunkt innerhalb eines definierten Zeitraums. Es dient als leistungsstarkes Tool zur Ausführung der folgenden Aufgaben:

  • Wiederherstellen von datenbezogenen Objekten (Tabellen, Schemas und Datenbanken), die versehentlich oder absichtlich gelöscht wurden.

  • Duplizieren und Sichern von Daten zu wichtigen Zeitpunkten der Vergangenheit.

  • Analyse der Datennutzung/Datenmanipulation über einen spezifizierten Zeitraum.

Unter diesem Thema:

Einführung in Time Travel

Time Travel in Continuous Data Protection lifecycle

Mit Hilfe von Time Travel können Sie die folgenden Aktionen innerhalb eines definierten Zeitraums durchführen:

  • Abfragen von Daten aus der Vergangenheit, die inzwischen aktualisiert oder gelöscht wurden.

  • Erstellen von Klonen von ganzen Tabellen, Schemas und Datenbanken an oder vor bestimmten Zeitpunkten der Vergangenheit.

  • Wiederherstellen von Tabellen, Schemas und Datenbanken, die gelöscht wurden.

Nach Ablauf der festgelegten Zeitspanne werden die Daten in Snowflake Fail-safe verschoben und diese Aktionen können nicht mehr ausgeführt werden.

SQL-Erweiterungen für Time Travel

Zur Unterstützung von Time Travel wurden folgende SQL-Erweiterungen implementiert:

  • AT | BEFORE-Klausel, die in SELECT-Anweisungen und CREATE … CLONE-Befehlen (unmittelbar nach dem Objektnamen) angegeben werden. Die Klausel verwendet einen der folgenden Parameter, um präzise die historischen Daten anzugeben, auf die Sie zugreifen möchten:

    • TIMESTAMP

    • OFFSET (Zeitdifferenz in Sekunden zur aktuellen Zeit)

    • STATEMENT (Bezeichner für Anweisung, z. B. Abfrage-ID)

  • UNDROP-Befehl für Tabellen, Schemas und Datenbanken.

    Time Travel SQL extensions

Datenaufbewahrungsfrist

Eine Schlüsselkomponente von Snowflake Time Travel ist die Datenaufbewahrungsfrist.

Wenn Daten in einer Tabelle geändert werden, einschließlich der Löschung der Daten oder des Objekts, das die Daten enthält, sichert Snowflake erst den Zustand der Daten, bevor die Aktualisierung durchgeführt wird. Die Datenaufbewahrungsfrist gibt die Anzahl der Tage an, für die diese historischen Daten aufbewahrt werden, sodass auf den Daten Time Travel-Operationen (SELECT, CREATE … CLONE, UNDROP) kann für die Daten ausgeführt werden.

Die Standardaufbewahrungsfrist beträgt 1 Tag (24 Stunden) und ist automatisch für alle Snowflake-Konten aktiviert:

  • Für die Snowflake Standard Edition kann die Aufbewahrungsfrist auf Konto- und Objektebene (d. h. Datenbanken, Schemas und Tabellen) auf 0 festgelegt (oder auf den Standardwert von 1 zurückgesetzt) werden.

  • Für Snowflake Enterprise Edition (und höher):

    • Für transiente Datenbanken, Schemas und Tabellen kann die Aufbewahrungsfrist auf 0 festgelegt (oder auf den Standardwert von 1 zurückgesetzt) werden. Gleiches gilt auch für temporäre Tabellen.

    • Für permanente Datenbanken, Schemas und Tabellen kann die Aufbewahrungsfrist auf einen beliebigen Wert zwischen 0 und 90 Tagen festgelegt werden.

Bemerkung

Durch Einstellen der Aufbewahrungsfrist eines Objekts auf 0 Tage wird Time Travel für das Objekt deaktiviert.

Wenn die Aufbewahrungsfrist für ein Objekt endet, werden die historischen Daten in Snowflake Fail-safe verschoben:

  • Historische Daten können nicht mehr abgefragt werden.

  • Bereinigte Objekte können nicht mehr geklont werden.

  • Vergangene Objekte, die fallengelassen wurden, können nicht mehr wiederhergestellt werden.

So legen Sie die Datenaufbewahrungsfrist für Time Travel fest:

  • Der Objektparameter DATA_RETENTION_TIME_IN_DAYS kann von Benutzern mit der Rolle ACCOUNTADMIN verwendet werden, um die Standardaufbewahrungsfrist für Ihr Konto festzulegen.

  • Der gleiche Parameter kann verwendet werden, um den Standard beim Erstellen einer Datenbank, eines Schemas und einer einzelnen Tabelle zu überschreiben.

  • Die Datenaufbewahrungsfrist einer Datenbank, eines Schemas oder einer Tabelle kann jederzeit geändert werden.

Aktivieren und Deaktivieren von Time Travel

Zum Aktivieren von Time Travel sind keine Aktivitäten erforderlich. Time Travel wird automatisch mit der Standardaufbewahrungsfrist von 1 Tag aktiviert.

Möglicherweise möchten Sie jedoch ein Upgrade auf Snowflake Enterprise Edition vornehmen, um längere Datenaufbewahrungsfristen von bis zu 90 Tagen für Datenbanken, Schemas und Tabellen zu konfigurieren. Beachten Sie, dass eine erweiterte Datenaufbewahrung zusätzlichen Speicherplatz erfordert, was sich in Ihren monatlichen Speicherkosten widerspiegelt. Weitere Informationen zu den Speichergebühren finden Sie unter Speicherkosten für Time Travel und Fail-safe.

Der Time Travel-Wert kann zwar nicht für ein Konto, aber für einzelne Datenbanken, Schemas und Tabellen deaktiviert werden. Dazu geben Sie für den Parameter DATA_RETENTION_TIME_IN_DAYS des Objekts den Wert 0 an.

Außerdem können Benutzer mit der Rolle ACCOUNTADMIN für DATA_RETENTION_TIME_IN_DAYS auf Kontoebene 0 festlegen. Dies bedeutet, dass für alle Datenbanken (und anschließend für alle Schemas und Tabellen), die im Konto erstellt wurden, standardmäßig keine Aufbewahrungsfrist gilt. Diese Standardeinstellung kann jedoch jederzeit für jede Datenbank, jedes Schema oder jede Tabelle überschrieben werden.

Achtung

Bevor Sie DATA_RETENTION_TIME_IN_DAYS für ein Objekt auf 0 setzen, prüfen Sie, ob Sie Time Travel für das Objekt deaktivieren möchten, insbesondere, wenn das Objekt wiederhergestellt werden soll, nachdem es gelöscht wurde. Die Möglichkeit, gelöschte Objekte ohne Aufbewahrungsfrist wiederherzustellen, bleibt nur für die Dauer der Sitzung bestehen, in der das Objekt gelöscht wurde. Das heißt, sobald ein Objekt ohne Aufbewahrungsfrist gelöscht wurde, können Sie das Objekt nach Beendigung der Sitzung nicht mehr wiederherstellen.

Im Allgemeinen empfehlen wir, für jedes Objekt einen Wert von (mindestens) 1 Tag beizubehalten.

Angeben der Datenaufbewahrungsfrist für ein Objekt

Standardmäßig beträgt die maximale Aufbewahrungsfrist 1 Tag (d. h. eine 24-Stunden-Periode). Mit Snowflake Enterprise Edition (und höher) kann der Standard für Ihr Konto auf einen beliebigen Wert von bis zu 90 Tagen festgelegt werden:

  • Beim Erstellen einer Tabelle, eines Schemas oder einer Datenbank kann der Standardwert des Kontos mit dem Parameter DATA_RETENTION_TIME_IN_DAYS im Befehl überschrieben werden.

  • Wenn für eine Datenbank oder ein Schema eine Aufbewahrungsfrist angegeben ist, wird die Periode standardmäßig für alle in der Datenbank bzw. im Schema angelegten Objekte vererbt.

Ändern der Datenaufbewahrungsfrist für ein Objekt

Wenn Sie die Datenaufbewahrungsfrist einer Tabelle ändern, wirkt sich die neue Aufbewahrungsfrist auf alle aktiven Daten sowie auf alle Daten aus, die sich derzeit in Time Travel befinden. Die Auswirkung hängt davon ab, ob Sie die Frist verlängern oder verkürzen:

Verlängerung der Aufbewahrungsfrist

Wenn Sie die Aufbewahrungsfrist verlängern, werden die aktuell in Time Travel enthaltenen Daten für einen längeren Zeitraum aufbewahrt.

Wenn Sie beispielsweise eine Tabelle mit einer Aufbewahrungsfrist von 10 Tagen haben und die Aufbewahrungsfrist auf 20 Tage erhöhen, werden Daten, die nach 10 Tagen entfernt worden wären, jetzt für weitere 10 Tage aufbewahrt, bevor sie in Fail-safe verschoben werden.

Beachten Sie, dass dies nicht für Daten gilt, die älter als 10 Tage sind und bereits in Fail-safe verschoben wurden.

Verkürzen der Aufbewahrungsfrist

Verkürzt die Aufbewahrungsfrist von Daten in Time Travel:

  • Für aktive Daten, die nach Verkürzung der Aufbewahrungsfrist geändert wurden, gilt die neue kürzere Frist.

  • Für Daten, die sich derzeit in Time Travel befinden, gilt Folgendes:

    • Wenn sich die Daten noch innerhalb des neuen kürzeren Zeitraums befinden, verbleiben sie in Time Travel.

    • Wenn sich die Daten außerhalb des neuen Zeitraums befinden, werden sie in die Fail-safe verschoben.

Wenn Sie beispielsweise eine Tabelle mit einer Aufbewahrungsfrist von 10 Tagen haben und die Aufbewahrungsfrist auf 1 Tag verkürzen, werden Daten der Tage 2–10 in Fail-safe verschoben, sodass nur Daten von Tag 1 für Time Travel zugänglich sind.

Der Prozess des Verschiebens der Daten von Time Travel in Fail-safe wird jedoch von einem Hintergrundprozess ausgeführt, sodass die Änderung nicht sofort sichtbar ist. Snowflake garantiert, dass die Daten verschoben werden, gibt jedoch nicht an, wann der Vorgang abgeschlossen sein wird. Bis zum Abschluss des Hintergrundprozesses sind die Daten weiterhin über Time Travel zugänglich.

Verwenden Sie den entsprechenden ALTER <Objekt>-Befehl, um die Aufbewahrungsfrist für ein Objekt zu ändern. So ändern Sie beispielsweise die Aufbewahrungsfrist für eine Tabelle:

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

ALTER TABLE mytable SET DATA_RETENTION_TIME_IN_DAYS=30;

Achtung

Wenn Sie die Aufbewahrungsfrist für Ihr Konto oder einzelne Objekte ändern, wird der Wert für alle untergeordneten Objekte geändert, für die keine explizite Aufbewahrungsfrist festgelegt wurde. Beispiel:

  • Wenn Sie die Aufbewahrungsfrist auf Kontoebene ändern, erben alle Datenbanken, Schemas und Tabellen, die keine explizite Aufbewahrungsfrist haben, automatisch die neue Aufbewahrungsfrist.

  • Wenn Sie die Aufbewahrungsfrist auf Schemaebene ändern, erben alle Tabellen im Schema, die keine explizite Aufbewahrungsfrist haben, automatisch die neue Aufbewahrungsfrist.

Beachten Sie dies, wenn Sie die Aufbewahrungsfrist für Ihr Konto oder für Objekte in Ihrem Konto ändern, da die Änderung möglicherweise Time Travel-Konsequenzen hat, die Sie nicht erwartet oder beabsichtigt haben. Insbesondere wird nicht empfohlen, die Aufbewahrungsfrist auf Kontoebene auf 0 zu ändern.

Abfragen von historischen Daten

Wenn DML-Operationen auf einer Tabelle durchgeführt werden, bewahrt Snowflake frühere Versionen der Tabellendaten für einen definierten Zeitraum auf. Dadurch wird ermöglicht, frühere Versionen der Daten mit der AT | BEFORE-Klausel abzufragen.

Diese Klausel unterstützt die Abfrage von Daten, die entweder genau an oder unmittelbar vor einem bestimmten Zeitpunkt in der Historie der Tabelle innerhalb der Aufbewahrungsfrist liegen. Der angegebene Zeitpunkt kann zeitbasiert sein (z. B. ein Zeitstempel oder Zeitversatz von der Gegenwart), oder er kann die ID einer abgeschlossenen Anweisung sein (z. B. SELECT oder INSERT).

Beispiel:

  • Die folgende Abfrage wählt historische Daten aus einer Tabelle ab dem Datum und der Uhrzeit aus, die durch den angegebenen Zeitstempel repräsentiert werden:

    SELECT * FROM my_table AT(TIMESTAMP => 'Mon, 01 May 2015 16:20:00 -0700'::timestamp);
    
  • Mit der folgenden Abfrage werden 5 Minuten alte historische Daten einer Tabelle ausgewählt:

    SELECT * FROM my_table AT(OFFSET => -60*5);
    
  • Mit der folgenden Abfrage werden alle historische Daten einer Tabelle ausgewählt, mit Ausnahme der durch die angegebene Anweisung vorgenommenen Änderungen:

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

Bemerkung

Wenn die in der AT | BEFORE-Klausel angegebene Werte für TIMESTAMP, OFFSET oder STATEMENT außerhalb der Datenaufbewahrungsfrist für die Tabelle liegen, schlägt die Abfrage fehl und gibt einen Fehler zurück.

Klonen von historischen Objekten

Zusätzlich zu Abfragen kann die AT | BEFORE-Klausel auch mit dem Schlüsselwort CLONE im Befehl CREATE für eine Tabelle, ein Schema oder eine Datenbank verwendet werden, um ein logisches Duplikat von einem bestimmten Zeitpunkt in der Historie des Objekts zu erstellen.

Beispiel:

  • Mit dem folgenden CREATE TABLE-Befehl wird ein Klon einer Tabelle für das Datum und die Uhrzeit wie im spezifizierten Zeitstempel angegeben erstellt:

    CREATE TABLE restored_table CLONE my_table
      AT(TIMESTAMP => 'Mon, 09 May 2015 01:01:00 +0300'::timestamp);
    
  • Mit dem folgenden CREATE SCHEMA-Befehl wird ein Klon eines Schemas und aller seiner Objekte erstellt, wie sie 1 Stunde vor dem aktuellen Zeit existierten:

    CREATE SCHEMA restored_schema CLONE my_schema AT(OFFSET => -3600);
    
  • Mit dem folgenden CREATE DATABASE-Befehl wird ein Klon einer Datenbank und aller ihrer Objekte erstellt, wie sie vor dem Abschluss der angegebenen Anweisung existierten:

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

Löschen und Wiederherstellen von Objekten

Löschen von Objekten

Wenn eine Tabelle, ein Schema oder eine Datenbank gelöscht wird, wird sie nicht sofort überschrieben oder aus dem System entfernt. Stattdessen wird das Objekt gemäß seiner Datenaufbewahrungsfrist aufbewahrt und kann in dieser Zeit wiederhergestellt werden. Sobald gelöschte Objekte in Fail-safe verschoben wurden, können Sie diese nicht mehr wiederherstellen.

Um eine Tabelle, ein Schema oder eine Datenbank zu löschen, verwenden Sie die folgenden Befehle:

Bemerkung

Nachdem das Objekt gelöscht wurde, führt das Erstellen eines Objekts mit dem gleichen Namen nicht dazu, dass das ursprüngliche Objekt wiederhergestellt wird. Stattdessen wird eine neue Version des Objekts erstellt. Die ursprüngliche, verlorene Version ist aber noch verfügbar und kann wiederhergestellt werden.

Bei der Wiederherstellung eines gelöschten Objekts wird das Objekt am ursprünglichen Speicherort wiederhergestellt (d. h. es wird kein neues Objekt erstellt).

Auflisten von gelöschten Objekten

Gelöschte Tabellen, Schemas und Datenbanken können mithilfe der folgenden Befehlen und mit dem spezifizierten Schlüsselwort HISTORY aufgelistet werden:

Beispiel:

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

SHOW SCHEMAS HISTORY IN mytestdb;

SHOW DATABASES HISTORY;

Die Ausgabe enthält alle gelöschten Objekte und eine zusätzliche Spalte DROPPED_ON, die das Datum und die Uhrzeit enthält, zu der das Objekt gelöscht wurde. Wenn ein Objekt mehr als einmal gelöscht wurde, wird jede Version des Objekts als separate Zeile in die Ausgabe aufgenommen.

Bemerkung

Nachdem die Aufbewahrungsfrist für ein Objekt abgelaufen ist und das Objekt bereinigt wurde, wird es in der Ausgabe SHOW <Objekttyp> HISTORY nicht mehr angezeigt.

Wiederherstellen von Objekten

Ein gelöschtes Objekt, das nicht im System bereinigt wurde (d. h. das Objekt wird in der Ausgabe SHOW <Objekttyp> HISTORY angezeigt), kann mit den folgenden Befehlen wiederhergestellt werden:

Durch Aufrufen von UNDROP wird das Objekt in dem letzten Zustand vor Ausführung des DROP-Befehls wiederhergestellt.

Beispiel:

UNDROP TABLE mytable;

UNDROP SCHEMA myschema;

UNDROP DATABASE mydatabase;

Bemerkung

Wenn mittlerweile ein Objekt mit dem gleichen Namen vorhanden ist, schlägt UNDROP fehl. Sie müssen das vorhandene Objekt umbenennen, damit Sie die vorherige Version des Objekts wiederherstellen können.

Zugriffssteuerungsanforderungen und Namensauflösung

Ähnlich wie beim Löschen eines Objekts muss ein Benutzer OWNERSHIP-Berechtigungen für ein Objekt haben, um es wiederherstellen zu können. Darüber hinaus muss der Benutzer CREATE-Berechtigungen für den Objekttyp der Datenbank oder des Schemas haben, in dem das gelöschte Objekt wiederhergestellt werden soll.

Die Wiederherstellung von Tabellen und Schemas wird nur im aktuellen Schema oder in der aktuellen Datenbank unterstützt, auch wenn ein vollqualifizierter Objektname angegeben ist.

Beispiel: Mehrfaches Löschen und Wiederherstellen einer Tabelle

Im folgenden Beispiel enthält das Schema mytestdb.public die beiden Tabellen loaddata1 und proddata1. Die Tabelle loaddata1 wird zweimal gelöscht und neu erstellt, wodurch drei Versionen der Tabelle erstellt werden:

  • Aktuelle Version

  • Zweite (d. h. aktuelle) gelöschte Version

  • Erste gelöschte Version

Das Beispiel veranschaulicht dann, wie die beiden gelöschten Versionen der Tabelle wiederhergestellt werden können:

  1. Zunächst wird die aktuelle Tabelle mit dem gleichen Namen umbenannt in loaddata3. Dies ermöglicht das Wiederherstellen der neuesten Version der gelöschten Tabelle anhand des Zeitstempels.

  2. Anschließend wird die zuletzt gelöschte Version der Tabelle wiederhergestellt.

  3. Die wiederhergestellte Tabelle wird in loaddata2 umbenannt, um die Wiederherstellung der ersten Version der gelöschten Tabelle zu ermöglichen.

  4. Schließlich wird die erste Version der gelöschten Tabelle wiederhergestellt.

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]                          |
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+