Intervento di Sergio Mior al Forum Qualità del Software e Servizi ICT di Milano, 02 Luglio 2015

1. Da Oracle a PostgreSQL :
L'evoluzione dei RDBMS
Le funzionalità di High Availability, Load
Balancing e Disaster Recovery con il
sistema di gestione dati Open Source
PostgreSQL
Milano, 2 Luglio 2015,
Forum della Qualità del Software e dei Servizi ICT
1

2. Sergio Mior
CEO di Database & Technology
Esperienza informatica dal 1970
Laurea Economia indirizzo statistico 1972
Oracle – PostgreSQL DBA
1998-2015 Correlatore Tesi UniMI Informatica
2001-2013 Prof. a Contratto UniMI
2

3. Business Continuity
3
DownTime
Non
Pianificato
DownTime
Pianificato
Media Failure
Data failure
& Disaster
Human Error
System
Maintenance
Backup / Restore-recover
Cold-Warm
Data Guard – FailOver
FlashBack – repair error
Data Guard –
SwitchOver

4. Disaster
« Se qualcosa può andar male,
andrà male »
Legge di Murphy
4

5. Disaster
Fonte: Quorum Q1 2013 Disaster Recovery Report
http://www.youtube.com/watch?v=pqDRcfI_E1s 5

6. Alcune Statistiche
•
Il 34% delle aziende italiane effettua
test di disaster recovery una volta
all'anno.
•
Il 72% sostiene che i disastri naturali
sono la loro principale fonte di
preoccupazione nel momento in cui
sviluppano piani di disaster recovery.
Fonte: report Symantec Disaster Recovery Research 2007
http://eval.symantec.com/mktginfo/enterprise/other_resources/b-symantec_disaster_recovery.08-2008.en-us.pdf
6

7. Alcune Statistiche
•
Le relazioni con i fornitori (78%),
•
la fedeltà dei clienti (74%),
•
i danni alla reputazione del marchio (64%),
•
la riduzione dei profitti (64%)
•
la produttività del personale (62%)
sono i primi 5 elementi di preoccupazione
associati al possibile verificarsi di un disastro.
Fonte: report Symantec Disaster Recovery Research 2007
http://eval.symantec.com/mktginfo/enterprise/other_resources/b-symantec_disaster_recovery.08-2008.en-us.pdf
7

8. 8
COLLABORAZIONE UniMI Corso
Laurea Informatica
● Anno Accademico 2005/2006 :
Laboratorio Basi Dati I : Oracle
● Anni Accademici dal 2005/2006 fino al 2008/2009 :
Laboratorio Basi Dati I : PostgreSQL
● Anni Accademici dal 2000/2001 fino al 2008/2009 :
Corso Prestazioni e Tuning di Basi di Dati : Oracle
● Anni Accademici dal 2005/2006 fino a tuttora :
Laboratorio Basi Dati II : Oracle

9. 9
D&T : Oracle – PostgreSQL : le Tesi
Anno Accademico Oracle PostgreSQL
2000/2001 Replication by Log Miner --
2001/2002 Tuning Prestazioni --
2002/2003 Sicurezza Dati MySQL
2006/2007 Replication Replication
2006/2007 Backup / Recovery Backup / Recovery
2006/2007 Materialized Views --
2007/2008 DW: progettazione fisica DW: progettazione fisica

10. 10
Anno Accademico Oracle PostgreSQL
2008/2009 -- Load Balancing e VLDB
2008/2009 Disaster Recovery Disaster Recovery
2008/2009
Strumenti di Tuning
Prestazionale
Strumenti di Tuning
Prestazionale
2009/2010
Load Balancing, High
Availability
Load Balancing, High
Availability
2010/2011 DW: Change Data Capture DW: Change Data Capture
2011/2012
DB Auditing e Normative
Sicurezza
--
D&T : Oracle – PostgreSQL : le Tesi

11. Anno Accademico Oracle PostgreSQL
2013/2014 FlashBack FlashBack
2013/2014 Load Balancing Load Balancing
2014/2015 Dati strutturati JASON
Dati strutturati JASON e
JASONB
D&T : Oracle - PostgreSQL : le Tesi
… in corso
11

12. 12
Anno Accademico Argomento Giudizio
2002/2003 Sicurezza Dati
Oracle usa RBAC e i criteri del System-R, MySQL solo la
Connection Verification e Request Verification
2006/2007 Replication
Oracle unisce replica master/ master,
sia sincrona che asincrona, con replica master/slave.
PostgreSQL più package pgpool-II ( master/ master,
sincrona) e Slony- I (master/slave).
Oracle replica : tabelle, indici, package, funzioni, viste,
sinonimi, ecc...
PostgreSQL Slony- I : tabelle, sequenze
2007/2008 DW Progettazione
fisica
PostgreSQL: No partizionamento composito, no indici
bitmap, no parallelismo di processi
Pochi strumenti di amministrazione e analisi carico.
benchmark TPC-H : La miglior ottimizzazione con
PostgreSQL ha tempi di risposta16 volte peggiori
rispetto alla miglior configurazione ottenuta con Oracle
e 3 volte peggiori rispetto a Oracle in configurazione
base senza alcuna ottimizzazione
D&T : Oracle – PostgreSQL: i Giudizi

