Freigeben über

Leitfaden zur Architektur der Speicherverwaltung

  • Artikel

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

Windows-Manager für virtuellen Arbeitsspeicher

Die zugesicherten Bereiche des Adressraums werden vom Windows-Manager für virtuellen Arbeitsspeicher (VMM, Virtual Memory Manager) dem verfügbaren physischen Arbeitsspeicher zugeordnet.

Weitere Informationen zur von anderen Betriebssystemen unterstützten Größe des physischen Speichers finden Sie in der Windows-Dokumentation Arbeitsspeichergrenzwerte für Windows-Versionen (möglicherweise in englischer Sprache).

Mit virtuellen Speichersystemen kann mehr physischer Arbeitsspeicher zugesichert werden, als tatsächlich vorhanden ist, sodass das Verhältnis von virtuellem zu physischem Arbeitsspeicher das Verhältnis 1:1 überschreiten kann. Auf diese Weise können größere Programme auf Computern mit verschiedenen Konfigurationen des physischen Arbeitsspeichers ausgeführt werden. Wenn jedoch deutlich mehr virtueller Arbeitsspeicher verwendet wird, als die kombinierten durchschnittlichen Workingsets aller Prozesse verwenden, kann dies zu einem ungünstigen Leistungsverhalten führen.

SQL Server-Arbeitsspeicherarchitektur

In SQL Server wird Arbeitsspeicher nach Bedarf dynamisch reserviert und freigegeben. Die Angabe des Arbeitsspeicherumfangs, der SQL Server zugeordnet werden soll, durch den Administrator ist in der Regel nicht erforderlich, obwohl die Möglichkeit weiterhin besteht und in einigen Umgebungen erforderlich ist.

Eines der vorrangigen Ziele beim Entwurf jeder Datenbanksoftware ist die Minimierung der Datenträger-E/A, da Lese- und Schreibvorgänge auf dem Datenträger zu den ressourcenintensivsten Vorgängen zählen. SQL Server erstellt einen Pufferpool im Arbeitsspeicher, um Seiten aufzunehmen, die aus der Datenbank gelesen werden. Ein großer Teil des Codes in SQL Server dient dazu, die Anzahl von physischen Lese- und Schreibvorgängen zwischen dem Datenträger und dem Pufferpool zu minimieren. SQL Server versucht, ein Gleichgewicht zwischen den beiden folgenden Zielen herzustellen:

  • Verhindern, dass der Pufferpool so groß wird, dass im gesamten System nicht genügend Arbeitsspeicher verfügbar ist.
  • Minimieren physischer E/A-Vorgänge in den Datenbankdateien durch Maximieren der Größe des Pufferpools.

Bei einem stark ausgelasteten System können umfangreiche Abfragen, die zum Ausführen sehr viel Arbeitsspeicher erfordern, nicht immer die Mindestmenge des angeforderten Arbeitsspeichers erhalten. Während auf die Arbeitsspeicherressourcen gewartet wird, wird deshalb ein Timeoutfehler erzeugt. Zur Behebung dieses Problems sollten Sie den Wert für die Option Abfragewartezeiterhöhen. Für eine parallele Abfrage können Sie den Wert für die Option Max. Grad an Parallelitätreduzieren.

Bei einem stark ausgelasteten System mit ungenügendem Arbeitsspeicher können Abfragen mit Zusammenführungsjoin, Sortierung und Bitmap im Abfrageplan zum Löschen der Bitmap führen, wenn für die Abfragen nicht der für die Bitmap erforderliche minimale Arbeitsspeicher verfügbar ist. Dies kann die Abfrageleistung beeinträchtigen. Wenn zudem der Sortierprozess nicht genügend Arbeitsspeicher erhält, kann dies zu einer erhöhten Verwendung von Arbeitstabellen in der tempdb-Datenbank tempdb führen, was ein Anwachsen von tempdb bewirkt. Um dieses Problem zu lösen, müssen Sie physischen Arbeitsspeicher hinzufügen oder die Abfragen so optimieren, dass Sie einen anderen und schnelleren Abfrageplan verwenden.

Konventioneller (virtueller) Speicher

Alle SQL Server-Editionen unterstützen konventionellen Speicher auf der 64-Bit-Plattform. Der SQL Server-Prozess kann auf den virtuellen Adressraum bis zum maximalen Betriebssystem für die x64-Architektur zugreifen (SQL Server Standard Edition unterstützt bis zu 128 GB). Bei der IA64-Architektur betrug der Grenzwert 7 TB (IA64 wird in SQL Server 2012 (11.x) und späteren Versionen nicht mehr unterstützt). Weitere Informationen finden Sie unter Arbeitsspeichergrenzen für Windows.

Speicher für Address Windows Extensions (AWE)

Mithilfe von Address Windowing Extensions (AWE) und Sperren von Seiten im Speicher (LPIM), die von AWE benötigt werden, können Sie den größten Teil des SQL Server-Prozessspeichers im physischen RAM unter Bedingungen mit geringem virtuellem Arbeitsspeicher sperren. Das passiert sowohl in 32-Bit- als auch in 64-Bit-AWE-Zuteilungen. Das Sperren des Arbeitsspeichers tritt auf, da der AWE-Speicher nicht den Manager für virtuellen Arbeitsspeicher in Windows durchläuft, der das Auslagern des Arbeitsspeichers steuert. Für die AWE-Speicherzuordnungs-API ist das Recht Sperren von Seiten im Speicher (SeLockMemoryPrivilege) erforderlich. Siehe Notizen zu AllocateUserPhysicalPages. Daher besteht der Hauptvorteil bei der Verwendung der AWE-API darin, den größten Teil des residenten Speichers im RAM zu behalten, wenn der Speicher des Systems ausgelastet ist. Informationen dazu, wie SQL Server die Verwendung von AWE zulassen kann, finden Sie unter Aktivieren der Option Sperren von Seiten im Speicher (Windows).

Wenn LPIM wird, wird dringend empfohlen, den maximalen Serverarbeitsspeicher (MB) auf einen bestimmten Wert festzulegen, anstatt den Standardwert von 2.147.483.647 Megabyte (MB) zu belassen. Weitere Informationen finden Sie unter Serverkonfiguration für den Serverspeicher: Manuelles Festlegen der Optionen und Sperren von Seiten im Speicher (LPIM).

