Embedded SQL - Performance-Probleme

[BenderD]

Hallo Alex,

nachdem wir von denselben Zeiten ausgehen: woher kommen diese Angaben (die 0,3 und 0,5 sec)???

mfg

Dieter Bender

du hast recht... war ein kompletter Irrtum meinerseits!
es sind 0.5 Sekunden und nicht 5 ms... sorry.

Benötigt ein INSERT einen speziellen "Zugriffspfad"?
oder kann ich einen speziellen Zugriffspfad erzwingen?

oder ist das nur bei SELECT so?

ein Update braucht derzeit ca. 0.3 Sekunden... ein Insert 0,5 bis 0,6 Sekunden.
wie kann ich denn bei Update/Select einen Zugriffspfad erzwingen so dass ich mir wenigstens diese Zeit sparen kann?

[Fuerchau]

Einen Zugriffspfad "erzwingen" kann man leider nicht.
Für einen Insert benötigt man keinen Zugriffspfad, wohl aber für einen "update ... where" als auch für einen "select ... where" der ja nun Bestandteil deines Insert's ist.

Ich würde auch mal prüfen, wieviele Sätze denn beim Update immer betroffen sind !
Ist es denn tatsächlich immer nur 1 Satz oder sind es ggf. auch mal mehrere oder ganz viele ?

Du kannst natürlich (auch per SQL) prüfen, ob es einen Zugriffsweg gibt, oder alternativ einfach einen Index (per Create Index) erstellen.
Verpasse einen eindeutigen Namen (max. 128 Stellen) aus z.B. den Feldnamen der Where-Klausel zusammengestellt und erstelle den Index.
Wird der Befehl abgewiesen, ist er halt schon da (zugegeben nicht besonders schön, funktioniert aber).
Insbesonders für das Feld PSLFNR einen absteigenden Index, da ja immer nach dem größten Schlüssel gesucht wird.

Als zusätzliche Alternative bietet sich SQLCLI an, da hier bei Parameter-Markern "?" auch Character-Felder mittels SQLPutParm() verwendet werden können.
Hier kann man dann auch eher mit SQLPrepare arbeiten, über eine interne Liste feststellen, ob der SQL-Befehl schon mal prepared wurde und sich somit Zeit und Performance sparen.

[Fuerchau]

Ach ja,

läuft deine Schnittstelle im Dialog oder Batch ?
Wie sehen deine CPW-Definitionen für Dialog und Batch aus ?

Bei SQLCLI kann man die SQL's im Batch ausführen lassen !

[MrBonZai]

nachdem wir von denselben Zeiten ausgehen: woher kommen diese Angaben (die 0,3 und 0,5 sec)???

ich habe zu Testzwecken, da die Performance so schlecht war ein Potokoll geschrieben, dass mittels Timestamp die Zeiten vor und nach dem SQL wegschreibt.
so habe ich das ganze Programm "analysiert" und der einzige wirkliche Knackpunkt scheint das SQL zu sein.

[MrBonZai]

beim Update wird nur ein einzelner Satz upgedatet.

Als zusätzliche Alternative bietet sich SQLCLI an, da hier bei Parameter-Markern "?" auch Character-Felder mittels SQLPutParm() verwendet werden können.
Hier kann man dann auch eher mit SQLPrepare arbeiten, über eine interne Liste feststellen, ob der SQL-Befehl schon mal prepared wurde und sich somit Zeit und Performance sparen.

Was ist SQLCLI ? habe ich leider noch nie gehört.
wo finde ich Informationen darüber?

Das Programm läuft immer im Dialog.
was sind CPW-Definitionen?

[BenderD]

Hallo Alex,

