Clone bancos de dados que contenham tabelas híbridas¶
Você pode clonar bancos de dados que contêm tabelas híbridas para duas finalidades principais:
Para executar operações de restauração pontual. A clonagem funciona em conjunto com o Time Travel, que, por padrão, cria backups contínuos implícitos. Após definir um período de retenção de dados, você pode clonar um banco de dados em qualquer ponto de seu histórico de Time Travel para restaurar o banco de dados a um estado íntegro (caso tenha ocorrido uma corrupção). Você não precisa criar um clone, exceto quando for necessária uma restauração.
Para hidratar outros ambientes a partir de um ambiente de origem, como clonar um banco de dados da produção para o desenvolvimento ou teste.
Antes de tentar criar qualquer banco de dados clonado que contenha tabelas híbridas, leia e compreenda os requisitos e limitações específicos das seções a seguir.
Clonagem de tabelas híbridas no nível do banco de dados¶
Os clones de tabelas híbridas devem ser criados no nível do banco de dados. Por exemplo:
CREATE DATABASE clone_db1 CLONE db1;
Você não pode clonar tabelas híbridas no nível do esquema ou no nível da tabela. Se você tentar criar uma nova tabela híbrida clonando uma tabela híbrida ou uma tabela padrão, o comando falhará com um erro. Por exemplo:
CREATE HYBRID TABLE clone_ht1 CLONE ht1;
391411 (0A000): This feature is not supported for hybrid tables: 'CLONE'.
Se você tentar criar um esquema clonando outro esquema e o esquema de origem tiver uma ou mais tabelas híbridas, o comando falhará. No entanto, você pode clonar o esquema usando o parâmetro IGNORE HYBRID TABLES para ignorar explicitamente as tabelas híbridas no esquema. Esse parâmetro também funciona para criar clones de banco de dados. Por exemplo:
CREATE OR REPLACE SCHEMA clone_ht_schema CLONE ht_schema IGNORE HYBRID TABLES;
+----------------------------------------------+
| status |
|----------------------------------------------|
| Schema CLONE_HT_SCHEMA successfully created. |
+----------------------------------------------+
Notas de uso para clonagem de tabelas híbridas¶
Você não pode criar clones que incluam tabelas híbridas usando os parâmetros AT BEFORE, OFFSET ou STATEMENT (UUID de consulta). Você deve especificar nenhum parâmetro ou AT TIMESTAMP com um valor de TIMESTAMP explicitamente convertido.
Consistente com o comportamento das tabelas padrão, o histórico de uma tabela de origem que é clonada não é retido pelo próprio clone. As tabelas clonadas perdem todo o histórico anterior de suas tabelas de origem, o que significa que você não pode usar o Time Travel para ver qualquer estado passado depois de elas terem sido clonadas. O Time Travel pode ser usado para ver o novo histórico de tabelas que se acumula após a operação de clonagem.
A clonagem de tabelas híbridas é uma operação de tamanho de dados, enquanto a clonagem de tabelas padrão é uma operação somente de metadados. Essa diferença tem impacto no custo de computação, no custo de armazenamento e no desempenho.
A própria operação de clonagem do banco de dados incorre em custo de computação quando o banco de dados contém tabelas híbridas.
Quando as tabelas híbridas são clonadas, os dados são fisicamente copiados para o armazenamento de linhas; portanto, a operação de clonagem pode levar muito tempo para tabelas grandes, e o custo é escalonado linearmente com o tamanho dos dados.
O desempenho da clonagem é semelhante ao do carregamento direto otimizado em massa com CREATE TABLE AS SELECT. Consulte Carregamento de dados.
Os exemplos a seguir destacam os principais requisitos para a criação de clones de bancos de dados que contêm tabelas híbridas. Para obter informações completas sobre a sintaxe e notas de uso, consulte AT | BEFORE e CREATE <objeto> … CLONE.
Exemplo: CREATE DATABASE … CLONE¶
Você pode clonar um banco de dados que contém tabelas híbridas usando o comando CREATE DATABASE … CLONE. O comando especifica o nome do banco de dados de origem existente e o nome de um novo banco de dados de destino. O banco de dados clonado é criado a partir do valor AT TIMESTAMP que você especificar ou a partir de agora, se não especificar um carimbo de data/hora. O novo banco de dados é uma cópia dos esquemas e tabelas que existiam na fonte naquele momento (independentemente do tipo de tabela padrão ou híbrida).
O exemplo a seguir demonstra o comportamento esperado quando você clona um banco de dados que contém uma ou mais tabelas híbridas. O primeiro comando mostra as duas tabelas que existem no esquema testdata do banco de dados testdb. A tabela ht1 é uma tabela híbrida, e a tabela st1 é uma tabela padrão.
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 |
+-------------------------------+------+-------+---------------+-------------+
O comando a seguir clona esse banco de dados, a partir das 16:01 de 14 de novembro, logo após a criação das tabelas:
CREATE OR REPLACE DATABASE clone_testdb
CLONE testdb AT(TIMESTAMP => '2024-11-14 16:01:00'::TIMESTAMP_LTZ);
+---------------------------------------------+
| status |
|---------------------------------------------|
| Database CLONE_TESTDB successfully created. |
+---------------------------------------------+
Para ver as tabelas clonadas, use o esquema testdata no banco de dados clone_testdb:
USE DATABASE clone_testdb;
USE SCHEMA testdata;
Use o comando SHOW TABLES para verificar se as tabelas foram clonadas com sucesso:
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 |
+-------------------------------+------+-------+---------------+-------------+
Exemplo: crie um clone que restaura uma tabela híbrida descartada¶
Usando o mesmo banco de dados testdb do exemplo anterior, suponha que um usuário crie e carregue outra tabela híbrida chamada ht2. No entanto, alguns minutos mais tarde, outro usuário descarta a tabela ht2 por engano.
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 |
+-------------------------------+------+-------+---------------+-------------+
Você pode restaurar o banco de dados ao seu estado “íntegro”, quando ele continha três tabelas, criando um clone de testdb (chamado restore_testdb neste caso) com um carimbo de data/hora apropriado. O carimbo de data/hora especificado aqui é muito próximo do momento em que a tabela foi criada (e antes de ser descartada). Na prática, você teria que escolher o carimbo de data/hora com cuidado, com base em quando os dados foram carregados na tabela ou quando outras atualizações foram aplicadas. O principal objetivo deste exemplo é capturar o estado da tabela imediatamente antes de ela ser descartada.
CREATE OR REPLACE DATABASE restore_testdb
CLONE testdb AT(TIMESTAMP => '2024-11-14 17:38'::TIMESTAMP_LTZ);
+-----------------------------------------------+
| status |
|-----------------------------------------------|
| Database RESTORE_TESTDB successfully created. |
+-----------------------------------------------+
Agora você pode verificar o conteúdo do novo clone e verificar se a tabela ht2 está lá:
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 |
+-------------------------------+------+-------+----------------+-------------+
Exemplo: restaure um banco de dados em um ponto no tempo antes de uma operação incorreta em DML¶
Um banco de dados chamado ht_sensors tem um esquema ht_schema que contém uma tabela chamada sensor_data_device2. Suponha que uma série de operações DELETE tenha sido executada nessa tabela em 25 de novembro. Você pode acessar Monitoring Query History no Snowsight para ver informações sobre essas operações DELETE. (Neste exemplo, o filtro SQL Text está definido como DELETE para isolá-los)
Se a segunda operação DELETE da lista foi executada por engano (as linhas com valores motor_rpm maiores que 1504 foram excluídas), você pode clonar o banco de dados para restaurá-lo ao seu estado imediatamente anterior ao commit da operação. (Para simplificar este exemplo, vamos supor que nenhuma outra alteração, como atualizações ou inserções, tenha sido aplicada a essa tabela ou a qualquer outra tabela no banco de dados durante esse período)
Antes de clonar o banco de dados, você pode verificar os resultados do Time Travel com uma consulta simples. Dessa forma, você pode verificar se o clone captura os dados esperados antes de executar a operação de restauração, que é mais cara.
Por exemplo, compare os resultados das duas consultas do Time Travel a seguir, que têm um minuto de diferença:
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 |
+----------+
Os resultados confirmam a diferença esperada. Agora você pode clonar o banco de dados, usando o mesmo carimbo de data/hora da primeira consulta:
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. |
+---------------------------------------------------+
Agora, verifique o estado do banco de dados clonado. Lembre-se de que a versão clonada da tabela sensor_data_device2 não tem nenhum dado do Time Travel.
USE DATABASE restore_ht_sensors;
USE SCHEMA ht_schema;
SELECT COUNT(*) FROM SENSOR_DATA_DEVICE2 WHERE motor_rpm>1504;
+----------+
| COUNT(*) |
|----------|
| 1855 |
+----------+
A seguinte consulta do Time Travel na nova tabela falha conforme esperado:
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.
Por fim, observe que a operação DELETE mais recente no histórico de consultas talvez precise ser reaplicada porque a tabela clonada manteve as linhas em que a coluna timestamp era maior que 2024-04-03 07:30:00.000.