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.