Inside Microsoft.comErste Schritte mit der Datenbankspiegelung

Saleem Hakani

Wenn Ihre Datenbank offline geschaltet wird, haben Sie wahrscheinlich ein großes Problem. Doch wenn Sie SQL Server 2005 mit SP1 verwenden, kann das Feature zur Datenbankspiegelung eine Katastrophe verhindern. Diese neue Technologie mit hoher Verfügbarkeit ermöglicht die Verwendung Ihrer Datenbank im „Hot Standby“-Modus, wenn Ihr Produktionsdatenbankserver

aus irgendeinem Grund nicht zur Verfügung steht. Beim Datenbankspiegelungsfeature werden Transaktionsprotokoll-Datensätze für eine Datenbank vom primären Server auf den sekundären Server übertragen, der als „Hot Standby“ dient. Bei der Datenbankspiegelung werden Datenänderungen im Transaktionsprotokoll aufgezeichnet, bevor Änderungen an den eigentlichen Datenseiten durchgeführt werden, also genau so, wie SQL Server™-Aktualisierungen immer funktionieren. Die Protokolle werden zuerst in den Protokollpuffer der Prinzipaldatenbank im Speicher gestellt und dann auf dem Datenträger beibehalten. Diese Transaktionsprotokolle werden in die Datenbank des Spiegelservers kopiert und werden dort wiedergegeben. Dadurch werden die Datenbankänderungen des Prinzipals in der Spiegeldatenbank dupliziert. Es ist zu beachten, dass nur die Prinzipaldatenbank für Clientverbindungen zugänglich ist. Wenn die Prinzipaldatenbank von Clients angeforderte Änderungen empfängt, sendet der Prinzipal diese aktiven Änderungen an den Spiegelserver. Der Spiegelserver trifft keine dieser Entscheidungen. Wenn die Datenbankspiegelung aktiviert ist und die Prinzipaldatenbank versagt, steht die gespiegelte Datenbank zur Verfügung.

Funktionsweise der Datenbankspiegelung

Die Datenbankenspiegelung funktioniert bei beliebiger Standardhardware, die SQL Server 2005 unterstützt, und sorgt dafür, dass bei einem Datenbankfehler keine Daten verloren gehen. Die Spiegeldatenbank wird immer mit der aktuellen Transaktion aktualisiert, die auf dem primären Datenbankserver verarbeitet wird. Abbildung 1 stellt den Datenfluss dar.

Wenn Ihr Hauptserver versagt, können Sie sichergehen, dass der Spiegelserver über eine genaue Kopie der letzten übernommenen Transaktion der Prinzipaldatenbank zu einem bestimmten Zeitpunkt verfügt. Der Spiegel ist also immer bereit, die Rolle des Prinzipalservers zu übernehmen.

Abbildung 1** Datenreplikation zum Spiegel **(Klicken Sie zum Vergrößern auf das Bild)

In der Datenbankspiegelungstopologie brauchen Sie einen dritten, als Zeuge bezeichneten Server, wenn Sie automatisches Failover vom Prinzipal- auf den Spiegelserver und umgekehrt ermöglichen wollen. Bei einem Zeugenserver kann es sich um einen beliebigen Computer handeln, der SQL Server 2005 unterstützen kann.

Betriebsmodi

Die von Ihnen verwendete Datenbankspiegelungstopologie hängt von der von Ihnen gewählten Transaktionssicherheit und den Betriebsmodi ab. Die von der Datenbankspiegelung unterstützten Betriebsmodi umfassen hohe Sicherheit (mit oder ohne automatisches Failover) und hohe Leistung.

Hohe Sicherheit (mit automatischem Failover). Dieser Modus unterstützt maximale Datenbankverfügbarkeit mit synchroner Datenübertragung und automatischem Failover zur Spiegeldatenbank. Dieser Betriebsmodus wird am besten dann verwendet, wenn Sie über eine schnelle und sehr zuverlässige Kommunikation zwischen dem Prinzipal- und dem Spiegelserver verfügen und automatisches Failover für eine einzelne Datenbank brauchen. Bei diesem Schema wartet die Prinzipaldatenbank mit einer Transaktion, bis sie eine Nachricht vom Spiegelserver empfängt, dass der Spiegelserver das Protokoll der Transaktion auf dem Datenträger abgesichert hat.

