Configuramos el reflejo de la base de datos durante el fin de semana y olvidamos volver a habilitar el trabajo que respalda los registros de transacciones. Cuando llegué esta mañana, el registro de transacciones se había disparado a 58 GB y ocupaba la mayor parte del espacio en el disco.
Hice una copia de seguridad manual del registro de transacciones en el disco para que la base de datos vuelva a ejecutarse, sin embargo, ejecutar DBCC SHRINKFILE no parece disminuir el tamaño físico del archivo de registro de transacciones.
DBCC SHRINKFILE (N'MyDatabaseName_Log', 1000)Si reviso el uso del registro usando
DBCC SQLPERF(LOGSPACE)Puedo ver que solo se está utilizando el 22% del registro actual
Nombre de la base de datos Tamaño del registro (MB) Espacio de registro utilizado (%) Estado MyDatabaseName 55440.87 22.38189 0
Si log_reuse_wait_descreviso en sys.databses, el único registro que veo es DATABASE_MIRRORING, así que supongo que el espejo está jugando un papel en por qué el tamaño físico del archivo de registro no se reducirá.
SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = N'MyDatabaseName';
También he notado que el estado de duplicación de mi base de datos principal está Suspendido, e intentar reanudarlo inmediatamente falla con el siguiente error:
El socio de duplicación remota para la base de datos 'MyDatabaseName' encontró el error 5149, estado 1, gravedad 25. La duplicación de la base de datos se ha suspendido. Resuelva el error en el servidor remoto y reanude la duplicación, o elimine la duplicación y restablezca la instancia del servidor duplicado.
Los registros de error en el servidor espejo también contienen este error, pero también contienen errores acerca de que la unidad del archivo de registro está llena
MODIFICAR ARCHIVO encontró el error 112 del sistema operativo (No hay suficiente espacio en el disco) al intentar expandir el archivo físico.
y
F: \ Databaselogs \ MyDatabaseName_1.ldf: Error del sistema operativo 112 (No hay suficiente espacio en el disco).
El servidor principal tiene 60 GB en la unidad de archivo de registro (hay otras bases de datos alojadas aquí), mientras que el servidor duplicado solo tiene 45 GB.
Hacer una copia de seguridad del archivo de registro hizo que la base de datos se pueda volver a usar, sin embargo, también quiero disminuir el tamaño del archivo de registro físico en el disco y reanudar la duplicación.
¿Cómo puedo reducir el tamaño de mi archivo de registro de transacciones físicas sin comprometer la duplicación o la cadena de respaldo?
Estoy ejecutando SQL Server 2005
Respuestas:
Por lo que puedo decir, no puedo.
Creo que gran parte del archivo de registro está esperando ser reflejado en el servidor espejo, pero el espejo está inactivo y no se puede reanudar porque el registro de transacciones reflejado también ha crecido para ocupar todo el espacio en el disco.
Esta teoría está respaldada por el hecho de que una vez que elimino la duplicación, el
DBCC SHRINKFILEcomando reduce correctamente el archivo de registro físico ylog_reuse_wait_descvuelve a esperarLOG_BACKUPNo puedo reducir el archivo de registro en el servidor reflejado porque actúa como un espejo y no se puede abrir, por lo que creo que el espejo es irrecuperable.
Así que voy a eliminar el espejo por completo y configurar todo de nuevo (proceso muy lento con una base de datos de 300 GB). Y esta vez, me aseguraré de que el tamaño del registro de transacciones sea bastante pequeño antes de iniciar el espejo, y que las copias de seguridad del registro de transacciones se estén ejecutando una vez que el espejo vuelva a funcionar.
También voy a establecer un límite sobre qué tan grande puede crecer el registro de transacciones en el servidor de producción, para que el espejo nunca intente aumentar su registro de transacciones más allá del tamaño disponible en el disco.
fuente
Encontré el mismo problema hoy con nuestros DB, que por alguna razón habían dejado de hacer copias de seguridad de los registros de transacciones durante los últimos 3 meses y los registros habían aumentado a 200 GB.
Exactamente los mismos códigos de error que en su situación y la duplicación no se reanudaría. La unidad de registro estaba completamente llena en el espejo.
Afortunadamente, pude liberar algo de espacio eliminando un par de registros antiguos perdidos en la unidad de registro. Después de eso, pude reanudar la duplicación.
Luego entró en las copias de seguridad del plan de mantenimiento y activó las copias de seguridad de la base de datos y el registro de transacciones manualmente. Incluso después de la copia de seguridad, los archivos de registro de transacciones seguían siendo enormes. Así que tuve que decirle repetidamente a SQL Studio que redujera los archivos de registro (liberar cualquier espacio no utilizado), y después de algunos intentos durante un par de horas, los redujo a un tamaño más manejable.
Espero que esto ayude.
fuente