Sei sulla pagina 1di 333

Cumulative Statistics :sono conteggi di informazioni sul timing per una

varieta’0 di eventi che accadono nell’istanza de DB.Alcune sono importanti


come la buffer busy wait,altre hanno impatti minimi come ad esempio
l’index block split.Le statistiche in Oracle 11g sono correlate dall’uso di un
TIME MODEL.LeTIME MODEL sono basate sulla percentuale di DB TIME
prendendo loro come una base per le comparazioni.

METRIC STATISTICS: Sono conteggi di statistiche per una singola unita’.

SAMPLE STATISTICS sono parte di ACTIVE SESSION HISTORY sono potenti


tools che sono inclusi in DIAGNOSTICS PACK che permettono di guardare
indietro nel tempo.Si possono guardare le statistiche gathered nel passato
in varie dimensioni
Le statistiche del DB sono memorizzate in varie tabelle e view.Alcune statistiche sono
memorizzate in tabelle permanenti come le statistiche raccolte dal DBMS_STATS per l’utilizzo
dell’ottimizzatore.Molte statistiche invece vengono memorizzate in tabelle e viste dinamiche
che sono memory based.Queste statistiche non sono salvate quando l’istanza è shutdown.
L’ALERT LOG invece sono una lista cronologica di eventi del database e di messaggi informativi.

Gli Alert Log possono dare importanti informazioni circa le operazioni del DB esulle aree che
devono esser ottimizzate e informazioni relative ai report del tuning.

I processi Utente e di Background invece creano dei TRACE FILE quando si verificano
determinati eventi e anche loro possono dare informazioni su problemi di performance ma sono
piu’ utilizzati per ricercare gli errori e informazioni di debugging.

STATSPACK è un set di procedure e script presenti in tutte le edizioni di ORACLE.Con essi si


possono collezionare snapshots di statistiche e compararli tra loro per creare baseline.

Il DIAGNOSTICS PACK è una licenza separata richiesta per l’utilizzo di AWR(AUTOMATIC


WORKLOAD REPOSITORY) e di tools basati sull’AWR.Esso colleziona statistiche e soluzioni
raccomandate.Il Tuning Pack è quindi una licenza separata.Il tuning Pack richiede il Diagnostics
Pack.
Il report sui TOP EVENTS che consumano piu’ risorse è un ottimo strumento per iniziare il
Tuning.In questo esempio la free buffer cache e la buffer busy waits stanno consumando
piu’ del 75% del tempo speso indicando un problema a livello di BUFFER CACHE.La lista
dei top events puo’ essere ottenuta tramite i report sia di AWR che di STATSPACK.
Una richiesta al DB è composta da due distinti segmanti:
1.Un WAIT TIME (DB WAIT TIME) e un SERVICES WAIT (CPU WAIT TIME).
Il WAIT TIME è la somma di tutti i waits per le varie risorse di una istanza.Il CPU TIME
è la somma del tempo che viene impiegato dal lavoro per una richiesta.Il tuning consiste
nell’eliminazione del DB WAIT e nella riduzione del CPU TIME.Un cattivo sistema puo’ avere
delle grandi CPU TIME che influenzano anche altri tempi.
Quando si fa il tuning del sistema è importante comparare la CPU TIME con la WAIT TIME del
sistema.Comparando i tempi si puo determinare quanto e dove il tempo viene speso.Un sistema
dove il CPU TIME è prevalente richiede mebo tempo di tuning rispetto ad un sistema dove
prevale un DB Time,tuttavia dei grandi CPU TIME possono essere causati da statments SQL
inefficienti.Quando ad incrementare è il DB WAIT TIME è facile intuire che aggiungendo piu’
memoria (CPU) o altri nodi ad un RAC non migliorera’ le prestazioni.

TIME MODEL
1.Sono un Set di statistiche che danno un overview di dove il tempo viene speso nel DB
2.Tutte le statistiche usano la stessa dimensione :il tempo
3.Le statistiche sono accessibili attraverso
-V$SYS_TIME_MODEL
-V$SESS_TiMe_MODEL
4.Il DB TIME rappresenta il totale del tempo speso nelle chiamate al DB ed è la piu’ imporatante
delle TIME MODEL STATISTICS
5.,L’obbiettivo del Tuning è ridurre il DB TIME
6.Utilizzando il db time si puo raccogliere le performance di ogni entita’ del database

Altre TIME MODEL STATISTICS forniscono informazioni su determinate operazioni come LOGON
OPERATION,HARD E SOFT PARSE,PL/SQL EXECUTION e JAVA EXCUTION.
Report di AWR sulle TIME MODEL STATISTICS:Notare che la somma del % of DB TIME
supera il 100 perche il parse time elapsed non viene considerato come figlio del sql excute
elapsed time,ci sono infatti degli elementi comuni conteggiati in entrambi i parametri.
Alcune V$ view possono mostrare dati prima che un DB sia MOUNTED o OPEN.
La V$FIXED_TABLE mostra la lista completa di tutte le dinamic View
I dati di queste viste sono utilizzati da AWR e STATSPACK per i report
Le viste DICT e la DICT_COLUMNS mostrano invece il nome delle viste
1.Queste viste sono OWNED da SYS
2.Differenti viste sono disponibili a diversi stadi:
-Quando l’istanza viene startata
-Quando l’istanza viene Mounted
-Quando l’istanza è OPEN
3.La READ CONSISTENCY non è garantita per queste viste perche’ i dati sono dinamici

V$BGPROCESS per guardare la lista dei processi in background che sono running puo essere
interrogata anche se il DB è solo MOUTED
V$DATAFILE per guardare lo stato dei data file essa ad esempio non puo essere interrogata se il
DB è solo MOUTED.

Come gia’ detto essendo delle viste Memory Based esse non sopravvivono ad uno shutt down.
Le statistiche registrate prima e dopo di un shutdown non sono comparabili.
Non ci sono sistemi di loocks per queste viste e quindi la consistenza non è garantita per cui
potrebbero vedersi delle anomalia durante la lettura di esse quando ad esempio alcune tabelle
non hanno ancora finito degli update e vengono fatte delle select su di esse.

Il SELECT_CATALOG_ROLE è il ruolo minimo che permette ad un utente di guardare queste viste


SI puo determinare il livello di collezzione delle statistiche settando il valore del parametro
STATISTICS_LEVEL.
Esso puo essere settato:
1.BASIC:Nessun avviso o altre statistiche vengono raccolte.Si puo manualmente settare dei
parametri per le statistiche come TIMED_STATISTICS ed il DB_CACHE_ADVICE.Molte delle
statistiche richieste per le baselinbe non sono collezzionate.Oracle fortementye scoraggio
l’utilizzo di questa impostazione.
2.TIPICAL:E’ IL VALORE DI DEFAULT.I dati vengono collezzionati per i segment-level-
statistics,timed-statistics e tutti gli advisories
3.ALL:Le statistiche vengono collezzionate come quelle del TIPICAL ma in piu’ vengono
collezzionate statistiche di sistema e le statistiche di esecuzioni delle row-source.

Una SELECT sulla V$STATISTICS_LEVEL ci dir’ l’attuale settaggio:


Questi parametri possono essere settati individualmente essi sono:
1.TIMED_STATISTICS:E’ settato a true per collezzionare TIME STATISTICS
2.DB_CACHE_ADVICE:Accetta i seguenti argomenti:
-OFF:Nessuna statistica collezionata e nessuna memoria utilizzata
-READY:Nessuna statistica collezzionata ma viene allocata della memoria,settando
questo parametro a READY prima di settarlo a ON puo’ prevenire errori di memoria
quando vengono collezzionate le statistiche sull’utilizzo della BUFFER CACHE.
-ON :Ler statistiche vengono collezzionate e la memoria viene allocata.Se si setta da
OFF a ON possono verificarsi degli errori se la memoria non è disponibile.
3.TIMED_OS_STATISTICS:Specifica l’intervallo in secondi a cui un istanza ORACLE collezziona le sta
Tistiche di sistema operativo quando una richiesta viene effettuata da un client ad un server o
quando una richiesta viene completata.

