DB2 (LUW) équivalent pour Oracle « drop user cascade »
Il pourrait être utile de revoir DB2 en général d’abord.
Lorsque vous installez DB2, il crée une instance. Pensez-y comme à un « serveur ». Une instance peut avoir zéro à plusieurs bases de données en son sein (je ne peux pas dire que je connais la limite). Lorsque vous avez créé DB2 localement, une instance nommée DB2 a été créée pour vous. Habituellement, lorsque vous installez DB2 sur un serveur Unix par exemple, vous nommez vos instances. Vous pouvez avoir plus d’une instance sur le même serveur physique. Votre ID dsinst1 est le « propriétaire » de l’instance (généralement, l’instance est nommée d’après l’ID qui la possède). Vous ne voulez jamais supprimer cet ID sans mettre l’instance au rebut, sinon vous risquez de vous retrouver avec des comportements très étranges. Cet ID (puisqu’il est propriétaire de l’instance) a le pouvoir de créer des bases de données, mais il n’est pas obligé de le faire. Cet article de blog d’un collègue utilisateur de DB2, Ember Crooks, aide à expliquer le concept d’une instance à ceux qui sont plus familiers avec Oracle.
Les instances peuvent avoir des bases de données créées en leur sein. Nous y reviendrons plus tard.
Le DAS (ou DB2 Administration Server) est en réalité plutôt un service. C’est ce qui permet à certains outils d’interface graphique comme DB2 Control Center de s’interfacer avec DB2. D’après ce que j’ai compris, ce service n’est pas nécessaire pour que DB2 fonctionne, mais il est souvent nécessaire pour que les utilisateurs finaux puissent s’interfacer avec DB2 d’un point de vue autre que la ligne de commande. (Mustaccio, ai-je raison ?). Peu importe le nombre d’instances que vous avez sur une boîte physique, il n’y a qu’une seule installation du DAS. Cette installation unique peut desservir toutes les instances. Il y a généralement un ID séparé qui est nécessaire pour exécuter le service DAS. Il s’agit de votre dasusr1. Encore une fois, vous ne voulez pas supprimer cet ID. Cet ID n’a généralement aucune autorité pour créer des objets dans votre base de données.
Maintenant pour l’ID de clôture (ie, db2fenc1). Avoir un de ces identifiants est une bonne idée. Lorsque vous créez une instance, vous pouvez spécifier un ID de clôture. Si vous le faites, l’instance devient cet ID. Si vous ne le faites pas, l’ID du propriétaire de l’instance devient l’ID de clôture. L’ID de clôture est utilisé pour exécuter certaines procédures stockées dans DB2. Dans DB2, il existe deux façons d’exécuter des procédures stockées : avec ou sans clôture. Unfenced signifie que la procédure stockée est exécutée dans la mémoire du moteur DB2. Elle s’exécutera plus rapidement, mais si la procédure stockée est plus que du SQL (c’est-à-dire qu’elle contient du code C++ ou Java par exemple) et qu’elle se bloque, elle peut menacer le moteur et même le bloquer et causer des dommages. Les procédures stockées clôturées s’exécutent en dehors de la mémoire du moteur DB2. Elles sont donc plus lentes, mais si elles se plantent, elles ne menacent pas le moteur DB2 car elles s’exécutent dans leur propre zone de mémoire protégée. Un exemple de la façon dont DB2 utilise ce principe : si vous exécutez l’utilitaire d’exportation db2 à partir de la procédure stockée ADMIN_CMD, DB2 changera l’utilisateur sur vous de celui qui exécute réellement l’exportation. Cela est dû au fait que vous effectuez des entrées/sorties de fichiers et que DB2 souhaite exécuter cette procédure en dehors de tout contrôle pour protéger le moteur. Ainsi, même si vous exécutez cet appel de procédure stockée en tant que propriétaire de l’instance, DB2 basculera l’ID vers l’ID protégé (sans que vous puissiez modifier ce comportement). Si vous regardez les permissions de qui possède le fichier d’exportation, vous remarquerez qu’il s’agit de l’ID clôturé, plutôt que de l’ID d’instance (ou de l’autre ID que vous avez utilisé pour lancer la procédure stockée). Bien sûr, si votre ID d’instance est votre ID clôturé, alors cela vous paraîtra identique.
(Grande respiration).
OK. Donc, j’ai dit tout cela pour vous présenter DB2 en quelques mots. Maintenant, nous arrivons à ce qui vous préoccupe probablement — qui possède quoi ? L’identifiant qui crée la base de données est propriétaire de la base de données. Il y a des « groupes » que DB2 accepte et qui ont généralement l’autorité DBADM (c’est-à-dire l’administrateur de la base de données) pour créer des bases de données. Ainsi, si vous créez une base de données en utilisant votre ID de propriétaire d’instance, alors il sera le propriétaire de la base de données et de tous les objets qu’il crée dans la base de données. Si un ID différent se connecte à la base de données (tant qu’il a les bonnes autorisations), il peut créer des objets et les posséder.
Voilà la chose intéressante à propos des groupes et des ID dans DB2. Ce ne sont pas vraiment des objets d’après ce que je peux voir. Vous ne pouvez donc pas les déposer. Vous ne pouvez pas non plus les créer (du moins d’après ce que je peux voir). Lorsque vous accordez ou révoquez une permission à un ID, DB2 stocke alors la mention de ce groupe ou ID. Mais DB2 ne les « crée » pas vraiment. Le plus souvent, j’ai vu DB2 pointer vers l’OS ou vers un LDAP ou les deux pour authentifier les ID. Si les ID sont supprimés, vous devez manuellement retirer les permissions des ID et/ou transférer la propriété des objets. Il n’y a rien de magique dans tout cela. J’ai posé une question similaire ayant trait à la réalisation d’une sauvegarde/restauration sur un système différent et à la façon dont cela affecte les permissions.
Et enfin pour votre commentaire sur les schémas, généralement chaque ID correspond à son propre schéma. Que le schéma existe ou non (créé par l’ID DBADM explicitement ou par l’utilisateur final via la permission IMPLICIT_SCHEMA) est une autre question. Généralement, quel que soit l’ID qui se connecte à une base de données, DB2 suppose que le schéma est le même que l’ID utilisateur et vous devez changer de schéma (SET SCHEMA MYSCHEMA) ou mentionner explicitement vos objets (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE) pour travailler avec eux.
J’espère que cela vous aidera.