Pregunta

Yo no soy un experto en SQL, y me viene a la memoria el hecho de que cada vez que tengo que hacer algo más allá de lo básico.Tengo una base de datos de prueba que no es grande en tamaño, pero el registro de transacciones sin duda lo es.¿Cómo puedo borrar el registro de transacciones?

¿Fue útil?

Solución

Hacer un archivo de registro más pequeño que en realidad debería ser reservada para los casos donde se encontró con el crecimiento inesperado que no se espere que ocurra de nuevo.Si el archivo de registro crecerá para el mismo tamaño de nuevo, no mucho se logra mediante la reducción es temporal.Ahora, dependiendo de los objetivos de recuperación de la base de datos, estas son las acciones que usted debe tomar.

En primer lugar, tome una copia de seguridad completa

No realizar ningún cambio en su base de datos sin asegurarse de que usted puede restaurar en caso de que algo vaya mal.

Si usted se preocupa por el punto en el tiempo de recuperación

(Y por el punto en el tiempo de recuperación, me refiero a que la atención acerca de ser capaz de restaurar a cualquier otra cosa que una copia completa o diferencial.)

Presumiblemente su base de datos está en FULL el modo de recuperación.Si no, entonces asegúrese de que es:

ALTER DATABASE testdb SET RECOVERY FULL;

