OracleのDROP USERはアカウントと所有オブジェクトへ破壊的な影響がある操作です。接続中/オブジェクトありのエラーを理由に、セッションの強制切断やCASCADEへ自動的に進みません。対象PDB・利用者・依存・復旧手順を確認してから、承認された管理作業として計画します。

接続と対象・必要な権限を先に確認する

実行にはDROP USERシステム権限が必要です。必ずSYSDBAやDBAロールである必要はありませんが、広い影響を持つ権限なので一般アプリへ与える対処にはしません。SYS/SYSTEM等を削除せず、CDB/PDBと対象アカウントを確認します。

-- Read only. Confirm the intended product, PDB service and authorized account.
SELECT USER, SYS_CONTEXT('USERENV','CON_NAME') AS container_name FROM dual;
SELECT privilege FROM user_sys_privs ORDER BY privilege;

利用者の接続情報、ジョブ、所有オブジェクト、他スキーマの参照や復旧可能性を管理者が調べます。メタデータの一覧だけを取得したことを、データを含む復元確認済みバックアップと呼びません。grepした秘密値やセッション情報を公開せず、本番でのexpdp/復元成功は今回の検査対象外です。

空の検体でも既存接続を正常に終える

以下は新しい隔離PDBで作った、所有物も接続もない検体だけの削除です。本番や他人のアカウントへ置き換えないでください。隔離検体では接続中の別ユーザーの削除がORA-01940になり、クライアントを通常終了してから削除できました。KILL SESSIONを新しい推奨例には使っていません。

-- Destructive: new owned scratch account only, with no owned objects or active session.
DROP USER CWIKI_W20_EMPTY;

ACCOUNT LOCKで新しいログインを止めても、既存接続がなくなる保証はありません。観測した日数が経っただけで未使用/削除安全と決めず、アプリ所有者と停止/更新/切断方針を確認します。

CASCADEは他スキーマの制約にも影響する

所有オブジェクトがある検体をCASCADEなしで削除した際はORA-01922で拒否されました。次の破壊的な例は、使い捨てPDBで作った親スキーマだけを削除する検査用です。通常のエラー回避手順や安全な削除ボタンではありません。

-- Destructive: disposable fixture only. This also removes another schema's referencing FK.
-- No real users, sessions, tablespaces, or application data may be used here.
DROP USER CWIKI_W20_PARENT CASCADE;

この検体では、別スキーマの子表と1行のデータは残りましたが、親の主キーを参照する外部キーは削除され、親表を読む別スキーマのビューはINVALIDになりました。他スキーマの外部キーは「削除されない」とする旧表の説明は誤りです。ビューをコンパイルするだけで失われた表/データを復旧できるわけでもありません。

DROP USER後にROLLBACKしても、検体の削除されたユーザーは戻りませんでした。Recycle BinやFlashbackで必ず戻せるとも扱いません。製品/版やFlashback Data Archive等の制限もあり、全てのオブジェクトを無条件に削除できる保証ではありません。

表領域削除と他製品の操作は別

DROP USERはDROP TABLESPACEやデータファイルの削除とは別です。共有表領域や他の利用者を調べず、旧例のINCLUDING CONTENTS AND DATAFILESへ続けないでください。またMySQL/PostgreSQL/SQL Serverの同名操作でも、アカウント/所有物/接続/依存の扱いが異なり、同等の一括処理ではありません。

旧例と対象版の注意

既存のコードと章は、誤った表のセルを訂正しながら保持します。危険なSYS接続/強制切断/表領域削除の旧例には、すぐ前に個別の注意を置いています。元v2の構文/説明も末尾に残しますが、「強制的」という語は接続や製品制限を無視できる意味ではありません。

比較例の注意：権限/接続/他製品の要点は訂正済みです。SYSDBA必須や強制切断を通常手順とする表ではありません。

この記事の要点

Oracle でユーザー（=スキーマ）を削除するには DROP USER ユーザー名 スキーマオブジェクトを保有するユーザーは CASCADE を付けないと削除できない 実行には DROP USER システム権限 が必要（SYSDBA/DBAロールが必須という意味ではない） 接続中のセッションがあるユーザーは削除不可。利用者と調整し、通常の接続終了を先に計画 製品ごとに意味の異なる関連操作は MySQL DROP USER、PostgreSQL DROP USER / DROP ROLE、SQL Server DROP USER / DROP LOGIN

はじめに

