Nós, DBAs, não existiríamos se não existisse um de grupo pessoas que necessitasse de apoio para usar os serviços de um banco de dados. Estes são os usuários.

Se você não gosta ou tem medo de usuários, certamente você está na carreira errada – se é que existe alguma carreira que trabalhe isolada do resto do mundo.

Os usuários podem ter diversos perfis: consumidores que fazem compras na sua empresa e que acessam o banco de dados sem nem se dar conta disso, gerentes e outros funcionários da empresa que também acessam o banco, além de programadores que criarão novas aplicações acessando esta base.

Existe ao menos uma coisa em comum com todos os grupos de usuários: nem sempre o que eles pedem é exatamente o que eles precisam. Até porque eles não têm obrigação de conhecer profundamente o seu SGBD. Esta obrigação é sua: o DBA.

Recentemente, passei por uma situação destas. Trabalhando como DBA de desenvolvimento num projeto interno, recebi uma solicitação de instalação de uma versão mais antiga do DB2 client, o software cliente usado para se conectar ao DB2. Então, entrei em contato com o desenvolvedor e ele me contou que isso foi uma recomendação de um outro grupo de DBAs, responsáveis pelo banco de dados de onde iríamos extrair dados.

Resolvi perguntar um pouco mais para saber qual era o problema que resolveríamos com esta instalação. Foi ai que meu colega desenvolvedor explicou que, durante minhas férias, eles fizeram alguns testes de exportação de dados acessando o servidor remoto. Nestes testes foram observadas mensagens de erro durante a execução da exportação. O comando dado era

db2 -v “EXPORT TO /tmp/minhatabela.ixf OF IXF SELECT * FROM minhatabela”.

E a mensagem de erro exibida no log do comando era:

SQL3015N  An SQL error “­552” occurred during processing.
SQL0552N  “meuID” does not have the privilege to perform operation “BIND”.
SQLSTATE=42502 SQL3015N  An SQL error “­805” occurred during processing.

Este erro SQL0552N não é crítico para a operação de exportação. O que ocorre é que o ID meuID está executando uma declaração SQL junto com o comando EXPORT. Sendo assim, o DB2 procura compilar e automaticamente salvar esta declaração como um pacote de instruções. Muitas vezes, nos referimos a estes pacotes como “planos de acesso” ou “planos de execução”. A mensagem de erro informa que o ID meuID pode executar o SQL, mas o plano de execução não pode ser salvo pelo DB2.

Resolvi fazer alguns testes por conta própria e confirmei que esta era a única mensagem de erro durante todo o processo e que ela não impedia a criação do arquivo com os dados exportados, como eu já esperava.

Conversando novamente com o desenvolvedor, ele confirmou que este era o único erro que ele havia observado em todo processo. Ele também confirmou que, quando viu a mensagem, ele entendeu que o processo tinha sido abortado.

De fato, é fácil entender porque ele teve esta impressão. É exatamente neste ponto da operação que o arquivo de exportação começa a ser criado e realmente demora para exportar centenas de milhares de registros que estão armazenados num servidor remoto. (Nosso caso, esta demora era superior a 60 segundos).

Identificado o problema, tivemos uma conversa entre o desenvolvedor, o líder técnico e eu, onde expliquei para o impacto da mensagem de erro que estávamos vendo, ressaltando que isso não impedia que a exportação fosse realizada. Concluímos que não iríamos dedicar esforço para solucionar aquele problema, visto que ele não teria impacto direto no projeto e, por essa razão, não era prioritária uma ação prioritária.

Moral da história: pergunte ao seu usuário o porquê de cada requisição que ele faz; isso pode ajudar sua empresa ou seu projeto a economizar tempo e dinheiro.

Para mais informações sobre o utilitário BIND do DB2, veja este fórum ou leia este artigo do DEVELOPERWORKS.