Ich glaube, dass dies tatsächlich ein Konstruktionsfehler ist, wenn auch einer, der nicht spezifisch für SQL Server 2016 ist, da alle anderen vorhandenen Implementierungen von temporalen Tabellen (soweit ich weiß) denselben Fehler aufweisen. Die Probleme, die dadurch bei Zeittabellen auftreten können, sind ziemlich schwerwiegend. Das Szenario in Ihrem Beispiel ist mild im Vergleich zu dem, was im Allgemeinen schief gehen kann:
Unterbrochene Fremdschlüsselreferenzen : Angenommen, wir haben zwei temporale Tabellen, wobei Tabelle A einen Fremdschlüsselverweis auf Tabelle B hat. Nehmen wir nun an, wir haben zwei Transaktionen, die beide auf einer Isolationsstufe READ COMMITTED ausgeführt werden: Transaktion 1 beginnt vor Transaktion 2, Transaktion 2 Fügt eine Zeile in Tabelle B ein und schreibt fest, dann fügt Transaktion 1 eine Zeile in Tabelle A mit einem Verweis auf die neu hinzugefügte Zeile von B ein. Da das Hinzufügen der neuen Zeile zu B bereits festgeschrieben wurde, ist die Fremdschlüsselbedingung erfüllt und die Transaktion 1 kann erfolgreich festschreiben. Wenn wir jedoch die Datenbank "AS OF" zwischen dem Beginn von Transaktion 1 und dem Beginn von Transaktion 2 anzeigen würden, würden wir Tabelle A mit einem Verweis auf eine Zeile von B sehen, die nicht existiert. Also in diesem FallDie Zeittabelle bietet eine inkonsistente Ansicht der Datenbank . Dies war natürlich nicht die Absicht des SQL: 2011-Standards, der besagt:
Historische Systemzeilen in einer systemversionierten Tabelle bilden unveränderliche Momentaufnahmen der Vergangenheit. Alle Einschränkungen, die beim Erstellen einer historischen Systemzeile wirksam waren, wurden bereits überprüft, als diese Zeile eine aktuelle Systemzeile war, sodass keine Einschränkungen für historische Systemzeilen erzwungen werden müssen.
Nicht eindeutige Primärschlüssel : Angenommen, wir haben eine Tabelle mit einem Primärschlüssel und zwei Transaktionen, beide auf der Isolationsstufe READ COMMITTED, in der Folgendes geschieht: Nachdem Transaktion 1 beginnt, aber bevor sie diese Tabelle berührt, löscht Transaktion 2 eine bestimmte Zeile der Tabelle und Commits. Anschließend fügt Transaktion 1 eine neue Zeile mit demselben Primärschlüssel ein wie der gelöschte. Dies geht gut durch, aber wenn Sie sich die Tabelle ab einem Zeitpunkt zwischen dem Beginn von Transaktion 1 und dem Beginn von Transaktion 2 ansehen, werden zwei Zeilen mit demselben Primärschlüssel angezeigt.
Fehler bei gleichzeitigen Aktualisierungen : Nehmen wir an, wir haben eine Tabelle und zwei Transaktionen, die beide dieselbe Zeile aktualisieren, wiederum auf der Isolationsstufe READ COMMITTED. Transaktion 1 beginnt zuerst, aber Transaktion 2 ist die erste, die die Zeile aktualisiert. Transaktion 2 wird dann festgeschrieben, und Transaktion 1 führt dann eine andere Aktualisierung der Zeile durch und schreibt fest. Dies ist alles in Ordnung, außer dass, wenn dies eine temporäre Tabelle ist, bei Ausführung der Aktualisierung in Transaktion 1, wenn das System die erforderliche Zeile in die Verlaufstabelle einfügt, die generierte SysStartTime die Startzeit von Transaktion 2 ist, während die SysEndTime ist die Startzeit von Transaktion 1, die kein gültiges Zeitintervall ist, da die SysEndTime vor der SysStartTime liegen würde. In diesem Fall gibt SQL Server einen Fehler aus und setzt die Transaktion zurück (siehe zdiese Diskussion ). Dies ist sehr unangenehm, da auf der Isolationsstufe READ COMMITTED nicht zu erwarten ist, dass Parallelitätsprobleme zu völligen Fehlern führen, was bedeutet, dass Anwendungen nicht unbedingt auf Wiederholungsversuche vorbereitet sind. Dies steht insbesondere im Widerspruch zu einer "Garantie" in der Microsoft-Dokumentation:
Dieses Verhalten garantiert, dass Ihre Legacy-Anwendungen weiterhin funktionieren, wenn Sie die Systemversionierung für Tabellen aktivieren, die von der Versionierung profitieren. ( Link )
Andere Implementierungen von Zeittabellen haben sich mit diesem Szenario befasst (zwei gleichzeitige Transaktionen, die dieselbe Zeile aktualisieren), indem sie die Option angeboten haben, die Zeitstempel automatisch "anzupassen", wenn sie ungültig sind (siehe hier und hier ). Dies ist eine hässliche Problemumgehung, da dies die unglückliche Folge hat, dass die Atomizität von Transaktionen unterbrochen wird, da bei anderen Anweisungen innerhalb derselben Transaktionen die Zeitstempel im Allgemeinen nicht auf die gleiche Weise angepasst werden. Wenn wir bei dieser Problemumgehung die Datenbank zu bestimmten Zeitpunkten "AB" anzeigen, werden möglicherweise teilweise ausgeführte Transaktionen angezeigt.
Lösung: Sie haben bereits die offensichtliche Lösung vorgeschlagen, bei der die Implementierung die Transaktionsendzeit (dh die Festschreibungszeit) anstelle der Startzeit verwendet. Ja, es stimmt, wenn wir eine Anweisung mitten in einer Transaktion ausführen, ist es unmöglich zu wissen, wie hoch die Festschreibungszeit sein wird (wie in der Zukunft oder möglicherweise nicht einmal vorhanden, wenn die Transaktion gerollt würde zurück). Dies bedeutet jedoch nicht, dass die Lösung nicht umsetzbar ist. es muss nur anders gemacht werden. Wenn Sie beispielsweise eine UPDATE- oder DELETE-Anweisung ausführen, kann das System beim Erstellen der Verlaufszeile anstelle einer Startzeit nur die aktuelle Transaktions-ID eingeben, und die ID kann später vom System nach dem Festschreiben der Transaktion in einen Zeitstempel konvertiert werden .
Im Zusammenhang mit dieser Art der Implementierung würde ich vorschlagen, dass vor dem Festschreiben der Transaktion alle Zeilen, die der Verlaufstabelle hinzugefügt werden, nicht für den Benutzer sichtbar sein sollten. Aus Benutzersicht sollte es einfach so aussehen, als würden diese Zeilen (mit dem Festschreibungszeitstempel) zum Zeitpunkt des Festschreibens hinzugefügt. Insbesondere wenn die Transaktion nie erfolgreich festgeschrieben wird, sollte sie niemals im Verlauf erscheinen. Dies steht natürlich nicht im Einklang mit dem SQL: 2011-Standard, der die Einfügungen in den Verlauf (einschließlich Zeitstempel) beschreibt, die zum Zeitpunkt der Anweisungen UPDATE und DELETE (im Gegensatz zum Zeitpunkt des Festschreibens) auftreten. Aber ich denke nicht, dass dies wirklich wichtig ist, wenn man bedenkt, dass der Standard aufgrund der oben beschriebenen Probleme nie richtig implementiert wurde (und wahrscheinlich auch nie sein kann).
Unter Leistungsgesichtspunkten erscheint es möglicherweise unerwünscht, dass das System zurückgehen und die Verlaufszeilen erneut aufrufen muss, um den Festschreibungszeitstempel auszufüllen. Aber je nachdem, wie dies gemacht wird, können die Kosten ziemlich niedrig sein. Ich bin nicht wirklich mit der internen Funktionsweise von SQL Server vertraut, aber PostgreSQL verwendet beispielsweise ein Write-Ahead-Protokoll, mit dem diese Aktualisierungen konsolidiert werden, wenn mehrere Aktualisierungen an denselben Teilen einer Tabelle durchgeführt werden Daten müssen nur einmal auf die physischen Tabellenseiten geschrieben werden - und das würde normalerweise in diesem Szenario zutreffen. Auf jeden Fall,
Da diese Art von System (soweit ich weiß) noch nie implementiert wurde, kann ich natürlich nicht sicher sagen, ob es funktionieren würde - vielleicht fehlt mir etwas -, aber ich sehe keinen Grund warum es nicht funktionieren konnte.
20160707 11:04:58und Sie aktualisieren jetzt alle Zeilen mit diesem Zeitstempel. Dieses Update wird jedoch auch einige Sekunden lang ausgeführt und endet20160707 11:05:02nun mit welchem Zeitstempel ist das richtige Ende der Transaktion? Oder nehmen SieRead Uncommitedan20160707 11:05:00, Sie haben at verwendet und Zeilen zurückgegeben, aber später werdenAS OFsie nicht angezeigt.