Zusammenfassung

Microsoft SQL Server 2005 verwendet den Hochauflösungs-CPU-Leistungsindikator, um Mikrosekunden-Anzeigefunktionen bereitzustellen. Eine Mikrosekunde ist ein Millionstel einer Sekunde (oder ein Tausendstel einer Millisekunde). SQL Server-timingwerte sind jedoch möglicherweise falsch, wenn Sie Technologien verwenden, die CPU-Frequenzen ändern. Dieses Problem kann beispielsweise auftreten, wenn Sie eine der folgenden Technologien verwenden:

  • CPU-Stepping

  • AMD-Cool'n'Quiet-Technologie

  • Verschiedene Energieschemas

Dieser Artikel enthält Methoden und weitere Informationen, die Ihnen helfen, dieses Problem zu umgehen.

Problembeschreibung

Wenn Sie die Anweisung "Statistik Zeit definieren" zum Anzeigen von Server Ausführungs-, Analyse-und Kompilierungszeiten verwenden, erhalten Sie möglicherweise falsche Werte. So können Sie beispielsweise feststellen, dass die verstrichene Zeit der SQL Server-Ausführungszeit weit mehr als die CPU-Zeit ist. Dieses Problem kann sich auf die Genauigkeit der Leistungsoptimierung auswirken. Dieses Problem tritt auf, wenn Sie eine der Technologien verwenden, die im Abschnitt "Zusammenfassung" auf dem Server aufgeführt sind.

Ursache

Dieses Problem tritt auf, weil die CPU-Frequenzen bei Verwendung dieser Technologien geändert werden. SQL Server 2005 verwendet den Hochauflösungs-CPU-Leistungsindikator, um Mikrosekunden-Anzeigefunktionen bereitzustellen. Wenn CPU-Frequenzen geändert werden, um Energie zu sparen und die Wärmeleistung zu verringern, können berechnete Dauer falsch sein.

Fehlerbehebung

Service Pack-Informationen

Um dieses Problem zu beheben, besorgen Sie sich das neueste Service Pack für SQL Server 2005. Wenn Sie weitere Informationen wünschen, klicken Sie auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

913089 Installieren des neusten Service Packs für SQL Server 2005Hinweis In SQL Server 2005 Service Pack 3 und in späteren Service Packs wird der Prozessorzeit Stempel nicht verwendet. Diese Versionen von SQL Server 2005 verwenden einen zuverlässigeren Zeitgeber mit einer maximalen Genauigkeit von 1 Millisekunde.

Status

Dieses Problem wurde zuerst in SQL Server 2005 Service Pack 3 behoben.

Problemumgehung

SQL Server 2005 erfordert bekannte und stabile Datenpunkte, um eine genaue Leistungsoptimierung durchzuführen. Wenn die Einstellungen für dynamische CPU-Frequenzen auf dem Computer aktiviert sind, können Sie Sie deaktivieren, damit die CPUs eine gleichmäßige Frequenz Rate beibehalten, bevor Sie mit der Überwachung und Optimierung der SQL Server-Leistung beginnen. Verwenden Sie dazu die folgenden Methoden.

Konfigurieren des Energieschemas auf dem Computer, um zu erzwingen, dass die CPUs bei maximaler Häufigkeit verbleiben

Gehen Sie dazu wie folgt vor:

  1. Klicken Sie auf Start, klicken Sie auf Ausführen, geben Sie powercfg. cplein, und klicken Sie dann auf OK.

  2. Klicken Sie im Dialogfeld Energieoptionen-Eigenschaften in der Liste Energieschemas auf immer aktiviert .

  3. Klicken Sie auf OK.

Es kann eine Abweichung auftreten. Bei einer Drift handelt es sich um eine Abweichung zwischen den CPU-Häufigkeits Werten. Weitere Informationen finden Sie im Abschnitt "driften". In diesem Fall müssen Sie Microsoft Windows neu starten, um die Frequenzen aller CPUs erneut zu synchronisieren, nachdem Sie das Energieschema geändert haben. Wenn Sie den Computer nicht neu starten können, aktivieren Sie die SQL Server-Prozessoraffinität, um zu verhindern, dass SQL Server-Worker-Threads zwischen den CPUs wechseln. Wenn Sie dies tun, müssen Sie den Computer nicht neu starten, selbst wenn eine Abweichung zwischen den Werten der CPU-Häufigkeit eintritt. Um die SQL Server-Prozessoraffinität für alle CPUs auf dem Server zu aktivieren, müssen Sie je nach Anzahl der auf dem Server installierten logischen Prozessoren eine andere Maske verwenden. In der folgenden Tabelle sind Beispielszenarien aufgeführt.

