Konfigurieren der hohen Verfügbarkeit

Aktualisiert: 05. Dezember 2005

In diesem Abschnitt werden mehrere Lösungen mit hoher Verfügbarkeit von Microsoft SQL Server 2005 vorgestellt, die die Verfügbarkeit von Servern oder Datenbanken verbessern. Eine Lösung mit hoher Verfügbarkeit unterdrückt die Auswirkungen eines Hardware- oder Softwarefehlers und hält die Verfügbarkeit von Anwendungen aufrecht, damit die Ausfallzeiten für Benutzer so gering wie möglich gehalten werden.

SQL Server 2005 enthält mehrere Optionen zum Erstellen der hohen Verfügbarkeit für einen Server oder eine Datenbank. Es gibt die folgenden Optionen für hohe Verfügbarkeit:

• Failover-Clusterunterstützung
  Die Failover-Clusterunterstützung bietet Unterstützung für hohe Verfügbarkeit für eine gesamte Instanz von SQL Server. Ein Failovercluster ist eine Kombination aus mindestens einem Knoten oder Server mit mindestens zwei freigegebenen Datenträgern. Anwendungen wie SQL Server und Notification Services werden in einer Clustergruppe für Microsoft Clusterdienste (MSCS, Microsoft Cluster Service) installiert, die als Ressourcengruppe bezeichnet wird. Zu jedem Zeitpunkt befindet sich jede Ressourcengruppe im Besitz genau eines Knotens im Cluster. Der Anwendungsdienst hat einen virtuellen Namen, der von den Knotennamen unabhängig ist und der aus diesem Grund als Name der Failoverclusterinstanz bezeichnet wird. Eine Anwendung kann die Verbindung mit der Failoverclusterinstanz nicht durch Verweisen auf den Namen der Failoverclusterinstanz herstellen. Die Anwendung muss nicht wissen, welcher Knoten die Failoverclusterinstanz hostet.
  Eine SQL Server-Failoverclusterinstanz wird wie ein einzelner Computer im Netzwerk angezeigt, verfügt jedoch über Funktionalität, die ein Failover von einem Knoten zu einem anderen Knoten ermöglichen, wenn der aktuelle Knoten nicht mehr verfügbar ist. Beispielsweise können Sie eine Instanz von SQL Server auf einem Knoten eines Failoverclusters konfigurieren, um im Falle eines Hardwarefehlers (nicht im Zusammenhang mit der Festplatte), Betriebssystemfehlers oder eines geplanten Updates des Betriebssystems ein Failover zu einem anderen Knoten in der Datenträgergruppe auszuführen.
  Ein Failovercluster schützt nicht vor Festplattenfehlern. Mit der Failover-Clusterunterstützung können Sie die Systemdowntime reduzieren und eine höhere Anwendungsverfügbarkeit ermöglichen. Die Failover-Clusterunterstützung wird in SQL Server 2005 Enterprise Edition, Developer Edition und, mit einigen Einschränkungen, Standard Edition unterstützt. Weitere Informationen zur Failover-Clusterunterstützung finden Sie unter Failover-Clusterunterstützung und Installieren eines Failoverclusters.