Incluso si usted está tomando regular de copias de seguridad completas, el archivo de registro que va a crecer y crecer hasta que se realice una registro de copia de seguridad - esto es para su protección, no innecesariamente comer fuera de su espacio de disco.Usted debe ser la realización de estas copias de seguridad del registro con bastante frecuencia, de acuerdo a sus objetivos de recuperación.Por ejemplo, si usted tiene una regla de negocio indica que usted puede permitirse el lujo de perder no más de 15 minutos de los datos en caso de un desastre, usted debe tener un trabajo que realiza copias de seguridad del registro cada 15 minutos.Aquí es un script que se va a generar sellos de tiempo los nombres de archivo basado en la hora actual (pero también se puede hacer esto con los planes de mantenimiento, etc., simplemente no elegir cualquiera de la reducción de las opciones 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 un equipo diferente que representa un dispositivo de almacenamiento subyacente.La copia de estos a la misma máquina (o a una máquina distinta a la que utiliza la misma base de discos, o en otra máquina virtual que está en el mismo host físico) no ayuda a usted, ya que si la máquina golpes, ha perdido su base de datos y sus copias de seguridad.Dependiendo de su infraestructura de red puede tener más sentido para copia de seguridad a nivel local y, a continuación, transferirlos a una ubicación diferente detrás de las escenas;en cualquier caso, usted desea conseguir fuera de la base de datos principal de la máquina tan pronto como sea posible.

Ahora, una vez que han regular de copias de seguridad del registro en funcionamiento, debe ser razonable para reducir el tamaño del archivo de registro a algo más razonable de lo que es soplado hasta ahora.Esto no no significa correr SHRINKFILE una y otra vez hasta que el archivo de registro es de 1 MB - incluso si usted está haciendo la copia de seguridad del registro con frecuencia, todavía es necesario dar cabida a la suma de cualquiera de las transacciones simultáneas que puede ocurrir.Archivo de registro automático de los eventos son caros, ya que SQL Server tiene a cero los archivos (a diferencia de los archivos de datos de inicialización instantánea de archivos está habilitado), y transacciones de usuario tiene que esperar mientras esto sucede.Quieres hacerlo crecer-shrink-crecer-reducir rutina como poco como sea posible, y ciertamente no desea que sus usuarios pagar por ello.

Tenga en cuenta que usted puede necesitar para copia de seguridad del registro dos veces antes de un shrink es posible (gracias Robert).

Así, tienes que venir para arriba con un práctico tamaño de su archivo de registro.Aquí nadie puede decir lo que es, sin saber mucho más acerca de su sistema, pero si usted ha sido frecuentemente reducir el archivo de registro y ha estado creciendo de nuevo, una buena marca de agua es probablemente el 10 y el 50% más alto que el más grande que ha sido.Digamos que llega a 200 MB, y quiere que los posteriores de crecimiento automático de eventos de 50 MB, entonces usted 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, puede que tenga que ejecutar esto primero:

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

Si usted no se preocupan por el punto en el tiempo de recuperación

Si esto es una prueba de la base de datos, y no se preocupan por el punto en el tiempo de recuperación, entonces usted debe asegurarse de que su base de datos está en SIMPLE el modo de recuperación.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Poner la base de datos en SIMPLE el modo de recuperación se asegurará de que SQL Server re-utiliza porciones del archivo de registro (esencialmente la eliminación gradual de las transacciones inactivas), en vez de crecer para mantener un registro de todos transacciones (como FULL la recuperación hasta que la copia de seguridad del registro). CHECKPOINT eventos le ayudará a controlar el registro y asegúrese de que no necesita crecer a menos que generan una gran cantidad de t-registro de la actividad entre CHECKPOINTs.

A continuación, debe hacer absoluto seguro de que este registro de crecimiento fue realmente debida a un evento anormal (es decir, un encuentro anual de primavera de la limpieza o de la reconstrucción de sus mayores índices), y no debido a la normal, de uso cotidiano.Si se reduce el archivo de registro para un ridículamente pequeño tamaño, y SQL Server sólo tiene que crecer de nuevo para dar cabida a su actividad normal, lo conseguiste?Fueron capaces de hacer uso de ese espacio de disco se liberará sólo temporalmente?Si usted necesita una solución inmediata, a continuación, puede ejecutar el 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, establecer un adecuado tamaño y tasa de crecimiento.Como por el ejemplo en el punto en el tiempo de recuperación de caso, usted puede utilizar el mismo código y la lógica para determinar qué archivo de tamaño es el apropiado y el conjunto razonable de crecimiento automático de los parámetros.

Algunas de las cosas que no quieres hacer

  • Copia de seguridad del registro con TRUNCATE_ONLY opción y, a continuación, SHRINKFILE.Por un lado, este TRUNCATE_ONLY opción ha quedado obsoleto y ya no se encuentra disponible en las versiones actuales de SQL Server.En segundo lugar, si usted está en FULL modelo de recuperación, esto va a destruir su cadena de registro y requieren una nueva copia de seguridad completa.

  • Separar la base de datos, elimine el archivo de registro, y vuelva a colocar.No puedo enfatizar lo peligroso que puede ser esto.Su base de datos no puede ser una copia de seguridad, puede aparecer como sospechoso, puede que tenga que volver a una copia de seguridad (si tiene uno), etc.etc.

  • El uso de la "reducir base de datos" opción. DBCC SHRINKDATABASE y el plan de mantenimiento de la opción de hacer el mismo son malas ideas, especialmente si usted realmente sólo necesita para resolver un problema de registro de tema.Objetivo el archivo que desea ajustar y ajustar de forma independiente, utilizando DBCC SHRINKFILE o ALTER DATABASE ... MODIFY FILE (ejemplos anteriores).

  • Reducir el archivo de registro a 1 MB.Esto se ve tentador porque, oye, SQL Server me deja hacerlo en determinados escenarios, y mira todo el espacio que libera!A menos que su base de datos es de sólo lectura (y lo es, debe marcarlo como tal el uso de ALTER DATABASE), esta absolutamente solo conducen a una cantidad innecesaria de crecimiento de eventos, ya que el registro tiene que atender a las transacciones corrientes, independientemente del modelo de recuperación.¿Cuál es el punto de liberar ese espacio de forma temporal, por lo que SQL Server puede tomar de nuevo lentamente y dolorosamente?

  • Crear un segundo archivo de registro.Esto proporcionará temporalmente el alivio de la unidad que ha llenado el disco, pero esto es como tratando de arreglar un pinchazo en un pulmón con una curita.Usted debe hacer frente a la problemática del archivo de registro directamente en lugar de sólo añadir otro problema potencial.Otro de redirigir a algunos de transacción de la actividad de registro en una unidad diferente, un segundo archivo de registro, realmente no hace nada para usted (a diferencia de un segundo archivo de datos), ya que sólo uno de los archivos puede ser usado alguna vez en un tiempo. Pablo Randal también explica por qué varios archivos de registro puede morder más tarde.

Ser proactivo

En lugar de reducir el archivo de registro para una pequeña cantidad y dejarla en constante crecimiento automático en una pequeña tasa en su propio, establece que para algunos bastante grandes de tamaño (uno que se acomode a la suma de su más grande conjunto de transacciones simultáneas) y establecer un razonable crecimiento automático de ajuste como un retroceso, por lo que no tiene que crecer varias veces para satisfacer las transacciones individuales y, por lo que será relativamente raro para que nunca tenga que crecer durante las operaciones normales del negocio.

El peor de los posibles valores aquí son de 1 MB de crecimiento o crecimiento del 10%.Curiosamente, estos son los valores por defecto de SQL Server (que me he quejado y preguntado por los cambios en vano) - 1 MB para los archivos de datos, y el 10% para los archivos de registro.El primero es demasiado pequeña en este día y edad, y el segundo conduce a más y más eventos cada vez (por ejemplo, en el archivo de registro es de 500 MB, el crecimiento en primer lugar es de 50 MB, al lado de crecimiento es de 55 MB, al lado de crecimiento es de 60.5 MB, etc.etc.- y en e/S lento, creo yo, se nota realmente esta curva).

Leer más

Por favor no pare aquí;mientras que muchos de los consejos que ves por ahí acerca de la reducción de los archivos de registro es inherentemente malo e incluso potencialmente desastroso, hay algunas personas que se preocupan más acerca de la integridad de los datos de liberar espacio en el disco.

Un blog post que escribí en el 2009, cuando vi a un par de "aquí es cómo reducir el archivo de registro" puestos de primavera.

Un blog Brent Ozar escribí hace cuatro años, apuntando a varios recursos, en respuesta a un Servidor SQL server artículo de la Revista que debe no se han publicado.

Un post del blog de Pablo Randal explicando por qué t-registro de mantenimiento es importante y por qué usted no debe comprimir los archivos de datos, ya sea.

Mike Walsh tiene una gran respuesta cubrir algunos de estos aspectos también, incluidas las razones por las que usted no podría ser capaz de reducir el tamaño de su archivo de registro inmediatamente.

Otros consejos

DESCARGO de responsabilidad: Por favor, lea los comentarios de abajo cuidadosamente, y supongo que usted ya ha leído el aceptado respuesta.Como me dijo hace casi 5 años:

si alguien tiene algún comentario que añadir para situaciones en las que este NO es un adecuada o de la solución óptima, a continuación, por favor deje un comentario más abajo


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

  • Seleccione Tareas → Reducir → Base De Datos

  • A continuación, haga clic en OK!

Yo suelo abrir el Explorador de Windows el directorio que contiene los archivos de base de datos, por lo que puedo ver de inmediato el efecto.

Yo estaba muy sorprendido de este trabajo!Normalmente he usado DBCC antes, pero he intentado eso y no tengas miedo de nada, así que he intentado que la interfaz gráfica de usuario (2005) y funcionó muy bien - la liberación de hasta 17 GB en 10 segundos

En modo de recuperación Completa, esto podría no funcionar, así que usted tiene que hacer una copia de seguridad primero en el registro, o cambiar de recuperación Simple, a continuación, reducir el archivo.[gracias @onupdatecascade para este]

--

PS:Aprecio lo que algunos han comentado acerca de los peligros de esta, pero en mi entorno no tengo problemas de hacer esto por mí mismo sobre todo porque yo siempre hacer una copia de seguridad primero.Así que por favor tome en cuenta lo que su entorno es, y cómo esto afecta a su estrategia de copia de seguridad y seguridad en el trabajo antes de continuar.De todo lo que estaba haciendo estaba apuntando a la gente 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)

