none
Shrink e Após Rebuild Index Etc... RRS feed

  • Pergunta

  • Pessoal, boa tarde!


    Alguns DBA´s são contra o Shirink pois ocorre a fragmentação dos índices.

    Se eu rodar o Shrink e depois as demais rotinas de índices (refaz índicesetc...), o banco fica melhor ?

     

    Valeu

    Denison



    quinta-feira, 17 de novembro de 2011 19:18

Respostas

  • Oi Denison,

    Vamos por parte. Eu acho inútil a opção de SHRINK dentro de rotinas de manutenção, ou seja, rodar o SHRINK periodicamente é ao meu ver uma perda de tempo. Entretanto isso não quer dizer que ela não tenha nenhuma utilidade.

    Em um mundo ideal sem limitações de storage, sem situações imprevistas e onde o conhecimento da base é 100% conhecido dificilmente o SHRINK seria necessário. Saberíamos previamente quanto e quando a base iria crescer e poderíamos nos planejar com antecedência para fazer as alocações de espaço necessárias e jamais iríamos recuar, ou seja, nunca precisaríamos reduzir nada, pois, com planejamento tudo daria certo sempre. Entretanto, no dia a dia, não é rara a situação em que alguém pede pra criar um banco e não informa nada sobre a volumetria ou ainda a informa de maneira imprecisa. Nessas situações é comum o espaço estourar e aí o SHRINK é necessário, mas veja que isso é uma excepcionalidade e não uma regra.

    Não vivo no mundo ideal, mas posso dizer que no meu ambiente atual onde o planejamento tem uma boa dose de acerto não rodo o SHRINK faz meses. Claro que algumas vezes o espaço estoura, mas muitas vezes, nas janelas permitidas eu movo uma base ou outra de disco (ou amplio o disco extendendo-o). São alternativas para não rodar o SHRINK.

    Outra situação onde o SHRINK é utilizado refere-se a exclusão em massa de dados. Suponha que você tenha uma base de 1TB e vai expurgar 400GB da base e não vai mais precisar desse espaço. Nesse caso não faz muito sentido manter a base em 1TB com 400GB livre. É melhor rodar o SHRINK para que o espaço seja liberado. Não por economia, mas simplesmente porque você realmente não vai utilizá-lo.

    A maioria das pessoas inclui o SHIRNK em rotinas administrativas e isso sim é algo totalmente equivocado (os links não me deixam mentir). A maioria das pessoas que faz isso, o faz por completo desconhecimento do efeitos adversos com a falsa idéia de que é necessário liberar espaço. Liberar espaço pra quê ? O disco já foi comprado mesmo, a energia elétrica é a mesma e os dados são os mesmos. Rodar o SHRINK pra quê ? Não há nada de benefício nisso. Completa ilusão... Reduzir o espaço da base não tras nenhum benefício no ambiente de produção (exceto nas situações que descrevi), pelo contrário, só trás problemas... E infelizmente a maioria das pessoas não sabe disso.

    Rode o sp_helpdb para saber se onde o espaço cresceu (no log ou nos dados)

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Denison Soares sexta-feira, 18 de novembro de 2011 17:10
    sexta-feira, 18 de novembro de 2011 02:15
    Moderador

