DB2 (LUW) equivalente ao Oracle “drop user cascade”
Pode ser útil rever primeiro o DB2 em geral.
Quando você instala o DB2, ele cria uma instância. Pense nisto como um “servidor”. Uma instância pode ter zero a muitas bases de dados dentro dela (não posso dizer que conheço o limite). Quando você criou localmente o DB2, ele criou uma instância para você chamada DB2. Normalmente quando você instala o DB2 em um servidor Unix, você nomeia suas instâncias. Você pode ter mais de uma instância no mesmo servidor físico. Você dsinst1 id é o “dono” da instância (normalmente a instância tem o nome do ID que a possui). Você nunca quer apagar este ID sem eliminar a instância ou pode acabar com alguns comportamentos muito estranhos. Este ID (uma vez que é o dono da instância) tem o poder de criar bases de dados, mas não tem de o fazer. Esta entrada de blog pelo colega usuário do DB2 Ember Crooks ajuda a explicar o conceito de uma instância para aqueles mais familiarizados com Oracle.
Instâncias podem ter bancos de dados criados dentro delas. Voltaremos a isto mais tarde.
O DAS (ou Servidor de Administração DB2) é realmente mais como um serviço. É o que permite que algumas das ferramentas GUI como o DB2 Control Center façam interface com o DB2. Pelo que entendi, este serviço não é necessário para o DB2 funcionar, mas é frequentemente necessário para que os usuários finais façam interface com o DB2 a partir de uma perspectiva de linha não-comando. (Mustaccio estou correto aqui?). Não importa quantas instâncias você tenha em uma caixa física, há apenas uma instalação do DAS. Esta instalação pode atender a todas as instâncias. Normalmente há uma identificação separada que é necessária para executar o serviço DAS. Este é o seu dasusr1. Mais uma vez, você não quer apagar este ID. Este ID normalmente não tem autoridade para criar quaisquer objetos dentro do seu banco de dados.
Agora para o ID da cerca (ou seja, db2fenc1). Ter um destes é uma boa ideia. Quando você cria uma instância, você pode especificar um ID de cerca. Se você o fizer, ele se torna esse ID. Se você não o fizer, então o ID do dono da instância torna-se o ID da cerca. O ID da cerca é usado para executar certos procedimentos armazenados no DB2. No DB2 há duas maneiras de executar procedimentos armazenados: vedado e não vedado. Sem vedação significa que o procedimento armazenado é executado dentro da memória do motor DB2. Ele executará mais rápido, mas se o procedimento armazenado for mais que SQL (ou seja, contém código C++ ou Java, por exemplo) e travar, ele pode ameaçar o mecanismo e realmente travá-lo e causar danos. Procedimentos armazenados cercados rodam fora da memória do motor DB2. Elas são, portanto, mais lentas, mas se travarem, não ameaçam o motor DB2 porque rodam em sua própria área de memória protegida. Um exemplo de como isso é usado pelo DB2: se você executar o utilitário de exportação db2 a partir do procedimento ADMIN_CMD armazenado, o DB2 irá ligar o usuário de quem realmente executa a exportação. Isto é porque você está fazendo I/O de arquivo e o DB2 deseja executar esta vedação para proteger o motor. Então mesmo se você estiver executando esta chamada de procedimento armazenado como proprietário da instância, o DB2 irá trocar o ID para o ID cercado (sem nenhuma chance de você alterar este comportamento). Se você olhar para as permissões de quem possui o arquivo de exportação, você notará que é o ID da cerca, ao invés do ID da instância (ou outro ID que você usou para disparar o procedimento armazenado). Claro que se o seu ID de instância é o seu ID cercado, então ele parecerá o mesmo para você.
(Big breath).
OK. Então eu disse tudo isso para te apresentar o DB2 em poucas palavras. Agora chegamos ao que você provavelmente está se preocupando — quem é o dono do quê? Qual é o ID que cria a base de dados que é dono da base de dados. Existem “grupos” que o DB2 aceita que geralmente têm a autoridade DBADM (ou seja, administrador do banco de dados) para criar bancos de dados. Então se você criou um banco de dados usando seu ID de proprietário de instância, então ele seria o proprietário do banco de dados e quaisquer objetos que ele crie dentro do banco de dados. Se um ID diferente se conectar ao banco de dados (desde que tenha as permissões corretas) ele pode criar objetos e possuí-los.
Aqui está a coisa interessante sobre grupos e IDs dentro do DB2. Eles não são realmente objetos do que eu posso ver. Então você não pode deixá-los cair. Você também não pode criá-los (pelo menos a partir do que eu posso ver). Quando você concede ou revoga uma permissão para um ID, o DB2 então armazena uma menção a esse grupo ou ID. Mas o DB2 não os “cria” realmente. Na maioria das vezes eu vi o DB2 apontar para o SO ou para um LDAP ou ambos para autenticar os IDs. Se os IDs forem removidos, você tem que remover manualmente as permissões dos IDs e/ou transferir a propriedade dos objetos. Não há nada de mágico nisto aqui. Eu fiz uma pergunta semelhante tendo a ver com fazer um backup/restauração para um sistema diferente e como isso afecta as permissões.
E por último para o seu comentário sobre esquemas, geralmente cada ID mapeia para o seu próprio esquema. Se o esquema existe ou não (criado pelo ID DBADM explicitamente ou pelo usuário final através da permissão IMPLICIT_SCHEMA) é outra questão. Geralmente qualquer ID que se ligue a um banco de dados, DB2 assume que o esquema é o mesmo que o ID do usuário e você tem que trocar de esquema (SET SCHEMA MYSCHEMA) ou mencionar explicitamente seus objetos (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE) para trabalhar com eles.
Espera que isto ajude.