Datenbankspiegelung und datenbankübergreifende Transaktionen

Die Datenbankspiegelung wird weder für datenbankübergreifende Transaktionen noch für verteilte Transaktionen 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: Nach einem Failover befindet sich die gespiegelte Datenbank auf einer anderen Serverinstanz, und normalerweise befindet sich diese in einer anderen Datenbank als der nicht gespiegelten Datenbank. Auch wenn beide Datenbanken zwischen den beiden gleichen Partnern gespiegelt werden, kann nicht gewährleistet werden, dass für beide Datenbanken zur gleichen Zeit ein Failover ausgeführt wird.

• Für verteilte Transaktionen: Nach einem Failover kann vom neuen Prinzipalserver keine Verbindung mit dem verteilten Transaktionskoordinator des vorherigen Prinzipalservers hergestellt werden, für den dieselbe Ressourcen-ID verwendet wird. Aus diesem Grund kann der neue Prinzipalserver den Transaktionsstatus nicht erlangen.

Im folgenden Beispiel wird verdeutlicht, wie eine logische Inkonsistenz auftreten könnte. 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.