Die Migration von Oracle auf MySQL/Percona Server ist keine triviale Aufgabe. Obwohl es immer einfacher wird, insbesondere mit der Ankunft von MySQL 8.0 und Percona kündigte Percona Server für MySQL 8.0 GA an. Abgesehen von der Planung Ihrer Migration von Oracle zu Percona Server müssen Sie sicherstellen, dass Sie den Zweck und die Funktionalität verstehen, warum es Percona Server sein muss.
Dieser Blog konzentriert sich auf die Migration von Oracle auf Percona Server als spezifische Zieldatenbank der Wahl. Auf der Oracle-Website gibt es eine Seite zu SQL Developer Supplementary Information for MySQL Migrations, die als Referenz für die geplante Migration verwendet werden kann. Dieser Blog behandelt nicht den gesamten Migrationsprozess, da es sich um einen langen Prozess handelt. Aber es wird hoffentlich genügend Hintergrundinformationen liefern, um als Leitfaden für Ihren Migrationsprozess zu dienen.
Da Percona Server ein Fork von MySQL ist, sind fast alle Funktionen von MySQL in Percona Server vorhanden. Daher ist jeder Verweis auf MySQL hier auch auf Percona Server anwendbar. Wir haben zuvor über die Migration von Oracle Database zu PostgreSQL gebloggt. Ich wiederhole noch einmal die Gründe, warum man erwägen sollte, von Oracle zu einem Open-Source-RDBMS wie PostgreSQL oder Percona Server/MySQL/MariaDB zu migrieren.
- Kosten:Wie Sie vielleicht wissen, sind die Lizenzkosten für Oracle sehr hoch, und für einige Funktionen wie Partitionierung und Hochverfügbarkeit fallen zusätzliche Kosten an. Insgesamt ist es also sehr teuer.
- Flexible Open-Source-Lizenzierung und einfache Verfügbarkeit von öffentlichen Cloud-Anbietern wie AWS.
- Profitieren Sie von Open-Source-Add-ons, um die Leistung zu verbessern.
Planungs- und Entwicklungsstrategie
Die Migration von Oracle zu Percona Server 8.0 kann mühsam sein, da viele Schlüsselfaktoren berücksichtigt und angegangen werden müssen. Beispielsweise kann Oracle auf einem Windows Server-Computer ausgeführt werden, aber Percona Server unterstützt Windows nicht. Obwohl Sie es für Windows kompilieren können, bietet Percona selbst keine Unterstützung für Windows. Sie müssen auch Ihre Anforderungen an die Datenbankarchitektur identifizieren, da Percona Server nicht für OLAP- (Online Analytical Processing) oder Data-Warehousing-Anwendungen ausgelegt ist. Percona Server/MySQL RDBMS eignen sich perfekt für OLTP (Online Transaction Processing).
Identifizieren Sie den Schlüsselaspekt Ihrer Datenbankarchitektur, zum Beispiel wenn Ihre aktuelle Oracle-Architektur MAA (Maximum Available Architecture) mit Data Guard ++ Oracle RAC (Real Application Cluster) implementiert, sollten Sie ihre Äquivalenz in Percona Server bestimmen. Innerhalb von MySQL/Percona Server gibt es dafür keine eindeutige Antwort. Sie können jedoch zwischen einer synchronen Replikation, einer asynchronen Replikation (Percona XtraDB Cluster ist derzeit noch auf Version 5.7.x) oder mit Gruppenreplikation wählen. Dann gibt es mehrere Alternativen, die Sie für Ihre eigene Hochverfügbarkeitslösung implementieren können. Zum Beispiel (um nur einige zu nennen) Corosync/Pacemaker/DRBD/Linux-Stack verwenden oder MHA (MySQL High Availability) verwenden oder Keepalived/HaProxy/ProxySQL-Stack verwenden oder sich einfach auf ClusterControl verlassen, das Keepalived, HaProxy, ProxySQL unterstützt, Garbd und Maxscale für Ihre Hochverfügbarkeitslösungen.
Auf der anderen Seite ist die Frage, die Sie im Rahmen des Plans berücksichtigen müssen, "Wie wird Percona Support leisten und wer hilft uns, wenn Percona Server selbst auf einen Fehler stößt oder wie hoch ist die Dringlichkeit, wenn wir Hilfe benötigen?". Eine zu berücksichtigende Sache ist auch das Budget, wenn der Zweck der Migration von einer Unternehmensdatenbank zu einem Open-Source-RDBMS der Kostensenkung dient.
Es gibt verschiedene Optionen von der Migrationsplanung bis hin zu den Dingen, die Sie als Teil Ihrer Entwicklungsstrategie tun müssen. Zu diesen Optionen gehört die Zusammenarbeit mit Experten im Bereich MySQL/Percona-Server, und dazu gehören auch wir hier bei Multiplenines. Es gibt viele MySQL-Beratungsfirmen, die Ihnen dabei helfen können, da die Migration von Oracle zu MySQL viel Fachwissen und Know-how im MySQL-Server-Bereich erfordert. Dies sollte nicht auf die Datenbank beschränkt sein, sondern auch Fachwissen in den Bereichen Skalierbarkeit, Redundanz, Backups, Hochverfügbarkeit, Sicherheit, Überwachung/Beobachtbarkeit, Wiederherstellung und Eingriff in unternehmenskritische Systeme umfassen. Insgesamt sollte es Ihre architektonischen Einblicke verstehen, ohne die Vertraulichkeit Ihrer Daten preiszugeben.
Bewertung oder Vorabprüfung
Das Sichern Ihrer Daten einschließlich Konfigurations- oder Setup-Dateien, Kernel-Tunings, Automatisierungsskripten darf nicht in Vergessenheit geraten. Es ist eine offensichtliche Aufgabe, aber sichern Sie vor der Migration immer zuerst alles, insbesondere wenn Sie auf eine andere Plattform wechseln.
Sie müssen auch beurteilen, ob Ihre Anwendungen den aktuellen Software-Engineering-Konventionen entsprechen, und sicherstellen, dass sie plattformunabhängig sind. Diese Vorgehensweisen können für Sie von Vorteil sein, insbesondere wenn Sie auf eine andere Datenbankplattform wie Percona Server for MySQL umsteigen.
Beachten Sie, dass das für Percona Server erforderliche Betriebssystem ein Hingucker sein kann, wenn Ihre Anwendung und Datenbank auf einem Windows-Server ausgeführt werden und die Anwendung Windows-abhängig ist; dann könnte das eine menge arbeit werden! Denken Sie immer daran, dass sich Percona Server auf einer anderen Plattform befindet:Perfektion ist möglicherweise nicht garantiert, kann aber nahe genug erreicht werden.
Stellen Sie schließlich sicher, dass die Zielhardware so konzipiert ist, dass sie mit den Serveranforderungen von Percona funktioniert, oder dass sie zumindest fehlerfrei ist (siehe hier). Sie können zunächst Stresstests mit Percona Server in Betracht ziehen, bevor Sie Ihre Oracle-Datenbank zuverlässig verlassen.
Was Sie wissen sollten
Es ist erwähnenswert, dass Sie in Percona Server / MySQL mehrere Datenbanken erstellen können, während Oracle nicht über die gleiche Funktionalität wie MySQL verfügt.
In MySQL ist ein Schema physisch gleichbedeutend mit einer Datenbank. Sie können das Schlüsselwort SCHEMA anstelle von DATABASE in der MySQL SQL-Syntax ersetzen, zum Beispiel mit CREATE SCHEMA statt CREATE DATABASE; während Oracle eine Unterscheidung davon hat. Ein Schema stellt nur einen Teil einer Datenbank dar:die Tabellen und anderen Objekte, die einem einzelnen Benutzer gehören. Normalerweise besteht eine Eins-zu-Eins-Beziehung zwischen der Instanz und der Datenbank.
In einem Replikationssetup, das in Oracle äquivalent ist (z. B. Real Application Clusters oder RAC), haben Sie beispielsweise mehrere Instanzen, die auf eine einzige Datenbank zugreifen. Dadurch können Sie Oracle auf mehreren Servern starten, aber alle greifen auf dieselben Daten zu. In MySQL können Sie jedoch den Zugriff auf mehrere Datenbanken von mehreren Instanzen aus zulassen und sogar herausfiltern, welche Datenbanken/Schemas Sie auf einen MySQL-Knoten replizieren können.
Bezugnehmend auf einen unserer vorherigen Blogs gilt das gleiche Prinzip, wenn es darum geht, Ihre Datenbank mit verfügbaren Tools aus dem Internet zu konvertieren.
Es gibt kein solches Tool, das Oracle-Datenbanken zu 100 % in Percona Server / MySQL konvertieren kann; ein Teil davon wird Handarbeit sein.
In den folgenden Abschnitten finden Sie Dinge, die Sie beachten müssen, wenn es um die Migration und die Überprüfung des logischen SQL-Ergebnisses geht.
Datentypzuordnung
MySQL / Percona Server haben eine Reihe von Datentypen, die fast die gleichen sind wie Oracle, aber nicht so umfangreich wie Oracle. Aber seit der Einführung der Version 5.7.8 von MySQL wird ein nativer JSON-Datentyp unterstützt.
Unten ist die äquivalente Darstellung des Datentyps (die tabellarische Darstellung stammt von hier):
| Orakel | MySQL | |||
|---|---|---|---|---|
| 1 | BFILE | Zeiger auf Binärdatei, ⇐ 4G | VARCHAR(255) | |
| 2 | BINARY_FLOAT | 32-Bit-Gleitkommazahl | SCHWEBEN | |
| 3 | BINARY_DOUBLE | 64-Bit-Gleitkommazahl | DOPPELT | |
| 4 | BLOB | Binäres großes Objekt, ⇐ 4G | LONGBLOB | |
| 5 | ZEICHEN(n), ZEICHEN(n) | String mit fester Länge, 1 ⇐ n ⇐ 255 | ZEICHEN(n), ZEICHEN(n) | |
| 6 | ZEICHEN(n), ZEICHEN(n) | String mit fester Länge, 256 ⇐ n ⇐ 2000 | VARCHAR(n) | |
| 7 | CLOB | Charakter großes Objekt, ⇐ 4G | LANGTEXT | |
| 8 | DATUM | Datum und Uhrzeit | DATETIME | |
| 9 | DEZIMAL(p,s), DEZ(p,s) | Festkommazahl | DEZIMAL(p,s), DEZ(p,s) | |
| 10 | DOPPELTE PRÄZISION | Fließkommazahl | DOPPELTE PRÄZISION | |
| 11 | FLOAT(p) | Fließkommazahl | DOPPELT | |
| 12 | INTEGER, INT | 38-stellige Ganzzahl | INT | DEZIMAL(38) |
| 13 | INTERVALL JAHR(p) BIS MONAT | Datumsintervall | VARCHAR(30) | |
| 14 | INTERVALL TAG(p) BIS SEKUNDE(n) | Tag und Zeitintervall | VARCHAR(30) | |
| 15 | LANG | Zeichendaten, ⇐ 2G | LANGTEXT | |
| 16 | LONG RAW | Binäre Daten, ⇐ 2G | LONGBLOB | |
| 17 | NCHAR(n) | UTF-8-String mit fester Länge, 1 ⇐ n ⇐ 255 | NCHAR(n) | |
| 18 | NCHAR(n) | UTF-8-String mit fester Länge, 256 ⇐ n ⇐ 2000 | NVARCHAR(n) | |
| 19 | NCHAR VARYING(n) | UTF-8-String unterschiedlicher Länge, 1 ⇐ n ⇐ 4000 | NCHAR VARYING(n) | |
| 20 | NCLOB | Unicode-String variabler Länge, ⇐ 4G | NVARCHAR(max) | |
| 21 | NUMMER(p,0), NUMMER(p) | 8-Bit-Ganzzahl, 1 <=p <3 | TINYINT | (0 bis 255) |
| 16-Bit-Ganzzahl, 3 <=p <5 | SMALLINT | |||
| 32-Bit-Ganzzahl, 5 <=p <9 | INT | |||
| 64-Bit-Ganzzahl, 9 <=p <19 | BIGINT | |||
| Festkommazahl, 19 <=p <=38 | DEZIMAL(p) | |||
| 22 | ZAHL(p,s) | Festkommazahl, s> 0 | DEZIMAL(p,s) | |
| 23 | NUMMER, NUMMER(*) | Gleitkommazahl | DOPPELT | |
| 24 | NUMERIC(p,s) | Festkommazahl | NUMERIC(p,s) | |
| 25 | NVARCHAR2(n) | UTF-8-String variabler Länge, 1 ⇐ n ⇐ 4000 | NVARCHAR(n) | |
| 26 | RAW(n) | Binärzeichenfolge variabler Länge, 1 ⇐ n ⇐ 255 | BINARY(n) | |
| 27 | RAW(n) | Binärzeichenfolge variabler Länge, 256 ⇐ n ⇐ 2000 | VARBINARY(n) | |
| 28 | ECHT | Fließkommazahl | DOPPELT | |
| 29 | ROWID | Physische Zeilenadresse | CHAR(10) | |
| 30 | SMALLINT | 38-stellige Ganzzahl | DEZIMAL(38) | |
| 31 | ZEITSTEMPEL(p) | Datum und Uhrzeit mit Bruch | DATETIME(p) | |
| 32 | ZEITSTEMPEL(p) MIT ZEITZONE | Datum und Uhrzeit mit Bruchteil und Zeitzone | DATETIME(p)  | |
| 33 | UROWID(n) | Logische Zeilenadressen, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 34 | VARCHAR(n) | String variabler Länge, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 35 | VARCHAR2(n) | String variabler Länge, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 36 | XMLTYPE | XML-Daten | LANGTEXT | |
Datentypattribute und Optionen:
| Oracle | MySQL |
| BYTE- und CHAR-Spaltengrößensemantik | Größe ist immer in Zeichen |
Transaktionen
Percona Server verwendet XtraDB (eine erweiterte Version von InnoDB) als primäre Speicher-Engine für die Verarbeitung von Transaktionsdaten; obwohl verschiedene Speicher-Engines eine alternative Wahl für die Abwicklung von Transaktionen sein können, wie z. B. TokuDB (veraltet) und MyRocks-Speicher-Engines.
Während es Vorteile und Vorteile gibt, MyRocks mit XtraDB zu verwenden oder zu erkunden, ist letzteres die robustere und de facto Speicher-Engine, die Percona Server verwendet, und sie ist standardmäßig aktiviert, sodass wir diese Speicher-Engine als Grundlage für die Migration in Bezug auf verwenden zu Transaktionen.
Standardmäßig hat Percona Server / MySQL die Autocommit-Variable auf ON gesetzt, was bedeutet, dass Sie Transaktionsanweisungen explizit verarbeiten müssen, um ROLLBACK zum Ignorieren von Änderungen oder zum Nutzen der Verwendung von SAVEPOINT zu nutzen.
Es ist im Grunde das gleiche Konzept, das Oracle in Bezug auf Commit, Rollbacks und Savepoints verwendet.
Für explizite Transaktionen bedeutet dies, dass Sie die START TRANSACTION/BEGIN;
Andernfalls, wenn Sie Autocommit deaktivieren müssen, müssen Sie die ganze Zeit explizit COMMIT für Ihre Anweisungen ausführen, die Änderungen an Ihren Daten erfordern.
Dualer Tisch
MySQL hat die duale Kompatibilität mit Oracle, die für die Kompatibilität von Datenbanken gedacht ist, die eine Dummy-Tabelle verwenden, nämlich DUAL.
Dies passt zur Verwendung von DUAL durch Oracle, sodass alle bestehenden Anweisungen in Ihrer Anwendung, die DUAL verwenden, möglicherweise keine Änderungen bei der Migration auf Percona Server erfordern.
Die Oracle FROM-Klausel ist für jede SELECT-Anweisung obligatorisch, daher verwendet die Oracle-Datenbank die DUAL-Tabelle für die SELECT-Anweisung, wenn kein Tabellenname erforderlich ist.
In MySQL ist die FROM-Klausel nicht obligatorisch, daher ist die DUAL-Tabelle nicht erforderlich. Die DUAL-Tabelle funktioniert jedoch nicht genau so wie bei Oracle, aber für einfache SELECTs in Percona Server ist dies in Ordnung.
Siehe folgendes Beispiel unten:
In Oracle
SQL> DESC DUAL;
Name Null? Type
----------------------------------------- -------- ----------------------------
DUMMY VARCHAR2(1)
SQL> SELECT CURRENT_TIMESTAMP FROM DUAL;
CURRENT_TIMESTAMP
---------------------------------------------------------------------------
16-FEB-19 04.16.18.910331 AM +08:00Aber in MySQL:
mysql> DESC DUAL;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DUAL' at line 1
mysql> SELECT CURRENT_TIMESTAMP FROM DUAL;
+---------------------+
| CURRENT_TIMESTAMP |
+---------------------+
| 2019-02-15 20:20:28 |
+---------------------+
1 row in set (0.00 sec)Hinweis:das DESC DUAL Syntax funktioniert in MySQL nicht und die Ergebnisse unterscheiden sich auch, da CURRENT_TIMESTAMP (verwendet den Datentyp TIMESTAMP) in MySQL die Zeitzone nicht enthält.
SYSDATUM
Die SYSDATE-Funktion von Oracle ist in MySQL fast identisch.
MySQL gibt Datum und Uhrzeit zurück und ist eine Funktion, die () (schließende und öffnende Klammern ohne erforderliche Argumente) erfordert. Um dies unten zu demonstrieren, hier Oracle und MySQL zur Verwendung von SYSDATE.
In Oracle gibt die Verwendung von einfachem SYSDATE nur das Datum des Tages ohne die Uhrzeit zurück. Aber um die Zeit und das Datum zu erhalten, verwenden Sie TO_CHAR, um die Datumszeit in das gewünschte Format zu konvertieren; während Sie es in MySQL möglicherweise nicht benötigen, um das Datum und die Uhrzeit zu erhalten, da es beides zurückgibt.
Siehe Beispiel unten.
Bei Oracle:
SQL> SELECT TO_CHAR (SYSDATE, 'MM-DD-YYYY HH24:MI:SS') "NOW" FROM DUAL;
NOW
-------------------
02-16-2019 04:39:00
SQL> SELECT SYSDATE FROM DUAL;
SYSDATE
---------
16-FEB-19Aber in MySQL:
mysql> SELECT SYSDATE() FROM DUAL;
+---------------------+
| SYSDATE() |
+---------------------+
| 2019-02-15 20:37:36 |
+---------------------+
1 row in set (0.00 sec)Wenn Sie das Datum formatieren möchten, hat MySQL eine DATE_FORMAT()-Funktion.
Weitere Informationen finden Sie in der MySQL Date and Time-Dokumentation.
TO_DATE
Das TO_DATE-Äquivalent von Oracle in MySQL ist die STR_TO_DATE()-Funktion.
Es ist fast identisch mit dem in Oracle:Es gibt den Datentyp DATE zurück, während es in MySQL den Datentyp DATETIME zurückgibt.
Orakel:
SQL> SELECT TO_DATE ('20190218121212','yyyymmddhh24miss') as "NOW" FROM DUAL;
NOW
-------------------------
18-FEB-19MySQL:
mysql> SELECT STR_TO_DATE('2019-02-18 12:12:12','%Y-%m-%d %H:%i:%s') as "NOW" FROM DUAL;
+---------------------+
| NOW |
+---------------------+
| 2019-02-18 12:12:12 |
+---------------------+
1 row in set (0.00 sec)SYNONYM
In MySQL gibt es weder eine solche Unterstützung noch eine Entsprechung für SYNONYM in Oracle.
Eine mögliche Alternative mit MySQL ist die Verwendung von VIEW.
Obwohl SYNONYM verwendet werden kann, um einen Alias einer entfernten Tabelle zu erstellen,
z. B.
CREATE PUBLIC SYNONYM emp_table FOR [email protected]In MySQL können Sie die FEDERATED-Speicher-Engine nutzen.
z. B.
CREATE TABLE hr_employees (
id INT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(32) NOT NULL DEFAULT '',
other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
INDEX name (name),
INDEX other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=utf8mb4
CONNECTION='mysql://[email protected]_host:9306/federated/test_table';Oder Sie können den Prozess mit der CREATE SERVER-Syntax vereinfachen, sodass es einfacher ist, eine Tabelle zu erstellen, die als Ihr SYNONYM für den Zugriff auf eine entfernte Tabelle dient. Weitere Informationen hierzu finden Sie in der Dokumentation.
Verhalten von leerem String und NULL
Beachten Sie, dass in Percona Server / MySQL leere Zeichenfolgen nicht NULL sind, während Oracle leere Zeichenfolgen als Nullwerte behandelt.
Bei Oracle:
SQL> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
Nul
---
YesIn MySQL:
mysql> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
+-----------+
| Null Eval |
+-----------+
| No |
+-----------+
1 row in set (0.00 sec)Sequenzen
In MySQL gibt es keinen genau gleichen Ansatz wie Oracle für SEQUENCE.
Obwohl es einige Beiträge gibt, die die Funktionalität dieses Ansatzes simulieren, können Sie möglicherweise versuchen, den nächsten Schlüssel mit LAST_INSERT_ID() abzurufen, solange der gruppierte Index Ihrer Tabelle, PRIMARY KEY, mit <
Zeichenkettenfunktionen
Im Gegensatz zu Oracle hat MySQL / Percona Server eine Handvoll String-Funktionen, aber nicht so viele hilfreiche Funktionen, die in die Datenbank integriert sind.
Es würde zu lange dauern, es hier einzeln zu diskutieren, aber Sie können die Dokumentation von MySQL überprüfen und diese mit den String-Funktionen von Oracle vergleichen.
DML-Anweisungen
Einfügen/Aktualisieren/Löschen-Anweisungen von Oracle sind in MySQL kongruent.
ALLE EINFÜGEN/ZUERST EINFÜGEN von Oracle wird in MySQL nicht unterstützt.
Andernfalls müssten Sie Ihre MySQL-Abfragen einzeln angeben.
z. B.
Bei Oracle:
SQL> INSERT ALL
INTO CUSTOMERS (customer_id, customer_name, city) VALUES (1000, 'Jase Alagaban', 'Davao City')
INTO CUSTOMERS (customer_id, customer_name, city) VALUES (2000, 'Maximus Aleksandre Namuag', 'Davao City')
SELECT * FROM dual;
2 rows created.2 Zeilen erstellt.
Aber in MySQL müssen Sie die Einfügung einzeln ausführen:
mysql> INSERT INTO CUSTOMERS (customer_id, customer_name, city) VALUES (1000, 'Jase Alagaban', 'Davao City');
Query OK, 1 row affected (0.02 sec)
mysql> INSERT INTO CUSTOMERS (customer_id, customer_name, city) VALUES (2000, 'Maximus Aleksandre Namuag', 'Davao City');
Query OK, 1 row affected (0.00 sec)INSERT ALL/INSERT FIRST ist nicht vergleichbar mit der Verwendung in Oracle, wo Sie Bedingungen nutzen können, indem Sie Ihrer Syntax ein WHEN-Schlüsselwort hinzufügen; In diesem Fall gibt es keine entsprechende Option in MySQL / Percona Server.
Daher besteht Ihre alternative Lösung darin, Prozeduren zu verwenden.
Outer Joins "+"-Symbol
In Oracle wird die Verwendung des +-Operators für linke und rechte Joins derzeit in MySQL nicht unterstützt, da der +-Operator nur für arithmetische Entscheidungen verwendet wird.
Wenn Sie also einen +-Operator in Ihren vorhandenen Oracle SQL-Anweisungen haben, müssen Sie diesen durch LEFT JOIN oder RIGHT JOIN ersetzen.
Vielleicht möchten Sie in der offiziellen Dokumentation zu "Outer Join Simplification" von MySQL nachsehen.
BEGINN MIT..VERBINDEN DURCH
Oracle verwendet START WITH..CONNECT BY für hierarchische Abfragen.
Beginnend mit MySQL / Percona 8.0 gibt es Unterstützung für die Generierung hierarchischer Datenergebnisse, die Modelle wie Adjazenzlisten oder verschachtelte Mengenmodelle verwenden. Dies wird in MySQL Common Table Expressions (CTE) genannt.
Ähnlich wie PostgreSQL verwendet MySQL WITH RECURSIVE Syntax für hierarchische Abfragen, übersetze also CONNECT BY -Anweisung in WITH RECURSIVE Aussage.
Sehen Sie unten nach, wie es sich von ORACLE und in MySQL / Percona Server unterscheidet.
Bei Oracle:
SELECT cp.id, cp.title, CONCAT(c2.title, ' > ' || cp.title) as path
FROM category cp INNER JOIN category c2
ON cp.parent_id = c2.id
WHERE cp.parent_id IS NOT NULL
START WITH cp.id >= 1
CONNECT BY NOCYCLE PRIOR c2.id=cp.parent_id; Und in MySQL:
WITH RECURSIVE category_path (id, title, path) AS
(
SELECT id, title, title as path
FROM category
WHERE parent_id IS NULL
UNION ALL
SELECT c.id, c.title, CONCAT(cp.path, ' > ', c.title)
FROM category_path AS cp JOIN category AS c
ON cp.id = c.parent_id
)
SELECT * FROM category_path
ORDER BY path;PL/SQL in MySQL / Percona?
MySQL / Percona RDBMS hat einen anderen Ansatz als Oracles PL/SQL.
MySQL verwendet gespeicherte Prozeduren oder gespeicherte Funktionen, die PL/SQL und der Syntax mit BEGIN..END ähneln Syntax.
PL/SQL von Oracle wird vor der Ausführung kompiliert, wenn es in den Server geladen wird, während MySQL kompiliert und im Cache gespeichert wird, wenn es aufgerufen wird.
Vielleicht möchten Sie diese Dokumentation als Referenzhandbuch zum Konvertieren von PL/SQL in MySQL lesen.
Migrationstools
Ich habe nach Tools gesucht, die ein De-facto-Standard für die Migration sein könnten, aber ich konnte keine gute Antwort finden.
Allerdings habe ich sqlines gefunden und es sieht einfach, aber vielversprechend aus.
Obwohl ich nicht tief in die Materie eingetaucht bin, bietet die Website eine Handvoll Einblicke, die Ihnen bei der Migration von Oracle zu MySQL/Percona Server helfen könnten. Es gibt auch kostenpflichtige Tools wie this und this.
Ich habe auch Github durchsucht, aber nichts Ansprechenderes als eine Lösung für das Problem gefunden. Wenn Sie also von Oracle zu Amazon migrieren möchten, haben sie das AWS Schema Conversion Tool, für das die Migration von Oracle zu MySQL unterstützt wird.
Insgesamt liegt der Grund, warum die Migration nicht einfach ist, hauptsächlich darin, dass Oracle RDBMS so ein Biest mit vielen Funktionen ist, die Percona Server / MySQL oder MariaDB RDBMS immer noch nicht haben.
Wie auch immer, wenn Sie Tools finden oder kennen, die Sie für die Migration von Oracle zu MySQL / Percona Server hilfreich und nützlich finden, hinterlassen Sie bitte einen Kommentar in diesem Blog!
Testen
Als Teil Ihres Migrationsplans ist das Testen eine wichtige Aufgabe, die eine sehr wichtige Rolle spielt und Ihre Entscheidung bezüglich der Migration beeinflusst.
Das Tool dbdeployer (eine Portierung von MySQL Sandbox) ist ein sehr hilfreiches Tool, das Sie nutzen können. Dies ist ziemlich einfach für Sie, um verschiedene Ansätze auszuprobieren und zu testen, und spart Ihnen Zeit, anstatt den gesamten Stack einzurichten, wenn Sie zuerst die RDBMS-Plattform ausprobieren und testen möchten.
Zum Testen Ihrer gespeicherten SQL-Routinen (Funktionen oder Prozeduren), Trigger und Ereignisse schlage ich vor, dass Sie diese Tools mytap oder das Unit Testing Framework von Google verwenden.
Auch Percona bietet eine Reihe von Tools an, die auf ihrer Website heruntergeladen werden können. Sehen Sie sich hier das Percona Toolkit an. Sie können die Tools entsprechend Ihren Anforderungen speziell für Test- und Produktionsnutzungsaufgaben auswählen.
Alles in allem sollten Sie Folgendes als Ihre Richtlinien beachten, wenn Sie einen Test für Ihren MySQL-Server durchführen:
- Nach der Installation müssen Sie einige Einstellungen vornehmen. Schauen Sie sich diesen Percona-Blog an, um Hilfe zu erhalten.
- Führen Sie einige Benchmarks und Belastungstests für Ihr Konfigurations-Setup auf Ihrem aktuellen Knoten durch. Testen Sie mysqlslap und sysbench, die Ihnen dabei helfen können. Lesen Sie auch unseren Blog "How to Benchmark Performance of MySQL &MariaDB using SysBench".
- Überprüfen Sie Ihre DDLs, ob sie korrekt definiert sind, wie z. B. Datentypen, Einschränkungen, gruppierte und sekundäre Indizes oder Partitionen, falls vorhanden.
- Überprüfen Sie Ihre DML, insbesondere, ob die Syntax korrekt ist und die Daten wie erwartet korrekt gespeichert werden.
- Überprüfen Sie Ihre gespeicherten Routinen, Ereignisse und Trigger, um sicherzustellen, dass sie die erwarteten Ergebnisse ausführen/zurückgeben.
- Stellen Sie sicher, dass Ihre ausgeführten Abfragen leistungsfähig sind. Ich schlage vor, dass Sie Open-Source-Tools nutzen oder unser Produkt ClusterControl ausprobieren. Es bietet Überwachung/Beobachtbarkeit insbesondere Ihres MySQL-/Percona-Servers. Sie können ClusterControl hier verwenden, um Ihre Abfragen und ihren Abfrageplan zu überwachen, um sicherzustellen, dass sie leistungsfähig sind.