Wenn LPIM nicht aktiviert ist, wechselt SQL Server zur Nutzung des konventionellen Arbeitsspeichers, und falls das Betriebssystem den Speicher auslastet und der Fehler [MSSQLSERVER_17890] (errors-events/mssqlserver-17890-database-engine-error.md) im Fehlerprotokoll gemeldet wird. Der Fehler ähnelt dem folgenden Beispiel:

A significant part of SQL Server process memory has been paged out. This may result in a performance degradation. Duration: #### seconds. Working set (KB): ####, committed (KB): ####, memory utilization: ##%.

Änderungen an der Speicherverwaltung ab SQL Server 2012

In älteren Versionen von SQL Server erfolgte die Speicherzuordnung mithilfe von fünf verschiedenen Mechanismen:

  • Einzelseitenbelegung (Single-Page Allocator, SPA), die im SQL Server-Prozess nur Speicherbelegungen umfasst, die kleiner als oder gleich 8 KB waren. Die Konfigurationsoptionen Max. Serverarbeitsspeicher (MB) und Min. Serverarbeitsspeicher (MB) bestimmten die Grenzen des vom SPA verbrauchten physischen Arbeitsspeichers. Der Pufferpool bildete zugleich den Mechanismus für SPA und den größten Verbraucher für Einzelseitenbelegungen.
  • Mehrseitenbelegung (Multi-Page Allocator, MPA) für Speicherbelegungen, die mehr als 8 KB erfordern.
  • CLR-Belegung, einschließlich des SQL CLR-Heaps und dessen globaler Belegungen, die während der CLR-Initialisierung erstellt werden.
  • Speicherbelegungen für Threadstapel im SQL Server-Prozess.
  • Direkte Windows-Belegungen (Direct Windows allocations, DWA) für Speicherbelegungsanforderungen, die direkt an Windows gerichtet sind. Dazu gehören die Windows-Heapnutzung und direkte virtuelle Belegungen von Modulen, die in den SQL Server-Prozess geladen werden. Beispiele für solche Speicherbelegungsanforderungen beinhalten Belegungen von DLLs erweiterter gespeicherter Prozeduren, Objekte, die mithilfe von Automatisierungsprozeduren (sp_OA-Aufrufen) erstellt werden, und Belegungen von verknüpften Serveranbietern.

Seit SQL Server 2012 (11.x) sind alle Einzelseitenbelegungen, Mehrseitenbelegungen und CLR-Belegungen in einer Seitenbelegung beliebiger Größe konsolidiert. Diese ist in den Speichergrenzwerten enthalten, die durch die Konfigurationsoptionen Max. Serverarbeitsspeicher (MB) und Min. Serverarbeitsspeicher (MB) gesteuert werden. Diese Änderung ermöglichte eine genauere Dimensionierung für alle Arbeitsspeicheranforderungen, die von der SQL Server-Arbeitsspeicherverwaltung verarbeitet werden.

Wichtig

Überprüfen Sie Ihre aktuellen Konfigurationen von Max. Serverarbeitsspeicher (MB) und Min. Serverarbeitsspeicher (MB) nach dem Upgrade auf SQL Server 2012 (11.x) und neueren Versionen. Das hat den Grund, dass diese Konfigurationen seit SQL Server 2012 (11.x) im Vergleich zu früheren Versionen jetzt mehr Arbeitsspeicherbelegungen umfassen. Diese Änderungen gelten sowohl für 32-Bit- als auch für 64-Bit-Versionen von SQL Server 2012 (11.x) und SQL Server 2014 (12.x) und 64-Bit-Versionen von SQL Server 2016 (13.x) und höhere Versionen.

In der folgenden Tabelle ist aufgeführt, ob ein bestimmter Typ von Speicherbelegung durch die Konfigurationsoptionen Max. Serverarbeitsspeicher (MB) und Min. Serverarbeitsspeicher (MB) gesteuert wird:

Typ der Speicherbelegung SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) und SQL Server 2008 R2 (10.50.x) Ab SQL Server 2012 (11.x)
Einzelseitenbelegungen Ja Ja, in Seitenbelegungen beliebiger Größe konsolidiert
Mehrseitenbelegungen No Ja, in Seitenbelegungen beliebiger Größe konsolidiert
CLR-Belegungen No Ja
Threadstapel-Arbeitsspeicher No No
Direkte Belegungen von Windows No No

SQL Server belegt möglicherweise mehr Speicher als in der Einstellung für den maximalen Serverspeicher angegeben

Ab SQL Server 2012 (11.x) weist SQL Server möglicherweise mehr Arbeitsspeicher als den in der Einstellung Max. Serverarbeitsspeicher (MB) angegebenen Wert zu. Dieses Verhalten kann auftreten, wenn der Wert für Serverspeicher gesamt (KB) bereits die Einstellung Zielserverspeicher (KB) erreicht hat, die als Max. Serverarbeitsspeicher (MB) angegeben ist. Wenn nicht ausreichend zusammenhängender freier Arbeitsspeicher vorhanden ist, um die Anforderung von Mehrseiten-Speicheranforderungen (mehr als 8 KB) zu bedienen, da der Arbeitsspeicher fragmentiert ist, kann SQL Server eine Zusage über den Grenzwert hinaus vornehmen, statt die Arbeitsspeicheranforderung zurückzuweisen.

Sobald diese Belegung vorgenommen wird, startet die Hintergrundaufgabe Ressourcenmonitor, um alle Arbeitsspeicherverbraucher aufzufordern, den belegten Arbeitsspeicher freizugeben, und versucht, den Wert von Serverspeicher gesamt (KB) unter die Angabe für Zielserverspeicher (KB) zu bringen. Aus diesem Grund kann die Arbeitsspeicherbelegung von SQL Server kurzzeitig den Wert der Einstellung Max. Serverarbeitsspeicher (MB) übersteigen. In dieser Situation überschreitet der gemeldete Wert des Leistungsindikators Serverspeicher gesamt (KB) die Einstellungen für Max. Serverarbeitsspeicher (MB) und Zielserverspeicher (KB).

Dieses Verhalten wird normalerweise während folgender Vorgänge beobachtet:

  • Umfangreiche Columnstore-Indexabfragen
  • Umfangreiche Abfragen im Batchmodus bei Rowstore
  • Erstellungen und Neuerstellungen des Columnstore-Index, die viel Arbeitsspeicher für die Ausführung von Hash- und Sortiervorgängen benötigen
  • Sicherungsvorgänge, die große Speicherpuffer erfordern
  • Ablaufverfolgungsvorgänge, die große Eingabeparameter speichern müssen
  • Anforderungen für große Speicherzuweisungen

