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”, mostra como construir um bom plano de manutenção. O melhor ponto de partida para criar seu próprio plano de manutenção é o script abrangente e gratuito de Ola Hallengren. Isso é o que eu recomendo aos meus clientes.

6. Garanta a segurança do seu sistema

Investir tempo na descoberta proativa de problemas de segurança é essencial para evitar incidentes e não precisar ter que lidar com eles mais tarde. Outro dos meus artigos da TechNet Magazine, “Problemas e soluções comuns de segurança do SQL Server”, lista os 10 problemas de segurança mais comuns e mostra como evitá-los. Além disso, não se esqueça de aplicar os patches nos seus sistemas quando descobrir vulnerabilidades.

5. Tenha um bom relacionamento com seus desenvolvedores

Normalmente, um dos principais pontos de tensão em qualquer departamento de TI ocorre entre a equipe de DBAs e a de desenvolvimento. Os dois grupos geralmente não entendem as prioridades e preocupações um do outro — de prazos de desenvolvimento a decisões de design do SQL Server. Opiniões divergentes sobre responsabilidades e problemas de comportamento e desempenho relacionados à implantação e ao suporte são relativamente comuns.

Você pode tornar seu trabalho muito mais simples se envolvendo de forma proativa e produtiva com a equipe de desenvolvimento. Organizar sessões de treinamento mútuas funciona muito bem, especialmente se isso for feito de forma a evitar acusações. Realize revisões de design com a presença de alguém da equipe de DBAs e teste o código de forma adequada antes de colocá-lo em produção, para tentar evitar erros graves que possam desgastar ainda mais os relacionamentos interequipes.

4. Desenvolva uma estratégia abrangente de recuperação de desastre

Não importa o quão segura a sua infraestrutura possa ser, é necessário ter um plano de contingências caso ocorra um desastre. Você não tem como prever corrupções, quedas de energia, incêndios, perda acidental de dados ou inúmeros outros problemas potenciais. Você precisa de um plano para lidar e se recuperar desses problemas.

Trabalhe em conjunto com sua gerência para definir cláusulas de tempo de inatividade e perda de dados nos contratos de licença de software dos seus bancos de dados, planeje como recuperar dados em vários cenários de perda de dados e determine o papel dos seus bancos de dados e de todas as instâncias do SQL no plano de continuidade dos negócios da empresa. Defina a importância relativa de todos os bancos de dados e de todas as instâncias para que seja possível priorizar a recuperação de desastre.

Você precisará também implementar tecnologias que irão ajudá-lo a determinar a ocorrência de problemas, como somas de verificação de página, verificações de consistência, alertas do SQL Agent e do System Center Operations Manager. Essa infraestrutura de recuperação de desastre o ajudará a proteger os dados com backups, envio de logs, replicação e espelhamento de bancos de dados; e, potencialmente, fazer o failover para um sistema redundante com espelhamento de banco de dados ou clustering de failover. Existem dois white papers da Microsoft que podem ajudá-lo com isso: “Alta disponibilidade com o SQL Server 2008” e “Arquiteturas comprovadas do SQL Server para alta disponibilidade e recuperação de desastre.”

3. Faça e teste os backups regularmente

Não importa o quão bom seja o seu plano de alta disponibilidade e recuperação de desastre, o backup regular dos seus bancos de dados não pode ser evitado. Caso seu banco de dados seja destruído ou fatalmente corrompido, seu único recurso poderá ser restaurá-lo a partir do conjunto mais recente de backups. Portanto, se você não tiver feito nenhum backup, sua empresa poderá sofrer as consequências. Você não só precisa fazer os backups, mas também deve praticar a restauração regularmente para ter certeza de que ela funcionará quando necessário.

Você pode obter mais informações sobre esse assunto nos dois artigos que escrevi para a TechNet Magazine em 2009: “Noções básicas sobre backups do SQL Server” e “SQL Server: recuperando-se de desastres usando backups”.

