Universit'a degli studi di Padova Da Oracle a PostgreSQL, analisi di una migrazione Tesi di Laurea - Facolt'a di Scienze MM.FF.NN - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli studi di Padova
Facoltà di Scienze MM.FF.NN.
Corso di Laurea in Informatica
Da Oracle a PostgreSQL,
analisi di una migrazione
Tesi di Laurea
Relatore: Laureando:
Prof. Alessandro Sperduti Andrea Agosti
Mat. 543079INDICE INDICE
Indice
1 Introduzione 4
1.1 ARPAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 SIRAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Il progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Scelta del candidato DBMS . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Analisi preliminare e risultato dello stage . . . . . . . . . . . . . 6
2 Tecnologie 7
2.1 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Oracle 10g RAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Storia del progetto . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Aderenza allo standard SQL . . . . . . . . . . . . . . . . . . . . 9
2.2.4 Accesso concorrente ai dati . . . . . . . . . . . . . . . . . . . . . 9
2.2.5 Stored procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.6 Partizionamento delle tabelle . . . . . . . . . . . . . . . . . . . 10
2.2.7 Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.8 Affidabilità e continuità di servizio . . . . . . . . . . . . . . . . 11
2.2.9 Evoluzioni future . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 LabWare LIMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Sviluppo 13
3.1 Approccio al problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Ambiente di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Installazione di PostgreSQL . . . . . . . . . . . . . . . . . . . . 14
3.2.2 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Amministrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Collegamento con altri database . . . . . . . . . . . . . . . . . . . . . . 16
3.4.1 dbi link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Ora2Pg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.1 Utilizzo del modulo . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.2 Conversione del codice . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.3 Definizione delle view . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.4 Materialized view . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5.5 Impressioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6 Creazione del database . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.7 Applicativi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7.1 Driver ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7.2 Applicativo LabWare LIMS . . . . . . . . . . . . . . . . . . . . 23
3.7.3 Crystal Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1 Pag: 1 di 67INDICE INDICE
4 Test e risultati 25
4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1 Oracle XE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Metodologia di test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1 Test su tabella singola . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.2 Test su JOIN multiplo . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.3 Test su connessioni multiple . . . . . . . . . . . . . . . . . . . . 30
4.2.4 Test su sessione di lavoro . . . . . . . . . . . . . . . . . . . . . . 30
4.2.5 Test sulla scalabilità . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Risultati dei test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5 Analisi tecnica 36
5.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Analisi dei risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6 Conclusioni 38
6.1 Fattibilità del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2 Vantaggi tecnici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3 Vantaggi economici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4 Vantaggi commerciali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.5 Vantaggi etici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.6 Consuntivo di progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.7 Prodotti dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.8 Conclusioni personali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A Piano di Lavoro 43
A.1 Preventivo ore per attività . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2 Consuntivo attività effettuate . . . . . . . . . . . . . . . . . . . . . . . 43
B Codice sorgente 45
B.1 export full.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.2 export data.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.3 limsDebugSqlParser.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.4 benchmark sql.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
B.5 benchmark thread.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
C Glossario 63
D Ringraziamenti 64
2 Pag: 2 di 67INDICE INDICE
Sommario
Con l’avvento di internet ed il continuo sviluppo delle reti di comunicazione,
l’importanza di avere accesso ad una informazione è fondamentale ed indispen-
sabile per ogni azienda o individuo. In pochi anni siamo passati da uno scenario
in cui poche fonti di informazioni monopolizzavano l’accesso ad uno dove ogni
singola persona può essere portatore di conoscenza per milioni di altri individui.
Avere accesso a questo flusso continuo di dati diventa strategico per tutte quelle
realtà in cui le decisioni dipendono dalla conoscenza acquisita e sono critiche
per il successo della propria attività. Mantenere una informazione aggiornata,
organizzata e fruibile è quindi indispensabile e per questo deve essere affidata
a strumenti che assicurino una elevata affidabilità e continuità di servizio. In
questo campo hanno avuto grande successo le Basi di Dati Relazionali [C] grazie
allo sviluppo di soluzioni software che permettono di gestire collezioni di dati
con relativa facilità. Tuttavia, con l’aumentare del numero di informazioni da
gestire, diventa sempre più difficile e oneroso riuscire ad assicurare di ottenere
l’informazione desiderata in tempi ragionevoli. Per questo, la più remunerativa
fetta del mercato dei DBMS [C] è sicuramente quella enterprise,che raccoglie le
più grandi aziende mondali. E di questo mercato, la soluzione leader è Oracle
Database che ha saputo conquistare il suo primato con prodotti innovativi ed è in
grado di assicurare prestazioni elevate, alta affidabilità e una ottima scalabilità.
Il rovescio della medaglia si trova nel costo estremamente elevato con cui Oracle
licenzia l’utilizzo dei propri prodotti, forte della sua posizione dominante e della
difficoltà di trovare un reale competitor in grado di combattere ad armi pari.
L’obiettivo principale di questo progetto è scoprire se il mondo open source[C]
ha una soluzione che si pone in competizione con Oracle senza essere soggetti
alle pesanti restrizioni d’uso e liberandosi dai cospiqui costi delle licenze.
3 Pag: 3 di 671 INTRODUZIONE
1 Introduzione
1.1 ARPAV
L’ARPAV, Agenzia Regionale per la Prevenzione e Protezione Ambientale del Veneto,
è un’agenzia regionale nata nel 1996 con la Legge Regionale n◦ 32 del 18 ottobre[1] e di-
venuta operativa il 3 ottobre 1997. La necessità segue l’esito del referendum dell’aprile
1993[2] e la sua attuazione attraverso la Legge 61 del 1994[3] emanata dal Parlamento
Italiano. Gli obiettivi di principali che persegue sono due:
• la protezione ambientale e della popolazione attraverso controlli del territorio;
• la prevenzione, attraverso la formazione, la ricerca, l’informazione e l’educazione.
L’ARPAV è dotata di autonomia amministrativa, organizzativa, tecnica e contabile,
ed è quindi in grado di riunire figure professionali provenienti da realtà diversificate
per ottenere un approccio multidisciplinare ai compiti dell’agenzia stessa. Per una
migliore copertura del territorio e degli incarichi, sono presenti inoltre due dipartimenti
regionali e sette provinciali con autonomia gestionale, coordinati da una direzione
centrale. Le attività principali portate avanti e i servizi offerti sono:
• Controlli ambientali su acque, suolo, aria, rifiuti, alimenti, agenti fisici e moni-
toraggio dello stato ambientale;
• Servizio metereologico, con controllo del rischio valanghe invernale;
• Analisi dell’impatto ambientale delle attività umane e intervento in caso di
incidenti industriali;
• Consulenza per la sostenibilità di nuove opere o di opere già realizzate;
• Consulenza a enti pubblici e privati sui temi ambientali.
1.1.1 SIRAV
SIRAV è l’identificativo del Sistema Informativo Ambientale della Regione Veneto,
dato in gestione all’ARPAV, il cui obiettivo è realizzare uno strumento che supporti la
gestione delle attività organizzative e tecniche a livello regionale. Quando si parla di
SIRAV si intende tutto l’apparato informatico (server, banche dati, infrastrutture di
rete, terminali di lavoro, software e strumenti applicativi) che permette alla Regione
Veneto e all’ARPAV di lavorare su una struttura omogenea e condivisa. Da una
parte infatti troviamo la necessità di coordinare, pianificare e controllare della Regione
Veneto mentre la parte tecnica è di competenza dell’ARPAV. La struttura è gerarchica
e rispecchia l’organizzazione degli enti che hanno accesso a SIRAV: questo ha la doppia
funzione di permettere di compiere le operazioni preposte a chi ha l’autorizzazione
e contemporaneamente di proteggere le informazioni da accessi non autorizzati. Il
flusso di informazioni segue infatti percorsi ben precisi, dettati da regolamenti e leggi
vista la presenza di dati sensibili. Mantenere attivo questo sistema è un’operazione
4 Pag: 4 di 671.2 Il progetto 1 INTRODUZIONE
onerosa data la grande quantità di sistemi diversi integrati insieme che si occupano di
particolari aree e in cui si sono specializzati. Bisogna inoltre garantire la possibilità
di crescita dell’infrastruttura per far fronte a nuove richieste o per offrire nuovi servizi
senza che questo pregiudichi la realtà esistente.
1.2 Il progetto
Il progetto proposto richiedeva di analizzare il mondo open source per trovare un
DBMS che possa sostituire l’attuale sistema in uso Oracle Database 10g RAC. Il fine
è di eliminare le pesanti spese per le licenze del software che l’ARPA Veneto deve
affrontare (quantificabili in centinaia di migliaia di euro all’anno) e di allinearsi alla
direttiva del Ministero delle Innovazioni e delle Tecnologie del 19 dicembre 2003[4]. È
necessario che il software individuato sia in grado di assicurare la stessa continuità di
servizio e di affrontare il carico di lavoro generato usando l’attuale infrastruttura in-
formatica disponibile (o con modesti accorgimenti e investimenti). Inoltre deve fornire
tutte le funzionalità necessarie per replicare il database in maniera completamente
trasparente rispetto ai client che la utilizzano. Se esistono questi presupposti risulta
possibile effettuare la migrazione dei dati da una piattaforma all’altra senza dover
modificare i programmi che accedono al database e il ciclo di lavoro degli operatori
che utilizzano quei dati. Un’altra richiesta è la possibilità di collegarsi e accedere ad
altre fonti di dati, in particolare Oracle, per integrarlo con la struttura informatica già
presente e non trovarsi con un servizio isolato.
1.2.1 Scelta del candidato DBMS
Fin dalla presentazione del progetto, ARPAV aveva manifestato il suo interesse per
il DBMS PostgreSQL, ritenendolo il più probabile sostituto della piattaforma Oracle.
Questa idea nasce sia dal fatto che è presente molta documentazione su migrazioni
effettuate con successo da altre aziende reperibile su internet, sia da un interessamen-
to del tutor azienda Dott. Zambotto Paolo. Per questi motivi, prima dell’effettivo
inizio di stage ho provveduto a fare una ricerca per assicurarmi che effettivamente
non ci fossero altre alternative meno conosciute ma altrettanto valide. Sicuramente,
il più conosciuto ed utilizzato DBMS open source è MySQL[5], di proprietà di Sun
Microsystem e recentemente acquistata proprio da Oracle Corporation. Seppure mol-
to famoso, MySQL non è adatto a rimpiazzare Oracle Database, in quanto il target
è sempre stato il mercato delle soluzioni a basso costo, prediligendo leggerezza e ve-
locità alla sicurezza dei dati e dotazione tecnica e tecnologica. Lo storage engine di
default, MyISAM, non supporta le transazioni, le chiavi esterne, il clustering e tante
altre funzionalità richieste da un utilizzo di classe Enterprise. Per questo molto spesso
era preferibile utilizzare InnoDB, molto più ricco di features ma vincolato dal fatto di
non essere proprietà di MySQL (i diritti sono di Innobase Oy, anch’essa acquistata nel
2005 da Oracle Corporation). Negli ultimi anni il suo sviluppo è accelerato soprattutto
per la versione Enterprise, impegno voluto da Sun Microsystem, in modo da colmare il
gap esistente con soluzioni di livello superiore. In questo modo ora riesce ad offrire ca-
ratteristiche per competere coi modermi DBMS, uscendo dalla nicchia delle soluzione
5 Pag: 5 di 671.2 Il progetto 1 INTRODUZIONE
a basso costo ma rinunciando alla versione Community che lo ha portato al successo.
Tuttavia non sembra ancora essere maturo per un utilizzo data warehousing[C], dovuto
alla scarsa ottimizzazione in ambienti distribuiti e alla soltanto recente introduzione di
features come il partizionamento e la replicazione dei dati. Un altro candidato preso
in considerazione è Firebird[6], nato dal codice di InterBase[7] liberato nel 2000 da
Borland. Questo DBMS ha molti aspetti interessanti da valutare, tra cui il basso uso
di risorse e la sua architettura, tuttavia ad oggi manca di molte caratteristiche, alcune
delle quali richieste dal progetto. Altre soluzioni non si sono rivelate adatte in quanto
progettate per problemi differenti (SQLite, Hadoop, HadoopDB) oppure perchè non
sono DBMS relazionali (CouchDB, MongoDB) e quindi il progetto è partito subito
con l’obiettivo di analizzare PostgreSQL, che verrà presentato in seguito.
1.2.2 Analisi preliminare e risultato dello stage
La scelta di questo progetto mi ha posto davanti ad alcuni problemi riguardanti so-
prattutto la mancanza di conoscenza riguardo gli strumenti da utilizzare, Oracle in
primis, e il dover presentare risultati che devono essere obiettivi e influenzeranno le
scelte di ARPAV. Oltre a questo, anche prevedere un piano di lavoro è risultato im-
pegnativo in quanto ho dovuto ragionare sulle attività da eseguire e stimare una loro
durata sulla sola base della mia esperienza. Su quest’ultimo sono riuscito a fare un
buon lavoro, in quanto il progetto è stato concluso nei tempi previsti senza cambia-
menti delle attività preventivate, mentre per la fase di apprendimento le conoscenze
acquisite in questi anni mi hanno permesso di capire facilmente il funzionamento degli
strumenti e di ottimizzare le risorse a mia disposizione. Il risultato del progetto è lo
studio quı̀ presentato ed è stato giudicato molto positivamente dal tutor aziendale in
quanto rispecchia le attese e fornisce i dati richiesti per una migliore comprensione del
problema e per una decisione sulle strategie da seguire.
6 Pag: 6 di 672 TECNOLOGIE
2 Tecnologie
2.1 Oracle
La storia di Oracle nasce nel 1977 quando Larry Ellison, insieme a Bob Miner e Ed
Oates, fonda la Software Development Laboratories e la prima release di Oracle Da-
tabase viene rilasciata nel 1979 col nome Oracle V2 (non è mai stata rilasciata una
versione 1). Nel 1982 la societá cambia nome in Relational Software, Inc. e successi-
vamente diventa Oracle Corporation per allinearsi al prodotto di punta dell’azienda.
Nel corso degli anni poi si sono succedute vari versioni del database, portando sempre
innovazioni tecnologie all’avanguardia tra cui SQL (1979)[C], symmetric multiproces-
sing (1983), distribuited database (1986), ANSI SQL standard (1993), supporto ad
architetture 64bit (1995), XML (1999)[C]. Nel corso degli anni Oracle Corporation è
riuscita a conquistare la fiducia dei suoi clienti e ad ottenere la leadership del mercato
enterprise per le soluzione database, middleware e business intelligence. Attualmente
può contare su un bacino di 320.000 clienti, tra cui tutte le prime 100 aziende del-
la Fortune Global 500 [8][9], e un fatturato di US$22.4 miliardi di dollari nel 2008.
L’ultima versione disponibile di Oracle Database è la 11g, rilasciata l’11 luglio 2007.
2.1.1 Oracle 10g RAC
ARPAV utilizza per la sua infrastruttura diversi DBMS, tra cui diverse versioni di
Oracle, a seconda dell’importanza del servizio e del carico di lavoro. In particolare, il
database oggetto dello studio è mantenuto su un’installazione di Oracle Database 10g
RAC. La versione 10g è stata rilasciata 2003, ed è la prima versione a essere commer-
cializzata col suffisso g che enfatizza il grid-computing ready. È stato poi rilasciato
un aggiornamento della piattaforma nel 2005 (Release 2) che è quella in possesso di
ARPAV. La sigla RAC sta per Real Application Cluster e indica una versione predi-
sposta a girare su più macchine server con storage condiviso. Questo permette molti
benefici in quanto si aumenta la potenza e la scalabilità delle applicazioni, oltre a
fornire una maggiore sicurezza di continuità del servizio in caso di guasto ad uno dei
server. Un altro vantaggio è la possibilità di aumentare la potenza installando nuo-
vi server senza dover cambiare l’hardware già in uso, aumentando la longevità degli
investimenti nell’infrastruttura informatica. Tra le altre caratteristiche del software
possiamo citare il partitioning, la gestione di dati XML tramite gli standard web del
W3C[C], l’introduzione delle espressioni regolari.
2.2 PostgreSQL
L’analisi del mondo open source alla ricerca di candidati ha portato alla luce la ric-
chezza di soluzione che sono disponibili per la gestioni di basi di dati. La maggior
parte del software però ha come target il mercato delle soluzioni a basso costo, oppure
nascono per esigenze specifiche e si specializzano in un certo segmento (alcuni progetti
sono leader del proprio segmento nonostante la presenza di soluzioni commerciali di
pari livello). Quando però si cercano prodotti per affrontare realtà molto complesse,
7 Pag: 7 di 672.2 PostgreSQL 2 TECNOLOGIE
si nota la diminuzione di soluzioni che affrontino completamente un certo problema.
Il motivo di questo è la complessità di sviluppo che questi progetti devono affrontare
e che, in mancanza di fondi, di una guida e di collaborazione, difficilmente riescono
a sopravvivere. Questo problema, che si riperquote in tutto il mondo open source,
è uno dei motivi principali per cui spesso si preferisce una soluzione proprietaria per
il semplice fatto che assicura (almeno sulla carta) un supporto duraturo nel tempo.
Esempi di eccellenza del mondo open source sono la Mozilla Foundation, il kernel Li-
nux, OpenOffice.org, Apache Foundation che, grazie a investimenti e supporto, hanno
dato alla luce prodotti che sono fra i maggiori player dei rispettivi mercati, se non i
leader. Per il mondo dei DBMS open source esiste un progetto che è riuscito a crescere
fino a competere attivamente nel segmento enterprise: PostgreSQL[10].
2.2.1 Storia del progetto
PostgreSQL è un object-relational database management system (ORDBMS) sviluppa-
to dal codice del progetto Berkeley POSTGRES e rilasciato sotto licenza open source.
Il progetto è nato nell’università di Berkeley nel 1986 e inizialmente fù diretto dal Pro-
fessore Michael Stonebraker e sponsorizzato dal DARPA (Defence Advance Research
Projects Agency), ARO (Army Research Office), NSF (National Science Foundation)
e da Esl, Inc. La prima versione funzionante risale al 1987 e viene effettuata una di-
mostrazione nel 1988 durante la ACM-SIGMOD Conference. L’anno successivo viene
rilasciata al pubblico, ricevendo tuttavia molte critiche al sistema delle regole, che vie-
ne riscritto sia nella seconda versione (1990) che nella terza (1991). Inoltre il progetto
si arricchisce di nuove funzionalità e comincia a puntare sulla portabilità e sull’affida-
bilità. Nel 1994, a causa di una riduzione dei fondi a sostegno, il progetto Berkeley
POSTGRES viene chiuso alla version 4.2.
Nel 1995, grazie al lavoro di Andrew Yu e Jolly Chen, viene aggiunto un interprete
SQL a POSTGRES (sostituisce il precedente linguaggio di query PostQUEL) e rila-
sciato col nuovo nome di Postgres95 sotto licenza open source con versione 1.0.x. Il
codice è completamente scritto in ANSI/C, superando le prestazioni della versione 4.2
di POSTGRES e si arricchisce di una nuova serie di funzionalità che tutt’oggi sono
parte integrante del progetto.
Tuttavia, nel 1996, viene deciso di cambiare il nome in PostgreSQL, per rende-
re chiaro il legame con POSTGRES e il cambiamento ottenuto col nuovo interprete
SQL. Il numero di versione viene portato a 6.0, per continuare la sequenza originale
cominciata con il progetto Berkeley POSTGRES. Attualmente l’ultima major release
rilasciata è la 8.4 e lo sviluppo si sta concentrando sulla versione 8.5.
2.2.2 Architettura
PostgreSQL usa un modello client/server e una tipica sessione di lavoro è il risultato
della cooperazione di diversi processi:
• un processo server che gestisce la base di dati e processa tutte le richieste di
accesso/modifica che arrivano dagli utilizzatori del database;
8 Pag: 8 di 672.2 PostgreSQL 2 TECNOLOGIE
• un processo client che richiede al server l’accesso/modifica dei dati in esso con-
tenuti. Un client può essere un’applicazione grafica, una console di testo, un
server web; in generale, chiunque usi il server diventa un client dello stesso.
Il processo server postgres può mantenere connessione multiple e concorrenti da più
client; per ogni utente viene effettuato un fork [C] dell’applicazione che si occupa sola-
mente del suo client, senza intervento del processo originale, il cui compito è di restare
in ascolto di eventuali nuove connessioni, tipicamente tramite protocollo TCP/IP.
Questa soluzione permette di mantenere un’alta continuità di servizio in quanto un
possibile malfunzionamento di un processo non influisce sulla capacità di accettare
nuove connessioni e sulle altre transazioni in corso.
2.2.3 Aderenza allo standard SQL
Lo standard SQL viene per la prima volta pubblicato dall’ANSI[C] nel 1986, e succes-
sivamente ratificato dall’ISO[C] nel 1987. Le evoluzioni più importanti sono avvenute
con la definizione di SQL-92, SQL-1999, SQL-2003 (supporto a XML e aggiornato con
SQL-2006 e SQL-2008) ad opera di ISO/IEC. Ad oggi, non esiste nessun DBMS che
rispetti completamente lo standard SQL-2003 il quale, per semplicità (e per problemi
avuti in passato nell’assegnazione della conformità), è diviso in più parti. PostgreSQL
supporta oltre 150 delle 164 caratteristiche definite fondamentali (full Core conforman-
ce) e molte altre funzionalità opzionali o di supporto. La difficoltà nel raggiungere la
piena conformità deriva dal fatto alcune richieste vanno in conflitto con funzionalità
tradizionali o modi di fare entrati nell’uso comune.
2.2.4 Accesso concorrente ai dati
PostgreSQL utilizza come default un approccio diverso da altri database per la ge-
stione degli accessi concorrenti ai dati: invece del tradizionale lock di righe e tabelle
utilizza un modello MVCC, MultiVersion Concurrency Control. Con questo modello,
ogni transazione vede uno snapshot del database che rappresenta i dati all’inizio della
connessione. Ogni UPDATE provoca un INSERT in fondo alla tabella e marca la vecchia
riga come invalida, ma resta disponibile per quei snapshot che devono poterla vedere.
Questo garantisce l’isolamento tra operazioni di lettura/scrittura ma comporta l’onere
di dover provvedere a pulire periodicamente il database dalle dead tuples tramite il
comando VACUUM FULL. Il sistema degli snapshot utilizza un indice di 4 byte per di-
stinguere ogni transazione e viene chiamato XID: un numero maggiore significa che la
transazione è stata eseguita temporalmente successivamente e quindi non è accessibile
alle transazioni ancora aperte con XID minore. Il comando VACUUM FULL si preoccu-
pa anche di gestire questo particolare indice impedendo che, superate le 4.294.967.296
transazioni, ci si possa trovare in situazioni in cui transazioni chiuse nel passato siano
nel futuro rispetto a nuove operazioni ancora aperte. Dalla versione 8.1 è stato intro-
dotto un processo demone che si occupa di lanciare periodicamente il comando VACUUM
e ANALYZE sul database e sugli schema, in base a parametri modificabili tramite il file
di configurazione.
9 Pag: 9 di 672.2 PostgreSQL 2 TECNOLOGIE
Nel caso in cui questo modello non soddisfi le aspettative, è comunque possibile
utilizzare il classico sistema a lock dei dati tramite comandi SQL. Questo approccio
però può portare alla creazione di deadlock : una transazione A blocca una tabella α
e richiede di operare sulla tabella β, che è stata bloccata dalla transazione B e che a
sua volta richiede di operare sulla tabella α. Questa situazione di stallo viene rilevata
da PostgreSQL che arbitrariamente elimina una delle transazioni coinvolte e permette
alle altre di continuare.
2.2.5 Stored procedure
PostgreSQL da pieno supporto alle stored procedure grazie al proprio linguaggo
PL/pgSQL che permette di implementare sottoprogrammi direttamente nel database.
Inoltre sono supportati anche PL/Perl, PL/TCL e PL/Python direttamente nel core
del programma, mentre altri possono essere aggiunti come estensioni. I vantaggi di
questa tecnologia sono vari:
• toglie complessità dal lato client in quanto query complesse possono essere ar-
chiviate all’interno del database;
• riduce la quantità di informazioni scambiate tra client e server migliorando le
prestazioni e i tempi di risposta;
• essendo di fatto un linguaggio strutturato, permette di compiere elaborazioni
che non sono possibili mediante l’uso di semplici query SQL;
• possibilità di creare librerie di funzioni a disposizione del database. Questo per-
mette di nascondere la struttura del database rendendo ogni operazione possibile
un funzione. Inoltre cosı̀ facendo si può evitare di dover garantire l’accesso al
database agli utenti;
• le procedure sono precompilate, eliminando l’onere di controllare la correttezza
degli statement richiesti.
2.2.6 Partizionamento delle tabelle
PostgreSQL permette di partizionare le tabelle per aumentare le prestazioni nel caso
in cui queste assumino dimensioni elevate (il punto esatto in cui questa operazione
sia conveniente non è calcolabile a priori, ma è consigliato quando la dimensione del-
la tabella sia superiore alla memoria fisica disponibile). Il partizionamento avviene
creando una tabella master da cui poi si derivano le tabelle child tramite ereditarietà
e creando dei vincoli all’inserimento tramite dei range sui dati. Si definisce poi una
funzione trigger sulla tabella master (che rimarrà vuota) in modo tale che le nuove
righe vengano reindirizzate nella partizione corretta. L’operazione risulta molto mac-
chinosa rispetto all’ambiente Oracle, anche se resta possibile creare delle funzioni per
automatizzare il processo di creazione di partizione e di aggiornamento dei trigger.
10 Pag: 10 di 672.3 LabWare LIMS 2 TECNOLOGIE
2.2.7 Jobs
PostgreSQL non supporta nativamente la schedulazione di jobs, la quale può essere
aggiunta tramite pgAgent. pgAgent è uno script che introduce una serie di funzioni
e procedure per la definizione di jobs che vengono eseguite poi da un demone (o
servizio, a seconda del sistema operativo). Si integra con la GUI pgadmin3 rendendo
più semplice la creazione e la gestione dei jobs.
2.2.8 Affidabilità e continuità di servizio
Caratteristica importante per un DBMS è la capacità di garantire il servizio e, nel
caso ciò non fosse possibile, di assicurare l’integrità e il recupero dei dati. PostgreSQL
mette a disposizione molti metodi per la replicazione sia del servizio sia dei dati. Il
metodo standard per assicurare l’integrità dei dati avviene tramite il Write-Ahead
Logging (WAL) il cui concetto si basa nel mantenere un log di tutte le transazioni
eseguite con successo. In questo modo, è possibile ripristinare lo stato del database
semplicemente ripercorrendo la storia contenuta nel log. Altro vantaggio è dato dal
minor uso di risorse, in quanto non è più strettamente necesario assicurare che ogni
transazione sia committata sul database, ma è sufficiente una fsinc() sul file di log.
Questo sistema viene anche utilizzato per la replicazione del database su macchine
slave e aumentare l’affidabilità globale, oltre che a bilanciare il carico di lavoro se
necessario. Oltre al sistema giá citato esistono poi altre configurazioni possibili che
migliorano il load balancing, i tempi di risposta e la replicazione del database
2.2.9 Evoluzioni future
Il ramo utilizzato per il progetto era contrassegnato dal numero di versione 8.3, rila-
sciata inizialmente il 4 febbraio 2008 e aggiornata fino alla versione 8.3.7 rilasciata il
16 marzo 2009 ed usata nel corso del progetto. Il 29 giugno 2009 è stata rilasciata
la versione 8.4, dopo 18 mesi di sviluppo, che diventa il nuovo ramo stabile e pro-
seguirà lo sviluppo di nuove features. Tra le principali novità ci sono le Windowing
Functions, le Recursive Queries, i Column Permissions e tutta una serie di migliora-
menti sull’aderenza allo standard, sulle prestazioni e sulla facilità di amministrazione.
Da sottolineare anche l’inizio dello sviluppo del supporto (si stima che sia completato
per la release 8.5) allo standard SQL/MED (Management of External Data)[11] che
permetterà di definire dei link a dati esterni al database, SQL e non, direttamente
all’interno di PostgreSQL[12].
2.3 LabWare LIMS
LabWare LIMS è l’applicativo che utilizza la base di dati di cui deve essere effettuata
la migrazione e per questo motivo sarà essenziale valutare il suo comportamento al
fine di decidere la fattibilità del progetto. La sigla LIMS è l’acronimo di Laboratory
Information Management System e indica tutta una serie di software che permettono
le gestione integrata di laboratori d’analisi e dei loro processi. Questi programmi de-
vono rispettare una serie di standard internazionali e nazionali (in Italia il riferimento
11 Pag: 11 di 672.4 Perl 2 TECNOLOGIE
è UNI/ISO EN 17025[13] per laboratori pubblici e privati) e si occupano di tutti gli
aspetti, dal personale ai metodi, alle apparecchiature, alla manipolazione dei campioni
e ai rapporti di prova. ARPAV ha da poco messo in funzione la soluzione LabWare
LIMS 6 (rilasciata il 28 febbraio 2008, che va a sostituire la precedente versione 5 in
uso presso ARPAV) per la gestione centralizzata di tutti i laboratori e dei rispettivi
campioni. L’azienda LabWare è tra i leader di questa fetta di mercato e i suoi prodotti
sono usati da molte grandi aziende del settore farmaceutico, chimico, minerario e da
grossi laboratori di analisi cliniche e ambientali. Il prodotto permette di avere una
gestione paperless, ovvero senza la necessità di stampare su carta i risultati e facendo
largo uso di report elettronici, garantendo un risparmio di prodotti consumabili e carta
e velocizzando le pratiche burocratiche.
2.4 Perl
L’utilizzo di Perl è stato vincolato in quanto alcuni degli strumenti utilizzati durante
la migrazione sono scritti in questo linguaggio. Di seguito, capita la potenza di questo
strumento e la sua versatilità, ho scelto di utilizzarlo per scrivere tutto il software di cui
ho avuto bisogno durante il progetto, rivelandosi una scelta fondamentale per il succes-
so dello stesso. Perl è un linguaggio di programmazione ad alto livello, con tipizzazione
dinamica, procedurale e interpretato creato nel 1987 da Larry Wall. Inizialmente na-
sce come linguaggio di scripting per l’ambito sistemistivo e per la manipolazione di
testi e file, ma si è evoluto, soprattutto grazie ai moduli creati dalla comunità, fino ad
ottenere un carattere più generale. Ad oggi può contare su un ricco archivio di moduli
creati dalla comunità, prevalentemente con licenza open source, raccolti sul sito web
CPAN[14] e con una ricca documentazione a supporto. Perl è diventato conosciuto
sopratutto grazie alla potenza delle espresioni regolari[C] che permettono di lavorare
e manipolare testi in maniera molto rapida e con una grande libertà. Il linguaggio
stesso permette di condensare molte operazioni complesse in poche righe di codice,
dimostrando la potenza del linguaggio stesso ma risultando spesso difficile da leggere
e mantenere. Questa è una delle critiche che più spesso vengono mosse al linguaggio,
anche se vengono spesso definiti dal suo creatore come vantaggi del linguaggio: There
is More Than One Way To Do It. Altra caratteristica importante per la sua diffusione
è la facilità con cui si integra con linguaggi diversi, diventando quindi il collante di
sistemi eterogenei. L’ultima versione disponibile è la 5.10.0 e lo sviluppo è concentrato
sull’uscita della versione 6.0, in sviluppo dal 19 luglio 2000.
12 Pag: 12 di 673 SVILUPPO
3 Sviluppo
3.1 Approccio al problema
Per una più facile comprensione del problema è stata effettuata una Analisi dei Re-
quisiti a cui il progetto deve rispondere con una possibile soluzione o con una rispo-
sta negativa in termini di fattibilità. Non viene effettuata una classificazione e sono
considerati tutti come requisiti obbligatori.
• Deve essere possibile trasferire l’attuale schema del database nella DBMS da
individuare che può comprendere: TABLE, VIEW, GRANT, SEQUENCE, TRIGGER,
FUNCTION, PROCEDURE e PACKAGE;
• Deve essere possibile tradurre eventuali costrutti PL/SQL in un linguaggio equi-
valente per ottenere gli stessi risultati;
• L’applicazione che utilizza il database si interfaccia ad esso tramite la tecnologia
ODBC[C]. È dunque necessario che esista un driver specifico per il DBMS da
sostituire alla piattaforma Oracle;
• IL DBMS deve essere in grado di acquisire/fornire informazioni a database diversi
in maniera trasparente;
• I requisiti hardware non devono essere troppo elevati o richiedere investimenti
nell’infrastruttura già esistente;
• Il DBMS deve essere in grado di soddisfare il carico di lavoro generato dall’u-
tenza, e deve essere in grado di scalare le proprie perfomance aumentando le
potenzialità hardware del server utilizzato allo scopo;
• Deve essere disponibile una interfaccia di controllo sufficentemente avanzata per
semplificare il lavoro di amministrazione.
Di conseguenza il lavoro svolto è stato suddiviso in tre fasi: replicazione dello schema,
test degli applicativi, benchmark delle prestazioni.
3.2 Ambiente di sviluppo
Fondamentale a questo punto è creare una piattaforma di sviluppo e test che permet-
tesse di ottenere un sistema adatto a contenere il progetto e che potesse essere poi
confrontato col sistema che attualmente gestisce il database LIMS. La scelta è caduta
sull’utilizzo di una macchina virtuale per la facilità con la quale può essere trasferita
su hardware diverso e la possibilità di cambiare le risorse hardware a disposizione.
Per velocizzare le operazioni si è scelto di adottare la tecnologia di VMware, già pre-
sente e utilizzato all’interno di ARPAV. La scelta del sistema operativo è caduta su
GNU/Linux vista la mia esperienza personale con lo stesso maturata dalla scelta di
abbandonare soluzioni software proprietarie. Da un punto di vista più tecnico, per-
mette di ottenere un sistema performante e sicuro, caratteristiche fondamentali in
13 Pag: 13 di 673.2 Ambiente di sviluppo 3 SVILUPPO
ambito server e che spesso vengono sottovalutate anche da grandi aziende. La scelta
del sistema operativo è caduta su OpenSUSE 11.1 in quanto già utilizzata in passato e
per la possibilità di avere facilmente accesso a programmi, aggiornamenti e supporto,
vista la numerosa community che segue questo progetto. Sicuramente non sarebbe la
scelta migliore per un ambiente di produzione, per il quale sarebbe appropriato usare
distribuzioni più orientate all’ambito enterprise quali Red Hat, SUSE Enterprise, Cen-
tOS. Oltre al sistema operativo, sono stati intallati ulteriori software utili alla gestione
e all’utilizzo della macchina. In particolare è stato installato un server SSH per il con-
trollo remoto e un server Apache2 per l’utilizzo di servizi web. Altro elemento chiave
è stato l’interprete Perl[15], necessario per l’esecuzione di script sia interni che esterni
al database. PostgreSQL è disponibile per una grande varietà di sistemi operativi ed è
quindi possibile scegliere una qualunque piattaforma supportata (BSD, Solaris, Unix,
Microsoft Windows, Mac OS X)1 .
3.2.1 Installazione di PostgreSQL
Nel nostro caso è stato necessario installare tramite il packet manager zypper i pac-
chetti postgresql, postgresql-contrib, postgresql-libs, postgresql-server e
postgresql-plperl reperibili dai repository standard della distribuzione. Si consiglia
di installare l’ultima versione disponibile di PostgreSQL, la 8.3.7, in quanto si sono
presentati problemi con versioni non aggiornate (in particolare, la versione 8.3.5 pac-
chettizzata per OpenSUSE non riusciva ad eseguire correttamente gli script forniti da
dbi link, causando un crash del thread di PostgreSQL). Nel caso non fosse disponibile
un pacchetto che installi i moduli per plperl è necessario attivare il supporto compi-
lando PostgreSQL con un apposito switch: --with-perl. In questo modo è possibile
attivare anche gli altri linguaggi supportati come Python, Java, Tcl.
3.2.2 Configurazione
La configurazione di base proposta non è utilizzabile per i nostri obiettivi e deve
necessariamente essere modificata. In particolare PostgreSQL, di default, è utilizza-
bile solo localmente dalla macchina su cui viene installato e l’accesso avviene tramite
l’utente postgres, account superuser non protetto da password. Le modifiche alle
impostazioni avvengono tramite dei file di configurazione: postgresql.conf per i
parametri di generali quali uso delle risorse, manutenzione automatica, logging, etc
e pg hba.conf per il controllo degli accessi utente. Questi file vengono creati nella
directory $HOME/data dell’utente postgres, possono essere modificati con un editor
di testo e vengono caricati all’avvio del processo server (in alternativa è possibile per
alcune impostazioni usare la server command line per la configurazione senza riav-
vio). La gestione degli utenti può avvenire sia dall’interno tramite comandi SQL, sia
dall’esterno usando i comandi specifici di PostgreSQL createuser e dropuser.
Per consentire a PostgreSQL di ricevere connessioni TCP/IP in ingresso è necessa-
rio modificare il parametro della variabile listen address situata all’interno del file
1
Per la documentazione completa si rimanda al sito ufficiale [16]
14 Pag: 14 di 673.3 Amministrazione 3 SVILUPPO
postgresql.conf a seconda dei proprio bisogni. Come parametri accetta una lista di
hostname e/o indirizzi ip oppure il carattere * per indicare qualsiasi indirizzo.
La gestione dell’accesso ai database è regolata attraverso il file pg hba.conf, il
quale contiene permette di specificare delle righe che definiscono chi può accedere, a
quale database e da quale indirizzo. In questo modo è possibile definire ogni singolo
aspetto delle connessioni in ingresso per mantenere un alto livello di sicurezza. Quı̀ di
seguito vengono riportati i vari formati che possono avere i record presi dai commenti
presenti all’interno del file stesso:
# local DATABASE USER METHOD [OPTION]
# host DATABASE USER CIDR-ADDRESS METHOD [OPTION]
# hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
# hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
La documentazione completa è presente sia all’interno del file sia sul sito web di
PostgreSQL[16] per ogni versione in fase di mantenimento e per le versioni in sviluppo.
3.3 Amministrazione
Insieme al programma server, il pacchetto PostgreSQL fornisce un programma client
per interfacciarsi al processo server tramite console di comando: psql. Oltre a permet-
tere l’inserimento e l’esecuziondi di query SQL, fornisce meta-comandi e funzionalità
per la scrittura di script. psql si è rivelato uno strumento molto potente nonostante la
scarsa efficacia della sua interfaccia grafica: il suo uso è stato necessario sia per motivi
di debug sia per l’esecuzione di operazioni lunghe in ordine di tempo di esecuzio-
ne. Tuttavia per la maggior parte ho preferito utilizzate pgAdmin, interfaccia grafica
multi-piattaforma. Durante il progetto la versione stabile era la 1.8 ed era disponibile
la versione 1.10beta, utilizzata per il numero maggiore di funzionalità a disposizione,
nonostante una diffusa instabilità (da qui la necessità ad utilizzare psql). La versione
1.10 stabile è stata rilasciata il 30 giugno 2009 e, oltre a nuove funzionalità, ufficializ-
za il supporto a PostgreSQL 8.4 e migliora l’affidabilità dell’applicazione. Oltre alle
normali operazioni di gestione di dati, tabelle, etc. è possibile effettuare backup, ripri-
stino di dati, manutenzione del server. È possibile anche visualizzare in tempo reale
le connessioni aperte, i lock sulle tabelle, le transazioni in corso ed creare file di log
di tutte le operazioni che vengono effettuate. Il giudizio è sostanzialmente positivo in
quanto permette di amministrare completamente la base di dati e si integra con altre
funzionalità (jobs, debug, etc.) che estendono ulteriormente le capacità di controllo e
manutenzione. Tuttavia risulta chiaro che l’applicazione necessita di ulteriore sviluppo
se vuole raggiungere un livello di maturità maggiore, sia dal profilo dell’usabilità sia
come stabilità. Esiste un’altra interfaccia grafica per PostgreSQL che ha più successo
per nel web, in quanto sviluppata in PHP[C]: phpPgAdmin. Per poterla utilizzare è
necessario appoggiarsi ad un server web con supporto a PHP e permette anch’essa
di amministrare in maniera completa ogni aspetto della base di dati. Il suo utilizzo
durante il progetto è stato molto limitato anche a causa del suo sviluppo fermo da
alcuni mesi che pregiudica la possibilità di diventare uno strumento di riferimento per
l’amministrazione di PostgreSQL.
15 Pag: 15 di 673.4 Collegamento con altri database 3 SVILUPPO
3.4 Collegamento con altri database
Nativamente PostgreSQL fornisce funzioni di collegamento solo a database remoti
PostgreSQL ma è possibile estendere questa funzionalità grazie all’uso del linguag-
gio Perl e dei suoi moduli. Per l’utilizzo di Perl come linguaggio di scripting si deve
compilare PostgreSQL attivando il supporto al linguaggio PL/PerlU tramite switch
di compilazione. Oltre a questo, deve essere installato un interprete Perl che si occu-
perà dell’esecuzione materiale degli script. Il collegamento ad altri database avviene
utilizzando il modulo DBI [17], lo standard de-facto per l’accesso a dati remoti per il
linguaggio Perl. Per ogni tipo di database supportato esiste un driver DBD specializ-
zato che permette di collegarsi, effettuare query, ricevere dati e inserirne di nuovi2 . A
questo punto le strade percorribili sono la scrittura di script per effettuare le operazioni
richieste (sia come script esterni al database, sia come funzioni o procedure contenute
all’interno dello schema) oppure l’installazione del pacchetto dbi link che crea la strut-
tura del database remoto direttamente in PostgreSQL e mette a disposizione funzioni
per l’utilizzo dei dati. Entrambi gli aspetti saranno approfonditi in seguito.
Il driver DBD:Oracle[18] viene fornito come sorgente da compilare sulla macchina
su cui deve essere eseguito. Questo scelta è derivata dal fatto che per la compilazione è
necessario avere delle librerie che vengono fornite insieme all’Instant Client di Oracle
e quindi specifiche per la piattaforma utilizzata. In particolare è necessario installare
i pacchetti Instant Client Basic, Instant Client SQL*Plus e Instant Client
SDK. Una volta che questi file sono accessibili è possibile procedere con la compilazione
del modulo ed installarlo globalmente sul sistema (ci si riferisca al file README contenuto
nel pacchetto DBD::Oracle).
Per collegarsi ad Oracle sono possibili due strade alternative. Con il metodo stan-
dard descritto dalla documentazione Oracle è necessario creare i file sqlnet.ora e
tnsnames.ora. Quest’ultimo contiene le entry con i dati relativi ai server a cui è
possible collegarsi, in modo che ai client basti specificare il database interessato, senza
dover specificare altri dati quali l’indirizzo del server, la porta utilizzata e il service
name (o sid). Per permettere poi l’utilizzo di questi file, si deve definire una variabile
d’ambiente TNS ADMIN che contiene il path a questi. Il modulo DBI può utilizzare
queste informazioni, riducendo i parametri necessari per la stringa di collegamento al
database. È comunque possibile e consigliato specificare tutti i parametri, rendendo
di fatto inutile la procedura esposta precedentemente, aumentando la portabilità degli
script e la facilità di manutenzione.
3.4.1 dbi link
Il pacchetto dbi link [19] fornisce uno script SQL che carica nel database uno schema
contenente funzioni e tabelle il cui compito è rendere trasparente la comunicazione
con il database remoto. La configurazione avviene tramite una funzione che scarica lo
schema del database remoto e lo replica localmente, permettendo di effettuare query,
inserimenti, aggiornamenti e cancellazione dei dati. È necessario che sia già creato
un database, nel quale lo script creerà uno schema, che abbia attivato il supporto
2
I moduli aggiuntivi per Perl possono essere reperiti sul sito CPAN[14]
16 Pag: 16 di 673.4 Collegamento con altri database 3 SVILUPPO
a PL/PerlU. Ci sono vari modi per fare questo, di cui il più semplice è tramite una
interfaccia grafica. Di seguito viene mostrato come fare avendo accesso ad una console:
prima si crea il database
createdb
e successivamente attivare il supporto a PL/PerlU sul database con il comando
createlang plperlu
A questo punto bisogna caricare il file dbi link.sql fornito dal pacchetto dbi link nel
database in modo da creare tutte le procedure e le funzioni per il corretto funziona-
mento del link al database remoto:
psql -f /dbi_link.sql
Il passo successivo è configurare il dbi link attraverso una chiamata ad una procedura
creata precedentemente, che si occuperà di creare uno schema associato al database
remoto, di cui importerà la struttura delle tabelle. I comandi successivs sono statement
SQL e per questo devono essere inseriti usando psql o una interfaccia grafica
--
-- Data source: dbi:oracle:database=world;host=localhost
-- User: root
-- Password: foobar
-- dbh attributes: {AutoCommit => 1, RaiseError => 1}
-- dbh environment: NULL
-- remote schema: NULL
-- remote catalog: NULL
-- local schema: world
--
SELECT dbi_link.make_accessor_functions(
’dbi:oracle:database=;host=’,
’root’,
NULL,
NULL,
NULL,
NULL,
NULL,
’’
);
Lo script, disponibile alla versione 2.0.0, non è stato in grado di importare corret-
tamente il remote schema Oracle anche se impostato nella riga di comando, con la
conseguenza che PostgreSQL non era in grado di eseguire correttamente query al da-
tabase remoto. Il problema è stato risolto esportando la struttura appena creata in
17 Pag: 17 di 673.5 Ora2Pg 3 SVILUPPO
un file .sql e procedendo a cambiare gli script di creazione delle view usando una
funzionalità di search and replace.
Una volta inseriti questi comandi, è possibile effettuare interrogazioni al database
remoto semplicemente specificandolo, per esempio:
SELECT * FROM ."";
SELECT "" FROM ."";
in quanto il link viene salvato all’interno dello schema precedentemente creato da
dbi link. È possibile registrare più link remoti utilizzando la funzione
dbi_link.make_accessor_function()
con i parametri desiderati.
SELECT dbi_link.make_accessor_functions(
’dbi:Oracle:database=LIMS.sirav;
host=carl-vip.arpa.veneto.it;
service_name=LIMS’,
’pg’,
’pg’,
NULL,
NULL,
NULL,
’labware’,
’labware’
);
L’uso di questo strumento ha portato alla luce parecchi limiti, dovuti soprattut-
to al fatto che l’ultima release stabile del progetto risale al 27 Gennaio 2007. Una
lacuna importante è emersa nella conversione dei tipi, praticamente inesistente. Ho
provato a migliorare questo aspetto, riuscendo a ottenere una struttura più ricca e
simile all’originale, ma sarebbe necessario riscrivere parte dello script per permettere
di effettuare una conversione opportuna per ogni diverso DBMS remoto. Un problema
che invece non è stato possibile risolvere ha riguardato la possibilità di personalizzare
le query al database remoto. Oracle permette di salvare in un tipo DATE anche le
informazioni riguardanti ore, minuti e secondi (lo standard SQL richiederebbe di usare
un tipo TIMESTAMP, tuttavia è prassi comune adottare questa soluzione in ambiente
Oracle) che non vengono poi restituite in una query semplice. Per ottenere tutta l’in-
formazione è necessario l’utilizzo della funzione to char(, ’DD-MM-YYYY
HH24:MI:SS’), ma non è stato possibile istruire dbi link ad utilizzarla in presenza di
campi DATE. Lo stato di abbandono del progetto è accentuato anche dalla mancanza
di documentazione e dall’inutilizzo di mailing list e forum.
3.5 Ora2Pg
Ora2Pg[20] è uno script Perl che permette di esportare la struttura e i dati di un
database Oracle nel dialetto SQL utilizzato da PostgreSQL. La prima versione è stata
18 Pag: 18 di 673.5 Ora2Pg 3 SVILUPPO
rilasciata il 9 maggio 2001 e l’ultima versione stabile è la 5.4 rilasciata il 15 luglio 2009.
Per poterlo utilizzare si deve essere in possesso di un interprete Perl (richiesta versione
5.8, consigliata 5.10) con l’accesso ai moduli DBI, DBD::Oracle e DBD::Pg[21].
3.5.1 Utilizzo del modulo
Per l’utilizzo di Ora2Pg ho scritto uno script Perl che si occupa di ottenere dal da-
tabase Oracle tutti gli oggetti necessari per riprodurre lo schema sulla piattaforma
PostgreSQL, il cui codice è riportato nell’appendice B.1. Lo script permette di espor-
tare separatamente i vari tipi di oggetti che possono essere presenti nella base di dati
Oracle e di scriverli su file. La sintassi è SQL e il dialetto dipende dal tipo di oggetto:
in generale, le tabelle vengono tradotte dallo script, mentre il resto degli oggetti viene
esportato as-is, senza manipolazioni.
3.5.2 Conversione del codice
Una volta ottenuti gli oggetti dal database Oracle, è necessario controllare il codice
di alcuni elementi, in particolare funzioni, procedure, trigger e package. Questo è
necessario in quanto sono oggetti scritti in linguaggio PL/SQL, non supportato da
PostgreSQL. È comunque relativamente semplice modificare il codice nel linguaggio
PL/pgSQL vista la sintassi molto simile. Inoltre è necessario decidere come trattare
i package perchè non supportati da PostgreSQL. Una soluzione semplice consiste nel
portare gli oggetti contenuti nel package nello spazio pubblico delle funzioni. Altri-
menti è possibile creare uno schema apposito, con proprie tabelle se neccessario, se si
vuole ottenere una maggiore separazione logica. Lo schema non ha bisogno di parti-
colari attenzioni, in quanto la differenza fra tipi viene già risolta internamente dallo
script, creando statement SQL già compatibili con PostgreSQL. Anche i dati vengono
esportati in maniera corretta, e sono subito inseribili nel nuovo schema senza necessità
di modifiche. In un paio di casi però non è stato possibile esportare i dati da alcune
tabelle a causa di un errore nello statement per la lettura. L’errore è causato da alcuni
nomi di colonne che sono anche keywords e che non vengono inibite tramite l’uso di
escaping characters nello statement creato dallo script. Il problema è stato segnalato
all’autore del programma e corretto nella versione 5.1 con l’aggiunta di una features
che permette di definire le keywords da controllare.
3.5.3 Definizione delle view
Nel trasportare alcune view da Oracle a PostgreSQL sono emersi dei problemi derivati
da techiche permesse in Oracle che non sono riproducibili in ambiente PostgreSQL.
In particolare Oracle permette di creare view definendo colonne di tipo nullo o con
valore costante, cosa non possibile in PostgreSQL che segnala come non corretto il
codice SQL generato. Questa pratica è stata usata per mantenere lo stesso codice di
creazione della view anche su database diversi con tabelle simili ma non uguali. Per
risolvere questo problema di portabilità ho separato i due casi e ho creato delle funzioni
per i campi a valore costante, il cui tipo di ritorno definisce anche il tipo della colonna,
19 Pag: 19 di 673.6 Creazione del database 3 SVILUPPO
e ho eliminato le colonne a valore nullo. Queste ultime non venivano giudicate come
un vero errore, si limitavano a lanciare un warning e venivano create colonne di tipo
unknown, tuttavia erano completamente inutili e inutilizzabili. Un difetto di Ora2PG
è stato riscontrato nella definizione delle clausole WHERE : i valori su cui effettuare
i confronti sono stati erroneamenti modificati da maiuscolo a minuscolo. Questo ha
portato ad avere view valide sintatticamente ma errate logicamente, in quanto non
ritornavano nessun risultato. Ho dovuto correggere manualmente gli script in modo da
ripristinare il corretto funzionamento. Il problema è stato segnalato all’autore insieme
ad una patch ed è stato risolto completamente nella versione 5.3. Altro difetto di
Ora2Pg si manifestava sistematicamente nella creazione del codice di una particolare
view (le altre view sono tutte create correttamente): l’ordine dei nomi delle colonne
non veniva preservato, creando un errore logico nella struttura della view. Anche
questo problema è stato segnalato all’autore e risolto nella versione 5.2 dello script.
3.5.4 Materialized view
Con Oracle è possibile definire delle materialized view (viste materializzate), ossia
delle viste il cui contenuto viene precalcolato. L’utilizzo principale è di ridurre il
costo computazionale di query troppo pesanti (anche se i dati possono essere out-of-
date) e di replicare tabelle remote. PostgreSQL non supporta nativamente questo
tipo di oggetti, anche se è possibile creare funzioni per la gestione di queste. Inoltre
lo script Ora2Pg non ha esportato queste viste insieme al resto dello schema. Nel mio
caso, erano presenti 3 materialized view il cui scopo era di replicare il contenuto di
alcune tabelle di un database remoto all’interno di LIMS. Per affrontare il problema
ho proceduto a creare 3 tabelle in PostgreSQL e ho scritto una funzione in Perl che
si collega al database remoto e porta i dati nel database locale. Tale scelta è dovuta
al fatto che le tabelle sono relativamente piccole e non c’è la necessità di ricorrere a
soluzioni più sofisticate.
3.5.5 Impressioni
L’uso di Ora2Pg è stato fondamentale per la riuscita della migrazione della base di dati:
permette infatti di ottenere subito la struttura del database su cui poi si può lavorare
per ottenere uno schema in PostgreSQL perfettamente funzionante e identico (nelle
funzionalià) a quello di partenza. Le lacune riscontrate sono state risolte in tempi
relativamente brevi, dimostrando di essere un progetto attivo e su cui c’è interesse.
La natura open source mi ha permesso di contribuire attivamente al miglioramento
dello stesso, cosa che ha velocizzato la risoluzione di alcuni problemi e mi ha portato
a conoscere meglio sia lo script sia il linguaggio Perl con cui è scritto.
3.6 Creazione del database
Per la creazione del database LIMS sulla piattaforma PostgreSQL sono stati creati
degli script che, eseguiti in sequenza, replicano la struttura e tutte le funzionalità
presenti. La procedra viene di seguito descritta:
20 Pag: 20 di 673.6 Creazione del database 3 SVILUPPO
• Creazione del database: la creazione può avvenire da riga di comando tramite
createdb -h -U -W
oppure usando un’interfaccia grafica;
• Script con comandi di supporto: il file 00 init.sql contiene tutti gli statement
di supporto necessari ad impostare correttamente il database. Nel nostro caso
vi sono definiti gli statement CREATE LANGUAGE per la definizione dei linguaggi
supportati. Questo file non viene creato dallo script precedente ma deve essere
scritto a seconda delle esigenze richieste. Può essere caricato sul database tramite
il comando
psql -h -U -W -d -f 00 init.sql
oppure usando un’interfaccia grafica;
• Creazione dello schema: la definizione delle tabelle dello schema è contenuta nel
file 01 schema.sql. Può essere caricato sul database tramite il comando
psql -h -U -W -d -f 01 schema.sql
oppure usando un’interfaccia grafica;
• Creazione delle SEQUENCE : la sequenzialità delle informazioni contenute del
database è mantenuta da alcune sequence aggiornate da funzioni trigger che si
attivano all’inserimento o all’update delle informazioni di alcune tabelle. Questa
informazione poi viene trasferita nel passaggio dei dati, per questo motivo è
consigliato creare questi oggetti prima di effettuare il passaggio dei dati. Può
essere caricato sul database tramite il comando
psql -h -U -W -d -f 02 sequence.sql
oppure usando un’interfaccia grafica;
• Caricamento dei dati: a questo punto si può procedere al caricamento dei dati.
È consigliato importarli adesso in quanto non sono ancora presenti i trigger che
possono influenzare il corretto inserimento dei dati e portare a discrepanze e in-
coerenza (lo script Ora2Pg permette in ogni caso di inserire i dati disabilitando
temporaneamente i trigger se è già disponibile la struttura completa del databa-
se). Per fare questo si deve eseguire lo script Perl export data.pl configurato
con i dati di collegamento ai due database. Il codice dello script è riportato
nell’appendice B.2;
• Creazione dei TRIGGER: dopo aver controllato ed eventualmente sistemato il
codice dei trigger, possono essere caricati sul database. Può essere caricato sul
database tramite il comando
psql -h -U -W -d -f 04 trigger.sql
oppure usando un’interfaccia grafica;
• Funzioni di supporto: per ovviare ad alcune convenzioni Oracle non riproducibili
in ambiente PostgreSQL è stato necessario scrivere alcune funzioni per permette-
re il corretto funzionamento delle view. In particolare, sono sta definite funzioni
21 Pag: 21 di 67Puoi anche leggere
