夏時間


9

私の環境では、ネイティブバックアップで実行されているサーバーとOla Hallengren計画があります。当社のサーバーは、2008、2012、2014の組み合わせです。すべての完全バックアップは午前12時に行われ、ログバックアップは15分ごとに行われます。

これまでに夏時間を考慮したことがないので、どのような調整を行うべきか教えてください。

午前12時のフルバックアップは影響を受け、ログバックアップはどうなりますか?


6
率直に言って、サーバーをUTCで実行します。
アーロンバートランド

残念ながらCSTです
SqlNovice

1
確かですが、公平に言うと、マザーボードにハードコーディングされていません。
アーロンバートランド

回答:


12

SQL ServerのエキスパートであるPaul Randal は、夏時間が障害回復どのように影響するかというこのトピックに対処しています。。比較的短い投稿なので、全体を引用します。トランザクションログのバックアップについて心配していたので、あなたの注意を引くために、投稿の一部を強調しました。

SQL Serverが夏時間(DST)に正しく対応しているのは常識ですが、なぜ気にする必要があるのでしょうか。

まあ、それほど一般的ではありませんが、DSTの終わりに時計が1時間戻ると(常に米国では02:00に)、SQLエージェントは基本的に1時間(少なくともSS2000以降)一時停止します。つまり、15分ごとに何かを実行しているジョブがある場合、01:45のジョブ実行と02:00のジョブ実行の間には75分のギャップが生じます。これは、02:00に時刻が01:00に戻されても、すべてのジョブの次回の実行時間は同じであるため、次の予定時刻である02:00までジョブを実行できないためです。したがって、毎年秋に北半球で、そして毎年春に南半球で、1時間分のSQLエージェントジョブを失います。それでも、なぜ気にする必要がありますか?

まあ、それは1時間遅れる仕事が何であるかに依存します。15分ごとにログバックアップを実行 するジョブがある 場合、DSTが終了する日に、ログバックアップの間に実際には75分のギャップがあります。あなたがいる場合 の最大量制限サービスレベル契約(SLA)は 、災害が発生した場合に15分に失われた作品を、それらの75のために 分あなたは、潜在的にそのSLAを満たすことができないにさらされています!

これは、特にその時間内に何か問題が発生した場合は、かなり大きな問題になる可能性があります(他の時間に問題が発生した場合と同じかそれより少ない可能性がありますが、それでも可能です)。その場合、代替ソリューションを考え出す必要があります。私が考えることができる問題を回避するためのいくつかの方法:

  • その時間の間に誰かが夜更かしをして、手動でログのバックアップを取ってもらいます。
  • データベースミラーリングに切り替えます。これにより、ログが継続的に冗長サーバーにストリーミングされるため、DSTの問題には影響しません。

これらはどちらも実行可能なソリューションですが、最良の解決策は、01:59に実行するSQLエージェントジョブを作成し、01:00、01:15、01:30、01:45に実行する追加のバックアップジョブを作成することです。これが不可能であるべき理由がわかりません。今朝の10:36に、日付をファイルに出力し、09:40-過去に実行するように設定する簡単なエージェントジョブを作成しました。次に、システム時間を1時間戻し、ジョブは完全に実行されました。このソリューションの唯一の欠点は、01:59ジョブのジョブステップに埋め込まれたT-SQLエージェントSPを使用して追加のジョブを作成およびスケジュールする必要があることです。多分誰かが私にスクリプトを送ってくれるかもしれません、そして私はそれを後続としてブログに書きますか?

したがって、DSTが11月4日に終了するので、余計な時間の露出に対処する手間をかけたくない場合でも、これは間違いなくあなたが知っておくべきことです。余談ですが、DSTの開始日と終了日は今年変更されました。KB記事931975は、SQL Serverのどの部分が変更された日付を認識していないか、およびそれに対して何ができるかについて説明しています。


したがって、75分間データが失われる可能性があることがわかりました...それでよければ、設定を変更する必要があります。そのままにしておくことができます
SqlNovice

次の定期的にスケジュールされたログバックアップまで75分を失う可能性があれば、変更する必要はないと思います。
Scott Hodgin 2017年

さらに、私が心配しているサーバーは常時稼働している可用性グループなので、何か問題が発生した場合に切り替えることができると思います。
SqlNovice 2017年

@SqlNoviceは、可用性グループが同じイベントの影響を受けない2つのサーバー上にあり、すべてのイベントが他のインスタンスにコミットされていることを前提としています= True。当然のことながら、もっと安全だと思っているかもしれません。PSサーバーは可用性グループになく、データベースはあります。(つまり、「私が心配しているサーバーは常時稼働している可用性グループです)
James Jenkins

申し訳ありませんが、可用性グループ内のデータベースは、1つのレプリカがSynモードで、もう1つがAsynモードです
SqlNovice '30 / 10/30
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.