Executando scripts – Dicas

DBA, roda esse script aí!

Ahhh! A requisição que todo DBA adora, executar o script que o fulano programou! Não adianta chorar, isso vai ser comum, pelo menos no seu começo de carreira.

Só que pera lá! Não saia colocando pra rodar qualquer coisa que te pedirem, não. Você é o DONO do banco de dados agora e, embora algumas diretrizes corporativas possam lhe isentar no caso de algo errado acontecer, você compartilha a responsabilidade do sucesso e do fracasso das atividades nas quais participa. Não adianta tirar o corpo fora porque o script do ciclano destruiu a base toda, você poderia ter evitado se tivesse analisado o script antes de executá-lo. A culpa é do ciclano também (na minha opinião, bem mais dele do que sua), mas você também deixou passar. É esse tipo de situação que podemos evitar tomando alguns cuidados.

Aqui vão algumas dicas para que você, rookie, fique esperto nessas ocasiões.

 

1) Leia e entenda o script

Antes de fazer qualquer coisa, abra o script e veja  o que ele faz. Nem sempre é um código muito extenso, é possível ter uma boa noção do que aquele código irá fazer no seu banco de dados. Você, como DBA, deve entender o que está acontecendo e pode (em alguns casos deve) sugerir ou propor alguma melhoria no código, antes de executá-lo.Você pode pegar casos como um DELETE sem cláusula WHERE e pode alertar o dono do script quanto a isso, confirmar se é isso mesmo que ele desejava executar ou se não foi um erro de lógica de programação.

 

2) Quem é o dono dos objetos manipulados?

Veja se, no script, estão mencionados os donos dos objetos explicitamente. Se não estiver, você terá que executar o script após ter acessado o banco com o usuário do schema correto. Ou, como DBA, alterar sua sessão para o schema correto.Caso não tenha o owner explícito e você estiver conectado como SYS ou outro usuário com privilégios suficientes, pode ser que uma infeliz coincidência aconteça e você delete, destrua (drop) ou crie objetos dentro de um schema que não era o alvo. Isso pode até ser impossível de se consertar sem ter que voltar um backup. Olha a dor de cabeça…

 

3) E se der tudo errado. Como voltar atrás?

Antes de executar, pergunte ao criador do script se já existe um plano de restauração do estado inicial (fallback). Se não existir, sugiro que você crie um. Mesmo que o requisitante diga que não precise ou que não será necessário, o DBA precisa se garantir.Por exemplo, o script vai atualizar dados de uma tabela. Antes de executar, faça uma cópia dessa tabela para uma tabela backup. Depois que executar o script, que o objetivo for validado, você até pode deletar o backup, mas seria ainda melhor se você o guardasse, por exemplo, por 1 semana ou 1 mês (dentro dos limites de espaço do seu ambiente).

Pode ser que, no momento após a execução do script, não se note problema, mas dias depois alguém perceba que algo está errado.

 

4) Ao final do script…

Observe se o caractere de término para execução do script existe. Se for um bloco anônimo tem que ter essa barra ‘/’ ao final (vide esse post aqui). Para comandos SQL, as linhas precisam conter o ‘;’ ou o ‘/’ ao final. Se o script não é finalizado corretamente, pode te causar confusão achando que está executando quando nem foi iniciado ainda.

 

Você tem outra sugestão de precaução que podemos tomar? Diz aí nos comentários ou manda um email!