Hohe Sicherheit (ohne automatisches Failover). Dieser Modus unterstützt maximale Datenbankverfügbarkeit mit synchroner Datenübertragung, aber ohne automatisches Failover zur Spiegeldatenbank. Wenn die Spiegelserverinstanz in diesem Modus nicht mehr verfügbar ist, funktioniert die Prinzipalserverinstanz weiter, kann jedoch die Daten nicht spiegeln. Wenn der Prinzipalserver ausfällt, wird die Datenbankspiegelung angehalten, aber Sie können manuell ein Failover des Diensts durchführen.

Hohe Leistung. In diesem Betriebsmodus erfolgt die Übertragung der Daten asynchron. Der Prinzipalserver wartet nicht auf eine Bestätigung des Spiegelservers wie bei den beiden vorangehenden Modi. Der Spiegelserver versucht, mit dem Prinzipalserver mitzuhalten, doch es wir zu keinem Zeitpunkt garantiert, dass die neuesten Transaktionen vom Prinzipal im Transaktionsprotokoll des Spiegelservers abgesichert werden. Wenn der Prinzipalserver ausfällt, wird die Datenbankspiegelung angehalten, aber Sie können manuell ein Failover des Diensts durchführen.

Schaffen der Grundlagen

Das Einrichten der Datenbankspiegelung ist ein einfacher Prozess, wenn Sie mit den empfohlenen Vorgehensweisen eine starke Grundlage schaffen:

Server Edition Überprüfen Sie, dass dieselbe Edition von SQL Server 2005 sowohl auf dem Prinzipal- als auch auf dem Spiegelserver ausgeführt wird. Sie können die Standard oder die Enterprise Edition verwenden.

Verfügbarkeit des Zeugenservers Wenn Sie die Verwendung von hoher Sicherheit mit automatischem Failover planen, sollten Sie sicherstellen, dass der Zeugenserver zur Verfügung steht und eine beliebige Edition von SQL Server 2005 installiert ist. Der Zeugenserver kann auf jedem beliebigen zuverlässigen Computersystem ausgeführt werden, das SQL Server 2005 unterstützen kann.

Spiegelbild Stellen Sie sicher, dass die Spiegelserverinstanz über die identischen Aufträge, Anmeldungen, SSIS-Pakete (SQL Server Integration Service), Datenträgerpartitionen, Dateispeicherorte und Serverkonfiguration wie die Prinzipalserverinstanz verfügt. Wenn der Spiegelserver genau wie der Prinzipalserver konfiguriert wird, kann der Spiegelserver genau wie der Prinzipalserver funktionieren.

Vollständige Wiederherstellung Es ist wichtig, dass alle Datenbanken, die an der Datenbankspiegelung beteiligt sind, auf das vollständige Wiederherstellungsmodell eingestellt sind.

Master und TempDB Überprüfen Sie, dass alle Serverinstanzen in einer Spiegelungstopologie dieselbe Master- und TempDB-Sortierung und Codeseite verwenden. Unterschiedliche Sortierung und Codeseiten können während der Einrichtung der Datenbankspiegelung Probleme verursachen.

Sicherung Wenn die zu spiegelnde Datenbank groß ist, müssen Sie zuerst eine komplette Sicherung der Datenbank durchführen und sie dann auf der Spiegelserverinstanz mithilfe der NORECOVERY-Option wiederherstellen.

Vorausplanung Legen Sie alle Servernamen, Portnummern, Sicherheitskonten und Speicherorte fest, wo Datenbanken gespeichert werden, und dokumentieren Sie diese. In der Randleiste „Best Practices für die Datenbankspiegelung“ finden Sie eine Prüfliste.

Nach Durchführung dieser grundlegenden Arbeiten können Sie die Einrichtung der Datenbankspiegelung in Ihrer Umgebung in Angriff nehmen.

Best Practices für die Datenbankspiegelung

