Aktuelles

Ich bin faul und das ist auch gut so!

Einleitend sei gesagt, dass dieser Blog in seiner Sprachwahl durchaus mit einem Augenzwinkern zu verstehen, fachlich allerdings absolut ernst zu nehmen ist! Man möge es mir bitte nachsehen... ;-) Da ich nun Ihre ungeteilte Aufmerksamkeit habe, erkläre ich worum es eigentlich geht: Ich war in letzter Zeit mit Oracle Datenbank Upgrades beschäftigt. Dies nahm ich zum Anlass, mich mit der Version 12 vertrauter zu machen und legte Hand an das eine oder andere System. Ziel hierbei war es, das System sich selbst pflegen zu lassen, oder wie Oracle es nennt: AMM (Automatic Memory Management). 

Was als erstes zu prüfen ist, um AMM und die Advisor (Advisor sagen einem wie sich was ändert, wenn man was ändert) nutzen zu können:
Der Parameter STATISTICS_LEVEL sollte auf TYPICAL (Default) oder ALL stehen damit die Advisor funktionieren und MEMORY_TARGET muss > 0 sein, damit AMM aktiv ist. Wobei AMM die Advisor für das "Schätzen" und Setzen der optimalen Werte benötigt.

Hier in aller Kürze die Parameter mit den nötigen Werten:

MEMORY_MAX_TARGET:  (mehr sollte es wirklich nicht sein) Dahinter versteckt sich das "Hardlimit" für SGA und PGA zusammen. Folglich kann der Wert so hoch gewählt werden, dass das System gerade eben NICHT swapt. Dieser Wert ist statisch, Oracle benötigt also einen Neustart für Änderungen.

MEMORY_TARGET: (softlimit) Eine Art Minimum-Wert, der bis zum Wert von MEMORY_MAX_TARGET vom System erhöht werden kann. Also ein Minimalwert für SGA & PGA zusammen. Dieser Wert ist dynamisch änderbar bis zu max. MEMORY_MAX_TARGET. Muss >0 sein, damit AMM aktiv ist.

STATISTICS_LEVEL: Der Wert muss auf TYPICAL oder ALL gesetzt sein, damit die Advisor aktiv sind und AMM die optimalen Werte "würfel" kann. Vorsicht mit ALL, es wird viel Protokolliert.

WORKAREA_SIZE_POLICY: Der Wert muss auf AUTO stehen, damit Oracle den PGA dynamisch verwalten kann.

PGA_AGGREGATE_TARGET: Das Softlimit für PGA, wenn MEMORY_TARGET gesetzt ist stellt dieser Parameter ein Minimum dar. Oracle wird den Speicherbereich nicht kleiner machen als dieser Wert vorgibt. Daher wird der Wert für AMM auf "0" gesetzt. Das gibt größtmögliche Flexibilität.

PGA_AGGREGATE_LIMIT: Das PGA Hardlimit. Ist der Wert gesetzt (Minimum 2GB) wird nicht mehr Speicher für PGA allokiert. Sollte mehr benötigt werden folgt ein Abbruch. Für AMM also auch hier der Wert "0". Auch dieses Hardlimit ist statisch. Für eine Änderung muss die DB neu gestartet werden.

SGA_TARGET: Das Softlimit für SGA, wenn MEMORY_TARGET gesetzt ist stellt dieser Parameter ein Minimum dar. Oracle wird den Speicherbereich nicht kleiner machen als dieser Wert vorgibt. Daher wird der Wert für AMM auf "0" gesetzt. Das gibt größtmögliche Flexibilität.

Zum SGA gehören noch weitere Parameter die, bis auf eine Ausnahme, für A(S)MM auf "0" gesetzt werden sollten:
SHARED_POOL_SIZE; DB_CACHE_SIZE; LARGE_POOL_SIZE; STREAMS_POOL_SIZE; JAVA_POOL_SIZE  -> alle auf den Wert "0" setzen

LOG_BUFFER (statisch): Den Wert dieses Parameters nur ändern, wenn man gute Gründe dafür hat.

SGA_MAX_SIZE: Stellt die SGA Obergrenze dar und ist ebenfalls statisch. Also wird dieser Parameter für AMM ebenfalls auf den Wert "0" gesetzt.

Nun ist Oracle in der Lage die Speicherverteilung nach Bedarf anzupassen. Dadurch werden z.B. Programme, die etwas mehr PGA benötigen, nicht mehr abbrechen, sondern kurz angehalten, der Speicher wird umverteilt und das Programm kann weiterlaufen - Es darf applaudiert werden! ;-)

Das war es in aller Kürze – und für die Misstrauischen unter Ihnen, hier noch ein paar zusätzliche Infos:
Zuerst eine schlechte Nachricht, AMM funktioniert leider nicht unter Linux, wenn Huge Pages genutzt werden!

Ein select Kommando um den PGA Advisor um Rat zu fragen:

select pga_target_for_estimate, pga_target_factor, estd_extra_bytes_rw from v$pga_target_advice;

Ein select Kommando um den SGA Advisor um Rat zu fragen:

select sga_size, sga_size_factor, estd_db_time from v$sga_target_advice;

Ein select Kommando Memory Target Advisor um Rat zu fragen:

select memory_size, memory_size_factor, estd_db_time from v$memory_target_advice;

v$memory_dynamic_components -> aktuelle Größen der Strukturen

v$memory_resize_ops -> die letzten 800 Änderungen

EOF ;-)