Wenn Sie dieses Verhalten häufig beobachten, sollten Sie die Verwendung des Ablaufverfolgungsflag 8121 in sSQL Server 2019 (15.x) in Betracht ziehen, damit der Ressourcenmonitor schneller bereinigt werden kann. Ab SQL Server 2022 (16.x) ist diese Funktionalität standardmäßig aktiviert, und das Ablaufverfolgungsflag hat keine Auswirkungen.

Änderungen an memory_to_reserve ab SQL Server 2012

In älteren Versionen von SQL Server reservierte die SQL Server-Arbeitsspeicherverwaltung einen Teil des virtuellen Prozessadressbereichs (Process Virtual Address Space, VAS) für die Verwendung durch die Mehrseitenbelegung (Multi-Page Allocation, MPA), CLR-Belegung, Speicherbelegungen für Threadstapel im SQL Server-Prozess und Direkte Belegungen von Windows (Direct Windows Allocations, DWA). Dieser Teil des virtuellen Adressbereichs wird auch als „Zu belassender Arbeitsspeicher“ oder „Nicht-Pufferpool“-Bereich bezeichnet.

Der virtuelle Adressbereich, der für diese Belegungen reserviert ist, wird durch die Konfigurationsoption memory_to_reserve festgelegt. Der von SQL Server verwendete Standardwert ist 256 MB.

Da Speicherbelegungen oberhalb von 8 KB ebenfalls von der Seitenbelegung beliebiger Größe vorgenommen werden, schließt der Wert von memory_to_reserve die Mehrseitenbelegungen nicht ein. Von dieser Änderung abgesehen bleibt bei dieser Konfigurationsoption alles unverändert.

Der folgenden Tabelle können Sie entnehmen, ob ein bestimmter Typ Speicherbelegung in den Bereich memory_to_reserve des virtuellen Adressbereichs für den SQL Server-Prozess fällt:

Typ der Speicherbelegung SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) und SQL Server 2008 R2 (10.50.x) Ab SQL Server 2012 (11.x)
Einzelseitenbelegungen No Nein, in Seitenbelegungen beliebiger Größe konsolidiert
Mehrseitenbelegungen Ja Nein, in Seitenbelegungen beliebiger Größe konsolidiert
CLR-Belegungen Ja Ja
Threadstapel-Arbeitsspeicher Ja Ja
Direkte Belegungen von Windows Ja Ja

Dynamische Arbeitsspeicherverwaltung

Die Arbeitsspeicherverwaltung der SQL Server-Datenbank-Engine ruft standardmäßig so viel Arbeitsspeicher wie nötig ab, ohne dass es dabei zu einem Speicherengpass im System kommt. Die SQL Server Datenbank-Engine verwendet dazu die für Arbeitsspeicherbenachrichtigungen verfügbaren APIs in Microsoft Windows.

Bei dynamischer Verwendung des Arbeitsspeichers von SQL Server wird der im System verfügbare Arbeitsspeicher in regelmäßigen Abständen abgefragt. Bei Beibehaltung dieses freien Arbeitsspeichers werden Auslagerungsvorgänge durch das Betriebssystem verhindert. Wenn weniger freier Arbeitsspeicher vorhanden ist, gibt SQL Server Arbeitsspeicher für das Betriebssystem frei. Wenn mehr Arbeitsspeicher frei ist, kann SQL Server auch mehr Speicher reservieren. SQL Server fügt Arbeitsspeicher nur dann hinzu, wenn durch die Arbeitsauslastung mehr Arbeitsspeicher erforderlich ist. Bei einem ruhenden Server wird die Größe seines virtuellen Adressraums nicht vergrößert. Wenn Sie feststellen, dass der Task-Manager und Leistungsmonitor eine stetige Abnahme des verfügbaren Speichers zeigen, wenn SQL Server die dynamische Speicherverwaltung verwendet, ist dies das Standardverhalten und es sollte nicht als Arbeitsspeicherverlust verstanden werden.

Konfigurationsoptionen für den Serverarbeitsspeicher steuern die SQL Server-Speicherbelegung, die Arbeitsspeicherkompilierung, alle Caches (einschließlich Pufferpool), Arbeitsspeicherzuweisungen für die Abfrageausführung, Sperren-Manager-Speicher und CLR1-Speicher (im Wesentlichen alle Arbeitsspeicherclerks in sys.dm_os_memory_clerks).

1 CLR-Speicher wird seit SQL Server 2012 (11.x) unter max_server-memory-Belegungen verwaltet.

Die folgende Abfrage gibt Informationen über den aktuell belegten Arbeitsspeicher zurück:

SELECT physical_memory_in_use_kb / 1024 AS sql_physical_memory_in_use_MB,
       large_page_allocations_kb / 1024 AS sql_large_page_allocations_MB,
       locked_page_allocations_kb / 1024 AS sql_locked_page_allocations_MB,
       virtual_address_space_reserved_kb / 1024 AS sql_VAS_reserved_MB,
       virtual_address_space_committed_kb / 1024 AS sql_VAS_committed_MB,
       virtual_address_space_available_kb / 1024 AS sql_VAS_available_MB,
       page_fault_count AS sql_page_fault_count,
       memory_utilization_percentage AS sql_memory_utilization_percentage,
       process_physical_memory_low AS sql_process_physical_memory_low,
       process_virtual_memory_low AS sql_process_virtual_memory_low
FROM sys.dm_os_process_memory;

Stapelgrößen

Arbeitsspeicher für Threadstapel 1, CLR 2, DLL-Dateien von erweiterten Prozeduren, OLE DB-Anbieter, auf die verteilte Abfragen verweisen, Automatisierungsobjekte, auf die Transact-SQL-Anweisungen verweisen, und jede Art von Arbeitsspeicher, die von nicht zu SQL Server gehörenden DLLs belegt wird, werden nicht durch Max. Serverarbeitsspeicher (MB) gesteuert.

1 Informationen zu den standardmäßig berechneten Arbeitsthreads für eine bestimmte Anzahl kategorisierter CPUs auf dem aktuellen Host finden Sie im Artikel zum Konfigurieren der maximalen Anzahl von Arbeitsthreads (Serverkonfigurationsoption). Die Stapelgrößen für SQL Server sind wie folgt:

SQL Server-Architektur Betriebssystemarchitektur Stapelgröße
X86 (32-Bit) X86 (32-Bit) 512 KB
X86 (32-Bit) X64 (64-Bit) 768 KB
X64 (64-Bit) X64 (64-Bit) 2.048 KB
IA64 (Itanium) IA64 (Itanium) 4.096 KB

