No soy un experto en SQL, y me acuerdo del hecho 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 definitivamente lo es. ¿Cómo borro el registro de transacciones?

Hacer un archivo de registro más pequeño realmente debería reservarse para escenarios en los que se encontró un crecimiento inesperado que no espera que vuelva a suceder. Si el archivo de registro volverá a crecer al mismo tamaño, no se logra mucho reduciéndolo temporalmente. Ahora, dependiendo de los objetivos de recuperación de su base de datos, estas son las acciones que debe tomar.

Primero, haga una copia de seguridad completa

Nunca realice cambios en su base de datos sin asegurarse de que pueda restaurarla si algo sale mal.

Si te importa la recuperación en un momento determinado

(Y por recuperación en un momento dado, me refiero a que le importa poder restaurar a otra cosa que no sea una copia de seguridad completa o diferencial).

Presumiblemente su base de datos está en FULLmodo de recuperación. De lo contrario, asegúrese de que sea:

ALTER DATABASE testdb SET RECOVERY FULL;

Incluso si está realizando copias de seguridad completas regulares, el archivo de registro crecerá y crecerá hasta que realice una copia de seguridad de registro ; esto es para su protección, no para consumir innecesariamente el espacio de su disco. Debe realizar estas copias de seguridad de registros con bastante frecuencia, de acuerdo con sus objetivos de recuperación. Por ejemplo, si tiene una regla comercial que establece que puede permitirse perder no más de 15 minutos de datos en caso de desastre, debe tener un trabajo que haga una copia de seguridad del registro cada 15 minutos. Aquí hay un script que generará nombres de archivo con marca de tiempo en función de 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 horribles).

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. Hacer una copia de seguridad de estos en la misma máquina (o en una máquina diferente que usa 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 respaldos. Dependiendo de la infraestructura de su red, puede tener más sentido hacer una copia de seguridad local y luego transferirlos a una ubicación diferente detrás de escena; en cualquier caso, desea sacarlos de la máquina de base de datos primaria lo más rápido posible.

Ahora, una vez que tiene 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 SHRINKFILEuna y otra vez hasta que el archivo de registro sea de 1 MB, incluso si realiza una copia de seguridad del registro con frecuencia, aún necesita acomodar la suma de las transacciones simultáneas que puedan 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 tienen que esperar mientras esto sucede. Desea hacer esta rutina de crecimiento-reducción-crecimiento-reducción lo menos posible, y ciertamente no desea que sus usuarios paguen por ello.

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

Por lo tanto, debe encontrar 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 reduciendo con frecuencia el archivo de registro y ha vuelto a crecer, una buena marca de agua es probablemente un 10-50% más alta que la más grande que ha sido. . Supongamos que llega a 200 MB y desea que cualquier evento de crecimiento automático posterior sea de 50 MB, entonces 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 ejecutar esto primero:

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

Si no te importa la recuperación en un momento determinado

Si se trata de una base de datos de prueba y no le importa la recuperación en un momento determinado, debe asegurarse de que su base de datos esté en SIMPLEmodo de recuperación.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Poner la base de datos en SIMPLEmodo de recuperación se asegurará de que SQL Server reutilice partes del archivo de registro (esencialmente eliminando las transacciones inactivas) en lugar de crecer para mantener un registro de todas las transacciones (como lo FULLhace la recuperación hasta que haga una copia de seguridad del registro). CHECKPOINTLos eventos ayudarán a controlar el registro y a asegurarse de que no es necesario que crezca a menos que genere mucha actividad t-log entre CHECKPOINTs.

A continuación, debe asegurarse absolutamente de que este crecimiento del registro se debió realmente a un evento anormal (por ejemplo, una limpieza anual de primavera o la reconstrucción de sus índices más grandes), y no debido al uso diario normal. Si reduce el archivo de registro a un tamaño ridículamente pequeño y SQL Server solo tiene que volver a crecer 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 y una tasa de crecimiento adecuados. Según el ejemplo en el caso de recuperación en un punto en el tiempo, puede usar el mismo código y lógica para determinar qué tamaño de archivo es apropiado y establecer parámetros de crecimiento automático razonables.

Algunas cosas que no quieres hacer

• Haga una copia de seguridad del registro con la TRUNCATE_ONLYopción y luegoSHRINKFILE . Por un lado, esta TRUNCATE_ONLYopción ha quedado en desuso y ya no está disponible en las versiones actuales de SQL Server. En segundo lugar, si está en el FULLmodelo de recuperación, 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 adjuntar . No puedo enfatizar cuán peligroso puede ser esto. Es posible que su base de datos no vuelva a aparecer, puede aparecer como sospechosa, es posible que deba volver a una copia de seguridad (si tiene una), etc., etc.

• Use la opción "reducir base de datos" . DBCC SHRINKDATABASEy la opción del plan de mantenimiento para hacer lo mismo son malas ideas, especialmente si realmente solo necesita resolver un problema de registro. Apunte el archivo que desea ajustar y ajústelo de forma independiente, utilizando DBCC SHRINKFILEo ALTER DATABASE ... MODIFY FILE(ejemplos anteriores).

• 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 es, debe marcarla como tal usando ALTER DATABASE), esto solo conducirá a muchos eventos de crecimiento innecesarios, ya que el registro tiene que acomodar las transacciones actuales independientemente del modelo de recuperación. ¿Cuál es el punto de liberar ese espacio temporalmente, solo 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 es como tratar de reparar un pulmón perforado con una curita. Debe tratar el archivo de registro problemático directamente en lugar de simplemente agregar otro problema potencial. Además de redirigir alguna actividad de 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 uno de los archivos puede usarse 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 su archivo de registro a una pequeña cantidad y dejar que crezca automáticamente a un ritmo pequeño por sí solo, configúrelo en un tamaño razonablemente grande (uno que acomode la suma de su mayor conjunto de transacciones concurrentes) y establezca un crecimiento automático razonable configurada como una alternativa, para que no tenga que crecer varias veces para satisfacer transacciones únicas y para que sea relativamente raro que tenga que crecer durante las operaciones comerciales normales.

