Microsoft SQL Server-e/a-Subsystem Anforderungen für die Tempdb-Datenbank

Microsoft SQL Server erfordert, dass das e/A-Subsystem zum Speichern von System- und Benutzerdatenbanken vollständig Write-Ahead-Protokoll (WAL) Anforderungen über bestimmte e/A-Prinzipale berücksichtigt. Diese Anforderungen sind erforderlich, um die ACID-Eigenschaften der Transaktionen zu berücksichtigen: atomarische, konsistent, isoliert und dauerhaft. Details über e/a-Subsystem Kompatibilitätsanforderungen sind in den folgenden Referenzen bereitgestellt:

• SQL Server 2000-e/a-Grundlagen
  http://technet.microsoft.com/en-us/library/cc966500.aspx

  (http://technet.microsoft.com/en-us/library/cc966500.aspx)
  Hinweis: Dieser Artikel gilt auch für SQL Server 2005.
• SQL Server 7.0 und SQL Server 2000-Protokollierung und Data Storage Algorithmen erweitern die Zuverlässigkeit der Daten
  http://support.microsoft.com/default.aspx?scid=kb;en-us;230785

  (http://support.microsoft.com/default.aspx?scid=kb;en-us;230785)

Die folgende Liste ist eine kurze Zusammenfassung der Anforderungen:

• Schreibreihenfolge muss verwaltet werden.
• Abhängige schreiben Konsistenz muss verwaltet werden.
• Schreibt müssen immer in/auf stabilen Medium gesichert werden.
• Zerrissene e/A-Vorbeugung muss auftreten.

Dauerhaftigkeit Wartung bleibt für alle anderen Datenbanken von entscheidender Bedeutung, aber möglicherweise niedrige für die Tempdb -Datenbank. Der folgende Tabelle sind verschiedene die kritischen e/A-Anforderungen für SQL Server-Datenbanken zusammengefasst.* Transaktions-Sektor Neuprogrammierungen beinhalten vollständig protokollierte Vorgänge durch das Subsystem einen Sektor vollständig verschoben, ersetzt oder ein Rollback auf das ursprüngliche Bild zulassen. Diese Neuprogrammierungen sind normalerweise wegen der zusätzlichen Verwaltungsaufwand für solche Aktionen abgeraten. Ein Beispiel hierfür wäre ein Defragmentierungsprogramm, die die Dateidaten verschoben wird. Der ursprüngliche Sektor in der Datei kann nicht mit dem neuen Sektor Speicherort ersetzt werden, bis die neuen Partitionsbootsektor und die Daten vollständig geschützt sind. Die Neuzuordnung des Sektors muss in einer Transaktions-Weise erfolgen, so, dass alle Fehler, einschließlich eines Stromausfalls der Re-establishment der ursprünglichen Daten verursacht. Sicherstellen Sie, dass Sie Sperrmechanismen verfügbar, während diese Art von Prozess, ungültige Datenzugriff zu verhindern und dadurch andere Mieter von SQL Server-e/a-Befolgung.

Survival über Ausfall

Die Tempdb -Datenbank ist ein Kratzer Bereich für SQL Server und wird jede SQL Server beim Start wiederhergestellt. Die Initialisierung ersetzt müssen für Daten, einen Neustart zu überstehen.

Transaktionale Sektor schreiben Operationen

Um den Erfolg der Wiederherstellung Prozesse, wie Rollbacks und Absturz Wiederherstellung zu gewährleisten müssen die Protokolldatensätze korrekt auf stabilen Medium gespeichert werden, bevor die Datenseite gespeichert wird und kann nicht ohne beachtet Transaktions-Eigenschaften umgeschrieben werden. Dies erfordert das Subsystem und SQL Server, um bestimmte Attribute, z. B. Schreibreihenfolge Sektor ausgerichtet und schreibt, Größe und andere solche e/a-Sicherheit Attribute in den zuvor erwähnten Dokumenten beschriebenen zu verwalten. Für das Tempdb -Datenbank ist Absturz Wiederherstellung unnötige, da die Datenbank immer beim Starten von SQL Server initialisiert ist. Die Tempdb -Datenbank erfordert jedoch weiterhin Rollback Funktionen. Daher können einige Attribute des Protokolls WAL gelockert werden.

Der Speicherort für die Tempdb -Datenbank muss in strenge Übereinstimmung mit festgelegten Laufwerk Protokolle fungieren. Auf alle Arten muss das Gerät auf dem die Tempdb -Datenbank gespeichert ist angezeigt und dienen als ein physischer Datenträger lesen nach Schreibzugriff Funktionen bereitstellen. Transaktion Sektor schreiben Operationen möglicherweise eine zusätzliche Anforderung bestimmter Implementierungen. Beispielsweise unterstützt SQL Server-Datenbank keine Änderungen mithilfe der NTFS-Komprimierung, da NTFS-Komprimierung neu schreiben kann, dass Sektoren des Protokolls, die bereits geschrieben angesehen und wurde abgesichert. Führt einem Fehler bei dieser Art von zum erneuten Schreiben von kann der Datenbank unbrauchbar, Daten beschädigt werden, dass SQL Server bereits als sicher.

Hinweis: SQL Server 2005 erweitert Unterstützung oder Komprimierung nur für Datenbanken und Dateigruppen lesen. Finden Sie in der SQL Server 2005-Onlinedokumentation ausführliche.

Transaktionale Sektor schreiben Vorgänge sind für alle SQL Server-Datenbanken, die die Tempdb -Datenbank enthalten relevant sind. Eine wachsende verschiedene erweiterte Speichertechnologien verwenden, Geräte und Dienstprogramme, die Daten schreiben können, die SQL Server als sicherer angesehen. Beispielsweise Ausführen einiger der neuen Technologien im Arbeitsspeicher zwischenspeichern oder Datenkomprimierung. Um schwerwiegende Datenbankschaden zu vermeiden, muss jeder Sektor schreiben vollständige Transaktionsunterstützung in einer solchen Weise sein, wenn ein Fehler auftritt, die Daten auf der vorherigen Sektor Bilder zurückgesetzt werden. Dadurch wird sichergestellt, dass SQL Server nie zu einer unerwarteten Unterbrechung oder Daten Schaden Bedingung gefährdet ist.

Sie können möglicherweise legen Sie die Tempdb -Datenbank auf spezielle Subsysteme, z. B. RAM-Laufwerke, durchgezogene Status oder andere Hochgeschwindigkeits-Implementierungen, die nicht für andere Datenbanken verwendet werden können. Schlüsselfaktoren, die in Abschnitt ? Weitere Informationen eingeben vorgestellten müssen jedoch berücksichtigt werden, wenn Sie diese Optionen bewerten.

Mehrere Faktoren sollten sorgfältig ausgebildet wurde werden, wenn Sie den Speicherort für die Tempdb -Datenbank bewerten. Beispielsweise werden in die Tempdb -Datenbank-Verwendung umfasst jedoch ist nicht auf Speicherbedarf, Abfrageplan und e/a-Entscheidungen beschränkt. Die entsprechenden Tuning und die Implementierung der Tempdb -Datenbank können die Skalierbarkeit und Reaktionsfähigkeit des Systems steigern. In diesem Abschnitt werden die Schlüsselfaktoren bestimmen die Speicheranforderungen für die Tempdb -Datenbank erläutert.

Hochgeschwindigkeits-Subsysteme

Es sind verschiedene Hochgeschwindigkeits-Subsystem Implementierungen auf dem Markt, SQL Server-e/a-Subsystem Protokollanforderungen bereitstellen, bieten jedoch nicht Beständigkeit des Mediums, verfügbar.

wichtig Immer bestätigen Sie mit dem Produkt Kreditor um vollständige Kompatibilität mit SQL Server-e/a-Anforderungen zu gewährleisten.

Ein RAM-Datenträger ist ein typisches Beispiel einer solchen Implementierung. RAM-Datenträger installieren Sie die erforderlichen Treiber und aktivieren Sie Teil von den wichtigsten RAM-Datenträger als angezeigt werden und wie einem beliebigen Laufwerk, der an das System angeschlossen ist. Alle e/A-Subsysteme sollte vollständige Kompatibilität mit der SQL Server-e/a-Anforderungen bereitstellen. Es ist jedoch offensichtlich, dass ein RAM-Datenträger nicht dauerhaften Medium ist. Daher wird eine Implementierung, z. B. einem RAM-Datenträger kann nur als Speicherort der Tempdb -Datenbank verwendet werden, und es kann nicht für jede andere Datenbank verwendet werden.

Tasten, um vor der Implementierung und Bereitstellung sollten Sie

Es gibt verschiedene Aspekte, die vor dem Bereitstellung der Tempdb -Datenbank auf diese Art von Subsystem zu berücksichtigen sind. In diesem Abschnitt verwendet einen RAM-Datenträger als Grundlage für Diskussionen, aber in anderen Implementierungen von hoher Geschwindigkeit ähnliche Ergebnisse auftreten.

E/a-Sicherheit

Kompatibilität des Lesevorgangs nach dem Schreiben und transaktionale Sektor Schreibvorgänge ist erforderlich. Bereitstellen von SQL Server nie auf jedem System, die die SQL Server-e/a-Anforderungen nicht vollständig unterstützt, oder Sie Risiko Schäden und zum Verlust Ihrer Daten.

Seiten bereits zwischengespeichert (Double RAM-Cache)

Temporäre Tabellen sind wie alle anderen Tabellen in einer Datenbank. Sie sind vom Pufferpool zwischengespeicherten und vom lazy Write-Vorgänge behandelt. Temporäre Tabelle Seiten auf einem RAM-Datenträger speichern bewirkt, dass doppelte Arbeitsspeicher zwischenspeichern, in den Pufferpool und eine für den RAM-Datenträger. Dieser Vorgang dauert direkt von ?s Pufferpool mit möglichen Gesamtgröße und i. d. r. verringert die Leistung von SQL Server.

Aufgegeben RAM

RAM-Datenträger bezeichnet einen Teil Haupt-RAM, wie der Name impliziert. Es sind verschiedene Implementierungen von RAM-Laufwerke und RAM-basierte Dateien Caches verfügbar. Einige ermöglichen auch die physische e / Operationen sichern. Das Key-Element der RAM-basierte Datei-Cache ist, direkt von den physikalischen Speicher benötigt, die von SQL Server verwendet werden können. Immer haben Sie nachgewiesen, dass hinzufügen ein RAM-basierte Datei-Cache verbessert die Leistung der Anwendung und anderen Abfrage oder Anwendungsleistung nicht verringert.

Zuerst optimieren

Eine Anwendung sollte optimieren, um unnötige und unerwünschte sortiert und Hashes, die die Verwendung der Tempdb -Datenbank führen könnten zu entfernen. Oft die Hinzufügung von einem Index kann die Notwendigkeit der Sortier- oder Hash im Plan vollständig entfernen führt, dass eine optimale Leistung ohne die Verwendung von der Datenbank Tempdb .

Mögliche Vorteile Punkt

Die Vorteile der Platzieren der Tempdb -Datenbank auf einem System hohe Geschwindigkeit können nur über strenge Tests und Messungen der Anwendung Arbeitsauslastungen ermittelt werden. Die Arbeitsauslastung hat zu ausgebildet sorgfältig wurde werden für die Eigenschaften, die die Tempdb -Datenbank profitieren kann, und die e/A-Sicherheit muss vor dem Bereitstellung bestätigt.

Die Vorgänge sortieren und Hash arbeiten zusammen mit SQL Server Speicher-Manager um die Größe des Entwurfsbereichs im Arbeitsspeicher für jede Sortier- oder Hash-Operation zu ermitteln. Sobald die Daten sortieren oder Hash zugewiesenen Entwurfsbereich im Speicher überschreitet, können Daten in die Tempdb -Datenbank geschrieben werden. Dieser Algorithmus wurde in SQL Server 2005, reduzieren die Tempdb -Datenbank Verwendungsanforderungen gegenüber früheren Versionen von SQL Server erweitert. Beispielsweise zeigt keine Indizes, absteigende Reihenfolge und dieselbe Hardwarekonfiguration, SQL Server 2005 mithilfe einer reinen erzwungene Sortierung einer Tabelle deutliche Verbesserungen über SQL Server 2000.

Vorsicht SQL Server dient zum Konto für Speicher Ebenen und aktuelle Abfrage Aktivitäten beim Abfrage-Plan Entscheidungen, die die Verwendung von Tempdb Datenbankoperationen betreffen. Daher hängen die Leistungsverbesserungen erheblich Arbeitsauslastungen und Anwendungsentwurf. Es wird empfohlen, dass Sie Tests mit die bevorzugte Lösung ermitteln mögliche Gewinne und Auswerten von Schutzanforderungen vor solchen Bereitstellung e/A ausführen.

SQL Server verwendet die Tempdb -Datenbank zur Behandlung verschiedener Aktivitäten im Zusammenhang mit Sortierungen, Hashes, der Versionsspeicher Zeile und temporäre Tabellen:

• Temporäre Tabellen werden durch die allgemeine Puffer-Pool-Routinen für Datenseiten verwaltet, und weisen im Allgemeinen nicht von Specialty Subsystem-Implementierungen Leistungsvorteile.
• Die Tempdb -Datenbank wird als einen Entwurfsbereich für Hashes und Sortierungen verwendet. Reduzieren der e/A-Latenz für solche Operationen kann nützlich sein. Allerdings wissen, einen Index um einen Hash zu vermeiden, hinzufügen oder eine Sortierung möglicherweise eine ähnliche Leistung bereit.

Führen Sie Baselines mit und ohne die Tempdb -Datenbank auf dem Hochgeschwindigkeits-Subsystem Vorteile vergleichen gespeichert. Teil der Tests sollte Abfragen in der Benutzerdatenbank enthalten, die nicht sortiert, Hashes temporäre Tabellen oder, und bestätigen, dass diese Abfragen nicht beeinträchtigt werden. Wenn Sie das System bewerten, können die folgenden Leistungsindikatoren hilfreich sein.

Transaktionale Sektor schreiben Beispiel

Im folgende Beispiel elaborates der Datensicherheit, die SQL Server-Datenbanken erforderlich ist.

Genommen Sie an, ein RAM-Festplattenherstellers eine speicherinterne Komprimierung Implementierung verwendet. Die Implementierung muss ordnungsgemäß gekapselt werden, durch die physische Darstellung des Datei-Stream bereitstellen, als ob der Sektor wurde ausgerichtet und angepasst, sodass SQL Server erkennt und aus der zugrunde liegenden Implementierung korrekt gesichert ist. Das Beispiel Komprimierung näher betrachten.Das Gerät möglicherweise führen Sie die folgenden Aktionen Sektor ?s 1-Daten zu schützen, wird mit Daten ?s 2 Sektor kombiniert.Die Möglichkeit bieten Sperrmechanismen um Sektor Änderungen und Rollback der Änderungen, wenn der Sektor Exchange fehlschlägt, wird übergangsweise kompatibel betrachtet. Für Implementierungen, die physischen Speicher für erweiterte sichern zu verwenden, würden Sie die entsprechenden Transaktion Protokoll Aspekten, die helfen, sichere und Rollback von Änderungen, die auf den Datenträgerstrukturen um die Integrität der SQL Server-Datenbankdateien erhalten angewendet wurden enthalten.

Jedes Gerät, das zum Umschreiben von Sektoren ermöglicht muss die Neuprogrammierungen Transaktions-Weise unterstützen, sodass SQL Server nicht zu Datenverlusten verfügbar gemacht wird.

Hinweis: Die Instanz von SQL Server wird neu gestartet in die Tempdb -Datenbank online e/a- und Rollback-Fehler auftreten.

Achten Sie beim Verschieben der Tempdb -Datenbank

Vorsichtig vor, wenn Sie die Tempdb -Datenbank verschieben, da die Tempdb -Datenbank kann nicht erstellt werden, SQL Server nicht gestartet werden. 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. Verwenden Sie ALTER DATABASE-Anweisung und der MODIFY FILE-Klausel, um die physischen Dateinamen aller Dateien in die Tempdb -Datenbank zum Verweisen auf den neuen physischen Speicherort, z. B. die neue Festplatte. ändern

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

Partner Produkt Zertifizierungen sind keine Guaranty der Kompatibilität oder Sicherheit

Ein Drittanbieter-Produkt oder einen bestimmten Kreditor erhalten eine Microsoft-Logo-Zertifizierung. Allerdings ist Partner-Zertifizierung oder eine bestimmte Microsoft-Logo nicht Kompatibilitäts- oder Eignung für einen bestimmten Zweck in SQL Server zertifizieren.

Unterstützung

Wenn Sie ein Teilsystem mit SQL Server, die e/A-Garantien für die Transaktionsdatenbank Verwendung verwenden wie in diesem Artikel beschrieben unterstützt, stellt Microsoft Unterstützung für SQL Server und SQL Server-basierten Anwendungen bereit. Jedoch mit Probleme oder zurückzuführen, das Subsystem wird sich beziehen an den Hersteller.

Für Tempdb -Datenbank-bezogene Probleme werden Microsoft Support Services so verschieben Sie die Tempdb -Datenbank aufgefordert. Wenden Sie sich an Ihr Gerät Hersteller um sicherzustellen, dass Sie ordnungsgemäß bereitgestellt und das Gerät für die Transaktionsdatenbank Verwendung konfiguriert haben.

Microsoft zertifizieren weder überprüfen, dass Produkte von Drittanbietern mit SQL Server ordnungsgemäß funktionieren. Darüber hinaus bietet Microsoft Garantie, Guaranty oder ?s Produkte von Drittanbietern Eignung für die Verwendung mit SQL Server-Anweisung keinen.

Weitere Informationen finden Sie in den folgenden Artikeln der Microsoft Knowledge Base: Die in diesem Dokument enthaltenen Informationen dar Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung behandelten Themen. Da Microsoft auf Marktanforderungen reagieren muss, sollte eine Verpflichtung seitens des Microsoft werden nicht interpretiert werden und Microsoft kann die Richtigkeit dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren.

Dieses Whitepaper dient nur zu Informationszwecken. MICROSOFT ÜBERNIMMT KEINE GEWÄHRLEISTUNGEN, AUSDRÜCKLICHE, KONKLUDENTE ODER KONKLUDENT, FÜR DIE INFORMATIONEN IN DIESEM DOKUMENT.

Die Benutzer sind verantwortlich für das Einhalten aller anwendbaren Urheberrechtsgesetze. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation kein Teil dieses Dokuments für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht.

Es ist möglich, dass Microsoft Rechte an Patenten bzw. angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Das Bereitstellen dieses Dokuments gibt Ihnen jedoch keinen Anspruch auf diese Patente, Marken, Urheberrechte oder auf sonstiges geistiges Eigentum, es sei denn, dies wird ausdrücklich in den schriftlichen Lizenzverträgen von Microsoft eingeräumt.

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