Migration von SQL Server auf MariaDB (oder MySQL)

Es geht hier nicht um die Webseite und deren DB-Anbindung, sondern einzig und allein darum, die nach MariaDB migrierten Tabellen etc. während der Migrationsphase weiterhin für den SQL-Server verfügbar zu halten. Hierbei interessieren mich die datenbanktechnischen Aspekte dieses Migrationsweges. Beispielsweise solche Hinweise wie der auf Probleme mit STRICT stehen für mich im Fokus.
Die Erwähnung der Webseite diente hingegen nur der kursorischen Beschreibung der Anwendungssituation, weshalb diese Beschreibung aus meiner Sicht auch so allgemein bleiben kann. Darauf hatte ich auch explizit hingewiesen:

Ja so in etwa wird/soll das am Ende sein, dass vereinfacht ausgedrückt nach der Migration der Datenbank "nur" die Zugriffsschicht von SQL Server auf MariaDB gewechselt wird.


Datenbank = SQL Server for Linux 2019 (Version 15.0.4343)

Das würde doch aber laut der Übersichtsbeschreibung von EF Core bei Microsoft bedeuten, ich müsste auf der Ebene von ASP.NET bzw. der Webseite agieren. Und nach meinem Verständnis wird das eher nicht wirklich bei der Migration der Datenbank helfen, weil ein erheblicher Teil der Daten-Logik in der Datenbank selbst, unter anderem über Computed Column und Gespeicherte Prozeduren abgebildet ist. Gerade diese Daten-Logik soll ebenfalls zu MariaDB migriert werden. Immerhin hat MariaDB äquivalente Datenbankfunktionen implementiert.

Was könnte zudem EF Core, was nicht (viel zielgenauer) mit DBeaver möglich wäre? Immerhin sind für die Datenbankobjekte entweder explizite SQL-Script-Dateien vorhanden oder die SQL-Scripte können im SQL Studio ganz einfach generiert werden. Diese SQL-Scripte auf MariaDB anzupassen und dann für die Migration einzusetzen, dürfte doch naheliegender sein, oder? Hierbei darf nicht übersehen werden, dass in DBeaver gleichsam wie bisher in SQL Studio die SQL-Scripte relative einfach getestet werden können. Gerade bei gespeicherten Prozeduren ist das äußerst hilfreich.

Viele Grüße
HansDampf06

Je nachdem wie man es nimmt. Augenscheinlich unterstützt die Linux-Version per SQL Studio das nur für einen anderen SQL Server als Datenquelle nativ. Jedoch kann per T-SQL ein solcher Linked Server auf MariaDB erstellt werden. Hier zeigt sich wieder einmal die Halbherzigkeit von Microsoft

Aktuell liegt das Problem eher darin, dass auf der Linux-Ebene der ODBC-Treiber von MariaDB zwar laut Beschreibung auf mariadb.com installiert und konfiguriert wurde, aber an der Linux-Konsole isql keine Verbindung aufbauen kann. Sobald dieses Problem überwunden ist, gibt aus meiner Sicht keinen wirklichen Grund, eine Linked-Server-Verbindung unter Linux als abenteuerlich zu bewerten. Es funktioniert ja dann wie technisch vorgesehen und ist keine krude Bastelei. Ein solche Verknüpfung von unterschiedlichen Datenquellen ist ja auch ein ganz normales Szenario.

Auch der Hinweis von @ukulele-7 auf mögliche Performanceprobleme erscheint mir nicht als tauglicher Grund für eine Abenteuerlichkeit, sondern liegt nach meinem Verständnis schlicht in der Natur der Sache. Denn eine solche Datenverbindung kann niemals so performant sein wie der Zugriff auf von SQL Server direkt gehostete Datenbankobjekte. Der Fernzugriff auf die andere Datenquelle muss immer zwingend mit Leistungseinbußen einhergehen, auch wenn sie nicht unbedingt spürbar werden müssen.

Oder was ist für Dich der Grund, dies als abenteuerlich einzuschätzen?

