Ottimizzazione Database Oracle SedApta per Pedon S.p.A.

Il database analizzato supporta una decision-Making Platform,  che connette dati di domanda, supply e produzione per sincronizzare pianificazione ed esecuzione. Permette la visibilità in tempo reale e i processi integrati dell’intera supply chain. L’ambiente operativo presenta vincoli tecnici che hanno richiesto un approccio analitico:

Vincoli Applicativi e Query Dinamiche

Le moderne Decision-Making Platform per la supply chain, come ad esempio la suite sedApta, utilizzano architetture complesse che generano query SQL dinamiche per garantire massima flessibilità all'utente. Essendo software pacchettizzati, il codice sorgente non può (e non deve) essere alterato per non invalidare gli standard del vendor. Il nostro intervento si è rivelato vincente proprio perché, lavorando chirurgicamente a livello strutturale sul database (indici e statistiche), abbiamo aggirato questo vincolo nativo, ottimizzando le performance senza richiedere alcuna modifica all'applicativo.

Limitazioni della Standard Edition

Trattandosi di un'istanza Oracle Standard Edition, non è stato possibile usufruire di strumenti avanzati presenti nella versione Enterprise. Un esempio su tutti è l'assenza dei Virtual Index: indici "non fisici" che permettono di testare l'efficacia di un'ottimizzazione senza crearli realmente, evitando di intaccare l’operatività del database durante i test. Ogni modifica ha quindi richiesto una validazione empirica estremamente precisa.
 

Durante la fase critica, il sistema ha mostrato picchi di latenza che hanno compromesso le performance generali. L'analisi tramite strumenti di monitoraggio ha evidenziato la prevalenza di due specifici eventi di attesa:

• PGA_memory_operation - Questo evento si manifesta quando una sessione richiede attivamente l'allocazione o il rilascio di blocchi di memoria nella Process Global Area (PGA). Nel caso di questa istanza, tale attesa indicava che le query stavano eseguendo operazioni intensive  che richiedevano continui ridimensionamenti della memoria di processo, saturando le risorse disponibili.
• resmgr: cpu quantum - Questo evento indica l'intervento del Database Resource Manager (DBRM). La sessione viene messa in attesa poiché ha consumato la sua quota temporale di CPU (quantum) definita dal piano di gestione delle risorse. È un segnale che il carico di lavoro ha superato le soglie impostate, portando il database a "frenare" determinati processi per preservare la stabilità complessiva.

L'intervento di ottimizzazione è stato strutturato attorno a tre obiettivi cardine, necessari per garantire la continuità del business:

• Ripristino delle performance per riportare i tempi di risposta delle query ai livelli ottimali precedenti alla crisi, eliminando i ritardi percepiti dagli utenti finali nelle operazioni di magazzino.
• Ottimizzazione del consumo di risorse riducendo il carico computazionale (CPU) e l'occupazione di memoria, minimizzando gli interventi limitanti del Resource Manager e prevenendo la saturazione del server.
• Scalabilità e stabilità. In questo caso si tratta di configurare il database affinché possa gestire l'incremento fisiologico del volume dei dati generato dalla suite applicativa, evitando che la crescita delle tabelle porti a un degrado esponenziale dei tempi di esecuzione.

Rispettando i vincoli architetturali della suite sedApta e l'inopportunità di alterare la sintassi delle query dinamiche generate dall'applicativo (per non invalidare gli standard del vendor), la nostra azione si è focalizzata su un'ottimizzazione chirurgica, lato database, dei percorsi di accesso ai dati.

• Analisi dei Piani di Esecuzione - Attraverso lo studio dei piani di esecuzione delle query, sono state individuate numerose query non performanti che, ad esempio, leggevano tutti i blocchi di una tabella, causando un elevato numero di letture logiche e fisiche.
• Implementazione di Indici Strategici - Sono stati introdotti indici mirati. Questo approccio permette al database di accedere direttamente ai record necessari, riducendo drasticamente il costo del piano di esecuzione e l'I/O richiesto.
• Gestione Manuale delle Statistiche - L'ottimizzatore Cost-Based (CBO) di Oracle dipende dalla qualità delle statistiche. Dopo la creazione degli indici, è stato eseguito un ricalcolo manuale delle statistiche sulle tabelle interessate per assicurarsi che il CBO avesse una visione aggiornata della cardinalità e della distribuzione dei dati, permettendogli di scegliere il percorso di esecuzione più rapido.

I risultati

L'intervento ha prodotto benefici immediati, misurabili e visibili nei log di monitoraggio dell'infrastruttura, scongiurando la necessità di costosi upgrade hardware:

• Abbattimento del 99% dei tempi di attesa (Query 1, 2 e 3) - Le interrogazioni identificate come critiche, visibili nei grafici sottostanti, hanno registrato un calo drastico dei Top Waits. Operazioni che in fase di picco accumulavano fino a 5 ore di attesa aggregata, causando blocchi operativi, sono tornate a essere eseguite in tempi millesimali.
• Riduzione del 70% del carico di sistema globale (Analisi Comparativa) - Confrontando le metriche correnti con quelle storiche, il carico complessivo giornaliero del database è sceso da quasi 35 ore di attesa a una baseline fisiologica e stabile di circa 8-10 ore.
• Risoluzione colli di bottiglia - Si osserva un azzeramento netto e definitivo delle attese critiche legate alla saturazione della memoria (PGA_memory_operation) e della CPU (resmgr: cpu quantum)

• Oracle Database (Standard Edition): il motore di database relazionale al centro dell'intervento di ottimizzazione logica e prestazionale.
• sedApta Suite: La Decision-Making Platform per la gestione integrata della supply chain (demand, supply e produzione) supportata dal database.
• Oracle Cost-Based Optimizer (CBO): il componente core di Oracle su cui si è agito ricalcolando manualmente le statistiche di cardinalità e distribuzione per forzare i percorsi di esecuzione più rapidi.
• Strumenti di Monitoraggio e Analisi Log: utilizzati per tracciare i Wait Events del database, estrarre i grafici di latenza e isolare le query dinamiche responsabili dei blocchi operativi.
• Database Resource Manager (DBRM): il gestore delle risorse di Oracle, monitorato per evitare che il superamento delle quote temporali di CPU mettesse in attesa le sessioni critiche.

Raccomandazioni finali

Nell'operatività quotidiana, i dipartimenti IT sono sempre più assorbiti nel soddisfare le richieste del business, gestire l’evoluzione di applicativi complessi ed ottimizzare i processi logistici. In questo scenario, la manutenzione profonda del database e la cura di dettagli tecnici come la gestione dei piani di esecuzione o l’analisi dei wait events rischia di essere relegata a un ruolo secondario. Tuttavia, la corretta gestione di questi elementi è il fattore fondamentale che determina le prestazioni, la stabilità e la longevità di qualsiasi sistema software critico. Di fatto, le performance dell'infrastruttura sono il vero ago della bilancia: agli occhi degli utenti e dell'azienda, un sistema lento viene inevitabilmente percepito come un progetto fallito, mentre un database reattivo decreta il successo dell'intero investimento software

Trascurare l'ottimizzazione o ignorare i segnali di degrado delle query può innescare infatti una catena di problemi latenti. Questi si manifestano nel tempo sotto forma di rallentamenti sistemici e colli di bottiglia, costringendo a interventi correttivi urgenti per evitare il blocco delle movimentazioni di magazzino. Inoltre, spesso, non riuscendo a identificare la vera radice del problema, si giunge alla conclusione errata di dover aumentare le risorse hardware del server. Questo approccio non solo gonfia inutilmente i costi, ma nasconde l'inefficienza logica di fondo senza risolverla alla radice.

Una visione miope, che non monitora costantemente l’interazione tra i carichi di lavoro applicativi e l’infrastruttura Oracle, può avere conseguenze gravi. L’accumulo di attese critiche e l’intervento forzato del Resource Manager possono infatti causare fermi improvvisi dell'intero sistema, bloccando l'operatività logistica e generando danni economici e di reputazione immediati.

L’ottimizzazione del database non è quindi un semplice esercizio tecnico di "tuning", ma una decisione strategica con un impatto diretto sull'efficienza operativa e sui costi. Una progettazione attenta, che preveda il monitoraggio proattivo degli indici e il ricalcolo costante delle statistiche, è essenziale per garantire che le risorse siano utilizzate al meglio, sia in infrastrutture on-premise che in cloud, assicurando che il cuore tecnologico dell'azienda rimanga performante e affidabile nel lungo periodo.