Todas as Respostas

  • Boa Tarde,

    Alguns DBAs são contra e os outros DBAs simplesmente não sabem que isso acontece, pois, se soubessem seriam contra também. Já foram citados diversos tópicos aqui no fórum dos melhores especialistas em SQL Server e não se trata de ser contra ou a favor. O fato é que o SHRINK introduz fragmentação e isso não é algo saudável. Só é interessante usar o SHRINK quando há uma grande exclusão de dados e o espaço não será reutilizado. Qualquer outra situação não é recomendado. Há situações em que o espaço aumenta e o SHRINK é inevitável, mas isso é muito mais fruto de mau planejamento do que uma necessidade usual do SHRINK.

    Não recomendo rodar o SHRINK após o antes do REINDEX por uma razão muito simples. Se você faz o SHRINK, o arquivo ficará reduzido. No momento em que você rodar o REINDEX, o arquivo precisará crescer e aí o SQL Server vai gastar tempo pedindo mais espaço no SO para poder rodar o REINDEX. Adicionalmente, o arquivo ficará fragmentado em nível de SO, pois, o Windows pode não alocar o espaço contíguamente.

    Rodar o REINDEX e depois o SHRINK é perda de tempo, pois, você fragmenta suas tabelas.
    Rodar o SHRINK e depois o REINDEX é perda de tempo, pois, você fragmenta seus arquivos.

    Então em linhas gerais, não rode o SHRINK como parte de suas rotinas de manutenção. Tremenda perda de tempo... O disco não vai durar mais tempo porque você liberou espaço. Você paga por espaço comprado e não por espaço alocado. Não há economia de energia porque o HD está mais vazio... Não há benefício nenhum nisso:

    Data file shrink does not affect performance
    http://sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(930)-data-file-shrink-does-not-affect-performance.aspx

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

    Stop Shrinking Your Database Files. Seriously. Now
    http://www.brentozar.com/archive/2009/08/stop-shrinking-your-database-files-seriously-now/

    Here's a good reason not to run SHRINKDATABASE...
    http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/06/13/629059.aspx

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 17 de novembro de 2011 20:16
    Moderador
  • Gustavo, deletei vários registros de várias tabelas do meu banco. E... engraçado... O tamanho do banco estava em 148 GB e foi para 170 GB. O espaço disponível estava em 12 GB e foi para 21 GB. Deveria diminuir...

     

    Se eu rodar o Shrink, ele não vai ver esse espaço alocado e vai comprimir?

     

    Obs.:  Minha base de dados já existe há vários anos e nunca executei sequer um plano de manutenção. Estou analisando sobre rodar as opções do plano de manutenção neste fds... mas tô na dúvida se também rodo e sse bendido shrink...

     

    Sugestões?

     

    Obrigado,

    Denison Soares

     

    quinta-feira, 17 de novembro de 2011 21:07
  • Boa Noite,

    Provavelmente o seu banco aumentou porque o arquivo de log cresceu e aí o tamanho do banco cresceu (ainda que os dados tenham diminuído). O espaço disponível (para dados) aumentou já que você excluiu dados liberando área útil.

    Se você rodar o SHRINK você irá diminuir o seu banco em uns 21GB, mas eu pergunto vale a pena ? Se seu banco ficar com zero de espaço livre quando você inserir novos dados ele vai precisar crescer de novo. Por que não já deixar esse 21GB de sobra ? Isso evitaria que o arquivo MDF crescesse fragmentado e que o SQL Server tivesse de pedir o SO mais espaço. 21GB em 170 representa apenas 12% e penso que 12% de margem é uma margem razoável.

    Não vejo razão com base no seu contexto para rodar o SHRINK. O seu banco não ficará mais rápido por conta desse espaço, sua conta de luz não vai diminuir, seu storage não irá durar mais e seu backup também não ficará mais rápido (aréa livre e esparsa e o backup despreza esse espaço). Agora se você rodar o SHRINK, quando o banco precisar crescer, há grandes chances do MDF fragmentar e aí não tem comando T-SQL que remova essa fragmentação em nível de arquivo.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 17 de novembro de 2011 22:10
    Moderador
  • Gustavo, obrigado pela resposta!

    Pra que existe essa opção Shrink e porquê todo mundo utiliza ela? Por que a Microsoft não remove do Produto?

    Kra, eu falei para meu gerente que após a deleção desses arquivos o espaço alocado iria diminuir e cresceu! O kra vai me matar! Huahuauhahuah

    Pelo menos não tem como voltar ao norma? kkkk aos 148 GB?


    Valeu !!

    Denison

    quinta-feira, 17 de novembro de 2011 22:45
  • Oi Denison,

    Vamos por parte. Eu acho inútil a opção de SHRINK dentro de rotinas de manutenção, ou seja, rodar o SHRINK periodicamente é ao meu ver uma perda de tempo. Entretanto isso não quer dizer que ela não tenha nenhuma utilidade.

    Em um mundo ideal sem limitações de storage, sem situações imprevistas e onde o conhecimento da base é 100% conhecido dificilmente o SHRINK seria necessário. Saberíamos previamente quanto e quando a base iria crescer e poderíamos nos planejar com antecedência para fazer as alocações de espaço necessárias e jamais iríamos recuar, ou seja, nunca precisaríamos reduzir nada, pois, com planejamento tudo daria certo sempre. Entretanto, no dia a dia, não é rara a situação em que alguém pede pra criar um banco e não informa nada sobre a volumetria ou ainda a informa de maneira imprecisa. Nessas situações é comum o espaço estourar e aí o SHRINK é necessário, mas veja que isso é uma excepcionalidade e não uma regra.

    Não vivo no mundo ideal, mas posso dizer que no meu ambiente atual onde o planejamento tem uma boa dose de acerto não rodo o SHRINK faz meses. Claro que algumas vezes o espaço estoura, mas muitas vezes, nas janelas permitidas eu movo uma base ou outra de disco (ou amplio o disco extendendo-o). São alternativas para não rodar o SHRINK.

    Outra situação onde o SHRINK é utilizado refere-se a exclusão em massa de dados. Suponha que você tenha uma base de 1TB e vai expurgar 400GB da base e não vai mais precisar desse espaço. Nesse caso não faz muito sentido manter a base em 1TB com 400GB livre. É melhor rodar o SHRINK para que o espaço seja liberado. Não por economia, mas simplesmente porque você realmente não vai utilizá-lo.

    A maioria das pessoas inclui o SHIRNK em rotinas administrativas e isso sim é algo totalmente equivocado (os links não me deixam mentir). A maioria das pessoas que faz isso, o faz por completo desconhecimento do efeitos adversos com a falsa idéia de que é necessário liberar espaço. Liberar espaço pra quê ? O disco já foi comprado mesmo, a energia elétrica é a mesma e os dados são os mesmos. Rodar o SHRINK pra quê ? Não há nada de benefício nisso. Completa ilusão... Reduzir o espaço da base não tras nenhum benefício no ambiente de produção (exceto nas situações que descrevi), pelo contrário, só trás problemas... E infelizmente a maioria das pessoas não sabe disso.

    Rode o sp_helpdb para saber se onde o espaço cresceu (no log ou nos dados)

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Denison Soares sexta-feira, 18 de novembro de 2011 17:10
    sexta-feira, 18 de novembro de 2011 02:15
    Moderador
  • Gustavo, executei o Shrink e a base diminui uns 30 GB. Mas evitarei executá-lo em planos de manutenção períodico.

     

    Obrigado pelas respostas!

     

     

    []'s

    Denison Soares

    sexta-feira, 18 de novembro de 2011 17:10