Ändert auf Sommerzeit 2007 SQL Server 2005 und SQL Server 2000 vorbereiten

Einführung

Im August 2005 übergeben US-Kongress den Energy Policy Act. Dies ändert das Startdatum und das Enddatum der Sommerzeit (DST). Wenn dies in 2007 Inkrafttreten DST beginnt drei Wochen früher und endet eine Woche später als bisher Beginn und Ende. Insbesondere Sommerzeit um 2:00 Uhr am zweiten Sonntag im März beginnt und endet am ersten Sonntag im November um 2:00 Uhr.

In der folgenden Tabelle sind die Änderungen Sommerzeit 2007 zusammengefasst.
Datum DST zuvor gestartetDatum Sommerzeit 2007 beginntEnddatum als DST zuvorEnddatum für Sommerzeit 2007 aus
Erster Sonntag im AprilZweiter Sonntag im MärzLetzter Sonntag im Oktober
Erster Sonntag im November
Hätte am 1. April 200711. März 2007Hätte 28. Oktober 2007Am 4. November 2007
Dieser Artikel beschreibt die Änderung der Sommerzeit 2007 Microsoft SQL Server 2005 und Microsoft SQL Server 2000 vorbereiten.

Weitere Informationen

Auszuführende Aktionen

Wenn Sie SQL Server auf einem Computer installiert, der zur automatischen Anpassung der DST konfiguriert haben und die Zeitzone des Computers Sommerzeit 2007 folgt müssen Sie die folgenden Aktionen ausführen:
  • Installieren Sie das Update für Windows, wird im Microsoft Knowledge Base-Artikel 924840. Für Weitere Informationen klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:

    924840 eine Testversion der 2007 globale Zeitzone für Windows update ist verfügbar

  • Wenn Sie SQL Server Notification Services auf dem Computer installiert haben, installieren Sie beschriebene Update im Microsoft Knowledge Base-Artikel 931815. Für Weitere Informationen klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:

    931815 update 2007 Zeitzone für SQL Server 2005 Notification Services und SQL Server 2000 Notification Services

  • Sie müssen keinen speziellen Updates für SQL Server, um sicherzustellen, dass SQL Server ordnungsgemäß angewendet. Allerdings müssen Sie das Betriebssystem aktualisieren. Darüber hinaus müssen Sie aktualisieren die Produkte und Programme interagieren mit SQL Server. Diese Produkte und Applikationen gehören Notification Services, Windows SharePoint Services, Microsoft CRM und So weiter. Eine vollständige Liste der Updates für andere Microsoft-Produkte gelten, finden Sie auf der folgenden Microsoft-Website:

Bearbeitungszeit für SQL Server und reporting

In SQL Server 2005 und SQL Server 2000 verwendet das SQL Server-Datenbankmodul die folgenden zwei Arten von Zeitgebern Informationen generiert:
  • Hochauflösenden Zeitgeber
  • Timer mit niedriger Auflösung
Die Auflösung des Zeitgebers basiert im hochauflösenden Zeitgeber auf Anweisung Read Zeitstempel Zähler (RDTSC) der CPU. In geringer Auflösung Timer die Auflösung des Zeitgebers GetTickCount -Funktion in Microsoft Windows-API basiert.

Verschiedene zeitgeberbasierte Hintergrundaufgaben und wichtige Systemkomponenten hängen von dieser Zeitgeber für eine ordnungsgemäße Funktion. Da dieser Zeitgeber relative Maßnahmen eines bestimmten Zeitraums arbeiten, werden interne Komponenten und internen der Änderung der Sommerzeit 2007 unberührt.

Beispielsweise führen Sie Aufgaben, die folgende zeitgeberbasierte Aktivitäten oder Komponenten beinhalten:
  • Systemkomponenten wie lazy Writer Lock Monitor und Scheduler monitor
  • Hintergrundaufgaben wie Ghost Cleanup und automatische Verkleinerung
  • Time-out-basierte Ressourcen wie Sperren und Riegel
  • Geplante Aktivitäten wie SQL Server-Agent-Aufträge und Wartungspläne
  • System-Anweisung wie die WAITFOR -Anweisung
SQL Server generiert außerdem Informationen, die auf externe Komponenten und Applikationen verfügbar ist. Diese Informationen wird vom Windows-Betriebssystem abgerufen. Daher stimmt die Informationen wie das Betriebssystem den richtigen Zeitwert zurückgibt.

Beispielsweise führen Sie Aufgaben mit folgenden externen Komponenten und Programme:
  • SQL Server Profiler oder SQL Profiler-Ereignisspalten Startzeit -Spalte der Spalte Endzeit und der Spalte Dauer für die verschiedenen Ereignisse
  • Informationen, die in verschiedenen Protokollen wie SQL Server-Fehlerprotokoll, Ereignisprotokollen und Systemtabellen berichtet wird
  • Systemfunktionen wie die GetDate -Funktion und die GetUtcDate -Funktion
