La migration d'Oracle vers MySQL/Percona Server n'est pas une tâche triviale. Bien que cela devienne plus facile, notamment avec l'arrivée de MySQL 8.0 et Percona a annoncé Percona Server pour MySQL 8.0 GA. Outre la planification de votre migration d'Oracle vers Percona Server, vous devez vous assurer que vous comprenez l'objectif et les fonctionnalités pour lesquelles il doit s'agir de Percona Server.
Ce blog se concentrera sur la migration d'Oracle vers Percona Server en tant que base de données cible spécifique de choix. Il existe une page sur le site Web d'Oracle sur les informations supplémentaires du développeur SQL pour les migrations MySQL qui peut être utilisée comme référence pour la migration prévue. Ce blog ne couvrira pas le processus global de migration, car il s'agit d'un long processus. Mais nous espérons qu'il fournira suffisamment d'informations générales pour vous guider dans votre processus de migration.
Étant donné que Percona Server est un fork de MySQL, presque toutes les fonctionnalités de MySQL sont présentes dans Percona Server. Ainsi, toute référence de MySQL ici s'applique également à Percona Server. Nous avons déjà blogué sur la migration d'Oracle Database vers PostgreSQL. Je vais réitérer les raisons pour lesquelles on envisagerait de migrer d'Oracle vers un SGBDR open source tel que PostgreSQL ou Percona Server/MySQL/MariaDB.
- Coût :comme vous le savez peut-être, le coût d'une licence Oracle est très élevé et il y a un coût supplémentaire pour certaines fonctionnalités telles que le partitionnement et la haute disponibilité. Donc dans l'ensemble c'est très cher.
- Licences open source flexibles et disponibilité facile auprès de fournisseurs de cloud public comme AWS.
- Bénéficiez de modules complémentaires open source pour améliorer les performances.
Stratégie de planification et de développement
La migration d'Oracle vers Percona Server 8.0 peut être pénible car de nombreux facteurs clés doivent être pris en compte et traités. Par exemple, Oracle peut s'exécuter sur une machine Windows Server, mais Percona Server ne prend pas en charge Windows. Bien que vous puissiez le compiler pour Windows, Percona lui-même n'offre aucun support pour Windows. Vous devez également identifier les exigences de votre architecture de base de données, puisque Percona Server n'est pas conçu pour les applications OLAP (Online Analytical Processing) ou d'entreposage de données. Percona Server/MySQL RDBMS sont parfaitement adaptés pour OLTP (Online Transaction Processing).
En identifiant l'aspect clé de votre architecture de base de données, par exemple si votre architecture Oracle actuelle implémente MAA (architecture disponible maximale) avec Data Guard ++ Oracle RAC (Real Application Cluster), vous devez déterminer son équivalence dans Percona Server. Il n'y a pas de réponse directe à cela dans MySQL/Percona Server. Cependant, vous pouvez choisir entre une réplication synchrone, une réplication asynchrone (Percona XtraDB Cluster est encore actuellement sur la version 5.7.x), ou avec Group Replication. Ensuite, il existe plusieurs alternatives que vous pouvez implémenter pour votre propre solution haute disponibilité. Par exemple, (pour n'en nommer que quelques-uns) en utilisant la pile Corosync/Pacemaker/DRBD/Linux, ou en utilisant MHA (MySQL High Availability), ou en utilisant la pile Keepalived/HaProxy/ProxySQL, ou simplement en s'appuyant sur ClusterControl qui prend en charge Keepalived, HaProxy, ProxySQL, Garbd et Maxscale pour vos solutions à haute disponibilité.
D'un autre côté, la question que vous devez également prendre en compte dans le cadre du plan est "Comment Percona fournira-t-il une assistance et qui nous aidera lorsque Percona Server lui-même rencontre un bogue ou quelle est l'urgence lorsque nous avons besoin d'aide ?". Une chose à considérer également est le budget, si l'objectif de la migration d'une base de données d'entreprise vers un SGBDR open source est une réduction des coûts.
Il existe différentes options, de la planification de la migration aux choses que vous devez faire dans le cadre de votre stratégie de développement. Ces options incluent l'engagement avec des experts dans le domaine des serveurs MySQL/Percona et cela nous inclut ici chez Manynines. De nombreuses sociétés de conseil MySQL peuvent vous aider, car la migration d'Oracle vers MySQL nécessite beaucoup d'expertise et de savoir-faire dans le domaine du serveur MySQL. Cela ne doit pas se limiter à la base de données, mais doit couvrir l'expertise en matière d'évolutivité, de redondance, de sauvegardes, de haute disponibilité, de sécurité, de surveillance/observabilité, de récupération et d'engagement sur des systèmes critiques. Dans l'ensemble, il doit avoir une compréhension de votre vision architecturale sans exposer la confidentialité de vos données.
Évaluation ou vérification préliminaire
La sauvegarde de vos données, y compris les fichiers de configuration ou d'installation, les réglages du noyau, les scripts d'automatisation ne doivent pas être oubliés. C'est une tâche évidente, mais avant de migrer, sécurisez toujours tout en premier , en particulier lorsque vous passez à une autre plate-forme.
Vous devez également évaluer que vos applications suivent les conventions d'ingénierie logicielle à jour et vous assurer qu'elles sont indépendantes de la plate-forme. Ces pratiques peuvent être à votre avantage, en particulier lorsque vous passez à une plate-forme de base de données différente, telle que Percona Server pour MySQL.
Notez que le système d'exploitation requis par Percona Server peut être un obstacle si votre application et votre base de données s'exécutent sur un serveur Windows et que l'application dépend de Windows ; alors cela pourrait être beaucoup de travail! Rappelez-vous toujours que Percona Server est sur une plate-forme différente :la perfection n'est peut-être pas garantie, mais peut être atteinte assez près.
Enfin, assurez-vous que le matériel ciblé est conçu pour fonctionner de manière réaliste avec les exigences du serveur de Percona ou qu'il est au moins exempt de bogues (voir ici). Vous pouvez d'abord envisager de tester le stress avec Percona Server avant de quitter votre base de données Oracle de manière fiable.
Ce que vous devez savoir
Il convient de noter que dans Percona Server / MySQL, vous pouvez créer plusieurs bases de données alors qu'Oracle n'offre pas les mêmes fonctionnalités que MySQL.
Dans MySQL, physiquement, un schéma est synonyme de base de données. Vous pouvez substituer le mot-clé SCHEMA au lieu de DATABASE dans la syntaxe MySQL SQL, par exemple en utilisant CREATE SCHEMA au lieu de CRÉER BASE DE DONNÉES ; tandis qu'Oracle a une distinction de cela. Un schéma ne représente qu'une partie d'une base de données :les tables et autres objets appartenant à un seul utilisateur. Normalement, il existe une relation un à un entre l'instance et la base de données.
Par exemple, dans une configuration de réplication équivalente dans Oracle (par exemple, Real Application Clusters ou RAC), vos multiples instances accèdent à une seule base de données. Cela vous permet de démarrer Oracle sur plusieurs serveurs, mais tous accédant aux mêmes données. Cependant, dans MySQL, vous pouvez autoriser l'accès à plusieurs bases de données à partir de vos multiples instances et même filtrer les bases de données/schémas que vous pouvez répliquer sur un nœud MySQL.
En référence à l'un de nos blogs précédents, le même principe s'applique lorsque l'on parle de convertir votre base de données avec des outils disponibles trouvés sur Internet.
Il n'existe aucun outil de ce type capable de convertir à 100 % la base de données Oracle en Percona Server / MySQL ; une partie sera un travail manuel.
Consultez les sections suivantes pour connaître les éléments dont vous devez être conscient en matière de migration et de vérification du résultat SQL logique.
Mappage des types de données
MySQL / Percona Server ont un certain nombre de types de données qui sont presque les mêmes qu'Oracle mais pas aussi riches qu'Oracle. Mais depuis l'arrivée de la version 5.7.8 de MySQL, il prend en charge un type de données JSON natif.
Vous trouverez ci-dessous sa représentation équivalente en type de données (la représentation tabulaire est tirée d'ici) :
| Oracle | MySQL | |||
|---|---|---|---|---|
| 1 | BFILE | Pointeur vers un fichier binaire, ⇐ 4G | VARCHAR(255) | |
| 2 | BINARY_FLOAT | Nombre à virgule flottante 32 bits | FLOAT | |
| 3 | BINARY_DOUBLE | Nombre à virgule flottante 64 bits | DOUBLE | |
| 4 | BLOB | Grand objet binaire, ⇐ 4G | LONGBLOB | |
| 5 | CARACTÈRE(n), CARACTÈRE(n) | Chaîne de longueur fixe, 1 ⇐ n ⇐ 255 | CARACTÈRE(n), CARACTÈRE(n) | |
| 6 | CARACTÈRE(n), CARACTÈRE(n) | Chaîne de longueur fixe, 256 ⇐ n ⇐ 2000 | VARCHAR(n) | |
| 7 | CLOB | Grand objet de caractère, ⇐ 4G | TEXTE LONG | |
| 8 | DATE | Date et heure | DATETIME | |
| 9 | DECIMAL(p,s), DEC(p,s) | Numéro à virgule fixe | DECIMAL(p,s), DEC(p,s) | |
| 10 | DOUBLE PRÉCISION | Nombre à virgule flottante | DOUBLE PRÉCISION | |
| 11 | FLOAT(p) | Nombre à virgule flottante | DOUBLE | |
| 12 | ENTIER, INT | Entier à 38 chiffres | INT | DECIMAL(38) |
| 13 | INTERVALLE ANNÉE(p) À MOIS | Intervalle de dates | VARCHAR(30) | |
| 14 | INTERVALLE JOUR(p) À SECONDE(s) | Jour et intervalle de temps | VARCHAR(30) | |
| 15 | LONG | Données de caractère, ⇐ 2G | TEXTE LONG | |
| 16 | LONG RAW | Données binaires, ⇐ 2G | LONGBLOB | |
| 17 | NCHAR(n) | Chaîne UTF-8 de longueur fixe, 1 ⇐ n ⇐ 255 | NCHAR(n) | |
| 18 | NCHAR(n) | Chaîne UTF-8 de longueur fixe, 256 ⇐ n ⇐ 2000 | NVARCHAR(n) | |
| 19 | NCHAR VARIANT(n) | Chaîne UTF-8 de longueur variable, 1 ⇐ n ⇐ 4000 | NCHAR VARIABLE(n) | |
| 20 | NCLOB | Chaîne Unicode de longueur variable, ⇐ 4G | NVARCHAR(max) | |
| 21 | NOMBRE(p,0), NOMBRE(p) | Entier 8 bits, 1 <=p <3 | TINYINT | (0 à 255) |
| Entier 16 bits, 3 <=p <5 | PETIT INTÉRIEUR | |||
| Entier 32 bits, 5 <=p <9 | INT | |||
| Entier 64 bits, 9 <=p <19 | GRANDINT | |||
| Nombre à virgule fixe, 19 <=p <=38 | DECIMAL(p) | |||
| 22 | NOMBRE(p,s) | Nombre à virgule fixe, s> 0 | DECIMAL(p,s) | |
| 23 | NOMBRE, NOMBRE(*) | Nombre à virgule flottante | DOUBLE | |
| 24 | NUMÉRIQUE(p,s) | Numéro à virgule fixe | NUMÉRIQUE(p,s) | |
| 25 | NVARCHAR2(n) | Chaîne UTF-8 de longueur variable, 1 ⇐ n ⇐ 4000 | NVARCHAR(n) | |
| 26 | RAW(n) | Chaîne binaire de longueur variable, 1 ⇐ n ⇐ 255 | BINAIRE(n) | |
| 27 | RAW(n) | Chaîne binaire de longueur variable, 256 ⇐ n ⇐ 2000 | VARBINAIRE(n) | |
| 28 | RÉEL | Nombre à virgule flottante | DOUBLE | |
| 29 | ROWID | Adresse de ligne physique | CHAR(10) | |
| 30 | SMALLINT | Entier à 38 chiffres | DECIMAL(38) | |
| 31 | TIMESTAMP(p) | Date et heure avec fraction | DATETIME(p) | |
| 32 | TIMESTAMP(p) AVEC FUSEAU HORAIRE | Date et heure avec fraction et fuseau horaire | DATETIME(p)  | |
| 33 | UROWID(n) | Adresses de lignes logiques, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 34 | VARCHAR(n) | Chaîne de longueur variable, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 35 | VARCHAR2(n) | Chaîne de longueur variable, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 36 | XMLTYPE | Données XML | TEXTE LONG | |
Attributs et options de type de données :
| Oracle | MySQL |
| Sémantique de la taille des colonnes BYTE et CHAR | La taille est toujours en caractères |
Transactions
Percona Server utilise XtraDB (une version améliorée d'InnoDB) comme moteur de stockage principal pour gérer les données transactionnelles ; bien que divers moteurs de stockage puissent être un choix alternatif pour gérer les transactions, tels que les moteurs de stockage TokuDB (obsolète) et MyRocks.
Bien qu'il y ait des avantages et des avantages à utiliser ou à explorer MyRocks avec XtraDB, ce dernier est un moteur de stockage plus robuste et de facto que Percona Server utilise et est activé par défaut, nous utiliserons donc ce moteur de stockage comme base pour la migration en ce qui concerne aux transactions.
Par défaut, Percona Server / MySQL a une variable de validation automatique définie sur ON, ce qui signifie que vous devez gérer explicitement les instructions transactionnelles pour tirer parti de ROLLBACK pour ignorer les modifications ou profiter de l'utilisation de SAVEPOINT.
C'est fondamentalement le même concept qu'Oracle utilise en termes de validation, de restauration et de points de sauvegarde.
Pour les transactions explicites, cela signifie que vous devez utiliser le START TRANSACTION/BEGIN ;
Sinon, si vous devez désactiver la validation automatique, vous devez explicitement COMMIT tout le temps pour vos déclarations qui nécessitent des modifications de vos données.
Table double
MySQL a la double compatibilité avec Oracle qui est destinée à la compatibilité des bases de données utilisant une table factice, à savoir DUAL.
Cela convient à l'utilisation de DUAL par Oracle, de sorte que toutes les instructions existantes dans votre application qui utilisent DUAL peuvent ne nécessiter aucune modification lors de la migration vers Percona Server.
La clause Oracle FROM est obligatoire pour chaque instruction SELECT, donc la base de données Oracle utilise la table DUAL pour l'instruction SELECT où un nom de table n'est pas requis.
Dans MySQL, la clause FROM n'est pas obligatoire donc la table DUAL n'est pas nécessaire. Cependant, la table DUAL ne fonctionne pas exactement de la même manière que pour Oracle, mais pour les SELECT simples dans Percona Server, cela convient.
Voir l'exemple suivant ci-dessous :
Dans 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:00Mais dans 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)Remarque :le DESC DUAL La syntaxe ne fonctionne pas dans MySQL et les résultats diffèrent également car CURRENT_TIMESTAMP (utilise le type de données TIMESTAMP) dans MySQL n'inclut pas le fuseau horaire.
DATESYS
La fonction SYSDATE d'Oracle est presque la même dans MySQL.
MySQL renvoie la date et l'heure et est une fonction qui nécessite () (parenthèses fermantes et ouvrantes sans arguments requis. Pour le démontrer ci-dessous, voici Oracle et MySQL sur l'utilisation de SYSDATE.
Dans Oracle, l'utilisation de SYSDATE simple renvoie simplement la date du jour sans l'heure. Mais pour obtenir l'heure et la date, utilisez TO_CHAR pour convertir l'heure de la date dans le format souhaité ; alors que dans MySQL, vous n'en aurez peut-être pas besoin pour obtenir la date et l'heure car il renvoie les deux.
Voir l'exemple ci-dessous.
Dans 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-19Mais dans MySQL :
mysql> SELECT SYSDATE() FROM DUAL;
+---------------------+
| SYSDATE() |
+---------------------+
| 2019-02-15 20:37:36 |
+---------------------+
1 row in set (0.00 sec)Si vous voulez formater la date, MySQL a une fonction DATE_FORMAT().
Vous pouvez consulter la documentation MySQL Date and Time pour plus d'informations.
TO_DATE
L'équivalent TO_DATE d'Oracle dans MySQL est la fonction STR_TO_DATE().
Il est presque identique à celui d'Oracle :il renvoie le type de données DATE, tandis que dans MySQL, il renvoie le type de données DATETIME.
Oracle :
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)SYNONYME
Dans MySQL, il n'y a pas un tel support ni aucune équivalence pour SYNONYM dans Oracle.
Une alternative possible peut être possible avec MySQL en utilisant VIEW.
Bien que SYNONYM puisse être utilisé pour créer un alias d'une table distante,
ex.
CREATE PUBLIC SYNONYM emp_table FOR [email protected]Dans MySQL, vous pouvez tirer parti de l'utilisation du moteur de stockage FEDERATED.
ex.
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';Ou vous pouvez simplifier le processus avec la syntaxe CREATE SERVER, de sorte que lors de la création d'une table agissant comme votre SYNONYM pour accéder à une table distante, ce sera plus facile. Voir la documentation pour plus d'informations à ce sujet.
Comportement de chaîne vide et NULL
Notez que dans Percona Server / MySQL, la chaîne vide n'est pas NULL alors qu'Oracle traite la chaîne vide comme des valeurs nulles.
Dans Oracle :
SQL> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
Nul
---
YesDans 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)Séquences
Dans MySQL, il n'y a pas exactement la même approche de ce qu'Oracle fait pour SEQUENCE.
Bien que certains messages simulent la fonctionnalité de cette approche, vous pourrez peut-être essayer d'obtenir la clé suivante à l'aide de LAST_INSERT_ID() tant que l'index clusterisé de votre table, PRIMARY KEY, est défini avec <
Fonctions de chaînes de caractères
Contrairement à Oracle, MySQL / Percona Server a une poignée de fonctions de chaîne mais pas autant de fonctions utiles intégrées à la base de données.
Il serait trop long d'en discuter ici un par un, mais vous pouvez consulter la documentation de MySQL et la comparer aux fonctions de chaîne d'Oracle.
Déclarations DML
Les instructions d'insertion/mise à jour/suppression d'Oracle sont compatibles avec MySQL.
INSÉRER TOUT/INSÉRER EN PREMIER d'Oracle n'est pas pris en charge dans MySQL.
Sinon, vous devrez énoncer vos requêtes MySQL une par une.
ex.
Dans 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 lignes créées.
Mais dans MySQL, vous devez exécuter l'insert un par un :
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)Le INSERT ALL/INSERT FIRST n'est pas comparable à la façon dont il est utilisé dans Oracle, où vous pouvez tirer parti des conditions en ajoutant un mot-clé WHEN dans votre syntaxe; il n'y a pas d'option équivalente dans MySQL / Percona Server dans ce cas.
Par conséquent, votre solution alternative consiste à utiliser des procédures.
Symbole "+" des jointures externes
Dans Oracle, l'utilisation de l'opérateur + pour les jointures gauche et droite n'est pas prise en charge actuellement dans MySQL, car l'opérateur + n'est utilisé que pour les décisions arithmétiques.
Par conséquent, si vous avez l'opérateur + dans vos instructions Oracle SQL existantes, vous devez le remplacer par LEFT JOIN ou RIGHT JOIN.
Vous voudrez peut-être consulter la documentation officielle pour "Outer Join Simplification" de MySQL.
COMMENCER PAR..CONNECTER PAR
Oracle utilise START WITH..CONNECT BY pour les requêtes hiérarchiques.
À partir de MySQL / Percona 8.0, il existe un support pour générer des résultats de données hiérarchiques qui utilisent des modèles tels que la liste de contiguïté ou les modèles d'ensembles imbriqués. C'est ce qu'on appelle les expressions de table communes (CTE) dans MySQL.
Semblable à PostgreSQL, MySQL utilise AVEC RECURSIVE syntaxe pour les requêtes hiérarchiques donc traduisez CONNECT BY instruction en AVEC RECURSIF déclaration.
Vérifiez ci-dessous en quoi il diffère d'ORACLE et de MySQL / Percona Server.
Dans 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; Et dans 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 dans MySQL/Percona ?
MySQL / Percona RDBMS a une approche différente de celle du PL/SQL d'Oracle.
MySQL utilise des procédures stockées ou des fonctions stockées, qui sont similaires à PL/SQL et à la syntaxe utilisant BEGIN..END syntaxe.
Le PL/SQL d'Oracle est compilé avant l'exécution lorsqu'il est chargé sur le serveur, tandis que MySQL est compilé et stocké dans le cache lorsqu'il est invoqué.
Vous voudrez peut-être consulter cette documentation comme guide de référence sur la conversion de votre PL/SQL en MySQL.
Outils de migration
J'ai fait des recherches sur les outils qui pourraient être une norme de facto pour la migration, mais je n'ai pas trouvé de bonne réponse.
Cependant, j'ai trouvé sqlines et cela semble simple mais prometteur.
Bien que je ne l'aie pas approfondi, le site Web offre une poignée d'informations qui pourraient vous aider à migrer d'Oracle vers MySQL/Percona Server. Il existe également des outils payants tels que ceci et cela.
J'ai également cherché sur github mais je n'ai rien trouvé de plus attrayant comme solution au problème. Par conséquent, si vous envisagez de migrer d'Oracle vers Amazon, ils disposent d'AWS Schema Conversion Tool pour lequel la migration d'Oracle vers MySQL est prise en charge.
Dans l'ensemble, la raison pour laquelle la migration n'est pas une chose facile à faire est principalement parce qu'Oracle RDBMS est une telle bête avec de nombreuses fonctionnalités que Percona Server / MySQL ou MariaDB RDBMS n'ont toujours pas.
Quoi qu'il en soit, si vous trouvez ou connaissez des outils que vous trouvez utiles et bénéfiques pour migrer d'Oracle vers MySQL / Percona Server, veuillez laisser un commentaire sur ce blog !
Test
Dans le cadre de votre plan de migration, les tests sont une tâche vitale qui joue un rôle très important et affecte votre décision en matière de migration.
L'outil dbdeployer (un port de MySQL Sandbox) est un outil très utile dont vous pouvez tirer parti. C'est assez facile pour vous d'essayer et de tester différentes approches et cela vous fait gagner du temps, plutôt que de configurer toute la pile si votre objectif est d'essayer et de tester d'abord la plate-forme RDBMS.
Pour tester vos routines stockées SQL (fonctions ou procédures), déclencheurs, événements, je vous suggère d'utiliser ces outils mytap ou le cadre de test unitaire de Google.
Percona propose également un certain nombre d'outils qui peuvent être téléchargés sur leur site Web. Découvrez la boîte à outils Percona ici. Vous pouvez sélectionner les outils en fonction de vos besoins, en particulier pour les tâches de test et d'utilisation en production.
Dans l'ensemble, les éléments que vous devez garder à l'esprit lorsque vous effectuez un test pour votre serveur MySQL sont :
- Après votre installation, vous devez envisager de faire quelques ajustements. Consultez ce blog Percona pour obtenir de l'aide.
- Effectuez des tests de performances et des tests de charge pour votre configuration de configuration sur votre nœud actuel. Consultez mysqlslap et sysbench qui peuvent vous aider. Consultez également notre blog "Comment évaluer les performances de MySQL et MariaDB à l'aide de SysBench".
- Vérifiez vos DDL s'ils sont correctement définis, tels que les types de données, les contraintes, les index clusterisés et secondaires, ou les partitions, si vous en avez.
- Vérifiez votre DML, en particulier si la syntaxe est correcte et enregistrez les données correctement comme prévu.
- Vérifiez vos routines, événements et déclencheurs stockés pour vous assurer qu'ils exécutent/renvoyent les résultats attendus.
- Vérifiez que vos requêtes en cours d'exécution sont performantes. Je vous suggère de profiter des outils open-source ou d'essayer notre produit ClusterControl. Il offre une surveillance/observabilité en particulier de votre serveur MySQL/Percona. Vous pouvez utiliser ClusterControl ici pour surveiller vos requêtes et son plan de requête afin de vous assurer qu'elles sont performantes.