Puede que desee una copia de seguridad primero.

A continuación es una secuencia de comandos para reducir el registro de transacciones, pero sin duda recomiendo la copia de seguridad del registro de transacciones antes de reducir la misma.

Si usted acaba de encoger el archivo que se va a perder un montón de datos que puede venir como un protector de la vida en caso de desastre.El registro de transacciones contiene una gran cantidad de datos útiles que se pueden leer con un tercero registro del log de transacciones (que se puede leer de forma manual, pero con un esfuerzo extremo, aunque).

El registro de transacciones es también una necesidad cuando se trata del punto en el tiempo de recuperación, así que no sólo tirarlo a la basura, pero asegúrese de realizar una copia de seguridad de antemano.

Aquí hay varios posts donde la gente utiliza los datos almacenados en el registro de transacciones para realizar 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

Usted puede obtener un error similar a este cuando la ejecución de comandos de arriba

"No se puede reducir el archivo de registro (log file name) porque la lógica archivo de registro ubicado al final de el archivo está en uso"

Esto significa que TLOG está en uso.En este caso, trate de la ejecución de este varias veces en una fila o encontrar una manera de reducir la base de datos de actividades.

Si usted no utiliza los registros de transacciones para las restauraciones (es decir,Sólo puedes hacer copias de seguridad completas), se puede establecer el Modo de Recuperación a una "Simple", y el registro de transacciones dentro de muy poco se encogen y nunca se llenan de nuevo.

