Effetti di SGA piccola in 10g

giovedì 7 maggio 2009 alle 07:48 | Pubblicato su Installation and Configuration | 2 commenti
Tag: , , ,

Stamattina, leggendo l’ultimo post di Kerry Osborne intitolato “Extremes“, mi è venuto in mente un bizzarro comportamento segnalatomi da un programmatore su un nostro database interno di test qualche tempo fa.

Il database è un 10.2.0.4 su win32, con SGA_MAX_SIZE=SGA_TARGET=432M. La macchina dispone di un GigaByte di RAM che però deve essere condivisa oltre che dal SO e da Oracle, anche a dall’application server, da ciò deriva l’esiguità della SGA. La gestione della SGA è automatica e il risultato di ciò era che la SHARED_POOL aveva all’incirca 60 Mbyte di spazio disponibile.

Il sintomo segnalato dal programmatore era il fatto che una sequence saltava frequentemente blocchi di venti numeri, al punto tale che due chiamate  consecutive della query

SELECT SMIASEQUENCE.nextval FROM DUAL;

davano due numeri con un buco in mezzo di venti, ad esempio la prima chiamata dava 1121 , la seconda 1141. La cosa era un po’ esagerata.  Dopo un po’ di verifiche ho notato il ridotto dimensionamento del database (di cui a dire il vero neanche ricordavo l’esistenza🙂 ) ed ho provato a fare un controllo tramite la vista V$ROWCACHE, la quale ha un riga dedicata proprio alle sequence e che in effetti mostrava un numero crescente di “FLUSH”, ho provato ad aumentare la shared pool, portandola fino un valore minimo di 240 M e le cose sono decisamente migliorate.

2 commenti »

RSS feed for comments on this post. TrackBack URI

  1. Volevo solo chiarire la dinamica dell’accaduto.
    Le sequences sono gestite nella Shared Pool da variabili contatore (una variabile per sequence) e dalla tabella SYS.SEQ$ (una tabella per tutte le sequences, una riga per sequence). Quando la Shared Pool è molto ristretta può succedere che anche queste variabili contatore vengano sacrificate dall’aging LRU della shared pool.
    In condizioni normali il valore raggiunto da una sequence viene ottenuto dalla variabile contatore corrispondente, ma se per aging (o per crash) non è più disponibile, Oracle è costretto a rileggere quanto presente nella tabella SEQ$, che però viene aggiornata solo per multipli del valore di CACHE (nel tuo caso 20).
    Se non si vogliono buchi (dovuti all’aging) basta specificare la sequence come NOCACHE, accollandosi però un degrado delle performance.
    Se si verificano molti flushes a carico degli oggetti sequences della dictionary cache – e credo pure per gli altri oggetti – significa evidentemente che non c’è sufficiente spazio per mantenere in cache tutto che ciò che abbisogna, e aumentare la shared pool è senz’altro la strada giusta.


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: