SQL-Performance Probleme ODBC

[berndl]

Hallo zusammen,

wir haben diverse Performance Probleme bei den Datenzugriffen per SQL. Wir greifen auf eine per DDS generierte DB mit Tables und Views neuerdings auch per ODBC und OLE-DB-Datenprovider von IBM und DataDirect (Fremdhersteller) zu.

Dabei kommt es zu unterschiedlichsten Antwortzeiten, bei denen DataDirect massiv schneller ist. Die Ausführung des SQLs per Navigator ist teilweise genauso schnell wie der DataDirect-Zugriff, meist aber so langsam wie ODBC.

Es handelt sich dabei um sehr umfangreiche SQLs mit diversen Joins, für die auch entsprechende Indexs (gem. Index-Advisor) auf der DB erstellt wurden. DataDirect-Zugriffe verwenden diese konsequent, die anderen Zugriffsarten meist nicht, sondern die von DDS her vorhanden Views. Teilweise wurden die Abfragen(!) nach löschen der Index wieder schneller.

Hat irgendjemand eine Idee, wo man da zu suchen anfängt? Wir haben in der alten RPG-Applikation keine Performanceprobleme, deswegen tippen wir auf eine falsche Konfiguration für die SQL-Zugriffe. Von uns ist aber niemand im Bereich der SQL-Einstellungen fit.

Herzlichen Dank

[Fuerchau]

Da hilft nur, die SQL's, die über ODBC reinkommen zu analysieren. Meist gibt z.B. OpsNav oder der Debug-Modus genug Auskunft für die Verwendung von Zugriffswegen.

Dass RPG native, also ohne SQL, meist schneller ist liegt nunmal an der Konzeption bei RPG. Da legt man sich meist ja entsprechende LF's an um schnell zuzugreifen.

[berndl]

Danke für die schnelle Anwort.

Wir haben da schon versucht zu analysieren, sind mit unseren Ergebnissen aber nicht zufrieden. Vor allem, da die gleichen SQL-Statements über Interfaces von Fremdherstellern schneller laufen, wie wenn sie direkt im iSeriesNavigator ausgeführt werden.

Werden die nicht alle durch die gleiche CLI ausgeführt, egal wie sie an die AS übergeben werden? Vor allem wie erklärt man einen Unterschied von 15 Sekunden vs. 6-8 Minuten?? Gibts da vielleicht ein paar grösser Schalter zum Drehen?

[Fuerchau]

Nö, nicht wesentlich.
Da gibts nur ein paar Hinweise zwischen den verschiedenen Optimizern, der "alte" ist da manchmal besser.
Wie man per ODBC diesen gezielt einschaltet, k.A.
Ggf. kann man über die Abfrageinformationsdatei (QAO-irgendwas) Einstellungen vornehmen.

Aber eigentlich muss es Unterschiede in den SQL's geben.

[B.Hauser]

Hallo,

m.E. hilft nur beide Jobs mit Database Monitor (STRDBG ist nicht ausreichend) aufzuzeichnen und analysieren. Aber Achtung DBMON generiert einen Wust an Datensätzen, d.h. man sollte gezielt auswählen und nur kurzzeitig aufzeichnen, sonst kann man sich leicht die Platte vollschreiben.

Das erste, das man feststellen muss ist, wieviel Zeit tatsächlich für SQL verwendet wurde. Wenn die SQL-Statements tatsächlich identisch sind und wenn in beiden Fällen dynamisches SQL verwendet wurde (iSeries Navigator ist auf alle Fälle ein dynamisches Interface), müsste die reine SQL-Zeit identisch sein.

Mit Hilfe des folgenden SQL-Scripts kann zum einen die Gesamt-Zeit für SQL pro Job und zum anderen die Zeit für die einzelnen SQL-Statements aus der DBMON-Aufzeichnung ermittelt werden:

CREATE ALIAS MySchema/MyDbgMon 
FOR MyDBMonLib/QZG0000605; 

-- Gesamt-Ausführungszeit pro Job für SQL 
with x as (select QQJNUM as JobNr,
                  cast(sum(qqi6)/1000000 as Dec(6, 0)) as ExcSQLSec, 
                  cast(mod(sum(qqi6), 1000000) as Dec(6, 0)) as ExcSQLMs
              from MyDbgMon
              where     QQRID=1000 and QQC21 <> 'MT'
              group by QQJNUM)
Select JobNr,
       Digits(Dec(Truncate(ExcSQLSec / 3600, 0), 2)) concat ':' concat
       Digits(Dec(Truncate(Mod(ExcSQLSec / 60, 60), 0), 2)) concat ':' concat
       Digits(Dec(Truncate(Mod(Mod(ExcSQLSec , 3600), 60), 0), 2)) concat ' - ' concat
       Digits(ExcSQLMs) as "SQLZeit"
   from x;

