none
Evitar Crescimento do LOG RRS feed

Respostas

  • Vithor, bom dia!

     

    Recovery Model Simple = Sempre que uma transação é finalizada, o log automaticamente entra em truncate log on checkpoint, isso quer dizer que depois da transação efetuada o LOG será truncado. Porém quando há uma massa muito grande de dados sendo realizado no LOG, o arquivo .ldf cresce isso porque dentro do LSN (Log Sequence Number) ou seja a estrutura interna do log fazem com que os (Virtual Log Files)  ou seja a estrutura interna do LSN crescem fazendo com que o log cresça.

    Depois das transações terminadas os VLF's são desocupados, porém como o tamanho do arquivo de Log já cresceu ele não diminui automaticamente. O arquivo físico do log é grande, porém dentro dele não há informações, somente o espaço que foi utilizad anteriormente.

     

    Por isso seu log cresce.  Nunca utilize  Auto Shrink isso faria com que toda a vez com que seu log crescesse ele automaticamente diminuiria o tamanho.

     

    Se desejar diminuir o tamanho do seu log utilize

     

    Shrink File Arquivo de LOG

    Sintaxe: DBCC SHRINKFILE (<FileName>, <TargetSize>)

    <FileName> = Nome do Arquivo de LOG

    <TargetSize> = KB


    Luan.Moreno [SQL Soul]|| Especialista SQL Server || MCTS SQL Server Admin e Dev @luansql
    • Marcado como Resposta Richard Juhasz sexta-feira, 28 de outubro de 2011 18:28
    quarta-feira, 19 de outubro de 2011 16:08
  • Também me deparo com esta mesma situação, tenho um banco de dados que usa Recovery Model = Simple, mas o log de transações dele durante a madrugada, cresce demasiadamente.

    É fato, que durante este horário ele recebe uma carga massante de inserções, mas porque o log cresce tanto, se nem mesmo estou usando a estratégia de Recovery Model FULL?


    Vithor da Silva e Silva | MCTS - SQL Server 2008, Implementation and Maintenance www.vssti.com.br


    Vithor;

    Na verdade o crescimento do Log É NECESSÁRIO, sem o log suas transações não irão ocorrer. Cada transação antes de ser efetivada no banco fica no log, no momento em que a transação é efetivada esta informação é removida do log.

    Tendo isto como informação, sua pergunta:

    "mas porque o log cresce tanto, se nem mesmo estou usando a estratégia de Recovery Model FULL?"

    R: O Log cresce de acordo com a necessidade do seu banco, imagine que você tenha um espaço virtual dentro de um arquivo (este é efetivamente o registro de tranação) quando este espaço se torna insuficiente ocorre o crescimento físico do arquivo (o que vc consegue ver no NTFS) daí o crescimento do seu arquivo, mas isto não significa que todo o seu arquivo de log esteja em uso.

    As boas práticas (vide o link que passei mais acima) indicam que não é legal para o banco ficar fazendo shirink de arquivos, pois, isto poderá degradar a performance dos processos (e causar fragmentação em disco caso não utilize uma storage). Imagine a que toda vez que vc preciar fazer uma operação (workload noturno por exemplo) você tenha que realocar xGb em espaço em disco. Discos são comprovadamente lentos por se tratar de processos mecânicos e blá blá blá. Eu tenho em mente que se uso um Recovery Mode em Simple e tenho problemas de espaço é mais válido adicionar disco do que ficar fazendo sanfona com o banco de dados.

    Eu não acho e não recomendo o uso de shirink, mas eventualmente eu mesmo sou obrigado a usar.

    Uma outra coisa importante é o controle do crescimento (autogrouth), tenha em mente que se atingir o tamanho máximo as transações não serão efetivadas, se o processo noturno (workload) for muito grande, seu bando poderá entrar em Recovering até que seja feito o rollback das transações (isto não é um erro e não haverá perda de dados já comitados) e este processo normalmente tem uma duração semelhante ao tempo de processamento (é um chute) por exemplo 1 hora rodando, estouro de log, 1 hora de rollback. Então cuidado ao definir um tamanho máximo, esteja certo de que irá comportar sua necessidade.


    View Ricardo Muramatsu's profile on LinkedIn
    quarta-feira, 19 de outubro de 2011 17:21

