DESCARTE

Aplica-se a: Databricks SQL Databricks Runtime 12.2 LTS e versões superiores

O comando UNDROP aborda a preocupação de relações gerenciadas ou externas (tabelas ou visualizações materializadas) localizadas no Catálogo Unity serem acidentalmente descartadas ou excluídas. Por padrão, este comando restabelece (recupera) a relação mais recentemente descartada, que seja de propriedade do utilizador do nome de relação fornecido. O esquema principal e o catálogo têm de existir. Este recurso suporta a recuperação de relações perdidas dentro de um período de retenção de 7 dias.

Se houver várias relações descartadas com o mesmo nome, você poderá usar SHOW TABLES DROPPED para identificar a ID da tabela e usáUNDROP TABLE WITH ID para recuperar uma relação específica.

Se houver uma relação com o mesmo nome que a relação que você deseja recuperar, use ALTER TABLE comando RENAME TO para alterar o nome da relação existente.

Os metadados da tabela, como privilégios de tabela, especificação de coluna e propriedades, serão recuperados. As restrições de chave primária e chave estrangeira não são recuperadas pelo comando UNDROP. Recrie-os manualmente usando ALTER TABLE ADD CONSTRAINT depois que a tabela for recuperada.

Sintaxe

UNDROP { MATERIALIZED VIEW | TABLE } { relation_name | WITH ID relation_id }

Parâmetro

• MATERIALIZED VIEW

  Aplica-se a: Databricks SQL Databricks Runtime 16.2 e superior

  Especifica que a relação relation_name a ser restaurada é uma visão materializada.

• TABLE

  Especifica que a relação relation_name a ser restaurada é uma tabela.

• relation_name

  O nome da tabela ou vista materializada a ser restaurada. O nome não deve incluir uma especificação temporal ou uma especificação de opções. Se não for possível encontrar a relação ou o tipo conforme especificado, o Azure Databricks gerará WRONG_COMMAND_FOR_OBJECT_TYPE ou TABLE_OR_VIEW_NOT_FOUND.

• relation_id

  Um STRING literal na forma de um UUID da relação, conforme exibido por SHOW TABLES DROPPED.

Permissões

UNDROP requer uma das seguintes permissões básicas:

• Um usuário é o proprietário da relação, tem CREATE TABLE e USE SCHEMA no esquema e USE CATALOG no catálogo.
• Um usuário é o proprietário do esquema e tem USE CATALOG no catálogo.
• Um usuário é o proprietário do catálogo.
• Um usuário é o proprietário do metastore.
• Um usuário tem MANAGE na mesa, CREATE TABLE e USE SCHEMA no esquema e USE CATALOG no catálogo.

Se um usuário estiver recuperando um tipo diferente de tabela, permissões adicionais serão aplicadas. Por exemplo, para descartar uma tabela externa, você também deve ter CREATE EXTERNAL TABLE no local externo ou credencial de armazenamento, que deve existir.

Depois de executar esse comando, a propriedade assume como padrão o proprietário da relação anterior. Se necessário, a propriedade pode ser alterada usando o comando ALTER TABLE ou ALTER MATERIALIZED VIEW.

Limitações

Visualizações materializadas e tabelas de streaming só podem ser restauradas se o pipeline de suporte ainda existir. Se o pipeline subjacente tiver sido eliminado, a exibição materializada ou a tabela de streaming não será recuperável.

Não é possível restaurar uma exibição materializada ou tabela de streaming que foi criada com o Databricks SQL. Somente visualizações materializadas ou tabelas de streaming criadas com um pipeline ETL podem ser restauradas.

Exemplos

-- UNDROP using the table name
> CREATE TABLE my_catalog.my_schema.my_table (id INT, name STRING);
> DROP TABLE my_catalog.my_schema.my_table;
> UNDROP TABLE my_catalog.my_schema.my_table;
  OK

-- UNDROP WITH ID
– Use SHOW TABLES DROPPED to find dropped tables
> SHOW TABLES DROPPED IN my_schema;
  catalogname schemaname tablename  tableid                              tabletype deletedat                     createdat                     updatedat                     createdby     owner         comment
  ----------- ---------- ---------- ------------------------------------ --------- ----------------------------- ----------------------------- ----------------------------- ------------- ------------- -------
  my_catalog  my_schema  my_table   6ca7be55-8f58-47a7-85ee-7a59082fd17a managed   2023-05-03 AD at 18:17:56 UTC 2023-05-03 AD at 18:17:00 UTC 2023-05-03 AD at 18:17:00 UTC alf@melmak.et alf@melmak.et
  my_catalog  my_schema  my_table   b819f397-c51f-4e60-8acc-05d4d4a7e084 managed   2023-05-04 AD at 10:20:00 UTC 2023-05-04 AD at 08:20:00 UTC 2023-05-04 AD at 08:20:00 UTC alf@melmak.et alf@melmak.et

–- Undrop a specific dropped table.
–- Here, we undrop my_table with table id '6ca7be55-8f58-47a7-85ee-7a59082fd17a'.
-- Note that the table id will be a string surrounded by single quotation marks.
> UNDROP TABLE WITH ID '6ca7be55-8f58-47a7-85ee-7a59082fd17a';
  OK

– Continuing from the example above, Now we want to undrop table with ID 'b819f397-c51f-4e60-8acc-05d4d4a7e084'.
- First, we rename the existing table
> ALTER TABLE my_table RENAME TO my_other_table
  OK
- Then we can undrop table with the name my_table
> UNDROP TABLE WITH ID 'b819f397-c51f-4e60-8acc-05d4d4a7e084'
  OK

—- Create some MVs
> CREATE MATERIALIZED VIEW mv1 AS SELECT * FROM RANGE(5);
> CREATE MATERIALIZED VIEW mv2 AS SELECT * FROM mv1;

—- Drop the MVs
> DROP MATERIALIZED VIEW mv1;
> DROP MATERIALIZED VIEW mv2;

-- UNDROP using the table name
> UNDROP MATERIALIZED VIEW mv1;
  OK

-- UNDROP WITH ID
–- Use SHOW TABLES DROPPED to find the dropped mv2's tableId
—- Assume it is 6ca7be55-8f58-47a7-85ee-7a59082fd17a
-- When undropping, note that the table id will be a string surrounded by single quotation marks.
> UNDROP MATERIALIZED VIEW WITH ID '6ca7be55-8f58-47a7-85ee-7a59082fd17a';
  OK

Artigos relacionados

• ALTER TABLE
• ALTER MATERIALIZED VIEW
• SHOW TABLES DROPPED