Die Oracle-Datenbank ist sehr, sehr mächtig und kann sehr genau konfiguriert und optimiert werden. Oracle hat aber auch die Fähigkeit sich selbst zu optimieren. Um die Datenbank einpendeln zu lassen, ist dies auch vollkommen problemlos. Wenn man sich allerdings mit Fehlern wie dem folgenden konfrontiert sieht, dann muss man etwas ändern.
Errors in file /u01/app/oracle/admin/.../bdump/....trc:
ORA-00604: Fehler auf rekursiver SQL-Ebene 1
ORA-04031: 32 Byte des Shared Memorys konnten nicht zugewiesen werden
("shared pool","select count(*) from sys.job...","sql area","tmp")
Shared Memory…
Es ist kein sehr gut gehütetes Geheimnis, dass die Speicherverwaltung von Windows und Linux nicht ganz perfekt ist. Das sagt Oracle jedenfalls und erklären das Verhalten ihres Datenbanksystems eben damit. Fest steht, dass dieser Fehler nicht mehr auftritt, wenn man an der Oracle-Speicherverwaltung etwas ändert. - Der Speicher muss manuell zugewiesen werden!
Die dynamische Voreinstellung liefert für dieses Vorhaben die perfekte Grundlage, denn Oracle hat den ‘optimalen’ Punkt bereits gefunden.
Arbeitet die Datenbank mit dem ’spfile’, so muss, nach erfolgter sys-Anmeldung, ein ‘pfile’ kreiert werden.
CREATE pfile FROM spfile;
Für den Fall, dass man sich nicht sicher ist, hilft ‘show parameter spfile‘, um zu sehen ob und wo ein ’spfile’ existiert. Ist die Ausgabe leer, so arbeitet das System mit einem pfile. ‘show parameter pfile‘ zeigt auch hier wo selbiges zu finden ist.
Nun kann das ‘pfile’ händisch bearbeitet werden.
Aber Vorsicht!!! - Nicht das ’spfile’ bearbeiten!
Auch wenn es nicht so aussieht - es ist mit, für den Texteditor nicht unbedingt sichtbaren, Steuerzeichen versehen. Bearbeitet man diese Datei, wird sie unbrauchbar. Daher: Nur das (erstellte) ‘pfile’ bearbeiten!
Das ‘pfile’ befindet sich im Falle von Unix/Linux unter ‘$ORACLE_HOME/dbs’ und unter ‘$ORACLE_HOME/database’ bei Windows. Der Dateiname sieht wie folgt aus:
init$SID.ora - $SID ist hier die Variable für die SID
Im oberen Teil der ora-Datei befinden sich die ‘optimalen’ Speicherwerte in der Form ‘$SID.__db_cachesize=…’. Damit die Werte (manuell) aktiviert werden, muss die Notation geändert werden. Hier ein Beispiel, welches auch als Template genutztwerden kann. (Auf dem System sind 8GB RAM, 4 Prozessoren und zwei binäre Datenbank-Installationen vorhanden.)
*.db_cache_size=1500M
*.java_pool_size=64M
*.large_pool_size=32M
*.shared_pool_size=1500M
*.streams_pool_size=128M
‘*.’ ist in RAC-Umgebungen sinnvoll. Da diese Schreibweise hier allerdings auch nicht stört, behalte ich diese bei!
Um die dynamische Speicherverwaltung abzuschalten muss nur ‘*.sga_target’ auskommentiert werden. (’sga_max_target’ auch, so es vorhanden ist.)
Nach dem das ‘pfile’ gespeichert wurde, muss die Datenbank herunter gefahren werden (shutdown immediate).
Im Falle der Verwendung eines ’spfiles’, muss das vorhandene spfile ‘entfernt’ werden. Der gesündeste Weg ist dabei sicher die Umbenennung oder die Verwendung von gzip, was dann wohl die genialere Lösung sein dürfte.
Also:
cd $ORACLE_HOME/dbs
mv spfile$SID.ora spfile$SID.ora.bak
oder
gzip spfile$SID.ora
Nun kann die Datenbank wieder angestartet werden und da selbige kein ’spfile’ findet, wird alternativ das ‘pfile’ verwendet. Mit ‘show parameter spfile‘ kann man prüfen, ob dem wirklich so ist und wenn, dann wird ein neues ’spfile’ erstellt.
CREATE spfile FROM pfile;
Ein weiterer Neustart und die Speicherverwaltung ist nicht mehr dynamisch.
shutdown immediate
startup
Nun kann und sollte getestet werden, ob die Oracle Datenbank wirklich wieder mit dem ’spfile’ arbeitet. Das wird auf gewohnte weise geprüft:
show parameter spfile;
Die Erfolgsbestätigung, dieser ganzen Aktion, kann man sich einholen, indem man nun die manuell gesetzten Werde abfragt:
show parameter ‘db_chache_size;
Was vormals mit ‘0′ bestätigt wurde, gibt nun die definierten Werte zurück.
Die Schlussfolgerung: Geschafft! …und der ’shared memory’-Fehler sollte damit der Geschichte angehören.
Nachtrag:
Diese ‘Anleitung’ ist nur ein Leitfaden und sollte ausschließlich von DBAs genutzt werden, die jeden Schritt nachvollziehen können und wissen was sie tun. Die Speicherverwaltung von Oracle ist nicht gerade trivial und so sollte jeder, der unsicher ist, lieber die Finger davon lassen!
Für Schäden, die gegebenenfalls auftreten können, trägt immer der Verursacher - der Admin/DBA - die Verantwortung!
Schlagworte: Optimierung, Oracle