CPU-Nummer

Anweisungen zum Aktivieren der Prozessoraffinität

02-CPUs

Exec sp_configure "Affinitätsmaske", 0x00000003GOreconfigureGO

04 CPUs

Exec sp_configure "Affinitätsmaske", 0x0000000FGOreconfigureGO

08-CPUs

Exec sp_configure "Affinitätsmaske", 0x000000FFGOreconfigureGO

16 CPUs

Exec sp_configure "Affinitätsmaske", 0x0000FFFFGOreconfigureGO

32-CPUs

Exec sp_configure "Affinitätsmaske", 0xFFFFFFFFGOreconfigureGO

Hinweis Es ist möglicherweise nicht ausreichend, die CPU-Frequenz Variationsfeatures auf BIOS-Ebene zu deaktivieren. Verschiedene Dienstprogramme von Drittanbietern können CPU-Frequenzen ändern. Einige Implementierungen ermöglichen Häufigkeits Anpassungen selbst dann, wenn die CPUs die maximale Energieschema Einstellung aufweisen. In diesem Fall müssen Sie diese Dienstprogramme von Drittanbietern deaktivieren, wenn Sie die Leistungsoptimierung in SQL Server 2005 durchführen.

Verwenden von Dienstprogrammen und Treibern von Drittanbietern zum Synchronisieren von CPU-Frequenzen und CPU-Takt Zählern

In seltenen Fällen erfordert ein System möglicherweise ein Update vom Hersteller, um Probleme mit der CPU-Häufigkeit zu beheben. Es ist eine bewährte Methode, das System auf die neuesten BIOS-, Mikro Code-und Firmware-Updates zu überprüfen, wenn Sie vermuten, dass das System ein Problem aufweisen kann.

Weitere Informationen

Microsoft SQL Server 2000 und frühere Versionen von SQL Server verwenden die Windows-Timing-Mechanismen. Die Timing-Mechanismen verwenden Millisekunden-Genauigkeitswerte. Diese Genauigkeit beträgt in der Regel 10 bis 15 ms. Die Genauigkeit kann jedoch so groß wie 55 ms sein. SQL Server-Abfragen werden häufig innerhalb einer einstelligen Millisekunden-oder Mikrosekunden-Zeitspanne abgeschlossen. Diese Genauigkeit erfordert einen Zeitgeber mit hoher Auflösung. Daher melden diese Versionen von SQL Server die Dauer einiger Abfragen als 0 ms. Aus diesem Grund ist es schwierig, die Leistung zu überwachen und die Leistung von SQL Server in früheren Versionen von SQL Server zu optimieren. SQL Server 2005 verbessert die Genauigkeit mithilfe des CPU-Leistungsindikators mit hoher Auflösung, um Mikrosekunden-Anzeigefunktionen bereitzustellen. Wenn Sie die im Abschnitt "Zusammenfassung" aufgelisteten Technologien verwenden, sind die gemeldeten Anzeigedauer Werte möglicherweise falsch. Dieses Problem kann sich auf die folgenden Objekte und Features auswirken:

  • Ablaufverfolgungsereignisse:

    • Das Attention -Ereignis

    • Ereignisse im Knoten gespeicherte Prozeduren

    • Ereignisse im TSQL-Knoten

    • Ereignisse im Knoten "Objekte"

    • Ereignisse im Knoten "Transaktionen"

  • Dynamische Verwaltungsansichten:

    • sys.dm_exec_query_stats

    • sys.dm_exec_requests

    • sys.dm_exec_sessions

    • sys.dm_io_pending_io_requests

    • sys.dm_os_ring_buffers

    • sys.dm_os_sys_info

    • sys.dm_io_virtual_file_stats

    • sys.dm_os_wait_stats

  • Die Anweisung "Statistik Zeit definieren"

  • Die sysprocesses -Systemtabelle

Nachdem Sie SQL Server 2005 Service Pack 2 (SP2) installiert haben, protokolliert SQL Server eine Fehlermeldung im Fehlerprotokoll, wenn SQL Server erkennt, dass die Hochauflösungs-Timer nicht synchron zwischen den CPUs sind. Die Fehlermeldung weist darauf hin, dass die Anzeigedauer für die Leistung möglicherweise nicht korrekt ist und Benutzer Leistungsdaten mit Bedacht verwenden sollten. Der Text der Fehlermeldung ähnelt einer der folgenden Fehlermeldungen:

Fehlermeldung 1

Der Zeitstempelzähler der CPU auf Scheduler-ID 2 wird nicht mit anderen CPUs synchronisiert.

Fehlermeldung 2

Die Häufigkeit des CPU-Zeitstempels hat sich von 191469 auf 1794177-Ticks pro Millisekunde geändert. Die neue Häufigkeit wird verwendet.

