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


577

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?



3
Debería haber un comando en Managment Studio: "Haga clic para reducir el registro" y ya está.
frenchie

Respuestas:


750

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 .


55
La recuperación en un punto en el tiempo no es la única razón para usar el modelo de recuperación completa. La razón principal es evitar la pérdida de datos. Su potencial de pérdida de datos es la duración entre las copias de seguridad. Si solo realiza una copia de seguridad diaria, su potencial de pérdida de datos es de 24 horas. Si luego agrega copias de seguridad de registros cada media hora, su potencial de pérdida de datos se convierte en 30 minutos. Además, se requieren copias de seguridad de registros para realizar cualquier tipo de restauración gradual (como para recuperarse de la corrupción).
Robert L Davis

99
Aparte de eso, esta es la respuesta más completa y correcta dada en esta página.
Robert L Davis

11
También me gustaría agregar que la limpieza del registro se realiza haciendo una copia de seguridad del registro (en recuperación completa o de registro masivo) o un punto de control (en recuperación simple). Sin embargo, si se encuentra en una situación en la que debe reducir el archivo de registro, eso no es suficiente. Debe hacer que el VLF actualmente activo vuelva al inicio del archivo de registro. Puede forzar esto en SQL 2008 y versiones posteriores emitiendo dos copias de seguridad de registros o puntos de control consecutivos. El primero lo borra y el segundo lo regresa al inicio del archivo.
Robert L Davis

2
@Doug_Ivison porque en cualquier momento, los registros de registros podrían ser purgados. ¿Cuál sería el punto de permitirle hacer una copia de seguridad de un registro que está incompleto? En la recuperación simple, el registro solo se usa realmente para permitir la reversión de transacciones. Una vez que una transacción ha sido confirmada o revertida, el siguiente segundo podría desaparecer del registro.
Aaron Bertrand

3
@zinczinc Ok, gracias por tus comentarios. El problema que veo al poner la respuesta primero y la explicación posterior es que nunca leerán las partes importantes. La conferencia con la que ahogo al lector es en realidad mucho más importante que la respuesta al final, y en mi humilde opinión, los antecedentes que proporciono son bastante importantes para tomar esas decisiones. Pero bueno, si desea enviar una respuesta de una línea porque cree que es mejor para el OP, no dude en utilizar esa parte de mi respuesta para obtener una mejor de la que todos podamos aprender.
Aaron Bertrand

200
-- 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.


gracias Maimónides, es de los documentos, así que diría que es el mejor: P especialmente porque no fue inventado por mí :)
Rui Lima

1
Después de hacer eso, el tamaño de mi registro no ha cambiado un poco. ¿Hice algo mal?
chester89

1
Este enfoque establece el tipo de recuperación en "COMPLETO", incluso si el tipo de recuperación era otra cosa antes
Vil

1
Funcionó como magia! Tenga en cuenta que el nombre del archivo de registro es en realidad su nombre lógico (que se puede encontrar en db-> propiedades-> archivos)
Bizhan

2
Incluiría una cláusula BACKUP DATABASE en este script, para que nadie olvide esta parte. Digo esto, porque hace algunos años reduje una base de datos en un disco donde tiene muy poco espacio libre. En el proceso de reducción, los archivos se hicieron más grandes y se produjo un error de falta de espacio. Resultado: perdí la base de datos. Afortunadamente, era una base de datos de registro que había perdido tolerancia.
Cesar

185

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!


50
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.
onupdatecascade

77
@onupdatecascade: buena decisión sobre el truco de recuperación completa. tenía otra base de datos con un registro enorme: cambió a simple, luego redujo la base de datos y volvió a llenar. archivo de registro hasta 500kb!
Simon_Weaver

