Microsoft SQL Server: ¿qué significa que un registro de transacciones esté lleno?

Question

¿Qué significa que un registro de transacciones esté lleno? Lo tengo configurado para que el archivo crezca un 20% cuando sea necesario. Me quedan 4 GB en el disco. ¿Cómo resuelvo este problema permanentemente? La ejecución de estos comandos resuelve el problema temporalmente:

DBCC SHRINKFILE('MyDatabase_log', 1)
BACKUP LOG MyDatabase WITH TRUNCATE_ONLY
DBCC SHRINKFILE('MyDatabase_log', 1)

Answer 1

El registro de transacciones es donde el servidor SQL 'registra' cada cambio que hace para que si algo sale mal (desde un bloqueo de software hasta una falla de energía, un ataque de asteroide ... bueno, tal vez no sea un ataque de asteroide), puede " recuperar " por "deshacer" todos los cambios que ha realizado, desde el último "CheckPoint" consistente - volviendo a lo que fue el último " Consistente " estado de la base de datos ... en ese punto de control. Cada vez que una transacción se completa (o se confirma), todos los cambios que se han almacenado en el registro de transacciones se marcan como "ok", y el marcador CheckPopint puede avanzar después de esos cambios, de modo que la recuperación futura solo "deshacerá" cambia a algún punto después de eso. Después de que esto suceda, todas las entradas en el Registro de transacciones anteriores al CheckPoint ya no son necesarias para recuperarse de un bloqueo del sistema ... pero aún pueden ser necesarias para recuperarse de un bloqueo del disco duro, así que ...

Como mencionó el otro caballero, el "modelo de recuperación" que ha configurado en el servidor controla lo que sucede con las entradas del Registro de transacciones antes de los puntos de control. En modo simple, se eliminan cuando se produce un punto de control, pero está en riesgo si el disco de datos principal falla, porque su registro de transacciones no contendrá los cambios escritos en el disco desde la última copia de seguridad.

En los otros modelos de recuperación, las entradas del Registro de transacciones no se eliminan hasta que realice una Copia de seguridad, lo que lo protege contra este riesgo ...

Entonces, en general, cuando ocurre este problema, es porque el servidor está en uno de los " normal " (no simple) modelos de recuperación configurados, (incrementales o completos) y no están haciendo copias de seguridad .... En este caso, el Registro de transacciones sigue creciendo ... y creciendo ... como los anuncios de próstata en la televisión ...

Answer 2

Parece que no tienes una estrategia de respaldo implementada. La realización de cualquiera de las copias de seguridad (Registro completo, diferencial o de transacciones) truncará el registro con el beneficio adicional de guardar un punto desde el cual puede recuperarse en caso de falla. Puede ejecutar el Asistente de mantenimiento de la base de datos para ayudarlo a configurar una programación de copias de seguridad para que se ejecute periódicamente.

Si honestamente no le importan sus datos (en cuyo caso, me pregunto por qué tiene una base de datos), puede configurar el Modo de recuperación de la base de datos en "Simple". lo que evitará que el TLog crezca en absoluto.

Una última cosa: si está realizando operaciones de carga masiva, también podría considerar cambiar a " Bulk-Logged " mientras realiza las operaciones masivas.

Answer 3

Debe mirar Modelos de recuperación de SQL Server . La respuesta corta es cambiar el modelo de recuperación a "Simple", pero esto tiene implicaciones para la copia de seguridad / recuperación.

Answer 4

Realice copias de seguridad a menudo, el registro de transacciones se borra cada vez que realiza una copia de seguridad de la base de datos.

Answer 5

Debe hacer una copia de seguridad del registro de transacciones no solo de la base de datos o el registro continuará creciendo hasta que se quede sin espacio.

Answer 6

Otra respuesta simple es que su copia de seguridad podría no estar programada. Durante un ciclo de actualización, una de nuestras programaciones de respaldo de bases de datos fue eliminada del trabajo. El registro creció hasta que descubrimos que la copia de seguridad no se estaba ejecutando.

Answer 7

No haría una tasa de crecimiento del 20%. Eso puede tener grandes consecuencias cuando necesita crecer. Si alguna vez creciera a, digamos, 100 GB, tendría que crecer en 20 GB en el próximo crecimiento, prepárese para que su sistema se desacelere en lugar de que esto suceda ... En cambio, lo establecería en una tasa fija, digamos 100 MB . Por supuesto, no sabemos el tamaño actual para hacer una recomendación más precisa.

Answer 8

Hay muchas formas diferentes de resolver este problema. Depende de cuáles sean sus requisitos de respaldo.

El problema principal es que los registros de transacciones no se respaldan regularmente, lo que hace que el registro de transacciones siga creciendo.

SQL Server 2005 tiene un modo de recuperación Simple (una propiedad / opción en la propia base de datos), que uso principalmente en entornos DEV y TEST donde no se requieren instantáneas por hora, el registro de transacciones solo crece suficiente para manejar la transacción más grande ejecutada en el servidor. No se requieren cronogramas ni planes de mantenimiento para este modo de recuperación.

En SQL Server 2000, básicamente tenía una secuencia de comandos de copia de seguridad programada que ejecutaba el mismo comando que usaba, aproximadamente cada hora:

REGISTRO DE COPIA DE SEGURIDAD MyDatabase WITH TRUNCATE_ONLY

Para entornos de producción, normalmente tenemos una copia de seguridad del registro de transacciones por hora y una copia de seguridad completa diaria programada en los planes de mantenimiento de la base de datos. Esto mantiene el registro de transacciones truncado a un tamaño razonable (un tamaño que contiene 1 hora de datos de transacciones, obviamente).