¿Cómo afecta la reducción del archivo de registro de SQL Server al rendimiento?

Tengo una base de datos SQL Server 2008 que tiene un archivo de datos de unos 2 GB de tamaño, pero el archivo de registro tiene más de 8 GB. Con las bases de datos anteriores a 2008, podría usar el 'Registro de copia de seguridad' y la TRUNCATE_ONLYopción, pero esto ya no está disponible con las bases de datos de 2008 y posteriores.

Tengo un script que trunca el archivo de registro:

USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO

Esto trunca el archivo de registro por completo, pero mi pregunta es: ¿esto afecta el rendimiento?

Realizo dos copias de seguridad completas diariamente, por lo que el registro no debería ser realmente necesario en lo que respecta a la recuperación de datos.

Realmente recomiendo leer Importancia de la gestión adecuada del tamaño del registro de transacciones por Paul S. Randal.

La quintaesencia es que solo hay dos formas realmente buenas de manejar el registro de transacciones :

1. Vaya con copias de seguridad regulares del archivo LOG y el archivo LOG reutilizará su espacio después de cada copia de seguridad LOG y no crecerá indefinidamente, o

2. Utilice el modelo de recuperación SIMPLE y no tendrá que preocuparse por el tamaño de su archivo LOG, ya que realiza copias de seguridad completas periódicas.

Lo que concierne al truncamiento y el rendimiento del archivo LOG es que siempre obtendrá un impacto en el rendimiento cuando se aumente el archivo LOG (una cita de la publicación de blog vinculada anteriormente):

Si encoge el registro, entonces volverá a crecer, posiblemente causando fragmentación de VLF y definitivamente causando que su carga de trabajo se detenga mientras el registro crece, ya que el registro no puede usar la inicialización [...]

Actualización: No confunda el truncamiento del archivo LOG con la reducción del archivo DATA. La reducción del archivo DATA es realmente mala. Consulte Por qué no debe reducir sus archivos de datos para obtener más detalles.

OK primero sí, el registro es necesario incluso con las copias de seguridad completas diarias si desea recuperar en caso de un problema. Respaldamos nuestro registro de transacciones cada 15 minutos. El problema es que no está haciendo una copia de seguridad de su registro de transacciones y es por eso que el registro crece tan escandalosamente. Casi nunca debería necesitar reducir un registro de transacciones si está haciendo copias de seguridad correctas del registro de transacciones.

Deberá realizar una copia de seguridad de la base de datos antes de truncar el registro. Sugiero hacerlo en horas libres para que no se inserten datos nuevos entre la copia de seguridad y el truncamiento. Luego configure las copias de seguridad adecuadas del registro de transacciones para que nunca vuelva a tener este problema.

En cuanto a afectar el rendimiento, bien sin conocer los detalles del hardware y el uso de su sistema, eso sería difícil de decir.

¿Qué tan rápido crece el registro de transacciones? Si es bastante rápido, afectará el rendimiento reduciéndolo a casi nada, ya que tiene que perder tiempo volviéndolo a crecer. Esto no significa que no deba reducirlo de vez en cuando, sino que debe pensar en el problema del tamaño en lugar de reducirlo al mínimo. ¿Es enorme el rendimiento? Probablemente no, pero depende de la carga en el servidor (número de transacciones, etc.).

Una cosa que encuentro problemática es "Realizo 2 copias de seguridad completas diariamente, por lo que el registro no debería ser realmente necesario en lo que respecta a la recuperación de datos". El registro es extremadamente importante para los puntos entre sus copias de seguridad completas. Incluso dos veces al día no elimina la necesidad de un archivo de registro para la recuperación ante desastres, a menos que se trate de una base de datos de solo lectura (sin embargo, no vería el gran aumento en el archivo de registro).