Migrazione da Oracle a MySQL

Transcript

1 Migrazione da a Stored Procedure, Pacchetti, Trigger, Script e Applicazioni White Paper Marzo 2009, Ispirer Systems Ltd. Copyright Ispirer Systems Ltd. Tutti i diritti riservati. 1

2 Introduzione L'obiettivo di questo libro bianco è descrivere i fattori che influiscono la migrazione di database e applicazioni da a. 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 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 è i rischi e la complessità di migrazione della logica di business da, soprattutto se le applicazioni esistenti usano spesso le procedure PL/SQL, trigger, pacchetti e istruzioni SQL specifiche di. La migrazione da a 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 la migrazione automatizzata diventa una soluzione alternativa veramente attrattiva. Sfide Il database 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. PL/SQL è un'estensione SQL procedurale potente facilmente gestita che viene consigliata da 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 ha la funzionalità molto simile con quella di, non usa PL/SQL. Oltre la sintassi specifica di, PL/SQL offre molte caratteristiche che sono non-ansi compatibili, compreso le caratteristiche che si può trovare solo in. 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 Ispirer Systems Ltd. Tutti i diritti riservati. 2

3 La migrazione da a può essere molto difficile, soprattutto se le caratteristiche specifiche di 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 a. 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, 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 Ispirer Systems Ltd. Tutti i diritti riservati. 3

4 SQL dinamico Pacchetti incorporati Funzioni OLAP Funzioni XML, ecc. Dopo che finirete l'esame, è meglio scegliere gli equivalenti in o le soluzioni in per sostituire le funzionalità specifiche di. 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. Si deve anche notare quanti file sorgenti dell'applicazione contengono il codice specifico di, quindi, questo codice deve essere modificato per lavorare con. La maggior parte di aplicazioni usano l'api standardizzata come ODBC, JDBC, o ADO.NET per accedere a, ma alcune applicazioni usano l'api nativa come, per esempio, 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, OCI, dovrete ridisegnare completamente il codice dell'accesso al database per utilizzare 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 Numero Tabelle 350 Viste 280 Procedure 420 Funzioni 135 Trigger 50 Pacchetti 10 Dettagli sul database BLOBs 37 Outer joins 155 Ref cursors 89 Eccezioni 450 Tabelle Temp 34 Copyright Ispirer Systems Ltd. Tutti i diritti riservati. 4

5 Applicazione Java/JDBC 590 files Outer joins 190 Funzioni SQL 356 Result sets 47 Approccio per migrazione 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 usate in un database o in un'applicazione. Più spesso vengono usate le caratteristiche di più complicata e costosa sarà la conversione. Allo stesso tempo, più spesso vengono usate le caratteristiche di, 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 e in, 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 <100 tabelle 10 colonne LOBs Max righe di tabelle <10M Max dimensione di tabella <300 Mb Processo di migrazione Valutazione Configurazione di Trasferimento automatizzato Testing, cambio di configurazione, iterazione ulteriore 2-8 ore 4-16 ore 2-4 ore 4-12 ore Tempo totale ore Copyright Ispirer Systems Ltd. Tutti i diritti riservati. 5

6 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, 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 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 e 3. Riguardare e esaminare i dati in tutte le tabelle rappresentative usando i tool SQL come, SQL*Plus, Query Browser o l'utilità della riga di comando. 4. Avviare e controllare applicazioni di destinazioone connesse a 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. 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 Ispirer Systems Ltd. Tutti i diritti riservati. 6

7 Alcuni ambienti hanno i requisiti molto esigenti per il performance di applicazioni. Pur migrando verso, è 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. 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 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 Ispirer Systems Ltd. Tutti i diritti riservati. 7

8 C'è un esempio della valutazione del progetto di migrazione della logica di business: Database Stored procedure 1000 Trigger 300 Funzioni 250 Pacchetti 10 (50 procedure per pacchetto Conversione manuale Il costo di lavoro Conversione automatizzata Valutazione, esame di soluzioni Conversione iterativa, analisi Testing 5,000 ore (~30 persone per mese) $50,000-$250,000 (dipende dal paese) ore ore ore Tempo totale ore Il costo di tool meno di $5,000-$10,000 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 a. 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, 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 che in. 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 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, 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 Ispirer Systems Ltd. Tutti i diritti riservati. 8

9 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. 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 e deve essere modificata. Le caratteristiche della sintassi più tipiche che sono importanti per le conversioni da a sono gli script con la sintassi di 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. 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 Ispirer Systems Ltd. Tutti i diritti riservati. 9

10 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 che deve essere aggiustata a. Secondo l'informazione raccolta durante la valutazione, potete definire gli approcci da usare (conversione manuale o automatizzata), il costo e i rischi della migrazione. Proof-of-Concept 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 Ispirer Systems Ltd. Tutti i diritti riservati. 1 0

