Dela via

UNDROP

Gäller för:markerad ja Databricks SQL markerad ja Databricks Runtime 12.2 LTS och senare

Kommandot UNDROP åtgärdar problemet med hanterade eller externa relationer (tabeller eller materialiserade vyer) som finns i Unity Catalog och tas bort av misstag. Som standardinställning återställer detta kommando den senast borttagna relationen som ägs av användaren av det angivna relationsnamnet. Det överordnade schemat och katalogen måste finnas. Den här funktionen stöder återställning av borttagna relationer inom en kvarhållningsperiod på 7 dagar.

Om det finns flera borttagna relationer med samma namn kan du använda SHOW TABLES DROPPED för att identifiera tabell-ID:t och använda UNDROP TABLE WITH ID för att återställa en specifik relation.

Om det finns en relation med samma namn som den relation som du vill återställa använder du kommandot ALTER TABLE RENAME TO för att ändra namnet på den befintliga relationen.

Tabellmetadata – till exempel tabellbehörigheter, kolumnspecifikation och egenskaper – återställs. Primär- och sekundärnyckelbegränsningar återställs inte av UNDROP kommandot. Återskapa dem manuellt med hjälp av ALTER TABLE ADD CONSTRAINT när tabellen har återställts.

Syntax

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

Parameter

  • MATERIALIZED VIEW

    gäller för:kontrollera markerat ja Databricks SQL-markerad som ja Databricks Runtime 16.2 och senare

    Anger att relationen relation_name, som ska återställas, är en materialiserad vy.

  • TABLE

    Anger att relationen relation_name som ska återställas är en tabell.

  • relationsnamn

    Namnet på tabellen som ska återställas. Namnet får inte innehålla en temporal specifikation eller alternativspecifikation. Om relationen eller typen inte är som specificerat och inte kan hittas genererar Azure Databricks WRONG_COMMAND_FOR_OBJECT_TYPE eller TABLE_OR_VIEW_NOT_FOUND.

  • relation_id

    En STRING literal i form av ett UUID för relationen som visas av SHOW TABLES DROPPED.

Behörigheter

UNDROP kräver någon av följande grundläggande behörigheter:

  • En användare är ägare till relationen, har CREATE TABLE och USE SCHEMA i schemat och USE CATALOG i katalogen.
  • En användare är ägare till schemat och har USE CATALOG i katalogen.
  • En användare är ägare till katalogen.
  • En användare är ägare till metaarkivet.
  • En användare har MANAGE i tabellen, CREATE TABLE och USE SCHEMA i schemat och USE CATALOG i katalogen.

Om en användare återställer en annan typ av tabell gäller ytterligare behörigheter. Om du till exempel vill ta bort en extern tabell måste du också ha CREATE EXTERNAL TABLE på den externa platsen eller lagringsautentiseringsuppgifterna, som måste finnas.

När du har kört det här kommandot återgår ägarskapet till den tidigare relationsägaren. Om det behövs kan ägarskapet ändras med hjälp av kommandot ALTER TABLE eller ALTER MATERIALIZED VIEW.

Begränsningar

Materialiserade vyer och strömmande tabeller kan bara återställas om den underliggande pipelinen fortfarande finns. Om den underliggande pipelinen har tagits bort kommer inte den materialiserade vyn eller strömningstabellen att kunna återställas.

Du kan inte återställa en materialiserad vy eller en strömmande tabell som skapades med Databricks SQL. Endast materialiserade vyer eller strömmande tabeller som skapats med en ETL-pipeline kan återställas. Du kan bara återställa materialiserade vyer efter ID, inte efter namn.

Exempel

-- 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
  • Last updated on