2 CLR-Speicher wird seit SQL Server 2012 (11.x) unter max_server-memory-Belegungen verwaltet.

Mithilfe der für Speicherbenachrichtigungen verfügbaren API QueryMemoryResourceNotification ermittelt SQL Server, wann der SQL Server-Speicher-Manager Speicher zuordnen oder freigeben kann.

Beim Starten berechnet SQL Server die Größe des virtuellen Adressraums für den Pufferpool auf Grundlage verschiedener Parameter, z. B. der Größe des physischen Arbeitsspeichers des Systems, der Anzahl der Serverthreads und verschiedener Startparameter. SQL Server reserviert die berechnete Größe des virtuellen Adressraumes für den Pufferpool, verwendet jedoch nur die für die aktuelle Last erforderliche Größe an physischem Arbeitsspeicher.

Die Instanz greift dann je nach Arbeitsauslastung auf weiteren Arbeitsspeicher zu. Wenn weitere Benutzer eine Verbindung herstellen und Abfragen ausführen, ruft SQL Server dem Bedarf entsprechend weiteren physischen Arbeitsspeicher ab. Eine SQL Server-Instanz ordnet so lange zusätzlichen physischen Arbeitsspeicher zu, bis entweder die Zielvorgabe Max. Serverarbeitsspeicher (MB) erreicht ist oder das Betriebssystem anzeigt, dass kein weiterer freier Arbeitsspeicher zur Verfügung steht. Die Instanz gibt Arbeitsspeicher frei, wenn die Einstellung für „Min. Serverarbeitsspeicher“ überschritten wird oder das Betriebssystem anzeigt, dass zu wenig freier Arbeitsspeicher vorhanden ist.

Sobald weitere Anwendungen auf einem Computer gestartet werden, auf dem eine Instanz von SQL Server ausgeführt wird, benötigen sie Arbeitsspeicher, sodass der Umfang des freien physischen Arbeitsspeichers auf einen Wert unter dem SQL Server-Ziel fällt. Die Instanz von SQL Server passt ihren Arbeitsspeicherverbrauch an. Wenn eine andere Anwendung beendet wird und mehr Arbeitsspeicher verfügbar wird, vergrößert die Instanz von SQL Server die Speicherbelegung. SQL Server kann mehrere MB Arbeitsspeicher pro Sekunde freigeben und reservieren, um schnell auf Änderungen der Speicherbelegung zu reagieren.

Auswirkungen der Konfigurationsoptionen Min. Serverarbeitsspeicher und Max. Serverarbeitsspeicher

Durch die Konfigurationsoptionen Min. Serverarbeitsspeicher und Max. Serverarbeitsspeicher werden die obere und untere Grenze für den Umfang des Speichers festgelegt, der vom Pufferpool und anderen Caches der Datenbank-Engine verwendet wird. Der Pufferpool reserviert nicht sofort die Menge an Speicher, die durch „Min. Serverarbeitsspeicher“ angegeben wurde. Der Pufferpool reserviert zuerst nur so viel Speicher, wie für die Initialisierung erforderlich ist. Mit ansteigender Arbeitsauslastung der SQL Server-Datenbank-Engine wird weiterer Speicher reserviert, um die Arbeitsauslastung zu unterstützen. Der Pufferpool gibt erst dann einen Teil des reservierten Speichers wieder frei, wenn der unter „Min. Serverarbeitsspeicher“ angegebene Wert erreicht wurde. Sobald „Min. Serverarbeitsspeicher“ erreicht ist, verwendet der Pufferpool den Standardalgorithmus, um Speicher nach Bedarf zu reservieren und freizugeben. Der einzige Unterschied besteht darin, dass der Pufferpool bei der Speicherbelegung nie unter die Ebene absinkt, die durch „Min. Serverarbeitsspeicher“ angegeben ist, und nie mehr Speicher reserviert, als durch die unter Max. Serverarbeitsspeicher (MB) angegebene Ebene angegeben ist.

Hinweis

SQL Server reserviert als Prozess mehr Speicher als durch die Option Max. Serverarbeitsspeicher (MB) angegeben wird. Sowohl interne als auch externe Komponenten können Speicher außerhalb des Pufferpools belegen. Dies führt zur Beanspruchung zusätzlicher Speicherkapazitäten. Der dem Pufferpool zugeordnete Speicher stellt jedoch weiterhin normalerweise den größten Teil des von SQL Server belegten Speichers dar.

Der Umfang des von der SQL Server-Datenbank-Engine reservierten Speichers hängt ausschließlich von der Arbeitsauslastung der jeweiligen Instanz ab. Eine SQL Server-Instanz, die nur wenige Anforderungen verarbeitet, erreicht von Min. Serverarbeitsspeicher spezifizierten Wert möglicherweise nie.

Wenn für „Min. Serverarbeitsspeicher“ und Max. Serverarbeitsspeicher (MB) derselbe Wert angegeben wurde, beendet die SQL Server-Datenbank-Engine die dynamische Freigabe und Zuordnung von Speicher für den Pufferpool, sobald der der SQL Server-Datenbank-Engine zugeordnete Speicher diesen Wert erreicht hat.

Wenn eine Instanz von SQL Server auf einem Computer ausgeführt wird, auf dem häufig andere Anwendungen gestartet oder beendet werden, kann das Starten anderer Anwendungen durch die Belegung und Freigabe von Speicher, die durch die Instanz von SQL Server vorgenommen wird, verlangsamt werden. Wenn SQL Server eine von mehreren Serveranwendungen ist, die auf einem einzelnen Computer ausgeführt werden, kann es darüber hinaus erforderlich sein, den Umfang des SQL Server zugeordneten Speichers von Systemadministratoren zu steuern. In solchen Fällen können Sie mithilfe der Optionen „Min. Serverarbeitsspeicher“ und Max. Serverarbeitsspeicher (MB) steuern, wie viel Speicher von SQL Server verwendet werden kann. Die Optionen Min. Serverarbeitsspeicher und Max. Serverarbeitsspeicher werden in Megabyte angegeben. Weitere Informationen, einschließlich Empfehlungen zum Festlegen dieser Speicherkonfigurationen, finden Sie unter Konfigurationsoptionen für den Serverarbeitsspeicher.

Spezifikationen für den von SQL Server-Objekten verwendeten Arbeitsspeicher

