verwendetes Datenbanksystem: <Oracle 11.2>
Hallo ich versuche eine Datenbank zu optimieren weil die Lesen langsam ist.
meine Datenbank besteht aus 6 Tabellen(siehe Bild)
was ich bis jetzt gemacht habe:
- alle Spalten, die öfter in where Klausel stehen indiziert.
- ein paar fremdschlüsseln indiziert weil sie öfter in joins verwendet werden
aber ich habe auch gelesen, dass wiederum zuviel indexen den datenbank verlangsammen
Den oben verlinkten PDF-Artikel hab ich hier angehängt, wegen [Hinweis] Wie poste ich richtig? Punkt 6.1. analog. Du hättest dafür ruhig 2 Beiträge hintereinander erstellen können.
wieviele Millionen meinst du? Es ist schon entscheident.
@BerndFfm: Viele Indexe können auch das lesen langsammer machen, wenn der Optimizer den falschen Index wählt. Es ist wie immer das maß der Dinge. Nicht zu viel und nicht zu wenig.
@sindibad:
-SQLPLUS und dort mal EXPLAIN deiner SQL Statments eingeben. Wenn eins ein Full-Tablescan macht, must du optimieren.
- FK kosten beim einfügen, etc. Performance.
- Trigger kosten beim einfügen, etc. Performance.
Bei Oracle 8 brachte es performance eine Index nach der häufigkeit von unterschiedlichen werten anzulegen.
z.B.:
create index on Table XXX ON BOOLEAN, NUMBER, DATETIME
(Anhand des Datentypen veranschauliche ich die Möglichkeit von unterschiedlichen einträgen.)
Zu erst die wenigst häufig wechselnden Spalten und zu letzt die am warscheinlichst häufigst unterschiedlichen Spalten.
Manchmal muss man einfach eine Index anlegen nur für eine Spalte. Nur weil das Where über 2 Spalten geht muss der Index nicht über beide gehen. Das muss man messen und Teste.
Fremdschlüssel müssen immer Indiziert werden. Bei einem FK passiert das dann Automatisch. (Bin nicht 100% sicher ob das bei Oracle auch so ist.)
Optimieren kannst du auch indem du das Tablespace für Indexe auf ein Stripeset (Raid 0) legst.
Hast du Blobs in deiner Tabelle? Wenn ja bedeutet das immer ein Read wenn du die "Select * from tabelle" machst. Wenn du Blobs hast bitte immer die Abfragen ohne "*" machen wenn man den Blob nich benötigt., da es sonst immer ein I/O Read bedeutet und somit performance.
Eine umstellungen der SQL Statmens kann auch Geschwindigkeit bringen.
Z.B. Die Ergebnissmenge zu erst klein machen und dann Groupieren.
Ach es gibt einfach zu viele möglichkeiten eine Datenbank zu Optimieren um dir die passende zu liefern. Einfach mal ein gutes Buch lesen.
Zu erst die wenigst häufig wechselnden Spalten und zu letzt die am warscheinlichst häufigst unterschiedlichen Spalten.
muss ich leider auf das heftigste Wiedersprechen! Ein Index ist dann besonders wirksam, wenn das Filterkriterium möglichst weit vorne im Index steht. Bei mehreren Kirterien sollte das Kriterium mit der höchsten Frequenz vorne stehen. Dadurch wird beim Zugriff die Ergebnismenge schon durch den Filter auf das erste Feld erheblich eingschränkt!
Zitat
bitte immer die Abfragen ohne "*" machen
kann ich hingegen voll und ganz unterstüzen. Je weniger man Selektiert desto besser. Viele DB-Systeme beherrschen auch sog. Index-only Zugriffe, d.h., dass falls ein Index alle benötigten Informationen enthält, gar kein Zugriff auf die Tabelle passiert!
Auch das hier
Zitat
Wenn eins ein Full-Tablescan macht, must du optimieren.
stimmt nicht immer. Wenn Du alle oder fast alle Sätze einer Tabelle lesen willst ist der Relation Scan eben der beste Zugriff, den man nicht weite optimieren kann!
Zitat
Ach es gibt einfach zu viele möglichkeiten eine Datenbank zu Optimieren um dir die passende zu liefern. Einfach mal ein gutes Buch lesen.
Ist ein guter Tipp! Einfach nur Indexe über Tabellen zu streuen bringt in der Regel wenig. Wichtig sind vor allem ein gutes DB-Design und vernünftige SQLs. Grundsätzlich kann man annehmen, dass mehr als drei Indexe auf einer Tabelle verdächtig sind. Das heist natürlich nicht, dass es auch Fälle gibt, wo es sinvoll sein kann 30 Indexe auf einer Tabelle zu haben. Allerdings kenne ich kein Beispiel ;-)!
Gruß
f_igy
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von f_igy am .
Zu erst die wenigst häufig wechselnden Spalten und zu letzt die am warscheinlichst häufigst unterschiedlichen Spalten.
muss ich leider auf das heftigste Wiedersprechen! Ein Index ist dann besonders wirksam, wenn das Filterkriterium möglichst weit vorne im Index steht. Bei mehreren Kirterien sollte das Kriterium mit der höchsten Frequenz vorne stehen. Dadurch wird beim Zugriff die Ergebnismenge schon durch den Filter auf das erste Feld erheblich eingschränkt!
Hi du hast recht es war genau anders rum. Sorry war gestern Spät.
Zitat von f_igy
...
Auch das hier
Zitat
Wenn eins ein Full-Tablescan macht, must du optimieren.
stimmt nicht immer. Wenn Du alle oder fast alle Sätze einer Tabelle lesen willst ist der Relation Scan eben der beste Zugriff, den man nicht weite optimieren kann!
...
Ok man muss eben immer wissen was man tut. Deshalb ja auch meine allgemeines Fazit am Ende, dass es viele Wege gibt und kein alleiniges Lösungsmittel, wie z.B. nur eine Index anlegen reicht.