Darin stimmen wir überein.
Bestens, dann stimmen wir auch hierin überein.

Die Frage ist gar nicht so einfach zu beantworten, weil jedes Datenbanksystem seine Vor- und Nachteile hat – irgendwann muss man sich entscheiden. Die drei wichtigsten Entscheidungskriterien waren, dass erstens bereits praktisches Wissen / Erfahrung mit MySQL vorhanden ist. Zweitens ergab sich aus unterschiedlichen Vergleichsbewertungen von Dritten die eigene Einschätzung, dass der Fork MariaDB die zukunftsträchtigere Variante gegenüber MySQL zu sein scheint. Drittens soll der Wechsel des Datenbanksystems nicht vom „Regen in die Traufe“ führen, weil Oracle hier ähnlich destruktiv wie Microsoft eingeschätzt wird; unter anderem deswegen werden ja die Microsoft-Produkte so weit wie möglich ersetzt.

Nein, in Bezug auf Daten derzeit nicht. Ein Dateizugriff erfolgt bisher über die Logik der Webseite. Insoweit bezieht sich die Migration ausschließlich auf die Datenbank als solche.
Die SQL-Server-internen Wartungsfunktionen für die Datenbank, z.B. Backup und Indexpflege werden über die Steuerungslogik der Webseite mittels Backgroundworkern durch den dynamischen Aufruf von gespeicherten Prozeduren angestoßen. Die Backup-Dateien werden in der Verzeichnisstruktur der Datenbank in einem dedizierten Verzeichnis abgelegt. Gewiss werden diese Wartungsfunktionen eher nicht ohne weiteres übernehmbar sein, sondern wohl von Grund auf neu erstellt werden müssen. Aber das ist in Ordnung.

Der eigentliche Gedanke ist, immer blockweise vorzugehen. Es werden zunächst die Tabellen migriert, die einen engeren thematischen Zusammenhang haben. Das wird zwangsläufig zur Anpassung der zugehörigen Sichten, Funktionen und Prozeduren auf dem SQL-Server führen (müssen), sofern deren gleichzeitige Migration nicht sinnvoller ist. Ist ein solcher Block abgeschlossen, muss in der Webseite lediglich das/die entsprechende(n) SQL-Statement(s) auf MariaDB angepasst werden. Das hält insgesamt den Arbeitsaufwand auf dem geringst möglichen, unumgänglichen Maß.

Ursprünglich war die Webseite mit einer Access-Datenbank gestartet und wurde dann auf SQL-Server umgestellt. Diese Umstellung war damals äußerst arbeitsintensiv, weil sich die gesamte Daten-Logik bei der Webseite befand – hierin wurde damals ein erhebliches Ärgernis gesehen. Die Überführung der Daten-Logik nach SQL Server war abermals erheblich arbeitsintensiv, aber führte zu einer spürbaren Leistungssteigerung. Daneben wurde die Voraussetzung geschaffen, dass die Daten-Logik für die Webseite weitestgehend transparent ist und die Migration der Webseite von IIS nach Linux (Apache / Nginx) nicht unbedingt an das Mono-Projekt gebunden ist. Zugleich wird so eine schrittweise Migration der Webseite wesentlich einfacher machbar sein.

Warum schrittweise? Eine 1:1-Hauruck-Umstellung hat den ganz großen Nachteil, dass in der Tat alles auf einmal und sofort erfolgen muss. Dass ist hier schon von den vorhandenen Ressourcen her nicht darstellbar. Außerdem müssen dann auch etwaige unerwartete Probleme sofort behoben werden. Sollte das nicht sofort gelingen, wäre das ebenfalls nicht vertretbar. Demgegenüber hat die schrittweise Umstellung den Vorteil, dass bei etwaigen nicht sofort lösbaren Problemen der problematischen Migrationsschritt einfach rückgängig gemacht werden kann. Die Webseite mit ihrem Zugriff auf den SQL Server funktioniert ja dann immer noch wie zuvor.