Los peores ajustes posibles aquí son 1 MB de crecimiento o 10% de crecimiento. Curiosamente, estos son los valores predeterminados para SQL Server (de los que me he quejado y he pedido cambios en vano ): 1 MB para archivos de datos y 10% para archivos de registro. El primero es demasiado pequeño hoy en día, y el segundo lleva a eventos cada vez más largos (digamos, 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 de 60.5 MB , etc. etc. - y en E / S lenta, créame, realmente notará esta curva).

Otras lecturas

Por favor no pares aquí; Si bien muchos de los consejos que ve sobre la reducción de los archivos de registro son intrínsecamente malos e incluso potencialmente desastrosos, hay algunas personas que se preocupan más por la integridad de los datos que por liberar espacio en disco.

Una publicación de blog que escribí en 2009, cuando vi algunas publicaciones de "aquí se explica cómo reducir el archivo de registro" .

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

Una publicación de blog de Paul Randal explicando por qué el mantenimiento de t-log es importante y por qué no debe reducir sus archivos de datos tampoco .

Mike Walsh también tiene una excelente respuesta que cubre algunos de estos aspectos, incluidas las razones por las cuales es posible que no pueda reducir su archivo de registro de inmediato .

-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1]) 


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.

DESCARGO DE RESPONSABILIDAD: Lea atentamente 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 situaciones en las que NO es una solución adecuada u óptima, por favor comente abajo

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

• Seleccione Tareas → Reducir → Base de datos

• Luego haga clic OK!

Por lo general, abro el directorio del Explorador de Windows que contiene los archivos de la base de datos, para poder ver el efecto de inmediato.

De hecho, me sorprendió bastante 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 de recuperación completa, esto podría no funcionar, por lo que primero debe hacer una copia de seguridad del registro o cambiar a Recuperación simple y luego reducir el archivo. [gracias @onupdatecascade por esto]

-

PD: Aprecio lo que algunos han comentado sobre los peligros de esto, pero en mi entorno no tuve ningún problema para hacerlo yo mismo, especialmente porque siempre hago primero una copia de seguridad completa. 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 estaba haciendo era señalarle a la gente una función provista por Microsoft!