• Datenbankspiegelung
  Die Datenbankspiegelung stellt in erster Linie eine Softwarelösung dar, mit der die Verfügbarkeit einer Datenbank erhöht wird, indem ein fast sofortiges Failover unterstützt wird. Mit der Datenbankspiegelung kann eine einzelne Datenbank, die sich im Standbymodus befindet, eine sogenannte Spiegeldatenbank, für eine entsprechende Produktionsdatenbank, eine sogenannte Prinzipaldatenbank, verwaltet werden.
  Zum Erstellen der Spiegeldatenbank wird eine vollständige Datenbanksicherung der Prinzipaldatenbank ohne Wiederherstellung wiederhergestellt. Daher haben Clients keinen Zugriff auf die Spiegeldatenbank. Sie kann jedoch indirekt für Berichtszwecke verwendet werden, indem in der Spiegeldatenbank ein Datenbanksnapshot erstellt wird. Der Datenbanksnapshot ermöglicht den Clients den schreibgeschützten Zugriff auf die Daten in der Datenbank, und zwar so wie sie zum Zeitpunkt der Snapshoterstellung vorlagen.
  Jede Datenbank-Spiegelungskonfiguration umfasst einen Prinzipalserver, der die Prinzipaldatenbank enthält, und einen Spiegelserver, der die Spiegeldatenbank enthält. Der Spiegelserver aktualisiert die Spiegeldatenbank ständig mit der Prinzipaldatenbank.
  Die Datenbankspiegelung kann entweder synchron im Modus für hohe Sicherheit oder asynchron im Modus für hohe Leistung ausgeführt werden. Im Modus für hohe Leistung wird für die Transaktionen ein Commit ausgeführt, ohne darauf zu warten, dass der Spiegelserver das Protokoll auf den Datenträger schreibt, wodurch die Leistung maximiert wird. Im Modus für hohe Sicherheit wird für eine Transaktion, für die ein Commit ausgeführt wird, auf beiden Partnern ein Commit ausgeführt wird, jedoch mit dem Risiko erhöhter Transaktionswartezeit.
  In der einfachsten Konfiguration umfasst die Datenbankspiegelung nur den Prinzipalserver und den Spiegelserver. In dieser Konfiguration kann bei Ausfall des Prinzipalservers der Spiegelserver als betriebsbereiter Standbyserver verwendet werden, mit möglichem Datenverlust. Im Modus für hohe Sicherheit wird eine alternative Konfiguration unterstützt, der Modus für hohe Sicherheit mit automatischem Failover. Diese Konfiguration umfasst eine dritte Serverinstanz, den Zeugen, die das Verwenden des Spiegelservers als unmittelbar betriebsbereiten Server ermöglicht. Ein Failover von der Prinzipaldatenbank zur Spiegeldatenbank nimmt in der Regel einige Sekunden in Anspruch.
  Datenbankspiegelungspartner und -zeugen werden nur in SQL Server 2005 Standard Edition SP1 und höheren Versionen sowie in SQL Server 2005 Enterprise Edition SP1 und höheren Versionen unterstützt. Die Partner müssen jedoch die gleiche Version verwenden. Die asynchrone Datenbankspiegelung (Modus für hohe Leistung) wird nur in SQL Server 2005 Enterprise Edition SP1 und höheren Versionen unterstützt. Zeugen werden auch in SQL Server 2005 Workgroup Edition SP1 und höheren Versionen sowie in SQL Server 2005 Express Edition SP1 und höheren Versionen unterstützt. Weitere Informationen zur Datenbankspiegelung finden Sie unter Database Mirroring.

• Protokollversand
  Wie die Datenbankspiegelung arbeitet auch der Protokollversand auf Datenbankebene. Mit dem Protokollversand kann mindestens eine Datenbank, die sich im betriebsbereiten Standbymodus befindet, die sogenannte sekundäre Datenbank, für eine entsprechende Produktionsdatenbank, die sogenannte primäre Datenbank, verwaltet werden. Jede sekundäre Datenbank wird durch das Wiederherstellen einer Datenbanksicherung der primären Datenbank ohne Wiederherstellung oder mit Standbymodus erstellt. Bei der Wiederherstellung mit Standbymodus kann die resultierende sekundäre Datenbank für eingeschränkte Berichterstellungszwecke verwendet werden.
  Eine Protokollversandkonfiguration enthält einen einzelnen primären Server, der die primäre Datenbank enthält, mindestens einen sekundären Server mit je einer sekundären Datenbank und einen Überwachungsserver. Jeder sekundäre Server aktualisiert seine sekundäre Datenbank in regelmäßigen Abständen von Protokollsicherungen der primären Datenbank. Der Protokollversand beinhaltet eine vom Benutzer änderbare Verzögerung zwischen dem Zeitpunkt, zu dem der primäre Server eine Protokollsicherung der primären Datenbank erstellt und dem Zeitpunkt, zu dem der sekundäre Server die Protokollsicherung wiederherstellt. Bevor ein Failover auftreten kann, muss eine sekundäre Datenbank vollständig auf den neuesten Stand gebracht werden, indem nicht wiederhergestellte Protokollsicherungen manuell angewendet werden.
  Der Protokollversand ist flexibel und unterstützt mehrere Standbydatenbanken. Wenn mehrere Standbydatenbanken erforderlich sind, können Sie den Protokollversand alleine oder als Ergänzung zur Datenbankspiegelung verwenden. Wenn diese Lösungen gemeinsam verwendet werden, ist die aktuelle Prinzipaldatenbank der Datenbank-Spiegelungskonfiguration gleichzeitig die aktuelle primäre Datenbank der Protokollversandkonfiguration.
  Der Protokollversand wird in SQL Server 2005 Enterprise Edition, Standard Edition und Workgroup Edition unterstützt. Weitere Informationen zum Protokollversand finden Sie unter Protokollversand.

