SQL Optimierung (Anfängerfrage)

[camouflage]

Sorry, man wird sich doch mal verschreiben dürfen (auch wenn das mein alter Lateinlehrer nicht so sehen würde).

Eruieren kommt von lat. eruere: ausfindig machen und bezeichnet heute in der gehobenen Umgangssprache als häufig verwendetes Fremdwort ...

Birgitta

... wobei eruere dem errare ziemlich nahe steht. *scnr ;-)
Kleines Spässchen in dieser mitunter trockenen Materie darf noch sein, Du mögest mir verzeihen.

Im Ernst, ich kann dem Systems Navigator nicht allzu viel abgewinnen, ausser dem link für die SSL Zertfikate. Dazu ist er mir einfach zu langsam und macht Probleme mit dem eigenen Zertifikat. Möglicherweise muss ich den einfach mal umkonfigurieren, nur hatte ich bis jetzt keine Zeit und auch keine Lust dazu.

In diesem Sinn, allen noch ein schönes WE.

[andreaspr@aon.at]

Jetzt muss ich auch nochmal meinen Senf dazugeben, da ich neugirig gemacht wurde.
Ich persönlich mag den Navigator auch nicht besonders, da er für den heutigen Stand der Technik nicht gerade aufregend ist. Abstürtze habe ich auch hin und wieder gehabt.
Und wehe du verwendest eine CA Version die nicht gleich der OS Version vom Server zu verwenden. Da ist es dann schon ein Glücksfall, wenn der DB-Monitor die Daten auch wirklich analysieren kann.

Aber jetzt mal eine ernsthafte Frage an alle die auf dem System irgendwas mit Datenzugriffen machen:
Wie analysiert ihr die Performance bei Datenzugriffen?
*) STRDBG im Green-Screen?
*) STRDBMON im Green-Screen?
*) System Director?
*) Oder gibt es noch andere Möglichkeiten, die ähnliche Informationen geben können wie die oben genannten?
*) Oder sagt ihr dann einfach: "Das geht nicht schneller. Die Maschiene braucht einfach mehr Hauptspeicher und CPU" (hab ich auch schon oft erlebt )

Ich bin auch gern bereit neue Analysetechniken kennen zu lernen!

[BenderD]

... Hauptpunkt ist den Aufwand dahin zu konzentrieren, wo es was bringt (80 : 20 Regel: 80 Prozent der Laufzeit werden von 20 Prozent des Codes verursacht). Häufig eingesetzt wird von mir:
- DSPLOG MSGID(CPF1100) und ein wenig Aufbereitung durch Programm oder Excel liefert Laufzeit und CPU Verbrauch von Batchjobs => Feinanalyse für Langläufer und Ausreißer, falls kritisch.
- Debug Messages im Joblog für SQL Zugriffe, wenn man begründete Verdachtsmomente hat, wo ein Problem verursacht wird.
- STRDBMON über die gesamte Maschine mit anschließender Auswertung in absteigender Reihenfolge der Laufzeit. Auswertung mit Ooops Nerv und SQL Scripten.
- Plausibilisierung von Laufzeiten mit Erfahrungswerten. Ein Programm, das 100.000 Datensätze liest, darf dafür ungefähr 100 sec. brauchen, braucht es 3 Minuten, lohnt Aufwand nur, wenn das kritisch ist - will ich das unter 1 Minute bringen, wird das richtig teuer (Anmerkung: das ist auch unter 10 sec. zu bringen => Parallelisierung, oder mit mehr Redundanz in der Datenbank)
- Runtime Statistics für kritische Jobs decken auf, wann Skalierbarkeitsgrenzen erreicht werden (dann kommt Aufwand auf einen zu)
- wichtigste Regel: Immunität gegen Schlauschwätzer und Patentrezepte aufbauen.

D*B

Jetzt muss ich auch nochmal meinen Senf dazugeben, da ich neugirig gemacht wurde.
Ich persönlich mag den Navigator auch nicht besonders, da er für den heutigen Stand der Technik nicht gerade aufregend ist. Abstürtze habe ich auch hin und wieder gehabt.
Und wehe du verwendest eine CA Version die nicht gleich der OS Version vom Server zu verwenden. Da ist es dann schon ein Glücksfall, wenn der DB-Monitor die Daten auch wirklich analysieren kann.

Aber jetzt mal eine ernsthafte Frage an alle die auf dem System irgendwas mit Datenzugriffen machen:
Wie analysiert ihr die Performance bei Datenzugriffen?
*) STRDBG im Green-Screen?
*) STRDBMON im Green-Screen?
*) System Director?
*) Oder gibt es noch andere Möglichkeiten, die ähnliche Informationen geben können wie die oben genannten?
*) Oder sagt ihr dann einfach: "Das geht nicht schneller. Die Maschiene braucht einfach mehr Hauptspeicher und CPU" (hab ich auch schon oft erlebt )

Ich bin auch gern bereit neue Analysetechniken kennen zu lernen!