¿Cómo borra el registro de transacciones de SQL Server?

No soy un experto en SQL, y me recuerda el hecho de que cada vez que necesito hacer algo más allá de lo básico. Tengo una base de datos de prueba que no es de gran tamaño, pero el registro de transacciones sí lo es. ¿Cómo borro el registro de transacciones?

Hacer que un archivo de registro sea más pequeño debería reservarse para los escenarios en los que se produjo un crecimiento inesperado que no espera que ocurra nuevamente. Si el archivo de registro volverá a crecer al mismo tamaño, no se logra mucho al reducirlo temporalmente. Ahora, dependiendo de los objectives de recuperación de su base de datos, estas son las acciones que debe tomar.

Primero, tome una copia de seguridad completa

Nunca realice ningún cambio en su base de datos sin asegurarse de que pueda restaurarla en caso de que algo salga mal.

Si te importa la recuperación puntual

(Y por recuperación puntual, me refiero a que le importa restaurar cualquier cosa que no sea una copia de seguridad completa o diferencial).

Es de suponer que su base de datos está en modo de recuperación completa. De lo contrario, asegúrate de que sea:

 ALTER DATABASE testdb SET RECOVERY FULL; 

Incluso si realiza copias de seguridad completas regularmente, el archivo de registro crecerá y crecerá hasta que realice una copia de seguridad de registro , esto es para su protección, no para comer innecesariamente en el espacio de su disco. Debería realizar estas copias de seguridad de registros con bastante frecuencia, de acuerdo con sus objectives de recuperación. Por ejemplo, si tiene una regla comercial que establece que puede permitirse no perder más de 15 minutos de datos en caso de un desastre, debe tener un trabajo que haga una copia de seguridad del registro cada 15 minutos. Aquí hay una secuencia de comandos que generará nombres de archivo de fecha y hora basados ​​en la hora actual (pero también puede hacerlo con planes de mantenimiento, etc., simplemente no elija ninguna de las opciones de reducción en los planes de mantenimiento, son terribles).

 DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' + CONVERT(CHAR(8), GETDATE(), 112) + '_' + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','') + '.trn'; BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION; 

Tenga en cuenta que \\backup_share\ debe estar en una máquina diferente que represente un dispositivo de almacenamiento subyacente diferente. Copia de seguridad de estos hasta la misma máquina (o en una máquina diferente que utiliza los mismos discos subyacentes, o una máquina virtual diferente que está en el mismo host físico) realmente no lo ayuda, ya que si la máquina explota, ha perdido su base de datos y sus copias de seguridad. Dependiendo de su infraestructura de red, puede que tenga más sentido hacer una copia de seguridad localmente y luego transferirlos a una ubicación diferente detrás de escena; en cualquier caso, quiere sacarlos de la máquina de base de datos primaria lo más rápido posible.

Ahora, una vez que tenga copias de seguridad de registro regulares en ejecución, debería ser razonable reducir el archivo de registro a algo más razonable que lo que sea que haya explotado hasta ahora. Esto no significa ejecutar SHRINKFILE una y otra vez hasta que el archivo de registro sea de 1 MB; incluso si hace una copia de seguridad del registro con frecuencia, aún necesita acomodar la sum de cualquier transacción simultánea que pueda ocurrir. Los eventos de crecimiento automático de archivos de registro son caros, ya que SQL Server tiene que poner a cero los archivos (a diferencia de los archivos de datos cuando la inicialización instantánea de archivos está habilitada) y las transacciones de los usuarios deben esperar mientras esto ocurre. Desea que esta rutina de crecimiento, encogimiento, encogimiento y encogimiento sea lo menos posible y, desde luego, no desea que los usuarios paguen por ella.

Tenga en cuenta que es posible que necesite hacer una copia de seguridad del registro dos veces antes de que sea posible una reducción (gracias Robert).

Por lo tanto, debe obtener un tamaño práctico para su archivo de registro. Nadie aquí puede decirle qué es eso sin saber mucho más sobre su sistema, pero si ha estado disminuyendo con frecuencia el archivo de registro y ha estado creciendo nuevamente, una buena marca de agua probablemente sea 10-50% más alta que la más grande que haya sido . Digamos que se trata de 200 MB, y desea que cualquier evento posterior de crecimiento automático sea de 50 MB, luego puede ajustar el tamaño del archivo de registro de esta manera:

 USE [master]; GO ALTER DATABASE Test1 MODIFY FILE (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB); GO 