Aber vielleicht komme ich auch zu der Erkenntnis, dass die Umstellung der Datenbank nur in einer 1:1-Hauruck-Aktion vernünftig machbar ist. Das wird vor allem davon abhängen, was über die Linked-Server-Verbindung überhaupt unterstützt wird und was sinnvoll funktioniert. Das betrifft vor allem die gespeicherten Prozeduren und Funktionen. Hier stehe ich ja erst am Anfang des Vorhabens. Deswegen hast Du mit:
völlig Recht. So ähnlich war das damals gelaufen: Zuerst mit einem Übertragungsassistenten von Access nach SQL Server die Tabellen und Abfragen übertragen. In der Webseite wurde ein parallel möglicher Datenbankzugriff eingerichtet. Der Erinnerung nach gab es noch eine direkte Datenverbindung von Access auf SQL Server vergleichbar mit dem Linked Server, um die Datenkonsistenz und -eindeutigkeit sicherzustellen. Sodann konnten in der Webseite die SQL-Statements auf die Syntax des SQL Servers und den Zugriff auf den SQL Server nacheinander umgestellt werden.

Viele Grüße
HansDampf06

PS: Ein alternativer Gedanke wäre, die Datenverbindung nicht vom SQL Server aus auf MariaDB zu erstellen, sondern umgekehrt von MariaDB aus. Das könnte mir vielleicht sogar besser gefallen, weil dann der SQL Server, sofern er nicht direkt von der Webseite angesprochen wird, eigentlich nur noch lesend zur Verfügung stehen müsste. Die neuen Daten werden dann ja schon in MariaDB gespeichert. Eine nähere Betrachtung ist das in jedem Fall wert.

@opsec2022
Besten Dank für Deine vielfältigen Anregungen in Deinem letzten Kommentar. Diese werde ich gewiss näher berücksichtigen, wenn es der Webseite migrationsmäßig "an den Kragen geht". Jedoch muss ich das Vorgehen abschichten. Und der Schwerpunkt liegt zunächst auf der Datenbank.

Nur so viel an dieser Stelle: Du beschreibst verschiedene Techniken, wie seitens einer Webseite mit einer Datenbank umgegangen werden kann. Welche Technik gewählt wird, hängt zu einem großen Teil davon ab, wo welche Schwerpunkte der Daten-Logik liegen. Liegen diese wie ursprünglich bei der Webseite, stellt sich die Datenbank letztlich im Kern nur noch als das Vorhalten der Tabellen dar. Ist die Daten-Logik hingegen in die Datenbank integriert, so können dort alle Möglichkeiten eines modernen Datenbanksystems gehoben werden, was insbesondere der Leistung zugutekommen dürfte – z.B. das Wirken des Abfrageoptimierers. Freilich ist auch eine Mischform dazwischen möglich. Nach dem Wechsel von Access auf SQL Server ist damals die Entscheidung getroffen worden, die Daten-Logik gehört in die Datenbank und das wird wohl auch beibehalten werden. Denn die Webseite greift auf die Datenbank transparent zu.
Je nach Technikansatz besteht der Vorteil dieser Transparenz darin, dass sich der Programmieraufwand für die Webseite letztlich auf simple SQL-Statements mit einem Prozeduraufruf und Parameterübergabe beschränkt. Ist der Zugriff derart minimalistisch reduziert, dürften die Unterschiede zwischen den Techniken gegen Null tendieren. Dennoch wird bei der späteren Migration der Webseite zu prüfen sein, welche der Techniken den Vorzug verdient. Immerhin kommt es auch dabei auf die bestmögliche Leistung für einen schnellen Seitenaufbau an.

Viele Grüße
HansDampf06

@ukulele-7:
Ich will doch noch einmal nachfragen, weil insoweit noch nichts in Stein gemeißelt ist:
Was wären für Dich die relevanten Aspekte, PostgreSQL gegenüber MariaDB(/MySQL) vorzuziehen?

Viele Grüße
HansDampf06

