Sie sind zurzeit offline. Es wird auf die erneute Herstellung einer Internetverbindung gewartet.

Microsoft SQL Server i/o-Anforderungen an das Datenträgersubsystem für die Tempdb-Datenbank

Wichtig: Dieser Artikel wurde maschinell übersetzt und wird dann möglicherweise mithilfe des Community Translation Framework (CTF) von Mitgliedern unserer Microsoft Community nachbearbeitet. Weitere Informationen zu CTF finden Sie unter http://support.microsoft.com/gp/machine-translation-corrections/de.

Den englischen Originalartikel können Sie über folgenden Link abrufen: 917047
Zusammenfassung
Microsoft SQL Server erfordert, dass das e/a-Subsystem zum Speichern von System- und Benutzerdatenbanken vollständig durch bestimmte e/a-Prinzipale Write-Ahead-Logging (WAL) Anforderungen berücksichtigt. Diese Anforderungen sind erforderlich, um die ACID-Eigenschaften von Transaktionen berücksichtigt: atomar, konsistent, isoliert und dauerhaft. Informationen zu e/a-Subsystem Compliance-Anforderungen werden in den folgenden Referenzen bereitgestellt:Die folgende Liste ist eine kurze Zusammenfassung der Anforderungen:
  • Schreibreihenfolge muss eingehalten werden.
  • Abhängiger Write-Konsistenz muss eingehalten werden.
  • Schreibvorgänge müssen in/auf stabilen Medien immer gesichert werden.
  • Zerrissene e/a-Prävention auftreten muss.
Haltbarkeit-Wartung für alle anderen Datenbanken bleibt jedoch möglicherweise ungenau für die Tempdb -Datenbank. Der folgenden Tabelle werden einige der wichtigen e/a-Anforderungen für SQL Server-Datenbanken.
E/a-AnforderungKurze BeschreibungSystem- odertempdb
Schreiben Sie die Bestellung

Abhängiger Write-Konsistenz
Die Möglichkeit des Teilsystems, die richtige Reihenfolge der Schreibvorgänge zu verwalten. Dies ist besonders wichtig für die Spiegelung Lösungen, Anforderungen an die Konsistenz und WAL der SQL Server-Protokoll verwenden.ErforderlichEmpfohlen
Nach dem Schreiben LesenDie Möglichkeit des Teilsystems Service Leseanforderungen mit dem neuesten Image, wenn der Lesevorgang ausgegeben wird, nach jedem Schreibvorgang erfolgreich abgeschlossen wurde.ErforderlichErforderlich
Überleben über AusfälleDie Möglichkeit, dass Daten bleiben vollständig neu intakt (dauerhaft) über einem Ausfall, z. B. ein System starten.ErforderlichNicht zutreffend
Zerrissene e/a-PräventionDie Fähigkeit des Systems, teilen die einzelne e/a-Anforderungen zu vermeiden.ErforderlichEmpfohlen
Sektor schreibenBereich kann nur in seiner Gesamtheit geschrieben werden und nicht durch eine Schreibanforderung in einem nahe gelegenen Sektor neu schreiben.* Nicht empfohlen, nur bei transactional zulässig* Nicht empfohlen, nur bei transactional zulässig
Gesicherte DatenDer Annahme, dass wenn eine Schreibanforderung oder FlushFileBuffers Vorgang erfolgreich abgeschlossen wurde, wurden die Daten auf stabilen Medien gespeichert.ErforderlichNicht zutreffend
Physische Sektorenausrichtung und GrößeSQL Server untersucht die Daten- und Protokolldateien Datei-Speicherorte. Alle Geräte sind erforderlich zur Unterstützung der Bereich Attribute ermöglichen SQL Server-Schreibvorgänge auf physischen Sektor ausgerichteten Grenzen und ein Vielfaches der Sektorgröße durchführen.ErforderlichErforderlich
* Die Transaktions-Sektor schreibt umfassen vollständig protokollierte Vorgänge durch das Subsystem einen Sektor vollständig verschoben, ersetzt oder Rollback zum ursprünglichen Bild zulassen. Diese schreibt sollten keinesfalls in der Regel durch den zusätzlichen Aufwand, um diese Aktionen auszuführen. Ein Beispiel hierfür wäre ein Defragmentierungsprogramm, die die Dateidaten verschoben werden. Der ursprüngliche Sektor in der Datei kann nicht mit dem neuen Speicherort der Sektor ersetzt werden, bis die neuen Sektor und Daten vollständig geschützt sind. Neuzuordnung des Sektors muss in Form einer Transaktion auftreten, so dass Ausfälle, einschließlich eines Stromausfalls bewirkt, die Wiederherstellung der ursprünglichen Daten dass. Stellen Sie sicher, dass Sperrmechanismen, während diese Art von Prozess zur Verhinderung von ungültigen Daten-Zugriff zur Verfügung stehen Ihnen damit nach anderen Mieter der SQL Server-i/o.

