Shared Memory Verwaltung in Oracle 11g

In der Historie der letzten Oracle Datenbank-Versionen hat es einige schrittweise Vernderungen hinsichtlich der Speicherverwaltung gegeben. Ein erster Schritt wurde in Oracle9i mit der Zusammenfassung der verschiedenen ProzessSpeicherbereiche (Sortierbereich, Hashbereich etc.) zu einem Gesamt-Pool gegangen, angesteuert durch den Serverparameter pga_aggregate_target. Mit Oracle 10g wurde dasselbe dann fr den Shared Memory-Bereich angegangen. Die verschiedenen Teilbereiche wie Buffer-Cache, Shared-Pool etc. werden dabei wiederum zu einem Gesamt-Pool zusammengefasst, die zugehrigen Serverparameter heien sga_target und sga_max_target. In beiden Fllen ist neben der automatischen Verwaltung des Gesamt-Pools auch weiterhin eine manuelle Verwaltung der einzelnen Bereiche mglich, oder aber es knnen ber die alten Parameter Untergrenzen fr einzelne Speicherbereiche gesetzt werden. Dies gilt genauso auch fr Oracle 11g. Auerdem ist hier als weitere Mglichkeit hinzugekommen, den gesamten Speicherbedarf der Oracle-Instanz, also SGA und PGA, ber einen einzigen Pool mit den Parametern memory_target und memory_max_target zu steuern. Eine kleine berraschung gibt es bei der Implementierung dieser neuen Technik. In allen DatenbankReleases bis einschlielich Oracle 10g verwendet Oracle nmlich das sogenannte System V-style Shared Memory. Dadurch konnte und kann z.B. ber das Unix-Kommando ipcs berprft oder per Skript ausgewertet werden, ob ein Shared Memory-Bereich aufgebaut wurde und wie gro dieser ist. [root@ora11gr2 ~]# ipcs -m ------ Shared Memory Segments -------key shmid owner perms 0x00000000 65536 oracle 600 0x00000000 98305 oracle 600 0x00000000 131074 oracle 600 0x00000000 163843 oracle 600 0x00000000 196612 oracle 600 0x00000000 229381 oracle 600 0x00000000 262150 oracle 600 0x00000000 294919 oracle 600 0x00000000 327688 oracle 600 0x75fc1f04 285376521 oracle 660 0x00000000 425994 oracle 600
Listing 1: Shared Memory Segmente bis Oracle10g

bytes 393216 393216 393216 393216 393216 393216 393216 393216 393216 348127232 393216

nattch 2 2 2 2 2 2 2 2 2 34 2

status dest dest dest dest dest dest dest dest dest dest

Hier sieht man die SGA mit aktuell 332MB Gre. Die Spalte nattch liefert die Anzahl Prozesse, die sich diesen Shared Memory-Bereich teilen in diesem Falle 34. Dabei handelt es sich um die Serverprozesse sowie Hintergrundprozesse wie DBWR, LGWR etc. Auch ein Performance-Werkzeug wie Quest Performance Analysis for Oracle hngt sich als ein weiterer Prozess an die SGA, um direkt aus dem Speicher Performance-Daten zu erheben. Schaltet man nun in einer Oracle 11g-Datenbank das Automatische Memory-Management (AMM) ein, sprich setzt man memory_target auf einen Wert, z.B. 500M, ergibt sich ein vllig ein anderes Bild: [root@ora11gr2 ~]# ipcs -m ------ Shared Memory Segments -------key shmid owner perms 0x00000000 65536 oracle 600 0x00000000 98305 oracle 600 Patrick Schwanke Seite 1 von 3 bytes 393216 393216 nattch 2 2 status dest dest 26.01.2009

0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x75fc1f04

131074 163843 196612 229381 262150 294919 327688 285442057 425994 285474827 285507596

oracle oracle oracle oracle oracle oracle oracle oracle oracle oracle oracle

600 600 600 600 600 600 600 660 600 660 660

393216 393216 393216 393216 393216 393216 393216 4096 393216 4096 4096

2 2 2 2 2 2 2 0 2 0 0

dest dest dest dest dest dest dest dest

Listing 2: Shared Memory Segmente mit Oracle 11g

Hier taucht die SGA nur noch mit einer Gre von 4KB und ohne angehngte Prozesse auf.

Was ist passiert?

Der Hintergrund hierfr ist, dass es mit dem System V-style Shared Memory Management nicht einfach mglich ist, Speicher zwischen dem monolithischen Shared Memory-Segment und den privaten Speicherbereichen der Prozesse (PGA) zu verschieben. Genau das war aber ja ein Ziel fr Oracle 11g. Daher wechselt die Oracle-Instanz bei Benutzung von memory_target zu einer anderen Verwaltung-Variante auf Betriebssystemebene, dem sogenannten Posix-Style Shared Memory Management. Dieses erlaubt es, Shared Memory in kleine Portionen, sogenannte Granulen aufzuteilen. Diese Granulen knnen dann bei Bedarf bequem einzeln dealloziert und in den PGA-Bereich alloziert werden, um Speicher zwischen SGA und PGA zu verschieben. Leider ist das auf diese Weise verwaltete Shared Memory nicht mittels der blichen Werkzeuge wie z.B. ipcs sichtbar. Stattdessen wird es ber ein virtuelles Dateisystem namens shmfs oder tmpfs verwaltet, das meist unter dem Mountpoint /dev/shm eingehngt ist. Der Shared Memory-Verbrauch via Posix entspricht nun einfach der Belegung dieses virtuellen Dateisystems. [oracle@ora11gr2 ~]$ df -k /dev/shm Filesystem tmpfs 1K-blocks 614400 Used Available Use% Mounted on 335688 278712 55% /dev/shm

Listing 3: Shared Memory Dateisystem

Ein Blick in das Verzeichnis /dev/shm offenbart auch die einzelnen Granulen, die je nach Gesamtgre des Speichers entweder 4MB oder 16MB gro sind. Manche haben auch die Gre 0, dieser Speicherbereich ist aktuell gerade der PGA zugeordnet, kann aber jederzeit in die SGA zurckgeholt werden. [oracle@ora11gr2 ~]$ df ls -la /dev/shm -rw-r-----rw-r-----rw-r-----rw-r----
Listing 4: Verzeichnis /dev/shm

1 1 1 1

oracle oracle oracle oracle

oinstall 4194304 Jan oinstall 4194304 Jan oinstall 0 Jan oinstall 4194304 Jan

5 5 5 5

19:51 19:51 19:51 19:51

ora_PS112_285474827_68 ora_PS112_285474827_69 ora_PS112_285474827_7 ora_PS112_285474827_70

Ntzliche Werkzeuge fr das Troubleshooting sind in diesem Zusammenhang die OS-Kommandos fuser sowie pmap. fuser listet zu einer Shared Memory-Granule die darauf zugreifenden Prozesse auf, z.B.

Patrick Schwanke

Seite 2 von 3

26.01.2009

sbin/fuser -v /dev/shm/ora_PS112_285507596_9 USER oracle oracle oracle

Listing 5: Prozessstruktur

PID 22848 22850 22854

ACCESS COMMAND ....m oracle ....m oracle ....m oracle

Umgekehrt listet pmap die zu einem Prozess gehrenden Shared Memory-Granulen. Fr den Datenbank-Administrator ist es auch wichtig zu wissen, dass vor dem Starten der OracleInstanz das zugrundeliegende virtuelle Dateisystem erst einmal passend dimensioniert werden muss. Ausschlaggebend ist hierbei der Wert fr memory_max_target, der wenn er nicht explizit festgelegt wird, standardmig den Wert von memory_target bernimmt. Beim ersten Anlauf bekommt man hufig folgenden Fehler beim Startup der Instanz: SQL> startup ORA-00845: MEMORY_TARGET not supported on this system
Listing 6: Fehlermeldung beim Starten der Instanz

Entgegen dem Wortlaut der Fehlermeldung ist die Benutzung von memory_target in den meisten Fllen sehr wohl untersttzt. Ein Blick in das Alert-Log gibt genauere Auskunft: [oracle@ora11gr2 trace]$ tail -3 alert_PS112.log Starting ORACLE instance (normal) WARNING: You are trying to use the MEMORY_TARGET feature. This feature requires the /dev/shm file system to be mounted for at least 2097152000 bytes. /dev/shm is either not mounted or is mounted with available space less than this size. Please fix this so that MEMORY_TARGET can work as expected. Current available is 629145600 and used is 0 bytes. Ensure that the mount point is /dev/shm for this directory. memory_target needs larger /dev/shm
Listing 7: Fehlermeldung im Alertlog

Die Lsung besteht darin, das Dateisystem /dev/shm zu unmounten und neu zu mounten, wobei ber den Mount-Parameter size eine hhere Gre spezifiziert wird. [root@ora11gr2 ~]# umount /dev/shm # Anpassen des Eintrags in /etc/fstab, z.B.: # tmpfs /dev/shm tmpfs size=2000m 0 0

[root@ora11gr2 ~]# mount /dev/shm

Listing 8: nderung des Dateisystems shm

Resmee
Oracle hat im Zuge des automatischen Memory-Managements der Version 11g im Hintergrund eine wesentliche nderung vollzogen, was die Speicherverwaltung auf Betriebssystem-Ebene angeht. Dies beeinflusst zum einen die Vorarbeiten fr die Inbetriebnahme einer Datenbank. Zum anderen wirkt es sich auch auf Troubleshooting-Prozesse aus, z.B. mssen bei der Diagnose auf Betriebssystemebene andere Kommandos verwendet werden. Hat man den neuen Mechanismus erst einmal verstanden, ist das Verhalten der Oracle-Instanz insgesamt aber logisch und konsequent.

Patrick Schwanke

Seite 3 von 3

26.01.2009