Zitat Zitat von Fuerchau Beitrag anzeigen
Ich hatte mal für eine Anwendung alle SQL's auf V5R4 optimiert. Bei V6R1 liefen sie auch noch performant. Nun bei V7R1 muss ich fast alle SQL's noch mal analysieren da sie nicht mehr performant sind.
Dieser Ansatz, SQL Statements so umzubauen, dass sie mit dem vorhandenen Datenbank- und Indexdesign schnell sind, ist Teil des Problems. Die Optimierungen müssen vorrangig am Indexdesign, dann am Datenbankdesign und zuletzt - wenn überhaupt - an der Formulierung bestimmter SQL Statements vorgenommen werden. Wenn zwei verschiedene Beschreibungen derselben Ergebnismenge unterschiedlich schnell ausgeführt werden, dann ist das eher ein Bug als ein Feature der Query Engine - mit der einzigen Ausnahme des optimizing for n rows, das ja die Optimierungsstrategie des Optimizers anspricht. Wenn dann ein Statement auf einen solchen blinden Fleck des Optimizers ausgerichtet wird, dann ist es nur logisch, dass das dann kippt und schlechter wird, wenn der Optimizer besser wird. Chaotisch wurde es dann, als man auf einmal zwei Optimizer hatte, die sich gegenseitig ins Handwerk gepfuscht haben, am Besten hätte man diese Releases komplett übersprungen, wenn man auf SQL setzte.
Ein ähnliches Problem organisiert man sich, wenn man SQL und RLA nebeneinander benutzt, spätestens wenn man bei dem wilden Mix von SQL DDL und DDS landet, der ja sogar von einigen propagiert wird, dann fallen bei der Neuerstellung eines LFs oder eines Index auf einmal ganze Kartenhäuser zusammen, weil das Access path sharing, eine DDS/RLA Altlast, dazu führen kann, dass ein bestimmter Access Path (und den schlägt die QUery engine eigentlich vor) garnicht erstellt wird, wenn man den geforderten Index (nur den kann man erstellen) anlegt. Da braucht man keinen Durcheinander mit CCSIDs und Text-Schlüsselfelder mehr, wenn man den Query Optimizer nicht mehr verstehen will...

D*B