Establecer manualmente el tamaño del archivo de registro después de reducir SQL Server 2008 R2

Me estoy convirtiendo en un DBA algo involuntario en el trabajo en ese momento y realmente necesito ayuda en algo.

Tenemos una base de datos de 40 GB en modo de recuperación completa, sin respaldo de registro configurado y un gran archivo de registro de 84 GB. Mi plan hasta ahora para salvar esta situación es ejecutar una copia de seguridad de registro completa en la base de datos, reducir el archivo de registro e instigar un plan de mantenimiento para ejecutar una copia de seguridad de registro todas las noches con la copia de seguridad de la base de datos para ayudar a mantenerla bajo control.

Mi problema es que no quiero que el archivo de registro se reduzca a nada y pase la primera mañana del lunes en constante crecimiento. Tengo una estimación aproximada de lo que debería ser el archivo (aproximadamente el 20% de la base de datos) y me gustaría configurarlo desde el principio para garantizar la mayor cantidad de espacio contiguo posible. ¿Es solo un caso de cambiar el "Tamaño inicial" en Propiedades de la base de datos -> Archivos? ¿Supongo también que la base de datos necesitaría estar fuera de línea para que esto ocurra?

Gracias por adelantado

Simplemente reduzca a lo que cree que es el tamaño óptimo. No use la interfaz de usuario, solo haga esto, digamos que 200 MB es su tamaño óptimo:

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

Si solo está interesado en hacer una copia de seguridad del registro una vez al día, y no está interesado en la recuperación en un punto en el tiempo, entonces debe cambiar al modelo de recuperación simple. Esto significará que las copias de seguridad del registro son innecesarias (de hecho imposibles), pero el contenido del registro se autogestionará.

Si desea que las copias de seguridad de registros sean significativas, no planee realizar una copia de seguridad completa por la noche y luego una única copia de seguridad de registro inmediatamente después. Esto lo mantiene en el modelo de recuperación completa, hace que el registro trabaje realmente duro y no le compra nada. Entonces, si desea una recuperación en un punto en el tiempo, ejecute copias de seguridad de registros con mayor frecuencia a una velocidad que satisfaga su tolerancia a la pérdida de datos. Si no desea perder más de 15 minutos de datos, ejecute una copia de seguridad de registro cada 15 minutos.

Su gestión de archivos puede ser una operación completamente en línea. Tiene dos rutas, dependiendo de su necesidad de retener su información de registro para fines de recuperación:

No es necesario recuperar el punto en el tiempo

1. Convierta la base de datos a SIMPLErecuperación. Ejecute un punto de control para escribir transacciones en el disco.
2. Acoplar el registro.
3. Cambie el tamaño del registro al tamaño apropiado.

También recomiendo establecer una cantidad de crecimiento fija y un crecimiento ilimitado (para ayudar a administrar mejor su registro). Tenga en cuenta que la cantidad de crecimiento fijo es muy dependiente, recomiendo ir con 1-2 GB inicialmente dependiendo de cuánto crecimiento pueda esperar ese registro. Idealmente, su registro no crecerá mucho, por lo que esto no debería tener un gran impacto. Si su registro crece regularmente, es posible que deba revisar su tamaño.

Logrado usando:

ALTER DATABASE [foo] 
SET RECOVERY SIMPLE;

CHECKPOINT;

DBCC SHRINKFILE (foo_log,0);

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

--Optional if you want the database in full recovery mode 
--for point in time recovery going forward
ALTER DATABASE [foo] 
SET RECOVERY FULL;

Punto de recuperación de tiempo necesario

El mayor problema será que no puede reducir su archivo de registro más allá de su segmento VLF actualmente activo. Para ver esto, puede usarlo DBCC LOGINFOen el contexto de la base de datos. Cualquier segmento con un Estado = 2 está activo. Para borrar segmentos activos, deberá ejecutar una copia de seguridad del registro de transacciones cuando no haya transacciones activas en ese segmento. Tus pasos son:

1. Ejecute una copia de seguridad del registro de transacciones.
2. Reduce tu archivo. (Idealmente, aplanar, pero si su base de datos está activa, será difícil hacerlo).
3. Repita los pasos 1 y 2 hasta que su registro tenga el tamaño adecuado, idealmente lo más pequeño posible.
4. Cambie el tamaño del registro al tamaño apropiado.

Logrado usando:

BACKUP LOG [foo] TO DISK='<Location of t-log backup>';

DBCC SHRINKFILE (foo_log,0);

--Repeat the above until your log file is small "enough"

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

Algunos recursos adicionales para comprender lo que está sucediendo aquí:

• Modelos de recuperación de SQL Server

• Recomendaciones de t-log de Kimberly Tripp

• Puntos de control de la base de datos

En realidad no, la base de datos no necesita estar fuera de línea para reducir el registro. Y diré que este es probablemente uno de los pocos casos en los que reducir el registro es una buena idea. Puede establecer el tamaño inicial, pero sería más fácil hacer el encogimiento y decirle que se reduzca a un tamaño específico.

USE [DBName]
GO
DBCC SHRINKFILE (N'LogName' , SizeInMg)
GO

También puede hacerlo utilizando la GUI y el segundo botón de opción y la casilla de verificación que dice qué tan grande desea que sea el registro al final. Puede acceder a la GUI haciendo clic derecho en la base de datos en el explorador de objetos en SSMS, seleccionando tareas, reducir, archivos.

Como complemento de la respuesta de Aaron sobre el modo simple , puede programar 2 (o más) copias de seguridad diferenciales por día, reduciendo así la ventana de pérdida de datos de la operación de su base de datos mientras mantiene el modo SIMPLE.