Microsoft SQL Server - Database Mirroring (Funktion und Konfiguration)

Database Mirroring (Datenbankspiegelung) ist eine Technologie, die von Microsoft eingeführt wurde, um bei dem Ausfall einer SQL Server Instanz oder einer SQL Server Datenbank in sehr kurzer Zeit und möglichst ohne Datenverlust eine Ersatz-Datenbank bereit zu stellen.

Wir möchten die Technik, die hinter Database Mirroring steckt und wie Sie diese Datenbank-Technologie in Ihrer SQL Server Instanz einrichten können, etwas genauer beschreiben.

Was steckt hinter dem Begriff Database Mirroring ?

In allen SQL Server-Datenbanken werden Änderungen in Transaktionsprotokollen festgehalten, bevor diese tatsächlich an den Daten vorgenommen werden. Die Transaktionsprotokolleinträge werden im Protokollpuffer der Datenbank im Speicher festgehalten und dann so schnell wie möglich auf die Festplatte geschrieben.
Beim Database Mirroring sendet eine SQL Server Instanz fortlaufend Transaktionseinträge an eine zweite SQL Server Instanz. Die sendende SQL Server Instanz ist der Prinzipal-Server und die empfangende SQL Server Instanz der Mirror-Server.
Wenn der Mirror-Server die Transaktionseinträge erhält, speichert er diese zuerst im Datenbankprotokollpuffer und schreibt sie dann so schnell wie möglich auf die Festplatte. So werden die Datenbankänderungen in der Prinzipal-Datenbank in der Mirror-Datenbank dupliziert.
Prinzipal-Server und Mirror-Server müssen eigenständige SQL Server - Instanzen sein und betrachten sich gegenseitig als Partner beim Database Mirroring. Ein Partnerserver kann für eine Database Mirroring-Session als Prinzipal-Server und als Mirror-Server für eine andere Database Mirroring-Session arbeiten.
Bei dem Ausfall des Prinizipal-Server kann ein automatischer Failover auf den Mirror-Server durchgeführt werden. Eine Clientanwendung, die den SQL Server Native Client für die Datenbank-Verbindung benutzt, kann so konfiguriert werden, dass diese bei einem Failover automatisch mit dem Mirror-Server weiter arbeitet.

Welche Rolle spielt der Witness-Server ?

Zusätzlich zu dem Prinzipal und Mirror Server kann es einen optionalen dritten Server geben: den Witness-Server (Zeugen-Server). Seine Aufgabe ist es, einen automatischen Failover zu ermöglichen.

Ein automatisches Failover bedeutet, dass bei einem Ausfall des Prinzipal-Servers der Prinzipal- und Mirror Server automatisch die Rollen tauschen. Dies kann nur mit dem Einsatz eines Witness-Servers erfolgen und beinhaltet folgende Schritte:

  • Der Prinzipal Server fällt aus und/oder kann von dem Mirror Server nicht mehr erreicht werden.
  • Der Mirror-Server fragt beim Witness Server an, ob dieser den Prinzipal Server auch nicht mehr erreichen kann.
  • Wenn der Witness-Server dem Mirror-Server bestätigt, dass dieser den Prinzipal Server auch nicht erreichen kann übernimmt der Mirror Server automatisch die Rolle vom Prinzipal-Server.

Für den Witness-Server müssen Sie keine zusätzliche SQL Server Lizenz erwerben da für diese Rolle auch eine SQL Server Express - Instanz verwendet werden kann.

Welche Voraussetzungen müssen beim Einsatz von Database Mirroring erfüllt werden ?

Folgende Punkte sollten beim Einsatz von Database Mirroring berücksichtigt werden:

  • Es werden 2 SQL Server Instanzen mit derselben SQL Server Version benötigt.
  • Die Prinzipal-Datenbank muss sich im Wiederherstellungsmodus FULL befinden.
  • Die Mirror-Datenbank muss über die Wiederherstellung eines Backups der Prinzipal-Datenbank mit NORECOVERY erzeugt werden. Anschliessend erfolgt die Wiederherstellung in der Reihenfolge der Sicherungen des Transaktionsprotokolls des Prinzipal-Servers.
  • Die Mirror-Datenbank muss den gleichen Namen haben wie die Prinzipal-Datenbank
  • Da sich eine Mirror-Datenbank in einem wiederhergestellten Zustand befindet, kann nicht direkt auf sie zugegriffen werden. Sie können Datenbanksnapshots auf dem Mirror erstellen, um die Datenbank indirekt zu lesen.

