克隆包含混合表的数据库

您可以出于两个主要目的，克隆包含混合表的数据库：

  • 运行时间点恢复操作。克隆与 Time Travel 结合使用，Time Travel 默认创建隐式连续备份。设置数据保留期 后，您可以在 Time Travel 历史记录的任何时间点克隆数据库，将数据库恢复到健康状态（如果出现损坏）。您不需要创建克隆，除非需要恢复。

  • 从源环境中复制其他环境，例如从生产到开发或测试环境中克隆数据库。

在尝试创建包含混合表的任何克隆数据库之前，请务必阅读并理解以下各部分中的具体要求和限制。

在数据库级别克隆混合表

必须在数据库级别创建混合表克隆。例如：

CREATE DATABASE clone_db1 CLONE db1;
Copy

您不能在架构级别或表级别克隆混合表。如果您尝试通过克隆混合表或标准表来创建新的混合表，则命令会失败并出现错误。例如：

CREATE HYBRID TABLE clone_ht1 CLONE ht1;
Copy
391411 (0A000): This feature is not supported for hybrid tables: 'CLONE'.

如果您尝试通过克隆其他架构来创建架构，并且源架构具有一个或多个混合表，则命令会失败。但是，您可以使用 IGNORE HYBRID TABLES 参数来克隆架构，以显式跳过架构中的混合表。此参数也适用于创建数据库克隆。例如：

CREATE OR REPLACE SCHEMA clone_ht_schema CLONE ht_schema IGNORE HYBRID TABLES;
Copy
+----------------------------------------------+
| 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 <object> ... CLONE。

示例：CREATE DATABASE ...CLONE

您可以使用 CREATE DATABASE ...CLONE 命令克隆包含混合表的数据库。该命令指定现有源数据库的名称和新目标数据库的名称。克隆的数据库按您指定的 AT TIMESTAMP 值创建，如果未指定时间戳，则按现在创建。新数据库是在当时时间点源中存在的架构和表的副本（无论是标准表类型还是混合表类型）。

以下示例演示了在克隆包含一个或多个混合表的数据库时的预期行为。第一个命令显示 testdb 数据库的 testdata 架构中存在的两个表。ht1 表是混合表，st1 表是标准表。

SHOW TERSE TABLES;
Copy
+-------------------------------+------+-------+---------------+-------------+
| 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:01 开始克隆此数据库：

CREATE OR REPLACE DATABASE clone_testdb
  CLONE testdb AT(TIMESTAMP => '2024-11-14 16:01:00'::TIMESTAMP_LTZ);
Copy
+---------------------------------------------+
| status                                      |
|---------------------------------------------|
| Database CLONE_TESTDB successfully created. |
+---------------------------------------------+

要查看克隆的表，请使用 clone_testdb 数据库中的 testdata 架构：

USE DATABASE clone_testdb;
USE SCHEMA testdata;
Copy

使用 SHOW TABLES 命令检查表是否已成功克隆：

SHOW TERSE TABLES;
Copy
+-------------------------------+------+-------+---------------+-------------+
| 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;
Copy
+-------------------------------+------+-------+---------------+-------------+
| 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;
Copy
+---------------------------+
| status                    |
|---------------------------|
| HT2 successfully dropped. |
+---------------------------+

SHOW TERSE TABLES;
Copy
+-------------------------------+------+-------+---------------+-------------+
| 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），将数据库恢复到“健康”状态。此处指定的时间戳非常接近在创建表（和删除表）时的时间点。实际上，您必须根据数据加载到表中的时间或其他更新的应用时间，仔细选择时间戳。本示例中的主要目标是捕获表被删除前的状态。

CREATE OR REPLACE DATABASE restore_testdb
  CLONE testdb AT(TIMESTAMP => '2024-11-14 17:38'::TIMESTAMP_LTZ);
Copy
+-----------------------------------------------+
| status                                        |
|-----------------------------------------------|
| Database RESTORE_TESTDB successfully created. |
+-----------------------------------------------+

现在，您可以检查新克隆的内容并验证表 ht2 是否存在：

USE DATABASE restore_testdb;
USE SCHEMA testdata;
SHOW TERSE TABLES;
Copy
+-------------------------------+------+-------+----------------+-------------+
| 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 操作。您可以前往 Snowsight 中的 Monitoring Query History，查看这些 DELETE 操作的信息。（在本示例中，SQL Text 筛选器设置为 DELETE 以隔离它们。）

查询按 SQL 文本筛选的历史记录，以显示一系列的四个 DELETE 操作。

如果列表中的第二个 DELETE 操作错误运行（包含大于 1504 的 motor_rpm 值的行被删除）,您可以克隆数据库，将其直接恢复到该操作提交前的状态。（为了简单起见，在本示例中，我们假设在此时间段内没有向该表或数据库中的任何其他表应用其他更改，例如更新或插入。）

在克隆数据库之前，您可以通过简单的查询来检查 Time Travel 结果。这样，您就可以在运行成本较高的恢复操作之前验证克隆是否捕获了预期数据。

例如，比较以下两个相隔一分钟的 Time Travel 查询的结果：

SELECT COUNT(*) FROM sensor_data_service2
  AT(TIMESTAMP => 'Mon, 25 Nov 2024 14:09:00'::TIMESTAMP_LTZ) WHERE MOTOR_RPM>1504;
Copy
+----------+
| COUNT(*) |
|----------|
|     1855 |
+----------+

SELECT COUNT(*) FROM sensor_data_service2
  AT(TIMESTAMP => 'Mon, 25 Nov 2024 14:10:00'::TIMESTAMP_LTZ) WHERE MOTOR_RPM>1504;
Copy
+----------+
| 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);
Copy
+---------------------------------------------------+
| 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;
Copy
+----------+
| 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;
Copy
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.

最后，请注意，可能需要重新应用查询历史记录中最近的 DELETE 操作，因为克隆的表保留了 timestamp 列大于 2024-04-03 07:30:00.000 的行。

语言: 中文