-
Moin zusammen,
Gestern ist der Aufruf (ohne Änderungen) vom Admin nach 1,5 Stunden abgebrochen worden, da es das System gebremst hat.
Ich hatte, parallel zu dem Lauf, ein paar LF gemäß Debug Empfehlung angelegt
(obwohl ich nicht wirklich einsehe auf Dateien mit max. 50 Sätzen zusätzliche LF zu legen)
Der 2. Aufruf (mit den LF) war dann wieder schnell.
Heute morgen läuft er wieder endlos, die LF Empfehlungen sind andere.
Vorgestern war (den ganzen Tag, auch der 1. Aufruf) alles schnell, nun ist es wieder 'mal so, mal so'
Wenn immer der 2 Aufruf schneller ging, ok aber selbst das ist nicht (immer) so.
Habe die View Erstellung und das letzte Posting von Baldur nun an 2 Kollegen gegeben.
Vielleicht können die noch was verschlimbessern!
Danke allen die uns unterstützt haben.
Robi
-
Nachtrag:
durch den eingeschalteten DEBUG kommt ein Spool raus : JOBSQL
In dem steht, nach jedem aufgelisteten SQL-Statement:
SQL4021 Zugriffsplan zuletzt am 19.02.15 um 15:48:46 gesichert.
SQL4020 Geschätzte Abfrageausführungszeit beträgt 0 Sekunden.
....
...das nächste Statement
SQL4021 Zugriffsplan zuletzt am 19.02.15 um 16:15:38 gesichert.
SQL4020 Geschätzte Abfrageausführungszeit beträgt 0 Sekunden.
Bleibe dabei ... am Zugriff kann es nicht liegen
Robi
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
Dann würde ich dir eine Fehlermeldung an IBM empfehlen.
-
Ich kann da so manche bzgl. des Optimizers schon verstehen.
Seit V7R1 laufen da halt viele SQL's langsamer.
Ich habe nun eine QAQQINI-Option ausgeschaltet:
FORCE_JOIN_ORDER *YES
Damit verhindere ich das Umbauen der Joins durch den Optimizer. Schließlcih habe ich mir bei den Joins und den On-Beziehungen was gedacht und entsprechende Indizes angelegt.
Und siehe da:
Ein SQL der mit V6R1 noch schnell war, mit V7R1 sporadisch, also wie oben nicht immer, 30 Minuten brauchte, läuft nun immer unter 1 Minute (Gesamtverarbeitung, nicht nur die Abfrage selber).
Na wer sagt's denn!!!!
-
Zitat von Fuerchau
Ich kann da so manche bzgl. des Optimizers schon verstehen.
Seit V7R1 laufen da halt viele SQL's langsamer.
Ich habe nun eine QAQQINI-Option ausgeschaltet:
FORCE_JOIN_ORDER *YES
Damit verhindere ich das Umbauen der Joins durch den Optimizer. Schließlcih habe ich mir bei den Joins und den On-Beziehungen was gedacht und entsprechende Indizes angelegt.
Und siehe da:
Ein SQL der mit V6R1 noch schnell war, mit V7R1 sporadisch, also wie oben nicht immer, 30 Minuten brauchte, läuft nun immer unter 1 Minute (Gesamtverarbeitung, nicht nur die Abfrage selber).
Na wer sagt's denn!!!!
... bei mehrfachen beteiligten an einem join geht das Datenvolumen schon mal steil nach oben, wenn die Query engine sich für einen Crossjoin und spätere Auswertung der where clause entscheidet. Ich würde in jedem Fall erstmal dafür sorgen, dass ich primary keys und referential constraints habe und im skizzierten Szenario kriegt man die Faxen relativ sicher mit Extrakten, die man dann verjoint weg.
D*B
-
Der Sch.... ist doch, dass ich die ganze Optimierungsarie bereits mit V5R3 für abgeschlossen hielt.
Bis V6R1 hielt sich die IBM ja auch daran.
Aber seit V7R1 muss ich ständig wieder dran.
Ich kann die anderen da schon verstehen, aber den Optimizer nicht.
Wenn ich schon einen Join mit F1/F2/F3 mache und ein Index in dieser Folge besteht, weiß ich nicht warum der Optimizer einen Index mit F1/F3/F2 vorschlägt. Manchmal auch nur ein einzelnes Feld, z.B. nur F3, aber im Plan dann doch wieder meinen Index nimmt.
Aber wie du schon sagst, auch kleine Dateien mit wenigen Sätzen benötigen einen vernünftigen Index.
Wenn ich 1Mio Sätze mit so einer kleinen Datei verknüpfe und kein vernünftiger Index besteht erwinge ich da schon 1Mio Mal einen Tablescan. Bei einer 100-Satzdatei können das im Zweifel halt mal 50 Zugriffe sein, macht in Summe dann 50Mio. Wenn ich dann noch mehrere davon habe...
Ich hatte da auch schon mal eine solche Abfrage, die grobgerechnet 100 Milliarden Zugriffe erfordert.
Da kann man sich dann schon mal einen Kurzurlaub gönnen.
-
... das Problem ist zuweilen, dass der Optimizer die Selektivität von where Bedingungen nicht korrekt einschätzt und dann, je nachdem ob das gerade ein pessimistisches oder ein optimistisches Release ist, einen Hang zum Full table scan entwickelt. Letzteres lässt sich zuweilen mit optimize for 1 row oder mit einem order by nach Feldern der größten Tabelle zähmen.
D*B
-
Das habe ich auch schon versucht und ist bei kleinen Datenmengen hilfreich.
Bei größeren Datenmengen (BI-Daten gehen ja schon mal in die Millionen) schlägt sich das in der Gesamtlaufzeit nieder, da nach dem 1. Block an Daten wieder auf der DB genudelt wird bis der nächste Block fertig ist.
Das Handbuch schlägt ja auch vor so was zu machen, wenn ein Dialoguser z.b. den Query vorher beendet (wer schaut sich denn wirklich die 500.000 Googletreffer an).
Google ist dann aber auch nicht schneller wenn man dann tatsächlich mal die 500.000 Ergebnisse haben will.
Similar Threads
-
By Mr-Ferret in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 28-02-14, 10:35
-
By Sho2 in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 01-12-02, 15:49
-
By Peter Kosel in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 27-11-02, 11:32
-
By stefan400 in forum NEWSboard Server & Hardware Markt
Antworten: 0
Letzter Beitrag: 17-10-02, 09:47
-
By cassandra in forum IBM i Hauptforum
Antworten: 8
Letzter Beitrag: 10-09-02, 15:01
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