SQLWays per la migrazione da Oracle a MySQL - White paper

Migrazione da Oracle a MySQL
Stored Procedure, Pacchetti, Trigger, Script e Applicazioni
White Paper
Marzo 2009, Ispirer Systems Ltd.
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
1
Introduzione
L'obiettivo di questo libro bianco è descrivere i fattori che influiscono la migrazione di
database e applicazioni da Oracle a MySQL. I fattori del costo e rischio saranno
descritti in dettaglio, e anche i tool e le metodologie che aiutano a raggiungere la prima
qualità di conversione.
Questo è la verità che il database MySQL di Sun può notevolmente ridurre il totale costo
di proprietà (Total Cost of Ownership (TCO)) di un'azienda abbassando i costi di licenze,
hardware e amministrazione. Il rischio più grande nel trasferimento su un'altra
piattaforma MySQL è i rischi e la complessità di migrazione della logica di business da
Oracle, soprattutto se le applicazioni esistenti usano spesso le procedure PL/SQL, trigger,
pacchetti e istruzioni SQL specifiche di Oracle.
La migrazione da Oracle a MySQL può essere molto faticosa, può richiedere tanto tempo ed
essere abbastanza costosa. Nondimeno, le metodologie approvate e i nostri tool possono
ridurre notevolmente i costi e il tempo necessario per il progetto di migrazione e anche
ridurre i rischi maggiori della conversione. Con l'aiuto del nostro prodotto - il tool
per migrazione SQLWays - una migrazione può essere valutata, disegnata e
automatizzata. Usando i nostri tool automatizzati in un modo corretto, avendo il processo
amministrativo ben organizzato, aziende possono risparmiare più di 70% del costo della
migrazione tradizionale manuale. Insieme con risparmi dall'implementazione di MySQL la
migrazione automatizzata diventa una soluzione alternativa veramente attrattiva.
Sfide
Il database Oracle ha le capacità avanzate di sviluppare la logica di un'applicazione che
si trova dentro di un database usando le stored procedure PL/SQL, funzioni, pacchetti e
trigger.
Oracle PL/SQL è un'estensione SQL procedurale potente facilmente gestita che viene
consigliata da Oracle per il suo performance. Nella maggior parte di applicazioni l'uso di
PL/SQL suscita l'esistenza del gran numero di procedure, pacchetti, e trigger. Nonostante
che MySQL ha la funzionalità molto simile con quella di Oracle, MySQL non usa PL/SQL.
Oltre la sintassi specifica di Oracle, PL/SQL offre molte caratteristiche che sono non-ANSI
compatibili, compreso le caratteristiche che si può trovare solo in Oracle. Tra queste
caratteristiche specifiche ci sono:
• Pacchetti - variabili condivise di pacchetti, pacchetti incorporati
• %TYPE, %ROWTYPE, eccezioni
• Caratteristiche orientate agli oggetti: tipi di oggetti, funzioni, e collezioni
• Il Business intelligence e le caratteristiche di XML, ecc.
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
2
La migrazione da Oracle a MySQL può essere molto difficile, soprattutto se le
caratteristiche specifiche di Oracle sono usate come, per esempio, le caratteristiche
sopra menzionate.
Tuttavia, la migraztione di questo tipo può essere effettuata abbastanza facilmente senza
tanti rischi. La migrazione viene realizzata facilmente se il database di destinazione ha
poche tabelle e la logica di business non è complicata.
I costi e i rischi sono diversi per ogni progetto di migarzione, perciò è molto importante
fare la valutazione preliminare.
Valutazione
L'obbiettivo della valutazione è definire le dimensioni del progetto, la fattibilità, costi e rischi
della migrazione di un database da Oracle a MySQL.
Valutazione di un database
Prima di tutto, si deve definire i tipi di oggetti in un database e la quantità di oggetti da
migrare. Tra oggetti ci sono:
•
•
•
•
•
•
•
Tabelle
Viste
Procedure
Funzioni
Pacchetti
Trigger
Sequenze, sinonimi ecc.
Se dovete convertire il codice PL/SQL (procedure, pacchetti, funzioni e trigger) oppure
viste/query contenenti la sintassi SQL specifica di Oracle, dovete studiare e venire a
sapere che caratteristiche vengono usate e determinare la quantità di queste
caratteristche. Tra le caratteristiche da contare ci sono:
•
•
•
•
•
•
•
Funzioni SQL Non-ANSI compatibili, operatori e istruzioni
Results sets
Cursor loops
Eccezioni
Tabelle Temp
Tipi di oggetti e funzioni
Collezioni
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
3
•
•
•
•
SQL dinamico
Pacchetti incorporati
Funzioni OLAP
Funzioni XML, ecc.
Dopo che finirete l'esame, è meglio scegliere gli equivalenti in MySQL o le soluzioni in
MySQL per sostituire le funzionalità specifiche di Oracle. Potete trovare le soluzioni tipiche
in capitoli seguenti.
Valutazione di un'applicazione
Oltre la conversione dello schema e della logica di business lato server, potete anche
modificare istruzioni SQL dentro l'applicazione. Si deve valutare l'entità del lavoro di questo
tipo prima di avviare la migrazione.
Per iniziare la migrazione dovete controllare che API di database viene usata nelle vostre
applicazioni per accedere al database in Oracle. Si deve anche notare quanti file sorgenti
dell'applicazione contengono il codice specifico di Oracle, quindi, questo codice deve
essere modificato per lavorare con MySQL.
La maggior parte di aplicazioni usano l'API standardizzata come ODBC, JDBC, o ADO.NET
per accedere a Oracle, ma alcune applicazioni usano l'API nativa come, per esempio,
Oracle OCI o Pro*C/C++. La racconta di tutta questa informazione è obbligatoria.
Nonostante che viene usata l'API standardizzata, per esempio, i driver ODBC/JDBC, i
cambiamenti importanti delle istruzioni SQL esistenti possono essere necessari. Per esempio,
funzioni DECODE o la sintassi ereditata left outer join (*) richiederà le modificazioni. Vi
consigliamo di contare la quantità di istruzioni SQL native.
Se l'applicazione usa l'API nativa come, per esempio, Oracle OCI, dovrete ridisegnare
completamente il codice dell'accesso al database per utilizzare MySQL API o ODBC.
I tool per valutazione
Bisogna sapere quante caratteristiche specifiche ci sono in un database. Com'è possibile
valutare tutte le caratteristiche specifiche e determinare la loro frequenza in un database?
Prima di tutto si deve calcolare il numero di tabelle, procedure, viste, ecc., com'è
dimostrato in una tabella qui sotto. Per fare l'analisi dettagliata potete usare il
prodotto di Ispirer per raccogliere la statistica onnicomprensiva.
C'è un esempio della valutazione:
Database
Tabelle
Viste
Procedure
Funzioni
Trigger
Pacchetti
Numero
350
280
420
135
50
10
Dettagli sul database
BLOBs
Outer joins
Ref cursors
Eccezioni
Tabelle Temp
37
155
89
450
34
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
4
Applicazione
Java/JDBC
Outer joins
Funzioni SQL
Result sets
Approccio per migrazione
590 files
190
356
47
Conversione automatizzata
Si può fare il piano della migrazione basato sui risultati della valutazione. Se avete solo
alcune decine di procedure, potete considerare la conversione manuale, ma se avete le
procedure da migrare a centinaia e migliaia, la soluzione migliore per la migrazione sarà
trovare un tool per una migrazione automatizzata. SQLWays è uno dei tool di questo tipo.
Costi e rischi
I costi e rischi della conversione dipendono dalle dimensioni del progetto di migrazione.
Giova notare che i costi e rischi della conversione sono determinati anche dalla diversità e
frequenza delle caratteristiche di Oracle usate in un database o in un'applicazione. Più
spesso vengono usate le caratteristiche di Oracle più complicata e costosa sarà la
conversione. Allo stesso tempo, più spesso vengono usate le caratteristiche di Oracle, più
efficace e utente sarà l'uso di tool automatizzati.
Il costo di migrazione di dati e DDL
Migrazione di dati e di oggetti di DDL (Schema) è realizzata di solito facilmente senza
tanta fatica perchè ci sono molti tool che possono aiutare a effettuare questo tipo di
migrazione.
La migrazione tipica si dati e di DDL include la conversione di:
•
•
•
•
Tipi di dato
Restrizioni (chiavi primarie e esterne, restrizioni unique, NULL, default ecc)
Trasferimento di dati
Indici
Nonostante che si sono differenze tra istruzioni DDL in Oracle e in MySQL, in entrambi
database ci sono i tipi di dato simili (character, number, date, time, LOBs) e c'è la
possibilità di specificare le restrizioni di integrità simili.
La valutazione esemplare della migrazione di DDL/Dati:
Database
Tabelle
LOBs
Max righe di tabelle
Max dimensione di tabella
<100 tabelle
10 colonne
<10M
<300 Mb
Processo di migrazione
Valutazione
Configurazione di MySQL
Trasferimento automatizzato
2-8 ore
4-16 ore
2-4 ore
Testing, cambio di configurazione, 4-12 ore
iterazione ulteriore
Tempo totale
12-40 ore
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
5
I tool
Gratuiti, o meno di 500 euro
Grazie all'automazione il costo di migrazione di DDL e di dati non è direttamente
proporzionale al numero di tabelle e alla quantità di dati. Per esempio, il costo di
migrazione di 100 e 300 tabelle può essere uguale se le tabelle hanno una struttura simile
e la quantità di dati simile.
Quando il numero di tabelle e le loro dimensioni si aumentano, si può bisognare spendere
più tempo per configurare bene un database MySQL, regolare il trasferimento di dati e
focalizzarsi sulle cose come, per esempio, il performance della creazione di indici.
I rischi di migrazione per la migrazione tipica di DDL e dati
La migrazione tipica di DDL/Dati non è di alto rischio. Usando SQLWays, è possibile
effettuare il trasferimento completo di un database in un modo di valutazione, riguardare i
dati e avviare applicazioni conesse a un database MySQL nuova:
Questo è il solito processo lavorativo:
1. Effettuare il trasferimento completo di un database in un modo di valutazione
2. Controllare se ci sono degli sbagli durante il trasferimento, comparare strutture di
tabelle, il numero di righe in Oracle e MySQL
3. Riguardare e esaminare i dati in tutte le tabelle rappresentative usando i tool SQL come
Oracle, SQL*Plus, MySQL Query Browser o l'utilità della riga di comando.
4. Avviare e controllare applicazioni di destinazioone connesse a MySQL
Migrazioni di dati difficili
Nonostante che, in generale, la migrazione di dati/DDL è abbastanza facile in
comparazione con la conversione della logica di business, ci sono alcune condizioni che
aumentano la complessità della migrazione di dati/DDL:
•
Il grabde volume di dati
Se avete bisogno di migrare i grandi volumi di dati, forse bisognerete anche configurare i
server MySQL.
Il grande volume di dati può influenzare il processo di migrazione, soprattutto riguardo il
tempo necessario per la realizzazione di migrazione. Per ridurre il tempo necessario per
finire la migrazione, potete effettuare una migrazione nel modo sincronico. Per questo la
migrazione divente più difficile.
Allo stesso tempo, il trasferimento di dati può complicare il trattamento di errori (error
handling), perchè non potrete avviare la stessa migrazione ancora una volta se solo alcune
tabelle non saranno convertite bene.
Il progetto può portare i vanatggi grazie ai tool che hanno le opzioni dell'inserimento per i
grandi volumi di dati, perchè i tool che eseguono una commissione alla fine di ogni riga,
non saranno efficaci più.
• Il downtime minimale
In alcuni ambienti mission-critical dovete essere sicuri che il downtime è il più minimo
possibile. Per rispondere a questi requisiti, dovete disegnare il processo di migrazione a
fondo per fare molti operazioni nello stesso tempo (per esempio, il trasferimento di run data
o il trasferimento di tabelle statiche dalla finestra di downtime). A volte si deve usare i
tool per replicazione per ridurre il tempo di downtime.
•
I requisiti esigenti per il performance
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
6
Alcuni ambienti hanno i requisiti molto esigenti per il performance di applicazioni. Pur
migrando verso MySQL, è obbligatorio che il performance esistente sarà conservato o
migliorato. Per questo si deve spendere più tempo per il design e aggiustamento di un
database e anche fare i test di controllo della migrazione per controllare il performance di
un'applicazione dopo la migrazione.
Migrazione rischiosa durante la migrazione di DDL e di dati
Ci sono migrazioni di dati molto complesse che non si può effettuare facendo solo un
doppio click. La migrazione ai margini di Proof-of-Concept (prova del concetto) è
necessaria per garantire la fattibilità sellla migrazione.
Di solito i processi seguenti sono consigliati per i progetti complessi di migrazone di
dati:
•
•
•
Migrazione durante la prova del concetto (Proof-of-Concept) per provare la fattibilità dei
requisiti
Test di migrazione per imitare completamente la migrazione finale e fare delle prove
onnicomprensive
Migrazione finale
Il costo della migrazione della logica di business
Se il vostro database contiene decine di procedure e trigger, è più facile convertirli a mano
verso la sintassi MySQL. Ma se avete procedure e trigger a migliaia, la migrazione
manuale sarà abbastanza costosa. Perciò è meglio considerare l'assistenza del tool
automatizzato.
Il costo della conversione manuale è direttamente proporzionale al numero di linee del
codice da convertire. Dall'altra parte, i tool automatizzati possono ridurre il costo, in
questo modo la migrazione di migliaia di linee del codice sarà effettuata a un prezzo
ragionevole senza tanta fatica.
Secondo il numero di linee del codice da convertire, la conversione automatizzata della
logica di business usando un tool automatizzato tipo il tool SQLWays sarà 7-10 meno
cara in comparazione con la migrazione manuale.
La diversità e frequenza di caratteristiche specifiche di Oracle definiscono la complessità
di migrazione della logica di business e il livello d'automazione che può essere raggiunto
grazie ai tool.
Per raggiungere l'automazione efficiente, i nostri esperti garantiscono che con il tool
SQLWays l'automazione di migrazione della logica di business può essere superiore al
95%.
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
7
C'è un esempio della valutazione del progetto di migrazione della logica di business:
Database
Stored procedure
Trigger
Funzioni
Pacchetti
Conversione manuale
Il costo di lavoro
Conversione automatizzata
1000
300
250
10 (50 procedure per pacchetto
5,000 ore (~30 persone per mese)
$50,000-$250,000 (dipende
dal paese)
Valutazione, esame di
soluzioni
Conversione
iterativa , analisi
Testing
16-40 ore
Tempo totale
Il costo di tool
96-200 ore
meno di $5,000-$10,000
40-80 ore
40-80 ore
Comparando la migrazione di DDL/Dati e la migrazione della logica di business, potete
vedere che la seconda migrazione può costiture il 95% del costo totale del progetto,
soprattutto se parliamo di grandi progetti di migrazione da Oracle a MySQL.
I rischi di migrazione della logica di business
Se ci sono molte linee di codice da convertire e se ci sono le caratteristiche diverse di un
database Oracle, la conversione può essere abbastanza rischiosa. In questo caso dovrete
fare alcuni passi importanti durante la migrazione della logica di business.
•
Esperienza
Il team responsabile del progetto di migrazione deve avere le competenze
amministrative e quelle di sviluppatori, e anche l'esperienza in un campo di trattamento
di database - sia in Oracle che in MySQL. I specialisti devono capire bene dimensioni,
sfide, incarichi e fasi del progetto di migrazione per realizzarlo con successo.
• Valutazione onnicomprensiva
All'inizio, dovete fare la valutazione onnicomprensiva di database da migrare. Alla fine,
saprete che funzionalità specifica da convertire c'è, che soluzioni dovete usare per supplire
le caratteristiche di Oracle con non sono compatibili con ANSI.
Dovete determinare se c'è una soluzione per ogni caratteristica usata. Non è facile trovare
gli equivalenti per alcune caratteristiche di Oracle, perciò dovrete ridisegnare alcune
funzionalità a volte.
•
Prova del concetto (Proof-of-Concept) per tutto il codice
I tool automatizzati come SQLWays permettono di realizzare la conversione di tutto il codice
all'inizio della valutazione di migrazione. Consigliamo a voi a farlo come una parte della
migrazione complessa perchè così avrete la possibilità di trovare i posti problematici per
conversione e venire a sapere "il percentuale di automazione" oppure il fattore del successo
che vi da il tool.
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
8
La cosa più importante è che sarete sicuri che la conversione del codice complicato PL/SQL
è possibile a un prezzo ragionevole.
•
Uso della migrazione automatizzata il più possibile
In aggiunta al costo alto, la migrazione manuale non lascia vedere i problemi di
conversione all'inizio, perciò dopo è probabile che dovrete correggere e rifare la
migrazione. Tutto questo aumenta i sforzi necessari per la migrazione e anche i costi
della migrazione.
In comparazione con la migrazione a mano, i tool automatizzati permettono di realizzare
la conversione alcune volte senza pagare tanto per questo, nello stesso tempo le
conversione iterative danno la possibilità di avere il feedback molto utile. Allora, con i tool
automatizzati potete risparmiare e avere la migrazione più efficace.
In generale, conversione a mano da troppo fastidio e c'è sempre anche la probabilità di un
errore umano. Molto spesso gli sviluppatori possono produrre i risultati diversi per la
conversione dello stesso codice. Ne risulta che ci sono i costi addizionali e il tempo
perso.
• Testing all'inizio
I test all'inizio vengono effettuati per minimizzare i rischi del progetto di migrazione. Potete
avviare i test d'unità o realizzare il controllo del codice perfino se il testing funzionale al
livello di un'applicazione non è ancora disponibile.
Potete usare le caratteristiche di tool automatizzati che possono generare i casi di test per
invocare procedure e funzioni con i valori specifici e comparare i risultati. Per favore, notate
che tutto questo non può sostituire il testing funzionale al livello di un'applicazione, però
può aiutare a rivelare i problemi potenziali.
Conversione di applicazioni
Oltre la logica di business lato server nella maggior parte dei casi dovete anche
modificare le vostre applicazioni per lavorare con MySQL.
In applicazioni Java e PowerBuilder a volte ci sono istruzioni SQL che non sono
compatibili con ANSI - significa che la sintassi non è uguale alla sintassi SQL di MySQL e
deve essere modificata.
Le caratteristiche della sintassi più tipiche che sono importanti per le conversioni da Oracle
a MySQL sono gli script con la sintassi di Oracle left outer join (+). Funzioni come
DECODE, NVL, e SYSDATE sono anche molto importanti.
Non potete solo sostituire i nomi di funzioni usando Find/Replace in tali situazioni. In tali
casi a volte le funzioni hanno la sintassi diversa di parametri oppure richiedono i
cambiamenti di istruzioni SQL, per esempio di left outer join.
Per di più, la sostituzione di una stringa sola può cambiare il testo in posti inaspettati,
come per esempio, nelle stringhe di carattere o istruzioni nel linguaggio di Java.
L'approccio migliore è usare un tool come SQLWays che è capace di modificare il
codice dell'applicazione automaticamente e convertire istruzioni SQL verso la
sintassi corrispondente di MySQL.
I tali tool possono identificare istruzioni SQL nel codice in modo corretto, effettuare la
conversione e generare i report su ogni cambiamento semplificando in questo modo
l'incarico della conversione di un'applicazione.
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
9
Pianificazione – Fasi di migrazione
La pianificazione profonda è molto importante per la migrazione fortunata. Le fasi tipiche
di una migrazione sono:
•
Valutazione
Valutazione (descritta prima in questo documento) è adibita ad analizzare un database
o un'applicazione da migrare, definire le dimensioni di una migrazione e fissare ogni
funzionalità specifica di Oracle che deve essere aggiustata a MySQL.
Secondo l'informazione raccolta durante la valutazione, potete definire gli approcci da
usare (conversione manuale o automatizzata), il costo e i rischi della migrazione.
•
&RQYHUVLRQHFRPSOHWDDOO
LQL]LR–Proof-of-Concept3URYDGHOFRQFHWWR
Poniamo che abbiate un database con 2,000 procedure. Potete avviare SQLWays per
convertire l'intero codice durante la fase della prova del concetto (Proof-of-Concept). Vi
consigliamo di farlo anche se avete deciso di controllare e convertire ogni modulo a parte.
All'inizio del processo di migrazione (se i tool automatizzati vengono usati), il feedback e la
visibilità sono disponibili, al contrario della migrazione a mano quando si deve spendere
molte ore per gli incarichi di migrazione prima di avviare il processo di migrazione. A volte
durante la migrazione manuale appaiono gli sbagli e in questo caso si deve correggere tutti
gli sbagli e ricominciare la migrazione da capo.
Allora potete usare un approccio integrato e uniforme usando le soluzioni automatizzate
come, per esempio, la migrazione con l'aiuto di SQLWays. Molto spesso, riguardo al fatto
che molte persone dall'organizzazione sono impegnati nello stesso progetto di
migrazione, a volte sono usati gli approcci e metodologie divesri per la conversione della
stessa sintassi. Però alla fine più uniformi e integrati sono i risultati della
conversione, più facile sarà controllare e modificare la conversione. Nella situazione ideale
dovete raggiungere la creazione di oggetti in SQL senza nessun sbaglio all'inizio del
processo di migrazione. Significa che tutte le tabelle, funzioni, procedure, tutti i trigger
sono stati creati con successo.
Riguardo al fatto che è abbastanza difficile raggiungere il 100% auomazione della
convesrione di qualsiasi database con una versione del tool attuale, il team di Ispirer offre la
customizzazione gratuita (1-2 giorni per l'aggiustamento) per avere l'automazione di circa
100% durante la fase iniziale della valutazione.
•
Il testing run-time, il testing del performance e della logica
Migrazione viene spesso effettuata per ogni modulo a parte. Dopo che avete
convertito la logica di business lato server, perfino prima che applicazioni vengono
convertite e il testing al livello di un'applicazione è disponibile, si deve già controllare
la conversione di un database.
Potete scegliere alcune procedure più rappresentative e difficili e fare la rivista del codice.
Ovviamente forse non troverete tutti i problemi della conversione durante la rivista del
codice, tuttavia sarà molto utile. Durante la rivista potete vedere che soluzioni sono usate
ed estimare la qualità della conversione in generale.
Sarebbe bene creare una lista di caratteristiche della conversione per esaminarle meglio.
Anche se potete creare una procedure o funzione nel database, questo non significa che non
ci sono degli errori. Si può rivelare molti errori avviando le procedure. Il modo più facile e
efficace a testare le procedure è generare i casi di test.
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
1
0
SQLWays può generare il set di chiamate alle procedure con i parametri di input diversi.
Esaminando il codice SQLWays può definire che valori, stringhe, costanti di dati, condizioni
della struttura di controllo sono usati, e generare i casi di test raggionevoli in molte
situazioni.
Per fare il testing onnicomprensivo della logica e del performance potete creare i script di
test con i dati reali ed implementare i vari scenari.
Se usate il software assicurativo automatizzato di prima qualità per il vostro database di
Oracle e applicazioni, potete considerare il loro ammodernamento per usarlo insieme con
MySQL e garantire il testing onnicomprensivo della migrazione.
Soluzioni tipiche per convesrione - Esemplari
Anche se gli incarichi e le soluzioni per convesrioni si variano secondo il progetto di
migrazione, molti progetti sono tipiche per ogni migrazione.
Attenzione. Tutte le conversioni descritte qui sotto vengono effettuate automaticamente con la
versione di SQLWays attuale.
DDL
Sia Oracle che MySQL supportano l'istruzione CREATE TABLE, ma ci sono molte differenze
nella sintassi.
•
Tipi di dato
Oracle
CREATE TABLE employees
(
id NUMBER(5),
name VARCHAR2(120),
hire_date DATE,
salary NUMBER(7),
dept_id NUMBER(2)
);
•
MySQL
CREATE TABLE employees
(
id INT,
name VARCHAR(120),
hire_date DATETIME,
salary INT,
dept_id TINYINT
);
Parole riservate
Oracle e MySQL usano i set delle parole riservate diversi, per questo alcuni nomi di
colonne ora devono essere virgolettate nelle query MySQL.
Oracle
MySQL
SELECT product_id, limit
FROM product_data;
SELECT product_id, `limit`
FROM product_data;
Le query e il codice PL/SQL
Avete bisogno di modificare istruzioni SQL principalmente per cambiare la sintassi di
funzioni ed espressioni. PL/SQL deve essere completamente convertito verso la sintassi
SQL procedurale di MySQL.
• Outer Joins
Oracle supporta la sintassi specifica di outer joins che sono spesso usati in applicazioni vecchie.
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
1
1
Oracle
MySQL
SELECT e.name, d.name
FROM employees e, departments d
WHERE e.dept_id = d.id(+);
SELECT e.name, d.name
FROM employees e LEFT OUTER JOIN
departments d ON e.dept_id = d.id;
•
Conferimento di un valore di identità ad una colonna
Oracle non supporta le colonne auto-increment (di identità), e un oggetto di sequenza
viene usata per conferire valori di identità nuovi da un'applicazione o da un trigger.
Nonostante che un singolo oggetto di sequenza può essere usato per conferire valori per le
tabelle multiple in Oracle, in molti casi è usato solo per una tabella e questa funzionalità può
essere convertita verso una colonna auto-increment in MySQL.
In riguardo alla convesrione automatizzata, SQLWays osserva le query SQL e istruzioni
INSERT in applicazioni, procedure e trigger per identificare il conferimento dell'identità e
convertirli verso le colonne auto-increment in MySQL.
Oracle
MySQL
CREATE TABLE employees
(
id NUMBER(5) PRIMARY KEY,
name VARCHAR2(120),
hire_date DATE,
dept_id NUMBER(2)
);
CREATE TABLE employees
(
id INT AUTO_INCREMENT PRIMARY
KEY,
name VARCHAR(120),
hire_date DATETIME,
dept_id TINYINT
);
CREATE TRIGGER emp_id BEFORE
INSERT ON employees
FOR EACH ROW
BEGIN
SELECT emp_id_seq.nextval
INTO :new.id FROM dual;
END;
•
-- Trigger is no required anymore
I trigger multipli per un evento
In Oracle, per la stessa tabella si può definire alcuni trigger per lo stesso evento (per
esempio, alcuni trigger per l'evento INSERT per la tabella di dipendenti (employees
table).
Non è possibile in MySQL, perchè si deve porre tutto il codice per uno evento nello
stesso trigger.
•
Pacchetti e variabili Shared
In Oracle, un pacchetto è un gruppo di procedure correlate e funzioni che possono
condividere i variabili. Procedure e funzioni di un pacchetto devono essere convertite
verso i singoli oggetti in MySQL.
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
1
2
Variabili di un pacchetto possono essere modificati in una procedura di un pacchetto.
Per di più, un'altra procedure di un pacchetto può vedere o sostituire il valore
ammodernato. Per sostituire questa funzionalità in MySQL potete usare i variabili della
sessione che iniziano con un segno @.
Oracle
MySQL
CREATE PACKAGE BODY emp_pack
AS
CREATE PROCEDURE new_employee
BEGIN
…
IF @processed IS NULL
THEN @processed = 0;
processed NUMBER DEFAULT 0;
PROCEDURE new_employee AS
BEGIN
…
processed := processed + 1;
END;
PROCEDURE raise_salary AS
BEGIN
…
processed := processed + 1;
END;
END;
•
@processed = @processed + 1;
END;
CREATE PROCEDURE raise_salary
BEGIN
…
IF @processed IS NULL
THEN @processed = 0;
@processed := @processed + 1;
END;
END;
Results sets che tornano
Dovete usare i variabili di cursori (REF CURSORs) come un parametro OUT per tornare
un result set da Oracle. In molti casi, può essere convertito verso SELECT in MySQL.
Oracle
MySQL
CREATE PROCEDURE get_salaries
(d_id IN NUMBER, cur OUT
SYS_REFCURSOR)
AS
BEGIN
CREATE PROCEDURE get_salaries (IN d_id
INT)
BEGIN
OPEN cur FOR
SELECT id, name, salary
FROM employees
WHERE dept_id = d_id
ORDER BY name;
SELECT id, name, salary
FROM employees
WHERE dept_id = d_id
ORDER BY name;
END;
END;
•
Definizioni di tipi di dato %TYPE e %ROWTYPE
Un attributo di Oracle %TYPE vi permette di definire i tipi di dato per i variabili PL/SQL
basati su tipi di colonne di tabelle. In MySQL, dovete specificare il tipo di dato in dettaglio.
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
1
3
Nello stesso modo, un attributo %ROWTYPE vi permette di creare i variabili record basati su
righe di tabelle. In MySQL, dovete creare i singoli variabili e specificare i loro tipi di dato in
dettaglio.
Oracle
MySQL
v_emp_name employees.name%TYPE;
v_emp_name VARCHAR(120)
v_emp_rec employees%ROWTYPE;
v_
v_
v_
v_
v_
•
emp_id INT
emp_name VARCHAR(120)
emp_hire_date DATETIME
emp_salary INT
emp_dept_id TINYINT
Conversione SQL in applicazioni Java
In applicazioni Java probabilmente dovete cambiare la sintassi di istruzioni SQL.
Oracle
…
PreparedStatement ps = null;
ResultSet rs = null;
String sql = “SELECT e.name, d.name” +
“FROM employees e, departments d” +
“WHERE e.dept_id = d.id(+)”;
MySQL
…
PreparedStatement ps = null;
ResultSet rs = null;
String sql = “SELECT e.name, d.name” +
“FROM employees e LEFT OUTER JOIN” +
“departments d ON e.dept_id = d.id”;
ps = conn.prepareStatement(sql);
rs = ps.executeQuery();
…
ps = conn.prepareStatement(sql);
rs = ps.executeQuery();
…
•
Conversione SQL in applicazioni PowerBuilder
In applicazioni PowerBuilder probabilmente dovete cambiare la sintassi di istruzioni SQL.
Oracle
datawindow(units=0 processing=0
print.orientation = 0
…
print.preview.buttons=no)
table(column=(type=char(120)
updatewhereclause=yes name=e_name
dbname="employees.name" )
column=(type=char(120)
updatewhereclause=yes name=d_name
dbname="departments.name" )
retrieve="SELECT e.name, d.name
FROM employees e, departments d
WHERE e.dept_id = d.id(+)”)
MySQL
datawindow(units=0 processing=0
print.orientation = 0
…
print.preview.buttons=no)
table(column=(type=char(120)
updatewhereclause=yes name=e_name
dbname="employees.name" )
column=(type=char(120)
updatewhereclause=yes name=d_name
dbname="departments.name" )
retrieve=" SELECT e.name, d.name
FROM employees e LEFT OUTER JOIN
departments d ON e.dept_id = d.id”)
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
1
4
Modi di aggiramento per funzionalità non supportata
Ci sono molte caratteristiche in Oracle PL/SQL che in questo momento non sono supportate
dal linguaggio procedurale SQL di MySQL. Se questa funzionalità viene usata in un
database di partenza, dovete applicare i vari modi di aggiramento per ricevere lo stesso
comportamento in MySQL. Ci sono degli esempi specifici:
•
Collezioni PL/SQL
Potete usare tabelle temporanee e operazioni SQL DML (SELECT, INSERT, UPDATE, DELETE)
per sostituire questa caratteristica in MySQL.
•
RAISE_APPLICATION_ERROR
Potete usare un UDF per sollevare lo sbaglio dalle stored procedure di MySQL.
•
Pacchetto incorporato UTL_FILE
Potete usare un UDF per lavorare con i file dalle stored procedure di MySQL.
•
La logica di business complessa
Come una soluzione comune, la logica di business complessa PL/SQL può essere convertita al
linguaggio Java.
Conclusione
La migrazione automatizzata verso il modello di MySQL concesso in licenza ha il valore
grandissimo. L'uso di SQLWays da Ispirer durante i proggetti difficili di migrazione da Oracle
a MySQL aumenta la qualità e riduce il tempo e i costi necessari per migrazione. Ci sono
molte cose importanti per la pianificazione della migrazione della logica di business e dei
contenuti di un database per l'applicazione esistente. Pianificazione profonda, analisi e
attenzione ai dettagli sono necessari per ogni fase del progetto di migrazione
Nonostante che la migrazione complessa di database da Oracle a MySQL, che include la
conversione complicata della logica di business, è un incarico difficile, il buon approccio e
l'uso dei tool per migrazione aiutano ad effettuare la migrazione a buon prezzo e senza
tanti rischi. Il prodotto di Ispirer SQLWays e i servizi di Ispirer garantiscono il gran valore
della migrazione durante la conversione complessa della logica di business.
Copyright © 1999-2013. Ispirer Systems Ltd. Tutti i diritti riservati.
1
5