sql-server - tipos - transacciones mysql

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

No soy un experto en SQL, y me lo recuerdo cada vez que necesito 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 definitivamente lo es. ¿Cómo borro el registro de transacciones?

Ejemplo:

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

Copia de seguridad de base de datos
Separar DB
Renombrar archivo de registro
Adjunte la base de datos (al adjuntar eliminar renombrado .ldf (archivo de registro). Seleccione y elimine presionando el botón Eliminar)
El nuevo archivo de registro será recreado
Eliminar archivo de registro renombrado.

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

Tome una copia de seguridad del archivo MDB.
Detener los servicios SQL
Renombra el archivo de registro
Iniciar el servicio

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

Elimine o mueva el archivo de registro renombrado.

A continuación se incluye una secuencia de comandos 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 tamaño del archivo, perderá una tonelada de datos que podrían salvar su vida en caso de desastre. El registro de transacciones contiene una gran cantidad de datos útiles que se pueden leer con un lector de registros de transacciones de terceros (se puede leer de forma manual pero con un esfuerzo extremo).

El registro de transacciones también es obligatorio cuando se trata de un punto en el tiempo de recuperación, así que no lo deseche, pero asegúrese de realizar una copia de seguridad de antemano.

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

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

Copia de seguridad de base de datos
Separar DB
Renombrar archivo de registro
Adjuntar DB
El nuevo archivo de registro será recreado
Eliminar archivo de registro renombrado.

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

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

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

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 frecuencia suficiente. Al no hacerlo, se arriesga a 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 usar para "borrarlo":

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

Mito: Mi servidor SQL está muy ocupado. No quiero hacer copias de seguridad del registro de transacciones de SQL Server
Una de las operaciones más intensivas en rendimiento de SQL Server es un evento de crecimiento automático del archivo de registro de transacciones en línea. Al no realizar copias de seguridad del registro de transacciones con suficiente frecuencia, 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í lo hace 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 del registro es una buena práctica de mantenimiento
FALSO. El crecimiento de los registros es muy costoso porque la nueva parte debe estar en cero. Toda la actividad de escritura se detiene en esa base de datos hasta que finaliza la reducción a cero, y si la escritura del disco es lenta o el tamaño del crecimiento automático es grande, la pausa puede ser enorme y los usuarios lo notarán. Esa es una de las razones por las que quieres evitar el crecimiento. Si reduce el registro, volverá a crecer y solo está desperdiciando el funcionamiento del disco en un juego innecesario de reducir y volver a crecer

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

En primer lugar, tomar 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 de un punto en el tiempo

(Y con la recuperación de un punto en el tiempo, me refiero a que te importa poder restaurar en otra cosa que no sea una copia de seguridad completa o diferencial).

Presumiblemente su base de datos está en modo de recuperación FULL . Si no, entonces 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 del registro ; esto es para su protección, para no consumir innecesariamente espacio de 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 no puede perder más de 15 minutos de datos en caso de un desastre, debe tener un trabajo que respalde el registro cada 15 minutos. Aquí hay una secuencia de comandos que generará nombres de archivos con marca de tiempo según la hora actual (pero también puede hacer esto 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. La copia de seguridad 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) no le ayuda realmente, ya que si la máquina explota, ha perdido su base de datos y sus copias de seguridad. Dependiendo de su infraestructura de red, puede tener más sentido hacer una copia de seguridad local y luego transferirla a una ubicación diferente entre bastidores; en cualquier caso, querrá sacarlos de la máquina de la base de datos primaria lo más rápido posible.

Ahora, una vez que tenga copias de seguridad de registro regulares en ejecución, debería ser razonable reducir el archivo de registro a algo más razonable que cualquier otra cosa hasta ahora. Esto no significa que se ejecute SHRINKFILE una y otra vez hasta que el archivo de registro tenga 1 MB; incluso si realiza una copia de seguridad del registro con frecuencia, debe acomodar la suma de cualquier transacción concurrente que pueda ocurrir. Los eventos de crecimiento automático de archivos de registro son costosos, 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 lo menos posible esta rutina de crecer, reducir, aumentar y reducir, y ciertamente no desea que sus usuarios paguen por ello.

