適用対象: Databricks SQL
Databricks Runtime 12.2 LTS 以降
UNDROP
コマンドは、Unity カタログにあるマネージドまたは外部のリレーション (テーブルまたはマテリアライズド ビュー) が誤って削除されたり削除されたりする問題に対処します。
既定では、このコマンドは、指定されたリレーションシップ名のユーザーが所有する最後に削除されたリレーションシップをドロップ解除 (回復) します。
親スキーマとカタログが存在している必要があります。 この機能では、7 日間のリテンション期間内の削除された関係の回復がサポートされます。
同じ名前の複数の削除されたリレーションシップがある場合は、 SHOW TABLES DROPPED を使用してテーブル ID を識別し、 UNDROP TABLE WITH ID
を使用して特定のリレーションシップを回復できます。
回復するリレーションと同じ名前のリレーションがある場合は、 RENAME TO コマンドを使用して既存のリレーションの名前を変更します。
テーブルのメタデータ (テーブルの特権、列の仕様、プロパティなど) は復旧されます。
主キー制約と外部キー制約は、UNDROP
コマンドでは復旧されません。
テーブルが復旧された後、 ALTER TABLE ADD CONSTRAINT を使用して手動で再作成します。
構文
UNDROP { MATERIALIZED VIEW | TABLE } { relation_name | WITH ID relation_id }
パラメーター
MATERIALIZED VIEW
適用対象:
Databricks SQL
Databricks Runtime 16.2 以降
復元する関係
relation_name
が具体化されたビューであることを指定します。TABLE
復元するリレーションシップ
relation_name
がテーブルであることを指定します。-
復元するテーブルまたは具体化されたビューの名前。 名前には、 時仕様またはオプション指定を含めてはなりません。 指定されている関係または型が見つからない場合、Azure Databricks は
WRONG_COMMAND_FOR_OBJECT_TYPE
やTABLE_OR_VIEW_NOT_FOUND
を発生させます。 relation_id
STRING
によって表示されるリレーションの UUID 形式の SHOW TABLES DROPPED リテラル。
アクセス許可
UNDROP
には、次の基本アクセス許可のいずれかが必要です。
- ユーザーはリレーションシップの所有者であり、スキーマに
CREATE TABLE
とUSE SCHEMA
があり、カタログにUSE CATALOG
。 - ユーザーがスキーマの所有者であり、カタログに対して
USE CATALOG
を持っている。 - ユーザーがカタログの所有者である。
- ユーザーがメタストアの所有者である。
- ユーザーはテーブルに
MANAGE
があり、スキーマにはCREATE TABLE
とUSE SCHEMA
があり、カタログにはUSE CATALOG
があります。
ユーザーが別の種類のテーブルを復旧する場合は、追加のアクセス許可が適用されます。
たとえば、外部テーブルの削除を解除するには、外部の場所に対する CREATE EXTERNAL TABLE
や、存在しなければならないストレージの資格情報も必要です。
このコマンドを実行すると、所有権の既定値は以前のリレーションシップ所有者になります。 必要に応じて、 ALTER TABLE または ALTER MATERIALIZED VIEW コマンドを使用して所有権を変更できます。
制限事項
具体化されたビューとストリーミング テーブルは、バッキング パイプラインがまだ存在する場合にのみ復元できます。 バッキング パイプラインが削除されている場合、具体化されたビューまたはストリーミング テーブルは復旧できません。
Databricks SQL で作成された具体化されたビューまたはストリーミング テーブルを復元することはできません。 ETL パイプラインで作成された具体化されたビューまたはストリーミング テーブルのみを復元できます。
例
-- 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
—- Create some MVs
> 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 using the table name
> UNDROP MATERIALIZED VIEW mv1;
OK
-- 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