ハイブリッドテーブルを含むクローンデータベース¶
ハイブリッドテーブルを含むデータベースをクローンする目的は主に2つあります。
ポイントインタイム・リストア演算子を実行します。クローニングは、 Time Travel、デフォルトで暗黙の連続バックアップを作成します。 データ保持期間を設定した 後、Time Travel 履歴の任意の時点でデータベースをクローンして、データベースを健全な状態に復元することができます（破損が発生したイベント）。リストアが必要な場合を除き、クローンを作成する必要はありません。
本番環境から開発環境またはテスト環境へのデータベースのクローニングなど、ソース環境から他の環境をハイドレートする場合。
ハイブリッド・テーブルを含むクローン・データベースを作成する前に、以下のセクションの具体的な要件と制限事項をよく読んで理解してください。
データベース・レベルでのハイブリッド・テーブルのクローニング¶
ハイブリッド・テーブル・クローンはデータベース・レベルで作成する必要があります。例:
CREATE DATABASE clone_db1 CLONE db1;
スキーマ・レベルまたはテーブル・レベルでのハイブリッド・テーブルのクローニングはできません。ハイブリッド・テーブルまたは標準テーブルをクローニングして新しいハイブリッド・テーブルを作成しようとすると、コマンドはエラーで失敗します。例:
CREATE HYBRID TABLE clone_ht1 CLONE ht1;
391411 (0A000): This feature is not supported for hybrid tables: 'CLONE'.
別のスキーマをクローニングしてスキーマを作成しようとし、ソース・スキーマに1つ以上のハイブリッド・テーブルがある場合、コマンドは失敗します。しかし、 IGNORE HYBRID TABLES パラメーターを使用してスキーマ内のハイブリッド・テーブルを明示的にスキップすることで、スキーマをクローンすることができます。このパラメーターはデータベースのクローンを作成する際にも有効です。例:
CREATE OR REPLACE SCHEMA clone_ht_schema CLONE ht_schema IGNORE HYBRID TABLES;
+----------------------------------------------+
| status |
|----------------------------------------------|
| Schema CLONE_HT_SCHEMA successfully created. |
+----------------------------------------------+
ハイブリッド・テーブルのクローニングの使用上の注意事項¶
AT BEFORE、 OFFSET、 STATEMENT （クエリ UUID） パラメーターを使用して、ハイブリッド・テーブルを含むクローンを作成することはできません。パラメーターをまったく指定しないか、 TIMESTAMP の値を明示的にキャストした AT TIMESTAMP を指定する必要があります。
標準テーブルの動作と同様に、クローニングされたソース・テーブルの履歴はクローン自体には保持されません。クローニングされたテーブルは、クローン元テーブルの過去の履歴をすべて失います。つまり、クローン後にTime Travelを使用して過去の状態を確認することはできません。Time Travelを使用すると、クローニング操作後に発生したテーブルの新しい履歴を確認できます。
ハイブリッド・テーブルのクローニングはデータ・サイズの操作ですが、標準テーブルのクローニングはメタデータのみの操作です。この違いは、コンピュートコスト、ストレージコスト、パフォーマンスに影響します。
データベースにハイブリッドテーブルが含まれる場合、データベースのクローン演算子自体に計算コストが発生します。
ハイブリッドテーブルをクローニングする場合、データは行ストアに物理的にコピーされます。そのため、クローニング演算子は大容量テーブルでは長時間を要し、コストはデータサイズに比例します。
クローニングパフォーマンスは、 CREATE TABLE AS SELECT を用いて最適化された直接バルクロードと同様です。 データのロード をご参照ください。
以下の例では、ハイブリッドテーブルを含むデータベースのクローンを作成するための主な要件を説明します。完全な構文情報と使用上の注意については、 AT | BEFORE と CREATE <オブジェクト> ... CLONE をご参照ください。
例: CREATE DATABASE ... CLONE¶
CREATE DATABASE ... CLONE コマンドを使用すると、ハイブリッド テーブルを含むデータベースをクローンできます。コマンドは、既存のソース・データベースの名前と新しい宛先データベースの名前を指定します。クローンされたデータベースは、指定した AT TIMESTAMP 値の時点、またはタイムスタンプを指定しない場合は現在の時点で作成されます。新しいデータベースは、その時点でソースに存在していたスキーマとテーブルのコピーです（標準またはハイブリッドのテーブルタイプに関係なく）。
次の例は、1つ以上のハイブリッド・テーブルを含むデータベースをクローンした場合の動作を示しています。最初のコマンドは、 testdb データベースの testdata スキーマに存在する2つのテーブルを表示します。 ht1 テーブルはハイブリッド・テーブル、 st1 テーブルはスタンダード・テーブル。
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 |
+-------------------------------+------+-------+---------------+-------------+
以下のコマンドは、テーブルが作成された直後の11月14日16時1分時点で、このデータベースをクローニングします。
CREATE OR REPLACE DATABASE clone_testdb
CLONE testdb AT(TIMESTAMP => '2024-11-14 16:01:00'::TIMESTAMP_LTZ);
+---------------------------------------------+
| status |
|---------------------------------------------|
| Database CLONE_TESTDB successfully created. |
+---------------------------------------------+
クローニングされたテーブルを見るには、 clone_testdb データベースの testdata スキーマを使用します。
USE DATABASE clone_testdb;
USE SCHEMA testdata;
SHOW TABLES コマンドを使用して、テーブルが正常にクローニングされたことを確認します。
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 |
+-------------------------------+------+-------+---------------+-------------+
例：ドロップされたハイブリッド・テーブルをリストアするクローンの作成¶
前の例と同じ testdb データベースを使用して、ユーザーが ht2 という名前の別のハイブリッドテーブルを作成し、ロードしたとします。しかし数分後、別のユーザーが誤って 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 |
+-------------------------------+------+-------+---------------+-------------+
testdb （この場合 restore_testdb という名前） のクローンを適切なタイムスタンプで作成することで、データベースが3つのテーブルを含んでいた「健全な」状態にリストアすることができます。ここで指定されたタイムスタンプは、テーブルが作成された時点（そして削除される前）に非常に近いものです。実際には、データの読み込み中やその他の更新が適用されたタイミングに基づいて、タイムスタンプを慎重に選択する必要があります。この例の主な目的は、削除される直前のテーブルの状態をキャプチャすることです。
CREATE OR REPLACE DATABASE restore_testdb
CLONE testdb AT(TIMESTAMP => '2024-11-14 17:38'::TIMESTAMP_LTZ);
+-----------------------------------------------+
| status |
|-----------------------------------------------|
| Database RESTORE_TESTDB successfully created. |
+-----------------------------------------------+
新しいクローンの中身を確認し、テーブル ht2 がそこにあることを証明できます。
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 |
+-------------------------------+------+-------+----------------+-------------+
例: データベースを、不正な DML 操作が行われる前の時点にリストアします。¶
ht_sensors という名前のデータベースには、 sensor_data_device2 という名前のテーブルを含むスキーマ ht_schema があります。11月25日にこのテーブルで DELETE の一連の操作が実行されたと仮定します。これらの DELETE 操作に関する情報については、 Snowsight の Monitoring Query History をご参照ください。(この例では、 SQL Text フィルターを DELETE にセットし、それらを分離しています)。
リストの2番目の DELETE 操作が誤って実行された場合（motor_rpm の値が1504より大きい行が削除された）、データベースをクローンして、その操作がコミットされる直前の状態に戻すことができます。(この例では簡易性のため、更新や挿入などの他の変更は、この期間中にそのテーブルやデータベース内の他のテーブルには適用されなかったと仮定します)。
データベースをクローニングする前に、簡単なクエリでTime Travelの結果を確認することができます。このようにして、コストのかかるリストア操作を実行する前に、クローンが期待されるデータをキャプチャしていることを確認できます。
例えば、次の2つのTime Travelクエリの結果を1分間隔で比較してみてください。
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 |
+----------+
結果は予想通りの差を示しています。これで、最初のクエリと同じタイムスタンプを使ってデータベースをクローンできます。
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. |
+---------------------------------------------------+
クローンしたデータベースの状態を確認してください。クローニングバージョンのテーブル （sensor_data_device2） には、Time Travelのデータがないことに注意してください。
USE DATABASE restore_ht_sensors;
USE SCHEMA ht_schema;
SELECT COUNT(*) FROM SENSOR_DATA_DEVICE2 WHERE motor_rpm>1504;
+----------+
| COUNT(*) |
|----------|
| 1855 |
+----------+
新しいテーブルに対する以下のTime Travelクエリは予想通り失敗しました。
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.
クローニングされたテーブルには、 timestamp 列が 2024-04-03 07:30:00.000 よりも大きい行が残っているため、クエリ履歴の中で最も新しい DELETE 操作を再適用する必要があるかもしれないことに注意してください。