Microsoft SQL Server-E/A-Subsystemanforderungen für die tempdb-Datenbank

In diesem Artikel werden die I/O-Subsystemanforderungen für die tempdb-Datenbank in SQL Server vorgestellt.

Originalproduktversion: Microsoft SQL Server
Ursprüngliche KB-Nummer: 917047

Zusammenfassung

Microsoft SQL Server erfordert, dass das E/A-Subsystem, das zum Speichern von System- und Benutzerdatenbanken verwendet wird, die Anforderungen für die Write-Ahead-Protokollierung (WAL) durch bestimmte E/A-Prinzipale vollständig berücksichtigen. Diese Anforderungen sind erforderlich, um die ACID-Eigenschaften von Transaktionen zu berücksichtigen: Atomic, Consistent, Isolated und Durable. Details zu den Complianceanforderungen des E/A-Subsystems werden in den SQL Server-E/A-Grundlagen bereitgestellt.

Die folgende Liste enthält eine kurze Zusammenfassung der Anforderungen:

  • Die Schreib sortierung muss beibehalten werden.
  • Abhängige Schreibkonsistenz muss beibehalten werden.
  • Schreibvorgänge müssen immer in/auf stabilen Medien gesichert werden.
  • Torn-E/A-Prävention muss auftreten.

Die Haltbarkeitswartung bleibt für alle anderen Datenbanken kritisch, kann aber für die tempdb-Datenbank entspannt sein. In der folgenden Tabelle sind einige der kritischen E/A-Anforderungen für SQL Server-Datenbanken zusammengefasst.

E/A-Anforderung Kurzbeschreibung System oder Benutzer tempdb
Schreiben der Sortierung

Konsistenz abhängiger Schreibvorgänge		 Die Fähigkeit des Subsystems, die richtige Reihenfolge von Schreibvorgängen beizubehalten. Dies kann besonders wichtig für Spiegelungslösungen, Gruppenkonsistenzanforderungen und die Verwendung des SQL Server WAL-Protokolls sein. Erforderlich Empfohlen
Lesen nach Schreibzugriff Die Fähigkeit des Subsystems, Leseanforderungen mit dem neuesten Datenimage zu warten, wenn der Lesevorgang nach erfolgreicher Ausführung des Schreibvorgangs ausgegeben wird. Erforderlich Erforderlich
Überleben über Ausfälle Die Möglichkeit, daten vollständig intakt zu bleiben (dauerhaft) über einen Ausfall hinweg, z. B. einen Systemneustart. Erforderlich Nicht zutreffend
Torn-E/A-Verhinderung Die Möglichkeit des Systems, das Aufteilen einzelner E/A-Anforderungen zu vermeiden. Erforderlich Empfohlen
Sektorumschreibung Der Sektor kann nur in seiner Gesamtheit geschrieben werden und kann aufgrund einer Schreibanforderung für einen nahe gelegenen Sektor nicht umgeschrieben werden. * Entmutigt, nur zulässig, wenn transaktional * Entmutigt, nur zulässig, wenn transaktional
Gehärtete Daten Wenn eine Schreibanforderung oder ein FlushFileBuffers-Vorgang erfolgreich abgeschlossen ist, wurden Daten auf stabilen Medien gespeichert. Erforderlich Nicht zutreffend
Ausrichtung und Größe des physischen Sektors SQL Server fragt die Speicherorte von Daten und Protokolldateien ab. Alle Geräte sind erforderlich, um Sektorattribute zu unterstützen, die ES SQL Server ermöglichen, Schreibvorgänge an physischen sektorbezogenen Grenzen und in Vielfachen der Sektorgröße durchzuführen. Erforderlich Erforderlich