Si está utilizando SQL 7 o 2000, puede habilitar el "truncar el registro de punto de control" en la base de datos de la ficha opciones.Esto tiene el mismo efecto.

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

Aquí es un simple y muy poco elegante & potencialmente peligrosos manera.

  1. Copia de seguridad de DB
  2. Separar DB
  3. Cambiar el nombre de archivo de Registro
  4. Adjuntar DB
  5. Nuevo archivo de registro será recreado
  6. Eliminar cambiado el nombre de archivo de Registro.

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

La mayoría de las respuestas aquí son hasta ahora suponiendo que usted no necesita realmente el archivo de Registro de Transacciones, sin embargo, si su base de datos es el uso de la FULL modelo de recuperación, y usted quiere guardar sus copias de seguridad en caso de que necesite restaurar la base de datos, entonces no trunca o eliminar el archivo de registro de la manera en que muchas de estas respuestas sugieren.

Eliminar el archivo de registro (a través de truncar, descartarlo, borrar, etc) romper su cadena de copia de seguridad, y le impedirá restaurar a cualquier punto en el tiempo desde su última completo, diferencial, o el registro de transacciones de copia de seguridad, hasta el próximo pleno o de la copia de seguridad diferencial se hace.

A partir de la Artículo de Microsoft enBACKUP

Le recomendamos que no utilice nunca NO_LOG o TRUNCATE_ONLY manualmente truncar el registro de transacciones, debido a que de esta forma se rompe la cadena de registro.Hasta el próximo completa o diferencial de la base de datos de copia de seguridad, la base de datos no es protegido de los medios de comunicación fracaso.Manual para el uso de truncamiento de registro en muy en circunstancias especiales, y crear copias de seguridad de los datos inmediatamente.

Para evitar que, de copia de seguridad de su archivo de registro en el disco antes de reducir la misma.La sintaxis sería algo como esto:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

Las transacciones de SQL Server de registro debe ser mantenido correctamente para evitar que su crecimiento no deseado.Esto significa que ejecutan copias de seguridad de registro de transacciones con la suficiente frecuencia.Por no hacerlo, corres el riesgo de que el registro de transacciones se llena y empiezan a crecer.

Además de las respuestas para esta pregunta, recomiendo la lectura y la comprensión de las transacciones de registro de los mitos más comunes.Estas lecturas pueden ayudar a la comprensión de que el registro de transacciones y de decidir qué técnicas usar para "claro" es:

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

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

