¿Por qué el registro de transacciones continúa creciendo en modo de recuperación simple con copias de seguridad nocturnas?

Antes de marcar inmediatamente como duplicado , he leído Mike Walsh ¿Por qué el registro de transacciones sigue creciendo o se queda sin espacio?, pero no creo que haya dado una respuesta a mi situación. Miré a través de una docena de preguntas similares, pero las más relevantes simplemente dijeron "duplicado" y señalaron la pregunta de Mike.

Detalles: Tengo un montón de ~ 500 MB de bases de datos en SQL Server 2008 R2, todo en modo de recuperación SIMPLE (no es mi elección), copias de seguridad completas nocturnas, con ~ 200 MB de archivos de datos y ~ 300 MB de archivos de registro. El registro no crece a 300 MB de inmediato, sino más bien lentamente en el transcurso de un par de meses. No hay transacciones abiertas en ninguno de ellos, al menos según sp_who2 y el monitor de actividad. Si hago clic derecho en la base de datos y selecciono propiedades, me dice que hay ~ 50MB gratis. Particularmente justo después de una copia de seguridad, ¿no debería estar libre todo el registro? En modo SIMPLE, ¿no debería estar libre el registro mientras no haya una transacción abierta?

log_reuse_wait_descde sys.databasesdice dice "NADA", que según la pregunta y la respuesta a las que se hace referencia anteriormente dice que no debe esperar nada para reutilizar el espacio.

Si hago 'DBCC SHRINKFILE', el archivo de registro se reduce a 1 MB, por lo que está dispuesto a reclamar el espacio. Puedo configurar algo que reduce los registros semanalmente y evitar que las cosas se salgan de control, pero estoy confundido sobre por qué SQL Server me obligaría a hacer eso.

Puedo entender si hubo alguna transacción loca que necesitó 300 MB para iniciar sesión, pero no estamos haciendo nada extremo, solo OLTP básico. De la pregunta / respuesta de Mike:

Modelo de recuperación simple: por lo tanto, con la introducción anterior, es más fácil hablar primero sobre el modelo de recuperación simple. En este modelo, le está diciendo a SQL Server: estoy de acuerdo con que use su archivo de registro de transacciones para la recuperación de bloqueo y reinicio (Realmente no tiene otra opción allí. Busque las propiedades de ACID y eso debería tener sentido rápidamente), pero una vez que no Ya no lo necesita para ese propósito de recuperación de bloqueo / reinicio, continúe y reutilice el archivo de registro.

SQL Server escucha esta solicitud en Simple Recovery y solo mantiene la información que necesita para realizar la recuperación de bloqueo / reinicio. Una vez que SQL Server está seguro de que puede recuperarse porque los datos se han endurecido en el archivo de datos (más o menos), los datos que se han endurecido ya no son necesarios en el registro y están marcados para truncamiento, lo que significa que se reutilizan.

Sigue diciendo que el espacio de registro debe reutilizarse, pero con este lento crecimiento en el transcurso de los meses, no parece que lo sea.

¿Qué me estoy perdiendo? ¿Hay algo que impide que SQL Server reconozca los datos como "reforzados" y libere el registro?

(editar) El informe posterior a la acción - También conocido, un poco de conocimiento es peligroso

Después de descubrir que esta es una "pregunta popular", sentí que debía una explicación de lo que sucedió hace 7 meses y de lo que aprendí a salvar a otras personas con algo de pena.

En primer lugar, el espacio disponible que ve en SSMS cuando ve las propiedades en una base de datos es el espacio disponible en el archivo de datos. Puede ver esto ejecutando lo siguiente en una base de datos, y encontrará que el espacio disponible informado por SSMS es la diferencia entre FileSizeMB y UsedSpaceMB:

SELECT
    DB.name,
    MF.physical_name,
    MF.type_desc AS FileType,
    MF.size * 8 / 1024 AS FileSizeMB,
    fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
    mf.name LogicalName
FROM
    sys.master_files MF
    JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE   DB.name = 'yourdatabasename'

Esto confirmó que, en circunstancias normales, estábamos usando muy poco espacio de registro (20 MB o menos), pero esto lleva al segundo elemento ...

En segundo lugar, mi percepción del crecimiento de los troncos era lenta con el tiempo. Sin embargo, en realidad los registros crecían rápidamente en las noches en que el responsable de aplicar parches para esta aplicación de terceros estaba aplicando parches. El parche se realizó como una transacción única, por lo que, dependiendo del parche, los datos de 200 MB necesitaban 300 MB de registro. La clave para rastrear eso fue la consulta de Aaron Bertrand en https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace

DECLARE @path NVARCHAR(260);

SELECT 
    @path = REVERSE(SUBSTRING(REVERSE([path]), 
    CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,
   [FileName],
    SPID,
    Duration,
    StartTime,
    EndTime,
    FileType = CASE EventClass 
       WHEN 92 THEN 'Data'
       WHEN 93 THEN 'Log'
    END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
    EventClass IN (92,93)
ORDER BY
    StartTime DESC;

Esto mostró que el registro estaba creciendo en ciertas tardes, cuando el cliente no estaba usando la base de datos. Eso llevó a la conversación con el chico que aplicaba los parches y la respuesta al misterio.

Gracias de nuevo por las personas que me ayudaron a llegar a la respuesta.

Es imposible para nosotros adivinar qué lo está causando, pero SQL Server no solo aumenta un archivo de registro a 300 MB por el gusto de hacerlo, sino que crece a 300 MB porque en algún momento desde su última operación de reducción, necesitaba eso mucho espacio de registro (ya sea debido a una gran transacción única o muchas pequeñas concurrentes). Tendría que rastrear los eventos de crecimiento del archivo de registro (hablé de esto aquí y aquí ) para intentar reducir cuándo o por qué sucede esto (también si registra la configuración de crecimiento del archivo es 300 MB o algo así, entonces crecerá en 300 MB tan pronto como necesite más de 1 MB de espacio para acomodar transacciones activas).

De todos modos, ¿por qué crees que necesitas reducir el archivo de registro una vez que ha alcanzado los 300 MB? ¿Realmente leíste todas las respuestas, a fondo, sobre la pregunta de Mike ? El archivo de registro NO se va a reducir por sí solo, porque reducir el archivo de registro a 1 MB, solo para que pueda crecer nuevamente durante sus transacciones más grandes, es una pérdida total de tiempo. ¿Qué vas a hacer con todo ese espacio libre mientras tanto?

Todas sus pruebas actuales ( DBCC SHRINKFILE, log_reuse_wait_desc) simplemente demuestran que en este momento está reutilizando los archivos de registro virtuales del registro de transacciones de manera adecuada. Pero cuando los eventos de crecimiento automático ocurren en el archivo de registro de transacciones, es una reacción a que el registro no se puede reutilizar.

A menudo, esa no es una condición continua (exactamente como te parece en este momento con la falta de síntomas que estás viendo actualmente). Hay un puñado de cosas que podrían causar este comportamiento, incluso en el modelo de recuperación simple.

Su mejor opción sería configurar un trabajo de recopilación de datos para extraerlo de forma rutinaria log_reuse_wait_descpara su base de datos, y registrarlo rutinariamente en algún lugar. Entonces debería poder realizar ingeniería inversa de lo que está causando la falta de reutilización de registros.

Sigue diciendo que el espacio de registro debe reutilizarse, pero con este lento crecimiento en el transcurso de los meses, no parece que lo sea.

Como he indicado anteriormente, no es normalmente una condición permanente que causa la falta de reutilización de registro de transacciones (salvo unos pocos casos de esquina, al igual que las transacciones mal construidos), por lo que tendría para determinar el momento cuando este está sucediendo. La recopilación de datos de diagnóstico livianos debería ser un buen comienzo.

¿Tiene habilitado el encogimiento automático en los DB? ¿Y / o tiene planes de mantenimiento programados para realizar reconstrucciones de índice?

Una reducción automática seguida del mantenimiento del índice producirá un volumen de registro significativo.

El mantenimiento del índice por sí solo también producirá un volumen de registro significativo, si hay problemas de diseño de la base de datos, como los índices agrupados en los GUID.

 create table #dblog (Databasename varchar(100),
                     logsize float,
                     logspace%] float,
                     [Status] int)

 insert into #dblog
 EXEC ('DBCC sqlperf(logspace)') 

 select * from #dblog

 alter table #dblog 
 add [lgspace used GB] float;

 update #dblog 
 set [lgspace used GB ] = (logsize*[logspace%]/1024)

 update #dblog 
 set [logsize] =([logsize]/1024)

 alter table #dblog 
 drop column [Status];

 select * from #dblog

 drop table #dblog