Geschäftskontinuität und Datenbankwiederherstellung – SQL Server

Artikel
04/26/2023

Gilt für: SQL Server 2016 (13.x) und höhere Versionen

Dieser Artikel bietet eine Übersicht über Lösungen für Geschäftskontinuität für Hochverfügbarkeit und Notfallwiederherstellung in SQL Server unter Windows und Linux.

Eine allgemeine Aufgabe, die jeder berücksichtigen sollte, der SQL Server bereitstellt, ist das Sicherstellen der Verfügbarkeit aller unternehmenskritischen SQL Server-Instanzen und der darin enthaltenen Datenbanken, wenn das Unternehmen oder die Benutzer diese benötigen, ob von 9 bis 17 Uhr oder rund um die Uhr. Das Ziel ist, das Unternehmen mit minimaler oder ohne Unterbrechung aufrechtzuerhalten. Dieses Konzept wird auch als Geschäftskontinuität bezeichnet.

In SQL Server 2017 (14.x) wurden viele neue Funktionen oder Erweiterungen für vorhandene eingeführt, einige davon dienen der Verfügbarkeit. Die wichtigste Erweiterung für SQL Server 2017 (14.x) war die Unterstützung für SQL Server für Linux-Distributionen. Eine vollständige Liste der neuen Features in SQL Server finden Sie in den folgenden Artikeln:

In diesem Artikel werden die Verfügbarkeitsszenarien ab SQL Server 2017 (14.x) sowie neue und erweiterte Verfügbarkeitsfeatures behandelt. Dabei sind auch hybride Szenarien enthalten, durch die SQL Server-Bereitstellungen unter Windows Server und Linux umfassen können sowie Szenarien, mit denen die Anzahl von lesbaren Kopien einer Datenbank erhöht werden kann.

Dieser Artikel behandelt keine Verfügbarkeitsoptionen außerhalb von SQL Server, z. B. solche, die durch die Virtualisierung bereitgestellt werden. Sämtliche Erläuterungen beziehen sich auf Installationen von SQL Server einer Gast-VM, die sich entweder in der öffentlichen Cloud befindet oder von einem lokalen Hypervisorserver gehostet wird.

SQL Server-Szenarios, die Verfügbarkeitsfeatures verwenden

Always On-Verfügbarkeitsgruppen, Always On-Failoverclusterinstanzen und der Protokollversand können auf unterschiedliche Weise und nicht unbedingt nur zu Verfügbarkeitszwecken verwendet werden. Verfügbarkeitsfunktionen können auf vier verschiedene Arten verwendet werden:

Hochverfügbarkeit
Notfallwiederherstellung
Migrationen und Upgrades
Horizontales Hochskalieren von lesbaren Kopien von einer oder mehreren Datenbanken

In den folgenden Abschnitten werden die relevanten Funktionen erläutert, die für ein bestimmtes Szenario verwendet werden können. Die einzige Funktion, die nicht behandelt wird, ist die SQL Server-Replikation. Die SQL Server-Replikation ist nicht offiziell als Verfügbarkeitsfeature für „Always On“ definiert, wird jedoch häufig zum Herstellen redundanter Daten in bestimmten Szenarios verwendet. Die Mergereplikation wird für SQL Server unter Linux nicht unterstützt. Weitere Informationen finden Sie unter SQL Server-Replikation unter Linux.

Wichtig

Die SQL Server-Verfügbarkeitsfunktionen ersetzen keine stabile, gut getestete Sicherungs- und Wiederherstellungsstrategie, bei der es sich um den grundlegendsten Baustein jeder Verfügbarkeitslösung handelt.

Hochverfügbarkeit

Es ist wichtig, sicherzustellen, dass SQL Server-Instanzen oder -Datenbanken im Fall eines lokalen Problems in einem Rechenzentrum oder einer einzelnen Region in der Cloudregion verfügbar sind. In diesem Abschnitt wird erläutert, wie die SQL Server-Verfügbarkeitsfeatures Ihnen bei dieser Aufgabe helfen können. Alle beschriebenen Features sind für Windows Server und Linux verfügbar.

