MariaDB 12.0: Features, Update-Risiken und Hosting-Strategie

MariaDB 12.0 korrekt einordnen

Die Bezeichnung „MariaDB 12“ beschreibt keinen einheitlichen, dauerhaft gepflegten Produktstand. Für konkrete technische Aussagen ist hier die Rolling-Serie MariaDB 12.0 gemeint. Innerhalb dieser Serie markieren die Veröffentlichungen unterschiedliche Reifegrade: 12.0.0 erschien am 26. März 2025 als Preview, 12.0.1 am 5. Juni 2025 als Release Candidate und 12.0.2 am 7. August 2025 als stabiler GA-Release.

Preview und Release Candidate dienen der Erprobung und sind nicht mit einem stabilen Plattformziel gleichzusetzen. Dass 12.0.2 als Stable beziehungsweise GA dokumentiert ist, beschreibt dagegen den Reifestatus genau dieses Releases. Daraus folgt weder, dass jede Installation sofort umgestellt werden sollte, noch dass spätere Serien automatisch dieselben Eigenschaften, Pakete oder Betriebsgrenzen besitzen.

Auch spätere Zweige wie 12.1, 12.2 oder 12.3 müssen getrennt betrachtet werden. Funktionen, Fehlerkorrekturen oder geänderte Standardwerte aus solchen Serien sind kein Nachweis für MariaDB 12.0. Das gilt ebenso für Entwicklungszweige: Eine Ankündigung oder Dokumentation dort ersetzt keine Aussage über einen veröffentlichten Community-Server-Stand.

Vor einem Rollout braucht die Plattform deshalb einen erneuten Abgleich des tatsächlich vorgesehenen Paketstands. Zu prüfen sind insbesondere die verfügbare Serverserie, zueinander passende Client- und Zusatzpakete, die Unterstützung durch die eingesetzte Betriebssystemversion sowie die aktuelle Release-Einstufung. Repository-Inhalte und Distributionspakete können von der allgemeinen Produktbezeichnung abweichen.

Rolling Release und LTS unterscheiden

Für Hosting-Plattformen ist nicht nur die Versionsnummer relevant, sondern das zugrunde liegende Release-Modell. MariaDB unterscheidet Innovation Releases von LTS-Releases. Innovation Releases bringen neue Funktionen in kurzen Abständen und folgen nach ihrem GA-Stand im Regelfall dem Weg zur nächsten Rolling-Serie. LTS-Releases werden dagegen laut Hersteller drei Jahre ab GA gepflegt.

Ein stabiler GA-Release beantwortet damit nur die Frage, ob dieser konkrete Stand als stabil veröffentlicht wurde. Er beantwortet nicht pauschal, wie lange Sicherheitskorrekturen bereitstehen, ob ein Distributor weiterhin Pakete liefert oder ob ein bestehender Kundenbestand ohne Migration auf der Serie bleiben kann. Diese Punkte hängen vom Vertrag, der Distribution und der aktuellen Release-Übersicht ab.

Eine Innovationsserie kann angemessen sein, wenn eine Plattform eine klar benötigte Funktion früh einsetzen möchte und die betroffenen Anwendungen, Connectoren sowie Betriebsabläufe isoliert testen kann. Dafür müssen Teams einplanen, den vorgesehenen Upgrade-Pfad zeitnah weiterzugehen. Besonders bei mandantenfähigen Angeboten erhöht dies den Aufwand für Freigaben, Kommunikation und Rückfallverfahren.

Ein LTS-Zielstand passt eher zu standardisierten Plattformen mit vielen klassischen Anwendungen, wenn planbare Wartungsfenster und ein länger stabiler Softwarestand wichtiger sind als einzelne neue Funktionen. Das ist keine Regel gegen Innovation Releases: Entscheidend ist, ob der Nutzen einer Funktion die zusätzlichen Tests und den erwartbaren Wechsel zur Folgeserie rechtfertigt.

Die Auswahl sollte daher mindestens Funktionsbedarf, aktuelle Paket- und Supportlage, getestete Anwendungskompatibilität, Wiederherstellbarkeit und personellen Betriebsaufwand berücksichtigen. Für eine Neuinstallation genügt es nicht, „MariaDB 12“ als modernsten Namen zu bewerten. Die Plattform entscheidet bewusst zwischen kurzfristiger Feature-Nutzung und einem langfristig standardisierten Datenbankstand.