Tenga en cuenta que si el archivo de registro es actualmente> 200 MB, es posible que deba ejecutarlo primero:

 USE yourdb; GO DBCC SHRINKFILE(yourdb_log, 200); GO 

Si no te importa la recuperación puntual

Si se trata de una base de datos de prueba, y no te importa la recuperación puntual, entonces debes asegurarte de que tu base de datos esté en modo de recuperación SIMPLE .

 ALTER DATABASE testdb SET RECOVERY SIMPLE; 

Al poner la base de datos en modo de recuperación SIMPLE , se asegurará de que SQL Server reutilice partes del archivo de registro (esencialmente eliminando transacciones inactivas) en lugar de crecer para mantener un registro de todas las transacciones (como la recuperación FULL hasta que haga una copia de seguridad del registro) . CHECKPOINT eventos CHECKPOINT le ayudarán a controlar el registro y a asegurarse de que no sea necesario que crezca a menos que genere una gran cantidad de actividad t-log entre CHECKPOINT s.

A continuación, debe asegurarse por completo de que este crecimiento del registro se debió realmente a un evento anormal (por ejemplo, una limpieza anual de spring o la reconstrucción de sus índices más grandes), y no debido al uso normal y cotidiano. Si reduce el tamaño del archivo de registro a un tamaño ridículamente pequeño, y SQL Server solo tiene que crecer de nuevo para acomodar su actividad normal, ¿qué ganó? ¿Pudiste hacer uso de ese espacio en disco que liberaste solo temporalmente? Si necesita una solución inmediata, puede ejecutar lo siguiente:

 USE yourdb; GO CHECKPOINT; GO CHECKPOINT; -- run twice to ensure file wrap-around GO DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs GO 

De lo contrario, establezca un tamaño apropiado y una tasa de crecimiento. Según el ejemplo del caso de recuperación de un punto en el tiempo, puede usar el mismo código y lógica para determinar qué tamaño de archivo es el apropiado y establecer parámetros razonables de auto crecimiento.

Algunas cosas que no quieres hacer

  • Realice una TRUNCATE_ONLY seguridad del registro con la opción TRUNCATE_ONLY y luego SHRINKFILE . Por un lado, esta opción TRUNCATE_ONLY ha quedado en desuso y ya no está disponible en las versiones actuales de SQL Server. En segundo lugar, si está en el modelo de recuperación FULL , esto destruirá su cadena de registro y requerirá una nueva copia de seguridad completa.

  • Separe la base de datos, elimine el archivo de registro y vuelva a conectarlo . No puedo enfatizar cuán peligroso puede ser esto. Su base de datos puede no volver a aparecer, puede aparecer como sospechosa, es posible que tenga que volver a una copia de seguridad (si tiene una), etc., etc.

  • Use la opción “reducir la base de datos” . DBCC SHRINKDATABASE y la opción del plan de mantenimiento para hacer lo mismo son malas ideas, especialmente si realmente solo necesita resolver un problema de registro de problemas. Oriente el archivo que desea ajustar y ajústelo de manera independiente, utilizando DBCC SHRINKFILE o ALTER DATABASE ... MODIFY FILE (ejemplos arriba).

  • Reducir el archivo de registro a 1 MB . Esto parece tentador porque, oye, SQL Server me permitirá hacerlo en ciertos escenarios, ¡y mirar todo el espacio que libera! A menos que su base de datos sea de solo lectura (y lo sea, debe marcarla como tal con ALTER DATABASE ), esto simplemente generará muchos eventos de crecimiento innecesarios, ya que el registro debe acomodar las transacciones actuales independientemente del modelo de recuperación. ¿Cuál es el objective de liberar ese espacio de forma temporal, para que SQL Server pueda recuperarlo lenta y dolorosamente?

  • Crea un segundo archivo de registro . Esto proporcionará un alivio temporal para la unidad que ha llenado su disco, pero esto es como tratar de reparar un pulmón pinchado con una curita. Debería lidiar directamente con el archivo de registro problemático en lugar de simplemente agregar otro problema potencial. Además de redirigir la actividad del registro de transacciones a una unidad diferente, un segundo archivo de registro realmente no hace nada por usted (a diferencia de un segundo archivo de datos), ya que solo se puede usar uno de los archivos a la vez. Paul Randal también explica por qué varios archivos de registro pueden morderte más tarde .

Ser proactivo

En lugar de reducir el archivo de registro a una pequeña cantidad y dejarlo crecer automáticamente solo a un ritmo pequeño, configúrelo en un tamaño razonablemente grande (uno que acomode la sum de su mayor conjunto de transacciones simultáneas) y establezca un crecimiento razonable configuración como una alternativa, para que no tenga que crecer varias veces para satisfacer transacciones individuales y para que sea relativamente raro que alguna vez tenga que crecer durante las operaciones comerciales normales.

La peor configuración posible aquí es 1 MB de crecimiento o 10% de crecimiento. Bastante gracioso, estos son los valores predeterminados para SQL Server (que me he quejado y solicitó cambios en vano ): 1 MB para archivos de datos y 10% para archivos de registro. El primero es demasiado pequeño en este día y edad, y el último conduce a eventos cada vez más largos (por ejemplo, su archivo de registro es de 500 MB, el primer crecimiento es de 50 MB, el siguiente crecimiento es de 55 MB, el siguiente crecimiento es 60.5 MB , etc., etc. – y en E / S lenta, créanme, realmente notarán esta curva).

Otras lecturas

Por favor no te detengas aquí; Si bien gran parte de los consejos que usted ve por ahí sobre la reducción de los archivos de registro es intrínsecamente malo e incluso potencialmente desastroso, hay algunas personas que se preocupan más por la integridad de los datos que por liberar espacio en el disco.

Una publicación de blog que escribí hace cuatro años, cuando vi aparecer algunas publicaciones sobre “cómo reducir el tamaño del archivo de registro” .

Una publicación de blog que Brent Ozar escribió hace cuatro años, apuntando a múltiples recursos, en respuesta a un artículo de la revista SQL Server que no debería haber sido publicado .

Una publicación de blog de Paul Randal que explica por qué el mantenimiento de t-log es importante y por qué no debes reducir tus archivos de datos tampoco .

Mike Walsh tiene una gran respuesta que también cubre algunos de estos aspectos, incluidos los motivos por los que es posible que no pueda reducir su archivo de registro de inmediato .

DESCARGO DE RESPONSABILIDAD: Lea detenidamente los comentarios a continuación, y supongo que ya ha leído la respuesta aceptada. Como dije hace casi 5 años:

si alguien tiene algún comentario que agregar para las situaciones cuando esta NO es una solución adecuada u óptima, por favor comente a continuación


  • Haga clic derecho en el nombre de la base de datos.

  • Seleccione Tareas → Reducir → Base de datos

  • ¡Entonces haz clic en OK !

Normalmente abro el directorio de Windows Explorer que contiene los archivos de la base de datos, por lo que puedo ver el efecto de inmediato.

¡Estaba bastante sorprendido de que esto funcionara! Normalmente he usado DBCC antes, pero lo intenté y no redujo nada, así que probé la GUI (2005) y funcionó muy bien, liberando 17 GB en 10 segundos

En el modo Recuperación total, es posible que esto no funcione, por lo que primero debe hacer una copia de seguridad del registro o cambiar a Recuperación simple, luego reducir el archivo. [gracias @onupdatecascade por esto]

PD: Aprecio lo que algunos han comentado con respecto a los peligros de esto, pero en mi entorno no tuve ningún problema al hacerlo, especialmente porque siempre hago una copia de seguridad completa primero. Por lo tanto, tenga en cuenta cuál es su entorno y cómo esto afecta su estrategia de respaldo y seguridad laboral antes de continuar. ¡Todo lo que hacía era señalar a las personas a una función proporcionada por Microsoft!

 USE AdventureWorks2008R2; GO -- Truncate the log by changing the database recovery model to SIMPLE. ALTER DATABASE AdventureWorks2008R2 SET RECOVERY SIMPLE; GO -- Shrink the truncated log file to 1 MB. DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1); GO -- Reset the database recovery model. ALTER DATABASE AdventureWorks2008R2 SET RECOVERY FULL; GO 

De: DBCC SHRINKFILE (Transact-SQL)

Es posible que desee hacer una copia de seguridad primero.

A continuación se muestra una secuencia de comandos para reducir el registro de transacciones, pero definitivamente recomiendo hacer una copia de seguridad del registro de transacciones antes de reducirlo.