Tenga en cuenta que es posible que deba realizar una copia de seguridad del registro dos veces antes de que sea posible reducirlo (gracias Robert).

Por lo tanto, necesita crear 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 el archivo de registro con frecuencia y ha vuelto a crecer, una buena marca de agua es probablemente un 10-50% más alta que la más grande. . Digamos que llega a 200 MB, y desea que cualquier evento de crecimiento automático posterior sea de 50 MB, luego puede ajustar el tamaño del archivo de registro de esta manera:

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

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

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

Si no te importa la recuperación de un punto en el tiempo

Si esta es una base de datos de prueba, y no le importa la recuperación de un punto en el tiempo, entonces debe asegurarse de que su base de datos esté en modo de recuperación SIMPLE .

ALTER DATABASE testdb SET RECOVERY SIMPLE;

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

A continuación, debe estar absolutamente seguro de que el crecimiento de este registro fue realmente debido a un evento anormal (por ejemplo, una limpieza de primavera anual 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 volverlo a aumentar para adaptarse a su actividad normal, ¿qué ganó? ¿Pudiste hacer uso de ese espacio de 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, establecer un tamaño apropiado y la tasa de crecimiento. Según el ejemplo en el caso de recuperación de un punto en el tiempo, puede usar el mismo código y lógica para determinar qué tamaño de archivo es el adecuado y establecer parámetros razonables de crecimiento automático.

Algunas cosas que no quieres hacer

Realice una TRUNCATE_ONLY seguridad del registro con la opción TRUNCATE_ONLY y luego SHRINKFILE . Por un lado, esta opción TRUNCATE_ONLY ha quedado en desuso y ya no está disponible en las versiones actuales de SQL Server. Segundo, si está en el modelo de recuperación FULL , esto destruirá su cadena de registro y requerirá una nueva copia de seguridad completa.
Desconecte la base de datos, elimine el archivo de registro y vuelva a adjuntar . No puedo enfatizar lo peligroso que puede ser esto. Es posible que su base de datos no se recupere, puede aparecer como sospechoso, es posible que tenga que volver a una copia de seguridad (si tiene una), etc.
Utilice la opción "reducir la base de datos" . DBCC SHRINKDATABASE y la opción de plan de mantenimiento para hacer lo mismo son malas ideas, especialmente si solo necesita resolver un problema de registro. Seleccione el archivo que desea ajustar y ajústelo de forma independiente, utilizando DBCC SHRINKFILE o ALTER DATABASE ... MODIFY FILE (ejemplos anteriores).
Reducir el archivo de registro a 1 MB . Esto parece tentador porque, hey, SQL Server me permite hacerlo en ciertos escenarios, y mira todo el espacio que libera. A menos que su base de datos sea de solo lectura (y así sea, debe marcarla como tal utilizando ALTER DATABASE ), esto simplemente conducirá a muchos eventos de crecimiento innecesarios, ya que el registro debe 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?
Crear un segundo archivo de registro . Esto proporcionará 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 se puede usar uno de los archivos a la vez. Paul Randal también explica por qué varios archivos de registro pueden morderlo más tarde .

Ser proactivo

En lugar de reducir su archivo de registro a una pequeña cantidad y dejarlo crecer automáticamente a una pequeña tasa por sí solo, configúrelo en un tamaño razonablemente grande (uno que se ajuste a la suma de su mayor conjunto de transacciones concurrentes) y establezca un crecimiento automático razonable la configuración como un respaldo, para que no tenga que crecer varias veces para satisfacer transacciones individuales y para que sea relativamente raro que tenga que crecer durante las operaciones comerciales normales.

Las peores configuraciones 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 en esta época, y el último conduce a eventos más y más largos cada vez (por ejemplo, su archivo de registro es de 500 MB, el primer crecimiento es de 50 MB, el siguiente crecimiento es de 55 MB, el próximo crecimiento es de 60.5 MB , etc. etc. - y en I / O lento, créame, realmente notará esta curva).

Otras lecturas

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

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

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

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

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

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

Eliminar el archivo de registro (truncarlo, descartarlo, borrarlo, etc.) interrumpirá su cadena de respaldo y evitará que restaure en cualquier momento desde su último respaldo de registro completo, diferencial o de transacciones, hasta el próximo completo o se hace copia de seguridad diferencial.

Del artículo de Microsoft en BACKUP

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

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)

