Statspack, forse non tutti sanno che.....

Conosco qualche DBA che dello Statspack ne ha fatto una ragione di vita, come se da esso si potessero individuare e risolvere tutti i problemi di performance legati ad un'istanza.

Premetto di essere il primo ad utilizzarlo per capire cosa c'è che non va studiando l'output che esso genera. Tuttavia, a mio avviso, Statspack deve essere un punto di partenza e non uno di arrivo.

Forse sarebbe più corretto dire che ne determinare problemi di performance, l'output più che guardarlo, andrebbe letto.

Spero di riuscire a chiarire il concetto.

1. Aggregazione dei dati

La funzionalità di base di Statspack è quella di fare due istatntanee dell'istanza in due momenti diversi; quindi si calcolano le differenze ed ne viene mostrato il risultato.

Questo però comporta un'aggregazione di dati. Purtroppo da un aggregato non è possibile estrarre un particolare.

Faccio un esempio. Se ho 100 palline che pesano 100 grammi, dico che ogni pallina pesa 1 grammo. Ma se di queste 100, 99 fossero nere ed 1 bianca, posso ancora dire che una sola pesa 1 grammo? In questo caso, l'informazione aggragata che tutte insieme pesano 100g non è sufficiente: per determinare il peso di ogni singola pallina devo necessariamente pesarle (i).

In Oracle succede una cosa analoga. L'output di Statspack mi dice che ci sono stati problemi di latching, di hard parsing, etc, ma non mi dice chi ne è stato la causa.

2. Heisemberg

Statspack è scritto in PL/SQL: quando vengono calcolati gli snapshot, vengono fatte query sul dizionario dati. In questo modo, secondo il Principio di Indeterminazione di Heisemberg, Statspak (l'osservatore) influenza l'istanza (l'osservato). Oracle 10g, cambia punto di vista: l'RDBMS stesso popola la base dati di AWR (ii).

3. Metriche inesatte

Fino alla versione 10gR1, le informazioni statistiche di uno statement non vengono aggiornate finché questo non si è concluso (iv). O meglio, la sessione aggiorna le statistiche di session e statement alla fine di ogni "database call" (v). Questo vuol dire che la macchina potrebbe star soffrendo a causa di latch contention, ma il nostro snapshot e relativo report non lo segnalano. 10gR2, ha modificato questo comportamento (v), aggiornando le statistiche ogni 5 sec.

4. Statement fantasma

Se il sistema è particolarmente sotto carico, potrebbe succedere che uno statement venga espulso dalla SQL AREA. In questo caso non sarà presente nello snapshot e quindi nel report (commento in v) (vi)

(i) Optimizing Oracle Performance

(ii) THE SELF-MANAGING DATABASE

(iv) Why you should ignore SQL metrics in Statspack

(v) Scoping
(vi) A problem with Statspack

1 giorno con Joze Senegacnik

Devo essere sincero. Joze Senegacnik mi era del tutto sconosciuto. Forse anche perché da quando seguo più lo sviluppo che l'esercizio, ho perso un pò di visione su quello che è la tematica che riguardante strettamente il DBA.

Cercando in rete però, mi sono reso conto che Senegacnik deve essere uno in gamba, vista la sua presenza su siti di un certo calibro (hotsos, oaktable). E se guardiamo le sue pubblicazioni (non ancora scaricabili), il quadro risulta completo.

Ero quindi molto curioso di partecipare al seminario, anche se mi chiedevo come in un solo giorno (il 13 Settembre 2007 a Milano) potesse parlare degli internals di Oracle.

Se confrontato con i seminari di Kyte e Lewis, quello di Senegacnik, è stato di tutt'altra pasta. Mentre i primi due hanno forinto tools e metodologie, quest'ultimo si è limitato a fare una panoramica delle strutture interne di Oracle. Del resto in 7 ore di corso, non poteva fare altrimenti.

Dal mio punto di vista, il seminario è stato un riassunto di quanto avevo studiato fino ad allora prorpio: gestione della buffer cache, degli undo etc. La cosa interessante che non avevo mai visto è stata la sua discussione su RAC.

C'è da dire comunque che tutto il materiale su cui si è basato è disponibile in rete sul sito di Julian Dyke, nella sezione Presentations. Consiglio gli interessati di leggersi attentamente i documenti che vi si trovano.

Ma vediamo gli argomenti del seminario:

1. Buffer Cache
2. RAC and Cache Fusion, RAC specific wait events
3. SGA and Library Cache
4. Undo and Redo
5. SQL Work Area Memory Management (PGA)

Come dicevo, quanto detto durante il corso, lo si può trovare sul sito di Julian Dyke. Quello che mi è sembrato interreante sono le seguenti cose:

1. Sia in una istanza stand alone che in RAC, esiste una sola versione "corretente" del blocco. Nel caso di RAC, però, ciò significa che se più sessioni eseguono un UPDATE sullo stesso blocco, questo deve girare tra le istanze.
2. Ogni istanza è MASTER per un pool di blocchi. Questo vuol dire che se un'applicazione è connessa ad una istanza I1 che non è master per il blocco richierichiesto, allora i) l'istanza I1, chiederà chi è il master per quel blocco; 2) si farà inviare il blocco in questione; 3) fornirà al client che ne ha fatto chiesta, la versione consistente del blocco.
3. Se un'istanza è lenta a rispondere, tipicamente perché le cpu sono sature, allora viene fatto lo shutdown dell'istanza stessa.

Le tre leggi

To be or not to be (a DBA), that is the question
- Amleto

Qualcuno potrebbe pensare che scomodare addirittura Shakespeare per essere o meno un DBA sia un po eccessivo. Eccentirco forse, ma eccessivo no. Vediamo il perché.

NON essere un DBA è facile. Conosco qualcuno che si spaccia come tale, ma è ben lontano dall'esserlo. Piuttosto, essere un DBA, ha a che fare con il carattere. Ma a questo ci arriveremo.

I DBA, esistono a diversi livelli:

• Chi si occupa di Installazione, Configurazione e Monitoring dell'RDBMS
• Chi si occupa di Backup & Recovery (quì intendo anche Replicazione, Standby DB, etc)
• Chi si occupa di HA (RAC ad esempio)
• Chi si occupa di Performance and Tuning
• Chi supporta lo sviluppo (DBA Applicativo)

Ovviamente esistono anche altri livelli di esistenza, ma mi premeva far capire la complessità dell'universo DBA.

A tutto questo va aggiunto che un DBA deve conoscere:

• il Sistema Operativo, per affrontare problematiche si installazione, performance, tuning, backup
• SQL & PL/SQL, per poter fare interrogazioni mirate sul db sia per il tuining che per il monitoring. Senza tener conto del supporto che deve fornire in qui casi in cui il codice è scritto male
• linguaggi di scripting come bash, perl e tcl/tk, per il monitoring ed il reporting
• linguaggi di programmazione come C/C++ e Java, per affrontare problematiche di installazione, di configurazione, supporto allo sviluppo

non è detto che debba conoscere tutto e bene, ma il "conoscere" sicuramente aiuta.

Cosa fondamentale poi, è che il DBA deve saper ascoltare. Deve saper interpretare le esigenze degli utilizzatori del DB. Deve saper capire quali sono i limiti degli utenti e fornire ove necessario valide alternative. E' per questo, ad esempio, che risulta fondamentale la conoscenza dell'SQL e del PL/SQL.

Il DBA deve avere quindi del carattere per poter sapientemente argomentare pregi e difetti di una soluzione. Il DBA deve aver carattere nel saper riconoscere i propri limiti. Il DBA deve aver carattere nell'ammettere che altri ne sanno più di lui. E soprattutto il DBA deve aver carattere dimostrandosi umile.

Quindi: si può fare il DBA per necessità, lo si puòfare per prestigio o solo per lavoro. Ma soprattutto lo si può fare per passione. La differenza? La differenza è il risultato finale: chi lo fa per passione ha fame di informazioni ed è sempre alla ricerca di nuove sfide da superare.

Un DBA cerca di conoscere le strutture fisiche e logiche degli schemi dei database che gestisce e cerca di comprendere le applicazione che li utilizzano: indaga sui perché di eventuali problemi e fornisce, come detto, valide alternative. Badate bene che "valide alternative" non vuol dire creare un indice o lanciare le statistiche: ci sono già tools che fanno questo. Tom Kyte in un suo interessantissimo thread, spiega bene l'idea (riporto parte della discussione):

Tools apply a set of rule, heuristics (like the things I have in my head after doing it for 15 years)... I can look at a query, and a plan -- and with a KNOWLEDGE of the data (statistics to the software, even more knowledge to a human) -- I can generally "make the query better". Not always, but many times. That is the software does, it applies a series of rules to the queries and suggests (based on rules of thumb) enhancements to the schema or the query that would make it better. I've yet to see any software take a query though and say things like "well, if you remove that non-necessary outer join, use the analytic functions instead it'll run much faster". I see them say "add this index" sort of advice (very basic).

Ma non solo. Un DBA deve preoccuparsi anche e soprattutto della sicurezza dei dati. Spesso si tende a confondere tale termine. Credo che il modo giusto di vedere la cosa sia nel dire che "sicurezza" racchiude in se tre concetti distinti:

• Protezione


• Affidabilità


• Disponibilità
  

La sola mancaza di protezione implica l'assenza delle componenti di affidabilità e disponibilità. Se il dato non è protetto allora possiamo essere certi che prima o poi le modifiche fatte alla base dati andranno perse perché non esiste nesun criterio di garanzia sulle operazioni svolte.

Supponiamo ad esempio di avere uno schema, acceduto dall'applicazione per inviare sms (l'appicazione di produzione), dallo sviluppo per fare i test, dall'esercizio per la manutenzione e dal monitoring per controllare eventuali problemi. In questo caso la probabilità che un danno accidentale si verifichi risulta proporzionale alla grandezza della base dati e dal numero di utilizzatori della stessa.

Che dire: un gran casino.

Ho allora immaginato 3 leggi a cui un DBA deve attenersi. 3 leggi che devono governare la vita di un DB. Un po come le 3 leggi della robotica di Asimov (prima Shakespeare, adesso Asimov: chi mi ferma più):

• Prima Legge: Il DBA deve garantire la sicurezza dei dati. Deve cioè garantire che siano rispettati i vincoli di Protezione, Affidabilità e Disponibilità;
• Seconda Legge: Ogni utilizzatore del db deve modellare la propria base dati secondo le esigenze di performance della sua applicazione, purché queste non contrastino con la Prima Legge;
• Terza Legge: Il DBA deve fornire ogni tipo di supporto agli utilizzatori del database, deve raccogliere le loro esigenze e suggerire valide alternative purché venga rispettata la Seconda Legge;

Vorrei concludere citando Stéphane Faroult, autore di The Art of SQL, edito da O'Reilly. Il libro si rifà, come si evince dal titolo, all'Arte della Guerra di Sun Tzu (questa non ve l'aspettavate, vero?). Nell'introduzione del libro, Faroult scrive:

[...] I realized that the problem of teaching developers how to use database efficiently was similar to the problem of teaching officers how to conduct a war. You need knowledge, you need skills, and you need talent. Talent cannot be taught, but it can be nurtured.

Direi che questa frase calzi perfettamenteanche ai DBA, oltre che agli sviluppatori.

Il Costo è Tempo?

Jonathan Lewis nel suo libro Cost-Based Oracle Fundamentals, nel Cap1 pagina 4 dice:

According to the CPU costing model:
Cost = (
#SRds * sreadtim +
#MRds * mreadtim +
#CPUCycles / cpuspeed
) / sreadtim

where

#SRDs - number of single block reads
#MRDs - number of multi block reads
#CPUCycles - number of CPU Cycles
sreadtim - single block read time
mreadtim - multi block read time
cpuspeed - CPU cycles per second

Translated, this says the following:

The cost is the time spent on single-block reads, plus the time spent on multiblock reads, plus the CPU time required, all divided by the time it takes to do a single-block read. Which means the cost is the total predicted execution time for the statement, expressed in units of the single-block read time.

L’affermazione che il “costo è il tempo” viene ribadito anche sul suo sito, dove aggiunge note al suo libro. La sezione “Cost is time (30th Dec 2005)”, termina infatti con: “Cost is Time – but the units are a bit funny”.

In realtà, come poi Lewis stesso ammette, le cose sono un pò diverse da come sembrano. In un thread del suo Blog infatti, si corregge con la seguente affermazione:

[…] I should have said “resource consumption” rather than cost […]

Di fatto, non possiamo utilizzare il costo di uno statement per dire se è buono o meno. Il motivo di tale affermazione è il risultato di un thread sul sito di Kyte che devo dire essere estremamente interessante.

Il mio personale consiglio è ovviamente di leggerlo. Qui riporto la risposta che Wolfgang Breitling in quel thread da ad una domanda fatta da un lettore:

To those who cling to the illusion that the "cost" of an explained sql is in any way related to the performance, read Tom's lips: "It is not".
The cost is used during the parse to pick one plan among all the ones considered (the one with the lowest "cost"). Once it has served that purpose and a plan is chosen, it is meaningless. In particular, it can NOT be compared to the cost of a another explain. If everything is the same between the two explain, the resulting plans and their costs will be the same. If they are not, then something is different and you can not compare the results anymore.
In pre-Oracle9, the "cost" is roughly equal to the estimated number of logical reads (db blocks needed to find the answer). That estimate of the number of blocks to be visited can be different from reality for a number of reasons, only a few of which could be considered bugs. A lot of the reasons for wrong estimates are due to data distribution and dependencies. That is what Tom refers to a human knowledge about the data which goes far beyond what the optimizer can discern from the statistics. For a presentation I am giving at the Hotsos Performance Symposium (IOUG wasn't interested) I have prepared testcases where the same query on tables with virtually identical statistics returns vastly different numbers of rows to show that it is impossible for the optimizer to come up with accurate estimates and therefore the best plan in all cases.

Cost and execution time are NOT related. There are plenty of examples that prove that they are not. The comparison of costs can only be made by the optimizer while it is parsing a sql and is evaluating different access paths. Once an access path is chosen it is invalid to compare its cost number to that of a different plan and draw any conclusion from it.
When parsing a sql the optimizer, in addition to using the gathered statistics - table as well as system in 9i - the optimizer has to make many assumptions about the data (uniform distribution for example in the absence of histogram data) and if the reality differs from the assumption the plan that came out with the lowest cost based on the assumptions can very well be far inferior to a plan that has a higher cost number (based on the assumptions) but is better suited to the reality and hence performs better. It is a rather far stretch to call the inability of the optimizer to accurately estimate certain characteristics of the data in the database, given limited information, a bug.

...e 2 giorni con Jonathan Lewis

Prima di qualsiasi commento, mi preme fare una precisazione. Per chi ha un "buon" grado conoscenza ed un "ottimo" livello di preparazione, i giorni 6 e 7 Febbraio non hanno rappresentato nulla di nuovo (se ricordo bene, il valore 7 a scuola era l'equivalente di discreto, poi c'era buono (8), ottimo (9) ed infine eccelente (10)).

Ho ritenuto doveroso tale precisazione per fugare il dubbio se questi due giorni fossero stati o meno utili. Se poi consideriamo il privilegio di aver potuto assistere dal vivo ad una lezione tenuta da Jonathan Lewis ( e farsi autografare il libro)....... :)

Bene. Il seminario ha coperto diversi argomenti, tutti legati all'ottimizzatore. La cosa interessante è che Lewis osserva il modo (Oracle) proprio dal punto di vista del CBO. In quest'ottica, allora gli argomenti trattati hanno tutti un filo conduttore:

Giorno1:
======

1. Aritmetica di base del COSTO
2. Meccanismi di JOIN
3. Selettività ed HINTS
4. Come e dove trovare i piani di esecuzione
5. Come leggere i piani di esecuzione

Giorno2:
======

1. Problemi con i piani di esecuzione
2. Uso degli indici
3. Mito degli indici
4. Descrivere i dati

Le informazioni che ha dato sono state davvero tante ed il mio unico rammarico è di non essere andato lì già preparato: diciamo che se avessi letto e studiato il suo libro, probabilmente avrei non solo apprezzato di più il suo intervento, ma sarei riuscito a catturare tutti i suggerimenti durante le due giornate.

In effetti se proprio dovessi muovere una critica al seminario sarebbe quella di essere stato troppo breve se rapportato alla quantità di cose discusse. Come dire: troppo, in troppo poco tempo. Ci sono state infatti cose che non sono riuscito a capire appieno ed altre che mi sono del tutto sfuggite. Ad esempio, non sono riuscito a capire esattamente l'algoritmo di HASH JOIN, anche se ne ho carpito il senso, ma mi è completamente sfuggito il funzionamento del piano di esecuzione di tipo BITMAP.

Lasciando però da parte le cose che mi sono sfuggite (diciamo il 20%), i restanti argomenti li ho trovati davvero utili.

• Non è vero ad esempio che l'ottimizzatore, nel caso in cui deve restituire meno del 5% delle righe, utilizza un indice. Ci sono diversi fattori che influenzano il CBO per la scelta del piano di esecuzione: il parametro DB_FILE_MULTIBLOCK_READ_COUNT, il CLUSTERING FACTOR (CF, da adesso in poi), i parametri OPTIMIZER_INDEX_COST_ADJ (OICA) e OPTIMIZER_INDEX_CACHING (OIC), ad esempio.
• Kyte nei suoi libri indica il fattore di clustering come "grado di disordine di un indice". Lewis ha dato un'altra definizione: "rappresenta la qualità di un indice". Ha inoltre tenuto a precisare che, nel caso in cui il CF approccia al numero di righe, non vuol dire che sia sbagliato. Il fatto è che se cerchiamo valori singoli in una tabella, allora il CF non ha rilevanza: lo ha nel caso in cui, per accedere alla tabella, facciamo un FULL SCAN dell'indice.
• Le statistiche di sistema (quelle raccolte con dbms_stats.gather_system_stats) misurano le performance di un sistema, visto che valutano la velocità di un processore (Mega operazioni al secondo), valutano la lettura media di una lettura singola e di una lettura multi-blocco. In ogni caso ha detto di fare attenzione ad i numeri che ne derivano. Il fatto è che talvolta le statistiche risultano falsate perché i venditori di hardware ottimizzano i loro sistemi per velocizzare l'accesso al disco rendendo ad esempio più veloce la lettura dalla cache (vedi EMC, ad esempio).
• Le statistiche di sistema (quelle raccolte con dbms_stats.gather_system_stats) hanno introdotto un nuovo modo di calcolare il costo. In Oracle 8i, c'era solo l'I/O cost, mentre a partire da Oracle 9i, è stato introdotto il CPU cost. Prima di Oracle 9i, cioè, c'erano due presupposti sbagliati:

1. L'ottimizzatore assumeva che tutte le letture avvenivano da disco

2. Non venivano considerati i tempi di accesso dell'indice e di un FULL SCAN: una lettura singolo-blocco, cioè, pesava esattamente come una lettura multi-blocco

Per tale motivo sono stati forniti i parametri OICA e OIC

E queste sono solo alcuni degli argomenti trattati. Immagginate 2 giorni pieni zeppi di cose da apprendere e soprattutto utili al fine di capire come l'ottimizzatore lavora e su come valutare l'impatto dei parametri messi a disposizione dall'RDBMS per far fare al CBO esattamente ciò che noi vogliamo.

Famiglia e lavoro permettendo, cercherò di pubblicare gli appunti che ho preso durante il seminario. La cosa come potete immaginare non è semplice visto che devo ripercorrere tutte le slide del corso e adattare quello che ho scritto con ciò che lui a detto. Cmq, ci proverò.

Heisenberg Uncertainty Principle

Dopo qualche anno (ormai quasi 7) che lavoro con Oracle, devo ammettere che lo studio di questo database è diventato soprattutto una passione. L'acquisto dei libri tecnici a partire dal 1999, è sempre stato mirato all'approfondimento di Oracle stesso. E non parlo solo di libri specifici (Backup & Recovery, Amministrazione, Performance and Tuning (sopratutto), PL/SQL), ma anche di Sistema Operativi (Unix like), File System e Programmazione C. Ormai ho perso il conto dei soldi spesi.

Ma si sà: gli hobby costano.

Tuttavia, non tutti condividono il mio stesso entusiasmo per Oracle. Qualche giorno fa ho scritto una email a colui che mi ha insegnato le basi di Oracle.

Il suo punto di vista è molto diverso: sostiene che Oracle non è l'unico database e sulla piazza si trovano db che costano meno e sono ugualmente funzionali. Sinceramente non saprei come dargli torto, ma credo che il primo amore non si scordi mai......

--- cut here ---

E’ vero che non conosco altri db se non Oracle, ma devi ammettere che le funzionalità implementate sono valide.

Potrei decantarti le lodi di questo database (la 10g inizia una nuova vita), ma so che saresti in grado di confutarne ogni caratteristica. Ti inoltro allora un
documento (1). Non so se lo hai già visto o letto, ma data la sua particolarità credo sia importante sottolineare lo sforzo fatto degli ingegneri per la realizzazione del software.

Non voglio anticiparti nulla, ti dico solo che non è la prima volta che il principio di intederminazione di Heisenberg viene tirato in ballo. Non sono un’esperto, ma una mia idea me la sono fatta.

La prima volta che ho visto porsi il problema di come effettuare misure corrette per individuare problemi di performance è stato nel libro Optimizing Oracle Performance (libro davvero incredibile. Scritto da Cary Millsap e Jeff Holt ed edito da O’Reilly). In un piccolo riquadro spiegano come sia difficle effettuare misure precise anche in sistemi di calcolo come i computer.

Il fatto poi di dover utilizzare software di terze parti, comporta l’alterazione del database stesso, per cui molte delle misure potrebbero essere imprecise.

In questo senso Oracle 10g ha fatto un passo avanti. A mio avviso ha cambiato la filosofia di approccio all’analisi: l’osservatore non influenza più l’osservto, ma è l’osservabile stesso a fornire le proprie informazioni.

--- cut here ---

(1) Qui il pdf in formato slide.