Microsoft SQL Server e/a-Subsystem an die Tempdb-Datenbank

Gilt für: Microsoft SQL Server 2005 Express EditionMicrosoft SQL Server 2005 Standard EditionMicrosoft SQL Server 2005 Workgroup Edition

Zusammenfassung


Microsoft SQL Server erfordert, dass das e/a-Subsystem zum Speichern von System- und Benutzerdatenbanken vollständig Write-Ahead-Logging (WAL) Vorschriften über bestimmte e/a-Prinzipale berücksichtigen. Diese Vorschriften sind notwendig, um die ACID-Eigenschaften von Transaktionen berücksichtigt: atomar, konsistent, isoliert und dauerhaft. Die folgenden Verweise enthält Details zu e/a-Subsystem Auflagen:Die folgende Liste ist eine kurze Zusammenfassung der erforderlichen:
  • Schreibreihenfolge einzuhalten.
  • Schreibvorgang Konsistenz einzuhalten.
  • Schreibt müssen immer in oder auf stabilen Medium gesichert werden.
  • Zerrissene e/a-Prevention muss auftreten.
Haltbarkeit Wartung kann bleibt für alle anderen Datenbanken jedoch für die Tempdb -Datenbank entspannt. Der folgende Tabelle werden mehrere wichtigen e/a-Anforderungen für SQL Server-Datenbanken.
E/a-AnforderungKurze BeschreibungSystem- odertempdb
Reihenfolge geschrieben

Schreibvorgang Konsistenz
Die Möglichkeit, die Reihenfolge der Schreibvorgänge Verwalten des Teilsystems. Dies ist besonders wichtig für die Spiegelung Lösungen, konsistenzanforderungen und SQL Server WAL-Protokoll verwenden.ErforderlichEmpfohlen
Nach dem Schreiben LesenDie Möglichkeit des Teilsystems Service lesen Anfragen mit den neuesten Daten beim Lesen erfolgt nach jedem Schreibvorgang erfolgreich abgeschlossen wurde.ErforderlichErforderlich
Überleben über AusfälleDie Möglichkeit, dass Daten weiterhin voll starten intakt (langlebig) über ein Ausfall wie ein.ErforderlichNicht zutreffend
Zerrissene e/a-PräventionDie Fähigkeit des Systems zu einzelne e/a-Anfragen aufteilen.ErforderlichEmpfohlen
Sektor schreibenBereich kann nur in seiner Gesamtheit geschrieben und kann nicht durch eine schreibanforderung auf einen benachbarten umgeschrieben werden.* Abgeraten, nur wenn Transaktions-* Abgeraten, nur wenn Transaktions-
Gesicherte DatenDie Annahme, dass beim Schreiben oder FlushFileBuffers Vorgang erfolgreich, stabile Medien gespeichert sind.ErforderlichNicht zutreffend
Physische Sektor Ausrichtung und GrößeSQL Server fragt die Daten- und Protokolldateien Datei-Speicherorte. Alle Geräte müssen Sektor ermöglicht SQL Server für Schreibvorgänge auf Grenzen ausgerichtet und ein Vielfaches der Sektorgröße Unterstützung.ErforderlichErforderlich
* Transaktionalen Bereich schreibt beinhalten Teilsystems ermöglichen einen Sektor vollständig verschoben, ersetzt oder Rollback zum ursprünglichen Bild vollständig protokollierte Vorgänge. Diese schreibt in der Regel durch den zusätzlichen Aufwand für solche Aktionen abgeraten. Ein Beispiel hierfür wäre ein Defragmentierungsprogramm, das die Daten verschieben. Ursprünglichen Bereich in der Datei kann Sektor Position ersetzt werden, bis die neuen und die Daten vollständig geschützt sind. Neuzuordnen des Sektors muss in Form einer Transaktion auftreten, sodass Ausfälle, einschließlich eines Stromausfalls bewirkt, die Wiederherstellung der ursprünglichen Daten dass. Achten Sie Sperrmechanismen verfügbar bei diesem Prozess zu ungültigen Datenzugriff und Einhaltung der Mieter SQL Server i/o.

