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.

Bemerkung

Eine Time Travel-Abfrage mit langer Laufzeit verzögert das Verschieben der Daten und Objekte (Tabellen, Schemas und Datenbanken) im Konto in den Fail-safe-Bereich, bis die Abfrage abgeschlossen ist.

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 kann. 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) ausgeführt werden können.

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.

  • Der Kontoparameter MIN_DATA_RETENTION_TIME_IN_DAYS kann von Benutzern mit der Rolle ACCOUNTADMIN festgelegt werden, um die minimale Aufbewahrungsfrist für das Konto festzulegen. Dieser Parameter ändert oder ersetzt nicht den Wert des Parameters DATA_RETENTION_TIME_IN_DAYS. Allerdings kann sich die Änderung die effektive Datenaufbewahrungsdauer ändern. Wenn dieser Parameter auf Kontoebene eingestellt ist, wird die effektive minimale Datenaufbewahrungsfrist für ein Objekt durch MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS) bestimmt.

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.

Time Travel kann für ein Konto nicht deaktiviert werden. Ein Benutzer mit der Rolle ACCOUNTADMIN kann 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.

Ein Benutzer mit der Rolle ACCOUNTADMIN kann auch den Wert für MIN_DATA_RETENTION_TIME_IN_DAYS auf Kontoebene festlegen. Diese Parametereinstellung erzwingt eine minimale Datenaufbewahrungsfrist für Datenbanken, Schemas und Tabellen. Die Einstellung für MIN_DATA_RETENTION_TIME_IN_DAYS ändert oder ersetzt nicht den Wert des Parameters DATA_RETENTION_TIME_IN_DAYS. Es kann jedoch die effektive Datenaufbewahrungsfrist von Objekten ändern. Wenn MIN_DATA_RETENTION_TIME_IN_DAYS auf Kontoebene eingestellt ist, wird die Datenaufbewahrungsfrist für ein Objekt durch MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS) bestimmt.

Der Time Travel-Wert kann für einzelne Datenbanken, Schemas und Tabellen deaktiviert werden, indem für den Parameter DATA_RETENTION_TIME_IN_DAYS des Objekts der Wert 0 angegeben wird. Wenn jedoch DATA_RETENTION_TIME_IN_DAYS auf einen Wert von 0 eingestellt ist und zugleich MIN_DATA_RETENTION_TIME_IN_DAYS auf Kontoebene einen Wert größer als 0 aufweist, hat die Einstellung mit dem höheren Wert Vorrang.

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. Das heißt, sobald ein Objekt ohne Aufbewahrungsfrist gelöscht wurde, können Sie das Objekt nicht mehr wiederherstellen.

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

Wenn die Time Travel-Aufbewahrungsfrist auf 0 gesetzt ist, werden alle geänderten oder gelöschten Daten durch einen Hintergrundprozess entweder in den Fail-safe-Bereich verschoben (bei permanenten Tabellen) oder gelöscht (bei transienten Tabellen). Diese Ausführung kann etwas Zeit in Anspruch nehmen. Während dieser Zeit kann die Spalte TIME_TRAVEL_BYTES in der Tabelle mit den Speichermetriken einen Wert ungleich Null enthalten, auch wenn die Time Travel-Aufbewahrungsfrist 0 Tage beträgt.

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.

Mit dem Parameter MIN_DATA_RETENTION_TIME_IN_DAYS kann für das Konto eine minimale Aufbewahrungsfrist festgelegt werden. Wenn dieser Parameter auf Kontoebene eingestellt ist, wird die Datenaufbewahrungsfrist für ein Objekt durch MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS) bestimmt.

Ä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.

Bemerkung

Wenn Sie die Datenaufbewahrungsfrist für eine Datenbank oder ein Schema ändern, wirkt sich die Änderung nur auf aktive Objekte in der Datenbank bzw. dem Schema aus. Objekte, die gelöscht wurden (z. B. Tabellen), bleiben davon unberührt.