Welche Ausfallsicherheit bietet Database Mirrorring ?

Es gibt drei mögliche Betriebsmodi beim Database Mirroring, die die Ausfallsicherheit und möglichen Datenverluste mit beeinflussen:

  1. Mit Transaktionssicherheit (Synchron) und automatischen Failover– High Protection mode
    Wenn Transaktionssicherheit gewährleistet werden soll, heißt dies, dass der Mirror-Server Transaktionen vom Prinzipal erhält und der Prinzipal-Server wartet bis der Mirror-Server eine Bestätigung zur Übernahme der Transaktionen zurückgesendet hat, bevor die nächsten Transaktionen erzeugt werden. In diesem Fall sind die Mirror-Datenbank und die Prinzipal-Datenbank zu jedem Zeitpunkt synchron.

    Der Betriebsmodus high-protection-mode bietet die bestmögliche Datenbankverfügbarkeit und eine hohe Ausfall-Sicherheit mit einem automatischen Failover auf die Mirror-Datenbank. Er erfordert, dass Database-Mirroring mit Transaktionssicherheit konfiguriert und ein Witness-Server eingerichtet wird.

    Dieser Modus wird am besten dann genutzt, wenn Sie über schnelle und zuverlässige Kommunikationspfade zwischen den Servern verfügen und einen automatischen Failover für eine einzelne Datenbank benötigen. Mit der Einstellung für synchrone Transaktionen muss der Prinzipal auf die Antworten des Mirrors warten. Daher ist die Leistung des Prinzipal-Servers von der des Mirror-Servers abhängig.

    Der Modus high-protection-mode überwacht sich selbst. Wenn die Prinzipal-Datenbank plötzlich nicht mehr zur Verfügung steht oder der Server ausfällt, dann bilden Mirror und Witness ein Quorum und der Mirror-Server führt ein automatisches Failover durch. An diesem Punkt ändert der Mirror-Server seine Rolle und wird zum neuen Prinzipal. Der Mirror-Server ist schnell verfügbar, da er alle Transaktionen des Prinzipals bereits wiederholt hat.

    Wenn der Mirror Server ausfällt, bleiben der Prinzipal und Witness Server weiter aktiv. Voraussetzung dafür ist eine Verbindung zwischen dem Prinzipal Server und dem Witness Server. Ist dies nicht der Fall versetzt der Prinzipal Server seine Datenbank so lange in den Offline Modus bis er entweder mit dem Mirror Server oder dem Witness Server eine Verbindung herstellen kann oder das Database Mirroring deaktiviert wird.

  2. Mit Transaktionssicherheit (synchron) ohne automatischen Failover– High Security mode
    Der High Security Mode wird wie der High Protection Mode, aber ohne eine Witness-Instanz ausgeführt und ermöglicht somit kein automatisches Failover.

    Wenn die Partner verbunden sind, wird das manuelle Failover unterstützt. Wenn die Mirror-Instanz ausfällt, bleibt die Prinzipal-Instanz in Betrieb und wird ungeschützt ausgeführt (d. h. ohne die Spiegelung der Daten). Wenn der Prinzipal-Server ausfällt, kann der Dienst auf dem Mirror-Server nur dann erzwungen werden, wenn keine Verbindung mehr zum Prinzipal Server besteht.

  3. Ohne Transaktionssicherheit (Asynchron)
    Wenn Transaktionssicherheit nicht gewährleistet werden muss, heißt dies, dass der Mirror-Server zwar laufend Transaktionen vom Prinzipal erhält, aber der Prinzipal nicht wartet bis der Mirror eine Bestätigung zur Übernahme der Transaktionen zurückgesendet hat bevor die nächsten Transaktionen erzeugt werden. In diesem Fall sind die Mirror-Datenbank und die Prinzipal-Datenbank nicht zu jedem Zeitpunkt synchron.

    In diesem Betriebs-Modus ist kein automatischer Failover möglich und kann auch kein manueller Failover aktiviert werden. Der einzige zugelassene Failover-Typ ist der erzwungene Failover.

    Der erzwungene Failover ist nur möglich, wenn keine Verbindung mehr zum Prinzipal Server besteht und sorgt für eine sofortige Wiederherstellung der gespiegelten Datenbank. Dies kann zu einem potenziellen Datenverlust führen (wenn Transaktionen vom Prinzipal-Server noch nicht vom Mirror-Server empfangen wurden). Dieser Modus ist am besten für Transaktionen über lange Distanzen (zum Beispiel bei Remotestandorten) oder zur Überwachung sehr aktiver Datenbanken geeignet.

    Dieses Szenario wird auch high-Performance-Scenario genannt, da es schnelle Schreib-Operationen auf dem Prinzipal-Server bei geringerer Ausfall-Sicherheit bedeutet.

    Es sollte in diesem Szenario kein Witness Server eingerichtet werden, da dieser aus den folgenden Gründen mehr Probleme als Nutzen bringt:

    A) Wenn der Mirror Server ausfällt, muss der Prinzipal Server noch mit dem Witness Server verbunden sein. Ist dies nicht der Fall versetzt der Prinzipal Server seine Datenbank so lange in den Offline Modus bis er entweder mit dem Mirror Server oder dem Witness Server eine Verbindung herstellen kann.

    B) Wenn der Prinzipal Server ausfällt, kann ein erzwungener Failover nur ausgeführt werden, wenn der Mirror Server eine Verbindung zum Witness Server besitzt.

    Hinweis:
    Der asynchrone Modus steht nur in der Enterprise und Developer Edition zur Verfügung und kann über das SQL Server Management Studio oder mit dem Alter Database-Befehl „Alter Database Set SAFETY OFF;“ auf der SQL Server Instanz der Prinzipal-Datenbank gesetzt werden.