Überleben über Ausfälle

Die Tempdb -Datenbank ist der Entwurfsbereich für SQL Server und bei jedem Start von SQL Server neu erstellt. Die Initialisierung ersetzt müssen keine Daten zu starten.

Transaktionale Sektor schreiben

Zum Erfolg der Recovery-Prozesse wie Rollback und Crash Recovery müssen Protokolldatensätze ordnungsgemäß auf stabilen Medium gespeichert werden vor die Seite gespeichert und kann nicht ohne berücksichtigt Transaktionseigenschaften umgeschrieben werden. Dies erfordert Subsystem und SQL Server-spezifische Attribute wie Schreibreihenfolge ausgerichtet und schreibt, Größe und andere diese e/a-Sicherheit Attribute in den zuvor erwähnten Dokumenten beschrieben. Für die Tempdb -Datenbank ist die Wiederherstellung nicht benötigte Datenbank immer beim Starten von SQL Server initialisiert wird. Die Tempdb -Datenbank erfordert jedoch weiterhin Rollback-Funktionen. Daher können einige Attribute des Protokolls WAL gelockert.

Der Speicherort für die Datenbank Tempdb muss in Übereinstimmung mit festgelegten Laufwerk Protokolle fungieren. Auf alle Arten muss auf die Tempdb -Datenbank gespeichert ist angezeigt und dienen als eine physische Festplatte gelesen nach Schreibfunktionen bereitstellen. Transaktion Sektor schreiben möglicherweise eine zusätzliche Anforderung der spezifischen Implementierung. Beispielsweise unterstützt SQL Server-Datenbank nicht, Änderungen mit NTFS-Komprimierung, da NTFS-Komprimierung Sektoren, die bereits geschrieben und als Protokoll schreiben kann abgesichert. Fehler bei diesem schreiben kann Datenbank verwendet Daten beschädigt werden, dass SQL Server bereits als sicher.

Hinweis SQL Server 2005 erweiterten Support oder Komprimierung nur Datenbanken und Dateigruppen. Finden Sie unter SQL Server 2005 Books Online Weitere Informationen.

Transaktionale Sektor schreiben sind für alle SQL Server-Datenbanken, die Tempdb -Datenbank enthalten. Wachsende verschiedene erweiterte Technologien verwenden Geräte und Dienstprogramme, die Daten schreiben können, die SQL Server als sicher betrachtet. Beispielsweise führen einige neue im Arbeitsspeicher Zwischenspeichern oder Datenkompression. Um schwere Datenbank vermeiden alle Sektor schreiben müssen vollständige transaktionale Unterstützung so, dass bei einem Fehler die Daten der vorherigen Sektor Bilder zurückgesetzt werden. Dies garantiert, dass SQL Server nie eine unerwartete Unterbrechung oder Daten Schaden Zustand verfügbar gemacht wird.

Möglicherweise können Sie die Tempdb -Datenbank auf spezielle Subsysteme wie RAM-Laufwerke, solid-State oder andere high-Speed-Implementierung, die für andere Datenbanken verwendet werden können. Jedoch wichtigen Faktoren im Abschnitt "Weitere Informationen" berücksichtigen diese Optionen auswerten.

Weitere Informationen


Faktoren sollten sorgfältig untersucht werden, wenn Sie den Speicherort der Datenbank Tempdb auswerten. Beispielsweise die Nutzung der Tempdb -Datenbank umfasst, jedoch nicht auf Speicherbedarf Abfrageplan und e/a-Entscheidung. Entsprechende Tuning und Implementierung der Datenbank Tempdb verbessern Skalierbarkeits- und Reaktionsfähigkeit eines Systems. Dieser Abschnitt beschreibt die wichtigsten Faktoren der Speicherbedarf für die Tempdb -Datenbank.

High-Speed-Subsysteme

Gibt verschiedene Hochgeschwindigkeits-Subsystem-Implementierung auf dem Markt, bieten SQL Server e/a-Subsystem protokollanforderungen, die bieten jedoch keine Beständigkeit des Mediums.

