MySQL e DB2, la giovane promessa e la consolidata certezza

Dalle applicazioni web al mondo dei mainframe bancari e alle loro gigantesche moli di dati. MySQL Italia intervista Salvatore Mancini, DBA DB2 per Cedacri spa, cercando di capire qual è attualmente il ruolo di MySQL nel mondo bancario e quali sono le prospettive per il futuro.

 
1.Ciao Salvatore, puoi presentarti a MySQL Italia?
Ciao a tutti; mi chiamo Salvatore Mancini, ho 48 anni, e bazzico il mondo dell’informatica, per lavoro,   dal lontano 1985, sebbene durante gli studi universitari per hobby e necessità di studio avevo già approcciato questo mondo in termini pionieristici per l’Italia; insomma sono uno della generazione dei “Commodore” e dei “VIC 20”, nonché delle prime calcolatrici programmabili, le “Texas” con la striscia magnetica per intenderci, e delle schede perforate a codice Hollerith. (il fondatore dell’IBM).
Sono laureato in Fisica ed ho due figli che vivono Internet con lo stesso entusiasmo con cui approcciavo ai primi MAINFRAME IBM. Si, perché la mia formazione lavorativa è cominciata su questi mostri sacri, che molti ritengono dinosauri e chiamano “BIG IRON”, ma che ancora oggi non hanno rivali in termini di sicurezza ed affidabilità e resistono al tempo, tanto da aprirsi al mondo dipartimentale e di internet supportando “WEB Services” e infrastrutture OPEN.
Non ne tesso le lodi, ma giustifico la mia esistenza in questo vecchio mondo di giovani :-).

2.Di cosa ti occupi oggi ?
Lavoro per “CEDACRI”, il più grande outsourcer informatico italiano per gli ambiti bancari, e mi occupo essenzialmente di database, sono un DBA in ambiente DB2 fo z/OS, cioè mi occupo di database DB2 che girano sui più recenti MAINFRAME IBM… tanto per restare in tema.
Le mie competenze sono orientate al tuning ad alle performances dei sistemi e delle applicazioni, nonché al supporto agli applicativi ed all’erogazione dei servizi.
In questo solco di competenze mi sento un eterno studente e cerco di mantenermi sempre aggiornato sulle evoluzioni dei sistemi e soprattutto  rivolgo una particolare attenzione all’apertura verso mondi OPEN, per cogliere novità e interrelazioni. 

3.Gli istituti bancari conservano nei propri dati un patrimonio inestimabile, quali sono le tecniche e gli accorgimenti che guidano il lavoro dei DBA in questi universi sconfinati?
Quello che deve guidare il lavoro del DBA è soprattutto un approccio mentale, in particolare la consapevolezza che qualsiasi sistema di protezione dei dati venga messo in opera sarà sempre un sistema vulnerabile intrinsecamente per cui le migliore protezione è un’attenzione regolare e diligente.
Detto questo esistono tecnologie e metodologie che aiutano nel realizzare un sistema affidabile di protezione dei dati.
Innanzitutto in ambiente mainframe (z/OS) esistono dei software specializzati che permettono di limitare l’accesso a dati di tutti i tipi da parte degli utenti in modo granulare e specifico. Questi prodotti (RACF, TSS, altri)  permettono di definire dei profili utente che per il DB2 possono addirittura arrivare a inibire gli accessi ai singoli campi di una tabella. L’uso di prodotti specializzati (sicurezza esterna) sgrava il DB2 da operazioni pesanti e tutto sommato inutili dal punto di vista di un DBMS. Il Db2 ha anche una sicurezza interna da usarsi in alternativa ma che ritengo sia da abbandonare rapidamente.
Altra tipologia di protezione è invece legata alla difesa da errori o corruzione di dati da parte di applicazioni o accessi autorizzati; allo scopo vanno realizzate e pianificate delle procedure di salvataggio e riorganizzazione periodica dei dati per il ripristino nel caso di problematiche di corruzione logica o fisica.
Il Db2 ha tutta una serie di utility molto potenti che permettono di implementare queste procedure; molte di queste utility possono lavorare nella cosiddetta modalità ‘on-line” cioè lasciando i dati in RW, disponibili alle applicazioni, e questo è fondamentale per le banche che offrono servizi H24.
Ancora si possono utilizzare delle tecniche di crittografia dei dati, con opportuni dispositivi o software, che sono trasparenti alle applicazioni, ma non a letture fisiche dirette sugli archivi memorizzati.
Il panorama è veramente vasto, ma niente può sostituire la sensibilità del DBA, che deve sempre vigilare sulla corretta funzionalità dell’impalcatura tecnologica perché sia sempre adeguata alle esigenza delle aziende fruitori dei servizi erogati. 

4.MySQL e le Banche nel panorama Italiano, presente e futuro secondo te?
Bah… al presente non ho notizie di un utilizzo di MySQL in organizzazioni bancarie, se non per piccoli siti web accessori e sempre non dispositivi… ma credo che se ve ne fossero di importanti le avreste già ben pubblicizzate…
Anche per il futuro credo che tutto dipenda da Oracle… nel senso che dopo l’acquisizione di MySQL bisogna capire cosa intende fare, e cioè se intende spingerlo come la versione OPEN di Oracle in sostituzione delle sue versioni FREE o farlo morire lentamente. Nel primo caso tenderà ad irrobustirlo di tutta la parte di utility e di supporto; nel secondo caso creerà dei tool di migrazione facile alle sue versioni FREE. Non saprei dire…