Transaktionssektorumschreibungen umfassen vollständig protokollierte Vorgänge des Subsystems, die es ermöglichen, dass ein Sektor vollständig verschoben, ersetzt oder auf das ursprüngliche Image zurückgesetzt werden kann. Diese Umschreibungen werden in der Regel aufgrund des zusätzlichen Aufwands abgeraten, der zum Ausführen solcher Aktionen erforderlich ist. Ein Beispiel hierfür wäre ein defragmentation Dienstprogramm, das die Dateidaten verschiebt. Der ursprüngliche Sektor in der Datei kann erst durch den neuen Branchenstandort ersetzt werden, wenn der neue Sektor und die Daten gesichert sind. Die Neuzuordnung des Sektors muss auf transaktionsbezogene Weise erfolgen, sodass ein Ausfall, einschließlich eines Stromausfalls, die Neueinrichtung der ursprünglichen Daten verursacht. Stellen Sie sicher, dass Während dieser Art von Prozess Sperrmechanismen verfügbar sind, um einen ungültigen Datenzugriff zu verhindern, wodurch die anderen Mandanten von SQL Server I/O aufrecht erhalten werden.

Überleben über Ausfälle

Die tempdb-Datenbank ist ein Entwurfsbereich für SQL Server und wird auf jedem SQL Server-Start neu erstellt. Die Initialisierung ersetzt alle Notwendigkeiten für Daten, um einen Neustart zu überleben.

Neuschreibung von Transaktionen im Transaktionssektor

Um den Erfolg der Wiederherstellungsprozesse wie Rollback und Absturzwiederherstellung zu gewährleisten, müssen die Protokolldatensätze ordnungsgemäß auf stabilen Medien gespeichert werden, bevor die Datenseite gespeichert wird und nicht neu geschrieben werden kann, ohne Transaktionseigenschaften zu berücksichtigen. Dies erfordert, dass das Subsystem und SQL Server bestimmte Attribute verwalten, z. B. Schreibrichtung, Sektorausrichtung und Größe von Schreibvorgängen und andere solche E/A-Sicherheitsattribute, die in den zuvor erwähnten Dokumenten beschrieben sind. Für die tempdb-Datenbank ist die Absturzwiederherstellung unnötig, da die Datenbank beim Starten von SQL Server immer initialisiert wird. Die tempdb-Datenbank erfordert jedoch weiterhin Rollbackfunktionen. Daher können einige Attribute des WAL-Protokolls entspannt sein.

Der Speicherort für die tempdb-Datenbank muss in strikter Übereinstimmung mit etablierten Laufwerksprotokollen handeln. Auf alle Arten muss das Gerät, auf dem die tempdb-Datenbank gespeichert ist, als physischer Datenträger angezeigt werden, der Lese-nach-Schreibfunktionen bereitstellt. Transaktionssektorumschreibungsvorgänge können eine zusätzliche Anforderung spezifischer Implementierungen sein. Sql Server unterstützt z. B. keine Datenbankänderungen mithilfe der NTFS-Dateisystemkomprimierung, da die NTFS-Komprimierung Sektoren des Protokolls neu schreiben kann, die bereits geschrieben und als gehärtet betrachtet wurden. Ein Fehler während dieser Art von Neuschreibvorgang kann dazu führen, dass die Datenbank nicht mehr verwendbar ist, schädliche Daten, die SQL Server bereits als sicher eingestuft hat.

Notiz

SQL Server hat die Unterstützung für die Komprimierung von schreibgeschützten Datenbanken und Dateigruppen erweitert. Ausführliche Informationen finden Sie in den SQL Server-Onlinebüchern.

Transaktionssektorumschreibungsvorgänge sind für alle SQL Server-Datenbanken relevant, die die tempdb-Datenbank enthalten. Eine wachsende Vielfalt erweiterter Speichertechnologien verwendet Geräte und Dienstprogramme, die Daten neu schreiben können, die SQL Server als sicher betrachtet. Einige der neuen Technologien führen z. B. Zwischenspeicherung oder Datenkomprimierung im Arbeitsspeicher durch. Um schwerwiegende Datenbankschäden zu vermeiden, muss jede Sektorumschreibung eine vollständige Transaktionsunterstützung haben, sodass die Daten bei Einem Ausfall auf die vorherigen Sektorbilder zurückgesetzt werden. Dadurch wird sichergestellt, dass SQL Server niemals einem unerwarteten Unterbrechungs- oder Datenschadenszustand ausgesetzt ist.

Möglicherweise können Sie die tempdb-Datenbank auf Spezialsubsystemen, z. B. RAM-Datenträger, Festkörper oder andere Hochgeschwindigkeitsimplementierungen, die nicht für andere Datenbanken verwendet werden können, platzieren. Die im Abschnitt "Weitere Informationen" aufgeführten Schlüsselfaktoren müssen jedoch berücksichtigt werden, wenn Sie diese Optionen auswerten.