EDIT:
Dieser Vergleich macht plastisch deutlich, wie schwer es ist, eine Entscheidung zwischen PostgreSQL und MariaDB zu treffen. Gerade der Kostenaspekt, nämlich dass bestimmte Vorkenntnisse bereits vorhanden sind, dürfte wie geschehen das "Zünglein an der Waage" sein. Gleichwohl legt dieser Vergleich nahe, schlicht mit einem der beiden Datenbanksysteme bei der Migration zu beginnen. Sollten die dabei entstehenden Probleme als sehr groß einzuschätzen sein oder die Erwartungen nicht wie gewünscht erfüllt werden, kann eine Konkurrenzinstallation mit dem anderen System und ein konkreter Vergleich erfolgen. Vor allem dann wird sich das avisierte schrittweise Vorgehen als äußerst effektiv erweisen.

Hinsichtlich des OBDC-Treiberproblems bin ich einen Schritt weiter. Ausweislich dieser und dieser Webseite kocht Microsoft wieder einmal sein eigenes Süppchen und bringt einen eigenen unixODBC-Treibermanager mit. Dann wundert es mich nicht, wenn der MariaDB-ODBC-Treiber trotz korrekter Installation nicht funktionieren will.

Zum SQL-Server-ODBC-Treiber von Microsoft gibt es wohl FreeTDS als Alternative. Mal sehen, ob es dann auch parallel mit MariaDB über ODBC klappt.

EDIT:
Das Problem ist beseitigt. Für MariaDB wurde zunächst der ODBC-Treiber Version 3.1.20 von mariadb.com heruntergeladen und installiert. Indes fehlten dieser Version mehrere Abhängigkeiten. Bei der Lösungssuche bin ich darauf gestoßen, dass es im offiziellen Ubuntu-20.04-Repository das Paket odbc-mariadb gibt, welches die Version 3.1.4 hat. Nachdem dieses Paket installiert worden ist, klappte es auch parallel zum Microsoft-ODBC17-Treiber mit dem parallelen Zugriff durch isql.

Viele Grüße
HansDampf06

Folgende Erkenntnis, die die bereits mitgeteilte Aussage von dritter Seite bestätigt:
Bei der Linux-Version von SQL Server ist eine Linked-Server-Verbindung nur zu einem anderen SQL Server möglich. Der von dritter Seite vorgeschlagene Provider SQLNCLI lässt nichts anderes zu. Wird ein anderer Provider wie in odbcinst.ini hinterlegt verwendet, gibt es eine Fehlermeldung, die auf die Ausschließlichkeit für diese Linux-Version hinweist.

Somit ist die Funktion Linked Server in der Linux-Version nicht abenteuerlich, sondern vielmehr schlicht unmöglich, soweit es andere Datenbankquellen betrifft als SQL Server.

Hierdurch ist die Entscheidung über den einzuschlagenden Migrationspfad von Microsoft für die Linux-Version vorentschieden worden. Und zwar erfolgt die Migration aus MariaDB heraus, indem über die CONNECT Engine auf die von SQL Server gehaltenen Daten zugegriffen wird. Ohnehin soll wohl die CONNECT Engine einige Vorteile gegenüber der Funktion Linked Server bieten, wie ich verschiedentlich gelesen habe.

Es wird dadurch jetzt neu zu überlegen sein, in welchen konkreten Schritten die Migration der Datenbankobjekte zu verwirklichen ist.

Viele Grüße
HansDampf06

@ukulele-7:
Besten Dank für Deine ausführliche Antwort.

Du hast Recht, die Webseite ist kein Baukastenableger, sondern eine gewachsene Eigenentwicklung. Schon immer ging es um die Datenbank - die Webseite war von Anfang an "nur" als plattformunabhängige Bedienungsoberfläche für diese Datenbank gedacht. Deswegen wurde nach dem ersten Datenbankwechsel die Daten-Logik schließlich in die Datenbank verlagert, weil das mittels der gespeicherten Prozeduren und Funktionen überhaupt erst möglich wurde. Zugleich ist das der Grund, warum die Daten-Logik aus heutiger Sicht auch in Zukunft in der Datenbank verbleiben wird.

