Optimizando Desempenho No SQL Server 2005

SQL Server: os dez principais segredos de um especialista em SQL Server

Manter um ambiente do SQL Server é um empreendimento potencialmente complexo. Aqui estão as dez principais maneiras pelas quais você pode minimizar a complexidade e diminuir o estresse.

Paul S. Randal

Várias empresas reduziram seus departamentos de TI ao longo dos últimos anos. E muitos administradores de bancos de dados (DBAs) acabaram se tornando responsáveis por um grande número de bancos de dados do SQL Server. O que é pior, muitas vezes as empresas não têm nenhum DBA. Alguém acaba sendo considerado um DBA involuntariamente. Em alguns casos, o DBA acaba entrando em um modo de apagar incêndios, passando de uma situação de crise para outra. Esse tipo de ambiente é difícil, tóxico e insustentável. Ninguém gosta de ficar em constante pressão e de ser interrompido toda hora.

Uma forma de sair desse tipo de situação é investir um pouco de tempo na otimização do seu ambiente do SQL Server para torná-lo mais fácil de compreender e gerenciar. Com base na minha experiência de consultoria no SQL Server, apresento a seguir as 10 principais maneiras pelas quais um DBA do SQL Server pode assumir o controle de seu ambiente e reduzir o potencial geral de ocorrência de crises. A lista é apresentada seguindo uma ordem de importância.

10. Faça um inventário

Quantas vezes você já foi solicitado a restaurar dados danificados em um banco de dados que você nem sabia que existia? Os bancos de dados do SQL Server se espalham pela empresa com uma facilidade incrível. A equipe de DBAs pode perder o controle dos bancos de dados que existem, resultando em instâncias não gerenciadas do SQL Server. O resultado disso são bancos de dados sem backup, sem patches e sem a segurança apropriada, bem como a ausência de um host para outras tarefas de gerenciamento necessárias.

É essencial ter um inventário atualizado das instâncias e dos bancos de dados que você possui na empresa sob o seu controle. Essa é a única forma de você gerenciá-los de forma adequada, fazer a consolidação quando necessário, bem como definir corretamente os planos e o escopo de projetos e atualizações. O inventário também o ajuda a definir limites para suas responsabilidades por meio da publicação de uma lista de instâncias conhecidas sob sua responsabilidade, com a concordância das várias equipes em sua organização. Você pode definir políticas de suporte para as instâncias conhecidas e fazer com que as novas instâncias atendam às diretrizes de configuração para que você possa dar suporte a elas.

Existem várias ferramentas que podem ajudá-lo a criar um inventário do SQL Server — de ferramentas simples, como o SQLPing3 e o SQLRecon, até o Microsoft Assessment and Planning Toolkit e o Quest Discovery Wizard.

9. Padronize as configurações

Se o número de bancos de dados e instâncias do SQL pelos quais você é responsável não para de crescer, você descobrirá que o número de diferentes configurações cresce de maneira similar. É extremamente difícil trabalhar com eficiência ao se mover de instância a instância se você tem que se lembrar toda hora dos detalhes de configuração das diferentes instâncias.

A solução é padronizar sua configuração ao máximo em termos de letras de unidades, opções de configuração do servidor, configurações de bancos de dados, manutenção de bancos de dados, configurações de segurança e assim por diante. O SQL Server 2008 foi o primeiro a incluir o recurso Gerenciamento com base em políticas para ajudar a definir e aplicar políticas. Lara Rubbelke, uma especialista em tecnologia do SQL Server na Microsoft, também criou o Enterprise Policy Management (EPM) Framework, que estende com facilidade os recursos de instâncias do SQL Server 2005 e do SQL Server 2000. O EPM Framework pode ser encontrado no CodePlex. A Figura 1 mostra um relatório de exemplo do EPM Framework.

Figura 1 O relatório do Enterprise Policy Management Framework

8. Compreenda o subsistema de E/S

Há vários fatores relacionados ao subsistema de E/S que podem afetar suas instâncias do SQL Server. Você precisa conhecer esses fatores e o impacto potencial que eles têm:

• A capacidade do subsistema de E/S em relação à taxa de transferência de leitura/gravação e ao espaço em disco. Ele deve ser capaz de atender à demanda de cargas de trabalho em horários de pico e, ao mesmo tempo, fornecer espaço para que o volume de dados cresça antes que seja necessário adquirir mais capacidade. Ao identificar os gargalos de E/S e mover os dados e/ou arquivos de log para outras partes do subsistema de E/S, você pode balancear melhor a carga.

• Os recursos de redundância do subsistema de E/S quanto ao nível do RAID e se ele pode executar tarefas como backups de espelhamento dividido e qualquer forma de espelhamento/replicação (no nível do subsistema de E/S, não no nível do SQL Server). É importante proteger seus dados e arquivos de log contra falhas de unidade e outros problemas potenciais. É uma troca — o RAID-10 oferece uma melhor redundância em comparação com o RAID-5, mas também é mais caro. Leia o white paper “Design do armazenamento de banco de dados físico” para obter mais orientações.

• Se o subsistema de E/S foi configurado corretamente no que diz respeito ao tamanho da faixa de RAID, ao tamanho da unidade/cluster de alocação do NTFS e ao alinhamento da partição. Confira esta postagem de blog, “Seus deslocamentos de partição de disco, os tamanhos da faixa de RAID e as unidades de alocação do NTFS foram definidos corretamente?”, para obter mais detalhes.

7. Crie um plano de manutenção personalizado

Sempre que eu dou aulas sobre manutenção de bancos de dados, sempre começo dizendo: “Você não pode simplesmente colocar um banco de dados em produção e virar as costas”. Os índices ficam fragmentados com o passar do tempo, o que leva à degradação do desempenho. As estatísticas ficam desatualizadas, o que leva a planos de consulta ineficientes e um baixo desempenho. Os subsistemas de E/S podem ser danificados, e há a eterna necessidade de backups.

Você pode contornar todos esses problemas tendo um plano de manutenção abrangente adequado aos seus bancos de dados. Um plano personalizado é muito melhor do que um genérico que não atende adequadamente às suas necessidades. O meu artigo de agosto de 2008 da TechNet Magazine, “Principais dicas para uma manutenção eficiente do banco de dados”,