Überleben über Ausfälle

Die Tempdb -Datenbank ist der Entwurfsbereich, damit SQL Server und wird bei jedem Start von SQL Server neu erstellt. Die Initialisierung ersetzt die Notwendigkeit von Daten an einen Neustart übersteht.

Transaktionale Rewrite-Sektor

Um die Garantie für den Erfolg von Recovery-Prozessen, z. B. Rollback und Crash Recovery müssen Protokolldatensätze ordnungsgemäß auf stabilen Medien gespeichert werden, bevor die Datenseite gespeichert werden und kann nicht neu geschrieben werden, ohne Berücksichtigung von Transaktionseigenschaften. Dies erfordert das Subsystem und SQL Server bestimmte Attribute, z. B. Schreibreihenfolge ausgerichtet und schreibt, Größe und andere solche e/a-Sicherheit Attribute in den zuvor erwähnten Dokumenten beschrieben. Für die Tempdb -Datenbank ist die Wiederherstellung nach einem Absturz nicht erforderlich, da die Datenbank immer während des Starts von SQL Server initialisiert wird. Die Tempdb -Datenbank erfordert jedoch nach wie vor Rollback-Funktionen. Aus diesem Grund können einige Attribute des Protokolls WAL gelockert werden.

Der Speicherort für die Datenbank Tempdb muss in strikter Übereinstimmung mit den festgelegten Laufwerk Protokolle fungieren. In jeder Hinsicht muss das Gerät, auf dem die Tempdb -Datenbank gespeichert ist, angezeigt werden und fungieren als ein physischer Datenträger lesen nach Write-Zugriff bereitstellen. Transaktion zum erneuten Schreiben von Sektor möglicherweise eine zusätzliche Anforderung spezifische Implementierungen. Angenommen, wird SQL Server-Datenbank nicht unterstützt, die mit NTFS-Komprimierung, da NTFS-Komprimierung neu schreiben kann Bereiche des Protokolls, die bereits geschrieben und als Änderungen abgesichert. Ein Fehler bei dieser Art der Neuprogrammierung kann der Datenbank verwendet, die Daten beschädigt werden, dass SQL Server bereits als sicher führen.

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

Transaktions-Sektor zum erneuten Schreiben von Operationen gelten für alle SQL Server-Datenbanken, die die Tempdb -Datenbank enthalten. Wachsende verschiedene erweiterte Speichertechnologien verwenden, Geräte und Programme, die Daten schreiben können, die SQL Server als sicher betrachtet. Einige neue Technologien führen z. B. im Arbeitsspeicher zwischenspeichern oder Datenkomprimierung. Zur Vermeidung von schweren Datenbankschaden jeder Sektor schreiben müssen vollständige Transaktionsunterstützung so, dass, wenn ein Fehler auftritt, die Daten zu den vorherigen Sektor Bildern zurückgesetzt werden. Dadurch wird sichergestellt, dass SQL Server nicht zu einer unerwarteten Unterbrechung oder Daten Schaden Zustand verfügbar gemacht wird.

Möglicherweise können Sie die Tempdb -Datenbank auf Specialty-Subsysteme, z. B. RAM-Laufwerke, solid-State oder andere high-Speed-Implementierungen, die für andere Datenbanken verwendet werden können. Wichtigen Faktoren im Abschnitt "Weitere Informationen" müssen jedoch berücksichtigt werden, beim Auswerten dieser Options.
Weitere Informationen
Mehrere Faktoren sollten sorgfältig geprüft werden, wenn Sie den Speicherort für die Datenbank Tempdb auswerten. Z. B. die Nutzung der Tempdb -Datenbank umfasst, jedoch nicht beschränkt auf Speicherbedarf, Abfrageplan und e/a-Entscheidungen. Die entsprechenden Tuning und Implementierung der Tempdb -Datenbank können die Skalierbarkeit und Reaktionsfähigkeit eines Systems verbessern. Dieser Abschnitt beschreibt die wichtigsten Faktoren bei der Bestimmung der Speicheranforderungen für die Tempdb -Datenbank.

