Compreensão e uso do Time Travel¶
O Snowflake Time Travel permite acessar dados históricos (ou seja, dados que foram alterados ou excluídos) em qualquer ponto de um determinado período. Ele serve como uma ferramenta poderosa para a realização das seguintes tarefas:
Restaurar objetos relacionados a dados (tabelas, esquemas e bancos de dados) que podem ter sido excluídos acidental ou intencionalmente.
Duplicar e fazer backup de dados de pontos principais no passado.
Analisar o uso e a manipulação de dados durante períodos especificados.
Neste tópico:
Introdução ao Time Travel¶
![Time Travel no ciclo de vida contínuo da proteção de dados](https://docs.snowflake.com/pt/_images/cdp-lifecycle-tt.png)
Com o Time Travel, você pode realizar as seguintes ações dentro de um período definido:
Consultar dados antigos que foram atualizados ou excluídos desde então.
Clonar tabelas, esquemas e bancos de dados inteiros em ou antes de pontos específicos no passado.
Restaurar tabelas, esquemas e bancos de dados que tenham sido descartados.
Nota
Ao consultar dados históricos em uma tabela ou exibição não materializada, a tabela atual ou o esquema de exibição são usados. Para obter mais informações, consulte Notas de uso para AT | BEFORE.
Depois de transcorrido o período definido, os dados são movidos para o Snowflake Fail-safe e essas ações não podem mais ser executadas.
Nota
Uma consulta de longo prazo do Time Travel atrasará a movimentação de quaisquer dados e objetos (tabelas, esquemas e bancos de dados) da conta para o Fail-safe, até que a consulta seja concluída.
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.
Nota
Um período de retenção de 0 para um objeto efetivamente desabilita o Time Travel para o objeto.
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).
Habilitação e desabilitação do Time Travel¶
Não são necessárias tarefas para habilitar o Time Travel. Ele é habilitado automaticamente com o período de retenção padrão de 1 dia.
No entanto, você pode atualizar para o Snowflake Enterprise Edition para permitir a configuração de períodos mais longos de retenção, com até 90 dias para bancos de dados, esquemas e tabelas. Observe que a retenção de dados estendida requer armazenamento adicional que será refletido em suas taxas mensais de armazenamento. Para obter mais informações sobre as taxas de armazenamento, consulte Custos de armazenamento para Time Travel e Fail-safe.
Não é possível desabilitar o Time Travel para uma conta. Um usuário com a função ACCOUNTADMIN pode definir DATA_RETENTION_TIME_IN_DAYS como 0 no nível da conta, o que significa que todos os bancos de dados (e posteriormente todos os esquemas e tabelas) criados na conta não têm período de retenção por padrão; no entanto, esse padrão pode ser substituído a qualquer momento para qualquer banco de dados, esquema ou tabela.
Um usuário com a função ACCOUNTADMIN também pode definir o valor de MIN_DATA_RETENTION_TIME_IN_DAYS no nível da conta. Essa configuração de parâmetro impõe um período mínimo de retenção de dados para bancos de dados, esquemas e tabelas. A configuração MIN_DATA_RETENTION_TIME_IN_DAYS não altera ou substitui o valor do parâmetro DATA_RETENTION_TIME_IN_DAYS. Ela pode, no entanto, alterar o período efetivo de retenção de dados para objetos. Quando MIN_DATA_RETENTION_TIME_IN_DAYS é definido no nível da conta, o período de retenção de dados para um objeto é determinado por MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS).
O Time Travel pode ser desabilitado para bancos de dados, esquemas e tabelas individuais com a especificação de DATA_RETENTION_TIME_IN_DAYS com um valor de 0 para o objeto. Entretanto, se DATA_RETENTION_TIME_IN_DAYS for definido como um valor de 0 e MIN_DATA_RETENTION_TIME_IN_DAYS for definido no nível da conta e for maior que 0, a configuração de valor mais alto terá precedência.
Atenção
Antes de definir DATA_RETENTION_TIME_IN_DAYS como 0 para qualquer objeto, considere se deseja desabilitar o Time Travel para o objeto, especialmente porque isso afeta a recuperação do objeto se ele for descartado. Quando um objeto sem período de retenção é descartado, você não é capaz de restaurar o objeto.
Como regra geral, recomendamos manter um valor de (pelo menos) 1 dia para qualquer objeto em particular.
Se o período de retenção do Time Travel estiver definido como 0, quaisquer dados modificados ou excluídos serão movidos para Fail-safe (para tabelas permanentes) ou excluídos (para tabelas transitórias) por um processo em segundo plano. Isso pode levar pouco tempo para ser concluído. Durante esse tempo, TIME_TRAVEL_BYTES nas métricas de armazenamento de tabela pode conter um valor diferente de zero, mesmo quando o período de retenção do Time Travel é de 0 dias.
Especificação do período de retenção de dados para um objeto¶
Por padrão, o período máximo de retenção é 1 dia (ou seja, um período de 24 horas). Com o Snowflake Enterprise Edition (e superior), o padrão para sua conta pode ser definido para qualquer valor até 90 dias:
Ao criar uma tabela, esquema ou banco de dados, você pode substituir o padrão de conta usando o parâmetro DATA_RETENTION_TIME_IN_DAYS no comando.
Se for especificado um período de retenção para um banco de dados ou esquema, o período é herdado por padrão para todos os objetos criados no banco de dados/esquema.
É possível definir um período mínimo de retenção na conta usando o parâmetro MIN_DATA_RETENTION_TIME_IN_DAYS. Se esse parâmetro for definido no nível da conta, o período de retenção de dados para um objeto será determinado por MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS).
Alteração do período de retenção de dados para um objeto¶
Se você alterar o período de retenção de dados para uma tabela, o novo período de retenção terá impacto sobre todos os dados que estiverem ativos, bem como sobre quaisquer dados atualmente no Time Travel. O impacto depende de você aumentar ou diminuir o período:
- Aumento da retenção:
Faz com que os dados no Time Travel atualmente sejam retidos por um período mais longo.
Por exemplo, se você tiver uma tabela com um período de retenção de 10 dias e aumentar o período para 20 dias, os dados que teriam sido removidos após 10 dias serão agora retidos por um período adicional de 10 dias antes de passar para o Fail-safe.
Note que isso não se aplica a nenhum dado com mais de 10 dias e que já tenha sido movido para o Fail-safe.
- Diminuição da retenção:
Reduz o tempo em que os dados ficam retidos no Time Travel:
Para dados ativos modificados após o período de retenção ser reduzido, aplica-se o novo período mais curto.
Para dados que estão no Time Travel:
Se os dados ainda estiverem dentro do novo período mais curto, eles permanecerão no Time Travel.
Se os dados estiverem fora do novo período, eles passarão para o Fail-safe.
Por exemplo, se você tiver uma tabela com um período de retenção de 10 dias e diminuir o período para 1 dia, os dados dos dias 2 ao 10 serão movidos para o Fail-safe, e apenas os dados do dia 1 ficarão acessíveis no Time Travel.
No entanto, o processo de mover os dados do Time Travel para o Fail-safe é realizado por um processo em segundo plano, de modo que a alteração não fica imediatamente visível. O Snowflake garante que os dados serão movidos, mas não especifica quando o processo será concluído. Você poderá continuar a acessar os dados pelo Time Travel até a conclusão do processo em segundo plano.
Nota
Se você alterar o período de retenção de dados de um banco de dados ou esquema, a alteração afetará apenas os objetos ativos contidos no banco de dados ou esquema. Quaisquer objetos que foram descartados (por exemplo, tabelas) permanecem inalterados.
Por exemplo, se você tiver um esquema s1
com um período de retenção de 90 dias e a tabela t1
estiver no esquema s1
, a tabela t1
herdará o período de retenção de 90 dias. Se você descartar a tabela s1.t1
, t1
será retido no Time Travel por 90 dias. Posteriormente, se você alterar o período de retenção de dados do esquema para 1 dia, o período de retenção da tabela descartada t1
permanecerá inalterado. A tabela t1
ainda será retida no Time Travel por 90 dias.
Para alterar o período de retenção de um objeto descartado, você deve cancelar o descarte do objeto e, em seguida, alterar seu período de retenção.
Para alterar o período de retenção de um objeto, use o comando ALTER <objeto> apropriado. Por exemplo, para alterar o período de retenção de uma tabela:
CREATE TABLE mytable(col1 NUMBER, col2 DATE) DATA_RETENTION_TIME_IN_DAYS=90;
ALTER TABLE mytable SET DATA_RETENTION_TIME_IN_DAYS=30;
Atenção
A alteração do período de retenção de sua conta ou de objetos individuais altera o valor para todos os objetos de nível inferior que não tenham um período de retenção explicitamente definido. Por exemplo:
Se você alterar o período de retenção no nível da conta, todos os bancos de dados, esquemas e tabelas que não tiverem um período de retenção explícito herdarão automaticamente o novo período de retenção.
Se você alterar o período de retenção no nível do esquema, todas as tabelas do esquema que não tiverem um período de retenção explícito herdarão o novo período de retenção.
Tenha isso em mente ao alterar o período de retenção de sua conta ou de quaisquer objetos em sua conta, pois a alteração poderá ter consequências imprevistas ou indesejadas no Time Travel. Em particular, não recomendamos alterar o período de retenção para 0 no nível da conta.
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.
Consulta de dados históricos¶
Quando qualquer operação DML é realizada em uma tabela, o Snowflake retém versões anteriores dos dados da tabela por um período definido. Isso permite consultar versões anteriores dos dados usando a cláusula AT | BEFORE.
Essa cláusula permite a consulta dos dados no momento exato ou imediatamente antes de um ponto especificado no histórico da tabela dentro do período de retenção. O ponto especificado pode se basear no tempo (por exemplo, um carimbo de data/hora ou uma diferença em relação à hora atual) ou em ID para uma instrução concluída (por exemplo, SELECT ou INSERT).
Por exemplo:
A consulta a seguir seleciona dados históricos de uma tabela a partir da data e hora representadas pelo carimbo de data/hora especificado:
SELECT * FROM my_table AT(TIMESTAMP => 'Fri, 01 May 2015 16:20:00 -0700'::timestamp_tz);
A consulta a seguir seleciona dados históricos de uma tabela de 5 minutos atrás:
SELECT * FROM my_table AT(OFFSET => -60*5);
A consulta a seguir seleciona dados históricos de uma tabela até quaisquer alterações feitas pela instrução especificada (mas sem que estejam incluídas):
SELECT * FROM my_table BEFORE(STATEMENT => '8e5d0ca9-005e-44e6-b858-a8f5b37c5726');
Nota
Se TIMESTAMP, OFFSET, ou STATEMENT especificados na cláusula AT | BEFORE estiverem fora do período de retenção de dados da tabela, a consulta falhará e retornará um erro.
Clonagem de objetos históricos¶
Além de consultas, a cláusula AT | BEFORE pode ser usada com a palavra-chave CLONE no comando CREATE no caso de uma tabela, esquema ou banco de dados a fim de criar uma duplicação lógica do objeto em um ponto especificado no histórico do objeto.
Por exemplo:
A instrução CREATE TABLE a seguir cria um clone de uma tabela a partir da data e hora representadas pelo carimbo de data/hora especificado:
CREATE TABLE restored_table CLONE my_table AT(TIMESTAMP => 'Sat, 09 May 2015 01:01:00 +0300'::timestamp_tz);
A instrução CREATE SCHEMA a seguir cria um clone de um esquema e de todos os seus objetos tal como existiam 1 hora antes da hora atual:
CREATE SCHEMA restored_schema CLONE my_schema AT(OFFSET => -3600);
A instrução CREATE DATABASE a seguir cria um clone de um banco de dados e de todos os seus objetos tal como existiam antes da conclusão da instrução especificada:
CREATE DATABASE restored_db CLONE my_db BEFORE(STATEMENT => '8e5d0ca9-005e-44e6-b858-a8f5b37c5726');
Nota
A operação de clonagem de um banco de dados ou esquema falhará:
Se a hora do Time Travel especificada estiver além do tempo de retenção de qualquer filho atual (por exemplo, uma tabela) da entidade.
Como solução alternativa para objetos filhos que foram eliminados do Time Travel, use o parâmetro IGNORE TABLES WITH INSUFFICIENT DATA RETENTION do comando CREATE <objeto> … CLONE. Para obter mais informações, consulte Objetos filhos e tempo de retenção de dados.
Se a hora do Time Travel especificada for o momento ou antes do momento em que o objeto foi criado.
A instrução CREATE DATABASE a seguir cria um clone de um banco de dados e de todos os seus objetos como existiam há quatro dias, ignorando quaisquer tabelas que tenham um período de retenção de dados inferior a quatro dias:
CREATE DATABASE restored_db CLONE my_db AT(TIMESTAMP => DATEADD(days, -4, current_timestamp)::timestamp_tz) IGNORE TABLES WITH INSUFFICIENT DATA RETENTION;
Descarte e restauração de objetos¶
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:
Nota
Depois de descartar um objeto, a criação de um objeto com o mesmo nome não restaura o objeto. Em vez disso, isso cria uma nova versão do objeto. A versão original descartada ainda estará disponível e poderá ser restaurada.
O restabelecimento de um objeto descartado restaura o objeto (ou seja, não cria um novo objeto).
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:
Por exemplo:
SHOW TABLES HISTORY LIKE 'load%' IN mytestdb.myschema; SHOW SCHEMAS HISTORY IN mytestdb; SHOW DATABASES HISTORY;
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.
Nota
Após o fim do período de retenção de um objeto e o objeto ter sido limpo, ele não é mais exibido na saída SHOW. <tipo_de_objeto> HISTORY.
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:
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;
Nota
Se um objeto com o mesmo nome já existir, UNDROP falhará. Renomeie o objeto existente, o que permitirá restaurar a versão anterior do objeto.
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:
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.Em seguida, a versão descartada mais recente da tabela é restaurada.
A tabela restaurada é renomeada como
loaddata2
para permitir a restauração da primeira versão.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] | +---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+