sql - tamaño - El registro de transacciones para la base de datos está lleno
reducir tamaño registro transacciones sql server 2008 (7)
¿Es esto una secuencia de comandos de una sola vez, o un trabajo que ocurre regularmente?
En el pasado, para proyectos especiales que requieren temporalmente mucho espacio para el archivo de registro, creé un segundo archivo de registro y lo hice enorme. Una vez que el proyecto está completo, eliminamos el archivo de registro adicional.
Tengo un proceso de larga ejecución que mantiene abierta una transacción durante todo el tiempo.
No tengo control sobre la forma en que esto se ejecuta.
Como una transacción se mantiene abierta durante todo el tiempo, cuando se completa el registro de transacciones, SQL Server no puede aumentar el tamaño del archivo de registro.
Entonces el proceso falla con el error "The transaction log for database ''xxx'' is full" .
Intenté evitar esto aumentando el tamaño del archivo de registro de transacciones en las propiedades de la base de datos, pero recibo el mismo error.
No estoy seguro de qué debo probar a continuación. El proceso se ejecuta durante varias horas, por lo que no es fácil jugar con prueba y error.
¿Algunas ideas?
Si alguien está interesado, el proceso es una importación de organización en Microsoft Dynamics CRM 4.0.
Hay un montón de espacio en disco, tenemos el registro en modo de registro simple y hemos hecho una copia de seguridad del registro antes de iniciar el proceso.
- = - = - = - = - UPDATE - = - = - = - = -
Gracias a todos por los comentarios hasta el momento. Lo siguiente me llevó a creer que el registro no crecería debido a la transacción abierta:
Estoy teniendo el siguiente error...
Import Organization (Name=xxx, Id=560d04e7-98ed-e211-9759-0050569d6d39) failed with Exception:
System.Data.SqlClient.SqlException: The transaction log for database ''xxx'' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
Entonces, siguiendo ese consejo fui a la log_reuse_wait_desc column in sys.databases " log_reuse_wait_desc column in sys.databases " y sostuvo el valor " ACTIVE_TRANSACTION ".
De acuerdo con Microsoft: http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx
Eso significa lo siguiente:
Una transacción está activa (todos los modelos de recuperación). • Puede existir una transacción de larga ejecución al inicio de la copia de seguridad del registro. En este caso, liberar el espacio puede requerir otra copia de seguridad de registro. Para obtener más información, consulte "Transacciones activas de larga duración" más adelante en este tema.
• Se difiere una transacción (SQL Server 2005 Enterprise Edition y versiones posteriores solamente). Una transacción diferida es efectivamente una transacción activa cuya reversión está bloqueada debido a algún recurso no disponible. Para obtener información sobre las causas de las transacciones diferidas y cómo sacarlas del estado diferido, consulte Transacciones diferidas.
¿He entendido mal algo?
- = - = - = - UPDATE 2 - = - = - = -
Acaba de iniciar el proceso con el tamaño de archivo de registro inicial establecido en 30 GB. Esto tomará un par de horas para completar.
- = - = - = - ACTUALIZACIÓN final - = - = - = -
El problema fue causado por el archivo de registro que consumió todo el espacio disponible en el disco. En el último intento, liberé 120GB y todavía lo usé todo y al final fallé.
No me di cuenta de que esto estaba ocurriendo anteriormente porque cuando el proceso se estaba ejecutando de la noche a la mañana, se estaba recuperando de la falla. Esta vez pude verificar el tamaño del archivo de registro antes de la reversión.
Gracias a todos por su aporte.
¿Ha habilitado el crecimiento automático y el crecimiento de archivos sin restricciones habilitados para el archivo de registro? Puede editarlos a través de SSMS en "Propiedades de la base de datos> Archivos"
Este es un enfoque de la vieja escuela, pero si está realizando una actualización iterativa o una operación de inserción en SQL, algo que se ejecuta durante mucho tiempo, es una buena idea llamar periódicamente "punto de control" (programáticamente). Llamar a "punto de control" hace que SQL escriba en el disco todos esos cambios solo de memoria (páginas sucias, se llaman) y elementos almacenados en el registro de transacciones. Esto tiene el efecto de limpiar su registro de transacciones periódicamente, evitando así problemas como el descrito.
Lo siguiente truncará el registro.
USE [yourdbname]
GO
-- TRUNCATE TRANSACTION LOG --
DBCC SHRINKFILE(yourdbname_log, 1)
BACKUP LOG yourdbname WITH TRUNCATE_ONLY
DBCC SHRINKFILE(yourdbname_log, 1)
GO
-- CHECK DATABASE HEALTH --
ALTER FUNCTION [dbo].[checker]() RETURNS int AS BEGIN RETURN 0 END
GO
Para solucionar este problema, cambie el Modelo de recuperación a Simple y luego reduzca el registro de archivos
1. Propiedades de la base de datos> Opciones> Modelo de recuperación> Simple
2. Tareas de la base de datos> Reducir> Archivos> Registro
Hecho.
Luego, verifique el tamaño del archivo de registro db en Propiedades de la base de datos> Archivos> Archivos de la base de datos> Ruta
Para verificar el registro completo del servidor sql: abra el Visor de archivos de registro en SSMS> Base de datos> Administración> Registros de SQL Server> Actual
Si su modelo de recuperación de base de datos está lleno y no tiene un plan de mantenimiento de copia de seguridad de registro, obtendrá este error porque el registro de transacciones se llena debido a LOG_BACKUP .
Esto evitará cualquier acción en esta base de datos (por ejemplo, reducir) y el motor de base de datos de SQL Server generará un error 9002.
Para superar este comportamiento, le aconsejo que verifique esto. El registro de transacciones para la base de datos ''SharePoint_Config'' está lleno debido a LOG_BACKUP que muestra los pasos detallados para resolver el problema.
Tuve este error una vez y terminó siendo el disco duro del servidor que se quedó sin espacio en disco.