No se recomienda esta técnica que recomienda John, ya que no hay garantía de que la base de datos se adjunte 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 usando DBCC SHRINKFILE.

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

Copia de seguridad del nombre de 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:

Recuperación de un registro de transacciones completo en una base de datos de SQL Server

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

Prueba esto:

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

Según mi experiencia en la mayoría de los servidores SQL, no hay una copia de seguridad del registro de transacciones. Las copias de seguridad completas o las copias de seguridad diferenciales son una práctica común, pero las copias de seguridad del registro de transacciones son muy poco frecuentes. Entonces, 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 se olvide de modificar las bases de datos del sistema "modelo" y "tempdb", también.

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

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

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

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

Utilice el DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY) . Si se trata de una base de datos de prueba y está intentando guardar / recuperar espacio, esto ayudará.

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

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

Nunca elimine el registro de transacciones: perderá datos. Parte de sus datos está en el Registro de TX (independientemente del modelo de recuperación) ... si se separa y "cambia el nombre" del archivo de registro de TX que elimina de manera efectiva parte de su base de datos.

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

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

Además, en general, no utilice archivos de contracción en los archivos MDF, ya que puede fragmentar gravemente sus datos. Consulte la sección de consejos incorrectos para obtener más información ("Por qué no debe reducir sus archivos de datos")

Echa un vistazo a la página web de Paul - él cubre estas mismas preguntas. El mes pasado, repasó muchos de estos problemas en su serie Myth A Day .

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 a continuación.

Haga clic derecho en el nombre de la base de datos.
Seleccionar tareas → Reducir → Base de datos
A continuación, haga clic en Aceptar !

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

En realidad me sorprendió bastante esto funcionó! Normalmente he usado DBCC antes, pero simplemente lo intenté y no encogió 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 tamaño del archivo. [Gracias @onupdatecascade por esto]

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

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 renombrar el 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:

Registro de copia de seguridad [DBName] con No_Log
Reducir la base de datos ya sea por:
Uso de Enterprise manager: - Haga clic derecho en la base de datos, Todas las tareas, Reducir la 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.

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 mantiene cuando se lleva a cabo 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 retiene 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 con el botón 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 el nombre del archivo para mantener los datos de la copia de seguridad (.bak)

Repita este paso otra vez y en este momento dé otro nombre de archivo

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

Tareas> Contracciones> Archivos Elija el tipo de archivo como acción Log Logrrink como liberar espacio no utilizado

Etapa 4:

Revise su archivo de registro normalmente en SQL 2014, este se puede encontrar en

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

En mi caso, se reduce de 28 GB a 1 MB.

Algunas de las otras respuestas no me funcionaron: 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);

Registro de transacciones de DB Reducir a tamaño mínimo :

Copia de seguridad: Registro de transacciones
Reducir archivos: registro de transacciones
Copia de seguridad: Registro de transacciones
Reducir archivos: registro de transacciones

Hice pruebas en varios DBs: esta secuencia funciona .

Por lo general, se reduce a 2MB .

O por un guión:

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

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

Desde: DBCC SHRINKFILE (Transact-SQL)

Es posible que desee hacer una copia de seguridad primero.