Uno de los mayores rendimiento de las operaciones intensivas en SQL Server es un auto-crecer evento de la línea del archivo de registro de transacciones.Por no hacer copias de seguridad de registro de transacciones con bastante frecuencia, el de registro de transacciones en línea se convertirá completo y tendrá que crecer.El valor predeterminado de crecimiento tamaño es de 10%.El más ocupado de la base de datos, la rapidez de las transacciones en línea de registro va a crecer si seguridad del registro de transacciones no se crean La creación de un Servidor SQL server copia de seguridad del registro de transacciones no bloquea la línea de registro de transacciones, pero un crecimiento automático de caso.Puede bloquear toda la actividad en línea de registro de transacciones

De Registro de transacciones de los mitos:

Mito:Regular de registro de contracción es una buena práctica de mantenimiento

FALSO.Registro de crecimiento es muy caro debido a que el nuevo fragmento se debe poner a cero-out.Toda la actividad de escritura se detiene en la base de datos hasta la reducción a cero está terminado, y si su escritura en disco es lento o de crecimiento automático de tamaño es grande, que la pausa puede ser enorme y que los usuarios notarán.Esa es una razón por la que quieres evitar el crecimiento.Si se reduce el registro, va a crecer de nuevo y se está perdiendo la operación de disco en huelga shrink-y-crecimiento-de nuevo juego

Esta técnica que Juan se recomienda no se recomienda como no hay ninguna garantía de que la base de datos sin adjuntar el archivo de registro.Cambio de la base de datos de lleno a la simple, la fuerza de un punto de control y esperar un par de minutos.El SQL Server borrar el registro, que puede reducir el uso de DBCC SHRINKFILE.

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

Registro de copia de seguridad DatabaseName Con Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile le dará la lógica de registro de nombre de archivo.

Se refieren a:

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

Si su base de datos en el Modelo de Recuperación Completa y si usted no está tomando TL de copia de seguridad, entonces el cambio es SENCILLO.

El uso de la DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY) comando.Si esto es una prueba de la base de datos y que están tratando de guardar/recuperar espacio, esto va a ayudar.

Recuerde sin embargo que el TX registros tienen una especie de mínimo/estado estacionario tamaño que ellos crezcan.Dependiendo de su modelo de recuperación puede no ser capaz de reducir el registro - si en su totalidad y no la emisión de TX copias de seguridad del registro el registro no se puede reducir - se va a crecer para siempre.Si usted no necesita TX registro de copias de seguridad, cambiar su modelo de recuperación para Simple.

Y recuerde, nunca, nunca, bajo ninguna circunstancia eliminar el registro (LDF) archivo!Va bastante tienen instantánea de base de datos de la corrupción.Cocido!Hecho!De pérdida de datos!Si la izquierda "reparar" el principal archivo MDF podría quedar dañado de forma permanente.

Nunca borrar el registro de transacciones, van a perder datos!Parte de los datos en el TX Log (independientemente del modelo de recuperación)...si separa y "cambiar el nombre de" el TX archivo de registro que efectivamente elimina parte de la base de datos.

Para aquellos que han eliminado el TX de Registro puede que desee ejecutar un par de checkdb comandos y reparar los daños antes de perder más datos.

Echa un vistazo Pablo Randal los posts en el blog sobre este tema, un mal consejo.

También, en general, no use shrinkfile en los archivos MDF como se puede ver muy fragmento de sus datos.Echa un vistazo a su Mal Asesoramiento de la sección para obtener más información ("¿por Qué usted no debe reducir sus archivos de datos")

Echa un vistazo Pablo del sitio web - se cubre esas preguntas.El mes pasado él caminó a través de muchas de estas cuestiones en su El Mito De Un Día de la serie.

Para Truncar el archivo de registro:

  • Copia de seguridad de la base de datos
  • Separar la base de datos, ya sea mediante el Administrador corporativo o mediante la ejecución de : Sp_DetachDB [DBName]
  • Eliminar el archivo de registro de transacciones.(o cambie el nombre del archivo, por si acaso)
  • Vuelva a conectar la base de datos utilizando de nuevo: Sp_AttachDB [DBName]
  • Cuando la base de datos se adjunta, un nuevo archivo de registro de transacciones se crea.

