Vorbereiten von SQL Server 2005 und SQL Server 2000 für die geänderte Sommerzeitregelung im Jahr 2007

Artikel-ID: 931975 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
931975
(http://support.microsoft.com/kb/931975/EN-US/ )
How to prepare SQL Server 2005 and SQL Server 2000 for changes to daylight saving time in 2007
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.
Alles erweitern | Alles schließen

Auf dieser Seite

Einführung

Im August 2005 verabschiedete der US-Kongress den Energy Policy Act. Mit diesem Gesetz wurde das Anfangsdatum und das Endedatum der Sommerzeit (Daylight Saving Time, DST) in den USA geändert. Der Energy Policy Act tritt 2007 in Kraft. Die Sommerzeit beginnt dann drei Wochen früher und endet eine Woche später als nach der ursprünglichen Regelung. Genau gesagt beginnt die Sommerzeit am zweiten Sonntag im März um 02:00 Uhr und endet am ersten Sonntag im November um 02:00 Uhr.

In der folgenden Tabelle sind die Änderungen bei der Sommerzeitregelung 2007 zusammengefasst.
Tabelle minimierenTabelle vergrößern
Ursprüngliches Anfangsdatum der SommerzeitAnfangsdatum der Sommerzeit 2007Ursprüngliches Endedatum der SommerzeitEndedatum der Sommerzeit 2007
Erster Sonntag im AprilZweiter Sonntag im MärzLetzter Sonntag im Oktober Erster Sonntag im November
Wäre der 1. April 2007 gewesen11. März 2007Wäre der 28. Oktober 2007 gewesen4. November 2007
In diesem Artikel wird besprochen, wie Sie Microsoft SQL Server 2005 und Microsoft SQL Server 2000 auf die geänderte Sommerzeitregelung im Jahr 2007 vorbereiten.
Zum Anfang | Ihr Feedback an uns

Weitere Informationen

Schritte, die Sie durchführen müssen

Wenn auf dem Computer, der für automatische Sommerzeitanpassungen konfiguriert ist, SQL Server installiert ist und die Zeitzone des Computers der geänderten Sommerzeitregelung 2007 folgt, müssen Sie folgende Aktionen durchführen:
  • Installieren Sie das Update für Windows, das in Artikel 924840 der Microsoft Knowledge Base beschrieben wird. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    924840
    (http://support.microsoft.com/kb/924840/DE/ )
    Erhält eine Testversion von dem Update global 2007 Zeitzone für Windows
  • Wenn SQL Server Notification Services auf dem Computer installiert ist, installieren Sie das in Artikel 931815 der Microsoft Knowledge Base beschriebene Update. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    931815
    (http://support.microsoft.com/kb/931815/DE/ )
    DST-Zeitzone-Aktualisierung für SQL Server 2005 Notification Services und SQL Server 2000 Notification Services
  • Sie müssen keine speziellen Updates für SQL Server anwenden, um sicherzustellen, dass SQL Server ordnungsgemäß funktioniert. Sie müssen jedoch das Betriebssystem aktualisieren. Außerdem müssen Sie die Produkte und Anwendungen, die mit SQL Server interagieren, aktualisieren. Zu diesen Produkten und Anwendungen zählen u. a. Notification Services, Windows SharePoint Services, Microsoft CRM usw. Eine vollständige Liste an Updates, die Sie für andere Microsoft-Produkte anwenden müssen, finden Sie auf folgender Microsoft-Website:
    http://support.microsoft.com/gp/cp_dst
    (http://support.microsoft.com/gp/cp_dst)

Verwendung der Uhrzeit und Berichterstellung in SQL Server

Unter SQL Server 2005 und SQL Server 2000 verwendet das SQL Server-Datenbankmodul die folgenden zwei Arten von Zeitgebern zur Generierung von Zeitinformationen:
  • Hochauflösender Zeitgeber
  • Niedrigauflösender Zeitgeber
Bei dem hochauflösenden Zeitgeber basiert die Zeitgeberauflösung auf den RDTSC-Anweisungen (RDTSC = Read Time-Stamp Counter) der CPU. Beim niedrigauflösenden Zeitgeber basiert die Zeitgeberauflösung auf der GetTickCount-Funktion in der Microsoft Windows-API.

Verschiedene zeitgeberbasierte Hintergrundaufgaben und wichtige Systemkomponenten sind für eine ordnungsgemäße Funktion auf diese Zeitgeber angewiesen. Da diese Zeitgeber relative Angaben in Bezug zu einer bestimmten Zeitangabe liefern, sind interne Komponenten und interne Aktivitäten nicht von der geänderten Sommerzeitregelung 2007 betroffen.

Sie führen beispielsweise Aufgaben durch, die folgende zeitgeberbasierte Aktivitäten oder Komponenten beinhalten:
  • Systemkomponenten wie etwa "Lazy Writer", "Lock Monitor" und "Scheduler Monitor"
  • Hintergrundaufgaben wie Ghost Cleanup und automatische Verkleinerung
  • Auf Zeitüberschreitung basierende Ressourcen wie Sperren und Latches
  • Geplante Aktivitäten wie Aufträge des SQL Server-Agents und Wartungspläne
  • Systemanweisungen wie etwa die WAITFOR-Anweisung
SQL Server generiert außerdem Zeitinformationen, die für externe Komponenten und Anwendungen zur Verfügung gestellt werden. Diese Zeitinformationen werden vom Windows-Betriebssystem abgerufen. Die Zeitinformationen sind deshalb nur dann präzise, wenn das Betriebssystem den richtigen Zeitwert zurückgibt.

Sie führen beispielsweise Aufgaben aus, die die folgenden externen Komponenten und Anwendungen einbeziehen:
  • SQL Server Profiler- oder SQL Profiler-Ereignisspalten wie etwa die Spalte Start Time, die Spalte End Time und die Spalte Duration für verschiedene Ereignisse
  • Zeitinformationen, über die in verschiedenen Protokollen wie dem SQL Server-Fehlerprotokoll, Ereignisprotokollen und Systemtabellen berichtet wird
  • Systemfunktionen wie die GetDate-Funktion und die GetUtcDate-Funktion
Stellen Sie sich folgendes Szenario vor: Sie erstellen eine SQL Server-Ablaufverfolgung mithilfe von SQL Server Profiler oder SQL Profiler. Die Ablaufverfolgung zeichnet eine Abfrage auf, die vor der Zeitumstellung im März 2007 startet und nach der Zeitumstellung im März 2007 endet. in diesem Szenario sind die Zeitinformationen präzise und werden nicht durch die Zeitumstellung beeinflusst.
Im Folgenden sehen Sie eine beispielhafte Ausgabe der Ablaufverfolgung:
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
Ebenso sehen Sie nachfolgend die Beispielausgabe einer Ablaufverfolgung, die eine Abfrage während der Zeitumstellung im November 2007 aufzeichnet:
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

Bekannte SQL Server-Probleme mit der Sommerzeit, die nicht mit der geänderten Sommerzeitregelung 2007 zusammenhängen

Die Sommerzeit wird von den Datums- und Uhrzeitfunktionen "DateDiff" und "DateAdd" nicht berücksichtigt

Wenn Sie mithilfe von Transact-SQL-Anweisungen Zeitkalkulationen durchführen, die auf vom System bereitgestellten Datums- und Uhrzeitfunktionen basieren, müssen Sie die Anweisungen sorgfältig überprüfen. Insbesondere wenn Sie Sommerzeit-Uhrzeiten hartkodiert in die Anwendungslogik geschrieben haben, wird die Sommerzeit von den Systemfunktionen DateDiff und DateAdd nicht berücksichtigt.

Eine Anwendung führt beispielsweise folgende Anweisungen aus, um den Zeitunterschied zu berechnen. Die Berechnung basiert auf der alten Sommerzeit. Beachten Sie, dass gemäß der neuen Sommerzeitregelung von 2007 der 11.03.2007 das Anfangsdatum der Sommerzeit ist. Gemäß der alten Sommerzeitregelung wäre der 01.04.2007 das Anfangsdatum der Sommerzeit.
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
Beim Ausführen der Anweisungen wird das folgende Ergebnis angezeigt:
TimeDiffInSecs 
-------------- 
3,630
Da die DateDiff-Systemfunktion die Sommerzeit nicht berücksichtigt, geben die Anweisungen 3.630 Sekunden anstelle von 30 Sekunden zurück.

Verwenden Sie anstelle der GetDate-Funktion die GetUtcDate-Funktion, um die Zeitberechnung in solchen Szenarien zu korrigieren. Die GetUtcDate-Funktion gibt die aktuelle UTC-Zeit zurück. Die aktuelle UTC-Zeit wird von der aktuellen lokalen Zeit zusammen mit der Zeitzoneneinstellung im Betriebssystem des Computers, auf dem SQL Server ausgeführt wird, abgeleitet.

Im Folgenden sehen Sie abgeänderte Anweisungen, die ordnungsgemäß funktionieren:
/*-------------------------------------------------------
	  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
Wenn Sie die Anweisungen ausführen, wird das richtige Ergebnis wie folgt angezeigt:
TimeDiffInSecs  --------------  30

Auswirkungen des Endedatums der Sommerzeit auf geplante Aufträge des SQL Server-Agents

Stellen Sie sich folgendes Szenario vor: Sie haben einen geplanten Auftrag eines SQL Server-Agents, bei dem die aktuelle Ortszeit gedruckt wird. Dieser Auftrag wird alle 15 Minuten ausgeführt. Bei der Zeitumstellung im November 2007 verfolgt der SQL Server-Agent automatisch die Zeitumstellung nach. Der SQL Server-Agent basiert seine Ablaufverfolgung auf dem Betriebssystem und aktualisiert die nächste geplante Ausführung des Auftrags ordnungsgemäß.

Im Folgenden sehen Sie eine beispielhafte Ausgabe des Auftrags:
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
In diesem Beispiel besteht wie erwartet eine einstündige Lücke zwischen der Ausführung des Auftrags am 11.03.2007 um 02:00:00 Uhr und der Ausführung des Auftrags am 11.03.2007 um 03:00:00.

Es gibt jedoch ein bekanntes Problem, bei dem geplante Aufträge des SQL Server-Agents während der Zeitdauer, in der die Zeitumstellung im November 2007 stattfindet, eine Stunde lang nicht ausgeführt werden können. Nachdem die Uhr am 4. November 2007 von 02:00 Uhr auf 01:00 Uhr zurückgestellt wird, überspringt SQL Server-Agent die nächste Stunde und wartet bis 02:00 Uhr, um die nächste Ausführung zu starten. Dies ist ein bekanntes Problem. Dieses Problem ist auch vor der Änderung der Sommerzeitkonventionen 2007 aufgetreten. Das Problem ist nicht auf die geänderte Sommerzeitregelung 2007 zurückzuführen.

Im Folgenden sehen Sie eine beispielhafte Ausgabe des Auftrags:
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
Sie sehen in dieser Beispielausgabe des Auftrags eine Lücke von einer Stunde und 15 Minuten zwischen der Ausführung des Auftrags am 11.04.2007 um 01:45:00 Uhr und der Ausführung des Auftrags am 11.04.2007 um 02:00:00 Uhr. Dieses Verhalten könnte sich auf Agent-Replikationsaufträge, Sicherungsaufträge, Protokollversandaufträge und andere geplante Aufträge in SQL Server auswirken.
Zum Anfang | Ihr Feedback an uns

Eigenschaften

Artikel-ID: 931975 - Geändert am: Freitag, 2. Mai 2008 - Version: 3.4
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard X64 Edition
  • Microsoft SQL Server 2005 Standard Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Enterprise X64 Edition
  • Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000, Workgroup Edition
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2000 Personal Edition
  • Microsoft SQL Server 2000 Enterprise Edition 64-bit
Keywords: 
kbhowto kbexpertiseadvanced kbsql2005engine kbinfo KB931975
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Zum Anfang | Ihr Feedback an uns

Ihr Feedback an uns

 
Zum AnfangZum Anfang