SO WIRD'S GEMACHT: Die korrekten SQL Server-Konfigurationseinstellungen ermitteln

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 319942 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel wurde zuvor veröffentlicht unter D319942
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
319942 HOW TO: Determine Proper SQL Server Configuration Settings
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

Zusammenfassung

Dieser Artikel beschreibt die folgenden Konfigurationseinstellungen und gibt Hinweise zu ihrer Verwendung:
  • Affinity Mask
  • Lightweight Pooling
  • Max Async IO
  • Max Worker Threads
  • Speicher
  • Priority Boost
  • Set Working Set Size
SQL Server kann bei relativ geringem Aufwand für die Optimierung der Konfiguration einen sehr hohen Leistungsgrad erreichen. Ein hoher Leistungsgrad wird durch gutes Anwendungs- und Datenbankdesign erreicht, nicht durch aufwändige Optimierung der Konfiguration. Im Abschnitt "Informationsquellen" in diesem Artikel finden Sie Hinweise zur Behebung verschiedener SQL Server-Leistungsprobleme.

Wenn Sie versuchen, ein Leistungsproblem zu beheben, ist der Grad an Verbesserung, der über die Optimierung der Konfiguration erreicht werden kann, in der Regel gering, es sei denn, Sie haben das System zu diesem Zeitpunkt nicht richtig konfiguriert. In SQL Server Version 7.0 und höheren Versionen optimiert SQL Server die Konfiguration automatisch, und es kommt nur äußerst selten vor, dass Konfigurationseinstellungen (insbesondere erweiterte Einstellungen) geändert werden müssen. Ändern Sie die SQL Server-Konfiguration nicht ohne zwingenden Grund und nicht ohne sorgfältiges systematisches Testen zur Überprüfung der Notwendigkeit der Änderung. Vor der Änderung der Konfiguration müssen Sie eine Grundlinie etablieren, um die Verbesserung nach der Änderung messen zu können.

Wenn Sie SQL Server nicht richtig konfiguriert haben, könnten manche Einstellungen den Server destabilisieren oder zu unberechenbarem Verhalten von SQL Server führen. Über die Jahre hat die Erfahrung im Support unterschiedlicher Umgebungen gezeigt, dass vom Standard abweichende Konfigurationseinstellungen neutrale bis äußerst negative Ergebnisse zur Folge haben können.

Wenn Sie die Konfiguration ändern, müssen Sie vor der Änderung gründliche systematische Leistungstests durchführen, um den Grad der Verbesserung bestimmen zu können.

Aktuelle Supportszenarien zeigen, dass SQL Server Version 7.0 oder höher ohne manuelle Optimierung der Konfiguration einen sehr hohen Leistungsgrad erreichen kann.

Ändern Sie in SQL Server 7.0 und höher die Einstellungen user connections, locks und open objects nicht, da SQL Server diese Einstellungen dynamisch optimiert.

Affinity Mask

Die Einstellung affinity mask bezieht sich darauf, wie fest ein Thread an eine bestimmte CPU gebunden ist. Standardmäßig verwenden Microsoft Windows NT und Microsoft Windows 2000 die "weiche" Affinität, d.h., es wird versucht, einen Thread für die CPU einzuplanen, wo er zuletzt ausgeführt wurde. Wenn das jedoch nicht möglich ist, kann ein Tread auf einer anderen CPU laufen.

In der Praxis verbessert eine Änderung der Einstellung affinity mask gegenüber dem Standard nur selten die Leistung; häufig wird sie sogar schlechter.

Affinity mask beschränkt SQL Server auf eine Teilmenge verfügbarer CPUs und ermöglicht anderen konkurrierenden Diensten einen besseren Zugriff auf die CPU. In den meisten Fällen brauchen Sie das nicht, da SQL Server mit normaler Priorität läuft. Der Windows NT- oder Windows 2000-Thread-Scheduler passt die Thread-Prioritäten aller konkurrierenden Threads dynamisch an, um sicherzustellen, dass sie bei allen verfügbaren CPUs vergleichbare Chancen haben.

Ändern Sie affinity mask nur in Ausnahmesituationen. Wenn Sie sich entschließen, diese Einstellung zu ändern, führen Sie vor und nach der Änderung gründliche systematische Tests durch, um die Notwendigkeit der Änderung und den Grad der Verbesserung zu überprüfen.

Lightweight Pooling

Standardmäßig verwendet SQL Server einen Thread pro aktiver SPID oder Benutzerprozess. Diese Threads laufen in einer Poolkonfiguration, um die Anzahl der Threads besser verwalten zu können. Die erweiterte Konfigurationsoption "lightweight pooling" (manchmal auch als "Fiber-Modus") bezeichnet) verwendet die Windows NT-"Fiber"-Unterstützung im Wesentlichen dazu, mehrere Ausführungskontexte mit einem einzigen Thread abwickeln zu können.

Erfahrungen mit aktuellen Produktivumgebungen zeigen, dass Sie den Fiber-Modus nur unter sehr selten auftretenden Bedingungen benötigen. Lightweight Pooling ist selbst dann nur eventuell sinnvoll, wenn alle folgenden Bedingungen zutreffen. Sie müssen durch sorgfältiges Testen herausfinden, ob es wirklich sinnvoll ist.
  • Große Multiprozessoren sind im Einsatz.
  • Alle Server laufen mit (fast) maximaler Kapazität.
  • Es finden viele Kontextumschaltungen statt (mehr als 20.000 pro Sekunde).
Um die Kontextumschaltungen zu überprüfen, öffnen Sie den Systemmonitor, wählen Sie die Counter-Threads aus, wählen Sie das Objekt Kontextwechsel/sec" und markieren Sie dann alle SQL Server-Instanzen für die Aufzeichnung. SQL Mail in SQL Server 2000 wird nicht unterstützt, wenn Sie den Server im Fiber-Modus betreiben. Weitere Informationen finden Sie in folgenden Artikeln der Microsoft Knowledge Base:
308604 PRB: SQL Mail Not Supported When You Run Server in Fiber Mode
303120 FIX: ConnectionWrite Error When You Use Lightweight Pooling Under Lightweight Pooling

Max Async IO

SQL Server 7.0 : Die Konfigurationseinstellung max async IO steht SQL Server 7.0 zur Verfügung. Es kann sinnvoll sein, diese Einstellung zu ändern, wenn Sie ein schnelles RAID-System haben und die Möglichkeit, die Verbesserung zu messen. Ändern Sie die Einstellung nicht, wenn Sie keine Grundlinie haben, an der Sie das Ergebnis messen können. Überwachen Sie die Datenträgeraktivität und suchen Sie nach Problemen mit Warteschlangen von Datenträgern. Weitere Informationen finden Sie in folgenden Themen der SQL Server-Onlinedokumentation:
  • "max async IO (Option)"
  • "Überwachen der Datenträgeraktivität"
  • "Beispiel für das Überwachen der Leistung: Erkennen von Engpässen"
SQL Server 2000 : In SQL Server 2000 können Sie die Einstellung max async IO nicht ändern. SQL Server 2000 optimiert diese Einstellung automatisch.

Max Worker Threads

Die Standardeinstellung für max worker threads ist 255, d.h., es können bis zu 255 Arbeitsthreads erstellt werden. Verwenden Sie die Standardeinstellung von 255 in den meisten Fällen. Das bedeutet nicht, dass Sie nur 255 Benutzerverbindungen einrichten können. Ein System kann Tausende von Benutzerverbindungen haben (die per Multiplexing in 255 Arbeitsthreads zusammengefasst werden). Im Allgemeinen sind für die Benutzer keine Verzögerungen wahrnehmbar. In diesem Fall können nur 255 Abfragen gleichzeitig ausgeführt werden, die jedoch per Multiplexing auf die Anzahl der verfügbaren CPUs verteilt werden, d.h., die Verarbeitung ist nur scheinbar parallel, unabhängig von der Anzahl konfigurierter Arbeitsthreads.

Wenn Sie eine Anzahl von Arbeitsthreads einstellen, die höher ist als der Standard, so ist dies fast immer kontraproduktiv und verschlechtert die Leistung aufgrund von Planungs- und Ressourcenaufwand. Erhöhen Sie diese Einstellung nur dann, wenn eine Ausnahmesituation vorliegt und gründliche systematische Tests gezeigt haben, dass diese Änderung sinnvoll ist.

Speicher


