oracle

Evite repetições de acesso ao banco de dados

“Se não for necessário acessar o banco de dados para obter informações, não o faça”

Geralmente algumas tabelas da aplicação possuem informações estáticas, ou seja, nunca sofrem (ou sofrem com pouquíssima frequência) comandos DML: são informações que sofrem leituras (SELECT) a todo momento.

Se essas informações não sofrem alterações, porém precisam ser lidas constantemente, a equipe de desenvolvimento deve fazer um esforço em conjunto com o DBA para minimizar esta freqüência de acesso banco de dados; afinal, se as informações não são alteradas, por que repetir as consultas?

Na aplicação, procure armazenar esses valores comumente acessados em variáveis locais. É muito mais rápido e eficiente o acesso a uma variável local do que um acesso ao banco de dados, que consome recursos do servidor (CPU, memória, I/O) e da rede.

Um típico caso são as telas de formulários de entrada de dados complexos, em que uma boa parte dos campos são preenchidos por uma consulta separada para cada campo. Exemplo: tabelas de CEP, Estados, Cidades, Sexo, Estado Civil. Imagine que um usuário final trabalhe unicamente fazendo cadastros de cliente, fazendo inserções constantemente, o dia todo. A cada campo desses preenchido, um SELECT executado. E se a empresa for grande e tiver 100 funcionários fazendo isso? Multiplique por 100 o número de SELECTs executados por cada um, o dia todo.

Agora imagine se todas essas informações são carregadas para a memória local do Client somente na primeira inserção, logo de manhã, e que esses dados fiquem persistentes na memória local do Client até o final do dia! Além da enorme agilidade para preenchimento do cadastro por parte do usuário (afinal, os dados estão em memória e não necessita constantes consultas ao banco de dados), que constantemente reclama de lentidão do sistema, os recursos do servidor podem ter um alívio enorme de CPU e tráfego de rede.

Este foi apenas um exemplo para ilustrar a possibilidade de eliminar acessos desnecessários ao banco de dados. Apesar de parecer simples, este tipo de erro é cometido com muita freqüência por desenvolvedores.

–

Este post também foi baseado em um trecho do livro Oracle Database 11g – Manual do DBA (Bob Bryla).

Milton Bastos é DBA Oracle e Desenvolvedor PL/SQL, dividido entre Apucarana/PR e Curitiba/PR. Certificações: OCA (Oracle 11g DBA Certified Associate), Oracle Database 11g Data Warehousing Certified Implementation Specialist, Oracle Database 11g Sales Specialist Assessment, Oracle Database Appliance PreSales Specialist Assessment, Oracle Database Appliance Sales Specialist Assessment