Udostępnij za pomocą

COFANIE

Dotyczy:zaznacz pole wyboru oznaczone jako tak Databricks SQL zaznacz pole wyboru oznaczone jako tak Databricks Runtime 12.2 LTS i nowsze

Polecenie UNDROP zapobiega przypadkowemu usunięciu lub skasowaniu zarządzanych lub zewnętrznych relacji (tabel lub zmaterializowanych widoków) znajdujących się w Katalogu Unity. Domyślnie to polecenie cofa (odzyskuje) ostatnio porzuconą relację należącą do użytkownika podanej nazwy relacji. Musi istnieć schemat nadrzędny i katalog. Ta funkcja obsługuje odzyskiwanie porzuconych relacji w ciągu 7-dniowego okresu przechowywania.

Jeśli istnieje wiele porzuconych relacji o tej samej nazwie, możesz użyć SHOW TABLES DROPPED, aby zidentyfikować identyfikator tabeli i użyć UNDROP TABLE WITH ID do odzyskania określonej relacji.

Jeśli istnieje relacja o tej samej nazwie co relacja, którą chcesz odzyskać, użyj polecenia ALTER TABLE RENAME TO, aby zmienić nazwę istniejącej relacji.

Metadane tabeli — takie jak uprawnienia tabeli, specyfikacje kolumn i właściwości — zostaną odzyskane. Ograniczenia klucza podstawowego i obcego nie są odzyskiwane przez polecenie UNDROP. Utwórz je ręcznie przy użyciu ALTER TABLE ADD CONSTRAINT po odzyskaniu tabeli.

Składnia

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

Parametr

  • MATERIALIZED VIEW

    Dotyczy:oznaczone jako zaznaczone tak SQL Databricks oznaczone jako zaznaczone tak Databricks Runtime 16.2 lub nowsze

    Określa, że relacja relation_name do przywrócenia jest zmaterializowanym widokiem.

  • TABLE

    Określa, że relacja relation_name do przywrócenia jest tabelą.

  • nazwa_relacji

    Nazwa tabeli do przywrócenia. Nazwa nie może zawierać specyfikacji czasowej ani specyfikacji opcji. Jeśli relacja lub typ nie jest zgodny z określonym, Azure Databricks zgłasza WRONG_COMMAND_FOR_OBJECT_TYPE lub TABLE_OR_VIEW_NOT_FOUND, gdy nie można go znaleźć.

  • relation_id

    Literał STRING w postaci identyfikatora UUID relacji wyświetlanego przez SHOW TABLES DROPPED.

Uprawnienia

UNDROP wymaga jednego z następujących podstawowych uprawnień:

  • Użytkownik jest właścicielem relacji, ma CREATE TABLE i USE SCHEMA w schemacie oraz USE CATALOG w wykazie.
  • Użytkownik jest właścicielem schematu i ma USE CATALOG w wykazie.
  • Użytkownik jest właścicielem wykazu.
  • Użytkownik jest właścicielem magazynu metadanych.
  • Użytkownik ma MANAGE w tabeli, CREATE TABLE i USE SCHEMA w schemacie oraz USE CATALOG w wykazie.

Jeśli użytkownik odzyskuje inny typ tabeli, mają zastosowanie dodatkowe uprawnienia. Aby na przykład przywrócić usuniętą tabelę zewnętrzną, musisz również mieć CREATE EXTERNAL TABLE w zewnętrznej lokalizacji lub uprawnienia do magazynu, które muszą istnieć.

Po uruchomieniu tego polecenia własność jest domyślna dla poprzedniego właściciela relacji. W razie potrzeby własność można zmienić przy użyciu polecenia ALTER TABLE lub ALTER MATERIALIZED VIEW.

Ograniczenia

Zmaterializowane widoki i tabele strumieniowe można przywrócić tylko wtedy, gdy potok wspierający nadal istnieje. Jeśli potok bazowy został usunięty, zmaterializowanego widoku lub tabeli przesyłania strumieniowego nie będzie można odzyskać.

Nie można przywrócić zmaterializowanego widoku ani tabeli przesyłania strumieniowego utworzonej za pomocą usługi Databricks SQL. Można przywrócić tylko zmaterializowane widoki lub tabele przesyłania strumieniowego utworzone za pomocą potoku ETL. Można przywrócić tylko zmaterializowane widoki według identyfikatora, a nie według nazwy.

Przykłady

-- 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