View Full Version : Runsql aus CL-Programm funktioniert nicht mehr
Der SQL-Optimizer ab V6R1 versucht (wie oben gesagt) zuerst einen CLRPFM. Auf Grund der Dateiwartezeit von 60 Sekunden erfolgt halt erst hinterher der satzweise Delete.
Du kannst das umgehen, in dem du eine simple Where-Klausel anhängst, die dann alle Sätze umfasst.
Der alte Optimizer ist ab V6 wohl abgeschafft, so dass hier diese Probleme mit dem Neuen auftreten.
... das ist kein ganz anderes Problem!!!
das ist genau der Effekt, den ich bereits mehrfach erwähnt habe.
delete * from ... einmal Satz weise - stört sich nicht an locks auf die Teildatei, sondern holt sich nacheinander die Satzsperren, sperrarm und lässt konkurrierende open auf die Teildatei zu.
delete * from als CLRPFM ausgeführt - geht wesentlich schneller, stirbt aber an konkurrierenden open auf die Teildatei
letzteres sollte eigentlich nur versucht werden, wenn die Datei frei ist => ergo Bug!!!
andreaspr@aon.at
31-08-11, 07:56
Das ein DELETE * FROM TAB1 als CLRPFM ausgeführt wird kann ich mir nicht vorstellen.
Bei einem DELETE (egal ob mit Where oder ohne) stehen nach einem DSPFD TAB1 bei "Gesamtzahl gelöschter Sätze" die Anzahl der gelösten Sätze.
Bei einem CLRPFM steht dort immer 0 (wie Bender so schön sagen würde: in Worten null ;) )
Das ein DELETE * FROM TAB1 als CLRPFM ausgeführt wird kann ich mir nicht vorstellen.
Bei einem DELETE (egal ob mit Where oder ohne) stehen nach einem DSPFD TAB1 bei "Gesamtzahl gelöschter Sätze" die Anzahl der gelösten Sätze.
Bei einem CLRPFM steht dort immer 0 (wie Bender so schön sagen würde: in Worten null ;) )
Hallo,
und da steht dann null, haben es gestern auf alle möglichen Wege durchgespielt.
LG
Das ein DELETE * FROM TAB1 als CLRPFM ausgeführt wird kann ich mir nicht vorstellen.
Bei einem DELETE (egal ob mit Where oder ohne) stehen nach einem DSPFD TAB1 bei "Gesamtzahl gelöschter Sätze" die Anzahl der gelösten Sätze.
Bei einem CLRPFM steht dort immer 0 (wie Bender so schön sagen würde: in Worten null ;) )
Das stimmt schon!
Sofern beim Delete * from ohne Where-Bedingungen kein Lock auf der Datei besteht, wird ein CLRPFM ausgeführt. Sofern ein Lock auf der Datei besteht werden lediglich die Sätze gelöscht, jedoch kein RGZPFM ausgeführt, der die gelöschten Sätze auf physisch aus der Datei entfernen würde. Konnte ein CLRPFM ausgeführt werden, so ist auch in diesem Fall die Anzahl der gelöschten Sätze 0 (in Worten NULL)
... das ist übrigens nicht erst seit Release 6.1 so, sondern wurde bereits mit Release V5R3M0 implementiert.
Birgitta
Birgitta
... das ist kein ganz anderes Problem!!!
das ist genau der Effekt, den ich bereits mehrfach erwähnt habe.
delete * from ... einmal Satz weise - stört sich nicht an locks auf die Teildatei, sondern holt sich nacheinander die Satzsperren, sperrarm und lässt konkurrierende open auf die Teildatei zu.
delete * from als CLRPFM ausgeführt - geht wesentlich schneller, stirbt aber an konkurrierenden open auf die Teildatei
letzteres sollte eigentlich nur versucht werden, wenn die Datei frei ist => ergo Bug!!!
Sollte vielleicht so funktionieren, dass wenn kein where definiert ist, löschen von relativer Satznr. 1 bis relativer Satznr. n und nicht clrpfm
lg
Das ein DELETE * FROM TAB1 als CLRPFM ausgeführt wird kann ich mir nicht vorstellen.
Bei einem DELETE (egal ob mit Where oder ohne) stehen nach einem DSPFD TAB1 bei "Gesamtzahl gelöschter Sätze" die Anzahl der gelösten Sätze.
Bei einem CLRPFM steht dort immer 0 (wie Bender so schön sagen würde: in Worten null ;) )
Das ist keine Frage des Glaubens oder der Vorstellung, das ist dokumentiertes Verhalten seit Version 5.3. Für die Ungläubigen unter uns RTFM (SQL Reference V5R3 S. 651).
D*B
andreaspr@aon.at
31-08-11, 08:31
Das stimmt schon!
Sofern beim Delete * from ohne Where-Bedingungen kein Lock auf der Datei besteht, wird ein CLRPFM ausgeführt. Sofern ein Lock auf der Datei besteht werden lediglich die Sätze gelöscht, jedoch kein RGZPFM ausgeführt, der die gelöschten Sätze auf physisch aus der Datei entfernen würde. Konnte ein CLRPFM ausgeführt werden, so ist auch in diesem Fall die Anzahl der gelöschten Sätze 0 (in Worten NULL)
... das ist übrigens nicht erst seit Release 6.1 so, sondern wurde bereits mit Release V5R3M0 implementiert.
Birgitta
Hi Birgitta,
tut mir leid, aber ich kann das nicht nachvollziehen. (5.4 und 7.1).
Mit WRKOBJLCK sehe ich, dass es keine Sperren für die Tabelle gibt, dennoch wird kein CLRPFM ausgeführt.
Wenn das bei euch funktioniert würde es mich sehr interessieren, warum es bei mir auf beiden Systemen nicht geht.
Ich schließe auch gar nicht aus, dass ich eventuell was nicht beachtet habe, komisch ist es dennoch.
andreaspr@aon.at
31-08-11, 08:39
Das ist keine Frage des Glaubens oder der Vorstellung, das ist dokumentiertes Verhalten seit Version 5.3. Für die Ungläubigen unter uns RTFM (SQL Reference V5R3 S. 651).
D*B
Danke für die Doku.
Dass statt einem DELETE ein CLRPFM ausgeführt wird unterliegt mehreren Kriterien.
Bei mir dürfte es daran liegen dass es zu wenige Datensätze sind die gelöscht werden.
Nachtrag:
@nico1964: Eventuell der neuen Maschiene nicht allen Kriterien erfüllt?
Hi Birgitta,
tut mir leid, aber ich kann das nicht nachvollziehen. (5.4 und 7.1).
Mit WRKOBJLCK sehe ich, dass es keine Sperren für die Tabelle gibt, dennoch wird kein CLRPFM ausgeführt.
Wenn das bei euch funktioniert würde es mich sehr interessieren, warum es bei mir auf beiden Systemen nicht geht.
Ich schließe auch gar nicht aus, dass ich eventuell was nicht beachtet habe, komisch ist es dennoch.
... da steht "may be deleted using either a clear operation..." not "are deleted..."
D*B