locked
Shrinkdatabase RRS feed

 > 

  • Pergunta

  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Pessoal sei que parece um tanto quanto estranho, mas não consegui desvendar esse mistério.

    Tenho algumas bases que precisam ser "shrincadas" quase diaramente devido a um erro de programação, então criei um plano de manutenção para efetuar os shrinks todos os dias, ele executa com sucesso sem nenhum log de erro porém a base não diminui o tamanho, e mais estranho, quando faço o processo manualmente clicando com o botão direito em cima do banco indo em task/shrink o sql me informa que ele possui 85% de espaço livre disponivel. Ok Então tento fazer  manualmente e ele roda perfeitamente porém não diminui, repito esses passos umas 5 vezes ai na quinta ou sexta vez ele diminui o banco. No inicio achei que fosse alguma conexão no banco que poderia estar interferido mas fiz esse processo sem nenhum acesso a base e acontece o mesmo sintoma. Alguém já viu isso??

    []'s Douglas R. Oliveira
    quinta-feira, 3 de fevereiro de 2011 10:47

Respostas

  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Se você roda o shrink todos os dias por conta de uma inserção muito grande na madrugada, a inserção muito grande vai demorar mais para rodar pois ela tem que esperar a alocação de mais espaço para os dados que serão inseridos.

    Como já foi destacado, shrink não é uma boa prática, e não é recomendado, a não ser que REALMENTE você esteja precisando de espaço livre para outras coisas. O que pelo visto não é o seu caso, aja visto que a rotina precisa do espaço disponível para rodar todos os dias.

    Por simplesmente não deixa de rodar o shrink?

    Com isso você vai otimizar sua rotina de insert, e não vai causar a fragmentação.

     

    Abraços

     

    Fabiano Neves Amorim - MCTS / MCP - SQLServer - http://blogs.solidq.com/fabianosqlserver/
    sexta-feira, 4 de fevereiro de 2011 14:24

Todas as Respostas

  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Olá Douglas,

    Realmente muito estranho. veja se no errorlog do SQL não aparece nenhuma mensagem após você executar o comando de shrink.

    Qual a versão/edição/build do seu SQL?

    Como está o 'recovery model' da sua database?
    Tente executar a seguinte sequencia para ver se corrige esta "esquisitisse"

    ***********
    Set the recovery model of the database to ‘SIMPLE’ and then run back up to ‘FULL’
    Ran DBCC SHRINKFILE(<logical name>)
    Article for further reading http://support.microsoft.com/kb/873235
    ***********

    Abraços,

    Fábio Oliveira Support Engieer | Microsoft Enterprise and Developer Support
    quinta-feira, 3 de fevereiro de 2011 11:29
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Olá Fábio,

    estou usando 2005 enterprise SP2.

     

    Consultei os logs e não aparece nada.

    []'s Douglas R. Oliveira
    quinta-feira, 3 de fevereiro de 2011 11:35
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Olá,

    Você tenteou executar com as recomendações que mandei acima?

    Fábio Oliveira Support Engieer | Microsoft Enterprise and Developer Support
    quinta-feira, 3 de fevereiro de 2011 12:13
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Executei sim Fábio e continuo com os mesmo sintomas.
    []'s Douglas R. Oliveira
    quinta-feira, 3 de fevereiro de 2011 12:54
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Olá Douglas,

    Realmente não sei o que pode ser a causa ... muito estranho....

    Tente capturar um profiler Trace com todas as tentativas assim você tem base para comparação de quando funciona e quando não e assim podemos progredir na investigação.

    Recomendação: Quando for possível atualize seu SQL para o SP4 Build 9.0.5000 (não acredito que estejam relacionados, mas com certeza você vai manter seu SQL em um build level suportado e com as ultimas correções de Performance, segurança e melhorias do produto)

     

    Fábio Oliveira Support Engieer | Microsoft Enterprise and Developer Support
    quinta-feira, 3 de fevereiro de 2011 13:05
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Douglas, dei uma pesquisada, e uma duvida, voce chegou a restartar o servico do sql depois que comecou este problema?
    ---------------------------------------------- Para dicas SQL Server e mais -> www.onlywhatmatters.wordpress.com
    quinta-feira, 3 de fevereiro de 2011 13:13
    Moderador
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Quais são os  tamanhos  reais  arquivos  (mdf/ldf)?
    Se o arquivo de log ou mdf é muito grande, tente executar DBCC OPENTRAN para determinar a transação mais antiga...
    pois parece que uma transação antiga aberta pode estar impedindo o arquivo de mdf/log de encolher significativamente.
    • Sugerido como Resposta CarlosHB quinta-feira, 3 de fevereiro de 2011 17:22
    • Não Sugerido como Resposta Douglas R. Oliveira quinta-feira, 3 de fevereiro de 2011 17:37
    quinta-feira, 3 de fevereiro de 2011 14:08
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    MDf está com 60gb o ldf 2mb.

     

    Já diminui o ldf antes, pelo dbcc opentran não existe transações abertas.

    []'s Douglas R. Oliveira
    quinta-feira, 3 de fevereiro de 2011 14:30
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    MDf está com 60gb o ldf 2mb.

     

    Já diminui o ldf antes, pelo dbcc opentran não existe transações abertas.

    []'s Douglas R. Oliveira
    quinta-feira, 3 de fevereiro de 2011 14:32
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Olá Douglas,

    Você consegue capturar o profiler trace como mencionei no meu post anterior?

     

    Fábio Oliveira Support Engieer | Microsoft Enterprise and Developer Support
    quinta-feira, 3 de fevereiro de 2011 17:18
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Bom realmente é estranho isto, já passei por isto uma vez tb, tinha que fazer um shrink em um database e ele não reduzia o tamanho.
    Pesquisando em vários fóruns e com uns professores de SQL que tive, eles diziam que com relação ao Shrink, a recomendação é não usar ele.
    Acho que porque utilizando o banco de dados, os dados são incluídos, alterados e excluídos, com isso o SQL vai alocando espaço...

    Você tem feito o REBUILD INDEX? (Para ajustar os espaços vazios que estão no meio do DATAFILE, e para alocá-los ao final do DATAFILE).
    • Sugerido como Resposta CarlosHB terça-feira, 1 de março de 2011 13:23
    quinta-feira, 3 de fevereiro de 2011 17:21
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Tentou seguir estes passos já?

    1 - Defrag Indexes;

    2 - Update Statistics;

    3 - Shrink na Base;

     

    • Sugerido como Resposta CarlosHB terça-feira, 1 de março de 2011 13:24
    quinta-feira, 3 de fevereiro de 2011 17:30
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    <!-- [if gte mso 10]> <mce:style>

    Douglas,

    Primeiro de tudo, saiba que o comando "shrink" causa fragmentação , e isso degrada bastante o desempenho.

    Para verificar o espaço usado por um database executa isso:

    use database-desejado
