Optimierung Datenbankzugriffe

[BenderD]

Hallo,

sieht nach full table scans aus, soweit das Problem nicht von einer aus dem Hauptspeicher verdrängten ängstlichen Spinne (WebsFear) herrührt. Die Zeiten sind allerdings so grotteschlecht, dass weitere Flaschenhälse nicht auszuschließen sind.

Dateisperren gibt es aus jeder Ecke unter Commit Level serializable, das dauert dann aber nicht lange, sondern bricht sofort ab (wg. Dateiwartezeit *immed). Satzsperren können jedoch (z. B. bei Commit Level repeatable read im Java Programm) durchaus zu langen Wartezeiten führen.

Beendete JVMs würde man merken, die starten sich nicht neu, gestartete werden (soweit man nix dagegen tut, gestartet gehalten.

Bevor man irgendwas macht, sollte man messen, um rauszukriegen, was da abgeht: STRDBMON *ALL *DETAIL ist dein Freund und Oops Nerv dein Feind bei der Auswertung.

mfg

Dieter Bender

PS: und viel Erfolg bei der Detektiv Arbeit

Hallo alle miteinander,

nachdem ich inzwischen irgendwo in der Programmierung untertauchen darf, komme ich mit neuen Fragen:

Ich habe das Problem, daß beim Zugriff auf ein PF (via JDBC) eine Zugriffszeit zum Lesen eines Datensatzes bis zu 30 Sekunden brauche. (Tendenz sinkend mit fortwährendem Betrieb - irgendwann sind wir bei 0,5 bis 1 Sekunde angelangt, wobei es auch mal wieder mehr werden kann und das bevorzugt direkt und schlagartig nach einer längeren Pause (ab 20 Minuten))

Meine Idee dazu ist jetzt, Indizes anzulegen, was meines Wissens nur über Logische Files gemacht wird. Meine Frage dazu: Kann ich darin auch einen Index über mehrere Spalten anlegen? Und mit welcher Performance-Einbuße muß ich beim Indexaufbau, bzw. wiederaufbau rechnen und wann macht die AS400 das?

Eine weitere Vermutung ist folgende: Ich habe sowohl RPG-Programme, die zyklisch immer mal wieder die physikalischen Files (evtl. exklusiv?) öffnen. Kann ich eigentlich eine Datei in RPG exklusiv öffnen? Soweit ich mich in meiner Schulung erinnern kann, verwendet RPG nur Satzsperren und keine Dateisperren.
Und wenn tatsächlich mal eine - wie auch immer geartete - Sperre zu einer Verzögerung der SQL-Zugriffe führen könnte: Gibt es eine Möglichkeit, dies mit zu loggen um dies zu überprüfen?

Und um die Fragen abzurunden die Letzte: Gibt es noch irgendwelche "Optimierungen" woran ich die JDBC-Zugriffe "effizienter" - sprich schneller - auf die Reihe bekomme? Also irgendetwas was eine Datenbankdatei auf einer Maschine haben könnte, was die selbe Datei auf anderen Maschinen nicht hat? (Ein Index ist es mal nicht, denn der fehlt bei allen Maschinen.)

Vielen herzlichen Dank schon mal für eure Hilfe!

Viele Grüße und eine gute Nacht!

Christian

[Christian.Hesse]

Hallo alle miteinander,

nachdem ich inzwischen einen fehlenden Index ausmachen konnte, der den Zugriff um bis zu Faktor 30 beschleunigt, bin ich beim Lesen von Database Performance and Query Optimization darüber gestolpert, daß die AS400 auch temporäre Indizes anlegt, wenn keine passenden vorhanden sind.

Kann es vielleicht sein, daß dies bei 2M Datensätzen (ca. 350 MByte) an die 12 Minuten dauert? Und kann es vielleicht sein, daß der Halbfertige Index auch schon mitgenutzt wird, während des Aufbaus? Wäre zumindest eine Erklärung, die (mir) passen würde.

Ansonsten schaue ich mal weiter, was das Dokument noch alles im Angebot hat - vielleicht finde ich ja noch die Erleuchtung schlechthin, daß meine Queries nächstens gar keine Zeit mehr brauchen.

Viele Grüße aus der verregneten Pfalz

Christian

[Fuerchau]

Wie der Name schon sagt ist es ein temporärer Index, der nach Abschluss der Abfrage (Close Cursor) wieder gelöscht wird.
12 Minuten für 2Mio Sätze zeigt nur, wie schnell die Maschine ist. Es kann auch schon mal länger als 1 Stunde dauern.
Hierfür ist dann das QueryTimeout sinnvoll, um den Query abzubrechen, falls er zu lange dauert. Leider schlägt dann aber manchmal der Optimizer quer, der Zeiten um Faktoren falsch einschätzt.

[BenderD]

Hallo,

wobei der close Cursor meist erst beim Close der Connection und bei JDBC erst beim Ende des Server Jobs erfolgt (lazy close). Bei der achSoFamosen neuen Query Engine werden statt temporären Indexen Full Table Scans gemacht, die meist noch aufwändiger sind.

Was ich mich immer wieder frage und nie verstehe, ist: warum raten fast alle leiber rum, statt mit STRDBMON zu messen???

mfg

Dieter Bender

Wie der Name schon sagt ist es ein temporärer Index, der nach Abschluss der Abfrage (Close Cursor) wieder gelöscht wird.
12 Minuten für 2Mio Sätze zeigt nur, wie schnell die Maschine ist. Es kann auch schon mal länger als 1 Stunde dauern.
Hierfür ist dann das QueryTimeout sinnvoll, um den Query abzubrechen, falls er zu lange dauert. Leider schlägt dann aber manchmal der Optimizer quer, der Zeiten um Faktoren falsch einschätzt.

[sim]

wird SQL_ATTR_QUERY_TIMEOUT überhaupt von den APIs unterstützt ? Ich konnte in der SQLCLI Copystrecke jedenfalls nichts finden.

[Fuerchau]

Das wird leider nicht unterstützt.
Man muss vorher für seinen Job einen CHGQRYA ausführen.