Oracle のユーザーはスキーマと一対一で、ユーザーを削除するとそのスキーマに属する表・ビュー・索引・PL/SQL もまとめて影響を受けます。本番環境では誤操作が致命傷になりやすい操作なので、構文だけでなく前提条件・影響範囲を理解しておきましょう。

基本構文

比較例の注意：日本語と角括弧は構文の説明です。対象と制限を確認せず、CASCADEを付けて実行しません。

DROP USER ユーザー名 [CASCADE];

比較例の注意：CASCADEは所有物と他スキーマの参照制約へ影響します。全条件で成功する指定ではありません。

オプション	意味
なし	スキーマオブジェクトがある場合はエラーで停止
CASCADE	スキーマ内オブジェクトも削除する破壊的指定。接続/Flashback Data Archive等の制限を無視できるものではない

基本例

比較例の注意：公開された検体名の破壊的な例です。既存app_user等へ実行せず、新しい隔離PDBだけで確認します。

-- オブジェクトを持たないユーザーをそのまま削除
DROP USER test_user;

-- 表などを保有しているユーザーは CASCADE 必須
DROP USER app_user CASCADE;

必要な権限

• DROP USER システム権限（DBA ロールに含まれる）
• 自分自身のユーザーは削除不可（接続中のため）
• SYS / SYSTEM のようなシステム予約ユーザーは削除禁止

比較例の注意：SYS/password AS SYSDBAは旧例で、通常の接続方法や公開秘密値として採用しません。DROP USERシステム権限とSYSDBAを同一視しません。

-- DBA ロールで接続して実行
SQL> CONNECT sys/password AS SYSDBA;
SQL> DROP USER app_user CASCADE;

接続中ユーザーの扱い

削除しようとしたユーザーで誰かが接続していると ORA-01940: cannot drop a user that is currently connected が出ます。利用者と正常な接続終了を調整します。次の強制切断を含む旧コードを一括実行しません。

比較例の注意：KILL SESSION IMMEDIATEとCASCADEを含む旧操作列は実行しません。SID/SERIAL#の例を流用せず、通常終了・ロックと既存接続・再接続を分けて計画します。

-- 1) 接続セッションを確認
SELECT sid, serial#, username, status, program
  FROM v$session
 WHERE username = 'APP_USER';

-- 2) セッションを切断（sid, serial# は前の結果から）
ALTER SYSTEM KILL SESSION '123,456' IMMEDIATE;

-- 3) 念のためアカウントをロックしておく
ALTER USER app_user ACCOUNT LOCK;

-- 4) 改めて削除
DROP USER app_user CASCADE;

CASCADE で削除されるもの

比較例の注意：参照側の外部キーが削除されないという誤記をセル内も訂正しました。別スキーマのビュー等も無効化され得ます。

対象	備考
表 / ビュー / マテリアライズドビュー	当該スキーマのもの全て
索引 / シーケンス / シノニム	同上
PL/SQL（プロシージャ / 関数 / パッケージ）	同上
トリガー	同上
表領域上の物理データ	領域は表領域に返却される
外部から参照しているビュー / シノニム	無効化（INVALID）になる
外部から参照している外部キー	参照側の外部キーも自動削除される。別スキーマの子表/データが残っても整合性制約は失われ得る

CASCADEは、削除対象表の主キー/一意キーを参照する他スキーマの外部キーも削除します。自動的に安全に解決する意味ではありません。依存先のデータ整合性への影響を事前に調査してください。

比較例の注意：dba_constraintsの閲覧権限が必要です。ここは外部キーの一部の調査で、全依存/ジョブ/アプリ利用や復旧可能性の網羅証明ではありません。

-- 他スキーマからの参照を調査
SELECT owner, constraint_name, table_name, r_owner, r_constraint_name
  FROM dba_constraints
 WHERE constraint_type = 'R'
   AND r_owner = 'APP_USER';

削除前の安全チェック

1. 該当ユーザーがアプリで使われていないか、接続情報（tnsnames・接続文字列）を grep
2. v$session で接続セッションがないか確認
3. 必要なデータ/メタデータの保護範囲と復元手順を確認する。一覧出力だけを復元可能なバックアップと扱わない
4. 他スキーマからの参照（外部キー・ビュー・シノニム）を調査
5. 本番は所有者と承認/停止/接続更新/依存/復旧を計画。ロック後の日数だけで削除安全と決めない

比較例の注意：ロックは既存接続を終了せず、数日待っただけで安全とは判定できません。最後のCASCADEへ自動的に進みません。

-- ステップ 1: アカウントロックで利用停止
ALTER USER app_user ACCOUNT LOCK;

