DB2 (LUW) equivalente para Oracle "drop user cascade"

Pode ser útil revisar primeiro o DB2 em geral.

Quando você instala o DB2, ele cria uma instância . Pense nisso como um "servidor". Uma instância pode ter de zero a muitos bancos de dados dentro dela (não posso dizer que conheço o limite). Quando você criou o DB2 localmente, 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. Seu id dsinst1 é o "proprietário" da instância (geralmente a instância recebe o nome do ID que a possui). Você nunca deseja excluir esse ID sem descartar a instância ou pode acabar com alguns comportamentos muito estranhos. Este ID (já que é superior à instância) tem o poder de criar bancos de dados, mas não é obrigatório. Esta entrada de blog do colega usuário do DB2, Ember Crooksajuda a explicar o conceito de uma instância para aqueles mais familiarizados com o Oracle.

As instâncias podem ter bancos de dados criados dentro delas. Voltaremos a isso mais tarde.

O DAS (ou DB2 Administration Server) é realmente mais como um serviço. É o que permite que algumas das ferramentas da GUI, como o DB2 Control Center, façam interface com o DB2. Pelo que entendi, esse serviço não é necessário para a execução do DB2, mas geralmente é necessário para que os usuários finais interajam com o DB2 de uma perspectiva que não seja da linha de 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. Geralmente, é necessário um ID separado para executar o serviço DAS. Este é o seu dasusr1. Novamente, você não deseja excluir esse ID. Esse ID geralmente não tem autoridade para criar nenhum objeto em seu banco de dados.

Agora, para o ID da cerca (ou seja, db2fenc1). Ter um desses é uma boa ideia. Ao criar uma instância, você pode especificar um ID de cerca. Se o fizer, torna-se esse ID. Caso contrário, o ID do proprietário da instância se tornará o ID da cerca. O ID de cerca é usado para executar determinados procedimentos armazenados no DB2. No DB2, há duas maneiras de executar procedimentos armazenados: protegido e não protegido. Unfenced significa que o procedimento armazenado é executado na memória do mecanismo do DB2. Ele será executado mais rapidamente, mas se o procedimento armazenado for mais do que SQL (ou seja, contiver código C++ ou Java, por exemplo) e travar, poderá ameaçar o mecanismo e realmente travar e causar danos. Os procedimentos armazenados limitados são executados fora da memória do mecanismo do DB2. Eles são, portanto, mais lentos, mas se travarem, não ameaçarão o mecanismo do DB2 porque foram executados em sua própria área de memória protegida.ADMIN_CMDprocedimento armazenado, o DB2 mudará o usuário para você de quem realmente executa a exportação. Isso ocorre porque você está fazendo E/S de arquivo e o DB2 deseja executar isso com proteção limitada para proteger o mecanismo. Portanto, mesmo se você estiver executando essa chamada de procedimento armazenado como o proprietário da instância, o DB2 alternará o ID para o ID limitado (sem chance de você alterar esse comportamento). Se você observar as permissões de quem possui o arquivo de exportação, notará que é o ID protegido, em vez do ID da instância (ou outro ID usado para disparar o procedimento armazenado). É claro que, se o ID da sua instância for o ID protegido, ele parecerá o mesmo para você.

(grande respiração).

OK. Então eu disse tudo isso para apresentá-lo ao DB2 em poucas palavras. Agora chegamos ao que você provavelmente está se preocupando - quem é o dono do quê? Qualquer ID que crie o banco de dados possui o banco de dados. Existem "grupos" que o DB2 aceita que geralmente têm DBADMautoridade (ou seja, administrador de banco de dados) para criar bancos de dados. Portanto, se você criou um banco de dados usando o ID do proprietário da instância, ele será o proprietário do banco de dados e de todos os objetos que ele criar no banco de dados. Se um ID diferente se conectar ao banco de dados (desde que tenha as permissões corretas), ele poderá criar objetos e possuí-los.

Aqui está o interessante sobre grupos e IDs no DB2. Eles não são realmente objetos pelo que posso ver. Então você não pode deixá-los cair. Você também não pode criá-los (pelo menos pelo que posso ver). Quando você concede ou revoga uma permissão para um ID, o DB2 armazena a menção desse grupo ou ID. Mas o DB2 realmente não os "cria". Na maioria das vezes, vi o DB2 apontado para o sistema operacional ou para um LDAP ou ambos para autenticar os IDs. Se os IDs forem removidos, você deverá remover manualmente as permissões dos IDs e/ou transferir a propriedade dos objetos. Não há nada de mágico nisso aqui. Eu fiz uma pergunta semelhante relacionada a fazer um backup/restaurar para um sistema diferente e como isso afeta as permissões.

E, finalmente, para seu comentário sobre esquemas, geralmente cada ID é mapeado para seu próprio esquema. Se o esquema existe ou não (criado pelo ID DBADM explicitamente ou pelo usuário final por meio da permissão IMPLICIT_SCHEMA) é outra questão. Geralmente, qualquer que seja o ID que se conecta a um banco de dados, o DB2 assume que o esquema é o mesmo que o ID do usuário e você precisa alternar os esquemas ( SET SCHEMA MYSCHEMA) ou mencionar explicitamente seus objetos ( SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE) para trabalhar com eles.

Espero que isto ajude.

@Chris Aldrich deu uma boa explicação. Vou apenas acrescentar algumas coisas aqui.

1) Não existe o conceito de "usuário do banco de dados" no DB2. Toda autenticação acontece fora do banco de dados ou instância, no sistema operacional. Além disso, não há relação direta entre um ID de usuário e um nome de esquema, ao contrário do Oracle. No DB2, um esquema é apenas um agrupamento lógico de objetos, não possui nenhum recurso de segurança especial. Qualquer usuário pode criar qualquer esquema. Por exemplo, enquanto logado como mustaccio , executo a instrução create table foo (id int...), e isso cria um esquema MUSTACCIO (se ainda não estiver lá) e uma tabela nele. Como você pode ver, a resolução do nome do esquema é padronizada para o meu ID de autorização . No entanto, também posso executar a instrução create table alok.foo (id char(3)...), que neste caso cria um esquema ALOK e a tabela nele. mustaccio será o dono de ambas as mesas.

2) Em relação ao mapeamento do ID do usuário, eu provavelmente diria que o proprietário DAS dasusr1 e o usuário limitado db2fenc1 não mapeiam para nada em um banco de dados Oracle. O proprietário da instância db2inst1 é mapeado para o ID do usuário oracle . Quem cria um banco de dados (pode ser db2inst1 ou algum outro usuário autorizado a fazer isso por pertencer ao grupo SYSADM, por exemplo) obtém privilégios DBADM e SECADM nesse banco de dados, o que é um pouco semelhante a ser sistema e/ou sys (estou não tenho certeza qual é a diferença entre os dois em um banco de dados Oracle). Se você precisar de um ID funcional que possua objetos de banco de dados, crie appownerno sistema operacional, conceda a ele as permissões apropriadas e conecte-se a esse usuário ao criar objetos. Da mesma forma, você cria appuser no sistema operacional, concede privilégios de acesso de objeto a ele e permite que seu aplicativo se conecte como esse usuário.

3) Como não há usuários de banco de dados no DB2, você não pode descartar um usuário. Para excluir objetos em um esquema específico, você pode usar o procedimento ADMIN_DROP_SCHEMA() .