DB2 (LUW) equivalent for Oracle “drop user cascade”
最初に DB2 を一般的に復習することが役に立つかもしれません。 これは「サーバ」だと考えてください。 インスタンスはその中に0個から多数のデータベースを持つことができます（上限はわかりません）。 DB2をローカルに作成すると、DB2という名前のインスタンスが作成されます。 通常、DB2 を Unix サーバーなどにインストールする場合、インスタンスに名前を付けます。 同じ物理サーバに複数のインスタンスを作成することができます。 dsinst1 という ID はインスタンスの「オーナー」です（通常、インスタ ンスはオーナーである ID の名前にちなんで命名されます）。 インスタンスを破棄せずにこのIDを削除すると、非常に奇妙な動作をすることになります。 このIDは（インスタンスの所有者なので）データベースを作成する権限を持っていますが、作成する必要はありません。 DB2 ユーザーの Ember Crooks によるこのブログエントリーは、Oracle に精通している人たちにインスタンスの概念を説明するのに役立ちます。 これについては後で説明します。
DAS (DB2 Administration Server) は、実際にはサービスのようなものです。 これは、DB2 Control Center などの一部の GUI ツールが DB2 とインターフェイスするためのものです。 私の理解では、このサービスは DB2 の実行には必要ありませんが、エンドユーザーがコマンドライン以外の観点から DB2 と連携するために必要なことがよくあります。 (Mustaccioは正しいですか？） 物理的な箱の中にいくつのインスタンスがあっても、DASのインストールは1つだけです。 この1つのインストールが、すべてのインスタンスにサービスを提供できます。 通常、DASサービスを実行するために必要な別のIDがあります。 これがあなたの dasusr1 です。 繰り返しますが、この ID は削除しないでください。 この ID は通常、データベース内にオブジェクトを作成する権限を持っていません。
次に、フェンス ID（たとえば、db2fenc1）です。 このIDは1つ持っておくとよいでしょう。 インスタンスを作成するときに、フェンスIDを指定することができます。 指定した場合は、そのIDになる。 指定しない場合は、インスタンスのオーナーIDがフェンスIDになります。 フェンス ID は DB2 内で特定のストアドプロシージャを実行するために使用されます。 DB2 では、ストアドプロシージャを実行する方法として、フェ ンス付きとフェンス無しの 2 種類があります。 アンフェンスとはストアドプロシージャを DB2 エンジンのメモリ内で実行することです。 より高速に実行されますが、ストアドプロシージャがSQL以上の内容（例えばC++やJavaのコードを含む）でクラッシュすると、エンジンに脅威を与え、実際にクラッシュして害を及ぼす可能性があります。 フェンス付きストアドプロシージャは DB2 エンジンのメモリの外側で実行されます。 そのため遅くなりますが、クラッシュした場合でも、独自の保護されたメモリ領域で実行されるため、DB2 エンジンを脅かすことはありません。 DB2 での使用例：ADMIN_CMD ストアドプロシージャから db2 export ユーティリティを実行すると、DB2 は実際にエクスポートを実行するユーザをあなたに切り替えます。 これはファイル I/O を行っているためで、DB2 はエンジンを保護するためにフェンスで囲んで実行することを希望しています。 そのため、インスタンスオーナーとしてこのストアドプロシージャコールを実行している場合でも、DB2はIDをフェンス内のIDに切り替えます（この動作を変更することはできません）。 エクスポートファイルの所有者の権限を見ると、インスタンス ID (またはストアドプロシージャを起動するために使用したその他の ID) ではなく、フェンスで保護された ID であることに気づくはずです。 もちろん、インスタンス ID がフェンス ID であれば、あなたには同じに見えるでしょう。
（大きな息）.
OK. というわけで、DB2を簡単に紹介するためにあれこれと申し上げました。 さて、ここで皆さんが気になるのは、「誰が何を所有するのか」ということでしょう。 データベースを作成したIDがそのデータベースを所有します。 DB2 が認める「グループ」というものがあり、一般に DBADM（つまりデータベース管理者）の権限を持ってデータベースを作成します。 つまり、インスタンスのオーナー ID を使用してデータベースを作成した場合、その ID がデータベースとデータベース内に作成したオブジェクトのオーナーになります。 別の ID がデータベースに接続すると、（正しい権限を持っている限り）オブジェクトを作成し、それを所有できます。
DB2 のグループと ID の興味深い点はここにあります。 これらは、私が見る限り、実際にはオブジェクトではありません。 したがって、それらをドロップすることはできません。 作成することもできません (少なくとも私が見た限りでは)。 IDに権限を与えたり、取り消したりすると、DB2はそのグループやIDに関する情報を保存します。 しかし、DB2 はそれらを実際に「作成」するわけではありません。 多くの場合、DB2はOSまたはLDAP、あるいはその両方を指してIDを認証しています。 IDが削除された場合、手動でIDから権限を削除し、かつ/またはオブジェクトの所有権を移行する必要があります。 ここでは、これに関する魔法のようなものは何もありません。 私は、異なるシステムへのバックアップ/リストアを行うことと、それが権限にどのように影響するかに関連して、同様の質問をしました。 スキーマが存在するかどうか (DBADM ID によって明示的に作成されるか、または IMPLICIT_SCHEMA 権限によってエンド ユーザーが作成する) は、別の問題です。 一般に、どのような ID でデータベースに接続しても、DB2 はスキーマがユーザー ID と同じであると見なし、スキーマを切り替える (SET SCHEMA MYSCHEMA) か、オブジェクトを明示的に指定 (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE) しなければ、作業することはできません。