Notiz

Die lokalen Datenträger in Failoverclustered-Umgebungen werden nur mit Vollzustands- oder Hochgeschwindigkeitsimplementierungen unterstützt. Dies liegt daran, dass der RAM-Datenträger nur über ein iSCSI-Ziel erstellt werden kann. Darüber hinaus können die iSCSI-Ziel- und Failoverclusterfeatures nicht auf demselben Host verwendet werden.

Weitere Informationen

Beim Auswerten des Speicherorts der tempdb-Datenbank sollten mehrere Faktoren sorgfältig untersucht werden. Die Tempdb-Datenbanknutzung umfasst z. B. die Speicherbedarfs-, Abfrageplan- und E/A-Entscheidungen. Die geeignete Optimierung und Implementierung der tempdb-Datenbank kann die Skalierbarkeit und Reaktionsfähigkeit eines Systems verbessern. In diesem Abschnitt werden die wichtigsten Faktoren bei der Ermittlung der Speicheranforderungen für die tempdb-Datenbank erläutert.

Hochgeschwindigkeits-Subsysteme

Es gibt verschiedene Hochgeschwindigkeits-Subsystemimplementierungen auf dem Markt, die SQL Server-E/A-Subsystem-Protokollanforderungen bereitstellen, die jedoch keine Haltbarkeit der Medien bieten.

Wichtig

Bestätigen Sie immer mit dem Produktanbieter, um die vollständige Einhaltung der SQL Server-E/A-Anforderungen zu gewährleisten.

Ein RAM-Datenträger ist ein gängiges Beispiel für eine solche Implementierung. RAM-Datenträger installieren die erforderlichen Treiber und ermöglichen es, dass ein Teil des Haupt-RAM-Datenträgers wie jedes laufwerk, das an das System angeschlossen ist, als und funktioniert. Alle E/A-Subsysteme sollten die vollständige Einhaltung der SQL Server-E/A-Anforderungen gewährleisten. Es ist jedoch offensichtlich, dass ein RAM-Datenträger kein dauerhaftes Medium ist. Daher kann eine Implementierung wie ein RAM-Datenträger nur als Speicherort der tempdb-Datenbank verwendet werden und kann nicht für eine andere Datenbank verwendet werden.

Schlüssel, die vor der Implementierung und Bereitstellung berücksichtigt werden sollten

Es gibt verschiedene Punkte, die Vor der Bereitstellung der tempdb-Datenbank für diese Art von Subsystem berücksichtigt werden müssen. In diesem Abschnitt wird ein RAM-Datenträger als Diskussionsgrundlage verwendet, ähnliche Ergebnisse treten jedoch in anderen Hochgeschwindigkeitsimplementierungen auf.

E/A-Sicherheit

Die Einhaltung von Lesevorgängen nach Schreib- und Transaktionssektorschreibvorgängen ist ein Muss. Stellen Sie SQL Server niemals auf einem System bereit, das die SQL Server-E/A-Anforderungen nicht vollständig unterstützt, oder Sie riskieren Schäden und Verlust Ihrer Daten.

Bereits zwischengespeicherte Seiten (Doppelter RAM-Cache)

Temporäre Tabellen sind wie alle anderen Tabellen in einer Datenbank. Sie werden vom Pufferpool zwischengespeichert und von faulen Schreibvorgängen behandelt. Das Speichern temporärer Tabellenseiten auf einem RAM-Datenträger führt zu doppelter RAM-Zwischenspeicherung, einem im Pufferpool und einem auf dem RAM-Datenträger. Dadurch wird die gesamt mögliche Größe des Pufferpools direkt aufgehoben und die Leistung von SQL Server im Allgemeinen verringert.

Ram aufzugeben

Der RAM-Datenträger bezeichnet einen Teil des Haupt-RAM, wie der Name schon sagt. Es gibt mehrere Implementierungen von RAM-Datenträgern und RAM-basierten Dateiencaches. Einige ermöglichen auch physische E/A-Sicherungsvorgänge. Das Schlüsselelement des RAM-basierten Dateicaches besteht darin, dass er direkt aus dem physischen Speicher entfernt wird, der von SQL Server verwendet werden kann. Es gibt immer starke Nachweise, dass das Hinzufügen eines RAM-basierten Dateicaches die Anwendungsleistung verbessert und keine andere Abfrage- oder Anwendungsleistung verringert.