Wichtig Immer bestätigen Sie Hersteller Produkt muss SQL Server i/o-Einhaltung sicherzustellen.

Ein RAM-Datenträger ist ein allgemeines Beispiel für eine Implementierung. RAM-Laufwerke installiert die erforderlichen Treiber und aktivieren Teil der wichtigsten RAM-Disk wie und wie einem beliebigen Laufwerk an das System angeschlossen ist. Alle e/a-Subsysteme soll vollständige Einhaltung SQL Server i/o. Es ist jedoch, dass ein RAM-Datenträger nicht dauerhaftes Medium. Daher eine Implementierung wie ein RAM-Datenträger kann nur als Speicherort für die Datenbank Tempdb verwendet und kann nicht für eine Datenbank verwendet werden.

Schlüssel müssen vor der Implementierung und Bereitstellung

Es gibt verschiedene Punkte, die vor der Bereitstellung der Datenbank Tempdb auf dieser Art von Subsystem. In diesem Abschnitt verwendet einen RAM-Datenträger als Grundlage für Diskussionen, aber ähnliche Ergebnisse in anderen high-Speed-Implementierung auftreten.

E/a-Sicherheit

Compliance lesen, schreiben und schreibt transaktionalen Bereich ist. SQL Server nicht auf jedem System, das SQL Server e/a-Anforderung nicht vollständig unterstützt bereitstellen oder Risiko Beschädigung und Verlust von Daten.

Seiten bereits zwischengespeichert (Double RAM-Cache)

Temporäre Tabellen werden wie alle anderen Tabellen in einer Datenbank. Sie werden vom Pufferpool zwischengespeichert und von verzögerte Schreibvorgänge. Temporäre Tabellenseiten auf einem RAM-Datenträger speichern verursacht doppelte RAM Zwischenspeichern im Pufferpool und die RAM-Disk. Dies nimmt direkt mögliche Größe des Pufferpools befinden und in der Regel wird die Leistung von SQL Server.

Geben Arbeitsspeicher

Der RAM-Disk bezeichnet einen Teil des RAM-Speicher, wie der Name impliziert. Es sind mehrere Implementierungen von RAM-Disks und RAM-basierten Dateien Caches verfügbar. Einige ermöglichen auch physische e/a unterstützt Operationen. Das zentrale Element der RAM-basierte Datei-Cache werden direkt vom physischen Speicher benötigt, die von SQL Server verwendet werden kann. Immer nachgewiesen hinzufügen ein RAM-basierte Datei-Cache verbessert die Leistung der Anwendung und nicht andere Abfrage oder Anwendung die Leistung verringern.

Zuerst optimieren

Eine Anwendung sollte optimieren, unnötige und unerwünschte sortiert und ab der Tempdb -Datenbank führen können. Oft das Hinzufügen eines Indexes kann Sortier- oder Hashoperationen im Plan vollständig überflüssig zur optimalen ohne Verwendung der Tempdb -Datenbank.

Nutzen Punkte

Die Vorteile, die Tempdb -Datenbank auf einem high-Speed-System können nur durch strenge Tests und Messung der Arbeitslasten ermittelt werden. Die Arbeitslast muss sorgfältig werden Eigenschaften, die die Tempdb -Datenbank kann von e/a-Sicherheit muss vor der Bereitstellung bestätigt werden.

Die Vorgänge sortieren und Hash gemeinsam mit SQL Server-Speicher-Manager die Größe der im Arbeitsspeicher Entwurfsbereich für jede Sortier- oder Hash-Operation. Als die Sortier- oder Hash-Daten zugeordneten Entwurfsbereich im Speicher überschreitet, können Daten in der Tempdb -Datenbank geschrieben. Dieser Algorithmus wurde in SQL Server 2005, Reduzierung der Tempdb -Datenbank Verwendung gegenüber früheren Versionen von SQL Server erweitert. Beispielsweise mithilfe einer reinen erzwungene Sortieren einer Tabelle keine Indizes absteigende Reihenfolge und dieselbe Hardwarekonfiguration SQL Server 2005 zeigt spürbare über SQL Server 2000.

Achtung: SQL Server dient zu Speicher-Ebenen und aktuelle Abfrage bei Abfrage Plan, der die Verwendung der Datenbank Tempdb . Daher hängen die Leistungssteigerung erheblich Arbeitslasten und Anwendung. Wir empfehlen die bevorzugte Lösung möglich Gewinne und e/a-Anforderungen vor einer Bereitstellung auswerten Test abgeschlossen.

SQL Server verwendet die Tempdb -Datenbank sortiert, Hashes, die Speicherung der Zeilenversion mit Aktivitäten und temporäre Tabellen:
  • Temporäre Tabellen gemeinsame Puffer Pool Routinen für Datenseiten verwaltet und Leistungsvorteile von Specialty Subsystem Implementierung im Allgemeinen nicht auf.
  • Die Tempdb -Datenbank dient als Entwurfsbereich für Hashes und sortiert. E/a-Wartezeit für solche Operationen verringern kann hilfreich sein. Jedoch wissen Sie, dass Hinzufügen eines Indexes zur Vermeidung von Hash oder eine ähnlichen nutzen kann.
Führen Sie Baselines mit und ohne die Tempdb -Datenbank auf Hochgeschwindigkeits-Subsystem Vorteile vergleichen. Die Tests sollten Abfragen der Datenbank gehört, die nicht sortiert, Hashes oder temporären Tabellen beinhalten, und bestätigen Sie, dass diese Abfragen nicht beeinträchtigt werden. Beim Auswerten des Systems kann die folgenden Leistungsindikatoren.
AnzeigeDescription/usage
Seite Lese- und SchreibvorgängeVerbessern der Leistung von Tempdb kann Datenbank OS die Seite Lese- und Schreibvorgänge für die Benutzerdatenbanken durch geringere Latenz der Tempdb -Datenbank e/a-ändern. Bei Datenbankseiten Benutzer sollte die Anzahl nicht die gleiche Arbeitslast variieren.
Physische Bytes lesen und Schreiben in die Tempdb-DatenbankSteigt die Tempdb -Datenbank auf einem Gerät wie einem RAM-Datenträger verschieben die tatsächliche e/a für die Tempdb -Datenbank, gibt an, dass der Speicher vom Pufferpool erhöhte Tempdb -Datenbankaktivität verursacht. Dieses Muster ist ein Indikator, dass die Lebenserwartung der Datenbank Mai auch Seiten negativ beeinflusst werden.
LebenserwartungEin Rückgang der Lebenserwartung kann Zunahme der e/a-Anforderungen an eine Datenbank angeben. Geschwindigkeit verringern deutet wahrscheinlich der Speicher vom Pufferpool auf Pufferpool vorzeitig beenden zwingt. Mit anderen Indikatoren und verstehen die Grenzen Parameter überprüfen.
Gesamtdurchsatz
CPU-Auslastung
Skalierung
Reaktionszeit
Tempdb -Datenbank-Konfiguration ändert das Hauptziel ist den Gesamtdurchsatz erhöhen. Die Tests sollten aus wiederholbare Arbeitslasten enthalten, die skaliert werden kann, bestimmen, wie Durchsatz auswirken.

Etwa eine Komprimierung RAM Disk Implementierung funktioniert gut mit 10 Benutzer. Mit steigender Arbeitslast dies möglicherweise CPU-Ebenen über gewünschten push und negativ auf die Antwortzeit bei der Auslastung hoch sind. True Belastungstests und zukünftige Vorhersage Auslastungstests werden dringend empfohlen.
Dateien und Arbeit Tabellenaktionen erstellenÄndert die Tempdb -Datenbank auf einem Gerät wie einem RAM-Datenträger verschieben den Abfrageplan durch Erhöhen der Anzahl oder Größe der Dateien oder Arbeitstabellen, bedeutet dies, dass der Speicher vom Pufferpool erhöhte Tempdb -Datenbankaktivität verursacht. Dieses Muster zeigt, dass die Lebenserwartung von Datenbankseiten auch negativ beeinträchtigt werden kann.