Si solo reduce el tamaño del archivo, perderá una tonelada de datos que pueden salvarle la vida en caso de desastre. El registro de transacciones contiene una gran cantidad de datos útiles que se pueden leer utilizando un lector de registro de transacciones de terceros (se puede leer manualmente pero con un esfuerzo extremo).

El registro de transacciones también es imprescindible en lo que respecta a la recuperación de un punto en el tiempo, así que no lo descarte, pero asegúrese de hacer una copia de seguridad de antemano.

Aquí hay varias publicaciones donde las personas utilizaron los datos almacenados en el registro de transacciones para lograr la recuperación:

  • Cómo ver los registros de transacciones en SQL Server 2008

  • Lea el archivo de registro (* .LDF) en SQL Server 2008

 USE DATABASE_NAME; GO ALTER DATABASE DATABASE_NAME SET RECOVERY SIMPLE; GO --First parameter is log file name and second is size in MB DBCC SHRINKFILE (DATABASE_NAME_Log, 1); ALTER DATABASE DATABASE_NAME SET RECOVERY FULL; GO 

Puede obtener un error que se parece a esto cuando los comandos de ejecución anteriores

“No se puede reducir el archivo de registro (nombre de archivo de registro) porque el archivo de registro lógico ubicado al final del archivo está en uso”

Esto significa que TLOG está en uso. En este caso, intente ejecutar esto varias veces seguidas o busque una manera de reducir las actividades de la base de datos.

Si no utiliza los registros de transacciones para las restauraciones (es decir, solo hace copias de seguridad completas), puede establecer el Modo de recuperación en “Simple” y el registro de transacciones se reducirá muy brevemente y nunca se llenará nuevamente.

Si está utilizando SQL 7 o 2000, puede habilitar “truncar el registro en el punto de control” en la pestaña de opciones de la base de datos. Esto tiene el mismo efecto.

Esto no es recomendable en entornos de producción, obviamente, ya que no podrá restaurar a un punto en el tiempo.

Aquí hay una manera simple y muy poco elegante y potencialmente peligrosa .

  1. Backup DB
  2. Separar DB
  3. Renombrar archivo de registro
  4. Adjuntar DB
  5. Nuevo archivo de registro será recreado
  6. Eliminar el archivo de registro con nombre.

Supongo que no estás haciendo copias de seguridad de registros. (Que truncar el registro). Mi consejo es cambiar el modelo de recuperación de completo a simple . Esto evitará la hinchazón del registro.

La mayoría de las respuestas aquí hasta ahora están asumiendo que realmente no necesita el archivo de registro de transacciones; sin embargo, si su base de datos está utilizando el modelo de recuperación FULL y desea mantener sus copias de seguridad en caso de que necesite restaurar la base de datos, no trunque ni elimine el archivo de registro de la manera que sugieren muchas de estas respuestas.

Eliminar el archivo de registro (al truncarlo, descartarlo, borrarlo, etc.) romperá su cadena de respaldo y le impedirá restaurar en cualquier momento desde su última copia de seguridad completa, diferencial o de registro de transacciones, hasta la próxima versión completa o se realiza una copia de seguridad diferencial.

Del artículo de Microsoft sobre BACKUP

Recomendamos que nunca utilice NO_LOG o TRUNCATE_ONLY para truncar manualmente el registro de transacciones, ya que esto rompe la cadena de registro. Hasta la próxima copia de seguridad de base de datos completa o diferencial, la base de datos no está protegida contra fallas de medios. Utilice el truncamiento de registro manual en circunstancias muy especiales y cree copias de seguridad de los datos de inmediato.

Para evitar eso, haga una copia de seguridad de su archivo de registro en el disco antes de reducirlo. La syntax se vería así:

 BACKUP LOG MyDatabaseName TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn' DBCC SHRINKFILE (N'MyDatabaseName_Log', 200) 

El registro de transacciones de SQL Server debe mantenerse adecuadamente para evitar su crecimiento no deseado. Esto significa ejecutar copias de seguridad del registro de transacciones con la frecuencia suficiente. Al no hacerlo, corre el riesgo de que el registro de transacciones se llene y empiece a crecer.

Además de las respuestas para esta pregunta, recomiendo leer y comprender los mitos comunes del registro de transacciones. Estas lecturas pueden ayudar a comprender el registro de transacciones y decidir qué técnicas utilizar para “borrarlo”:

De los 10 mitos de registro de transacciones de SQL Server más importantes :

