Il tempo è un fattore importante perché le persone percepiscono le "performance" in termini di tempo e throughput. Per questo motivo, se la nostra analisi sulle prestazioni è di tipo quantitativo e basata sul "time model", possiamo sviluppare, almeno in parte, un collegamento tra ciò che l'utente osserva e la nostra analisi sulle performance.
Ma andiamo con ordine.
Quando una sessione lavora, delle due l'una: o consuma CPU oppure aspetta per consumarla. Per questo motivo ci sono due principali componenti che compongono il "database time": il tempo di CPU utilizzato (anche detto "CPU time") ed il tempo di attesa di tipo "non Idle" ("non-idle wait time").
Ho già parlato del tempo di attesa. Per maggiori informazioni leggi i precedenti post "Wait Event: Introduzione".
I dettagli di "CPU time" sono collezionati direttamente dal sistema operativo ed esportati attraverso le viste del dizionario dati V$[SYS|SES]_TIME_MODEL, mentre i "wait time" sono basati su "misure" (in inglese "instrumentetion"). In pratica gli sviluppatori Oracle hanno inserito del codice aggiuntivo per collezionare quanto tempo impiega uno step di "non-CPU".
E' a partire dalla versione 10g che abbiamo a disposizione questo nuovo approccio alle analisi prestazionali. Non che prima non fosse possibile, ma da questa release, Oracle ha messo a disposizione un vero e proprio framework construito direttamente nel kernel dell'RDBMS.
Dalla versione 10g l'approccio all'analisi prestazionale è possibile da due punti di vista: da un lato è basato sul tempo dall'altro sul campionamento. In successivi post vedremo quali differenze ci sono tra i due metodi. Ma soprattutto vedremo come in realtà il limite del secondo (il campionamento) collassa sul primo (il tempo).
Nessun commento:
Posta un commento