Guten Morgen,
gibt es eine Richtschnur, wie groß der shared_pool und java_pool bei 4GB Hauptspeicher sein sollte? Kann mir vielleicht noch jemand sagen, wovon die Wahl der Größe abhängig ist?
Danke und beste Grüße
Bozi
Hi!
gibt es eine Richtschnur, wie groß der shared_pool und
java_pool bei 4GB Hauptspeicher sein sollte?
Nein - erst wenn die DB am Laufen ist, gibt’s verschiedenste System-Views, aus denen Du Dir diverseste Werte rauslesen kannst.
Kann mir
vielleicht noch jemand sagen, wovon die Wahl der Größe
abhängig ist?
Ja: von der Applikation bzw. vom „Geschehen“ auf der Datenbank (Zugriffe, gleiche Statements, Anzahl der Statements, Anzahl User, etc. …)
Grundsätzlich gilt: Je größer der Shared Pool, umso besser - aber nicht zu groß (tolle Aussage, was?).
Und die Java Pool Size habe ich teilweise sogar auf 0 runtergedreht (Das Zeugs kommt mir nicht auf die DB 
Wie schon gesagt: Erst, nachdem die DB ein paar Tage „Echt“ gelaufen ist, lassen sich Aussagen treffen, was rauf- bzw. runtergesetzt werden kann; ansonsten gibt’s bei der DB-Installation mit dem Assistenten diesen schönen Punkt, wo Du die Größe des Speichers angibst, den Oracle verwenden darf und dort kannst Du Dir dann die Aufteilung ansehen (dies kannst Du natürlich auch Dummy-mäßig machen, darfst halt dann icht unbedingt auf „Create Database“ drücken
Wenn Dein DB-Server also 4GB RAM hat und nur rein als DB-Server fungiert, dann zieh ein bißchen was für das System ab und die restlichen 3-3,5GB gib Oracle zum Aufteilen …
Grüße,
Tomh
Hallo Tomh,
erstmal vielen Dank für die ausführliche Information! Das Problem ist, bei der Installation einer speziellen Applikation bricht diese mit einem Fehler ab. Der Support der Firma sagte lediglich: „Mal den shared_pool und den java_pool hochsetzen“. Um wie viel liesen sie offen. Hab zwar nachgefragt, aber keine Antwort bekommen.
Aktuell sind die Werte wie folgt:
shared_pool: 80 MB
buffer_cache: 512 MB
large_pool: 12 MB
java_pool: 52 MB
Gesamte SGA: 657,245 MB
Grüße
Bozi
Hi!
Das
Problem ist, bei der Installation einer speziellen Applikation
bricht diese mit einem Fehler ab.
Ah - jetzt wirds interessant (Noch interessanter wäre natürlich auch der Fehler, denn Oracle bringt bei zu wenig Speicher ziemlich _gute_ Meldungen)
Der Support der Firma sagte
lediglich: „Mal den shared_pool und den java_pool hochsetzen“.
Übersetzt: Woher soll ich das wissen? Aber es klingt halt gut.
Aktuell sind die Werte wie folgt:
shared_pool: 80 MB
buffer_cache: 512 MB
large_pool: 12 MB
java_pool: 52 MB
Gesamte SGA: 657,245 MB
Zuerst: Welche DB-Version? 8 oder 9?
Jedenfalls würde ich die share_pool_size mal - wenn möglich - zumindest verdoppeln, genauso die java_pool_size - und weiter probieren (Mir kommt das Verhältnis shared_pool und buffer_cache äußerst dubios groß vor.)
Grüße,
Tomh
Hallo Tomh,
ich hab mal ein „find -name *.log“ gemacht. Der findet zwar etliche Log-Dateien, aber irgendwie steht in keiner was vernünftiges (was auf den Fehler schließen lässt) drin. Kannst Du mir zufälligerweise sagen, wo ich diese Log-Dateien finde?
Das Programm installiert automatisch 10gR1. Die Installation von Oracle erfolgt praktisch durch diese Applikation.
Danke und ein schönes Wochenende!
Bozi
Hi!
ich hab mal ein „find -name *.log“ gemacht. Der findet zwar
etliche Log-Dateien, aber irgendwie steht in keiner was
vernünftiges (was auf den Fehler schließen lässt) drin. Kannst
Du mir zufälligerweise sagen, wo ich diese Log-Dateien finde?
Im Oracle-Verzeichnis ($ORACLE_HOME/admin/$ORACLE_SID/bdump
Und hier vor allem das Alert-File (alert_$ORACLE_SID.log) und die jenes Trace-File, das in den Fehlerzeitpunkt reinfällt.
Das Programm installiert automatisch 10gR1. Die Installation
von Oracle erfolgt praktisch durch diese Applikation.
Na toll - Einser-Releases würde ich im Normalfall nicht mal unter Androhung der Todesstrafe installieren (zu vergleichen mit Windows ohne ServicePacks) - ABER:
Du hast Die Möglichkeit, hier Oracle selber die gesamte Speicherverwaltung zu überlassen, indem Du anstatt den ganzen _Sizes_ nur die SGA_TARGET angibst: Hier gibst Du den gesamten Speicher an, den Du Oracle überläßt („Automatic Shared Memory Management“) und folgende Parameter initalisierst Du mit „0“:
- DB_CACHE_SIZE
- SHARED_POOL_SIZE
- LARGE_POOL_SIZE
- JAVA_POOL_SIZE
- STREAMS_POOL_SIZE
Oracle verteilt den Speicher selber, zwackt vom LargePool was ab, wenn es im SharedPool mehr braucht, gibt das dann an den JavaPool weiter etc. …
Wenn JETZT noch ein Fehler auftritt, dann wird’s jedoch haarig …
Einen Versuch ist es jedoch wert …
Grüße,
Tomh
Hallo Tomh,
also…im alert-log steht folgendes (hab nur mal den Schluß genommen, sonst wird es zu lange):
Successful open of redo thread 1
Fri Jul 11 09:23:18 2008
SMON: enabling cache recovery
Fri Jul 11 09:23:18 2008
Successfully onlined Undo Tablespace 1.
Fri Jul 11 09:23:18 2008
SMON: enabling tx recovery
Fri Jul 11 09:23:18 2008
Database Characterset is WE8ISO8859P15
Fri Jul 11 09:23:18 2008
Starting background process QMNC
QMNC started with pid=10, OS id=11122
Fri Jul 11 09:23:18 2008
replication_dependency_tracking turned off (no async multimaster replication found)
Fri Jul 11 09:23:18 2008
Starting background process MMON
Starting background process MMNL
MMON started with pid=11, OS id=11124
MMNL started with pid=12, OS id=11126
Fri Jul 11 09:23:18 2008
Completed: ALTER DATABASE OPEN
Im letzten Trace-Log steht:
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /opt/fiscus/osoft/dbsoft/10.1.0
System name: Linux
Node name: osadbt
Release: 2.6.5-7.244-bigsmp
Version: #1 SMP Mon Dec 12 18:32:25 UTC 2005
Machine: i686
Instance name: ORACLE
Redo thread mounted by this instance: 0
Oracle process number: 0
11046
*** SERVICE NAME:frowning:) 2008-07-11 09:22:46.762
*** SESSION ID:frowning:318.1) 2008-07-11 09:22:46.762
OPIRIP: Uncaught error 1089. Error stack:
ORA-01089: immediate shutdown in progress - no operations are permitted
osadbt:/opt/fiscus/osoft/admin/ORACLE/bdump # cat oracle_ora_11018.trc
Du/opt/fiscus/osoft/admin/ORACLE/bdump/oracle_ora_11018.trc
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /opt/fiscus/osoft/dbsoft/10.1.0
System name: Linux
Node name: osadbt
Release: 2.6.5-7.244-bigsmp
Version: #1 SMP Mon Dec 12 18:32:25 UTC 2005
Machine: i686
Instance name: ORACLE
Redo thread mounted by this instance: 0
Oracle process number: 0
11018
*** SERVICE NAME:frowning:) 2008-07-11 09:21:45.249
*** SESSION ID:frowning:314.1) 2008-07-11 09:21:45.249
OPIRIP: Uncaught error 1089. Error stack:
ORA-01089: immediate shutdown in progress - no operations are permitted
Grüße
Bozi
Hallo bozi,
ich übernehme hier mal von Tom
also…im alert-log steht folgendes (hab nur mal den Schluß
genommen, sonst wird es zu lange):
[…]
Das ist leider zu wenig. Was da steht ist, dass das starten beim letrzten mal geklappt hat. Suche einmal nach Fehlermeldungen und poste das was so 20 Zeilen davor und danach kommt.
Im letzten Trace-Log steht:
*** SERVICE NAME:frowning:) 2008-07-11 09:21:45.249
*** SESSION ID:frowning:314.1) 2008-07-11 09:21:45.249
OPIRIP: Uncaught error 1089. Error stack:
ORA-01089: immediate shutdown in progress - no operations are
permitted
Die DB fährt runter, deswegen darf man drauf nix mehr machen. Interessant wäre, WARUM sie runterfährt. Such das bitte einmal im Alert raus (Urzeit siehst Du ja hier). Falls das nicht vom DBA angefordert wurde müsste da ein Verweis auf ein Trace-File stehen.
Gruß
Martin