Das folgende Szenario. Erstellen einen SQL Server-Trace mit SQL Server Profiler oder SQL Profiler. Ablaufverfolgungsdatensätze vor März 2007 Sommerzeit Abfrage ändern und endet nach März 2007 DST Zeit ändern. Die Informationen in diesem Szenario ist und nicht durch die Änderung der Sommerzeit betroffen.
Beispielausgabe von Trace lautet:
EventSequence  EventClass         TextData              StartTime                EndTime                  Duration156            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
Ebenso wird folgende Beispielausgabe eines Trace, der eine Abfrage während der Zeitwechsel November 2007 DST aufzeichnet:
EventSequence  EventClass         TextData              StartTime                EndTime                  Duration178            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

Bekannte DST-bezogenen SQL Server ausgibt, die nicht spezifisch für die Änderung der Sommerzeit 2007

DateDiff und DateAdd Datums- und Uhrzeitfunktionen sind nicht DST Beachten

Wenn Sie Transact-SQL-Anweisungen Zeitkalkulationen ausführen, die vom System bereitgestellten Datums- und Zeitfunktionen basieren, müssen Sie die Anweisung sorgfältig untersuchen. Insbesondere wenn Sie Sommerzeit-Uhrzeiten hartkodiert in die Anwendungslogik geschrieben haben, sind die Funktionen DateDiff und DateAdd nicht DST beachten.

Eine Anwendung führt z. B. die folgenden Aussagen zur Berechnung der zeitlichen Differenz. Die Berechnung basiert auf der alten Sommerzeit. Beachten Sie, dass unter neuen DST-System 2007 2007-03-11 das Startdatum der Sommerzeit. Im alten System Sommerzeit wäre 2007-04-01 das Startdatum des DST jedoch.
DECLARE @starttime datetimeDECLARE @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

Beim Ausführen der Anweisung erhalten Sie folgende Ergebnis:
TimeDiffInSecs -------------- 
3,630

Da Systemfunktion DateDiff keine Sommerzeit bekannt ist, zurückgeben die Anweisung 3.630 Sekunden 30 Sekunden.

Um die Berechnung in solchen Szenarien zu korrigieren, verwenden Sie die GetUtcDate -Funktion anstelle der GetDate -Funktion. Die GetUtcDate -Funktion gibt die aktuelle UTC-Zeit. Die aktuelle UTC-Zeit ist die aktuelle lokale Zeit und die Zeitzone im Betriebssystem des Computers abgeleitet auf dem SQL Server ausgeführt wird.

Folgende sind geänderte Anweisungen ordnungsgemäß funktioniert:
/*-------------------------------------------------------  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
Beim Ausführen der Anweisung wird das richtige Ergebnis wie folgt angezeigt:
TimeDiffInSecs -------------- 
30

Auswirkung der DST Enddatum auf geplanten SQL Server-Agent-Aufträge

Das folgende Szenario. Sie haben einen geplanten SQL Server-Agent-Auftrag, der aktuelle Ortszeit gedruckt wird. Der Auftrag wird alle 15 Minuten ausgeführt. Tritt die DST-Änderung im November 2007, überwacht SQL Server Agent automatisch die DST-Änderung. SQL Server-Agent basiert die Überwachung auf dem Betriebssystem und die nächste geplante Ausführung des Auftrags richtig aktualisiert.

Im folgenden finden die Beispielausgabe des Auftrags:
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-03-11 01:30:00CurrentTime    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

In diesem Beispiel gibt eine einstündige Lücke zwischen der Ausführung des Auftrags am 2007-03-11 02:00:00 Uhr und der Ausführung des Auftrags am 2007-03-11 03:00:00 wie erwartet.

Allerdings gibt es ein bekanntes Problem in dem geplanten SQL Server-Agent-Aufträge für eine Stunde im Zeitraum ausgeführt werden können der November 2007 DST bei Änderung. Nachdem die Uhr um 1:00 Uhr am 4. November 2007 von 2:00 Uhr geändert wird würde SQL Server-Agent-Aufträge überspringen die nächste Stunde und warten, bis 2:00 Uhr weiter zu führen. Dies ist ein bekanntes Problem. Dieses Problem auch unter vor 2007 DST Konventionen. Dieses Problem führt nicht aus der Sommerzeit 2007.

Im folgenden finden die Beispielausgabe des Auftrags:
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-11-04 01:30:00CurrentTime    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

Beachten Sie, dass in dieser Beispielausgabe des Auftrags eine Lücke 1-Stunden-und 15 Minuten zwischen der Ausführung des Auftrags am 2007-11-04 01:45:00 Uhr und der Ausführung des Auftrags am 2007-11-04 02:00:00. Dieses Verhalten kann Agent-Replikationsaufträge, Sicherungsaufträge, Protokollversandaufträge und andere geplante Aufträge in SQL Server auswirken.
Eigenschaften

Artikelnummer: 931975 – Letzte Überarbeitung: 14.01.2017 – Revision: 2

Feedback