-- 数日〜数週間運用して問題なし → ステップ 2 で削除
DROP USER app_user CASCADE;

表領域とユーザー削除の関係

ユーザーを削除しても表領域（TABLESPACE）自体は残ります。ユーザーが使用していたセグメントは解放され、表領域内の空き領域として再利用可能になります。表領域削除は別の破壊的作業で、共有利用/所有者/データファイルと復旧を独立に確認します。ユーザー削除後の定型手順にはしません。

比較例の注意：INCLUDING CONTENTS AND DATAFILESはユーザー削除とは別の破壊的操作です。既存/共有表領域へ実行せず、削除後の通常片付けにしません。

-- ユーザー削除後に、不要になった表領域も削除
DROP TABLESPACE app_data INCLUDING CONTENTS AND DATAFILES;

他 DBMS との比較

比較例の注意：他製品との意味の違いを比べる表で、同等の全削除手順ではありません。所有物の削除や権限/依存の一括変更へ直結しません。

DBMS	構文	備考
Oracle	DROP USER ユーザー名 [CASCADE]	スキーマと一体
MySQL	DROP USER 'user'@'host'	Oracleの所有スキーマ削除とは異なる。既存DB/表の削除まで自動的に続けない
PostgreSQL	DROP USER ユーザー名 / DROP ROLE	依存がある場合は所有権/権限と対象DB等を調査。REASSIGN OWNED/DROP OWNEDを一括前処理として実行しない
SQL Server	DROP USER ユーザー名; + DROP LOGIN ログイン名;	userとloginは別の対象。常に両方を削除する意味ではなく、contained user等も確認

よくあるトラブル

比較例の注意：エラーの自動回避表ではありません。CASCADE/強制切断/DBA付与/参照制約削除やビュー作直しを無条件に行いません。

エラー	原因 / 対処
ORA-01922: CASCADE must be specified to drop ...	所有物あり。影響/復元/承認を確認し、エラーを消すため自動でCASCADEを付けない
ORA-01940: cannot drop a user that is currently connected	接続中。所有者と通常の終了を調整。強制切断は別の承認/影響評価が必要
ORA-01031: insufficient privileges	必要なDROP USERシステム権限等を承認された管理者が確認。一般アプリへDBAを付与しない
ORA-02429: cannot drop index used for enforcement of unique/primary key	このエラーは主キー/一意制約を実施する索引の削除に関係する。実行SQLと制約を調査し、DROP USERの一般原因と断定して外部キーを削除しない
削除後にビューが INVALID	参照先が失われた可能性。再コンパイルだけで表/データは復元できない。依存と承認済み復旧計画を確認

関連

• ユーザー関連 — 親カテゴリ
• CREATE USER — ユーザー作成
• ALTER USER — パスワード変更・アカウントロック
• GRANT / REVOKE — 権限付与・剥奪
• DROP TABLESPACE — 表領域削除

元の基本構文と説明

元例の注意：次は元v2の書式付き構文です。「強制的」は接続/製品制限を無視できるという意味ではありません。対象と依存/復旧を確認し、CASCADEを通常のエラー回避に使いません。

Oracleのユーザー削除SQLです。

 

【構文】 ※ []は任意

DROP USER ユーザー名 [CASCADE]

 

【説明】

指定したユーザーを削除することが出来ます。

ユーザーがスキーマオブジェクト（表など）を保有している場合は削除することができませんが、

CASCADE オプションを指定することで強制的にスキーマオブジェクトも含め削除することができます。

 

確認範囲と関連ページ

2026年10月26日確認。新しいOracle例はOracle AI Database 26ai Free 23.26.3.0.0の隔離PDBで、公開された検体アカウント/パスワードと新規データだけを使って検査しました。ロック/パスワードと既存接続、既定表領域とquota、権限不足、空ユーザー/接続中/所有物ありの削除、別スキーマの外部キー/ビューとROLLBACKの結果を確認しています。実運用のバックアップ復元、RAC/ASM、全認証方式/全DB版やMySQL/PostgreSQL/SQL Serverの全比較例を今回実行したものではありません。本番DBのユーザー/認証/権限/表領域は変更していません。

ユーザー関連の親ページから子ページを選択できます。Oracleのユーザー作成、ユーザー定義変更、Oracleのユーザー削除を操作別に参照してください。

一次資料：Oracle ALTER USERの権限とPDB/属性、Oracle DROP USERの権限・CASCADEと制限、MySQL 8.4 ALTER USER、PostgreSQLの将来オブジェクトの権限、SQL Serverのユーザー種類。