Oracle auf Multiprozessor-Systemen

[michaelmeier]

Hallo zusammen,

kurze Frage zum Thema Oracle-Server:

Wir betreiben hier eine Applikation, die nen Oracle-Server als Datenbackend hat.

Zum Umfeld:

Server: Sun Fire V890, 6x U-SparcV mit 1,8 GHZ und 32 GByte Hauptspeicher.

OS: Solaris 10

DB: Oracle 10g Enterprise

Die DB als solche ist knapp 800 GByte groß und hängt im SAN.

Interessant: wenn Verarbeitungen in der Datenbank laufen, dann wird nur ein Bruchteil der möglichen Performance abgerufen - die CPUs schaukeln sich (platt formuliert) schön was die Eier.

Ich persönlich hätte gedacht, dass die 10g durchaus in der Lage ist, mit Mehrprozessorsystemen umzugehen und diese auch voll zu nutzten. Hängt natürlich stark von der Verarbeitung in der DB ab, aber wenn die CPU-Last nie über 8% steigt, dann dümpelt das Biest nur auf einer CPU rum. That's bad.

Da ich selbst keinerlei Erfahrungen mit DB-Servern habe und das allwissende google zum Thema Oracle auf Mehrprozessorsystemen bzw. Performance nur garstige Informationen zu den Lizenzverträgen raushaut... hat von Euch jemand Erfahrung damit? Gibt es Einstellungen, mit denen Oracle mehr Prozessoren auch tatsächlich verwendet?

Dumm: da der DB-Server von einem externen Dienstleister betreut wird, habe ich keinen Zugriff auf die Administration des Servers. Also ist auch nix mit Config-Files etc.

Hat jemand Erfahrung damit? Oder Vorschläge? Zufällig?

[dr.dimitri]

Ich persönlich hätte gedacht, dass die 10g durchaus in der Lage ist, mit Mehrprozessorsystemen umzugehen und diese auch voll zu nutzten.

Das konnte auch schon die 7er.

aber wenn die CPU-Last nie über 8% steigt, dann dümpelt das Biest nur auf einer CPU rum.

Das hängt jetzt aber nicht von der Db ab. Viel CPU verbrauch bedeutet auch nicht automatisch, dass die Verarbeitung schnell ist. Handelt es sich um einen Batchprozess? Ist die Query entsprechend optimiert sind aktuelle Tabellenstatistiken erfasst? Wenn Oracle z.B. aufgrund felender/alter Tabellenstatistiken einen falschen Plan ermittelt, kann es z.B. sein, dass die ganze zeit nur von der Platte gelesen wird und Oracle nur drauf wartet, dass die Daten häppchenweise kommen. Da kann natürlich auch die CPU nicht ausgelastet werden.

da der DB-Server von einem externen Dienstleister betreut wird, habe ich keinen Zugriff auf die Administration des Servers.

Dann solltest diesem Dienstleister den Auftrag geben deine Session zu überwachen, damit evtl. auftretende Engpässe erkannt werden können.

An Oracle liegt es, rein technisch gesehen, nicht, dass nicht alle CPUs verwendet werden können - es müssen aber natürlich auch die entsprechenden Rahmenbedingungen vorhanden sein.

Wär nicht schlecht, wenn Du noch etwas mehr Informationen über die AW bzw. den Batchlauf etc schreibst.

Dim

[michaelmeier]

Hi,

thx für die Antwort. Ich hatte auch schon überlegt, ob der Oraculus nur auf Nachricht von den Platten wartet - unwahrscheinlich wäre es nicht, da wir seit geraumer Zeit große Probleme mit der SAN-Performance haben.

Bei der Applikation handelt es sich um Bearingpoints Davinci - und natürlich weiß niemand so genau, was das Biest im Hintergrund treibt. Und natürlich was man auch nicht so genau, in welchem Umfang die Applikation auf Parallelisierung getrimmt wurde - da bin ich völlig bei Dir.

Ich sehe: ich muss selbst losziehen und erst noch weitere Infos sammeln. Bzw. selbst ein paar Tests machen, um mal zu schauen, in wie weit man evtl. die Auslastung hoch bekommt.

Ich hatte nur die Hoffnung, dass jemand um die Ecke kommt und sagt, dass man mal hier und da schauen sollte um so schonmal einen ungefähren Anhaltspunkt zu bekommen.

Was die Auskünsfte vom Dienstleister angeht: natürlich sind die Rahmenverträge so super gestrickt, dass die dafür sofort Kohle sehen wollen. Und in Zeiten des Sparens wird die natürlich nicht bewilligt. Da lebt man dann lieber mit miesen Batchzeiten. :upps

Wie gesagt: mehr, wenn ich mehr weiß.

[dbwizard]

Hi,

thx für die Antwort. Ich hatte auch schon überlegt, ob der Oraculus nur auf Nachricht von den Platten wartet - unwahrscheinlich wäre es nicht, da wir seit geraumer Zeit große Probleme mit der SAN-Performance haben.

Wie gesagt: mehr, wenn ich mehr weiß.

- Das würde sich ja relativ einfach herausfinden lassen. Wenn ihr den Enterprise Manager oder das Grid Control benutzt, sind unter Performance die entsprechenden Statistike verfügbar

Gruss

[michaelmeier]

Ja, wenn wir Zugriff darauf hätten... hamma aber nich.

Weil: ist in der Hoheit des Dienstleisters - und der läßt sich nicht in die Karten schauen.

Hier ist nix mit Kurzpassspiel im Mittelfeld... hier gibt's nur die langen Pässe über die Flanken.

Naja, mal schauen, was ich auf dem kleinen Dienstweg erreichen kann.

[dbwizard]

Ja, wenn wir Zugriff darauf hätten... hamma aber nich.

Weil: ist in der Hoheit des Dienstleisters - und der läßt sich nicht in die Karten schauen.

- Aber dann wäre dies ja die Aufgabe des Dienstleisters ? Wir haben bei uns oft auch diese Situation, das ein Hoster die Applikationen im Auftrag des Kunden betreibt, falls solche Situationen auftreten, muss der Dienstleister ja an der Behebung mitwirken.

Gruss

[michaelmeier]

naja, das kommt ganz darauf an, wie die Verträge definiert sind.

Fakt ist: die Maschinen wurden in ihrer jetzigen Form abgenommen - der "Fehler" (also das Issue) nicht registiert und nicht gemeldet. Im nachhinein noch mit Reklamationen zu kommen wird natürlich nicht ganz einfach - das Spiel haben wir schon mehrfach gespielt.

Und die spontane Reaktion "Hey... Provider.. .wirf doch mal nen Blick drauf und sach was dazu..." führt natürlich sofort zu Kosten.

Andererseits: im Januar wird ohnehin alles besser... da gibt's dann ein Projekt zur Performanceoptimierung und der Hersteller der Applikation ist dann auch direkt an Bord. Bis dahin können wir damit auch noch leben...

Wenn sich da etwas ereignet, dann poste ich die Ergebnisse nochmal.

Bis dahin...

[dr.dimitri]

Dann würd ich dir schon mal dieses oder dieses Buch empfehlen, damit Du auch mit- oder besser noch fundiert dagegen reden kannst.

Bei der Gelegenheit könnte man sich ja auch mal andere Provider ansehen, denn besonders kundenfreundlich hört sich deiner jetzt nicht an.

Dim

Bearbeitet 11. Dezember 2008 von dr.dimitri