Mit T-SQL (als Sprache) hat das recht wenig zu tun. Applikationen können sich nicht an der Transaktionssteuerung vorbeimogeln
Wobei man hierzu noch sagen muss das mit Autocommit in einer falsch programmierten Applikation die Datenbank nachher logisch (d.h. auf Applikations-Ebene, nicht auf SQL-Server Ebene) korrupt sein kann, bzw. Geschäftsprozesse nur halb gelaufen sind aber als "komplett" markiert sind.
Leider gibt es sehr viele Software auf dem Markt die nicht richtig entwickelt wurde. Der Preis sagt dabei leider überhaupt nichts aus, auch bei Namhaften Herstellern kann dies vorkommen, speziell wenn Anpassungen für euch durchgeführt wurden.
Bei einem teuren Unterbau mit aufwendiger Architektur sollte man auch die Applikation(en) genau beleuchten.
Zitat von LukasB
Wobei man hierzu noch sagen muss das mit Autocommit in einer falsch programmierten Applikation die Datenbank nachher logisch (d.h. auf Applikations-Ebene, nicht auf SQL-Server Ebene) korrupt sein kann, bzw. Geschäftsprozesse nur halb gelaufen sind aber als "komplett" markiert sind.
Hallo zusammen und vielen Dank für die vielen Antworten am Freitag,
ich hoffe noch auf ein paar Informationen in der neuen Woche zu folgender Frage.
Welche Vorkehrungen müsste ich treffen um den Datenverlust im Falle eines Failovers gegen 0 zufahren? Wenn ich das so wie in den ersten Beiträgen geschrieben habe nur Clustern würde, dann wären die Informationen aus dem Arbeitsspeicher des Aktiven Notes ja verloren.
Bringt mir an dieser Stelle eine Spiegelung des SQL Servers vielleicht wirklich mehr nutzen? Dann würden ja die Datenbestände zweimal vorhanden sein. Was ist mit den Daten aus dem Arbeitsspeicher.
Wie würde das Failover in einem solchen Fall aussehen?
Mit T-SQL müssten dann unsere Entwickler arbeiten. Die Anwendung die wir mit dem SQL Server nutzen wollen wird selbst programmiert.
Wobei man hierzu noch sagen muss das mit Autocommit in einer falsch programmierten Applikation die Datenbank nachher logisch (d.h. auf Applikations-Ebene, nicht auf SQL-Server Ebene) korrupt sein kann, bzw. Geschäftsprozesse nur halb gelaufen sind aber als "komplett" markiert sind.
Zitat von Lian
Bei einem teuren Unterbau mit aufwendiger Architektur sollte man auch die Applikation(en) genau beleuchten.
völlig richtig. Das sind dann einige der Fälle, in denen ein Cluster überhaupt nichts bringt. Das liegt dann in der Hand des Applikationsentwicklers und ist keine Schwäche der Transaktionssteuerung des SQL Server.
Welche Vorkehrungen müsste ich treffen um den Datenverlust im Falle eines Failovers gegen 0 zufahren? Wenn ich das so wie in den ersten Beiträgen geschrieben habe nur Clustern würde, dann wären die Informationen aus dem Arbeitsspeicher des Aktiven Notes ja verloren.
wie schon geschrieben: Datenverlust aus dem nicht versorgten RAM kann nicht auftreten, wenn es um einen Serverfehler geht. Genau dafür ist ja das Transaktionsprotokoll da. Nur wenn der Server und das Log-Volume gleichzeitig kaputtgingen, träte Datenverlust auf. Um dieses Risiko zu mindern, setzt man auf ein entsprechend abgesichertes Storage-System.
Mit T-SQL müssten dann unsere Entwickler arbeiten. Die Anwendung die wir mit dem SQL Server nutzen wollen wird selbst programmiert.
Dann sollten sich eure Entwickler rechtzeitig und ausführlich genug damit beschäftigen, denn erfahrungsgemäß ist sehr oft die Applikation verantwortlich für Probleme.
Das heißt auch bei einem Failoverclustering würde mir keine Informationen verloren gehen wenn durchweg von der Anwendung T-SQL sauber verwendet wird. Im Falle von einem Failover würde der 2. Knoten übernehmen und dann die entsprechenden Informationen aus dem Transaktionsprotokoll entnehmen können.
Das heißt auch bei einem Failoverclustering würde mir keine Informationen verloren gehen wenn durchweg von der Anwendung T-SQL sauber verwendet wird.
Genau - eine Transaktion ist dann entweder nicht abgeschlossen oder abgeschlossen. Die Applikation muss aber natürlich in der Lage sein sich von einer fehlgeschlagenen Transaktion zu erholen - wie dies bei euch konkret aussieht ist natürlich sehr von der Applikation abhängig.
Evtl. kann es hier sinnvoll sein wenn ihr externe Hilfe beizieht die auf diesem Gebiet bereits über Erfahrung verfügt.
ja, das ist richtig dargestellt. Wobei, wie gesagt, SQL Server sowieso nur über T-SQL kommuniziert, das allein ist also nicht der Punkt. Die Anwendungslogik muss so aufgebaut sein, dass die definierten Transaktionen auch tatsächlich einen konsistenten Stand ergeben - wie Lukas korrekt betont.