26
Lo siento. Pero esta respuesta simplemente NO podría estar MÁS equivocada. Al reducir la base de datos, crecerá el archivo de registro de transacciones. CUALQUIER vez que mueva datos en una base de datos de SQL Server, necesitará iniciar sesión, hinchar el archivo de registro. Para disminuir el tamaño del registro, configure la base de datos en Recuperación simple O (si le importan / necesita datos registrados, y casi siempre lo hace en producción) haga una copia de seguridad del registro. Más detalles en estos videos simples y gratuitos: sqlservervideos.com/video/logging-essentials sqlservervideos.com/video/sql2528-log-files
Michael K. Campbell

30
Wow, felicitaciones por obtener más de 1300 repeticiones por esta respuesta, pero realmente es un consejo terrible.
Aaron Bertrand

8
Aquí hay una exageración para demostrar lo que está sucediendo y por qué la reducción es absolutamente crítica de forma periódica: el registro A se cambia 1 millón de veces antes de que se realice una copia de seguridad. ¿Qué hay en el registro? 999,999 piezas de datos que son irrelevantes. Si los registros nunca se reducen, nunca sabrá cuál es el verdadero gasto operativo de la base de datos. Además, probablemente esté acaparando recursos valiosos en una SAN. La reducción es un buen mantenimiento y lo mantiene en contacto con su entorno. Muéstrame a alguien que piense que nunca deberías encogerte y te mostraré a alguien ignorando su entorno.
Newclique

54

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:

 

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.


30

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.


15
Respetuosamente, eliminar / renombrar / recrear / reemplazar el registro es una muy mala idea. La reducción es menos riesgosa, además es bastante simple de hacer.
onupdatecascade

12
+1: poco elegante o no, este método me ha sacado del agua caliente un par de veces con registros de la base de datos que han llenado todo el disco, de modo que incluso un comando de reducción no puede ejecutarse.
Shaul Behr

3
¿No existe el riesgo de transacciones no marcadas en el registro?
Paul

Esto también podría estar bien para bases de datos más pequeñas, pero si tiene una base de datos de 3 o 4 TB, puede que no sea la mejor solución.
Jaques

Esto parece correcto si ha estado desarrollando un sistema durante mucho tiempo y cargando / borrando miles de registros durante el período de desarrollo. Entonces, cuando desee utilizar esta base de datos para implementarla en vivo, los datos de prueba / desarrollo que se han registrado son redundantes y, por lo tanto, no importa si se pierden, ¿no?
JsonStatham

28

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.


1
Establecer el modo de recuperación en simple no, por sí solo, reducirá mágicamente el registro de transacciones.
Aaron Bertrand

@ Aaron No está solo, no. Supuse que el OP estaría usando su base de datos de prueba y, por lo tanto, "el registro de transacciones se reducirá muy pronto", pero tiene razón en que es más un efecto secundario: el modo de recuperación simple probablemente lo hará terminar con un encogimiento registro de transacciones pronto
Jonathan