als nächstes würde ich erst mal mit STRDBMON (detail auswählen) oder Ooops Nerv den Job mit dem Database Monitor überwachen und dann in der Summary die durchschnittlichen und max Zeiten pro INSERT/UPDATE ermitteln und in den Details die teuersten Statements genauer ansehen mit den dazugehörigen Infos, was die Query Engine treibt. Zusätzlich interessant sind hier noch die Empfehlungen für Indexe.
Nächste Maßnahme wäre das rausloggen der gebastelten SQL Statements, soweit nicht bereits geschehen.
Die Verarbeitungszeiten Deiner Protokolle müssen mit den Logs konsistent und nachvollziehbar sein.
Wichtig ist auch, dass ein halbwegs aktuelles GRPPTF für die Datenbank installiert ist - ohne Group PTF funktioniert die Datenbank sowieso nicht seitdem es GRP PTFs für die DB gibt.

mfg

Dieter Bender

ich habe zu Testzwecken, da die Performance so schlecht war ein Potokoll geschrieben, dass mittels Timestamp die Zeiten vor und nach dem SQL wegschreibt.
so habe ich das ganze Programm "analysiert" und der einzige wirkliche Knackpunkt scheint das SQL zu sein.

[Fuerchau]

Im Dialog kannst du dein Programm sicherlich debuggen (STRDBG).
Nach Ausführung des jeweiligen SQL's schau mal ins Joblog.
Die Datenbank schreibt dann jede Menge Meldungen über verwendete und empfohlene Zugriffspfade.
Lege dann einfach mal per STRSQL mit CREATE INDEX genau so einen Zugriffspfad an und wiederhole den Test mittels STRDBG.
Vergleiche dann die Meldungen des Joblogs mit den vorherigen.

SQLCLI ist ein C-Interface, dass ODBC-ähnliche Zugriffe auf Datenbanken unterstützt.

CPW sind die sog. Transaktionswerte, die IBM in Dialog und Batch aufgedröselt hat.
Zu erfragen bei IBM bzw. feststellbar durch Model und Prozessor.
Bei langlaufenden SQL's wird der Dialog häufig ausgebremst, was im Batch nicht der fall ist.

[MrBonZai]

ich habe mitterweile mal beim Debug die Meldungen angeschaut...

Abfrageoptionsdatei kann nicht abgerufen werden.
Wartezeit für Abfrageoptimierungsprogramm für Datei NC6000 überschritten.
Zusätzliche Ursachencodes für Zugriffspfad verwendet.
Zugriffspfad der Datei NC6000 wurde von einer Abfrage verwendet.
ODP erstellt.
Datenumsetzung für Anweisung INSERT oder UPDATE erforderlich.
Offener Datenpfad (ODP) gelöscht.
1 Zeilen in NC6000 in TRZ90PD aktualisiert.

was ist denn mit Abfrageoptionsdatei gemeint?
eine F1 auf die Meldung bringt folgendes zu Tage:

Nachricht . . . : Abfrageoptionsdatei kann nicht abgerufen werden.

Ursache . . . . : Die Abfrageoptionen konnten aus Teildatei QAQQINI in Datei
QAQQINI in Bibliothek QUSRSYS aufgrund von Ursachencode 2 nicht abgerufen
werden. Ursachencodes und ihre Bedeutung:
2 - Datei QAQQINI in Bibliothek QUSRSYS wurde nicht gefunden.

damit kann ich nichts anfangen.

Auch die Meldung "Wartezeit für Abfrageoptimierungsprogramm für Datei NC6000 überschritten." ist mir schleierhaft.
Ich habe ALLE Key-Felder in korrekter Reihenfolge in meiner "Where"-Klausel.
Er hat im Endeffekt auch die korrekte LF (was in diesem Fall die PF ist) verwendet... Die Meldung erstaunt mich allerdings.


zudem habe ich Probleme mit "Datenumsetzung für Anweisung INSERT oder UPDATE erforderlich. "
dort wird das Feld BWOT angemeckert (BWOT ist 17 A)
Ich habe aufgrund dieser Meldung z.B. alpha-Felder mit der korrekten Länge angegeben z.B. anstatt bwot = 'test' in korrekter Länge bwot = 'test '
Die Meldung erscheint aber weiterhin, oder ist hiermit etwas anderes gemeint?

