locked
Shrink Database não compactando arquivos RRS feed

  • Pergunta

  • Amigos,

       Tenho a seguinte composição de um pequeno DW

       - 1 arquivo mdf relacionada as tabelas de cadastro (dimensões)
       - 2 arquivos ndf, destinados ao armazenamento, por assunto, dos dados de algumas fato
       - 1 arquivo ndf, para armazenamento de índices
       - 1 arquivo de log, para todos estes arquivos.

       => O Somatório em Gbs de todos os arquivos dpa algo aproximado de 40 GBs
       => Todos os arquivos crescem de 1 em 1 MB, com restrições específicas de autogrowth

       O problema aqui é que o arquivo de log já chegou num espaçamento ocupado de cerca de 20 Gbs e continua crescendo. Para piorar, como já precisei fazer eliminações com Shrinck Database e File antes, não estou mais conseguindo espaço livre no log para realizar mais compactações, o que me impede de controlar o tamanho do log, e assim, este consome mais ainda espaço em disco. A questão é:

    - O QUE PODE ESTAR ACONTECENDO E COMO CONSEGUIR REALIZAR AS COMPACTAÇÕES PRINCIPALMENTE DO LOG E DO ARQUIVO DE INDICES?
    - O QUE ACONTECE SE FICAR USANDO SHRINK TODA HORA?
    -
    O Forte Sobreviverá e o Fraco irá Sofrer
    sexta-feira, 26 de fevereiro de 2010 18:05

Respostas

  • Boa Noite,

    Normalmente um Data Warehouse não carece de restauração do tipo POINT IN TIME através de backups de log. A característica de recuperação de um DW é simplesmente restaurar o último FULL e reaplicar as cargas de dados que em tese são feitas de forma controlada e podem ser reproduzidas. Se esse for o seu cenário eu recomendo que adote o uso de RECOVERY MODEL SIMPLE. Se não for, jamais rode o comando BACKUP Log WITH TRUNCATE_ONLY (apenas opte por fazer um backup).

    O uso contínuo do SHRINK não é uma boa idéia. Reduções e sucessivos crescimentos de arquivos levarão a fragmentações do arquivo no sistema operacional o que incorre em perda de desempenho.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Encontrando tabelas não utilizadas
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!957.entry
    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 1 de março de 2010 02:34