Hinsichtlich der von Dir verlinkten Forumsdiskussion kann ich Dir noch (m)einen Erfahrungstipp geben, den ich Dir per PN sende.

Viele Grüße
HansDampf06

Ein kurzes Update:
Der Zugriff von MariaDB auf den SQL Server über die CONNECT Engine klappt seit vorgestern Abend bestens. Es muss nach meinem aktuellen Kenntnisstand für jede Tabelle des SQL Servers eine Tabelle bei MariaDB deklariert werden, die eine Art Platzhalter für den Remotezugriff darstellt. Entweder lässt man dabei die Spalten automatisch übernehmen oder gibt sie explizit an. Bei letzterem kann dann sogar ein Primärindex mit angelegt werden. Ebenso dürften im Nachhinein noch Indizes zu diesen Platzhaltertabellen hinzugefügt werden können.

Weil beide Datenbanken auf der selben VM installiert sind, ist der Datenaustausch augenscheinlich außerordentlich schnell.

DBeaver scheint daneben nicht nur für MariaDB, sondern auch für SQL Server ein brauchbares Instrument zu sein (anstelle von SQL Studio). Jedenfalls kann so die unvermeidliche Handarbeit der Migration in einer Oberfläche bei gleichzeitigem Zugriff auf beide Datenbanken erfolgen. Auf diese Art und Weise können die bei DBeaver als DDL bezeichneten SQL-Scripte für die zu migrierenden Datenbankobjekte jeweils entnommen und gleich bei der Erstellung des neuen künftigen migrierten Objekts in MariaDB weiterverwendet werden. Freilich muss vor dem Speichern des migrierten Objekts die Scriptsyntax noch überarbeitet werden.

Die Hauptlast der Handarbeit für die Migration wird sowieso in der Syntaxanpassung und dem Ausgleich von in SQL Server genutzten, aber in MariaDB fehlenden Funktionalitäten liegen. So kennt MariaDB beispielsweise keine zur Laufzeit deklarierten Tabellenvariablen, sondern nur temporäre Tabellen, die obendrein auch noch eine sitzungsbezogene Lebenszeit haben und keine bloß prozedurbezogene Lebenszeit. Also müssen auch die bisherigen konzeptionellen Ansätze überdacht werden, damit während der Laufzeit bei einem mehrfachen parallelen Aufruf von Prozeduren etc. keine wechselseitigen Behinderungen und Datenverfälschungen entstehen ...

Viele Grüße
HansDampf06

Ein neues kurzes Update:
Der erste Block der alten Datenbank, zu dem sechs Tabellen und drei gespeicherte Prozeduren gehören, ist migriert. Das heißt, es sind die Verknüpfungen für die einzelnen Tabellen zur alten Datenbank eingerichtet, die sechs Tabellen in der neuen Datenbank angelegt und die gespeicherten Prozeduren syntaktisch umgeschrieben. Somit könnte die neue Datenbank mit diesem Block theoretisch der Webseite im vollen Umfang zur Verfügung stehen. Hierfür fehlt aber noch die Etablierung der entsprechenden Connection auf die neue Datenbank in der Webseite und die dortige Anpassung des jeweiligen Datenzugriffs auf diese neue Connection.

Bevor der Zugriff durch die Webseite überhaupt losgehen kann, müssen ersteinmal die Daten zwischen den Datenbanken transferiert werden. Dabei zeigt sich, dass die Verknüpfung von der neuen zur alten Datenbank durchaus keinen Leistungspreis gewinnen wird. Während beispielsweise die Abfrage der Anzahl der Datensätze einer Tabelle sowohl in der einen als auch in der anderen Datenbank relativ flott geschieht, benötigt die Abfrage über die Verknüpfung doch einiges mehr an Zeit. Das wird insbesondere bei der einen Tabelle relevant, die aktuell immerhin knapp 72,5 Mio Datensätze hat ...
Außerdem werden nach dem Datentransfer noch die logische Fehlerfreiheit und die Ergebnisgleichheit der umgeschriebenen Prozeduren zu testen sein, bevor dieser Block produktiv nutzbar wird.