Wenn Sie beispielsweise ein Schema s1 mit einer Aufbewahrungsfrist von 90 Tagen haben und sich die Tabelle t1 im Schema s1 befindet, erbt die Tabelle t1 die Aufbewahrungsfrist von 90 Tagen. Wenn Sie die Tabelle s1.t1 löschen, bleibt t1 für 90 Tage in Time Travel erhalten. Wenn Sie später die Datenaufbewahrungsfrist des Schemas auf 1 Tag ändern, bleibt die Aufbewahrungsfrist für die gelöschte Tabelle t1 unverändert. Die Tabelle t1 wird noch für 90 Tage in Time Travel aufbewahrt.

Um die Aufbewahrungsfrist eines gelöschten Objekts zu ändern, müssen Sie das Objekt wiederherstellen und dann seine Aufbewahrungsfrist ändern.

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;
Copy

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 Konsequenzen für Time Travel hat, die Sie nicht erwartet oder beabsichtigt haben. Insbesondere wird nicht empfohlen, die Aufbewahrungsfrist auf Kontoebene auf 0 zu ändern.

Gelöschte Container und Vererbung der Aufbewahrungsfristen von Objekten

Derzeit wird bei der Löschung einer Datenbank die Datenaufbewahrungsfrist von untergeordneten Schemas oder Tabellen nicht berücksichtigt, falls deren Frist anders als die Aufbewahrungsfrist der Datenbank ist. Die untergeordneten Schemas oder Tabellen werden so lange aufbewahrt wie die Datenbank.

Gleichermaßen wird bei der Löschung eines Schemas die Datenaufbewahrungsfrist von untergeordneten Tabellen nicht berücksichtigt, falls deren Frist anders als die Aufbewahrungsfrist des Schemas ist. Die untergeordneten Tabellen werden so lange aufbewahrt wie das Schema.

Damit die Datenaufbewahrungsfrist für diese untergeordneten Objekte (Schemas oder Tabellen) berücksichtigt wird, müssen Sie diese Objekte explizit löschen, bevor Sie die Datenbank oder das Schema löschen.

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 das Abfragen 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 => 'Fri, 01 May 2015 16:20:00 -0700'::timestamp_tz);
    
    Copy
  • Mit der folgenden Abfrage werden 5 Minuten alte historische Daten einer Tabelle ausgewählt:

    SELECT * FROM my_table AT(OFFSET => -60*5);
    
    Copy
  • 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');
    
    Copy

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 der folgenden CREATE TABLE-Anweisung 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 => 'Sat, 09 May 2015 01:01:00 +0300'::timestamp_tz);
    
    Copy
  • Mit der folgenden CREATE SCHEMA-Anweisung wird ein Klon eines Schemas und aller seiner Objekte erstellt, wie sie 1 Stunde vor dem aktuellen Zeitpunkt existierten:

    CREATE SCHEMA restored_schema CLONE my_schema AT(OFFSET => -3600);
    
    Copy
  • Mit der folgenden CREATE DATABASE-Anweisung 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');
    
    Copy

Bemerkung

Die Klonoperation für eine Datenbank oder ein Schema schlägt in folgenden Fällen fehl:

  • Die angegebene Time Travel-Zeit liegt außerhalb der Aufbewahrungsdauer eines beliebigen aktuellen untergeordneten Objekts (z. B. einer Tabelle) der Entität.

    Als Problemumgehung für untergeordnete Objekte, die aus Time Travel gelöscht wurden, verwenden Sie den Parameter IGNORE TABLES WITH INSUFFICIENT DATA RETENTION des Befehls CREATE <object> … CLONE. Weitere Informationen dazu finden Sie unter Untergeordnete Objekte und Datenaufbewahrungsdauer.

  • Die angegebene Time Travel-Zeit liegt zu oder vor dem Zeitpunkt, an dem das Objekt erstellt wurde.

  • Die folgende CREATE DATABASE-Anweisung erstellt einen Klon einer Datenbank und aller ihrer Objekte, wie sie vor vier Tagen existierten, wobei alle Tabellen übersprungen werden, die eine Datenaufbewahrungsfrist von weniger als vier Tagen haben:

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

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;
Copy

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;
Copy

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