Il Contesto
Il DB2 di AS400 (IBM) è un database relazionale utilizzato frequentemente da molte aziende della GDO e da imprese manifatturiere di grandi dimensioni.
L'esperienza descritta riguarda un cliente del settore GDO che, da diversi anni, riscontrava un problema prestazionale su un flusso ETL di ODI (Oracle Data Integration) relativo alla gestione della contabilità.
Il Problema prestazionale ETL tra AS400 e Oracle
In questa procedura, schedulata giornalmente, esisteva un mapping che si occupava di inserire in una tabella Oracle i record presenti in un file fisico di DB2 (l'equivalente di una tabella dei database relazionali tradizionali). Prima dell'intervento, questa operazione richiedeva diverse ore per completarsi, nonostante le dimensioni non fossero particolarmente significative (1.800.000 record con 76 campi di tipo CHAR, DECIMAL e DATE).
Come soluzione temporanea, circa 8 anni prima il mapping era stato suddiviso in 5 "sotto-mapping" che, agendo in parallelo e utilizzando filtri differenti, caricavano ciascuno la propria parte dei record dal file AS400 nella tabella Oracle. Questi 5 mapping impiegavano ogni mattina circa 120 minuti per completarsi.
Gli Obiettivi
Il cliente ha richiesto a Miriade di ridurre ulteriormente i tempi di esecuzione del flusso, poiché il Controllo di Gestione necessitava di utilizzare i dati già nella prima parte della giornata lavorativa. L'obiettivo era quindi migliorare significativamente le prestazioni del processo di caricamento dati, riducendo il tempo necessario per l'elaborazione completa.
La Soluzione
L'analisi si è concentrata sui 5 mapping seguendo diversi approcci complementari che vengono di seguito elencati.
- Modifica dei Knowledge Modules dei mapping (componenti centrali dell'architettura di ODI che definiscono le modalità di esecuzione delle operazioni di integrazione dei dati).
- Esecuzione di test di consistenza e verifica dell'integrità della tabella target in Oracle.
- Esecuzione di test di consistenza e verifica dell'integrità della tabella source in AS400.
- Aggiunta di indici nel file sorgente di AS400.
- Analisi di possibili problemi di rete tra le tecnologie coinvolte (AS400, Oracle e ODI).
- Esecuzione di un'analisi accurata della qualità dei dati.
Mentre i primi cinque approcci non hanno prodotto risultati soddisfacenti, dal sesto, eseguendo query mirate sul file sorgente, è emerso che, tra i quattro campi di tipo data, tre risultavano completamente valorizzati a NULL.
Un'analisi più approfondita, utilizzando una funzione di conversione in stringa, ha rivelato che i valori apparentemente nulli erano in realtà impostati a '0001-01-01'.
È stato quindi verificato il formato dell'anno dei campi data del file, scoprendo che era impostato a 2 cifre. Secondo la documentazione IBM, l'intervallo di date predefinito e valido per i formati di data a 2 cifre è compreso tra il 1° gennaio 1940 e il 31 dicembre 2039: il valore '0001-01-01' produceva quindi errori invisibili sia a livello applicativo sia utilizzando un client SQL come DBeaver, causando evidenti rallentamenti nella lettura dei record nel file AS400.
La soluzione è stata modificare i 5 mapping di ODI per leggere i campi di tipo DATA utilizzando una condizione per cui, in caso di valore pari a '0001-01-01', questo venisse convertito nella data massima supportata da AS400 ('2039-12-31'). È importante notare che, nel caso specifico, i campi di tipo DATA non venivano utilizzati dall'applicazione.
I RIsultati
Questo semplice accorgimento ha permesso di migliorare drasticamente i tempi di inserimento dei record nella tabella Oracle, passando da circa 120 minuti a soli 50 secondi, con evidente soddisfazione del cliente.
La stessa soluzione è stata successivamente applicata a un altro flusso, questa volta in ambito commerciale, non schedulato giornalmente ma attivato "a chiamata" e soggetto al medesimo problema. Anche in questo caso, si trattava di un mapping che leggeva i record da un file AS400 e li scriveva in una tabella Oracle.
I tempi di completamento del flusso che, a seconda del numero di record da inserire, prima dell'intervento erano compresi tra le 3 e le 8 ore, sono diminuiti dopo l'intervento a un intervallo tra i 30 e i 120 secondi.
Le Raccomandazioni Conclusive
Questa esperienza dimostra che, in presenza di criticità prestazionali nell'uso dei dati, un'analisi approfondita della loro qualità può rivelarsi determinante nel migliorare l'efficienza complessiva dei processi. Si raccomanda quindi di:
- eseguire un'analisi preventiva della qualità dei dati prima di implementare soluzioni complesse;
- verificare sempre i formati di data e i valori anomali nei campi critici;
- controllare la compatibilità tra i formati di dati tra sistemi diversi (in questo caso AS400 e Oracle);
- considerare l'impatto dei valori di default o non validi sulle prestazioni del sistema;
- documentare adeguatamente le soluzioni applicate per facilitare la manutenzione futura.
Se gestisci database Oracle e l'articolo ti è stato utile, potrebbe interessarti anche l'articolo Incident Oracle. Blocco applicativo causato da query inefficiente - Analisi e soluzioni.
Ti è piaciuto quanto hai letto? Iscriviti a MISPECIAL, la nostra newsletter, per ricevere altri interessanti contenuti.
Iscriviti a MISPECIAL
