Moin,
das ist so auch nicht ganz richtig.
Den Arbeitsspeicher kannst du nicht synchronisieren. Das wäre bei einem System, das für Höchstleistung geeignet ist (wie SQL Server) auch kaum sinnvoll machbar.
Das Transaktionsproblem besteht aber nicht. Jede Transaktion, die an SQL Server gesendet wird, wird im Transaction Log protokolliert,
bevor SQL Server sie ausführt. Nach einem Server-Ausfall werden alle abgeschlossenen Transaktionen, deren Daten noch nicht in der Datenbank stehen, in diese kopiert (Rollforward) und alle nicht abgeschlossenen Transaktionen gelöscht (Rollback). Da letztere aber auch gegenüber dem Client nicht bestätigt wurden, gibt es auf diese Weise keinen Datenverlust.* Erst nach diesem Vorgang geht die Datenbank online. (Das ist auch der Grund für einen evtl- längeren Failover-Vorgang; zu kontrollieren im Eventlog.)
Mit T-SQL (als Sprache) hat das recht wenig zu tun. Applikationen können sich nicht an der Transaktionssteuerung vorbeimogeln, egal ob sie T-SQL sprechen (was fast alle tun) oder per .NET mit dem Server kommunizieren (was in den meisten Fällen auch auf eine T-SQL-Ansprache hinausläuft).
* Es sei denn, der Ausfall betrifft auch das Storage-System und beschädigt geschriebene Daten. (Das ist einer der Fälle, die Lian meinte.)
Ein paar Hintergründe findest du hier:
http://www.faq-o-matic.net/2009/03/2...nsistent-sein/
Und noch einmal die eindringliche Warnung: Die Fragen, die du stellst, sind nachvollziehbar und okay, aber sie deuten darauf hin, dass ihr bei dem Aufbau eines Hochverfügbarkeitssystems für SQL Server Unterstützung braucht. Klärt eure Anforderungen auf der geschäftlichen Ebene, bevor ihr Systementscheidungen trefft!
Gruß, Nils
