◀ 5.

Oracle 19cのDROP TABLE｜CASCADE・PURGEと復旧条件

▶

Oracle 19cの表削除と条件付き復旧を扱います。以下のSQLは独立した教材例で、Oracle実行・復旧・性能は未検証です。製品別比較は各製品の条件で読み、連続した本番手順として実行しないでください。

Oracle 19cの表削除と条件付きFlashback Drop、PURGEによる復旧境界を区別する模式図
DROP後の通常ROLLBACKと条件付きFlashback Dropは別です。PURGEなしでも復旧を保証せず、対象・設定・残存・権限・名前と戻らない依存を本文で確認します。実SQLの復旧試験結果ではありません。
この記事の要点
  • DROP TABLE はテーブルを定義・データごと削除する DDL 文
  • Oracle: DROP TABLE 表 [CASCADE CONSTRAINTS] [PURGE];
  • CASCADE CONSTRAINTS: 他表からの参照制約も一緒に削除
  • PURGE: ごみ箱（Recycle Bin）に入れず削除。Flashback Drop不可（バックアップ等の復旧可否とは別）
  • 誤削除時のFLASHBACK TABLE ... TO BEFORE DROPは対象・設定・権限・名前とrecycle binへの残存が条件。PURGEなしだけでは復旧を保証しない

DROP TABLE とは

DROP TABLE はテーブルの定義（メタ情報）と格納データを同時に削除する DDL 文です。データだけ消したい場合は TRUNCATE や DELETE を使います。

構文

製品別の構文比較であり実行用SQLではありません。角括弧や省略記号をそのまま実行しないでください。Oracle 19c、MySQL 8.4、PostgreSQL 18、SQL Server 2016以降のIF EXISTSを区別します。CASCADEの依存削除範囲は製品で異なります。Oracle実行は未検証です。

-- Oracle
DROP TABLE 表名 [CASCADE CONSTRAINTS] [PURGE];

-- MySQL
DROP TABLE [IF EXISTS] 表名 [, 表名 ...];

-- PostgreSQL
DROP TABLE [IF EXISTS] 表名 [, 表名 ...] [CASCADE | RESTRICT];

-- SQL Server
DROP TABLE [IF EXISTS] 表名;

Oracle のオプション

オプション意味
なし対象・設定等の条件を満たす場合にRecycle Binへ移動。残存・権限・名前等を確認してFlashback Dropを検討する
CASCADE CONSTRAINTS他表からの参照整合性制約（外部キー）も削除
PURGERecycle Binに入れず削除。Flashback Drop不可。他の復旧方式の可否は別途確認する

例

保存した独立した破壊的比較例です。普通のDROPでも無条件にごみ箱へ残る保証はありません。CASCADE CONSTRAINTSは参照FKを削除して保護を失わせ、子表を削除する意味ではありません。PURGEはFlashback Drop不可で、バックアップ復旧の全方式が不可能という意味ではありません。4文を連続実行せず、制約解除をエラー突破の手順にしないでください。

-- 普通に削除（ごみ箱に入る）
DROP TABLE emp;

-- 外部キー参照ごと削除
DROP TABLE dept CASCADE CONSTRAINTS;

-- 完全削除（復元不可）
DROP TABLE emp PURGE;

-- 参照と領域を同時に解放
DROP TABLE dept CASCADE CONSTRAINTS PURGE;

誤って削除したテーブルの復元（Oracle）

PURGEを付けないことは復旧の十分条件ではありません。recycle binの対象・設定、領域回収で消えていないこと、必要な権限、同名の現存表や複数の削除履歴を確認します。TO BEFORE DROPはSYSTEM以外のローカル管理表領域にあった対応表が対象です。同名の履歴は最新の対象が選ばれ、別名復旧やシステム生成名による対象識別も必要になります。

Flashback Dropで全依存が元通りになるとは限りません。bitmap join/domain索引とmaterialized view logは一緒に復旧できず、参照整合性制約も復旧しません。戻る索引・トリガ・制約の名前もrecycle bin名となり得ます。表だけでなく定義・依存・権限とアプリの整合性まで確認してください。通常のROLLBACKやTRUNCATEした行の復旧とは別の機能です。

旧教材は読取・復旧・消去を混在させています。SELECTだけが一覧確認で、FLASHBACKは変更処理です。2つのFLASHBACKは独立した選択肢で、対象残存・権限・名前等が条件です。末尾PURGE RECYCLEBINは復旧手順ではなく復旧候補を消す破壊操作なので実行しないでください。復旧成功を保証するコードではありません。

-- ごみ箱の中身を確認
SELECT object_name, original_name, droptime FROM RECYCLEBIN;

-- テーブルを直前の状態に復元
FLASHBACK TABLE emp TO BEFORE DROP;

-- 復元先の名前を変えたい場合
FLASHBACK TABLE emp TO BEFORE DROP RENAME TO emp_restored;

-- ごみ箱を空にする
PURGE RECYCLEBIN;

TRUNCATE / DELETE との違い

次表はOracle 19cの通常表を対象とした比較です。外部表のDROPはDB内のメタデータのみを削除し、外部の実データは削除しません。DROPでごみ箱に残る領域は他のobjectへ直ちに解放されずquotaにも算入されます。所有schemaと権限を確認し、表の所有者でない場合はDROP ANY TABLE等の前提を確認します。権限追加を勧める手順ではありません。

SQL定義データロールバック処理時間・負荷（固定順位ではない）
DROP TABLE削除削除通常のROLLBACK不可（Oracle通常表DDL）依存・待機・対象次第
TRUNCATE TABLE残る全行削除（領域扱いは指定等による）通常のROLLBACK不可（Oracle通常表DDL）行削除より効率的な場合があるが、待機・負荷次第
DELETE FROM ...残る削除未COMMITの同一transaction等の条件下で可能対象行・索引・トリガ・待機次第

注意点

  • Oracle 19cの通常表DDLは構文上正しいDDLの前と成功後に暗黙COMMITがあり、失敗しても先行DMLが戻るとは保証しない。通常のROLLBACK不可。private temporary tableのDROPが既存transactionをCOMMITしない例外は別。製品共通の取消規則ではなく、PostgreSQL等のtransaction内DDLへ一律転用しない
  • 外部キー参照で拒否されたら削除を中止し、業務上必要な整合性保護と依存を確認する。OracleのCASCADE CONSTRAINTSは参照制約を削除し、子表そのものは削除しない。PostgreSQLのCASCADEは依存ビュー等も削除し得る。子表削除や制約解除をエラーの自動対処にしない
  • PURGEはFlashback Dropの候補を残さない。事前バックアップの存在だけでは復元を保証せず、対象範囲・時点・整合性・復元手順の検証が必要
  • Oracleでは依存ビュー・プログラム等は無効化され得る。シノニムは名前解決先を失うため、すべての依存が同じINVALID状態になるとは扱わない。表のobject権限も失われ、同名表を再作成しただけで元の依存・権限が戻るわけではない

関連記事

公式資料と確認範囲

2026-10-27にOracle 19cの公式資料を照合しました。掲載SQLは独立した教材で、Oracleでの実行・復旧・ロック・性能は未検証です。設定変更・権限追加やschema変更を伴う診断手順ではありません。

Post Share
子ページ

子ページはありません

同階層のページ
  1. 表の作成
  2. カラムの追加
  3. カラムの定義変更
  4. カラムの削除
  5. 表の削除
  6. TRUNCATE文
2026-10-26 17:21:20 atom 433

人気ページ

最近更新/作成されたページ