Neue Funktionen mit Grenzen bewerten

MariaDB 12.0 ergänzt Optimizer-Hints zur gezielteren Beeinflussung von Ausführungsplänen, etwa für Join-Reihenfolgen, Range-Optimierung oder bestimmte Join-Algorithmen. Erweiterungen betreffen außerdem absteigend sortierte Indexbestandteile bei Loose Index Scan und Index Condition Pushdown. Für Hosting ist dies vor allem ein Diagnosewerkzeug für einzelne problematische Abfragen, kein Ersatz für passende Indizes, korrekte Join-Bedingungen und aktuelle Tabellenstatistiken.

Ein Hint kann einen unerwünschten Plan begrenzen, aber nach Datenwachstum oder geänderten Statistiken selbst nachteilig wirken. Er gehört deshalb in eine reproduzierbare Analyse der betroffenen Anwendung und nicht als globale Vorgabe in den database server. Für typische CMS- und Shop-Datenbanken ist allein die Verfügbarkeit solcher Hints kein überzeugender Grund für ein MariaDB-Update.

Beim Audit protokolliert das Audit Plugin in 12.0 zusätzlich Host und Port eingehender Verbindungen sowie die verwendete TLS-Version. Für Zugriffe hinter Proxys, NAT oder Load Balancern kann das die forensische Zuordnung verbessern. Der Vorteil entsteht jedoch erst durch zentrale, zugriffsgeschützte Logsammlung und festgelegte Aufbewahrungsregeln; zusätzliche Logdaten müssen in die Kapazitäts- und Datenschutzplanung passen.

Für Verschlüsselung stehen mit SHA-2-Unterstützung in file_key_management.so und ssl_passphrase Bausteine bereit. Replikationsumgebungen erhalten Optionen für temporäre Tabellen sowie eine Variable zum Umgang mit Ereignissen der eigenen Server-ID. Zusätzlich bringt 12.0 unter anderem SYS_REFCURSOR, ein Cursorlimit pro Sitzung und GIS-Funktionen wie Validierung, Vereinfachung und Geohash-Umwandlung. Diese Werkzeuge helfen jeweils nur passenden Anwendungen und Topologien.

MariaDB Server, MaxScale und Galera bleiben getrennte Komponenten: MaxScale hat eigene Versionen und Konfigurationen, Galera-relevante Änderungen betreffen ausschließlich Cluster. Ebenso bedeutet MySQL-Kompatibilität keine Austauschbarkeit ohne Prüfung. MariaDB nutzt ein eigenes GTID-Modell und unterstützt beispielsweise nicht MySQLs SET PERSIST. Neue GIS-Funktionen können MySQL-8-orientierten Geodaten-Anwendungen helfen, sind für gewöhnliche Webdatenbanken aber meist kein Upgrade-Anlass.

Releasestatus und Funktionen gegenüberstellen

Für den Plattformbetrieb ist der konkrete Stand innerhalb der Serie entscheidend. MariaDB 12.0.0 war ein Preview, 12.0.1 ein Release Candidate und erst 12.0.2 ist als Stable beziehungsweise GA dokumentiert. Diese Status markieren unterschiedliche Reifegrade; sie sind keine Aussage dazu, ob die Serie für einen bestimmten Hosting-Rollout, ein Betriebssystem oder einen Supportvertrag geeignet ist.

Neue Funktionen sind vor allem dann nützlich, wenn sie ein konkretes Betriebsproblem adressieren. Optimizer-Hints können etwa einen unerwünschten Ausführungsplan für eine einzelne komplexe Abfrage begrenzen. Sie ersetzen weder passende Indizes noch korrekte Join-Bedingungen oder aktuelle Statistiken und sollten nicht als globale Vorgabe für Kundenanwendungen eingesetzt werden.

Die zusätzlichen Auditfelder können Host, Port und verwendete TLS-Version einer eingehenden Verbindung erfassen. Die Schlüsseloption ssl_passphrase und die erweiterten GIS- oder Cursor-Funktionen rechtfertigen dagegen keinen pauschalen Versionswechsel. Ihr Nutzen entsteht nur bei Anwendungen, deren Architektur, Datenmodell und Sicherheitsvorgaben diese Fähigkeiten tatsächlich benötigen.