Gruss Alex

[BenderD]

Hallo Alex,

ich habe mitterweile mal beim Debug die Meldungen angeschaut...

was ist denn mit Abfrageoptionsdatei gemeint?
eine F1 auf die Meldung bringt folgendes zu Tage:

damit kann ich nichts anfangen.

Auch die Meldung "Wartezeit für Abfrageoptimierungsprogramm für Datei NC6000 überschritten." ist mir schleierhaft.
Ich habe ALLE Key-Felder in korrekter Reihenfolge in meiner "Where"-Klausel.
Er hat im Endeffekt auch die korrekte LF (was in diesem Fall die PF ist) verwendet... Die Meldung erstaunt mich allerdings.


zudem habe ich Probleme mit "Datenumsetzung für Anweisung INSERT oder UPDATE erforderlich. "
dort wird das Feld BWOT angemeckert (BWOT ist 17 A)
Ich habe aufgrund dieser Meldung z.B. alpha-Felder mit der korrekten Länge angegeben z.B. anstatt bwot = 'test' in korrekter Länge bwot = 'test '
Die Meldung erscheint aber weiterhin, oder ist hiermit etwas anderes gemeint?

Gruss Alex

mit Abfrage Optionsdatei ist die Datei QAQQINI gemeint, die eigentlich vorhanden sein sollte und Einstellparameter für die Query Engine enthält. Das deutet auf einen mangelnden Gruppen PTF Stand hin, was auch zu Deinem Problem beitragen könnte.
Wartezeit ... meint: der Query Optimizer hat seine maximale Zeit überschritten, die Suche nach einem Zugriffspfad wird abgebrochen und der bisher optimale wird verwendet. Das wäre kein Drama, wenn es sich nicht um dynamisches SQL handeln würde, wo der Optimizer jedesmal beim prepare oder execute immediate zuschlägt. Das ist wohl eines Deiner Probleme. Ursache dafür könnte eine große Anzahl logischer Dateien über Deiner physischen sein.
Lösungsweg besteht in aktuellem Group PTFs für die Datenbank einspielen und Du musst von Deinem dynamischen SQL runter und notfalls mit entsprechender Verzweigungslogik auf feste SQL Statements umsteigen, wenn das flotter werden soll.

mfg

Dieter Bender

[MrBonZai]

mit Abfrage Optionsdatei ist die Datei QAQQINI gemeint, die eigentlich vorhanden sein sollte und Einstellparameter für die Query Engine enthält. Das deutet auf einen mangelnden Gruppen PTF Stand hin, was auch zu Deinem Problem beitragen könnte.

ich habe mal nach der Datei gesucht. Sie ist in QSYS vorhanden.
QAQQINI *FILE QSYS PF QUERY OPTIONS FILE

muss ich hier irgendetwas umstellen, damit er nicht auf die QUSRSYS zugreift?
Die Meldung lautete ja so:

Ursache . . . . : Die Abfrageoptionen konnten aus Teildatei QAQQINI in Datei QAQQINI in Bibliothek QUSRSYS aufgrund von Ursachencode 2 nicht abgerufen

[BenderD]

Hallo Alex,

ich habe mal nach der Datei gesucht. Sie ist in QSYS vorhanden.
QAQQINI *FILE QSYS PF QUERY OPTIONS FILE

muss ich hier irgendetwas umstellen, damit er nicht auf die QUSRSYS zugreift?
Die Meldung lautete ja so:

direkter Handlungsbedarf ist hier nicht, aber nochmal: wie sieht es mit den Gruppenptfs Database aus? (Details sind Release abhängig!)

mfg Dieter Bender

[MrBonZai]

wie sieht es mit den Gruppenptfs Database aus? (Details sind Release abhängig!)

Ich habe mal in unserer IT nachgefragt.
Der letzte installierte Group-PTF für V4R5 ist vom 22.1.2003.