Handbuch zur Speicherverwaltungsarchitektur

  • Artikel
  • 28 Minuten Lesedauer

Gilt für: SQL Server Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsPlatform 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 Speicherarchitektur

InSQL Server wird Arbeitsspeicher nach Bedarf dynamisch reserviert und freigegeben. In der Regel muss ein Administrator nicht angeben, wie viel Arbeitsspeicher SQL Server zugewiesen werden soll, obwohl die Option weiterhin vorhanden ist 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.

In einem stark geladenen System können einige große Abfragen, für die eine große Menge an Arbeitsspeicher ausgeführt werden muss, nicht die mindeste Menge des angeforderten Arbeitsspeichers abrufen und beim Warten auf Arbeitsspeicherressourcen einen Timeoutfehler erhalten. 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.

In einem stark belasteten System unter Arbeitsspeicherauslastung können Abfragen mit Mergejoin, Sortierung und Bitmap im Abfrageplan die Bitmap löschen, wenn die Abfragen nicht den mindestens erforderlichen Arbeitsspeicher für die Bitmap erhalten. Dies kann sich auf die Abfrageleistung auswirken. Wenn der Sortierprozess nicht in den Arbeitsspeicher passt, kann dies die Verwendung von Arbeitstabellen in tempdb der Datenbank erhöhen, was zu einer Zunahme führt tempdb . Um dieses Problem zu beheben, fügen Sie physischen Arbeitsspeicher hinzu, oder optimieren Sie die Abfragen, um einen anderen und schnelleren Abfrageplan zu verwenden.

Konventioneller (virtueller) Arbeitsspeicher

Alle SQL Server Editionen unterstützen herkömmlichen Speicher auf der 64-Bit-Plattform. Der SQL Server-Prozess kann in der x64-Architektur auf den virtuellen Adressraum bis zum Maximalen Betriebssystem 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 höher nicht unterstützt). Weitere Informationen finden Sie unter Arbeitsspeicherlimits für Windows .

Adressspeicher für Windows-Erweiterungen (AWE)

Durch die Verwendung von Adressfenstererweiterungen (Address Windowing Extensions, AWE) und der von AWE geforderten Berechtigung Sperren von Seiten im Arbeitsspeicher (LPIM) können Sie den größten Teil des SQL Server Prozessarbeitsspeichers im physischen RAM unter geringen bedingungen des virtuellen Arbeitsspeichers sperren. Dies geschieht sowohl bei 32-Bit- als auch bei 64-Bit-AWE-Zuordnungen. Die Speichersperre erfolgt, weil der AWE-Arbeitsspeicher nicht den Virtual Memory Manager in Windows durchläuft, der die Auslagerung des Arbeitsspeichers steuert. Die AWE-Speicherbelegungs-API erfordert die Berechtigung Seiten im Arbeitsspeicher sperren (SeLockMemoryPrivilege). Siehe Hinweise zu AllocateUserPhysicalPages. Daher besteht der Hauptvorteil der Verwendung der AWE-API darin, den größten Teil des Arbeitsspeichers im RAM zu behalten, wenn speicherauslastung auf dem System besteht. Informationen dazu, wie sie SQL Server die Verwendung von AWE zulassen, finden Sie unter Aktivieren der Option Seiten im Arbeitsspeicher sperren.

Wenn LPIM gewährt 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 Serverspeicherserverkonfiguration: Manuelles Festlegen von Optionen und Sperren von Seiten im Arbeitsspeicher (LPIM).

Wenn LPIM nicht aktiviert ist, wechselt SQL Server zur Verwendung des herkömmlichen Arbeitsspeichers, und bei Auslastung des Betriebssystemspeichers wird möglicherweise fehler 17890 im Fehlerprotokoll gemeldet. 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 (11.x)

In älteren Versionen von SQL Server wurde die Speicherbelegung mithilfe von fünf verschiedenen Mechanismen durchgeführt:

  • 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.

