Handbuch zur Thread- und Taskarchitektur

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance

Planung von Betriebssystemtasks

Threads sind die kleinsten Verarbeitungseinheiten, die von einem Betriebssystem ausgeführt werden, und ermöglichen die Trennung der Anwendungslogik in mehrere gleichzeitige Ausführungspfade. Threads sind insbesondere dann hilfreich, wenn komplexe Anwendungen viele Tasks aufweisen, die gleichzeitig ausgeführt werden können.

Wenn ein Betriebssystem eine Instanz einer Anwendung ausführt, wird eine als Prozess bezeichnete Einheit erstellt, um die Instanz zu verwalten. Der Prozess besitzt einen so genannten Ausführungsthread. Dabei handelt es sich um eine Folge von Programmieranweisungen, die vom Anwendungscode ausgeführt werden. Wenn beispielsweise eine einfache Anwendung eine einzige Gruppe von Anweisungen umfasst, die seriell ausgeführt werden können, wird diese Gruppe von Anweisungen als ein einzelner Task behandelt, und es gibt lediglich einen Ausführungspfad (bzw. Thread) durch die Anwendung. Komplexere Anwendungen können mehrere Tasks aufweisen, die gleichzeitig statt seriell ausgeführt werden können. Eine Anwendung kann dies tun, indem sie für jeden Task gesonderte Prozesse startet, was ein ressourcenintensiver Vorgang ist, oder einzelne Threads startet, die vergleichsweise weniger ressourcenintensiv sind. Außerdem kann das Ausführen der einzelnen Threads unabhängig von anderen Threads geplant werden, die einem Prozess zugeordnet sind.

Threads ermöglichen, dass komplexe Anwendungen Prozessoren (CPUs) effizienter nutzen, selbst auf Computern mit nur einer CPU. Bei einer einzigen CPU kann zu einem bestimmten Zeitpunkt immer nur ein Thread ausgeführt werden. Wenn ein Thread einen umfangreiche Vorgang ausführt, für die die CPU nicht verwendet wird, z. B. beim Lesen oder Schreiben vom bzw. auf den Datenträger, kann so lange ein anderer Thread ausgeführt werden, bis der erste Vorgang beendet ist. Da es möglich ist, Threads auszuführen, während andere Threads auf das Abschließen eines Vorgangs warten, kann eine Anwendung die CPU optimal nutzen. Dies gilt insbesondere für Multibenutzeranwendungen mit umfangreichen E/A-Vorgängen, wie es bei einem Datenbankserver der Fall ist. Computer mit mehreren CPUs können pro CPU nur einen Thread gleichzeitig ausführen. Wenn ein Computer beispielsweise über acht CPUs verfügt, können gleichzeitig acht Threads ausgeführt werden.

Planen von SQL Server-Tasks

Im Rahmen von SQL Server ist eine Anforderung die logische Darstellung einer Abfrage oder eines Batches. Eine Anforderung stellt auch Vorgänge dar, die für Systemthreads erforderlich sind, wie z. B. Prüfpunkt- oder Protokollschreibvorgänge. Anforderungen existieren während ihrer gesamten Lebensdauer in verschiedenen Zuständen und können Wartezeiten anhäufen, wenn Ressourcen, die zur Ausführung der Anforderung erforderlich sind, nicht verfügbar sind, z. B. aufgrund von Sperren oder Latches. Weitere Informationen zu Anforderungszuständen finden Sie unter sys.dm_exec_requests.

Aufgaben

Ein Task stellt die Arbeitseinheit dar, die abgeschlossen werden muss, um die Anforderung zu erfüllen. Ein oder mehrere Tasks können einer einzelnen Anforderung zugewiesen werden.

