none
Backup de arquivos de LOG. RRS feed

  • Pergunta

  • Caros boa tarde.

    Estou com meu arquivo de LDF com 32Gb e está grande, para minha base.

    O  backup dos logs é executado de 1 em 1 hora,  e é armazenado em ( Storage de duplicação).

    A questão é : Se eu mudar a recuperação para simples ao invés do FULL( como estava) eu perco o bkp dos Logs? 

    O pessoal de Storage me informou que temos 3 tipos de backup ( Full( 1 vez por semana), LOG (de 1 em 1hra), Diferencial(1 vez ao dia) ).

    No meu entendimento minha situação é :  Tenho 1 bkp ful no domingo, e 1 diferencial pela manha.   Se  precisar de um recover  terei os dados da semana  passada devido ao bkp full, e o diferencia do período da manha....logo, na necessidade de um recover da base após  o diferencial,  terei um intervalo que pode ser de até 12hrs. ( Prejuízo)

    Alguém poderia me dar uma orientação?

    VLW

    [ ]s


    quinta-feira, 31 de outubro de 2013 17:09

Respostas

  • Olá!

    Você não perde o backup dos logs mas você rompe a log chain. Isto significa que você poderá restaurar seu ambiente até o momento que você mudou pra SIMPLE e só voltará a ter backup de Transaction Log depois de um backup FULL da base.

    Mudar para SIMPLE não diminui o tamanho do seu arquivo de Transaction Log. O tamanho ideal do Transaction Log não está relacionado ao tamanho da sua base mas a quantidade e tamanho das transações realizadas.

    Verifique quantos % do seu arquivo está sendo utilizado através do DBCC SQLPERF(logspace).

    Tente procurar também o motivo de o arquivo ter chegado a este tamanho, um REBUILD de índices, uma transação ativa há muito tempo, problemas com replicações ou mirroring, entre outros. Se o seu arquivo de Transaction Log estiver cheio você pode verificar o motivo por não ter sido truncado através da coluna log_reuse_wait_desc da sys.databases (SELECT * FROM sys.databases).

    Ficou mais alguma dúvida?

    Abs!



    Luiz Mercante
    MCITP SQL 2008 | MCTS SQL 2008 | MTA Database Fundamentals | MCTS Windows Apps | MCTS Windows Network | MCP 2003
    sqldicas@outlook.com
    http://sqldicas.com.br
    Se a resposta foi útil de alguma forma, classifique como resposta ou vote como útil.

    quinta-feira, 31 de outubro de 2013 17:29

Todas as Respostas

  • Olá!

    Você não perde o backup dos logs mas você rompe a log chain. Isto significa que você poderá restaurar seu ambiente até o momento que você mudou pra SIMPLE e só voltará a ter backup de Transaction Log depois de um backup FULL da base.

    Mudar para SIMPLE não diminui o tamanho do seu arquivo de Transaction Log. O tamanho ideal do Transaction Log não está relacionado ao tamanho da sua base mas a quantidade e tamanho das transações realizadas.

    Verifique quantos % do seu arquivo está sendo utilizado através do DBCC SQLPERF(logspace).

    Tente procurar também o motivo de o arquivo ter chegado a este tamanho, um REBUILD de índices, uma transação ativa há muito tempo, problemas com replicações ou mirroring, entre outros. Se o seu arquivo de Transaction Log estiver cheio você pode verificar o motivo por não ter sido truncado através da coluna log_reuse_wait_desc da sys.databases (SELECT * FROM sys.databases).

    Ficou mais alguma dúvida?

    Abs!



    Luiz Mercante
    MCITP SQL 2008 | MCTS SQL 2008 | MTA Database Fundamentals | MCTS Windows Apps | MCTS Windows Network | MCP 2003
    sqldicas@outlook.com
    http://sqldicas.com.br
    Se a resposta foi útil de alguma forma, classifique como resposta ou vote como útil.

    quinta-feira, 31 de outubro de 2013 17:29
  • Luiz, bom dia !

    Obrigado pelo retorno.

    Sim, eu tenho conhecimento que ao alterar para simples não  diminuiria o tamanho do arquivo LDF, mas que ao menos não aumentaria mais.

    Logo se parar de aumentar, é porque não atualiza transações realizadas.

    Aí que surgiu a duvida do backup.

    Não aumenta o LDF  = sem backup atualizado . 

    Luiz tenho como iniciar um novo arquivo de LDF?

    Não precisa nem ser menor, basta limpar esse arquivo antigo e utilizar o espaço dele mesmo.

    Entendo que por algum tempo ele não aumentaria o tamanho. 

    É  uma solução de contorno...a definitiva virá depois.

    A quantidade de  transações realizadas é significativa mesmo.  E atualmente estou aguardando uma atualização do time de DEV para corrigir uma aplicação,  que gera aproximadamente 400mil linhas por dia indevidamente em uma  única tabela.

    Isso  me ferra.... Hoje rodo uma JOB ,  que deleta toda noite  500 mil linhas.

     

    Bom....mais ima vez agradeço a ajuda.

     

    [  ]s


    sexta-feira, 1 de novembro de 2013 12:07
  • Daniel,

    Neste caso, a alternativa que você poderia utilizar é configurar um Job que a cada x dias realizada o processo de encolhimento de banco de dados, mas isso é algo que você tem que analisar e avaliar, pois em alguns cenários poderá ocasionar inicialmente fragmentação de dados.

    Outro ponto importante que o processo de encolhimento força a execução do processo de realocação das páginas de dados e isso também deve ser planejado e feito com cautela, sempre tendo um backup realizado antes de qualquer tipo de procedimento.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    sexta-feira, 1 de novembro de 2013 13:11
    Moderador
  • Boa tarde Junior.

    Obrigado pelo retorno.

    Vc. se refere ao Shrink, para encolher o Banco?

    Tenho lido algumas notas sobre essa ferramenta, e por enquanto não pretendo utiliza-la no MDF.

    Estou estudando a possibilidade de fazer no LDF.

    Por esse motivo( Shrink LDF) que estou pesquisando e recorrendo a ajuda de colegas que possam me orientar.

    vlw,

    [  ]s

    • Sugerido como Resposta Renato Siqueira sábado, 2 de novembro de 2013 00:53
    sexta-feira, 1 de novembro de 2013 16:50