Horário de verão

No meu ambiente, existem servidores em execução no backup nativo e nos planos Ola Hallengren. Nossos servidores são uma combinação de 2008, 2012 e 2014. Todos os backups completos são realizados às 12h e os backups de log a cada 15 minutos.

Eu nunca tinha considerado o horário de verão antes, então, por favor, diga-me quais os ajustes que devo fazer.

Os backups completos das 12h serão afetados e o que acontece com os backups de log?

Paul Randal, especialista em SQL Server, aborda esse tópico em Como o horário de verão afeta a recuperação de desastres? . É um post relativamente curto, por isso estou citando-o na íntegra. Como você estava preocupado com os backups do log de transações, também destaquei um pouco da postagem para chamar sua atenção.

É do conhecimento geral que o SQL Server lida com o horário de verão (DST) corretamente. Por que você deveria se importar?

Bem, não é de conhecimento geral que, no final do horário de verão, quando os relógios retornam uma hora (sempre às 02:00 nos EUA), o SQL Agent faz uma pausa essencialmente por uma hora (pelo menos no SS2000 em diante). Isso significa que, se você tem um trabalho que está fazendo algo a cada 15 minutos, haverá um intervalo de 75 minutos entre a execução do trabalho às 01:45 e a execução às 02:00. Isso acontece porque às 02:00, o horário é definido como 01:00, mas o próximo tempo de execução de todos os trabalhos permanece o mesmo - portanto, seu trabalho não pode ser executado até a próxima hora agendada das 02:00. Portanto, no hemisfério norte todo outono e no hemisfério sul toda primavera, você perde uma hora em empregos do SQL Agent. Ainda assim, por que você deveria se importar?

Bem, depende de quais são os trabalhos que atrasam uma hora. Se você tem um trabalho que faz um backup de log a cada 15 minutos e, no dia em que o horário de verão termina, há um intervalo de 75 minutos entre os backups de log. Se você possui um SLA (Service Level Agreement) que limita a quantidade máxima de trabalho perdido a 15 minutos no caso de um desastre, nesses 75 minutos você estará exposto a potencialmente não conseguir cumprir esse SLA!

Isso pode ser um grande problema, especialmente se algo der errado durante essa hora (não mais ou menos provável do que algo der errado em qualquer outro momento, mas ainda possível). Nesse caso, você precisa encontrar uma solução alternativa. Em algumas maneiras de contornar o problema, posso pensar em:

• Peça que alguém fique acordado até tarde durante essa hora e faça backups de log manuais.
• Alterne para o espelhamento de banco de dados, que transmite continuamente o log para o servidor redundante e, portanto, não afeta o problema do horário de verão.

Ambas são soluções viáveis, mas acho que a melhor é criar uma tarefa do SQL Agent executada às 01:59 e criar tarefas extras de backup para as 01:00, 01:15, 01:30 e 01:45. Não vejo por que isso não deveria ser possível. Às 10:36 desta manhã, criei um trabalho simples de agente para imprimir a data em um arquivo e configurá-lo para ser executado às 09:40 - no passado. Em seguida, defino o horário do sistema para uma hora e o trabalho é executado perfeitamente. A única desvantagem dessa solução é que você precisa criar e agendar tarefas extras usando os T-SQL Agent SPs incorporados nas etapas da tarefa 01:59 - tediosa, mas não difícil. Talvez alguém possa me enviar um script e eu o publique como uma continuação?

Portanto, com o horário de verão terminando em 4 de novembro, isso é definitivamente algo para você estar ciente, mesmo que não queira se dar ao trabalho de lidar com a exposição de uma hora extra. Como um aparte - as datas em que o horário de verão começa e termina mudam este ano. O artigo 931975 da Base de Dados de Conhecimento discute quais partes do SQL Server não estão cientes das datas alteradas e o que você pode fazer sobre isso.