Ab SQL Server 2012 (11.x) werden Single-Page-Zuordnungen, Multi-Page-Zuordnungen und CLR-Zuordnungen alle in einer Seitenzuordnung "Beliebiger Größe" konsolidiert und in speicherlimits eingeschlossen, die von den 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 sorgfältig Ihre aktuellen Konfigurationen für den maximalen Serverarbeitsspeicher (MB) und den minimalen Serverarbeitsspeicher (MB), nachdem Sie ein Upgrade auf SQL Server 2012 (11.x) und höher durchgeführt haben. 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 für 32-Bit- und 64-Bit-Versionen von SQL Server 2012 (11.x) und SQL Server 2014 (12.x) sowie für 64-Bit-Versionen von SQL Server 2016 (13.x) und höher.

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) Seit SQL Server 2012 (11.x)
Einzelseitenbelegungen Ja Ja, in Seitenbelegungen beliebiger Größe konsolidiert
Mehrseitenbelegungen Nein Ja, in Seitenbelegungen beliebiger Größe konsolidiert
CLR-Belegungen Nein Ja
Threadstapel-Arbeitsspeicher Nein Nein
Direkte Belegungen von Windows Nein Nein

Ab SQL Server 2012 (11.x) weisen SQL Server möglicherweise mehr Arbeitsspeicher zu, als in der Einstellung max. Serverarbeitsspeicher (MB) angegeben ist. Dieses Verhalten kann auftreten, wenn der Wert des Gesamten Serverarbeitsspeichers (KB) bereits die Einstellung Zielserverarbeitsspeicher (KB) erreicht hat, wie in max. Serverarbeitsspeicher (MB) angegeben. 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 SQL Server Arbeitsspeicherauslastung die Einstellung max. Serverarbeitsspeicher (MB) kurzzeitig überschreiten. In diesem Fall überschreitet der Leistungsindikatorwert gesamt server memory (KB) die Einstellungen max. Serverarbeitsspeicher (MB) und Zielserverarbeitsspeicher (KB).

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

  • Abfragen großer Columnstore-Indexe
  • Großer Batchmodus für Rowstore-Abfragen
  • Columnstore-Index(re)builds, die große Speichervolumes zum Ausführen von Hash- und Sortiervorgängen verwenden
  • Sicherungsvorgänge, die große Speicherpuffer erfordern
  • Ablaufverfolgungsvorgänge, die große Eingabeparameter speichern müssen

Änderungen an memory_to_reserve ab SQL Server 2012 (11.x)

In älteren Versionen von SQL Server hat der SQL Server-Speicher-Manager einen Teil des prozessbezogenen virtuellen Adressraums (VAS) für die Verwendung durch MPA (Multi-Page Allocator),CLR Allocator, Speicherbelegungen für Threadstapel im SQL Server-Prozess und Direkte Windows-Zuordnungen (DWA) reserviert. Dieser Teil des virtuellen Adressbereichs wird auch als „Zu belassender Arbeitsspeicher“ oder „Nicht-Pufferpool“-Bereich bezeichnet.

Der virtuelle Adressraum, der für diese Zuordnungen reserviert ist, wird durch die Konfigurationsoption memory_to_reserve bestimmt. Der von SQL Server verwendete Standardwert ist 256 MB.

Da die Seitenzuordnung "beliebige Größe" auch Zuordnungen verarbeitet, die größer als 8 KB sind, enthält der memory_to_reserve-Wert nicht die Mehrseitenzuordnungen. 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) Seit SQL Server 2012 (11.x)
Einzelseitenbelegungen Nein 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 Speicherverwaltung

Die Arbeitsspeicherverwaltung von SQL Server-Datenbank-Engine ruft standardmäßig so viel Arbeitsspeicher wie nötig ab, ohne dass es dabei zu einem Speicherengpass auf dem System kommt. 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 hinzu, wenn die Workload mehr Arbeitsspeicher benötigt. Ein ruhender Server erhöht die Größe des virtuellen Adressraums nicht. Wenn Sie feststellen, dass Task-Manager und Leistungsmonitor eine stetige Abnahme des verfügbaren Arbeitsspeichers aufweisen, wenn SQL Server dynamische Speicherverwaltung verwendet, ist dies das Standardverhalten und sollte nicht als Speicherverlust wahrgenommen werden.