• Replikation
  Die Replikation verwendet ein Veröffentlichen/Abonnieren-Modell, mit dem ein primärer Server, der Verleger, Daten an mindestens einen sekundären Server oder Abonnenten verteilen kann. Die Replikation ermöglicht zwischen diesen Servern die Verfügbarkeit und Skalierbarkeit in Echtzeit. Sie unterstützt das Filtern, um eine Teilmenge der Daten auf Abonnenten bereitzustellen, und ermöglicht außerdem partitionierte Updates. Abonnenten sind online und für die Berichterstellung oder andere Funktionen verfügbar, ohne die Wiederherstellung von Abfragen. SQL Server bietet drei Replikationstypen: Snapshot-, Transaktions- und Mergereplikation. Die Transaktionsreplikation weist die geringste Wartezeit auf und wird meist für hohe Verfügbarkeit verwendet. Weitere Informationen finden Sie unter Verbesserung der Skalierbarkeit und Verfügbarkeit.
  Die Replikation wird in allen Editionen von SQL Server 2005 unterstützt. Die Replikationsveröffentlichung ist in SQL Server 2005 Express Edition oder SQL Server Compact Edition nicht verfügbar. Eine vollständige Liste der Replikationsfeatures, die von jeder Edition unterstützt werden, finden Sie unter Von den SQL Server 2005-Versionen unterstützte Features.

  Wichtig:
  Eine sorgfältig durchdachte und implementierte Sicherungs- und Wiederherstellungsstrategie ist für jede Lösung mit hoher Verfügbarkeit von entscheidender Bedeutung. Weitere Informationen finden Sie unter Sichern und Wiederherstellen von Datenbanken in SQL Server und Sichern und Wiederherstellen replizierter Datenbanken.

Auswählen einer Lösung mit hoher Verfügbarkeit

Die folgende Liste enthält Aspekte, die beim Auswählen einer Lösung mit hoher Verfügbarkeit berücksichtigt werden müssen:

• Failover-Clusterunterstützung und Datenbankspiegelung bieten Folgendes:
  • Automatische Erkennung und automatisches Failover
  • Manuelles Failover
  • Transparente Clientumleitung
    Die Failover-Clusterunterstützung weist folgende Einschränkungen auf:
  • Wird im Serverinstanzbereich verwendet.
  • Erfordert signierte Hardware.
  • Verfügt im Standbymodus über keine Berichterstellung.
  • Verwendet eine einzelne Kopie der Datenbank.
  • Schützt nicht vor Festplattenfehlern.
    Die Datenbankspiegelung bietet folgende Vorteile:
  • Arbeitet im Datenbankbereich.
  • Verwendet eine einzelne, doppelte Kopie der Datenbank.

    Hinweis:
    Falls Sie zusätzliche Kopien benötigen, können Sie für die Datenbank neben der Datenbankspiegelung auch den Protokollversand verwenden.

  • Verwendet Standardserver.
  • Bietet mithilfe von Datenbanksnapshots eine eingeschränkte Berichterstellung für den Spiegelserver.
  • Im synchronen Betrieb gehen durch ein verzögertes Commit für die Prinzipaldatenbank keine Daten verloren.
    Die Datenbankspiegelung bietet eine wesentlich höhere Verfügbarkeit im Vergleich zur früheren Verfügbarkeit in SQL Server und stellt eine einfach zu verwaltende Alternative zur Failover-Clusterunterstützung dar.

  Hinweis:

  Weitere Informationen zum Verwenden der Datenbankspiegelung mit einem Failovercluster finden Sie unter Datenbankspiegelung und Failover-Clusterunterstützung. Informationen zum Verwenden von Notification Services mit der Failover-Clusterunterstützung finden Sie unter Verwenden der Failover-Clusterunterstützung mit Notification Services. Informationen zum Verwenden von Notification Services mit der Datenbankspiegelung finden Sie unter Verwenden des Protokollversands oder der Datenbankspiegelung mit Notification Services.