A continuación se muestra un script para reducir el registro de transacciones, pero definitivamente recomendaría hacer una copia de seguridad del registro de transacciones antes de reducirlo.

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

El registro de transacciones también es imprescindible cuando se trata de la recuperación en el momento, así que no solo lo deseche, sino que asegúrese de hacer una copia de seguridad de antemano.

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

• Cómo ver 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 similar al siguiente cuando se ejecutan los comandos anteriores

"No se puede reducir el archivo de registro (nombre del 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 encuentre una manera de reducir las actividades de la base de datos.

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

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

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

Si no utiliza los registros de transacciones para las restauraciones (es decir, solo realiza copias de seguridad completas), puede configurar el Modo de recuperación en "Simple", y el registro de transacciones se reducirá muy pronto y nunca se volverá a llenar.

Si está utilizando SQL 7 o 2000, puede habilitar el "punto de verificación de inicio de sesión truncado" en la pestaña de opciones de la base de datos. Esto tiene el mismo efecto.

Obviamente, esto no se recomienda en entornos de producción, ya que no podrá restaurar a un punto en el tiempo.

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

La mayoría de las respuestas aquí hasta ahora suponen que en realidad no necesita el archivo de registro de transacciones, sin embargo, si su base de datos está utilizando el FULLmodelo de recuperación 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 (truncandolo, descartándolo, borrándolo, etc.) romperá su cadena de copias de seguridad y le impedirá restaurar en cualquier momento desde su última copia de seguridad completa, diferencial o de registro de transacciones, hasta la próxima completa o se hace una copia de seguridad diferencial.

Del artículo de Microsoft sobreBACKUP

Recomendamos que nunca use 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 la base de datos completa o diferencial, la base de datos no está protegida contra fallas de medios. Utilice el truncamiento de registro manual solo 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 sintaxis 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 correctamente para evitar su crecimiento no deseado. Esto significa ejecutar copias de seguridad del registro de transacciones con la suficiente frecuencia. Al no hacerlo, corre el riesgo de que el registro de transacciones se llene y comience a crecer.

Además de las respuestas a 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 "borrar":

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

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

Una de las mayores operaciones intensivas de rendimiento en SQL Server es un evento de crecimiento automático del archivo de registro de transacciones en línea. Al no hacer copias de seguridad del registro de transacciones con la frecuencia suficiente, el registro de transacciones en línea se llenará y tendrá que crecer. El tamaño de crecimiento predeterminado es del 10%. Cuanto más ocupada esté la base de datos, más rápido crecerá el registro de transacciones en línea si no se crean las copias de seguridad del registro de transacciones. La creación de una copia de seguridad del 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 reducción regular de registros es una buena práctica de mantenimiento

FALSO. El crecimiento del registro es muy costoso porque la nueva porción debe ser puesta a cero. Toda la actividad de escritura se detiene en esa base de datos hasta que finaliza la puesta a cero, y si la escritura de su disco es lenta o el tamaño de crecimiento automático es grande, esa pausa puede ser enorme y los usuarios lo notarán. Esa es una razón por la que desea evitar el crecimiento. Si reduce el registro, volverá a crecer y solo está desperdiciando la operación del disco en un juego innecesario de reducir y volver a crecer

Primero verifique el modelo de recuperación de la base de datos. Por defecto, SQL Server Express Edition crea una base de datos para el modelo de recuperación simple (si no me equivoco).

Copia de seguridad del nombre de la base de datos con Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

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

Referirse a:

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

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

Usa el DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY)comando. Si se trata de una base de datos de prueba y está tratando de ahorrar / recuperar espacio, esto será de ayuda.

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

Y recuerde, ¡nunca, bajo ninguna circunstancia, elimine el archivo de registro (LDF)! Tendrá una corrupción instantánea de la base de datos. ¡Cocido! ¡Hecho! Datos perdidos! Si se deja "sin reparar", el archivo MDF principal podría dañarse permanentemente.

Nunca borre el registro de transacciones, ¡perderá datos! Parte de sus datos está en el Registro TX (independientemente del modelo de recuperación) ... si separa y "renombra" el archivo de registro TX que elimina efectivamente parte de su base de datos.

Para aquellos que han eliminado el Registro 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 de blog de Paul Randal sobre este mismo tema, malos consejos .

Además, en general, no use el archivo retráctil en los archivos MDF, ya que puede fragmentar severamente sus datos. Consulte su sección de Consejos incorrectos para obtener más información ("Por qué no debe reducir sus archivos de datos")

Visite el sitio web de Paul: él cubre estas mismas preguntas. El mes pasado caminó sobre muchos de estos temas en su serie Myth A Day .

Para truncar el archivo de registro:

• Copia de seguridad de la base de datos
• 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 nuevamente 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:

• Copia de seguridad del registro [DBName] con No_Log

• Reducir la base de datos por:

  Usando Enterprise Manager: - Haga clic 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 encontrar el nombre lógico del archivo de registro ejecutando sp_helpdb o buscando en las propiedades de la base de datos en Enterprise Manager.

Según mi experiencia en la mayoría de los servidores SQL, no existe 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 del registro de transacciones rara vez son reales. 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 también las bases de datos del sistema "modelo" y "tempdb".

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

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

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

Elimine o mueva el archivo de registro renombrado.

Sucedió conmigo donde el archivo de registro de la base de datos era de 28 GB.

¿Qué puedes hacer para reducir esto? En realidad, los archivos de registro son aquellos datos de archivo que el servidor SQL guarda cuando se realiza una transacción. Para que una transacción procese el servidor SQL asigna páginas para el mismo. Pero después de la finalización de la transacción, estos no se lanzan repentinamente con la esperanza de que pueda haber una transacción como la misma. Esto sostiene el espacio.

Paso 1: Primero ejecute este comando en el punto de control explorado de la consulta de la base de datos

Paso 2: haga clic derecho en la base de datos Tarea> Copia de seguridad Seleccione el tipo de copia de seguridad como Registro de transacciones Agregue una dirección de destino y un nombre de archivo para mantener los datos de la copia de seguridad (.bak)

Repita este paso nuevamente y en este momento proporcione otro nombre de archivo

Paso 3: Ahora ve a la base de datos Haz clic derecho en la base de datos

Tareas> Reducir> Archivos Elija el tipo de archivo como acción Reducir registro como liberar espacio no utilizado

Paso 4:

Verifique su archivo de registro normalmente en SQL 2014, esto se puede encontrar en

C: \ Archivos de programa \ Microsoft SQL Server \ MSSQL12.MSSQL2014EXPRESS \ MSSQL \ DATA

En mi caso, se redujo de 28 GB a 1 MB

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 derecho en Propiedades → archivo → agregue otro archivo de registro con un nombre diferente y configure la ruta de la misma manera 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. DB de respaldo
2. Separar DB
3. Renombrar archivo de registro
4. Adjuntar DB (mientras se adjunta eliminar .ldf renombrado (archivo de registro). Seleccione y elimine presionando el botón Eliminar)
5. Nuevo archivo de registro será recreado
6. Eliminar el archivo de registro renombrado.

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

Algunas de las otras respuestas no funcionaron para mí: no fue posible crear el punto de control mientras la base de datos estaba en línea, porque el registro de transacciones estaba lleno (qué irónico). Sin embargo, después de configurar la base de datos en modo de emergencia, pude reducir el archivo de registro:

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

Ejemplo:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Respuesta ligeramente actualizada, para MSSQL 2017, y utilizando el estudio de administración del servidor SQL. Fui principalmente de estas instrucciones https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

Tenía una copia de seguridad de db reciente, así que hice una copia de seguridad del registro de transacciones. Luego lo respalde de nuevo por si acaso. Finalmente, reduje el archivo de registro y pasé de 20G a 7MB, mucho más en línea con el tamaño de mis datos. No creo que se hayan realizado copias de seguridad de los registros de transacciones desde que se instaló hace 2 años ... así que poner esa tarea en el calendario de limpieza.

Reducción del registro de transacciones de la base de datos al tamaño mínimo :

1. Copia de seguridad: registro de transacciones
2. Reducir archivos: registro de transacciones
3. Copia de seguridad: registro de transacciones
4. Reducir archivos: registro de transacciones

Hice pruebas en varios DB: esta secuencia funciona .

Por lo general, se reduce a 2 MB .

O por un script:

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --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