In der folgenden Liste werden die Richtwerte für den Arbeitsspeicher beschrieben, den die einzelnen Objekte in SQL Server in Anspruch nehmen. Die aufgeführten Angaben sind Schätzwerte und können je nach Umgebung und Erstellung der Objekte variieren:

  • Sperre (durch den Sperren-Manager verwaltet): 64 Byte + 32 Byte pro Besitzer
  • Benutzerverbindung: Etwa (3 * network_packet_size + 94 KB)

Die Netzwerkpaketgröße entspricht der Größe der TDS-Pakete (Tabular Data Stream), die für die Kommunikation zwischen Anwendungen und der Datenbank-Engine verwendet werden. Die Standardpaketgröße beträgt 4 KB und wird durch die Konfigurationsoption Netzwerkpaketgröße gesteuert.

Wenn mehrere aktive Resultsets (Multiple Active Result Sets, MARS) aktiviert sind, benötigt die Benutzerverbindung ca. (3 + 3 * num_logical_connections) * network_packet_size + 94 KB.

Auswirkungen von „Min. Arbeitsspeicher pro Abfrage“

Sie können mithilfe der Konfigurationsoption Min. Arbeitsspeicher pro Abfrage die Mindestmenge an Arbeitsspeicher (in KB) festlegen, die für das Ausführen einer Abfrage zugeordnet wird. Dies ist auch als minimale Arbeitsspeicherzuweisung bekannt. Alle Abfragen müssen warten, bis der mindestens erforderliche Arbeitsspeicher zugesichert werden kann oder bis der Wert überschritten wird, der in der Serverkonfigurationsoption „Abfragewartezeit“ angegeben ist, bevor die Ausführung gestartet wird. Der Wartetyp, der in diesem Szenario gesammelt wird, ist RESOURCE_SEMAPHORE.

Wichtig

Legen Sie die Konfigurationsoption Min. Arbeitsspeicher pro Abfrage nicht auf einen zu hohen Wert fest, insbesondere nicht auf stark ausgelasteten Systemen, da dadurch Folgendes verursacht werden kann:

  • Stärkerer Wettbewerb um Arbeitsspeicherressourcen.
  • Verringerte Parallelität durch den erhöhten Bedarf an Arbeitsspeicher für jede einzelne Abfrage, auch wenn zur Laufzeit weniger Arbeitsspeicher als in dieser Konfiguration erforderlich ist.

Empfehlungen zur Verwendung dieser Konfiguration finden Sie unter Konfigurieren der Serverkonfigurationsoption „Min. Arbeitsspeicher pro Abfrage“.

Überlegungen zur Arbeitsspeicherzuweisung

Für die Zeilenmodusausführung kann die ursprüngliche Arbeitsspeicherzuweisung nicht überschritten werden. Wenn mehr Arbeitsspeicher als ursprünglich zugewiesen erforderlich ist, um Hash- oder Sortiervorgänge durchzuführen, laufen diese Vorgänge auf den Datenträger über. Ein überlaufender Hashvorgang wird von einer Arbeitsdatei in tempdb unterstützt, während ein überlaufender Sortiervorgang von einer Arbeitstabelle unterstützt wird.

Ein Überlauf, der während eines Sortiervorgangs auftritt, wird als Ereignisklasse Sortierwarnung bezeichnet. Sortierwarnungen zeigen an, dass der Arbeitsspeicher für Sortiervorgänge nicht ausreicht. Darin sind keine Sortiervorgänge eingeschlossen, die die Indexerstellung beinhalten, sondern nur Sortiervorgänge innerhalb einer Abfrage (z. B. eine ORDER BY-Klausel in einer SELECT-Anweisung).

Ein Überlauf, der während eines Hashvorgangs auftritt, wird als Ereignisklasse Hashwarnung bezeichnet. Hashwarnungen treten auf, wenn während eines Hashvorgangs eine Hashrekursion oder eine Beendigung des Hashings (Hashabbruch) auftritt.

  • Die Hashrekursion tritt auf, wenn die Eingabe für den verfügbaren Arbeitsspeicher zu groß ist und deshalb auf mehrere Partitionen verteilt wird, die separat verarbeitet werden. Sollten diese Partitionen für den Arbeitsspeicher immer noch zu groß sein, werden sie in Unterpartitionen aufgeteilt, die dann ebenfalls separat verarbeitet werden. Dieser Vorgang wird so lange fortgesetzt, bis jede Partition in den verfügbaren Arbeitsspeicher passt oder die maximale Rekursionsebene erreicht ist.
  • Ein Hashabbruch tritt auf, wenn ein Hashvorgang die maximale Rekursionsebene erreicht hat und ein alternativer Plan verwendet wird, um die restlichen Partitionsdaten zu verarbeiten. Diese Ereignisse können zu verringerter Leistung auf Ihrem Server führen.

Für die Batchmodusausführung kann die ursprüngliche Arbeitsspeicherzuweisung standardmäßig bis zu einem bestimmten internen Schwellenwert dynamisch erhöht werden. Dieser Mechanismus der dynamischen Arbeitsspeicherzuweisung wurde dafür entwickelt, die speicherresidente Ausführung von Hash- und Sortiervorgängen im Batchmodus zu ermöglichen. Wenn diese Vorgänge immer noch zu viel Arbeitsspeicher erfordern, laufen sie auf den Datenträger über.

Weitere Informationen zu den Ausführungsmodi finden Sie unter Handbuch zur Architektur der Abfrageverarbeitung.

Pufferverwaltung

Der Hauptzweck einer SQL Server -Datenbank ist das Speichern und Abrufen von Daten. Daher stellt eine hohe Ein-/Ausgabe auf dem Datenträger ein Hauptmerkmal der Datenbank-Engine dar. Datenträger-E/A-Vorgänge beanspruchen viele Ressourcen und benötigen relativ viel Zeit für die Ausführung. Daher ist SQL Server so konzipiert, dass E/A-Vorgänge möglichst effizient gestaltet werden. Die Pufferverwaltung ist eine zentrale Komponente zum Erreichen dieser Effizienz. Die Pufferverwaltungskomponente weist zwei Mechanismen auf: den Puffer-Manager, mit dem auf Datenbankseiten zugegriffen wird und mit dem sie aktualisiert werden, und den Puffercache (auch als Pufferpool bezeichnet), mit dem Datenbankdatei-E/A-Vorgänge reduziert werden.

Eine ausführliche Erläuterung der Disk-E/A in SQL Server finden Sie in den Grundlagen zu SQL Server-E/A.

Funktionsweise der Pufferverwaltung