1. Verwenden Sie Partnerserver, deren CPU, Arbeitsspeicher, Speicher und Netzwerkkapazität identisch sind.
2. Stellen Sie sicher, dass beide Partner dieselbe SQL Server- und Betriebssystemedition sowie dieselben Service Packs und Updates haben.
3. Installieren Sie SQL Server auf der Prinzipal- und der Spiegelserverinstanz in einem identischen Verzeichnis und einer identischen Laufwerkstruktur.
4. Wenn Leistung wichtig ist, könnten Sie eine dedizierte Netzwerkkarte zum Trennen der Last in Betracht ziehen.
5. Wie bei den Serverpartnern stellen Sie sicher, dass sowohl die Prinzipal- als auch die Spiegelserverinstanz in Bezug auf CPU, Arbeitsspeicher, Speicher und Netzwerkkapazität identisch sind. Durch Sicherstellen derselben Verzeichnisstruktur, desselben Datenträger-Partitionierungsschemas und derselben SQL Server-Konfiguration bei beiden Servern wird dafür gesorgt, dass während oder nach dem Failover am Spiegelpartner keine Änderungen vorgenommen werden müssen.
6. Stellen Sie sicher, dass sich all Ihre Anwendungen verbinden lassen, dass sie alle notwendigen Aktionen ausführen und dass alle aktiven SQL Server-Anmeldungen (und ihre Berechtigungen) der Prinzipalserverinstanz auch auf der Spiegelserverinstanz vorhanden sind. Zu diesem Zweck können Sie den Task „Anmeldungen übertragen“ für SQL Server 2005 Integration Services verwenden.
7. Kopieren Sie SQL Server Agent-Aufträge, Warnungen, SSIS-Pakete, Supportdatenbanken, verknüpfte Serverdefinitionen, Sicherungsgeräte, Wartungspläne, Datenbank-E-Mail-Profile und so weiter vom Prinzipalserver zum Spiegelserver.
8. Legen Sie ein Verfahren fest, mithilfe dessen Sie jedes Mal, wenn Sie Änderungen auf dem Prinzipalserver vornehmen (wie z. B. Änderungen an Hardware, Software, SQL Server-Einstellungen oder Datenbankenobjekten), diese Änderungen automatisch wiederholen oder replizieren und sie auf die Spiegelserverinstanz übertragen.
9. Führen Sie mehrere Testfailovers durch, bevor Sie das System bereitstellen.

Setup

Nun geht es um das Setup der Datenbankspiegelung mithilfe des Betriebsmodus für hohe Sicherheit mit automatischem Failover. (Wie bereits erwähnt, bedeutet dies, dass eine Zeugenserverinstanz erforderlich ist.) Für mein Beispiel hier verwende ich die in Abbildung 2 dargestellten Server- und Datenbanknamen. Die Abbildung gibt auch die Rolle der einzelnen Server an.

Die Konfiguration kann sich auf die Leistung auswirken, da das ausstehende Transaktionsprotokoll vom Prinzipalserver zum Spiegelserver kopiert wird. Aus diesem Grund könnte es angebracht sein, die anfängliche Konfiguration der Datenbankspiegelung außerhalb der Hauptgeschäftszeiten durchzuführen.

Das Einrichten des Spiegels besteht aus drei Schritten: dem Erstellen von Endpunkten auf den teilnehmenden Servern, dem Durchführen der Sicherung und Wiederherstellen Ihrer Prinzipaldatenbank und dem Aktivieren von Spiegelungssitzungen auf allen teilnehmenden Servern.

Vor dem Einrichten einer Datenbankspiegelungssitzung müssen Sie den Kommunikationsmechanismus zwischen allen an der Datenbankspiegelung teilnehmenden Servern einrichten. Dazu erstellen Sie Endpunkte auf allen Servern, indem Sie diese Anweisung auf ServerA und ServerB ausführen:

Create Endpoint Mirroring_Endpoint
State= Started as TCP (Listener_Port=5001)
For Database_Mirroring (Role=Partner);

Für ServerC (der als Zeuge dient) ändern Sie (Role=Partner) in (Role=Witness), bevor Sie die Anweisung ausführen. Dies steuert den TCP-Port, den die jeweilige Instanz überwacht.

Beim nächsten Schritt sollten Sie eine vollständige Datenbanksicherung gefolgt von einer Protokollsicherung der DBM_Demo-Datenbank vom Prinzipalserver durchführen und diese dann auf der Spiegelserverinstanz mit der NORECOVERY-Option wiederherstellen. (Die Verwendung von NORECOVERY stellt sicher, dass sich die Spiegeldatenbank im Wiederherstellungsstatus befindet, sodass die Transaktionsprotokolle angewendet werden können.)

