Il database è lento

Il database è lento.

Penso che chiunque lavori nell’IT, almeno una volta nella vita abbia sentito pronunciare queste parole. Se poi come mestiere fa il DBA allora gli sarà capitato molto ma molto spesso. Ogni volta che le sento penso, il database non può andare lento, non si muove, casomai sarà qualche processo/flusso che risponde lentamente, ma di sicuro non il database che va lento. Altrettanto spesso chi pronuncia quelle parole crede che ci sia un parametro FAST=TRUE con il quale risolvere tutti i problemi. Ovviamente quel parametro, per fortuna, non esiste altrimenti lo metterebbe direttamente a TRUE senza chiedere e non esisterebbero i DBA. Detto questo però, rimane il problema vero o percepito che sia, del quale sappiamo poco o niente e ci viene dato pochissimo tempo per risolvere. In fondo per mettere un parametro a TRUE quanto tempo ci volete mettere? Che fare a questo punto?

C’è un’equazione che riassume tutto il lavoro di un database, con la quale si può avere un’idea di massima delle sue performance e che a me è stata sempre utile ad inquadrare i problemi. Quell’equazione è:

ResponseTime = ServiceTime + WaitTime

Il lavoro di un database può essere misurato come la somma dei tempi di risposta di tutti gli statement (select, insert, create etc…) in un dato periodo di tempo. Il numero che si ricava è il ResponseTime che è uguale alla somma dei tempi di servizio (ServiceTime), ovvero il tempo in cui quello statement e’ eseguito in CPU e dei tempi di attesa (WaitTime), cioè il tempo che quello statement ha atteso una specifica risorsa.

Dunque, se il ResponseTime è simile al periodo di tempo preso in esame, ci potrebbe essere un problema di capacità di calcolo. Se è molto piccolo il database o non fa nulla oppure ha attese elevate per qualche causa specifica. Se la percentuale di WaitTime è molto più alta di quella del ServiceTime, c’è un problema di risorse. Se invece il ServiceTime è piu alto del WaitTime e il ResponseTime è minore del periodo di tempo preso in analisi, il database va bene e se c’è un problema è molto specifico o relativo ad una frazione di tempo inferiore a quella presa in esame. Di solito si usano tempi di raccolta dei dati di circa un’ora, ma mi sono capitati casi in cui sono dovuto scendere fino a 5 minuti per trovare il problema. Si potrebbe continuare con esempi all’infinito, ma va oltre lo scopo di questa discussione. Basta mettere la formula su google per trovare infiniti documenti, quando lo farete valutate sempre bene chi scrive, non tutti dovrebbero poterlo fare, metalink e ask tom sono ottimi punti di partenza.

Oracle fornisce questi dati negli AWR report e li riassume all’inizio nei : Top 5 Wait Events

Capire il significato di questi tre numeri, come confrontarli tra loro oppure paragonarli a quelli collezionati con altri database può essere una base solida da cui far partire un’analisi per il tuning del database. Con il passare del tempo con l’esperienza diranno sempre di più e semplificheranno parecchio la vita laddove in qualche progetto dove sarete appena arrivati, senza alcuna informazione, dovrete dare una qualche risposta al cliente. Ricordate però che è solo un punto di partenza. Fare il tuning di un database è difficile richiede tempo e tanta tantissima esperienza. Per il momento si può cominciare da qui.

Autore: Stefano Compieta