MariaDB-Update kontrolliert vorbereiten

Ein MariaDB-Update im Managed oder Shared Hosting beginnt mit einer Inventur: Instanzen, Datenbanken, Connectoren, Plugins, Konfigurationsdateien, Replikationswege und betroffene Anwendungen müssen bekannt sein. Danach folgt eine Staging-Umgebung, die Produktionsdaten und Konfiguration nur unter den zulässigen Schutzvorgaben abbildet. So lassen sich Startprobleme und SQL-Abweichungen erkennen, bevor mehrere Mandanten betroffen sind.

Vor jedem begrenzten Rollout braucht es ein vollständiges Backup und einen dokumentierten Wiederherstellungsablauf. Entscheidend ist nicht allein, dass Sicherungsdateien vorhanden sind: Verantwortliche müssen prüfen, ob sich daraus ein konsistenter, für Anwendungen nutzbarer Datenstand wiederherstellen lässt. Anschließend kontrollieren sie Anmeldungen, Schreibvorgänge, Hintergrundjobs und typische Kundenpfade als Anwendungs-Regression. Die konkrete Vorgehensweise hängt vom eingesetzten Sicherungsverfahren und der Plattformarchitektur ab.

Ein Rückfallplan legt fest, wer entscheidet, welche Datenstände maßgeblich sind und wie Anwendungen bei einem Abbruch wieder auf den vorherigen konsistenten Stand wechseln. Das ist redaktionelle Betriebspraxis, keine Eigenschaft einer bestimmten MariaDB-Version. Replikation, Monitoring und Failover müssen deshalb in der jeweiligen Staging-Topologie geprüft werden, statt ihre Funktion aus einem erfolgreichen Update einer Einzelinstanz abzuleiten.

MariaDB 12.0 entfernt die Systemvariablen big_tables, large_page_size und storage_engine. Vorhandene Einträge müssen daher in my.cnf und allen eingebundenen Konfigurationsfragmenten gefunden und für den Zielstand bewertet werden. Die Bereinigung gehört vor das Paketupdate; bei large_page_size ist zusätzlich zwischen der entfernten MariaDB-Variable und einer davon unabhängigen HugePages-Konfiguration des Betriebssystems zu unterscheiden.

Auch die Paketplanung verdient einen eigenen Schritt: Ein Repository kann mehrere MariaDB-Stände enthalten, und zusammengehörige Server-, Client-, Shared- und Common-Pakete sollten versionsgleich vorgesehen werden. Betriebssystemstand und Paketquellen sind dabei Bestandteil der Freigabe. Für Abhängigkeiten auf Host-Ebene liefert der Beitrag zu relevanten Neuerungen für Hosting-Server unter Linux Kernel 6.x zusätzlichen Kontext; er ersetzt jedoch nicht die Datenbank-spezifische Staging-Prüfung.

Spezialfälle sicher konfigurieren

Bei instabilen Reporting-Abfragen sollte die Diagnose mit Ausführungsplänen, Indizes, Join-Bedingungen und Tabellenstatistiken beginnen. Erst wenn ein unerwünschter Plan reproduzierbar eingegrenzt ist, kann ein Optimizer-Hint eine gezielte Begrenzung sein. Der Hint gehört zur betreffenden Abfrage und in eine dokumentierte Prüfung, weil Datenwachstum oder geänderte Statistiken seine Wirkung später verändern können.

Für eine risikofreie Bestandsaufnahme eignen sich lesende Abfragen. Führe sie mit einem Konto aus, das nur die dafür erforderlichen Einsichtsrechte besitzt; sie ändern weder Daten noch Rechte oder Serverkonfiguration. Die Ergebnisse erfassen den tatsächlich verbundenen database server und helfen, Annahmen aus Deployment-Dokumentationen zu überprüfen.

SELECT VERSION();
SHOW VARIABLES LIKE 'max_open_cursors';
SHOW VARIABLES LIKE 'create_tmp_table_binlog_formats';

In einer Proxy-Architektur ist SET SESSION AUTHORIZATION kein Komfortmerkmal, sondern ein Eingriff in das Sicherheitsmodell. Der Sitzungswechsel erfordert das Privileg SET USER und ist nicht innerhalb von Transaktionen, Prepared Statements oder Stored Procedures verfügbar.

