Datenbankübergreifende Transaktionen nicht unterstützt für Datenbankspiegelungs- oder AlwaysOn-Verfügbarkeitsgruppen (SQL Server)
Datenbankübergreifende Transaktionen und verteilte Transaktionen werden von Always On Verfügbarkeitsgruppen oder datenbankbasierter Spiegelung nicht unterstützt. Dies ist darauf zurückzuführen, dass die Unteilbarkeit/Vollständigkeit von Transaktionen aus folgenden Gründen nicht gewährleistet werden kann:
Für datenbankübergreifende Transaktionen: Jede Datenbank führt einen unabhängigen Commit aus. Aus diesem Grund kann sogar für Datenbanken in einer einzelnen Verfügbarkeitsgruppe ein Failover auftreten, nachdem eine Datenbank für eine Transaktion einen Commit ausgeführt hat, jedoch bevor die andere Datenbank diesen Schritt ausgeführt hat. Bei der Datenbankspiegelung wird dieses Problem zusammengefasst, da sich die gespiegelte Datenbank nach einem Failover in der Regel auf einem anderen Server befindet instance als die andere Datenbank, und selbst wenn beide Datenbanken zwischen denselben beiden Partnern gespiegelt werden, gibt es keine Garantie, dass beide Datenbanken gleichzeitig ein Failover ausführen.
Für verteilte Transaktionen: Nach einem Failover kann vom neuen Prinzipalserver bzw. vom primären Replikat keine Verbindung mit dem verteilten Transaktionskoordinator auf dem vorherigen Prinzipalserver bzw. primären Replikat hergestellt werden. Aus diesem Grund kann der neue Prinzipalserver bzw. das neue primäre Replikat den Transaktionsstatus nicht erlangen.
Im folgenden Beispiel zur Datenbankspiegelung wird verdeutlicht, wie eine logische Inkonsistenz auftreten kann. In diesem Beispiel fügt eine Anwendung über eine datenbankübergreifende Transaktion zwei Datenzeilen ein: Eine Zeile wird in eine Tabelle in einer gespiegelten Datenbank (A) eingefügt, und die andere Zeile wird in eine Tabelle in einer anderen Datenbank (B) eingefügt. Datenbank A wird im Modus für hohe Sicherheit mit automatischem Failover gespiegelt. Während des Commits der Transaktion fällt Datenbank A aus. Die Spiegelungssitzung führt automatisch ein Failover zum Spiegel von Datenbank A aus.
Nach dem Failover kann ein Commit der datenbankübergreifenden Transaktion möglicherweise erfolgreich für Datenbank B ausgeführt werden, jedoch nicht für die Datenbank, für die der Failover ausgeführt wurde. Dies wäre möglich, wenn der ursprüngliche Prinzipalserver für Datenbank A nicht das Protokoll für die datenbankübergreifende Transaktion vor dem Ausfall an den Spiegelserver gesendet hätte. Nach dem Failover wäre diese Transaktion auf dem neuen Prinzipalserver nicht vorhanden. Datenbanken A und B würden inkonsistent werden, da die in Datenbank B eingefügten Daten erhalten bleiben, während die in Datenbank A eingefügten Daten verloren gingen.
Ein vergleichbares Szenario kann bei einer MS DTC-Transaktion auftreten. Angenommen, der neue Prinzipal setzt sich nach dem Failover mit MS DTC in Verbindung. Der neue Prinzipalserver ist MS DTC jedoch nicht bekannt, deshalb beendet er alle Transaktionen, für die "ein Commit vorbereitet wird", für die in anderen Datenbanken jedoch bereits anscheinend ein Commit ausgeführt wurde.
Wichtig
Eine SQL Server-Installation wird auch unterstützt, wenn Datenbankspiegelungsfunktionen oder Verfügbarkeitsgruppen zusammen mit DTC verwendet werden. Wenn eine Datenbank jedoch Teil einer Datenbank-Spiegelungssitzung ist oder eine Verfügbarkeitsgruppe und DTC ebenfalls in der Datenbank verwendet werden, geht Microsoft Supportproblemen nur dann nach, wenn sie nicht in Zusammenhang mit der kombinierten Verwendung der Datenbankspiegelungsfunktionen oder Verfügbarkeitsgruppen mit DTC stehen.