Automatic Segment Space Management (ASSM) – parte II

giovedì 13 agosto 2009 alle 13:19 | Pubblicato su Installation and Configuration, Performance Tuning | Lascia un commento

Il post su ASSM di ieri come molti altri miei post in questo blog è stato forse un po’ confuso, ma l’ho scritto di getto; io sono un po’ così, disordinato, cerco di migliorare ma spesso comincio a scrivere un post e mi accorgo che mi richiede più tempo e più energie di quante non ne abbia a disposizione. C’è un’altro aspetto, scrivendo un post approfondisco l’argomento per evitare di scrivere cose inesatte, ciò spesso mi porta ad espandere il contenuto del post. Oggi, anche in conseguenza ad un intervento di Mladen Gogala alla discussione su CDOS sul presunto bug di ASSM ho fatto nuove indagini.

Gogala descrive il comportamento di Oracle nel caso descritto come un possibile caso di “dirty read” in quanto un’altra sessione vede cose non committate, infatti la seconda sessione vede nel bitmap che i blocchi sono liberi prima che la prima sessione abbia committato. Durante l’esecuzione dello stesso test ho fatto vari dump del primo blocco della tabella TEST_ASSM, che contiene la bitmap di primo livello per i primi 16 blocchi, e quindi lo stato di occupazione di questi blocchi (i primi tre sono metadata come gia spiegato ieri). Quello che ho visto è che anche in fase di insert i bitmap vengono aggiornati ben prima del commit, presumo che nel momento in cui l’insert cerca di mettere un record in un blocco e in questo non c’è più spazio per l’inserimento Oracle aggiorni subito la bitmap. Anche durante il delete ho osservato lo stesso comportamento. Il caso interessante è quello di un rollback: in questo caso non ho visto aggiornate le bitmap, che indicavano sempre tutti i blocchi “75-100% free”:

0:Metadata   1:Metadata   2:Metadata   3:0-25% free
4:0-25% free   5:0-25% free   6:0-25% free   7:0-25% free
8:0-25% free   9:0-25% free   10:0-25% free   11:0-25% free
12:0-25% free   13:0-25% free   14:0-25% free   15:0-25% free

quando invece ovviamente erano pieni. Completato il rollback nel dump della bitmap dei primi 16 blocchi risultava ancora tutto lo spazio libero. A questo punto ho lanciato un insert da una terza sessione (dalla seconda facevo i dump) e tale insert con una certa mia sorpresa è durato circa due minuti e mezzo,  mostrando alla fine le seguenti statistiche (vedi nota 1):

Statistiche
——————————
231  recursive calls
152993  db block gets
52  consistent gets
57140  physical reads
4730468  redo size

Dopo meno di un minuto dal lancio dell’insert, quindi ben prima che terminasse ho fatto l’ennesimo dump dello stesso blocco contenente la bitmap dei primi secici blocchi e a questo punto risultava aggiornato indicando tutti i blocchi pieni:

0:Metadata   1:Metadata   2:Metadata   3:FULL
4:FULL   5:FULL   6:FULL   7:FULL
8:FULL   9:FULL   10:FULL   11:FULL
12:FULL   13:FULL   14:FULL   15:FULL

I successivi insert sono più veloci (infatti a questo punto le bitmap sono aggiornate).

In verità confrontanto i vari dump una differenza si nota nel blocco contenente la bitmap di secondo livello (il blocco di tipo: SECOND LEVEL BITMAP”). In questo blocco infatti vi è una sezione che elenca l’indirizzo di tutti i blocchi contenenti le bitmap di primo livello:

L1 Ranges :
——————————————————–
0x04485e89  Free: 2 Inst: 1
0x04485e91  Free: 2 Inst: 1
0x04485e99  Free: 2 Inst: 1
0x04485ea1  Free: 2 Inst: 1

Il primo campo è il dba (Data block address del blocco, Inst suppongo indichi l’istanza che ha modificato il blocco (il mio test non è in ambiente RAC ed ho visto sempre 1). Non so cosa significhi “Free”, ho visto solo i valori 1,2 e 5.

Prima ancora, sembre nella bitmap di secondo livello vi è un’altra sezione fatta così:

Dump of Second Level Bitmap Block
number: 385     nfree: 250     ffree: 128    pdba:     0x04485e8b
Inc #: 0 Objd: 126227

Number:385 sono i blocchi contenenti le bitmap di primo livello, così suddivisi:

  1. 8 per i primi 16 extent (da 8 blocchi l’uno, quindi un BMB ogni 16 blocchi)
  2. 124 per i successivi 63 extent (da 128 blocchi l’uno, quindi un BMB ogni 64 blocchi)
  3. 1 per il successivo extent (da 128 blocchi, quindi un BMB per 128 blocchi)
  4. 252 per gli ultimi 63 extent (da 1024 blocchi l’uno, quindi un BMB ogni 256 blocchi)

Non l’ho detto ma la tablespace utilizza l’allocazione automatica degli extent.

pdba:     0x04485e8b è il dba del blocco “parent”, è il blocco di tipo “PAGETABLE SEGMENT HEADER”

nfree: 250     ffree: 128  sembra no due contatori che indicano in qualche modo il numero di bitmap con spazio libero, ma non so esattamente cosa significhino. il valore che riporto è quello del dump eseguito dopo il “clean-out” ovvero l’insert eseguito dalla terza sessione dopo il rollback, prima di tale clean out è  nfree: 385     ffree: 0

Nel dump effettuato durante l’insert c’è number: 165     nfree: 3       ffree: 161

Insomma, come si vede i meccanismi che ci sono dietro ogni operazione sono complessi. Non ho testato ancora il comportamento con una tablespace MSSM ovvero con gestione dello spazio libero per i segmenti basato su freelist, che forse in questo caso veramente molto particolare si comportano meglio (ma diventa importante configurare correttamente i parametri PCTUSED, FREELIST E FREELIST GROUPS. Thomas Kyte nel suo libro dedica alcune pagine del suo ultimo libro a questo argomento.

Nota 1:

L’insert eseguito da una seconda sessione senza fare ne commit ne rollback dalla prima sessione che ha fatto il delete mostra queste statistiche:

Statistiche
——————————
920  recursive calls
83346  db block gets
69437  consistent gets
69292  physical reads
888  redo size

L’ho eseguito due volte e le statistiche sono simili. La tabella ha in tutto 72704 blocchi

P.S.

Ho scoperto che WordPress.com mi lascia caricare doc e jpeg ma non file txt, quindi ho caricato qui un file txt con un tracciato dei miei esperimenti.

Lascia un commento »

RSS feed for comments on this post. TrackBack URI

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Blog su WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: