locked
Maintenance Plan SQL Server 2005 RRS feed

  • Pergunta

  • Eu gostaria de saber quais management plan são recomendáveis para uma boa performance e manutenção de uma base de dados. Algumas pessoas me falaram que eu devo sempre schedular o reibuild index, reorganize index e update statistics. No entanto, gostaria de saber se eu devo schedular mais algum, como schrink, checar consistência de base, etc. E qual deve ser a ordem, por exemplo, devo executar primeiro o reorganize, depois o rebuild e por último o update statistics?

    Obrigado,

    Ralph


    Ralph Nogueira Haddad
    sexta-feira, 19 de março de 2010 18:16

Respostas

  • Com relação ao Shirink, a recomendação é não usar ele.

    Pelo seguinte, com a utilização do banco, os dados são incluidos, alterados e excluidos, com isso o SQL vai alocando espaço.

    Quando é feito um REBUILD INDEX, o SQL ajusta os espaços vazios que estão no meio do DATAFILE, para alocá-los ao final do DATAFILE, fazendo com que os dados fiquem de forma continua dento do DATAFILE.

    Com isso em uma proxima inclusão ou alteração de dados, ao inves do SQL tentar aumentar o tamanho do DATAFILE ele irá penas utilizar os espaços vazios ao final, isso gera um ganho de performance visto que não haverá uma nova alocação de espaço.

    Com relação do Transaction Log, vale o mesmo comentário, quando é realizado um Backup Full, as informações do Transaction Log são eliminadas, isto é, o tamanho do Transaction Log continua o mesmo, mas ele irá estar cheio que espaço vazio, que poderá ser utilizado pelo SQL apos o Backup Full, de modo que se você realiazar um Backup Full por dia, e analizar o tamanho do do seu Transaction Log, o crescimento dele do segundo dia em diante irá ser bem pequeno, até que irá chegar em um ponto que não crescerá mais.

    Quanto é executado um Shirink o SQL elimina todos os espaços vazios do DATAFILE e do Transaction Log, obrigando o mesmo, quanto necessário a fazer uma nova alocação de espaço em disco.


    Alexandre Baseio Se a minha ajuda lhe for útil não esqueça de classificar.
    sexta-feira, 26 de março de 2010 13:29

Todas as Respostas

  • Olá Ralph!

     

    O comando ALTER INDEX...REBUILD, "dropa" e recria o índice.

    O parâmetro STATISTICS_NORECOMPUTE = OFF, "seta" que as estatísticas serão recalculadas automaticamente.

     

    O ideal é você analisar as tabelas índices para determinar qual e quando devem ser recriados.

     

    Atualizar as estatísticas e reogranizar os índices são boa práticas a ajudam a melhorar o desempenho das queries e que assim como o REBUILD, devem ser analizados individualmente (tabela/índice).

     

    Eu particularmante, o utilizo o DBCC SHRINKDATABASE com a opção NOTRUNCATE para não devolver o espaço liberado do arquivo de dados para o sistema operacional. Com o crescimento do seu banco de dados, aquele "pedaço" será necessário para o SQL Server e o arquivo de dados vai se fragmentando.

    Eu procuro criar os bancos de dados, já com o seu tamanho previsto levantado no CAPACITY PLAN, para evitar esta fragmentação.

    segunda-feira, 22 de março de 2010 17:47
  • Bom dia Daniel,

    Eu estou com algumas dúvidas.

    Quando eu executar o rebuild index em seguida eu devo executar o reorganize, ou devo executar ou um ou o outro e não os dois em sequência.

    Qual seria a melhor sequência para um banco que há muita fragmentação e para outro que há pouca fragmentação, por exemplo:

    Muita fragmentação - 2 schedules - 1 para rebuild index e outro para update statistics

    Pouca fragmentação - 2 schedules - 1 para reorganize index e outro para update statistics

    Ou eu devo executar o rebuild e em seguida o reorganize?

    Referente ao shrink eu tenha a seguinte dúvida, as bases que realmente tem uma alta transação de dados eu tenho uma rotina de backup com pouca perda.

    Por exemplo: 1 backup full diário, backup diferencial para cada hora e backup transacional a cada 10 minutos, mas isto são para as bases que tem um alto processamento e não pode praticamente haver perda de dados. Normalmente o .ldf (log) não cresce muito desta forma. De qualquer forma é importante executar o shrink database? ou é apenas para casos em que há muito crescimento de log? Fora o rebuild, reorganize, update statisitcs, shrink, existe mais algum maintenance plan que é recomendável?

    Obrigado e desculpe pelo excesso de questionamentos.

    Ralph

     

     


    Ralph Nogueira Haddad
    terça-feira, 23 de março de 2010 12:08
  • Bom dia,

    Por favor, caso alguém saiba alguma coisa as dúvidas que eu tenho, eu fico agradecido.

    Obrigado,

     

    Ralph


    Ralph Nogueira Haddad
    sexta-feira, 26 de março de 2010 11:53
  • Ralph,

     

    Eu particularmente utilizo todos os recursos e componentes do Plano de Manutenção, acredito que assim, poderia garantir o meu ambiente mais seguro, integro, atualizado e com performance aceitável.

    Os dos principais itens que gosto de utilizar é a parte de fragmentação e reindexação da base se dados.


    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    sexta-feira, 26 de março de 2010 13:06
    Moderador
  • Com relação ao Shirink, a recomendação é não usar ele.

    Pelo seguinte, com a utilização do banco, os dados são incluidos, alterados e excluidos, com isso o SQL vai alocando espaço.

    Quando é feito um REBUILD INDEX, o SQL ajusta os espaços vazios que estão no meio do DATAFILE, para alocá-los ao final do DATAFILE, fazendo com que os dados fiquem de forma continua dento do DATAFILE.

    Com isso em uma proxima inclusão ou alteração de dados, ao inves do SQL tentar aumentar o tamanho do DATAFILE ele irá penas utilizar os espaços vazios ao final, isso gera um ganho de performance visto que não haverá uma nova alocação de espaço.

    Com relação do Transaction Log, vale o mesmo comentário, quando é realizado um Backup Full, as informações do Transaction Log são eliminadas, isto é, o tamanho do Transaction Log continua o mesmo, mas ele irá estar cheio que espaço vazio, que poderá ser utilizado pelo SQL apos o Backup Full, de modo que se você realiazar um Backup Full por dia, e analizar o tamanho do do seu Transaction Log, o crescimento dele do segundo dia em diante irá ser bem pequeno, até que irá chegar em um ponto que não crescerá mais.

    Quanto é executado um Shirink o SQL elimina todos os espaços vazios do DATAFILE e do Transaction Log, obrigando o mesmo, quanto necessário a fazer uma nova alocação de espaço em disco.


    Alexandre Baseio Se a minha ajuda lhe for útil não esqueça de classificar.
    sexta-feira, 26 de março de 2010 13:29