Was passiert beim "Rollentausch" auf dem Prinzipal- und Mirror-Server ?

Die Rollen-Übernahme des Mirror-Servers zum Prinzipal-Server kann auf verschiedenen Wegen erfolgen:

  1. Automatisches Failover
    Die Möglichkeit der automatischen Rollen-Übernahme im Falle eines Ausfalls des Prinzipal-Servers besteht nur, wenn für die Spiegelung ein Witness-Server („Zeuge“) eingesetzt wird und die Datenbank Spiegelung mit Transaktionssicherheit ausgeführt wird.
    Der Mirror- und der Witness-Server kontaktieren parallel den Prinzipal-Server um festzustellen, ob der physikalische Server, die Server-Instanz und die Datenbank des Prinzipals erreichbar sind. Wenn der Prinzipal-Server vom Mirror-Server nicht mehr kontaktiert werden kann, vergewissert sich dieser beim Witness-Server, dass auch dieser den Prinzipal-Server nicht mehr erreichen kann.
    Wenn dies der Fall ist, wird der Mirror-Server zum Prinzipal-Server und informiert den Witness-Server über den Rollen-Tausch.
    Sobald der „alte“ Prinzipal-Server wieder online ist, wird dieser vom Witness-Server über den Rollentausch informiert, übernimmt die Rolle des Mirror-Servers und erhält vom neuen Prinzipal-Server die noch fehlenden Transaktions-Logs.
    DB Mirroring - automatisches Failover Szenario
  2. Manuelles Failover
    Ein manuelles Failover wird eingesetzt, wenn der Prinzipal-Server und der Mirror-Server (z. Bsp. aus Performancegründen oder zur Durchführung eines SQL Server Updates) ihre Rollen tauschen sollen ohne dass ein physikalisches Problem die Ursache ist. Unter der Voraussetzung, daß die Datenbank-Spiegelung mit Transaktionssicherheit ausgeführt wird, kann dieser Prozeß ohne Datenverlust durchgeführt werden.
    DB Mirroring - manuelles Failover Szenario
  3. Erzwungendes Failover
    Diese Art des Rollen-Tausches wird nur eingesetzt, wenn der Prinzipal-Server ausfällt und nicht mehr vom Mirror Server erreicht werden kann und der asynchrone Betriebsmodi ohne den Einsatz eines Witness-Servers gewählt wurde.
    In diesem Fall kann kein automatischer Failover oder manuelles Failover erfolgen und können durch Verlust von Transaktions-Logs auch Daten verloren gehen.
    DB Mirroring - erzwungendes Failover Szenario

