Beschreibung der Unterstützung für Netzwerkdatenbankdateien in SQL Server

  • Artikel

In diesem Artikel wird die Unterstützung für Netzwerkdatenbankdateien in SQL Server beschrieben, und es wird beschrieben, wie Sie SQL Server konfigurieren, um eine Datenbank auf einem Netzwerkserver oder auf einem NAS-Speicherserver zu speichern.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 304261

Zusammenfassung

Microsoft empfiehlt im Allgemeinen die Verwendung eines SAN (Storage Area Network) oder eines lokal angefügten Datenträgers für die Speicherung Ihrer Microsoft SQL Server-Datenbankdateien, da diese Konfiguration SQL Server Leistung und Zuverlässigkeit optimiert. Standardmäßig ist die Verwendung von Netzwerkdatenbankdateien, die auf einem Netzwerkserver oder einem NAS-Server (Network Attached Storage) gespeichert sind, für SQL Server nicht aktiviert.

Sie können jedoch SQL Server so konfigurieren, dass eine Datenbank auf einem Netzwerkserver oder NAS-Server gespeichert wird. Server, die zu diesem Zweck verwendet werden, müssen SQL Server Anforderungen für die Sortierung von Datenschreibvorgängen und Durchschreibgarantien erfüllen. Diese informationen finden Sie im Abschnitt Weitere Informationen .

Die folgenden Bedingungen beschreiben die Verwendung von Netzwerkdatenbankdateien, die auf einem Netzwerkserver oder NAS-Server gespeichert sind:

  • Diese Verwendung ist in Microsoft SQL Server 2008 R2 und höheren Versionen standardmäßig aktiviert.

  • Für diese Verwendung muss das Startablaufverfolgungsflag -T1807 in Microsoft SQL Server 2008 und früheren Versionen verwendet werden. Ab SQL Server 2012 ist das Ablaufverfolgungsflag nicht mehr erforderlich. Weitere Informationen zum Aktivieren von Startablaufverfolgungsflags finden Sie unter Startoptionen des Datenbank-Engine-Diensts.

Windows Hardware Quality Lab (WHQL)-qualifizierte Geräte

Microsoft Windows-Server und Netzwerkserver oder NAS-Speicherserver mit WHQL-Qualifikation (Windows Hardware Quality Lab) erfüllen automatisch die Für die Unterstützung eines SQL Server Speichergeräts erforderlichen Datenschreibreihenfolge und -durchschreibgarantien. Microsoft unterstützt anwendungs- und speicherbezogene Probleme in diesen Konfigurationen.

Hinweis

Um von SQL Server unterstützt zu werden, sollte die NAS-Speicherlösung auch alle Anforderungen erfüllen, die im Downloaddokument aufgeführt sind: SQL Server Anforderungen für das E/A-Zuverlässigkeitsprogramm.

Andere Geräte

Wenn Sie ein nicht WHQL-qualifiziertes Speichergerät mit SQL Server verwenden, das die in diesem Artikel beschriebenen E/A-Garantien für die Verwendung von Transaktionsdatenbanken unterstützt, bietet Microsoft vollständige Unterstützung für SQL Server- und SQL Server-basierten Anwendungen. Probleme mit dem Gerät oder dessen Speichersubsystem werden jedoch an den Gerätehersteller verwiesen. Wenn Sie ein nicht WHQL-qualifiziertes Speichergerät verwenden, das die in diesem Artikel beschriebenen E/A-Garantien für die Verwendung von Transaktionsdatenbanken nicht unterstützt, kann Microsoft keine Unterstützung für SQL Server oder SQL Server-basierte Anwendungen bereitstellen. Wenden Sie sich an Ihren Gerätehersteller, um festzustellen, ob Ihr nicht WHQL-qualifiziertes Speichergerät die in diesem Artikel beschriebenen E/A-Garantien für die verwendung von Transaktionsdatenbanken unterstützt. Wenden Sie sich außerdem an Ihren Gerätehersteller, um zu überprüfen, ob Sie das Gerät ordnungsgemäß bereitgestellt und für die Verwendung von Transaktionsdatenbanken konfiguriert haben.

Weitere Informationen

Standardmäßig können Sie in SQL Server 2008 und früheren Versionen keine SQL Server Datenbank auf einer Netzwerkdateifreigabe erstellen. Jeder Versuch, eine Datenbankdatei an einem zugeordneten oder UNC-Netzwerkspeicherort zu erstellen, generiert eine der folgenden Fehlermeldungen:

  • Fehlermeldung 1

    5105 "Geräteaktivierungsfehler"

  • Fehlermeldung 2

    5110 "Die Datei 'file_name' wird auf einem Netzwerkgerät nicht für Datenbankdateien unterstützt."

Dieses Verhalten wird erwartet. Das Ablaufverfolgungsflag 1807 umgeht die Überprüfung und ermöglicht es Ihnen, SQL Server mit netzwerkbasierten Datenbankdateien zu konfigurieren. SQL Server und die meisten anderen Enterprise-Datenbanksysteme verwenden ein Transaktionsprotokoll und die zugehörige Wiederherstellungslogik, um die Transaktionsdatenbankkonsistenz im Falle eines Systemausfalls oder eines nicht verwalteten Herunterfahrens aufrechtzuerhalten. Diese Wiederherstellungsprotokolle basieren auf der Möglichkeit, direkt auf die Datenträgermedien zu schreiben, sodass das Wiederherstellungssystem sicher sein kann, dass der Schreibvorgang abgeschlossen ist oder dass der Abschluss des Schreibvorgangs garantiert werden kann, wenn eine Eingabe-/Ausgabeanforderung des Betriebssystems an den Datenbank-Manager zurückgegeben wird. Jeder Fehler einer Software- oder Hardwarekomponente, um dieses Protokoll zu berücksichtigen, kann im Falle eines Systemausfalls zu einem teilweisen oder vollständigen Datenverlust oder einer Beschädigung führen. Weitere Informationen zu diesen Aspekten der Protokollierung und wiederherstellungsprotokolle in SQL Server finden Sie unter Beschreibung der Protokollierungs- und Datenspeicherungsalgorithmen, die die Datensicherheit in SQL Server erweitern.

Microsoft unterstützt keine SQL Server vernetzten Datenbankdateien auf NAS- oder Netzwerkspeicherservern, die diese Anforderungen an das Durchschreiben und die Schreibreihenfolge nicht erfüllen.

Aufgrund des Risikos, dass Netzwerkfehler die Datenbankintegrität beeinträchtigen, sowie mögliche Auswirkungen auf die Leistung, die sich aus der Verwendung von Netzwerkdateifreigaben zum Speichern von Datenbanken ergeben können, empfiehlt Microsoft, Datenbankdateien entweder auf lokalen Datenträgersubsystemen oder in Speicherbereichsnetzwerken (Storage Area Networks, SANs) zu speichern.

Ein NAS-System (Network Attached Storage) ist ein dateibasiertes Speichersystem, an das Clients über den Netzwerkumleitungsor mithilfe eines Netzwerkprotokolls (z. B. TCP/IP) anfügen. Wenn für den Zugriff auf eine Datenträgerressource die Zuordnung einer Freigabe erforderlich ist oder die Datenträgerressource als Remoteserver über einen UNC-Pfad (z. B. \Servername\Freigabename) im Netzwerk angezeigt wird, wird das Datenträgerspeichersystem nicht als Speicherort für SQL Server Datenbanken unterstützt.

Leistungsprobleme

SQL Server können wie andere Enterprise-Datenbanksysteme eine große Last auf ein E/A-Subsystem stellen. In den meisten großen Datenbankanwendungen spielen die physische E/A-Konfiguration und -Optimierung eine wichtige Rolle für die Gesamtleistung des Systems. Es gibt drei wichtige E/A-Leistungsfaktoren, die berücksichtigt werden müssen:

  • E/A-Bandbreite: Die aggregierte Bandbreite, die in der Regel in Megabyte pro Sekunde gemessen wird und für ein Datenbankgerät aufrechterhalten werden kann.
  • E/A-Latenz: Die In der Regel in Millisekunden gemessene Latenz zwischen einer E/A-Anforderung durch das Datenbanksystem und dem Punkt, an dem die E/A-Anforderung abgeschlossen wird.
  • CPU-Kosten: Die CPU-Hostkosten, die in der Regel in CPU-Mikrosekunden gemessen werden, damit das Datenbanksystem eine einzelne E/A durchführen kann.

Jeder dieser E/A-Faktoren kann zu einem Engpass werden, und Sie müssen alle diese Faktoren berücksichtigen, wenn Sie ein E/A-System für eine Datenbankanwendung entwerfen.

In ihrer einfachsten Form verwendet eine NAS-Lösung einen Standard-Netzwerkumleitungssoftwarestapel, eine Standard-Netzwerkschnittstelle Karte (NIC) und Standard-Ethernet-Komponenten. Der Nachteil dieser Konfiguration besteht darin, dass alle Datei-E/A-Vorgänge über den Netzwerkstapel verarbeitet werden und den Bandbreitenbeschränkungen des Netzwerks selbst unterliegen. Dies kann zu Leistungs- und Datensicherheitsproblemen führen, insbesondere in Programmen, die ein hohes Maß an Datei-E/A erfordern, z. B. SQL Server. In einigen von Microsoft getesteten NAS-Konfigurationen betrug der E/A-Durchsatz ein Drittel (1/3) wie bei einer direkt angeschlossenen Speicherlösung auf demselben Server. In derselben Konfiguration waren die CPU-Kosten für die Durchführung einer E/A über das NAS-Gerät doppelt so hoch wie bei einer lokalen E/A. Mit der Weiterentwicklung von NAS-Geräten und der Netzwerkinfrastruktur können sich diese Verhältnisse auch im Vergleich zu direkt angeschlossenem Speicher oder SANs verbessern. Wenn Ihre Anwendungsdaten größtenteils im Datenbankpufferpool zwischengespeichert werden und keine der beschriebenen E/A-Engpässe auftreten, ist die Leistung auf einem NAS-basierten System wahrscheinlich für Ihre Anwendung ausreichend.

Überlegungen zur Sicherung und Wiederherstellung

SQL Server stellt die Virtual Device Interface (VDI) für die Sicherung bereit. Die VDI bietet Anbietern von Sicherungssoftware eine leistungsstarke, skalierbare und zuverlässige Möglichkeit für die Durchführung von Sicherungen mit heißem Zustand und für die Wiederherstellung SQL Server Datenbanken.

Die Sicherungssoftware arbeitet mit Datenbankdateien, die über VDI auf NAS-Geräten gespeichert sind, ohne spezielle Unterstützung für das NAS. Dies führt jedoch zu viel zusätzlichem Netzwerkdatenverkehr während der Sicherung und Wiederherstellung. Während der Sicherung über VDI liest SQL Server die Dateien remote und übergibt die Daten an die Sicherungssoftware des Drittanbieters, die auf dem SQL Server Computer ausgeführt wird. Der Wiederherstellungsvorgang ist analog.

Um den zusätzlichen Netzwerkaufwand zu vermeiden, muss der Sicherungsanbieter NAS-spezifischen Support durch den Sicherungsanbieter und den NAS-Anbieter bereitstellen. SQL Server VDI ermöglicht es der Sicherungssoftware, die von den NAS-Geräten unterstützten Hardware- (Split-Spiegel) oder Softwaretechnologien (Copy-on-Write) zu nutzen, um schnelle Kopien der Datenbankdateien lokal auf dem NAS zu erstellen. Diese Technologien vermeiden nicht nur den Mehraufwand für das Kopieren der Dateien über das Netzwerk für die Sicherung, sie können auch die Wiederherstellungszeiten um ein Vielfaches verkürzen.

Sicherungen, die auf nas gespeichert sind, sind anfällig für dieselben Fehler, die sich auf datenbankdateien auswirken, die auf dem NAS gespeichert sind. Sie sollten diese Sicherungen schützen, indem Sie sie auf alternative Medien kopieren.

Achtung

Wenn Sie NAS-Sicherungstechnologien ohne SQL Server VDI-Unterstützung verwenden, kann eine Datenbankbeschädigung in der Sicherung auftreten. Diese Beschädigung umfasst zerrissene Seiten oder Inkonsistenzen zwischen den Protokoll- und Datendateien, wenn sie auf separaten Geräten gespeichert sind. SQL Server erkennen die beschädigten Seiten oder Inkonsistenzen möglicherweise erst, wenn Sie die Datenbank wiederherstellen und auf die beschädigten Daten zugreifen. Microsoft unterstützt nicht die Verwendung von NAS-Sicherungstechnologien, die nicht mit SQL Server koordiniert sind.

Sicherungsunterstützung und NAS-Anbieterunterstützung für SQL Server VDI variieren. Wenden Sie sich an Ihre NAS- und Sicherungssoftwareanbieter, um Details zur VDI-Unterstützung zu erhalten.

Microsoft fordert Kunden, die eine Bereitstellung einer NAS-Lösung für SQL Server Datenbanken in Betracht ziehen, auf, sich an ihren NAS-Anbieter zu wenden, um sicherzustellen, dass der End-to-End-Lösungsentwurf für die Datenbankverwendung vorgesehen ist. Viele NAS-Anbieter verfügen über Best Practices-Leitfäden und zertifizierte Konfigurationen für diese Verwendung. Microsoft empfiehlt kunden außerdem, ihre E/A-Leistung zu vergleichen, um sicherzustellen, dass keiner der zuvor erwähnten E/A-Faktoren einen Engpass in ihrer Anwendung verursacht.

In der folgenden Liste wird die Unterstützung für netzwerkbasierte Dateien in SQL-Failoverclustern beschrieben:

Zusätzliche Hinweise

Eine falsche Verwendung von Datenbanksoftware mit einem NAS-Produkt oder die Datenbanknutzung mit einem nicht ordnungsgemäß konfigurierten NAS-Produkt kann zu Datenverlusten führen, einschließlich des Totalverlusts der Datenbank. Wenn das NAS-Gerät oder die Netzwerksoftware Datengarantien wie Schreibreihenfolge oder Durchschreiben nicht vollständig berücksichtigt, können Hardware-, Software- oder sogar Stromausfälle die Datenintegrität ernsthaft beeinträchtigen.

References