Ora legale

Nel mio ambiente, ci sono server in esecuzione su backup nativo e piani di Ola Hallengren. I nostri server sono una combinazione di 2008, 2012 e 2014. Tutti i backup completi vengono eseguiti alle 12:00 e i backup dei log vengono eseguiti ogni 15 minuti.

Non ho mai tenuto conto dell'ora legale prima, quindi per favore dimmi quali aggiustamenti dovrei fare.

Verranno interessati i backup completi delle 12:00 e cosa succede ai backup dei log?

L'esperto di SQL Server Paul Randal affronta proprio questo argomento in In che modo l'ora legale influisce sul ripristino di emergenza? . È un post relativamente breve, quindi lo sto citando nella sua interezza. Dato che eri preoccupato per i tuoi backup del registro delle transazioni, ho anche messo in evidenza un po 'di post per attirare la tua attenzione.

È risaputo che SQL Server gestisce correttamente l'ora legale (DST), quindi perché dovresti preoccupartene?

Bene, non è una conoscenza così comune che alla fine dell'ora legale quando l'orologio torna indietro di un'ora (sempre alle 02:00 negli Stati Uniti), SQL Agent si interrompe sostanzialmente per un'ora (almeno in SS2000 in poi). Ciò significa che se hai un lavoro che fa qualcosa ogni 15 minuti, ci sarà un intervallo di 75 minuti tra l'esecuzione del lavoro alle 01:45 e l'esecuzione del lavoro alle 02:00. Ciò accade perché alle 02:00, l'orario è tornato alle 01:00, ma il tempo di esecuzione successivo di tutti i lavori rimane lo stesso, quindi il lavoro non può essere eseguito fino al prossimo orario programmato delle 02:00. Quindi, nell'emisfero nord ogni autunno e nell'emisfero sud ogni primavera, perdi un'ora di lavoro di SQL Agent. Tuttavia, perché dovresti preoccupartene?

Bene, dipende da quali lavori vengono ritardati di un'ora. Se si dispone di un lavoro che esegue un backup del registro ogni 15 minuti, il giorno in cui termina l' ora legale , tra i backup del registro esiste effettivamente un intervallo di 75 minuti. Se hai un Accordo sul livello di servizio (SLA) che limita la quantità massima di lavoro perso a 15 minuti in caso di catastrofe, per quei 75 minuti sei esposto a potenzialmente non essere in grado di soddisfare tale SLA!

Potrebbe essere un grosso problema, soprattutto se qualcosa va storto durante quell'ora (non più o meno probabile che qualcosa vada storto in qualsiasi altro momento, ma ancora possibile). In tal caso, devi trovare una soluzione alternativa. Un paio di modi per aggirare il problema che mi viene in mente:

• Chiedi a qualcuno di rimanere sveglio fino a tardi durante quell'ora e fare backup manuali del registro.
• Passa al mirroring del database, che trasmette continuamente il registro al server ridondante e quindi non è interessato dal problema dell'ora legale.

Entrambe sono soluzioni praticabili, ma penso che la migliore sia creare un processo SQL Agent in esecuzione alle 01:59 e creare processi di backup aggiuntivi da eseguire alle 01:00, 01:15, 01:30 e 01:45. Non vedo perché questo non dovrebbe essere possibile. Alle 10:36 di questa mattina ho creato un semplice lavoro agente per stampare la data su un file e impostarlo per l'esecuzione alle 09:40 - in passato. Quindi ho impostato l'ora di sistema indietro di un'ora e il lavoro è stato eseguito perfettamente. L'unico aspetto negativo di questa soluzione è che è necessario creare e pianificare i lavori extra utilizzando gli SP agente T-SQL incorporati nei passaggi del lavoro per il lavoro 01:59 - noioso ma non difficile. Forse qualcuno potrebbe inviarmi uno script e lo blog come follow-on?

Quindi, con l'ora legale che termina il 4 novembre, questo è sicuramente qualcosa di cui dovresti essere consapevole anche se non vuoi preoccuparti di affrontare l'esposizione dell'ora in più. A parte questo, le date di inizio e fine dell'ora legale sono cambiate quest'anno. L'articolo della KB 931975 illustra quali parti di SQL Server non sono a conoscenza delle date modificate e cosa è possibile fare al riguardo.