Performance e Otimização de Aplicações Através do Banco de Dados

Performance e Otimização de Aplicações Através do Banco de Dados

Neste artigo o principal objetivo será mostrar os passos para a obtenção de uma melhor performance da Aplicação através do Banco de Dados.

Acho que todos que trabalham na área de desenvolvimento de sistemas, já sofreram com a “lentidão” do sistema na hora de realizar a busca de dados no Banco de Dados. O problema pode estar em alguns fatores físicos (problema de conectividade ou de hardware) ou em fatores lógicos (Erros na Aplicação ou mal desempenho do Banco de Dados).

Os problemas mais comuns são causados por:

• Erro de Comunicação;
• Erros na aplicação;
• Erros nas queries;
• Problemas no hardware;
• Modelagem de dados incorreta;
• Recursividade/Duplicidade de dados;

Tais problemas não podem em hipótese alguma tornarem-se comuns dentro do seu ambiente. Por isso segue uma lista das soluções da qual você deve tomar para evitar a continuidade de tais problemas.

1) Modelagem do Banco de Dados:

Uma má performance geralmente é resultado de uma modelagem ruim. É importante se preocupar com a modelagem, pelo menos até a 3FN (Terceira Forma Normal).

2) Tuning de Aplicação, Lei do 80/20 dos Bancos de Dados:

Por mais que os desenvolvedores reclamem do servidor de banco de dados, em 80% dos casos o problema está na aplicação e em 20% no SGDB. Não que a aplicação seja ruim em si, mas ela pode não usar o SGDB de forma eficiente. Existem várias formas de se obter os mesmos dados de forma ineficiente. Pior, uma consulta que funcionava bem num SGDB pode ter uma performance catastrófica em outro SGDB. Infelizmente isto pode ocorrer também com migrações para outra versão do mesmo SGDB. Mesmo assim, a culpa ainda não é do SGDB. A aplicação que tem (infelizmente) de adaptar às especificidades de cada fornecedor e cada versão. Somente otimize o SQL depois que tiver certeza que o código está correto.

3) Lei do 80/20 da informática

Cerca de 20% dos parâmetros de configuração do seu SGDB são utilizados em 80% do tempo. Aprenda a manejar bem estes parâmetros antes de mais nada. A maioria dos outros parâmetros são utilizados em ocasiões específicas e não tem um impacto tão forte no desempenho. Normalmente o tuning do SGDB começa por estes parâmentros mais importantes, os demais só são utilizados se você conhece especificidades da sua aplicação que sugerem o seu uso, caso contrário são deixados em seus valores padrão.

4) Conheça o perfil das suas aplicações

A forma como a sua aplicação utiliza o seu SGDB é de suma importante para o DBA. Existem alguns padrões que lhe indicam caminhos já trilhados por outros. Sendo assim identificar o tipo de carga que a aplicação projeta sobre o banco de dados é muito importante. Aqui alguns tipos clássicos:

• OLTP ou On Line Trasactional Processing: consiste na maior parte da carga das aplicações corporativas atuais. É caracterizado por um grande volume de pequenas transações conconrretes e alto volume de gravações. As cargas OLTP são as que tem o desempenho de disco mais crítico.
• BI ou Business Inteligence: consistem num universo paralelo com diversas tecnologias como Data Mining, OLAP, Data Warehouse, Data Mart e Balanced Scored Card. A questão é que quando falamos em BI, o banco de dados sempre acaba de um jeito ou de outro, tendo que suportar consultas enormes, com grande quantidade de dados e cálculos complexos. As cargas de BI exigem muita velocidade em leitura de disco, memória para ordenações e uso intenso do processador.
• Sites Web Dinâmicos: os sites dinâmicos são aqueles que armazenam o seu conteúdo num banco de dados. Desta forma um único acesso numa página web pode representar uma dúzia de pequenas leituras no banco de dados. As cargas de sites web são caracterizadas por um enorme número de conexões simultâneas realizando pequenas leituras.
• Operações em lote ou batch: são cargas de trabalho intensas no banco de dados que podem durar várias horas para se completar e tem um grande impacto na performance. São comuns tanto em aplicações OLTP (cálculo de uma folha de pagamento, fechamento de ano fiscal, etc), como em BI (carga de grandes tabelas vindas de fontes externas). As cargas em lote sempre são alvos de estudos cuidadosos tem o potencial de crescer rapidamente em tempo de execução até inviabilizar os negócios da empresa.

5) Tuning de I/O Físico:

Arquivos de Banco de Dados precisam estar com o tamanho correto e em um local que prove um mínimo de I/O.

6) Elimine Contenção de Dados:

Eliminar ao máximo eventos que realizam contenção de dados, chamados de Wait Events ou Eventos de Espera. Pode-se classificá-los em dois tipos:
Físico: Evento espera disco rígido ou de uma quantidade de memória disponível ou de acesso a rede, por exemplo, para que seja concluído.
Lógico:Evento espera recursos computacionais para que seja concluído. Como por exemplo:Lock – O mecanismo de lock (trava), é um conceito aplicados à MultiUsuário, onde quando é iniciada uma transação, o usuário irá travar o banco para ele até que a transação se efetivada(commit) ou rejeitada(rollback).

Latch – É um mecanismo de alocação de estruturas na memória SGA (System Global Area) serializado e desenhado para que sejam alocados por curtos períodos de tempo. Ele controla os vários processos que desejam acessar áreas compartilhadas da SGA, permitindo que somente um processo de cada vez acesse a estrutura requisitada, evitando corrupção da memória, ou seja, mantendo a integridade.

7) Melhorar os comandos de busca

7.1) Padronização

Garanta que os comandos sejam escritos absolutamente iguais para facilitar a reutilização no banco de dados. O re-parsing no banco de dados pode ser evitado para cada uso subseqüente.

Ex:

SELECT * FROM EMP;

É diferente de:

Select * From Emp;

SELECT * from EMP;

Procure trazer do banco de dados somente as informações necessárias, e por mais que a linguagem SQL não seja case sensitive, busque sempre padronizar suas pesquisas. Lembre-se: Se você não precisa da informação contida em uma coluna específica, não é preciso trazê-la.

Procure otimizar primeiro os SQL mais críticos. Não gaste tempo otimizando códigos que nunca ou raramente serão usados.

7.2) Utilização de Índices

Use índices, mas não os crie em demasia. Muitos índices podem resultar em um efeito adverso na performance. Lembre-se de escolher o tipo de índice mais adequado a cada situação. O critério básico para escolha de índices é a seletividade. Quando o banco de dados resolve uma consulta, freqüentemente, ele precisa percorrer mais registros do que aqueles realmente retomados pela consulta. Os registros percorridos que forem rejeitados representam o trabalho perdido. Quanto menor for o trabalho perdido, mais perto estaremos da performance ótima para resolver a consulta.

Portanto, o melhor índice para uma consulta é aquele que apresenta a maior seletividade.Construa os índices a partir das restrições dos SELECT (cláusula WHERE); Lembre-se que as comparações usando “<>”, “NOT”, “NULL”, “LIKE” podem invalidar o índice.

7.3) Não faça nada muito complexo caso desnecessário

Realize a divisão das queries complexas em queries menores. Evite lógicas complexas de negócio no SQL. A lógica deve ficar no código fonte. Lembre-se que: SQL não é uma linguagem procedural.

7.4) Evitem comandos SORT (Ordenação ou Agregação)

Use os comandos que produzem sort (Group By, Order By, Distinct, etc.) somente quando necessário. No sort, o banco recupera todas as informações necessárias primeiro e depois as ordena.

7.5) Mude a maneira de pensar

Os comandos “EXIST” e “NOT EXIST” possuem menor custo do que os comandos “IN” e “NOT IN” na maior parte dos casos. Quando a maioria dos filtros estiver na sub-query o comando “IN” se torna mais eficiente.

Procure usar “EXISTS” ao invés de “DISTINCT”.

Use:
SELECT dept_no, dept_name
FROM dept d
WHERE
EXISTS (SELECT ‘X’
FROM emp e
WHERE e.dept_no = d.dept_no);

Ao invés de:

SELECT DISTINCT dept_no, dept_name
FROM dept d, emp e
WHERE
d.dept_no = e.dept_no;

Toda vez que houver função na coluna, o índice não será usado.

Use: WHERE cargo = rtrim(1);

Ao invés de:

WHERE rtrim(cargo) = 1;

Evite comparar dados incompatíveis. O SQL Server converte automaticamente os campos char e number, mas evite utilizar este recurso.

8) Finalizando

Fica válido que quando falamos dos conceitos de performance do banco de dados, devemos lembrar que sua Base de Dados está ligada diretamente ao seu SGBD (Sistema Gerenciador de Banco de Dados), e muitas vezes algumas regras de desempenho se aplicam exclusivamente à forma na qual o SGBD foi desenvolvido. Por isso podemos ter resultados de performance diferentes quando realizamos testes com mais de um SGBD.

Espero que tenha ajudado a entenderem um pouco mais sobre performance da Banco de Dados. Foram passados alguns conceitos básicos sobre desempenho do banco de dados, como no ultimo artigo segue uma lista de links onde pode-se aprender mais sobre o assunto:

http://www.macoratti.net
http://www.oracle.com
http://imasters.com.br
http://msdn.microsoft.com
https://www.soe.ucsc.edu
http://www.devmedia.com.br
http://docs.oracle.com
http://www.linhadecodigo.com.br