• Protokollversand
  Der Protokollversand ist eine Ergänzung oder Alternative zur Datenbankspiegelung. Zwischen der asynchronen Datenbankspiegelung und dem Protokollversand bestehen trotz der konzeptionellen Ähnlichkeit wesentliche Unterschiede. Der Protokollversand bietet folgende Funktionen:
  • Unterstützt mehrere sekundäre Datenbanken in mehreren Serverinstanzen für eine einzelne primäre Datenbank.
  • Ermöglicht eine vom Benutzer angegebene Verzögerung zwischen dem Zeitpunkt, zu dem der primäre Server das Protokoll der primären Datenbank sichert, und dem Zeitpunkt, zu dem die sekundären Server die Protokollsicherung wiederherstellen müssen. Eine längere Verzögerung kann nützlich sein, wenn z. B. versehentlich Daten in der primären Datenbank geändert werden. Wenn die versehentliche Änderung schnell bemerkt wird, kann eine Verzögerung es Ihnen ermöglichen, die noch unveränderten Daten von einer sekundären Datenbank abzurufen, bevor die Änderung dort widergespiegelt wird.
    Im Vergleich zu der kürzesten Zeit, die beim Protokollversand erforderlich ist, um eine Änderung in einer sekundären Datenbank widerzuspiegeln, bietet die asynchrone Datenbankspiegelung den möglichen Vorteil einer kürzeren Zeitspanne zwischen dem Zeitpunkt, zu dem eine bestimmte Änderung in der primären Datenbank vorgenommen wird, und dem Zeitpunkt, zu dem diese Änderung in der Spiegeldatenbank widergespiegelt wird.
    Ein Vorteil der Datenbankspiegelung gegenüber dem Protokollversand liegt darin, dass der Modus für hohe Sicherheit eine Konfiguration ohne Datenverlust darstellt, die als einfache Failoverstrategie unterstützt wird.

    Hinweis:
    Informationen zum Verwenden des Protokollversands mit der Datenbankspiegelung finden Sie unter Datenbankspiegelung und Protokollversand. Informationen zum Verwenden von Notification Services mit dem Protokollversand finden Sie unter Verwenden des Protokollversands oder der Datenbankspiegelung mit Notification Services.

• Replikation
  Die Replikation bietet die folgenden Vorteile:
  • Ermöglicht aufgrund der Verwendung im Datenbankbereich das Filtern in der Datenbank, um eine Teilmenge von Daten in den sekundären Datenbanken bereitzustellen.
  • Ermöglicht mehr als eine redundante Kopie der Datenbank.
  • Ermöglicht zwischen mehreren Datenbanken die Verfügbarkeit und Skalierbarkeit in Echtzeit und unterstützt partitionierte Updates.
  • Ermöglicht die vollständige Verfügbarkeit der sekundären Datenbanken für die Berichterstellung oder sonstige Funktionen, ohne die Wiederherstellung von Abfragen.

  Hinweis:
  Informationen zum Verwenden der Datenbankspiegelung mit der Replikation finden Sie unter Replikation und Datenbankspiegelung.

In diesem Abschnitt

Siehe auch

Andere Ressourcen

Hardware- und Softwareanforderungen für die Installation von SQL Server 2005
Von den SQL Server 2005-Versionen unterstützte Features
SQL Server-Replikation

Hilfe und Informationen

Informationsquellen für SQL Server 2005