Oracle Performance

[kerstin]

Hallo,
auf einem Windows- Server habe ich Oracle 9i installiert.

Server :
Windows 2003 Server ( Standard Edition ) SP 1
Intel® Xeon (TM) CPU 2,80 GHz
1 GB Ram

Als Parameter habe ich bis jetzt diese verändert:

Total System Global Area 336665620 bytes
Fixed Size 453652 bytes
Variable Size 125829120 bytes
Database Buffers 209715200 bytes
Redo Buffers 667648 bytes

db_cache_size 209715200
shared_pool_size 67108864

Gibt es noch welche die ich beachten muss, um die Performance der DB zu erhöhen und sind die bis jetzt eingestellten bei der genannten Hardware okay?

Danke im vorraus

[Ulrich Vaid]

Gibt es noch welche die ich beachten muss, um die Performance der DB zu erhöhen und sind die bis jetzt eingestellten bei der genannten Hardware okay?

Danke im vorraus

- Hmmm, die klassische Antwort darauf ist :

Ja, Nein, Vielleicht....

- Ist den die Performance jetzt schlecht ? Was willst du mit der DB machen ? Es gibt viele Parameter, welche die Datenbankperformance beeinflussen, also musst du schon etwas spezifischer werden. Generell sind die Wert so schon ok, aber eben, it depends...


Gruss

[kerstin]

Als Grundlage für die Performancemessung dienen Abfragen, die später von einer Anwendung an die DB gestellt werden. Die Datenbank beinhaltet ersteinmal 200 MB. Die Performance ist bis jetzt noch nicht optimal.
Für weitere Vorschläge wäre ich sehr dankbar. Auch eine Übersicht über die Parameter und welche Bedeutung sie haben würde mir helfen.

Grüße

[Ulrich Vaid]

Als Grundlage für die Performancemessung dienen Abfragen, die später von einer Anwendung an die DB gestellt werden. Die Datenbank beinhaltet ersteinmal 200 MB. Die Performance ist bis jetzt noch nicht optimal.
Für weitere Vorschläge wäre ich sehr dankbar. Auch eine Übersicht über die Parameter und welche Bedeutung sie haben würde mir helfen.

Grüße

- Ich würde folgendermassen vorgehen :

- Definieren, was "gute" resp. "schlechte" Performace ist
- Identifizieren, welche Abfrage Probleme bereiten
- verifizieren, ob diese Abfragen effektiv die gestellte Frage beantworten
- wenn ja : Jeweils Benchmarks erstellen für jeden einzelnen Fall, Tracen der Abfragen und via TKPROF auswerten
- Sinnnvoll wäre sicher, sich mal ins Statspack einzulesen
- Stimmt deine physische Implemention (Indizies ? Partitionierung ? etc)

- Ausser der DB gibt es natürlich, je nach Architekur, noch andere "Felder", welche Engpässe hervorrufen könnten (Netz ? AppServer ?)


- BTW, was bedeutet "Die DB beinhaltet erstmals 200 MB" ?.

Gruss

[kerstin]

Danke für eure Antworten.

Ich habe nun mal Snaphot on Oracle ( Quest ) ausprobiert und das einzige was ich finden konnte war ein Alarm bei :

Flow database block change rate
lock waits are 45, 3 % of non-idle wait time

Vielleicht könnt ihr mir ja sagen was das genau bedeutet, und wie ich es unterbinden kann.

Grüße Kerstin

[Ulrich Vaid]

Danke für eure Antworten.

Ich habe nun mal Snaphot on Oracle ( Quest ) ausprobiert und das einzige was ich finden konnte war ein Alarm bei :

Flow database block change rate
lock waits are 45, 3 % of non-idle wait time

Vielleicht könnt ihr mir ja sagen was das genau bedeutet, und wie ich es unterbinden kann.

Grüße Kerstin

Hallo,

Das kann alles oder nichts bedeuten. Vesuche doch mal folgendes zu machen :

- Identifiziere ein SQL, welches Performance Probleme macht
- Setze eine Session in der TRACE-Modus (ALTER SESSION SET SQL_TRACE = TRUE und ALTER SESSION SET TIMED_STATISTICS=TRUE
- Lasse das SQL in SQLPLus laufen
- Verwende TKPROF, um das entstandene Trace-File zu formatieren
(Das Trace FIle findes du auf dem Server unter .../admin/udump/xxx, beachte das Filedatum)
- Poste das Ergebnis hier


Gruss

Mithilfe dieses Trace-Files lassen sich schon wesentlich genauere Aussagen zu deinem Problem machen.