none
REorganize/Rebuild Index RRS feed

  • Pergunta

  • Boa tarde!

    Uma dúvida que não consegui clarear lendo foruns MS e outros, artigos e etc..

    Fazendo um "Rebuild Index", automaticamente faria o que o "Reorganize Index" faz? ou seja, o resultado final será o mesmo?

    A dúvida é pois o "Reorganize" tranforma um arquivo de log de 50MB para 4.7GB, o modo da base é "recovery full", no modo simple não acontece isto!!

     

    Obrigado,

    • Movido Gustavo Maia Aguiar terça-feira, 21 de setembro de 2010 18:42 (De:SQL Server - Desenvolvimento Geral)
    terça-feira, 21 de setembro de 2010 17:14

Respostas

  • Boa tarde Rafael,

    O rebuild index e o reorganize agem de formas diferentes. O Reorganize desfragmenta o nível de folha (leaf level) dos índices clusterizados e não clusterizados, reordenando-os fisicamente. Esse processo não altera (cria/remove) as paginas, apenas reordena os indices dentro dela, conforme jah mencionsado. O Rebuild deleta os indices e recria-os novamente. Esse processo altera as páginas, removendo as fragmentações e colocando-as de forma contígua. Na maioría das vezes o tamanho do banco de dados (mdf) diminui de tamanho, porque as fragmentações foram removidas...

    Quanto ao arquivo de log crescer em modo full, isso é "normal", jah que todas as transações do banco de dados são logadas (incluindo o processo de rebuild)... e no modo simples , as transações são "minimamente" logadas...

    Espero ter ajudado,

    Rafael Melo

     

    • Marcado como Resposta rafael.dev terça-feira, 21 de setembro de 2010 19:51
    terça-feira, 21 de setembro de 2010 17:59
  • Bom dia Rafael,

    "melhorar o desempenho de uma base o ideal é realmente executar as 2 tarefas certo".... Não. Quando vc executa o rebuild ele recria o indice, removendo então toda fragmentação, reordenando-os. Nesse caso não havería necessidade alguma do reorganize pq o rebuild jah fez o trabalho.

    Agora, é obvio que o rebuild é mais custoso que o reorganize, porém é mais eficiente . O que muitos DBA's fazem é compor uma rotina de manutenção onde se verifica o percentual de fragmentação de cada índice e se caso o indice tiver, por exemplo, com 30% ou mais de fragmentação, executa-se então o rebuild, senão, o reorganize.

    Quanto ao shrink no modo de recuperação FULL, vc poderá fazer um "backup de log" antes. Ai ele encolhe.

    att.
    Rafael Melo

    • Marcado como Resposta rafael.dev quarta-feira, 22 de setembro de 2010 12:04
    • Editado Rafael S. Melo quarta-feira, 22 de setembro de 2010 12:04
    quarta-feira, 22 de setembro de 2010 11:44

Todas as Respostas

  • Boa tarde Rafael,

    O rebuild index e o reorganize agem de formas diferentes. O Reorganize desfragmenta o nível de folha (leaf level) dos índices clusterizados e não clusterizados, reordenando-os fisicamente. Esse processo não altera (cria/remove) as paginas, apenas reordena os indices dentro dela, conforme jah mencionsado. O Rebuild deleta os indices e recria-os novamente. Esse processo altera as páginas, removendo as fragmentações e colocando-as de forma contígua. Na maioría das vezes o tamanho do banco de dados (mdf) diminui de tamanho, porque as fragmentações foram removidas...

    Quanto ao arquivo de log crescer em modo full, isso é "normal", jah que todas as transações do banco de dados são logadas (incluindo o processo de rebuild)... e no modo simples , as transações são "minimamente" logadas...

    Espero ter ajudado,

    Rafael Melo

     

    • Marcado como Resposta rafael.dev terça-feira, 21 de setembro de 2010 19:51
    terça-feira, 21 de setembro de 2010 17:59
  • Entendi, então com o intuito de melhorar o desempenho de uma base o ideal é realmente executar as 2 tarefas certo?

    No meu caso, estou programando o agendamento de um "plano de manutenção", do wizard do SQL 2008. Meu único problema é o Log.

    Vou ver se consigo fazer uma rotina para setar o modo recovery para Simple, executar o rebuild/reorganize e logo alterar para modo full novamente antes de o backup FULL, pois logo tem os logs backups de tempo em tempo. Assim evitando o crescimento do arquivo de Log da base e perder o link entre um log e outro do backup.

    PS: O comando shrick não reduz o log quando faço o Reorganize em modo recovery full, apenas se eu executar outras rotinas que tenho aqui (ex: setar simple no wait.... sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1...... setar full)

     

    Obrigado novamente,

    terça-feira, 21 de setembro de 2010 19:51
  • Bom dia Rafael,

    "melhorar o desempenho de uma base o ideal é realmente executar as 2 tarefas certo".... Não. Quando vc executa o rebuild ele recria o indice, removendo então toda fragmentação, reordenando-os. Nesse caso não havería necessidade alguma do reorganize pq o rebuild jah fez o trabalho.

    Agora, é obvio que o rebuild é mais custoso que o reorganize, porém é mais eficiente . O que muitos DBA's fazem é compor uma rotina de manutenção onde se verifica o percentual de fragmentação de cada índice e se caso o indice tiver, por exemplo, com 30% ou mais de fragmentação, executa-se então o rebuild, senão, o reorganize.

    Quanto ao shrink no modo de recuperação FULL, vc poderá fazer um "backup de log" antes. Ai ele encolhe.

    att.
    Rafael Melo

    • Marcado como Resposta rafael.dev quarta-feira, 22 de setembro de 2010 12:04
    • Editado Rafael S. Melo quarta-feira, 22 de setembro de 2010 12:04
    quarta-feira, 22 de setembro de 2010 11:44
  • Blz! obrigado..

    tirou todas as minhas dúvidas,

    Só uma obs quanto ao shrink no modo de recup FULL, mesmo fazendo o backup do log, o arquivo de LDF não encolhe rodando o shrink depois que o "Reorganize Index" é executado (criado no wizard).. Não sei se é porque a base é replicada, mas somente com o comando que postei anteriormente é que consigo reduzir um log de 4GB para 1MB por exemplo.

    Ex: Antes do reorganize 1MB (LDF), depois 4.7GB.

    A base é pequena ainda, < que 4GB, da ultima vez que executei, o Reorganize gastou 13:31min e o Rebuild 4:26min. Logo vou deixar só o Rebuild na rotina por enquanto.

     

    Obrigado,
    Rafael Silva

    quarta-feira, 22 de setembro de 2010 12:03
  • Rafael, Se você está utilizando a opção shrink para diminuir o arquivo de log, acredito não ser necessário deixar seu recovery model como FULL, assim evitando o gerenciamento do mesmo. Alterando para Simple, você não irá se preocupar mais com o crescimento do log.
    segunda-feira, 2 de maio de 2011 16:31