Frage zur Performance

[chrispriva]

Hallo,
in meinen SQL-Abrfagen werden merhere Tabellen einer Databenbank abgefragt. Diese Tabellen sind zum Tei sehr groß und werden über Primär- und Sekundärschlüßel verknüft. Ich muß aber auch immer wieder zusätliche Sekektonskriterien formulieren, so das manchmal recht komplexe Statements entsehen.
Nun mereke ich, dass die Ausführung dieser Abfragen unterschiedlich lang dauert, je nachdem welche Tabellen in welcher Reihenfolge und wie mtieniander verküft wurden. Ich kann leider so kein Schema darin erkennen. Gibt es da irgendwelche SQL-Grundregeln, die bedacht werden müßen, um eine Abrfage optimlazu formulieren. Wo könnte ich dazu was nachlesen?
Wäre für jeden Tipp sehr dankbar
Gruß
Christoph

[Bernhard Geyer]

Jedes DBMS hat ihre Eigenheiten. Was bei DBMS 1 gut ist führt zu inakzeptablen Zeiten bei DBMS 2.

[chrispriva]

Sorry, habe vergessen: Access2000

[Bernhard Geyer]

Bei Access sollte man Serverseitige Curser verwenden (Bei ADO heißt der wert UseServer).

Wenn Performance wichtig ist, sollte man keine Desktop-Datenbank wie Access (noch dazu in so einer alten Version) verwenden. Wenn schon dann ein Server mit entsprechend viel Cache so das alle Indize im Speicher gehalte werden können.

[tAgedObject]

...ein paar Hinweise...

Hallo,

Man sollte genau hinsehen, welche Datenbanken bzw. welche Objekte in den Datenbanken welchem Zweck dienen.

OLTP bedeutet, daß man sehr viele Änderungen an den Daten ausführt und die Datenbank-Objekte dafür optimiert sein sollten.

Data-Mining (und verwandte Spielarten) sollen bestimmte Ergebnisse aus großen Datenmengen in sehr kurzer Zeit liefern.

Während für die Geschwindigkeit bei OLTP jede Einschränkung und jeder Index eher hinderlich ist, kann man bei Data-Mining soweit gehen, daß für jede Lesart der Daten unterschiedliche Abfrage-Objekte mit mehreren Indizees bereitstehen.

****************

Wenn man einen Kompromiss zwischen Änderungen und Abfragen der Daten erzielen muß, kann man bspw. in bestimmten Fällen die Daten aus den "Änderungs"-Objekten in andere Objekte für Abfragezwecke überführen.

In Tabellen mit häufig geänderten Daten kann man versuchen nur mit Einschränkungen zu arbeiten oder Indizees mit großen Reserven zu erstellen und sollte die Statistiken häufig aktualisieren.

****************

Beim Abfragen sollte man immer versuchen die größte Einschränkung der End-Datenmenge möglichst früh durchzuführen, damit nicht sinnlose Daten "mitgeschleift" werden und dann am Ende doch aus der Ergebnissmenge entfernt werden.

****************

Die Art und die kritischen Punkte der Ausführung einer Abfrage kann man sehr gut mit dem DB-Management-Studio des SQL-Servers (oder ähnlichen Tools) beobachten, indem man sich einen Abfrage-Plan generieren läßt.

Im Fall des DB-Management-Studio des SQL-Servers bekommt man auf Wunsch (Knopf in Symbolleiste) auch einen graphischen Ausführungsplan angezeigt.
In diesem sind die jeweiligen prozentualen Anteile der Abfragen gelistet.

Findet man einen Abfrage-Anteil mit sehr hoher Prozentzahl, muß man sich überlegen, ob bzw. wie man diesen Anteil senken kann.

Durch wiederholtes Ändern der Objekte/Abfrage und erneutem Anschauen des Ausführungsplanes kann man dann mehrere Szenarien durchpielen um ein optimales Ergebnis zu erzielen.

****************

Auch bei der Auswahl der Datentypen in einer Tabelle sollte man Vorsicht walten lassen. Man sollte bei OLTP wenige Spalten pro Tabelle verwenden und die Feldlängen so kurz wie möglich wählen.

Man sollte vermeiden Felder anzulegen, die viele Null-Werte in vielen Zeilen enthalten. Solche Daten sollte man eher in verknüpfte Tabellen auslagern - das erhöht auch die Übersicht ;-)

****************

Wenn man Indizees für Abfragen anlegt, so sollten diese günstigerweise die gleichen Felder in der gleichen Reihenfolge enthalten, wie sie in Abfragen in der Where-Klausel enthalten sind.

****************

Grüße,
tAgedObject