Quando il parametro STATISTIc_LEVEL viene settato a livello di sessione con ALTER SESSION le
seguenti statistiche e advisor sono eseguite solo per la sessione local.

Una lista completa di statistiche puo’ essere vista dalla V$STATNAME view.
I WAIT EVENT sono statistiche che sono incrementate da un processo server o da dei thread che
indicano che essi hanno dovuto aspettare la fine di un altro evento prima di poter andare avanti.I
WAIT EVENT possono indicare una serie di sintomi di problemi che potrebbero influenzare kle
performance come dei latch contention,buffer contention e le IO contention.Ricorda che questi
sono solo dei sintomi di problemi ma non sono l’effettiva causa.La lista completa degli WAIT
EVENT puo’ essere vista nella V$EVENT_NAME.
Il server visualizza una serie di calculeted statistics a livello di sistema nella V$SYSTAT.Si possono
interrogare queste viste per cercare dei totali cumulativi senza che l’istanza sia startata.A tutti i
livelli ci sono degli statistics identifier che permettono la JOIN con la tabella V$STATNAME
SYSTEM-LEVEL STATISTICS

Tutte le viste listate includono la colonna NAME,CLASS e VALUE.Le viste a livello di sistema
includono la colonna SERVICE_NAME mentre quelle a livello di sessione includono la colonna
SID (session identifier).Queste colonne permettono la JOIN con la V$SERVICE_NAME e la
V$SESSION.
SERVICE_LEVEL STATISTICS

Queste statistiche sono cumulative da quando l’istanza è stata startata.Esse permettono di


collezzionare le statistiche tramite una CONNECTION SERVICE NAME.Questo è davvero molto
utile per monitorare le performance dell’applicazione.Ogni User che si connette utilizza uno
specifico Service Name dell’applicazione.
Esempio
Ci sono due Service definiti:SYS$BACKGROUND e SYS$USER.Piu’ di 62 servizi addizzionali
possono essere creati basati sul parametro SERVICES_NAME o settati con il package
DBMS_SERVICE.I dati dei servizi sono cumulativi da quando l’istanza viene startata.
L’oracle database server visualizza tutte le service statistics nella V$SERVICE_STAT che puo essere
interrogata senza quando l’istanza è startata.
SESSION RELATED STATISTICS
Sulla vista V$SESSION possono essere visualizzate le informazioni circa la sessione corrente per
ogni utente loggato.Il server visualizza tutte le statistiche delle sessioni nella V$SESSTAT mentre
le statistiche per la sessione corrente sono visualizzate nella V$MYSTAT.
ESEMPIO:
Determina le sessioni che stanno consumando piu’ di 30,000 bytes di PGA MEMORY
SGA STATISTICS
La vista V$SGAINFO fornisce la dimensione corrente della SGA,la granule size e la free memory.
Una summary è presentata nella V$SGA.Mentre tutte le statistiche della memoria sono visualizzat
nella V$SGASTAT.
WAIT EVENTS
1.Una collezzione di wait events fornisce informazioni circa le session che hanno dovuto
aspettare o che devono aspettare per differenti ragioni
2.Questi eventi sono listati nella V$EVENT_NAME che ha le seguenti colonne:
-EVENT#
-NAME
-PARAMETER1
- PARAMETER2
- PARAMETER3
Tutti i WAIT EVENT hanno un nome nella V$EVENT_NAME ed includono:
FREE BUFFER WAIT
LATCH FREE
BUFFER BUSY WAITS
DB FILE SEQUENTIAL READ
DB SCATTERED READ
DB FILE PARALLEL WRITE
UNDO SEGMENT TX SLOT
UNDO SEGMENT EXSTENSION

Ogni evento viene assegnato ad una wait class.Queste assegnazioni sono mostrate nella
V$EVENT_NAME.Ogni evento puo’ avere addizionali paratmetri ritornati con l’evento le colonne
PARAMETER1 fino a PARAMETER3 mostrano questi parametri.

NOTA:Le informazioni sul tempo dei WAIT sono popolate solo se il parametro
TIMED_STATISTICS è settato a TRUE
Un WAIT EVENT puo’ avere fino a tre parametri che sono listati nbelle colonne PARAMETERn

Il BUFFER BUSY WAITS EVENT


Questo evento memorizza il tempo richiesto per trovare un buffer disponibile.Questo WAIT
indica che ci sono multipli processi che stanno tentando di accedere concorrenzialmente ad
alcuni buffer nella buffer cache .
BUFFER BUSY WAITS EVENT
Questo evento è accompagnato da tre parametri:
1.FILE# e BLOCK# che identificano il block number nel datafile che è identificato dal file number pe
il blocco per cui il server ha bisogno di attendere
2.ID:Il “buffer busy wait” è chiamato in differenti posti nella sessione.Ogni posto nel KERNEL punta
ad una differente ragione.L’ID riferisce al posto nella sessione chiamante l’evento.

LOG FILE SWITCH(CECK POINT INCOMPLETE) EVENT


Memorizza il WAIT per un log switch poiche una session non puo’ scrivere il wrap nel prossimo log
Il wrapping (la scrfittura di informazioni ausiliari di cornice) non possono essere eseguite poiche’
Il ceckpoint per quekl log non è stato completato.Questo evento non ha parametri.
Tutti i possibili differenti WAIT EVENTS sono categorizzati in WAIT CLASSES Ogni evento è
relazionato ad una e solo una classe.Questo abilita l’hight level analisis per quello evento.
Per esempio exclusive Transaction Locks(TX) sono generalmente un problema a livello di
application-level mentre i segment space management (HW) locks sono un CONFIGURATION-
LEVEL issue.
Di seguito le piu’ comuni classi di WIAT EVENTS:
Tutti gli eventi sono catalogati nella V$EVENT_NAME
Le statistiche cumulative degli WIAT EVENTS per tutte le sessioni sono memorizzate nella
V$SYSTEM_EVENT che mostra il WAIT per un particolare evento da quando l’istanza pè stata
startata.
La V$SERVICE_EVENT mostra i wait cumulativi per ogni servizio.
La V$SESSION_EVENT mostra i wait cumulativi per ogni session.
Molte delle statistiche sui i WAIT EVENT sono le stesse per ogni vista,le differenze sono mostrate
di seguito:
La V$SYSTEM_EVENT include un breakout delle statistiche per i processi FOREGROUND.
La V$SERVICE_EVENT include i servizi mentre la V$SESSION_EVENT include gli SID (SESSION
IDENTIFIER).

NOTA: LA V$SERVICE_EVENT non include le wait classes ma esse possono essere facilmente
otenutre andando in joinb con la V&EVENT_NAME.
Quando si ottimizza bisogna conoscere se un processo ha aspettato per altre risorse.
La V$SESSION_EVENT mostra il tempo totale di WAIT per un particolare evento da quando
l’istanza è startata.
La V$SERVICE_WAIT_CLASS aggrega il wait con la classe di appertenenza

La V$SESSION_WAIT lista le risorse o gli eventi per cui le sessioni attive stanno aspettando,la
V$SESSION quindi include le informazioni di WAIT.Quando si otimizza bisogna conoscere quale
processo sta aspettando cosa.La struttura della V$SESSION_WAIT rende questo facile da ricercare
In tempo reale per guardare chi aspetta cosa e chi.
SID è il session identifier
SEQ#:E la sequence number per identificare il wait
EVENT:La risorsa o l’evento che aspetta per.Se il WAIT TIME è maggiore di 0 allora questo è
l’ultimo evento che causa un session wait.
1.GENERAL : Nella pagina precedente la voce GENERAL indica una vista veloce dello stato del
DB e fornisce informazioni basilari circa il database.Lo stato puo essere UP,DOWN,UNDER
BLACKOUT,UNMONITORED o UNKNOWN.Da questa sessione si puo’ accedere ad altre pagine
per maggiori dettagli come la PROPERTIES PAGE,HOST HOME page LISTNER HOME page e ASM
HOME page.

