Consultas re Backup de SQL, arquivos de log e Log Shipping

3

Recebi um arquivo .bak de backup do servidor MS-SQL para restaurar em minha máquina que tinha cerca de 25 MB, mas precisava de 10 GB de espaço livre em disco porque o arquivo de log era desse tamanho, o que indica que o arquivo de log não é sendo recuado ou truncado. (Note que o arquivo de log de 10Gb deve estar quase vazio, caso contrário o arquivo .bak seria muito maior que 25mb)

Este banco de dados é um pouco usado (e possivelmente não muito importante) banco de dados, e o mesmo site tem outro banco de dados muito mais importante e muito maior (tamanho em algum lugar na região de 5 Gb) que possui um arquivo de log menor por isso estou assumindo que o arquivo de log para esse banco de dados está sendo cortado.

Foi-me dito que o site usa o envio de log para fazer backup de seu banco de dados principal para um segundo servidor, mas não tenho certeza se o banco de dados menor também está sendo submetido a backup.

Então, estou supondo que ou eles estão usando somente o envio de logs para o banco de dados principal ou estão apenas fazendo backup do banco de dados principal.

O que levanta algumas questões

  1. Existe algum tipo de backup que um usuário / administrador no site possa realizar interferindo ou interrompendo o envio de logs?
  2. Se você usar o envio de logs, isso é suficiente para garantir que os logs não cresçam continuamente ou ainda precisa fazer o backup dos logs (usando, por exemplo, um plano de manutenção)?
  3. Este não é muito importante, mas se algum dia eu obtiver um backup que precise de mais espaço para um arquivo de log do que o disponível, existe alguma maneira de restaurá-lo sem o arquivo de log ou sem corrigir o problema na origem e recebendo um novo backup.
por sgmoore 11.08.2011 / 13:07

1 resposta

3

O SQL na verdade não redimensiona o log após um backup de log - em vez disso, ele apenas altera os metadados internos para marcar partes do log (chamadas Virtual Log Files ou VLFs) que podem ser reutilizadas. Esse processo é chamado de truncamento de log. Portanto, seu arquivo de log crescerá se não houver VLFs livres, mas nunca diminuirá, a menos que você diga manualmente ao SQL Server para fazer isso.

Como o tamanho do log do banco de dados é 10Gb, a restauração do backup também criará um arquivo de log de 10Gb, independentemente da quantidade realmente em uso. O mesmo se aplica a qualquer arquivo de dados.

Você pode reduzir o arquivo de registro usando o comando ' DBCC SHRINKFILE ' - embora, a menos que você É certo que o log não vai crescer para 10Gb novamente, então eu recomendo contra fazê-lo (há um impacto no desempenho do crescimento do arquivo). Transações de longa duração ou atividades de manutenção de banco de dados podem consumir muito log de transações, portanto vale a pena descobrir por que o log está em 10Gb antes de encolher.

Para responder às suas três perguntas:

Existe algum tipo de backup que um usuário / administrador no site possa realizar interferindo ou interrompendo o envio de logs?

Sim - se você interromper a cadeia de backup fazendo o backup do log em um destino fora da configuração de envio de log, resultando na não aplicação do backup no servidor secundário. Você deve usar backups COPY_ONLY nessa situação, pois eles não afetarão a cadeia de log. Isso se aplica apenas aos backups de log, pois os backups completos não truncam o log.

Se você usar o envio de logs, isso é suficiente para garantir que os logs não cresçam continuamente ou ainda seja necessário fazer o backup dos logs (usando, por exemplo, um plano de manutenção)?

Isso deve estar bem, a menos que exista algo mais que impeça que o log seja truncado, como espelhamento de banco de dados, transações de longa execução, replicação ou mesmo criação de instantâneo de banco de dados. A maneira de descobrir por que seu log não está sendo truncado é examinar a coluna log_reuse_wait_desc em sys.databases .

Também é possível (mas improvável) que a tarefa de backup para o envio de logs esteja fazendo backups usando COPY_ONLY / NO_TRUNCATE, o que significa que o arquivo de log aumentará continuamente quando estiver cheio.

Esse não é muito importante, mas se eu tiver um backup que precise de mais espaço para um arquivo de log do que o disponível, existe alguma maneira de restaurá-lo sem o arquivo de log ou sem corrigir o problema? na origem e obtendo um novo backup.

Se você reduzir o arquivo de log e fizer um backup completo, quando for restaurá-lo, o SQL Server criará o banco de dados usando o arquivo de log menor.

Se você não puder reduzir, mas estiver restaurando para um servidor de desenvolvimento / teste, poderá montar um armazenamento temporário e usar 'WITH MOVE' na instrução RESTORE para mover o arquivo de log para essa unidade, depois reduzir o log e mover o arquivo de log fora do armazenamento temporário (avisos sobre se você deve reduzir o log ou ainda não se aplicam!).

    
por 14.08.2011 / 14:53