High-Speed-Subsysteme

Auf dem Markt, die SQL Server-e/a-Subsystem Protokollanforderungen bereitstellen, die bieten jedoch nicht Haltbarkeit des Mediums, stehen verschiedene Implementierungen von high-Speed-Subsystem zur Verfügung.

Wichtig Bestätigen Sie immer mit den Hersteller des Produkts zum vollständigen SQL Server-e/a-Anforderungen zu gewährleisten.

Ein RAM-Datenträger ist ein gängiges Beispiel für eine solche Implementierung. RAM-Laufwerke installiert die erforderlichen Treiber und Aktivieren der Teil der Haupt-RAM-Datenträgers als angezeigt werden und funktionieren wie eine Festplatte, die an das System angeschlossen ist. Alle i/o-Subsysteme sollte die Übereinstimmung mit den SQL Server-i/o-Anforderungen bereitstellen. Es ist jedoch offensichtlich, dass ein RAM-Datenträger nicht dauerhaften Medium ist. Aus diesem Grund eine Implementierung, wie z. B. einem RAM-Datenträger darf nur als Speicherort für die Datenbank Tempdb verwendet werden und nicht für eine andere Datenbank verwendet werden.

Tasten berücksichtigen, damit die Implementierung und Bereitstellung

Es gibt verschiedene Punkte berücksichtigen, damit die Bereitstellung der Datenbank Tempdb bei dieser Art von Subsystem. In diesem Abschnitt verwendet einen RAM-Datenträger als Grundlage für Diskussionen, aber wie möglich, in anderen high-Speed-Implementierungen.

E/a-Sicherheit

Lesen, schreiben und Transaktions-Sektor Schreibvorgänge sind ein muss. Nie Bereitstellen von SQL Server auf jedem System, das die SQL Server-i/o-Anforderungen nicht vollständig unterstützt, oder laufen Sie Gefahr, Beschädigung und Verlust Ihrer Daten.

Seiten bereits zwischengespeichert (Double RAM-Cache)

Temporäre Tabellen sind wie alle anderen Tabellen in einer Datenbank. Sie sind vom Pufferpool zwischengespeichert und durch verzögerte Schreibvorgänge behandelt. Speichern von Seiten der temporären Tabelle auf einem RAM-Datenträger verursacht doppelte RAM-Zwischenspeicherung in den Pufferpool und die RAM-Disk. Dies nimmt direkt möglich Gesamtgröße des Pufferpools befinden und in der Regel wird die Leistung von SQL Server.

RAM aufgegeben

Die RAM-Disk bezeichnet einen Teil des RAM-Speicher, wie der Name impliziert. Es stehen verschiedene Implementierungen von RAM-Disks und RAM-basierten Dateien Caches. Einige ermöglichen außerdem die physische e/a Backup-Vorgänge. Das zentrale Element der RAM-basierte Datei-Cache ist, dass es direkt von der physische Speicher wird, die von SQL Server verwendet werden kann. Immer haben Sie erhebliche Anhaltspunkte, dass das Hinzufügen ein RAM-basierte Datei-Cache verbessert die Anwendungs-Performance und verringert nicht die andere Abfrage oder Anwendungsleistung.

Zuerst optimieren

Entfernen Sie unnötige und unerwünschte sortiert und Hashes, die die Verwendung der Tempdb -Datenbank führen könnten, sollte eine Anwendung optimieren. Oft das Hinzufügen eines Indexes kann die Notwendigkeit der Sortier- oder Hashoperationen im Plan vollständig entfernen führender für eine optimale Performance ohne die Verwendung der Tempdb -Datenbank.

Punkte nutzen

Platzieren die Tempdb -Datenbank auf einem Highspeed-System die Vorteile können nur durch strenge Tests und Messungen von Anwendungs-Workloads bestimmt werden. Die Arbeitsauslastung muss sorgfältig untersucht werden für die Eigenschaften, die die Tempdb -Datenbank profitieren kann, und die e/a-Sicherheit muss bestätigt werden, vor der Bereitstellung.