Todas as Respostas

  • Marcos, bom dia!

     

    1. - Não está sendo realizado BACKUP DE LOG, então o arquivo de log não é "esvaziado". Assim faça backup de LOG

    2. - Possuem transações abertas na qual ainda não foram fechadas, isso faz com que os VLF's (Virtual Log Files), fiquem ocupados, fazendo com que o LOG tenha que crescer

    Temos 3 tipos de Recovery Model(Modo de recuperação), no banco de dados que você consegue mudar nas opções do banco de dados, esses 3 modos são:

     

     

    FULL, BULK-LOGGED e SIMPLE.

     

    FULL e BULK-LOGGED = Eles apresentam algumas diferenças, mais não vou aprofundar sobre isso agora, o que aconteçe é que quando possuímos o banco de dados em modo de recuperação FULL, todas as transações que são realizadas no banco de dados são gravadas no arquivo de LOG do banco de dados, o que faz com que o LOG começe a ficar cheio. Nesses modos de recuperação o que faz o LOG diminuir é somente um BACKUP DE LOG da base de dados, o que é diferente de realizar um backup de DADOS. Provavelmente o que está acontecendo é que toda a estrutura interna do arquivo de LOG esteja preenchida.

     

    SIMPLE = Essem é diferente, sempre que a transação é realizada, ele automaticamente realizada o TRUNCATE do LOG, por isso não existe backup de log quando temos o modo de recuperação no SIMPLE.

     

     

     BACKUP DE LOG do Banco de Dados.

     

    Sintaxe: BACKUP LOG [NomeBancoDeDados]

         TO DISK = '[LOCAL]\[NOMEBACKUP].TRN'

     

    Não é recomendável realizar o Shrink em base de dados de produção, o log tende a se normalizar quando for realizado rotinas de backup de log periódicos.

     

    Se deseja pode realizar o Shirink do arquivo de log

    Shrink File Arquivo de LOG

    Sintaxe: DBCC SHRINKFILE (<FileName>, <TargetSize>)

    <FileName> = Nome do Arquivo de LOG

    <TargetSize> = KB

     

    Att,

     


    Luan.Moreno [SQL Soul]|| Especialista SQL Server || MCTS SQL Server Admin e Dev @luansql
    terça-feira, 18 de outubro de 2011 22:55
  • Ola Marcos,

    É um banco com muitas transações?

    Verifica se o seu banco esta e modelo de recuperação, caso esteje no Full,

    Faça um backup de log , automaticamente ele trunca o arquivo de log.

    Verificar nos proprietes do banco, na opção FILES veja se a opção Autogrowth esta selecionado, se estiver desmarque.

    Voce tambem pode diminuir o tamanho inicial do arquivo de Log, mas sempre faça um bkp antes.

     

    Abrs.

     

    Bruno Henrique.

     

     

    terça-feira, 18 de outubro de 2011 23:38
  • Como posso evitar o crescimento do log de uma base?

    Att,


    Primeiro, acho interessante analisar se você utiliza alguma dessas funções:

    -Backup Log

    -Database Mirroring

    -LogShipping

    Segundo, faça um levantamento da sua rotina de backups e qual é a perda de dados aceitável para sua necessiade (1 dia? / 1hora? / 1seg?)

    Terceiro, você precisa fazer restore constantemente desta base de dados em um outro ambiente? Tem espaço suficiente para restaurar a base + Log neste outro ambiente?

    Com isto em mãos leve em consideração as informações fornecidas pelo Luan.Moreno (FULL, BULK-LOGGED e SIMPLE)

    Quanto a outras opções considere fortemente ler os dois excelentes artigos do Gustavo Maia Aguiar sobre este assunto (leia os dois):

    http://gustavomaiaaguiar.wordpress.com/2009/08/01/piores-praticas-%e2%80%93-utilizar-o-comando-backup-log-com-a-opcao-with-truncate_only-%e2%80%93-parte-i/

    http://gustavomaiaaguiar.wordpress.com/2009/08/01/piores-praticas-%e2%80%93-utilizar-o-comando-backup-log-com-a-opcao-with-truncate_only-%e2%80%93-parte-ii/

    Se ainda tiver dúvidas poste aí que ajudamos.


    View Ricardo Muramatsu's profile on LinkedIn
    quarta-feira, 19 de outubro de 2011 12:48
  • Também me deparo com esta mesma situação, tenho um banco de dados que usa Recovery Model = Simple, mas o log de transações dele durante a madrugada, cresce demasiadamente.

    É fato, que durante este horário ele recebe uma carga massante de inserções, mas porque o log cresce tanto, se nem mesmo estou usando a estratégia de Recovery Model FULL?


    Vithor da Silva e Silva | MCTS - SQL Server 2008, Implementation and Maintenance www.vssti.com.br
    quarta-feira, 19 de outubro de 2011 13:26
  • Vithor!

    Provavelmente o seu log está usando a opção Autogrowth = X% ou X MB e MaxSize = Unlimited.

    Marcos!

    O que você pode fazer é criar um Alerta no Agent. Assim quando o LOG chegar a um determinado tamanho um Backup de Log é acionado e o LOG é Truncado.

     

    Abraços

     

     

    quarta-feira, 19 de outubro de 2011 14:08
  • Pedro, realmente não havia me atentado a este detalhe.

    Configurei para ele crescer até 15 GB, de hoje para manhã irei acompanhar o resultado.

    Obrigado!

    Marcos,

    Realmente isto que o Marcos, poderá lhe ajudar, pois também configurei em meus bancos esse alerta. Você pode fazer assim:

    • Conecte ao Servidor/instância;
    • Vá em SQL Server Agent;
    • Alerts;
    • Com o botão direito - New Alert;
    • Dê um nome, exemplo: SQL Insufficient Resources - SERVIDOR - Database MEUBANCO;
    • O Type deve ser: SQL Server event alert;
    • Database Name: Informe o banco que seu log estoura;
    • Severity: 017 - Insufficient Resources;
    • Marque o checkbox 'Raise alert when contentes....';
    • Em Message Text informe a seguinte mensagem: "The transaction log for database 'NOMEDOSEUBANCODEDADOS' is full."
    • Em Response, informe um JOB seu que faz o shrink/truncate do Log de seu Banco de dados;
    • Ainda em Response, você poderá informar via notificação o problema ocorrido;
    • Marque OK;

    Espero ter ajudado, se sim marque como uma resposta.


    Vithor da Silva e Silva | MCTS - SQL Server 2008, Implementation and Maintenance www.vssti.com.br
    quarta-feira, 19 de outubro de 2011 16:05
  • Vithor, bom dia!

     

    Recovery Model Simple = Sempre que uma transação é finalizada, o log automaticamente entra em truncate log on checkpoint, isso quer dizer que depois da transação efetuada o LOG será truncado. Porém quando há uma massa muito grande de dados sendo realizado no LOG, o arquivo .ldf cresce isso porque dentro do LSN (Log Sequence Number) ou seja a estrutura interna do log fazem com que os (Virtual Log Files)  ou seja a estrutura interna do LSN crescem fazendo com que o log cresça.

    Depois das transações terminadas os VLF's são desocupados, porém como o tamanho do arquivo de Log já cresceu ele não diminui automaticamente. O arquivo físico do log é grande, porém dentro dele não há informações, somente o espaço que foi utilizad anteriormente.

     

    Por isso seu log cresce.  Nunca utilize  Auto Shrink isso faria com que toda a vez com que seu log crescesse ele automaticamente diminuiria o tamanho.

     

    Se desejar diminuir o tamanho do seu log utilize

     

    Shrink File Arquivo de LOG

    Sintaxe: DBCC SHRINKFILE (<FileName>, <TargetSize>)

    <FileName> = Nome do Arquivo de LOG

    <TargetSize> = KB


    Luan.Moreno [SQL Soul]|| Especialista SQL Server || MCTS SQL Server Admin e Dev @luansql
    • Marcado como Resposta Richard Juhasz sexta-feira, 28 de outubro de 2011 18:28
    quarta-feira, 19 de outubro de 2011 16:08
  • Também me deparo com esta mesma situação, tenho um banco de dados que usa Recovery Model = Simple, mas o log de transações dele durante a madrugada, cresce demasiadamente.

    É fato, que durante este horário ele recebe uma carga massante de inserções, mas porque o log cresce tanto, se nem mesmo estou usando a estratégia de Recovery Model FULL?


    Vithor da Silva e Silva | MCTS - SQL Server 2008, Implementation and Maintenance www.vssti.com.br


    Vithor;

    Na verdade o crescimento do Log É NECESSÁRIO, sem o log suas transações não irão ocorrer. Cada transação antes de ser efetivada no banco fica no log, no momento em que a transação é efetivada esta informação é removida do log.

    Tendo isto como informação, sua pergunta:

    "mas porque o log cresce tanto, se nem mesmo estou usando a estratégia de Recovery Model FULL?"

    R: O Log cresce de acordo com a necessidade do seu banco, imagine que você tenha um espaço virtual dentro de um arquivo (este é efetivamente o registro de tranação) quando este espaço se torna insuficiente ocorre o crescimento físico do arquivo (o que vc consegue ver no NTFS) daí o crescimento do seu arquivo, mas isto não significa que todo o seu arquivo de log esteja em uso.

    As boas práticas (vide o link que passei mais acima) indicam que não é legal para o banco ficar fazendo shirink de arquivos, pois, isto poderá degradar a performance dos processos (e causar fragmentação em disco caso não utilize uma storage). Imagine a que toda vez que vc preciar fazer uma operação (workload noturno por exemplo) você tenha que realocar xGb em espaço em disco. Discos são comprovadamente lentos por se tratar de processos mecânicos e blá blá blá. Eu tenho em mente que se uso um Recovery Mode em Simple e tenho problemas de espaço é mais válido adicionar disco do que ficar fazendo sanfona com o banco de dados.

    Eu não acho e não recomendo o uso de shirink, mas eventualmente eu mesmo sou obrigado a usar.

    Uma outra coisa importante é o controle do crescimento (autogrouth), tenha em mente que se atingir o tamanho máximo as transações não serão efetivadas, se o processo noturno (workload) for muito grande, seu bando poderá entrar em Recovering até que seja feito o rollback das transações (isto não é um erro e não haverá perda de dados já comitados) e este processo normalmente tem uma duração semelhante ao tempo de processamento (é um chute) por exemplo 1 hora rodando, estouro de log, 1 hora de rollback. Então cuidado ao definir um tamanho máximo, esteja certo de que irá comportar sua necessidade.


    View Ricardo Muramatsu's profile on LinkedIn
    quarta-feira, 19 de outubro de 2011 17:21