Horario de verano

En mi entorno, hay servidores que se ejecutan en copias de seguridad nativas y planes de Ola Hallengren. Nuestros servidores son una combinación de 2008, 2012 y 2014. Todas las copias de seguridad completas se toman a las 12 a.m. y las copias de seguridad de registros se toman cada 15 minutos.

Nunca antes había contabilizado el horario de verano, así que dígame qué ajustes debo hacer.

¿Se verán afectadas las copias de seguridad completas de las 12 a.m. y qué sucede con las copias de seguridad del registro?

El experto en SQL Server Paul Randal aborda este mismo tema en ¿Cómo afecta el horario de verano a la recuperación ante desastres? . Es una publicación relativamente corta, así que la estoy citando en su totalidad. Como estaba preocupado por las copias de seguridad del registro de transacciones, también destaqué un poco de la publicación para llamar su atención.

Es de conocimiento común que SQL Server hace frente al horario de verano (DST) correctamente, ¿por qué debería importarle?

Bueno, no es un conocimiento tan común que al final del horario de verano cuando los relojes retroceden una hora (siempre a las 02:00 en los EE. UU.), El Agente SQL esencialmente se detiene durante una hora (al menos en SS2000 en adelante). Esto significa que si tiene un trabajo que hace algo cada 15 minutos, habrá un espacio de 75 minutos entre la ejecución del trabajo a las 01:45 y la ejecución del trabajo a las 02:00. Esto sucede porque a las 02:00, la hora se vuelve a establecer a la 01:00 pero el siguiente tiempo de ejecución de todos los trabajos sigue siendo el mismo, por lo que su trabajo no puede ejecutarse hasta la próxima hora programada de 02:00. Entonces, en el hemisferio norte cada otoño, y en el hemisferio sur cada primavera, pierdes una hora de trabajos de Agente SQL. Aún así, ¿por qué debería importarte?

Bueno, depende de cuáles sean los trabajos que se retrasan una hora. Si tiene un trabajo que realiza una copia de seguridad de registro cada 15 minutos, el día en que finaliza el horario de verano , en realidad hay un espacio de 75 minutos entre las copias de seguridad de registro. Si tiene un Acuerdo de Nivel de Servicio (SLA) que limita la cantidad máxima de trabajo perdido a 15 minutos en caso de desastre, ¡entonces durante esos 75 minutos está expuesto a no poder cumplir ese SLA!

Eso podría ser un gran problema, especialmente si algo sale mal durante esa hora (no es más o menos probable que algo salga mal en cualquier otro momento, pero aún es posible). En ese caso, debe encontrar una solución alternativa. Se me ocurren algunas maneras de solucionar el problema:

• Haga que alguien se quede despierto hasta tarde durante esa hora y realice copias de seguridad de registros manuales.
• Cambie a la creación de reflejo de la base de datos, que transmite continuamente el registro al servidor redundante y, por lo tanto, no se ve afectado el problema del horario de verano.

Ambas son soluciones viables, pero creo que la mejor es crear un trabajo de Agente SQL que se ejecute a las 01:59 y cree trabajos de copia de seguridad adicionales para ejecutar a las 01:00, 01:15, 01:30 y 01:45. No veo por qué esto no debería ser posible. A las 10:36 de esta mañana, creé un trabajo de agente simple para imprimir la fecha en un archivo y configurarlo para que se ejecute a las 09:40, en el pasado. Luego configuré el tiempo de mi sistema una hora y el trabajo se ejecutó perfectamente. El único inconveniente de esta solución es que necesita crear y programar los trabajos adicionales utilizando los SP del Agente T-SQL integrados en los pasos del trabajo para su trabajo 01:59, tedioso pero no difícil. ¿Tal vez alguien podría enviarme un guión y lo bloguearé como seguimiento?

Entonces, con la finalización del horario de verano el 4 de noviembre, definitivamente es algo que debe tener en cuenta, incluso si no quiere tomarse la molestia de lidiar con la exposición de la hora extra. Como comentario aparte, las fechas en que comienza y termina el horario de verano cambiaron este año. El artículo 931975 de KB analiza qué partes de SQL Server no conocen las fechas cambiadas y qué puede hacer al respecto.