Informationen zur Speicherkonfiguration für SQL Server 7.0 finden Sie in der SQL Server-Onlinedokumentation im Thema "Optimieren der Serverleistung mithilfe von Speicherkonfigurationsoptionen".

Weitere Informationen zur Speicherkonfiguration für Cluster-SQL Server finden Sie in den SQL Server-Onlinedokumentationen, für SQL Server 2000 unter "Überlegungen zur Verwendung" im Thema "Erstellen eines Failoverclusters", für SQL Server 7.0 unter "Konfigurieren des SQL Server-Speichers für einen Cluster" im Thema "Verwenden von SQL Server-Failoversupport".
Weitere Informationen finden Sie in folgenden Artikeln der Microsoft Knowledge Base:
274750 SO WIRD'S GEMACHT: Konfigurieren von mehr als 2 GB Arbeitsspeicher in SQL Server
224818 Simple Memory Tuning Is Required with SQL Server 7.0 and Exchange 5.5 SP2
316749 PRB: PRB: There May Not Be Enough Virtual Memory with Large Number of Databases

Priority Boost

Die Standardeinstellung für priority boost ist 0, d.h., SQL Server läuft mit normaler Priorität, unabhängig davon, ob es sich um einen Uniprozessor-Computer oder einen symmetrischen Multiprozessor-Computer (SMP) handelt. Wenn Sie priority boost auf 1 setzen, läuft SQL Server mit hoher Priorität. Diese Einstellung bewirkt nicht, dass der SQL Server-Prozess mit höchster Betriebssystempriorität läuft.

Aktuelle Supporterfahrungen zeigen, dass Sie priority boost für eine gute Leistung nicht benötigen. Wenn Sie priority boost verwenden, so kann dies unter bestimmten Bedingungen den reibungslosen Serverbetrieb beeinträchtigen. Sie sollten die Einstellung nur in Ausnahmesituationen verwenden. Beispielsweise könnte der Microsoft Software Service die Einstellung priority boost zur Analyse eines Leistungsproblems verwenden.

WICHTIG: Verwenden Sie priority boost nicht bei Clusterservern, auf denen SQL Server läuft.

Set Working Set Size

Lassen Sie die Standardeinstellung für set working set size unverändert. Beim Standardwert 0 kann die virtuelle Speicherverwaltung in Windows NT oder Windows 2000 die Workingset-Größe von SQL Server ermitteln. Bei der Installation von SQL Server weist das Setup-Programm Windows NT oder Windows 2000 automatisch an, die Leistung für Netzwerkanwendungen zu optimieren. Die Verwaltung des virtuellen Speichers in Windows NT oder Windows 2000 wird also die Workingset-Größe nur minimal verringern, wodurch das Workingset der SQL Server-Instanzen nur geringfügig beeinträchtigt wird.

Das Ändern dieser Einstellung bringt in der Regel keine Leistungsverbesserung mit sich. Aktuelle Supportfälle zeigen, dass das Ändern dieser Einstellung in der Regel mehr schadet als nützt.

Wenn Sie die Einstellung set working set size ändern, so kann dies auch die Ursache für die SQL Server-Fehlermeldungen 844 oder 845 sein. Im Abschnitt "Informationsquellen" in diesem Artikel finden Sie weitere Informationen zu den häufigsten Gründen für die Fehlermeldungen 844 und 845.

Informationsquellen

Weitere Informationen finden Sie in folgenden Artikeln der Microsoft Knowledge Base:
310834 PRB: Common Causes of Error Message 844 or Error Message 845
298475 INF: Informationen, die für eine erfolgreiche Lösung von Performanzproblemen einer Anwendung erforderlich sind
243589 SO WIRD'S GEMACHT: Fehlerbehandlung bei langsamen Abfragen auf SQL Server 7.0 oder höher
243588 INF: Troubleshooting Performance of Ad-Hoc Queries
224587 INF: Troubleshooting Application Performance with SQL Server
166967 INF: Proper SQL Server 6.5 Configuration Settings
254321 INF: Clustered SQL Server Do's, Don'ts, and Basic Warnings
297864 INF: Performance Considerations for Upgrade from SQL Server 6.5

Eigenschaften

Artikel-ID: 319942 - Geändert am: Dienstag, 23. September 2003 - Version: 2.2
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
Keywords: 
kbhowto kbhowtomaster KB319942
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.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com