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.