Regras Básicas de Tuning de Banco de Dados

Antes de começar a trabalhar é importante ressaltar algumas regras de performance. São elas:
1 - Verifique os problemas de software e hardware antes de mexer com o banco, muitas vezes o hardware não é adequado ou a aplicação não tem um bom fluxograma;

2 - Tenha um enfoque global, entenda todos as partes do sistema (hardware, S.O, rede, Banco de Dados, SQL e a própria aplicação. A baixa performance pode não estar ligada ao Banco e sim aos outro componentes que acabam afetando o banco;

3 - Modifique uma parte de cada vez, divida a tarefa em partes, analise, altere e veja os resultados um de cada vez. Muitas vezes ao modificar vários procedimentos ao mesmo tempo acaba-se dificultando a resolução caso algum imprevisto;

4 - NÃO PRATIQUE TUNING POR ESPORTE. Tuning é coisa séria e um parâmetro mal configurado por onerar ou até mesmo fazer com que o Banco pare de funcionar;

5 – Não tente resolver todos os problemas. Segundo Pareto 80% da resolução dos problemas são resultantes de 20% de ajustes, sendo assim, não perca tempo;

6 - Acima de tudo entenda o seu tipo de aplicação. Aplicações Web, OLTP ou DW requerem atenções diferentes.

CAUSA DOS PROBLEMAS

65% das causas de baixa performance em Bancos de Dados são causadas pelas aplicações. Dificilmente temos no mesmo ambiente um DBA Desenvolvedor ou um Desenvolvedor DBA, sendo assim, muito , mas muito cuidado na criação das consultas.

25% são causados pelos modelos de dados. Banco mal modelado tende a ser terrível. A melhor forma é normalizar o modelo, com isso ganhamos economia de espaço e a não repetição dos dados. Porém é necessário uma análise, pois em relatórios muito grandes não é aconselhável normalização quando falamos de ganho de performance.

5% são problemas do SGDB, acontece do gerenciador do banco não ter um algoritmo eficiente, ou não consegue manter as informações necessárias na memória por tempo eficiente. Atenção na aplicação de patchs e upgrades de versões.

5% são causadas por configurações ou deficiências do Sistema Operacional. Atenção no fluxo da rede, muitas vezes o servidor esta com uma placa de rede não adequada para a quantidade de fluxo de informações que trafega. Verificações de parâmetros de Kernel também são consideráveis, pois o S.O pode não estar deixando o banco escalonar que influencia no impacto do sistema.

TIPOS DE APLICAÇÕES

WEB - O Banco de dados costuma ser menor do que a memória disponível. Por ser pequeno, todo o seu conteúdo cabe na memória As consultas são bem simples e a quantidade de escrita é bem pequena.

OLTP - Nesse caso o Banco é grande e não cabe na memória, podendo chegar a 1TB. 20 a 40% das consultas são de pequeno porte e cresce consideravelmente a quantidade de escrita dos dados em disco.

DW - São bancos de grande porte variando de 100GB a 100TB. Esse tipo de banco tem cargas muito pesadas de dados e a escrita de dados costuma ser por meio de cargas com horários determinados, mas o volume de consultas é grande, sendo que, essas consultas na sua grande maioria sao complexas usadas para alimentação de relatórios.

PRIORIDADES NO SISTEMA OPERACIONAL

Cada tipo de aplicação demanda uma prioridade diferente no sistema operacional, levando-se em contas as considerações acima.

WEB - CPU, RAM, I/O. Na sua maioria o Banco esta em memória, sendo assim, o maior consumo é de CPU para o processamento das informações;

OLTP - I/O, RAM, CPU. A característica desse tipo de banco é justamente o grande volume de gravação em disco. Como grande parte do consumo é de I/O (Disco), deve-se dar uma atenção especial para eles em bancos desse porte. Um equilíbrio entre discos e memória é muito interessante nesse tipo de Banco de Dados;

DW - RAM, CPU, I/O. DataWareHouse tem a característica de ser um banco para consultas, muito usado em soluções de BI. A metodologia de uso de um DW varia de empresa para empresa, mas o ideal seriam cargas com horários pré-determinados (Madrugada, por exemplo) e as consultas durante o dia. Sendo assim o recurso mais consumido é a memória para retornar o valor das consultas, portanto é de extrema importância que o servidor de DW tenha uma quantidade grande de memória para evitar o uso de SWAP.

Obtive parte dessas informações no curso de Tuning de PostgreSQL, mas elas cabem para qualquer que seja o Banco de Dados.

Kenia Milene

3 thoughts on “Regras Básicas de Tuning de Banco de Dados

  1. Boa tarde.

    Li seu artigo e consegui sanar algumas dúvidas.
    Porém, gostaria de saber se você pode indicar-me algum livro ou apostila
    para poder aprofundar-me ainda mais. Você escreveu que fez um curso de Tuning de PostGreSQL. Teria como indicar os materiais utilizados ou passá-los para estudo?
    Trabalho no INEP, Instituto Nacional de Estudo e Pesquisas Educacionais, e temos um projeto que está demandando melhoras no banco.

    Desde já agradeço pela atenção.

    Ricardo Ávila

  2. Olá
    Lí seus artigos e gostei muito na preparaçao de uns artigos que pretendo fazer.
    Gostaria que vc me indicasse ou fornecesse algum material de tunning do postgresql.
    Fico no aguardo.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s