2.HOST CPU :Mostra un diagramma a barre relativo all’utilizzo di CPU.Due valori appaiono nel
diagramma a barre.Il colore scuro rsappresenta quanta CPU l’istanza sta consumando,mentre il
colore chiaro rappresenta tutti gli altri priocessin che consumano memoria.

3.Active Session : Il diagramma mostra l’ammontare di tempo che l’istanza consuma usando la
CPU e le I/O e l’ammontare di tempo che esso consuma nei colli di bottiglia.Il diagramma mostra
l’ultimo valore piuttosto che il valore storico.Le tre categorie sono sempre CPU.USER I/O,e WAIT.
La categoria WAIT mostra tutti i WAIT CLASSES escludendo le USER I/O

4.SQL RESPONCE TIME :Questa categoria mostra la corrente risposta degli SQL confrontati con la
risposta delle BASELINE.Se ilo tempo della base line ed il tempo della risposta sono uguali allora
il sistema è normalmente running,se il tempo di risposta è maggiore della base line allora uno o
piu’ statment SQL stanno girando piu’ lentamente del previsto .

5.DIAGNOSTIC SUMMARY:Visualizza informazioni circa le violazioni di policy el’ultimo


Automatic DATABASE DIAGNOSTIC MONITOR (ADDM).Il Link conduce alla pagina del ADDM che
fornisce informazioni sulle performance.
4.SPACE SUMMARY Per identificare dei problemi di spazio e fornisce delle raccomandazioni per
le performance.La grandezza del DB (GB) è derivata dal campo Total size (MB) AD ESEMPIO SE
LA Total Size è 9,000.0 il numero della DB SIZE sara’ 99 (GB).
5.HIGHT AVAILABILIY: Questa categoria visualizza il tempo dell’ultimo backup per i pre ORACLE
10g Database,il piu’ recente backup time e dove oppure no il backup ha avuto successo per gli
oracle 10g version.Se l’ultimo backup fallisce per una versione di oracle 10g il link per LAST
BACVK UP visualizza il risultato del backup,se il backup ha avuto successo si puo fare il drilldown
alla pagina di manage current backups.Cliccando su il link produrra il CONFIGURE RECOVERY
SETTING page.
Ogni database ha un alert_<sid>.log file.Il file è sul server e viene memorizzzato nella directory
specificata nel parametro di inizializzazione DIAGNOSTIC_DEST.Esso è memorizzato in due posti
ed in due formati.L’XML format alert log è posto nella
$DIAGNOSTIC_DEST/rdbms/<db_name>/<istance_name>/trace.Il file ALERT LOG è un log
cronologico di messaggi ed errori inclusi i seguenti:
1.Ogni parametro di inizializzazione avente un setting non di default e utilizzato allo start up
2.Tutti gli errori interni (ORA-600),blocks corruption error(ORA-1578) e deadlock errors (ORA-60)
3.Operazioni amministrative come CREATE,ALTER,DROP DATABASE e TABLESPACE e l’enterprise
Manager o SQL PLUS statments di STARTUP,SHUTDOWN,ARCHIVE LOG e RECOVER.
4.Diverse messaggi e errori relativi alle funzioni di shared server e dispacher process
5.Errori durante l’automatic refresh di materialized view.

L’ENTERPRISE MANAGER monitora gli alert log file e notifica sui errori critici.Si puo quindi
guardaere il log per vedere non-critical error e i messaggi di informazioni.
USER TRACE FILES
1.Il tracing dei Server Process puo essere abilitato o disabilitato a livello
di istanza o di sessione
2.Un User Trace File contiene le statistiche per uno statment SQL
tracciato nella sessione
3.Essi sono creati su un per process server basis.
4.Possono essere creati:
-Eseguendo un BACKUP CONTROL FILE TO TRACE
-Process Errors.
I processi server possonoo generare degli User Trace File su richiesta di
un User o del DBA.
ISTANCE LEVEL TRACING
Dovrebbe essere abilitato solo se necessario perche’ crea un carico di
I/O che rende il sistema molto lento.Questi trace file sono abilitati e
disabilitati da EXEC
DBMS_MONITOR.SESSION_TRACE_ENABLE(8,12,waits=>true,binds=>tru
e) dove 8 e 12 sono ilsistem identifier ed il serial number dell’user
connesso.Tipicamente solo un DBA ha il permesso per abilitare e
Il DBMS_MONITOR package è creato quando il file catproc.sql viene lanciato.Questo script è
localizzato nelle seguenti directory:
AWR è una infrastruttura che fornisce dei servizi ad Oracle DB per collezzionare,mantenere e
utilizzare le statistiche.
Essa consiste di due principali parti:
1.Una IN-MEMORY-STATISTICS COLLECTION che è utilizzata da vari componenti.Le statistiche
sono conservate in memoria per problemi di performance e sono accessibili attraverso le
dinamic views.
2.AWR snapshot che rappresenta la porzione persistente e che è accessibile attraverso le viste
del DATA-DICTIONARY e il DATABASE CONTROL.Esse sono memorizzate in modo permanente per
le seguenti ragioni:
-Le statistiche devono sopravvivere anche se l’istanza crashes.
-Vi è bisogno di mantenere delle versioni storiche delle statistiche per le comparazioni con le
baseline e per certi tipi di analisi
-Memory OverFlow:

La versione MEMORY-STATISTICS viene trasferita al disco da un processo chiamato MMON


(Manegeability Monitor).Con AWR il DB fornisce un modo per collezzionare le statistiche senza
l’ausilio del DBA.
AWR cattura una varieta’ di statistiche ad esempio log switches e process memoty allocated,SQL
statistics come le letture sul discoper gli statments SQL.
I dati dell’ACTIVE SESSION HISTORY (ASH) sono memorizzati prima in memoria per quelle
sessioni che sono attive ed eseguono una chiamata al DB.ASH utilizza l’AUTOMATIC DATABASE
DIAGNOSTIC MONITOR (ADDM) per identificare la causa dei problemi di performance.I report
prodotti da ADDM cioe’ i Segment Advisor ed altri advisor sono memorizzati in AWR per essere
interpellati successivamente.
Come abbiamo detto le statistiche esistono a due livelli:le IN-MEMORY RECENT STATISTICS nelle
V$ view e le PERSISTENT STATISTICS memorizzate sul disco come SNAPSHOT e nelle DBA* view.
Il WorkLoad Repository è una collezzione di statistiche persistenti owned dal ruolo SYS.Esso
risiede nel SYSAUX tablespace ed è uno dei maggiori repository del table space SYSAUX.
Uno snapshot è un set di performance statistics catturate in un certo perieodo.Ogni snapshot è
caratterizzato da un snapshot sequence number id (snap_id) che è univoco nel workload
repository.Di default gli snapshot sono generati ogni 60 minuti, questo tempo puo’ essere
moodificato tramite il parametro INTERVAL ma è sconsigliato aumentare il tempo.In un RAC ogni
snapshot mostra tutti i nodi in un cluster e ha lo stesso snap_id per tutti i nodi.
Si possono fare degli snapshot manuali utilizzando DATABASE CONTROL,essi vengono utilizzati
quando si vogliono catturare le differenze di sistema a due specifici punti che magari non
coincidono con l’automatic schedule.
Utilizzando il DATABASE CONTROL si puo configurare la RETENTION e l’INTERVAL parametersper
catturare gli snapshot.
Si puo controllare l’incremento di historical AWR statistics attraverso settando il perieodo di
RETENTION e l’intervallo degli snapshot.In generale gli snapshot sono rimossi automaticamente
in un ordine cronologico.In un sistema con 10 sessioni attive le collezzioni di AWR hanno
bisogno di 200 MB a 300 MB di spaziose i dati vengono mantenuti per 7 giorni.lo spazio
consumato dipende dal numero di sessioni attive.Uno scrip di sizing utlsyxsz.sql produce un
report per stimare la grandezza del tablespace SYSAUX,il numero di sessioni attive la frequenza
degli snapshot e il tempo di retention,mentre il file awrinfo.sql produce una stima dei vari
occupanti del tablespace SYSAUX.Entrambi gli scrip sono allocati nella
$ORACLE_HOME/rdbms/admin directory.AWR mantiene lo spazio per gli snapshot.
Ogni notte il processo MMON svuota gli snapshot che piu’ vecchi rispetto al perieodo di
retrenzione retention se AWR vede che la tables0pace SYSAUX è piena automaticamente
riutilizza lo spaziooccupato dai vecchi snapshot cancellando loro ed un alert viene mandato al
DBA per informare che la SYSAUX è piena.