" Simple... y nunca llenes de nuevo" - no es cierto. Lo he visto suceder (en las últimas 48 horas) en una base de datos donde el Modelo de recuperación se configuró en "SIMPLE". El crecimiento del archivo del archivo de registro se estableció en "restringido", y habíamos estado haciendo una actividad inmensa en él ... Entiendo que era una situación inusual. (En nuestra situación, donde teníamos mucho espacio en el disco, aumentamos el tamaño del archivo de registro y configuramos el crecimiento del archivo de archivo de registro en "sin restricciones" ... que por cierto, error de interfaz, aparece después del cambio como "restringido" "con un tamaño máximo de 2,097,152 MB.)
Doug_Ivison

2
@Doug_Ivison Sí, el registro de transacciones tendrá transacciones abiertas, pero se eliminarán en modo simple una vez que haya tenido lugar un punto de control. Esta respuesta solo pretende ser una rápida "mi caja de desarrollo / prueba tiene un gran registro de transacciones, y quiero que desaparezca para no tener que preocuparme con demasiada frecuencia", en lugar de tener la intención de entrar en producción medio ambiente. Para volver a iterar: no haga esto en producción .
Jonathan

1
Todo eso es cierto, y entiendo que fue un enfoque rápido de solo desarrollo. Por qué comenté: hasta que me sucedió, en realidad pensé que el modelo de recuperación simple NUNCA podría llenarse ... y creo que me tomó más tiempo resolverlo / resolverlo, mientras entendía que las transacciones inusualmente grandes pueden hacer eso.
Doug_Ivison

9

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.


... pero lo he hecho docenas de veces sin problemas. tal vez podría explicar por qué la base de datos no puede volver a adjuntar.
Johnno Nolan

En ocasiones (no muy a menudo) he visto que SQL Server no puede adjuntar la base de datos a la base de datos cuando se ha eliminado el archivo de registro. Esto te deja con un archivo MDF inútil. Hay varias posibilidades que pueden causar el problema. Las transacciones pendientes de reversión vienen a la mente.
mrdenny

44
Estoy de acuerdo con esta táctica, pero debería reservarse para casos en los que el registro se ha volado debido a algún evento imprevisto y / o extraordinario. Si configura un trabajo para hacer esto cada semana, lo está haciendo muy, muy mal.
Aaron Bertrand

2
Muy, muy cierto Aaron.
mrdenny

Sí, esto nos acaba de pasar. Queríamos deshacernos de 20G del archivo de registro ya que acabábamos de hacer una copia de seguridad de los datos antes de mover la base de datos. De ninguna manera MSSQL nos permitiría volver a adjuntar la nueva base de datos sin el enorme archivo de registro.
George M reinstala a Mónica el

9

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)

3
Estoy de acuerdo con tu respuesta, excepto por la , 1)parte. El problema es que si lo reduce a 1 MB, los eventos de crecimiento que conducen a un tamaño de registro normal serán bastante costosos, y habrá muchos de ellos si la tasa de crecimiento se deja al valor predeterminado del 10%.
Aaron Bertrand

9

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


5

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.


Esta es la forma en que borro los archivos de registro en mis cuadros de desarrollo. Prod entornos con todas las estrategias de copia de seguridad asociadas, etc. Dejo a los DBA :-)
Joon

TRUNCATE_ONLYya no es una opción en las versiones actuales de SQL Server, y no se recomienda en versiones que sí lo admiten (vea la respuesta de Rachel ).
Aaron Bertrand

5

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 .


+1 ¡Por ser la primera respuesta en mencionar que esta puede no ser una buena idea! El OP especifica una base de datos de prueba, pero es un punto que vale la pena destacar para el caso más general.
Martin Smith

Debería haber agregado: si elimina el registro TX, ¡reanude la actualización!
ripvlan

4

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.


Nunca borre el registro de transacciones. Parte de sus datos está en el registro. Eliminarlo y la base de datos se dañará. No tengo representante para rechazar el voto.
ripvlan

4

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".


Simplemente establecer la base de datos en simple no reducirá el archivo de registro, en cualquier estado en el que se encuentre actualmente. Solo puede ayudar a evitar que crezca más (pero aún podría).
Aaron Bertrand

4
  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.


3

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

ingrese la descripción de la imagen aquí

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

ingrese la descripción de la imagen aquí

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


2

Prueba esto:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

TRUNCATE_ONLYya no es una opción en las versiones actuales de SQL Server, y no se recomienda en versiones que sí lo admiten (vea la respuesta de Rachel ).
Aaron Bertrand

Funciona para mí usando MSSQL Server 2005 Standard edition
bksi

2

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
  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.


1

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);

0

Ejemplo:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

TRUNCATE_ONLYya no es una opción en las versiones actuales de SQL Server, y no se recomienda en versiones que sí lo admiten (vea la respuesta de Rachel ).
Aaron Bertrand

La pregunta no es sobre el tema de Stack Overflow como se define en el centro de ayuda . Por favor no conteste tales preguntas; en su lugar, debe marcarlos para llamar la atención y se cerrarán o migrarán adecuadamente.
Toby Speight

0

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.


-1

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

1
TRUNCATE_ONLYya no es una opción en las versiones actuales de SQL Server, y no se recomienda en versiones que sí lo admiten (vea la respuesta de Rachel ).
Aaron Bertrand
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.