• Parallele Anforderungen verfügen über mehrere aktive Tasks, die gleichzeitig anstatt seriell ausgeführt werden, einschließlich eines übergeordneten Tasks (bzw. koordinierenden Tasks) und mehrerer untergeordneter Tasks. Ein Ausführungsplan für eine parallele Anforderung kann serielle Branches umfassen, d. h. Bereiche des Plans mit Operatoren, die nicht parallel ausgeführt werden. Der übergeordnete Task ist auch für die Ausführung dieser seriellen Operatoren verantwortlich.
• Serielle Anforderungen verfügen während der Ausführung immer nur über einen einzigen aktiven Task. Tasks existieren während ihrer gesamten Lebensdauer in verschiedenen Zuständen. Weitere Informationen zu Zuständen von Tasks finden Sie unter sys.dm_os_tasks. Tasks im Zustand SUSPENDED warten darauf, dass Ressourcen, die für ihre Ausführung benötigt werden, verfügbar werden. Weitere Informationen zu wartenden Tasks finden Sie unter sys.dm_os_waiting_tasks.

Arbeitskräfte

Ein Arbeitsthread in SQL Server, auch bekannt als Worker oder Thread, ist eine logische Darstellung eines Betriebssystem-Threads. Bei der Ausführung serieller Anforderungen erzeugt die SQL Server-Datenbank-Engine einen Worker, um den aktiven Task (1:1) auszuführen. Bei der Ausführung paralleler Anforderungen im Zeilenmodus weist die SQL Server-Datenbank-Engine einen Worker zu, der die untergeordneten Worker koordiniert, die für die Ausführung (ebenfalls 1:1) der ihnen zugewiesenen Tasks zuständig sind. Dies wird als übergeordneter Thread (oder koordinierender Thread) bezeichnet. Dem übergeordneten Thread ist ein übergeordneter Task zugeordnet. Der übergeordnete Thread ist der Einstiegspunkt der Anforderung und ist auch vorhanden, bevor die Engine eine Abfrage analysiert. Die Hauptaufgaben des übergeordneten Threads lauten:

• Koordinieren eines parallelen Scans
• Starten paralleler untergeordneter Worker.
• Erfassen von Zeilen von parallelen Threads und Senden dieser an den Client
• Durchführen lokaler und globaler Aggregationen

Die Anzahl der Arbeitsthreads, die für jeden Task erzeugt werden, hängt von folgenden Faktoren ab:

• Ob die Anforderung entsprechend der Bestimmung durch den Abfrageoptimierer für Parallelität geeignet war.

• Wie hoch der tatsächlich verfügbare Grad an Parallelität (Degree Of Parallelism, DOP) im System basierend auf der aktuellen Last ist. Dies kann vom geschätzten DOP abweichen, der auf der Serverkonfiguration des maximalen Grads an Parallelität (MAXDOP) basiert. So kann beispielsweise die Serverkonfiguration für MAXDOP 8 sein, aber der zur Laufzeit verfügbare DOP kann nur 2 sein, was die Abfrageleistung beeinträchtigt. Speicherauslastung und Mangel an Workern sind zwei Faktoren, die den verfügbaren DOP zur Laufzeit reduzieren.

Zeitplaner

Ein Planer, auch bekannt als SOS-Planer, verwaltet Arbeitsthreads, die Verarbeitungszeit benötigen, um Aufgaben im Rahmen von Tasks auszuführen. Jeder Planer ist einem einzelnen Prozessor (CPU) zugeordnet. Die Zeit, die ein Worker in einem Planer aktiv bleiben kann, wird als Betriebssystemquantum bezeichnet, wobei das Maximum bei 4 ms liegt. Nach Ablauf seiner Quantumzeit gibt ein Worker seine Zeit an andere Worker weiter, die auf CPU-Ressourcen zugreifen müssen, und ändert seinen Zustand. Diese Zusammenarbeit zwischen Workern zur Maximierung des Zugriffs auf CPU-Ressourcen wird als kooperative Planung oder auch nicht präemptive Planung bezeichnet. Die Änderung des Workerzustands wiederum wird an den Task, der diesem Worker zugeordnet ist, und an die mit dem Task verbundene Anforderung weitergegeben. Weitere Informationen zu Zuständen von Workern finden Sie unter sys.dm_os_workers. Weitere Informationen zu Planern finden Sie unter sys.dm_os_schedulers.

Zusammenfassend kann eine Anforderung eine oder mehrere Tasks erzeugen, um Arbeitseinheiten auszuführen. Jeder Task wird einem Arbeitsthread zugewiesen, der für das Abschließen des Tasks zuständig ist. Jeder Arbeitsthread muss für die aktive Ausführung des Tasks geplant (d. h. auf einem Scheduler platziert) werden.