Ein Puffer ist eine 8-KB-Seite im Arbeitsspeicher. Dies entspricht der Größe einer Datenseite oder Indexseite. Der Puffercache ist ebenfalls in Seiten von je 8 KB unterteilt. Mit dem Puffer-Manager werden die Funktionen verwaltet, mit denen Daten- oder Indexseiten aus Datenbankdatenträgerdateien in den Puffercache geladen und geänderte Seiten zurück auf den Datenträger geschrieben werden. Eine Seite verbleibt im Puffercache, bis der Pufferbereich vom Puffer-Manager zum Laden weiterer Daten benötigt wird. Daten werden nur dann zurück auf den Datenträger geschrieben, wenn sie geändert wurden. Daten im Puffercache können mehrfach geändert werden, bevor sie zurück auf den Datenträger geschrieben werden. Weitere Informationen finden Sie unter Lesen von Seiten und Schreiben von Seiten.

Beim Starten berechnet SQL Server die Größe des virtuellen Adressraums für den Puffercache auf Grundlage verschiedener Parameter, z. B. der Größe des physischen Arbeitsspeichers des Systems, der konfigurierten Anzahl maximaler Serverthreads und verschiedener Startparameter. SQL Server reserviert die berechnete Größe des virtuellen Adressraums (das Arbeitsspeicherziel) für den Puffercache, verwendet jedoch nur die für die aktuelle Last erforderliche Größe an physischem Arbeitsspeicher. Sie können die Spalten committed_target_kb und committed_kb in der Katalogsicht der sys.dm_os_sys_info abfragen, um die Anzahl der als Arbeitsspeicherziel reservierten Seiten bzw. die Anzahl der Seiten zurückzugeben, die derzeit im Puffercache committet sind.

Das Intervall zwischen dem Start von SQL Server und dem Zeitpunkt, wenn der Puffercache sein Arbeitsspeicherziel erreicht hat, wird als „Anlaufprozess“ bezeichnet. In dieser Zeit wird der Puffer mit den erforderlichen Leseanforderungen gefüllt. Durch eine Leseanforderung für eine einzelne 8-KB-Seite wird beispielsweise eine einzelne Pufferseite gefüllt. Dies bedeutet, dass der Anlaufprozess von der Anzahl und der Art der Clientanforderungen abhängt. Dieser Prozess wird beschleunigt, indem Leseanforderungen für einzelne Seiten in ausgerichtete 8-Seiten-Anforderungen (die einen Block darstellen) transformiert werden. Dadurch kann der Anlaufprozess sehr viel schneller erfolgen, insbesondere auf Maschinen mit großem Arbeitsspeicher. Weitere Informationen zu Seiten und Blöcken finden Sie im Handbuch zur Architektur von Seiten und Blöcken.

Einen Großteil seines Arbeitsspeichers verwendet der Puffer-Manager im SQL Server-Vorgang. Daher erfolgt eine Zusammenarbeit zwischen Puffer-Manager und Speicher-Manager, damit auch andere Komponenten die Puffer verwenden können. Der Puffer-Manager interagiert vorrangig mit den folgenden Komponenten:

  • Resource Manager zur Steuerung der gesamten Speicherauslastung und (auf 32-Bit-Plattformen) zur Steuerung der Adressraumverwendung.
  • Datenbank-Manager und dem SQL Server-Betriebssystem (SQLOS) für Datei-E/A-Vorgänge auf niedriger Ebene.
  • Protokoll-Manager für Write-Ahead-Protokollierung.

Unterstützte Funktionen

Der Puffer-Manager unterstützt die folgenden Funktionen:

  • Der Puffer-Manager ist NUMA-fähig (Non-Uniform Memory Access). Außerdem werden Puffercacheseiten auf NUMA-Hardwareknoten verteilt, sodass ein Thread auf eine Pufferseite zugreifen kann, die dem lokalen NUMA-Knoten zugewiesen ist, statt den Zugriff über einen fremden Speicher vorzunehmen.

  • Der Puffer-Manager unterstützt das Hinzufügen von Arbeitsspeicher im laufenden Systembetrieb (Hot Add Memory), das dem Benutzer ermöglicht, physischen Arbeitsspeicher hinzuzufügen, ohne den Server neu starten zu müssen.

  • Es werden auch große Seiten auf 64-Bit-Plattformen vom Puffer-Manager unterstützt. Die Seitengröße ist spezifisch für die Version von Windows.

    Hinweis

    Vor SQL Server 2012 (11.x) erfordert das Aktivieren großer Seiten in SQL Server Ablaufverfolgungsflag 834.

  • Es werden vom Puffer-Manager weitere Diagnosen bereitgestellt, durch die dynamische Verwaltungssichten offengelegt werden. Mithilfe dieser Ansichten können Sie verschiedene für SQL Server spezifische Betriebssystemressourcen überwachen. Beispielsweise können Sie mithilfe der Sicht sys.dm_os_buffer_descriptors die Seiten im Puffercache überwachen.

Ermittlung hoher Arbeitsspeicherauslastung

Die hohe Arbeitsspeicherauslastung ist ein Zustand, der sich aus einem Speicherengpass ergibt und zu Folgendem führen kann:

  • Zusätzliche E/A-Vorgänge (z.B. sehr aktive LAZY WRITER-Hintergrundthreads)
  • Höheres Neukompilierungsverhältnis
  • Länger ausgeführte Abfragen (wenn Wartevorgänge für die Arbeitsspeicherzuweisung vorhanden sind)
  • Zusätzliche CPU-Zyklen

Diese Situation kann durch externe oder interne Ursachen ausgelöst werden. Folgende externe Ursachen sind möglich:

  • Wenig physischer Speicher (RAM) ist verfügbar. Dadurch kürzt das System die Workingsets der derzeit ausgeführten Prozesse, wodurch das gesamte System verlangsamt werden kann. SQL Server kann das Commit-Ziel des Pufferpools verringern und interne Caches häufiger kürzen.
  • Es ist insgesamt wenig Systemspeicher (einschließlich der Auslagerungsdatei des Betriebssystems) verfügbar. Dadurch schlagen Speicherbelegungen durch das System möglicherweise fehl, da der derzeit zugewiesene Arbeitsspeicher nicht ausgelagert werden kann.

Folgende interne Ursachen sind möglich:

  • Eine Reaktion auf die externe hohe Arbeitsspeicherauslastung, wenn die SQL Server-Datenbank-Engine niedrigere Obergrenzen für die Arbeitsspeicherauslastung festlegt.
  • Die Arbeitsspeichereinstellungen wurden manuell gesenkt, indem die Konfiguration Max. Serverarbeitsspeicher reduziert wurde.
  • Änderungen an der Arbeitsspeicherverteilung der internen Komponenten zwischen den verschiedenen Caches.

