Há alguns anos tive uma
reunião com um consultor da IBM chamado Antoine. O
sujeito era belga, e seu português era tão perfeito quanto o meu inglês. Ou seja,
passamos uma tarde praticamente nos comunicando por mímica e desenhos de flipchart.
De qualquer forma, o papo foi
sobre o gerenciador de banco de dados DB2 e muito produtivo, até que Antoine
fez uma pergunta que me desconcertou:
- Sua empresa tem uma rotina
corporativa para controle de commit?
Não tínhamos, é claro, mas
comecei a refletir sobre o assunto.
Na mesma linha do texto sobre bind, vou tratar aqui desse outro termo
estranho, o commit, sobre o qual
conversamos bastante nos cursos de Performance
SQL que ministramos na TI do Banco
do Brasil.
Numa tradução livre, commit significa “confirmação”. No mundo
DB2, trata-se exatamente disso. Ao executar uma instrução insert, delete ou update, o dado é fisicamente incluído,
excluído ou alterado da tabela (podendo inclusive ser
“enxergado” por outras instâncias). No entanto, somente após o commit a operação é efetivada.
Inversamente, o rollback, desfaz o
comando executado.
No ambiente mainframe,
principalmente, o commit e o rollback são instruções “caras” em
termos de processamento, porém são indispensáveis à estabilidade do ambiente
produtivo e à integridade dos dados processados pelas transações. Um fim inesperado – também
conhecido por abend – de uma rotina
provoca a perda de todas as informações não commitadas.
Existem ainda situações
complexas, em que há mais de um banco de dados
envolvido. Um protocolo denominado two-phase-commit
se encarrega de sincronizar a confirmação dos dados nos diferentes ambientes,
evitando inconsistências na transação.
O commit é importante nas aplicações on-line, mas nas rotinas batch
é ainda mais crítico. Mesmo programadores experientes costumam controlar o commit apenas implementando um contador e um loop a cada bloco de registros – mil ocorrências,
por exemplo. Isso é insuficiente, e vamos explicar o porquê.
A questão é delicada porque,
sob a ótica do desempenho, o commit
deve ser realizado o mínimo possível. Inversamente, se considerarmos o aspecto
da segurança, seria ideal commit a
cada ciclo de processamento. Para atender a essas duas necessidades, portanto, conclui-se
que sua periodicidade deve ser necessária e suficiente, ou seja, um uso
parcimonioso do comando, de forma a haver um equilíbrio entre performance e segurança.
Aqui voltamos ao
questionamento do Antoine. Ao commitar
apenas pelo contador, não sabemos exatamente de quanto em quanto tempo o
comando será executado. Mil registros podem ser processados em segundos ou
horas.
É, pois, fundamental gerenciar
a variável tempo. Como isso requer uma programação um pouco mais elaborada, um
“serviço corporativo” traria uma série de benefícios à TI, encapsulando a
“regras do negócio”, facilitando a codificação, evitando redundância de código,
minimizando a incidência de erros e facilitando os testes.
A partir da sugestão do
consultor da IBM, portanto, concebemos
uma sub-rotina de commit. Essa
importante ferramenta conferiu segurança e melhor desempenho aos programas batch de grandes sistemas corporativos.
Mais alguns lembretes:
- O commit deve ser realizado sempre a
partir do programa mais externalizado, preferencialmente aquele
referenciado no JCL, nunca dentro de uma sub-rotina, pois esta não detém o
controle do ciclo completo do processamento;
- Se um componente
Cobol batch não tem acesso ao
DB2, porém realiza chamada(s) de sub-rotinas Cobol/SQL, sua compilação é
como Cobol puro. No entanto, a procedure deve ser construída como se ele
fosse um Cobol/SQL, ou seja, o JCL o chama via módulo específico do SGBD –
no BB esse módulo é o IKJEFT01;
- Mesmo
com um controle rigoroso, um programa ainda pode ter problema de commit, quando uma instrução SQL
for muito “pesada” e levar um tempo excessivo para ser executada. Nesses
casos, pode ser necessário “quebrar” eventuais joins, subselects e outros comandos em instruções distintas,
ou reavaliar como estão os índices das tabelas envolvidas;
- Boas
práticas orientam o uso do commit
inclusive nos programas que realizam apenas consultas (instruções select). Isso libera recursos do
SGBD, por exemplo, caso outra aplicação esteja esperando para executar um
utilitário sobre o mesmo tablespace.
Bom, desculpem pelo texto excessivamente
técnico, mas essa “escovação de bits” faz parte do dia-a-dia de quem trabalha com TI.
