A história é recorrente: o desenvolvedor mandou para você  um mega script (ou um pacote com dezenas deles) para rodar no banco de dados Oracle. Em 99% dos casos o desenvolvedor vai dizer que o script precisa ser executado com você conectado no banco de dados utilizando o usuário XYZ, que é o dono dos objetos que vão ser criados/alterados/apagados.

Aí o que o DBA faz? Pega a senha do usuário numa listinha “cuidadosamente” guardada e roda o script em questão. Então, pare e pense: qual é o problema nisso?

• Você tem que guardar a senha dos usuários da base. Isso vai lhe levar a uma das seguintes situações:
  • Você vai colocar senhas fáceis (como o mesmo nome do usuário ou a mesma senha para todos usuários), o que representa uma brecha de segurança;
  • Você vai anotar num papel, txt ou algo do tipo todas as senhas. E esse papel, txt, etc não vai estar guardado num cofre, pois você precisa disso com frequência. Nova falha de segurança.
  • Você vai criar um banco de dados para guardar as senhas… e ter mais uma base para administrar, gênio.
  • Você vai deixar o próprio desenvolvedor/fornecedor rodar o script para você. Tá louco? Jamais faça isso num ambiente de produção!!!
• Você vai ter que conceder permissões para este usuário além do necessário. Se precisa criar uma tabela, precisa conceder permissão de CREATE TABLE. Precisa criar uma sequência? CREATE VIEW. E por aí vai. Não é raro o DBA usar logo uma daquelas mega permissões como DBA, RESOURCE, etc. Afinal, perder tempo com segurança é coisa de DBA chato, certo?

Ok, você é um DBA esperto… muitos anos de praia, já sabe que existem outras alternativas:

• Rodar o script como DBA, mas antes abrir o script num editor e sair colocando o nome do esquema antes do nome do objeto. Isso dá certo, mas dá muito trabalho. Não é algo que se possa automatizar sem cometer alguns erros. Acredite, há casos em que isso pode levar horas e está sujeito a muitos erros.
• Você pode pegar a senha criptografada em DBA_USERS, alterar a senha do usuário, rodar o script e depois voltar a senha original. É também uma forma de bloquear o acesso deste usuário enquanto você está atualizando os objetos. Claro que idealmente um usuário dono de objetos não deveria nunca ser utilizado para acesso pela aplicação… mas não é o que os desenvolvedores tem a mania de fazer. Por mim esse usuário não deveria sequer ter permissão para se conectar na base. Eu realmente não acho esta uma solução elegante, e você precisa manter o usuário com um monte de privilégios desnecessários da mesma forma que antes. Já vi também pessoas colocando permissões de DBA enquanto rodam o script e depois que terminam removem a permissão. Não, não é uma boa idéia. Você também tem de anotar com cuidado a senha criptografada para alterar a senha de volta para a original qualquer caracter bizarro que você erre, já era. Por fim você  tem conhecer o impacto de alterar a senha, mesmo que provisóriamente. Experimenta por exemplo trocar a senha do usuário APPS no EBS para ver o que acontece…

Então qual é o procedimento que 10 entre 10 DBAs experientes utilizam? Simples:

ALTER SESSION SET current_shema=foo;

Simples assim. O esquema padrão passa a ser foo. Todos os objetos criados, alterados e apagados serão neste esquema.

Mas calma, existem alguns problemas sim: alguns comandos não trabalham bem com outro CURRENT_SCHEMA. Um deles é a criação de DB Links. Não é possível criar um DB Link para outro esquema, você tem de estar realmente conectado com o usuário em questão para criar este DB Link. Claro que você não cria DB Links no ambiente de produção com frequência (pela sua sanidade mental, eu espero que não). DB Links públicos não tem esse problema, é claro. Outro problema é a criação de JOBs com o DBMS_JOB. Você pode utilizar o DBMS_IJOB, para contornar este problema ou pelo bem da humanidade migrar para o Scheduler.

Bom, de qualquer forma é sempre obrigação do DBA revisar os scripts, verificar os parâmetros de Storage, etc.

OBS: Este post é dedicado a um DBA velho de guerra que ainda guarda velhos hábitos dos tempos que era desenvolvedor e insiste em me trazer mais problemas do que soluções.

OBS2: No PostgreSQL existe uma não conformidade com o padrão SQL (você pode trabalhar no padrão se quiser, mas não vejo vantagem) que permite que os usuários e os esquemas não sejam diretamente relacionados.  Então esta cultura ruim do Oracle não é tão comum entre os desenvolvedores/DBAs do PostgreSQL. Além disso o PostgreSQL tem o SEARCH_PATH que é mais refinado que o CURRENT_SCHEMA, e permite trocar facilmente o dono de qualquer objeto (que não seja um objeto de sistema, claro).