Die Vorgänge sortieren und Hash gemeinsam mit der SQL Server-Speicher-Manager bestimmen Sie die Größe des Entwurfsbereichs in Arbeitsspeichers für jede Sortier- oder Hash-Operation. Sobald die Sortier- oder Hashoperationen Daten zugewiesenen Entwurfsbereich in Arbeitsspeichers übersteigt, können Daten in die Tempdb -Datenbank geschrieben werden. Dieser Algorithmus wurde in SQL Server 2005, Reduzierung der Anforderungen für die Tempdb -Datenbank Verwendung gegenüber früheren Versionen von SQL Server erweitert. Zeigt z. B. mithilfe einer reinen erzwungene Sortieren einer Tabelle keine Indizes, absteigende Reihenfolge und dieselbe Hardwarekonfiguration, SQL Server 2005 spürbare Verbesserungen gegenüber SQL Server 2000.

Achtung: SQL Server-Konto für Speicher Sie Ebenen und Aktivitäten der aktuellen Abfrage Abfrage-Plan Entscheidungen, bei denen die Verwendung der Datenbank Tempdb dient. Daher hängen die Leistungsverbesserungen erheblich Arbeitslasten und Anwendungsdesign. Es wird dringend empfohlen, dass Sie führen Tests mit die bevorzugte Lösung bestimmt mögliche Gewinne und e/a-Sicherheitsanforderungen vor dieser Bereitstellung auswerten.

SQL Server verwendet die Tempdb -Datenbank verwenden verschiedene Aktivitäten im Zusammenhang mit Sortierungen, Hashes, die Speicherung der Zeilenversion und temporäre Tabellen:
  • Temporäre Tabellen werden durch die gemeinsamen Puffer-Pool-Routinen für Datenseiten verwaltet und Leistungsvorteile von Specialty-Subsystem-Implementierungen im Allgemeinen nicht auf.
  • Die Tempdb -Datenbank dient als Entwurfsbereich für Hashes und sortiert. Reduziert die i/o-Latenz für solche Operationen kann von Vorteil sein. Allerdings wissen, das Hinzufügen eines Indexes um einen Hash zu vermeiden oder eine Art kann eine ähnliche Leistung.
Führen Sie Baselines mit und ohne die Tempdb -Datenbank auf der high-Speed-Subsystem, um Vorteile vergleichen gespeichert. Die Tests sollten Abfragen in der Datenbank gehört, die nicht sortiert, Hashes oder temporären Tabellen beinhalten, und vergewissern Sie sich, dass diese Abfragen nicht beeinträchtigt werden. Beim Auswerten des Systems können die folgenden Leistungsindikatoren hilfreich sein.
IndikatorBeschreibung/Verwendung
Seite Lese- und SchreibvorgängeVerbessern der Leistung von Tempdb kann Datenbank-i/OS die Rate der Seite Lese- und Schreibvorgänge für die Benutzerdatenbanken aufgrund der reduzierten Wartezeit im Zusammenhang mit der Tempdb -Datenbank-i/o-ändern. Für Benutzer von Datenbankseiten sollte die Gesamtzahl nicht derselben Arbeitsauslastung unterschiedlich.
Physische lesen und Schreiben von Bytes in der Tempdb-DatenbankVerschieben der Tempdb -Datenbank auf einem Gerät, z. B. einem RAM-Datenträger verlängert sich durch die tatsächliche e/a für die Tempdb -Datenbank, bedeutet dies, dass der Speicher vom Pufferpool erhöhte Tempdb -Datenbankaktivität verursacht. Dieses Muster ist ein Indikator, dass die Lebenserwartung der Datenbank auch Mai Seiten negativ beeinflusst werden.
LebenserwartungEin Rückgang der Lebenserwartung kann eine Zunahme der physischen e/a-Anforderungen für eine Benutzerdatenbank angeben. Die Verringerung der Anzahl deutet wahrscheinlich, dass der Speicher vom Pufferpool erzwingt Datenbankseiten Pufferpool vorzeitig beendet. Verbinden mit anderen Indikatoren und testen, um die Grenzen der Parameter vollständig zu verstehen.
Gesamtdurchsatz
CPU-Auslastung
Skalierbarkeit
Reaktionszeit
Das primäre Ziel eine Änderung der Tempdb -Datenbank ist den Gesamtdurchsatz erhöhen. Die Tests sollen unterschiedliche wiederholbare Arbeitslasten, die skaliert werden kann, um zu ermitteln, wie Durchsatz betroffen ist.

So etwas wie eine Komprimierung-basierte RAM-Disk-Implementierung funktioniert gut mit 10 Benutzer. Allerdings kann dies mit steigender Arbeitslast push CPU-Level über die gewünschten Ebenen und haben negative Auswirkungen auf die Antwortzeit, wenn die Arbeitsauslastung hoch ist. True Belastungstests und zukünftige Vorhersage Auslastungstests werden dringend empfohlen.
Arbeitsdateien und Arbeit Tabellenaktionen erstellenWenn den Abfrageplan durch Erhöhen der Anzahl oder Größe der Arbeitsdateien oder Arbeitstabellen Verschieben der Tempdb -Datenbank auf einem Gerät, z. B. einem RAM-Datenträger geändert wird, bedeutet dies, dass der Speicher vom Pufferpool erhöhte Tempdb -Datenbankaktivität verursacht. Dieses Muster ist ein Hinweis darauf, dass die Lebenserwartung von Datenbankseiten auch negativ beeinflusst werden kann.

Transaktions-Sektor Rewrite-Beispiel

Im folgende Beispiel führt die Datensicherheit, die SQL Server-Datenbanken erforderlich ist.

Angenommen Sie, ein RAM-Datenträger Kreditor eine Implementierung in Arbeitsspeichers Komprimierung verwendet. Die Implementierung muss ordnungsgemäß durch das Erscheinungsbild des Dateistreams bereitstellen, als ob der Sektor ausgerichtet und angepasst werden, damit SQL Server nicht erkennen und aus der zugrunde liegenden Implementierung korrekt gesichert wird gekapselt werden. Die Komprimierung wird näher betrachten.
Aktion
Sektor 1 bezieht sich auf das Gerät und wird komprimiert, um Speicherplatz zu sparen.
Sektor 2 bezieht sich auf das Gerät und ist mit 1, um Platz zu sparen komprimiert.
Das Gerät kann folgendermaßen um Sektordaten 1 zusammen mit 2er-Sektordaten zu sichern.
Aktion
Alle Schreibvorgänge auf Bereiche 1 und 2 blockiert.
Dekomprimieren Sie Sektor 1 in einem Entwurfsbereich ausgelagerten aktuelle Sektor 1 als aktiven Daten abgerufen werden.
Komprimieren Sie Bereiche 1 und 2 in ein neues Speicherformat.
Blockieren Sie alle Lese- und Schreibvorgänge der Bereiche 1 und 2.
Alte Storage für die Bereiche 1 und 2 mit einer neuen austauschen.
Schlägt der Versuch von Exchange (Rollback):
  • Wiederherstellen des ursprünglichen Speichers für die 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 Möglichkeit, Sperrmechanismen bereit, um die Änderungen der Sektor bieten und einen Rollback der Änderungen bei Fehlschlagen der Sektor der Exchange gilt übergangsweise kompatibel. Für Implementierungen, die physischen Speicher für erweiterte Unterstützung verwenden, zählen sie die entsprechende Transaktion Protokoll Aspekte um zu sichern, und Rollback für Änderungen, die auf die Strukturen auf dem Datenträger, um die Datenintegrität der SQL Server-Datenbankdateien angewendet wurden.

Jedes Gerät, das das Umschreiben der Sektoren ermöglicht muss die schreibt Transaktions-unterstützen, so dass SQL Server nicht zu Datenverlusten verfügbar gemacht wird.

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

Achten Sie beim Verschieben der Tempdb -Datenbank

Achten Sie beim Verschieben der Tempdb -Datenbank, weil die Tempdb -Datenbank erstellt werden kann, von SQL Server nicht gestartet werden kann. 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 verweisen.
    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 dann SQL Server.

Partner-Produktzertifizierungen sind keine Garantie für Sicherheit oder die Kompatibilität

Ein Produkt oder einen bestimmten Kreditor kann eine Microsoft-Zertifizierung erhalten. 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, die die e/a-Garantien für die Verwendung einer Transaktionsdatenbank in diesem Artikel beschriebenen unterstützt verwenden, wird Microsoft SQL Server und SQL Server-basierten Anwendungen unterstützen. Jedoch Probleme mit, oder zurückzuführen, das Subsystem wird verwiesen, der dem Hersteller.