Nehmen Sie das folgende Szenario als Beispiel:

• Worker 1 ist ein Task mit langer Ausführungszeit, z. B. eine Leseabfrage, die Read-Ahead für datenträgerbasierte Tabellen verwendet. Worker 1 stellt fest, dass die erforderlichen Datenseiten bereits im Pufferpool vorhanden sind, sodass er nicht auf E/A-Vorgänge warten muss und sein vollständiges Quantum nutzen kann, bevor Ergebnisse geliefert werden.
• Worker 2 führt kürzere Tasks mit einer Dauer unter einer Millisekunde aus und muss daher vor dem Erreichen des vollständigen Quantums Ergebnisse zurückgeben.

In diesem Szenario und bis SQL Server 2014 (12.x) kann Worker 1 den Planer im Grunde durch eine höhere gesamte Quantumzeit monopolisieren.

Ab SQL Server 2016 (13.x) umfasst die kooperative Planung die LDF-Planung (Large Deficit First). Bei der LDF-Planung werden die Quantumverwendungsmuster überwacht, und ein Workerthread monopolisiert keinen Scheduler. In demselben Szenario ist es für Worker 2 zulässig, wiederholte Quantums zu nutzen, bevor Worker 1 mehr Quantum nutzen darf, sodass Worker 1 daran gehindert wird, den Planer mit einem unfreundlichen Muster zu monopolisieren.

Planen von parallelen Tasks

Angenommen, ein SQL Server ist mit MaxDOP 8 konfiguriert, und die CPU-Affinität ist für 24 CPUs (Planer) zwischen den NUMA-Knoten 0 und 1 konfiguriert. Die Scheduler 0 bis 11 gehören zum NUMA-Knoten 0, die Scheduler 12 bis 23 zum NUMA-Knoten 1. Eine Anwendung sendet die folgende Abfrage (Anforderung) an die Datenbank-Engine:

SELECT h.SalesOrderID,
    h.OrderDate,
    h.DueDate,
    h.ShipDate
FROM Sales.SalesOrderHeaderBulk AS h
INNER JOIN Sales.SalesOrderDetailBulk AS d
    ON h.SalesOrderID = d.SalesOrderID
WHERE (h.OrderDate >= '2014-3-28 00:00:00');

Der Ausführungsplan zeigt einen Hashjoin zwischen zwei Tabellen sowie alle parallel ausgeführten Operatoren, wie dies durch den gelben Kreis mit den beiden Pfeilen angegeben wird. Jeder Parallelitätsoperator ist ein anderer Branch im Plan. Daher gibt es im folgenden Ausführungsplan drei Branches.

Zwar enthält der Ausführungsplan drei Branches, während der Ausführung können jedoch immer nur zwei Branches gleichzeitig in diesem Ausführungsplan ausgeführt werden:

1. Der Branch, in dem ein Clustered Index Scan für Sales.SalesOrderHeaderBulk (Buildeingabe des Joins) verwendet wird, wird allein ausgeführt.
2. Der Branch, in dem ein gruppierter Indexscan im Sales.SalesOrderDetailBulk (Testeingabe des Joins) verwendet wird, wird dann gleichzeitig mit dem Branch ausgeführt, in dem die Bitmap erstellt wurde und in dem zur selben Zeit der Hashvergleich ausgeführt wird.

Die Showplan XML-Ereignisklasse zeigt an, dass 16 Workerthreads reserviert und auf den NUMA-Knoten 0 verwendet wurden:

<ThreadStat Branches="2" UsedThreads="16">
  <ThreadReservation NodeId="0" ReservedThreads="16" />
</ThreadStat>