Die SQL Server-Datenbank-Engine implementiert ein Framework, das als Teil seiner dynamischen Speicherverwaltung für die Ermittlung und das Behandeln von hoher Arbeitsspeicherauslastung vorgesehen ist. Dieses Framework umfasst den Hintergrundtask namens Ressourcenmonitor. Der Task „Ressourcenmonitor“ überwacht den Status von externen und internen Arbeitsspeicherindikatoren. Sobald sich der Status einer dieser Indikatoren ändert, berechnet dieser die entsprechende Benachrichtigung und zeigt diese an. Bei diesen Benachrichtigungen handelt es sich um interne Meldungen für jede der Engine-Komponenten. Sie werden in Ringpuffern gespeichert.

Zwei Ringpuffer enthalten Informationen, die für die dynamische Speicherverwaltung relevant sind:

  • Der Ringpuffer „Ressourcenmonitor“, der die Aktivitäten des Ressourcenmonitor nachverfolgt, z.B. ob eine hohe Arbeitsspeicherauslastung signalisiert wurde oder nicht. Dieser Ringpuffer enthält Statusinformationen, die von der aktuellen Bedingung von RESOURCE_MEMPHYSICAL_HIGH, RESOURCE_MEMPHYSICAL_LOW, RESOURCE_MEMPHYSICAL_STEADY oder RESOURCE_MEMVIRTUAL_LOW abhängen.
  • Der Ringpuffer „Speicherbroker“, der Datensätze von Arbeitsspeicherbenachrichtigungen für jeden Resource Governor-Ressourcenpool enthält. Wenn eine interne hohe Arbeitsspeicherauslastung ermittelt wird, wird eine Benachrichtigung, dass wenig Arbeitsspeicher vorhanden ist, für Komponenten aktiviert, denen Arbeitsspeicher zugewiesen ist. Dadurch sollen Aktionen ausgelöst werden, die den Arbeitsspeicher zwischen Caches ausgleichen.

Speicherbroker überwachen den von jeder Komponente angeforderten Arbeitsspeicherverbrauch und berechnen dann auf Basis der gesammelten Informationen den optimalen Arbeitsspeicher für jede dieser Komponenten. Es gibt mehrere Broker für jeden Resource Governor-Ressourcenpool. Diese Information wird dann an jede der Komponenten übermittelt, und die Arbeitsspeichernutzung wird entsprechend erhöht oder gesenkt.

Weitere Informationen zu Speicherbrokern finden Sie unter sys.dm_os_memory_brokers.

Fehlererkennung

Von Datenbankseiten kann einer von zwei möglichen optionalen Mechanismen verwendet werden, mit dem die Integrität der Seite ab dem Zeitpunkt sichergestellt werden kann, an dem die Datei auf den Datenträger geschrieben wird, bis zu dem Zeitpunkt, wenn sie erneut gelesen wird: Schutz vor zerrissenen Seiten und Prüfsummenschutz. Anhand dieser Mechanismen kann die richtige Funktionsweise des Datenspeichers, der Hardwarekomponenten (Controller, Treiber, Kabel) und des Betriebssystems unabhängig geprüft werden. Der Schutz wird der Seite hinzugefügt, bevor sie auf den Datenträger geschrieben wird, und überprüft, wenn die Seite vom Datenträger gelesen wird.

SQL Server wiederholt Lesevorgänge, die wegen eines Prüfsummenfehlers, einer zerrissenen Seite oder eines anderen E/A-Fehlers fehlschlagen, viermal. Ist der Lesevorgang bei einem dieser Wiederholungsversuche erfolgreich, wird eine Meldung in das Fehlerprotokoll geschrieben, und der Befehl, der den Lesevorgang ausgelöst hat, wird fortgesetzt. Wenn die erneuten Versuche fehlschlagen, schlägt der Befehl mit dem Fehler MSSQLSERVER_824 fehl.

Die Art des verwendeten Seitenschutzes stellt ein Attribut der Datenbank dar, in der die Seite enthalten ist. Der Prüfsummenschutz stellt den Standardschutz für Datenbanken dar, die in SQL Server 2005 (9.x) und späteren Versionen erstellt wurden. Der Seitenschutzmechanismus wird beim Erstellen der Datenbank angegeben; er kann mithilfe von ALTER DATABASE SET modifiziert werden. Sie können den aktuellen Seitenschutz bestimmen, indem Sie eine Abfrage an die Spalte page_verify_option in der Katalogsicht sys.databases oder die IsTornPageDetectionEnabled-Eigenschaft der DATABASEPROPERTYEX-Funktion senden.

Hinweis

Bei einer Änderung der Seitenschutzeinstellungen haben die neuen Einstellungen nicht unmittelbar Auswirkungen auf die gesamte Datenbank. Stattdessen wird von Seiten die aktuelle Schutzebene der Datenbank übernommen, wenn der nächste Schreibvorgang für die Seite erfolgt. Dies bedeutet, dass in der Datenbank Seiten mit unterschiedlichem Schutz enthalten sein können.

Schutz vor zerrissenen Seiten

Der Schutz vor zerrissenen Seiten, der in SQL Server 2000 (8.x) eingeführt wurde, stellt in erster Linie eine Methode zum Erkennen von Seitenbeschädigungen dar, die auf Stromausfälle zurückzuführen sind. Beispielsweise kann der Fall eintreten, dass durch einen unerwarteten Stromausfall nur ein Teil einer Seite auf den Datenträger geschrieben wird. Wenn Schutz vor zerrissenen Seiten festgelegt ist, wird beim Schreiben der Seite auf den Datenträger für jeden Sektor von 512 Byte auf einer Datenbankseite von 8 KB ein bestimmtes 2-Bit-Signaturmuster gespeichert und im Kopf der Datenbankseite gespeichert.

Wenn die Seite vom Datenträger gelesen wird, werden die im Seitenkopf gespeicherten zerrissenen Bits mit den tatsächlichen Seitensektorinformationen verglichen. Das Signaturmuster wechselt bei jedem Schreibvorgang zwischen den Binärzuständen 01 und 10. Damit kann jederzeit ermittelt werden, ob nur ein Teil der Sektoren auf den Datenträger geschrieben wird: Wenn ein Bit beim späteren Lesen der Seite den falschen Zustand aufweist, wurde die Seite nicht richtig auf den Datenträger geschrieben, d.h., es wird eine zerrissene Seite ermittelt. Für die Erkennung von zerrissenen Seiten sind nur minimale Ressourcen erforderlich. Es werden jedoch keine Fehler erkannt, die durch Hardwarefehler des Datenträgers verursacht werden. Weitere Informationen zum Festlegen der Erkennung von zerrissenen Seiten finden Sie unter ALTER DATABASE SET-Optionen (Transact-SQL).

Prüfsummenschutz

Der Prüfsummenschutz, der in SQL Server 2005 (9.x) eingeführt wurde, ermöglicht eine verbesserte Datenintegritätsprüfung. Eine Prüfsumme wird für die Daten berechnet, die in den einzelnen Seiten geschrieben werden, und im Seitenkopf gespeichert. Wenn eine Seite, deren Prüfsumme gespeichert wird, vom Datenträger gelesen wird, wird von der Datenbank-Engine die Prüfsumme für die Daten in der Seite neu berechnet. Wenn die neue Prüfsumme von der gespeicherten Prüfsumme abweicht, wird der Fehler 824 ausgegeben. Mithilfe des Prüfsummenschutzes können mehr Fehler ermittelt werden als mithilfe des Schutzes vor zerrissenen Seiten, da sich jedes in der Seite enthaltene Byte auf dieses Verfahren auswirkt. Der Prüfsummenschutz ist jedoch relativ ressourcenintensiv.

Wenn die Prüfsumme aktiviert ist, werden durch Stromausfälle oder fehlerhafte Hard- oder Firmware verursachte Fehler erkannt, sobald die Seite vom Puffer-Manager vom Datenträger gelesen wird. Weitere Informationen zum Festlegen der Prüfsumme finden Sie unter ALTER DATABASE SET-Optionen (Transact-SQL).

Wichtig

Wenn ein Benutzer oder eine Systemdatenbank auf SQL Server 2005 (9.x) oder höher upgegradet wird, wird der Wert PAGE_VERIFY (NONE oder TORN_PAGE_DETECTION) beibehalten. Sie sollten unbedingt CHECKSUM verwenden. TORN_PAGE_DETECTION kann weniger Ressourcen verwenden, bietet jedoch eine minimale Teilmenge des CHECKSUM-Schutzes.

Grundlegendes zu NUMA (nicht einheitlicher Speicherzugriff)

SQL Server ist NUMA-fähig (Non-Uniform Memory Access, nicht einheitlicher Speicherzugriff) und liefert hervorragende Leistungen auf NUMA-Hardware, ohne dass eine besondere Konfiguration notwendig wäre. Mit immer schnelleren Prozessoren und einer wachsenden Anzahl von Prozessoren wird es zunehmend schwieriger, die Speicherlatenzzeit zu verringern, die für die Verwendung dieser zusätzlichen Verarbeitungsleistung erforderlich ist. Für die Umgehung dieser Schwierigkeit stellen Hardwarehersteller große L3-Caches bereit; dies ist jedoch nur eine eingeschränkte Lösung. Die NUMA-Architektur bietet eine skalierbare Lösung für dieses Problem.

SQL Server kann die Vorteile NUMA-basierter Computer nutzen, ohne dass Anwendungsänderungen erforderlich sind. Weitere Informationen finden Sie unter Soft-NUMA (SQL Server).

Dynamische Partitionierung von Speicherobjekten

Heapzuordnungen, die in als Speicherobjekte in SQL Server bezeichnet werden, ermöglichen der Datenbank-Engine, Arbeitsspeicher vom Heap zuzuordnen. Diese können mithilfe der sys.dm_os_memory_objects-DMV nachverfolgt werden.

CMemThread ist ein threadsicherer Speicherobjekttyp, der gleichzeitige Speicherzuordnungen von mehreren Threads zulässt. Zur ordnungsgemäßen Nachverfolgung verwenden CMemThread-Objekte Synchronisierungskonstrukte (Mutex), um sicherzustellen, dass nur ein einzelner Thread wichtige Informationen gleichzeitig aktualisiert.

Hinweis

Der CMemThread-Objekttyp wird in der Datenbank-Engine-Codebasis für viele verschiedene Zuordnungen verwendet und kann global, nach Knoten oder nach CPU partitioniert werden.

Die Verwendung von Mutexen kann jedoch zu Konflikten führen, wenn viele Threads hochgradig parallel aus demselben Speicherobjekt zuordnen. Daher weist SQL Server das Konzept von partitionierten Speicherobjekten (PMO) auf, und jede Partition wird durch ein einzelnes CMemThread-Objekt dargestellt. Die Partitionierung eines Speicherobjekts ist statisch definiert und kann nach der Erstellung nicht mehr geändert werden. Da Speicherzuordnungsmuster aufgrund von Aspekten wie Hardware und Speicherauslastung stark variieren, ist es nicht möglich, das perfekte Partitionierungsmuster vorab festzulegen.

In den meisten Fällen genügt die Verwendung einer einzelnen Partition, aber in einigen Szenarien kann dies zu Konflikten führen, die nur mit einem stark partitionierten Speicherobjekt verhindert werden können. Es ist nicht wünschenswert, jedes Speicherobjekt zu partitionieren, da eine größere Anzahl von Partitionen möglicherweise andere Ineffizienzen verursachen und die Speicherfragmentierung erhöhen kann.

Hinweis

Vor SQL Server 2016 (13.x) konnte das Ablaufverfolgungsflag 8048 verwendet werden, um zu erzwingen, dass ein knotenbasiertes PMO zu einem CPU-basierten PMO wird. Ab SQL Server 2014 (12.x) SP 2 und SQL Server 2016 (13.x) ist dieses Verhalten dynamisch und wird durch die Engine gesteuert.

Ab SQL Server 2014 (12.x) SP2 und SQL Server 2016 (13.x) kann die Datenbank-Engine Konflikte für ein bestimmtes CMemThread-Objekt dynamisch erkennen und das Objekt auf eine pro-Knoten- oder pro-CPU-basierten Implementierung heraufstufen. Nach der Heraufstufung bleibt das PMO höher gestuft, bis der SQL Server-Prozess neu gestartet wird. CMemThread-Konflikte können durch das Vorhandensein von hohen CMEMTHREAD-Wartezeiten im DMV sys.dm_os_wait_stats erkannt werden, und durch Beobachten der DMV-Spalten sys.dm_os_memory_objects contention_factor, partition_type, exclusive_allocations_count und waiting_tasks_count.

Zugehöriger Inhalt