Partager via

UNDROP

S’applique à :coche marquée oui Databricks SQL coché oui Databricks Runtime 12.2 LTS et versions ultérieures

La commande UNDROP répond au problème de suppression ou d’annulation accidentelle des relations managées ou externes (tables ou vues matérialisées) situées dans Unity Catalog. Par défaut, cette commande annule (récupère) la relation la plus récemment supprimée appartenant à l’utilisateur du nom de relation donné. Le schéma parent et le catalogue doivent exister. Cette fonctionnalité permet de récupérer les relations supprimées pendant une période de rétention de 7 jours.

S’il existe plusieurs relations supprimées du même nom, vous pouvez utiliser SHOW TABLES DROPPED pour identifier l’ID de table et l’utiliser UNDROP TABLE WITH ID pour récupérer une relation spécifique.

S’il existe une relation portant le même nom que la relation que vous souhaitez récupérer, utilisez ALTER TABLE la commande RENAME TO pour modifier le nom de la relation existante.

Les métadonnées de table, telles que les privilèges de table, les spécifications de colonne et les propriétés, seront récupérées. Les contraintes de clé primaire et étrangère ne sont pas récupérées par la commande UNDROP. Recréez-les manuellement à l’aide de ALTER TABLE ADD CONSTRAINT une fois la table restaurée.

Syntaxe

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

Paramètre

  • MATERIALIZED VIEW

    S’applique à :case cochée oui Databricks SQL case cochée oui Databricks Runtime 16.2 et versions ultérieures

    Spécifie que la relation relation_name à restaurer est une vue matérialisée.

  • TABLE

    Spécifie que la relation relation_name à restaurer est une table.

  • relation_name

    Nom de la table à restaurer. Le nom ne doit pas inclure de spécification temporelle ou de spécification d’options. Si la relation ou le type tel que spécifié est introuvable, Azure Databricks déclenche WRONG_COMMAND_FOR_OBJECT_TYPE ou TABLE_OR_VIEW_NOT_FOUND.

  • relation_id

    Un littéral STRING sous la forme d’un UUID de la relation comme indiqué par SHOW TABLES DROPPED.

Autorisations

UNDROP requiert l'une des autorisations de base suivantes :

  • Un utilisateur est le propriétaire de la relation, a CREATE TABLE et USE SCHEMA sur le schéma et USE CATALOG sur le catalogue.
  • Un utilisateur est le propriétaire du schéma et a USE CATALOG sur le catalogue.
  • Un utilisateur est le propriétaire du catalogue.
  • Un utilisateur est le propriétaire du metastore.
  • Un utilisateur a MANAGE sur la table, CREATE TABLE et USE SCHEMA sur le schéma et USE CATALOG sur le catalogue.

Si un utilisateur récupère un autre type de table, des autorisations supplémentaires s’appliquent. Par exemple, pour restaurer une table externe, vous devez également disposer de CREATE EXTERNAL TABLE sur l’emplacement externe ou les informations d’identification de stockage, qui doivent exister.

Après avoir exécuté cette commande, la propriété revient par défaut à l'ancien propriétaire de la relation. Si nécessaire, la propriété peut être modifiée à l’aide de la commande ALTER TABLE ou de la commande ALTER MATERIALIZED VIEW.

Limites

Les vues matérialisées et les tables de streaming ne peuvent être restaurées que si le pipeline sous-jacent existe toujours. Si le pipeline sous-jacent a été supprimé, la vue matérialisée ou la table de diffusion en continu ne sera pas récupérable.

Vous ne pouvez pas restaurer une vue matérialisée ou une table de diffusion en continu créée avec Databricks SQL. Seules les vues matérialisées ou les tables de diffusion en continu créées avec un pipeline ETL peuvent être restaurées. Vous pouvez uniquement restaurer des vues matérialisées par ID, et non par nom.

Exemples

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