IGTI Blog
A hora da DR com a equipe de desenvolvimento

A hora da DR com a equipe de desenvolvimento

Sim, discutir é importante! E o diálogo entre os times em busca de um bem comum deve ser praticado com frequência e sempre que se fizer necessário.

Não são incomuns casos em que o Administrador de Banco de Dados (Database administrator – DBA) se vê as rusgas com a equipe de desenvolvimento… e não quero aqui apontar quem tem a razão ou quem está certo ou está errado. Quero, a partir desse ponto, destacar situações que considero pertinentes nesse convívio e também determinar responsabilidades de um e de outro.  Sabemos que construir um sistema não é tarefa simples e que exige grande esforço da empresa desenvolvedora para concluí-lo, são várias sessões com o usuário para o levantamento de requisitos, construção de modelos, organização de projetos e equipes, enfim exige-se muito trabalho para todos os envolvidos e em muitos casos com muita pressão associada, quer seja por causa de prazo, quer seja por causa de desempenho ou ainda por rendimento das equipes. Toda essa situação pode servir como um catalisador para discussões de méritos ou deméritos.

Entretanto, devemos ter em mente a existência de responsabilidades próprias de cada envolvido no processo, o que não quer dizer que ele não possa contribuir com outros atores. Quando limitamos esse ensaio a dois atores apenas (DBA e Desenvolvedor) temos que perceber a importância de termos uma aplicação enxuta e bem estruturada de modo a minimizar o esforço do banco de dados. E a equipe desenvolvedora deve se preocupar, por exemplo, com o número de conexões que a aplicação faz com o banco de dados, com a possibilidade de aproveitar dados já lidos pela aplicação, ou ainda com a concorrência gerada pelos múltiplos acessos e minimizar possíveis bloqueios de registros interdependentes entre os usuários.

De certo modo, existem responsabilidades que devem ser atribuídas à aplicação e consequentemente à equipe desenvolvedora, o que de certa forma minimiza a participação do responsável pelo banco de dados, mas não a exclui por completo, uma vez que ele pode auxiliar os desenvolvedores com feedbacks dos tempos e custos dos comandos originados da aplicação, com o conhecimento dos fundamentos de banco de dados, com sugestões de otimização de comandos e recomendações de criação de índices por exemplo.

A equipe desenvolvedora deve estar atenta aos seguintes pontos:

  • Transações demoradas – uma transação não pode demorar, nem por causa da insatisfação do usuário e nem porque, quanto mais demorada ela for maior a chance de trazer impactos (bloqueios) as demais transações. Pois, quanto maior for um número de bloqueios maior será a chance de haver dependência do registro bloqueado e a consequência disso é potencializar o número de ocorrência de usuários travados ou sem êxito em suas ações e desse modo trazendo insatisfação na utilização do sistema. Para essa primeira situação há sempre uma predileção por acusar o banco de dados como o causador do problema e isso pode se revelar uma grande injustiça, pois o bloqueio e o tempo de sua ocorrência podem estar diretamente relacionados à lógica do próprio sistema. Para esse conflito é necessário que juntamente o DBA e o desenvolvedor discutam ferramentas e metodologias para o correto apontamento do originador do problema e juntos encontrar meios para sua solução.
  • Transações sem commit – o desenvolvedor deve ter cuidado redobrado com esse tipo de transação, pois a falta da efetivação dos comandos gera bloqueio de registros e consequentemente afeta as transações concorrentes. Outra situação em que a falta de commit pode representar problemas é na realização de rotinas batch no qual um grande volume de alterações é realizado e geralmente consumindo horas de processamento. O ideal é que essas rotinas tenham pontos de efetivação, de modo que quando uma falha ocorrer, a rotina será retomada a partir desses pontos e não do início, o que poderia ser inviável devido a janela de tempo disponível para isso. Para essa situação é fácil perceber a pouca efetividade do DBA sobre a rotina, de tal modo que a responsabilidade pode ser quase exclusivamente do responsável pela rotina, talvez a única colocação pertinente do DBA seja indicar a melhor janela para o início da rotina, ou em último caso propor o desmembramento da rotina para serem executados em momentos diferentes.
  • Transações concorrentes – embora sejam comuns e até desejáveis, pois a concorrência é condição para o paralelismo, devemos ter o cuidado para que a concorrência não signifique problema de falta de recursos. Assim, como os demais recursos, o banco de dados também tem um limite e este limite deve ser respeitado pela equipe de desenvolvimento, caberá aqui ao DBA conscientizar a equipe de desenvolvimento e tentar manter as coisas dentro de parâmetros viáveis a aplicação e ao próprio banco de dados. Naturalmente, uma vez que é pertinente a todas as aplicações, o crescimento do volume de dados e transações exigem do DBA esforço para aquisição e liberação de novos recursos para o sistema
  • Transações distribuídas – Muitas aplicações já fazem uso de processamento distribuído, o que significa o uso de mais de uma máquina para processar as informações trazendo desempenho ao sistema. Entretanto, essas aplicações necessitam de algoritmos especiais para fazer o balanceamento das operações e para manter a consistência dos aplicativos. Cabe aqui a reunião interdisciplinar entre as equipes de desenvolvimento, de infraestrutura, de sistema operacional e de banco de dados para o consenso da melhor estratégia de uso desse cenário. Você deve reparar que o cenário proposto com processamento distribuído apresenta-se como o melhor dos mundos, entretanto se mal dimensionado ou mal parametrizado pode reter enfileiramento de processos e ocasionar transtornos às aplicações, tanto que não são raras as histórias de aplicações sofrerem downgrades por baixo desempenho em cenários teoricamente muitos superiores.
  • Transações em massa – já foi falado da existência de rotinas de massa que são executadas geralmente em horários alternativos com pouca concorrência de processamento, isto porque, normalmente são pesadas e demoradas. Além das preocupações comuns aos demais processos, nas rotinas batch devemos nos preocupar com a janela de tempo disponível para concluí-la. É sempre bom, haver concordância no uso compartilhado do servidor, especialmente em situações onde o consumo de recursos ocorre por um período significativo. Pois é fácil perceber que quanto maior o tempo de uso dos recursos da máquina (por exemplo evolução de contratos) maior a chance de haver colisões de interesses, por exemplo a necessidade de execução de rotina demasiadamente longa em desfavor de uma rotina de backup, sem dúvidas representa um cenário no qual ambos atores têm razão no próprio pleito.

Minha intenção era mostrar situações de prováveis conflitos entre equipes causados por prejuízo a um ou a outro. Devemos levar como aprendizado principal que todos compartilham os mesmos recursos e estão sujeitos a abusos de tal modo que, respeitando as necessidades do próprio sistema, deverão arbitrar em favor do bom uso desses recursos.

O dever do DBA é zelar pelo bom funcionamento do banco de dados, mas isso não lhe garante o título de dono do banco de dados. Este também deve ser um colaborador dentro do cenário.

Professor autor: Gilberto Assis