5.Oggi MySQL è Oracle, ciò potrebbe essere un vantaggio per MySQL nei confronti del mercato Bancario ?
Potrebbe essere un vantaggio perché Oracle è già inserita nel mercato bancario, ma, come dicevo, tutto dipenderà da che direzione prenderà lo sviluppo di MySQL in mano ad Oracle.

6.DB2 e MySQL, perchè le banche preferiscono ancora IBM, solo una questione di supporto e know-how?
No, direi proprio di no. Il fatto è che il DB2 per z/OS è la massima espressione del progresso informatico nelle tecnologie dei DB relazionali e si vede nei fatti.  Le prestazioni e i livelli di sicurezza e di affidabilità raggiunti sono insuperati a detta della stessa Oracle e di tutti i guru del settore. 

7.Come si effettua una migrazione da un ambiente DB2 a MySQL, quali sono i problemi e l'esigenze da affrontare?
Non è una migrazione che vedo plausibile e non mi è mai capitato di affrontarla, ma immagino che le problematiche siano le stesse che si incontrano nel passare da un ambiente DB2 per z/OS ad uno tipo Unix/Oracle.
Innanzitutto c’è da considerare il fattore conversione tra mondi ASCII e mondi IBM EBCDIC che hanno codifiche differenti dei caratteri (CCSID); esistono tool automatici di conversione che vanno presi…  con le molle.
Soprattutto vanno analizzati molti altri fattori di compatibilità tra differenti DBMS:
a)Compatibilità dei differenti tipi di dati (VARCHAR, BLOB, CLOB, etc.)
b)Compatibilità dei differenti tipi di oggetti (Trigger, Sequences, Stored procedure, etc)
c)Compatibilità tra i formati di upload e reload
d)Compatibilità tra funzionalità specifiche
E poi non dimentichiamo che migrare quasi mai significa solo migrare dati, quasi sempre significa migrare applicazioni e qui si apre tutto un altro mondo che va analizzato specificatamente, perché di solito le applicazioni dei mondi IBM (soprattutto quelle bancarie) non sono portabili e se si va in un’ottica di emulazione, la migrazione diventa… un bagno di sangue. L’emulazione delle funzioni è il principale motivo di fallimento di progetti di downsizing o rehosting.

8.Il sapere tecnico e il saper fare, è una questione di esperienza o di competenze?
Banalmente direi entrambe. Però quello che ci tengo a ribadire è che bisogna acquisire un ambito mentale orientato ai fruitori dei nostri servizi. Mai bisogna dimenticare che quello che si fa’ ha un impatto immediato o futuro su chi utilizza il prodotto del nostro lavoro, anche quando esso è trasparente o invisibile a tutti. Mai bisogna pensare di avere sotto controllo ogni cosa, Insomma non bisogna mai sottovalutare il lavoro di nessuno, approcciando sempre ogni attività come se fosse la prima volta e prevedendo sempre la possibilità di un ritorno indietro perché l’errore è dietro l’angolo. Inoltre bisogna mantenere l’approccio del ricercatore, sentirsi sempre un eterno studente e mai presumere di sapere, ma sapere di presumere. In questo modo non si darà mai per scontato niente.
9.Cosa pensi della nostra iniziativa MySQL Italia?
E’  una bella iniziativa, stringete i denti e andate avanti, cercando di partecipare attivamente alla community ufficiale, che è da sempre l'arma in più di MySQL, in Italia non sempre si trovano riferimenti tecnici rigorosi precisi e puntuali, quindi lavoro da fare ne avete.. ma non fermatevi.. in bocca al lupo!
Salvatore Mancini
Intervista a cura di algweb

Condividi su:

Esprimi un voto:

• Current rating: 5.0/5
• 1
• 2
• 3
• 4
• 5

Argomenti chiave:

• db2
• banche
• mainframe
• dba

re-verse
scrive: circa un anno fa

Mi trovo d'accordo su tutto... in particolare sui progetti di downsizing e rehosting, uno dei quali mi ha visto coinvolto alcuni anni fa' ... e che ovviamente non ha avuto nessun seguito. Devo dire che, per esperienza personale, lavorare in ambienti mainframe è tutta un'altra storia :) Grazie Salvatore per il prezioso contributo :)

g2d
scrive: circa un anno fa

Ciao Salvatore, Grazie a nome di tutto lo staff per aver condiviso la tua esperienza. Noi siamo nati con il web ... e piu' in generale con i sistemi dipartimentali ... lavorare con i Mainframe ancora oggi riserva tutto il fascino di cui parlavi nonostante la rigidita e la ben nota poca flessibilita'. Grazie per questo tuffo in questo mondo e per i chiarimenti che ci hai dato. Grazie ancora per il tuo contributio e torna a trovarci

Sante Caserio
scrive: circa un anno fa

E' sempre interessante leggere i pensieri di chi ha iniziato a lavorare nell'informatica (ma forse lo stesso discorso è valido in molti altri ambiti) negli anni 80. Grazie a Mancini e a MySQL Italia! Per quanto riguarda la migrazione, vorrei dire che se la logica aziendale si trova nelle stored procedure, nei trigger e nei vincoli di integrità, purtroppo migrando a MySQL questa logica dovrà essere portata in buona parte alle applicazioni. Però per quanto riguarda la migrazione dei dati in sè, segnalo questo strumento: http://www-01.ibm.com/support/docview.wss?uid=nas1fa4df410a5fc784f8625757c0079e847 http://dev.mysql.com/doc/refman/5.5/en/se-db2.html Saluti.