oracle

Mais da metade dos casos de problemas de desempenho do banco de dados são criados em uma aplicação.

Muitas vezes o arquiteto da aplicação não conhece a forma de uso dos dados pela empresa, e este comportamento resulta na geração de componentes que causam fraco desempenho, alguns já fase inicial do projeto, como numa versão inicial da aplicação (por exemplo), enquanto outros problemas aparecem à medida em que o uso da aplicação aumente junto com o volume de dados.

Em alguns casos a correção pode ser simples, como a alteração de um parâmetro de inicialização ou criação de um índice, por exemplo. Em outros casos esta correção pode exigir maiores esforços, chegando ao extremo de necessitar alterar a arquitetura da aplicação.

Vou citar agora algumas “boas práticas” que podem ajudar (e muito) no desempenho de aplicações e que devem ser pensadas desde a fase inicial do projeto.

Faça o mais simples possível

“O foco do seu projeto não deve ser a perfeição teórica do projeto; ele deve estar sempre na habilidade do usuário final de executar seu trabalho.”

Simplifique os processos. Um modelo de dados perfeitamente normalizado tende se tornar um fracasso de desempenho. Tente sempre chegar a um formato em que os dados estejam armazenados da forma mais parecida possível com que o usuário final deseja que eles sejam inseridos e recuperados. O usuário final não se importa se as estruturas do banco estejam normalizados de acordo com  Terceira Forma Normal.

Procure não fugir muito de um modelo de dados bem gerenciável, mas lembre-se que a principal meta é o bom funcionamento da aplicação e sua capacidade de atender necessidades de desempenho.

Elimine leituras lógicas desnecessárias

“Nenhuma leitura física ocorre a menos que as leituras lógicas as requisitem.”

Estamos “acostumados” a nos preocupar com I/O físico, e com razão, pois leitura e escrita física requerem um cuidado todo especial. O primeiro passo para eliminar I/O desnecessário pode ser exatamente a preocupação com leituras lógicas: eliminando leituras lógicas desnecessárias, eliminamos também leituras físicas desnecessárias. Além disso, diminuirá o consumo de CPU.

Mas como diminuir o número de leituras lógicas? Como saber se o aplicativo está realizando consultas lógicas desnecessárias?

O arquiteto deve saber identificar casos em que isso pode ocorrer. E como nas outras dicas deste post, isso pode (e deve) ser feito ainda durante o projeto. Um típico caso de leituras lógicas desnecessárias é quando um mesmo query select é executado com muita frequencia (milhares, milhões de vezes ao dia), porém retornando o mesmo valor repetidamente a vários usuários diferentes. Uma das formas de otimizar é utilizar uma variável global em uma package, apenas para citar um exemplo de possível solução.

–

Referência bibliográfica:

Oracle Database 11g – Manual do DBA, de Bob Bryla e Kevin Loney

Todos os posts desta série são baseados neste livro, que indico fortemente a compra por DBA’s de todos os níveis.

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