Verfügbarkeitsgruppen

Die in SQL Server 2012 (11.x) eingeführten Always On-Verfügbarkeitsgruppen stellen Schutz auf Datenbankebene bereit, indem sie jede Transaktion einer Datenbank zu einer anderen Instanz (auch als Replikat bezeichnet) senden, die eine Kopie dieser Datenbank in einem speziellen Zustand enthält. Eine Verfügbarkeitsgruppe kann in der Standard Edition oder Enterprise Edition bereitgestellt werden. Die Instanzen, die in einer Verfügbarkeitsgruppe enthalten sind, können eigenständig oder Always On-Failoverclusterinstanzen (FCIs, im nächsten Abschnitt beschrieben) sein. Da die Transaktionen direkt an ein Replikat gesendet werden, werden Verfügbarkeitsgruppen empfohlen, wenn Anforderungen für niedrigere Ziele bei Wiederherstellungspunkten und der Wiederherstellungszeit gelten. Das Verschieben von Daten zwischen Replikaten kann synchron oder asynchron erfolgen. Die Enterprise Edition unterstützt bis zu drei synchrone Replikate, einschließlich des primären Replikats. Eine Verfügbarkeitsgruppe enthält eine vollständige Lese-/Schreibkopie der Datenbank, die sich auf dem primären Replikat befindet. Sekundäre Replikate können keine Transaktionen direkt von Benutzer*innen oder Anwendungen empfangen.

Hinweis

Always On ist ein Überbegriff für die Verfügbarkeitsfeatures in SQL Server und schließt Verfügbarkeitsgruppen und FCIs ein. Always On ist nicht der Name des Verfügbarkeitsgruppenfeatures.

Vor SQL Server 2022 (16.x) boten Verfügbarkeitsgruppen nur Schutz auf Datenbankebene und nicht auf Instanzebene. Alles, was nicht im Transaktionsprotokoll erfasst oder in der Datenbank konfiguriert ist, muss für jedes sekundäre Replikat manuell synchronisiert werden. Einige Beispiele für Objekte, die manuell synchronisiert werden müssen, sind Anmeldungen auf Instanzebene, Verbindungsserver und SQL Server-Agent-Aufträge.

Ab SQL Server 2022 (16.x) können Sie Metadatenobjekte wie Benutzer*innen, Anmeldungen, Berechtigungen und SQL Server-Agent Aufträge zusätzlich zur Instanzebene auch auf Gruppenebene verwalten. Weitere Informationen finden Sie unter Enthaltene Verfügbarkeitsgruppen.

Eine Verfügbarkeitsgruppe besitzt eine weitere Komponente, die als Listener bezeichnet wird. Durch diesen können Anwendungen und Benutzer*innen eine Verbindung herstellen, ohne zu wissen, welche Instanz von SQL Server das primäre Replikat hostet. Jede Verfügbarkeitsgruppe hat einen eigenen Listener. Während die Implementierungen des Listeners sich geringfügig zwischen Windows Server und Linux unterscheiden, sind die bereitgestellte Funktionalität und die Verwendung identisch. Die folgende Abbildung zeigt eine Windows Server-basierte Verfügbarkeitsgruppe, die einen Windows Server-Failovercluster (WSFC) verwendet. Ein zugrunde liegender Cluster auf OS-Ebene ist für die Verfügbarkeit auf Linux oder Windows Server erforderlich. Dieses Beispiel zeigt eine einfache Konfiguration für zwei Server oder Knoten, bei der ein WSFC den zugrunde liegenden Cluster darstellt.

Abbildung einer einfachen Verfügbarkeitsgruppe

