Quando o banco de dados do SQL Server está no modo SIMPLES, você não precisa se preocupar com os bakcups do log de transações. Mas, no modo SIMPLES, o log de transações parece aumentar como no modo COMPLETO. É truncado automaticamente em algum momento? Ou eu tenho que truncar / encolher manualmente?
Respostas:
Ele truncará automaticamente, mas é muito diferente diminuir. O truncamento recupera espaço de log para reutilização, diminuindo fisicamente o tamanho do arquivo para liberar espaço de volta ao sistema operacional. Se o seu registro cresceu para o tamanho atual, é provável que ele cresça novamente se você o reduzir.
Eu sugiro que você identifique o uso típico e máximo de log para o seu sistema. A consulta abaixo (não a minha, impulsionada pelos scripts DMV da Glen Berrys) pode ser executada manualmente ou você pode capturar a saída em uma tabela por meio de um trabalho do agente. Se você registrá-lo em uma tabela por uma semana ou mais, obterá uma imagem do uso típico e, mais importante, quando um processo estiver fazendo com que o log cresça além do esperado.
SELECT
db.[name] AS [Database Name]
, db.recovery_model_desc AS [Recovery Model]
, db.log_reuse_wait_desc AS [Log Reuse Wait Description]
, ls.cntr_value AS [Log Size (KB)]
, lu.cntr_value AS [Log Used (KB)]
, CAST(
CAST(lu.cntr_value AS FLOAT) / CAST(ls.cntr_value AS FLOAT)
AS DECIMAL(18,2)
) * 100 AS [Log Used %]
, db.[compatibility_level] AS [DB Compatibility Level]
, db.page_verify_option_desc AS [Page Verify Option]
, db.is_auto_create_stats_on, db.is_auto_update_stats_on
, db.is_auto_update_stats_async_on, db.is_parameterization_forced
, db.snapshot_isolation_state_desc, db.is_read_committed_snapshot_on
FROM sys.databases AS db
INNER JOIN sys.dm_os_performance_counters AS lu
ON db.name = lu.instance_name
INNER JOIN sys.dm_os_performance_counters AS ls
ON db.name = ls.instance_name
WHERE lu.counter_name LIKE N'Log File(s) Used Size (KB)%'
AND ls.counter_name LIKE N'Log File(s) Size (KB)%'
AND ls.cntr_value > 0
OPTION (RECOMPILE);O truncamento do log de transações descreve o quando e por que o truncamento do log ocorre.
Se os registros de log nunca fossem excluídos do log de transações, acabariam preenchendo todo o espaço em disco disponível para os arquivos de log físico. O truncamento de log libera automaticamente espaço no log lógico para reutilização pelo log de transações.
Fatores que podem atrasar o truncamento de log são uma referência útil para entender por que seu log pode falhar em truncar e, portanto, crescer maior que o esperado.
Como mencionado anteriormente, não, ele não se encolherá automaticamente. No entanto, ele limpará algum lixo.
O motivo é que, no modelo de recuperação completa, você está dizendo ao SQL que deseja fazer backups de tlog para recuperação pontual, portanto, ele mantém um registro de todas as transações feitas em um banco de dados.
Como você está dizendo que deseja recuperação pontual, é necessário fazer backups completos e backups de tlog. Quando você concluir os backups do tlog, ele liberará o conteúdo do log (além do final) e começará novamente.
Pode ajudar se você pensar nesses arquivos como contêineres.
Minha sugestão é que, se os tlogs se tornarem grandes e incontroláveis, faça um backup completo. Alterne para o modelo de recuperação SIMPLE e SHRINK o arquivo tlog. Volte para o modelo de recuperação completa e execute a manutenção de fragmentação *. Como outros postaram, essa não é a melhor das práticas e levará a altos níveis de fragmentação.
Planeje e inicie um regime de backup depois disso.
* Índice reconstruir / reorganizar operações e desfragmentação no nível do disco . Isso não faz parte da manutenção de logs: você mantém seus T Logs fazendo backup deles. São recipientes que crescem quando se aproximam da capacidade. A reconstrução / reorganização pode ajudar a recuperar-se do gerenciamento inadequado de logs, levando ao uso de grandes unidades.