Nella versione 10g, Oracle ha introdotto l'"Intelligent Self-Management Infrastructure" [1]
L'idea di base di tale Infrastruttura è quella di raccogliere il maggior numero di informazioni con il minor impatto sul sistema. In base al principio di intederminazione di Heisenberg, sappiamo che osservando un fenomeno ne modifichiamo il comportamento. E questo ovviamente si applica anche all'rdbms [2].
Una delle componenti dell'infrastruttura è ASH.
In questo post vorrei mettere in evidenza un particolare punto di vista, basato su un idea di Kyle Hailey [3].
Sappiamo che ASH è basato su un campionamento effettuato ogni secondo. Questo ovviamente comporta dei buchi tra un'istantanea e l'altra. In raltà noi siamo interessatti solo a quelle sessioni che durano un certo periodo di tempo (soltanto le "sessioni lunghe" vengono analizzate: quelle di breve durata non hanno generalmente impatto sulle performance).
Così se una sessione impiega minuti prima di terminare, sono sicuro di osservare la sua attività, anche se questa non avviene in modo continuo ma solo ad intervalli di un secondo. E' come vedere un film a fotogrammi distanziati di un secondo.
(questa immagine è presa da [3])
Come sempre un'immagine vale più di mille parole. Quella qui sopra ci mostra come sia possibile determinare cosa stia succedendo anche se non ne conosciamo la storia istante per istante.
E la cosa più sbalorditiva è che il campionamento è quasi del tutto fedele al modello temporale. Per mostrare questo ho utilizzato una query [4] il cui risultato è il grafico in figura ottenuto con Microsoft Excell
Il grafico mostra la differenza tra misure campionate (ASH) e quelle ottenute in tempo reale (DB Time). In Y c'è il valore di "ASH"/"DB Time", mentre in X lo "snap_id/time stamp"
In realtà, per ottenere questo grafico, ho dovuto eliminare alcuni valori. Sto cercando ancora di capire quali sono le cause che producono tali anomalie.
Ho modificato l'immagine perché ho eliminato un punto dak grafico. Sto scrivendo un post sulle anomalie che ho riscontrato.
Sappiamo che ASH è basato su un campionamento effettuato ogni secondo. Questo ovviamente comporta dei buchi tra un'istantanea e l'altra. In raltà noi siamo interessatti solo a quelle sessioni che durano un certo periodo di tempo (soltanto le "sessioni lunghe" vengono analizzate: quelle di breve durata non hanno generalmente impatto sulle performance).
Così se una sessione impiega minuti prima di terminare, sono sicuro di osservare la sua attività, anche se questa non avviene in modo continuo ma solo ad intervalli di un secondo. E' come vedere un film a fotogrammi distanziati di un secondo.
(questa immagine è presa da [3])
Come sempre un'immagine vale più di mille parole. Quella qui sopra ci mostra come sia possibile determinare cosa stia succedendo anche se non ne conosciamo la storia istante per istante.
E la cosa più sbalorditiva è che il campionamento è quasi del tutto fedele al modello temporale. Per mostrare questo ho utilizzato una query [4] il cui risultato è il grafico in figura ottenuto con Microsoft Excell
Il grafico mostra la differenza tra misure campionate (ASH) e quelle ottenute in tempo reale (DB Time). In Y c'è il valore di "ASH"/"DB Time", mentre in X lo "snap_id/time stamp"
In realtà, per ottenere questo grafico, ho dovuto eliminare alcuni valori. Sto cercando ancora di capire quali sono le cause che producono tali anomalie.
- Update 31/Mar/2016
Ho modificato l'immagine perché ho eliminato un punto dak grafico. Sto scrivendo un post sulle anomalie che ho riscontrato.
- Riferimenti
[2] http://www.oracle.com/technetwork/database/manageability/twp-40169-134162.pdf
[3] https://sites.google.com/site/embtdbo/wait-event-documentation/ash---active-session-history
http://blog.orapub.com/20150812/Which-Is-Better-Time-Model-Or-ASH-Data.html
[4] http://www.evernote.com/l/ABzQFwwMxo5HyKs8pmpIcyVjmjH7vreMvVo/
Nessun commento:
Posta un commento