Optimierung Datenbankzugriffe

[Christian.Hesse]

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

[Fuerchau]

Vom Grundsatz ist ein Index beim Zugriff immer von Vorteil.
Per SQL geht das auch einfach per "create index mylib/myindex on mylib/myfile (k1, k2, ...., kn)", wobei auch jedes Keyfeld sowohl ASCEND als auch Descend sortiert sein kann.
Ein Index ist eigentlich immer erforderlich, sobald im SQL eine Where- oder Order-By-Klausel verwendet wird.
Die einfachste Regel hierbei ist:
Ein Index mit den Feldern und der Reihenfolge der Where/Order-Klausel.

Bei Joins wirds da etwas komplizierter, aber auch da gilt im Wesentlichen obige Regel:
Über die Bezüge des Joins ist je Tabelle ein Index anzulegen.

Ein Index wird von der AS/400 permanent mitgepflegt und fällt kaum auf.
Bestehende Programme merken auch davon nichts.

Was die Satzsperre angeht: ein Select interessiert sich im Normalfall nicht dafür (weiteres siehe Commitlevel), wohl aber ein Update/Delete.
RPG kann keine Datei sperren, wohl aber ein vorgeschaltetes Kommando ALCOBJ (ggf. per CL-Programm).
Der Select schlägt dann fehl mit einem ODBC/JDBC-Fehler (Cursor nicht geöffnet).
Hier kann ggf. die Dateiwartezeit (Default 60 Sekunden) zuschlagen.

Was den JDBC-Zugriff schneller macht ?
Auch hierzu gibts mehrere Beiträge, im Wesentlichen jedoch folgendes:
- Prepared Statements
- Parametermarker

[RobertPic]

... (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))

Wie sich das anhört werden da viele Sätze überlesen (übel). Je öfter gelesen wird, desto mehr Datei wird im Hauptspeicher gepuffert. Wenn nicht mehr gelesen wird der Hauptspeicher mit anderem Zeug belegt.

Meine Idee dazu ist jetzt, Indizes anzulegen...

Indizes sind das A&O für gute Performance. Wenn ihr bisher keinen Gebrauch davon gemacht habt, wundern mich Performanceprobleme nicht!

.. was meines Wissens nur über Logische Files gemacht wird.

Logische Files ist die Native-Variante für RPG&Co. Für SQL-Zugriffe kann man das SQL-Kommando CREATE INDEX verwenden.

Meine Frage dazu: Kann ich darin auch einen Index über mehrere Spalten anlegen?

Ja freilich, z.B.
CREATE INDEX LIB/DATIDX ON LIB/DAT (ID, BEZ) WITH
2 DISTINCT VALUES

für Syntax: STRSQL, CREATE INDEX + F4-Taste

Unique-Key kostet etwas mehr Performance, beim Update/Insert von Sätzen. Also wenn die Eindeutigkeit geregelt ist, auf das (Schlüsselwort) Unique verzichten.

Und mit welcher Performance-Einbuße muß ich beim Indexaufbau, bzw. wiederaufbau rechnen und ....

Als bei Zugriffen von 24x7-Jobs sind sicher permanente Indizes sinnvoll. In diesem Fall "zahlt man die Zeche" bei jedem Update bzw. Insert auf die Datei. Wenige Indizes sind i.d.Regel aber nicht spürbar. Es muss schon verdammt blöd hergehen (große Datei die jeden Tag komplett neu gefüllt wird), dass sich ein permanenter Index
nicht auszahlt.

...wann macht die AS400 das?

Ein Index wird im Normalfall sofort erstellt. Das Aktualisieren machen die QDBSRVxxx-Jobs. Auch hier der Hinweis: Unnötige Angaben von Unique vermeiden, da sich die Uniqueprüfung ja nur schwer in den Hintergrund schieben läßt.

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.)

Wenn du mit den Maschinen verschiedene AS/400 meinst, sage ich nur: Query Optimizer

Dieses "schlaue Ding" wählt die Strategie bzw. den Zugriffsweg für das SQL-Statement aus und hat etwas von Glückspiel.

Beispiel gefällig (war glaube ich unter V5R1):
SQL-Statement ca. 30% Maschinenauslastung --> ein vorhandener Index wird nicht gefunden (es gibt ein Timeout wie lange bei den vorhandenen Indizes suchen darf)
---> Laufzeit 55min

gleiche Maschine/gleiches SQL-Statement ein paar Tage später bei ca. 15% CPU-List
Vorhandener Zugriffspfad wird gefunden und genutzt ---> Laufzeit 2 Minunten

Robert P.

[KM]

Das Problem mit der Wartezeit könnte auch an der JVM liegen. So wie es aussieht scheint sich die nach einer gewissen Zeit zu beenden. Ein neues Starten dauert dann immer einige Sekunden.

Gruß,
KM

[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.