Mito: mi servidor SQL está demasiado ocupado. No quiero hacer copias de seguridad del registro de transacciones de SQL Server

Una de las operaciones de mayor rendimiento intensivo en SQL Server es un evento de crecimiento automático del archivo de registro de transacciones en línea. Al no hacer suficientes copias de seguridad de los registros de transacciones, el registro de transacciones en línea se llenará y tendrá que crecer. El tamaño de crecimiento predeterminado es 10%. Cuanto más ocupada es la base de datos, más rápido crecerá el registro de transacciones en línea si no se crean copias de seguridad de registros de transacciones Crear una copia de seguridad de registro de transacciones de SQL Server no bloquea el registro de transacciones en línea, pero sí un evento de crecimiento automático. Puede bloquear toda la actividad en el registro de transacciones en línea

De los mitos del registro de transacciones :

Mito: la contracción regular del tronco es una buena práctica de mantenimiento

FALSO. El crecimiento del registro es muy costoso porque el nuevo fragmento debe ponerse a cero. Toda la actividad de escritura se detiene en esa base de datos hasta que se completa el cero, y si la escritura del disco es lenta o el tamaño del crecimiento automático es grande, esa pausa puede ser enorme y los usuarios lo notarán. Esa es una de las razones por las que desea evitar el crecimiento. Si reduce el tamaño del tronco, volverá a crecer y estará desperdiciando la operación del disco en un juego innecesario de contracción y crecimiento.

Esta técnica que recomienda John no es recomendable ya que no hay garantía de que la base de datos se adjunte sin el archivo de registro. Cambia la base de datos de completa a simple, fuerza un punto de control y espera unos minutos. El SQL Server borrará el registro, que luego puede reducir utilizando DBCC SHRINKFILE.

Primero revise el modelo de recuperación de la base de datos. De forma predeterminada, SQL Server Express Edition crea una base de datos para el modelo de recuperación simple (si no me equivoco).

Registro de respaldo DatabaseName con Truncate_Only:

 DBCC ShrinkFile(yourLogical_LogFileName, 50) 

SP_helpfile le dará el nombre de archivo de registro lógico.

Referirse a:

Recuperarse de un registro de transacciones completo en una base de datos de SQL Server

Si su base de datos está en el Modelo de Recuperación Total y si no está tomando una copia de seguridad de TL, entonces cámbiela a SIMPLE.

Use el DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY) . Si esta es una base de datos de prueba y está tratando de ahorrar / recuperar espacio, esto ayudará.

Sin embargo, recuerde que los registros de TX tienen un tipo de tamaño de estado mínimo / estable al que crecerán. Dependiendo de su modelo de recuperación, es posible que no pueda reducir el tamaño del registro: si está COMPLETO y no está emitiendo copias de seguridad de registros de TX, el registro no se puede reducir: crecerá para siempre. Si no necesita copias de seguridad de registros de TX, cambie su modelo de recuperación a Simple .

¡Y recuerde, nunca bajo ninguna circunstancia borre el archivo de registro (LDF)! Tendrás prácticamente corrupción de base de datos instantánea. ¡Cocido! ¡Hecho! ¡Datos perdidos! Si se deja “sin reparar”, el archivo MDF principal podría dañarse de forma permanente.

Nunca borres el registro de transacciones, ¡perderás datos! Parte de sus datos se encuentra en el registro TX (independientemente del modelo de recuperación) … si separa y “cambia el nombre” del archivo de registro TX que borra efectivamente parte de su base de datos.

Para aquellos que han eliminado el registro de TX, es posible que desee ejecutar algunos comandos checkdb y corregir la corrupción antes de perder más datos.

Echa un vistazo a las publicaciones del blog de Paul Randal sobre este mismo tema, un mal consejo .

Además, en general, no utilice shrinkfile en los archivos MDF, ya que puede fragmentar gravemente sus datos. Eche un vistazo a su sección de Consejos malos para obtener más información (“Por qué no debe reducir sus archivos de datos”)

Echa un vistazo al sitio web de Paul: él cubre estas preguntas. El mes pasado revisó muchos de estos temas en su serie Myth A Day .

Para truncar el archivo de registro:

  • Haga una copia de seguridad
  • Separe la base de datos, ya sea utilizando Enterprise Manager o ejecutando: Sp_DetachDB [DBName]
  • Eliminar el archivo de registro de transacciones. (o cambie el nombre del archivo, por si acaso)
  • Vuelva a adjuntar la base de datos usando: Sp_AttachDB [DBName]
  • Cuando se adjunta la base de datos, se crea un nuevo archivo de registro de transacciones.