Bei Replikaten gelten für die Standard Edition und die Enterprise Edition unterschiedliche Höchstwerte. Eine Verfügbarkeitsgruppe in der Standard Edition, die als Basis-Verfügbarkeitsgruppe bezeichnet wird, unterstützt zwei Replikate (ein primäres und ein sekundäres) mit nur einer einzigen Datenbank in der Verfügbarkeitsgruppe. In der Enterprise Edition können nicht nur mehrere Datenbanken für eine einzige Verfügbarkeitsgruppe konfiguriert werden, sondern es können auch bis zu neun Replikate (ein primäres, acht sekundäre) verwendet werden. Die Enterprise Edition bietet weitere optionale Vorteile, z.B. lesbare sekundäre Replikate, das Erstellen von Sicherungen aus einem sekundären Replikat usw.

Hinweis

Die Datenbankspiegelung, die seit SQL Server 2012 (11.x) veraltet ist, ist nicht für die Linux-Version von SQL Server verfügbar und wird auch nicht hinzugefügt. Kund*innen, die die Datenbankspiegelung immer noch verwenden, sollten die Migration zu Verfügbarkeitsgruppen planen, die den Ersatz für die Datenbankspiegelung darstellen.

Verfügbarkeitsgruppen können für die Verfügbarkeit entweder automatische oder manuelle Failover bereitstellen. Automatische Failover können auftreten, wenn die synchrone Datenverschiebung konfiguriert ist und die Datenbank auf dem primären und sekundären Replikat sich in einem synchronisierten Zustand befindet. Solange der Listener verwendet wird und die Datenbank eine höhere Version des .NET Framework (3.5 mit einem Update oder 4.0 und höher) verwendet, sollte das Failover mit minimaler oder ohne Auswirkungen für die Benutzer*innen ausgeführt werden. Ein Failover zu einem sekundären Replikat, das dieses zum neuen primären Replikat macht, kann als automatisch oder manuell konfiguriert werden und wird im Allgemeinen in Sekunden gemessen.

In der folgenden Liste werden einige Unterschiede bei Verfügbarkeitsgruppen zwischen Windows Server und Linux beschrieben:

Da die zugrunde liegenden Cluster unter Linux und Windows Server unterschiedlich funktionieren, werden unter Linux alle Failover (manuell oder automatisch) von Verfügbarkeitsgruppen über den Cluster ausgeführt. Bei Bereitstellungen von Windows Server-basierten Verfügbarkeitsgruppen müssen manuelle Failover über SQL Server ausgeführt werden. Automatische Failover werden unter Windows Server und Linux von den zugrunde liegenden Clustern behandelt.
Für SQL Server für Linux umfasst die empfohlene Konfiguration für Verfügbarkeitsgruppen mindestens drei Replikate. Der Grund dafür liegt in der Funktionsweise des zugrunde liegenden Clusterings.
Unter Linux wird der allgemeine Name, der von jedem Listener verwendet wird, im DNS und nicht wie unter Windows Server im Cluster definiert.

Ab SQL Server 2017 (14.x) sind für Verfügbarkeitsgruppen einige neue Features und Erweiterungen verfügbar:

Clustertypen
REQUIRED_SECONDARIES_TO_COMMIT
Erweiterte MS DTC-Unterstützung (Microsoft Distributed Transaction Coordinator) für Windows Server-basierte Konfigurationen
Zusätzliche Szenarios für das horizontale Hochskalieren von schreibgeschützten Datenbanken (später in diesem Artikel beschrieben)

Clustertypen für Verfügbarkeitsgruppen

Das integrierte Verfügbarkeitsformular des Clusterings in Windows Server wird über eine Funktion namens Failoverclustering aktiviert. Dadurch kann ein WSFC erstellt werden, der mit einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz (FCI) verwendet werden kann. Die Integration von Verfügbarkeitsgruppen und FCIs wird über clusterfähige Ressourcen-DLLs bereitgestellt, die in SQL Server enthalten sind.

