¿Cómo reduzco el tamaño de un archivo de registro de SQL Server?

No puedo entender cómo reducir el tamaño del archivo ldf de bases de datos.

El DBA dice que debería usar backup log dbname with truncate_only

Y aunque parece que se ejecutó correctamente en SQL Query Analyzer, el archivo ldf aún tiene más de 2 Gb.

** Aclaración basada en algunos comentarios y algunas respuestas a continuación. *** La base de datos específica en cuestión es una base de datos que está en mi computadora portátil y la uso solo para procesos de desarrollo. El archivo de registro estaba creciendo hasta un punto en el que parecía causar un disco lleno. No hay riesgo de producción involucrado. Entiendo que el método en la pregunta que hice y la respuesta que acepté son riesgosas en un entorno de producción. *

sql-server log-files shrink

— Ron Tuffin
fuente

seguramente esta es una pregunta duplicada?

— JamesRyan

Miré y pude encontrar solo uno que estaba haciendo una pregunta sobre cuándo falla el SHRINKFILE. En ese momento no tenía sentido, así que publiqué esta pregunta. Pensé en eliminar la pregunta, pero luego pensé que habría otras personas en el mismo barco. Si puede encontrar una pregunta duplicada (que realmente hace la misma pregunta, no una similar), estaré encantado de eliminarla.

— Ron Tuffin

Hay alrededor de 8 respuestas en la primera página de una búsqueda que lo incluyen, pero supongo que debe saber lo que está buscando. Lo veo tan regularmente como parte de una respuesta, me sorprendió que no se haya preguntado de manera tan directa.

— JamesRyan

La respuesta depende mucho de la opción de recuperación de la base de datos: ¿simple o completa?

— Richard

Gracias por aclarar, Ron. Dado que es una base de datos de desarrollo, querrá cambiar el modelo de recuperación a SIMPLE además de reducir el archivo de registro, de lo contrario su problema se repetirá.

— BradC

Respuestas:

¡Oh, el horror! ¡Por favor, deja de decirle a la gente que deberían reducir sus archivos de registro!

Si te has metido en esta situación, entonces uno de los siguientes casos es extremadamente probable:

Su base de datos está en modo de recuperación completa, y realmente debería estar en modo simple
Su base de datos está en modo de recuperación completa, y debe realizar copias de seguridad de registros regulares
Su base de datos está en modo de recuperación completa y sus copias de seguridad de registro fallan por algún motivo
Está ejecutando transacciones enormemente grandes que están volcando el archivo de registro a tamaños masivos

La respuesta para cada uno de estos es la siguiente:

If (1), luego cambie la base de datos a modo simple
If (2), luego programe copias de seguridad de registro regulares
If (3), luego corrija sus copias de seguridad de registro programadas
If (4), simplemente no haga eso :) En su lugar, haga trabajar en lotes más pequeños.

Tenga en cuenta que NINGUNO de estos requiere el uso del "nombre de base de datos de registro de copia de seguridad (en desuso) con truncate_only"

En cambio, una vez que borre el archivo de registro utilizando una de las técnicas anteriores, reduzca el registro (ahora vacío) con:

DBCC SHRINKFILE ('log logical name', 2000)

Siempre especifique un tamaño final razonable, de lo contrario se reducirá a casi 0, y la próxima vez que lo necesite, tendrá que tomarse el tiempo para crecer.

— BradC
fuente

es una lástima que la respuesta aceptada fue tan rápida. Esta es una de las preguntas que uso para eliminar a los administradores de SQL durante las entrevistas. Si regresan con copia de seguridad con truncate_only, eso cuenta como 2 golpes desde el principio.

— Jim B

Estoy de acuerdo en que es lo último que debe hacer, reducir el archivo. El mantenimiento correcto evita la necesidad de esto. Pero una vez que es grande y lo quieres más pequeño, debes reducirlo. Sin embargo, cuando se reduce, es mejor reducir el archivo lo más pequeño posible, luego hacer crecer el archivo al tamaño correcto en incrementos de 8GB. Esto optimizará la cantidad de VLF en el archivo. Ver - sqlskills.com/BLOGS/KIMBERLY/post/… .

— Brian Knight

Enlace interesante, parece que solo se aplica si su registro trans es superior a 8 Gb. Creo que el punto de BradC (o al menos el mío) es que sí, hay emergencias que lo obligarán a reducir su archivo de registro, pero debe reconocer que si ejecuta el notorio respaldo / trunc w, seguido del archivo de reducción, acaba de limpiar su cadena de respaldo (espero que no haya sido nada importante), y aparte de los problemas de espacio en disco, es muy probable que tenga algunos problemas serios con el servidor sql probablemente desde una perspectiva de diseño de base de datos o arquitectónica. Sin arreglar el problema subyacente, te has ganado algo de tiempo en el mejor de los casos.

— Jim B

después de hacer la "copia de seguridad con truncate_only", debe emitir el siguiente comando para reducir

dbcc SHRINKFILE (logfilename,shrink_tosize)

p.ej

dbcc SHRINKFILE (mydatabase_Log,512)

— Mani
fuente

La secuencia de comandos que escribió anteriormente marcará el contenido del registro para su reutilización. Sigue ese guión con:

USE <database>;

DBCC SHRINKFILE (<log logical file name>)

Eso lo reducirá para ti.

— Brian Knight
fuente