Tamanho do log virtual do SQL Server


8

Sou um DBA acidental, sendo um desenvolvedor que herdou alguns servidores de banco de dados (2005 e 2008) de alguém que sabia pouco sobre administração de banco de dados e, aparentemente, tinha ainda menos interesse em aprender mais sobre o assunto.

Estou aprendendo e continuando tentando descobrir os arquivos de log de transações.

Todos os nossos bancos de dados foram configurados com o modelo de recuperação simples e o autoshrink. Entendi que o uso do autoshrink geralmente é uma ideia horrível, mas entendo que isso foi feito para impedir que os logs de transações fiquem fora de controle. (O autoshrink realmente reduz o (s) arquivo (s) de log ou apenas o banco de dados?)

Eu descobri isso sobre o SQL Server 2012 e fiquei pensando se isso é verdade sobre 2005 e / ou 2008 e exatamente o que isso significa: "Quando um banco de dados usa o modelo de recuperação simples, o Mecanismo de Banco de Dados trunca o log de transações após um ponto de verificação. [. ..] O Mecanismo de Banco de Dados aciona um ponto de verificação automático no modelo de recuperação simples quando o log virtual fica 70% cheio. " Onde está especificado o tamanho do log virtual?

Quero desativar a redução automática em todos os bancos de dados, mas antes de fazer isso, preciso saber que os arquivos de log não ficarão fora de controle rapidamente.

Qualquer ajuda seria muito apreciada.


11
Leia este rusanu.com/2012/07/27/how-to-shrink-the-sql-server-log e veja se ele esclarece o que está acontecendo.
Remus Rusanu

Respostas:


6

Um único arquivo de log de transações possui um tamanho físico (que você vê no disco) e também é dividido no arquivo físico em seções lógicas chamadas arquivos de log virtuais (VLFs).

O crescimento automático e o encolhimento automático operam no arquivo de log de transações físicas .

O truncamento do log de transações (também chamado de "limpeza de log") opera nas seções lógicas do log de transações (VLFs) e não afeta o tamanho do arquivo físico. Esta parte é frequentemente objeto de confusão.

Um arquivo de log sempre deve crescer para acomodar uma transação grande; desativar o encolhimento automático deixará o arquivo de log com o tamanho máximo necessário, em vez de diminuir fisicamente o tamanho.

Se você não tiver transações grandes, será seguro desativar a redução automática; os arquivos de log não crescerão sem limites, como aconteceria se o banco de dados estivesse dentro FULLou BULK_LOGGEDvocê não estivesse fazendo backups de log de transações.

Esse comportamento é o mesmo para o SQL Server 2005+.


Obrigado, é sobre isso que eu estava procurando quando fiz a pergunta. Cheguei às mesmas conclusões depois de ler a resposta anterior de Remus.
Petter Brodin 10/10/12

2

Então, aqui está o que eu encontrei depois de ler as outras respostas aqui e fazer algumas pesquisas por conta própria:

P: "O autoshrink reduz realmente os arquivos de log ou apenas o banco de dados?" A: Pelo que entendi: sim, ele faz. O autoshrink é definido no nível do banco de dados e afeta todos os arquivos (visto se você clicar com o botão direito do mouse no banco de dados -> propriedades -> arquivos ou se executar a consulta 1). O crescimento automático, no entanto, funciona em um nível por arquivo.

P: "Onde está especificado o tamanho do log virtual?" R: Veja a resposta de Jon Seigel e o link que Remus postou. Para ver o tamanho do log físico e lógico, use a consulta 2

Um problema é que, se o banco de dados tiver o modo de recuperação completo ativado, aumentado para um tamanho grande e o modo de recuperação alterado para simples, um ponto de verificação não será acionado, pois o VLF terá crescimento automático. É possível tentar resolver isso (consulte a resposta do Remus para problemas em potencial com os cabeçalhos / cauda dos arquivos de log) executando a consulta 3, que reduzirá o arquivo de log ao tamanho em que estava quando foi originalmente criado.

Consultas:

1)

SELECT name, physical_name AS current_file_location, DB_NAME(database_id) AS dbname
FROM sys.master_files
WHERE DB_NAME(database_id) = 'mydb'

2)

DECLARE @tmpt TABLE(
    dbname VARCHAR(255),
    logsize DECIMAL,
    logspaceused DECIMAL,
    stat INT
)

INSERT INTO @tmpt
    EXEC ('DBCC SQLPERF(LOGSPACE)')

SELECT * FROM @tmpt WHERE dbname LIKE 'mydb' ORDER BY logspaceused DESC

3)

checkpoint
DBCC SHRINKFILE('logfile_name')

2

Como você consultou sua pergunta, no SQL 2005 e 2008 após o ponto de verificação, o arquivo de log de transações também será truncado.

Minha sugestão seria definir o modelo de recuperação como completo e criar uma tarefa para fazer um backup do arquivo de log de transações. Este trabalho pode ser agendado no seu banco de dados e truncará o log de transações após o backup. Ele truncará automaticamente o arquivo de log para você. Por favor, dê uma olhada nos links abaixo:

SQL Server 2005: http://technet.microsoft.com/en-us/library/ms189085(v=sql.90).aspx

SQL Server 2008: http://technet.microsoft.com/en-us/library/ms189085(v=sql.100).aspx


Sim, esse é o meu plano a longo prazo, mas por enquanto eu só quero me livrar do autoshrink.
Petter Brodin

Alterações: você deseja alterá-las para recuperação COMPLETA, mas antes de avaliar se é realmente necessário ou não. Se você precisar restaurar o mais próximo possível de um desastre, faça isso. Se voltar ao último backup completo (geralmente à noite) é bom, o modo de recuperação SIMPLES funcionará bem para você.
Cfradenburg 9/10/12
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.