Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a:
SQL do Databricks
Databricks Runtime 12.2 LTS e superior
O comando UNDROP aborda a preocupação de relações gerenciadas ou externas (tabelas ou exibições materializadas) localizadas no Catálogo do Unity sendo acidentalmente descartadas ou excluídas.
Por padrão, esse comando reverte (recupera) a relação descartada mais recentemente de propriedade do usuário do nome de relação fornecido.
O esquema pai e o catálogo devem existir. Esse recurso dá suporte à recuperação de relações descartadas 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 usar 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 o comando RENAME TO para alterar o nome da relação existente.
Metadados de tabela – como privilégios de tabela, especificação de coluna e propriedades – serão recuperados.
As restrições de chave primária e 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 VIEWAplica-se a:
Databricks SQL
Databricks Runtime 16.2 e versões superioresEspecifica que a relação
relation_namea ser restaurada é uma exibição materializada.TABLEEspecifica que a relação
relation_namea ser restaurada é uma tabela.-
O nome da tabela a ser restaurada. O nome não deve incluir uma especificação temporal ou especificação de opções. Se a relação ou o tipo especificado e não for encontrado, o Azure Databricks gerá um
WRONG_COMMAND_FOR_OBJECT_TYPEouTABLE_OR_VIEW_NOT_FOUND. relation_idUm literal
STRINGna forma de uma UUID da relação, conforme exibido por SHOW TABLES DROPPED.
Permissões
UNDROP exige uma das seguintes permissões de base:
- Um usuário é o proprietário da relação, possui
CREATE TABLEeUSE SCHEMAno esquema, eUSE CATALOGno catálogo. - Um usuário é o proprietário do esquema e tem
USE CATALOGno catálogo. - Um usuário é o proprietário do catálogo.
- Um usuário é o proprietário do metastore.
- Um usuário tem
MANAGEna tabela,CREATE TABLEeUSE SCHEMAno esquema eUSE CATALOGno catálogo.
Se um usuário estiver recuperando um tipo diferente de tabela, serão aplicadas permissões adicionais.
Por exemplo, para cancelar a remoção de uma tabela externa, você também precisa ter CREATE EXTERNAL TABLE no local externo ou na credencial de armazenamento, que precisa existir.
Depois de executar esse comando, a propriedade reverte para o proprietário anterior da relação. Se necessário, a propriedade pode ser alterada usando o comando ALTER TABLE ou ALTER MATERIALIZED VIEW.
Limitações
Exibições materializadas e tabelas de streaming só poderão ser restauradas se o pipeline de backup ainda existir. Se o pipeline de backup tiver sido excluído, a exibição materializada ou a tabela de streaming não serão recuperáveis.
Você não pode restaurar uma exibição materializada ou uma tabela de streaming que foi criada com o DATAbricks SQL. Somente exibições materializadas ou tabelas de streaming criadas com um pipeline ETL podem ser restauradas. Você só pode restaurar exibições materializadas por ID, não por nome.
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
-- Assume the following commands created MVs in an ETL pipeline
> 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 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