Die Threadreservierung stellt sicher, dass die Datenbank-Engine über genügend Arbeitsthreads verfügt, um alle Tasks auszuführen, die für die Anforderung benötigt werden. Threads können für mehrere NUMA-Knoten oder nur in einem NUMA-Knoten reserviert werden. Die Threadreservierung erfolgt zur Laufzeit vor Beginn der Ausführung und hängt von der Auslastung des Schedulers ab. Die Anzahl der reservierten Arbeitsthreads wird generisch mithilfe der Formel concurrent branches * runtime DOP ermittelt und schließt den übergeordneten Arbeitsthread aus. Jeder Branch ist auf eine Anzahl von Arbeitsthreads beschränkt, die MAXDOP entspricht. In diesem Beispiel gibt es zwei gleichzeitige Branches, und MAXDOP ist auf 8 festgelegt, daher gilt 2 * 8 = 16.

Beachten Sie als Referenz den Live-Ausführungsplan im Artikel Live-Abfragestatistik, bei dem ein Branch abgeschlossen ist und zwei Branches gleichzeitig ausgeführt werden.

Die SQL Server-Datenbank-Engine weist einen Arbeitsthread zum Ausführen eines aktiven Tasks (1:1) zu. Dies kann während der Abfrageausführung beobachtet werden, indem die DMV sys.dm_os_tasks wie im folgenden Beispiel gezeigt abgefragt wird:

SELECT parent_task_address, task_address,
       task_state, scheduler_id, worker_address
FROM sys.dm_os_tasks
WHERE session_id = <insert_session_id>
ORDER BY parent_task_address, scheduler_id;

Hier sehen Sie das Ergebnis. Beachten Sie, dass es für die aktuell ausgeführten Branches 17 aktive Tasks gibt: 16 untergeordnete Tasks, die den reservierten Threads entsprechen, sowie den übergeordneten Task oder koordinierenden Task.

Beachten Sie, dass jedem der 16 untergeordneten Tasks ein anderer Arbeitsthread zugewiesen ist (siehe Spalte worker_address), aber alle Worker demselben Pool von acht Schedulern (0, 5, 6, 7, 8, 9, 10, 11) zugewiesen sind, und dass der übergeordnete Tasks einem Scheduler außerhalb dieses Pools (3) zugewiesen ist.

Ein Arbeitsthread kann im Planer nur während seines Quantums (4 ms) aktiv bleiben und muss seinen Planer nach Ablauf dieses Quantums anhalten, sodass möglicherweise ein Arbeitsthread aktiv wird, der einem anderen Task zugewiesen ist. Wenn das Quantum eines Workers abläuft und nicht mehr aktiv ist, wird der betreffende Task im Status RUNNABLE in einer FIFO-Warteschlange abgelegt, bis er wieder in den Status RUNNING wechselt. Dabei wird vorausgesetzt, dass der Task keinen Zugriff auf Ressourcen benötigt, die momentan nicht verfügbar sind, z. B. ein Latch oder eine Sperre. Andernfalls würde der Task nicht in den Status RUNNABLE, sondern in den Status SUSPENDED versetzt, bis die Ressourcen verfügbar sind.

Zusammenfassend erzeugt eine parallele Anforderung mehrere Tasks. Jeder Task muss einem einzelnen Arbeitsthread zugewiesen werden. Jeder Arbeitsthread muss einem einzelnen Scheduler zugewiesen werden. Daher kann die Anzahl der verwendeten Planer nicht die Anzahl der parallelen Tasks pro Branch überschreiten, die durch die MaxDOP-Konfiguration oder einen Abfragehinweis festgelegt ist. Der koordinierende Thread trägt nicht zum MaxDOP-Limit bei.

Thread-Zuordnung zu CPUs

Standardmäßig startet jede Instanz von SQL Server jeden Thread, und das Betriebssystem verteilt Threads von SQL Server-Instanzen je nach Last auf die Prozessoren (CPUs) eines Computers. Wenn Prozessaffinität auf Betriebssystemebene aktiviert wurde, weist das Betriebssystem jeden Thread einer bestimmten CPU zu. Im Gegensatz dazu weist die SQL Server-Datenbank-Engine SQL Server-Arbeitsthreads zu Planern zu, die die Threads gleichmäßig auf die CPUs verteilen (im Roundrobin-Verfahren).

Um Multitasking zu ermöglichen, z. B. wenn mehrere Anwendungen auf dieselbe CPU-Gruppe zugreifen, verschiebt das Betriebssystem mitunter Arbeitsthreads zwischen verschiedenen CPUs. Obwohl dieses Vorgehen hinsichtlich des Betriebssystems effizient ist, kann es die Leistung von SQL Server bei starker Systemauslastung beeinträchtigen, da jeder Prozessorcache wiederholt mit Daten beladen wird. Durch das Zuweisen von CPUs für bestimmte Threads kann unter diesen Bedingungen die Leistung verbessert werden, weil das erneute Laden von Daten in den Prozessor entfällt und die Threadmigration zwischen CPUs reduziert wird (wodurch der Kontextwechsel reduziert wird). Diese Zuordnung zwischen einem Thread und einem Prozessor wird als Prozessoraffinität bezeichnet. Wenn Affinität aktiviert wurde, weist das Betriebssystem jeden Thread einer bestimmten CPU zu.

Die Affinitätsmaskenoption wird mit ALTER SERVER CONFIGURATION festgelegt. Wenn die Affinitätsmaske nicht festgelegt wird, ordnet die SQL Server-Instanz den Zeitplanungsmodulen, die nicht durch die Maske ausgeschlossen werden, gleichmäßig Arbeitsthreads zu.

Threadpools erleichtern das Optimieren der Leistung, wenn sehr viele Clients mit dem Server verbunden sind. Üblicherweise wird ein separater Betriebssystem-Thread für jede Abfrageanforderung erstellt. Wenn jedoch bei Hunderten von Verbindungen mit dem Server weiterhin ein Thread pro Abfrageanforderung verwendet wird, kann dabei eine große Menge an Systemressourcen verbraucht werden. Die Option Max. Anzahl von Arbeitsthreads ermöglicht SQL Server das Erstellen eines Pools mit Arbeitsthreads, der eine große Anzahl von Abfrageanforderungen versorgen kann und so zur Verbesserung der Leistung beiträgt.

Verwenden der Lightweightpooling-Option

Das Wechseln zwischen Threadkontexten stellt möglicherweise keinen sehr großen Aufwand dar. Für die meisten Instanzen von SQL Server stellt es keinen Leistungsunterschied dar, ob die Option für Lightweightpooling auf 0 oder 1 festgelegt ist. Die einzigen Instanzen von SQL Server, die möglicherweise von Lightweightpooling profitieren, sind diejenigen, die auf einem Computer mit folgenden Eigenschaften ausgeführt werden:

• Ein großer Server mit mehreren CPUs.
• Alle CPUs werden mit nahezu maximaler Kapazität ausgeführt.
• Eine große Anzahl an Kontextwechseln findet statt.

Für diese Systeme kann eventuell eine geringe Leistungssteigerung erzielt werden, indem der Wert für Lightweightpooling auf 1 festgelegt wird.

Thread- und Fiberausführung

Von Microsoft Windows wird ein numerisches Prioritätssystem verwendet, das von 1 bis 31 reicht, um die Ausführung von Threads zu planen. Null ist für die Verwendung durch das Betriebssystem reserviert. Wenn mehrere Threads auf die Ausführung warten, sendet Windows den Thread mit der höchsten Priorität.

Standardmäßig hat jede Instanz von SQL Server die Priorität 7, was als normale Priorität bezeichnet wird. Die Priorität von SQL Server-Threads ist somit hoch genug, um ausreichend CPU-Ressourcen zu erhalten, ohne jedoch im Gegenzug andere Anwendungen zu beeinträchtigen.

Mithilfe der Konfigurationsoption Prioritätserhöhung kann die Priorität der Threads von einer Instanz von SQL Server auf 13 heraufgesetzt werden. Diese Einstellung wird als "hohe Priorität" bezeichnet. Durch diese Einstellung erhalten SQL Server-Threads eine höhere Priorität als die meisten anderen Anwendungen. SQL Server-Threads werden somit im Allgemeinen verteilt, sobald sie zur Ausführung bereit sind, und müssen nicht für Threads anderer Anwendungen zurücktreten. Auf diese Weise kann die Leistung gesteigert werden, wenn ein Server nur Instanzen von SQL Server und keine anderen Anwendungen ausführt. Wenn jedoch eine arbeitsspeicherintensive Operation in SQL Server durchgeführt wird, verfügen andere Anwendungen in der Regel nicht über eine ausreichend hohe Priorität, um Vorrang vor dem SQL Server-Thread zu besitzen.

Falls Sie mehrere Instanzen von SQL Server auf einem Computer ausführen und die Prioritätserhöhung nur für einige Instanzen aktiviert ist, kann die Leistung von Instanzen, die mit normaler Priorität ausgeführt werden, beeinträchtigt werden. Auch kann die Leistung anderer Anwendungen und Komponenten auf dem Server beeinträchtigt werden, wenn die Prioritätserhöhung aktiviert ist. Diese Option sollte somit nur in genau kontrollierten Situationen verwendet werden.

Hinzufügen von CPUs bei laufendem Systembetrieb

Hinzufügen von CPUs im laufenden Systembetrieb bedeutet, dass Sie CPUs dynamisch hinzufügen können, während das System ausgeführt wird. CPUs können auf verschiedene Weise hinzugefügt werden: physisch durch neue Hardware, logisch durch eine Onlinepartitionierung der Hardware oder virtuell über eine Virtualisierungsschicht. SQL Server unterstützt das Hinzufügen von CPUs im laufenden Systembetrieb.

Voraussetzungen für das Hinzufügen von CPUs im laufenden Systembetrieb:

• Die Hardware muss das Hinzufügen von CPUs zu einem laufenden System unterstützen.
• Erfordert eine unterstützte Version von Windows Server Datacenter oder Enterprise Edition. Ab Windows Server 2012 wird das Hinzufügen im laufenden Systembetrieb in der Standard Edition unterstützt.
• Erfordert die SQL Server Enterprise Edition.
• SQL Server kann nicht für die Verwendung von Soft-NUMA konfiguriert werden. Weitere Informationen zu Soft-NUMA finden Sie unter Soft-NUMA (SQL Server).

Neu hinzugefügte CPUs werden nicht automatisch von SQL Server verwendet. So wird verhindert, dass SQL Server CPUs verwendet, die aus einem anderen Grund hinzugefügt wurden. Führen Sie die RECONFIGURE -Anweisung aus, nachdem Sie CPUs hinzugefügt haben, damit die neuen CPUs von SQL Server als verfügbare Ressourcen erkannt werden.

Bewährte Methoden zum Ausführen von SQL Server auf Computern mit mehr als 64 CPUs

Zuweisung von Hardwarethreads zu CPUs

Verwenden Sie die Serverkonfigurationsoptionen Affinity Mask und Affinity64 Mask nicht, um Prozessoren an bestimmte Threads zu binden. Diese Optionen sind auf 64 CPUs beschränkt. Verwenden Sie stattdessen die Option SET PROCESS AFFINITY von ALTER SERVER CONFIGURATION.

Verwaltung der Größe der Transaktionsprotokolldatei

Verlassen Sie sich nicht auf automatische Vergrößerung, um die Transaktionsprotokolldatei zu vergrößern. Das Vergrößern des Transaktionsprotokolls muss ein serieller Prozess sein. Das Erweitern des Protokolls kann bis zum Abschließen der Protokollerweiterung verhindern, dass Transaktionsschreibvorgänge fortgeführt werden. Weisen Sie stattdessen allen Protokolldateien im Voraus Speicherplatz zu, indem Sie die Dateigröße auf einen Wert festlegen, der hoch genug ist, um der typischen Arbeitsauslastung in der Umgebung gerecht zu werden.

Festlegen des maximalen Grads an Parallelität für Indexvorgänge

Die Leistung von Indexvorgängen, z. B. das Erstellen bzw. das erneute Erstellen von Indizes, kann auf Computern mit vielen CPUs verbessert werden, indem das Wiederherstellungsmodell der Datenbank vorübergehend entweder auf das massenprotokollierte oder auf das einfache Wiederherstellungsmodell festgelegt wird. Diese Indexvorgänge können eine bedeutende Protokollaktivität generieren, und Protokollkonflikte können sich auf den besten Grad an Parallelität (Degree of Parallelism, DOP) von SQL Server auswirken.

Zusätzlich zum Anpassen der Serverkonfigurationsoption Max. Grad an Parallelität (MAXDOP) sollten Sie die Parallelität für Indexvorgänge mit der Option MAXDOP anpassen. Weitere Informationen finden Sie unter Konfigurieren von Parallelindexvorgängen. Weitere Informationen und Leitlinien zum Anpassen des maximalen Grads an Parallelität finden Sie unter Konfigurieren der Serverkonfigurationsoption Max. Grad an Parallelität.

Option Maximale Anzahl von Arbeitsthreads

SQL Server konfiguriert beim Start dynamisch die Serverkonfigurationsoption Max. Anzahl von Arbeitsthreads. SQL Server verwendet die Anzahl verfügbarer CPUs und die Systemarchitektur, um diese Serverkonfiguration während des Startvorgangs unter Verwendung einer dokumentierten Formel zu bestimmen.

Diese Option ist eine erweiterte Option und sollte ausschließlich von einem erfahrenen Datenbankadministrator oder einem zertifizierten SQL Server -Experten geändert werden. Wenn Sie ein Leistungsproblem vermuten, ist es wahrscheinlich nicht die Verfügbarkeit von Arbeitsthreads. Eine wahrscheinlichere Ursache ist z.B. E/A, die ein Warten der Arbeitsthreads bewirkt. Sinnvollerweise sollten Sie die Grundursache eines Leistungsproblems ermitteln, bevor Sie die Einstellung für die maximale Anzahl der Arbeitsthreads ändern. Wenn Sie jedoch die maximale Anzahl der Arbeitsthreads manuell festlegen müssen, muss dieser Konfigurationswert stets auf einen Wert festgelegt werden, der mindestens das Siebenfache der Anzahl der CPUs des Systems beträgt. Weitere Informationen finden Sie unter Konfigurieren der Serverkonfigurationsoption „Maximale Anzahl von Arbeitsthreads“.

Vermeiden der Verwendung von SQL-Ablaufverfolgung und SQL Server Profiler

Es wird davon abgeraten, die SQL-Ablaufverfolgung und SQL Profiler in einer Produktionsumgebung zu verwenden. Der Aufwand zum Ausführen dieser Tools nimmt mit zunehmender Anzahl von CPUs zu. Wenn Sie die SQL-Ablaufverfolgung in einer Produktionsumgebung verwenden müssen, sollten Sie die Anzahl der Ablaufverfolgungsereignisse auf ein Minimum beschränken. Erstellen Sie für jedes Ablaufverfolgungsereignis ein Profil, und führen Sie einen Auslastungstest durch. Vermeiden Sie es, Ereignisse zu kombinieren, die die Leistung stark beeinträchtigen.

Festlegen der Anzahl von tempdb-Datendateien

Die Anzahl der Dateien hängt von der Anzahl der (logischen) Prozessoren auf dem Computer ab. Als allgemeine Regel gilt: Verwenden Sie die Anzahl von Datendateien, die der Anzahl von logischen Prozessoren entspricht, falls die Anzahl von logischen Prozessoren acht oder weniger beträgt. Verwenden Sie acht Datendateien, wenn die Anzahl von logischen Prozessoren größer als acht ist. Falls weiterhin ein Konflikt besteht, erhöhen Sie die Anzahl von Datendateien um ein Vielfaches von vier, bis der Konflikt auf ein akzeptables Ausmaß reduziert ist, oder ändern Sie die Workload bzw. den Code. Beachten Sie auch andere Empfehlungen für tempdb, die unter Optimieren der tempdb-Leistung in SQL Server verfügbar sind.

Sie können den Aufwand für die Datenbankverwaltung jedoch reduzieren, indem Sie die Parallelitätsanforderungen von tempdb sorgfältig überdenken. Wenn ein System beispielsweise über 64 CPUs verfügt und tempdb in der Regel nur von 32 Abfragen verwendet wird, lässt sich keine Leistungsverbesserung erzielen, indem die Anzahl der tempdb-Dateien auf 64 erhöht wird.

SQL Server-Komponenten, die mehr als 64 CPUs verwenden können

In der folgenden Tabelle sind SQL Server-Komponenten aufgeführt, und es wird angegeben, ob sie mehr als 64 CPUs verwenden können.