Para Reducir el tamaño del archivo de registro:

  • Registro de copia de seguridad [DBName] con No_Log
  • Reduzca la base de datos, ya sea por:

    Mediante el administrador corporativo :- Haga clic derecho en la base de datos, Todas las tareas, Reducir base de datos, Archivos, Seleccione el archivo de registro, ACEPTAR.

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

Usted puede encontrar el nombre lógico del archivo de registro mediante la ejecución de sp_helpdb o mirando en las propiedades de la base de datos en el Administrador corporativo.

Mi experiencia en la mayoría de los Servidores de SQL no hay ninguna copia de seguridad del registro de transacciones.Copias de seguridad completas o copias de seguridad diferenciales son una práctica común, pero la seguridad del registro de transacciones son realmente, muy pocas veces.De modo que el archivo de registro de transacciones crece para siempre (hasta que el disco esté lleno).En este caso el modelo de recuperación debe estar ajustado a "simple".No te olvides de modificar el sistema de bases de datos "modelo" y "tempdb", también.

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

  1. Tome una copia de seguridad del archivo MDB.
  2. Deje de servicios de SQL
  3. Cambie el nombre del archivo de registro
  4. Iniciar el servicio

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

Eliminar o mover el nuevo nombre de archivo de registro.

Intente esto:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

Base de datos → clic derecho Propiedades → archivo → añadir otro archivo de registro con un nombre diferente y establecer la ruta de acceso de la misma como el antiguo archivo de registro con un nombre de archivo diferente.

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

  1. Copia de seguridad de DB
  2. Separar DB
  3. Cambiar el nombre de archivo de Registro
  4. Adjuntar DB (mientras se coloca quitar cambiado de nombre .ldf (archivo de registro).Seleccionar y eliminar pulsando el botón Quitar)
  5. Nuevo archivo de registro será recreado
  6. Eliminar cambiado el nombre de archivo de Registro.

Esto funciona, pero se sugiere tomar copia de seguridad de su base de datos.

Ejemplo:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Sucedió conmigo donde el archivo de registro de base fue de 28 de Egb.

¿Qué se puede hacer para reducir este?En realidad, los archivos de registro los archivos de datos que el servidor de SQL server mantiene cuando una transacción se haya realizado.Para una transacción de proceso de SQL server asigna páginas para la misma.Pero después de la finalización de la transacción, estos no son liberados de repente con la esperanza de que puede haber una transacción que viene al igual que el mismo.Esto se mantiene hasta el espacio.

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

Paso 2:Haga clic derecho en la base de datos Tarea> copia de seguridad Seleccione copia de seguridad de tipo de Registro de Transacciones Agregar una dirección de destino y nombre de archivo para guardar los datos de copia de seguridad (.bak)

Repita este paso de nuevo y en este momento dar otro nombre de archivo

enter image description here

Paso 3:Ahora vaya a la base de datos Haga clic derecho en la base de datos

Tareas> Encoge> Archivos Elija el tipo de Archivo de Registro como Reducir la acción como liberar espacio no utilizado

enter image description here

Paso 4:

Compruebe el archivo de registro normalmente en SQL 2014 esto se puede encontrar en

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

En mi caso, su reducido de 28 GB a 1 MB

Algunas de las otras respuestas no me funciona:No fue posible crear el punto de control, mientras que la db en línea, debido a que el registro de transacciones estaba lleno (qué irónico).Sin embargo, después de ajustar la base de datos en modo de emergencia, que fue capaz de 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);

DB Registro de Transacciones Reducir al mínimo el tamaño de la:

  1. Copia de seguridad:Registro de transacciones
  2. Comprimir archivos:Registro de transacciones
  3. Copia de seguridad:Registro de transacciones
  4. Comprimir archivos:Registro de transacciones

He hecho pruebas en varios número de DBs: esta secuencia de trabajos.

Normalmente se reduce a 2 MB.

O por una secuencia de comandos:

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
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top