SQL Server für Linux unterstützt mehrere Clustertechnologien. Microsoft unterstützt die SQL Server Komponenten, während unsere Partner die entsprechende Clustertechnologie bereitstellen. So unterstützt SQL Server für Linux zusammen mit Pacemaker als Clusterlösung auch HPE Serviceguard und DH2i DxEnterprise.

Ein Windows-basierter Failovercluster und eine Linux-Clusterlösung haben mehr Gemeinsamkeiten als Unterschiede. Beide ermöglichen das Kombinieren von einzelnen Servern in einer Konfiguration, um die Verfügbarkeit zu gewährleisten und enthalten Konzepte für Ressourcen, Einschränken (die jedoch unterschiedlich implementiert sind), Failover usw.

Microsoft stellt z. B. für die Unterstützung von Pacemaker für die Konfiguration von Verfügbarkeitsgruppen und FCIs, einschließlich des automatischen Failovers, das Paket mssql-server-ha bereit. Dieses ähnelt den Ressourcen-DLLs in einem WSFC, ist aber nicht mit diesen identisch. Einer der Unterschiede zwischen einem WSFC und Pacemaker besteht darin, dass Pacemaker keine Netzwerknamenressource enthält. Diese Komponente ermöglicht das Abstrahieren des Namens des Listeners (oder der FCI) auf einem WSFC. DNS stellt diese Namensauflösung unter Linux bereit.

Aufgrund der Unterschiede im Clusterstapel müssen für Verfügbarkeitsgruppen einige Änderungen vorgenommen werden, da SQL Server einige der Metadaten behandeln muss, die nativ von einem WSFC behandelt werden. Eine wichtige Änderung ist die Einführung eines Clustertyps für eine Verfügbarkeitsgruppe. Dieser wird in sys.availability_groups in den Spalten cluster_type und cluster_type_desc gespeichert. Es gibt drei Clustertypen:

WSFC
Extern
Keine

Alle Verfügbarkeitsgruppen, die Verfügbarkeit erfordern, müssen einen zugrunde liegenden Cluster verwenden. Dies ist im Fall von SQL Server 2017 (14.x) und höher ein WSFC oder ein Linux-Cluster-Agent. Für Windows Server-basierte Verfügbarkeitsgruppen, die einen zugrunde liegenden WSFC verwenden, ist der Standardclustertyp WSFC, der nicht explizit festgelegt werden muss. Beim Erstellen von Linux-basierten Verfügbarkeitsgruppen muss der Clustertyp auf „Extern“ festgelegt werden. Die Integration mit einer externen Clusterlösung unter Linux wird nach der Erstellung der Verfügbarkeitsgruppe konfiguriert, während dies bei einem WSFC zur Erstellungszeit erfolgt.

Der Clustertyp „Keiner“ kann für Windows Server- und Linux-Verfügbarkeitsgruppen verwendet werden. Das Festlegen des Clustertyps auf „Keiner“ bedeutet, dass die Verfügbarkeitsgruppe keinen zugrunde liegenden Cluster erfordert. Das bedeutet, dass es sich bei SQL Server 2017 (14.x) um die erste Version von SQL Server handelt, die Verfügbarkeitsgruppen ohne einen Cluster unterstützt. Der Nachteil hierbei ist jedoch, dass diese Konfiguration nicht als Hochverfügbarkeitslösung unterstützt wird.

Wichtig

Ab SQL Server 2017 (14.x) können Sie den Clustertyp einer Verfügbarkeitsgruppe nach der Erstellung nicht mehr ändern. Das bedeutet, dass eine Verfügbarkeitsgruppe nicht von „Keiner“ in „Extern“ oder „WSFC“ (oder umgekehrt) geändert werden kann.

