Desmistificando o BIND

Todas as vezes que converso com alguém de TI sobre BIND, percebo que esse é um conceito extremamente vago para a maioria das pessoas, mesmo em se tratando de analistas e programadores experientes.

Há algum tempo, coloquei numa prova uma questão em que perguntava qual o significado dessa estranha palavra. A maioria dos alunos marcou a opção relacionada à sigla  Binary INteractive Dynamic, algo sem o menor sentido. Na realidade, até existe um acróstico para o termo -Berkeley Internet Name Domain – mas se trata, no entanto, de um servidor para o protocolo DNS.

Estamos falando de outra coisa. Vou tentar explicar tudo em linguagem  coloquial, lembrando que, dependendo da área de tecnologia envolvida, podemos ter significados diversos, mas sempre com o sentido de “ligação”.

Bom, delimitando o escopo, neste contexto vamos tratar de bind como o processo de conexão de um programa com um banco de dados. Utilizaremos o exemplo de um módulo Cobol/SQL acessando o DB2 em ambiente mainframe.

Dentro do código, consideremos duas instruções hipotéticas:
MOVE 1 TO GDA-SDO
EXEC-SQL SELECT NOM FROM DB2XXX.CLIENTE WHERE SALDO = :GDA-SDO 

Ao compilarmos o programa, um dos primeiros passos é a pré-compilação, que varre o código-fonte, identifica as instruções de diferentes linguagens e realiza alguns procedimentos, quais sejam:

1. Extrai do programa Cobol a linha do EXEC-SQL, substituindo-a pela chamada de uma subrotina que irá realizar o acesso ao DB2;

2. O fonte Cobol, após a pré-compilação, ficará mais ou menos assim:

 MOVE 1 TO GDA-SDO

CALL “Interface-DB2” + Parâmetros (incluído na linkedição)

3. Todas as instruções SQL extraídas dão origem a um outro arquivo-fonte, denominado DBRM (Data Base Request Module);

4. Os dois fontes recebem um timestamp com o exato momento da geração dos dois arquivos (um com as instruções Cobol e o outro com o  SQL). Isso é necessário para que, em tempo de execução, quando o programa fizer requisições ao banco de dados, o mesmo se certifique de que tudo faz parte de uma mesma versão. Havendo divergência, o DB2 retorna o “famoso” SQLCODE -805;

5. O bind é simplesmente a criação do plano de acesso do programa ao BD, ou a geração de um executável (o package) a partir do fonte DBRM relacionado. Esse executável normalmente tem o mesmo nome do programa de origem.

Portanto, ao executarmos o programa e este  chegar à instrução SQL, o módulo de carga Cobol, na prática, chama (vide CALL acima) a interface com o DB2 “pedindo” o seguinte:

- Acesse o “package” com o meu nome/timestamp para o meu SELECT com as variáveis que estou lhe passando e me retorne o resultado.

É importante ressaltar que aqui estamos falando de bind “estático”, ou seja, aquele que é realizado previamente à execução, no momento em que o programa é instalado em cada ambiente. Isso é extremamente importante, pois desonera a aplicação de traçar sua estratégia de acesso às tabelas no momento em que o usuário está utilizando o sistema (mais adiante falaremos de bind dinâmico). 

Em cada ambiente produtivo (desenvolvimento, teste, produção, etc) há um bind específico, utilizando o mesmo DBRM.

Mas por que fazer um novo bind em todos os ambientes, ao invés de se reutilizar o package gerado no desenvolvimento? Porque cada ambiente tem seu próprio DB2, com características específicas, e o processo considera diversas informações do catálogo, como a existência de índices, a quantidade de registros da tabela e até a variedade de conteúdos dos campos das tabelas.

Quer dizer que o bind deve ser mais demorado conforme envolva tabelas grandes, pois o DB2 analisa cada linha? Não! Ao se rodar o utilitário RUNSTATS, todas as estatísticas das tabelas necessárias ao bind são consolidadas e gravadas no catálogo do DB2, e essas sim, são utilizadas na geração do package.

Por conta disso é que, como o conteúdo dos bancos de dados é muito dinâmico, faz-se necessário a realização periódica de RUNSTATS e REBIND, para que, a partir do mesmo DBRM, o DB2 reavalie sua estratégia de acesso e gere novo package.

Por fim, quando falamos em bind dinâmico, estamos nos referindo à realização, em tempo de execução, de todo o processo de decisão do DB2 quanto à forma de acesso aos dados, o que pode causar degradação de performance na aplicação, ou mesmo sua indisponibilidade.

Costumo dizer que o bind dinâmico é, na realidade, a ausência de bind, embora não seja bem isso. Até porque, quando uma classe de persistência Java chega ao mainframe via JDBC (Java Database Conector), por exemplo, a primeira execução é bastante onerosa, mas o plano gerado fica em cache e é reutilizado nas chamadas subseqüentes.

Bem, o assunto vai longe, acredito termos abordado o essencial.