Ein erstes Credo der bisherigen Migration: Es ist wegen der unumgänglichen Handarbeit teilweise sehr mühselig. Die kleinen Syntaxunterschiede sind teilweise eigentlich nur kosmetisch, aber dennoch zwingend und nervig. Zudem sind die Fehlermeldungen der neuen Datenbank, dass ein Syntaxfehler vorliegt, durchgehend wenig hilfreich - hier scheint SQL Server doch komfortabler zu sein. Also ist viel zu googeln, um sich die neue Syntax und deren Eigenheiten umfassend zu erschließen. Natürlich ist mit fortschreitendem Kenntnis- und Erfahrungsschatz eine Beschleunigung gut spürbar. Auch kristallieren sich erste neue Lösungsmuster heraus, die konstante Arbeitsergebnisse sicherstellen ...

Relevante Themen sind unter anderem:
(1.) Wie bereits erwähnt keine Tabellenvariablen möglich, so dass mit temporären Tabellen gearbeitet werden muss.
(2.) Sind wohl nicht alle bei SQL Server eingebauten Funktionen unter MariaDB verfügbar, so dass diese als gespeicherte Funktion / Prozedure selbst erstellt werden müssen. Hier müssen konzeptionelle Überlegungen auf lange Sicht angestellt werden.

Viele Grüße
HansDampf06

So, meine Lieben!

Der zweite Migrationsschritt ist insoweit vollbracht, als nunmehr in der Webseite der Zugriff auf MariaDB integriert ist (siehe IIS und ASP.NET: MariaDB als Dataprovider verwenden). Damit muss nur noch die DoWork-Routine des einen Backgroundworkers angepasst werden und der erste Migrationsblock kann in die funktionale Testphase gehen.

Wie ich bereits skizziert hatte, wurde die Webseite vor langer Zeit von MS Access auf MS SQL Server umgestellt. Aufgrund der damals integrierten (und seither belassenen) besonderen Codestruktur, um die Webseite sukzessive auf die neue Datenbank umstellen zu können, brauchte ich jetzt lediglich die neueste Datenbankverbindung dem betreffenden Connection-Array hinzuzufügen und die beiden Routinen für das Öffnen und Schließen der Datenbankverbindungen zu ergänzen.
Würden SQL Server und MariaDB syntaktisch identisch sein (z.B. nicht "CALL" anstelle von "EXECUTE" für das Ausführen von gespeicherten Prozeduren), wäre damit quasi die Umstellung der Webseite bereits vollzogen. Allein der Indexparameter für das genannte Array müsste dann noch an der jeweiligen Stelle im Code geändert werden, sobald die zugehörigen Tabellen / Prozeduren etc. in die neue Datenbank migriert sind.

Der bereits erwähnte Leistungsunterschied einmal in Zahlen:
Führe ich auf beiden Datenbanken folgenden SQL-Code
für die beschriebene Tabelle mit den sehr vielen Datensätzen (aktuell ca. 89 Mio.) aus, dann benötigt SQL Server ca. 1 Minute 35 Sekunden (in DBeaver; in SQL Studio ebenso), während MariaDB mit nur ca. 40 Sekunden signifikant schneller ist. Führe ich den Befehl über die CONNECT-Datenverbindung aus, dann dauert das Ganze sogar ca. 26 bis 30 Minuten (mindestens, meist länger). Wohlgemerkt: Beide DB-Server laufen auf derselben VM und die beiden Datenbanken liegen auf derselben VDisk, so dass der objektive Rahmen identisch ist.

Bestünde denn eigentlich Interesse an meinen weiteren Erfahrungen bei dieser Migration? Sollte ich diese vielleicht in einer Beitragsserie teilen?

Viele Grüße
HansDampf06