Reducción de un registro de transacciones de SQL Server

Actualmente tengo que lidiar con un registro de transacciones de SQL Server que se ha salido de control. Descargo de responsabilidad: no soy un dba y esta no es mi área de especialización, así que tengan paciencia conmigo.

Actualmente tengo un archivo de registro de Transacción de 115GB para una base de datos de 500MB que (obviamente) ha sido mal administrada durante algún tiempo para que llegue a este estado.

¡La máxima prioridad es reclamar el espacio en el disco ocupado por este archivo antes de que se acabe! Me han dicho que aumentar el tamaño de la unidad no es una opción, ni siquiera temporalmente, y según el crecimiento anterior, debemos actuar muy pronto.

Según tengo entendido, el mejor enfoque es mantener la base de datos en modo de recuperación completa, pero realizar copias de seguridad periódicas del archivo de registro, monitorear esto durante un período de tiempo y ajustar el tamaño inicial y el incremento según corresponda. Todo bien.

Dado que realizamos copias de seguridad db completas regulares a medianoche, ¿sería seguro para mí poner temporalmente la base de datos en modo de recuperación simple (después de que se haya ejecutado una de estas copias de seguridad), reducir el archivo de registro para recuperar (prácticamente todo) el espacio y luego volver a ponerlo en Recuperación completa con la estrategia de copia de seguridad mencionada anteriormente?

Mi opinión es que si algo sucediera alrededor de este tiempo, simplemente podríamos restaurar la copia de seguridad completa sin usar los registros.

ACTUALIZAR

Algunos detalles adicionales en respuesta a algunas de las respuestas y comentarios:

• Queremos retener la capacidad de hacer una restauración en un punto en el tiempo para que la base de datos permanezca en modo de recuperación completa.

• La razón por la que el archivo t-log ha crecido tanto es que nunca se ha realizado una copia de seguridad . Verificado como log_reuse_wait_desc devuelve 'LOG_BACKUP'.

El registro de transacciones para esa base de datos contiene todas las transacciones desde la última copia de seguridad del registro de transacciones o la última vez que se cambió del modo de recuperación simple. Ejecute lo siguiente para obtener la respuesta definitiva sobre por qué SQL Server no puede truncar el registro y, posteriormente, por qué el registro está creciendo.

SELECT  d.Name
        ,d.log_reuse_wait_desc
FROM    sys.databases d
ORDER BY
        d.name

Si desea una recuperación puntual, deje la base de datos en el modelo de recuperación completa y realice copias de seguridad de registros frecuentes. Cada copia de seguridad del registro contendrá todas las transacciones desde la última copia de seguridad del registro. El proceso de copia de seguridad del registro también es responsable de borrar el registro y marcar el espacio para su reutilización, es decir, la próxima transacción realizada en la base de datos se escribirá al inicio del registro truncado de forma circular. Esta copia de seguridad y reutilización del registro es lo que impide que el archivo de registro crezca.

Si no está interesado en la recuperación en un momento determinado y desea simplificar la administración de la base de datos. Luego configure la base de datos con el modelo de recuperación simple y no realice copias de seguridad de t-log. SQL Server truncará automáticamente el registro de transacciones después de confirmar cada transacción. Esto significa que una vez que la transacción se ha confirmado en el registro, la próxima transacción sobrescribe el registro, etc.

De cualquier manera, una vez que haya tomado una de estas dos decisiones, puede reducir el archivo de registro a un tamaño más razonable. Tenga en cuenta que lo ideal es que sea lo suficientemente grande como para que no crezca, pero no tan grande como para que deba reducirlo nuevamente. También tenga en cuenta que no puede reducir la parte activa del registro.

Descargue e implemente https://ola.hallengren.com/ solución de administración de bases de datos para cubrir copias de seguridad, fragmentación de índices, estadísticas y CHECKDB.

También puede encontrar el informe de 'uso de disco' devuelto haciendo clic derecho en la base de datos en el Explorador de objetos> Informes> Informes estándar> 'uso de disco' útil para devolver el espacio libre en el t-log.

También te recomiendo que busques en Google por qué es tan importante mantener intacta la cadena de registro desde un punto de vista de DR, y cómo cambiar de completa a simple rompe la cadena dejándote expuesto a la pérdida de datos.

Dado que realizamos copias de seguridad db completas regulares a medianoche, ¿sería seguro para mí poner temporalmente la base de datos en modo de recuperación simple (después de que se haya ejecutado una de estas copias de seguridad), reducir el archivo de registro para recuperar (prácticamente todo) el espacio y luego volver a ponerlo en Recuperación completa con la estrategia de copia de seguridad mencionada anteriormente?

Sí, sería seguro siempre que interfiera con ninguna transacción cuando haga esto, como una carga nocturna. En general, si una base de datos debe estar en modo de recuperación completa, desea copias de seguridad regulares de T-Log. Esto reducirá el problema que enfrenta. Escribo "en general" porque, en algunos casos, he visto a personas establecer una base de datos completa sin saber por qué lo hicieron. Asumamos que este no es ese caso.

Sin embargo, es posible que desee considerar por qué el registro es de este tamaño en relación con el tamaño de la base de datos. Una base de datos de 500 MB con un registro de 116 GB parece muy desproporcionada para un evento único. Sugeriría monitorear lo que está sucediendo en la base de datos para ver cómo llegó a ese tamaño en primer lugar.