SQL Server verwendet die RDTSC-Anweisung (Real Time Stamp Counter) zum Abrufen der CPU-Taktanzahl von 64-Bit. Sie können diesen Wert durch die CPU-Häufigkeit dividieren, um den Wert in Millisekunden zu konvertieren. Zeitabweichungen können auftreten, wenn die CPU-Frequenz geändert oder Abdriften erfolgt.

CPU-Stepping

CPU-Stepping wird als bewusste Änderung der CPU-Häufigkeit definiert. CPU-Stepping kann auch als Intel SpeedStep-Technologie oder AMD PowerNow! bekannt sein. Technologie. Wenn CPU-Stepping erfolgt, kann die CPU-Geschwindigkeit in Schritten von 50 MHz erhöht oder verringert werden, um Energie zu sparen und die Wärmeleistung zu verringern. CPUs, die sich innerhalb desselben NUMA-Knotens (Non-Uniform Memory Access) befinden, können Frequenzen nicht unabhängig voneinander anpassen. Die folgende Tabelle zeigt, wie sich die Änderungen an der CPU-schrittweise auf die Berechnung von Berechnungen auswirken können.

Aktion

RDTSC-Ticks

Ticks pro Millisekunde (Häufigkeit)

Uhrzeit der Wanduhr

Batch starten

1

200

0

Häufigkeits Schritt nach unten

200

100

1ms

Stapel beenden

500

3ms

Summen

500

4ms

SQL Server erfasst die RDTSC-Ticks sowohl am Anfang als auch am Ende des RDTSC-Ticks. Anschließend dividiert SQL Server die Ticks durch den Häufigkeitswert. In diesem Beispiel treten die folgenden Zeitberechnungen auf, wenn Sie einen Häufigkeitswert von 200 oder 100 verwenden:

  • Häufigkeit 200: 500/200 = 2,5 ms

  • Häufigkeit 100: 500/100 = 5 ms

Keine der Zeitberechnungen entspricht der tatsächlichen Wanduhr von 4 ms. Wenn diese Berechnung in einem RPC: Completed -Ablaufverfolgungsereignis verwendet wird, werden die Datenspalten Duration und Endzeit falsch gemeldet. Das RPC: Completed -Ereignis erfasst die Startzeit und die CPU-Taktanzahl. Um eine höhere Auflösung als Windows-Lieferungen in SQL Server 2005 zu erreichen, werden die Datenspalten Duration und Endzeit in einer SQL Server-Ablaufverfolgung mithilfe der Taktanzahl der verstrichenen CPU berechnet. Die Spalte Endzeit wird berechnet, indem die Spalte Duration zur Spalte Anfangszeit hinzugefügt wird. In diesem Beispiel wird die Spalte Endzeit berechnet, indem entweder 2,5 ms oder 5 ms zur Startzeit falsch hinzugefügt werden.

Drift

Drift ist eine Abweichung in den CPU-Takt Werten. Systeme mit mehreren CPUs können unterschiedliche CPU-Taktwerte für denselben Zeitpunkt produzieren. Obwohl es nicht üblich ist, kann es vorkommen, dass CPUs über einen Zeitraum Taktabstand aufweisen. Im folgenden Beispiel wird veranschaulicht, wie sich Drift Änderungen auf das Ergebnis der Duration -Datenspalte in einer SQL Server-Ablaufverfolgung auswirken können. In diesem Beispiel wird davon ausgegangen, dass die CPU-Häufigkeit bei 200-Ticks pro Millisekunde konstant bleibt. In der folgenden Tabelle werden die Ereignisse in diesem Szenario veranschaulicht.

Aktion

Geplante Windows-CPU

CPU 1 RDTSC

CPU 2 RDTSC

Uhrzeit der Wanduhr

Batch starten

1

100

1100

0

Stapel beenden

2

900

1900

4 MS

Summen

4 MS

SQL Server erfasst die RDTSC-Ticks an den Anfangs-und Endpunkten. Anschließend dividiert SQL Server die RDTSC-Ticks durch den Häufigkeitswert. In diesem Beispiel hat Windows den SQL Server-Worker-Thread auf zwei verschiedenen CPUs geplant. Der SQL Server-Worker-Thread, der den Batch zuerst verarbeitet, lief auf der ersten CPU (CPU 1). Die Batchausführung wurde jedoch irgendwann unterbrochen, und SQL Server hat die Batchausführung an die ausstehende Warteschlange gesendet. Wenn SQL Server den SQL Server-Worker-Thread, der diesen Batch ausführt, erneut an die ausführbare Warteschlange gesendet hat, hat Windows den Thread zur Ausführung auf der zweiten CPU (CPU 2) weitergeleitet. Der SQL Server-Worker-Thread wurde auf CPU 2 ausgeführt. Aufgrund von CPU-Drift war der endtick-Wert, der von CPU 2 erfasst wurde, 1900 statt 900. Sie können dieses Verhalten vermeiden, wenn Sie die SQL Server-Prozessoraffinität aktivieren. In diesem Beispiel werden die folgenden Berechnungen zur Zeitmessung verwendet:

  • Der fehlerhafte, aber gemeldete Wert: (1900 – 100 = 1800)/200 = 9 ms

  • Korrekter Wert: (900 – 100 = 800)/200 = 4 MS