Der Rollentausch zwischen Prinzipal- und Mirror Datenbank kann beim Database Mirroring in sehr kurzer Zeit und beim automatischen Failover ohne den Verlust von Daten erfolgen und benötigt keine properitäre Hardware.

Was passiert, wenn der Witness Server nicht mehr erreichbar ist ?

Der Witness- Server wird primär für die Möglichkeit eines automatischen Failover benötigt, wenn der Prinzipal-Server ausfällt.

Wenn der Witness-Server ausfällt, können folgende Szenarien entstehen:

A) Wenn nur der Witness Server ausfällt und der Prinzipal – und Mirror Server noch miteinander verbunden sind, wird die Datenbank-Spiegelung ohne automatisches Failover weiter ausgeführt.

B) Wenn der Mirror Server ausfällt, muss der Prinzipal Server noch mit dem Witness Server verbunden sein. Fällt auch der Witness Server aus versetzt der Prinzipal Server seine Datenbank so lange in den Offline Modus bis er entweder mit dem Mirror Server oder dem Witness Server eine Verbindung herstellen kann oder die Datenbank-Spiegelung deaktiviert wird.

C) Wenn der Prinzipal Server ausfällt, kann ein erzwungener Failover nur ausgeführt werden, wenn der Mirror Server eine Verbindung zum Witness Server besitzt. Fallen Prinzipal- und Witness Server gleichzeitig aus kann ebenfalls kein automatisches Failover erfolgen und ist keine der Datenbanken mehr erreichbar bis mindestens 2 Server-Instanzen wieder aktiv sind.

Wie können Client-Applikation auf den "Rollen"-Tausch reagieren ?

Auf den Ausfall eines Prinzipal-Servers und Rollen-Tausch mit dem Mirror Server können Client-Applikationen, die auf eine Datenbank des Prinzipal-Servers zugreifen, unterschiedlich reagieren. Die möglichen Reaktionen hängen von dem Datenbank-Provider ab, der für die Verbindung zur SQL Server Datenbank verwendet wird:

  1. Client Applikation verwendet SQL Server Native Client oder ADO.Net als Datenbank-Provider für den Zugriff auf die Prinzipal-Datenbank
    Mit dem Einsatz des SQL Server Native Client oder ADO.Net als Datenbank-Provider können Client-Applikationen so eingerichtet werden, dass diese im Failover-Fall ihre Verbindungs-Informationen zum neuen Prinzipal-Server automatisch umlenken. Dazu wird in dem Connectionstring zur SQL Server Datenbank der Prinzipal- und Mirror-Server angegeben.
  2. Client Applikation verbindet sich via ODBC Datenquelle mit der Prinzipal Datenbank
    Beim Einsatz einer ODBC-Datenquelle für die Verbindung zur Prinzipal-Datenbank muß im Failover-Fall der Verbindungspfad zum neuen Prinzipal-Server manuell in der ODBC-Datenquelle angepasst werden.
  3. Client Applikation verwendet einen Connectionstring mit Angabe des Server- und Datenbanknamen für den Zugriff auf die Prinzipal-Datenbank
    In diesem Fall muß bei einem Failover innerhalb der Applikation der Name des neuen Prinzipal-Servers in dem Connectionstring eingetragen werden.

Können Client-Applikationen auf die Mirror-Datenbank zugreifen ?

Die Mirror-Datenbank ist schreib- und lese-geschützt. Das bedeutet, daß von Client-Applikationen nicht auf die Mirror-Datenbank zugegriffen werden kann.

Die Möglichkeit, dass Client-Applikationen auf die Daten der Mirror-Datenbank zugreifen, besteht nur durch den Einsatz eines Datenbank-Snapshots oder der Replikation auf die Mirror-Datenbank. Dieses Szenario erfordert mindestens eine Lizenz der SQL Server Enterprise-Edition auf dem Mirror-Server.

Was sind die Unterschiede zum Logfile-Shipping ?

