Mantenimiento del registro de transacciones al cambiar a Recuperación simple

Antecedentes:

Recientemente heredé más de 50 servidores SQL con más de 450 bases de datos. Las copias de seguridad nocturnas son de aproximadamente 8 TB y, no hace falta decir que estamos usando más espacio en disco del que quisiéramos. Todas las bases de datos están configuradas en recuperación COMPLETA y los registros de transacciones nunca han sido respaldados. Revisé todos los servidores SQL e identifiqué los de baja prioridad que solo necesitan una copia de seguridad nocturna y un día en que sea aceptable un día de pérdida de datos.

Pregunta:

Estoy cambiando muchas bases de datos de baja prioridad al SIMPLEmodo de recuperación FULL. ¿Los registros de transacciones existentes se truncarán (cuando se creen puntos de control)? Algunos de los registros de transacciones existentes son de 50-100 GB; ¿Cuál es el mejor enfoque para determinar a qué debo reducirlos para avanzar? Obviamente no quiero mantenerlos tan grandes. O, ¿se reducirán solos con el tiempo (no creo que lo hagan)?

Antes de cambiar FULLal SIMPLEmodelo de recuperación, pregúntese cuántos datos puede permitirse perder. Para las bases de datos donde, en caso de desastre, está bien restaurar la última copia de seguridad de la base de datos, SIMPLEdebería estar bien. Si este no es el caso, quédese con FULL.

Para reducir el LDFarchivo al tamaño más pequeño posible, siga los pasos dados por Kimberly Tripp aquí: 8 pasos para mejorar el rendimiento del registro de transacciones

1. Espere el momento en que haya poca actividad en la base de datos

2. Ejecutar en SSMS:

   DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)

3. Modifique el tamaño del archivo de registro de transacciones:

   ALTER DATABASE db_name
   MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)

Estoy cambiando muchas bases de datos al modo de recuperación SIMPLE desde el modo de recuperación COMPLETO (T-Logs y la recuperación en un punto en el tiempo no son necesarias). ¿Los registros de transacciones existentes se truncarán (cuando se creen puntos de control)?

En el modelo de recuperación simple, el motor de la base de datos emitirá puntos de control automáticos y su frecuencia está determinada por el intervalo de recuperación (configuración avanzada del servidor) o si el registro se llena al 70%.

A menos que tenga algunas transacciones de larga duración que retrasen el truncamiento del registro, un punto de control automático truncará la parte no utilizada del T-log.

Algunos de los registros de transacciones existentes son de 50-100 GB, ¿cuál es el mejor enfoque para determinar a qué debo reducirlos para avanzar? Obviamente no quiero mantenerlos tan grandes.

Si tiene el modelo de recuperación de la base de datos configurado en COMPLETO para aquellas bases de datos con 50-100 GB de registros T, entonces debe comenzar a hacer copias de seguridad frecuentes de registros T. Recuerde que en el modelo de recuperación completa, una vez que se ha establecido una cadena de respaldo de registro, incluso los puntos de control automáticos no harán que el registro se trunque.

Como último recurso, puede truncar el archivo de registro e inmediatamente realizar una copia de seguridad completa y luego comenzar a realizar copias de seguridad de T-log para que pueda realizar una recuperación en un punto en el tiempo si ocurre un desastre.

O, ¿se reducirán solos con el tiempo (no creo que lo hagan)?

Como señaló @TomTom, es una operación manual.

Leer :

• Administrar el tamaño del archivo de registro de transacciones
• CÓMO REDUCIR EL REGISTRO DEL SERVIDOR SQL : excelente redacción.
• ¿Cómo funcionan los puntos de control y qué se registra? - Por: Paul Randal

Muchas de las preguntas no pueden ser respondidas por nosotros. ¿Que tan larga es una pieza de cordon?

Algunos de los registros de transacciones existentes son de 50-100 GB, ¿cuál es el mejor enfoque para determinar a qué debo reducirlos para avanzar?

Mientras tengan que serlo. Sugiero NO encogerse. Truncar los registros, volver en una semana y ver cuánto espacio se usa, ENTONCES decidir. Pero TIENES que responder a esta.

Las copias de seguridad nocturnas son de aproximadamente 8 TB y no hace falta decir que estamos usando más espacio en disco del que quisiéramos.

Entonces, ¿por qué convertirlos en simples? Es enserio.

Todas las bases de datos están configuradas en recuperación COMPLETA y los registros de transacciones nunca han sido respaldados.

Un poco de lógica le dirá que si los trunca UNA VEZ, entonces probablemente usará MUCHO menos espacio para hacer una copia de seguridad de todos modos. El resultado puede ser que puede mantenerlos en modo de recuperación completa. Prueba eso primero. Si se recuperan son de bajo volumen, etc., las copias de seguridad del registro serán MUCHO más pequeñas en el futuro.

Revisé todos los servidores SQL e identifiqué los de BAJA prioridad que solo necesitan una copia de seguridad nocturna y un día de pérdida de datos en caso de desastre no será un problema (bases de datos de fax y cosas así).

Si. Eso es hasta que termines en la corte y te den el culo por no tener documentos legales críticos. ¿Sabe que los registros de fax pueden ser parte de lo que debe mantener durante años como información comercial relevante? Es así en mi jurisdicción (10 años). Si usted es una compañía de acciones de U, puede haber una sorpresa similar (SOX). No hacerlo lo hace MUY malo en la corte si quiere probar que no recibió un fax. O envió uno. A nadie le importa si esto sucedió mensualmente y si tiene registros más recientes: no cumple con los requisitos de la ley. Asegúrate de que alguien MUY alto firme esto, porque tu negocio no crítico puede ser tu motivo de despido.

O, ¿se reducirán solos con el tiempo (no creo que lo hagan)?

No. Y no deberían hacer eso. El cambio de tamaño del registro es una operación manual, excepto para bases de datos de bajo volumen.