Max. Serverarbeitsspeicher steuert die SQL Server-Speicherbelegung, die Arbeitsspeicherkompilierung, alle Caches (einschließlich des Pufferpools), Arbeitsspeicherzuweisungen für die Abfrageausführung, den Arbeitsspeicher für den Sperren-Manager und den CLR-Arbeitsspeicher 1 (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, erweiterte Prozedur .dll Dateien, die OLE DB-Anbieter, auf die von verteilten Abfragen verwiesen wird, Automatisierungsobjekte, auf die in Transact-SQL-Anweisungen verwiesen wird, und jeglicher Arbeitsspeicher, der von einer nicht SQL Server DLL zugewiesen wird, werden nicht durch max. Serverarbeitsspeicher (MB) gesteuert.

1 Informationen zu den berechneten Standardarbeitsthreads für eine bestimmte Anzahl von affinitierten CPUs auf dem aktuellen Host finden Sie im Artikel Konfigurieren der Serverkonfigurationsoption max. 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) 2048 KB
IA64 (Itanium) IA64 (Itanium) 4096 KB

2 CLR-Arbeitsspeicher wird seit SQL Server 2012 (11.x) unter max_server_memory-Belegungen verwaltet.

SQL Server verwendet die Speicherbenachrichtigungs-API QueryMemoryResourceNotification, um zu bestimmen, wann der SQL Server Arbeitsspeicher-Manager Arbeitsspeicher zuordnen und Arbeitsspeicher freigeben kann.

Wenn SQL Server gestartet wird, wird die Größe des virtuellen Adressraums für den Pufferpool basierend auf mehreren Parametern berechnet, z. B. der Menge des physischen Arbeitsspeichers im System, der Anzahl von Serverthreads und verschiedenen Startparametern. 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 erhält weiterhin physischen Arbeitsspeicher, bis sie entweder das Maximale Serverarbeitsspeicher-Zuordnungsziel (MB) erreicht oder das Betriebssystem angibt, dass kein übermäßig freier Arbeitsspeicher mehr vorhanden ist. Es gibt Arbeitsspeicher frei, wenn mehr als die Einstellung min. Serverarbeitsspeicher vorhanden ist, und das Betriebssystem weist darauf hin, dass es zu einem Mangel an freiem Arbeitsspeicher kommt.

Sobald weitere Anwendungen auf einem Computer gestartet werden, auf dem eine Instanz von SQL Serverausgefü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 server memory und max server memory werden die obere und untere Grenze für den Umfang des Speichers festgelegt, der vom Pufferpool und anderen Caches von Datenbank-Engine verwendet wird. Der Pufferpool ruft nicht sofort die Menge an Arbeitsspeicher ab, die in min. Serverarbeitsspeicher angegeben ist. Der Pufferpool reserviert zuerst nur so viel Speicher, wie für die Initialisierung erforderlich ist. Mit ansteigender Arbeitsauslastung von SQL Server-Datenbank-Engine wird weiterer Speicher reserviert, um die Arbeitsauslastung zu unterstützen. Der Pufferpool gibt den erworbenen Arbeitsspeicher erst frei, wenn er die in Min. Serverarbeitsspeicher angegebene Menge erreicht. 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 seine Speicherbelegung niemals unter die in Min. Serverarbeitsspeicher angegebene Ebene zurückgibt und niemals mehr Arbeitsspeicher erhält, als in max. Serverarbeitsspeicher (MB) angegeben ist.

Hinweis

SQL Server als Prozess erhält mehr Arbeitsspeicher, als in der Option max. Serverarbeitsspeicher (MB) angegeben ist. 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 normalerweise trotzdem den größten Teil des von SQL Server belegten Speichers dar.

Der Umfang des von SQL Server-Datenbank-Engine reservierten Speichers hängt ausschließlich von der Arbeitsauslastung der jeweiligen Instanz ab. Eine SQL Server Instanz, die nicht viele Anforderungen verarbeitet, erreicht möglicherweise nie den minimalen Serverarbeitsspeicher.

