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

  • Artikel

In diesem Artikel werden die Anforderungen an das E/A-Subsystem für die tempdb-Datenbank in SQL Server eingeführt.

Ursprüngliche Produktversion: Microsoft SQL Server 2005, SQL Server 2008, SQL Server 2012 SQL Server 2014
Ursprüngliche KB-Nummer: 917047

Zusammenfassung

Microsoft SQL Server erfordert, dass das E/A-Subsystem, das zum Speichern von System- und Benutzerdatenbanken verwendet wird, Write-Ahead Protokollierungsanforderungen (WAL) über bestimmte E/A-Prinzipale vollständig erfüllt. Diese Anforderungen sind erforderlich, um die ACID-Eigenschaften von Transaktionen zu berücksichtigen: Atomic, Consistent, Isolated und Durable. Details zu den Complianceanforderungen für das E/A-Subsystem finden Sie in den folgenden Referenzen:

SQL Server 2000 E/A-Grundlagenhttps://technet.microsoft.com/library/cc966500.aspx

Hinweis

Dieser Artikel gilt auch für SQL Server 2005 und höhere Versionen.

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

  • Die Schreibreihenfolge muss beibehalten werden.
  • Abhängige Schreibkonsistenz muss beibehalten werden.
  • Schreibvorgänge müssen immer auf stabilen Medien gesichert werden.
  • Gerissene E/A-Verhinderung muss auftreten.

Die Dauerhaftigkeitswartung bleibt für alle anderen Datenbanken von entscheidender Bedeutung, kann aber für die tempdb-Datenbank gelockert werden. In der folgenden Tabelle sind einige der kritischen E/A-Anforderungen für SQL Server Datenbanken zusammengefasst.

E/A-Anforderung Kurze Beschreibung System oder Benutzer tempdb
Schreibreihenfolge

Abhängige Schreibkonsistenz		 Die Fähigkeit des Subsystems, die richtige Reihenfolge von Schreibvorgängen beizubehalten. Dies kann besonders wichtig für Spiegelungslösungen, Gruppenkonsistenzanforderungen und SQL Server Verwendung des WAL-Protokolls sein. Erforderlich Empfohlen
Lesen nach dem Schreiben Die Fähigkeit des Subsystems, Leseanforderungen mit dem neuesten Datenimage zu verarbeiten, wenn der Lesevorgang ausgegeben wird, nachdem ein Schreibvorgang erfolgreich abgeschlossen wurde. Erforderlich Erforderlich
Überleben bei Ausfall Die Möglichkeit, dass Daten bei einem Ausfall, z. B. einem Systemneustart, vollständig intakt (dauerhaft) bleiben. Erforderlich Nicht zutreffend
Gerissene E/A-Verhinderung Die Fähigkeit des Systems, die Aufteilung einzelner E/A-Anforderungen zu vermeiden. Erforderlich Empfohlen
Sektor rewrite 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 Die Erwartung, dass daten auf stabilen Medien gespeichert wurden, wenn eine Schreibanforderung oder ein FlushFileBuffers-Vorgang erfolgreich abgeschlossen wurde. Erforderlich Nicht zutreffend
Ausrichtung und Größe des physischen Sektors SQL Server fragt die Speicherorte für Daten und Protokolldateien ab. Alle Geräte müssen Sektorattribute unterstützen, die es SQL Server ermöglichen, Schreibvorgänge an physischen sektorbezogenen Grenzen und in Vielfachen der Sektorgröße auszuführen. Erforderlich Erforderlich

Transaktionssektor-Rewrites umfassen vollständig protokollierte Vorgänge durch das Subsystem, die es ermöglichen, dass ein Sektor vollständig verschoben, ersetzt oder zurück auf das ursprüngliche Image zurückgesetzt werden kann. Von diesen Neuschreibungen wird in der Regel aufgrund des zusätzlichen Mehraufwands abgeraten, der zum Ausführen solcher Aktionen erforderlich ist. Ein Beispiel hierfür wäre ein defragmentation Hilfsprogramm, das die Dateidaten verschiebt. Der ursprüngliche Sektor in der Datei kann erst durch den neuen Sektorstandort ersetzt werden, wenn der neue Sektor und die Daten gesichert sind. Die Neuzuordnung des Sektors muss auf transaktionale Weise erfolgen, sodass jeder Ausfall, einschließlich eines Stromausfalls, die Wiederherstellung der ursprünglichen Daten verursacht. Stellen Sie sicher, dass Während dieser Art von Prozess Sperrmechanismen verfügbar sind, um ungültigen Datenzugriff zu verhindern, und behalten Sie dadurch die anderen Mandanten von SQL Server E/A bei.

Überleben bei Ausfall

Die tempdb-Datenbank ist ein Ablagebereich für SQL Server und wird bei jedem start SQL Server neu erstellt. Die Initialisierung ersetzt alle Notwendigkeiten für Daten, um einen Neustart zu überstehen.

Transaktionssektor-Umschreibungsvorgänge

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 können nicht ohne Berücksichtigung von Transaktionseigenschaften neu geschrieben werden. Dies erfordert, dass das Subsystem und SQL Server bestimmte Attribute wie Schreibreihenfolge, sektorbezogene und größenbezogene Schreibvorgänge und andere E/A-Sicherheitsattribute beibehalten müssen, die in den oben genannten Dokumenten beschrieben sind. Für die tempdb-Datenbank ist die Absturzwiederherstellung nicht erforderlich, da die Datenbank immer während SQL Server Start initialisiert wird. Für die tempdb-Datenbank sind jedoch weiterhin Rollbackfunktionen erforderlich. Daher können einige Attribute des WAL-Protokolls gelockert werden.

Der Speicherort für die tempdb-Datenbank muss in strikter Übereinstimmung mit den etablierten Datenträgerlaufwerkprotokollen 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. Transaktionssektor-Umschreibungsvorgänge können eine zusätzliche Anforderung bestimmter Implementierungen sein. Beispielsweise unterstützt SQL Server keine Datenbankänderungen mithilfe der NTFS-Dateisystemkomprimierung, da die NTFS-Komprimierung Sektoren des Protokolls umschreiben kann, die bereits geschrieben und als gehärtet betrachtet wurden. Ein Fehler während dieser Art des erneuten Generierens kann dazu führen, dass die Datenbank unbrauchbar ist und daten beschädigt SQL Server, die bereits als sicher angesehen SQL Server.

Hinweis

SQL Server 2005 erweiterte Unterstützung oder Komprimierung für schreibgeschützte Datenbanken und Dateigruppen. Ausführliche Informationen finden Sie in der SQL Server 2005-Onlinedokumentation.

Transaktionssektor-Umschreibungsvorgänge sind für alle SQL Server Datenbanken relevant, die die tempdb-Datenbank enthalten. Eine wachsende Vielfalt erweiterter Speichertechnologien verwendet Geräte und Hilfsprogramme, die Daten umschreiben können, die SQL Server als sicher erachtet. Einige der neuen Technologien führen beispielsweise In-Memory-Zwischenspeicherung oder Datenkomprimierung durch. Um schwerwiegende Datenbankschäden zu vermeiden, muss jede Sektor-Neuschreibung über vollständige Transaktionsunterstützung verfügen, sodass im Fall eines Fehlers ein Rollback der Daten auf die vorherigen Sektorimages ausgeführt wird. Dadurch wird sichergestellt, dass SQL Server niemals unerwarteten Unterbrechungen oder Datenschäden ausgesetzt ist.

Möglicherweise können Sie die tempdb-Datenbank auf speziellen Subsystemen wie RAM-Datenträgern, Solid State oder anderen Hochgeschwindigkeitsimplementierungen platzieren, die nicht für andere Datenbanken verwendet werden können. Bei der Auswertung dieser Optionen müssen jedoch die im Abschnitt Weitere Informationen aufgeführten Schlüsselfaktoren berücksichtigt werden.

Hinweis

Die lokalen Datenträger in Failoverclusterumgebungen werden nur mit Solid State- 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 Features des iSCSI-Ziels und des Failoverclusters nicht auf demselben Host verwendet werden.

Weitere Informationen

Bei der Auswertung des Speicherorts der tempdb-Datenbank sollten mehrere Faktoren sorgfältig untersucht werden. Die Tempdb-Datenbanknutzung umfasst z. B. Speicherbedarf, 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 beim Bestimmen des Speicherbedarfs für die tempdb-Datenbank erläutert.

Hochgeschwindigkeitssubsysteme

Auf dem Markt sind verschiedene Hochgeschwindigkeitssubsystemimplementierungen verfügbar, die SQL Server Anforderungen an das Protokoll des E/A-Subsystems erfüllen, aber keine Dauerhaftigkeit der Medien bieten.

Wichtig

Vergewissern Sie sich immer beim Produktanbieter, um die vollständige Einhaltung 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 Standard RAM-Datenträgers wie jedes Laufwerk, das an das System angefügt ist, angezeigt wird und funktioniert. Alle E/A-Subsysteme sollten die SQL Server E/A-Anforderungen vollständig erfüllen. 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 und nicht für eine andere Datenbank verwendet werden.

Schlüssel, die vor der Implementierung und Bereitstellung zu berücksichtigen sind

Es gibt verschiedene Punkte, die vor der Bereitstellung der tempdb-Datenbank auf dieser Art von Subsystem zu berücksichtigen sind. In diesem Abschnitt wird ein RAM-Datenträger als Grundlage für die Diskussion verwendet, aber ähnliche Ergebnisse treten bei anderen Hochgeschwindigkeitsimplementierungen auf.

E/A-Sicherheit

Die Konformität von Lesevorgängen nach schreib- und Transaktionssektorschreibvorgängen ist ein Muss. Stellen Sie niemals SQL Server 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 durch verzögerte Schreibvorgänge verarbeitet. Das Speichern temporärer Tabellenseiten auf einem RAM-Datenträger führt zu doppelter RAM-Zwischenspeicherung, eine im Pufferpool und eine auf dem RAM-Datenträger. Dies nimmt die gesamte mögliche Größe des Pufferpools direkt weg und verringert im Allgemeinen die Leistung von SQL Server.

Verzicht auf RAM

Der RAM-Datenträger bezeichnet einen Teil Standard RAM, wie der Name schon sagt. Es sind mehrere Implementierungen von RAM-Datenträgern und RAM-basierten Dateicaches verfügbar. Einige ermöglichen auch physische E/A-Unterstützungsvorgänge. Das wichtigste Element des RAM-basierten Dateicaches ist, dass er direkt aus dem physischen Speicher entfernt wird, der von SQL Server verwendet werden kann. Stellen Sie immer sicher, dass das Hinzufügen eines RAM-basierten Dateicaches die Anwendungsleistung verbessert und die Leistung anderer Abfragen oder Anwendungen nicht beeinträchtigt.

Zuerst optimieren

Eine Anwendung sollte optimieren, um unnötige und unerwünschte Sortierungen und Hashes zu entfernen, die die Verwendung der tempdb-Datenbank verursachen könnten. Häufig kann das Hinzufügen eines Indexes dazu führen, dass die Sortierung oder der Hash im Plan vollständig erforderlich ist, was zu einer optimalen Leistung führt, ohne dass die tempdb-Datenbank verwendet werden muss.

Mögliche Vorteilspunkte

Die Vorteile der Verwendung der tempdb-Datenbank auf einem Hochgeschwindigkeitssystem können nur durch strenge Tests und Messungen der Anwendungsworkloads ermittelt werden. Die Workload muss sorgfältig auf die Merkmale 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 Speicher-Managern zusammen, um die Größe des Speicherbereichs im Arbeitsspeicher für jeden Sortier- oder Hashvorgang zu bestimmen. Sobald die Sortier- oder Hashdaten den zugeordneten Speicherbereich überschreiten, können Daten in die tempdb-Datenbank geschrieben werden. Dieser Algorithmus wurde SQL Server 2005 erweitert, wodurch die Anforderungen an die Tempdb-Datenbanknutzung gegenüber früheren Versionen von SQL Server reduziert wurden.

Achtung

SQL Server ist so konzipiert, dass speicherebenen und aktuelle Abfrageaktivitäten bei Abfrageplanentscheidungen berücksichtigt werden, die die Verwendung von tempdb-Datenbankvorgängen beinhalten. Daher variieren die Leistungssteigerungen je nach Workloads und Anwendungsentwurf erheblich. Es wird dringend empfohlen, tests mit der bevorzugten Lösung abzuschließen, um mögliche Vorteile 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 gängigen Pufferpoolroutinen für Datenseiten verwaltet und weisen im Allgemeinen keine Leistungsvorteile von Speziellen Subsystemimplementierungen auf.
  • Die tempdb-Datenbank wird als Scratchbereich 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 zur Vermeidung eines Hashs oder einer Sortierung einen ähnlichen Vorteil bieten kann.

Führen Sie Baselines mit und ohne die im Hochgeschwindigkeitssubsystem gespeicherte tempdb-Datenbank aus, um die Vorteile zu vergleichen. Ein Teil der Tests sollte Abfragen für die Benutzerdatenbank enthalten, die keine Sortierungen, Hashes oder temporären Tabellen umfassen, und dann sicherstellen, dass diese Abfragen nicht beeinträchtigt werden. Bei der Bewertung des Systems können die folgenden Leistungsindikatoren hilfreich sein.

Indikator Beschreibung/Verwendung
Seitenlese- und Schreibvorgänge Durch die Verbesserung der Leistung der E/A-Vorgänge der tempdb-Datenbank kann sich die Rate der Seitenlese- und Schreibvorgänge für die Benutzerdatenbanken aufgrund der verringerten Latenz im Zusammenhang mit der tempdb-Datenbank-E/A ändern. Bei Benutzerdatenbankseiten sollte die Gesamtanzahl nicht für dieselbe Workload variieren.
Physische Lese- und Schreibbytes 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, weist dies darauf hin, dass der aus dem Pufferpool entfernte Arbeitsspeicher zu einer erhöhten tempdb-Datenbankaktivität führt. Dieses Muster ist ein Indikator dafür, dass die Seitenlebenserwartung von Datenbankseiten auch negativ beeinflusst werden kann.
Seitenlebenserwartung Ein Rückgang der Seitenlebenserwartung kann auf einen Anstieg der physischen E/A-Anforderungen für eine Benutzerdatenbank hinweisen. Die Verringerung der Rate könnte wahrscheinlich darauf hindeuten, dass der aus dem Pufferpool genommene Arbeitsspeicher datenbankseitige Seiten erzwingt, den Pufferpool vorzeitig zu verlassen. Kombinieren Sie mit den anderen Indikatoren, und testen Sie, um die Parametergrenzen vollständig zu verstehen.
Gesamtdurchsatz
CPU-Auslastung
Skalierbarkeit
Antwortzeit		 Das primäre Ziel einer tempdb-Datenbankkonfigurationsänderung besteht darin, den Gesamtdurchsatz zu erhöhen. Ihre Tests sollten eine Mischung aus wiederholbaren Workloads enthalten, die horizontal hochskaliert werden können, um zu bestimmen, wie sich der Durchsatz auswirkt.

Eine komprimierungsbasierte RAM-Datenträgerimplementierung kann mit 10 Benutzern gut funktionieren. Bei erhöhter Workload kann dies jedoch die CPU-Ebene über die gewünschten Ebenen hinaus pushen und negative Auswirkungen auf die Antwortzeit haben, wenn die Workloads hoch sind. Echte Belastungstests und zukünftige Auslastungsvorhersagetests werden empfohlen.
Arbeitsdateien und Arbeitstabellenerstellungsaktionen Wenn das Verschieben der tempdb-Datenbank auf ein Gerät, z. B. einen RAM-Datenträger, den Abfrageplan ändert, indem die Anzahl oder Größe von Arbeitsdateien oder Arbeitstabellen erhöht wird, weist dies darauf hin, dass der aus dem Pufferpool entfernte Arbeitsspeicher zu einer erhöhten tempdb-Datenbankaktivität führt. Dieses Muster ist ein Hinweis darauf, dass die Seitenlebenserwartung von Datenbankseiten auch negativ beeinflusst werden kann.

Beispiel für das Erneute Generieren eines Transaktionssektors

Im folgenden Beispiel wird die Datensicherheit erläutert, die für SQL Server Datenbanken erforderlich ist.

Angenommen, ein RAM-Datenträgerhersteller verwendet eine In-Memory-Komprimierungsimplementierung. Die Implementierung muss ordnungsgemäß gekapselt werden, indem das physische Erscheinungsbild des Dateidatenstroms bereitgestellt wird, als ob der Sektor ausgerichtet und dimensioniert wäre, sodass SQL Server nicht bekannt ist und ordnungsgemäß vor der zugrunde liegenden Implementierung geschützt ist. Sehen Sie sich das Komprimierungsbeispiel genauer an.

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

Das Gerät kann die folgenden Aktionen ausführen, um die Daten von Sektor 1 zu schützen, wenn sie mit den Daten von Sektor 2 kombiniert werden.

  • Alle Schreibvorgänge in Sektoren 1 und 2 blockieren.
  • Dekomprimieren Sie Sektor 1 in einem Scratchbereich, und lassen Sie den aktuellen Sektor 1-Speicher als aktive Daten, die abgerufen werden sollen.
  • Komprimieren Sie die Sektoren 1 und 2 in ein neues Speicherformat.
  • Alle Lese- und Schreibvorgänge der Sektoren 1 und 2 blockieren.
  • Tauschen Sie alten Speicher für die Sektoren 1 und 2 mit neuem Speicher aus. Wenn der Austauschversuch fehlschlägt (Rollback):
    • Stellen Sie den ursprünglichen Speicher für die Sektoren 1 und 2 wieder her.
    • Entfernen Sie die kombinierten Daten der Sektoren 1 und 2 aus dem Scratch-Bereich.
    • Fehler beim Sektor 2-Schreibvorgang.
  • Aufheben der Blockierung von Lese- und Schreibvorgängen für Sektoren 1 und 2.

Die Möglichkeit, Sperrmechanismen für sektorspezifische Änderungen bereitzustellen und die Änderungen zurück zu setzen, wenn der Sektoraustausch fehlschlägt, gilt als übergangskonform. Für Implementierungen, die physischen Speicher für erweiterte Sicherungen verwenden, enthält sie die entsprechenden Transaktionsprotokollaspekte, um Änderungen zu schützen und zurückzusetzen, die auf die Strukturen auf dem Datenträger angewendet wurden, um die Integrität der SQL Server Datenbankdateien aufrechtzuerhalten.

Jedes Gerät, das das erneute Generieren von Sektoren ermöglicht, muss die Neuschreibungen auf transaktionale Weise unterstützen, sodass SQL Server nicht datenverlustbefallt ist.

Hinweis

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

Seien Sie beim Verschieben der tempdb-Datenbank vorsichtig

Gehen Sie beim Verschieben der tempdb-Datenbank vorsichtig vor, denn wenn die tempdb-Datenbank nicht erstellt werden kann, wird SQL Server nicht gestartet. Wenn die tempdb-Datenbank nicht erstellt werden kann, starten Sie SQL Server mithilfe des Startparameters (-f), 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. 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 ihn dann neu.

Zertifizierungen von Partnerprodukten sind keine Garantie für Kompatibilität oder Sicherheit

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

Support

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

Bei problemen mit der tempdb-Datenbank werden Sie von Microsoft-Support Services aufgefordert, die tempdb-Datenbank zu verschieben. Wenden Sie sich an Ihren Gerätehersteller, 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, dass Produkte von Drittanbietern ordnungsgemäß mit SQL Server funktionieren. Darüber hinaus bietet Microsoft keine Garantie, Garantie oder Erklärung für die Eignung eines Drittanbieterprodukts für die Verwendung mit SQL Server.

References

Weitere Informationen finden Sie in den folgenden Microsoft Knowledge Base-Artikeln: