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


24

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.


En realidad, he observado un fenómeno similar en una de las bases de datos de sitios de mis clientes con el modelo de recuperación SIMPLE. Los registros no crecen (sin embargo, de todos modos), pero el espacio utilizado en los archivos de registro que hace crecer por un poquito cada noche. Y sucede cuando se ejecuta la copia de seguridad de la base de datos. Todavía no he descubierto qué lo está causando ni si es un problema o no.
RBarryYoung

Respuestas:


20

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?


No creo que hagamos nada que requiera 300 MB de registro, pero incluso si lo hiciéramos, una vez hecho, ¿no aparecería como espacio libre en la base de datos? Al mirar las propiedades en la base de datos en SQL Server Management Studio, el tamaño es el tamaño de los datos y el registro, y esperaría que el espacio libre sea el espacio libre en los datos y el registro. ¿El espacio libre en el registro no aparece? El hecho de que no se mostrara como gratuito parecía que todavía estaba en uso, pero no había actividad en la base de datos.
DerekCate

1
No, una vez hecho, no se convierte automáticamente en espacio libre. Las transacciones confirmadas no se ponen a cero, su espacio se marca como disponible para su reutilización.
Aaron Bertrand

1
@DerekCate "No creo que estemos haciendo nada que requiera 300 MB de registro" ... Te sorprendería, no toma mucho tiempo obligar a la reutilización del registro de transacciones. No piense en términos de cantidad de carga de trabajo, ya que esa no siempre es la causa.
Thomas Stringer

Ok, solo para confirmar que entiendo esto correctamente, el registro de 300 MB, incluso si no se necesita actualmente, no se mostrará como espacio libre, pero se reutilizará. Y en algún momento, necesitaba 300 MB para manejar alguna transacción. Ok, nuevas cosas a considerar. ¡Gracias!
DerekCate

1
Otra cosa a tener en cuenta: un punto de control automático para una base de datos de recuperación simple solo se pone en cola una vez que el registro ya está lleno al 70%. Por lo tanto, es posible que no necesite tanta actividad de registro para generar crecimiento, según el momento.
Paul White dice GoFundMonica

6

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.


Si está viendo 50 MB gratis y un registro de 300 MB, fn_DBLOG () le dará una idea de lo que aumentaba el tamaño de su registro.
Kenneth Fisher

0

¿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.


La reducción automática no está habilitada en los DB, estamos buscando evitar la fragmentación del índice brentozar.com/archive/2009/08/… . Tenemos verificaciones semanales de integridad, pero no creo que haya ninguna reconstrucción de índice como parte de eso, tendré que investigar eso. Aparte de eso, no hay GUID, cada tabla tiene una columna de identidad que es la clave principal.
DerekCate

-3
 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
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.