2. Monitore e mantenha o desempenho

O ajuste do desempenho toma a maior parte do tempo de um DBA, mas há várias formas de otimizar o processo:

• Defina uma linha de base de desempenho para que você possa verificar se o desempenho realmente mudou.
• Divida o sistema em primitivos para que você possa medir isoladamente sem a incerteza de fatores externos.
• Use a metodologia de aguardar na fila para determinar rapidamente problemas de desempenho.
• Monitore o desempenho com primitivos do sistema, contadores de desempenho e estatísticas de espera. Dessa forma, você saberá quando o desempenho começar a se degradar. Use o recurso Coletor de Dados de desempenho no SQL Server 2008 e o Dashboard de Desempenho do SQL Server 2005.
• Defina um plano de manutenção.
• Planeje e execute cuidadosamente sua estratégia de indexação com ferramentas como o Database Engine Tuning Advisor, ou DTA, exibições de gerenciamento dinâmico (DMVs) de índice ausente e DMVs de uso de índices.

1. Saiba onde obter mais informações

Com um lista de tarefas sem fim, é vital que você saiba quando parar e buscar ajuda. Você precisa conhecer suas limitações e aceitar que você não pode saber absolutamente tudo sobre o SQL Server. Não faz sentido bater sua cabeça contra a parede e gastar um tempo precioso quando existe alguém que pode ajudá-lo com a tarefa ou o problema.

Sua fonte de informações número 1 sobre o SQL Server são os Manuais Online do SQL Server, que podem ser baixados e instalados localmente ou pesquisados online no MSDN. Os Manuais Online do SQL Server são ótimos para buscar sintaxe, mas se você tiver uma dúvida prática mais complexa ou estiver tentando solucionar um problema, o melhor a fazer é postar uma pergunta em um fórum online. Existem diversos fóruns do SQL Server no MSDN e sites populares da comunidade como o SQL Server Central.

Outra maneira rápida de encontrar ajuda é conferir a comunidade do SQL Server no Twitter. Poste sua pergunta usando a marca de hash #sqlhelp, que é monitorada por vários especialistas em SQL (inclusive por mim).

Participe de uma conferência específica sobre o SQL Server, como o PASS Community Summit anual, a conferência SQL Server Connections bianual ou o evento mais frequente chamado SQL Saturdays. Confira alguns dos vários blogs mantidos por especialistas no SQL Server da comunidade. Você poderá ter uma boa ideia de quais blogs estão ativos e valem a pena a partir dos rankings de blogs mantidos pelo nosso colega MVP Thomas LaRock.

Talvez você esteja sobrecarregado e estupefato, mas se puder fazer um esforço e seguir essas sugestões, descobrirá grandes benefícios. Seus sistemas serão executados sem problemas, você poderá se organizar melhor e terá mais tranquilidade — e se tornará um DBA mais experiente.

Paul S. Randalé diretor administrativo da SQLskills.com, diretor regional da Microsoft e um MVP no SQL Server. Ele trabalhou na equipe do Mecanismo de Armazenamento do SQL Server na Microsoft de 1999 a 2007. Paul escreveu o DBCC CHECKDB/repair para o SQL Server 2005 e foi responsável pelo mecanismo de armazenamento principal durante o desenvolvimento do SQL Server 2008. Randal é especialista em recuperação de desastre, alta disponibilidade e manutenção de bancos de dados, e participa regularmente de conferências em todo o mundo. Ele mantém um blog em SQLskills.com/blogs/paul, e seu Twitter é o Twitter.com/PaulRandal.

Conteúdo relacionado

• Perguntas e respostas sobre o SQL: mantendo logs e índices
• Perguntas e respostas sobre o SQL: movimentando, ajustando o desempenho, fazendo backup e espelhando bancos de dados
• Perguntas e respostas sobre o SQL: dicas de recuperação de corrupção, conselhos para a redução de bancos de dados e muito mais