sql server - tamaño - ¿Por qué no puedo reducir un archivo de registro de transacciones, incluso después de una copia de seguridad?
sql vaciar log (15)
¿Ha intentado desde dentro de SQL Server Management Studio con la GUI. Haga clic derecho en la base de datos, tareas, reducir, archivos. Seleccione filetype = Log.
Trabajé para mí hace una semana.
Tengo una base de datos que tiene un archivo de registro de transacciones de 28gig. El modo de recuperación es simple. Acabo de hacer una copia de seguridad completa de la base de datos y luego ejecuté ambos:
backup log dbmcms with truncate_only DBCC SHRINKFILE (''Wxlog0'', TRUNCATEONLY)
backup log dbmcms with truncate_only DBCC SHRINKFILE (''Wxlog0'', TRUNCATEONLY)
El nombre de la base de datos es db_mcms y el nombre del archivo de registro de transacciones es Wxlog0.
Tampoco ha ayudado. No estoy seguro de qué hacer a continuación.
''sp_removedbreplication'' no solucionó el problema para mí, ya que SQL acaba de regresar diciendo que la base de datos no era parte de una replicación ...
Encontré mi respuesta aquí:
- http://www.sql-server-performance.com/forum/threads/log-file-fails-to-truncate.25410/
- http://blogs.msdn.com/b/sqlserverfaq/archive/2009/06/01/size-of-the-transaction-log-increasing-and-cannot-be-truncated-or-shrinked-due-to-snapshot-replication.aspx
Básicamente tuve que crear una replicación, restablecer todos los punteros de replicación a cero; luego borre la replicación que acabo de hacer. es decir
Execute SP_ReplicationDbOption {DBName},Publish,true,1
GO
Execute sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
GO
DBCC ShrinkFile({LogFileName},0)
GO
Execute SP_ReplicationDbOption {DBName},Publish,false,1
GO
Esta respuesta se eliminó de here y se publica aquí en caso de que se elimine el otro hilo:
El hecho de que haya un LSN no distribuido en el registro es el problema. He visto esto una vez antes, no estoy seguro de por qué no deseleccionamos la transacción como replicada. Vamos a investigar esto internamente. Puede ejecutar el siguiente comando para desmarcar la transacción como replicada
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
En este punto, debería poder truncar el registro.
Gracias a todos por responder.
Finalmente encontramos el problema. En sys.databases, log_reuse_wait_desc fue igual a ''replicación''. Aparentemente, esto significa algo en el sentido de que SQL Server espera a que finalice una tarea de replicación antes de poder reutilizar el espacio de registro.
La replicación nunca se ha utilizado en esta base de datos o este servidor se jugó una vez en esta db. Hemos borrado el estado incorrecto ejecutando sp_removedbreplication. Después de ejecutar esto, el registro de copia de seguridad y el archivo shrink de dbcc funcionaron bien.
Definitivamente una para la bolsa de trucos.
Fuentes:
http://www.eggheadcafe.com/conversation.aspx?messageid=34020486&threadid=33890705
He tenido el mismo problema en el pasado. Normalmente, una reducción y una copia de seguridad trn tienen que ocurrir varias veces. En casos extremos, establezco la base de datos en recuperación "Simple" y luego ejecuto una operación de reducción en el archivo de registro. Eso siempre funciona para mí. Sin embargo, recientemente tuve una situación en la que eso no funcionaría. El problema fue causado por una consulta de larga duración que no se completó, por lo que cualquier intento de reducir el tamaño fue inútil hasta que pude detener ese proceso y luego ejecutar mis operaciones de reducción. Estamos hablando de un archivo de registro que creció a 60 GB y ahora se reduce a 500 MB.
Recuerde, tan pronto como cambie de modo de recuperación COMPLETO a Simple y realice el encogimiento, no olvide volver a establecerlo en COMPLETO. Luego, inmediatamente después, debe hacer una copia de seguridad de FULL DB.
Intente crear otra copia de seguridad completa después de hacer una copia de seguridad del registro w / truncate_only (IIRC debe hacer esto de todos modos para mantener la cadena de registros). En el modo de recuperación simple, su registro no debería crecer mucho, ya que se trunca efectivamente después de cada transacción. Luego intente especificar el tamaño que desea que tenga el archivo de registro, por ejemplo
-- shrink log file to c. 1 GB
DBCC SHRINKFILE (Wxlog0, 1000);
La opción TRUNCATEONLY no reorganiza las páginas dentro del archivo de registro, por lo que es posible que tenga una página activa al "final" de su archivo, lo que podría evitar que se encoja.
También puede usar DBCC SQLPERF (LOGSPACE) para asegurarse de que realmente haya espacio en el archivo de registro que se va a liberar.
Intente usar el tamaño de destino que necesita en TRUNCATEONLY en DBCC:
DBCC SHRINKFILE (''Wxlog0'', 1)
Y verifique esto en los artículos:
http://msdn.microsoft.com/en-us/library/ms189493(SQL.90).aspx
http://support.microsoft.com/kb/907511
Editar:
Puede intentar mover las páginas asignadas al principio del archivo de registro con
DBCC SHRINKFILE (''Wxlog0'', NOTRUNCATE)
y después de eso
DBCC SHRINKFILE (''Wxlog0'', 1)
No necesitas esto
DBCC SHRINKFILE (''Wxlog0'', 0)
Solo asegúrese de estar al tanto de los peligros: vea aquí: ¡No trunca sus archivos ldf!
Y aquí copia de seguridad de registro con Truncate_Only: como una trampa de oso
No puede reducir un registro de transacciones más pequeño que su tamaño creado inicialmente.
Probé todas las soluciones enumeradas y ninguna de ellas funcionó. Terminé teniendo que hacer un sp_detach_db, luego borrando el archivo ldf y volviendo a adjuntar la base de datos obligándolo a crear un nuevo archivo ldf. Eso funciono.
Puede encontrarse con este problema si su base de datos está configurada para generar automáticamente el registro y usted termina con muchos archivos de registro virtuales.
Ejecute DBCC LOGINFO(''databasename'') y observe la última entrada, si este es un 2, su archivo de registro no se reducirá. A diferencia de los archivos de datos, los archivos de registro virtuales no se pueden mover dentro del archivo de registro.
Deberá ejecutar BACKUP LOG y DBCC SHRINKFILE varias veces para reducir el tamaño del archivo de registro.
Para obtener puntos de bonificación adicionales, ejecute DBBC LOGINFO entre log y shirks
Sé que esto tiene algunos años, pero quería agregar algo de información.
Encontré en registros muy grandes, específicamente cuando la base de datos no estaba configurada para respaldar registros de transacciones (los registros eran muy grandes), la primera copia de seguridad de los registros no establecería log_reuse_wait_desc a nada, pero dejaría el estado como respaldo. Esto bloquearía el encogimiento. Ejecutar la copia de seguridad por segunda vez correctamente restablecer el log_reuse_wait_desc a NADA, permitiendo que el encogimiento se procese.
Si configura el modo de recuperación en la base de datos en 2005 (no lo sé para antes de 2005), eliminará todo el archivo de registro y luego podrá volver a ponerlo en modo de recuperación completa para reiniciar / volver a crear el archivo de registro. Nos encontramos con esto con SQL 2005 express, ya que no pudimos acercarnos al límite de 4GB con datos hasta que cambiamos el modo de recuperación.
Vuelva a poner la base de datos en modo completo, ejecute la copia de seguridad del registro de transacciones (no solo una copia de seguridad completa) y luego la reducción.
Una vez que se ha reducido, puede volver a poner la base de datos en modo simple y el registro txn permanecerá del mismo tamaño.
Yo tuve el mismo problema. Ejecuté un proceso de desfragmentación de índice, pero el registro de transacciones se llenó y el proceso de desfragmentación falló. El registro de transacciones se mantuvo grande.
Realicé una copia de seguridad del registro de transacciones y luego procedí a reducir el archivo de registro de transacciones .ldf. Sin embargo, el registro de transacciones no se redujo en absoluto.
Luego emití un "CHECKPOINT" seguido de "DBCC DROPCLEANBUFFER" y pude reducir el archivo de registro de transacciones .ldf a partir de entonces