Bei der Datenbankspiegelung wird zunächst die zu spiegelnde Datenbank auf einer zweiten SQL Server Instanz wiederhergestellt. Die Original-Datenbank wird dabei als Prinzipal-Datenbank, die Kopie als Spiegel-Datenbank bezeichnet. Die Rolle der beiden Datenbanken kann im Verlauf der Zeit wechseln, d.h. die ursprünglich Kopie kann im Fehlerfall die Rolle des Prinzipals übernehmen und das ursprüngliche Original kann als Spiegel des neuen Prinzipals wiederhergestellt werden.

Alle Änderungen an der Prinzipal-Datenbank werden laufend in der Spiegeldatenbank wiederhergestellt (Rollforward). Dazu werden alle Einträge die im Transaktionsprotokoll des Prinzipals erfolgen umgehend auch an den Datenbank-Spiegel übertragen. Im Gegensatz zum Protokollversand wird hier nicht der Umweg über Sicherung und Wiederherstellung des Protokolls gegangen, sondern die Protokolleinträge werden direkt über das Netzwerk an die Spiegel-Instanz übermittelt und dort verarbeitet.

Synchrone oder asynchrone Datenbankspiegelung

Beim Einrichten der Datenbankspiegelung kann zwischen asynchroner und synchroner Spiegelung gewählt werden. Bei der synchronen Datenbankspiegelung wartet der Prinzipal bei einem Commit von Datenänderungen auf die Bestätigung vom Spiegel, dass die Änderungen dort gespeichert worden sind; erst nach erfolgter Rückmeldung ist die Transaktion durchgeführt. Um die zusätzliche Wartezeit für die Rückmeldung zu reduzieren, kann die Spiegelung auch asynchron betrieben werden: Dabei werden die Änderungen vom Prinzipal umgehend an den Spiegel weitergegeben, es wird aber nicht auf eine Antwort gewartet, um die Transaktion abzuschließen. Dadurch wird eine schnellere Verarbeitung in der Prinzipal-Instanz erreicht; bei der Spiegelinstanz kann es zu einer Verzögerung bei der Wiederherstellung der Änderungen kommen.

Automatisches Failover mit Hilfe eines Zeugen

Bei der Datenbankspiegelung kann eine weitere Datenbank-Instanz die Rolle eines „Zeugen“ übernehmen. Der Zeuge überwacht Prinzipal- und Spiegel und prüft, ob beide Systeme verfügbar sind. Fällt der Prinzipal aus, kann bei synchroner Spiegelung ein automatisches Failover durchgeführt werden. Wird für eine Spiegelsitzung ein Zeuge festgelegt, so muss für ein Failover (automatisch oder manuell) ein Quorum vorhanden sein.

Quorum – Sicherstellen der „Beschlussfähigkeit“

Sobald drei Instanzen – also Prinzipal, Spiegel und Zeuge – an einer Datenbankspiegelung teilhaben, muss im Fehlerfall ein Quorum vorhanden sein, damit ein Failover durchgeführt werden kann. Das Quorum ist die minimale Anzahl an Partnern, die noch kommunizieren können, um ein Failover auszuführen. Bei der Datenbankspiegelung ist das Quorum erfüllt, wenn mindestens zwei Partner noch miteinander verbunden sind. Die folgende Übersicht stellt die verschiedenen Möglichkeiten dar:

Prinzipal	Spiegel	Zeuge	Quorum
Erreichbar	Erreichbar	Erreichbar	Vollständiges Quorum
Nicht erreichbar	Erreichbar	Erreichbar	Quorum von Spiegel und Zeuge, automatisches Failover
Nicht erreichbar	Erreichbar	Nicht erreichbar	Kein Quorum, die Spiegel-Datenbank kann nicht online gehen
Erreichbar	Nicht erreichbar	Nicht erreichbar	Kein Quorum, die Prinzipal-Datenbank geht offline
Erreichbar	Erreichbar	Nicht erreichbar	Partner-Quorum, ein manuelles Failover von Prinzipal zu Spiegel ist möglich

Die Wahl zwischen synchroner oder asynchroner Spiegelung und Spiegelung mit oder ohne Zeuge bestimmt den Betriebsmodus, in dem die Spiegelung ausgeführt wird;
die folgende Übersicht zeigt den Zusammenhang zwischen Synchronisierungsart und Zeuge und den verschiedenen Betriebsmodi für die Datenbankspiegelung:

Synchronisierung	Zeuge	Modus
Synchron	Festgelegt	Modus für hohe Verfügbarkeit
Synchron	Nicht festgelegt	Modus für hohen Schutz
Asynchron	Nicht festgelegt	Modus für hohe Leistung
	Festgelegt	Modus für hohe Leistung
	Festgelegt	Diese Kombination ist zwar möglich, aber nicht sinnvoll, da bei der asynchronen Spiegelung kein automatisches Failover möglich ist und zusätzlich ein Quorum benötigt wird, wenn die Spiegelinstanz online geschaltet werden soll.

Vorbereitungen für das Einrichten der Datenbankspiegelung

Aktivieren der Datenbank-Spiegelung

Die Datenbankspiegelung war vor dem Service Pack 1 standardmäßig deaktiviert und konnte nur zu Evalierungszwecken aktiviert werden. Dazu mussten die Dienste auf allen beteiligten SQL Server Instanzen mit dem Trace-Flag 1440 gestartet werden.
Starten Sie dazu den „SQL Server Konfigurations Manager“ und wählen Sie in der Liste der „SQL Server 2005 Dienste“ den SQL Server 2005 Dienst aus. Öffnen Sie den Eigenschaften-Dialog. („Eigenschaften“ im Kontext-Menü des SQL Server 2005 Dienst).
Auf der Registerseite „Erweitert“ können Sie die Eigenschaft „Startparameter“ bearbeiten.
Ergänzen Sie die vorhandenen Startparameter um das Trace-Flag 1400:

;-T1400

Die Dienst muss anschließend neu gestartet werden, damit die geänderte Startoption aktiv ist.

Vorbereitungen für die Prinzipal-Datenbank

Stellen Sie sicher, dass die Datenbank im Wiederherstellungsmodell „Vollständig“ betrieben wird.
Datenbanken mit dem Wiederherstellungsmodell „Einfach“ oder „Massenprotokolliert“ können nicht gespiegelt werden.
Prüfen Sie, ob alle SQL-Anmeldungen, die von den Datenbankbenutzern verwendet werden auf der Spiegelinstanz auch vorhanden sind.
Falls nicht, sollten Sie die Logins zuvor auf der vorgesehenen Spiegelinstanz anlegen. Achten Sie darauf, dass für die Anmeldungen auf der Spiegelinstanz die gleichen Spracheinstellungen verwendet werden.
Falls Sie mit SQL Server Anmeldungen (im Gegensatz zu Windows-Anmeldungen) arbeiten, sollten Sie sicherstellen, dass die Kennwörter auf beiden Instanzen synchron sind oder den Anwendern eine Möglichkeit zum Ändern des Kennworts gegeben wird.
Erstellen Sie eine vollständige Datenbanksicherung der Prinzipal-Datenbank und stellen Sie diese Sicherung mit der Option „NORECOVERY“ auf der Spiegel-Instanz wieder her. Erstellen Sie anschließend auch noch eine Transaktionsprotokollsicherung und stellen Sie diese ebenfalls auf der Spiegel-Instanz mit der Option „NORECOVERY“ wieder her.
Auf der Spiegelinstanz sollte nach Möglichkeit die gleiche Verzeichnisstruktur wie auf dem Prinzipal vorhanden sein, dies ist aber nicht zwingend erforderlich. Falls Sie abweichende Verzeichnisse verwenden, sollten Sie im laufenden Betrieb beim Hinzufügen weiterer Dateien zur Datenbank daran denken, dass ein gleichnamiges Verzeichnis auf der Spiegelinstanz ebenfalls vorhanden sein muss.

Bevor die Datenbank-Spiegelung konfiguriert wird, sollten Sie noch folgende Punkte klären:

Unter welchem Dienstkonto laufen die beteiligten Instanzen?
Falls alle beteiligten Partner unter dem gleichen Dienstkonto arbeiten, ist keine weitere Konfiguration notwendig. Falls Sie unterschiedliche Dienstkonten verwenden, müssen entsprechende Anmeldungen auf den beteiligten Instanzen eingerichtet werden; der Assistent zum Konfigurieren der Sicherheit für die Datenbankspiegelung kann die notwendigen Anmeldungen erstellen und die erforderliche Berechtigung für den Zugriff auf die Spiegelungsendpunkte setzen. Falls die Instanzen unter dem Konto „Netzwerkdienst“ ausgeführt werden, müssen entsprechende Anmeldungen für die Computerkonten eingerichtet werden. Falls die Instanzen unter dem Konto „Lokaler Dienst“ ausgeführt werden oder sich nicht in einer vertrauten Domäne befinden, kann auch eine Authentifizierung mittels Zertifikaten erfolgen.
Befindet sich eine Firewall zwischen den Instanzen?
Die Instanzen kommunizieren über eigene Ports miteinander. Für jede Datenbankspiegelung können die Ports für alle beteiligten Instanzen festgelegt werden. Falls ein Firewall vorhanden ist, müssen für diese Ports sowohl eingehende als auch ausgehende Verbindungen zugelassen sein.