13. Anno Accademico Argomento Giudizio
2008/2009 Load Balancing e
VLDB
PGCluster realizza DB replicati in modo sincrono,
garantendo la Business Continuity
Scalabile, intervenendo con aggiunta di
ClusterDB in modo dinamico
Alta affidabilità con continuo monitoring del
sistema e eventuale esclusione dei ClusterDB
inattivi e pianificazione del loro recupero
2008/2009 Disaster Recovery
Log Shipping in PostgreSQL a livello Transaction
Log, in Oracle anche a livello transazione.
PostgreSQL ha solo Redo Apply, Oracle anche
SQL Apply.
La proposta di PostgreSQL è efficace e robusta,
economicamente più vantaggiosa.
Oracle risponde alla necessità presente o futura
di una granularità a livello di transazione e fosse
indispensabile disporre immediatamente anche
dell’ultima transazione committata.
D&T : Oracle – PostgreSQL: i Giudizi
13

14. D&T : Oracle – PostgreSQL: i Giudizi
Anno
Accademico
Argomento Giudizio
2008/2009 Strumenti di Tuning
Prestazionale
Confronto Oracle 11.1 e PostgreSQL 8.4
Entrambi hanno Tool di stima e di consuntivo
In Oracle le stime sono 1/10 del consuntivo, il
contrario in PostgreSQL.
In query complesse e con strutture non adeguate
i tempi sono simili, ma con strutture adeguate
(partizionamento sul predicato di WHERE), i
tempi di PostgreSQL sono 1/10 di Oracle
2010/2011 DW: Change Data
Capture
Confronto tra Oracle Golden Gate (GG) e Slony-I
GG è mono e bidirezionale, Slony-I solo mono
Slony-I ha migliori performance del 10-20%
2014/2015
Dati non strutturati o
semistrutturati in Oracle
e PostgreSQL in
previsione dei BigData
Oracle e PostgreSQL per la capacità di
estensibilità si inseriscono perfettamente dentro
il panorama big data o NoSQL.
PostgreSQL ha prestazioni migliori rispetto ad
Oracle, per quanto riguarda i tipo di dato JSON,
ovvero all`aumentare del numero di sessioni e
del volume delle transazioni e dei dati presenti
nel database, PostgreSQL mantiene un livello
pressoché lineare dei tempi di esecuzione. 14

15. MIGRAZIONE da piattaforma
commerciale a PostgreSQL: VINCOLI
● Mancata collaborazione dei fornitori degli
applicativi aventi il Repository Dati su un RDBMS
commerciale.
● Indifferenza da parte del Management
aziendale a causa della presenza di strategie più
critiche
● Spirito di conservazione degli attuali utenti
15

16. 16
MIGRAZIONE da piattaforma
commerciale a PostgreSQL: la
collaborazione D&T
● Verifica d'impatto sugli applicativi coinvolti nel cambio di
Repository Dati
● Predisposizione solidale del Piano di Migrazione
● Verifica Mantenimento concordato in modi e tempi del
Repository Dati precedente e versione precedente degli applicativi
● entro 3 mesi (default) dalla migrazione, si può decidere di
rinunciare alla stessa. Lo smantellamento e il ripristino saranno a
carico di D&T a titolo gratuito per i primi 5 giorni/uomo

17. 17
● I DBMS “chiusi” (es: Oracle) sono molto costosi.
● Soffrono spesso di gravi problemi di sicurezza.
● Economicamente solo la società che lo sviluppa può trarne
vantaggi e per questo motivo è raro vedere community
interessate a questi prodotti.
● Inoltre lo studio di questi prodotti è ostacolato dalla
segretezza del codice sorgente.
Fonte : Seminario UniBicocca 22/1/2007 DBMS a Confronto
http://geekplace.org/download/DBMS%20a%20confronto%20-%20NeCoSi%2001.odp
Confronto tra DBMS :
chiusi, semichiusi, aperti

18. 18
● I DBMS “semi-aperti” (es: MySQL)
offrono un elevato livello di sicurezza grazie alla duplice attenzione
da parte di una community e da parte di un team di sviluppo
ufficiale.
● Possono essere sfruttati economicamente da tutti, ma una
sola azienda è posta in una posizione privilegiata.
Fonte : Seminario UniBicocca 22/1/2007 DBMS a Confronto
http://geekplace.org/download/DBMS%20a%20confronto%20-%20NeCoSi%2001.odp
Confronto tra DBMS :
chiusi, semichiusi, aperti

19. 19
Confronto tra DBMS :
chiusi, semichiusi, aperti
● I DBMS “aperti” (es: PostgreSQL) non soffrono
problematiche di mercato. La loro sicurezza è comunque alta.
Tutti possono trarne liberamente profitto.
● Essendo il sorgente di pubblico dominio ed utilizzando
licenze libere, sono predisposti per studi ed analisi; per questo
sono consigliati in ambiti accademici.
Fonte : Seminario UniBicocca 22/1/2007 DBMS a Confronto
http://geekplace.org/download/DBMS%20a%20confronto%20-%20NeCoSi%2001.odp

20. 20
PostgreSQL :
cosa c'è ….. in giro …..
● EnterpriseDB è stata fondata nel 2004 col compito di
rompere l'oligopolio in campo DBMS, con una tecnologia
equivalente basata sull' open source. Fu scelto PostgreSQL
perchè testato per più di 20 anni in applicazioni commerciali su
larga scala, per la sua fiorente comunità di sviluppatori, per la
reputazione di essere il più robusto open source database
disponibile.
● tra i Servizi : Oracle Migration Assessment
Fonte : http://www.enterprisedb.com

21. 21
PostgreSQL :
cosa c'è ….. in giro …..
● In Italia, sperando di non far torto a nessuno, scegliamo
2ndquadrant, detentrice del sistema Barman (Backup e Recovery
Manager presentato il 15/10/2012 a Prato in ambito di Business
Continuity).
● il 22/1/2010 Bartolini, Principal Consultant in 2ndquadrant,
fondatore e Presidente di ITPUG - Italian PostgreSQL Users
Group, scriveva a proposito di MySQL e PostgreSQL : è la comunità
che detiene il codice sorgente di PostgreSQL, prodotto a licenza BSD, che quindi
non potrà mai essere detenuto da una singola azienda.
La maggior diffusione di MySQL (nel 2010) sembra dovuta alla appartenenza di
questi all'acronimo LAMP e ad un marketing più efficace rispetto a quello promosso
da una comunità di sviluppatori come può essere quella di PostgreSQL e infine al
fatto che PostgreSQL sia più giovane.

22. 22
La funzionalità di TimeTravel(FlashBack) in PostgreSQL
● vedere stati precedenti di oggetti del database
● ripristinare oggetti allo stato precedente
PostgreSQL :
ma ….. D&T ha fatto qualcosa ?

23. 23
PostgreSQL :
ma ….. D&T ha fatto qualcosa ?
Business Continuity
DownTime
Non
Pianificato
DownTime
Pianificato
Media Failure
Data failure
& Disaster
Human Error
System
Maintenance
Backup / Restore-recover
Cold-Warm
Data Guard – FailOver
FlashBack – repair error
Data Guard –
SwitchOver

24. 24
PostgreSQL :
ma ….. D&T ha fatto qualcosa ?
TimeTravel: A COSA SERVE?
Far tornare ad uno stato precedente
un oggetto, cancellando a ritroso le
transazioni sull'oggetto stesso.

25. 25
PostgreSQL :
ma ….. D&T ha fatto qualcosa ?
TimeTravel: COME FUNZIONA ?
Questa funzionalità ricorda tutte le
modifiche subìte dalle tabelle del DataBase
e possiamo conservarle per un eventuale
RollBack.
Si estraggono tutti gli Statement
inversi relativi ad ogni transazione

26. 26
PostgreSQL :
ma ….. D&T ha fatto qualcosa ?
TimeTravel: CHI LA DOVREBBE USARE ?

In caso la pubblicazione di una nuova applicazione
(RollUp) non vada a buon fine e si decida di rinunciarvi, se
la soluzione fosse quella del Restore/Recovery
costerebbe molto in termini di tempo (RTO = tempo
massimo richiesto per il recovery).

Tornare al punto di partenza ma cercando di eseguire un
“intervento chirurgico” cioè salvaguardando le modifiche
al DataBase che nel frattempo fossero state corrette.

27. 27
PostgreSQL :
ma ….. D&T ha fatto qualcosa ?
TimeTravel: QUANDO USARLA ?
Poco prima della pubblicazione di una nuova
applicazione (RollUp) e mantenerla finchè non si
sia certi che sia andata a buon fine

28. 28
PostgreSQL :
ma ….. D&T ha fatto qualcosa ?
TimeTravel: E' INVASIVA ?
Nessuna modifica al codice applicativo
Richiesto solo l'uso delle attivazioni / disattivazioni
proprie della funzionalità

29. 29
Sede operativa Database & Technology s.r.l.
Largo Promessi Sposi, 4 20142 Milano, Italy
Tel. +39 02 8950.0080
Fax. +39 02 8954.9736
www.databtech.com
www.owb2odiconverter.com
www.remotedba.biz
__________________________________________
______________
Per ulteriori informazioni contattare:
Massimo Sposaro – Responsabile Marketing
mobile: +39 348 6979791
email: massimo.sposaro@databtech.com
Sergio Mior – CEO D&T
mobile: +39 348 3036527
email: sergio.mior@databtech.com