Ein weiterer Ansatz, um nach einem Server-Ausfall in sehr kurzer Zeit eine "Ersatz-" Datenbank zu erzeugen ist die Logfile Shipping Methode. Mit dieser Methode werden von einer primären Datenbank Transaktionsprotokolle an eine oder mehrere sekundäre Datenbanken versendet und dort zur laufenden Wiederherstellung der sekundären Datenbanken verwendet.
Im Gegensatz zum Database Mirroring wird beim Logfile Shipping eine Netzwerkfreigabe benötigt, auf der die Transaktionsprotokolle vom primären Server kopiert werden. Diese Transaktionsprotokolle werden von den sekundären Instanzen auf ein lokales Laufwerk kopiert und für ein Restore der sekundären Datenbank verwendet. Für die Kopier- und Restore-Aktionen auf dem primären und sekundären Server wird der SQL Server Agent der primären und sekundären Instanzen verwendet.
Der Vorteil beim Logifle Shipping besteht darin, daß mehrere Stand-By-Datenbanken erzeugt werden können, auf die Applikationen lesend zugreifen können. Ein Nachteil im Gegensatz zum Database Mirroring ist die fehlende Möglichkeit eines automatischen Failovers und ein höheres Datenverlust-Risiko bei einem Server-Ausfall.

Welche Edition wird für das Database Mirroring benötigt ?

Für die Rolle des Prinzipal-Server oder Mirror-Server wird mindestens die Standard Edition des SQL Server benötigt.
Für die Rolle des Witness Server kann auch eine SQL Server Express Edition verwendet werden.

Hinweis:
Microsoft unterstützt Database Mirroring nur unter SQL Server 2005 Service Pack 1 (SP1) und höher.
Wenn Sie nicht SQL Server 2005 mit SP1 oder höher ausführen, sollten Sie Database Mirroring nicht in Produktivumgebungen einsetzen.

Wie richte ich Database Mirroring auf meiner SQL-Server Instanz ein ?

Vor dem Einsatz von Database Mirroring sollten Sie prüfen ob Ihre vorhandene SQL Server- Umgebung bereits die notwendigen Voraussetzungen erfüllt.

Voraussetzungen für den Einsatz von Database Mirroring

Für den Einsatz eines Prinzipal- und Mirror – Servers sind die folgenden Systemvoraussetzungen notwendig:

  • Anzahl Server:
    2 separate SQL Server Instanzen (Version 2005 SP1 oder höher)
  • Unterstütze Betriebssysteme:
    Ab Windows 2000 Advanced Server SP4
    Windows 2003 Server SP1 (oder höher)
  • Hardware (Mindestanforderung):
    Pentium III-kompatibler Prozessor 1 Ghz oder höher
    1 GB RAM
  • SQL Server Lizenzen:
    1 SQL Server Standard Edition oder höher für den Prinzipal
    Für den Mirror wird nur dann eine Lizenz benötigt, wenn die SQL Server Instanz auf diesem Server nicht nur für das Database - Mirroring eingesetzt werden soll.
    Beachten Sie, dass für den Einsatz von Database Mirroring die gleiche SQL Server-Version auf dem Prinzipal und auf dem Mirror benötigt wird.
    Wenn ein Witness-Server eingesetzt werden soll kann für diese Witness-Server Instanz eine andere Edition (z. Bsp. SQL Server Express) verwendet werden.
  • Netzwerk-Anforderungen:
    Für den Einsatz von Database Mirroring sollte eine stabile Netzwerkverbindung zwischen dem Prinzipal- und dem Mirror-Server zur Verfügung stehen.
    Um den Witness-Server optimal zu nutzen sollte dieser auf einer anderen Netzwerkverbindung mit dem Prinzipal- und dem Mirror-Server in Verbindung stehen.

