Qui la versione Inglese
DB Time (2 di 3)
DB Time (3 di 3)
Quando abbiamo a che fare con il “tuning“ dobbiamo sempre fare i conti con il tempo. L’utilizzatore finale di un database percepisce ogni tipo di problema sotto forma di tempo di risposta. Il tempo è ciò che mette in relazione l'esperienza utente con le prestazioni del database.
DB Time (2 di 3)
DB Time (3 di 3)
Quando abbiamo a che fare con il “tuning“ dobbiamo sempre fare i conti con il tempo. L’utilizzatore finale di un database percepisce ogni tipo di problema sotto forma di tempo di risposta. Il tempo è ciò che mette in relazione l'esperienza utente con le prestazioni del database.
Nella ormai datata versione 10g, Oracle introdusse ciò chiamò “Intelligent Infrastructure”. Lo scopo di tale infrastruttura è triplice:
- self-monitor
- self-diagnostic
- self-tuning
- self-monitor
- self-diagnostic
- self-tuning
Questo avveniva nel 2004.
In questo documento è nei prossimi, parleremo di 2 strumenti che abbiamo a disposizione
- DB Time
- ASH
- DB Time
- ASH
DB Time
È definito come la “somma del tempo speso all’interno del database nel processare una richiesta utente”.
È una grandezza misurata in microsecondi e la possiamo ottenere interrogando il dizionario dati. Le viste che espongono le informazioni sono:
- V$SYS_TIME_MODEL
- V$SESS_TIME_MODEL
Quando un processo non può consumare CPU, è costretto ad aspettare per poterla nuovamente impegnarla. Noi conosciamo questa attesa, come “wait event”. Detto in altre parole, quanto un processo non può utilizzare una CPU, ci avvisa dicendo che aspetterà ed il motivo dell’attesa è proprio il “wait event”.
Ma non sempre le attese hanno un impatto sulle prestazioni. In tal caso diciamo che gli eventi di attesa sono di tipo “Idle”. Quando invece l’evento di attesa influenza la risposta di uno statement diciamo che è di tipo “Non-Idle”.
Ma non sempre le attese hanno un impatto sulle prestazioni. In tal caso diciamo che gli eventi di attesa sono di tipo “Idle”. Quando invece l’evento di attesa influenza la risposta di uno statement diciamo che è di tipo “Non-Idle”.
Un processo attivo (che lavora) quindi o consuma CPU, oppure aspetta su un evento di tipo Non-Idle.
Tutto questo può essere espresso attraverso un’espressione matematica, nel seguente modo:
DB Time = CPU Time + Non Idle Wait Time
Quasi sempre il “Non-Idle” è sottinteso, così l’espressione diventa
DB Time = CPU Time + Wait Time
Volendo essere precisi, la relazione corretta è
DB Time = CPU Time + Wait Time + gap
Il motivo è che quando le CPU di un sistema sono molto impegnate, aumenta il “CPU Queue Time”, ovvero il tempo di attesa che i processi impiegano prima di utilizzare una CPU. Oracle chiama questa particolare attesa, “CPU Wait Time”, che ovviamente è una scelta piuttosto infelice come nome.
Maggiori dettagli su questa particolare tematica sono ottenibili nei link presenti nei riferimenti sotto indicati. In ogni caso, in questo articolo, siamo interessati al caso più comune:
DB Time = CPU Time + Wait Time
Nessun commento:
Posta un commento