Para reducir el archivo de registro:

  • Registro de copia de seguridad [DBName] con No_Log
  • Reducir la base de datos por:

    Usando Enterprise Manager: – Haga clic con el botón derecho en la base de datos, Todas las tareas, Reducir base de datos, Archivos, Seleccionar archivo de registro, Aceptar.

    Usando T-SQL: – Dbcc Shrinkfile ([Log_Logical_Name])

Puede buscar el nombre lógico del archivo de registro ejecutando sp_helpdb o examinando las propiedades de la base de datos en Enterprise Manager.

Para mi experiencia en la mayoría de los Servidores SQL, no hay una copia de seguridad del registro de transacciones. Las copias de seguridad completas o las copias de seguridad diferenciales son una práctica común, pero las copias de seguridad de los registros de transacciones son muy raras. Por lo tanto, el archivo de registro de transacciones crece para siempre (hasta que el disco esté lleno). En este caso, el modelo de recuperación debe establecerse en ” simple “. No olvide modificar las bases de datos del sistema “modelo” y “tempdb” también.

Una copia de seguridad de la base de datos “tempdb” no tiene sentido, por lo que el modelo de recuperación de este db siempre debe ser “simple”.

  1. Haga una copia de seguridad del archivo MDB.
  2. Detener los servicios de SQL
  3. Cambiar el nombre del archivo de registro
  4. Comience el servicio

(El sistema creará un nuevo archivo de registro).

Elimine o mueva el archivo de registro renombrado.

Prueba esto:

 USE DatabaseName GO DBCC SHRINKFILE( TransactionLogName, 1) BACKUP LOG DatabaseName WITH TRUNCATE_ONLY DBCC SHRINKFILE( TransactionLogName, 1) GO 

Base de datos → haga clic con el botón secundario en Propiedades → archivo → agregue otro archivo de registro con un nombre diferente y establezca la ruta igual que el archivo de registro anterior con un nombre de archivo diferente.

La base de datos recoge automáticamente el archivo de registro recién creado.

  1. Backup DB
  2. Separar DB
  3. Renombrar archivo de registro
  4. Adjuntar DB (mientras se adjunta eliminar renombrado .ldf (archivo de registro). Seleccionar y eliminar presionando el botón Eliminar)
  5. Nuevo archivo de registro será recreado
  6. Eliminar el archivo de registro con nombre.

Esto funcionará, pero se sugiere hacer una copia de seguridad de su base de datos primero.

Ejemplo:

 DBCC SQLPERF(LOGSPACE) BACKUP LOG Comapny WITH TRUNCATE_ONLY DBCC SHRINKFILE (Company_log, 500) DBCC SQLPERF(LOGSPACE) 

It happened with me where the database log file was of 28 GBs.

What can you do to reduce this? Actually, log files are those file data which the SQL server keeps when an transaction has taken place. For a transaction to process SQL server allocates pages for the same. But after the completion of the transaction, these are not released suddenly hoping that there may be a transaction coming like the same one. This holds up the space.

Step 1: First Run this command in the database query explored checkpoint

Step 2: Right click on the database Task> Back up Select back up type as Transaction Log Add a destination address and file name to keep the backup data (.bak)

Repeat this step again and at this time give another file name

enter image description here

Step 3: Now go to the database Right-click on the database

Tasks> Shrinks> Files Choose File type as Log Shrink action as release unused space

enter image description here

Etapa 4:

Check your log file normally in SQL 2014 this can be found at

C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014EXPRESS\MSSQL\DATA

In my case, its reduced from 28 GB to 1 MB

DB Transaction Log Shrink to min size :

  1. Backup: Transaction log
  2. Shrink files: Transaction log
  3. Backup: Transaction log
  4. Shrink files: Transaction log

I made tests on several number of DBs: this sequence works .

It usually shrinks to 2MB .

OR by a script:

 DECLARE @DB_Name nvarchar(255); DECLARE @DB_LogFileName nvarchar(255); SET @DB_Name = ''; --Input Variable SET @DB_LogFileName = ''; --Input Variable EXEC ( 'USE ['+@DB_Name+']; '+ 'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' + 'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' + 'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' + 'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)' ) GO