Zugriff auf Tabellen langsam

[JP]

Hallo Forum,

wir haben in einer Bibliothek Tabellen eines Drittanbieters,
bei denen der lesende Zugriff per SQLRPG seit ca. zwei Wochen länger dauert als üblich.
Was vorher ca. 30 Minuten gedauert hat, braucht nun ca. 1,5 - 2 Stunden.
Ein SELECT per STRSQL auf irgendeine dieser Tabellen (z.B. mit 1,6 Mio Datensätzen) geht recht flott. Wir können uns das Verhalten nicht erklären.

Ich meine das Problem auf die Tabellen in dieser Bibliothek einschränken zu können, da wir noch andere Tabellen haben, bei denen das Problem nicht auftritt.

Hier noch einige Infos:
- Tabellen werden journalisiert
- an einigen hängen Trigger
- QAQQINI in QUSRSYS (IGNORE_DERIVED_INDEX = *YES)

Habt Ihr eine Idee oder einen Ansatz, wie wir das wieder in den Griff bekommen können.

Danke und Gruß
Jörg

[andreaspr@aon.at]

Hallo Jörg,

gab es denn vor zwei Wochen irgendwelche änderungen? Updates, PTFs, Releasewechsel, ...?
Das könnte natürlich viele Ursachen haben.
Gelöschter Index, geänderte Abfrageeinstellungen, Satzsperren, Systemauslastung usw.

Im STRSQL werden meist nur die ersten x Sätze gelesen. Dadurch scheint es schneller zu wirken.

Du könntest einfach mal einen DB Monitor starten. Damit sollte man das recht schnell herausfinden können.

lg Andreas

[Fuerchau]

STRSQL trifft es tatsächlich nicht immer da intern "optimize for firstio" angewendet wird.
Bei embedded SQL wird "optimize for allio" standardmaäßig gesetzt, wobei das der bessere Weg ist wenn alle Datensätze gelesen werden, was bei STRSQL eher selten der Fall ist.

Beim Anwachsen der Tabellen stellt man das häufiger fest, dass einfach Indizes fehlen.
Der DB-Monitor oder die QAQQINI-Einstellung für DEBUG-Nachrichten können da schon massiv helfen um Indizes anzulegen.

[BenderD]

Was vorher ca. 30 Minuten gedauert hat, braucht nun ca. 1,5 - 2 Stunden.
Ein SELECT per STRSQL auf irgendeine dieser Tabellen (z.B. mit 1,6 Mio Datensätzen) geht recht flott. Wir können uns das Verhalten nicht erklären.

Danke und Gruß
Jörg

... was treiben diese Programme da??? Die Zeiten waren ja vorher schon im dunkelroten Bereich!!! In der Zeit kann man diese schlappen 1,6 Millionen Sätze ja 50 mal hin und herschaufeln mit löschen und jedesmal neu schreiben, versteht sich.

D*B

[JP]

Änderungen wie PTF's etc. wurden nicht gemacht.
Der Datenbestand dieser Tabellen hat sich auch nicht wesentlich erhöht.
Systemauslastung ist auch normal. Bis auf die oben beschriebenen Jobs, die ziehen natürlich CPU.

Ich hab das Gefühl das da irgendwas mitläuft.

Auf diese Tabellen wird auch per ODBC zugegriffen.
Der QZDASOINIT-Job generiert dann ein Jobprotokoll, da er einen ENDDBG versucht hat.
Das darf er natürlich nicht, da der entsprechende Benutzer nicht berechtigt ist.
In der ODBC-System-DSN ist aber kein Trace/Debug eingestellt bzw. aktiviert.
Auch in der Software die sich dieser Jobs bedient ist nichts dergleichen konfiguriert.

Ich werde dann mal den DB-Monitor bemühen.

Gruß
Jörg

[Fuerchau]

ODBC-Zugriffe sind m.U. die schlimmsten da meistens in Unkenntnis falsche Zugriffswege verwendet werden und zu Tablescans oder temporären Indexaufbau führen.

[BenderD]

@Baldur:
ein full tablescan für 1,6 Mio Sätze dauert auf meiner uralt 520 1 bis 2 Minuten!, ein Index Aufbau kann da drüber liegen, aber bei dieser läppischen Anzahl von Daten erklärt selbst der die Zeiten nur, wenn in einem Programm gleich reihenweise Indexe angelegt werden.

D*B

PS: Cache Batterie etc. alles gesund?

[camouflage]

PS: Cache Batterie etc. alles gesund?

Hätte ich jetzt mal so auch darauf getippt. Ist das Ding mal leer, geht die Kiste ganz schön in die Knie.

[holgerscherer]

Hätte ich jetzt mal so auch darauf getippt. Ist das Ding mal leer, geht die Kiste ganz schön in die Knie.

Nicht, wenn nur lesend zugegriffen wird. Aber evtl. ist ja die CACHBATT leer, und die Software strickt ständig neue temporäre Indexe. Dann wäre die CPU-Last aber nicht hoch...

-h

[andreaspr@aon.at]

Dieter hat schon recht. Selbst 30 min ist eine sehr lange dauer. Da wird sicher mehr als nur ein einfaches "SELECT" gemacht.