![[Oracle] Tuning durante o projeto: boas práticas (parte 3)](https://certificacaobd.com.br/wp-content/uploads/2012/03/oracle_dest.jpg)
Evite conexões repetidas ao banco de dados
“Mantenha as conexões abertas. Reutilize sempre que possível”
Sabe aquela conexãozinha rápida que o teu aplicativo abre com o banco, só pra fazer um selectzinho rápido, e já fechar a conexão?
Pois é, pense duas vezes antes de fazer isso. É muito importante saber a frequência que essa operação será realizada. Abrir uma conexão e fechá-la pouco tempo depois pode não ser muito custoso, porém, e se ela se repetir milhares de vezes ao dia? Não seria melhor manter a conexão aberta?
O custo de abrir a conexão em alguns casos é maior do que os próprios comandos que são executados dentro desta conexão. Para exemplificar, vou usar valores hipotéticos:
– Imagine que um aplicativo abre uma conexão apenas para executar um select, de custo 20. E que o custo para se abrir essa conexão é de 150. Se isso é feito poucas vezes ao dia, por exemplo, 10 vezes ao dia, o custo total será de 1700: ((10 x 150) + (10 x 20)).
Considerando que 10 vezes ao dia é uma freqüência muito baixa, vale a pena. Afinal, durante a grande parte do dia em que não está sendo executada uma dessas 10 vezes, não há uma conexão aberta exclusiva para a tarefa. E esta conexão consome recursos do servidor.
– Agora imagine que o mesmo aplicativo executa esta operação 3.000 vezes ao dia. O custo total, considerando os mesmos valores, seria de ((3000 x 150) + (3000 x 20)) = 510.000.
E se manter uma conexão aberta constantemente?
((1 x 150) + (3000 x 20)) = 60.150.
Ou seja, “economizamos” 449.850.
Essa economia compensa o recurso usado pela conexão aberta constantemente.
Este é apenas um exemplo bem simples em que não considero alguns fatores que existem na prática. Alguém poderia perguntar: mas como manter uma conexão exclusiva e reutilizá-la com milhares de clients rodando o sistema? Isso depende da arquitetura. Se a aplicação rodar sob um servidor de aplicação web, por exemplo, as conexões ficam apenas entre o servidor de aplicação e o banco de dados. E nesta arquitetura é fácil criar um pool de conexões abertas constantemente, em que todos os clients conectados usem esse pool.
Em breve postarei um artigo sobre Pool de Conexões usando Java, um exemplo prático.
Use os índices corretos
“Criar muitos índices não é sinônimo de boa performance”
Alguns desenvolvedores criam vários índices em cada tabela, com a intenção de diminuir a quantidade de leituras físicas durante os Select’s. Muitos desses índices talvez nunca sejam usados, por não serem necessários, para dar suporte às consultas. Com isso, esses índices impactam em um custo maior em outras operações: inserts, updates e deletes. O problema fica ainda mais evidente em grandes cargas de dados, que ficam muito mais lentas devido a inserção de valores nas árvores dos índices.
O uso de índices bitmap não é recomendado em sistemas OLTP, mesmo que a coluna tenha poucos valores distintos. Neste caso, deixe esta coluna sem índice.
–
Este post também foi baseado em um trecho do livro Oracle Database 11g – Manual do DBA (Bob Bryla).