Zuerst optimieren

Eine Anwendung sollte so optimiert werden, dass unnötige und unerwünschte Sortierungen und Hashes entfernt werden, die die Verwendung der tempdb-Datenbank verursachen könnten. Oft kann das Hinzufügen eines Indexes die Notwendigkeit für die Sortierung oder den Hash im Plan vollständig entfernen, was zu einer optimalen Leistung führt, ohne dass die Verwendung der tempdb-Datenbank erforderlich ist.

Mögliche Leistungspunkte

Die Vorteile der Verwendung der tempdb-Datenbank auf einem Hochgeschwindigkeitssystem können nur durch strenge Tests und Messungen der Anwendungsworkloads bestimmt werden. Die Arbeitsauslastung muss sorgfältig nach den Merkmalen untersucht werden, von denen die tempdb-Datenbank profitieren kann, und die E/A-Sicherheit muss vor der Bereitstellung bestätigt werden.

Die Sortier- und Hashvorgänge arbeiten mit den SQL Server-Speichermanagern zusammen, um die Größe des Speicherbereichs für jeden Sortier- oder Hashvorgang zu bestimmen. Sobald die Sortier- oder Hashdaten den zugeordneten Speicher-Entwurfsbereich überschreiten, können Daten in die tempdb-Datenbank geschrieben werden. Dieser Algorithmus wurde in SQL Server erweitert und verringert die Anforderungen an die Tempdb-Datenbanknutzung gegenüber früheren Versionen von SQL Server.

Achtung

SQL Server ist so konzipiert, dass Speicherebenen und aktuelle Abfrageaktivitäten berücksichtigt werden, wenn Abfrageplanentscheidungen getroffen werden, die die Verwendung von tempdb-Datenbankvorgängen umfassen. Daher variieren die Leistungsgewinne erheblich je nach Workloads und Anwendungsdesign. Es wird dringend empfohlen, dass Sie tests mit der bevorzugten Lösung durchführen, um mögliche Gewinne zu ermitteln und E/A-Sicherheitsanforderungen vor einer solchen Bereitstellung zu bewerten.

SQL Server verwendet die tempdb-Datenbank, um verschiedene Aktivitäten zu verarbeiten, die Sortierungen, Hashes, den Zeilenversionsspeicher und temporäre Tabellen umfassen:

  • Temporäre Tabellen werden von den allgemeinen Pufferpoolroutinen für Datenseiten verwaltet und weisen in der Regel keine Leistungsvorteile von Spezialsubsystemimplementierungen auf.
  • Die tempdb-Datenbank wird als Entwurfsbereich für Hashes und Sortierungen verwendet. Die Verringerung der E/A-Latenz für solche Vorgänge kann von Vorteil sein. Beachten Sie jedoch, dass das Hinzufügen eines Indexes, um einen Hash oder eine Sortierung zu vermeiden, einen ähnlichen Vorteil bieten kann.

Führen Sie Basispläne mit und ohne die tempdb-Datenbank aus, die im Hochgeschwindigkeitssubsystem gespeichert ist, um Die Vorteile zu vergleichen. Ein Teil des Tests sollte Abfragen für die Benutzerdatenbank enthalten, die keine Sortierungen, Hashes oder temporäre Tabellen umfasst, und bestätigen Sie dann, dass diese Abfragen nicht beeinträchtigt werden. Wenn Sie das System auswerten, können die folgenden Leistungsindikatoren hilfreich sein.

Indikator Beschreibung/Nutzung
Seitenlese- und Schreibvorgänge Die Verbesserung der Leistung der tempdb-Datenbank-E/A kann die Rate von Seitenlese- und Schreibvorgängen für die Benutzerdatenbanken aufgrund der reduzierten Latenz ändern, die der tempdb-Datenbank-E/A zugeordnet ist. Bei Benutzerdatenbankseiten sollte die Gesamtanzahl nicht über dieselbe Workload hinweg variieren.
Physisches Lesen und Schreiben von Bytes in die tempdb-Datenbank Wenn das Verschieben der tempdb-Datenbank auf ein Gerät, z. B. einen RAM-Datenträger, die tatsächliche E/A für die tempdb-Datenbank erhöht, bedeutet dies, dass der vom Pufferpool entfernte Speicher zu einer erhöhten tempdb-Datenbankaktivität führt. Dieses Muster ist ein Indikator, dass die Lebenserwartung von Datenbankseiten auch negativ beeinflusst werden kann.
Lebenserwartung der Seite Ein Rückgang der Seitenlebensdauer kann auf eine Zunahme der physischen E/A-Anforderungen für eine Benutzerdatenbank hinweisen. Die Rateverkürzung könnte wahrscheinlich darauf hindeuten, dass der speicherabgenommene Speicher aus dem Pufferpool Datenbankseiten erzwingt, um den Pufferpool vorzeitig zu beenden. Kombinieren Sie die anderen Indikatoren, und testen Sie, um die Parametergrenzen vollständig zu verstehen.
Gesamtdurchsatz
CPU-Auslastung
Skalierbarkeit
Antwortzeit		 Das Hauptziel einer Tempdb-Datenbankkonfigurationsänderung besteht darin, den Gesamtdurchsatz zu erhöhen. Ihre Tests sollten eine Mischung aus wiederholbaren Workloads enthalten, die skaliert werden können, um zu bestimmen, wie sich der Durchsatz auswirkt.

Etwas wie eine komprimierungsbasierte RAM-Datenträgerimplementierung funktioniert möglicherweise gut mit 10 Benutzern. Mit erhöhter Workload kann dies jedoch CPU-Ebenen über die gewünschten Ebenen hinausschieben und negative Auswirkungen auf die Reaktionszeit haben, wenn die Workloads hoch sind. Echte Stresstests und zukünftige Belastungsvorhersagetests werden empfohlen.
Arbeitsdateien und Arbeitstabellenerstellungsaktionen Wenn sie die tempdb-Datenbank auf ein Gerät wie einen RAM-Datenträger verschieben, ändert sich der Abfrageplan, indem die Anzahl oder Größe von Arbeitsdateien oder Arbeitstabellen erhöht wird, bedeutet dies, dass der vom Pufferpool entfernte Arbeitsspeicher zu einer erhöhten tempdb-Datenbankaktivität führt. Dieses Muster ist ein Hinweis darauf, dass die Lebenserwartung von Datenbankseiten auch negativ beeinflusst werden kann.

Beispiel für die Neuschreibung des Transaktionssektors

Im folgenden Beispiel wird die Datensicherheit ausgearbeitet, die von SQL Server-Datenbanken benötigt wird.

Gehen Sie davon aus, dass ein RAM-Datenträgeranbieter eine In-Memory-Komprimierungsimplementierung verwendet. Die Implementierung muss ordnungsgemäß gekapselt werden, indem die physische Darstellung des Dateidatenstroms bereitgestellt wird, als ob der Sektor ausgerichtet und angepasst wurde, damit SQL Server nicht erkennt und ordnungsgemäß von der zugrunde liegenden Implementierung gesichert ist. Sehen Sie sich das Komprimierungsbeispiel näher an.

  • Sektor 1 wird auf das Gerät geschrieben und komprimiert, um Platz zu sparen.
  • Sektor 2 wird auf das Gerät geschrieben und mit Sektor 1 komprimiert, um Platz zu sparen.

Das Gerät kann die folgenden Aktionen ausführen, um die Daten der Branche 1 zu sichern, wenn es mit den Daten von Sektor 2 kombiniert wird.

  • Alle Schreibvorgänge in die Sektoren 1 und 2 blockieren.
  • Entkomprimieren Sie Sektor 1 in einen Entwurfsbereich, sodass der aktuelle Sektor 1-Speicher als aktive Daten abgerufen werden kann.
  • Komprimieren Sie die Sektoren 1 und 2 in ein neues Speicherformat.
  • Alle Lese- und Schreibvorgänge der Sektoren 1 und 2 blockieren.
  • Exchange alter Speicher für die Sektoren 1 und 2 mit neuem Speicher. Wenn der Austauschversuch fehlschlägt (Rollback):
    • Stellen Sie den ursprünglichen Speicher für die Sektoren 1 und 2 wieder her.
    • Entfernen Sie die Sektoren 1 und 2 kombinierte Daten aus dem Entwurfsbereich.
    • Fehler beim Schreiben des Sektor 2-Schreibvorgangs.
  • Aufheben der Blockierung von Lese- und Schreibvorgängen für die Sektoren 1 und 2.

Die Möglichkeit, Sperrmechanismen rund um die Sektoränderungen bereitzustellen und die Änderungen zurückzurufen, wenn der Sektoraustauschversuch fehlschlägt, gilt als übergangskonform. Bei Implementierungen, die physischen Speicher für die erweiterte Sicherung verwenden, würde es die entsprechenden Transaktionsprotokollaspekte enthalten, um Änderungen zu sichern und zurückzugeben, die auf die Strukturen auf dem Datenträger angewendet wurden, um die Integrität der SQL Server-Datenbankdateien aufrechtzuerhalten.

Jedes Gerät, das das Umschreiben von Sektoren ermöglicht, muss die Umschreibung auf transaktionsseitige Weise unterstützen, sodass SQL Server nicht datenverlustbelastet ist.

Notiz

Die Instanz von SQL Server wird neu gestartet, wenn Online-E/A-Fehler auftreten und Rollbackfehler in der tempdb-Datenbank auftreten.

Achten Sie darauf, wenn Sie die tempdb-Datenbank verschieben.

Achten Sie beim Verschieben der tempdb-Datenbank darauf, dass SQL Server nicht gestartet wird, wenn die tempdb-Datenbank nicht erstellt werden kann. Wenn die tempdb-Datenbank nicht erstellt werden kann, starten Sie SQL Server mithilfe des (-f)-Startparameters, und verschieben Sie die tempdb-Datenbank an einen gültigen Speicherort.

Führen Sie die folgenden Schritte aus, um den physischen Speicherort der tempdb-Datenbank zu ändern:

  1. Verwenden Sie die ALTER DATABASE Anweisung und die MODIFY FILE Klausel, um die physischen Dateinamen jeder Datei in der tempdb-Datenbank zu ändern, um auf den neuen physischen Speicherort zu verweisen, z. B. auf den neuen Datenträger.

    ALTER DATABASE tempdb MODIFY FILE 
(name = tempdev, filename = 'C:\MyPath\tempdb.mdf')

ALTER DATABASE tempdb MODIFY FILE 
(name = templog, filename = 'C:\MyPath\templog.ldf')

  2. Beenden Sie SQL Server, und starten Sie sie dann neu.

Partnerproduktzertifizierungen sind kein Garant für Kompatibilität oder Sicherheit

Ein Drittanbieterprodukt oder ein bestimmter Anbieter kann eine Microsoft-Logo-Zertifizierung erhalten. Die Partnerzertifizierung oder ein bestimmtes Microsoft-Logo zertifizieren jedoch keine Kompatibilität oder Eignung für einen bestimmten Zweck in SQL Server.

Unterstützung

Wenn Sie ein Subsystem mit SQL Server verwenden, das die E/A-Garantien für die Transaktionsdatenbankverwendung unterstützt, wie in diesem Artikel beschrieben, bietet Microsoft Unterstützung für SQL Server- und SQL Server-basierte Anwendungen. Probleme mit oder verursacht durch das Subsystem werden jedoch an den Hersteller verwiesen.

Bei datenbankbezogenen tempdb-Problemen werden Sie Microsoft-Support Dienste aufgefordert, die tempdb-Datenbank zu verschieben. Wenden Sie sich an Ihren Geräteanbieter, um zu überprüfen, ob Sie das Gerät ordnungsgemäß bereitgestellt und für die Verwendung von Transaktionsdatenbanken konfiguriert haben.

Microsoft zertifiziert oder überprüft nicht, ob Produkte von Drittanbietern mit SQL Server ordnungsgemäß funktionieren. Darüber hinaus bietet Microsoft keine Garantie, Garantie oder Erklärung der Eignung eines Drittanbieterprodukts für die Verwendung mit SQL Server.

Verweise

Weitere Informationen finden Sie unter:

  • Last updated on