Performanceoptimierung bei komplexen Abfragen

[mike]

Grüssi!

Hab eine frage bezüglich optimierung von selects auf eine (oracle) db.

der select geht über 3 tabellen mit einigen x 100tausend ds.
und das dauert.
und das ist schlecht so.
und ich soll das ändern.
und ich weiss noch nicht genau wie.

hat wer von euch schlaue seiten in seiner bookmarkliste, die sich mit geschickter indizierung, performancetricks usw. beschäftigen?

thx

lf

p.s. kann leider keine detailinfos bzgl. db angeben. ich bin nur als trouble-shooter gefragt worden und hab keinen einblick in die gesamte db.

[Toxical]

hm ich denk mit den 4 stufen der db optimierung bist du vertraur,.
oder sollst du nur die select's und nicht die db struktur verbessern?

[mike]

4 stufen der db optimierung

meinst normalisierung - oder?

es geht darum was man am select noch drehen kann, um das ding performanter zu machen.
- bringt eine view im laufzeitverhalten geschwindigkeitsvorteile?
- join vs. expliziter verknüpfung (where id=foreignID) ?
- index-tricks,... ?

und so zeuchs halt.

die herausforderung ist diese, dass die jungs eine db angelegt haben, und dann z.b. auf eine tabelle mit über 2000000 ds auf ein artikelnummernfeld abgefragt haben. das hat dann so 2 min gedauert und hat den rest des db-servers in die knie gezwungen.
auf die frage, ob sie denn auch das feldi indiziert haben, kam die antwort: 'was ist denn ein index?!'

bei dem select liegt der hund ein bissl tiefer begraben. indizes sind für die schlüssel und foreigns eigentlich da.
also versuch ich den view ein bissl performanter zu gestalten.

...mit eurer hilfe, wenn möglich...

lf

[Toxical]

Original geschrieben von Longfang

meinst normalisierung - oder?
lf

ja meine ich, ist doch im prinzip das selbe

Puh, kann dir da wohl kaum weiterhelfen, meine db's musste ich nie einer solchen radikal Performance Kur unterziehen, von daher hab ich wenig Erfahrungen was die einzelnen Verbesserungen im einzelnen bringen.

[Colin Schlüter]

Hallo!

Kenn mich auch nicht so sehr mit der Query-Optimierung aus, weil ich noch nie so riesige Datenbanken benutzt habe, aber vielleicht hilft dir die Dokumentation weiter:

http://www.mysql.de/documentation/my...ml#Query_Speed

HTH

Colin

[wuselmann]

Mit den Oracles kenn' ich mich auch nicht so sehr aus - kann dir nur empfehlen, Dich an jemanden zu wenden, der sich damit auskennt was bei Oracle-DB's etwas schwieriger ist als bei MySQL. Allerdings wirst Du den wohl leider nicht in den gelben Seite finden

Versuch' es doch mal ansatzweise bei Oracle selbst. Da bekommst Du uU Support und ein paar Tipps, wenn es sich um eine Lizenz handelt, was ich mal denke.

Ansonsten wären Dozenten&Profs von Uni/FH noch eine Lösung. Wenn Du da jemanden kennst? Ansonsten schick mir mal 'ne PM und du bekommst die Mail-Adresse meiner DB-Dozentin.


Holger, der wuselmann

[mike]

Thx.

hat sich erledigt.

perverserweise ist ein verschachtelter subselect schneller als ein join.
irgendwie hat der verdammte select nicht den richtigen index gezogen.

das positive: hab was gelernt, und wir bekommen hoffentlich eine inhouse schulung bezüglich db-tuning *freu*

lf

[Toxical]

Hö? Seit wann darf man in Mysql verschachtelt selecten?
ich mein, praktisch wär es schon

[mike]

sag mal, liest du meine einträge eigentlich oder tust du nur posts schinden

ORACLE toxical nicht mysql (is a spielzeug...)

[Toxical]

Original geschrieben von Longfang
sag mal, liest du meine einträge eigentlich oder tust du nur posts schinden

hab ich wohl uebersehen, tut mir leid.

[mike]

dir sei vergeben. gehe hin in frieden...

[MuschPusch]

ähm hab mich ja ma versucht ueber die "Normalform" schlau zu lesen und die Informatiker von irgendwo haben in 10 Seiten eigentlich doch nur sagen wollen:

Zieh die Sachen auseinander, ich meine pack sie in verschiedene Tabellen wenn sie nicht zusammengehoeren!

Vergib immer einen unique Index!

Lass nie etwas doppelt irgendwo auftauchen...!

Fuer haeufig auftretende Inhalte: mach wieder eine neue Tabelle auf die Du dann wieder verweist...

Die ersten sind ja klar aber bei der letzten kann ich keinen wirklichen Sinn erkennen ausser das man Speicherplatz schafft, dafuer aber nochma extra in ne weitere Tabelle muss bei jeder query....