Tuning
Um pouco sobre ajustes de performance.
Tuning vem do verbo em inglês to tune, que pode ser traduzido como “ajustar”.
Calma, este post não será sobre tuning automotivo … se bem que eu gostaria muito de comentar sobre as rodas e o aerofólio que estou querendo comprar para o meu pálio, rsrs. O assunto agora é Tuning de banco de dados.
Conceito
Tuning de banco de dados refere-se a ações de ajuste no servidor Oracle a fim de prover performance.
As ações de ajuste no banco de dados geralmente são feitas com o sistema já em pé, funcionando a todo o vapor… e com os usuários reclamando que tá tudo lento! O ideal é que o tuning seja feito de forma proativa e diária.
Métodos de tuning
Como dito anteriormente, o tuning pode ser feito por duas razões: Preventivamente ou reativamente. É obvio que tunar o sistema durante sua implementação é o ideal, dentro daquele novíssimo ditado “melhor prevenir do que remediar”. Porém, como todos já sabemos, a maior parte das açoes de tuning é reativa: o usuário final reclama de lentidão, e lá vai o DBA correr atrás do problema, muitas vezes gerando retrabalho.
Porém, não adianta muito analisar um problema isoladamente no banco de dados, e é isso que quero demonstar neste post: Devemos olhar o servidor de banco de dados como um todo, envolvendo o hardware, o sistema operacional, a aplicação e o próprio servidor oracle.
Outra coisa importante: não pense que tuning é uma ação única e definitiva: ele deve ser constante, fazendo parte da rotina de todo administrador de banco de dados.
A Oracle recomenda que seja seguida uma ordem nos passos de tuning, sendo que os passos com maior impacto devem ser realizados primeiro.
Abaixo, os passos (por prioridade de ajuste):
1º – A regra de negócio
2º – A modelagem dos dados
3º – A modelagem da aplicação
4º – A estrutura lógica do banco de dados
5º – As operações do banco de dados
6º – O caminho de acesso
7º – Memória
8º – I/O e estrutura física
9º – Contenção de recursos
10º – Plataforma Base
1 – Regra de Negócio
O planejamento das necessidades de performance correspondem diretamente à necessidade do negócio.
Com as regras de negócio, conseguimos levantar qual a espectativa do numero de usuários concorrentes, o tempo de resposta da transação, o número de dados gravados online que o sistema deverá suportar.
2 – Modelagem dos Dados
Nesta fase, de acordo com as regras de negócio, é importante determinar que tipo de dados deverão ser armazenados. Deverão ser definidos quais os relacionamentos e atributos são importantes para o sistema, consequentemente, as chaves primárias e estrangeiras.
É aqui que são definidos qual o nível de normalização a ser utilizado. Geralmente, normalizar até a 3º forma normal é recomendado, porém, de acordo (de novo) com as regras de negócio, algumas estruturas podem ser desnormalizadas (visando performance)
É neste ponto que você deverá considerar :
a) O particionamento de dados;
b) o uso de índices globais ou locais.
3 – Modelagem da Aplicação
Neste ponto, é necessário “traduzir” os objetivos do negócio em um sistema efetivo. Alguns processos podem tornar-se desde funcionalidades, ou até sistemas completos. É aqui que devem ser consideradas a configuração dos processos individualmente.
4 – Estrutura Lógica
Depois da modelagem do sistema e da aplicação, é a hora de “conceber” o banco de dados. No passo 2, foram definidas as chaves primárias e estrangeiras, e agora é hora de “refinar” estes índices, além de acrescentar índices adicionais para suprimir todas as necessidades da aplicação.
5 – Operações
Agora é a hora de tunar nossas “benditas” queries. No mundo ideal, os desenvolvedores de aplicação (e arquitetos de sistema) deveriam conhecer o funcionamento do Oracle na recuperação dos dados, a fim de escrever códigos sql <<<consistentes>>>. É nesta parte onde estão concentrados os maiores problemas de performance – e onde o DBA mais sofre. Preventivamente, o dba deve acompanhar este processo, orientando os programadores a utilizar corretamente os recursos do banco de dados, como os índices, funções, hints.
Na minha humilde opinião, todo o dba deve explicar -neste ponto- o que é o Oracle Optmizer ( nos próximos posts irei falar sobre ele, nosso maior amigo).
6 – Caminho de Acesso
Neste passo, deve ser assegurado o acesso eficiente aos dados, considerando o uso de clusters, hash clusters, índices B-Tree e indices de bitmap.
7 – Memória
Este ponto diz respeito à correta alocação de memória para as estruturas do servidor Oracle, como o dicionario de dados, library cache, buffer cache, entre outras.
É aqui onde muito DBA comete o terrível erro de alocar mais memória para a SGA do que o sistema tem disponível, afetando o desempenho do Sistema Operacional, além de causar terríveis swappings…
8 – I/O e estrutura física
É um problema que afeta o desempenho do servidor como um todo. O processo de tuning de I/O e estruturas físicas envolve, entre outros coisas, a distribuição dos dados de acordo com os dispositivos existentes, evitando contenção de disco.
A sugestão da IBM para distribuição de discos é a separação dos dados, conforme abaixo:
* Tablespaces de dados
* Tablespaces temporárias
* Segmentos de redo log
* Dados do aplicativo
* Índices de aplicativos
9 – Contenção de Recursos
Processamento concorrente causado pelo acesso de multíplos usuários pode causar contenção de recursos do Oracle.
Deve-se ter atenção aos seguintes tipos de contenção:
* Block contention
* Shared pool contention
* Lock contention
* Pinging (in a parallel server environment)
* Latch contention
10 – Plataforma Base
De acordo com a plataforma escolhida, há ítens que devem ser ajustados. Por exemplo, em ambientes Unix devemos nos atentar a:
* Tamanho do UNIX buffer cache
* Gerenciamento dos Logical volume
* Memória tamanho para cada processo.
Bem, este post é uma introdução à outros que pretendo colocar no site a respeito de tuning, especialmente sobre tuning de aplicação (que é onde tenho mais experiência). Lembrando que os passos acima são recomendações da Oracle e dizem respeito ao mundo ideal (se você está terminando a graduação, é isto que seu professor vai querer encontrar no seu TCC, rsrs).
Então,
Até mais!
Bom dia Lilian..!!
Excelente Post.. Da uma ideia de onde começar um Tunning.. Pois o dificil é quando chegam e falam.. Vamos fazer Tunning do Banco de Dados.. A pessoa se pergunta.. Por onde começar?? O que preciso ver primeiro?
No minha opinião.. Tunning deve ser efetuado tanto pelo DBA quanto pelo desenvolvedor da aplicação.. Pois muitas vezes o que ocasiona a lentidão no banco são conexões mau feitas dos sistemas e/ou instruções SQL que estão “chumbadas” na aplicação e o DBA não tem acesso.. Não adianta o DBA ajustar o I/O em disco.. fazer analyse.. rebuild de indices para uma Tablespace exclusiva de indices.. Criar novos indices.. etc.. e ter uma aplicação modelada de forma errada e com instruções SQL de má qualidade…
O Tunning é algo que envolve muito mais que apenas 1 pessoa.. Para o bem estar em comum.. tanto da aplicação quanto do banco de dados..
Parabens.. =)
A minha maior dor de cabeça são as queries mal elaboradas, principalmente porque o desenvolvedor muitas vezes não conhece Oracle, e conhece pouco de sql (eu fico muito brava com aquelas queries complexas cheias de funções e hints… o pessoal tem que aprender que SQL não é linguagem procedural e o Oracle não é burro!).
Se o DBA se envolver de forma construtiva com o desenvolvedor, muita dor de cabeça seria evitada, para os dois lados.
Isso que você colocou seria o mundo ideal e feliz…
Pena que as pessoas prefiram viver num mundo alternativo, fast food, fast program, fast dor de cabeça…
Tento implementar partes disso que você colocou e a resistência é muito grande, as desculpas são as mais variadas e as conseqüências são as mais desastrosas…
Olá Lílian,
Parabéns pelo post. Acredito que, no mínimo, existam 2 tipos de DBA’s hoje no mercado.
O tipo 1 seria aquele DBA que trabalha no servidor de produção realizando manutenções necessárias de tuning, sugerindo ajustes de memória e I/O quando necessários, realocação de arquivos de banco de dados, criação e execução de políticas de backup/recovery, aplicações de pacthes e correções críticas, entre outras … sem ter uma noção clara de como os SQL’s foram codificados nas aplicações de terceiros executadas no servidor.
O outro tipo de DBA (tipo 2) que é mais o meu caso, é aquele voltado para o desenvolvimento de aplicações na qual é de fundamental importância o conhecimento das regras de negócios de forma a fornecer a melhor solução de banco de dados para um determinado tipo de problema, possuir conhecimentos sólidos de modelagem de dados, sugerir a criação de um padrão de nomenclatura de objetos de banco de dados e conseqüentemente fiscalizar e garantir o uso desse padrão pelos analistas de sistemas e desenvolvedores. Outra tarefa seria a criação de uma política de melhores práticas de construções de instruções SQL, realização de análise de performance dos SQL’s construídos de forma a capturar o melhor plano de acesso aos registros e, assim, realizar os ajustes necessários avaliando a necessidade de criação de índices (btree/bitmap), views materializadas, tabelas/índices particionados, etc…
Em resumo, o trabalho do DBA tipo 2 seria mais de prover suporte à equipe de desenvolvimento, garantindo a qualidade das aplicações desenvolvidas no que se refere ao modelo e acesso ao banco de dados.
Em resumo, acredito que um bom trabalho realizado pelo DBA tipo 2 facilitaria muito, em parte, o trabalho realizado pelo DBA tipo 1.
Abraços …