Verwenden der Datenbankspiegelung

Hinweis

Dieses Feature wird in einer zukünftigen Version von Microsoft SQL Server entfernt. Vermeiden Sie die Verwendung dieses Features in neuer Entwicklungsarbeit, und planen Sie, Anwendungen zu ändern, die derzeit dieses Feature verwenden. Verwenden Sie stattdessen Always On Verfügbarkeitsgruppen.

Die in SQL Server 2005 eingeführte Datenbankspiegelung ist eine Lösung für die Erhöhung der Datenbankverfügbarkeit und Datenredundanz. SQL Server Native Client bietet implizite Unterstützung für die Datenbankspiegelung, sodass der Entwickler keinen Code schreiben oder eine andere Aktion ausführen muss, nachdem sie für die Datenbank konfiguriert wurde.

Bei einer Datenbankspiegelung, die für Datenbanken einzeln implementiert wird, befindet sich eine Kopie einer SQL Server-Produktionsdatenbank auf einem Standbyserver. Bei dem Server handelt es sich je nach Konfiguration und Status der Datenbankspiegelungs-Sitzung um einen unmittelbar betriebsbereiten oder einfach betriebsbereiten Standbyserver. Ein Hot-Standby-Server unterstützt ein schnelles Failover ohne Verlust von zugesicherten Transaktionen, und ein warmer Standbyserver unterstützt das Erzwingen des Diensts (mit möglichen Datenverlusten).

Die Produktionsdatenbank wird als Prinzipaldatenbank bezeichnet, und die Standbykopie wird als Spiegeldatenbank bezeichnet. Die Prinzipaldatenbank und die Spiegeldatenbank müssen sich auf separaten Instanzen von SQL Server (Serverinstanzen) befinden, und sie sollten sich nach Möglichkeit auf separaten Computern befinden.

Die Produktionsserverinstanz, die als Prinzipalserver bezeichnet wird, kommuniziert mit der Standbyserverinstanz, die als Spiegelserver bezeichnet wird. Die Prinzipal- und Spiegelserver fungieren als Partner innerhalb einer Datenbankspiegelungssitzung. Wenn der Prinzipalserver fehlschlägt, kann der Spiegelserver seine Datenbank über einen Prozess, der als Failover bezeichnet wird, in die Prinzipaldatenbank umwandeln. Beispiel: Partner_A und Partner_B sind zwei Partnerserver. Die Prinzipaldatenbank befindet sich anfänglich auf dem Prinzipalserver Partner_A und die Spiegeldatenbank auf dem Spiegelserver Partner_B. Wenn Partner_A offline geht, kann die Datenbank auf Partner_B ein Failover ausführen, um zur aktuellen Prinzipaldatenbank zu werden. Sobald Partner_A wieder mit der Sitzung verbunden ist, übernimmt er wieder die Rolle des Spiegelservers und seine Datenbank wird zur Spiegeldatenbank.

Alternative Konfigurationen für die Datenbankspiegelung bieten unterschiedliche Leistungs- und Datensicherheitsstufen und unterstützen unterschiedliche Formen des Failover. Weitere Informationen finden Sie unter Datenbankspiegelung (SQL Server).

Es ist möglich, beim Angeben des Spiegeldatenbanknamens einen Alias zu verwenden.

Hinweis

Informationen zu anfänglichen Verbindungsversuchen und erneuten Verbindungsversuchen mit einer gespiegelten Datenbank finden Sie unter Verbinden von Clients mit einer Datenbankspiegelungssitzung (SQL Server).

Überlegungen zur Programmierung

Wenn auf dem Prinzipaldatenbankserver ein Fehler auftritt, empfängt die Clientanwendung als Antwort auf API-Aufrufe Fehlermeldungen. Dadurch wird angezeigt, dass die Verbindung zur Datenbank unterbrochen ist. In diesem Fall gehen alle nicht ausgelassenen Änderungen an der Datenbank verloren, und die aktuelle Transaktion wird zurückgesetzt. In diesem Fall sollte die Anwendung die Verbindung schließen (oder das Datenquellenobjekt freigeben) und erneut öffnen. Die Verbindung wird transparent erneut an die Spiegeldatenbank weitergeleitet, die jetzt als Prinzipalserver fungiert.

Wenn eine Verbindung hergestellt wurde, teilt der Prinzipalserver die Identität seines Failoverpartners, der bei einem Failover einspringt, dem Client mit. Wenn eine Anwendung versucht hat, eine Verbindung herzustellen, nachdem der Prinzipalserver fehlgeschlagen ist, weiß der Client nicht die Identität des Failoverpartners. Um Clients die Möglichkeit zu ermöglichen, dieses Szenario zu bewältigen, ermöglichen eine Initialisierungseigenschaft und ein zugehöriges Verbindungszeichenfolgen-Schlüsselwort, dass der Client die Identität des Failoverpartners selbst angeben kann. Das Client-Attribut wird nur in diesem Szenario verwendet; wenn der Prinzipalserver verfügbar ist, wird er nicht verwendet. Wenn der vom Client bereitgestellte Failoverpartnerserver nicht auf einen Server verweist, der als Failoverpartner fungiert, wird die Verbindung vom Server abgelehnt. Damit Anwendungen sich an Konfigurationsänderungen anpassen können, kann die Identität des tatsächlichen Failoverpartners durch Prüfen des Attributs bestimmt werden, nachdem die Verbindung hergestellt wurde. Sie sollten die Partnerinformationen zwischenspeichern, um die Verbindungszeichenfolge zu aktualisieren oder eine Wiederholungsstrategie zu entwickeln, falls der erste Versuch, eine Verbindung herzustellen, fehlschlägt.

Hinweis

Sie müssen die Datenbank explizit angeben, die von einer Verbindung verwendet werden soll, wenn Sie dieses Feature in einer DSN- oder Verbindungszeichenfolge oder verbindungseigenschaft/attribut verwenden möchten. SQL Server Native Client versucht nicht, ein Failover in die Partnerdatenbank auszuführen, wenn dies nicht der Fall ist.

Die Spiegelung ist ein Feature der Datenbank. Anwendungen, die mehrere Datenbanken verwenden, können dieses Feature möglicherweise nicht ausnutzen.

Darüber hinaus wird die Groß-/Kleinschreibung von Servernamen nicht beachtet, bei Datenbanknamen wird jedoch die Groß-/Kleinschreibung beachtet. Daher sollten Sie sicherstellen, dass Sie die gleiche Groß-/Kleinschreibung in DSNs und Verbindungszeichenfolgen verwenden.

SQL Server Native Client OLE DB-Anbieter

Der OLE DB-Anbieter von SQL Server Native Client unterstützt die Datenbankspiegelung über Verbindungs- und Verbindungszeichenfolgenattribute. Die SSPROP_INIT_FAILOVERPARTNER-Eigenschaft wurde dem DBPROPSET_SQLSERVERDBINIT Eigenschaftensatz hinzugefügt, und das FailoverPartner Schlüsselwort ist ein neues Verbindungszeichenfolgen-Attribut für DBPROP_INIT_PROVIDERSTRING. Weitere Informationen finden Sie unter Verwenden von Verbindungszeichenfolgenstichwörtern mit SQL Server Native Client.

Der Failovercache wird beibehalten, solange der Anbieter geladen wird, d. h., bis CoUninitialize aufgerufen wird oder solange die Anwendung über einen Verweis auf ein objekt verfügt, das vom SQL Server Native Client OLE DB-Anbieter verwaltet wird, z. B. ein Datenquellenobjekt.

Ausführliche Informationen zur SQL Server Native Client OLE DB-Anbieterunterstützung für die Datenbankspiegelung finden Sie unter Initialisierungs- und Autorisierungseigenschaften.

ODBC-Treiber für SQL Server Native Client

Der ODBC-Treiber für SQL Server Native Client unterstützt die Datenbankspiegelung über Verbindungs- und Verbindungszeichenfolgenattribute. Insbesondere wurde das attribut SQL_COPT_SS_FAILOVER_PARTNER für die Verwendung mit den Funktionen SQLSetConnectAttr und SQLGetConnectAttr hinzugefügt; und das Failover_Partner Schlüsselwort wurde als neues Verbindungszeichenfolgen-Attribut hinzugefügt.

Der Failovercache wird beibehalten, solange die Anwendung mindestens ein Umgebungshandle zugeordnet hat. Umgekehrt geht sie verloren, wenn der letzte Umgebungshandle deallocated wird.

Hinweis

Der ODBC-Treiber-Manager wurde erweitert, um die Spezifikation des Failoverservernamens zu unterstützen.

Siehe auch

SQL Server Native Client-Funktionen
Verbinden von Clients mit einer Datenbank-Spiegelungssitzung (SQL Server)
Datenbankspiegelung (SQL Server)