Für Benutzer*innen, die nur zusätzliche schreibgeschützte Kopien einer Datenbank hinzufügen möchten oder die festlegen möchten, welche Optionen eine Verfügbarkeitsgruppe für die Migration/Upgrades bereitstellt, ohne an die zusätzliche Komplexität eines zugrunde liegenden Clusters oder der Replikation gebunden zu sein, ist eine Verfügbarkeitsgruppe mit dem Clustertyp „Keiner“ die ideale Lösung. Weitere Informationen finden Sie in den Abschnitten Migrationen und Upgrades und Schreibgeschützte Verfügbarkeitsgruppen.

Der folgende Screenshot zeigt die Unterstützung für die verschiedenen Clustertypen in SQL Server Management Studio (SSMS). Sie müssen Version 17.1 oder höher ausführen. Der folgende Screenshot stammt aus Version 17.2.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

In SQL Server 2016 (13.x) wurde die Unterstützung für die Anzahl von synchronen Replikaten in der Enterprise Edition von zwei auf drei erhöht. Wenn jedoch ein sekundäres Replikat synchronisiert wurde und bei einem anderen ein Problem auftrat, konnte das Verhalten nicht gesteuert werden, um dem primären Replikat mitzuteilen, entweder auf das sich falsch verhaltende Replikat zu warten oder fortzufahren. Dadurch erhält das primäre Replikat ab einem bestimmten Punkt weiterhin Schreibdatenverkehr, obwohl das sekundäre Replikat sich nicht in einem synchronisierten Zustand befindet. Dies bedeutet, dass es zu Datenverlusten im sekundären Replikat kommt. Ab SQL Server 2017 (14.x) können Sie mit REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT steuern, was geschieht, wenn synchrone Replikate vorhanden sind. Diese Option funktioniert folgendermaßen:

Es gibt drei mögliche Werte: 0, 1 und 2.
Der Wert entspricht der Anzahl von sekundären Replikaten, die synchronisiert werden müssen, und hat Auswirkungen auf Datenverluste, auf die Verfügbarkeit von Verfügbarkeitsgruppen und auf Failover.
Für WSFCs und den Clustertyp „Keiner“ ist der Standardwert 0 und kann manuell auf 1 oder 2 festgelegt werden.
Für den Clustertyp „Extern“ wird dies standardmäßig durch den Clustermechanismus festgelegt, kann aber manuell überschrieben werden. Bei drei synchronen Replikaten ist der Standardwert 1.

Unter Linux wird der Wert für REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT in der Ressource der Verfügbarkeitsgruppe im Cluster konfiguriert. Unter Windows wird er per Transact-SQL festgelegt.

Ein Wert größer 0 gewährleistet einen höheren Datenschutz, denn wenn die erforderliche Anzahl von sekundären Replikaten nicht verfügbar ist, ist auch das primäre Replikat nicht verfügbar, bis dieses Problem behoben ist. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT wirkt sich auch auf das Failoververhalten aus, da kein automatisches Failover ausgeführt werden kann, wenn sich nicht die erforderliche Anzahl von sekundären Replikaten in einem korrekten Zustand befindet. Unter Linux lässt ein Wert von 0 keine automatischen Failover zu. Wenn Sie unter Linux also synchrone Replikate mit automatischem Failover verwenden, muss ein Wert größer 0 festgelegt werden, um ein automatisches Failover zu erzielen. 0 unter Windows Server entspricht dem Verhalten in SQL Server 2016 (13.x) und früheren Versionen.

Erweiterte Unterstützung für den Microsoft Distributed Transaction Coordinator

Vor SQL Server 2016 (13.x) bestand die einzige Möglichkeit für Verfügbarkeit in SQL Server für Anwendungen, die verteilte Transaktionen erfordern, die DTC im Hintergrund ausführen, in der Bereitstellung von FCIs. Eine verteilte Transaktion kann auf zwei Arten erfolgen:

Eine Transaktion, die mehr als eine Datenbank auf derselben Instanz von SQL Server umfasst
Eine Transaktion, die mehr als eine Instanz von SQL Server oder möglicherweise eine Nicht-SQL Server-Datenquelle umfasst

In SQL Server 2016 (13.x) wurde eine Teilunterstützung für DTC mit Verfügbarkeitsgruppen eingeführt, die das zweite Szenario abdecken. SQL Server 2017 (14.x) unterstützte dann beide Szenarien mit DTC.

Ab SQL Server 2017 (14.x) kann einer Verfügbarkeitsgruppe auch nach deren Erstellung DTC-Unterstützung hinzugefügt werden. In SQL Server 2016 (13.x) konnte die Unterstützung für DTC für eine Verfügbarkeitsgruppe erst aktiviert werden, nachdem die Verfügbarkeitsgruppe erstellt wurde.

Failoverclusterinstanzen

Gruppierte Installationen sind eine Funktion von SQL Server seit Version 6.5. FCIs sind eine bewährte Methode zum Gewährleisten der Verfügbarkeit für die gesamte Installation von SQL Server, die als Instanz bezeichnet wird. Das bedeutet, dass alle Elemente in der Instanz (einschließlich Datenbanken, SQL Server-Agent-Aufträge, Verbindungsserver) auf einen anderen Server verschoben werden, wenn auf dem zugrunde liegenden Server ein Problem auftritt. Alle FCIs erfordern freigegebenen Speicher, auch wenn dieser über ein Netzwerk bereitgestellt wird. Die Ressourcen der FCIs können jeweils nur von einem Knoten gleichzeitig ausgeführt und besessen werden. In der folgenden Abbildung besitzt der erste Knoten des Clusters die FCI. Das bedeutet, dass dieser auch die freigegebenen Speicherressourcen besitzt, die ihm zugewiesen sind. Dies ist durch die durchgezogene Linie zum Speicher gekennzeichnet.

Abbildung einer Failoverclusterinstanz

Wie in der folgenden Abbildung dargestellt ändert sich der Besitz nach einem Failover.

Abbildung einer Failoverclusterinstanz nach einem Failover

Mit einer FCI treten keine Datenverluste auf, aber der zugrunde liegende freigegebene Speicher ist ein Single Point of Failure, da eine Kopie der Daten vorhanden ist. FCIs werden häufig mit anderen Verfügbarkeitsmethoden kombiniert, z. B. Verfügbarkeitsgruppen und Protokollversand, damit redundante Kopien der Datenbank verfügbar sind. Die zusätzlich bereitgestellte Methode sollte einen anderen physischen Speicher als die FCI verwenden. Wird für die FCI ein Failover auf einen anderen Knoten ausgeführt, wird sie auf dem einen Knoten beendet und auf dem anderen Knoten gestartet. Dies ähnelt der Vorgehensweise beim Aus- und Einschalten eines Servers. Eine FCI durchläuft den normalen Wiederherstellungsprozess. Das bedeutet, dass alle Transaktionen ein Rollforward ausgeführt wird, die einen benötigen, und für alle unvollständigen Transaktionen wird ein Rollback ausgeführt. Daher ist eine Datenbank von einem Datenpunkt aus bis zum Zeitpunkt des Fehlers oder des manuellen Failovers konsistent und es kommt nicht zu Datenverlust. Datenbanken sind erst verfügbar, wenn die Wiederherstellung abgeschlossen ist. Die Wiederherstellungszeit hängt also von mehreren Faktoren ab und dauert im Allgemeinen länger als das Ausführen eines Failovers für eine Verfügbarkeitsgruppe. Der Nachteil besteht darin, dass beim Ausführen eines Failovers für eine Verfügbarkeitsgruppe zusätzliche Aufgaben erforderlich sein können, damit die Datenbank verwendet werden kann, z. B. das Aktivieren eines SQL Server-Agent-Auftrags.

