DB2 (LUW) äquivalent zu Oracle „drop user cascade“
Es könnte hilfreich sein, DB2 zunächst allgemein zu betrachten.
Wenn Sie DB2 installieren, wird eine Instanz erstellt. Betrachten Sie diese als einen „Server“. Eine Instanz kann null bis viele Datenbanken enthalten (ich weiß nicht, wie viele es sind). Als Sie DB2 lokal erstellt haben, wurde eine Instanz für Sie mit dem Namen DB2 erstellt. Wenn Sie DB2 z.B. auf einem Unix-Server installieren, geben Sie Ihren Instanzen normalerweise einen Namen. Sie können mehr als eine Instanz auf demselben physischen Server haben. Ihre dsinst1 ID ist der „Besitzer“ der Instanz (normalerweise wird die Instanz nach der ID benannt, die sie besitzt). Sie sollten diese ID niemals löschen, ohne die Instanz zu verschrotten, da es sonst zu sehr seltsamen Verhaltensweisen kommen kann. Diese ID (da sie der Instanzbesitzer ist) hat die Möglichkeit, Datenbanken zu erstellen, muss es aber nicht. Dieser Blogeintrag von DB2-Kollege Ember Crooks hilft denjenigen, die mit Oracle besser vertraut sind, das Konzept einer Instanz zu erklären.
Instanzen können Datenbanken in sich selbst erstellen. Wir werden später darauf zurückkommen.
Der DAS (oder DB2 Administration Server) ist eigentlich eher ein Dienst. Er ermöglicht es einigen GUI-Tools wie dem DB2 Control Center, sich mit DB2 zu verbinden. Soweit ich weiß, ist dieser Dienst nicht notwendig, damit DB2 läuft, aber er wird oft von Endbenutzern benötigt, um eine Schnittstelle zu DB2 zu haben, die nicht auf der Kommandozeile liegt. (Liege ich hier richtig, Mustaccio?). Unabhängig davon, wie viele Instanzen Sie auf einer physischen Box haben, gibt es nur eine Installation des DAS. Diese eine Installation kann alle Instanzen bedienen. Es gibt normalerweise eine separate ID, die für die Ausführung des DAS-Dienstes benötigt wird. Dies ist Ihre dasusr1. Auch diese ID sollten Sie nicht löschen. Diese ID hat normalerweise keine Berechtigung zum Erstellen von Objekten in Ihrer Datenbank.
Nun zur Fence-ID (d.h. db2fenc1). Es ist ratsam, eine dieser IDs zu haben. Wenn Sie eine Instanz erstellen, können Sie eine Zaun-ID angeben. Wenn Sie das tun, wird sie zu dieser ID. Wenn Sie das nicht tun, wird die ID des Instanzbesitzers zur Fence-ID. Die Fence-ID wird für die Ausführung bestimmter gespeicherter Prozeduren in DB2 verwendet. In DB2 gibt es zwei Möglichkeiten, Stored Procedures auszuführen: fenced und unfenced. Unfenced bedeutet, dass die Stored Procedure im Speicher der DB2-Engine ausgeführt wird. Sie läuft schneller, aber wenn die gespeicherte Prozedur mehr als SQL ist (z. B. C++- oder Java-Code enthält) und abstürzt, kann sie die Engine bedrohen und tatsächlich zum Absturz bringen und Schaden verursachen. Fenced Stored Procedures werden außerhalb des Speichers der DB2-Engine ausgeführt. Sie sind daher langsamer, aber wenn sie abstürzen, stellen sie keine Gefahr für die DB2-Engine dar, da sie in ihrem eigenen geschützten Speicherbereich ausgeführt werden. Ein Beispiel dafür, wie dies von DB2 genutzt wird: Wenn Sie das Dienstprogramm db2 export aus der gespeicherten Prozedur ADMIN_CMD ausführen, wechselt DB2 den Benutzer, der den Export tatsächlich ausführt. Der Grund dafür ist, dass Sie Dateieingabe und -ausgabe durchführen und DB2 dies zum Schutz der Engine geschützt ausführen möchte. Selbst wenn Sie diesen Stored-Procedure-Aufruf als Eigentümer der Instanz ausführen, wird DB2 die ID auf die geschützte ID umstellen (ohne dass Sie die Möglichkeit haben, dieses Verhalten zu ändern). Wenn Sie sich die Berechtigungen des Eigentümers der Exportdatei ansehen, werden Sie feststellen, dass es sich um die geschützte ID handelt und nicht um die Instanz-ID (oder eine andere ID, die Sie zum Ausführen der gespeicherten Prozedur verwendet haben). Wenn Ihre Instanz-ID natürlich Ihre Fenced ID ist, dann sieht es für Sie ein und dasselbe aus.
(Tief durchatmen).
OK. So, das habe ich alles gesagt, um Ihnen DB2 in aller Kürze vorzustellen. Jetzt kommen wir zu dem, worüber Sie sich wahrscheinlich Sorgen machen – wer besitzt was? Die Datenbank gehört derjenigen ID, die sie erstellt. Es gibt „Gruppen“, die DB2 akzeptiert, die im Allgemeinen die DBADM (d.h. Datenbankadministrator) Berechtigung haben, Datenbanken zu erstellen. Wenn Sie also eine Datenbank mit Ihrer Instanz-Eigentümer-ID erstellen, ist diese der Eigentümer der Datenbank und aller Objekte, die sie innerhalb der Datenbank erstellt. Wenn eine andere ID eine Verbindung zur Datenbank herstellt (sofern sie die richtigen Berechtigungen hat), kann sie Objekte erstellen und sie besitzen.
Hier ist das Interessante an Gruppen und IDs in DB2. Soweit ich sehen kann, sind sie nicht wirklich Objekte. Man kann sie also nicht löschen. Sie können sie auch nicht erstellen (zumindest soweit ich das sehe). Wenn Sie einer ID eine Berechtigung erteilen oder entziehen, speichert DB2 einen Hinweis auf diese Gruppe oder ID. Aber DB2 „erstellt“ sie nicht wirklich. Meistens habe ich gesehen, dass DB2 auf das Betriebssystem oder auf ein LDAP oder beides verweist, um die IDs zu authentifizieren. Wenn die IDs entfernt werden, müssen Sie den IDs manuell die Berechtigungen entziehen und/oder das Eigentum an den Objekten übertragen. Hier gibt es nichts Magisches zu entdecken. Ich habe eine ähnliche Frage gestellt, die mit der Sicherung/Wiederherstellung auf einem anderen System und den Auswirkungen auf die Berechtigungen zu tun hat.
Und schließlich zu Ihrer Bemerkung über Schemata: Im Allgemeinen wird jede ID einem eigenen Schema zugeordnet. Ob das Schema existiert oder nicht (von der DBADM-ID explizit erstellt oder vom Endbenutzer durch die IMPLICIT_SCHEMA-Berechtigung) ist eine andere Frage. Im Allgemeinen geht DB2 bei jeder ID, die eine Verbindung zu einer Datenbank herstellt, davon aus, dass das Schema dasselbe ist wie die Benutzerkennung, und Sie müssen das Schema wechseln (SET SCHEMA MYSCHEMA) oder Ihre Objekte explizit erwähnen (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE), um mit ihnen arbeiten zu können.
Hoffe, das hilft.