1) Modelagem 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
Por: Alfredo Henrique Martins Lopes