Condividi tramite

UNDROP

Si applica a:segno di spunta sì Databricks SQL segno di spunta sì Databricks Runtime 12.2 LTS e versioni successive

Il comando UNDROP risolve il problema delle relazioni gestite o esterne (tabelle o viste materializzate) che si trovano nel catalogo Unity che vengono accidentalmente eliminate o cancellate. Per impostazione predefinita, questo comando rimuove (recupera) la relazione eliminata più di recente di proprietà dell'utente del nome di relazione specificato. Lo schema padre e il catalogo devono esistere. Questa funzionalità supporta il recupero delle relazioni eliminate entro un periodo di conservazione di 7 giorni.

Se sono presenti più relazioni eliminate con lo stesso nome, è possibile usare SHOW TABLES DROPPED per identificare l'ID tabella e usare UNDROP TABLE WITH ID per recuperare una relazione specifica.

Se esiste una relazione con lo stesso nome della relazione da ripristinare, usare ALTER TABLE COMANDO RENAME TO per modificare il nome della relazione esistente.

I metadati della tabella, ad esempio privilegi di tabella, specifiche di colonna e proprietà, verranno recuperati. I vincoli di chiave primaria ed esterna non vengono recuperati dal UNDROP comando . Ricrearli manualmente usando ALTER TABLE ADD CONSTRAINT dopo il ripristino della tabella.

Sintassi

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

Parametro

  • MATERIALIZED VIEW

    Si applica a:contrassegnato come sì Databricks SQL contrassegnato come sì Databricks Runtime 16.2 e versioni successive

    Specifica che la relazione relation_name da ripristinare è una vista materializzata.

  • TABLE

    Specifica che la relazione relation_name da ripristinare è una tabella.

  • relation_name

    Nome della tabella da ripristinare. Il nome non deve includere una specifica temporale o una specifica delle opzioni. Se Azure Databricks non può trovare la relazione o il tipo come specificato, genera WRONG_COMMAND_FOR_OBJECT_TYPE o TABLE_OR_VIEW_NOT_FOUND.

  • relation_id

    Valore letterale STRING sotto forma di UUID della relazione come visualizzato da SHOW TABLES DROPPED.

Autorizzazioni

UNDROP richiede una delle autorizzazioni di base seguenti:

  • Un utente è il proprietario della relazione, ha CREATE TABLE e USE SCHEMA sullo schema e USE CATALOG nel catalogo.
  • Un utente è il proprietario dello schema e ha USE CATALOG nel catalogo.
  • Un utente è il proprietario del catalogo.
  • Un utente è il proprietario del metastore.
  • Un utente ha MANAGE nella tabella, CREATE TABLE e USE SCHEMA nello schema e USE CATALOG nel catalogo.

Se un utente sta ripristinando un tipo diverso di tabella, si applicano autorizzazioni aggiuntive. Ad esempio, per rimuovere una tabella esterna, è necessario avere anche CREATE EXTERNAL TABLE nella posizione esterna o nella credenziale di archiviazione, che deve esistere.

Dopo aver eseguito questo comando, per impostazione predefinita la proprietà è il proprietario della relazione precedente. Se necessario, la proprietà può essere modificata usando il comando ALTER TABLE o ALTER MATERIALIZED VIEW.

Limitazioni

Le viste materializzate e le tabelle di streaming possono essere ripristinate solo se la pipeline di supporto esiste ancora. Se la pipeline di backup è stata eliminata, la vista materializzata o la tabella di streaming non sarà recuperabile.

Non è possibile ripristinare una vista materializzata o una tabella di streaming creata con Databricks SQL. È possibile ripristinare solo le viste materializzate o le tabelle di streaming create con una pipeline ETL. È possibile ripristinare solo le viste materializzate in base all'ID, non in base al nome.

Esempi

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