Dies ist die T-SQL-Anweisung zur Durchführung einer vollständigen Datenbanksicherung der DBM_Demo-Datenbank von ServerA (der Prinzipalserverinstanz):

Backup Database DBM_Demo to DISK='E:\MSSQL\Bak\DBM_Demo_FULL.bak';

Wenn nach Durchführen der vollständigen Datenbanksicherung Änderungen an der Datenbank vorgenommen werden, müssen Sie möglicherweise eine Protokollsicherung der Datenbank durchführen. Andernfalls ist dies nicht erforderlich.

Falls erforderlich, können Sie folgende T-SQL-Anweisung zur Durchführung einer Protokollsicherung der DBM_Demo-Datenbank von ServerA verwenden:

Backup Log DBM_Demo to Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak';

Nach Durchführung aller Sicherungen verschieben Sie die Sicherungsdateien zu ServerB oder zu einem freigegebenen Speicherort, damit Sie diese Sicherungen auf ServerB wiederherstellen können. Anschließend sollten Sie zusätzlich alle Transaktionsprotokollsicherungen wiederherstellen, die Sie seit der letzten vollständigen Datenbanksicherung von ServerA durchgeführt haben.

Sie können folgende T-SQL-Anweisung zur Wiederherstellung der vollständigen Sicherungen und Protokollsicherungen auf ServerB mithilfe der NORECOVERY-Option verwenden:

--Restore full database backup on the mirror --server instance
Restore Database DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_FULL.bak' with NORECOVERY;

Schließlich verwenden Sie folgende T-SQL-Anweisung zur Wiederherstellung der Protokollsicherung auf dem Spiegelserver mithilfe der NORECOVERY-Option:

Restore Log DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak' with NORECOVERY;

Nach der Wiederherstellung aller Sicherungen können Sie den letzten Schritt durchführen – die Aktivierung Ihrer Datenbankspiegelungssitzung auf allen teilnehmenden Servern.

Zum Einrichten einer Datenbankspiegelungssitzung ist eine Servernetzwerkadresse für jede Serverinstanz erforderlich. Diese Adresse muss die Instanz durch Bereitstellen einer Systemadresse und der Portnummer identifizieren, die von der Instanz überwacht wird. Die Syntax für eine Servernetzwerkadresse sieht folgendermaßen aus:

TCP://<System-address>:<port>

<Systemadresse>: ist ein vollqualifizierter Domänenname oder eine IP-Adresse. Sie erhalten diese Informationen durch Ausführen von IPCONFIG auf dem lokalen Computer von einer Eingabeaufforderung aus.

Sie haben den <Port> eingerichtet, als Sie die Endpunkte erstellt haben.

Sie können die Datenbankspiegelungssitzung auf ServerB wie folgt starten:

Alter Database DBM_Demo
Set Partner= 'TCP://ServerA.com:5001';

Dann führen Sie folgende T-SQL-Anweisung aus, um die Sitzung auf ServerA zu starten:

Alter Database DBM_Demo
Set Partner='TCP://ServerB.com:5001';

Als Nächstes aktivieren Sie die Spiegelungssitzung auf ServerC (dem Zeugenserver) folgendermaßen:

Alter Database DBM_Demo
Set Witness='TCP://ServerC.com:5001';

Die Datenbankspiegelung kann jetzt in Ihrer Umgebung ausgeführt werden. Datenbankobjekte, die in der DBM_Demo-Datenbank hinzugefügt oder geändert wurden, werden in die ServerB-Kopie übertragen. Wenn jedoch die Datenbank von ServerA nicht verfügbar ist, kann ein Failover stattfinden, das die Rolle der gespiegelten Datenbank in die Prinzipalrolle ändert.

Mit der Datenbankspiegelung steht ihnen immer ein „Hot Standby“ zur Verfügung, falls Ihre Produktionsdatenbank einmal ausfallen sollte.

Saleem Hakani ist Senior Database Engineer bei Microsoft und verfügt über mehr als 14 Jahre Erfahrung mit Datenbanksystemen. Er hat die Microsoft SQL Community gegründet, die er jetzt leitet, und ist verantwortlich für die Bereitstellung von SQL Server-Standards und die Automatisierung in der gesamten Windows Live-Organisation. Saleem hat MCTS-, MCDBA- und MCSA-Zertifizierungen. Sie erreichen ihn unter Saleem@sqlcommunity.net.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.