none
Como liberar espaço reservado para a tabela SQL SERVER após grande deleção? RRS feed

  • Pergunta

  • Pessoal, vamos partir do seguinte princípio. A maioria sabe o que é shrink files e database. Sabemos que só liberam unused spaces. Por favor, se esta é (ou seria) a sua resposta, obrigado, mas, é desnecessária. Não resolve o que procuro(amos)

    Li o seguinte post, mas, já está fechado para reperguntar (a pergunta da pergunta):

    • Tinha uma tabela de log que chegou a ocupar 129GB e acabou com o meu espaço. Trunquei a tabela, fiz o shrink e não resolveu. Com isso cai na mesma situação de todos aqui.

    Como resolvi: Dentro do meu database, em Tables, existe um diretório System Tables. Nele continha duas tabelas que foram criadas pelo sqlserver. São as tabelas sysdiagrams e sysssislog. Trunquei as duas e  fiz o Shrink, porém acho que só precisava ter feito da sysssislog. Problema resolvido! meu .mdf ficou com 3MB!!

    Ocorre que o nosso amigo, a quem devo o meu maior respeito, pois foi o único que não rodou em torno de shrinks, parece que tem a solução, mas, responde com conhecimento que não possuo. "O que é truncar??" Qual comando exatamente usou´para "truncar"?? O que faz esse "truncar"?

    OBRIGADO A TODOS E FELIZ 2015.

    segunda-feira, 5 de janeiro de 2015 11:53

Respostas

  • Em tempo (e voltando). O tema é "Como liberar espaço reservado para o SQL SERVER após grande deleção de dados?" (infelizmente o texto ficou ruim e não refletiu bem isto).

    Sabemos que o Shrink no MDF nem sempre libera espaço.

    Sabemos que há system Tables que o SQL Server cria.

    Sabemos que a versão express tem limitações, por isso, sempre bom mantermos o BD em tamanho adequado.

    Olá,

         Sobre o seu post, gostaria de fazer alguns comentários:

          - "O Shrink no MDF nem sempre libera espaço". O Shrink não irá reduzir o tamanho do datafile para um tamanho menor do que o tamanho que a base foi originalmente criada. Exemplo: Se você criar uma base com 50Gb mas tiver apenas 1Gb de dados nela, se você rodar o Shrink, ele irá manter o datafile em 50Gb. Esse comportamento também se refere ao arquivo de Log (.LDF). Apesar deste comportamento, uma boa prática nas bases de dados SQL Server é mantê-las com um espaço livre considerável de acordo com o seu Data Sizing.

         - Não há nenhuma System Table que o SQL Server crie que cresça tanto a ponto de exigir o Shrink. Você pode citar um exemplo de tabela que é criada pelo SQL e que consuma grande espaço?

          - Apesar de concordar com a sua afirmação que é "sempre bom mantermos o BD em tamanho adequado", não há nenhuma limitação no SQL Express que tenha impacto sobre o Shrink. A limitação de 10Gb por banco nada tem a ver com Shrink, pois se a base efetivamente tiver 10Gb de dados o Shrink não terá nenhum efeito de redução e você terá que migrar a sua base para uma versão paga do SQL Server.


    Roberto Fonseca MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008 MCITP - Business Intelligence 2008

    segunda-feira, 5 de janeiro de 2015 20:13
    Moderador

Todas as Respostas

  • Amigo,

    O termo "truncar" se refere ao "esvaziamento" da tabela, sem registrar a operação em log e sem definição de critérios para limitação de registros. Isto torna a execução mais rápida e com um menor consumo nos recursos do servidor.

    Para executar o "truncate" adapte o scritp abaixo à sua necessidade:

    USE SeuBanco
    GO
    
    TRUNCATE TABLE SuaTabela
    GO

    Para maiores informações veja:

    http://msdn.microsoft.com/pt-br/library/ms177570.aspx

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    segunda-feira, 5 de janeiro de 2015 12:48
    Moderador
  • Em tempo (e voltando). O tema é "Como liberar espaço reservado para o SQL SERVER após grande deleção de dados?" (infelizmente o texto ficou ruim e não refletiu bem isto).

    Sabemos que o Shrink no MDF nem sempre libera espaço.

    Sabemos que há system Tables que o SQL Server cria.

    Sabemos que a versão express tem limitações, por isso, sempre bom mantermos o BD em tamanho adequado.

    segunda-feira, 5 de janeiro de 2015 12:54
  • Em tempo (e voltando). O tema é "Como liberar espaço reservado para o SQL SERVER após grande deleção de dados?" (infelizmente o texto ficou ruim e não refletiu bem isto).

    Sabemos que o Shrink no MDF nem sempre libera espaço.

    Sabemos que há system Tables que o SQL Server cria.

    Sabemos que a versão express tem limitações, por isso, sempre bom mantermos o BD em tamanho adequado.

    Olá,

         Sobre o seu post, gostaria de fazer alguns comentários:

          - "O Shrink no MDF nem sempre libera espaço". O Shrink não irá reduzir o tamanho do datafile para um tamanho menor do que o tamanho que a base foi originalmente criada. Exemplo: Se você criar uma base com 50Gb mas tiver apenas 1Gb de dados nela, se você rodar o Shrink, ele irá manter o datafile em 50Gb. Esse comportamento também se refere ao arquivo de Log (.LDF). Apesar deste comportamento, uma boa prática nas bases de dados SQL Server é mantê-las com um espaço livre considerável de acordo com o seu Data Sizing.

         - Não há nenhuma System Table que o SQL Server crie que cresça tanto a ponto de exigir o Shrink. Você pode citar um exemplo de tabela que é criada pelo SQL e que consuma grande espaço?

          - Apesar de concordar com a sua afirmação que é "sempre bom mantermos o BD em tamanho adequado", não há nenhuma limitação no SQL Express que tenha impacto sobre o Shrink. A limitação de 10Gb por banco nada tem a ver com Shrink, pois se a base efetivamente tiver 10Gb de dados o Shrink não terá nenhum efeito de redução e você terá que migrar a sua base para uma versão paga do SQL Server.


    Roberto Fonseca MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008 MCITP - Business Intelligence 2008

    segunda-feira, 5 de janeiro de 2015 20:13
    Moderador
  • Em tempo (e voltando). O tema é "Como liberar espaço reservado para o SQL SERVER após grande deleção de dados?" (infelizmente o texto ficou ruim e não refletiu bem isto).

    Sabemos que o Shrink no MDF nem sempre libera espaço.

    Sabemos que há system Tables que o SQL Server cria.

    Sabemos que a versão express tem limitações, por isso, sempre bom mantermos o BD em tamanho adequado.

    IMI,

    Sinceramente suas observações neste post não refletem ou condizem com a verdade sobre o SQL Server.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | SoroCódigos] @JuniorGalvaoMVP | pedrogalvaojunior.wordpress.com

    quarta-feira, 7 de janeiro de 2015 11:50
  • Em tempo (e voltando). O tema é "Como liberar espaço reservado para o SQL SERVER após grande deleção de dados?" (infelizmente o texto ficou ruim e não refletiu bem isto).

    Sabemos que o Shrink no MDF nem sempre libera espaço.

    Sabemos que há system Tables que o SQL Server cria.

    Sabemos que a versão express tem limitações, por isso, sempre bom mantermos o BD em tamanho adequado.

    Olá,

         Sobre o seu post, gostaria de fazer alguns comentários:

          - "O Shrink no MDF nem sempre libera espaço". O Shrink não irá reduzir o tamanho do datafile para um tamanho menor do que o tamanho que a base foi originalmente criada. Exemplo: Se você criar uma base com 50Gb mas tiver apenas 1Gb de dados nela, se você rodar o Shrink, ele irá manter o datafile em 50Gb. Esse comportamento também se refere ao arquivo de Log (.LDF). Apesar deste comportamento, uma boa prática nas bases de dados SQL Server é mantê-las com um espaço livre considerável de acordo com o seu Data Sizing.

         - Não há nenhuma System Table que o SQL Server crie que cresça tanto a ponto de exigir o Shrink. Você pode citar um exemplo de tabela que é criada pelo SQL e que consuma grande espaço?

          - Apesar de concordar com a sua afirmação que é "sempre bom mantermos o BD em tamanho adequado", não há nenhuma limitação no SQL Express que tenha impacto sobre o Shrink. A limitação de 10Gb por banco nada tem a ver com Shrink, pois se a base efetivamente tiver 10Gb de dados o Shrink não terá nenhum efeito de redução e você terá que migrar a sua base para uma versão paga do SQL Server.


    Roberto Fonseca MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008 MCITP - Business Intelligence 2008

    Roberto,

    Concordo totalmente com você!!!!


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | SoroCódigos] @JuniorGalvaoMVP | pedrogalvaojunior.wordpress.com

    quarta-feira, 7 de janeiro de 2015 11:51
  • Olá IMI, tudo bem?

    Fico no readonly lendo alguns tópicos e acabei topando com o tópico deste amigo que diz que resolveu o problema truncando a sysdiagrams e a sysssislog (o mesmo que reclamou que ninguém responde de fato as questões de shrink, o que reflete total falta de pesquisa no fórum sobre o tema)  e fez o shrink de novo e teve liberação de espaço. Não é uma solução inédita: trata-se do clássico expurgo + shrink. Me parece ser um caso bem anormal, uma tabela de log utilizada pelo SQL Server e/ou SSIS chegar a absurdos 193GB conforme foi relatado. 

    Sua primeira pergunta era o que seria o comando truncar dito pela pessoa que você mencionou: Durval já respondeu.

    Sobre sua segunda pergunta:

     Como liberar espaço reservado para o SQL SERVER após grande deleção de dados?

    Resposta: Fazendo Shrink do arquivo que teve um grande número de dados expurgado.

    Concordo com as colocações do Roberto, só deixo a seguinte consideração: o SQL Server permite diminuir o tamanho do arquivo de log para um tamanho inferior ao inicial via shrink.

    E reforço também o ponto central deste assunto: shrink em arquivo de dados na minha opinião só é interessante se você fizer um expurgo bastante considerável e realmente precise devolver espaço para o SO. Caso contrário, fragmentação sem necessidade e diversos outros problemas (já dito em outros tópicos) são certos. 

    []'s


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.




    quarta-feira, 7 de janeiro de 2015 20:42
  • Renato,

        Falha minha... Falta de costume em reduzir o TL que acabei confundindo com o conceito do VLF que o Shrink irá utilizar para reduzir o log...

        Apenas para esclarecer então:

       - O log não poderá ser reduzido a um tamanho menor do que o tamanho somado de no mínimo 2 VLFs (já que o número de VLFs não pode ser menor do que 2), O VLF ativo e mais 1 VLF, no caso do VLF ativo ser o primeiro VLF ou então todos os VLFs anteriores ao(s) VLF ativo(s) e mais o(s) VLF ativo(s) no caso do VLF ativo não ser o primeiro.

         Tanto VLF.. acho que confundi mais... hehe...

    Roberto Fonseca MCT / MCSE -Data Platform


    quinta-feira, 8 de janeiro de 2015 03:07
    Moderador
  • Roberto,

    Isso mesmo, e caso o seu banco de dados venha a ter até 1GBs de Dados, o VLF terá tamanho máximo de 64MBs.

    

    Renato,

    Em relação ao VLF, indico que você acesse e leia os seguintes posts:

    http://edvaldocastro.com/vlf_control/

    http://www.sqlskills.com/blogs/paul/important-change-vlf-creation-algorithm-sql-server-2014/?utm_source=rss&utm_medium=rss&utm_campaign=important-change-vlf-creation-algorithm-sql-server-2014


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | SoroCódigos] @JuniorGalvaoMVP | pedrogalvaojunior.wordpress.com

    sexta-feira, 9 de janeiro de 2015 16:26