2005 年 8 月、米国議会は、夏時間 (DST) の開始日と終了日を変更する「2005 年エネルギー政策法」を可決しました。2007 年にこの法律が施行されると、DST は従来より 3 週間早く始まり、1 週間遅く終了します。具体的には、3 月の第 2 日曜日午前 2:00 に始まり、11 月の第 1 日曜日午前 2:00 に終了します。
次の表は、2007 年の夏時間変更についてまとめたものです。
元に戻す全体を表示する
|
従来の DST 開始日
|
2007 年の DST 開始日
|
従来の DST 終了日
|
2007 年の DST 終了日
|
|---|
|
4 月の第 1 日曜日
|
3 月の第 2 日曜日
|
10 月の最終日曜日
|
11 月の第 1 日曜日
|
|
2007 年 4 月 1 日
|
2007 年 3 月 11 日
|
2007 年 10 月 28 日
|
2007 年 11 月 4 日
|
この資料では、2007 年の夏時間変更に対する準備を Microsoft SQL Server 2005 および Microsoft SQL Server 2000 で行う方法について説明します。
必要な作業
自動的に夏時間の調整をするように構成されているコンピュータに SQL Server がインストールされていて、コンピュータで設定されているタイム ゾーンが 2007 年の DST 変更の影響を受ける場合は、次の作業を行う必要があります。
-
「サポート技術情報」 (Microsoft Knowledge Base) の資料 924840 に記載されている、Windows 用の更新プログラムをインストールします。
関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
924840?
(http://support.microsoft.com/kb/924840/
)
Windows 用の 2007 年グローバル タイム ゾーン更新プログラムのテスト版について
-
コンピュータに SQL Server Notification Services がインストールされている場合は、「サポート技術情報」 (Microsoft Knowledge Base) の資料 931815 に記載されている更新プログラムをインストールします。
関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
931815?
(http://support.microsoft.com/kb/931815/
)
SQL Server 2005 Notification Services および SQL Server 2000 Notification Services 用の 2007 年タイム ゾーン更新プログラム
-
SQL Server には、正常に実行されるようにするためにインストールする必要がある特定の更新プログラムはありません。ただし、オペレーティング システムは更新する必要があります。また、SQL Server と相互運用している製品およびアプリケーションも更新する必要があります。これらの製品およびアプリケーションには、Notification Services、Windows SharePoint Services、Microsoft CRM などがあります。その他のマイクロソフト製品に適用する必要のある更新プログラムの一覧については、次のマイクロソフト Web サイトを参照してください。
SQL Server における時刻の使用方法とレポートの作成
SQL Server 2005 および SQL Server 2000 では、次の 2 つのタイマ形式を使用して、SQL Server データベース エンジンにより時刻情報が生成されます。
高分解能タイマでは、タイマの分解能は CPU の RDTSC (Read Time-Stamp Counter) 命令に基づいています。低分解能タイマでは、タイマの分解能は Microsoft Windows API の GetTickCount 関数に基づいています。
タイマ ベースのさまざまなバックグラウンド タスクや重要なシステム コンポーネントは、正しく機能するためにこれらのタイマに依存しています。これらのタイマは特定の時刻からの相対的な時間として機能しているため、内部コンポーネントや内部操作は 2007 年の DST 変更による影響を受けません。
たとえば、次のタイマ ベースの操作またはコンポーネントを含むタスクを実行します。
-
Lazy Writer、Lock Monitor、Scheduler Monitor などのシステム コンポーネント
-
ゴースト クリーンアップや自動圧縮などのバックグラウンド タスク
-
ロックやラッチなどのタイムアウト ベースのリソース
-
SQL Server エージェントのジョブやメンテナンス プランなどの定期的な操作
-
WAITFOR ステートメントなどのシステム ステートメント
SQL Server では、外部コンポーネントおよび外部アプリケーションで使用できる時刻情報も生成されます。この時刻情報は Windows オペレーティング システムから取得されます。そのため、オペレーティング システムから正しい時刻の値が返される限り、正確な時刻情報が生成されます。
たとえば、次の外部コンポーネントおよび外部アプリケーションを含むタスクを実行します。
-
さまざまなイベントの Start Time 列、End Time 列、Duration 列などの SQL Server Profiler または SQL Profiler のイベント列
-
SQL Server エラー ログ、イベント ログ、システム テーブルなどのさまざまなログでレポートされる時刻情報
-
GetDate 関数、GetUtcDate 関数などのシステム関数
次の場合について検討します。SQL Server プロファイラまたは SQL プロファイラを使用して SQL Server のトレースを作成します。トレースには 2007 年 3 月の DST 時刻の変更前に開始され、2007 年 3 月の DST 時刻の変更後に終了されるクエリが記録されます。この場合、時刻情報は正確で、DST 変更による影響はありません。
トレース出力の例を次に示します。
EventSequence EventClass TextData StartTime EndTime Duration
156 Sql:StmtStarting Select * From Table1 2007-03-11 01:59:57.187
157 Sql:StmtCompleted Select * From Table1 2007-03-11 01:59:57.187 2007-03-11 03:00:07.187 9987
同様に、2007 年 11 月の DST 時刻の変更期間中のクエリを記録するトレース出力の例を次に示します
EventSequence EventClass TextData StartTime EndTime Duration
178 Sql:StmtStarting Select * From Table1 2007-11-04 01:59:54.967
179 Sql:StmtCompleted Select * From Table1 2007-11-04 01:59:54.967 2007-11-04 01:00:05.030 10055
2007 年の DST 変更に固有の問題ではない、DST 関連の SQL Server に関する既知の問題
DateDiff および DateAdd 日時関数が DST に対応していない
Transact-SQL ステートメントを使用して、システムで提供されている日時関数に基づいて時間を計算する場合、ステートメントに注意を払う必要があります。特に、アプリケーションのロジックで DST 時刻をハード コーディングしている場合、DateDiff システム関数および DateAdd システム関数は DST に対応しません。
たとえば、アプリケーションで次のステートメントを実行して時差を計算します。計算は従来の DST 時刻を基に行われます。2007 年の新しい DST システムでは 2007 年 3 月 11 日が DST の開始日ですが、従来の DST システムでは 2007 年 4 月 1 日が DST の開始日であることに注意してください。
DECLARE @starttime datetime
DECLARE @endtime datetime
SELECT @starttime = GetDate() -- returns '2007-03-11 1:59:50.000'
WAITFOR DELAY '00:00:30'
SELECT @endtime = GetDate() ?- returns '2007-03-11 3:00:20.000'
If @starttime < '2007-04-01 3:00:00.000' And
@endtime > '2007-04-01 1:59:59.000'
SELECT (cast((DATEDIFF(s, @starttime, @endtime)) as int) - 3600) AS TimeDiffInSecs
Else
SELECT cast((DATEDIFF(s, @starttime, @endtime)) as int) AS TimeDiffInSecs
Go
ステートメントを実行すると、次の結果が表示されます。
TimeDiffInSecs
--------------
3,630
DateDiff システム関数は DST に対応していないため、このステートメントは、30 秒ではなく 3,630 秒を返します。
このような場合に時間の計算を修正するには、GetDate 関数ではなく GetUtcDate 関数を使用します。GetUtcDate 関数は正しい UTC 時刻を返します。現在の UTC 時刻は、現在のローカル時刻、および SQL Server が実行されているコンピュータのオペレーティング システムでのタイム ゾーンから算出されます。
正しく動作するように修正したステートメントを次に示します。
/*-------------------------------------------------------
GetDate() GetUtcDate()
datetime 2007-03-11 1:59:50.000 2007-03-11 09:59:50.000
datetime 2007-03-11 3:00:20.000 2007-03-11 10:00:20.000
-------------------------------------------------------*/
DECLARE @starttime datetime
DECLARE @endtime datetime
SELECT @starttime = GetUtcDate() -- returns '2007-03-11 9:59:50.000'
WAITFOR DELAY '00:00:30'
SELECT @endtime = GetUtcDate() ?- returns '2007-03-11 10:00:20.000'
SELECT DATEDIFF (s, @starttime, @endtime) AS TimeDiffInSecs
Go
ステートメントを実行すると、次のように、正しい結果が表示されます。
TimeDiffInSecs
--------------
30
SQL Server エージェントの定期的なジョブに対する DST 終了日の影響
次の場合について検討します。現在のローカル時刻を印刷する、SQL Server エージェントの定期的なジョブがあります。ジョブは 15 分ごとに実行されます。2007 年 11 月に DST 変更が行われると、SQL Server エージェントでは自動的に DST 変更をトレースします。SQL Server エージェントでは、オペレーティング システムを基にトレースを実行しており、次回の定期的なジョブの実行を正しく更新します。
ジョブ出力の例を次に示します。
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-03-11 01:30:00
CurrentTime 2007-03-11 01:30:00.343
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-03-11 01:45:00
CurrentTime 2007-03-11 01:45:00.343
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-03-11 03:00:00
CurrentTime 2007-03-11 03:00:00.357
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-03-11 03:15:00
CurrentTime 2007-03-11 03:15:00.357
この例では、2007-03-11 02:00:00 に実行されたジョブと 2007-03-11 03:00:00 に実行されたジョブの間に、予想どおり 1 時間の差があります。
ただし、2007 年 11 月の DST 変更が発生している期間中、SQL Server エージェントの定期的なジョブが 1 時間実行されないという、既知の問題があります。2007 年 11 月 4 日に、時計が午前 2:00 から午前 1:00 に戻った後、SQL Server エージェントでは時間が 1 時間進み、午前 2:00 になると次のジョブが実行されます。これは既知の問題です。この問題は 2007 年以前の DST 規則でも発生しており、2007 年の DST 変更が原因ではありません。
ジョブ出力の例を次に示します。
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-11-04 01:30:00
CurrentTime 2007-11-04 01:30:00.343
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-11-04 01:45:00
CurrentTime 2007-11-04 01:45:00.343
one hour plus 15 minutes gap here */
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-11-04 02:00:00
CurrentTime 2007-11-04 02:00:00.357
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-11-04 02:15:00
CurrentTime 2007-11-04 02:15:00.357
ジョブ出力の例では、2007-11-04 01:45:00 に実行されたジョブと 2007-11-04 02:00:00 に実行されたジョブの間に、1 時間 15 分の差があります。この動作は、SQL Server のレプリケーション エージェント ジョブ、バックアップ ジョブ、ログ配布ジョブ、およびその他の定期的なジョブに影響を及ぼします。