Wenn der gleiche Wert sowohl für den minimalen Serverarbeitsspeicher als auch für den maximalen Serverarbeitsspeicher (MB) angegeben ist, erreicht die SQL Server-Datenbank-Engine diesen Wert, sobald der der SQL Server-Datenbank-Engine zugeordnete Arbeitsspeicher diesen Wert erreicht, beendet die SQL Server-Datenbank-Engine das dynamische Freigeben und Abrufen von Arbeitsspeicher für den Pufferpool.

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, dass der Umfang des SQL Serverzugeordneten Speichers von Systemadministratoren gesteuert wird. In diesen Fällen können Sie die Optionen min. Serverarbeitsspeicher und max. Serverarbeitsspeicher (MB) verwenden, um zu steuern, wie viel Arbeitsspeicher SQL Server verwenden können. 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 Serverbelegen. 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 Bytes + 32 Bytes pro Besitzer
  • Benutzerverbindung: Ungefähr (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 Datenbank-Engine verwendet werden. Die Standardpaketgröße beträgt 4 KB und wird durch die Konfigurationsoption Netzwerkpaketgröße gesteuert.

Wenn mehrere aktive Resultsets (MARS) aktiviert sind, beträgt die Benutzerverbindung ungefähr (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 akkumuliert wird, ist RESOURCE_SEMAPHORE.

Wichtig

Legen Sie die Konfigurationsoption "Min. Arbeitsspeicher pro Abfrageserver " nicht zu hoch fest, insbesondere bei stark ausgelasteten Systemen, da dies zu Folgenden führen 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

Bei der Ausführung des Zeilenmodus kann die anfängliche Speicherzuweisung unter keiner Bedingung überschritten werden. Wenn mehr Arbeitsspeicher als ursprünglich zugewiesen erforderlich ist, um Hash- oder Sortiervorgänge durchzuführen, laufen diese auf den Datenträger über. Ein Hashvorgang, der überläuft, wird von einer Arbeitsdatei in tempdbunterstützt, während ein Sortiervorgang, der überlauft, von einer Worktable unterstützt wird.

Ein Überlauf, der während eines Sortierungsvorgangs auftritt, wird als Sortwarnung bezeichnet. Sortierwarnungen weisen darauf hin, dass Sortiervorgänge nicht in den Arbeitsspeicher passen. Dies schließt keine Sortiervorgänge ein, die die Erstellung von Indizes betreffen, nur Sortiervorgänge innerhalb einer Abfrage (z. B. eine ORDER BY klausel, die in einer SELECT Anweisung verwendet wird).

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

  • Hashrekursion tritt auf, wenn die Buildeingabe nicht in den verfügbaren Arbeitsspeicher passt, was zu einer Aufteilung der Eingabe in mehrere Partitionen führt, die separat verarbeitet werden. Wenn eine dieser Partitionen immer noch nicht in den verfügbaren Arbeitsspeicher passt, wird sie in Unterpartitionen unterteilt, die 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 nicht in den Arbeitsspeicher passen, werden diese auf den Datenträger überschüttet.

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.

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.

Wenn SQL Server gestartet wird, wird die Größe des virtuellen Adressraums für den Puffercache basierend auf mehreren Parametern berechnet, z. B. der Menge des physischen Arbeitsspeichers auf dem System, der konfigurierten Anzahl der maximalen Serverthreads und verschiedenen Startparametern. 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. Beispielsweise füllt eine einzelne Leseanforderung mit einer 8 KB-Seite eine einzelne Pufferseite aus. 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 Erweiterungen finden Sie unter Architekturhandbuch für Seiten und Erweiterungen.

Ein 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 SQL Server-Betriebssystem (SQLOS) für Datei-E/A-Vorgänge auf systemnaher Ebene.
  • Protokoll-Manager für Write-Ahead-Protokollierung.

Unterstützte Features

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) ist zum Aktivieren von großen Seiten in SQL Server das Ablaufverfolgungsflag 834 erforderlich.

  • Der Puffer-Manager bietet zusätzliche Diagnosen, die über dynamische Verwaltungsansichten verfügbar gemacht werden. Sie können diese Ansichten verwenden, um verschiedene Betriebssystemressourcen zu überwachen, die für SQL Server spezifisch sind. Beispielsweise können Sie mithilfe der Sicht sys.dm_os_buffer_descriptors die Seiten im Puffercache überwachen.

Datenträger-E/A

Mit dem Puffer-Manager werden nur Lese- und Schreibvorgänge für die Datenbank ausgeführt. Sonstige Datei- und Datenbankvorgänge, z. B. öffnen, schließen, erweitern und verkleinern) werden von den Datei- und Datenbank-Manager-Komponenten ausgeführt.

