La migrazione da Oracle a MySQL/Percona Server non è un compito banale. Anche se sta diventando più facile, soprattutto con l'arrivo di MySQL 8.0 e Percona ha annunciato Percona Server per MySQL 8.0 GA. Oltre a pianificare la migrazione da Oracle a Percona Server, devi assicurarti di aver compreso lo scopo e la funzionalità per cui deve essere Percona Server.
Questo blog si concentrerà sulla migrazione da Oracle a Percona Server come database di destinazione specifico. C'è una pagina nel sito Web di Oracle sulle informazioni supplementari per gli sviluppatori SQL per le migrazioni MySQL che possono essere utilizzate come riferimento per la migrazione pianificata. Questo blog non tratterà l'intero processo di migrazione, poiché è un processo lungo. Ma si spera che fornisca informazioni di base sufficienti per fungere da guida per il processo di migrazione.
Poiché Percona Server è un fork di MySQL, in Percona Server sono presenti quasi tutte le funzionalità presenti in MySQL. Quindi qualsiasi riferimento a MySQL qui è applicabile anche a Percona Server. In precedenza abbiamo scritto sul blog sulla migrazione di Oracle Database a PostgreSQL. Ribadirò di nuovo i motivi per cui si potrebbe prendere in considerazione la migrazione da Oracle a un RDBMS open source come PostgreSQL o Percona Server/MySQL/MariaDB.
- Costo:come forse saprai, il costo della licenza Oracle è molto elevato e c'è un costo aggiuntivo per alcune funzionalità come il partizionamento e l'elevata disponibilità. Quindi nel complesso è molto costoso.
- Licenze open source flessibili e facile disponibilità da provider di cloud pubblico come AWS.
- Trai vantaggio dai componenti aggiuntivi open source per migliorare le prestazioni.
Strategia di pianificazione e sviluppo
La migrazione da Oracle a Percona Server 8.0 può essere un problema poiché ci sono molti fattori chiave che devono essere considerati e affrontati. Ad esempio, Oracle può essere eseguito su una macchina Windows Server ma Percona Server non supporta Windows. Sebbene tu possa compilarlo per Windows, Percona stesso non offre alcun supporto per Windows. È inoltre necessario identificare i requisiti dell'architettura del database, poiché Percona Server non è progettato per OLAP (Online Analytical Processing) o applicazioni di data warehousing. Percona Server/MySQL RDBMS sono perfetti per OLTP (Online Transaction Processing).
Identificando l'aspetto chiave della tua architettura di database, ad esempio se la tua attuale architettura Oracle implementa MAA (Maximum Available Architecture) con Data Guard ++ Oracle RAC (Real Application Cluster), dovresti determinarne l'equivalenza in Percona Server. Non esiste una risposta diretta per questo all'interno di MySQL/Percona Server. Tuttavia, puoi scegliere tra una replica sincrona, una replica asincrona (Percona XtraDB Cluster è ancora nella versione 5.7.x) o con Group Replication. Quindi, ci sono più alternative che puoi implementare per la tua soluzione ad alta disponibilità. Ad esempio, (solo per citarne alcuni) utilizzando lo stack Corosync/Pacemaker/DRBD/Linux, o utilizzando MHA (MySQL High Availability) o utilizzando lo stack Keepalived/HaProxy/ProxySQL, o semplicemente fare affidamento su ClusterControl che supporta Keepalived, HaProxy, ProxySQL, Garbd e Maxscale per le tue soluzioni ad alta disponibilità.
D'altra parte, la domanda che devi considerare anche come parte del piano è "In che modo Percona fornirà supporto e chi ci aiuterà quando Percona Server stesso incontra un bug o quanto è alta l'urgenza quando abbiamo bisogno di aiuto?". Un'altra cosa da considerare è il budget, se lo scopo della migrazione dal database aziendale a un RDBMS open source è dovuto alla riduzione dei costi.
Ci sono diverse opzioni dalla pianificazione della migrazione alle cose che devi fare come parte della tua strategia di sviluppo. Tali opzioni includono il coinvolgimento di esperti nel campo MySQL/Percona Server e questo include noi qui a Manynines. Ci sono molte società di consulenza MySQL che possono aiutarti in questo poiché la migrazione da Oracle a MySQL richiede molta esperienza e know-how nell'area di MySQL Server. Questo non dovrebbe essere limitato al database, ma dovrebbe coprire competenze in materia di scalabilità, ridondanza, backup, alta disponibilità, sicurezza, monitoraggio/osservabilità, ripristino e coinvolgimento di sistemi mission-critical. Nel complesso, dovrebbe avere una comprensione delle tue informazioni sull'architettura senza esporre la riservatezza dei tuoi dati.
Valutazione o verifica preliminare
Il backup dei dati inclusi le configurazioni o i file di installazione, le regolazioni del kernel, gli script di automazione non devono essere lasciati nell'oblio. È un'attività ovvia, ma prima di eseguire la migrazione, assicurati sempre prima tutto , soprattutto quando passi a una piattaforma diversa.
È inoltre necessario valutare che le applicazioni seguano le convenzioni di ingegneria del software aggiornate e assicurarsi che siano indipendenti dalla piattaforma. Queste pratiche possono essere a tuo vantaggio soprattutto quando passi a una piattaforma di database diversa, come Percona Server for MySQL.
Tieni presente che il sistema operativo richiesto da Percona Server può essere un ostacolo se l'applicazione e il database vengono eseguiti su un server Windows e l'applicazione dipende da Windows; allora questo potrebbe essere un sacco di lavoro! Ricorda sempre che Percona Server si trova su una piattaforma diversa:la perfezione potrebbe non essere garantita ma può essere raggiunta abbastanza vicino.
Infine, assicurati che l'hardware di destinazione sia progettato per funzionare in modo fattibile con i requisiti del server di Percona o che almeno sia privo di bug (vedi qui). Potresti considerare di eseguire prima lo stress test con Percona Server prima di abbandonare in modo affidabile il tuo database Oracle.
Cosa dovresti sapere
Vale la pena notare che in Percona Server / MySQL puoi creare più database mentre Oracle non ha le stesse funzionalità di MySQL.
In MySQL, fisicamente, uno schema è sinonimo di database. Puoi sostituire la parola chiave SCHEMA invece di DATABASE nella sintassi SQL di MySQL, ad esempio usando CREATE SCHEMA invece di CREA DATABASE; mentre Oracle ha una distinzione di questo. Uno schema rappresenta solo una parte di un database:le tabelle e altri oggetti di proprietà di un singolo utente. Normalmente, esiste una relazione uno-a-uno tra l'istanza e il database.
Ad esempio, in una configurazione di replica equivalente in Oracle (ad es. Real Application Clusters o RAC), hai più istanze che accedono a un singolo database. Ciò ti consente di avviare Oracle su più server, ma tutti accedono agli stessi dati. Tuttavia, in MySQL, puoi consentire l'accesso a più database dalle tue istanze multiple e puoi persino filtrare i database/schemi che puoi replicare su un nodo MySQL.
Facendo riferimento a uno dei nostri precedenti blog, lo stesso principio si applica quando si parla di convertire il database con gli strumenti disponibili trovati su Internet.
Non esiste uno strumento del genere in grado di convertire al 100% il database Oracle in Percona Server / MySQL; parte sarà un lavoro manuale.
Dai un'occhiata alle seguenti sezioni per informazioni di cui devi essere a conoscenza quando si tratta di migrazione e verifica del risultato SQL logico.
Mappatura del tipo di dati
MySQL/Percona Server ha un numero di tipi di dati che è quasi lo stesso di Oracle ma non così ricco rispetto a Oracle. Ma dall'arrivo della versione 5.7.8 di MySQL, è supportato un tipo di dati JSON nativo.
Di seguito è riportata la sua rappresentazione equivalente del tipo di dati (la rappresentazione tabellare è tratta da qui):
| Oracolo | MySQL | |||
|---|---|---|---|---|
| 1 | BFILE | Puntatore a file binario, ⇐ 4G | VARCHAR(255) | |
| 2 | BINARY_FLOAT | Numero a virgola mobile a 32 bit | GALLEGGIANTE | |
| 3 | BINARY_DOUBLE | Numero a virgola mobile a 64 bit | DOPPIA | |
| 4 | BLOB | Oggetto binario di grandi dimensioni, ⇐ 4G | LONGBLOB | |
| 5 | CHAR(n), CHARACTER(n) | Stringa a lunghezza fissa, 1 ⇐ n ⇐ 255 | CHAR(n), CHARACTER(n) | |
| 6 | CHAR(n), CHARACTER(n) | Stringa a lunghezza fissa, 256 ⇐ n ⇐ 2000 | VARCHAR(n) | |
| 7 | CLOB | Oggetto grande personaggio, ⇐ 4G | LOGTESTO | |
| 8 | DATA | Data e ora | DATETIME | |
| 9 | DECIMAL(p,s), DEC(p,s) | Numero a virgola fissa | DECIMAL(p,s), DEC(p,s) | |
| 10 | DOPPIA PRECISIONE | Numero in virgola mobile | DOPPIA PRECISIONE | |
| 11 | FLOAT(p) | Numero in virgola mobile | DOPPIA | |
| 12 | INTERO, INT | Intero di 38 cifre | INT | DECIMAL(38) |
| 13 | INTERVALLO ANNO(p) AL MESE | Intervallo di date | VARCHAR(30) | |
| 14 | INTERVALLO GIORNO(p) A SECONDO(i) | Giorno e intervallo di tempo | VARCHAR(30) | |
| 15 | LUNGO | Dati sui caratteri, ⇐ 2G | LOGTESTO | |
| 16 | LUNGO CRUDO | Dati binari, ⇐ 2G | LONGBLOB | |
| 17 | NCHAR(n) | Stringa UTF-8 a lunghezza fissa, 1 ⇐ n ⇐ 255 | NCHAR(n) | |
| 18 | NCHAR(n) | Stringa UTF-8 a lunghezza fissa, 256 ⇐ n ⇐ 2000 | NVARCHAR(n) | |
| 19 | NCHAR VARIANTE(n) | Stringa UTF-8 di lunghezza variabile, 1 ⇐ n ⇐ 4000 | NCHAR VARIANTE(n) | |
| 20 | NCLOB | Stringa Unicode a lunghezza variabile, ⇐ 4G | NVARCHAR(max) | |
| 21 | NUMERO(p,0), NUMERO(p) | Intero a 8 bit, 1 <=p <3 | TINYINT | (da 0 a 255) |
| Intero a 16 bit, 3 <=p <5 | PICCOLA | |||
| Intero a 32 bit, 5 <=p <9 | INT | |||
| Intero a 64 bit, 9 <=p <19 | GRANDE | |||
| Numero a virgola fissa, 19 <=p <=38 | DECIMAL(p) | |||
| 22 | NUMERO(p,s) | Numero a virgola fissa, s> 0 | DECIMAL(p,s) | |
| 23 | NUMERO, NUMERO(*) | Numero in virgola mobile | DOPPIA | |
| 24 | NUMERICO(p,s) | Numero a virgola fissa | NUMERIC(p,s) | |
| 25 | NVARCHAR2(n) | Stringa UTF-8 a lunghezza variabile, 1 ⇐ n ⇐ 4000 | NVARCHAR(n) | |
| 26 | RAW(n) | Stringa binaria a lunghezza variabile, 1 ⇐ n ⇐ 255 | BINARIO(n) | |
| 27 | RAW(n) | Stringa binaria a lunghezza variabile, 256 ⇐ n ⇐ 2000 | VARBINARY(n) | |
| 28 | REALE | Numero in virgola mobile | DOPPIA | |
| 29 | ROWID | Indirizzo di riga fisico | CHAR(10) | |
| 30 | SMALLINT | Intero di 38 cifre | DECIMA(38) | |
| 31 | TIMESTAMP(p) | Data e ora con frazione | DATETIME(p) | |
| 32 | TIMESTAMP(p) CON FUSO ORARIO | Data e ora con frazione e fuso orario | DATETIME(p)  | |
| 33 | UROWID(n) | Indirizzi di riga logici, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 34 | VARCHAR(n) | Stringa a lunghezza variabile, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 35 | VARCHAR2(n) | Stringa a lunghezza variabile, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 36 | TIPOXML | Dati XML | LOGTESTO | |
Attributi e opzioni del tipo di dati:
| Oracolo | MySQL |
| Semantica delle dimensioni delle colonne BYTE e CHAR | La dimensione è sempre in caratteri |
Transazioni
Percona Server utilizza XtraDB (una versione avanzata di InnoDB) come motore di archiviazione principale per la gestione dei dati transazionali; sebbene vari motori di archiviazione possano essere una scelta alternativa per la gestione di transazioni come TokuDB (obsoleto) e motori di archiviazione MyRocks.
Sebbene ci siano vantaggi e vantaggi nell'utilizzo o nell'esplorazione di MyRocks con XtraDB, quest'ultimo è un motore di archiviazione più robusto e di fatto utilizzato da Percona Server ed è abilitato per impostazione predefinita, quindi utilizzeremo questo motore di archiviazione come base per la migrazione per quanto riguarda alle transazioni.
Per impostazione predefinita, Percona Server/MySQL ha la variabile autocommit impostata su ON, il che significa che devi gestire esplicitamente le istruzioni transazionali per sfruttare ROLLBACK per ignorare le modifiche o sfruttare SAVEPOINT.
È fondamentalmente lo stesso concetto utilizzato da Oracle in termini di commit, rollback e punti di salvataggio.
Per le transazioni esplicite, questo significa che devi usare START TRANSACTION/BEGIN;
Altrimenti, se devi disabilitare l'autocommit, devi impegnarti in modo esplicito in ogni momento per le tue dichiarazioni che richiedono modifiche ai tuoi dati.
Tabella doppia
MySQL ha la doppia compatibilità con Oracle che è pensata per la compatibilità dei database utilizzando una tabella fittizia, ovvero DUAL.
Ciò si adatta all'utilizzo di DUAL da parte di Oracle, pertanto qualsiasi istruzione esistente nell'applicazione che utilizza DUAL potrebbe non richiedere modifiche durante la migrazione a Percona Server.
La clausola Oracle FROM è obbligatoria per ogni istruzione SELECT, quindi il database Oracle utilizza la tabella DUAL per l'istruzione SELECT dove non è richiesto un nome di tabella.
In MySQL, la clausola FROM non è obbligatoria, quindi la tabella DUAL non è necessaria. Tuttavia, la tabella DUAL non funziona esattamente come per Oracle, ma per semplici SELECT in Percona Server va bene.
Vedere il seguente esempio di seguito:
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:00Ma 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)Nota:il DESC DUAL la sintassi non funziona in MySQL e anche i risultati differiscono poiché CURRENT_TIMESTAMP (usa il tipo di dati TIMESTAMP) in MySQL non include il fuso orario.
SYSDATE
La funzione SYSDATE di Oracle è quasi la stessa in MySQL.
MySQL restituisce data e ora ed è una funzione che richiede () (chiudi e apri parentesi senza argomenti richiesti. Per dimostrarlo di seguito, ecco Oracle e MySQL sull'utilizzo di SYSDATE.
In Oracle, l'utilizzo di SYSDATE semplice restituisce semplicemente la data del giorno senza l'ora. Ma per ottenere l'ora e la data, usa TO_CHAR per convertire la data e l'ora nel formato desiderato; mentre in MySQL, potresti non averne bisogno per ottenere la data e l'ora poiché restituisce entrambe.
Vedi esempio sotto.
In 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-19Ma in MySQL:
mysql> SELECT SYSDATE() FROM DUAL;
+---------------------+
| SYSDATE() |
+---------------------+
| 2019-02-15 20:37:36 |
+---------------------+
1 row in set (0.00 sec)Se vuoi formattare la data, MySQL ha una funzione DATE_FORMAT().
Puoi controllare la documentazione di MySQL Date and Time per maggiori informazioni.
TO_DATE
L'equivalente TO_DATE di Oracle in MySQL è la funzione STR_TO_DATE().
È quasi identico a quello in Oracle:restituisce il tipo di dati DATE, mentre in MySQL restituisce il tipo di dati DATETIME.
Oracolo:
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)SINONIMI
In MySQL, non esiste tale supporto né alcuna equivalenza per SYNONYM in Oracle.
Una possibile alternativa possibile con MySQL è l'utilizzo di VIEW.
Sebbene SYNONYM possa essere utilizzato per creare un alias di una tabella remota,
es.
CREATE PUBLIC SYNONYM emp_table FOR [email protected]In MySQL, puoi trarre vantaggio dall'utilizzo del motore di archiviazione FEDERATED.
es.
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';Oppure puoi semplificare il processo con la sintassi CREATE SERVER, in modo che quando crei una tabella che funge da SINONIMO per accedere a una tabella remota, sarà più facile. Consulta la documentazione per maggiori informazioni al riguardo.
Comportamento di stringa vuota e NULL
Tieni presente che in Percona Server / MySQL, la stringa vuota non è NULL mentre Oracle tratta la stringa vuota come valori nulli.
In 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)Sequenze
In MySQL, non esiste esattamente lo stesso approccio a ciò che Oracle fa per SEQUENCE.
Sebbene ci siano alcuni post che simulano la funzionalità di questo approccio, potresti essere in grado di provare a ottenere la chiave successiva usando LAST_INSERT_ID() purché l'indice cluster della tua tabella, CHIAVE PRIMARIA, sia definito con <
Funzioni di stringhe di caratteri
A differenza di Oracle, MySQL/Percona Server ha una manciata di funzioni di stringa ma non tante funzioni utili integrate nel database.
Sarebbe troppo lungo discuterne qui uno per uno, ma puoi controllare la documentazione di MySQL e confrontarla con le funzioni di stringa di Oracle.
Dichiarazioni DML
Le istruzioni Inserisci/Aggiorna/Elimina da Oracle sono congrue in MySQL.
INSERT ALL/INSERT FIRST di Oracle non è supportato in MySQL.
Altrimenti, dovresti dichiarare le tue query MySQL una per una.
es.
In 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 righe create.
Ma in MySQL, devi eseguire l'inserimento uno alla volta:
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 non è paragonabile a come viene utilizzato in Oracle, dove puoi sfruttare le condizioni aggiungendo una parola chiave WHEN nella tua sintassi; in questo caso non esiste un'opzione equivalente in MySQL/Percona Server.
Quindi, la tua soluzione alternativa a questo è usare le procedure.
Simbolo "+" di unione esterna
In Oracle, l'utilizzo dell'operatore + per i join sinistro e destro non è attualmente supportato in MySQL poiché l'operatore + viene utilizzato solo per decisioni aritmetiche.
Quindi, se hai l'operatore + nelle tue istruzioni Oracle SQL esistenti, devi sostituirlo con LEFT JOIN o RIGHT JOIN.
Potresti voler controllare la documentazione ufficiale per "Outer Join Semplification" di MySQL.
INIZIA CON..COLLEGATI BY
Oracle utilizza START WITH..CONNECT BY per le query gerarchiche.
A partire da MySQL/Percona 8.0, è disponibile il supporto per la generazione di risultati di dati gerarchici che utilizzano modelli come l'elenco di adiacenza oi modelli di insiemi nidificati. Questo è chiamato Common Table Expressions (CTE) in MySQL.
Simile a PostgreSQL, MySQL usa CON RICORSO sintassi per le query gerarchiche, quindi traduci CONNECT BY dichiarazione in CON RICORSIVA dichiarazione.
Controlla di seguito come differisce da ORACLE e in MySQL / Percona Server.
In 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; E 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 ha un approccio diverso rispetto a PL/SQL di Oracle.
MySQL utilizza stored procedure o funzioni memorizzate, che è simile a PL/SQL e la sintassi usando BEGIN..END sintassi.
PL/SQL di Oracle viene compilato prima dell'esecuzione quando viene caricato nel server, mentre MySQL viene compilato e archiviato nella cache quando viene richiamato.
Potresti voler controllare questa documentazione come guida di riferimento sulla conversione di PL/SQL in MySQL.
Strumenti di migrazione
Ho fatto qualche ricerca per eventuali strumenti che potrebbero essere uno standard de facto per la migrazione, ma non sono riuscito a trovare una buona risposta.
Tuttavia, ho trovato sqlines e sembra semplice ma promettente.
Anche se non l'ho approfondito, il sito Web offre una manciata di approfondimenti, che potrebbero aiutarti a migrare da Oracle a MySQL/Percona Server. Ci sono anche strumenti a pagamento come questo e questo.
Ho anche cercato su github ma non ho trovato nulla di molto più allettante come soluzione al problema. Quindi, se stai mirando a migrare da Oracle e ad Amazon, hanno AWS Schema Conversion Tool per il quale è supportata la migrazione da Oracle a MySQL.
Nel complesso, il motivo per cui la migrazione non è una cosa facile da fare è principalmente perché Oracle RDBMS è una tale bestia con molte funzionalità che Percona Server / MySQL o MariaDB RDBMS non hanno ancora.
Ad ogni modo, se trovi o conosci strumenti che ritieni utili e utili per la migrazione da Oracle a MySQL/Percona Server, lascia un commento su questo blog!
Test
Come parte del tuo piano di migrazione, il test è un'attività vitale che svolge un ruolo molto importante e influisce sulla tua decisione in merito alla migrazione.
Lo strumento dbdeployer (un port di MySQL Sandbox) è uno strumento molto utile che puoi sfruttare. È abbastanza facile per te provare a testare approcci diversi e ti fa risparmiare tempo, piuttosto che impostare l'intero stack se il tuo scopo è provare prima a testare la piattaforma RDBMS.
Per testare le routine memorizzate SQL (funzioni o procedure), trigger, eventi, ti suggerisco di utilizzare questi strumenti mytap o lo Unit Testing Framework di Google.
Anche Percona offre una serie di strumenti disponibili per il download sul proprio sito Web. Checkout Percona Toolkit qui. Puoi scegliere gli strumenti in base alle tue esigenze, in particolare per le attività di test e utilizzo della produzione.
Nel complesso, le cose che devi tenere a mente come linee guida quando fai un test per il tuo server MySQL sono:
- Dopo l'installazione, è necessario prendere in considerazione la possibilità di eseguire alcune modifiche. Dai un'occhiata a questo blog di Percona per ricevere assistenza.
- Esegui alcuni benchmark e test di carico di stress per l'impostazione della configurazione sul nodo corrente. Dai un'occhiata a mysqlslap e sysbench che possono aiutarti in questo. Dai un'occhiata anche al nostro blog "Come confrontare le prestazioni di MySQL e MariaDB usando SysBench".
- Controlla i tuoi DDL se sono definiti correttamente come tipi di dati, vincoli, indici cluster e secondari o partizioni, se ne hai.
- Controlla il tuo DML soprattutto se la sintassi è corretta e stai salvando i dati correttamente come previsto.
- Controlla le routine, gli eventi e i trigger memorizzati per assicurarti che eseguano/restituiscano i risultati attesi.
- Verifica che le tue query in esecuzione siano performanti. Ti suggerisco di sfruttare gli strumenti open-source o di provare il nostro prodotto ClusterControl. Offre monitoraggio/osservabilità in particolare del tuo server MySQL/Percona. Puoi utilizzare ClusterControl qui per monitorare le tue query e il relativo piano di query per assicurarti che siano performanti.
