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 .
