Klonen von Datenbanken, die Hybridtabellen enthalten¶
Sie können Datenbanken, die Hybridtabellen enthalten, für zwei Hauptzwecke klonen:
Zur Durchführung von zeitpunktbezogenen Wiederherstellungsvorgängen. Das Klonen funktioniert in Kombination mit Time Travel, das standardmäßig implizite kontinuierliche Backups erstellt. Nachdem Sie eine Datenaufbewahrungsfrist festgelegt haben, können Sie eine Datenbank zu einem beliebigen Zeitpunkt in ihrem Time Travel-Verlauf klonen, um einen gesunden Zustand der Datenbank wiederherzustellen (für den Fall, dass eine Beschädigung aufgetreten ist). Sie müssen keinen Klon erstellen, außer wenn eine Wiederherstellung erforderlich ist.
Zum Hydrieren anderer Umgebungen von einer Quellumgebung aus, z. B. zum Klonen einer Datenbank von der Produktions- in die Entwicklungs- oder Testumgebung.
Bevor Sie versuchen, geklonte Datenbanken zu erstellen, die Hybridtabellen enthalten, sollten Sie die spezifischen Anforderungen und Beschränkungen in den folgenden Abschnitten lesen und verstehen.
Klonen von Hybridtabellen auf Datenbankebene¶
Hybridtabellenklone müssen auf der Datenbankebene erstellt werden. Beispiel:
CREATE DATABASE clone_db1 CLONE db1;
Sie können Hybridtabellen nicht auf Schema- oder Tabellenebene klonen. Wenn Sie versuchen, eine neue Hybridtabelle zu erstellen, indem Sie eine Hybridtabelle oder eine Standardtabelle klonen, schlägt der Befehl mit einem Fehler fehl. Beispiel:
CREATE HYBRID TABLE clone_ht1 CLONE ht1;
391411 (0A000): This feature is not supported for hybrid tables: 'CLONE'.
Wenn Sie versuchen, ein Schema durch Klonen eines anderen Schemas zu erstellen, und das Quellschema eine oder mehrere Hybridtabellen enthält, schlägt der Befehl fehl. Sie können das Schema jedoch klonen, indem Sie den Parameter IGNORE HYBRID TABLES verwenden, um die Hybridtabellen im Schema ausdrücklich zu überspringen. Dieser Parameter funktioniert auch bei der Erstellung von Datenbankklonen. Beispiel:
CREATE OR REPLACE SCHEMA clone_ht_schema CLONE ht_schema IGNORE HYBRID TABLES;
+----------------------------------------------+
| status |
|----------------------------------------------|
| Schema CLONE_HT_SCHEMA successfully created. |
+----------------------------------------------+
Nutzungshinweise für das Klonen von Hybridtabellen¶
Sie können keine Klone erstellen, die Hybridtabellen enthalten, indem Sie die Parameter AT BEFORE, OFFSET oder STATEMENT (Abfrage UUID) verwenden. Sie müssen entweder gar keine Parameter angeben oder AT TIMESTAMP mit einem explizit umgewandelten TIMESTAMP-Wert.
In Übereinstimmung mit der Verhaltensweise für Standardtabellen wird der Verlauf einer geklonten Quelltabelle nicht von dem Klon selbst beibehalten. Geklonte Tabellen verlieren den gesamten bisherigen Verlauf ihrer Quelltabellen, was bedeutet, dass Sie Time Travel nicht verwenden können, um einen früheren Zustand zu sehen, nachdem sie geklont wurden. Time Travel kann verwendet werden, um den neuen Verlauf der Tabellen zu sehen, die nach dem Klonvorgang entstanden ist.
Das Klonen von Hybridtabellen ist ein Vorgang, bei dem nur die Datengröße berücksichtigt wird, während das Klonen von Standardtabellen ein reiner Metadatenvorgang ist. Dieser Unterschied wirkt sich auf die Rechenkosten, die Speicherkosten und die Leistung aus.
Der Vorgang des Klonens der Datenbank selbst verursacht Rechenkosten, wenn die Datenbank Hybridtabellen enthält.
Wenn Hybridtabellen geklont werden, werden die Daten physisch in den Zeilenspeicher kopiert. Daher kann der Klonvorgang bei großen Tabellen sehr lange dauern und die Kosten skalieren linear mit der Größe der Daten.
Die Klonleistung ist vergleichbar mit der einer optimierten direkten Massenladung mit CREATE TABLE AS SELECT. Siehe Laden von Daten.
Die folgenden Beispiele verdeutlichen die wichtigsten Anforderungen für die Erstellung von Klonen von Datenbanken, die Hybridtabellen enthalten. Vollständige Syntaxinformationen und Nutzungshinweise finden Sie unter AT | BEFORE und CREATE <Objekt> … CLONE.
Beispiel: CREATEDATABASE … CLONE¶
Sie können eine Datenbank, die Hybridtabellen enthält, mit dem Befehl CREATE DATABASE. .. CLONE klonen. Der Befehl gibt den Namen der vorhandenen Quelldatenbank und den Namen einer neuen Zieldatenbank an. Die geklonte Datenbank wird ab dem von Ihnen angegebenen AT TIMESTAMP-Wert erstellt, oder ab jetzt, wenn Sie keinen Zeitstempel angeben. Die neue Datenbank ist eine Kopie der Schemata und Tabellen, die zu diesem Zeitpunkt in der Quelle vorhanden waren (unabhängig vom Typ der Standard- oder Hybridtabelle).
Das folgende Beispiel veranschaulicht die erwartete Verhaltensweise, wenn Sie eine Datenbank klonen, die eine oder mehrere Hybridtabellen enthält. Der erste Befehl zeigt die beiden Tabellen an, die im Schema testdata der Datenbank testdb vorhanden sind. Die Tabelle ht1 ist eine Hybridtabelle und die Tabelle st1 ist eine Standardtabelle.
SHOW TERSE TABLES;
+-------------------------------+------+-------+---------------+-------------+
| created_on | name | kind | database_name | schema_name |
|-------------------------------+------+-------+---------------+-------------|
| 2024-11-14 15:59:32.683 -0800 | HT1 | TABLE | TESTDB | TESTDATA |
| 2024-11-14 16:00:01.360 -0800 | ST1 | TABLE | TESTDB | TESTDATA |
+-------------------------------+------+-------+---------------+-------------+
Der folgende Befehl klont diese Datenbank zum Zeitpunkt 16:01 Uhr am 14. November, kurz nachdem die Tabellen erstellt wurden:
CREATE OR REPLACE DATABASE clone_testdb
CLONE testdb AT(TIMESTAMP => '2024-11-14 16:01:00'::TIMESTAMP_LTZ);
+---------------------------------------------+
| status |
|---------------------------------------------|
| Database CLONE_TESTDB successfully created. |
+---------------------------------------------+
Um die geklonten Tabellen zu sehen, verwenden Sie das Schema testdata in der Datenbank clone_testdb:
USE DATABASE clone_testdb;
USE SCHEMA testdata;
Verwenden Sie den Befehl SHOW TABLES, um zu überprüfen, ob die Tabellen erfolgreich geklont wurden:
SHOW TERSE TABLES;
+-------------------------------+------+-------+---------------+-------------+
| created_on | name | kind | database_name | schema_name |
|-------------------------------+------+-------+---------------+-------------|
| 2024-11-14 16:05:14.102 -0800 | HT1 | TABLE | CLONE_TESTDB | TESTDATA |
| 2024-11-14 16:05:14.102 -0800 | ST1 | TABLE | CLONE_TESTDB | TESTDATA |
+-------------------------------+------+-------+---------------+-------------+
Beispiel: Erstellen Sie einen Klon, der eine gelöschte Hybridtabelle wiederherstellt¶
Nehmen wir an, dass ein Benutzer unter Verwendung derselben Datenbank testdb wie im vorherigen Beispiel eine weitere Hybridtabelle namens ht2 erstellt und lädt. Ein paar Minuten später löscht jedoch ein anderer Benutzer versehentlich die Tabelle ht2.
SHOW TERSE TABLES;
+-------------------------------+------+-------+---------------+-------------+
| created_on | name | kind | database_name | schema_name |
|-------------------------------+------+-------+---------------+-------------|
| 2024-11-14 15:59:32.683 -0800 | HT1 | TABLE | TESTDB | TESTDATA |
| 2024-11-14 17:37:24.304 -0800 | HT2 | TABLE | TESTDB | TESTDATA |
| 2024-11-14 16:00:01.360 -0800 | ST1 | TABLE | TESTDB | TESTDATA |
+-------------------------------+------+-------+---------------+-------------+
DROP TABLE HT2;
+---------------------------+
| status |
|---------------------------|
| HT2 successfully dropped. |
+---------------------------+
SHOW TERSE TABLES;
+-------------------------------+------+-------+---------------+-------------+
| created_on | name | kind | database_name | schema_name |
|-------------------------------+------+-------+---------------+-------------|
| 2024-11-14 15:59:32.683 -0800 | HT1 | TABLE | TESTDB | TESTDATA |
| 2024-11-14 16:00:01.360 -0800 | ST1 | TABLE | TESTDB | TESTDATA |
+-------------------------------+------+-------+---------------+-------------+
Sie können die Datenbank in den „gesunden“ Zustand zurückversetzen, in dem sie drei Tabellen enthielt, indem Sie einen Klon von testdb (in diesem Fall restore_testdb) mit einem entsprechenden Zeitstempel erstellen. Der hier angegebene Zeitstempel liegt sehr nahe an dem Zeitpunkt, zu dem die Tabelle erstellt wurde (und bevor sie gelöscht wurde). In der Praxis müssen Sie den Zeitstempel sorgfältig auswählen, je nachdem, wann die Daten in die Tabelle geladen oder andere Aktualisierungen vorgenommen wurden. Das Hauptziel in diesem Beispiel ist es, den Zustand der Tabelle zu erfassen, kurz bevor sie gelöscht wurde.
CREATE OR REPLACE DATABASE restore_testdb
CLONE testdb AT(TIMESTAMP => '2024-11-14 17:38'::TIMESTAMP_LTZ);
+-----------------------------------------------+
| status |
|-----------------------------------------------|
| Database RESTORE_TESTDB successfully created. |
+-----------------------------------------------+
Jetzt können Sie den Inhalt des neuen Klons überprüfen und feststellen, ob die Tabelle ht2 vorhanden ist:
USE DATABASE restore_testdb;
USE SCHEMA testdata;
SHOW TERSE TABLES;
+-------------------------------+------+-------+----------------+-------------+
| created_on | name | kind | database_name | schema_name |
|-------------------------------+------+-------+----------------+-------------|
| 2024-11-14 17:47:58.984 -0800 | HT1 | TABLE | RESTORE_TESTDB | TESTDATA |
| 2024-11-14 17:47:58.984 -0800 | HT2 | TABLE | RESTORE_TESTDB | TESTDATA |
| 2024-11-14 17:47:58.984 -0800 | ST1 | TABLE | RESTORE_TESTDB | TESTDATA |
+-------------------------------+------+-------+----------------+-------------+
Beispiel: Wiederherstellen einer Datenbank zu einem Zeitpunkt vor einer fehlerhaften DML-Operation¶
Eine Datenbank namens ht_sensors hat ein Schema ht_schema, das eine Tabelle namens sensor_data_device2 enthält. Nehmen wir an, dass am 25. November eine Reihe von DELETE-Operationen in dieser Tabelle ausgeführt wurden. Sie können Monitoring Query History in Snowsight aufrufen, um Informationen über diese DELETE-Operationen zu erhalten. (In diesem Beispiel ist der Filter SQL Text auf DELETE eingestellt, um sie zu isolieren.)
Wenn die zweite DELETE-Operation in der Liste versehentlich ausgeführt wurde (Zeilen mit motor_rpm Werten größer als 1504 wurden gelöscht), können Sie die Datenbank klonen, um den Zustand unmittelbar vor dem Commit dieser Operation wiederherzustellen. (Der Einfachheit halber nehmen wir in diesem Beispiel an, dass in diesem Zeitraum keine anderen Änderungen, wie z. B. Aktualisierungen oder Einfügungen, an dieser oder einer anderen Tabelle in der Datenbank vorgenommen wurden)
Bevor Sie die Datenbank klonen, können Sie die Time Travel-Ergebnisse mit einer einfachen Abfrage überprüfen. Auf diese Weise können Sie überprüfen, ob der Klon die erwarteten Daten erfasst, bevor Sie den kostspieligeren Wiederherstellungsvorgang durchführen.
Vergleichen Sie zum Beispiel die Ergebnisse der folgenden beiden Time Travel-Abfragen, die eine Minute auseinander liegen:
SELECT COUNT(*) FROM sensor_data_service2
AT(TIMESTAMP => 'Mon, 25 Nov 2024 14:09:00'::TIMESTAMP_LTZ) WHERE MOTOR_RPM>1504;
+----------+
| COUNT(*) |
|----------|
| 1855 |
+----------+
SELECT COUNT(*) FROM sensor_data_service2
AT(TIMESTAMP => 'Mon, 25 Nov 2024 14:10:00'::TIMESTAMP_LTZ) WHERE MOTOR_RPM>1504;
+----------+
| COUNT(*) |
|----------|
| 0 |
+----------+
Die Ergebnisse bestätigen den erwarteten Unterschied. Jetzt können Sie die Datenbank klonen und dabei denselben Zeitstempel wie bei der ersten Abfrage verwenden:
USE DATABASE ht_sensors;
USE SCHEMA ht_schema;
CREATE OR REPLACE DATABASE restore_ht_sensors
CLONE ht_sensors AT(TIMESTAMP => 'Mon, 25 Nov 2024 14:09:00'::TIMESTAMP_LTZ);
+---------------------------------------------------+
| status |
|---------------------------------------------------|
| Database RESTORE_HT_SENSORS successfully created. |
+---------------------------------------------------+
Überprüfen Sie nun den Status der geklonten Datenbank. Beachten Sie, dass die geklonte Version der Tabelle sensor_data_device2 keine Time Travel-Daten enthält.
USE DATABASE restore_ht_sensors;
USE SCHEMA ht_schema;
SELECT COUNT(*) FROM SENSOR_DATA_DEVICE2 WHERE motor_rpm>1504;
+----------+
| COUNT(*) |
|----------|
| 1855 |
+----------+
Die folgende Time Travel-Abfrage gegen die neue Tabelle schlägt wie erwartet fehl:
SELECT COUNT(*) FROM SENSOR_DATA_DEVICE2 AT(TIMESTAMP => 'Mon, 25 Nov 2024 14:09:00'::TIMESTAMP_LTZ) WHERE MOTOR_RPM>1504;
000707 (02000): Time travel data is not available for table SENSOR_DATA_DEVICE2. The requested time is either
beyond the allowed time travel period or before the object creation time.
Beachten Sie schließlich, dass die letzte DELETE-Operation im Abfrageverlauf möglicherweise erneut angewendet werden muss, da die geklonte Tabelle die Zeilen beibehält, in denen die Spalte timestamp größer als 2024-04-03 07:30:00.000 ist.