Melhores práticas com Maintenance Plans

Recentemente postaram em um fórum uma dúvida sobre planos de manutenção (maintenance plans) do SQL Server, sobre o que cada tarefa fazia e qual o melhor esquema para criar oe mesmos. Resolvi criar um artigo para ajudar a tirar essas dúvidas, uma vez que também já passei por essa situação.

Maintenance plans são conjuntos de tarefas criadas para realizar uma determinada ação, como backup dos databases, atualização de estatísticas das tabelas, verificação de integridade dos bancos, entre outras. Podemos criar os planos individualmente ou agrupá-los em planos separados por tipos, nesse caso o modo como vai ser criado vai da preferência de cada um.

Irei resumir agora os principais planos de manutenção existentes no SQL Server 2008 R2:

CHECK DATABASE INTEGRITY -> executa verificação de integridade dos bancos. Durante essa task são executados os comandos DBCC CHECKCATALOG, DBCC CHECKTABLE e DBCC CHECKALLOC;
REORGANIZE INDEX -> Reordena os índices em tabelas;
REBUILD INDEX -> Dropa os índices atuais e recria novos;
CLEANUP HISTORY -> Remove histórico de informações do banco MSDB, responsável por gerenciar as atividades de manutenção;
UPDATE STATISTICS -> atualiza as estatísticas de consulta às tabelas.

Agora que sabemos o que cada task faz, vem a pergunta: Qual a melhor periodicidade de execução das tasks ?

Nesse ponto, exporei minha opinião, o que uso no meu dia a dia, o que pode não ser o ideal para outros, pois isso vai variar de acordo com o ambiente. Vamos lá:

UPDATE STATISTICS -> não crio um maintenance plan, configuro a opção AUTO UPDATE STATISTICS no database, fazendo com que seja automático;
REORGANIZE INDEX -> Executo 1 vez por dia;
REBUILD INDEX -> a necessidade de execução dessa task depende do percentual de fragmentação dos índices, mas costumo executar essa task 1 vez por semana (de preferência no final de semana e na madrugada);
CHECK DATABASE INTEGRITY -> habilito a execução semanal, porém dependendo do banco (volume de dados) e da criticidade, executo diariamente. Apenas lembrando que essa task não altera nada no banco, apenas faz uma verificação;
HISTORY CLEANUP -> não costumo criar pois ele faz apenas limpeza do histórico de atividades gerenciadas pelo MSDB (backups, execução de jobs, etc.).

Bem, é isso. Em um próximo artigo vou mostrar como criar maintenance plans.

Abraços e até a próxima.

Melhores Práticas com Maintenance Plans – Parte II

Anúncios

2 comentários sobre “Melhores práticas com Maintenance Plans

  1. Oi Angelo,

    Eu já utilizei planos de manutenção e concordo que para algumas situações eles são úteis e práticos. Porém, de uns anos pra cá eu deixei de utilizá-los. Você talvez concorde que os planos de manutenção são de certa forma limitados, não nos oferecem muita flexibilidade, pois isso, passei a utilizar outras soluções.

    Por exemplo, o Ola Hallengre (http://ola.hallengren.com/) possui uma solução bem completa para automatização de rotinas de backup, validação de integridade da base e manutenção de índices. É uma solução um pouco mais complexa que os planos de manutenção, mas em compensação muito mais flexível.

    A Michelle Ufford (@sqlfool) tem também uma solução interessante para tratar de fragmentação de índices. Veja aqui: http://sqlfool.com/2011/06/index-defrag-script-v4-1/

    Outro ponto que vale a pena ser observado é sóbre o shrink. A intenção dele é realmente liberar parte do espaço reservado por um arquivo, espaço que não estaria sendo utilizado. Entretanto, esta operação traz sérias consequências negativas para o seu banco de dados. Vou deixar algumas referências abaixo para validar as consequências desta operação:

    Why you should not shrink your data files
    http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx

    Auto-Shrink – turn it OFF
    http://www.sqlskills.com/BLOGS/PAUL/post/Auto-shrink-e28093-turn-it-OFF!.aspx

    Inclusive, no blog do Paul Randal você irá encontrar outras várias referências sobre este assunto.

    No demais, parabéns pela iniciativa do blog. Seja persistente, estude e se dedique. A comunidade brasileira de SQL Server agradece! ;-)

    Abraços,
    Erickson Ricci (@EricksonRicci)

    • Olá Erickson,

      concordo com sua opinião sobre a limitação dos maintenance plans, porém o uso deles deve ser avaliado de acordo com o ambiente, com poucos databases e alta latência acredito que serão mais práticos para gerenciar. Em relação ao Shrink, como eu coloquei no post, não sou fã desse recurso, mas acho que para ambientes como o citado anteriormente, não irá gerar impacto no desempenho do SQL Server.
      Não conhecia o ola hallengren, vou analisar as sugestões de maintenance plan, afinal conhecimento nunca é demais. (8D
      Obrigado pelas dicas e pelo comentário.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s