go
exec sp_spaceused
go
    Se vc estiver na duvida se esses números estão corretos, executa isso para atualizar esses números: 
    USE database-desejado;
GO
EXEC sp_spaceused @updateusage = N'TRUE';
GO

    []'s!

    http://www.diaadiasql.com.br
    quinta-feira, 3 de fevereiro de 2011 18:18
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Tenhos planos de manutenção que rodam quase que diariamente Rebuild, Reorganize e Update statistics.

     

    O shrink só rode nesse banco especifico porque ele sofre uma inserção muito grande em uma tabela de log que truncada todos os dias a noite, por isso preciso fazer o shrink para voltar o tamanho do banco a sua realidade.

    []'s Douglas R. Oliveira
    sexta-feira, 4 de fevereiro de 2011 12:48
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Olá Renato já vinha utilizando o sp_spaceused para ver o nivel e espaço de utilização do banco, ele está dentro correto levando em consideração que todos os dias noite tenho um job que trunca a tabela de log.

     

    O que fiz de diferente e que deu um pouco certo, foi antes de rodar shrinkdatabase coloque o banco com offline e depois online... isso diminui minhas tentativas de 5 a 6 para no máximo 2 ou 3.

     

     

    []'s Douglas R. Oliveira
    sexta-feira, 4 de fevereiro de 2011 12:50
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Se você roda o shrink todos os dias por conta de uma inserção muito grande na madrugada, a inserção muito grande vai demorar mais para rodar pois ela tem que esperar a alocação de mais espaço para os dados que serão inseridos.

    Como já foi destacado, shrink não é uma boa prática, e não é recomendado, a não ser que REALMENTE você esteja precisando de espaço livre para outras coisas. O que pelo visto não é o seu caso, aja visto que a rotina precisa do espaço disponível para rodar todos os dias.

    Por simplesmente não deixa de rodar o shrink?

    Com isso você vai otimizar sua rotina de insert, e não vai causar a fragmentação.

     

    Abraços

     

    Fabiano Neves Amorim - MCTS / MCP - SQLServer - http://blogs.solidq.com/fabianosqlserver/
    sexta-feira, 4 de fevereiro de 2011 14:24
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Fabiano eu entendo isso, porém seu não fizer o shrink quase que diariamente ele enche o disco e para o servidor.
    []'s Douglas R. Oliveira
    sexta-feira, 4 de fevereiro de 2011 15:35
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Este post foi encerrado por ser considerado um post antigo.

    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 5 de junho de 2018 17:55
    Moderador