Compreensão e uso do Time Travel¶

Extensões SQL do Time Travel¶

Para oferecer suporte ao Time Travel, as seguintes extensões SQL foram implementadas:

• Cláusula AT | BEFORE que pode ser especificada em instruções SELECT e comandos CREATE … CLONE (imediatamente após o nome do objeto). A cláusula usa um dos parâmetros a seguir para identificar os dados históricos exatos que você deseja acessar:

  • TIMESTAMP

  • OFFSET (diferença de tempo em segundos em relação à hora atual)

  • STATEMENT (identificador da instrução; por exemplo, ID da consulta)

• Comando UNDROP para tabelas, esquemas e bancos de dados.

  

Período de retenção de dados¶

Um componente-chave do Snowflake Time Travel é o período de retenção de dados.

Quando os dados em uma tabela são modificados, incluindo a exclusão de dados ou o descarte de um objeto contendo dados, o Snowflake preserva o estado dos dados antes da atualização. O período de retenção de dados especifica o número de dias para os quais esses dados históricos são preservados e, portanto, as operações do Time Travel (SELECT, CREATE … CLONE, UNDROP) podem ser realizadas nos dados.

O período de retenção padrão é 1 dia (24 horas) e é habilitado automaticamente para todas as contas Snowflake:

• Para o Snowflake Standard Edition, o período de retenção pode ser definido como 0 (ou voltar ao padrão de 1 dia) no nível de conta e objeto (ou seja, bancos de dados, esquemas e tabelas).

• Para o Snowflake Enterprise Edition (e superior):

  • No caso de bancos de dados, esquemas e tabelas transitórios, o período de retenção pode ser ajustado para 0 (ou voltar ao padrão de 1 dia). O mesmo é válido também para tabelas temporárias.

  • No caso de bancos de dados, esquemas e tabelas permanentes, o período de retenção pode ser definido para qualquer valor de 0 até 90 dias.

Quando o período de retenção termina para um objeto, os dados históricos são movidos para o Snowflake Fail-safe:

• Os dados históricos não estão mais disponíveis para consulta.

• Objetos passados não podem mais ser clonados.

• Objetos passados que foram descartados não podem mais ser restaurados.

Para especificar o período de retenção de dados do Time Travel:

• O parâmetro de objeto DATA_RETENTION_TIME_IN_DAYS pode ser usado pelos usuários com a função ACCOUNTADMIN para definir o período de retenção padrão para sua conta.

• O mesmo parâmetro pode ser usado para substituir explicitamente o padrão ao criar um banco de dados, um esquema e uma tabela individual.

• O período de retenção de dados para um banco de dados, esquema ou tabela pode ser alterado a qualquer momento.

• O parâmetro de conta MIN_DATA_RETENTION_TIME_IN_DAYS pode ser definido pelos usuários com a função ACCOUNTADMIN para determinar um período de retenção mínimo para a conta. Esse parâmetro não altera ou substitui o valor do parâmetro DATA_RETENTION_TIME_IN_DAYS. No entanto, isso pode alterar o tempo efetivo de retenção de dados. Quando esse parâmetro é definido no nível da conta, o período mínimo efetivo de retenção de dados para um objeto é determinado por MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS).

Herança da retenção de contêineres e objetos descartados¶

Atualmente, quando um banco de dados é descartado, não é seguido o período de retenção de dados de esquemas ou tabelas filhos, caso tenha sido explicitamente definido para ser diferente da retenção do banco de dados. Os esquemas ou tabelas filhos são retidos pelo mesmo período que o banco de dados.

Da mesma forma, quando um esquema é descartado, não é seguido o período de retenção de dados de tabelas filhas, caso tenha sido explicitamente definido para ser diferente da retenção do esquema. As tabelas filhas são retidas pelo mesmo período que o esquema.

Para respeitar o período de retenção de dados desses objetos filhos (esquemas ou tabelas), descarte-os explicitamente antes de descartar o banco de dados ou esquema.

Descarte de objetos¶

Quando uma tabela, um esquema ou um banco de dados são descartados, eles não são imediatamente substituídos ou removidos do sistema. Em vez disso, são retidos segundo seu período de retenção de dados, durante o qual podem ser restaurados. Quando os objetos descartados forem movidos para o Fail-safe, você não poderá restaurá-los.

Para descartar uma tabela, esquema ou banco de dados, use os comandos a seguir:

• DROP TABLE

• DROP SCHEMA

• DROP DATABASE

Listagem de objetos descartados¶

Tabelas, esquemas e bancos de dados descartados podem ser listados usando-se os comandos a seguir com a palavra-chave HISTORY especificada:

• SHOW TABLES

• SHOW SCHEMAS

• SHOW DATABASES

Por exemplo:

SHOW TABLES HISTORY LIKE 'load%' IN mytestdb.myschema;

SHOW SCHEMAS HISTORY IN mytestdb;

SHOW DATABASES HISTORY;

Copy

A saída inclui todos os objetos descartados e uma coluna DROPPED_ON adicional, que exibe a data e a hora em que o objeto foi descartado. Se um objeto tiver sido descartado mais de uma vez, cada versão do objeto será incluída como uma linha separada na saída.

Restauração de objetos¶

Um objeto descartado que não foi limpo do sistema (ou seja, o objeto é exibido na saída SHOW <tipo_de_objeto> HISTORY) pode ser restaurado usando-se os comandos a seguir:

• UNDROP TABLE

• UNDROP SCHEMA

• UNDROP DATABASE

A chamada de UNDROP restaura o objeto a seu estado mais recente antes de o comando DROP ser emitido.

Por exemplo:

UNDROP TABLE mytable;

UNDROP SCHEMA myschema;

UNDROP DATABASE mydatabase;

Copy

Requisitos de controle de acesso e resolução de nomes¶

Como ocorre com o descarte de um objeto, um usuário precisa ter privilégios OWNERSHIP para um objeto a fim de restaurá-lo. Além disso, o usuário precisará ter privilégios CREATE para o tipo de objeto de banco de dados ou esquema onde o objeto descartado será restaurado.

A restauração de tabelas e esquemas só é permitida no esquema ou banco de dados atual, mesmo que seja especificado um nome de objeto totalmente qualificado.

Exemplo: descarte e restauração de uma tabela várias vezes¶

No exemplo a seguir, o esquema mytestdb.public contém duas tabelas: loaddata1 e proddata1. A tabela loaddata1 é descartada e recriada duas vezes, criando três versões da tabela:

• Versão atual

• Segunda (ou seja, a mais recente) versão descartada

• Primeira versão descartada

O exemplo mostra como restaurar as duas versões descartadas da tabela:

1. Em primeiro lugar, a tabela atual com o mesmo nome é renomeada como loaddata3. Isso permite restaurar a versão mais recente da tabela descartada, com base no carimbo de data/hora.

2. Em seguida, a versão descartada mais recente da tabela é restaurada.

3. A tabela restaurada é renomeada como loaddata2 para permitir a restauração da primeira versão.

4. Por fim, a primeira versão da tabela descartada é restaurada.

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