Transaktionale Sektor schreiben wird

Das folgende Beispiel erläutert die Sicherheit, die SQL Server-Datenbanken erforderlich ist.

Angenommen Sie, ein RAM Festplatte im Arbeitsspeicher Komprimierung Implementierung verwendet. Die Implementierung muss ordnungsgemäß mit dem Erscheinungsbild des Dateistreams Bereich ausgerichtet und angepasst, sodass SQL Server richtig gesicherte aus der zugrunde liegenden Implementierung wurde gekapselt werden. Die Komprimierung wird näher betrachten.
Aktion
1 bezieht sich auf das Gerät und komprimiert, um Speicherplatz zu sparen.
2 auf das Gerät geschrieben und mit 1 Speicherplatz komprimiert.
Das Gerät kann gehen um Sektors 1 Sichern zusammen mit Sektordaten 2.
Aktion
Alle Schreibvorgänge auf Bereiche 1 und 2 blockiert.
Dekomprimieren Sie Sektor 1 in einem Entwurfsbereich und aktuellen Bereich 1-Speicher als aktiven Daten abgerufen werden.
Komprimieren Sie Bereiche 1 und 2 in einem neuen Speicherformat.
Blockieren Sie alle Lese- und Schreibvorgänge Bereiche 1 und 2.
Alte Storage für die Bereiche 1 und 2 mit neuen austauschen.
Wenn die Exchange (Rollback) fehlschlägt:
  • Wiederherstellen des ursprünglichen Speichers für Bereiche 1 und 2.
  • Entfernen Sie die Bereiche 1 und 2 kombiniert Daten aus dem Entwurfsbereich.
  • Den Sektor 2-Schreibvorgang fehl.
Entsperren Sie Lese- und Schreibvorgänge für die Bereiche 1 und 2.
Die Fähigkeit Sperrmechanismen um Sektor geändert und die Änderungen rückgängig Wenn die Sektor Exchange fehlschlägt gilt übergangsweise kompatibel. Für Implementierungen, die Speicherplatz für erweiterte Unterstützung verwenden, wäre es auch die entsprechende Transaktion Protokoll Aspekte zum Sichern und Wiederherstellen ändert die Datenträgerstrukturen weiterhin die Integrität der SQL Server-Datenbankdateien angewendet wurden.

Jedes Gerät, das neu Sektoren kann muss die schreibt transaktionale so unterstützen SQL Server nicht zu Datenverlusten verfügbar gemacht wird.

Hinweis Die Instanz von SQL Server wird neu gestartet, bei online-e/a und Rollback-Fehler in der Datenbank Tempdb .

Achten Sie beim Verschieben der Tempdb -Datenbank

Seien Sie vorsichtig, wenn Sie die Tempdb -Datenbank verschieben, da die Tempdb -Datenbank kann erstellt werden, wird SQL Server nicht gestartet. Wenn die Tempdb -Datenbank erstellt werden kann, starten Sie SQL Server mithilfe der (-f) Startparameter und Verschieben der Tempdb -Datenbank auf einen gültigen Speicherort.

Gehen Sie folgendermaßen vor, um den physischen Speicherort der Tempdb -Datenbank zu ändern:
  1. Mithilfe der ALTER DATABASE-Anweisung und der MODIFY FILE-Klausel die physischen Dateinamen aller Dateien in der Tempdb -Datenbank auf den neuen physischen Speicherort, 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 und starten Sie SQL Server.

Partner produktzertifizierungen sind keine Garantie Kompatibilität und Sicherheit

Ein Produkt oder einen bestimmten Kreditor erhalten eine Microsoft Logo-Zertifizierung. Allerdings bestätigt Partner Zertifizierung oder einer bestimmten Microsoft-Logo nicht die Kompatibilität oder Eignung für einen bestimmten Zweck in SQL Server.

Unterstützung

Wenn Sie ein Subsystem mit SQL Server verwenden, die e/a-Garantien für die Verwendung einer Transaktionsdatenbank in diesem Artikel beschriebenen unterstützt, unterstützen Microsoft SQL Server und SQL Server-basierte. Jedoch Probleme mit oder verursacht durch das Subsystem wird dem Hersteller.

Für Tempdb -Datenbank Fragen fragt Microsoft Support Services Sie die Tempdb -Datenbank verschieben. Wenden Sie sich an der Gerätehersteller, um sicherzustellen, dass Sie ordnungsgemäß bereitgestellt und das Gerät für die Verwendung einer Transaktionsdatenbank konfiguriert haben.

Microsoft nicht bestätigt oder Überprüfen von Drittanbieterprodukten mit SQL Server funktionsfähig. Darüber hinaus bietet Microsoft kein Gewährleistung, Garantie oder Anweisung alle Drittanbieterprodukt Eignung für die Verwendung mit SQL Server.

Referenzen


Klicken Sie für weitere Informationen auf die folgenden Artikelnummern, um die betreffenden Artikel in der Microsoft Knowledge Base anzuzeigen:

826433 PRB: zusätzliche SQL Server-Diagnose hinzugefügt, um nicht berichtete e/a-Probleme aufzuspüren

828339 Fehlermeldung 823 kann Hardware- oder Systemprobleme in SQL Server hindeuten.

234656 Laufwerk Zwischenspeichern mit SQL Server verwenden

Beschreibung der Unterstützung von Datenbankdateien im Netzwerk in SQL Server 304261

913945 Microsoft bestätigt nicht, dass Drittanbieterprodukte mit Microsoft SQL Server

910716 an SQL Server 2005 und SQL Server 2000 unterstützt remote-Spiegelung von Datenbanken

917043 Schlüsselfaktoren beim Bewerten der Drittanbieter-Cache-Systeme mit SQL Server

SSDs verwendet in Azure VMs SQL Server TempDB und Puffer Pool Extensions speichern

Best Practices zur Performance für SQL Server in Azure Virtual Machines

Optimieren der Abfrage-Pläne mit SQL Server 2014 Kardinalität Gutachter

Abfrage-Leistung


In diesem Dokument enthaltenen Informationen stellt die aktuelle Ansicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung behandelten Themen. Da Microsoft zu reagieren muss, sollten kein Verpflichtung seitens Microsoft interpretiert werden und Microsoft kann die Richtigkeit der Informationen nach dem Datum der Veröffentlichung garantieren.

In diesem Whitepaper wird nur zu Informationszwecken. MICROSOFT ÜBERNIMMT KEINE GEWÄHRLEISTUNG, EXPRESS, KONKLUDENT ODER GESETZLICH GEREGELT, INFORMATIONEN IN DIESEM DOKUMENT.

Einhaltung aller geltenden Urheberrechtsgesetze obliegt dem Benutzer. Ohne die Urheberrechtsgesetze kein Teil dieses Dokuments möglicherweise werden reproduziert, gespeichert einem eingeführt oder übertragen in irgendeiner Form oder mit welchen Mitteln (elektronisch, mechanisch, Fotokopieren, aufzeichnen oder andernfalls) und ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation.

Microsoft möglicherweise Patente, Patentanmeldungen, Marken, Urheberrechte oder andere geistige Eigentumsrechte für den Gegenstand dieses Dokuments. Ausdrückliche alle schriftlichen Lizenzvertrag von Microsoft, die dieses Dokuments nicht Sie an diesen Patenten, Marken, Copyrights oder sonstiges geistiges Eigentum Lizenzverträgen ist.

© 2006 Microsoft Corporation. Alle Rechte vorbehalten.

Microsoft, Windows, Windows Server und SQL Server sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
SQL Server erfordert die Zustellung stabile Medien unterstützen gemäß SQL Server i/o-ZuverlässigkeitsanforderungenWeitere Informationen zu den Eingabe- und Ausgabeparameter für die SQL Server-Datenbank-Engine klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:

967576 Microsoft SQL Server-Datenbank-Engine Input/Output Vorschriften