Automatic Segment Space Management (ASSM)

mercoledì 12 agosto 2009 alle 12:57 | Pubblicato su Performance Tuning | 1 commento
Tag:

Dalla versione 8i (8.1.5, ricostruendo la storia delle versioni dalla documentazione online) Oracle ha introdotto le tablespace “Locally Managed” (LMT) .

Apro una piccola parentesi: per verificare con esattezza la versione  ho controllato la documentazione della versione precedente, la 8.0.5 denominata 8 senza la “i”, nel manuale “SQL Reference” della sezione “CREATE TABLESPACE” non compare la parte “…EXTENT MANAGEMENT”. Ho cercato fra i manuali un documento con l’elenco delle nuove caratteristiche, ma solo con la versione 9i (9.0.1) è stato introdotto un manuale chiamato “New Features” che però è alquanto superficiale. Chiusa la parentesi.

Le “Locally Managed Tablespaces” si distinguono dalla tradizionali “Dictionary Managed Tablespaces” (DMT) in quanto mentre nella DMT le informazioni sui blocchi allocati per gli extent veniva registrato nel dizionario dati, quindi in tabelle della tablespace SYSTEM possedute dall’utente SYS, nelle LMT queste informazioni vengono gestite mediante blocchi riservati all’inizio di ogni datafile compenente una tablespace.  La tecnica utilizzate è definita a mappe di bit (bitmap) ovvero di definisce una mappa di tanti bit quanti sono i blocchi della tablespace e questi bit vengono settati quando i blocchi vengono allocati per un’extent. In questo modo si evitano conflitti nell’accesso a queste informazioni sul dizionario dati e si rendono le operazioni più veloci (compresa la cosiddetta deframmentazione, ovvero l’unione di blocchi liberi adiacenti in questo caso). Da alcuni appunti che scrissi tempo fa mi risulta che prima della versione 9iR2 (9.2.0.1) la tablespace SYSTEM non p0teva essere creata come “Locally Managed”, a partire dalla versione 9.2.0.1 invece è possibile creare anch’essa come LMT, in questo caso non si possono più creare tablespace “Dictionary Managed”, mentre è possibile convertire tablespace Dictionary Managed in Locally Managed.

Questa premessa sulla LMT serve per introdurre la successiva novità:  le tablespace con la gestione automatica dello spazio per i segmenti, ovvero l’Automatic Segment Space Management (ASSM), da cui il titolo del post introdotte con la versione 9i (9.0.1)  come si può dedurre non facilmente dal primo manuale “new features” di Oracle ma meglio ancora (secondo me) confrontando la sezione “CREATE TABLESPACE” del manuale “SQL Reference” della versione 9.0.1 (dove compare la parte “segment_management_clause” e della versione 8.1.7 (ultima release della 8i).

Anche in questo caso la novità è l’introduzione di una bitmap. Nella gestione tradizionale, pre-9i, definita”manuale” , dello spazio dei segmenti (ovvero la tracciatura dello spazio libero nei blocchi per inserire nuovi record) si utilizzano “freelist” ovvero liste di blocchi liberi che soprattutto in caso di elevata concorrenza (tipica degli ambienti OLTP) che possono dare problemi e richiedono un po’ di configurazione (sostanzialmente occorre definire più freelist). La nuova gestione utilizzabile utilizza sembre delle bitmap, a cui sono dedicati dei blocchi all’inizio degli extent. In questo caso la tracciatura è forse anche più precisa della gestione con freelist, in quanto è in grado di dare la percentuale di spazio libero di ogni blocco (a scaglioni, 0-25%, 25-50%, 50-75% e 75-100%);  anche in questo caso si dovrebbero ridurre i conflitti in caso di elevata concorrenza, ma soprattutto si semplifica ulteriormente la gestione eliminando di fatto altri tre possibili parametri specificabili alla creazine di una tabella: PCTUSED, FREELIST e FREELIST GROUPS, come annotato in questo manuale.

Il motivo per cui ho pensato di scrivere questo post è un thread di discussione aperto recentemente su CDOS intitolato:  “Do you use ASSM?“. L’OP riporta dopo qualche post un’interessante caso di test in cui si evidenzia un caso in cui ASSM ha un difetto.  La situazione è questa: si inseriscono in una tabella un sacco di record (piuttosto grandi), si cancellano tutti i record senza committare e da un’altra sessione si inseriscono nuovi record sulla stessa tabella. In questa situazione si osservano prestazioni scarse ovvero la seconda sessione ad ogni insert deve aspettare un tempo notevole.  Incuriosito ho provato a tracciare la sessione per capire il motivo di tale lentezza nell’eseguire singoli insert (lentezza che dalla sessione che ha fatto il delete e non il commit non si osserva).  L’unica cosa che ho capito guardando il trace è che per fare l’insert Oracle si passa quasi tutti i blocchi, singolarmente, quindi si osservano numerosi “db file sequential read”. A fare luce su questo caso è intervenuto Jonathan Lewis, il quale ha spiegato che in pratica la prima sessione aggiorna subito i bitmap del segmento (ho fatto una prova facendo un dump del blocco e pare proprio così),  in questo modo la seconda sessione vede subito che tutti i blocchi hanno spazio libero per l’inserimento (cominciando dal primo extent) e va sul blocco dove però trova la transazione non committata, quindi deve passare al blocco sucessivo e così via, passandosi quindi tutti i blocchi alla disperata ricerca di un blocco libero.  Jonathan Lewis spiega che in passato Oracle aspettava ad aggiornare la bitmap ma questo aveva portato ad un baco per cui poteva accadere che non risultasse spazio libero quando invece c’era. Ho fatto una ricerca su metalink (classic, speriamo rimanga) ed ho trovato la nota  numero 2917432.8 che descrive questo problema (molto sommariamente).

Non ho capito bene il perché la prima sessione non soffra dello stesso problema, la mia ipotesi è che in qualche modo Oracle faccia questo ragionamento,  prendo per buono il primo blocco, tanto la stessa transazione che richiede lo spazio per il nuovo inserimento è la stessa che ha fatto il delete liberandolo, quindi se committa lo spazio c’è se non committa lo spazio non c’è ma neppure serve perchè non viene più fatto l’insert.

il dubbio che avevo prima di pensarci bene era il perché oracle si preoccupasse di trovare un blocco con dello spazio per fare l’insert, ma in effetti Oracle deve preparare in buffer cache un blocco con il nuovo record, in questo modo la stessa sessione poi puo’ interrogare la tabella (senza aver ancora fatto il commit) e vedere il nuovo record inserito; è un meccanismo un po’ complesso, ma indispensabile a garantire il modello READ COMMITTED.

Per capire meglio il tutto ho fatto un po’ di dump dei blocchi di un segmento creato in una tablespace con ASSM, su un 10.2.0.4. La struttura che ho visto è così:  i primi tre blocchi sono usati per tre tipologie di “metadati”, FIRS LEVEL BITMAP, SECOND LEVEL BITMAP, PAGETABLE SEGMENT HEADER. Per ogni segmento (io ho provato solo con HEAP TABLES) c’è un PAGETABLE SEGMENT HEADER, solitamente il terzo blocco, un SECOND LEVEL BITMAP, solitamente il secondo, n FIRST LEVEL BITMAP in dipendenza dal numero di blocchi (extent). Il blocco di tipo PAGETABLE SEGMENT HEADER contiene fra l’altro gli indirizzi (dba , data block address) degli altri Bitmap block e poi la mappa degli extent che appartengono al segmento. Il blocco di tipo SECOND LEVEL BITMAP contiene gli indirizzi dei bitmap block di livello 1. I blocchi di tipo FIRST LEVEL BITMAP contengono in sostanza i bitmap veri e propri, quindi il livello di occupazione per ogni blocco (approfondirò quanti blocchi può “gestire” un singolo blocco di bitmap”).

Si potrebbe approfondire meglio la descrizione della struttura dei blocchi di bitmap per la gestione ASSM, ma va oltre lo scopo di questo post che è quello di porre l’attenzione su un comportamento particolare si ASSM, a sua volta posto in evidenza sul newsgroup CDOS.

1 commento »

RSS feed for comments on this post. TrackBack URI

  1. […] Management (ASSM) – parte II Posted on Giovedì 13 Agosto 2009 by Cristian Cudizio Il post su ASSM di ieri come molti altri miei post in questo blog è stato forse un po’ confuso, ma l’ho […]


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

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: