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.

...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ò.

2 giorni con Tom Kyte...

Credo fosse estate o giù di lì quando lessi che Tom Kyte sarebbe venuto a Roma per tenere il suo primo seminario in Italia. Ricordo che come un bambino, ero tutto emozionato all'idea di poter seguire personalmente l'autore di ben 3 libri incredibili (tutti acquistati ovviamente).

Dovevo assolutamente partecipare. Ed infatti mossi mari e monti per cercare di non mancare l'appuntamento. Come a scuola, seduto nell'ultima fila ero armato di auricolari per ascoltare la traduzione in italiano (già, purtroppo ho questa mancanza: l'inglese): non mi sono perso una sola parola di quanto il buon Tom ha detto.

Ma ovviamente dovevo fare qualcosa. Dovevo segnare quel giorno e così alla fine della seconda giornata ho fatto 3 domande.

* Domanda. Come capire se soffro di "Write Consistency" (un effetto collaterale della "lettura consistente" che Oracle mette a disposizione)?
* Risposta. Non esistono particolari tecniche che consentono di individuare se la nostra applicazione è sotto l'effeto del "Write Consistency". L'unico suggerimeto è quello di lanciare una prima volta lo statement dopo aver messo sotto trace la nostra sessione e leggere i corrispondenti valori di "query" e "current" dall'output del file prodotto. Lanciare quindi una seconda volta lo stesso statement e ricontrollare il file di trace prodotto. Se siamo nelle condizioni di "Write Consistency", allora vedremo il valore "current" molto maggiore rispetto al caso precedente. E dovremmo basarci solo sul valore di "current" e non quello di "query", perché i blocchi letti in modo consistente in questo contensto non fanno testo (di fatto possiamo dire che il 95% delle letture sul db avviene dagli undo segment)

* Domanda. La seconda invece è stata relativa ad una cosa che avevo letto sul libro "Effective Oracle by Design". Non so se ricordate, ma ad un certo punto Kyte dimostra che spostare il codice di un trigger in una stored procedure (meglio in un package ovviamente) porta ad un guadagno in performance. Non dice tuttavia il perché di questo miglioramento. Quale occasione migliore della sua stessa presenza per avere una risposta?
* Risposta. Ebbene, ciò che succede è che Oracle esegue il cache del codice PL/SQL delle stored procedure (e quindi dei package) ma non di quello dei trigger. Spostando quindi la logica fuori dal trigger, consentiamo al db di effettuare meno parsing, guadagnando quindi in performance. Questo spostamento del codice fuori dal trigger non sarà più necessario a partire dalla versione 11g in quanto Oracale effetuerà anche il caching del codice PL/SQL di un trigger.

* Domanda. Ed infine una cosa che dovevo assolutamente sapere: quando uscirà il suo prossimo libro.
* Risposta. Purtroppo sembra che non lo abbia ancora finito di scrivere. Ci tocca quindi aspettare.

Ma non basta. Mi sono fatto firmare anche gli ultimi due libri (se riuscivo a trovare quello su 8i, mi sarei fatto autografare anche quello) che aveva scritto.

Insomma un evento eccezionale a cui non potevo assolutissimamente mancare. Che figata. Pensate, da anni seguo ciò che scrive sul suo sito e leggo gli aricoli che scrive su Oracle Magazine ed adesso addirittura ho seguito un suo seminario.

Wow.

Un commento sul corso. La struttura è stata di tipo standard:

Giorno 1
========
1. The Tools I Use
2. All About Binds
3. SQL Techniques
4. Read and Write Consistency

Giorno 2
========
1. Effective Schema
2. 10gR1
3. 10gR2

Come già detto è stato molto bello e direi anche emozionante (almeno per me). La seconda giornata però, mi duole ammetterlo, ha disatteso le mie aspettative. Si è parlato fondamentalmente delle nuove caratteristiche della 10g: utile sicuramente, ma un corso di "New Features" lo possono sostenere tutti. Lui, Tom, poteva puntare in alto anche il secondo giorno ed invece si è limitato a descriverci cosa è stato introdotto nell'ultima release del db e come sfruttare tale caratteristiche.

...e adesso posso dire....io c'ero!!!!! Il prossimo appuntamento, se ci riesco, è il 6-7 Febbraio 2006 a Milano per ascoltare e seguire un'altro mostro sacro: Jonathan Lewis. Quì il link dell'agenda.

Il materiale, slide e codice di esempio, lo si trova sul suo sito nella sezione "Files": il titolo è Denmark_Italy.zip. Spero presto di scrivere presto un resoconto di queste due indimenticabili ed incredibili giornate sul mio sito web.