Unterstützende MaxScale-Versionen können Service-Zugangsdaten für die Backend-Verbindung verwenden und anschließend zur Identität des Clients wechseln. Dafür sind ein MariaDB-12-oder-neuerer Backend-Server und das Privileg SET USER für das Servicekonto erforderlich. Aus einem MariaDB-12.0-Backend allein folgt diese Fähigkeit jedoch nicht: Vor dem Rollout ist die konkrete Kombination aus MariaDB Server, MaxScale-Version und Konfiguration zu prüfen.

Die MaxScale-Einstellung use_service_credentials steuert in dafür geeigneten Versionen, ob sich MaxScale zunächst mit den im Service hinterlegten Zugangsdaten am Backend anmeldet und anschließend zur Client-Identität wechselt. Das Servicekonto darf über die technisch nötigen Rechte hinaus keine zusätzlichen Verwaltungsrechte erhalten. Auditierung und eine dokumentierte Notfallabschaltung müssen zum Verbindungs- und Pooling-Modell passen.

Replikations- und Galera-Topologien benötigen einen eigenen Testpfad für Failover, Rejoin und Wiederherstellung. Optionen für temporäre Tabellen oder die Behandlung gleicher Server-IDs dürfen nicht ohne Verständnis von Binlog-Format, Server-ID und Rückkehrpfad verändert werden. Eine Galera-Optimierung ist zudem kein allgemeines Leistungsversprechen für Cluster, weil Lastprofil und Netzwerklatenz maßgeblich bleiben.

Wer interne Tabellen, temporäre Strukturen oder Storage-Engines im Umfeld bewertet, sollte die Rolle der jeweiligen Engine getrennt von der Versionsmigration betrachten. Der Artikel zur MariaDB Aria Storage Engine im Hosting ordnet solche Einsatzfragen ein. Für den Upgrade-Entscheid bleibt aber ausschlaggebend, ob die konkrete Anwendung und ihre Betriebsabläufe auf dem Zielstand reproduzierbar funktionieren.

Sitzungswechsel und Audit absichern

SET SESSION AUTHORIZATION ist ein Baustein für bewusst entworfene Verbindungsarchitekturen, nicht bloß eine Erleichterung für die Administration. Die Anweisung erlaubt einem berechtigten Konto, innerhalb der aktuellen Sitzung unter der Identität eines anderen Benutzers zu handeln. Voraussetzung ist das Privileg SET USER. Damit verschiebt sich die Verantwortung für Anmeldung und Identitätsprüfung teilweise von einzelnen Kundenverbindungen zu einer kontrollierten Plattformkomponente.

Für einen Proxy kann dieses Muster sinnvoll sein, aber MariaDB Server und MaxScale bleiben getrennte Produkte mit eigener Versionierung. Nur MaxScale-Versionen, welche die Verwendung von Service-Zugangsdaten mit anschließendem Identitätswechsel unterstützen, können diesen Ablauf bereitstellen. Ein MariaDB-12.0-Backend erweitert einen älteren oder anders konfigurierten MaxScale-Zweig nicht automatisch um diese Fähigkeit.

In einer unterstützten Kombination meldet sich der Proxy mit dem Servicekonto am MariaDB Server an und wechselt danach zur angeforderten Nutzeridentität. Die Einstellung use_service_credentials setzt dafür einen MariaDB-12-oder-neueren Backend-Server sowie SET USER für das Servicekonto voraus. Vor der Einführung müssen deshalb die konkret eingesetzten MariaDB- und MaxScale-Versionen, die Konfiguration und der vorgesehene Authentifizierungsweg gemeinsam geprüft werden.

Das Servicekonto ist wegen der Möglichkeit zum Identitätswechsel sicherheitskritisch. Das Privileg SET USER verleiht ihm nicht automatisch beliebige globale Verwaltungsrechte; darüber hinaus darf es nur die technisch erforderlichen Berechtigungen erhalten. Beim Sitzungswechsel können unter anderem Kontosperre, Passwortablauf, Authentifizierung und REQUIRE-SSL-Prüfung des Zielkontos umgangen werden. Der Wechsel ist zudem nicht innerhalb von Transaktionen, Prepared Statements oder Stored Procedures verfügbar.

Für mandantenfähiges Hosting bedeutet das: Kundenkonten bleiben logisch getrennt, und der zulässige Wechselkreis wird dokumentiert und begrenzt. Zusätzlich braucht die Plattform eine Notfallabschaltung, beispielsweise über das Sperren des Servicekontos oder das Entfernen des betroffenen Verbindungswegs nach einem festgelegten Incident-Verfahren. Welche Maßnahme geeignet ist, muss mit Verbindungs-Pooling, bestehenden Sitzungen und den Auswirkungen auf andere Mandanten abgestimmt werden.

Das Audit Plugin ergänzt in MariaDB 12.0 eingehende Verbindungen um Host und Port sowie die verwendete TLS-Version. Diese Angaben helfen, Zugriffe hinter NAT, Load Balancern oder Proxys besser einzuordnen. Sie ersetzen jedoch keine verlässliche Zuordnung, wenn ein vorgeschaltetes System Quellinformationen verändert oder nur seine eigene Adresse an den Datenbankserver weitergibt.

Wirksam wird Auditierung erst mit einem Betriebsprozess: Logs sollten zentral gesammelt, gegen unbefugte Veränderung geschützt und anhand einer festgelegten Aufbewahrungsfrist verwaltet werden. Zugriffsrechte für Einsicht und Export sind ebenso zu trennen wie die Zuständigkeit für Alarmierung und Untersuchung. Ob zusätzliche Protokolldaten Kapazität oder Leistung einer konkreten Plattform merklich beeinflussen, lässt sich ohne Messung nicht aus der Version ableiten.

Bei einem Sicherheitsvorfall sollten Betreiber nachvollziehen können, welche Identität der Proxy gesetzt hat, über welchen Zugang die Sitzung entstand und welche Auditdaten dazu vorliegen. Regelmäßige, dokumentierte Prüfungen der Abschaltung und der Log-Verfügbarkeit sind wichtiger als eine möglichst umfangreiche Protokollierung. Insbesondere darf ein Audit-Log nicht zum Ersatz für Rechtekonzept, Transportverschlüsselung oder sichere Geheimnisverwaltung werden.

Betrieb nach dem Upgrade überwachen

Nach einem MariaDB-Update beginnt eine Beobachtungsphase, keine automatische Optimierung. Zuerst ist zu unterscheiden, ob der Serverstart fehlschlägt, eine Anwendung keine Verbindung mehr aufbauen kann oder ein Replikationspfad abweicht. Diese Fehlerbilder haben unterschiedliche Ursachen und benötigen getrennte Artefakte, statt mit pauschalen Konfigurationsänderungen beantwortet zu werden.

Startfehler werden anhand des Server-Error-Logs und einer versionierten Inventur der tatsächlich geladenen Konfigurationsdateien eingegrenzt. In MariaDB 12.0 wurden beispielsweise big_tables und storage_engine entfernt. Solche Einträge dürfen nicht unverändert in my.cnf oder eingebundenen Konfigurationsfragmenten stehen; die dokumentierte Variablenreferenz und die Startmeldung zeigen, welche Einstellung konkret betroffen ist.

Bei Connectoren und Plugins sind installierte Pakete, geladene Modulversionen und die Fehlermeldung der Anwendung gemeinsam zu erfassen. Eine Repository-Auswahl allein garantiert keine zusammenpassende Installation: Bei einer gezielten Serverversion müssen Server-, Client-, Shared- und Common-Pakete versionsgleich geplant werden. Welche Namen und Stände verfügbar sind, hängt vom verwendeten Repository und Betriebssystem ab.

Anwendungsfehler lassen sich am besten mit einem reproduzierbaren, möglichst kleinen SQL-Fall und den zugehörigen Client- beziehungsweise Connector-Logs untersuchen. Eine lesende Bestandsaufnahme kann mit SELECT VERSION(); beginnen. Das Ergebnis identifiziert den antwortenden Datenbankserver, beweist aber weder die Kompatibilität eines ORM noch die korrekte Wirkung einer Anwendungskonfiguration.

Für Replikation gehören der dokumentierte Replikationsstatus, Binlog-Format, Server-IDs sowie Ereignisse rund um Failover und Rejoin in die Diagnoseakte. Temporäre Tabellen, die Topologie und Änderungen an Replikationsoptionen sind separat zu prüfen. Eine erfolgreiche lokale Schreibprobe genügt nicht, um Konsistenz und erwartetes Verhalten auf allen beteiligten Instanzen zu belegen.

