Automatic Workload Repository (AWR)
AWR la componente che si occupa della RACCOLTA, della MANUTENZIONE, dell'ACCESSO e dell'ELABORAZIONE di una serie di dati (metrics) e statistiche sulle prestazioni del database. Generalmente comunque ci si riferisce ad AWR per indicare meno genericamente il solo "repository" ovvero l'insieme delle tabelle dove vengono salvati i dati. Una delle componenti della CMI comune il processo MMON (Manageability Monitor) il quale in pratica svolge tutte le azioni. A sua volta MMON comprende la "AWR Statistics Collection Facility" ovvero lo strumento di raccolta delle statistiche di AWR. Queste statistiche vengono rese disponibili dal motore Oracle e raccolte appunto da questa "facility" che in alcuni casi le elabora e le mette in strutture chiamate "fixed tables". Le "Fixed Tables" sono strutture di memoria che emulano vere tabelle, nel senso che possono essere interrogate tramite SQL. I dati raccolti in queste tabelle ("Database Performance Statistics") appartengono a tre categorie:
- Valori cumulativi (Cumulative Values) quelli ad esempio che si trovano in V$SESSTAT e V$SYSSTAT, si tratta di valori che vengono raccolti in maniera "cumulativa" dall'avvio dell'istanza e che vengono quindi azzerati ad ogni riavvio
- Metriche (metrics) esse sono definite come il tasso di cambio (rate of change) di alcune statistiche cumulative
- Dati campione, questi dati sono raccolti dalla componente Active Session History (ASH) sampler che in sostanza raccoglie dati campione sulle sessioni attive.
Il tutto si basa su quella componente di Oracle gi esistente dalla versione 7 e chiamata "Oracle Wait Interface" (OWA). Solo che in Oracle 10g questa componente stata arricchita con maggiori dettagli. La ver novit, quello che fa AWR cio fare alcune elaborazioni su questi dati, raccoglierli automaticamente a intervalli regolari e salvarli in maniera permanente in tabelle del database che risiedono su una nuova tablespace chiamata "SYSAUX". La configurazione di default prevede che AWR faccia una foto (Snapshot) di tutti questi dati ogni ora, e poi li mantenga per 7 giorni, dopo di che vengono sovrascritti (se lo spazio sulla tablespace necessario).
Seguendo il manuale passiamo a una descrizione delle statistiche raccolte da AWR tramite la loro classificazione in quattro tipologie:
- Wait Events: sono tutte le cose (eventi, attivit) su cui le elaborazioni hanno dovuto attendere del tempo (ad esempio se serve un blocco dati che non gi presente in cache il sistema lancer una chiamata del sistema operativo per prelevare il blocco dal disco, il tempo che la procedura attende perch la chiamata prelevi il blocco dal disco un "evento di attesa", per singoli blocchi chiamato "db sequential read")
- Time Model Statistic: V$SESS_TIME_MODEL and V$SYS_TIME_MODEL danno una panoramica di come viene speso il tempo nel database. Queste statistiche, pi generali, non erano disponibili nelle versioni precedenti.
- Active Session History: V$ACTIVE_SESSION_HISTORY. Ogni second ASH raccoglie le informazioni sulle sessioni "ATTIVE" cio le sessioni che non sono in attesa di eventi di tipo idle o sono sulla CPU. Queste informazioni sono rese accessibili tramite la vista V$ACTIVE_SESSION_HISTORY, ma si tratta di un buffer circolare di dimensione fissa, quindi in presenza di forte attivit probabile che le informazioni vengano sovrascritte in breve tempo. In ogni caso tale buffer, o una sua parte a seconda delle dimensioni viene salvato in modo permanente da AWR, e reso consultabile tramite la vista DBA_HIST_ACTIVE_SESS_HISTORY.
- System e Session Statistics V$SYSSTAT and V$SESSTAT
Oltre ai dati sopra descritti AWR raccoglie anche statistiche sugli oggetti del database e informazioni su specifici statement SQL che hanno prodotto un carico particolare sul sistema.
AWR dispone di una API PL/SQL che consiste nel package DBMS_WORKLOAD_REPOSITORY che prevede le seguenti procedure:
- CREATE_SNAPSHOT
- DROP_SNAPSHOT_RANGE
- MODIFY_SNAPSHOT_SETTINGS
- CREATE_BASELINE
- DROP_BASELINE
AWR pu tranquillamente essere visto come una evoluzione di STASTSPACK, infatti prevede anche degli script per generare dei report, in formato testo normale o HTML che ricordano appunto i report generati da STATSPACK. Lo script principale per generare tali report $ORACLE_HOME/rdbms/admin/awrrpt.sql che funziona in modo analogo a $ORACLE_HOME/rdbms/admin/spreport.sql.
I dati di AWR sono consultabili tramite una serie di viste, V$ per le metriche e DBA_HIST_ per i dati complessivi (nella mia istanza di sviluppo ne conto 78), mentre in ultima istanza sono memorizzati in tabelle che hanno come prefisso WRM$_ (per i metadati, ne conto 5) , WRH$_ (per le statistiche vere e proprie, ne conto 94) e WRI$_ (dati collegati agli "advisor" ne conto 63).
Server Generated Alerts
Un'altra componente di CMI si occupa in pratica di monitorare il database alla ricerca di problemi per poi segnalarli in modo tempestivo affinch possano essere prese le contromisure necessarie. Queste segnalazioni vengono definite "server-generated alerts e sono di due tipi:
- basate su soglie (threshold alerts), si basa sulle metriche calcolate (ogni minuto) da MMON
- non basate su soglie (non-threshold alerts), si basano su alcuni eventi generati dal database, ad esempio alcuni errori ORA-
Automatic Routine Administration Tasks (Automatic Maintenance Tasks)
La terza componente di CMI si occupa di automatizzare una serie di compiti di "routine" eseguiti dai DBA. Infatti pare che alcune indagini abbiano calcolato che in tali attivit venga speso il 50% del tempo.
Raccolta automatica delle statistiche
Oracle da un bel po' spinge per l'utilizzo del CBO e dalla versione 10g ha tolto il supporto per RBO, quindi ha completato tale transizione automatizzando il pi il possibile la raccolta delle statistiche su cui CBO si basa. Le statistiche usate dall'ottimizzatore sono di quattro tipi:
- Dictionary Statistics, nuove, statistiche sugli oggetti componenti il dizionario dati
- System Statistics, si parla delle statistiche visualizzate tramite V$SYSSTAT eV$SESSTAT
- Operating System statistics, nuove in 10g, vizualizzabili tramite V$OSSTAT
- User-defined statistics. siccome oracle supporta anche la struttura ad oggetti permette anche di conseguenza la definizione di statistiche personalizzate.
Alla creazione del database viene creato un job, chiamato GATHER_STATS_JOB che invoca la procedure DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC, che simile a DBMS_STATS.GATHER_DATABASE_STATS con il parametro GATHER=AUTO ma in pi da priorit agli oggetti senza statistiche o con statistiche "stale". Questo JOB viene fatto girare in una finestra temporarle nello scheduler chiamata "Maintenance Window" che si apre dalla 22:00 alle 06:00 di tutte le notti dei giorni lavorativi e per tutta la giornata per sabato e domenica.
Volendo possibile sospendere la schedulazione (o programmazione per usare un termine italiano pi adatto) con la funzione DBMS_SCHEDULER:DISABLE:
BEGIN;
DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');
END;
Infine un rapido cenno alla possibilit di "bloccare" il ricalcolo delle statistiche usate dall'ottimizzatore per determinati oggetti :
DBMS_STAT.LOCK_TABLE_STATS
Monitoring DMStable changes
Prima della versione 10g esisteva la clausola [NO]MONITORING delle istruzioni CREATE TABLE/ALTER TABLE. Quando si attivava in questo modo il monitoring, Oracle registrava la "quantit" di dati modificati nella tabella con DML, questo per capire quando era ora di aggiornare le statistiche. Dalla 10g tale metodo stato disattivato, deprecato e sostituito. Infatti in 10g il settaggio del parametro STATISTICS_LEVEL che attiva il controllo/conteggio della quantit di modifiche ai dati degli oggetti, rendendo quindi inutile l'attivazione esplicit di questa funzionalit. A parte la modalit di attivazione, la funzionalit rimane simile a prima, le viste di sistema che permettono il controllo di queste informazioni sono [DBA|ALL|USER]_TAB_MODIFICATIONS.
Il parametro di sistema STATISTICS_LEVEL accetta come valori BASIC, TYPICAL E ALL. TYPICAL il settaggio di default ed quello che attiva buona parte delle caratteristiche e funzionalit fin'ora descritte. Alcune specifiche funzionalit possono essere attivate a livello di sessione, per questo possibile avere informazioni tramite la vista V$STATISTICS_LEVEL
Advisory Framework (infrastruttura di consiglieri?)
Questa la parte finale del CMI, quella che dovrebbe contenere "l'intelligenza". Si tratta di un insieme di servizi che anallzzano ciascuno uno specifico gruppo di statistiche ed elaborano delle segnalazione e dei consigli.
Automatic Database Diagnostic Monitor (ADDM)
Diciamo che il capo di tutti i consiglieri, esso lavora in automatico continuamente controllando i dati elaborati da AWR e sulla base di tali dati elabora avvisi e reccomandazioni, esso lavora collaborando con gli altri consiglieri (advisors).
The Segment Advisor
Questo advisor analizza la frammentazione dello spazio per i segmenti e suggerisce quando lo ritiene utile le manovre di ricompattamento
The Undo Advisor
Questo advisor controlla il corretto dimensionamento dello spazio di UNDO ed il suo utilizzo.
The SQL Tuning Advisor
Questo advisor analizza i singoli statement SQL a fornisce suggerimenti per migliorarne le prestazioni. Esso pu essere lanciato manualmente su specifici statement e viene lanciato da ADDM su quegli statement che hanno richiesto molte risorse.
The SQL Access Advisor
Questo advisor analizza il carico SQL determinato da uno o pi statement SQL e suggerisce strutture di accesso pi appropriate per migliorare le prestazioni. Generalmente si parla di Materialized Views e Indici.
The Memory Advisor
Analizza l'uso delle varie componenti della SGA e della PGA e fornisce suggerimenti sul loro dimensionamento. Esso funziona nel caso non si utilizzi Automatic Shared Memory Management (ASMM)
Tutti gli advisor sono accomunati dal fatto di avere una interfaccia di accesso simile e di basarsi su AWR. Ovviamente il metodo di accesso consigliato tramite EM Database Control che fornisce un'interfaccia grafica di facile utilizzo. In alternativa gli advisor possono essere attivati da MMON, in risposta a particolari scoperte. Un terzo metodo di invocazione di un advisor in risporta a un Server Alert. Infine vi l'API PL/SQL: il package DBMS_ADVISOR
ADDM pu anche essere utilizzato in modo simile a statspack e AWR per la generazione di report, attraverso lo script SQL @$ORACLE_HOME/rdbms/admin/addmrpt.sql
Attraverso il package PL/SQL DBMS_ADVISOR, l'invocazione di ADDM avviene essenzialmente in tre passi:
- creazione del task con DBMS_ADVISOR.CREATE_TASK( 'ADDM', tid, tname, tdesc );
- settaggio dei paremetri, come i due snapshot di riferiemnto: DBMS_ADVISOR.SET_TASK_PARAMETER( tname, 'START_SNAPSHOT', begin_snap );
- lancio dell'esecuzione: DBMS_ADVISOR.EXECUTE_TASK( tname );
Il risultato dell'elaborazione del task pu poi essere esaminato in forma di report attraverso la funzione DBMS_ADVISOR.GET_TASK_REPORT tutte le informazioni sono anche accessibili attraverso una serie di viste di sistema, ad esempio:
- DBA_ADVISOR_TASKS
- DBA_ADVISOR_LOG
- DBA_ADVISOR_RECOMMENDATIONS
- DBA_ADVISOR_FINDINGS
Automatic Database Diagnostic Monitor (ADDM)
ADDM viene invocato automaticamente da MMON dopo ogni AWR Snapshot e analizza quindi le statistiche degli ultimi due snapshot (che per default significa l'ultima ora di attivit del database). Il tutto ruota attorno alla statistica DB_TIME, l'obbiettivo principale diminuire DB_TIME.
Nel manuale si raccomanda di settare il parametro di default per ADDM DBIO_EXPECTED tramite la procedura:
EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(
'ADDM', 'DBIO_EXPECTED', 8000);
Il concetto fondamentale rimane quello del tempo perch alla fine l'obbiettivo che si vuole raggiungere quello di ottenere dei risultati nel minor tempo possibile.
Tutte le stastiche raccolte da AWR permettono (anche se non con precisione assoluta) di conoscere dove viene impiegato il tempo di elaborazione, quanto sulla CPU, quanto sull'I/O ecc ecc.
Il risultato dell'elaborazione di ADDM sono un insieme di FINDINGS, RECOMMENDATIONS e RATIONALES dove:
- FINDINGS sono i problemi rilevati
- RECOMMENDATIONS sono i suggeriementi elaborati che possono anche consigliare l'invocazione di un advisor specifico
- RATIONALE sono le spiegazioni per le recommendations.
SQL Tuning Advisor
| < Prev | Next > |
|---|
Feed Articoli