Für die Tempdb -Datenbank-Problemen fordert Microsoft Support Services Sie die Tempdb -Datenbank verschieben. Wenden Sie sich an den Anbieter Ihres Geräts, um sicherzustellen, dass Sie ordnungsgemäß bereitgestellt und das Gerät für die Verwendung einer Transaktionsdatenbank konfiguriert.

Microsoft nicht bestätigt oder überprüfen, dass Produkte von Drittanbietern mit SQL Server ordnungsgemäß funktionieren. Darüber hinaus bietet Microsoft kein Gewährleistung, Garantie oder Anweisung alle Drittanbieterprodukt Eignung für die Verwendung mit SQL Server.
Informationsquellen
Klicken Sie für weitere Informationen auf die folgenden Artikelnummer, um die betreffende 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 auf Hardware- oder Systemprobleme in SQL Server hindeuten.
234656 Ein Zwischenspeichern mit SQL Server
304261 Beschreibung der Unterstützung für Netzwerkdatenbank legt in SQL Server
913945 Microsoft kann nicht garantieren, dass Produkte von Drittanbietern mit Microsoft SQL Server
910716 Anforderungen für SQL Server 2005 und SQL Server 2000 für die Unterstützung der remote-Spiegelung von Benutzerdatenbanken
917043 Wichtige Faktoren zu berücksichtigen bei der Auswertung von Drittanbieter-Cache-Systeme mit SQL Server
Verwendung von SSDs in Azure VMs zum Speichern von SQL Server TempDB und Puffer-Pool-Erweiterungen

Best Practices zur Performance für SQL Server in Azure virtuellen Maschinen

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

Abfrageleistung


In diesem Dokument enthaltene Informationen repräsentieren den Kenntnisstand der Microsoft Corporation in der beschriebenen Themen zum Zeitpunkt der Veröffentlichung. Da Microsoft auf sich ändernde Marktbedingungen reagieren muss, wird es nicht als Verpflichtung seitens Microsoft dar, und Microsoft garantiert nicht die Richtigkeit der dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung.

In diesem Whitepaper wird nur zu Informationszwecken. MICROSOFT ÜBERNIMMT KEINE GEWÄHRLEISTUNGEN, AUSDRÜCKLICH, KONKLUDENT ODER GESETZLICH GEREGELT, FÜR DIE INFORMATIONEN IN DIESEM DOKUMENT.

Einhaltung aller geltenden Urheberrechtsgesetze obliegt dem Benutzer. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze, kann kein Teil dieses Dokuments reproduziert, gespeichert oder in einem Retrievalsystem eingeführt, oder übertragen werden, in irgendeiner Form oder mit welchen Mitteln (elektronische, mechanische, Fotokopieren, aufzeichnen oder anderweitig) oder anderen Zwecken ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation.

Microsoft kann über Patente, Patentanmeldungen, Marken, Urheberrechte oder andere Rechte an geistigem Eigentum, die sich auf Themen in diesem Dokument beziehen. Es sei ausdrücklich in den schriftlichen Lizenzverträgen von Microsoft, die Bereitstellung dieses Dokuments nicht Sie keinen Anspruch auf diese Patente, Marken, Urheberrechten oder anderem geistigen Eigentum.

© 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-Systemen zur Unterstützung der 'Garantierte Übermittlung an stabilen Media' als gegliederten underthe SQL Server i/o Zuverlässigkeit Programmanforderungen.Weitere Informationen zu den Eingabe- und Anforderungen für die SQL Server-Datenbank-Engine klicken Sie auf die folgende Artikelnummer, um den Artikel der Microsoft Knowledge Base anzuzeigen:
967576 Microsoft SQL Server-Datenbank-Engine Input/Output Anforderungen


Warnung: Dieser Artikel wurde automatisch übersetzt.

Eigenschaften

Artikelnummer: 917047 – Letzte Überarbeitung: 05/12/2015 21:01:00 – Revision: 2.0

Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2000 Personal Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2000 Workgroup Edition, Microsoft SQL Server 2000 Developer Edition, Microsoft SQL Server 2000 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2014 Business Intelligence, Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Enterprise Core, Microsoft SQL Server 2014 Express, Microsoft SQL Server 2014 Service Pack 1, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2014 Web

  • kbsql2005setup kbsql2005engine kbexpertiseadvanced kbinfo kbmt KB917047 KbMtde
Feedback
dy>