Datenträger-E/A-Vorgänge des Puffer-Managers weisen die folgenden Merkmale auf:

  • Alle E/A-Vorgänge werden asynchron ausgeführt, sodass der aufrufende Thread die Verarbeitung fortsetzen kann, während der E/A-Vorgang im Hintergrund ausgeführt wird.
  • Alle E/A-Vorgänge werden in den aufrufenden Threads ausgegeben, es sei denn, die Affinität-E/A-Option wird verwendet. Durch die Option Affinity I/O Mask wird die SQL Server -Datenträger-E/A an eine bestimmte Teilmenge der CPUs gebunden. In High-End-OLTP-Umgebungen (Online Transactional Processing, Onlinetransaktionsverarbeitung) für SQL Server kann diese Erweiterung die Leistung von SQL Server -Threads, die E/A verursachen, verbessern.
  • Mehrfachseiten-E/A wird durch Scatter-Gather-E/A erreicht; dadurch wird ermöglicht, dass Daten in nicht zusammenhängende Bereiche des Arbeitsspeichers oder aus diesen übertragen werden können. Damit kann der Puffercache von SQL Server problemlos gefüllt oder gelöscht werden; zugleich werden mehrere physische E/A-Anforderungen verhindert.

Lange E/A-Anforderungen

Vom Puffer-Manager werden alle seit mindestens 15 Sekunden ausstehenden E/A-Anforderungen gemeldet. Damit kann der Systemadministrator einfacher zwischen SQL Server -Problemen und Problemen im E/A-Subsystem unterscheiden. Es wird die Fehlermeldung 833 angegeben. Im SQL Server -Fehlerprotokoll wird sie wie folgt angezeigt:

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

Eine lange E/A kann ein Lese- oder Schreibvorgang sein. sie wird derzeit nicht in der Nachricht angegeben. Bei Meldungen zu langen E/A-Vorgängen handelt es sich um Warnungen, nicht um Fehlermeldungen. Sie weisen nicht auf Probleme mit SQL Server sondern mit dem zugrunde liegenden E/A-System hin. Die Meldungen werden ausgegeben, damit der Systemadministrator die Ursache der langen Antwortzeiten von SQL Server leichter ermitteln kann und um Probleme, die nicht durch SQL Serververursacht werden, abgrenzen zu können. Daher sind keine Aktionen erforderlich, aber der Systemadministrator sollte untersuchen, warum die E/A-Anforderung so lange gedauert hat und ob die Zeit vertretbar ist.

Ursachen für lange E/A-Anforderungen

Eine lange E/A-Nachricht kann darauf hinweisen, dass eine E/A dauerhaft blockiert ist und nie abgeschlossen wird (als verlorene E/A bezeichnet), oder lediglich, dass sie noch nicht abgeschlossen ist. Es ist nicht möglich, aus der Nachricht zu erkennen, welches Szenario der Fall ist, obwohl eine verlorene E/A häufig zu einem Latch-Timeout führt.

Lange Wartezeiten bei der E/A sind häufig ein Hinweis auf eine zu hohe Arbeitsauslastung für das Datenträgersubsystem in SQL Server . Ein unzureichendes Datenträgersubsystem wird in folgenden Fällen angezeigt:

  • Es werden mehrere lange E/A-Meldungen im Fehlerprotokoll angezeigt bei starker SQL Server -Arbeitsauslastung.
  • Leistungsmonitor Indikatoren zeigen lange Datenträgerlatenz, lange Datenträgerwarteschlangen oder keine Leerlaufzeit des Datenträgers an.

Lange E/A-Vorgänge können auch durch eine Komponente im E/A-Pfad verursacht werden (z. B. durch einen Treiber, einen Controller oder durch Firmware), bei der das Bedienen einer alten E/A-Anforderung kontinuierlich verschoben wird, anstatt neuere Anforderungen zu bedienen, die näher an der aktuellen Position des Lesekopfs liegen. Die gängige Technik der Verarbeitung von Anforderungen mit Priorität, basierend darauf, welche der aktuellen Position des Lese-/Schreibkopfs am nächsten sind, wird als "Aufzugssuche" bezeichnet. Dies kann mit dem Leistungsmonitor-Tool schwer zu bestätigen sein, da die meisten E/A-Vorgänge umgehend gewartet werden. Lange E/A-Anforderungen werden durch Arbeitsauslastungen erschwert, bei denen viele sequenzielle E/A-Anforderungen (z. B. Sichern und Wiederherstellen, Prüfen von Tabellen, Sortieren, Erstellen von Indizes, Massenladen und Dateien auf Null setzen) ausgeführt werden.