Server- und Audit-Logs, Konfigurationsinventar, Versionsabfragen und reproduzierbare Abfragetests ergeben zusammen eine nachvollziehbare Fehlerkette. Sie erleichtert auch die Entscheidung, ob ein Rückfallplan ausgelöst werden muss. Aus einer höheren Versionsnummer folgt weder eine bestimmte Leistungswirkung noch ein universelles Tuning; Änderungen an Speicher-, Optimizer- oder Replikationsparametern benötigen eine konkrete Hypothese und eine prüfbare Wirkung.

Den Zielstand strategisch entscheiden

Der passende Zielstand richtet sich nach Plattformaufgabe und Betriebsmodell, nicht nach der Sammelbezeichnung MariaDB 12. Für klassische CMS-, Shop- und Webanwendungsdatenbanken haben Upgrade-Sicherheit, saubere Mandantentrennung und ein belastbarer Wiederherstellungsweg meist Vorrang vor einzelnen neuen SQL-Funktionen. Neue GIS-Funktionen oder Routinen sind kein eigenständiger Migrationsgrund, wenn die Anwendungen sie nicht verwenden.

Komplexe Reporting-Anwendungen können von Optimizer-Hints profitieren, wenn eine Analyse einen unerwünschten Ausführungsplan klar eingrenzt. Zuvor sind Indizes, Join-Bedingungen, Datenverteilung und Statistiken zu prüfen. Ein Hint ist eine gezielte Bindung an eine Planentscheidung und kann nach Datenwachstum oder geänderten Statistiken unpassend werden; er gehört daher mit Abfrage, Begründung und Rücknahmekriterium in die Anwendungsdokumentation.

Proxy- und Clusterumgebungen benötigen einen eigenen Testpfad. Für einen Proxy betrifft er insbesondere das Berechtigungsmodell des Servicekontos, die Sitzungswechsel und die Auditierbarkeit. Für Replikation oder Galera gehören Failover, Rejoin, Restore und das Verhalten temporärer Tabellen dazu. Ein erfolgreiches Upgrade einer einzelnen Instanz belegt nicht, dass diese Abläufe in der gesamten Topologie korrekt funktionieren.

Die Release-Strategie muss Innovation Releases und LTS getrennt bewerten. MariaDB beschreibt Innovation Releases als Rolling-Releases, die nach GA im Regelfall nicht fortlaufend mit Patch-Versionen gepflegt werden; der vorgesehene Weg führt zur nächsten Rolling-Serie. LTS-Releases werden dagegen drei Jahre ab GA gepflegt. Daraus folgt keine pauschale Zusage für Paket- oder Vertragssupport einer konkreten Hosting-Umgebung.

Vor der Entscheidung sind deshalb Paket- und Supportlage der Distribution, getestete Anwendungskompatibilität, ein nachgewiesenes Restore, das Sicherheitsmodell und der laufende Betriebsaufwand zusammen zu bewerten. MariaDB und MySQL sind trotz vieler gemeinsamer SQL-Muster nicht austauschbar: MariaDB verwendet ein eigenes GTID-Modell und unterstützt beispielsweise nicht MySQLs SET PERSIST. Migrationsannahmen aus einer MySQL-Umgebung müssen daher überprüft werden.

Für die Serie 12.0 ist 12.0.2 als stabiler GA-Stand dokumentiert, während 12.0.0 Preview und 12.0.1 Release Candidate waren. Diese Einordnung beschreibt den damaligen Reifestatus, ersetzt aber keine aktuelle Freigabeentscheidung. Unmittelbar vor Rollout oder Veröffentlichung müssen Betreiber angebotenen Paketstand, Betriebssystemunterstützung und aktuelle Release-Einstufung erneut gegen die Herstellerinformationen prüfen.

Entscheidend ist somit der konkret geprüfte Plattformstand mit seinen Abhängigkeiten und Betriebsregeln. Ein kontrollierter Rollout ist gerechtfertigt, wenn Kompatibilität, Rückfall und Verantwortlichkeiten nachweisbar vorbereitet sind. Fehlen diese Voraussetzungen, ist der Name MariaDB 12 kein Argument, Risiken im Shared Hosting oder in einer geschäftskritischen Datenbanklandschaft zu übernehmen.