View Full Version : SQL-Pessimizer
andreaspr@aon.at
01-07-13, 13:28
Witzig wie da gegen Stored Procedures vorgegangen wird!
Alle bis jetzt genannten Punkte deuten darauf hin dass es in diesem Bereich einen großen Wissensbedarf gibt.
Sorry!
In Birgittas und meinen Schulungen werden auch Stored Procedures Schritt für Schritt erklärt (Verwendung, Wartung, Entwicklung uvm.)
Ich will jedoch jetzt nicht auf jeden genannten Punkt eingehen und erklären warum diese teilweise eindeutig falsch sind.
Dafür kann ein neuer Thread erstellt wenn es spezifische Fragen gibt.
lg Andreas
Mich würde auch interessieren ob du das gleiche Problem hast, wenn du die Parameter an eine SQL Prozedur übergibst und von dort dann einfach nur den geöffneten Cursor zurückgibst.
lg Andreas
... diese "Empfehlung" ist doch gerade hier Murks!!! Wenn die stored Procedure Bestandteil eines komplexen Queries wird, geht das doch nur noch über weitere funktionale Logik in weiteren Procedures. Ich gebe hin und wieder Kurse über Datenbank Design inklusive View Layer; wenn ich mal in südlichen Gefilden damit unterwegs bin, gebe ich Dir da gerne einen Rabatt.
D*B
Und ich erstelle dann für jeden SQL, den ein Anwender mit meiner Software selber produziert eine SQL-Prozedur die nichts anderes tut, als diesen SQL auszuführen?
Das Problem liegt im Zusammenspiel zwischen ODBC-Treiber und dem QZDA-Job und lässt sich so ziemlich auf die Abfrage von Spalten-Metadaten (SQL-Schemaabfragen durch ODBC definiert) einschränken.
Mit V7 hat die IBM nämlich einige der Abfragen auf Stored-Procedure umgestellt und genau diese lösen den Querytimeout aus.
Ich möchte nun aber ungern diesen Timeout auf Nomax umstellen da dies weitere Konsequenzen nach sich zieht die die Anwender nur mehr verwirren.
Ein Timeout macht nämlich durchaus sinn.
andreaspr@aon.at
01-07-13, 15:42
Und ich erstelle dann für jeden SQL, den ein Anwender mit meiner Software selber produziert eine SQL-Prozedur die nichts anderes tut, als diesen SQL auszuführen?
War die Frage jetzt ernst gemeint oder seid ihr jetzt einfach nur beleidigt?
@Dieter:
Ich bin mir nicht sicher ob ihr mich beim erstem mal verstanden habt, deshalb nocheinmal im Detail.
Ich habe vorgeschlagen (zum Testen!!) dieses komplexe Query einfach nur in eine SP zu verschieben (copy & paste) und dort als Cursor zurück geben lassen.
Wie ich zuvor schon geschrieben habe, würde mich interessieren, ob das Problem dann noch immer vorhanden ist.
Dabei ging es jetzt auch nicht um eine "Empfehlung" abzugeben sondern weitere Hinweise auf das Problem zu finden.
Wenn man das nun nicht Testen möchte hab ich damit auch kein Problem.
@Andreas:
... ich habe Dein erstes Statement erst im Zusammenhang mit Deinem zweiten pro stoPros mit ResultSet Rückgabe als Empfehlung angesehen (aber da bist Du ja jetzt am zurück rudern).
Was das als zusätzliche Info bringt und was die dann wert sein soll, erschließt sich mir da allerdings ebenfalls nicht; das Statement wird nun einmal als dynamisches SQL gebrauicht, da ist der Informationsgehalt ob die Datenbank das statisch besser kann, nicht einmal akademisch.
D*B
@Dieter
Da hast du nun mal Recht.
@Andreas
Die SQL's werden dynamisch erstellt.
Da ich auf verschiedene Datenbanken mit ODBC gehe ist es mir letztlich egal ob es sich um eine AS/400 handelt.
Nur bei der AS/400 habe ich bessere Analysemöglichkeiten.
Seit V7 hat die IBM bzgl. der Schemaabfragen aus irgendwelchen Gründen alles auf Procedure umgestellt (select * from qsys2.sysprocs).
Man weiß nun leider nicht, was denn in den Prozeduren passiert und die SQL's werden nicht protokolliert.
Bis V6R1 konnte man dei ODBC-Schemaabfragen per QZDAPKG ansehen und der SQL-Optimizer konnte da auch einschreiten.
Dies geht so wohl nicht mehr und führt in Folge zu Problemen, die es bis V6R1 nicht gab.
Die IBM scheint nämlich genau der unsinnigen Empfehlung nachgekommen zu sein, SQL's als Prozeduren zur Verfügung zu stellen, warum auch immer.
ODBC funktioniert so nicht, da nun mal SQL's grundsätzlich dynamisch sind und solange ich keine Businesslogik benötige brauche ich auch keine Prozeduren.
andreaspr@aon.at
01-07-13, 18:07
@Andreas:
... ich habe Dein erstes Statement erst im Zusammenhang mit Deinem zweiten pro stoPros mit ResultSet Rückgabe als Empfehlung angesehen (aber da bist Du ja jetzt am zurück rudern).
Tut mir leid, aber ich glaub du musst den Beitrag genauer lesen.
Wenn du mir den Teil heraussuchen kannst wo eine Empfehlung herauszulesen ist, wäre ich sehr verbunden.
Und ich "rudere" überhaupt nicht zurück, ich finde SPs weiterhin (wenn man weis wo und wie sie einzusetzen sind) für ein sehr nützliches Werkzeug.
@Baldur:
*) SQLs in SPs werden ganz normal behandelt wie wenn du das SQL in RPG oder sonst wo ausführst. (Eintrag im Plan Cache, Monitoring usw.)
*) Speziell über ODBC kannst du SPs auch dynamisch aufrufen.
@ihr beide:
Wenn ihr vernünftig und vor allem sachlich!! weiter diskutieren wollt, können wir gerne genauer auf einzelne Problematiken eingehen, ansonsten sollten wir es diesmal besser lassen.
lg Andreas
... ich verstehe immer weniger, was Du denn nun empfiehlst. Zu sagen, dass stored Procedures ein nützliches Werkzeug sind, wenn man sie richtig einsetzt, ist ja nicht einmal ein Allgemeinplatz, das ist reine Klugscheißerei - der Punkt ist doch: wo sind sie angebracht und wo nicht!!! Ich habe mich da klar positioniert: das von Baldur angeführte Beispiel ist ein klassischer Fall, wo stored Procedures nicht angebracht sind. Und ich verdeutliche hier noch einmal, stored Procedures, die ein ResultSet zurück liefern, können in der Mehrzahl der Fälle durch eine View ersetzt werden und dann sollte man diesen Unfug bleiben lassen.
D*B
Natürlich kann man SPs auch dynamisch aufrufen, aber ich bin dagegen, für jeden SQL dann automatisch eine neue SP zu generieren :).
Gegen SP's mit Businesslogik habe ich ja auch nichts, das mache ich auch so, aber SPs nur für Select's zu erstellen bringt halt mehr Nach- als Vorteile.
Nur um Updates zu verhindern eignen sich spezielle Views und Berechtigungen erheblich besser.
Ansonsten gibt es bei embedded SQL's (auch bei SP's) zur Laufzeit doch noch so den einen oder anderen Unterschied als bei voll dynamischen SQL's wie per ODBC.
Bei embedded SQL's sind keinerlei Metadatenabfragen erforderlich da das Resultset statisch definiert ist.
Bei dynamischem SQL müssen Metadaten abgefragt werden um die Feldtypen zu ermitteln.
Und genau diese sind nun in V7R1 das Problem.
Probier es doch einfach mal mit MS-Access aus per verknüpften Tabellen auf Dateien zuzugreifen.
In meinem Fall enthält die Tabelle 240 Felder und kann nicht eingebunden werden.