Isolierte lange E/A-Vorgänge, die nicht mit einer der vorherigen Bedingungen zusammenhängen, können durch ein Hardware- oder Treiberproblem verursacht werden. Das Systemereignisprotokoll enthält möglicherweise ein ähnliches Ereignis, mit dem eine Problemdiagnose vorgenommen werden kann.

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 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.

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 verfügt über Statusinformationen abhängig von der aktuellen Bedingung von RESOURCE_MEMPHYSICAL_HIGH, RESOURCE_MEMPHYSICAL_LOW, RESOURCE_MEMPHYSICAL_STEADYoder RESOURCE_MEMVIRTUAL_LOW.
  • 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

Datenbankseiten können einen von zwei optionalen Mechanismen verwenden, die die Integrität der Seite vom Zeitpunkt, an dem sie auf den Datenträger geschrieben wird, bis sie erneut gelesen wird, sicherstellen: Schutz der aufgerissenen Seite 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, vier Mal. 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. Schlagen alle Wiederholungsversuche fehl, schlägt der Befehl mit Fehlermeldung 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 höheren Versionen erstellt wurden. Der Seitenschutzmechanismus wird zum Zeitpunkt der Datenbankerstellung angegeben und kann mithilfe ALTER DATABASE SETvon geändert werden. Sie können die aktuelle Seitenschutzeinstellung ermitteln, indem Sie die Spalte in der page_verify_optionsys.databases-Katalogsicht oder die IsTornPageDetectionEnabled Eigenschaft der DATABASEPROPERTYEX-Funktion abfragen.

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 in SQL Server 2000 (8.x) eingeführte Schutz von abgerissenen Seiten ist in erster Linie eine Möglichkeit, Seitenbeschädigungen aufgrund von Stromausfällen zu erkennen. 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 zwischen binär 01 und 10 mit jedem Schreibvorgang, sodass es immer möglich ist, zu erkennen, wann nur ein Teil der Sektoren es auf den Datenträger geschafft hat: Wenn sich ein Bit im falschen Zustand befindet, wenn die Seite später gelesen wird, wurde die Seite falsch geschrieben und eine abgerissene Seite erkannt. Bei der Erkennung von abgerissenen Seiten werden nur minimale Ressourcen verwendet. Es werden jedoch nicht alle Fehler erkannt, die durch Hardwarefehler der Datenträger verursacht werden. Informationen zum Festlegen der Erkennung von eingerissenen Seiten finden Sie unter ALTER DATABASE SET-Optionen (Transact-SQL).

Prüfsummenschutz

Der Prüfsummenschutz, der in SQL Server 2005 (9.x) eingeführt wird, 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. Informationen zum Festlegen der Prüfsumme finden Sie unter ALTER DATABASE SET-Optionen (Transact-SQL).

Wichtig

Wenn eine Benutzer- oder Systemdatenbank auf SQL Server 2005 (9.x) oder höher aktualisiert wird, wird der PAGE_VERIFY Wert (NONE oder TORN_PAGE_DETECTION) beibehalten. Es wird dringend empfohlen, die Verwendung von zu verwenden CHECKSUM. TORN_PAGE_DETECTION kann weniger Ressourcen verbrauchen, stellt jedoch eine minimale Teilmenge des CHECKSUM Schutzes bereit.

Grundlegendes zu nicht einheitlichem Speicherzugriff

SQL Server ist NUMA-fähig (Non-Uniform Memory Access) 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 Vorgehensweise: Soft-NUMA (SQL Server).

Dynamische Partitionierung von Speicherobjekten

Heapzuordnungen, die in SQL Server als Speicherobjekte bezeichnet werden, ermöglichen 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 reicht die Verwendung einer einzelnen Partition aus, 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 mehr Partitionen zu anderen Ineffizienzen führen und die Speicherfragmentierung erhöhen können.

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) SP2 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 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 in der sys.dm_os_wait_stats DMV und durch Beobachten der sys.dm_os_memory_objects DMV-Spalten contention_factor, partition_type, und exclusive_allocations_countwaiting_tasks_counterkannt werden.

Nächste Schritte