Con la procedura MODIFY_SNAPSHOT_SETTINGS si possono controllare i parametri dello


SNAPSHOT.Si puo’ modificare:
1.La RETENTION espressa in minutiIl default è 8 giorni ilo minimo è un giorn.Settando la
RETENTION a 0 si disabilita’ il purging automatico.
2.INTERVAL fra gli snapshot.Il valore minimo è di 10 minuti il massimo e di 100 anni ed il default
è di 60 minuti.
3.Il numero di TOP SQL STATMENTS per cui catturare i dati delle performance avendo a
disposizione tre setting:DEFAULT,MAXIMUM,N dove N è il numero di statments da controllare.
Specificando DEFAULT si catturano i top 30 SQL STATMENTS per il livello TIPICAL del parametro
STATISTICS_LEVEL ed i Top 100 per il livell ALL del parametro STATISTICS_LEVEL.Specificando
MAXIMUM si cattura l’intero set di SQL STATMENTS nella cursor cache.Specificando NULL per
mantenere il setting corrente
In alcune circostanze gli snapshot possono essere completamente stoppati settando l’INTERVAL
a 0,le raccolte automatiche di colezzioni e i dati statistici non vengono catturati e molte delle
funzioni di Oracle self-management saranno disabilitate poer cui Oracle sconsiglkia vivamente di
settare a 0 il parametro INTERVAL.
Gli snapshot sono normalmente collezzionati automaticamente ma ci potrebbero essere delle
volte che si vogliono collezzionare manualmente prima o dopo che un determinato evento
accade e che magari non ha un match con l’INTERVAL degli snap automatici
La prima sessione del report AWR fornisce un diagnostic set che descrive:

La sessione TOP 5 TIMED FOREGROUND EVENTS è un buon starting point per cominciare il
tuning.L’esempio sopra mostrra un valore davvero alto di % di tempo speso dalla buffer busy
waits.Le sessioni addizzionali aiutano a duiagnosticare i problemi che sono mostrati nella prima
sessione.
Un perieodo di comparazione abilita a de3finire due differenti perieodi e comparare i loro
rispettivi AWR data sets.
Questa slide mostra una porzione del risultato del Compare Perieods che identifica differenze di
statistiche tra due pereodi.Questo snapshot compare lo stesso WorkLoad eseguito su due
differenti tablespace configuration.Le comparazioni possono essere fatte sia per Second CHE
PER transaction.Siccome il workload è lo stesso in ogni perioedo una comparazione per
transaction è appropriata .Per esempio questo report mostra che ci sono significanti differenze
Il primo perieodo ed il secondo per il DB TIME (Second) speso per transazione.Sulla GENERAL
tabbed page si possono visualizzare le statistiche generali per secondi piuttosto che per transazio
Ne ,semplicemente selezionando il corrispondente valore nella vista VIEW DATA FIELD.Cliccanbdo
sul link REPORT verra’ visualizzato un report HTML che compara i due perieodi mostrando le
differenze di waits events,OS statistics,services,SQL statistics,istance activity,IO statistics e segmen
statistics.
NOTA:Se le misure dei due perieodi sono differenti i dati vengono normalizzati sulla DBTIME prima
di calcolate le differenze affinche’ i periedi con differenti lunghezze possano essere comparati.
Quando si clicca sulla Report Tab viene generato il WorkLoad Repository Compare Perieods
Report.Questo report contiene le stesse sessioni del primo in piu’ mostra una comparazione di
configurazione tra il primo perieodo ed il secondo.L’esempio mostrato sopra prende due
perieodi con lo stesso elapsed time e ci dice che lo stesso workload script è stato lanciato nei
due perieodi,in questo esempio il DBTIME è stato ridotto significativamente nel secondo
perieodo.Un cambiamento che produce un beneficio di parformanc non è sempre cosi’ chiaro.
NOTA:Si puo’ ottenere lo stesso report lanciando lo script awrddrpt.sql localizzato nella
$ORACLE_HOME/rdbms/admin directory.
Il LOAD PROFILE è veramente utile per comparare i due perieodi.Esso aiuta ad isolare le
differenze nel worload.In questo report il workload script è uguale in entrambe i perieodiSolo la
configurazione del DB è cambiataSi puo vedere che il DBTIME per Second e Per Transaction sono
diminuite e che diverse I/O metriche per transaction sono diminuite :Logical Read,BLOCK
Chances,PHYSICAL READS e PHYSICAL WRITE.La transaction per second mostra che è stato
eseguito piu’ lavoro nello stesso tempo.NOTA:Questo esempio mostra un change che ha
prodotto dei benefici ma attenzione perche’ riducendo i waits in un area potrebbero causare
contention e waits in un’altra area.
Ogni istanza anche se ben ottimizzata avra sempre un top waits event che puntano alle aree che
potrebbero beneficiare del tuning.
Molte informazioni possono essere recuperate dal EM interfaccia:
STATSPACK o AWR collezzionano metriche regolarmente.
OS o EM tools controllano i problemi legati alla CPU e al disco e alla memoria che danno il
segnale di un sistema sovraccaricato.
Utilizzare AWR e STATSPACK per identificare gli statments SQL che consumano piu’ risorse.
Controllare gli ALERT LOG e i TRACE FILE error messages che potrebbero fornire indicazioni sulla
natura del problema
Assicurarsi che i parametri di inizzializzazione del DB abbiano senso per il sistema
Collezzionare Istances e OS statistics.STATSPACK report puntano ai componenti dove ci sono i
maggiori WAITS eil maggior utilizzo di risorse
ADDM focalizza su questi componenti.
Capire dove vi è un calo di prestazioni ad esempio a livello di OS,di ISTANCE o a livello di
APPLICATION SQL?Questa domanda non è sempre facile da rispondere.Inefficienti SQL
statments possono causare eccessive letture fisiche e scritture e appaiono come dei I/O= issue.
Impropri SIZING della memoria (ISTANCE CONFIGURATION ISSUE) possono causare eccessivi
SWAPPING nell’OS.Inefficienti configurazioni del DISCO possono apparire anche essi come
ISTANCE CONFIGURATION ISSUE causando un LARGE REDO LOG WAITS o COMMITS WAIT e altri
problemi.
Eliminare le possibilita’.Quando l’istanza appare avere un problema di I/O comparare il file delle
statistiche di I/O con quello del OS LEVEL STATISTICS.Le differenze possono guidare al problema
reale.Per esempio Un AVERAGE WAIT TIME piu grande -del normale su una particolare
tablespace potrebbe essere causato da:
HARDWARE : Un file è su un drive lento o su di un appropriata configurazione RAID
OS : L’OS è peggiore con altri file sullo stesso drive o partizione
ISTANCE: Il tablespace era stato creato con differenti proprieta’ di altre tablespace,altri fikle di
database non hanno lo stesso disco o la stessa partizione(le I/O del database non sono
bilanciate su tutti i drivers)o gli oggetti che sono acceduti sono troppi nello stesso tablespace,file
o disco.
Application : L’applicazione sta facendo troppe I/O causando un access path inefficiente causato
da inefficienti indici,da statistiche non fatte o errate o altre ragioni.
Determina quale problema deve essere tuning per primo.I report delle statistiche forniscono la
TOP EVENTS LIST.
Ogni richiesta al DB ha un tempo di risposta che è la somma del WAIT TIME e del SERVICE
TIME.Il SERVICE TIME (CPU TIME).Sia il SERVICE TIME ed il WAIT TIME possono essere
ottimizzati.
Per ottimizzare il SERVICE TIME devono essere fatti cambiamenti ai processi,SQL,all’access Path
o alle strutture di memorizzazioone dei dati.
Il WAIT TIMES puo’ essere ottimizzato riducendo le CONTENTION per le risorse dove il WAIT
avviene.
Ogni processo server tipicamente in uno di questi stadi:
1.IDLE: Aspetta per fare qualcosa (SLEEPING)
2.Running Code:Utilizza la CPU o è in un coda di run
3.WAITING(Blocked):
-Che alcune risorse diventano disponibili
-Aspetta che una richiesta venga completata
Il TOP EVENTS EVENT ha sempre lo stesso valore.
La TOP 5 TIMED FOREGRAUND EVENTS mostra solo che l’istanza sta utilizzando la CPU.,
La sessione ISTANCES CPU mostra che l’istanza sta utilizzando il 65% della CPU dell’OS,questa
informazione è inconclusiva.L’istanza è preposta per utilizzare la CPU e non aspetta.,Questo set
di diagnostiche puo’ indicare che l’istanza è CPU BOUND.In questo caso il SERVICE TIME ha
bisogno di essere ottimizzato.Per ridurre il SERVICE TIME l’SQL è l’area che usualmente viene
analizzata.
Iul Report sui TOP WAITS EVENTS non da una chiara indicazione.Quindi si deve continuare ad
indagare con le TIME MODEL per cercare quale area sta consumando piu’ DB TIME.Si possono
determinare i TOP- priority tuning comparando il tempo speso in vari waits e task conl’overall
wait time e service time.Entrmbi i tools mostrano le TIME MODEL STATISTICS per guidare al
tuning.
Il tuning degli statments SQL ha un alto impatto che puo’ ridurre l’uso della memoria,la CPU e le
risorse di I/O.Gli statments SQL non performanti possono essere determinati da un cattivo
utilizzo di indici,da un access path errato,e dalle operazioni di sorting.In questo corso npon
verranno analiozzati i cambiamenti possibili per gli statments perche’ vi è un altro corso che
spiega questo.
I problemi come le eccessive nuove connessioni al db,eccessivi SQL parsing e l’alto numero di
Contentionper una grande quantita’ di dati (conosciute come application-level block contention)
Possono degradare le performance significativamente.

I problemi legati alla memoria sono listati in alto.Facendo propriamente il sizing della memoria
SYSTEM GLOBAL AREA (SGA) e della PROCESS GLOBAL AREA (PGA) si possono ridurre le
contention per le risorse di memoria e indirettamente ridurre le I/O e la CPU.

Un alto grado di attivita’ concorrenti,processi multipli o user multipli possono risultare in


Contention per risorse condivise che possono manifestarsi invarie forme di Wait.
Molte risorse possono essere accedute solo da un singolo processo per volta.Diversi processi
tentano di accedere alla stessa risorsa creando delle Contention.
In ogni DB kle I/O issue come i database file layout sul disco o su un dispositivo RAID possono
essere una sorgente di problemi di performance.Nelle applicazioni OLTP l’ammontare di redoe
undo possono creare dei colli di bottiglia in memoria o in I/O.
Alcuni problemi vengono reportati dagli utenti ma ma potrebbero non apparire dai report che
prendono intervalli di 30 minuti o piu’.IlDB ha tool addizzionali (Active Session History ASH) che
permette ai DBA di guardare le statistiche e le metriche su grandi segmenti di tempo.
Molti DB avranno cambiamenti graduali ad esempio il numero di utenti ,l’aumentare dei dati il
numero dei report e i moduli in uso.Questi cambiamenti possono peggiotrare le performance.Il
DBA catturera’ e salvera le statistiche da quando il database aveva performance accettabili
comparandole alle statistiche prese quando il db ha performance basse in modo da capire quali
sono stati i cambiamenti(ad esempio Pacth,upogrades,new hardware o parametri di istanza).
I problemi di LOOKING non sono molto comuni ma quando si verificano essei diventano molto
importanti.
1.METRIC:Valutazione dei cambiamenti nelle statistiche cumulative
2.ALERT:Eventi generati quando una metrica monitorata supera una
certa soglia
3.BASELINE:Dati raccolti da un “Normal Running DATABASE” per le
comparazioni di performance.
Una metrica è una percentuale di cambiamenti nel tempo in una statistica cumulativa,
ad esempio le letture fisiche al secondo.I valori di soglia possono essere settati per
varie metriche e quando un valore supera la soglia un alert viene inviato.
Una baseline comprende set memorizzati di metrics e statistics.Un single SET è
chiamato snapshot.Una baseline è composta di due o piu’ snapshot.Solitamente
una baseline viene catturata durante un perieodo di normale o accettabile
performance,ma essa puo’ catturare tutti i perieodi di interesse.
Quando le performance non sono come si ci aspoettava un altro set di metrics puo’
essere catturato e comparato con le baseline.Questo metodo permette ai dati di
cancellare il punto per i problemi di performance.
Le statistiche sono conteggi di eventi che accadono nel database.Statistiche e WAIT EVENTS
sonoi i dati grezzi.Base Statistics sono sempre solo un valore ad un determinato tempo.
Se si traccia le base statistics per un lungo perieodo di tempo si puo’ vedere come i valori
continuano a crescere nel corso del tempo.La slide illustra un possibile esempio di un grafico per
le phisical read estratto dalla V$SYSSTAT.Come si puo vedere le statistiche hanno lo stesso valore
Per entrambi i grafici,ma alla fine del perieodo di osservazione i grafici sono completamente
diversi.Nel grafico sopra è chiaro che il DB ha un alto numero di higher rate rispetto al grafico in
Quindi si rende conto che le statistiche sono sensa senso.Per meglio capire l’ambiente
del DB si ha bisogno di guardare la curva o l’andamento non solo il valore.Percio si
ha bisogno delle percentuali delle compute statistics in un perieodo di tempo per
determinare l’andamento di quel perieodo.

TYPICAL DELTA TOOLS


Comparazione delle statistiche in due punti diversi nel tempo è necessaria
I seguenti tools producono il delta:
1.AWR report
2.Statspack
3.Customized Script

Le base statistics sono dei numeri grezzi accumulati dallo startup dell’istanza,uno
snapshot è un set di statisiche catturate ad un punto nel tempo.La differenza tra i
due punti negli snapshot si chiama delta.AWR e STATSPACK permettono di salvare
set di snapshot nel tempo per future indagini,questi set salvati si chiamano
statistics baseline.
Il server Oracle collezziona base statistics durante le normali operazioni.Esse sono
semplici conteggi,ad esempio la media del numero di letture fisiche nel sistema
negli ultimi60 minuti è na metrica.Le metriche sono utilizzate da internal
components (client) per il monitoraggio del sistema per la cattura di problemi ed il
self tuning.Il processo MMON periodicamente aggiorna i dati dalle corrispondenti
base statistics.Ad esempio Automatic Database Diagnostic Monitor (ADDM) usa la
media delle letture fisiche nel sistema negli ultimi 60 minuti come input.Un altro
componente potrebbe avere differenti metriche basate sulle stessa base statistics
delle letture fisiche.Ad esempio la Memory Advisorpotrebbe aver bisogno delle
statistiche sulle letture fisiche.Oracle supporta metriche per system,session,files e
wait event statistics.Ogni metrica è identificat univocamente da un numero
associato con il nome della metrica.Il diagramma mostra alcune delle fixed viewche
possono essere accedute dal browser metric data.
Il maggior beneficio di mantenere le statistiche è quando un componente ha bisogno di mantenere la percentuale di
cambiamenti di alcune attivita’,i dati sono subito disponibili.Nelle versioni precedenti si dovevano catturare le
statistiche prima e dopo aver lanciato un workload per catturare il cambiamento di una base statistics.
Con le metricstutto quello che bisogna fare e lanciare il workload e catturare le corrispondenti metrics
I componenti Server ora hanno una base per il self tuning.Le metriche forniscono le informazioni di performance per
l’AUTOMATIC MEMORY MANAGEMENT e per l’AUTOMATIC DATABASE DIAGNOSTIC MONITOR
Utilizzare la ALL METRICS page per guardare una lista di tutte le metriche delle performance
disponibili per il nostro DB
STATISTICS HISTOGRAMS
Attraverso le metriche si puo’ avere un idea dell’andamento per delle
particolari statistiche ,ma esse non ci dicono pero’ se si è verificato
qualche collo di bottiglia e dove potrebbe essere localizzato.Ad
esempio puo essere osservata una elevata percentuale sulla metrica
che improvvisamente ma questa potrebbe essere localizzata solo su
una o due sessioni nel nostro sistema.In questo caso potrebbe non
valere la pena di investigare ,tuttavia se l’improvviso incremento è
localizzato all’intero sistema potrebbe essere necessario investigare
ulteriolmente.Queste informazioni sono disponibili sulle Histogramm
Performance View.
Come mostrato nela precedente slide si osserva un improvvisa incremento di I/O rate.Si puo’ correlare
questa informazione alla corrispondente I/O histogramm che si trova nella V$FILE_HISTOGRAM
view.Questa vista mostra gli istogrammi di tutti i singoli block readssu di un PER-FILE BASIS.Gli
istogrammi hanno delle recipienti di intervalli di tempo misurati in millesecondi da 1 a 2 all
22esima(69,9 minuti)Il valore in ogni recipiente è il numero di volte che il sistema ha dovuto aspettare in
quell ammontare di tempo.Ad esempio si puo guardare nella slide che il sistema ha aspettato 5500 volte
per piu’ di 32 ms secondi e meno di 64 millisecondi per leggere i blocchi dal disco
Questo è certamente una causa di preuccupazione per il nostro sistema l’accesso sono
normalmente minori di 10 ms e quindi andrebbe investigato le cause.
Le metriche di danno un alert ad un potenziale problema drilling down sugli istogrammi si
possono determinare chiaramente dove realmente vi è un problema.
Gli ALERT sono sono notifiche emesse quando il DB è in uno stato idesiderato.Per Default il DB manda gli alerts via
Enterprise Manager Control dove essi vengono visualizzati.Opzionalmente l’EM puo’ essere configurato per
inviare gli alert tramite mail.Il DB mantiene quindi una storia delle metriche e degli alerts nel workload
repository.Gli alert possono essere personalizzati e comprendono:
AVERAGE FILE READ TIME (centisecond)
Response Time(per transaction)
SQL Response Time(%)
WAIT TIME (%)
Se si vuole conoscere soltanto il valore delle metriche del server allora un valore assoluto
potrebbe esserecorretto,ma se si vuole conoscere le differenze di performance tra oggi ed una
settimana fa o un mese fa allora le performance correnti devono essere confrontate con le
baseline.Le base line sono un set di snapshot prese in un determinato perieodo di tempo.Ad
esempio il numero di transazioni per second in certi database variadipendendo dallìora nel
giorno.Il valore delle transaction per secondo saranno alte nelle ore di working e basso nelle ore
di non working ad esempio di notte.Le baseline memorizzano queste variazioni e possono
essere settate poer mandare un alert se il numero concorrente di transazioniper secondo è
significativamente maggiore rispetto alla baseline.
La baseline una comparazione real-time e possono essere usate per produrre dei report AWR
per comparare due poerieodi di tempo.

Le baseline di AWR forniscono un potente strumento per definire dinamiche e future baseline e
semplificano il processo di mantenimento e di creazione delle baseline per scopi di
comparazione.Oracle 11g fornisce due tipi di baseline le STATIC BASELINE e le MOVING
WINDOW
STATIC BASELINE: possono essere sia singole che ripetute.Una singola baseline di AWR è
collezzionata su un singolo perieodo.Una base line ripetuta è collezzionata su un perieodo
ripetuto (ad esempio ogni lunedi del mese di Giugno).In Oracle 11g esse sono abilitate di
default se il parametro STATISTICS_LEVEL=TYPICAL o ALL
MOVING WINDOW ASELINE: C’e’ una sola moving window baseline:
La SYSTEM_MOVING_WINDOW:una moving window baseline che corrisponde agli ultimi 8 giorni dei dati di
AWR
E’ creata automaticamente in ORACLE 11g ,la default window size corrisponde al perieodo di retenzione di
AWR che è di 8 giorni.Se si pianifica di utilizzare un adaptive threshold considerare di utilizzare una
windows piu’ larga ad esempio 30 giorni per catturare accuratamente le statistiche.
Si pu ridimensionare la window moving window baseline ad un valore che è uguale o piu’ basso del
perieodo di retenzione dell’AWR(8 giorni di default).Tuttavia per aumentare la window bisogna
aumentare il perieodo di retenzione di AWR accuratamente e deve essere sempre maggiore o uguale
alla window baseline size.
Ci sono tre task automatici di mantenimento in Oracle 11g:
OPTIMIZER STATISTICS GATHERING
SEGMENT ADVISOR
AUTOMATIC SQL TUNING
Questi task vengono lanciati in un set di predefinite job window.Essi sono assegnati ad un RESOURCE
CONSUMER GROUP che pianifica la durata delle window e delle risorse che i task possono
consumare come ad esempiuo la CPU.Questi task automatici aiutano il monitoraggio del DBA
SPACE,collezzionano statistiche e ottimizzano i hight-load SQL statments.
Il DBA dovrebbe monitorare questi task.Il risultato potrebbe apparire nella forma di raccomandazioni
referenziate nell’AUTOMATIC DATABASE DIAGNOSTIC MONITOR (ADDM) reports o essere
visualizzati nella pagina ADVISOR CENTRAL page.L’esecuzioni di questi task sono priorizzati.Se il
task non ha sufficiente tempo o risorse per completare essi saranno schedulati per la prossima
window.Quando i Task stanno riependo le window disponibili la durata e l’allocazione delle
risorse potrebbero aver bisogno di essere cambiate.
Con Oracle 11g l’AUTOMATIC MAINTENANCE TASK risiede nella RESORCE MANAGER.L’obbiettivo
è prevenire che il lavoro di mantenimento consuma eccessive risorse di sistema.Ogni
maintenance window è associata con un resource plan che specifica come le risorse saranno
allocate durante la durata della window.In ORACLE 11g WEEKNIGHT_WINDOW e
WEEKEND_WINDOW sono rimpiazzate con la dayli9 maintenance window.Gli Automatic Task
sono assegnati con una specifica Window.Tutte le Windows giornaliere appartengono al
,al MAITENANCE_WINDOW_GROUP di default, ma siamo ancora liberi di definire altre
maintenance window cambiando il STRAT TIMES e la durata della daily window.Allo stesso
modo ogni window che è ritenuta nion necessaria puo’ essere disabilitata o rimossa.
L’operazione puo’ essere fatta attraverso EM o la SCHEDULAR INTERFACE.
Quando una window di maitenance viene aperta,il DEFAULT_MAINTENANCE_PLAN nel RESOURCE
MANAGER è automaticvamente settato per controllare l’increnmento di risorse della CPU utilizzate dai
automatic maintenance tasks.Per essere abilitati a prendere diverse priorita’ per ogni possibile durata
dei task vari consumers group sono assegnati al DEFAULT_MAINTENANCE_PLAN.La gerarchia fra i vari
gruppi e i piani è mostrata nella slide:
I piani urgenti sono assegnati al gruppo ORA$AUTOTASK_URGENT_GROUP,tutti i task assegnati
a questo gruppo hanno una priorita’
I piani di urgenza media vengono assegnati al gruppo ORA$AUTOTASK_MEDIUM_GROUP.
Per i task a bassa priorita’:
IL TASK AUTOMATICO OPTMIZER STATISTICS GATHERING è assegnato al
ORA$AUTOTASK_STATS_GROUP consumer group.
Il task automatico Segment Advisor è assegnato al gruppo ORA$autotask_space_group
L’AUTOMATIC sql Tuning Task viene invece assegnato al consumer group
ORA$autotask_sql_group
Se è necessario tu puoi manualmente cambiare la percentuale di CPU assegnata ai vari gruppi
di automatic task all’interno del ORA$AUTOTASK_HIGH_SUB_PLAN.
L’Automated Maintenance task feature è implementata dal processo AUTOMATIC BACKGROUND
PROCESS(ABP)
Che funziona come un intermediario tra l’automated task e lo scheduler.L’ABP mantiene una
storia dell’esecuzione di tutti i task,esso memorizza le informazioni nel suo repository privato
situato nella SYSAUX tablespace,si puo’ guardare il repository attraverso il
DBA_AUTOTASK_TASK.
ABP è startato dal MMON allo start delle window di mantenimento.E’ richiesto solo un ABP per
tutta l’istanza.Il MMON monitora l’ABP e lo restarta se è necessario.
ABP determina una lista di JOB che hanno bisogno di essere creati per ogni maintenance task.
Questa lista è ordinata dalle priorita’:Urgent,Hight e Medium.All’interno di ogni gruppo di
priorita’ i job sono eseguiti nell’ordine prerito di esecuzione.ABP crea i jobs nella seguente
maniera:tutti gli Urgent-Priority jobs sono creati prima, poi vengono creati tutti i Hight-
Priority Jobs e successivamnente vengono creati tutti i Medium Priority Jobs .
ABP assegna i Job a varie JOB CLASSES che mappano il job al gruppo basandosi sulla priorita’
NOTA:In Oracle 11g nessun gruppo è associato permanentemente coun uno specifico task di
mantenimento.Tutavia non puo’ essere utilizzato il DBMS_SCHEDULER per
controllarel’esecuzione degli automated task ma bisogna utilizzare la procedura
DBMS_AUTO_TASK_ADMIN
La feture AUTOMATIC MAINTANANCE TASK DETERMINA quando e l’ordine in cui i task vengono
eseguiti.Come DBA tu puoi controllare le seguenti:
1.Se la windows di maitenance è inadeguata per il maintenance del workload puoi aggiustare la
durata e lo start time della window
2.Controllare il resource plan che alloca le risorse per l’utomazione dei maintanence task
durante ogni window
3.Abilitare o disabilitare i task individualmente in alcune window o in tutte le window
4.In un ambiente RAC spostare il lavoro di maintenance da una o piu istanze mappando il work
di maintenance ad un servizio.Abilitare il servizio ad un subset di istanze spostando il
maintenance work solo a queste istanze.
Come mostrato nella slide Enterprise manager è il modo preferito di controllare gli Automatic
task tuttavia puo’ essere utilizzato anche il DBMS_AUTO_TASK_ADMIN package.
Di default il server Oracle cattura le informazioni sulle statistiche dalla SGA ogni 60 minuti e le
memorizza nell’AUTOMATIC WORKLOAD REPOSITORY(AWR) nel formato di snapshot.Questi
snapshot sono memorizati sul discoe sono simili agli snapshot dello STATSPACK tuttavia essi
contengono informazioni piu’ precise.
Addizzionalmente,ADDM è schedulato per lanciare automaticamente il processo MMON su ogni
istanza del DB per catturare eventuali problemi.Ogni volta che viene fatto uno snapshot
ADDM è triggerato per eseguire un analisi sul perieodo corrispondente agli ultimi due
snapshot.Questo approcio immediatamente monitora l’istanza e cattura i colli di bottiglia
prima che essi diventino un reale problema.I risultati dell’e analisi dellADDM sono
memorizzati nel Automatic Workload Repository e sono quindi accessibili attraverso il
Database Control.
NOTA:Sebbene le analisi dell’ADDM sono eseguite sul perieodo degli ultimi due snapshot è
possibile manualmente invocare un ADDM analisi su ogni snapshot.
DATABASE TIME (DB TIME) è la somma del tempo speso affinche’ il database non produca una risposta ad
un USER REQUEST.
La slideprecedente visualizza un semplice scenario dove un singolo user invia una richiesta .Il tempo di
risposta è la l’intervallo di tempo tra l’istante in cui la richiesta è mandata al DB e l’istantre in cui la
risposta viene ricevuta.Il database Time trascorso in questa user request è solo una porzione del tempo
di risposta che è speso dal DB.
Il grafico piu’ in basso nella precedente slide mostra come il database time è sommato tra diversi user,e ogni
user sta effettuando una serie di operazioni risultanti in una serie di richieste al db.Si puo’ vedere come il
database time sia direttamente proporzionale al numero e alla durata delle user request.Utilizzando il
DB TIME come misura tu puoi valutare l’impatto di performance di ogni entita’ e del database.
Ad esempio l’impatto delle performance di una non dimensionata Buffer Cache potrebbe essere misurata
come il totale del DB Time speso in addizzionali operazioni di I/O che potevano essere evitate se la
buffer cache era stata dimensionata meglio.
Il DATABASE TIME è semplcemente una misura del totale del lavoro fatto dal server.La percentuale n di
database time consumata è la media del carico misurata come DATABASE TIME per secondo.Lo scopo
dell’ADDM è ridurre l’incremento di DATABASE TIME speso pèer ognio workload che è analogo a dire di
consumare meno energia per lo stesso lavoro.
Identificare la componente che contribuisce ad aumentare il DB TIME è equivalente a
cercare il singolo componente del DB che fornisce il miglior beneficio quando viene
ottimizzato.ADDM utilizza il database Time per identificare i componenti del
database che richiedono un investigazione.Il primo passo dell’automatic
performance tuning è trovare la causa del problema edlle performance.Solo
quando la causa del problema è correttamente identificata si puo’ pensare alla
soluzione del problema.
ADDM guarda al database time speso in due differenti dimensioni:
1.La prima guarda al tempo speso in varie fasi di una user request come ad esempio la
connessione al DB,l’ottimizzazione degli statment SQL e l’esecuzione del SQL
2.La seconda utilizza o aspetta varie risorse di database utilizzate nella richiesta
utente.Le risorse analizzate includono sia quelle hardware come la CPU e i
dispositivi di I/O che le risorse software come i database lock e le application lock.
Queste due dimensioni possono essere rappresentate utilizzando il DBTime-Graph.

I problemi di performance spesso distribuiscono il database time a molte categorie in


