Início / dba / Perguntas / 78037
Accepted
Tom
Asked: 2014-10-01 03:51:42 +0800 CST

VLF, Encolhimento e Recuperação Simples

  • 772

Atualmente, temos um log de transações que está crescendo de forma incremental e possui muitos arquivos VLF. Vou seguir um processo de redução e, em seguida, aumentar novamente o arquivo de log para um tamanho adequado para aliviar esse problema.

Minha pergunta é que o encolhimento reduzirá apenas do final do arquivo até a última parte ativa do log. Portanto, devo mudar para recuperação simples primeiro e depois realizar a redução?

Em seguida, voltarei a executar um backup completo para iniciar a cadeia de backup novamente.

sql-server transaction-log

2 respostas

  1. Best Answer

    Não, não mude para o modelo de recuperação SIMPLE, pois isso resultará em uma quebra na sua cadeia de backup. Se você estiver fazendo no modelo de recuperação TOTAL, faça o seguinte:

    1. PONTO DE VERIFICAÇÃO
    2. BACKUP do LOG
    3. DBCC SHRINKFILE (arquivo de log, tamanho do alvo)

    Repita até encolher o arquivo de log o menor possível. (Minha experiência é que geralmente são necessárias duas ou três vezes.)

    Em seguida, defina o tamanho de log padrão preferido e o incremento de crescimento para o log. Não use crescimento de log percentual, mas tenha um incremento definido.

    Se você seguir isso, a cadeia de backup será preservada.

    Se houver motivos pelos quais você precisa mudar para o modelo de recuperação SIMPLES, depois de retornar ao modelo de recuperação COMPLETO, você deve FAZER BACKUP DO BANCO DE DADOS para restabelecer o ponto inicial para os próximos backups de log.

    • 1

  2. Já que você mencionou muitas coisas más que fará em seu banco de dados, devo deixar claro

    Atualmente, temos um log de transações que está crescendo de forma incremental e possui muitos arquivos VLF. Vou seguir um processo de redução e, em seguida, aumentar novamente o arquivo de log para um tamanho adequado para aliviar esse problema.

    Pode haver muitos motivos para o arquivo de log crescer fora de proporção, alguns são transações não confirmadas de execução longa, uma transação com início de tran, mas sem confirmação, isso impedirá que os logs sejam truncados quando ocorrer o próximo backup de log. Quando você disse muitos arquivos VLF, imediatamente percebeu que você não definiu o valor adequado para o crescimento automático. No seu caso, parece-me que você manteve o valor muito baixo. Peço que você leia este link que você pode usar abaixo da consulta para verificar o crescimento automático e quando isso está acontecendo.

    DECLARE @filename NVARCHAR(1000);
DECLARE @bc INT;
DECLARE @ec INT;
DECLARE @bfn VARCHAR(1000);
DECLARE @efn VARCHAR(10);

-- Get the name of the current default trace
SELECT @filename = CAST(value AS NVARCHAR(1000))
FROM ::fn_trace_getinfo(DEFAULT)
WHERE traceid = 1 AND property = 2;

-- rip apart file name into pieces
SET @filename = REVERSE(@filename);
SET @bc = CHARINDEX('.',@filename);
SET @ec = CHARINDEX('_',@filename)+1;
SET @efn = REVERSE(SUBSTRING(@filename,1,@bc));
SET @bfn = REVERSE(SUBSTRING(@filename,@ec,LEN(@filename)));

-- set filename without rollover number
SET @filename = @bfn + @efn

-- process all trace files
SELECT
  ftg.StartTime
,te.name AS EventName
,DB_NAME(ftg.databaseid) AS DatabaseName  
,ftg.Filename
,(ftg.IntegerData*8)/1024.0 AS GrowthMB
,(ftg.duration/1000)AS DurMS
FROM ::fn_trace_gettable(@filename, DEFAULT) AS ftg
INNER JOIN sys.trace_events AS te ON ftg.EventClass = te.trace_event_id  
WHERE (ftg.EventClass = 92  -- Date File Auto-grow
    OR ftg.EventClass = 93) -- Log File Auto-grow
ORDER BY ftg.StartTime

    Minha pergunta é que o encolhimento reduzirá apenas do final do arquivo até a última parte ativa do log.

    A redução do log de transações reduz seu tamanho físico removendo um ou mais arquivos de log virtuais inativos. A unidade da redução de tamanho é sempre o arquivo de log virtual. Por exemplo, se você tiver um arquivo de log de 600 megabytes (MB) que foi dividido em seis logs virtuais de 100 MB, o tamanho do arquivo de log só poderá ser reduzido em incrementos de 100 MB. O tamanho do arquivo pode ser reduzido para tamanhos como 500 MB ou 400 MB, mas o arquivo não pode ser reduzido para tamanhos como 433 MB ou 525 MB. Um arquivo de log virtual que contém qualquer registro de log ativo, ou seja, um arquivo de log virtual ativo, faz parte do log lógico e não pode ser removido

    Portanto, devo mudar para a recuperação simples primeiro e, em seguida, realizar a redução? Em seguida, voltarei para a execução completa de um backup completo para iniciar a cadeia de backup novamente.

    Alterar o modelo de recuperação para simples o privaria da recuperação pontual. Além disso, você precisa fazer backup de log antes de alterar o modelo de recuperação para simples e fazer backup completo depois de alterá-lo novamente para completo. Outra coisa a observar é que, se você não precisar de recuperação pontual, deixe seu banco de dados em recuperação simples; nesse caso, você não precisaria fazer backups de log para truncar o log.

    Se o seu banco de dados estava em recuperação total, com que frequência você fez o backup do log de transações, observe que, na recuperação total, apenas o backup do log de transações trunca o log (se nada o estiver segurando)

    O que a consulta abaixo retorna

    select log_reuse_wait_desc from sys.databases where name='db_name'

    A consulta acima informará o que está mantendo os logs e não permitindo que eles sejam truncados e, portanto, reutilizados.

    Finalmente, você deve ler Por que o log de transações continua crescendo sem espaço

    • 1

relate perguntas