Enorme registro de transacciones con la base de datos de SQL Server en el modo de recuperación simple

Question

Tengo una base de datos de SQL Server bastante grande que está utilizando el modo de recuperación SIMPLE. Realmente no tenemos necesidad de hasta la segunda recuperación, así que preferiría que nos quedáramos con este modo.

Por alguna razón, el registro de transacciones para esta base de datos es masivo (410 GB) con el 99% del espacio sin asignar.

He intentado contraer el archivo usando (DBCC SHRINKFILE (MyDatabase_log, 20000)) pero parece que no funciona.

¿Alguien tiene alguna sugerencia sobre por qué una base de datos de modo de recuperación SIMPLE tendría un archivo tan grande? Realmente me gustaría que se redujera mucho.

Answer 1

Significa que una vez tuvo una sola transacción que duró tanto tiempo que obligó al registro a crecer 410GB. El registro no se puede reutilizar si hay una transacción activa ya que la información de restitución no se puede borrar. Tal ejemplo sería si alguien abre una consulta SSMS, inicia una transacción, actualiza un registro y luego se va de vacaciones. La transacción estará activa y obligará al registro a crecer hasta que se comprometa o se retrotraiga. Cuando la transacción finalmente finaliza, el espacio usado finalmente puede recuperarse, dejando un enorme archivo de registro vacío.

Otro escenario es si tiene aproximadamente 200 GB de datos actualizados en una sola transacción. El registro almacenará las imágenes de antes y después de los cambios, consumiendo así el doble de espacio, y no se podrá reutilizar, nuevamente porque es una única transacción.

actualización

me olvidó mencionar que la replicación es también un factor que puede impedir que el truncamiento del registro. Y también lo es Mirroring, una transacción distribuida (técnicamente eso es lo mismo que una 'transacción activa', pero la implicación de DTC lo convierte en un caso distinto). La lista completa y las explicaciones se encuentran en Factors That Can Delay Log Truncation.

Answer 2

que se está perdiendo un argumento en dbcc shrinkfile:

dbcc shrinkfile (MyDatabase_log, 20000, TRUNCATEONLY) 

NOTRUNCATE es el valor predeterminado, que se mueve asigna bloques al inicio del espacio no asignado. TRUNCATEONLY elimina el espacio no asignado. Entonces, si haces un NOTRUNCATE seguido de un TRUNCATEONLY, obtienes un registro adelgazado.

Answer 3

Si tiene solo un archivo mdf y un archivo de registro, quizás la forma más sencilla sea separar la base de datos, cambiar el nombre del registro y volver a conectar la base de datos. SQL Server creará un nuevo archivo de registro. Después de eso, su gran archivo de registro se puede eliminar de forma segura.

Sin embargo, esto no funcionará si tiene varios archivos de datos.

Answer 4

Replication Publisher? ¿Podría ser esta la razón del gran registro de transacciones?

Answer 5

Como se ha dicho en otras respuestas, transacciones activas y Replications son causas comunes de este problema.
Otro, menos visible, es Change Data Capture (CDC).

tuve un problema similar hace poco y el procedimiento que me permitió liberar a la madera era el siguiente:

• Desactivar CDC: EXEC sys.sp_cdc_disable_db
• crear una publicación en una mesa arbitraria dentro de la base de datos en cuestión
• Borrar esta/todas publicación (s). EXEC sp_removedbreplication 'my_db' es una forma conveniente de hacerlo.
• reducir el registro según se desee

estoy seguro de por qué era necesario la creación/supresión de esta maniquí/nunca utilizado publicación, pero fue así. Tentativamente, la base de datos puede haber tenido publicaciones anteriores que no se eliminaron correctamente (se dice que ocurre con frecuencia con las bases de datos restauradas de una copia de seguridad anterior).

Otro lenguaje de diagnóstico útil es comprobar la log_reuse_wait_desc en sys.databases para la base de datos infractor. Este campo lee REPLICATION hasta que complete el procedimiento anterior.

SELECT log_reuse_wait_desc, * FROM sys.databases where name = 'my_db'