Skjulte parametre bak PGA_AGGREGATE_TARGET

PGA_AGGREGATE_TARGET er en av disse litt underligge parametrene, som alle stort sett gir en verdi uten og helt forstå hvordan den virker. Hvis jeg f.eks. setter pga_aggregate_target til 256M, hva betyr egentlig dette? De fleste kjenner til at oracle oppfatter dette som et “målbilde”(target), men definitivt ikke en absolutt øvre grense. Det betyr at når Oracle har behov for dette, vil det allokerte minne til PGA overstige 256M. Men hva om jeg var alene på databasen og kjørte en eneste stor SQL i en enkelt sesjon (f.eks. en stor sortering)? Hvor mye minne vil denne få allokert? Man skulle kanskje tro at denne ene prosessen ville få de fulle 256M. Men – det stemmer ikke. Så her må det være noe mer. Hva om jeg utfører en hash join og en sortering, og dermed har behov for flere slike områder innenfor samme prosess? Skal vi kunne håndtere PGA på en effektiv måte, bør vi også ha en formening om hvordan disse mekanismene fungerer.

Det finnes flere skjulte parametre som påvirker hvordan minne håndteringen i PGA (Program Global Area) utføres. Dette er minneområder som benyttes ved sortering, hash joins og bitmap sammenslåinger (merges). Når vi bruker dedikerte server prosesser (som vi stortsett alltid gjør) vil også UGA (User Global Area) bli allokert i PGA området. I UGA området allokeres minneområder for å holde cursorer og annen sesjons informasjon. Men allikevel er det sorteringer og hash joins, som vil være mest plasskrevende og sette krav til minne i vårt PGA område.

Det er ofte sånn at det bak en init parameter finnes flere andre skjulte parametre (også kalt underscore parametre – fordi disse starter med en ‘_’). De skjulte parametrene knyttet til pga_aggregate_target er _pga_max_size, _smm_max_size og _smm_px_max_size. Størrelsene på disse tre vil være avhenigig av størrelsen på pga_aggregate_target. Algoritmene for hvordan disse størrelsene settes, har endret seg med de ulike versjonen fra versjon 9 til og med versjon 11. _pga_max_size begrenser hvor mye av PGA en server prosess kan benytte. Hvis vi i versjon 11.2.0.2 setter pga_aggregate_target til 256M, ser vi at vi får følgende verdier for de relaterte parametrene:

SQL> r
  1  select
  2  	nam.ksppinm    	Name,
  3  	val.ksppstvl	Value,
  4  	nam.ksppity    	Type,
  5  	val.ksppstdf	Is_default,
  6  	decode(bitand(nam.ksppiflg/256,1),1,'True','False') session_modifiable
  7  from
  8   x$ksppi  nam,
  9   x$ksppsv val
 10  where
 11   nam.indx = val.indx and
 12*  nam.ksppinm in ('pga_aggregate_target','_pga_max_size','_smm_max_size','_smm_px_max_size')

NAME			  VALUE 	TYPE IS_DEFAULT SESSION MO
------------------------- ------------ ----- ---------- ----------
pga_aggregate_target	  268435456	   6 FALSE	False
_pga_max_size		  209715200	   6 TRUE	False
_smm_max_size		  52428 	   3 TRUE	True
_smm_px_max_size	  131072	   3 TRUE	True

Hvis vi varierer pga_aggregate_target (PAT) fra 10M og oppover, vil vi se at _pga_max_size vil bli satt til 200MB helt til PAT når 1GB. På PAT på 2 GB øker _pga_max_size opp til 410M. På PAT på 3 GB øker _pga_max_size opp til 612MB. Når PAT er satt til 4GB øker _pga_max_size opp til 820 MB (Fikk ikke testet med høyere PAT, da jeg ikke fikk satt høyere memory_max_size, pga av størrelsen på /dev/shm).

Parameteren _smm_max_size begrenser hvor mye hvert enkelt minneområdet kan tildeles for en enkelt prosess. Dermed ser vi at _pga_max_size begrenser hvor mye som totalt blir allokert for en enkelt prosess, mens _smm_max_size begrenser hvor mye som kan allokeres til hver sortering eller merge join. Størrelsen på _smm_max_size vil være 20% av PAT opp til en PAT på 256MB. Derfra ser jeg at _smm_max_size blir satt til ca 50% av _pga_max_size.

Parameteren _smm_px_max_size ser ut til å settes til 50% av PAT. Denne parameteren benyttes ved parallel eksekvering, og er med på å begrense på hvor mye minne som kan allokeres til hver parallel tråd i eksekveringen. Hver tråd kan ikke bruke mer enn _smm_px_max_size/(degree of parallelism (DOP)). Begrenseningen som _smm_max_size setter for hver prosess gjelder også ved parallel prosessering. For å sortere fullt og helt i minne må data mengden per PX prosess være mindre enn _smm_max_size OG mindre enn _smm_px_max_size/DOP.

Alle disse tre skjulte parametrene kan settes manuelt. Når vi nå kjenner eksistensen og betydningen av disse parametrene, så har vi også bedre forutsetninger for å analysere problemer relatert til bruk av PGA og verdiene satt for pga_aggregate_target, _pga_max_size, _smm_max_size og _smm_px_max_size.

Post a Comment

Your email is never published nor shared. Required fields are marked *