Ideen wie man DBs performanter machen kann

[Mackhack]

Hi DPler,

ich habe eine Hausarbeit bekommen von der Uni. Es geht darum auf ca. 2-3 Seiten aufzuschreiben wie man die Performance einer Datenbank im allgemeinen oder aber auch speziell sollte es um SQL Server geht zu verbessern.

Ich moechte jetzt auch nicht dass jemand mir die Hausarbeit erledigt, was ich mir wuensche sind einige gute Anregungen, oder Beispiele zu bekommen mit denen ich arbeiten und meine Hausarbeit erledigen kann.

Ich sitzte jetzt schon seit 4 Tagen dran und komme auf keine besonders gelungenen Ideen. Vlt. kann mir ja der eine oder andere seine Ideen oder Gedanken hier niederschreiben.

Vielen Dank!

[marabu]

Hallo Tobias,

nichts geht über eine gute Materialsammlung. Du könntest diese hier mal sichten: klick

Freundliche Grüße

[Mackhack]

Hallo marabu,

vielen lieben Dank fuer deine schnelle Hilfe. Werde ich gleich nach Feierabend hier erledigen!

[Bernhard Geyer]

Zitat von Mackhack:

... speziell sollte es um SQL Server geht zu verbessern.

Also kein spezieller MySQL, Oracle und Interbase sind ja SQL Server

Hier ein paar Stichworte:

HW-Vorraussetzungen:
- Viel RAM. Besser: Noch mehr RAM
- Schnelles RAID-System

Datenbank-Modell:
- Definition von passenden Indize auf Felder nach denen oft gesucht wird. Je mehr Indize es gibt desto langsamer sind Inserts und dest mehr RAM benötigt die Datenbank um schnell zu sein (Indize sind nur dann sehr schnell wenn sie auch komplett im Speicher gehalten werden können
- U.u. verletzung der 3.ten oder höheren Normalform um Daten die oft benötigt werden nicht erst durch komplexe Joins zu bekommen

Zugriff:
- Verwendung von parametrisierten Abfragen/Inserts welche auch entsprechend Prepared werden
- Verwendung von Stored Procedures um den Aufbau von Recordssets zu vermeiden

Verteilung:
- Verteilung der Datenbank/DB-Zugriffsschicht und Businesslogik auf mehrere Rechner oder auf einen großen Rechner.
Mehrer Rechner haben den Nachteil von Round-Trip-Delays (Jede Abfrage kosted übers Netz ein paar ms.



Ach ja. Bevor ich es vergesse: Mehr RAM einbauen hilft bei großen Datenbanken.
Und je nach Datenbanksystem nicht vergessen das DBMS so zu konfigurieren das es den RAM auch verwenden darf.


Ich hoffe das sind jetzt genügende Stichworte

[Mackhack]

Dank dir Bernhard. Ja damit laesst sich bestimmt noch einiges ergeben!

[Bernhard Geyer]

Zitat von Mackhack:

Hallo Bernhard,

koenntest du mir das vlt. etwas genauer erklaeren wie das funktioniert?

Zitat:

Zugriff:
- Verwendung von parametrisierten Abfragen/Inserts welche auch entsprechend Prepared werden
- Verwendung von Stored Procedures um den Aufbau von Recordssets zu vermeiden

Verteilung:
- Verteilung der Datenbank/DB-Zugriffsschicht und Businesslogik auf mehrere Rechner oder auf einen großen Rechner.
Mehrer Rechner haben den Nachteil von Round-Trip-Delays (Jede Abfrage kosted übers Netz ein paar ms.

Vielen Dank!

Parametriesierte Abfragen mit Prepared:
Jede Abfrage/Insert muss von der Datenbank durch den Query Analyser geschickt werden um zu bestimmen welche Indeze benötigt/verwendet werden usw. Da die Zeit benötigt ist es von Vorteil eine mehrfach verwendete Query (welche sich nur durch Abfrage/Einfügewerte unterscheidet) nur einmal bewerten zu lassen und dann diese vorbereitung für mehrer Inserts/Queries zu verwenden.

Verwendung von Stored Procedures um den Aufbau von Recordssets zu vermeiden:
Für ein normales SELECT ... muß die Datenbank eine Ergebnismenge aufbauen mit beschreibung der einzelnen Felder. U.U. ist auch ein Serverseitiger Curser nötig, wenn die Ergebnismenge nicht in einem Schwung zum Client übertragen wird. Bei einer SP liegt schon in der DB hinterlegt das als Paramter nur ein Int, varchar, ... kommt uns als Ergebnisparameter ein Int nötig ist. Auch kann hier der gleiche Vorteil wie von einer parametrisierten Abfrage gezogen werden

Verteilung:
Je nach Programmlogik ist das Hauptbremsende Element in einem System die Latenzzeiten der Netzwerkkommunikation. Jeder noch so kleine Abfrage benötigt auch in einem GBit-Netzwerk einige µs - ms bis eine (IP-)Nachricht vom Client zum Server gelangt, durch den IP-Stack läuft beantwortet wird und beim Client ankommt. Deshalb kann es manchmal sehr von Vorteil sein wenn bei einer N-Tier-Architektur die Nicht-DB-Schichten auf einem Rechner laufen und bei hoher Last "einfach" per Clustering weitere Rechner dazu gestellt werden welche ebenfalls diese Nicht-DB-Schichten beinhalten.