web-dev-qa-db-ja.com

夏時間

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

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

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

9
SqlNovice

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

SQL Serverが夏時間(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のどの部分が変更された日付を認識していないか、およびそれに対して何ができるかについて説明しています。

12
Scott Hodgin