DB2 (LUW) equivalente para Oracle «drop user cascade»
Podría ser útil revisar DB2 en general primero.
Cuando instalas DB2 se crea una instancia. Piense en esto como un «servidor». Una instancia puede tener de cero a muchas bases de datos dentro de ella (no puedo decir que conozco el límite). Cuando usted creó DB2 localmente, creó una instancia para usted llamada DB2. Normalmente, cuando instalas DB2 en un servidor Unix, nombras tus instancias. Puedes tener más de una instancia en el mismo servidor físico. Su id dsinst1 es el «propietario» de la instancia (normalmente la instancia se llama como el ID que la posee). Nunca debe eliminar este ID sin desechar la instancia o puede terminar con algunos comportamientos muy extraños. Este ID (ya que es el dueño de la instancia) tiene el poder de crear bases de datos, pero no tiene que hacerlo. Esta entrada del blog del usuario de DB2 Ember Crooks ayuda a explicar el concepto de una instancia a aquellos más familiarizados con Oracle.
Las instancias pueden tener bases de datos creadas dentro de ellas. Volveremos a esto más adelante.
El DAS (o Servidor de Administración de DB2) es realmente más bien un servicio. Es lo que permite que algunas de las herramientas de la interfaz gráfica de usuario, como el Centro de Control de DB2, interactúen con DB2. Por lo que tengo entendido, este servicio no es necesario para que DB2 funcione, pero a menudo es necesario para que los usuarios finales puedan interactuar con DB2 desde una perspectiva que no sea de línea de comandos. (Mustaccio, ¿estoy en lo cierto?). No importa cuántas instancias tenga en una caja física, sólo hay una instalación del DAS. Esta instalación puede dar servicio a todas las instancias. Normalmente hay un ID separado que se necesita para ejecutar el servicio DAS. Este es su dasusr1. Nuevamente, usted no quiere borrar este ID. Este ID normalmente no tiene autoridad para crear ningún objeto dentro de su base de datos.
Ahora el ID de la valla (es decir, db2fenc1). Tener uno de estos es una buena idea. Cuando creas una instancia puedes especificar un ID de valla. Si lo hace, se convierte en ese ID. Si no lo hace, el ID del propietario de la instancia se convierte en el ID de la valla. El ID de valla se utiliza para ejecutar ciertos procedimientos almacenados en DB2. En DB2 hay dos formas de ejecutar los procedimientos almacenados: con y sin restricciones. Sin cercar significa que el procedimiento almacenado se ejecuta dentro de la memoria del motor de DB2. Se ejecutará más rápido, pero si el procedimiento almacenado es más que SQL (es decir, contiene código C++ o Java, por ejemplo) y se bloquea, puede amenazar al motor y realmente bloquearlo y causar daños. Los procedimientos almacenados cerrados se ejecutan fuera de la memoria del motor DB2. Por lo tanto, son más lentos, pero si se bloquean no amenazan al motor DB2 porque se ejecutan en su propia área de memoria protegida. Un ejemplo de cómo lo utiliza DB2: si ejecuta la utilidad de exportación de db2 desde el procedimiento almacenado ADMIN_CMD, DB2 le cambiará el usuario de quien realmente ejecuta la exportación. Esto se debe a que usted está haciendo la E/S de archivos y DB2 desea ejecutar esta valla para proteger el motor. Así que incluso si está ejecutando esta llamada al procedimiento almacenado como propietario de la instancia, DB2 cambiará el ID al ID vallado (sin posibilidad de que usted altere este comportamiento). Si mira los permisos de quién es el propietario del archivo de exportación, notará que es el ID vallado, en lugar del ID de la instancia (u otro ID que haya utilizado para lanzar el procedimiento almacenado). Por supuesto, si tu ID de instancia es tu ID cercado, entonces te parecerá uno y el mismo.
(Gran respiración).
OK. Así que he dicho todo eso para presentarte a DB2 en pocas palabras. Ahora llegamos a lo que probablemente te preocupa: ¿quién es el dueño de qué? El ID que crea la base de datos es el propietario de la misma. Hay «grupos» que DB2 acepta que generalmente tienen la autoridad DBADM (es decir, administrador de la base de datos) para crear bases de datos. Así que si usted creó una base de datos utilizando su ID de propietario de instancia, entonces sería el propietario de la base de datos y de cualquier objeto que cree dentro de la base de datos. Si un ID diferente se conecta a la base de datos (siempre que tenga los permisos correctos) puede crear objetos y ser propietario de ellos.
Aquí está lo interesante de los grupos e IDs dentro de DB2. No son realmente objetos por lo que veo. Así que no puedes soltarlos. Tampoco se pueden crear (al menos por lo que veo). Cuando se concede o revoca un permiso a un ID, DB2 almacena la mención de ese grupo o ID. Pero DB2 no los «crea» realmente. La mayoría de las veces he visto que DB2 apunta al SO o a un LDAP o a ambos para autenticar los IDs. Si se eliminan los IDs, hay que eliminar manualmente los permisos de los IDs y/o transferir la propiedad de los objetos. No hay nada mágico en esto. Hice una pregunta similar que tenía que ver con hacer una copia de seguridad/restauración a un sistema diferente y cómo eso afecta a los permisos.
Y por último para su comentario sobre los esquemas, generalmente cada ID se asigna a su propio esquema. Que el esquema exista o no (creado por el ID DBADM explícitamente o por el usuario final a través del permiso IMPLICIT_SCHEMA) es otra cuestión. Generalmente sea cual sea el ID que se conecte a una base de datos, DB2 asume que el esquema es el mismo que el id de usuario y hay que cambiar de esquema (SET SCHEMA MYSCHEMA) o mencionar explícitamente sus objetos (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE) para trabajar con ellos.
Espero que esto ayude.