quinta-feira, 10 de junho de 2010

Performance Tuning no SQL Server

Olá,

gostaria de abordar um tema que está começando a gerar interesse de muitos administradores de banco de dados: "performance tuning" ou melhoria de desempenho.

Seu banco de dados está crescendo, o servidor fica cada dia mais lento, você começa a procurar as possíveis causas da lentidão, e se pergunta: onde está o problema ?

Raramente, a resposta é simples.
Encontrar um serviço/processo rodando no servidor que está tomando muito tempo de CPU; anti-virus; baixar a última atualização; são alguns exemplos... mas convenhamos, é praticamente uma loteria.

Na maioria dos casos, o problema está relacionado a vários fatores.

Sem olhar seu sistema, eu diria que 90% dos problemas relacionados a performance estão na sua aplicação.

Portanto, faça sua lição de casa, e revise seu código, seu modelo de dados, sua metodologia de acesso aos dados, a forma de exibição, etc.

No mais, segue abaixo uma lista de boas práticas para manter seu servidor com uma boa performance.

As primeiras dicas são as que estão ao seu alcance, e não há necessidade de desembolso... em seguida, outras dicas que exigem um pouco de investimento.

1) Básicas:
- mantenha seu Windows com o último Service Pack disponível;
- mantenha seu SQL Server com o último Service Pack disponível + pacotes acumulativos (CUs);
- disponha de uma janela de manutenção mensal, onde você vai reindexar sua base de dados, com base no índice de fragmentação das tabelas mais críticas;
- desfragmente seu disco rígido também, com o serviço SQL Server desligado;
- se o seu database é grande (acima de 10Gb por exemplo), separe as tabelas por Filegroups, e distribua quando possível, estes Filegroups em discos rígidos diferentes;
- configure o anti-virus do servidor SQL Server para não escanear as pastas onde estão os arquivos MDF/NDF e LDF dos databases, tampouco as pastas dos System Databases;
- não instale impressoras no servidor SQL Server;
- evite compartilhamento com outras aplicações, isole seu servidor única e exclusivamente para o serviço SQL Server;
- coloque os Filegroups em outro disco rígido, assim como o TempDB;
- desligue as opções de Auto-Close e Auto-Shrink de cada database;
- revise as tabelas, de forma que as mesmas tenham Primary e Foreign Keys bem definidas, índices que estejam sendo utilizados;
- centralize o código, utilizando Stored Procedures - esta prática também evita tráfego de rede, deixando o processamento no servidor e retornando somente o resultado para aplicação;
- evite o uso de Cursores, prefira operações baseadas em blocos (set-based);
- faça backups completos diariamente.

2) Avançadas ($$$):
- adquira mais discos rígidos, você vai precisar para RAID e também para separar os arquivos;
- prefira RAID nível 10 (espelhamento e distribuição);
- disco rápido é SAS (antigo SCSI) - fuja de IDE e SATA;
- se puder, adquira uma unidade Storage (SAN, EVA, etc);
- compre memória RAM: o ideal é que o SQL Server trabalhe sempre utilizando o "cache", portanto, quanto mais memória melhor;
- não há uma recomendação padrão, pois os ambientes podem variar muito (OLTP e OLAP), mas sempre faço uma conta básica: 2GB de RAM para o sistema operacional; e o restante, pelo menos 25% da soma do tamanho dos databases para Buffer Pool do SQL Server, isto evita paginação;
- ou seja, se a soma dos seus databases for de aproximadamente 100GB, seu servidor SQL deveria ter em torno de 24GB de RAM (mínimo de 16GB, e ideal 32GB);
- particione as tabelas "gigantes", utilizando o recurso do próprio SQL Server, "partitioned tables"; para isto você vai precisar da versão Enterprise.

É claro que os tópicos apresentados são muito superficiais, e necessitam de um estudo adequado para cada caso, a idéia aqui foi dar uma "pincelada" nos principais.

Sinta-se à vontade para entrar em contato, e expor suas dúvidas, ou contribuir com mais alguma dica, terei maior prazer em publicar.

Obrigado, abraços e até a próxima!
Péricles Sevegnani.

Um comentário:

Richard disse...

Tu sabe que eu tenho aqui o melhor software contábil do mundo né? Aquele com "banco de dados" proprietário que não dá pra fazer nada disso que você escreveu. Bom, eu comprei um disco SSD pra ele! Outra coisa, pelo menos no MySQL, nunca fazer um Join com Views...