11 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 e applicazioni, potete considerare il loro ammodernamento per usarlo insieme con 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 che supportano l'istruzione CREATE TABLE, ma ci sono molte differenze nella sintassi. Tipi di dato CREATE TABLE employees ( id NUMBER(5), name VARCHAR2(120), hire_date DATE, salary NUMBER(7), dept_id NUMBER(2) ); CREATE TABLE employees ( id INT, name VARCHAR(120), hire_date DATETIME, salary INT, dept_id TINYINT ); Parole riservate e usano i set delle parole riservate diversi, per questo alcuni nomi di colonne ora devono essere virgolettate nelle query. 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. Outer Joins supporta la sintassi specifica di outer joins che sono spesso usati in applicazioni vecchie. Copyright Ispirer Systems Ltd. Tutti i diritti riservati. 1 1

12 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 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, in molti casi è usato solo per una tabella e questa funzionalità può essere convertita verso una colonna auto-increment in. 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. CREATE TABLE employees ( id NUMBER(5) PRIMARY KEY, name VARCHAR2(120), hire_date DATE, dept_id NUMBER(2) ); CREATE TRIGGER emp_id BEFORE INSERT ON employees FOR EACH ROW BEGIN SELECT emp_id_seq.nextval INTO :new.id FROM dual; CREATE TABLE employees ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(120), hire_date DATETIME, dept_id TINYINT ); -- Trigger is no required anymore I trigger multipli per un evento In, 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, perchè si deve porre tutto il codice per uno evento nello stesso trigger. Pacchetti e variabili Shared In, 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. Copyright Ispirer Systems Ltd. Tutti i diritti riservati. 1 2

13 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 potete usare i variabili della sessione che iniziano con un CREATE PACKAGE BODY emp_pack AS processed NUMBER DEFAULT 0; PROCEDURE new_employee AS BEGIN processed := processed + 1; PROCEDURE raise_salary AS BEGIN processed := processed + 1; CREATE PROCEDURE new_employee BEGIN IS NULL = + 1; CREATE PROCEDURE raise_salary BEGIN IS NULL = + 1; Results sets che tornano Dovete usare i variabili di cursori (REF CURSORs) come un parametro OUT per tornare un result set da. In molti casi, può essere convertito verso SELECT in. CREATE PROCEDURE get_salaries (d_id IN NUMBER, cur OUT SYS_REFCURSOR) AS BEGIN OPEN cur FOR SELECT id, name, salary FROM employees WHERE dept_id = d_id ORDER BY name; CREATE PROCEDURE get_salaries (IN d_id INT) BEGIN SELECT id, name, salary FROM employees WHERE dept_id = d_id ORDER BY name; Definizioni di tipi di dato %TYPE e %ROWTYPE Un attributo di %TYPE vi permette di definire i tipi di dato per i variabili PL/SQL basati su tipi di colonne di tabelle. In, dovete specificare il tipo di dato in dettaglio. Copyright Ispirer Systems Ltd. Tutti i diritti riservati. 1 3

14 Nello stesso modo, un attributo %ROWTYPE vi permette di creare i variabili record basati su righe di tabelle. In, dovete creare i singoli variabili e specificare i loro tipi di dato in dettaglio. v_emp_name employees.name%type; v_emp_rec employees%rowtype; v_emp_name VARCHAR(120) v_ emp_id INT v_ emp_name VARCHAR(120) v_ emp_hire_date DATETIME v_ emp_salary INT v_ emp_dept_id TINYINT Conversione SQL in applicazioni Java In applicazioni Java probabilmente dovete cambiare la sintassi di istruzioni SQL. PreparedStatement ps = null; ResultSet rs = null; String sql = SELECT e.name, d.name + FROM employees e, departments d + WHERE e.dept_id = d.id(+) ; ps = conn.preparestatement(sql); rs = ps.executequery(); 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(); Conversione SQL in applicazioni PowerBuilder In applicazioni PowerBuilder probabilmente dovete cambiare la sintassi di istruzioni SQL. 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(+) ) 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 Ispirer Systems Ltd. Tutti i diritti riservati. 1 4

15 Modi di aggiramento per funzionalità non supportata Ci sono molte caratteristiche in PL/SQL che in questo momento non sono supportate dal linguaggio procedurale SQL di. Se questa funzionalità viene usata in un database di partenza, dovete applicare i vari modi di aggiramento per ricevere lo stesso comportamento in. 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. RAISE_APPLICATION_ERROR Potete usare un UDF per sollevare lo sbaglio dalle stored procedure di. Pacchetto incorporato UTL_FILE Potete usare un UDF per lavorare con i file dalle stored procedure di. 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 concesso in licenza ha il valore grandissimo. L'uso di SQLWays da Ispirer durante i proggetti difficili di migrazione da a 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 a, 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 Ispirer Systems Ltd. Tutti i diritti riservati. 1 5