FCIs abstrahieren genau wie Verfügbarkeitsgruppen, auf welchem Knoten des zugrunde liegenden Clusters diese gehostet werden. Eine FCI behält immer denselben Namen bei. Anwendungen und Benutzer verbinden sich nie mit den Knoten, sondern der eindeutige Name, der der FCI zugewiesen ist, wird verwendet. Eine FCI kann in einer Verfügbarkeitsgruppe als eine der Instanzen enthalten sein, die entweder ein primäres oder ein sekundäres Replikat hosten.

Die folgende Liste hebt einige Unterschiede von FCIs zwischen Windows Server und Linux hervor:

Unter Windows Server ist FCI ein Teil des Installationsvorgangs. Unter Linux wird eine FCI nach der Installation von SQL Server konfiguriert.
Linux unterstützt nur eine einzige Installation von SQL Server pro Host, sodass alle FCIs eine Standardinstanz darstellen. Windows Server unterstützt bis zu 25 FCIs pro WSFC.
Der allgemeine Name, der von FCIs unter Linux verwendet wird, wird in DNS definiert und sollte mit dem der Ressource identisch sein, die für die FCI erstellt wurde.

Protokollversand

Wenn die Ziele für den Wiederherstellungspunkt und die Wiederherstellungszeit flexibler sind, oder Datenbanken nicht als unternehmenskritisch betrachtet werden, ist der Protokollversand ein weiteres bewährtes Verfügbarkeitsfeature in SQL Server. Basierend auf den nativen Sicherungen von SQL Server generiert der Prozess für den Protokollversand automatisch Transaktionsprotokollsicherungen, kopiert diese auf eine oder mehrere Instanzen, die als betriebsbereit bekannt sind, und wendet sie auf diese Standbyinstanzen an. Der Protokollversand verwendet SQL Server-Agent-Aufträge, um den Sicherungs- und Kopiervorgang sowie den Anwendungsvorgang der Transaktionsprotokollsicherungen zu automatisieren.

Abbildung des Protokollversands

Der größte Vorteil der Verwendung des Protokollversands in gewissem Umfang ist der, dass menschliche Fehler erfasst werden. Die Anwendung der Transaktionsprotokolle kann verzögert werden. Wenn jemand also z.B. ein Update ohne eine WHERE-Klausel ausführt, verfügt die Standbyinstanz dadurch nicht über die Änderung, sodass Sie zu dieser wechseln können, während Sie das primäre System reparieren. Während der Protokollversand einfach zu konfigurieren ist, ist das Wechseln von der primären zur betriebsbereiten Standbyinstanz, auch als Rollenänderung bezeichnet, immer ein manueller Vorgang. Eine Rollenänderung wird über Transact-SQL initiiert, und alle Objekte, die nicht im Transaktionsprotokoll erfasst sind, müssen wie bei Verfügbarkeitsgruppen manuell synchronisiert werden. Der Protokollversand muss pro Datenbank konfiguriert werden, während einzelne Verfügbarkeitsgruppen mehrere Datenbanken enthalten können.

Im Gegensatz zu einer Verfügbarkeitsgruppe oder FCI bietet der Protokollversand keine Abstraktion für eine Rollenänderung, die Anwendungen verarbeiten können müssen. Techniken wie ein DNS-Alias (CNAME) können eingesetzt werden, es gibt jedoch Vor- und Nachteile, z.B. die Zeit, die ein DNS nach dem Wechsel zum Aktualisieren benötigt.

Notfallwiederherstellung

Wenn Ihr primärer Verfügbarkeitsstandort einer Katastrophe wie einem Erdbeben oder einer Überschwemmung ausgesetzt ist, muss das Unternehmen darauf vorbereitet sein, die Systeme an anderer Stelle online schalten zu können. Dieser Abschnitt erläutert, wie die SQL Server-Verfügbarkeitsfunktionen Sie bei der Geschäftskontinuität unterstützen können.