Der Wert der Duration -Spalte für das RPC: Completed -Ereignis würde als 9 ms anstelle von 4 MS gemeldet. Dieses Ergebnis ist mehr als doppelt so viel wie der richtige Wert von 4 ms. Drift-Warnmeldungen werden SQL Server 2005 hinzugefügt, um anzugeben, dass die zuvor erwähnten Leistungsausgaben möglicherweise nicht zuverlässig sind. In einigen ungedeckten Situationen meldet SQL Server 2005 SP2 möglicherweise Warnmeldungen zu folgenden Themen:

  • Warnmeldungen für falsche Drift

  • Drift kann zu zehn Millisekunden werden, ohne dass ein spürbarer System Effekt verursacht wird

Sie müssen vorsichtig sein, wenn Sie die leistungsbezogenen Ausgaben auswerten und die leistungsbezogenen Ausgaben mit den Uhrzeiten der Wanduhren vergleichen. Wenn es keine Anzeichen für andere Leistungsprobleme gibt, können Sie die Drift-Warnmeldungen in der Regel ignorieren. So können Sie beispielsweise die Drift-Warnmeldungen in den folgenden Situationen ignorieren:

  • Prozesse werden wie erwartet ausgeführt.

  • SQL Server-Abfragen werden nicht in seltsamen Dauer Mustern ausgeführt.

  • Es werden keine Anzeichen für andere Engpässe angezeigt.

Bevor Sie jedoch die Drift-Warnmeldungen ignorieren, empfehlen wir, dass Sie sich an Ihren Hersteller wenden, um sicherzustellen, dass keine bekannten RDTSC-Probleme vorliegen. Sie können das Ablaufverfolgungsflag 8033 (– T8033) verwenden, um zum Berichtsverhalten in der ursprünglichen Version von SQL Server 2005 und SQL Server 2005 SP1 zurückzukehren. In der ursprünglichen Version von SQL Server 2005 und SQL Server 2005 SP1 werden keine Drift-Warnmeldungen gemeldet. Wenn Sie die ursprüngliche Version von SQL Server 2005 oder SQL Server 2005 SP1 ohne Probleme ausführen, können Sie die Nachrichten in der Regel ignorieren.

Warum funktioniert die WAITFOR DELAY-Anweisung richtig? Was ist mit periodischen Systemprozessen?

Timeout Mechanismen sind vom Entwurf mit hoher Auflösung nicht betroffen. In SQL Server wird der Timer mit hoher Auflösung für Timer-basierte Aktivitäten nicht verwendet. Einige Timeout Aktivitäten basieren auf dem Zeitgeber für reduzierte Auflösungen, der die GetTickCount -Funktion verwendet. Zu diesen Timeout Aktivitäten zählen Sperrtimeout, WAITFOR DELAY-Anweisung und Deadlock-Erkennung.

Weitere Informationen finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:

938448 Ein Windows Server 2003-basierter Server kann Zeitstempel-Leistungsindikator Drift aufweisen, wenn der Server Dual-Core-AMD Opteron-Prozessoren oder AMD Opteron-Prozessoren mit einem Prozessor verwendet

895980 Programme, die die QueryPerformanceCounter-Funktion verwenden, funktionieren möglicherweise in Windows Server 2003 und Windows XP schlechtDie Produkte von Drittanbietern, die in diesem Artikel beschrieben werden, werden von Unternehmen hergestellt, die von Microsoft unabhängig sind. Microsoft übernimmt keine impliziten oder anderweitigen Garantien bezüglich der Leistung oder Zuverlässigkeit dieser Produkte.

Benötigen Sie weitere Hilfe?

Ihre Office-Fähigkeiten erweitern
Schulungen erkunden
Neue Funktionen als Erster erhalten
Microsoft Insider beitreten

War diese Information hilfreich?

Wie zufrieden sind Sie mit der Übersetzungsqualität?
Was hat Ihre Erfahrung beeinflusst?

Vielen Dank für Ihr Feedback!

×