Beispiel: Einrichten einer Datenbankspiegelung im Modus für „hohe Verfügbarkeit“

Beteiligte Server und Instanzen

Rolle	Server	Instanz	Port
Prinzipal	Mars	Mars\SQL2005	5022
Spiegel	Venus	Venus\SQL2005	5050
Zeuge	Vulkan	Vulkan\SQL2005	5051

Alle drei Instanzen befinden sich in der gleichen Domäne und laufen unter dem Domänenkonto „SQLServer“.

Die Datenbank „Suedwind“ soll von der Instanz „Mars\SQL2005“ auf die Instanz „Venus\SQL2005“ gespiegelt werden. Alle Anmeldungen, die von der Datenbank Suedwind verwendet werden, sind auf beiden Instanzen vorhanden.

Erstellen einer vollständigen Datenbanksicherung
Erstellen einer Transaktionsprotokollsicherung der Datenbank „Suedwind“ auf der Instanz „Mars\SQL2005“
Wiederherstellen der vollständigen Datenbanksicherung auf der Instanz „Venus\SQL2005“ mit der Option „NORECOVERY“
Wiederherstellen der Transaktionsprotokollsicherung auf der Instanz „Venus\SQL2005“ mit der Option „NORECOVERY“

Konfigurieren der Sicherheit für die Datenbankspiegelung mithilfe des Assistenten

Der Assistent zum Konfigurieren der Sicherheit sammelt die notwendigen Informationen zum Erstellen der Endpunkte für die Datenbankspiegelung auf allen beteiligten Instanzen. Außerdem können die Anmeldungen und erforderlichen Berechtigungen für den Zugriff auf die Endpunkte festgelegt werden.

Konfigurieren der Prinzipalserverinstanz

Für die Prinzipalserverinstanz kann der Endpunktname und der für die Spiegelung verwendete Port konfiguriert werden. In diesem Beispiel wird der Port 5022 verwendet. Der Endpunkt erhält den Namen „SpiegelSuedwind“. Falls gewünscht, kann über die Option „Durch diesen Endpunkt gesendete Daten verschlüsseln“ aktiviert werden.

Abbildung: Sicherheitskonfiguration der Prinzipalserverinstanz

Konfigurieren der Spiegelserverinstanz

Für die Spiegelserverinstanz können ebenfalls der Name und Port für die Endpunkte festgelegt werden. Dabei muss nicht der gleiche Port wie bei der Prinzipalserverinstanz verwendet werden.

Abbildung: Sicherheitskonfiguration der Spiegelserverinstanz

Konfigurieren der Zeugenserverinstanz

Auch für die Zeugenserverinstanz werden Port und Endpunktname festgelegt. Verwenden Sie für den Endpunktnamen nach Möglichkeit einen Namen, der die Rolle als Zeuge verdeutlicht.

Abbildung: Sicherheitskonfiguration der Zeugenserverinstanz

Falls Sie unterschiedliche Dienstkonten für die drei Serverinstanzen verwenden, können Sie auf der nächsten Seite des Assistenten die Namen der Konten festlegen. Dadurch kann der Assistent die Anmeldungen und benötigten Berechtigungen für die Endpunkte automatisch anlegen.

Fertigstellen des Assistenten

Überprüfen der Konfiguration

Sie finden die vom Assistenten erstellten Endpunkte für die Datenbankspiegelung im SQL Server Management Studio unter dem Ordner „Serverobjekte“, „Endpunkte“, „Datenbankspiegelung“. Sie können auch die folgende Abfrage verwenden, um alle Informationen über den Endpunkt abzurufen:

SELECT * FROM sys.database_mirroring_endpoints

Starten der Spiegelung

Nachdem die Endpunkte konfiguriert sind, kann die Datenbankspiegelung gestartet werden. Legen Sie vor dem Starten den gewünschten Modus fest. In diesem Beispiel soll der Modus „Hohe Verfügbarkeit“ verwendet werden, d.h. ein automatischer Failover ist möglich.

Abbildung: Starten der Datenbank-Spiegelung

Mögliche Probleme beim Starten der Spiegelung

Beim Starten der Spiegelung wird geprüft, ob die Datenbank auf der Spiegelinstanz erfolgreich synchronisiert werden kann. Wurden auf der Prinzipalinstanz inzwischen Protokollsicherungen durchgeführt, die auf der Spiegelinstanz noch nicht eingespielt wurden, kann die Spiegelung nicht aktiviert werden. Führen Sie in diesem Fall zunächst eine Wiederherstellung aller noch nicht eingespielten Transaktionsprotokollsicherungen auf der Spiegelinstanz durch.

Nachdem die Datenbankspiegelung gestartet ist, tauschen alle drei beteiligten Instanzen regelmäßig Statusinformationen aus. Sie können den Netzwerkstatus aller drei Instanzen mithilfe von netstat prüfen:

Netstat –abn

Einrichten der Datenbankspiegelung mit Transact-SQL

Natürlich kann die Datenbankspiegelung auch über Transact-SQL Anweisungen eingerichtet werden. Diese Methode ist empfehlenswert, wenn eine ganze Reihe von Datenbanken auf eine andere Instanz gespiegelt werden soll. Das folgende Beispiel zeigt die Einrichtung der Datenbankspiegelung analog zum vorangegangenen Beispiel. Die Datenbank „Suedwind“ soll von der Instanz „Mars/SQL2005“ auf die Instanz „Venus/SQL2005“ gespiegelt werden. Als Zeuge wird die Instanz „Vulkan/SQL2005“ verwendet.

Erstellen der Endpunkte auf allen drei beteiligten Instanzen

Auf der Prinzipalinstanz soll der Port 5022 verwendet werden. Als Name für den Endpunkt wird „SpiegelSuedwind“ festgelegt. Das Dienstkonto „SQLServer“ erhält die notwendige Berechtigung zum Verbindungsaufbau:

-- Prinzipal Instanz
-- Endpunkt für Datenbankspiegelung erstellen:
CREATE ENDPOINT SpiegelSuedwind STATE = STARTED
   AS TCP ( LISTENER_PORT = 5022 )
   FOR DATABASE_MIRRORING
   ( ENCRYPTION = SUPPORTED, ROLE = PARTNER );
GO
-- Dienstkonto "sqlserver" Berechtigung zum Verbinden mit dem
-- Endpunkt erteilen:
GRANT CONNECT
ON ENDPOINT::SpiegelSuedwind
TO [sqltrain\sqlserver];
GO

Listing: Einrichten des Datenbankspiegel-Endpunkts auf der Prinzipalinstanz

Auf der Spiegelinstanz wird der Port 5050 verwendet. Das folgende Transact-SQL Skript wird auf der Instanz „Venus\SQL2005“ ausgeführt:

-- Spiegel Instanz
-- Endpunkt für Datenbankspiegelung erstellen:
CREATE ENDPOINT SpiegelSuedwind STATE = STARTED
   AS TCP ( LISTENER_PORT = 5050 )
   FOR DATABASE_MIRRORING
   ( ENCRYPTION = SUPPORTED, ROLE = PARTNER );
GO
-- Dienstkonto "sqlserver" Berechtigung zum Verbinden mit dem
-- Endpunkt erteilen:
GRANT CONNECT
ON ENDPOINT::SpiegelSuedwind
TO [sqltrain\sqlserver];
GO

Listing: Einrichten des Datenbankspiegel-Endpunkts auf der Spiegelinstanz „Venus\SQL2005“

Schließlich wird auf der Zeugen-Instanz der Endpunkt „ZeugeSuedwind“ mit Port 5051 aktiviert:

-- Zeugen Instanz
-- Endpunkt für Datenbankspiegelung erstellen:
CREATE ENDPOINT ZeugeSuedwind STATE = STARTED
   AS TCP ( LISTENER_PORT = 5051 )
   FOR DATABASE_MIRRORING
   ( ENCRYPTION = SUPPORTED, ROLE = WITNESS );
GO
-- Dienstkonto "sqlserver" Berechtigung zum Verbinden mit dem
-- Endpunkt erteilen:
GRANT CONNECT
ON ENDPOINT::ZeugeSuedwind
TO [sqltrain\sqlserver];
GO

Listing 1.6: Aktiveren des Endpunkts „ZeugeSuedwind“ auf der Zeugen-Instanz

Starten der Datenbankspiegelung

Nachdem alle Endpunkte konfiguriert sind, kann die Datenbankspiegelung gestartet werden. Dazu wird im ersten Schritt auf der Spiegelinstanz („Venus\SQL2005“) die Prinzipalinstanz als Partner festgelegt.
Die Datenbank „Suedwind“ wurde auf der Spiegelinstanz bereits mit der Option „NORECOVERY“ wiederhergestellt.

-- 1. Partner von Spiegel zu Prinzipal
ALTER DATABASE Suedwind SET PARTNER = 'TCP://mars.muc.sqltrain:5022'
GO

Listing: Festlegen des Partners auf der Spiegelinstanz

Anschließend kann auf der Prinzipalinstanz („Mars\SQL2005“) die Spiegelinstanz als Partner festgelegt werden.
Dadurch werden beide Datenbanken synchronisiert; die Datenbank „Suedwind“ auf der Instanz „Mars\SQL2005“ wird zur Prinzipaldatenbank.
Im gleichen Skript kann zusätzlich die Instanz „Vulkan\SQL2005“ als Zeuge für die Spiegelsitzung definiert werden:

-- 2. Partner von Prinzipal zu Spiegel
ALTER DATABASE Suedwind
SET PARTNER = 'TCP://venus.muc.sqltrain:5050'
GO
-- Festlegen der Zeugen-Instanz:
ALTER DATABASE Suedwind
SET WITNESS = 'TCP://vulkan.muc.sqltrain:5051'
-- Abfragen der Eigenschaften der Spiegelung:
USE Suedwind;
SELECT *
FROM sys.database_mirroring
WHERE database_id = DB_ID()
GO

Listing: Aktivieren von Spiegelung und Zeuge auf der Prinzipalinstanz

Nachdem alle Partner konfiguriert sind, können über die Sicht „sys.database_mirroring“ die Konfiguration und der Status der einzelnen Partner abgefragt werden.

Abbildung: Zusammenspiel von Prinzipal, Spiegel und Zeuge

Failover-Szenarien

Manueller Failover

Im Fehlerfall kann ein manueller Failover vom Prinzipal zum Spiegel durchgeführt werden. Der Spiegel übernimmt in diesem Fall die Rolle des Prinzipals und bringt seine Datenbank online. Die folgende Transact-SQL Anweisung kann auf dem Prinzipal ausgeführt werden, um einen manuellen Failover zu starten:

USE master
GO
ALTER DATABASE Suedwind
SET PARTNER FAILOVER
GO

Automatischer Failover

Ist der Prinzipalserver nicht mehr erreichbar und Spiegel und Zeuge können noch miteinander kommunizieren, erfolgt ein automatischer Failover (Im Betriebsmodus „Hohe Verfügbarkeit“). Wird der ursprüngliche Prinzipal später wieder erreicht, übernimmt er die Rolle des Spiegels und synchronisiert die Daten wieder mit dem neuen Prinzipal.

Failover und Clientverbindungen

Für Clientprogramme, die mit dem SQL Native Client Provider auf die Datenbank zugreifen, ist ein Failover transparent, d.h. dem Client muss die Adresse des aktiven Servers nicht explizit mitgeteilt werden.

Baut ein solcher Client eine Verbindung zu einer gespiegelten Datenbank auf (der Name der Datenbank muss in der Verbindungszeichenfolge angegeben sein), sendet der Prinzipal dem Client mit dem Verbindungsaufbau auch die Adresse der Spiegelinstanz. Findet während des Programmlaufs ein Failover statt, wird die Verbindung automatisch mit dem Failover Partner aufgebaut. Bestand noch eine offene Verbindung zum ursprünglichen Prinzipal, als der Failover stattfand, erhält der Client zunächst eine entsprechende Fehlermeldung, dass die Verbindung getrennt wurde. Anschließend kann die Verbindung jedoch einfach wiederhergestellt werden, ohne dass der Name des „neuen“ Prinzipals explizit angegeben werden muss.

Damit auch Clients, die zum Zeitpunkt des Failovers noch nicht gestartet wurden direkt eine Verbindung zum aktuellen Prinzipal aufbauen können, sollte die Verbindungszeichenfolge immer auch den Namen des Fail-over Partners enthalten. In diesem Fall wird automatisch eine Verbindung zum Partner aufgebaut, wenn keine Verbindung zum ursprünglichen Prinzipal möglich ist.

Beispiel für eine Verbindungszeichenfolge mit Failover Partner:

connectionString="Data Source=mars.muc.sqltrain\SQL2005;Initial Catalog=Suedwind;Integrated Security=True;Failover Partner=venus.muc.sqltrain\SQL2005;"

Mit welcher Instanz die Verbindung tatsächlich hergestellt wird, kann im Client-Programm nach dem Verbindungsaufbau über die Eigenschaft „DataSource“ des „SQLConnection“-Objekts ermittelt werden.

Einige Zusatzinfos zu transparentem Failover und Connection-Pooling

Tatsächlich spielen Connection Pooling und die Angabe von "Failover Partner" im Connection-String eine Rolle, aber grundsätzlich kommt es darauf an, in welchem Zustand sich die Client-Verbindung befindet, während der Failover stattfindet. Ich habe mal die folgenden Szenarien durchgespielt:

1. Fall: Failover bevor das Client Programm gestartet wurde

Ist der Failover Partner im ConnectionString angegeben, wird automatisch eine Verbindung zum neuen Prinzipal aufgebaut, ist der Failover Partner nicht angegeben, findet kein Verbindungsaufbau statt (Auch wenn ein manueller Failover durchgeführt wurde und der "Master"-Server eigentlich erreichbar ist.)

2. Fall: Failover während das Client-Programm läuft; es besteht aber zur Zeit keine Verbindung

(was bei der Arbeit mit Datasets durchaus realistisch ist), d.h. das Connection Objekt hat den Status "Closed" und es existiert dahinter auch keine durch das Connection-Pooling offen gehaltene Verbindung mehr.

Bei diesem Szenario spielt es keine Rolle, ob ein Failover Partner im Connectionstring angegeben ist, da beim ersten Öffnen der Verbindung der Name des Partners im Connection-Objekt gecacht wird. Diese Information bleibt erhalten, auch wenn die Verbindung geschlossen wird (State=Closed). Wird die Verbindung nach dem Failover erneut geöffnet, z.B. durch ein Update über Datenadapter, findet eine transparente Umleitung zum Partner statt. Natürlich muss für den Verbindungsaufbau wieder das gleiche Connection-Objekt verwendet werden, sonst ist das Verhalten wie im 1. Fall beschrieben.

3. Fall: Failover während das Client-Programm läuft; die Verbindung wurde seit dem letzten Befehl (Update, Fill, etc.) nicht geschlossen.

Ich meine hier die "echte" Verbindung zum Server - ist Connection Pooling aktiviert, so bleibt die eigentliche Verbindung ja noch einige Zeit geöffnet, auch wenn das Connection-Objekt den Status "Closed" hat. Wird jetzt der nächste Befehl an den Server gesendet, kommt es zum Fehler: Ist gar keine Verbindung zum Server mehr möglich (Server weg oder Netz weg) gibt es entsprechend eine Meldung: Verbindung zum Server fehlgeschlagen, ...

Ist der Server noch erreichbar und wurde die Verbindung durch den Failover getrennt, gibt es eine entsprechende Fehlermeldung, dass die Verbindung vom Server getrennt wurde. In beiden Fällen muss der Fehler abgefangen werden. Ein anschließender Verbindungsaufbau ist jedoch wieder fehlerfrei möglich - die Verbindung wird dann automatisch zum Failover Partner umgeleitet. Auch hier gilt wieder das gleiche wie bei Fall 2: Für den erneuten Verbindungsaufbau muss das gleiche Connection-Objekt verwendet werden, ansonsten muss der Failover-Partner im Connectionstring angegeben sein.

Das heißt, ganz ohne Fehlerbehandlung kommt man nicht aus, aber die sollte ja in jedem Fall vorhanden sein: Es gibt ja auch noch den Zeitraum zwischen Fehler und Umschalten auf den Spiegelpartner. Insgesamt finde ich, dass man doch von einer transparenten Umleitung sprechen kann.

Leider habe ich keinen Weg gefunden, den Namen des Partner Servers nach dem Verbindungsaufbau aus dem Connection-Objekt auszulesen, obwohl die Information ja irgendwo gecacht wird, aber man kann den Namen leicht sofort nach dem Verbindungsaufbau durch einen Select auf die Sicht sys.database_mirroring abfragen.

Nach erfolgreichem Verbindungsaufbau kann man übrigens über die Eigenschaft DataSource des Connection-Objekts feststellen, mit welchem Server die Verbindung tatsächlich hergestellt wurde.

Link-Tipp zum Thema "Microsoft SQL Server": www.devx.com/projectcool/developer/Default.asp

Viele Artikel, Links zu .Net, VB, SQL Server, und und und...