sql-server - transacciones - reducir log sql server 2005

Enorme registro de transacciones: ¿es esto normal?

Question

Tengo una base de datos de 5GB y un registro de transacciones de 20GB (SQL Server 2005). No estoy seguro de por qué es tan grande o lo que sucedió para que sea tan grande, solía ser alrededor de 1/2 del tamaño de la base de datos. DB crece alrededor de 1GB / mes.

¿Hay alguna guía sobre cuán grande debe ser su registro de transacciones en relación con el tamaño de su archivo de base de datos?

EDITAR: No estoy diciendo que mi registro de transacciones sea enorme (sé que algunos DBA se reirán de mi base de datos del tamaño de un weenie), solo en relación con el archivo DB, creo que es enorme.

Answer 1

En términos de "esto es normal", tenga en cuenta que las transacciones se acumulan en el registro para siempre hasta que las copias de seguridad y los puntos de control se configuren correctamente. Por ejemplo, si no lo hace, cada registro en la base de datos tiene al menos una transacción de inserción.

Answer 2

Er ... disculpe el sangrado obvio, pero ¿tiene copias de seguridad programadas con "BACKUP LOG"?

Si el modelo de recuperación es FULL, entonces esto debe suceder.

Hay otras opciones raras que incluiré (no exhaustivas):

• Reconstrucción / mantenimiento de índice de tabla grande. Sin embargo, el registro de copia de seguridad lo limpiará.
• Una transacción abierta que impide el registro de copia de seguridad eliminando entradas (de ahí que crezca)
• Una conexión con SET IMPLICIT_TRANSACTIONS ON (ver punto anterior)

Answer 3

Si tiene mucho comportamiento transaccional, no es raro en absoluto. Sin embargo, probablemente debas investigar los medios para hacerlo más pequeño. Hay bastantes opciones para esto, pero sin conocer su modelo de recuperación, nunca podría suponer hacer una recomendación. Comience con este enlace de MSDN , este artículo de la base de conocimientos , luego muévase desde allí. Cuidadosamente. :)

Answer 4

Si tiene un código que realiza muchas transacciones (en relación con el tamaño real de la base de datos), ciertamente inflará el registro.

Si no tiene uno ahora, definitivamente recomendaría configurar un plan de mantenimiento de la base de datos para hacer copias de seguridad nocturnas (y quizás copias de seguridad de registro de transacciones más frecuentes). Normalmente, el proceso de copia de seguridad reducirá el tamaño del registro a algo razonable una vez que se complete la copia de seguridad.

En cuanto a una guía general, trato de mantenerla por debajo del 50% del tamaño de la base de datos, aunque con el plan de respaldo, generalmente no veo que nuestros registros se acerquen demasiado a eso.

Si no le importa guardar los registros de transacción, este tipo de consulta lo reducirá, pero primero leí en Shrinkfile.

Backup Log DatabaseName With Truncate_Only
GO
Declare @LogFileLogicalName sysname
select @LogFileLogicalName=RTRIM(Name) from sysfiles where filename like ''%.ldf%''
--SELECT @LogFileLogicalName
DBCC Shrinkfile(@LogFileLogicalName,2)

Answer 5

Además de verificar qué modelo de recuperación se utiliza en la base de datos, puede ir más allá con respecto a " qué pasó para que sea tan grande ": puede leerlo y ver qué tipo de transacciones y cuántas de ellas se guardan en el registro . Además, puede inspeccionar cuándo ocurrieron las transacciones y quién las ejecutó

Para hacerlo, puede usar las funciones nativas de SQL Server fn_dblog , DBCC PAGE o fn_dump_dblog o alguna herramienta de terceros. Sin embargo, las funciones nativas no están documentadas y es muy difícil entender los resultados que proporcionan. En cuanto a una herramienta de terceros, puede consultar el archivo Open LDF y ver el artículo en línea sobre el contenido del archivo LDF para obtener más detalles y un análisis más profundo de lo que se necesita para leer la información del registro de transacciones.

Descargo de responsabilidad: trabajo como ingeniero de soporte de productos en ApexSQL