-
SQL Prepare - Verwendeter Zugriffspfad ?
Hallo,
folgende Situation. Wir haben ein Programm mit dem der Anwender nach Adressen suchen kann. Für die Suche kann der User diverse Suchbegriffe angeben. z.Bsp nach Name, Vorname, Straße, Ort, Plz, etc.....
Das Programm verwendet für die suche SQL bzw SQL-CLI.
Der Such-SQL wird entsprechend dynamisch erstellt und mit
PREPARE vorbereitet.
Nun zu meiner Frage.
Vor dem FETCH möchte ich nun prüfen ob SQL für die Ausführung des Statements einen bestehenden Zugriffspfad verwendet oder einen Temporär erstellen muß.
Falls einer erstellt wird wäre es interessant zu wissen wie lange dies dauern würde.
Sollten die "Kosten" zu hoch sein könnte ich den Benutzer auffordern die Suchparameter zu ändern.
Kann vlt. jemand weiterhelfen ???
-
Dazu gibt es leider keine Unterstützung, da die Analyse nur zur Laufzeit tatsächlich durchgeführt wird.
In der QAQQINI kann hinterlegt werden, ob Diagnose-Nachrichten ins Joblog kommen.
Mittels CHGQRYA kann das QRYTIMLMT z.B. auf 1 gesetzt werden, so dass eine Abfrage fast nie ausgeführt wird.
Gibts nun einen SQLCOD -666, wird das Limit überschritten und die Analyse des Joblogs kann starten.
Allerdings würde ich einfach den CHGQRYA generell vorziehen, das Limit z.B. auf 10 Sekunden setzen und bei -666 den User bitten seine Abfrage zu spezifizieren.
-
So etwas kann man übrigens auch über ein normales (nicht on-the-fly) SQL lösen..
Select a, b, c from datei where
(:EingabeA = ' ' or :EingabeA = a) and
(:EingabeB = ' ' or :EingabeB = b) and
(:EingabeC = ' ' or :EingabeC = c)
Damit hast du immer denselben Zugriffsweg und die angenehmen Performancevorteile.
Damit habe ich die prepare Statements bei mir auf flexible Sortierung bzw flexible Feldauswahl eingeschränkt (was einen erheblichen Performancegewinn bringt)
Schönen Gruß
Rince
-
Zitat von Fuerchau
Dazu gibt es leider keine Unterstützung, da die Analyse nur zur Laufzeit tatsächlich durchgeführt wird.
In der QAQQINI kann hinterlegt werden, ob Diagnose-Nachrichten ins Joblog kommen.
Mittels CHGQRYA kann das QRYTIMLMT z.B. auf 1 gesetzt werden, so dass eine Abfrage fast nie ausgeführt wird.
Gibts nun einen SQLCOD -666, wird das Limit überschritten und die Analyse des Joblogs kann starten.
Allerdings würde ich einfach den CHGQRYA generell vorziehen, das Limit z.B. auf 10 Sekunden setzen und bei -666 den User bitten seine Abfrage zu spezifizieren.
Das die Analyse erst zur Laufzeit erfolgen soll kann ich nicht ganz nachvollziehen. Wenn ich vor dem FETCH den Befehl
PRTSQLINF OBJ(*JOB) ausführe erhalte ich einen Spool mit genau den Informationen die ich benötigen würde.
siehe Beispiel
Für diese sollte es doch auch APIs geben ??
PHP-Code:
STATEMENT NAME: SQLSTATEMENT000003
select * from stamm where stmcnam = ? and stmcnam1 = ? and upper(stvnm) =
upper(?) and upper(stnam) = upper(?)
SQL4021 Zugriffsplan zuletzt am 24.03.06 um 11:03:43 gesichert.
SQL4020 Geschätzte Abfrageausführungszeit beträgt 1 Sekunden.
SQL4017 Host-Variablen als wiederverwendbarer ODP implementiert.
SQL4006 Alle Indizes für Tabelle 1 berücksichtigt.
SQL4008 Index STAMMRC02 für Tabelle 1 verwendet.
-
API's kann ich leider keine finden, haber siehe mal hier:
http://publib.boulder.ibm.com/infoce...69%6e%66%22%20
Die Informationen können sich mit dem tatsächlichen FETCH immer noch ändern, so dass die Daten erst richtig gültig sind, wenn Daten gelesen wurden.
Ansonsten ist es ein vorläufiger Zugriffsplan.
Es bleibt dir nichts anderes übrig als CHGQRYA, QAQQINI und die Joblog-Nachrichten zu verwenden.
Besser finde ich allerdings die Methode von Rince, da die Zugriffspläne sich dann nicht ändern und man alle Varianten vorher testen kann um bereits selber Indizees anzulegen.
-
Hallo,
im Package stehen nur Informationen drin für "Varianten", die bereits ausgeführt wurden und selbst diese Informationen sind nicht zuverlässig: die Schätzun kann (grob) falsch sein und der Zugriffsplan kann bei der nächsten Ausführung ein anderer sein.
Bei dem Weg über QRYA, egal ob Job oder QAQQINI ist die Krux ebenfalls, dass die estimates ses Query Optimizers zuweilen per würfeln ermittelt werden - das hat mit der realen Ausführung oft nix zu tun; da werden aus 0 Sekunden schon mal Minuten und 20 Sekunden können ratz fatz um sein.
Kontrollieren lässt sich das nur über Restriktionen und weniger Dynamik, oder man kann durch entsprechendes Datenbank Design und Indexe vorbeugen und Problemkandidaten (per DBMON) ermitteln und nachbessern.
mfg
Dieter Bender
Zitat von sim
Das die Analyse erst zur Laufzeit erfolgen soll kann ich nicht ganz nachvollziehen. Wenn ich vor dem FETCH den Befehl
PRTSQLINF OBJ(*JOB) ausführe erhalte ich einen Spool mit genau den Informationen die ich benötigen würde.
siehe Beispiel
Für diese sollte es doch auch APIs geben ??
PHP-Code:
STATEMENT NAME: SQLSTATEMENT000003
select * from stamm where stmcnam = ? and stmcnam1 = ? and upper(stvnm) =
upper(?) and upper(stnam) = upper(?)
SQL4021 Zugriffsplan zuletzt am 24.03.06 um 11:03:43 gesichert.
SQL4020 Geschätzte Abfrageausführungszeit beträgt 1 Sekunden.
SQL4017 Host-Variablen als wiederverwendbarer ODP implementiert.
SQL4006 Alle Indizes für Tabelle 1 berücksichtigt.
SQL4008 Index STAMMRC02 für Tabelle 1 verwendet.
-
Dem kann ich auch nur zustimmen.
Es gibt schon mal wesentliche Unterschiede zwischen STRSQL (weil Dialog) und embedded SQL/ODBC (weil Batch).
Bei ODBC setze ich die QueryTimeouts mittlerweile auf 30.000 Sekunden, da die Schätzungen häufig um Faktor 1000! daneben liegen. Die tatsächliche spätere Abfragezeit bewegt sich dann zwischen 1 und 30 Sekunden.
Da fragt man sich, was der Optimizer? da wohl so treibt !
-
Hallo,
mit der angeblich so grandiosen neuen Query Engine zunehmend Dummfug, mit parallel Database Feature entdeckt die Query engine ihr Herz für full table scans mit grandiosem Ressourcenverbrauch wahrscheinlich wird mit dem nächsten Group PTF dann die automatische Hardwarebestellung ermöglicht...
mfg
Dieter Bender
Zitat von Fuerchau
Dem kann ich auch nur zustimmen.
Es gibt schon mal wesentliche Unterschiede zwischen STRSQL (weil Dialog) und embedded SQL/ODBC (weil Batch).
Bei ODBC setze ich die QueryTimeouts mittlerweile auf 30.000 Sekunden, da die Schätzungen häufig um Faktor 1000! daneben liegen. Die tatsächliche spätere Abfragezeit bewegt sich dann zwischen 1 und 30 Sekunden.
Da fragt man sich, was der Optimizer? da wohl so treibt !
-
Zitat von Rincewind
So etwas kann man übrigens auch über ein normales (nicht on-the-fly) SQL lösen..
Select a, b, c from datei where
(:EingabeA = ' ' or :EingabeA = a) and
(:EingabeB = ' ' or :EingabeB = b) and
(:EingabeC = ' ' or :EingabeC = c)
Damit hast du immer denselben Zugriffsweg und die angenehmen Performancevorteile.
Damit habe ich die prepare Statements bei mir auf flexible Sortierung bzw flexible Feldauswahl eingeschränkt (was einen erheblichen Performancegewinn bringt)
Schönen Gruß
Rince
So etwas hat mit performanten SQL nichts mehr zu tun. Diese Logik führt dazu, das die Abfrage immer in einem kompletten Table-Scan endet.
Ich habe das einmal Beispielhaft an eine Datei mit 2.1 Mio Sätzen durchgeführt. In der WHERE-Bedingung stehen zwei Parameter, einmal direkt angegeben und einmal mit der geklammerten OR-Angabe, Index über diese beiden Werte vorhanden.
Zeiten aus dem VE:
195234 Mikrosekunden Direktangabe
12920528 Mikrosekungen geklammerte OR-Angabe.
Mit solchen OR-Abfrage kann der Optimizer nichts mehr anfangen. Da ist eine prepare-Abfrage immer vorzuziehen. Statisches SQL macht nur bei bekannter Parameter-Anzahl Sinn.
Bei dem Problem von sim wäre es besser, für gängige Abfragefelder Indizies aufzubauen. Nicht so häufig benutzte Felder sollten separat mit dem Hinweis auf die lange Ausführdauer aufgeführt werden (eventuell separatem Window über Funktionstaste).
Gruß
M.Withake
Similar Threads
-
By olbe in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 28-12-06, 13:53
-
By christian_lettner in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 16-11-06, 10:15
-
By FNeurieser in forum NEWSboard Programmierung
Antworten: 3
Letzter Beitrag: 11-10-06, 14:53
-
By Kaufmann in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 28-06-06, 14:11
-
By loeweadolf in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 01-06-06, 09:43
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks