Migrationshandbuch von Oracle zu SQL Server und von SQL Server zu Oracle – Pt. 3

Der erste und der zweite Teil dieser Serie behandelten Unterschiede zwischen Oracle Database und Microsoft SQL Server bei der Implementierung von Transaktionen und die daraus resultierenden Fallstricke bei der Konvertierung sowie einige häufig verwendete Syntaxelemente.

In diesem letzten Teil wird der Begriff der Oracle-Lesekonsistenz behandelt und wie die auf diesem Begriff basierende Architektur in eine Microsoft SQL Server-Version konvertiert wird. Es wird auch die Verwendung von Synonymen (und wie man sie NICHT verwendet) und die Rolle des Änderungskontrollprozesses bei der Verwaltung Ihrer Datenbankumgebung behandeln.

Oracle-Lesekonsistenz und ihre Entsprechung in SQL Server

Oracle-Lesekonsistenz ist eine Garantie dafür, dass alle Daten, die von einer einzelnen SQL-Anweisung zurückgegeben werden, vom selben einzelnen Zeitpunkt stammen.

Dies bedeutet, dass, wenn Sie um 12:01:02.345 eine SELECT -Anweisung ausgegeben haben und diese 5 Minuten lang ausgeführt wurde, bevor die Ergebnismenge zurückgegeben wurde, alle Daten (und nur Daten), die ab 12:01:02.345 in der Datenbank festgeschrieben wurden, es schaffen in Ihr Rückgabeset. Ihrem Rückgabesatz werden in den 5 Minuten, die die Datenbank zur Verarbeitung Ihres Auszugs benötigt hat, keine neuen Daten hinzugefügt, noch werden Aktualisierungen vorgenommen, und es werden keine Löschungen sichtbar sein.

Die Oracle-Architektur erreicht Lesekonsistenz, indem jede Änderung an den Daten intern mit einem Zeitstempel versehen und ein Ergebnissatz aus zwei Quellen erstellt wird: permanente Datendateien und ein Undo-Segment (oder „Rollback-Segment“, wie es bis Version 10g bekannt war).

Um dies zu unterstützen, sollten die Undo-Informationen erhalten bleiben. Wenn es überschrieben wird, führt dies zu dem berüchtigten Fehler ORA-01555: snapshot too old .

Abgesehen von der Rückgängig-Segmentverwaltung – und wie man durch den Fehler ORA-01555: snapshot too old navigiert – schauen wir uns die Auswirkungen der Lesekonsistenz auf jede praktische Implementierung in Oracle an. Wie sollte es auch in SQL Server gespiegelt werden, der es – wie bei anderen RDBMS-Implementierungen mit der möglichen und qualifizierten Ausnahme von PostgreSQL – nicht unterstützt?

Der Schlüssel ist, dass sich Lese- und Schreibvorgänge von Oracle nicht gegenseitig blockieren. Dies bedeutet auch, dass Ihr Rückgabesatz für lang andauernde Abfragen möglicherweise nicht über die neuesten Daten verfügt.

Nicht blockierende Lese- und Schreibvorgänge sind ein Vorteil von Oracle und wirken sich auf den Transaktionsbereich aus.

Lesekonsistenz bedeutet aber auch, dass Sie nicht über den neuesten Stand der Daten verfügen. Wenn es in einigen Szenarien vollkommen in Ordnung ist (z. B. das Erstellen eines Berichts für einen bestimmten Zeitraum), kann es in anderen zu erheblichen Problemen führen.

Nicht über die neuesten – nicht einmal „schmutzigen“ oder nicht festgeschriebenen – Daten zu verfügen, könnte kritisch sein: Das klassische Szenario ist ein Hotelzimmerreservierungssystem.

Betrachten Sie den folgenden Anwendungsfall: Sie haben zwei Kundendienstmitarbeiter, die gleichzeitig Bestellungen für Zimmerreservierungen entgegennehmen. Wie können Sie sicherstellen, dass Zimmer nicht überbucht werden?

In SQL Server können Sie eine explizite Transaktion starten und einen Datensatz aus der Liste verfügbarer Räume (die eine Tabelle oder eine Ansicht sein kann) SELECT . Solange diese Transaktion nicht abgeschlossen ist (entweder durch COMMIT oder ROLLBACK ), kann niemand denselben Raumdatensatz abrufen, den Sie ausgewählt haben. Dies verhindert Doppelbuchungen, lässt aber auch jeden anderen Agenten darauf warten, dass jeder andere Reservierungsanfragen einzeln nacheinander abschließt.

In Oracle können Sie dasselbe Ergebnis erzielen, indem Sie eine SELECT ... FOR UPDATE -Anweisung für Datensätze ausgeben, die Ihren Suchkriterien entsprechen.

Hinweis: Es gibt bessere Lösungen, wie das Setzen eines temporären Flags, das einen Raum als „in Prüfung“ markiert, anstatt den Zugang zu ihm blind zu sperren. Aber das sind architektonische Lösungen, keine Sprachoptionen.

Fazit : Die Lesekonsistenz von Oracle ist nicht „alles gut“ oder „alles schlecht“, sondern eine wichtige Eigenschaft der Plattform, die gut verstanden werden muss und für die plattformübergreifende Codemigration von entscheidender Bedeutung ist.

Öffentliche (und private) Synonyme in Oracle und Microsoft SQL Server

„Öffentliche Synonyme sind böse.“ Es ist nicht gerade meine persönliche Entdeckung, aber ich hatte es als Evangelium akzeptiert, bis mein Tag, meine Woche und mein Jahr durch öffentliche Synonyme gerettet wurden.

In vielen Datenbankumgebungen – ich würde sagen, allen Oracle-Umgebungen, mit denen ich gearbeitet habe, aber keiner, die ich entworfen habe – war die Verwendung von CREATE PUBLIC SYNONYM für jedes Objekt Routine, weil „wir das schon immer so gemacht haben“.

In diesen Umgebungen hatten öffentliche Synonyme nur eine Funktion: Verweise auf ein Objekt zu ermöglichen, ohne seinen Eigentümer anzugeben. Und dies ist ein schlecht durchdachter Grund, Synonyme öffentlich zu machen.

Öffentliche Oracle-Synonyme können jedoch äußerst nützlich sein und der Teamproduktivität Vorteile bringen, die alle ihre Nachteile deutlich überwiegen, wenn sie richtig und mit gutem Grund implementiert und verwaltet werden. Ja, ich sagte „Teamproduktivität“. Aber wie? Dazu müssen wir verstehen, wie die Namensauflösung in Oracle funktioniert.

Wenn der Oracle-Parser einen Namen (ein nicht reserviertes Schlüsselwort) findet, versucht er, ihn in der folgenden Reihenfolge mit einem vorhandenen Datenbankobjekt abzugleichen:

Hinweis: Der ausgelöste Fehler ORA-00942: table or view does not exist für DML-Anweisungen, oder PLS-00201: identifier 'my_object' must be declared für gespeicherte Prozeduren oder Funktionsaufrufe deklariert werden.

In dieser Namensauflösungsreihenfolge ist leicht zu erkennen, dass, wenn ein Entwickler in seinem eigenen Schema arbeitet, jedes lokale Objekt mit demselben Namen wie ein öffentliches Synonym dieses öffentliche Synonym verbirgt . (Hinweis: Oracle 18c hat den Schematyp „Nur Anmeldung“ implementiert, und diese Diskussion gilt nicht dafür.)

Öffentliche Synonyme für Skalierungsteams: Oracle Change Control

Schauen wir uns nun ein hypothetisches Team von 100 Entwicklern an, die an derselben Datenbank arbeiten (was ich selbst erlebt habe). Nehmen wir außerdem an, dass sie alle lokal auf ihren persönlichen Workstations arbeiten und unabhängig voneinander Nicht-Datenbank-Builds durchführen, die alle mit derselben Datenbankentwicklungsumgebung verbunden sind. Die Auflösung des Zusammenführens von Code in Nicht-Datenbankcode (sei es C#, Java, C++, Python oder irgendetwas anderes) erfolgt zum Zeitpunkt des Eincheckens der Änderungssteuerung und tritt mit dem nächsten Codebuild in Kraft. Aber Datenbanktabellen, Code und Daten müssen während der laufenden Entwicklung mehrmals hin und her geändert werden. Jeder Entwickler tut dies unabhängig und es tritt sofort in Kraft.

Dazu werden alle Datenbankobjekte in einem gemeinsamen Anwendungsschema angelegt. Dies ist das Schema, auf das die Anwendung verweist. Jeder Entwickler:

• Verbindet sich mit seinem persönlichen Benutzerkonto/Schema mit der Datenbank
• Beginnt immer mit einem leeren Personenschema
• Verweist auf das allgemeine Schema nur durch Namensauflösung in ein öffentliches Synonym, wie oben beschrieben

Wenn ein Entwickler Änderungen an der Datenbank vornehmen muss – eine Tabelle erstellen oder ändern, einen Prozedurcode ändern oder sogar einen Datensatz ändern muss, um ein Testszenario zu unterstützen – erstellt er eine Kopie des Objekts in seinem persönlichen Schema. Dazu erhalten sie DDL-Code mit dem DESCRIBE -Befehl und führen ihn lokal aus.

Von diesem Moment an sieht der Code dieses Entwicklers die lokale Version des Objekts und der Daten, die für andere Personen nicht sichtbar sind (und sich nicht auf sie auswirken). Nach Abschluss der Entwicklung wird der geänderte Datenbankcode in die Quellcodeverwaltung eingecheckt und Konflikte werden gelöst. Dann wird der endgültige Code (und ggf. Daten) in das gemeinsame Schema implementiert.

Danach kann das gesamte Entwicklungsteam wieder dieselbe Datenbank sehen. Der Entwickler, der gerade den Code geliefert hat, löscht alle Objekte aus seinem persönlichen Schema und ist bereit für eine neue Aufgabe.

Diese Fähigkeit, die unabhängige parallele Arbeit mehrerer Entwickler zu erleichtern, ist der Hauptvorteil öffentlicher Synonyme – eine Bedeutung, die kaum zu überschätzen ist. In der Praxis sehe ich jedoch weiterhin Teams, die öffentliche Synonyme in Oracle-Implementierungen erstellen, „nur weil wir es immer tun“. Im Gegensatz dazu sehe ich in Teams, die SQL Server verwenden, die Erstellung öffentlicher Synonyme nicht als gängige Praxis. Die Funktionalität ist vorhanden, wird aber nicht oft genutzt.

In SQL Server ist das aktuelle Standardschema für einen Benutzer in der Benutzerkonfiguration definiert und kann jederzeit geändert werden, wenn Sie über die Berechtigung „Benutzer ändern“ verfügen. Es kann genau dieselbe Methodik wie oben für Oracle beschrieben implementiert werden. Wenn diese Methode jedoch nicht verwendet wird, sollten öffentliche Synonyme nicht kopiert werden.

Da Microsoft SQL Server standardmäßig kein neues Benutzerkonto mit seinem eigenen Schema verknüpft (wie es Oracle tut), sollte die Zuordnung Teil Ihres Standardskripts „Benutzer erstellen“ sein.

Nachfolgend finden Sie ein Beispiel für ein Skript, das dedizierte Benutzerschemas erstellt und einem Benutzer eines zuweist.

Erstellen Sie zunächst Schemas für neue Benutzer, die in die Datenbank mit dem Namen DevelopmentDatabase integriert werden müssen (jedes Schema muss in einem eigenen Stapel erstellt werden):

 use DevelopmentDatabase; GO CREATE SCHEMA Dev1; GO CREATE SCHEMA Dev2; GO

Erstellen Sie zweitens den ersten Benutzer mit seinem zugewiesenen Standardschema:

 CREATE LOGIN DevLogin123 WITH PASSWORD = 'first_pass123'; CREATE USER Dev1 FOR LOGIN DevLogin123 WITH DEFAULT_SCHEMA = Dev1; GO

An diesem Punkt wäre das Standardschema für Benutzer Dev1 Dev1 .

Erstellen Sie als Nächstes den anderen Benutzer ohne Standardschema:

 CREATE LOGIN DevLogin321 WITH PASSWORD = 'second_pass321'; CREATE USER Dev2 FOR LOGIN DevLogin321; GO

Das Standardschema für Benutzer Dev2 ist dbo .

Ändern Sie nun den Benutzer Dev2 , um sein Standardschema in Dev2 zu ändern:

 ALTER USER Dev2 WITH DEFAULT_SCHEMA = Dev2; GO

Jetzt ist das Standardschema für Benutzer Dev2 Dev2 .

Dieses Skript demonstriert zwei Möglichkeiten zum Zuweisen und Ändern eines Standardschemas für einen Benutzer in Microsoft SQL Server-Datenbanken. Da SQL Server mehrere Methoden der Benutzerauthentifizierung unterstützt (die gebräuchlichste ist die Windows-Authentifizierung) und das Benutzer-Onboarding möglicherweise von Systemadministratoren und nicht von DBAs durchgeführt wird, ist die ALTER USER -Methode zum Zuweisen/Ändern des Standardschemas benutzerfreundlicher.

Hinweis: Ich habe den Namen des Schemas mit dem Namen eines Benutzers identisch gemacht. In SQL Server muss es nicht so sein, aber ich bevorzuge es, weil es (1) so aussieht wie in Oracle und (2) es die Benutzerverwaltung vereinfacht (und damit den größten Einwand eines DBAs anspricht, es richtig zu machen an erster Stelle) – Sie kennen den Namen eines Benutzers und Sie kennen automatisch das Standardschema des Benutzers.

Fazit : Öffentliche Synonyme sind ein wichtiges Werkzeug zum Aufbau einer stabilen und gut geschützten Mehrbenutzer-Entwicklungsumgebung. Leider wird es nach meiner Beobachtung in der Branche häufiger aus den falschen Gründen verwendet – was dazu führt, dass Teams unter der Verwirrung und anderen Nachteilen öffentlicher Synonyme leiden, ohne ihre Vorteile zu erkennen. Diese Praxis zu ändern, um echte Vorteile aus öffentlichen Synonymen zu ziehen, kann echte Vorteile für den Entwicklungsworkflow eines Teams bringen.

Datenbankzugriffsverwaltung und Änderungsverwaltungsprozesse

Da wir gerade über die Unterstützung der parallelen Entwicklung durch große Teams gesprochen haben, lohnt es sich, ein separates und oft missverstandenes Thema anzusprechen: Change-Control-Prozesse.

Änderungsmanagement wird oft zu einer Form von Bürokratie, die von Teamleitern und DBAs kontrolliert wird und von rebellischen Entwicklern verachtet wird, die alles liefern wollen, wenn nicht „gestern“, dann „jetzt“.

Als DBA lege ich immer wieder Schutzbarrieren auf dem Weg in „meine“ Datenbank. Und ich habe einen sehr guten Grund dafür: Eine Datenbank ist eine gemeinsam genutzte Ressource.

Twittern

Im Zusammenhang mit der Quellcodeverwaltung ist das Änderungsmanagement allgemein akzeptiert, da es einem Team ermöglicht, von neuem, aber kaputtem Code zu altem, aber funktionierendem Code zurückzukehren. Aber in einem Datenbankkontext kann das Änderungsmanagement wie eine Reihe unangemessener Barrieren und Einschränkungen erscheinen, die von DBAs aufgestellt werden: Es ist purer Wahnsinn, der die Entwicklung unnötig verlangsamt!

Lassen wir dieses Entwicklergeschwätz beiseite: Ich bin DBA und werfe keine Steine ​​auf mich selbst! Als DBA lege ich immer wieder Schutzbarrieren auf dem Weg in „meine“ Datenbank. Und ich habe einen sehr guten Grund dafür: Eine Datenbank ist eine gemeinsam genutzte Ressource.

Jedes Entwicklungsteam – und jeder seiner Entwickler – hat ein sehr spezifisch definiertes Ziel und ein sehr spezifisches Ergebnis. Das einzige Ziel, das jeden Tag auf dem Schreibtisch eines DBAs liegt, ist die Stabilität der Datenbank als gemeinsam genutzte Ressource. Ein DBA hat die einzigartige Rolle in einer Organisation, alle Entwicklungsbemühungen aller Teams zu überwachen und eine Datenbank zu kontrollieren, auf die alle Entwickler zugreifen. Es ist der DBA, der sicherstellt, dass alle Projekte und alle Prozesse ablaufen, ohne sich gegenseitig zu stören, und dass jeder über die erforderlichen Ressourcen verfügt, um zu funktionieren.

Das Problem ist, wenn sowohl Entwicklungs- als auch DBA-Teams in ihren jeweiligen Elfenbeintürmen sitzen.

Entwickler wissen es nicht, haben keinen Zugriff und kümmern sich nicht einmal darum, was mit der Datenbank passiert, solange sie für sie einwandfrei läuft. (Es ist weder ihre Leistung, noch wird sie ihre Leistungsbewertung beeinflussen.)

Das DBA-Team hält die Datenbank geheim und schützt sie vor Entwicklern, die „nichts wissen“, weil ihr Teamziel die Datenbankstabilität ist. Und der beste Weg, um Stabilität zu gewährleisten, besteht darin, destruktive Änderungen zu verhindern – was häufig zu einer Haltung führt, die Datenbank so weit wie möglich vor Änderungen zu schützen.

Diese widersprüchlichen Einstellungen gegenüber einer Datenbank können, wie ich gesehen habe, zu Feindseligkeiten zwischen Entwicklungs- und DBA-Teams führen und zu einer nicht funktionsfähigen Umgebung führen. Aber DBAs und das Entwicklungsteam müssen zusammenarbeiten, um ein gemeinsames Ziel zu erreichen: eine Geschäftslösung zu liefern, was sie überhaupt zusammengebracht hat.

Da ich auf beiden Seiten der Entwickler-DBA-Kluft war, weiß ich, dass das Problem einfach zu lösen ist, wenn DBAs die gemeinsamen Aufgaben und Ziele von Entwicklungsteams besser verstehen. Auf ihrer Seite müssen Entwickler eine Datenbank nicht als abstraktes Konzept, sondern als gemeinsam genutzte Ressource sehen – und da sollte ein DBA die Rolle eines Pädagogen übernehmen.

Der häufigste Fehler, den Nicht-Entwickler-DBAs machen, ist die Einschränkung des Entwicklerzugriffs auf das Datenwörterbuch und auf Code-Optimierungstools. Der Zugriff auf Oracle DBA_ Katalogansichten, dynamische V$ -Ansichten und SYS -Tabellen erscheint vielen DBAs als „privilegierter DBA“, obwohl es sich tatsächlich um kritische Entwicklungstools handelt.

Dasselbe gilt für SQL Server, mit einer Komplikation: Der Zugriff auf einige Systemansichten kann nicht direkt gewährt werden, ist jedoch nur Teil der Datenbankrolle SYSADMIN , und diese Rolle sollte niemals außerhalb des DBA-Teams gewährt werden. Dies kann gelöst werden (und sollte im Fall der Migration eines Projekts von Oracle zu SQL Server gelöst werden), indem Ansichten und gespeicherte Prozeduren erstellt werden, die unter SYSADMIN -Berechtigungen ausgeführt werden, aber für Nicht-DBA-Benutzer zugänglich sind. Dies ist die Aufgabe des Entwicklungs-DBAs , wenn eine neue SQL Server-Entwicklungsumgebung konfiguriert wird.

Datenschutz ist eine der Hauptaufgaben eines DBA. Trotzdem ist es durchaus üblich, dass Entwicklungsteams vollen Zugriff auf ungefilterte Produktionsdaten haben, um eine datenbezogene Ticket-Fehlerbehebung zu ermöglichen. Dies sind die gleichen Entwickler, die eingeschränkten Zugriff auf Datenstrukturen haben – Strukturen, die von ihnen oder für sie erstellt wurden.

Wenn angemessene Arbeitsbeziehungen zwischen Entwicklungs- und DBA-Teams hergestellt werden, wird die Erstellung eines guten Änderungssteuerungsprozesses intuitiv. Die Besonderheit und Herausforderung des datenbankseitigen Änderungsmanagements ist die gleichzeitige Starrheit und Fluidität einer Datenbank – die Struktur ist starr, die Daten sind fließend.

Es kommt häufig vor, dass das Änderungsmanagement für Strukturänderungen – dh für die Datendefinitionssprache oder DDL – gut etabliert ist, während Datenänderungen wenig bis gar kein Änderungsmanagement aufweisen. Die Begründung ist einfach – Daten ändern sich ständig.

Aber wenn wir uns das genauer ansehen, werden wir sehen, dass in jedem System alle Daten in eine von zwei Kategorien fallen: Anwendungsdaten und Benutzerdaten.

Anwendungsdaten sind ein Datenwörterbuch, das das Verhalten einer Anwendung definiert und für ihre Prozesse genauso wichtig ist wie jeder Anwendungscode. Änderungen an diesen Daten sollten genau wie alle anderen Anwendungsänderungen strengen Änderungskontrollprozessen unterliegen. Um Transparenz im Change-Control-Prozess für Anwendungsdatenänderungen zu schaffen, sollten die Anwendungsdaten und die Nutzerdaten explizit getrennt werden.

In Oracle sollte dies erfolgen, indem Anwendungs- und Benutzerdaten jeweils in einem eigenen Schema platziert werden. In Microsoft SQL Server sollte dies erfolgen, indem jede in ein separates Schema oder – viel besser – in eine separate Datenbank platziert wird. Diese Entscheidungen sollten Teil der Migrationsplanung sein: Oracle hat eine zweistufige Namensauflösung (Schema/Eigentümer – Objektname), während SQL Server eine dreistufige Namensauflösung hat (Datenbank – Schema/Eigentümer – Objektname).

Die korrekte Trennung von Anwendungs- und Benutzerdaten ermöglicht es einem DBA-Team, sein zweitwichtigstes Anliegen anzugehen: die Sicherheit der Benutzerdaten. Da Benutzerdaten separat gespeichert werden, ist es sehr einfach, bei Bedarf ein Break-Glass-Verfahren für den Zugriff auf Benutzerdaten zu implementieren.

Fazit : Change-Control-Prozesse sind in jedem Projekt von entscheidender Bedeutung. Im Software Engineering wird das Change Management auf Datenbankseite oft vernachlässigt, weil Daten als „zu flüssig“ gelten. Aber gerade weil Daten „fließend“ und „persistent“ zugleich sind, sollte ein gut konzipierter Änderungskontrollprozess der Eckpfeiler einer angemessenen Datenbankumgebungsarchitektur sein.

Zur Verwendung von Codemigrationstools

Die Standardtools von Erstanbietern, Oracle Migration Workbench und SQL Server Migration Assistant, können bei Codemigrationen hilfreich sein. Was jedoch berücksichtigt werden muss, ist die 80/20-Regel: Wenn der Code zu 80 % korrekt migriert wird, werden die verbleibenden 20 % 80 % Ihres Migrationsaufwands in Anspruch nehmen.

Das mit Abstand größte Risiko beim Einsatz von Migrationstools ist die „Silver Bullet“-Wahrnehmung. Man könnte versucht sein zu denken: „Es wird den Job machen, und ich muss nur ein bisschen aufräumen und aufräumen.“ Ich habe ein Projekt beobachtet, das aufgrund einer solchen Einstellung des Konvertierungsteams und seiner technischen Leitung gescheitert ist.

Andererseits habe ich vier Arbeitstage gebraucht, um die grundlegende Konvertierung eines mittelgroßen Microsoft SQL Server 2008-Systems (etwa 200 Objekte) mit der Bulk-Replace-Funktionalität von Notepad++ als Hauptbearbeitungstool durchzuführen.

Keines der kritischen Migrationselemente, die ich bisher angesprochen habe, kann durch Migrationstools gelöst werden.

Sicher, verwenden Sie Tools zur Migrationsunterstützung, aber denken Sie daran, dass diese nur Unterstützung beim Bearbeiten bieten. Der resultierende Ausgabetext muss überprüft, modifiziert und – in einigen Fällen – umgeschrieben werden, um produktionstauglicher Code zu werden.

Die Entwicklung von Tools für künstliche Intelligenz könnte diese Mängel der Migrationstools in Zukunft beheben, aber ich würde erwarten, dass die Unterschiede zwischen den Datenbanken vorher verschwimmen und jeder Migrationsprozess selbst unnötig wird. Solange diese Art von Projekten benötigt wird, müssen wir es also auf die alte Art und Weise tun, indem wir altmodische menschliche Intelligenz verwenden.

Fazit : Die Verwendung von Tools zur Migrationsunterstützung ist hilfreich, aber kein Wundermittel, und jedes Konvertierungsprojekt erfordert immer noch eine detaillierte Überprüfung der oben genannten Punkte.

Oracle/SQL Server-Migrationen: Immer genau hinschauen

Oracle und Microsoft SQL Server sind die beiden am weitesten verbreiteten RDBMS-Plattformen in der Unternehmensumgebung. Beide sind grundsätzlich mit dem ANSI-SQL-Standard kompatibel, und kleine Codesegmente können mit sehr geringen Änderungen oder sogar so wie sie sind übertragen werden.

Diese Ähnlichkeit erweckt den trügerischen Eindruck, dass die Migration zwischen den beiden Plattformen eine einfache, unkomplizierte Aufgabe ist und dass dieselbe Anwendung problemlos von einem RDBMS-Backend auf ein anderes übernommen werden kann.

In der Praxis sind solche Plattformmigrationen alles andere als trivial und müssen die feinen Elemente des Innenlebens jeder Plattform und vor allem die Art und Weise berücksichtigen, wie sie die Unterstützung für das kritischste Element des Datenmanagements implementieren: Transaktionen.

Obwohl ich zwei RDBMS-Plattformen behandelt habe, die den Kern meiner Expertise ausmachen, sollte die gleiche Warnung – „Ähnliches Aussehen bedeutet nicht, dass es gleich funktioniert“ – auf das Verschieben von Code zwischen anderen SQL-kompatiblen Datenbankverwaltungssystemen angewendet werden. Und in allen Fällen sollte das erste Augenmerk darauf gerichtet werden, wie sich die Implementierung des Transaktionsmanagements zwischen Quell- und Zielplattform unterscheidet.