Kurzanleitung zur Konfiguration von Database Mirroring

  1. Auf dem Prinzipal-Server und dem Mirror-Server muß die gleiche SQL Server Edition installiert und müssen die Netzwerkprotokolle aktiviert sein.
  2. Die Server, die an der Mirror-Session beteiligt sind, müssen einander vertrauen. Bei einer lokalen Domäne bedeutet dies, dass jeder SQL Server über Berechtigungen verfügen muss, sich mit den anderen Servern zu verbinden.
    Verwenden Sie deshalb als Dienstkonto für beide SQL Server -Instanzen das gleiche Domänen-Konto, welches Mitglied der Gruppe der lokalen Administratoren auf beiden Servern ist.
  3. Erstellen Sie eine Sicherung der Prinzipal-Datenbank (Datenbank und Transaktionsprotokolle)
    Hinweis:
    Die Prinzipaldatenbank muss folgende Einstellungen besitzen, bevor Sie die Sicherung erstellen:
    Wiederherstellungsmodus: FULL (Vollständig)
    AutomaticClose: False
  4. Übertragen Sie (z. Bsp. Mithilfe der SQL Server Integrationservices) alle Server-Logins, die für die Prinzipal-Datenbank verwendet werden, auf die Mirror-Instanz.
  5. Stellen Sie die Sicherung der Prinzipal-Datenbank auf dem vorgesehenen Mirror-Server mit der Wiederherstellungs-Option „ohne Wiederherstellung“ her.
  6. Konfigurieren Sie jetzt das Database Mirroring auf dem Prinzipal-Server, indem Sie mit dem SQL Server Management Studio in den Eigenschaften der Prinzipal-Datenbank den Menu-Eintrag "Mirroring" („Spiegelung“) auswählen und auf den Button "Configure Security" („Sicherheit konfigurieren“) klicken:

    Anschließend öffnet sich der Assistent zum Einrichten des Database Mirroring:

    Im nächsten Schritt geben Sie an, ob Sie die Mirror-Session mit einer Zeugeninstanz einrichten möchten.
    Wenn Sie einen automatischen Failover beim Ausfall der Prinzipal-Datenbank benötigen, müssen Sie an dieser Stelle die Option „Ja“ auswählen, um die Witness-Instanz angeben zu können.


    Im nächsten Fenster geben Sie an, dass die Sicherheitskonfigurationen auf der Prinzipal-Instanz und der Witness-Instanz gespeichert werden und gelangen mit Klick auf „Weiter“ zum Dialog, um den Port für die Prinzipal-Instanz anzupassen:

    Standardmäßig wird für die Kommunikation zwischen den Instanzen der Port 5022 verwendet. Passen Sie diesen an, wenn bereits andere Applikationen diesen Port für die Kommunikation verwenden.
    Mit Klick auf „Weiter“ können Sie die SQL Server-Instanzen auswählen, die als Mirror- und als Witness-Instanz verwendet werden sollen.

    Passen Sie für diese beiden Instanzen den Port für die Kommunikation nur dann an, wenn dieser bereits von anderen Applikationen für die Kommunikation verwendet wird.

    Anschließend können Sie die Dienstkonten der Instanzen angeben, falls für die Instanzen unterschiedliche Dienstkonten verwendet werden. Lassen Sie die Eingabefelder leer, wenn für die Prinzipal-, Mirror- und Witness-Instanz dasselbe Dienstkonto verwendet wird.


    Mit Klick auf „Weiter“ erhalten Sie eine Zusammenfassung der vorgenommenen Konfigurationseinstellungen.

    Mit Bestätigung der Einstellungen werden die Mirroring-Endpunkte erzeugt.

    Wenn dieser Prozess erfolgreich abgeschlossen wurde sehen die das folgende Dialog-Fenster und können anschließend die Spiegelung starten.

    Der aktuelle Status der Database Mirroring-Session wird Ihnen in den Eigenschaften der Prinzipal-Datenbank angezeigt:

    Sie haben hier die Möglichkeit die Database Mirroring-Session anzuhalten oder diese zu entfernen.

    Zur Überwachung der Database Mirroring-Session können Sie den Database Mirroring-Monitor (Datenbankspiegelungs Monitor) mit der rechten Maustaste auf die Prinzipal-Datenbank im Kontextmenu Task-> Database Mirroring-Monitor starten.

Welche Vorteile bietet Database Mirroring ?

Die Vorteile beim Einsatz von Database Mirroring kurz zusammengefasst:

  • Ermöglicht Fehlertoleranz auf der Hardware-, Betriebssystem-, SQL-Server- und Festplatten-Ebene
  • Mit dem Einsatz eines Witness-Servers können Client-Applikationen, die für den Datenbank-Zugriff den SQL Native Client verwenden, bei einem Ausfall des Prinzipal-Servers durch das automatische Failover ohne Unterbrechung weiter ausgeführt werden.
  • Die gespiegelte Datenbank kann sich auf einem anderen Server befinden und somit gleichzeitig als Backup dienen
  • Es wird keine spezielle Hardware für den Prinzipal- und den Mirror-Server benötigt
  • Geringe Kosten

Wenn Sie weitere Informationen zu dem Thema Database Mirroring oder Unterstützung beim Konfigurieren einer Database Mirroring-Session benötigen, stehen wir Ihnen gerne zur Verfügung.