Todas as Respostas

  • pabloslobo,

    Está fazendo backup do transaction log?

    Se seu banco estiver em full ou bulk recovery  model, o transaction log é esvaziado apenas quando for feito backup. Se ele estiver em simple mode, o log é esvaziado a cada checkpoint. Sugiro fazer backups durante o dia do log para você conseguir fazer restore em um horário determinado do dia, isso se o banco não estiver em simple recovery model.

    Além disso, o shrink do log funciona diferente do de dados pois ele usa virtual logs com tamanhos distintintos que dependem das necessidades do seu banco. Sugiro fazer o shrink e depois checkpoint e backup do transaction log. Depois outro shrink

    Pela minha experiência, quando é feita uma alteração muito grande, gera-se muito log até que a transação seja commitada. Verifique se existe algum código fazendo isso, que pode estar causando o crescimento do log.
    Se a resposta resolveu sua questão ou problema, classifique-a para manter a qualidade do forum e a confiabilidade dos participantes.

    Alex M. Bastos
    http://bastosalex.spaces.live.com
    sexta-feira, 26 de fevereiro de 2010 18:55
  • Respondendo,

       - O banco está erm Full Recovery e o backup é full
       - Para compactar o log, então devo rodar o Shrinck e fazer um restore do bd?
       - O crescimento grande do log acontece devido ao processo de carga de alguns arquivos que são extremamente grandes.
    O Forte Sobreviverá e o Fraco irá Sofrer
    sexta-feira, 26 de fevereiro de 2010 19:00
  • Use o seguinte quey antes de efetuar o Shrinck, irá zerar seu LOG.


    Backup log meubanco with truncate_only




    Ate +

    sexta-feira, 26 de fevereiro de 2010 23:59
  • Opa, Alexandre,

       Isso até resolve (um DBCC tb). Como estava precisando, tive que usar o truncate_only, mas isto também pode comprometer o backup do log, uma vez que você não terá mais as informações do checkpoint depois disso. Neste caso, já que vou ficar zerando o log em algumas vezes, passei o database para SIMPLE e rodei a rotina acima.

    VLW!
    O Forte Sobreviverá e o Fraco irá Sofrer
    sábado, 27 de fevereiro de 2010 12:23
  • Boa Noite,

    Normalmente um Data Warehouse não carece de restauração do tipo POINT IN TIME através de backups de log. A característica de recuperação de um DW é simplesmente restaurar o último FULL e reaplicar as cargas de dados que em tese são feitas de forma controlada e podem ser reproduzidas. Se esse for o seu cenário eu recomendo que adote o uso de RECOVERY MODEL SIMPLE. Se não for, jamais rode o comando BACKUP Log WITH TRUNCATE_ONLY (apenas opte por fazer um backup).

    O uso contínuo do SHRINK não é uma boa idéia. Reduções e sucessivos crescimentos de arquivos levarão a fragmentações do arquivo no sistema operacional o que incorre em perda de desempenho.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Encontrando tabelas não utilizadas
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!957.entry
    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 1 de março de 2010 02:34
  • Pablo,

    O que eu aconselho a fazer antes de realizar qualquer tipo de procedimento para redução do tamanho do arquivo é analisar a maneira que o seu banco de dados esta crescendo. Talvez seja possível estimar esta taxa de crescimento e dimensionar.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    segunda-feira, 1 de março de 2010 17:34
    Moderador
  • Olá, amigos.

       Eu fiz a estimativa do crescimento, limitei o autogrowth e tudo mais. Quanto ao que o Gustavo disse, não preciso realizar restauração POINT in TIME. Logo, optei pelo RECOVERY MODEL SIMPLE, e assim (usando o DBCC informado acima - foi preciso, acreditem), consegui diminuir o crescimento assutador do log.
      Quanto ao que o Galvão citou acima, estou bastante preocupado neste quesito. A máquina utilizada para este pequeno DW não é lá grande coisa e já estou tendo problemas de performance.
      Estou desenvolvendo um dashboard web com PHP e consultas com alguns JOINs num TOP 100 estão demorando mais de 1 min p ser retornado, o que não é muito bom. Meus índices são do tipo NONCLUSTERED, e as tabelas são ROLAP. Então, o que devo fazer para melhorar a performance, nestes casos?

       Um outro porém é que eu tenho um arquivo .ndf destinado ao armazenamento dos índices, mas como algumas tabelas são bem grandes, este arquivo está indo na mesma proporção do arquivo de log. Entretanto, não consegui eliminar algumas coisas deste arquivo e o percentual de espaço livre dele está sendo informado como 0%. O que é isso e como devo proceder para melhorar/eliminar algum espaço deste arquivo?

    VLW!


    O Forte Sobreviverá e o Fraco irá Sofrer
    segunda-feira, 1 de março de 2010 22:59
  • pabloslobo,

    você pode rodar DBCC SHOWCONTIG nos índices e verificar a saída do comando para ver se tem índice fragmentado.
    Se tiver, você pode reindexar os índices mais fragmentados, o que deve liberar espaço no filegroup dos índices. Nesse rebuild, verifique se o fill factor não está muito alto, pois você pode estar reservando espaço para índices que não sofrem muitas alterações, despediçando espaço em disco.
    Se a resposta resolveu sua questão ou problema, classifique-a para manter a qualidade do forum e a confiabilidade dos participantes.

    Alex M. Bastos
    http://bastosalex.spaces.live.com
    quinta-feira, 4 de março de 2010 17:38
  • Post antigo, por isso o mesmo foi encerrado.

    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 13:15
    Moderador