una dimensione ma non nell’altra.Ad esempio un problema di scarsa CPU rallenta
tutte le fasi di un user request che appartegono alla prima dimensione analizzata
da ADDM.Tuttavia potrebbe essere invece subito chiaro che il problema appartiene
alla seconda dimensione e cioe’ alla scarsa CPU.ADDM esplora il DBTime-Graph
partendo dal nodo root e analizzando tutti i nodi children dove il db consuma le
risorse in modo significante.I nodi ramo nel grafico identificano l’impatto delle
performance di come è usualmente un sintomo di un collo di bottiglia
Il nodo terminale identifica particolari principali cause che possono causare tutti i sintomi che
sono significanti lungo il percorso in cui il nodo terminale era raggiunto.Ad esempio nella
slide il nodo ramo delle Capacity di I/O misura il database time speso in tutte le I/O request
il quale è significante grazie ai vari colli di bottiglia.Ogni volta che significanti I/O database
time viene speso in una richiesta tutti i rami children del nodo della Capacity I/O vengono
esplorati.Essi corrispondono a due terminali nodi nela slide.il nodo non dimensionata
BUFFER CACHE punta ad una particolare causa Root:la buffer cache dei data-blocknon è
dimensionata e causa eccessivi I/O.Il nodo INSUFFICIENT BANDWIDHT I/O guarda a
problemi di hardware che possono rallentare le I/O .Dopo cheun un nodo terminale
identifica una causa principale ADDM misura l’impatto della root causa nel database time
speso.Esso allora illustra i modi che possono risolvere o alleviare il problema identificato.
E’ interessante vedere come l’ADDM non ha bisogno di attraversare l’intero grafico esso puo
ridurre i subgrafici non interessati.Alla fine dell’analisi ADDMvisualizza la causa ROOT e le
rispettive tutning rccomandetion.
Con le precedenti versioni di oracle StatsPack non era abilitato ad identificare alcuni problemi
listati nella precedente slide.Con l’introduzione delle WIAT e delle TIME statistics model in
oracle 11g ADDM è abilitato ad identificare le top issue listate nella slide.Un altro beneficio
di ADDM è che ADDM concentra la sua analisi sui TOP ISSUE.Inoltre ADDM raccoglie
statistiche in aree ralative all CPU,PAGING e INTEGRATED CACH.Lo scopo di ADDM e
aggiungere piu server component come lo STREAMS,AQ e RMAN.
Sulla Home page del nostro DB noi possiamo osservare la DIAGNOSTIC SUMMARY SECTION che ci da il
numero delle ricerche ADDM del precedente run automatico.Cliccando sul link PERFORMANCE
FINDING si va direttamente nella AUTOMATIC DATABASE DIAGNOSTIC MONITOR (ADDM) page dove si
puo accedere ai dettagli dell’ultimo ADDM run.
Nella pagina Automatic DataBase Diagostic Monitor(ADDM) noi possiamo vedere il dettaglio per l’ultimo
ADDM run.Database Time rappresenta la somma dei tempi non-idle spesi dalle sessioni nel database per
il perieodo delle analisi.Una specifica percentuale di impatto viene fornita per ogni ricerca.L’impatto
rappresenta il tempo consumato dei corrispondenti issue comparati con il database time per il perieodo
di analisi.
Le seguenti informazioni sono riferite al numero nella slide:
1.Il grafico mostra la media del numero di utenti attiviQuindi,il problema maggiore era un WAIT
2.Le icone mostrano che l’ADDM output visualizzato alla fine della pagina corrispondono a questo punto nekl
tempo.Si puo guardare la storia cliccando sulle altre icone.
3.La finding ci da un veloce sommario di quale area dell’istanza potrebbe essere ottimizata.Cliccando su di
un particolare ISSUE si andra direttamente al Performance Finding Details page
Si puo cliccare sul bottone View Report per ricevere dei dettagli sulle analisi delle performance in forma di
report testuale.
Nella pagina Performance Finding Details si possono vedere delle raccomandazioni per
risolvere il corrispondente Issue.Le raccomandazioni sono raggrupate in
SCHEMA,SQL TUNING,DB CONFIGURATION e altre categorie.La colonna
BENEFIT(%) da la riduzione massima dell’elapsed database time se le
raccomandazioni vengono implementate.

ADDM considera una varieta’ di cambiamenti al sistema e le sue raccomandazioni


possono includere
1.HARDWARE CHANGES:Aggiunta di CPU o cambi di configurazioni di sistema per le I/O
2.DATABASE CONFIGURATION:Cambi di parametri di inizializzazione
3.SCHEMA CHANGES:Hash Partiztioning di una tabella o di un indice o utilizzo di
Automatic Segment Space Management(ASSM)
4.APPLICATION CHANGES:Utilizzo di opzioni di cache per le sequence o l’utilizzo di bind
variabiles
5.UTILIZZO DI ALTRI ADVISOR:Running del SQL TUNING ADVISOR sui statments SQL
hight-load o il running del SEGMENT ADVISOR sugli oggetti del DB
Di default ADDM task sono lanciati ad ogni snapshot che viene memorizzato nel repository workload.Tuttavia
si puo creare un custom ADDM task per analizzare che noi identifichiamo con un snapshot di Start e
duno di END.
ADDM è abilitato di default ed è controllato dal parametro STATISTIC_LEVEL che deve essere settato a
TYPICAL o a ALL mentre se esso èò settato a BASIC ADDM non sara running.Il default per il parametro
STATISTIC_LEVEL è TYPICAL.
Le analisi di ADDM delle performance di I/O dipendono parzialmente dal parametro ADDM DBIO_EXPECTED
Questo parametro descrive le performance attese di un sottosistema di I/O.Il valore del parametro
DBIO_EXPECTED rappresenta la media del tempo per leggere un singolo blocco del database in
microsecomndi.ADDM utilizza il valore medio di 10 millisecondi che è un valore appropriato per lka
maggior parte dei hard disk moderni.Se il nostro hardware è significativamente differente si puo
utilizzare un valore differente.Per eseguire il corretto setting del valore del parametro del
DBIO_EXPECTED eseguire quanto segue:
1.Misurare la media del twempo di lettura di un singolo database block per il nostro hardware.Notare che
questa misura è per I/O random che includono tempi di ricerca se si utilizza uno standard hard
driversTipici valori di hard drivers sono compresi tra 5,000 e 20,000 microsecondi
2.Settare i valore del DBIO_EXPECTED.Ad esempio se il valore della misura eseguita al punto primo è 8,000
microsecondi allora si dovrebbe eseguire il primo comando illustato nella slide precesente
connettendosi come utente SYS.
La vista V$ACTIVE_SESSION_HISTORY fornisce semplici attivita di sessione nell’istanza.Questo
puo essere utilizzato come come la prima analisi di sistema.Ogni sessione che è connessa al
database e che sta aspettando un evento è considerata una sessione attiva.Le sessioni
semplici attive sono memorizzate nella Circular Buffer Cache nella SGA.All’aumentare delle
attivita’ di sistema il numero di secondi delle sessioni attive che possono essere memorizzate
nella buffer circular cache diminuisce.Il tempo di una sessione semplice è mantenuto nella
V$ viewIl numero dei secondi di una sessione attiva visualizzata nella V$ view è
completamente dipendente dalle attivita’ del DB.
Quando gli snapshot dell’l’AUTOMATIC WORKLOAD REPOSITORY AWR vengono creati il
contenuto della V$ACTIVE_SESSION_HBISTORY viene svuotata dal disco.Catturando solo le
sessioni attive un set di fati viene rappresentato e la sua dimensione è direttamente
relazionata al lavoro essendo eseguito piuttosto che al numero di sessoni permesse dal
sistema.Si possono visualizzare i dati delle correnti ACTIVE SESSION HISTORY (ASH) nella
V$ACTIVE_SESSION_HISTORY e i dati storici nella DBA_HISTORY_ACTIVE_SESS_HISTORY
view.Si possono eseguire dettaglate indagini su questi dati spesso evitando la necessita’ di
ripetere il workload per raccogliere addizzionali infrmazioni di tracing delle performance.I
dati rappresentati nella ASH possono essere comprese nelle varie dimensioni che essi
catturano.