-- Ausführungszeit pro SQL-Statement
SELECT qqi6 "Total Time", qqjnum, qqjob, qquser, qq1000 
   FROM MyDbgMon
   WHERE qqrid=1000 AND qqc21 <> 'MT'
   ORDER BY qqi6 DESC; 

Vielleicht kommst Du dadurch zu neuen Erkenntnissen.

Birgitta

[BenderD]

Hallo,

dass ich das noch erleben durfte, ich muss doch mal eine Lanze für den OOps Nerv brechen, die Empfehlung DBMON ist goldrichtig, bei ODBC muss man nur drauf achten, dass man selbigen für alle Jobs startet (damit er vor dem connect aktiv ist), detailliert, versteht sich - die Auswertung der Daten, das ist dann das einzige, für das Ooops Nerv taugt (vor Auswertung importieren aus Datei).

mfg

Dieter Bender

Hallo,

m.E. hilft nur beide Jobs mit Database Monitor (STRDBG ist nicht ausreichend) aufzuzeichnen und analysieren. Aber Achtung DBMON generiert einen Wust an Datensätzen, d.h. man sollte gezielt auswählen und nur kurzzeitig aufzeichnen, sonst kann man sich leicht die Platte vollschreiben.

Das erste, das man feststellen muss ist, wieviel Zeit tatsächlich für SQL verwendet wurde. Wenn die SQL-Statements tatsächlich identisch sind und wenn in beiden Fällen dynamisches SQL verwendet wurde (iSeries Navigator ist auf alle Fälle ein dynamisches Interface), müsste die reine SQL-Zeit identisch sein.

Mit Hilfe des folgenden SQL-Scripts kann zum einen die Gesamt-Zeit für SQL pro Job und zum anderen die Zeit für die einzelnen SQL-Statements aus der DBMON-Aufzeichnung ermittelt werden:

CREATE ALIAS MySchema/MyDbgMon 
FOR MyDBMonLib/QZG0000605; 

-- Gesamt-Ausführungszeit pro Job für SQL 
with x as (select QQJNUM as JobNr,
                  cast(sum(qqi6)/1000000 as Dec(6, 0)) as ExcSQLSec, 
                  cast(mod(sum(qqi6), 1000000) as Dec(6, 0)) as ExcSQLMs
              from MyDbgMon
              where     QQRID=1000 and QQC21 <> 'MT'
              group by QQJNUM)
Select JobNr,
       Digits(Dec(Truncate(ExcSQLSec / 3600, 0), 2)) concat ':' concat
       Digits(Dec(Truncate(Mod(ExcSQLSec / 60, 60), 0), 2)) concat ':' concat
       Digits(Dec(Truncate(Mod(Mod(ExcSQLSec , 3600), 60), 0), 2)) concat ' - ' concat
       Digits(ExcSQLMs) as "SQLZeit"
   from x;

-- Ausführungszeit pro SQL-Statement
SELECT qqi6 "Total Time", qqjnum, qqjob, qquser, qq1000 
   FROM MyDbgMon
   WHERE qqrid=1000 AND qqc21 <> 'MT'
   ORDER BY qqi6 DESC; 

Vielleicht kommst Du dadurch zu neuen Erkenntnissen.

Birgitta

[BenderD]

Hallo,

Schalter zum drehen gibt es da schon, aber derartige Unterschiede deuten eher drauf hin, dass da auch was verdrechselt sein könnte (Pool, Priorität, Timeslice).
Treiber müssen keineswegs CLI verwenden, sondern könnten auch einen eigenen Serverjob verwenden (merkt man bei der Installation). Ansonsten kämen 2 verschiedene Serverjobs in Frage (mit möglicherweise unterschiedlichen Workmanagement Einstellungen). Im übrigen kann man auch über CLI gleiche Anforderungen unterschiedlich ausführen.
Noch ein Kandidat können auch andere Jobs sein, die die ODBC Anfrage verhungern lassen (CFINT lässt grüßen, oder ähnliches).

mfg

Dieter Bender

Danke für die schnelle Anwort.

Wir haben da schon versucht zu analysieren, sind mit unseren Ergebnissen aber nicht zufrieden. Vor allem, da die gleichen SQL-Statements über Interfaces von Fremdherstellern schneller laufen, wie wenn sie direkt im iSeriesNavigator ausgeführt werden.

Werden die nicht alle durch die gleiche CLI ausgeführt, egal wie sie an die AS übergeben werden? Vor allem wie erklärt man einen Unterschied von 15 Sekunden vs. 6-8 Minuten?? Gibts da vielleicht ein paar grösser Schalter zum Drehen?